이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 분석 수업 팀 프로젝트에서 외부 API로 받은 결괏값이 공백·null·N/A 문자열이 뒤섞인 상태였습니다. pandas로 읽었더니 dtype 불일치로 집계가 무너졌습니다. 우선 정제 함수를 만들어 세 종류를 모두 NaN으로 통일했고, 이후 SQL 단계에서 COALESCE로 빈 값 처리 기준을 명시했습니다. 덕분에 ETL 파이프라인 중간에 값이 달라지는 현상이 사라졌습니다. 입력 데이터의 타입 규약을 먼저 정하는 습관이 생긴 계기였습니다. 이후 팀 전체가 데이터 입력 규약을 미리 정하고 시작하는 방식으로 바꿨습니다. 사전 합의 하나가 디버깅 시간을 수 시간 단축했고, 파이프라인 설계 시 입력 검증을 처음부터 넣어야 한다는 교훈으로 남았습니다.
개인 프로젝트에서 수십만 행 규모의 데이터를 ETL로 처리할 때 가장 어려웠던 상황은 쿼리 실행 시간이 예상보다 10배 이상 길어졌을 때입니다. 처음에는 JOIN 순서가 잘못된 줄 알고 바꿔봤지만 크게 달라지지 않았습니다. 문제 해결 과정으로는 `EXPLAIN ANALYZE`로 실행 계획을 먼저 확인했더니 풀 스캔이 반복되는 구간이 있었습니다. SQL과 ETL 활용 경험으로는 자주 조회되는 컬럼에 인덱스를 추가하고, 중간 집계 결과를 임시 테이블로 분리했더니 실행 시간이 90% 이상 줄었습니다. 어려웠던 이유는 문제의 원인이 쿼리 로직이 아니라 실행 계획에 있었기 때문입니다. 코드만 보면 문제가 없어 보여서 처음에 방향을 잘못 잡았고, 실행 계획을 보는 방법을 알기 전까지는 감으로 수정하는 방식을 반복했습니다. 이 경험으로 SQL 성능 문제는 코드 수정보다 실행 계획 분석이 먼저라는 것을 배웠습니다.
느린 쿼리의 원인은 항상 코드에 있는 게 아니라 실행 경로에 있습니다.
ETL 파이프라인을 운영하면서 소스 테이블의 스키마가 갑자기 바뀌었을 때 가장 어려웠습니다. 특정 컬럼이 이름이 바뀌었는데 파이프라인이 자동으로 실패하지 않고 잘못된 값을 정상적으로 통과시켰습니다. 어려운 상황이었던 이유는 오류가 즉시 드러나지 않고 며칠 뒤 집계에서 이상한 수치로 나타났기 때문입니다. 원인을 역추적하는 데 많은 시간이 걸렸습니다. 해결책으로는 입력 데이터의 컬럼 존재 여부와 타입을 ETL 시작 전에 검증하는 단계를 추가했습니다.
SQL에서는 INFORMATION_SCHEMA로 컬럼 목록을 조회하고, 기대하는 컬럼이 없으면 즉시 파이프라인을 중단하도록 했습니다. 문제 해결 과정에서 배운 것은 ETL의 핵심은 정상 케이스보다 비정상 케이스를 얼마나 빨리 감지하느냐라는 것입니다. 조용히 실패하는 파이프라인이 시끄럽게 실패하는 파이프라인보다 훨씬 위험합니다.
파이프라인의 신뢰는 정확성이 아니라 오류를 빠르게 드러내는 설계에서 나옵니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.