이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 작품에서 일간 판매 분석 쿼리가 데이터가 늘수록 느려졌습니다. MySQL에서 전체 기간 집계를 하면 5만 건 기준으로 8초가 넘었습니다. 분석 쿼리에 행 지향 DB가 맞지 않는다는 걸 그때 처음 알았습니다.
DuckDB를 사이드 프로젝트에서 써봤던 경험이 있어서 도입해 봤습니다. 같은 데이터에 대해 집계 쿼리를 실행했더니 400ms로 줄었습니다. 컬럼형 저장 방식이 집계 연산에 얼마나 유리한지 직접 체감했습니다.
실패 경험도 있었습니다. DuckDB는 인-메모리 기반이라 서버 재시작 시 데이터를 다시 로드해야 했고, 운영 환경에서 메모리 예산을 초과하는 문제가 생겼습니다. 자주 조회되는 집계 결과는 미리 계산해 별도 테이블에 캐싱하는 방식을 추가해 해결했습니다.
분석 성능은 DB 선택부터 시작된다는 걸 그때 처음 배웠습니다.
인턴 때 광고 노출 로그 집계 배치가 날짜 범위 조건이 있음에도 전체 테이블 스캔을 하는 것을 발견했습니다. 실행 계획을 보니 날짜 컬럼에 파티셔닝이 없어서였습니다.
log_date 기준 월별 파티셔닝을 적용했습니다. 쿼리 시 당월 파티션만 스캔하도록 조건을 함께 정리하니, 3억 건짜리 테이블에서 조회 시간이 47분에서 3분으로 줄었습니다. 팀에서 예상보다 효과가 커서 바로 다른 분석 테이블에도 적용했습니다.
파티셔닝은 설정보다 '어떤 조건으로 쿼리하는가'를 먼저 이해해야 한다는 걸 배웠습니다. 파티션 키가 쿼리 조건과 다르면 효과가 없습니다. OLAP 성능 개선은 데이터 구조와 쿼리 패턴을 함께 봐야 한다는 것이 지금도 제 첫 번째 확인 항목입니다.
팀 프로젝트에서 대시보드 집계 API가 요청마다 여러 테이블을 조인해 계산하다 보니 응답이 12초가 넘었습니다. 사용자가 새로 고침할 때마다 기다리는 구조였습니다.
매시간 집계 결과를 별도 요약 테이블에 미리 계산해 저장하는 방식으로 바꿨습니다. API는 요약 테이블을 단순 조회만 하니 응답이 200ms로 줄었습니다. 실시간 정확성을 1시간 주기 정확성으로 타협한 것이었는데, 대시보드 데이터 특성상 허용 가능했습니다.
처음엔 집계 배치가 실패했을 때 오래된 데이터가 표시되는 문제가 있었습니다. 배치 실행 시각을 화면에 함께 표시하고, 실패 시 알람이 오도록 했습니다. 빠른 응답과 최신성은 트레이드오프이며 도메인이 어느 쪽을 더 중요하게 보는지에 따라 설계가 달라진다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.