이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 분산 집계 쿼리가 다른 쿼리보다 유독 오래 걸리는 문제를 맡았습니다. 워커 모니터링을 보니 대부분의 워커는 유휴 상태인데 하나만 계속 작동하고 있었습니다.
집계 키의 데이터 분포를 확인하니 특정 값 하나가 전체 데이터의 70%를 차지하고 있었습니다. 해당 키로 셔플하면 그 값이 한 워커로 몰립니다. 집계를 2단계로 나눠 첫 단계에서 랜덤 prefix를 붙여 분산하고, 두 번째 단계에서 prefix를 제거해 합산하는 방식으로 해결했습니다.
쏠림 문제는 쿼리 최적화로는 해결이 안 되고 데이터 특성을 파악해야 보인다는 걸 그때 배웠습니다. 분산 쿼리 병목은 데이터 분포를 확인하는 것부터 시작한다는 것이 지금도 제 첫 번째 진단 순서입니다.
팀 프로젝트에서 일간 리포트 생성 쿼리가 새벽에 4시간 이상 걸렸습니다. 처음엔 데이터가 많아서 그런 줄 알았는데, 실행 계획을 분석하니 파티션 조건이 있음에도 전체 데이터를 읽고 있었습니다.
조건에서 사용한 날짜 컬럼이 실제 파티션 키 컬럼명과 달라서 프루닝이 안 됐던 것이었습니다. 컬럼명을 파티션 키와 일치시키니 스캔 범위가 당일 데이터로 줄었고, 처리 시간이 4시간에서 18분으로 줄었습니다.
실행 계획을 읽는 것이 쿼리를 다시 짜는 것보다 먼저라는 걸 그때 배웠습니다. 이후엔 느린 쿼리를 만나면 항상 EXPLAIN을 먼저 보는 습관이 생겼습니다. 병목 분석은 추측이 아니라 측정에서 시작한다는 기준이 그때부터 제 방식입니다.
졸업 작품에서 3개 테이블을 조인하는 집계 쿼리가 실행마다 10분이 넘었습니다. EXPLAIN 결과를 분석하니 가장 큰 테이블과 먼저 조인이 이뤄져 중간 결과 크기가 커지는 구조였습니다.
가장 작은 필터 결과를 먼저 처리하도록 조인 순서를 재배열했습니다. 쿼리 힌트로 조인 순서를 명시하니 중간 결과 크기가 80% 줄었고 전체 처리 시간이 2분으로 줄었습니다.
쿼리 최적화는 옵티마이저를 믿기보다 직접 실행 계획을 보고 판단해야 할 때가 있다는 걸 배웠습니다. 특히 데이터 특성을 옵티마이저가 모를 때는 힌트를 통해 명시적으로 유도하는 것이 효과적입니다. 그 판단 근거를 항상 주석으로 남기게 된 것도 그 경험에서 나온 습관입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.