2026년 데이터 엔지니어링 면접 질문 상위 25개

2026년 데이터 엔지니어링 면접은 단순한 SQL 기초를 넘어 시스템 설계, 실시간 아키텍처, 비용 최적화, AI 준비도까지 폭넓게 다룹니다. 본 가이드는 스타트업부터 FAANG급 기업까지 데이터 엔지니어 면접에서 가장 빈번하게 출제되는 25가지 질문과 실무자를 위한 답변을 제공합니다.

SQL 및 쿼리 최적화 질문

SQL은 모든 데이터 엔지니어링 면접의 기초로 남아 있습니다. 시니어 후보자도 SQL 질문을 받으며, 주로 문법보다는 성능에 초점을 맞춥니다.

1. 윈도우 함수와 GROUP BY의 차이는 무엇입니까?

GROUP BY는 행을 집계된 결과로 축소하여 행 수를 줄입니다. 윈도우 함수는 현재 행과 관련된 행 집합에 대해 값을 계산하되 축소하지 않습니다. 출력은 모든 원본 행을 유지합니다.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

윈도우 함수 버전은 쿼리가 행 수준 세부 정보와 집계 컨텍스트를 동시에 필요로 할 때 필수적이며, 데이터 품질 검사 및 리포팅 파이프라인에서 흔히 요구되는 패턴입니다.

2. 5억 행 팩트 테이블에서 느린 쿼리를 어떻게 최적화하시겠습니까?

구조화된 접근 방식이 가장 효과적입니다:

1. 실행 계획 확인 (EXPLAIN ANALYZE)하여 전체 테이블 스캔, 인덱스 없는 컬럼의 해시 조인, 디스크 스필 등을 식별합니다.
2. 테이블 파티셔닝을 쿼리 필터와 일치하는 날짜 또는 기타 높은 카디널리티 컬럼으로 적용합니다.
3. 타겟 인덱스 추가를 자주 필터링되는 컬럼에 적용하되, 과도한 인덱싱은 피합니다(각 인덱스는 쓰기 오버헤드를 추가합니다).
4. 중간 결과 구체화를 여러 대시보드에서 동일한 서브쿼리가 반복 실행되는 경우 적용합니다.
5. 조건자 푸시다운으로 조기 필터링하여 스테이지 간 셔플되는 데이터를 줄입니다.

면접관이 찾는 핵심 신호는 최적화가 체크리스트가 아닌 반복적이고 맥락 의존적임을 이해하는 것입니다.

3. CTE, 서브쿼리, 임시 테이블을 설명하세요. 각각 언제 사용합니까?

CTE(Common Table Expression)는 가독성을 향상시키고 재귀 쿼리를 허용합니다. 대부분의 쿼리 엔진은 이를 인라인화하므로 성능은 서브쿼리와 유사합니다. 임시 테이블은 데이터를 물리적으로 구체화하며, 세션 내 여러 다운스트림 쿼리에 동일한 중간 결과를 제공할 때 유용합니다. 서브쿼리는 간단한 일회성 변환에 적합합니다.

경험 법칙: 명확성을 위해 CTE, 재사용을 위해 임시 테이블, 간단한 인라인 필터를 위해 서브쿼리를 사용합니다.

고급 SQL 패턴에 대한 심화 내용은 SQL for Data Analysts: Window Functions, CTEs and Advanced Queries를 참조하세요.

ETL vs ELT 및 데이터 파이프라인 아키텍처

파이프라인 설계 질문은 아키텍처적 사고를 테스트합니다. 면접관은 도구 옹호가 아닌 트레이드오프 분석을 보고자 합니다.

4. ETL vs ELT: 언제 각각을 선택하시겠습니까?

