개념 30문항

C1. 레이크하우스가 데이터 레이크와 다른 점

• 답: 객체 스토리지 위의 파일을 오픈 테이블 포맷(Iceberg 등)으로 "테이블"로 승격해 ACID 트랜잭션·스냅샷 격리·스키마/파티션 진화·파일 통계 기반 프루닝·멀티 엔진 호환을 제공한다.
• 메커니즘/근거: 테이블 포맷이 메타데이터 계층(스냅샷→매니페스트→파일)으로 커밋을 원자적으로 관리하므로 DW와 레이크를 두 벌 운영하며 생기던 이중 적재·불일치가 사라진다.
• 함정: "Parquet를 S3에 쌓은 것"은 레이크일 뿐이다. 레이크가 스웜프가 되는 원인은 ACID·스키마·계보 부재이며, 해법은 테이블 포맷 + 카탈로그 + 컨트랙트다.

C2. 메달리온 아키텍처 3계층

• 답: Bronze(원본 그대로·불변·수집 메타) → Silver(정제·중복 제거·표준화·PII 비식별·SCD2) → Gold(차원 모델·집계·피처·메트릭).
• 메커니즘/근거: 계층 경계가 품질 게이트 위치다 — Bronze→Silver에서 컨트랙트 검증, Silver→Gold에서 비즈니스 규칙 검증, 실패 시 격리(quarantine).
• 적용 예: K생명은 Silver 진입 시 결정론적 토큰화로 PII를 제거해 Gold 이하 전 계층을 비식별로 운영한다. Gold만 두고 원본을 버리면 재처리가 불가능하다.

C3. Iceberg 스냅샷의 용도 2가지

• 답: ① 타임트래블·롤백(FOR SYSTEM_VERSION/TIME AS OF), ② 증분 읽기(두 스냅샷 간 변경분 추출).
• 메커니즘/근거: 모든 커밋이 새 스냅샷(매니페스트 리스트)을 남기고 이전 파일을 즉시 삭제하지 않으므로 과거 상태를 그대로 읽을 수 있다. ML 학습 데이터 재현의 핵심이다.
• 함정: 스냅샷을 만료(expire_snapshots)하지 않으면 스토리지가 누적되고 개인정보 삭제 요청이 과거 스냅샷에 남아 이행이 불완전해진다 — 보존 정책과 삭제 의무의 충돌 지점.

C4. 파티션 진화(partition evolution)

• 답: 기존 데이터를 재작성하지 않고 파티션 전략(예: days(ts) → hours(ts))을 바꾸며, 메타데이터가 두 레이아웃을 함께 질의한다.
• 메커니즘/근거: Iceberg는 변환 함수 기반 히든 파티셔닝을 쓰므로 파티션 스펙이 메타데이터에 버전으로 기록되고, 플래너가 스펙별로 프루닝을 적용한다.
• 함정: 과도한 파티셔닝으로 소형 파일이 폭증하는 것이 가장 흔한 실패다. 파일 크기 128MB~1GB를 목표로 컴팩션을 병행한다.

C5. SCD Type 2

• 답: 속성이 바뀔 때 기존 행을 덮지 않고 새 행을 추가하며, 유효 시작·종료일과 현재 플래그로 이력을 보존한다.
• 메커니즘/근거: 팩트 조인 시 사건 시각 BETWEEN 유효시작 AND 유효종료 조건으로 "그 시점의 차원 값"을 복원한다. Feature Store의 point-in-time 조인과 동일 원리다.
• 적용 예: 보험금 심사 모델의 재현성을 위해 dim_customer는 SCD2가 필수다. Type 1(덮어쓰기)로 두면 언더라이팅 기준 재현이 불가능하다.

C6. Data Vault 3요소

• 답: Hub(비즈니스 키 + 해시 키 + 최초 적재 시각 + 소스), Link(Hub 간 관계), Satellite(설명 속성과 변경 이력).
• 메커니즘/근거: 소스 스키마 변화를 Satellite 추가로 흡수하고, 해시 디프로 변경을 감지하므로 다수 소스 통합과 감사 추적(“언제 어떤 소스에서”)에 강하다.
• 함정: 조인 수가 많아 직접 분석에 부적합하므로 Silver(통합 계층)에만 쓰고 Gold는 Kimball로 간다. 12명 팀에 전면 도입은 과하며 핵심 엔티티(계약·고객·청구)에 한정한다.

