데이터 엔지니어 면접 질문

답변 구조 — 결정적인 정렬을 사용하는 윈도 함수

row_number() over (partition by event_id order by updated_at desc, ingestion_at desc, source_sequence desc)로 순번을 부여하고 1번을 남깁니다. 같은 시각이 있을 수 있으므로 updated_at만으로는 결정적이지 않을 수 있습니다. event_id가 사업상 키인지, 이후 업데이트가 이전 이벤트를 대체하는지 확인합니다. 증분 처리에서는 되돌아보는 기간이나 MERGE로 지연 데이터를 처리하고 멱등하게 씁니다. 중복, null 키, 충돌은 조용히 버리지 않고 측정합니다.

답변 구조 — 유효 활동 → 날짜 → 고유 사용자 → 증분 파티션

먼저 활동으로 셀 이벤트와 제외할 테스트, 봇, 내부 사용자를 정의합니다. event_at을 합의한 시간대와 날짜로 정규화하고 날짜별 고유 user_id를 셉니다. 프로덕션에서는 event_date로 파티셔닝하고 재실행을 멱등하게 만들며 지연 이벤트를 처리하고 품질 검사를 추가합니다. 입력 및 출력 건수와 비정상 변화를 모니터링하고 정의와 최신성을 문서화합니다.

답변 구조 — 변화 파악 → 실행 계획 → 용량 → 조인 및 조건 → 자원

성능 저하가 시작된 시점과 코드, 스키마, 용량, 분포, 통계, 파티션, 컴퓨팅 자원의 변경을 확인합니다. 실행 계획을 비교해 전체 스캔, 비효율적인 조인, 디스크 스필, 데이터 쏠림, 파티션 프루닝 부족을 찾습니다. 행 수 증가, 카디널리티, 조인 세분성도 봅니다. 새로운 일대다 조인은 데이터를 부풀릴 수 있습니다. 조기 필터 및 집계, 조인 순서, 적절한 파티션과 클러스터링, 통계 갱신, 필요한 경우 자원 증설을 시험하고 시간, 읽은 양, 셔플, 비용을 전후 비교합니다.

답변 구조 — 사업 프로세스 → 팩트 → 디멘션 → 세분성 → 지표

탐색, 장바구니, 주문, 결제, 배송, 반품, 환불, 재고, 기여도부터 시작합니다. 후보 팩트는 주문 단위 fact_orders, 주문 항목 단위 fact_order_items, 결제, 환불, 배송, 일별 재고 스냅샷입니다. 고객, 제품, 날짜, 창고, 유입 채널, 캠페인은 디멘션으로 둡니다. 각 세분성을 명시합니다. 카테고리 매출은 주문 항목, 고객 생애주기는 고객 또는 계약, 재고는 스냅샷에서 계산합니다. 속성 이력, 취소, 주문 및 항목 할인, 통화, 세금, 비회원 구매, 지연 데이터를 고려하고 재무 및 거래·결제·창고 시스템과 대조합니다.

답변 구조 — 이력 요구사항에 따라 유형 1 또는 유형 2 선택

유형 1은 이전 값을 덮어쓰며 현재 상태만 필요할 때 적합합니다. 유형 2는 변경마다 새 행을 만들고 유효 시작일, 종료일, current_flag, 대체 키를 유지합니다. 고객 지역이 서부에서 동부로 바뀌면 유형 1은 과거 매출도 동부로 다시 분류합니다. 유형 2는 각 시점의 올바른 지역을 보존하고 이벤트 시각에 유효한 버전으로 팩트를 조인할 수 있습니다. 키, 시간 조인, 지연 팩트, 현재 및 이력 보기가 복잡해지므로 사업 요구에 따라 선택합니다.

답변 구조 — 통제 및 유연성과 단순성 및 쿼리 성능 비교