| 기준 | ETL | ELT | |----------|-----|-----| | 변환 위치 | 로드 전(외부 컴퓨팅) | 로드 후(웨어하우스 컴퓨팅) | | 적합한 경우 | 레거시 시스템, 엄격한 스키마 | 클라우드 웨어하우스(BigQuery, Snowflake) | | 스키마 유연성 | 낮음(변환이 스키마를 조기에 고정) | 높음(원시 데이터가 재변환 가능) | | 비용 모델 | 웨어하우스 외부 컴퓨팅 | 웨어하우스 컴퓨팅 비용이 변환에 따라 확장 | | 데이터 신선도 | 높은 지연(변환 단계) | 낮은 지연(먼저 로드, 주문형 변환) |

ELT는 스토리지가 저렴하고, 컴퓨팅이 탄력적으로 확장되며, 원시 데이터 보존이 스키마 진화를 가능하게 하기 때문에 현대 클라우드 네이티브 스택에서 지배적입니다. ETL은 규제 요구 사항이 데이터가 웨어하우스에 들어가기 전에 변환을 요구할 때(예: PII 스크러빙) 여전히 관련이 있습니다.

5. 멱등성 있는 데이터 파이프라인을 설계하세요. 멱등성이 왜 중요합니까?

멱등성은 동일한 입력으로 파이프라인을 여러 번 실행해도 데이터 중복 없이 동일한 결과를 생성함을 보장합니다. 이는 파이프라인이 실패하고 재시도되기 때문에 중요합니다.

구현 전략:

• 업서트 패턴 (자연 키 또는 복합 키 기반 MERGE 또는 INSERT ... ON CONFLICT)
• 파티션 덮어쓰기: 추가 대신 전체 날짜 파티션 교체
• 쓰기 시 중복 제거: 결정론적 ID 할당(비즈니스 키 + 이벤트 타임스탬프 해시)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

이 접근 방식은 4월 11일 실행 재시도가 중복 행을 추가하는 대신 4월 11일 파티션을 교체하도록 보장합니다.

6. 데이터 리니지란 무엇이며 프로덕션 파이프라인에서 왜 중요합니까?

데이터 리니지는 파이프라인 전반에 걸쳐 데이터의 원본, 이동 및 변환을 추적합니다. 이는 이 숫자가 어디에서 왔는지, 어떤 변환이 적용되었는지, 어떤 다운스트림 시스템이 이에 의존하는지를 답합니다.

실용적 가치: 대시보드에 예상치 못한 값이 표시될 때, 리니지는 몇 시간이 아닌 몇 분 안에 근본 원인 분석을 가능하게 합니다. OpenLineage, dbt docs, 클라우드 네이티브 리니지(BigQuery 컬럼 수준 리니지)와 같은 도구가 이를 자동화합니다.

스트리밍 및 실시간 데이터 처리

스트리밍 질문은 "Kafka가 무엇인가"에서 스트리밍을 언제, 어떻게 사용할지에 대한 아키텍처 결정으로 이동했습니다.

7. 배치 vs 스트리밍: 어떻게 선택하십니까?

결정은 기술 선호도가 아닌 지연 요구 사항에 따라 달라집니다:

• 배치: 데이터 소비자가 분-시간 지연을 허용할 때 적합합니다. 구축, 테스트, 디버그가 더 간단합니다. 대부분의 워크로드에서 운영 비용이 낮습니다.
• 스트리밍: 비즈니스 로직이 1분 미만의 신선도에 의존할 때 필요합니다: 사기 탐지, 실시간 가격 책정, 라이브 대시보드.
• 마이크로 배치: 배치와 유사한 단순성으로 거의 실시간을 제공하는 실용적 중간 지점(예: Spark Structured Streaming)입니다.

가장 강력한 답변은 대부분의 파이프라인이 배치로 시작하여 구체적인 지연 SLA가 요구될 때만 스트리밍으로 이동해야 함을 인정합니다.

8. Kafka의 아키텍처를 설명하세요: 토픽, 파티션, 컨슈머 그룹

Kafka는 데이터를 토픽(논리적 채널)으로 구성합니다. 각 토픽은 브로커에 분산된 파티션(순서가 있고 불변인 로그)으로 분할됩니다. 프로듀서는 레코드를 파티션에 씁니다(라운드 로빈 또는 키 기반). 컨슈머 그룹은 읽기를 병렬화합니다: 각 파티션은 그룹 내 정확히 하나의 컨슈머에 할당되어 수평 확장을 가능하게 합니다.