C7. Feature Store의 point-in-time correctness

• 답: 학습 샘플의 사건 시각 기준으로 “그때 실제로 알 수 있었던” 최신 피처 값만 조인해 미래 정보 누수(leakage)을 막는다.
• 메커니즘/근거: ASOF 조인(feature_ts <= event_ts 중 최신)으로 구현하며, 오프라인 스토어(Iceberg)의 이력 테이블이 전제다.
• 함정: "현재 피처 값"으로 과거 샘플을 조인하면 오프라인 성능은 좋고 온라인은 나쁜 전형적 누수가 생긴다.

C8. Training-serving skew

• 답: 학습과 서빙에서 피처 계산 로직 또는 데이터 분포가 달라 모델 성능이 저하되는 현상.
• 메커니즘/근거: 오프라인(배치 SQL)과 온라인(애플리케이션 코드)이 같은 피처를 따로 구현하면 미세한 차이(반올림·널 처리·윈도우 경계)가 누적된다. 피처 레지스트리에 정의를 한 번만 두고 양쪽이 공유해 완화한다.
• 적용 예: K생명 온라인 피처(100ms)는 KV 스토어에 "최신 상태"만 두되, 계산 정의는 오프라인 Gold와 동일 레지스트리를 참조한다.

C9. 데이터 컨트랙트

• 답: 생산자–소비자 간 스키마·의미·SLA·품질 규칙·소유권을 코드로 선언하고 CI에서 검증하는 계약.
• 메커니즘/근거: 벤더 중립 표준은 ODCS(Bitol)이며 datacontract CLI·Soda가 네이티브 지원한다. 스키마 변경은 호환성 규칙(하위 호환 추가만 허용 등)으로 통제한다.
• 적용 예: 이관 후 월말 집계 불일치(정밀도·시간 기준)를 막으려면 컨트랙트에 DECIMAL 정밀도와 기준 타임존을 명시한다.

C10. 시맨틱 레이어

• 답: 지표·차원·조인 정의를 중앙화해 BI·사람·LLM이 같은 정의로 질의하게 하는 계층(dbt MetricFlow, Cube 등).
• 메커니즘/근거: LLM에 물리 테이블 대신 메트릭·차원 API를 도구로 주면 ① 지표 정의 통일, ② 권한·행 필터 강제, ③ 존재하지 않는 조인(환각) 구조적 차단의 세 가치를 얻는다.
• 함정: DDL을 프롬프트에 넣는 방식은 조인 경로 추론 실패와 지표 재정의를 막지 못한다.

C11. 온톨로지 vs 데이터 카탈로그

• 답: 온톨로지는 도메인 개념·관계의 형식 모델(OWL 클래스/관계, SKOS 용어, SHACL 검증), 카탈로그는 데이터 자산의 메타데이터 인벤토리(자산·소유자·리니지·분류).
• 메커니즘/근거: 카탈로그 용어집이 온톨로지 개념을 참조해 "코어의 CONT_NO와 CRM의 policy_number는 같은 개념"을 기계가 읽게 한다.
• 적용 예: 보험 온톨로지(당사자–상품–계약–담보–청구)를 GraphRAG 엔티티 추출 프롬프트와 Text-to-SQL 용어집에 공통 제공한다.

C12. CDC 로그 기반 vs 쿼리 기반

• 답: 로그 기반(Debezium/DMS)은 트랜잭션 로그(redo/LSN)를 읽어 저부하로 삽입·갱신·삭제를 모두 포착하고 순서를 보장한다. 쿼리 기반은 타임스탬프 컬럼을 폴링해 원천에 부하를 주고 삭제를 놓친다.
• 메커니즘/근거: CDC 레코드에 op(c/u/d)·ts_ms·lsn을 보존해 순서·멱등 처리에 쓴다.
• 실패 모드: 쿼리 기반은 물리 삭제·같은 타임스탬프 내 다중 변경을 누락한다. 로그 접근이 불가하면 쿼리 기반 + 소프트 삭제 + 지연 허용으로 타협하고 답안에 명시한다.

C13. Exactly-once의 현실적 구현

