이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 외부 API로 수집하는 데이터의 품질이 예고 없이 달라지는 문제를 겪었습니다. 처음에는 데이터가 조용히 망가지는 걸 모르고 집계 결과를 믿다가 나중에 오류를 발견한 경험이 있습니다. 이후 Great Expectations를 도입해 컬럼 타입, null 비율, 값 범위를 사전에 정의하고, 파이프라인 실행 시마다 자동으로 검증이 돌아가는 구조를 만들었습니다. 기대 조건을 넘으면 슬랙 알림이 오고, 해당 배치는 저장을 멈추도록 설계했습니다. 덕분에 잘못된 데이터가 DB에 들어오는 빈도가 크게 줄었습니다. 데이터 품질 검사는 파이프라인 끝이 아니라 데이터가 들어오는 시점에 걸어야 한다는 걸 그 경험에서 배웠습니다.
인턴십에서 외부 API로 수집하는 데이터를 혼자 담당했을 때 이야기입니다. 처음에는 `NULL` 체크와 타입 일치만 확인했는데, 날짜 컬럼에 미래 날짜가 조용히 들어오는 경우가 생겼습니다. 스키마 검증은 통과했지만 집계 결과가 눈에 띄게 튀었고, 원인 추적에 반나절이 걸렸습니다. 이후 검증을 두 레이어로 나눴습니다.
스키마 레이어에서는 타입·NULL·길이를 확인하고, 도메인 레이어에서는 날짜 범위·값 분포·참조 무결성을 검사했습니다. 두 레이어 중 하나라도 실패하면 해당 레코드를 격리 테이블로 보내고 집계 대상에서 제외했습니다. 격리된 건수가 매일 자동 리포트로 올라오니, 데이터 공급 품질이 어떤 방향으로 움직이는지 추세로 읽을 수 있었습니다.
잘못된 데이터가 집계에 섞이는 빈도가 사라졌고, 문제 발생 시점도 당일 안에 잡히게 됐습니다.
팀 프로젝트에서 dbt 기반 데이터 마트를 관리했을 때, 파이프라인을 수정할 때마다 하위 테이블이 조용히 깨지는 현상이 반복됐습니다. 각자 로컬에서 확인하고 올리는 방식이었는데, 머지 후에야 오류가 발견되는 경우가 잦았습니다. 저는 dbt test를 CI 파이프라인에 연결해 머지 전에 자동으로 검증이 돌아가는 구조를 제안했습니다. 테스트 항목은 팀원들과 함께 정했는데, `NULL` 여부·유일성·참조 무결성을 기본으로 두고 비즈니스 규칙이 생길 때마다 추가하는 방식이었습니다. 처음엔 작성이 번거롭다는 반응도 있었지만, 오류 발생 빈도가 줄자 자연스럽게 유지됐습니다. 그보다 더 달라진 건 팀 내에서 데이터 품질 기준이 공통 언어처럼 쓰이기 시작한 것이었습니다 — 코드 리뷰에서 "`NULL` 허용하면 안 되지 않나요?"라는 대화가 자연스러워졌습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.