핵심 트레이드오프: 더 많은 파티션은 병렬성을 증가시키지만 브로커에 오버헤드를 추가합니다(파일 핸들, 복제). 일반적인 시작점은 토픽당 6-12개 파티션이며, 처리량 요구 사항에 따라 확장합니다.

9. 스트리밍 파이프라인에서 지연 도착 데이터를 어떻게 처리하십니까?

지연 데이터는 분산 시스템에서 불가피합니다. 세 가지 접근 방식:

1. 워터마크: 임계값(예: 10분)을 정의하여 그 이후 지연 데이터를 삭제합니다. Apache Flink와 Spark Structured Streaming이 이를 기본 지원합니다.
2. 윈도우 재처리: 최근 시간 윈도우에 대한 집계를 주기적으로 재실행하여 지연자를 포착합니다.
3. 델타/업서트 싱크: 업데이트를 지원하는 변경 가능한 저장소(Delta Lake, Apache Iceberg)에 쓰기하여 지연 레코드가 이전 결과를 수정할 수 있도록 합니다.

올바른 접근 방식은 다운스트림 소비자가 정확히 한 번 의미론을 필요로 하는지 또는 최종 일관성을 허용할 수 있는지에 따라 달라집니다.

데이터 모델링 및 스키마 설계

데이터 모델링 질문은 후보자가 데이터 저장 방식뿐만 아니라 소비 방식에 대해 생각하는지를 드러냅니다.

10. 스타 스키마 vs 스노우플레이크 스키마: 트레이드오프는?

스타 스키마는 차원 테이블을 중앙 팩트 테이블에 조인된 평평하고 넓은 테이블로 비정규화합니다. 스노우플레이크 스키마는 차원을 하위 차원으로 정규화합니다.

| 측면 | 스타 | 스노우플레이크 | |--------|------|-----------| | 쿼리 성능 | 빠름(조인 적음) | 느림(조인 많음) | | 스토리지 | 높음(중복 데이터) | 낮음(정규화) | | 복잡성 | 이해하기 쉬움 | 더 복잡한 관계 | | 유지보수 | 차원 업데이트 어려움 | 하위 차원 업데이트 쉬움 | | 적합한 경우 | BI/리포팅(읽기 중심) | 엄격한 정규화가 필요한 상황 |

실제로는 쿼리 성능과 단순성이 스토리지 절약을 능가하기 때문에 분석 웨어하우스(BigQuery, Snowflake, Redshift)에서 스타 스키마가 지배적입니다. 더 자세한 내용은 data modeling interview module을 참조하세요.

11. SCD(Slowly Changing Dimension)란 무엇입니까? Type 1, 2, 3을 설명하세요.

SCD는 시간 경과에 따른 차원 속성 변경을 추적합니다:

• Type 1: 이전 값 덮어쓰기. 이력 없음. 간단하지만 손실이 있음.
• Type 2: 버전 추적(valid_from, valid_to, is_current)과 함께 새 행 추가. 전체 이력 보존. 프로덕션 웨어하우스에서 가장 일반적.
• Type 3: 이전 값에 대한 컬럼 추가(current_city, previous_city). 제한된 이력(변경 하나만 추적).

Type 2는 감사 추적과 과거 리포팅이 필요하기 때문에 대부분의 비즈니스 차원(고객 주소, 제품 카테고리, 직원 부서)에 대한 기본 선택입니다.

12. 실시간 분석과 장기 스토리지 모두를 위해 이벤트 데이터를 어떻게 모델링하시겠습니까?

이중 레이어 접근 방식:

