이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 Presto를 사용해 수억 건 수준의 앱 사용자 행동 로그를 분석하는 작업을 맡았습니다. 주로 작성한 쿼리는 세션별 페이지 방문 순서를 추적하는 퍼널 분석 쿼리였습니다. 사용자 ID와 타임스탬프를 기준으로 세션을 구분하고, 각 세션 내에서 특정 이벤트 시퀀스가 몇 번 나타나는지를 집계하는 방식이었습니다. Presto에서 어려웠던 건 윈도우 함수를 제대로 활용하는 것이었습니다. LAG, LEAD 함수로 이전·다음 이벤트를 참조하는 방식에 처음에는 익숙하지 않았고, 파티션과 ORDER BY 조건을 잘못 설정해서 결과가 틀리는 경우가 있었습니다. 멘토님 리뷰를 받으며 수정하면서 윈도우 함수의 실행 순서를 이해하게 됐습니다. 또 대규모 데이터 특성상 조인 순서와 파티션 프루닝을 신경 쓰지 않으면 쿼리 실행 시간이 수십 배 차이났는데, 실행 계획을 보고 개선하는 과정이 흥미로웠습니다.
대규모 데이터를 다루는 쿼리 작성에서 가장 먼저 확인할 것은 전체 테이블을 스캔하지 않도록 파티션 조건을 명시하는 것입니다. 수억 건 로그 테이블에서 날짜 파티션 조건 없이 실행하면, 전체 파티션을 풀 스캔해서 처리 시간과 비용이 수십 배 차이가 납니다.
파티션 프루닝(Partition Pruning)이 쿼리 실행 시 조건에 맞는 파티션만 읽도록 Presto/Hive가 내부적으로 스캔 범위를 제한하는 최적화 방식입니다. 일별 파티션으로 분리된 이벤트 로그 테이블에서, 특정 기간의 사용자 행동 패턴을 집계하는 쿼리를 작성할 때 파티션 조건을 항상 첫 번째로 명시하는 습관이 생겼습니다. 파티션 없이 작성된 쿼리를 최적화하는 것만으로 처리 시간이 10분에서 30초로 줄어든 경험이 있습니다.
대규모 데이터 쿼리에서 속도는 인덱스보다 파티션 설계에서 먼저 결정됩니다. 파티션 조건 우선 명시가 대규모 데이터 쿼리 작성의 첫 번째 원칙입니다.
대규모 로그 데이터 분석에서 가장 자주 쓴 기능이 윈도우 함수(Window Function)였습니다. 사용자별 최초 구매일, 누적 매출, 이전 이벤트 경과 시간 같은 지표를 계산할 때, 서브쿼리와 셀프 조인을 반복하는 대신 윈도우 함수를 쓰면 단일 패스로 처리됩니다.
ROW_NUMBER()·LAG()·SUM() OVER()가 Presto/Hive 분석에서 가장 자주 쓰이는 세 가지 윈도우 함수입니다. 사용자 퍼널 분석에서 각 단계 간 이탈 시간을 계산할 때, LAG()로 이전 이벤트 타임스탬프를 현재 행에 가져와서 시간 차이를 바로 계산하는 방식이 가장 깔끔했습니다. 윈도우 함수는 집계 없이 행을 유지하면서 계산하기 때문에, GROUP BY 후 조인 방식보다 코드 가독성과 성능이 모두 좋습니다.
좋은 분석 쿼리는 결과뿐 아니라 다음 사람이 수정하기 쉬운 구조입니다. 윈도우 함수가 대규모 로그 분석의 핵심 도구였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.