이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 로그 데이터의 결측값이 분석 결과를 왜곡하고 있다는 걸 발견한 적이 있습니다. 당시 팀에서는 문제를 알고 있었지만 규모가 커서 손을 대지 못하고 있었습니다. 저는 먼저 어떤 필드에서 결측이 자주 나는지 빈도 분석을 돌렸고, 수집 시점의 타임아웃이 반복 원인임을 확인했습니다.
pandas로 결측 패턴을 시각화한 뒤 팀 리뷰에서 공유했고, 타임아웃 임계값을 조정하는 방향으로 수집 스크립트를 수정했습니다. 수정 후 해당 필드의 결측률이 18%에서 3% 아래로 떨어졌고, 이후 집계 리포트의 불일치 문의도 눈에 띄게 줄었습니다. 혼자 처음부터 끝까지 한 건 아니었고, 원인 분석과 개선안 제안 부분에서 주도적으로 움직였습니다. 그 경험 이후로 데이터 품질 점검은 분석 전에 먼저 하는 습관이 됐습니다.
인턴 때 외부 API에서 받아오는 고객 데이터를 파이프라인에 연결하는 작업을 지원했습니다. 초기 데이터를 살펴보니 같은 고객 ID가 대문자·소문자·공백 유무에 따라 서로 다른 키로 들어오는 문제가 있었습니다. 단순한 표기 차이처럼 보였지만 조인이 깨지고 집계가 이중으로 잡히는 원인이 되고 있었습니다. 먼저 어떤 케이스가 얼마나 발생하는지 빈도 분석을 돌렸고, 수집 시점에 소문자 통일과 공백 제거를 적용하는 정규화 레이어를 추가했습니다. 적용 후 ID 중복 건수가 일 평균 340건에서 12건 이하로 줄었고 리포트 수치가 안정됐습니다. 데이터 품질 문제는 수집 단계에서 처리하지 않으면 하위 단계에서 비용이 배로 든다는 걸 이 경험으로 배웠습니다. 지금도 새 데이터 소스를 연결할 때 정규화 조건 목록을 먼저 작성하는 것을 시작으로 삼습니다.
팀 프로젝트에서 크롤링으로 수집한 텍스트 데이터를 분석에 쓰기 전에 품질을 점검하는 역할을 맡았습니다. 수집이 완료된 데이터를 살펴보니 HTML 태그가 제거되지 않은 레코드, 동일 URL에서 중복 수집된 항목, 인코딩 오류로 깨진 문자가 섞여 있었습니다. 유형별로 규칙 기반 필터를 만들어 각각 처리했고, 처리 후 어떤 레코드가 제거됐는지 로그로 기록해 팀이 추적할 수 있게 했습니다. 전체 수집 데이터의 약 11%가 필터에서 걸렸는데, 그 구성을 분석하다 보니 특정 시간대 수집분에서 인코딩 오류가 집중되는 패턴을 발견해 수집 스크립트도 수정했습니다. 데이터 품질 작업이 단순 청소가 아니라 수집 과정의 문제를 드러내는 진단이 될 수 있다는 걸 알게 됐습니다.
품질 수치를 만드는 것과 원인 추적까지 연결하는 것은 다른 수준의 작업이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.