1. 핫 레이어: 최근 데이터에 대한 낮은 지연 집계에 최적화된 실시간 저장소(Apache Druid, ClickHouse 또는 웨어하우스의 Materialized Views)로 이벤트를 스트리밍합니다.
2. 콜드 레이어: 날짜별로 파티셔닝된 레이크하우스(Delta Lake, Iceberg)에 원시 이벤트를 착륙시켜 애드혹 분석 및 ML 피처 엔지니어링을 위해 무기한 보존합니다.

핫 레이어는 속도를 위해 사전 집계되거나 비정규화된 스키마를 사용합니다. 콜드 레이어는 전체 세분성을 유지합니다. 조정 작업이 두 레이어가 일치하는지 주기적으로 검증합니다.

Apache Spark 및 분산 처리

Spark 질문은 단순한 API 호출이 아닌 병렬성과 성능 이해에 초점을 맞춥니다.

13. Spark에서 데이터 스큐의 원인은 무엇이며 어떻게 수정하십니까?

데이터 스큐는 하나의 파티션이 다른 것보다 불균형적으로 더 많은 데이터를 보유할 때 발생하며, 단일 태스크가 전체 스테이지를 병목시킵니다.

일반적인 원인: 몇 가지 지배적인 값이 있는 키로 조인(널 키, 단일 인기 제품 ID), 또는 낮은 카디널리티 컬럼으로 파티셔닝.

수정 방법:

• 솔팅: 스큐된 키에 임의 접미사 추가, 솔트된 키로 조인, 그런 다음 집계하여 솔트 제거.
• 브로드캐스트 조인: 한쪽이 충분히 작으면(일반적으로 <200MB), 브로드캐스트하여 셔플 완전 회피.
• AQE(Adaptive Query Execution): Spark 3.x+는 런타임에 스큐된 파티션을 자동 감지하고 분할 가능.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

이는 워크로드를 실행자 간에 고르게 분산시켜 병목 현상을 제거합니다.

14. Spark에서 변환과 액션의 차이를 설명하세요.

변환(map, filter, select, join)은 지연됩니다: 논리적 계획을 구축하지만 아무것도 실행하지 않습니다. 액션(count, collect, write)은 계획을 클러스터에 제출하여 실제 계산을 트리거합니다.

이 지연 평가는 Spark의 Catalyst 최적화 프로그램이 데이터가 이동하기 전에 작업을 재정렬하고, 조건자를 푸시다운하고, 불필요한 셔플을 제거할 수 있게 합니다. 이 구별을 이해하는 것은 디버깅에 필수적입니다: 느려 보이는 변환은 실제로 괜찮습니다. 병목은 이를 트리거하는 액션에 있습니다.

15. repartition()과 coalesce()의 차이는 무엇입니까?

repartition(n)은 정확히 n개의 파티션을 생성하기 위해 전체 셔플을 수행하여 데이터를 고르게 분산시킵니다. 병렬성을 증가시키거나 스큐된 파티션을 재균형화하는 데 사용합니다.

coalesce(n)은 인접 파티션을 병합하여 셔플 없이 파티션을 줄입니다. 쓰기 전에 파티션 수를 줄여(많은 작은 파일 방지) 사용합니다.

규칙: 줄이려면 coalesce, 늘리거나 재균형화하려면 repartition.

오케스트레이션 및 파이프라인 관리

오케스트레이션 질문은 운영 성숙도를 테스트합니다: 프로덕션에서 파이프라인이 어떻게 실행되고, 실패하고, 복구되는지.

16. Airflow, Dagster, Prefect를 비교하세요. 언제 각각을 선택하시겠습니까?

| 특징 | Airflow | Dagster | Prefect | |---------|---------|---------|--------| | 성숙도 | 가장 성숙, 최대 커뮤니티 | 성장 중, ML/데이터 팀에서 강력 | 클라우드 우선, 강력한 DX | | 핵심 추상화 | 태스크의 DAG | 자산(데이터 중심) | 플로우와 태스크 | | 테스트 | 어려움(DAG 수준) | 내장 자산 테스트 | 좋은 태스크 수준 테스트 | | 로컬 개발 | Docker/컨테이너 필요 | 네이티브 로컬 실행 | 네이티브 로컬 실행 | | 적합한 경우 | 복잡하고 장기 실행 ETL | 데이터 메시 / 자산 지향 팀 | 최소 인프라를 원하는 팀 |