• 답: "at-least-once 전달 + 멱등 소비"를 기본으로 하고, exactly-once는 트랜잭션 싱크가 있는 구간(Kafka↔Flink↔Iceberg)에 한정해 보장한다.
• 메커니즘/근거: Kafka 멱등 프로듀서 + 트랜잭션, Flink 체크포인트 + 2단계 커밋(Iceberg 싱크는 체크포인트 단위 커밋), 싱크는 비즈니스 키 + 버전(LSN/ts) 기반 MERGE INTO로 최신 버전만 반영.
• 실패 모드: 외부 API(임베딩) 호출은 트랜잭션에 못 넣으므로 chunk_id + model_version 키로 중복 호출을 막지 않으면 재시도 시 비용이 중복 발생한다.

C14. BM25의 핵심 요소

• 답: 용어 빈도 포화(k1, 기본 1.2), 역문서 빈도(IDF), 문서 길이 정규화(b, 기본 0.75).
• 메커니즘/근거: 같은 단어가 반복돼도 점수가 선형이 아니라 포화하고, 짧은 문서를 b만큼 우대한다. 점수는 코퍼스 통계(IDF)에 의존하므로 인덱스·샤드가 다르면 값이 달라진다.
• 함정: 그래서 BM25 점수를 코사인 점수와 그대로 더할 수 없다 → RRF 또는 정규화 융합이 필요하다.

C15. 한국어 검색에서 형태소 분석기가 필요한 이유

• 답: 조사·어미가 결합하고 복합명사가 붙어 쓰이므로 공백 토큰화로는 질의와 문서 토큰이 일치하지 않는다. nori(mecab-ko-dic 기반)로 분해해 일치율을 높인다.
• 메커니즘/근거: decompound_mode: mixed로 복합명사의 원형과 분해형을 모두 색인하고, nori_part_of_speech로 조사·어미를 제거한다.
• 적용 예: 사내 상품명·약어는 사용자 사전, 유사 표현은 검색 시 동의어 필터 — "분석기 + 사용자 사전 + 동의어"는 세트이며 사전 운영 프로세스가 없으면 품질이 퇴화한다.

C16. HNSW의 M, ef_construction, ef_search

• 답: M은 노드당 간선 수(16~48, 메모리·정확도), ef_construction은 색인 시 후보 수(100~512, 그래프 품질·빌드 시간), ef_search는 질의 시 후보 수(≥k, 100~512, 재현율·지연).
• 메커니즘/근거: 메모리 ≈ 1.1 × (4d + 8M) B/벡터 — d=1024, M=16이면 약 4.6KB/벡터, 1,000만 벡터 ≈ 46GB(int8 ≈ 12.7GB). M이 8 늘면 벡터당 70B가 더 든다.
• 함정: 운영 중 조정 가능한 파라미터는 ef_search뿐이다(M·ef_construction은 재빌드). ef_search를 올리면 재현율이 오르는 대신 지연이 늘므로 SLO 안에서 recall@10 ≥ 0.95 같은 목표를 맞춘다.

C17. pre-filter vs post-filter

• 답: pre-filter는 조건을 만족하는 후보 집합에서 ANN을 수행하고, post-filter는 ANN 결과 top-k를 얻은 뒤 조건으로 거른다.
• 메커니즘/근거: post-filter는 k개 중 권한 밖 문서를 걸러내면 결과가 비는 "top-k 고갈"이 생기고, 필터 전 결과가 애플리케이션에 노출될 수 있다. OpenSearch efficient filtering은 필터 선택도에 따라 정확 k-NN으로 전환해 pre-filter 재현율을 지킨다.
• 실패 모드: 권한 필터를 post-filter로 두면 “봐야 할 문서를 못 찾는” 재현율 손실과 “안 보여줄 문서가 LLM 컨텍스트에 들어가는” 유출이 동시에 발생한다.

C18. RRF 수식

• 답: RRF(d) = Σ_i 1 / (k + rank_i(d)), k = 60(관례). 각 검색기의 순위만 쓰고 점수는 버린다.
• 메커니즘/근거: 예: 문서 A가 BM25 1위·벡터 3위면 1/61 + 1/63 ≈ 0.0323, 문서 B가 BM25 2위·벡터 1위면 1/62 + 1/61 ≈ 0.0325로 B가 앞선다. k는 상위 순위의 지배력을 완화하는 상수로, 작을수록 1위 가중이 커진다.
• 함정: 스케일 무관·무튜닝이 장점이지만 질의 유형별 가중을 줄 수 없다. 골든셋이 확보되면 정규화(min-max/z-score) 가중합과 비교해 선택한다.

