이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 파이프라인을 검증할 때 정합성 확인을 몇 가지 레이어로 나눠서 접근했습니다. 먼저 소스와 목적지의 레코드 수가 일치하는지 카운트를 비교했고, 집계값(합계, 평균)도 양쪽에서 계산해 오차 임계값 이내인지 확인했습니다. 무작위 샘플 N건을 직접 조회해 필드 단위 값이 맞는지 스팟 체크하는 단계도 넣었습니다.
체크섬을 활용한 경우도 있었는데, 전체 데이터의 해시를 비교해 변형 여부를 빠르게 확인했습니다. 중복·누락이 생기는 구간을 찾을 때는 소스·변환·로드 각 단계마다 카운트를 찍는 중간 체크포인트 로그가 원인 추적에 가장 유용했고, 이 로그를 자동화 스크립트로 만들어두니 파이프라인 변경 후 정합성 회귀도 빠르게 잡을 수 있었습니다.
데이터 정합성 검증에서 불일치를 발견하는 것보다 발견 후 어떻게 처리하는지가 더 어려웠습니다. 처음엔 오류가 나면 파이프라인을 멈추게만 했는데, 멈추면 다음 데이터가 밀려서 더 큰 문제가 생겼습니다. 이후에는 불일치 레코드를 격리 테이블에 따로 적재하고 정상 데이터는 계속 흘리는 방식으로 바꿨습니다. 격리된 데이터는 자동으로 Slack 알림이 오고, 담당자가 확인 후 재처리할 수 있는 스크립트를 따로 만들어뒀습니다. 재처리 스크립트는 같은 데이터를 두 번 적재해도 결과가 같도록 멱등성을 보장하는 게 핵심이었습니다. 불일치를 멈춤이 아닌 격리+추적 가능한 흐름으로 다루면 운영 부담이 크게 줄었습니다.
데이터가 많아지면서 수동으로 집계값을 비교하는 방식이 한계에 부딪혔습니다. 파이프라인이 돌 때마다 담당자가 쿼리를 실행해 숫자를 눈으로 확인했는데, 사람이 보는 시간만큼 불일치가 늦게 발견됐습니다. 그래서 dbt Test를 도입해 변환 단계마다 자동 검증 게이트를 붙였습니다. not_null·unique·accepted_values 테스트를 기본으로 설정하고, 집계값 편차가 전날 대비 20%를 넘으면 파이프라인이 중단되도록 커스텀 테스트를 추가했습니다. 처음엔 임계값이 너무 엄격해서 정상 트래픽 변동에도 경보가 울리는 문제가 있었고, 2주치 실측 분포를 보고 임계값을 조정했습니다. 자동 검증 게이트를 붙인 후 불일치가 운영자에게 닿기 전에 잡히는 비율이 크게 높아졌습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.