스타 스키마는 팩트와 디멘션을 분리해 재사용 가능한 디멘션, 일관된 지표, 명확한 세분성, 적은 중복, 유연한 분석에 적합합니다. 와이드 테이블은 자주 사용하는 대시보드, 특정 분석, 머신러닝 특징량처럼 단순성과 속도를 우선하는 용도에 적합하지만 중복과 정의 불일치를 만들기 쉽습니다. 보통 정식 팩트 및 디멘션과 사용자별 데이터 마트 및 와이드 테이블을 함께 사용합니다. 용량, 사용자, BI, 비용, 지연, 변경 빈도로 판단합니다.

답변 구조 — 추출 → 원시 데이터 저장 → 변환 → 검증 → 게시 → 모니터링

최신성, 용량, 원본 DB에 허용되는 부하, 사용자, 사후 수정을 확인합니다. updated_at 또는 CDC로 주문을 증분 추출하고 객체 저장소나 raw 테이블에 변경 불가능한 사본을 저장하며 staging에서 정제한 뒤 fact_orders와 fact_order_items를 게시합니다. 의존성은 오케스트레이터가 관리합니다. 재시도는 MERGE, 파티션 교체, 원자적 전환으로 결정적으로 만듭니다. 되돌아보는 기간으로 지연 변경을 수집합니다. 행 수, null 키, 중복 ID, 매출, 상태, 최신성, 원본 DB 대조를 검사하고 실패, 비정상 용량, 중복, 지연을 알립니다. 책임자와 의존 대상도 문서화합니다.

답변 구조 — 같은 입력을 다시 처리해도 같은 출력 상태 생성

멱등 파이프라인은 같은 입력으로 여러 번 실행해도 중복이나 의도치 않은 부작용 없이 같은 올바른 상태를 만듭니다. 재시도와 백필에 필수적입니다. 멱등하지 않은 처리는 재실행할 때마다 어제 주문을 다시 추가합니다. 견고한 방식은 대상 파티션을 교체하거나, 기본 키로 MERGE하거나, 임시 영역에 쓴 뒤 원자적으로 전환합니다. 고유 키, 적절한 파티션, 결정적 변환, 통제된 부작용이 필요합니다.

답변 구조 — 탐지 → 분류 → 보호 → 소통 → 마이그레이션

레지스트리, 메타데이터 검사, 계약 테스트, 수집 검증으로 변경을 탐지하고 열 추가·삭제·이름 변경, 데이터형, null 허용 여부, 의미 변경으로 분류합니다. null 허용 열 추가는 대체로 호환되지만 이름 변경, 삭제, 데이터형 변경은 소비자를 깨뜨립니다. 의미만 바뀌면 스키마 검사를 통과하므로 특히 위험합니다. 원시 데이터를 보존하고 중요한 정보원에는 계약과 호환성 규칙을 적용합니다. 호환되지 않는 변경은 상위 책임자와 조율하고, 버전을 나누고, 변환을 갱신하고, 필요하면 이력을 재구축하며, 계보를 통해 영향을 받는 사용자에게 알립니다.

답변 구조 — 의사결정 지연과 복잡성 비교

부정 거래 탐지, 운영 알림, 개인화, 재고 갱신, 최근 이벤트를 사용하는 기능처럼 낮은 지연이 실제 가치를 만들 때 선택합니다. 일일 보고, 이력 분석, 재무 대조, 시간 단위 변환은 보통 배치가 더 단순하고 저렴하며 재현하기 쉽습니다. 최신성, 용량, 순서, 상태 처리, 내결함성, 팀 경험, 비용, 사용자로 판단합니다. 스트리밍은 중복, 지연 이벤트, 체크포인트, 스키마, 모니터링을 복잡하게 합니다. 사업 요구를 충족하는 가장 단순한 구조를 선택합니다.

답변 구조 — 이벤트 → 스트림 → 보강 → 규칙 및 모델 → 조치 → 저장 → 모니터링

