이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 Airflow로 일 배치 ETL 파이프라인을 유지 관리한 경험이 있습니다. 처음에는 선임이 만들어둔 DAG를 모니터링하고 실패 알림이 오면 재실행하는 수준이었는데, 어느 날 특정 DAG가 매일 새벽 같은 시간에 타임아웃으로 떨어지는 패턴을 발견했습니다. 로그를 파보니 상위 태스크가 끝나기 전에 하위 태스크가 시작되면서 DB 연결이 몰리는 구조였습니다. 저는 태스크 의존성을 명시적으로 재정의하고, 동시 실행 태스크 수에 max_active_tasks 제한을 걸었습니다. 수정 후 타임아웃 발생이 2주간 0건이었고, 평균 실행 시간도 18분에서 11분으로 줄었습니다. 혼자 전부 해결한 건 아니었고, 원인 분석과 수정 방향 제안에서 주도적으로 움직였습니다. 그 경험으로 ETL에서 실패는 데이터가 아닌 실행 순서 설계에서 자주 온다는 걸 배웠습니다.
Airflow ETL 운영 경험으로, DAG 수가 늘어나면서 의존성이 복잡해지고 장애 원인 파악이 어려워졌던 상황을 다룬 것이 기억에 남습니다. 파이프라인이 성장하면 upstream·downstream 관계가 얽혀서 하나의 실패가 어디까지 영향을 주는지 추적하기 어려워집니다. ETL 프로세스 유지 관리 경험으로는 DAG 간 의존성을 `TriggerDagRunOperator` 대신 `ExternalTaskSensor`로 교체하면서 의존성을 명시적으로 관리했습니다. 이를 통해 상위 DAG가 실패했을 때 하위 DAG도 명확하게 대기 상태로 멈추게 했습니다. DAG 설계 방식으로는 각 DAG를 단일 책임 원칙에 따라 분리하고, 실패 시 재시도 범위를 최소화했습니다. 모니터링 구축 경험으로는 Airflow의 `on_failure_callback`을 활용해 Slack 알림을 붙였고, 실패가 발생하면 어떤 태스크와 DAG에서 발생했는지를 즉시 확인할 수 있게 했습니다.
ETL 파이프라인은 실행보다 실패를 빠르게 감지하는 구조가 운영 비용을 줄이는 핵심이라고 생각합니다.
Airflow ETL 운영 경험으로, 데이터 재처리가 빈번해지면서 멱등성을 보장하지 않은 DAG가 문제가 됐던 상황을 겪었습니다. 같은 날짜 데이터를 두 번 적재하면 중복이 생기는 구조였는데, 장애 후 재실행할 때마다 이 문제가 반복됐습니다. ETL 프로세스 유지 관리 경험으로는 각 태스크에서 날짜 파티션 기준으로 DELETE 후 INSERT하는 방식으로 멱등성을 확보했습니다. 이 방식은 재실행해도 결과가 동일하게 유지됩니다. DAG 설계 방식으로는 `backfill`을 안전하게 사용하기 위해 날짜 파티션 단위로 태스크를 분리하고, 각 파티션이 독립 실행 가능하도록 설계했습니다. ETL 최적화 경험으로는 `catchup=True`로 과거 날짜 데이터를 재처리할 때 `max_active_runs`를 제한해 DB 부하를 조절했습니다.
ETL 파이프라인의 재처리 안정성은 처음 설계 시 결정되는 것이지, 장애가 생긴 다음에 추가하기 어렵다는 것을 그 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 NICE그룹 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.