Airflow는 성숙한 데이터 플랫폼의 업계 표준으로 남아 있습니다. Dagster는 태스크 시퀀스보다 데이터 자산 측면에서 생각하는 팀에 적합합니다. Prefect는 운영 오버헤드가 적은 Airflow와 유사한 오케스트레이션을 원하는 팀에게 매력적입니다. Airflow 관련 면접 준비는 Airflow fundamentals module을 참조하세요.

17. 프로덕션에서 파이프라인 실패와 경고를 어떻게 처리하십니까?

프로덕션급 실패 전략에는 다음이 포함됩니다:

1. 백오프를 사용한 재시도: 일시적 실패(네트워크 타임아웃, API 속도 제한)는 지수 재시도로 해결됩니다.
2. 데드 레터 큐: 독성 메시지는 파이프라인을 차단하지 않고 수동 검사를 위해 별도의 큐로 라우팅됩니다.
3. 회로 차단기: N번 연속 실패 후, 나쁜 데이터로 다운스트림 시스템을 넘치게 하는 대신 파이프라인을 일시 중지하고 경고합니다.
4. 관찰 가능성: 구조화된 로그, 메트릭(태스크 기간, 행 수, 오류율), 각 파이프라인 단계의 데이터 품질 검사(Great Expectations, dbt tests).
5. 경고 계층: P1(파이프라인 다운, 데이터 누락)은 온콜 페이징. P2(데이터 품질 드리프트)는 다음 영업일 Slack 알림.

18. 파이프라인을 "프로덕션 준비"와 프로토타입으로 만드는 것은 무엇입니까?

프로덕션 준비성은 멱등성 실행, 자동 재시도, 모니터링 및 경고, 수집 및 변환 단계의 데이터 검증, 데이터 계약 문서화, 버전 관리된 파이프라인 정의, 테스트된 롤백 경로를 의미합니다. 프로토타입은 이 중 어느 것도 없습니다. 둘 사이의 격차는 대부분의 파이프라인 기술 부채가 누적되는 곳입니다.

클라우드 데이터 플랫폼 및 레이크하우스 아키텍처

클라우드 플랫폼 질문은 후보자가 벤더별 문법을 넘어 비용, 규모, 아키텍처 트레이드오프를 이해하는지 평가합니다.

19. 레이크하우스란 무엇이며 왜 지배적인 아키텍처가 되었습니까?

레이크하우스는 데이터 레이크의 유연성(스키마 온 리드, 원시 데이터 저장, 다중 파일 형식)과 데이터 웨어하우스의 신뢰성(ACID 트랜잭션, 스키마 강제, 쿼리 최적화)을 결합합니다. Delta Lake, Apache Iceberg, Apache Hudi와 같은 기술은 객체 스토리지(S3, GCS, ADLS) 위에 메타데이터/트랜잭션 레이어를 추가하여 이를 가능하게 합니다.

레이크하우스가 우세한 이유는 레이크와 웨어하우스 간의 비용이 많이 드는 ETL 레이어를 제거하고, 동일한 데이터에서 BI 쿼리와 ML 워크로드를 모두 지원하며, 저렴한 객체 스토리지를 활용하기 때문입니다.

20. 클라우드 웨어하우스 비용(BigQuery, Snowflake, Redshift)을 어떻게 최적화하십니까?

비용 최적화 전략:

• 테이블 파티셔닝 및 클러스터링으로 쿼리당 스캔되는 바이트 감소
• 적절한 웨어하우스 크기(Snowflake) 또는 슬롯 예약(BigQuery)을 워크로드 패턴에 따라 설정
• 유휴 리소스 자동 일시 중단: Snowflake 웨어하우스는 1-5분의 비활성 후 자동 일시 중단
• 쿼리당 비용 모니터링: BigQuery의 INFORMATION_SCHEMA.JOBS 뷰는 비용이 많이 드는 쿼리를 드러냄
• 구체화된 뷰 사용으로 반복 계산되는 집계
• 콜드 데이터 아카이브를 수명 주기 정책이 있는 저렴한 스토리지 계층으로

