데이터 엔지니어 면접 준비 예시

저는 이레데이터웍스에서 DAG 214개의 실패 기록을 원인별로 나눠 재시도와 의존성 규칙을 정비했습니다. 우선 최근 8주간의 실패를 일시적 원천 지연, 작업 코드 오류, 상위 데이터 미완료로 분류하고, 재시도해도 해결되지 않는 코드 오류는 반복 실행하지 않도록 했습니다. 원천 지연처럼 회복 가능한 실패에는 제한된 재시도를 두고, 데이터 선후관계가 필수인 작업만 의존성을 유지했습니다. 업무별 입력 형식이나 외부 시스템 제한은 공통 규칙에 넣지 않고 예외로 관리했습니다. 같은 기간의 일간 실패 건수는 37건에서 4건으로 줄었습니다. 공통화는 예외를 없애는 일이 아니라 예외를 분명히 관리하는 일이라고 배웠습니다.

저는 이레데이터웍스의 웨어하우스 1,240개 테이블을 조회 빈도, 최근 사용일, 쿼리 스캔량으로 나눠 우선순위를 정했습니다. 먼저 비용 비중이 큰 상위 40개 쿼리의 필터 조건과 날짜 범위를 살펴 자주 거르는 컬럼에 파티션을 맞추고, 함께 조회되는 기준에는 클러스터링을 적용했습니다. 변경 전후는 같은 기간의 쿼리 실행 기록과 청구 비용을 비교해 사용량 변동도 함께 확인했습니다. 미사용 테이블 312개는 소유자와 하위 의존성을 확인한 뒤 정리했습니다. 제가 기준을 적용해 전체 구조를 점검했고, 우선 최적화한 상위 40개 쿼리의 스캔량은 평균 68% 감소했습니다. 월 비용은 1,840만 원에서 720만 원으로 줄어, 사용 패턴을 기준으로 비용을 관리하는 효과를 확인했습니다.

저는 Kafka 토픽 38개와 초당 평균 3,400건을 처리하는 수집 구조에 스키마 레지스트리를 적용했습니다. 기존에는 producer가 필드를 바꾸면 consumer가 뒤늦게 오류를 내는 일이 월 6건 발생했습니다. 저는 필드 추가처럼 기존 소비에 영향을 주지 않는 변경과 필드 삭제·형식 변경처럼 호환성을 깨는 변경을 구분해 등록 전 검증하도록 구성했습니다. 변경은 새 스키마를 먼저 등록하고 consumer가 사용할 수 있는지 확인한 뒤 producer에 반영하는 순서로 운영했습니다. 배포 후 월별 장애 기록에서 스키마 불일치로 분류된 건을 확인했고, 이후 6개월간 해당 장애는 0건이었습니다. 변경을 코드 배포만의 문제가 아니라 소비자까지 이어지는 흐름으로 봐야 한다는 점을 배웠습니다.

저는 이레데이터웍스에서 핵심 테이블 96개에 품질 규칙 341건을 적용했습니다. 규칙은 필수값 누락, 중복, 허용 범위, 참조 관계로 나누고, 매출 합계나 기준일처럼 하위 지표를 바꾸는 오류는 차단 대상으로 정했습니다. 반면 일부 설명 컬럼의 누락처럼 분석 결과를 바꾸지 않는 항목은 경고로 남겨 처리를 계속하게 했습니다. 차단이 발생하면 실패 테이블과 의존 작업을 확인하고 해당 입력을 바로잡은 뒤 영향받은 구간만 재처리하도록 구성했습니다. 그 결과 오류가 대시보드에 도달한 사례는 분기 5건에서 0건으로 줄었고, 재처리 범위도 평균 62% 축소됐습니다. 품질 기준은 모든 오류를 똑같이 막기보다 영향도에 맞춰야 한다고 배웠습니다.

저는 첫 2개월에는 파이프라인 목록과 실행 기록, 테이블 사용 이력, 장애 알림을 함께 모아 실제 영향도를 먼저 파악하겠습니다. 이레데이터웍스에서 DAG 214개의 실패 유형과 의존성을 정리하고, 1,240개 테이블의 조회 패턴으로 비용 우선순위를 정한 경험을 적용하겠습니다. 거래·매장 핵심 데이터는 장애 빈도와 하위 의존 테이블, 업무상 중요도를 기준으로 먼저 묶고, 사용량이 낮더라도 재무 마감이나 핵심 지표에 필요한 데이터는 별도로 표시하겠습니다. 각 후보를 영향도, 비용, 변경 난도, 재처리 위험으로 비교해 단계별 범위를 제안하겠습니다. 첫 달에는 현황 지도를 만들고 둘째 달에는 우선순위와 이전 순서를 정해, 이후 이행의 기준으로 삼겠습니다.

저는 밝은길소프트에서 마케팅·영업 요구를 받아 데이터 마트 7종과 테이블 84개를 설계했습니다. 먼저 부서별로 지표의 대상 기간, 포함·제외 조건, 집계 단위를 모았고, 원천에서 공통 정제와 계산을 거쳐 소비용 마트로 이어지도록 구조를 나눴습니다. 지표 정의 문서 32건에는 산식과 기준일, 사용 범위를 함께 적어 같은 계산을 대시보드마다 다시 만들지 않도록 했습니다. 특히 정의가 달랐던 11건은 실제 조회 사례를 대조해 차이가 생긴 조건을 드러내고, 합의한 기준을 문서와 마트 변환에 반영했습니다. 그 결과 부서 간 정의 차이를 해소하고 수기 추출 요청을 월 45건에서 8건으로 줄였습니다. 모델과 지표 문서를 함께 관리해야 기준이 지속된다는 점을 배웠습니다.