용량, 지연 목표, 판단 내용, 허용 가능한 거짓 양성, 차단 또는 검토 필요 여부를 확인합니다. 결제 이벤트를 Kafka나 Kinesis로 보내고 처리기가 스키마를 검증하고 event_id로 중복 제거한 뒤 사용자, 기기, 가맹점, 거래 속도 정보를 보강해 규칙이나 모델을 적용합니다. 위험이 높으면 차단, 추가 인증, 수동 검토로 보냅니다. 이벤트와 판단은 감사 및 학습용으로 저장합니다. 순서, 중복, 특징량 최신성, 상태 크기, 백프레셔, 데드레터 큐, 재생, 지연, 버전 관리가 중요합니다. 이유 코드, 거짓 양성 모니터링, 롤백으로 고객과 운영을 보호합니다.

답변 구조 — 파티션 사이에서 데이터를 재분배하는 처리

groupBy, join, distinct, orderBy, repartition 등에서 Spark가 파티션 사이의 데이터를 재분배할 때 발생합니다. 네트워크 전송, 직렬화, 디스크 입출력, 조정이 필요합니다. 중간 결과가 크거나 빈번한 키가 있으면 일부 작업이 느려지거나 메모리가 부족해집니다. 조기 필터링, 필요한 열만 선택, 사전 집계, 작은 테이블의 broadcast join, 적절한 파티션, 쏠림 키 salting, 불필요한 distinct와 orderBy 제거로 줄입니다. Spark UI에서 stage, shuffle read 및 write, spill, 작업 시간, executor 메모리를 확인합니다.

답변 구조 — stage 파악 → 데이터 축소 → 쏠림 수정 → 파티션 조정 → 문제 연산 제거

Spark UI와 로그에서 실패하는 stage, 연산, 파티션, executor를 찾습니다. 데이터 쏠림, 대규모 조인, collect(), 너무 큰 파티션, 비효율적인 UDF, 과도한 캐시가 원인일 수 있습니다. 필터와 열 선택을 일찍 적용하고 partition pruning, broadcast join, 빈번한 키의 salting, 파티션 수를 검토합니다. 큰 collect()와 내장 함수로 대체할 수 있는 Python UDF를 제거하고 재사용 데이터만 캐시합니다. 메모리 증설보다 데이터 분포와 실행 계획 개선을 우선합니다.

답변 구조 — 열 지향, 스키마, 압축, predicate pushdown

Parquet은 열 단위로 저장하고 데이터형과 스키마를 유지하며 효율적으로 압축하고 열 프루닝과 predicate pushdown을 지원합니다. 분석 쿼리는 일부 열만 읽는 경우가 많아 스캔 양을 줄일 수 있습니다. CSV는 이식성이 좋은 텍스트지만 데이터형이 없고 크며 느리고 구분자 및 이스케이프 문제가 있습니다. 작은 출력이나 교환에는 적합하지만 데이터 레이크나 웨어하우스의 주 형식으로는 보통 Parquet이 더 빠르고 저렴합니다.

답변 구조 — 최신성 → 완전성 → 고유성 → 유효성 → 대조

최신성, 행 수, 기본 키 null, 중복 거래, 유효한 상태와 통화, 허용 범위의 금액과 날짜, 주문·결제·환불·고객 사이의 참조 무결성을 확인합니다. 매출을 결제 시스템이나 재무와 대조하고 계절성을 고려해 전일 및 전주 차이를 모니터링합니다. 테스트와 취소를 제외하고 순매출에서 환불을 빼며 통화를 정확히 변환합니다. 각 알림에는 책임자, 대응, 대상 테이블, 심각도, 하위 영향, 운영 절차가 필요합니다.

답변 구조 — 영향 평가 → 버전 비교 → 계보 추적 → 완화 → 원인 수정

영향받은 대시보드, 지표, 사용자, 기간, 의사결정을 확인하고 새 값이 오류인지 이전 오류를 고친 것인지 판단합니다. 구버전과 신버전을 테이블, 파티션, 행 수, 고유값, 합계, 세그먼트로 비교하고 계보를 따라 변경을 추적합니다. 코드, 스키마, 필터, 조인, 중복 제거, 날짜도 확인합니다. 오류라면 변환이나 테이블 버전을 롤백하고 화면을 중단하거나 주석을 달며 올바른 데이터를 재구축합니다. 영향, 확신도, 복구 예상 시간, 과거 의사결정을 재검토해야 하는지 알립니다.