C19. 재순위화(cross-encoder)가 bi-encoder와 다른 점

• 답: bi-encoder는 질의와 문서를 독립 인코딩해 빠르지만 상호작용을 못 보고, cross-encoder는 (질의, 문서) 쌍을 함께 입력해 정밀 점수를 내지만 후보마다 추론이 필요해 느리다.
• 메커니즘/근거: 그래서 2단계 파이프라인(넓게 검색 top-50~100 → 재순위 top-5~10)이 표준이며, 지연은 후보 수 N에 선형(+200~400ms 수준)이다.
• 적용 예: 재순위화는 nDCG@5를 가장 크게 올리는 단일 개선 수단인 경우가 많으므로 골든셋으로 lift를 측정해 정당화하고, 캐시 적중 질의는 건너뛴다.

C20. Small-to-big(부모-자식) 청킹

• 답: 작은 자식 청크로 검색해 정밀도를 확보하고, 생성 시에는 부모 청크(조·절·문서)를 컨텍스트로 전달한다.
• 메커니즘/근거: 검색 단위와 생성 단위를 분리하면 짧은 청크의 임베딩 변별력과 긴 문맥의 완결성을 동시에 얻는다. 저장은 2배가 된다.
• 적용 예: 약관은 "항"으로 검색하고 “조” 전체를 LLM에 준다. Bedrock KB의 hierarchical chunking이 같은 패턴이다.

C21. HyDE

• 답: 질의에 대한 가상의 답변 문서를 LLM으로 생성하고 그 임베딩으로 검색해, 짧은 질의와 긴 문서 사이의 표현 격차를 줄인다.
• 메커니즘/근거: 문서–문서 유사도가 질의–문서 유사도보다 안정적이라는 점을 이용한다.
• 함정: 환각된 가상 답변이 검색을 오도할 수 있고, 도메인 지식이 LLM에 없으면 역효과다. 사내 전문 용어 질의에는 multi-query나 사용자 사전이 더 안전하다.

C22. Lost-in-the-middle

• 답: LLM이 긴 컨텍스트의 중간에 위치한 정보를 덜 활용하는 현상.
• 메커니즘/근거: 주의(attention)가 시작·끝에 편중되므로 가장 관련 높은 청크를 앞과 끝에 배치하거나 문서별로 그룹화하고, 컨텍스트를 토큰 예산 내로 축소한다.
• 적용 예: 진단형 문제에서 "커넥터 추가 후 컨텍스트가 길어졌다"는 변경은 이 현상의 유력 가설이다.

C23. RAGAS 4대 지표

• 답: faithfulness(답이 컨텍스트에 근거하는가), answer relevancy(답이 질의에 적합한가), context precision(검색된 컨텍스트 중 관련 비율·순위), context recall(정답에 필요한 정보가 컨텍스트에 있는가).
• 메커니즘/근거: 앞 둘은 생성 품질, 뒤 둘은 검색 품질을 측정하므로 품질 저하 시 "어디서 깨졌는가"를 분리할 수 있다.
• 함정: LLM-as-judge 편향이 있으므로 사람 샘플 검증으로 보정하고, 변경 시 임계값(예: faithfulness −3pp)에 걸리면 배포를 차단한다.

C24. nDCG@k

• 답: 순위 위치를 log2로 할인한 등급 관련도 이득(DCG)을 이상적 순위의 DCG(IDCG)로 나눠 0~1로 정규화한 순위 품질 지표.
• 메커니즘/근거: 예: 관련 문서가 2위·4위에만 있으면 DCG@5 = 1/log2(3) + 1/log2(5) = 0.631 + 0.431 = 1.062, IDCG@5 = 1/log2(2) + 1/log2(3) = 1.631 → nDCG@5 = 0.651.
• 함정: MRR은 첫 관련 문서의 순위만 보지만 nDCG는 모든 관련 문서의 등급·순위를 합산하므로 재순위화 효과 측정에 적합하다.

C25. 문서 수준 보안(DLS)