저는 실패 작업 자체만 재실행하지 않고 먼저 영향 테이블과 하위 의존성을 좁히겠습니다. Airflow의 실패 태스크와 실행 구간을 확인하고, 핵심 테이블 품질 검사 결과를 대조해 잘못된 데이터가 적재됐는지 판단합니다. 원천 지연이면 누락 구간을 확인하고, 변환 오류면 해당 입력 파티션부터 다시 계산하며, 이미 정상인 상위 구간은 재실행 대상에서 제외합니다. 재처리 전에는 중복 적재를 막을 수 있는지 확인하고, 완료 뒤에는 건수와 주요 품질 규칙을 다시 검사하겠습니다. 저는 96개 핵심 테이블에 341건의 규칙을 적용해 실패 시 하위 작업을 멈추게 했고, 이 방식으로 재처리 범위를 평균 62% 줄였습니다. 영향과 멱등성을 확인하는 절차가 복구 속도와 신뢰성을 함께 높인다고 배웠습니다.

저는 Terraform과 Kubernetes를 기술 환경에서 사용해 왔고, 이를 바탕으로 운영 자동화가 반복 작업과 변경 추적을 돕는다는 점을 알고 있습니다. 다만 제 경험의 중심은 Airflow 파이프라인과 웨어하우스 운영이므로, 클러스터 전체를 설계하고 운영했다고 말씀드리지는 않겠습니다. 입사 후에는 먼저 저장소와 배포 흐름, 관리 대상 자원, 변경 승인 및 복구 절차를 파악하겠습니다. 첫 2개월 안에 제가 맡을 구성의 배포와 상태 확인 과정을 직접 수행하고, 변경 이력과 검증 기준을 문서화하겠습니다. 이후 작은 운영 작업부터 자동화해 검증 환경에서 확인한 뒤 적용 범위를 넓히겠습니다. 인프라 변경도 데이터 파이프라인과 마찬가지로 재현 가능성과 복구 가능성을 기준으로 다루겠습니다.

저는 Iceberg 기반 레이크하우스를 구축한 경험은 없습니다. 가장 가까운 경험은 BigQuery와 Snowflake에서 1,240개 테이블의 사용 패턴을 분석해 파티션과 클러스터링 기준을 재설정한 일입니다. 조회 조건과 비용을 연결해 구조를 바꾸고, 상위 40개 쿼리의 스캔량을 평균 68% 줄였습니다. 다만 관리형 웨어하우스의 테이블 최적화와 Iceberg의 파일·메타데이터·컴팩션 운영은 다른 문제라고 이해하고 있습니다. 입사 후 첫 2개월 동안 현행 저장 구조와 접근 패턴을 분석하고, 6개월 안에 핵심 거래·매장 데이터를 대상으로 테이블 포맷의 스키마 변경과 스냅샷 관리, 읽기 성능을 검증하겠습니다. 실제 운영 요구를 기준으로 적용 범위를 판단하겠습니다.

저는 생산 팀과 소비 팀 사이에 정식 데이터 계약을 도입한 경험은 없습니다. 가장 가까운 사례는 Kafka 토픽 38개의 producer와 consumer 사이에서 스키마 레지스트리를 적용한 일입니다. 필드 변경으로 월 6건 발생하던 불일치 장애를 줄이기 위해 스키마를 등록하고 호환성을 확인한 뒤 배포하는 흐름을 운영해 이후 해당 장애를 월 0건으로 만들었습니다. 이는 구조 변경 관리 경험이지, 소유권과 서비스 수준까지 합의한 데이터 계약과 같지는 않습니다. 입사 후 첫 2개월에는 거래·매장 데이터의 생산자와 주요 소비자를 확인하고, 6개월 안에 핵심 도메인에 스키마, 변경 통보, 품질 기준, 책임자를 명시한 계약을 시범 적용하겠습니다. 운영 피드백을 반영해 범위를 넓히겠습니다.

저는 밝은길소프트에서 지표 정의 문서 32건을 만들며 부서별 해석 차이를 조정했습니다. 예를 들어 매출 지표에서 마케팅은 취소 전 주문을 포함해 캠페인 유입을 보려 했고, 영업은 취소분을 제외한 확정 매출을 기준으로 삼았습니다. 저는 먼저 두 정의가 답하려는 질문과 원천 상태값을 나눠 적고, 회의에서 같은 기간의 사례 데이터를 대조해 차이를 확인했습니다. 하나의 숫자로 억지로 맞추기보다 확정 매출과 주문 매출을 구분해 산식과 사용 목적을 문서화하고 마트에 반영했습니다. 그 결과 정의 차이 11건을 해소하고 수기 추출 요청을 월 45건에서 8건으로 줄였습니다. 지표는 계산식뿐 아니라 사용 맥락까지 합의해야 한다고 배웠습니다.

저는 Airflow 실패 알림에 담당자와 복구 절차 링크를 연결해 운영자가 알림만 보고 첫 조치를 찾을 수 있도록 바꿨습니다. 기존에는 오류 메시지와 작업 이름만 확인한 뒤 담당자나 절차를 별도로 찾아야 해 평균 복구에 72분이 걸렸습니다. 저는 알림에 작업별 담당 정보와 확인 순서, 재처리 문서를 연결하고, 절차에는 영향 테이블과 재실행 전 확인 항목을 넣었습니다. 적용 뒤 복구 기록을 비교해 평균 시간이 21분으로 줄었고, 일간 실패도 37건에서 4건으로 감소했습니다. 장애 대응은 알림을 많이 보내는 것보다 다음 행동과 책임 정보를 함께 주는 것이 중요하다는 점을 배웠습니다.