면접 신호: 비용을 나중 생각이 아닌 일급 엔지니어링 제약으로 생각하는 후보자.

데이터 품질 및 거버넌스

데이터 품질 질문은 파이프라인을 제공하는 엔지니어와 신뢰할 수 있는 데이터 플랫폼을 유지하는 엔지니어를 구분합니다.

21. 파이프라인에서 데이터 품질 검사를 어떻게 구현하십니까?

데이터 품질 검사는 세 단계에 속합니다:

1. 수집: 스키마 적합성 검증, 널 기본 키 확인, 소스 대비 행 수 임계값 확인.
2. 변환: 비즈니스 규칙 주장(예: 수익 > 0, 유효한 범위의 날짜), 테이블 간 참조 무결성 확인.
3. 서빙: 메트릭 드리프트 모니터링(일일 활성 사용자의 갑작스러운 50% 감소는 비즈니스 변경이 아닌 파이프라인 문제를 나타낼 가능성이 높음).

도구: dbt tests(스키마 및 커스텀), Great Expectations, Soda Core, Monte Carlo(데이터 관찰 가능성). 최상의 접근 방식은 검사를 파이프라인 DAG에 직접 통합하여 실패가 다운스트림 처리를 차단하도록 합니다.

22. 데이터 계약이란 무엇이며 파이프라인 중단을 어떻게 방지합니까?

데이터 계약은 데이터 프로듀서와 소비자 간의 공식 합의로 다음을 지정합니다: 스키마(컬럼 이름, 유형, 널 가능성), 신선도 SLA(UTC 오전 6시까지 데이터 사용 가능), 볼륨 기대치(일일 100만~1000만 행), 의미론적 규칙(상태 필드는 ACTIVE, INACTIVE, SUSPENDED만 포함).

프로듀서가 계약을 업데이트하지 않고 스키마를 변경하면, 자동 검증이 다운스트림으로 전파되기 전에 불일치를 포착합니다. 이는 파이프라인 실패를 조용한 데이터 손상에서 명시적이고 실행 가능한 오류로 전환합니다.

시스템 디자인 및 아키텍처

시스템 디자인 라운드는 중급에서 시니어 데이터 엔지니어링 역할에 표준입니다. 이는 엔드투엔드 사고를 테스트합니다.

23. 전자상거래 플랫폼을 위한 실시간 분석 파이프라인을 설계하세요.

견고한 설계는 다음을 다룹니다:

수집: 클릭스트림 이벤트와 트랜잭션 이벤트는 Kafka 토픽으로 흐르며, 사용자 세션 내 순서 보장을 위해 user_id로 파티셔닝됩니다.

처리: Flink 또는 Spark Structured Streaming 작업이 Kafka에서 소비하고, 제품 카탈로그 데이터(차원 테이블의 브로드캐스트 조인)로 이벤트를 보강하고, 세션 수준 및 5분 집계를 계산합니다.

서빙: 집계된 메트릭은 1초 미만 지연의 대시보드 쿼리를 위해 실시간 OLAP 저장소(ClickHouse 또는 Apache Druid)에 착륙합니다. 원시 이벤트는 과거 분석을 위해 Delta Lake/Iceberg에 착륙합니다.

데이터 품질: 스키마 레지스트리(Confluent 또는 AWS Glue)가 수집 시 이벤트 스키마를 검증합니다. 스트리밍 데이터 품질 검사는 이상 징후(이벤트 볼륨의 갑작스러운 감소)를 플래그하고 데드 레터 토픽으로 라우팅합니다.

실패 처리: Kafka의 컨슈머 오프셋은 체크포인팅을 통한 정확히 한 번 처리를 가능하게 합니다. 스트리밍 작업은 실패 시 마지막 체크포인트에서 자동 재시작합니다.