답변 구조 — 계측 → 수집 → 저장 → 처리 → 모델링 → 제공 → 거버넌스

용량, 지연, 사용자, 보존 기간, 스키마 진화, 개인정보 보호, 신뢰성을 확인합니다. 클라이언트는 SDK를 통해 event_name, 사용자 및 세션 ID, 시각, 속성, 앱 버전, 플랫폼을 포함한 형식화된 이벤트를 보냅니다. 수집기는 내구성 있는 스트림에 쓰고 원시 이벤트를 재생용 객체 저장소와 분석용 웨어하우스 또는 레이크하우스에 저장합니다. 처리에서는 스키마 검증, 중복 제거, 봇 및 내부 사용자 제외, 세션화, ID 해석을 수행하고 fact_events, fact_sessions, dim_users, 데이터 마트를 만듭니다. 계약, 스키마 레지스트리, 개인정보 및 동의 규칙, 계보, 책임자, 최신성 및 용량 알림으로 보호하며 BI, 실험, reverse ETL, feature store에 제공합니다.

답변 구조 — 오프라인 및 온라인 일치 → 정의 → 최신성 → 제공 → 모니터링

feature store는 학습과 서빙에 재사용할 수 있는 신뢰성 높은 특징량을 제공합니다. 오프라인 특징량은 시점 및 엔터티별로 웨어하우스나 레이크하우스에, 온라인 특징량은 저지연 키-값 저장소에 둡니다. 레지스트리에는 이름, 책임자, 엔터티 키, 변환, 최신성 SLA, 정보원, 설명을 기록합니다. point-in-time correctness로 학습 시 미래 정보를 사용하지 않게 합니다. 온라인 및 오프라인 변환은 공통 로직이나 엄격한 비교 테스트를 사용합니다. 최신성, null, 분포 드리프트, 서빙 지연, training-serving skew, 모델 영향을 모니터링하고 개인정보, 계보, 권한, 폐기를 통제합니다.

답변 구조 — 영향 → 격리 → 완화 → 원인 → 재발 방지

데이터 누락, 잘못된 지표, 중복, 중단된 대시보드, 제품 기능 영향처럼 실제 피해가 있었던 장애를 고릅니다. 누가 왜 영향을 받았는지 먼저 설명하고 로그, 오케스트레이터, 원천 데이터 최신성, 배포, 스키마, 행 수, 파티션, 계보를 사용한 격리와 재시도, 롤백, 수정, 백필, 주석을 통한 완화를 설명합니다. 품질 검사, 알림, 계약, 멱등 쓰기, 운영 절차, 계보, 안전한 출시 같은 재발 방지로 마무리합니다. 책임과 커뮤니케이션을 보여 주되 누구도 탓하지 않습니다.

답변 구조 — 확인 → 재현 → 계보 추적 → 해결 → 문서화

지표, 테이블, 기간, 필터, 기대값, 사업 근거를 구체화합니다. 쿼리를 재현하고 세분성, 필터, 조인, 시간대, 최신성, 정의, 계보상의 변경을 확인합니다. 오류라면 수정하고 영향을 알립니다. 기술적으로는 맞지만 정의가 다르면 사업 정의에 합의하고 문서화합니다. 아직 불확실하다면 알고 있는 것, 조사 중인 것, 답변 시점을 알립니다. 빠르고 근거 있는 대응이 신뢰를 만듭니다.

답변 구조 — 영향 → 신뢰성 → 긴급성 → 의존성 → 파급 효과

사업 영향, 신뢰성 위험, 긴급성, 하위 의존성, 파급 효과로 우선순위를 정합니다. 매출 파이프라인 중단이나 규제 위험은 선택적인 모델보다 우선합니다. 하나의 기반 개선이 여러 개별 요청보다 더 큰 가치를 만들 수도 있습니다. 장애, 전략적 인프라 작업, 요청, 기술 부채, 운영 부담을 구분합니다. 책임자, SLA, 심각도, 로드맵, 명확한 트레이드오프를 사용해 무엇을 연기하고 어떤 위험을 수용하는지 공유합니다.