이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 분석 인턴 시절 BigQuery로 사용자 퍼널 분석을 처음 다뤘습니다. 모바일 앱의 회원가입부터 첫 구매까지 이탈 구간을 파악하는 것이 과제였는데, 로그 테이블이 분산 저장돼 단일 SQL로는 처리가 안 되는 구조였습니다.
저는 Spark SQL로 로그를 세션 단위로 집계한 뒤 BigQuery에 적재해 분석하는 2단계 파이프라인을 설계했습니다. Spark 최적화 경험이 부족해 시니어 엔지니어에게 파티션 전략을 조언받았고, 그 덕분에 처리 시간이 40분에서 8분으로 줄었습니다.
분석 결과 회원가입 후 24시간 내 앱 재방문율이 전체 전환율을 가장 크게 좌우한다는 것을 확인했고, 이 지표를 핵심 모니터링 대시보드에 추가하게 됐습니다. 이후 파이프라인 구조와 Spark 사용 기준을 팀 문서로 남겼습니다.
인턴 프로젝트에서 사용자 그룹별 30일 잔존율을 분석하는 코호트 쿼리를 처음 작성했습니다. 이론으로는 코호트 분석 개념을 알고 있었는데, 실제 로그 테이블에서 날짜 기준으로 그룹을 나누고 조인하는 방식이 생각처럼 되지 않았습니다. 처음 작성한 쿼리가 의도한 결과를 내지 못해서 2시간을 혼자 찾았는데도 원인을 몰랐습니다.
그 시점에서 선배에게 막힌 부분을 공유했고, DATE_TRUNC를 써서 등록 월 기준으로 그룹을 자르는 방식을 배웠습니다. 그 원리를 이해하고 나서 쿼리를 수정했더니 의도한 코호트 테이블이 바로 나왔습니다. 이후 이 구조를 팀 내 BigQuery 쿼리 가이드에 예시로 추가했습니다.
지금도 처음 다루는 분석 유형은 작동하는 예시 쿼리를 먼저 찾고 나서 직접 변형하는 순서를 씁니다. 빈 화면에서 짜는 것보다 예시에서 이해하고 수정하는 방식이 막히는 시간을 줄여줍니다.
인턴 때 매주 같은 지표를 수동으로 추출해서 보고하는 루틴이 반복됐습니다. 처음에는 그냥 매주 쿼리를 실행했는데, 쿼리 결과를 복사해서 스프레드시트에 붙여 넣는 과정에서 한 번은 숫자를 잘못 붙여서 보고한 적이 있었습니다.
그 이후 BigQuery에서 예약 쿼리(Scheduled Query) 기능을 찾아서, 쿼리가 매주 자동으로 실행되고 결과가 테이블에 쌓이도록 설정했습니다. 방법을 모르는 부분은 공식 문서를 읽고 팀 선배에게 한 번 검토를 받았습니다. 설정 이후 수동 추출 시간이 주 40분에서 0분이 됐고, 오류도 사라졌습니다.
지금도 반복적으로 실행하는 분석은 자동화 가능한지를 먼저 확인하는 것이 습관입니다. 한 번 자동화해두면 이후로는 해석에만 시간을 쓸 수 있게 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 디지털·퍼포먼스 마케팅 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.