24. 레거시 ETL 파이프라인을 최신 스택으로 어떻게 마이그레이션하시겠습니까?

마이그레이션은 교살자 무화과 패턴을 따릅니다:

1. 감사: 모든 기존 파이프라인, 소스, 변환 및 소비자를 카탈로그화합니다. 종속성과 SLA를 식별합니다.
2. 병렬 실행: 기존 파이프라인과 함께 새 파이프라인을 구축합니다. 둘 다 동일한 소스를 소비하고 별도의 대상에 씁니다.
3. 검증: 기존 파이프라인과 새 파이프라인 간 출력을 비교합니다. 자동 조정 쿼리가 불일치를 플래그합니다.
4. 전환: 출력이 2주 이상 허용 오차 내에서 일치하면 소비자를 새 대상으로 전환합니다. 롤백을 위해 기존 파이프라인을 읽기 전용 모드로 유지합니다.
5. 폐기: 안정화 기간 후 레거시 파이프라인을 종료합니다.

핵심 통찰력: 빅뱅 마이그레이션을 절대 하지 마세요. 신뢰가 확립될 때까지 두 시스템을 병렬로 실행하세요.

25. 중요한 대시보드에 잘못된 숫자가 표시됩니다. 디버깅 프로세스를 안내하세요.

체계적인 접근 방식:

1. 문제 범위: 어떤 메트릭이 잘못되었습니까? 언제부터? 모든 차원 또는 특정 필터?
2. 서빙 레이어 확인: 웨어하우스를 직접 쿼리하여 문제가 대시보드 도구(캐싱, 필터 로직)에 있는지 데이터 자체에 있는지 확인합니다.
3. 업스트림 리니지 추적: 대시보드 테이블에서 각 변환 단계를 통해 데이터를 역추적합니다. 각 단계에서 행 수와 핵심 메트릭을 확인합니다.
4. 중단 지점 식별: 예상 값이 실제 값과 달라지는 단계가 근본 원인 위치입니다.
5. 일반적인 원인 확인: 소스 시스템의 스키마 변경, 경고되지 않은 실패한 파이프라인 실행, 처리 윈도우를 놓친 지연 도착 데이터, 또는 변환 로직을 변경한 배포.
6. 수정 및 방지: 즉각적인 문제를 패치하고, 이를 포착했을 데이터 품질 검사를 추가하고, 런북을 업데이트합니다.

이 질문은 인시던트 대응 성숙도를 테스트합니다. 면접관은 무작위 추측이 아닌 구조화된 사고를 보고자 합니다.

데이터 엔지니어링 면접 준비

SharpSkill의 data engineering interview preparation track은 ETL/ELT patterns, 데이터 모델링, Airflow, BigQuery 등에 걸친 대화형 연습으로 이러한 주제를 다룹니다.

결론

• SQL 윈도우 함수, CTE, 쿼리 최적화는 시니어리티 수준에 관계없이 기본으로 남아 있습니다
• ETL vs ELT 결정은 트렌드 추종이 아닌 지연 요구 사항, 데이터 거버넌스 요구 사항, 인프라 비용에 의해 주도되어야 합니다
• 멱등성, 데이터 계약, 데이터 품질 검사는 프로덕션급 파이프라인을 프로토타입과 구분합니다
• 스트리밍 아키텍처 질문은 도구별 지식보다 트레이드오프(배치 vs 스트리밍 vs 마이크로 배치)에 초점을 맞춥니다
• 데이터 모델링 선택(스타 vs 스노우플레이크, SCD 유형)은 이론적 모범 사례가 아닌 소비 패턴과 일치해야 합니다
• 시스템 디자인 답변은 해피 패스와 함께 실패 처리, 비용 최적화, 관찰 가능성을 다루어야 합니다
• 가장 강력한 후보자는 트레이드오프에 대한 구조화된 문제 해결과 정직한 추론을 보여줍니다