• 답: 각 문서(청크)에 허용 주체 목록(acl_principals)을 저장하고, 질의 시 사용자의 그룹 집합으로 필터해 권한 밖 문서를 검색 단계에서 제외한다.
• 메커니즘/근거: 애플리케이션이 filter 절을 주입(조기 필터)하고, 엔진의 Security 플러그인 DLS를 역할에 바인딩해 버그 시 2차 방어한다. ACL 변경은 본문 재임베딩 없이 필드만 5~15분 주기로 부분 갱신한다.
• 적용 예: 디렉터리 그룹 멤버십은 토큰 또는 수 분 TTL 캐시에서 해석하며, 매핑 실패 시 기본 거부(deny by default)다.

C26. 간접 프롬프트 인젝션

• 답: 검색된 문서 내용에 숨은 지시(흰 글씨·주석·메타데이터)가 LLM을 조종하는 공격.
• 메커니즘/근거: 인제스천 시 숨김 텍스트 제거, 자료를 데이터로 취급하는 프롬프트 구조(시스템/사용자/자료 분리), 도구 호출 권한 최소화, 출력 URL·명령 허용목록으로 완화한다.
• 함정: 에이전트형(도구 호출)에서는 문서 한 줄이 쓰기 도구를 실행시킬 수 있어 치명적이다. MCP 도구 설명 자체도 인젝션 벡터(tool poisoning)다.

C27. 6R 중 Repurchase와 Retire

• 답: Repurchase는 차별화 요소가 아닌 기능(BI·카탈로그·검색 일부)을 SaaS/상용 제품으로 대체, Retire는 사용 로그상 미접근 자산을 폐기해 범위·비용을 즉시 줄이는 전략.
• 메커니즘/근거: Retire는 이관·검증 대상 자체를 줄이므로 가장 먼저 검토한다(예: 미접근 테이블·비활성 리포트 30% 폐기).
• 함정: 분기·연 1회 접근 자산을 오탐하지 않도록 접근 로그를 최소 13개월 확보하고, 규제 보존 의무 자산은 Retire가 아니라 아카이브다. Repurchase는 데이터 레지던시·망분리 요건을 SaaS가 못 맞추면 불가하다.

C28. Strangler Fig

• 답: 신 시스템이 레거시 기능을 하나씩 가로채며 점진 대체하고, 신규 요청은 신 플랫폼에만 구현해 레거시를 서서히 축소한 뒤 최종 폐기하는 패턴.
• 메커니즘/근거: 전제는 레거시 앞에 파사드(뷰·API·alias)를 둘 수 있어야 한다는 것이다. 파사드가 라우팅을 바꾸므로 기능 단위 롤백이 가능하다.
• 함정: 직접 DB 접속 리포트가 많아 파사드를 못 두면 적용 불가이며, 금융권 DW에서는 Phased + Parallel Run과 조합해 쓴다.

C29. Reconciliation 6계층

• 답: ① 행 수 → ② 열 집계(SUM/COUNT DISTINCT/MIN/MAX) → ③ 행 해시 합 → ④ 샘플 행 전수 비교 → ⑤ 통계 분포(히스토그램·분위수·NULL률, KS 검정) → ⑥ 다운스트림 리포트 수치. 비용과 신뢰가 함께 오른다.
• 메커니즘/근거: 파티션 단위 비교 결과를 테이블로 적재하고 허용 오차(규제 보고 금액 합 차이 0, 일반 0.01% 수준, 분포 p > 0.05)로 N주 연속 일치 시 컷오버 게이트를 자동 통과시킨다.
• 실패 모드: 해시 합이 거짓 불일치를 내는 원인은 숫자·날짜 포맷, 타임존, 문자셋(EUC-KR), NULL/빈 문자열 표기, 엔진별 해시 함수 차이 — 정규화 문자열을 먼저 합의해야 한다.

C30. Blue/green 인덱스 전환

• 답: 애플리케이션은 alias(search-docs)만 참조하고, 신 인덱스(green)를 병행 구축·골든셋 검증한 뒤 alias를 원자적으로 교체하며, 문제 시 이전 인덱스(blue)로 즉시 복귀한다.
• 메커니즘/근거: alias 스왑은 원자적이므로 Big Bang이 허용되는 "원자적 전환 단위"의 대표 예다. 쓰기 alias와 읽기 alias를 분리하면 전환 중 신규 문서 유실을 막는다.
• 적용 예: 임베딩 모델 교체는 벡터 공간이 비호환이라 전면 재임베딩이 필요하므로, 인덱스명에 모델 버전을 넣고 접근 빈도 순으로 재임베딩한 뒤 alias를 스왑한다. 이중 스토리지 비용이 대가다.