이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 파이프라인 프로젝트에서 소스와 타깃의 행 수 비교부터 시작했습니다. 단순하지만 전체 데이터가 빠지지 않고 넘어갔는지 확인하는 가장 빠른 방법이었습니다. 이후 NULL 비율, 중복 키, 주요 컬럼 값 분포를 파이프라인 각 단계마다 체크하는 로직을 추가했습니다.
중간 단계에서 이상이 생기면 마지막에 잡는 게 훨씬 어렵다는 것을 배웠습니다. 단계별 검증 로그를 남기도록 하여 문제가 어느 단계에서 생겼는지 바로 추적할 수 있게 했습니다. 정합성 검증은 파이프라인 설계와 함께 넣어야 한다는 것이 그 경험의 교훈이었습니다. 나중에 검증 로직을 추가하면 기존 구조를 손대야 하고, 히스토리 로그도 없어서 원인 추적이 어려워지더라고요. 초반에 넣는 것이 훨씬 이득입니다.
운영 중인 배치 파이프라인에서 집계 수치가 매일 조금씩 달라지는 현상을 발견했어요. 원인을 찾다 보니 소스에서 타임존 처리가 날짜마다 다르게 들어오고 있었습니다. UTC 기준 정규화를 파이프라인 입력 단계에 추가하고, 타임존 값이 없는 행은 별도 태그를 달아 처리 구분했어요. 이후에는 날짜 범위 집계를 비교하는 검증 쿼리를 매일 자동 실행하도록 했습니다. 수치 오차가 0.1%여서 처음엔 허용 범위로 넘겼는데, 누적되면 의사결정에 영향을 준다는 걸 그때 배웠어요.
작은 오차를 넘기면 나중에 더 큰 문제가 된다는 걸 그 경험이 가르쳐줬습니다. 정합성은 엄격하게 봐야 해요.
데이터 엔지니어링 수업 프로젝트에서 Great Expectations 라이브러리를 활용해 파이프라인 정합성 검증을 자동화했어요. 컬럼 타입, 허용 값 범위, 중복 여부 등을 기대값으로 설정하고, 매 실행 시 자동으로 리포트가 생성되도록 했습니다. 처음엔 기대값을 어떻게 정의해야 하는지 몰라서 도메인 담당자에게 직접 여쭤봤어요. 그 과정에서 데이터 품질 기준이 비즈니스 맥락에서 나온다는 걸 배웠습니다.
도구보다 기준 설정이 더 어렵다는 게 그 프로젝트의 결론이었어요. 자동화 검증은 기준이 명확할 때 의미가 있고, 기준 없는 자동화는 잘못된 걸 빠르게 통과시킬 수 있습니다. 기준을 먼저 정하는 게 도구 선택보다 중요해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.