우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›토스›데이터 분석가›질문 상세
    問
    토토스데이터 분석가직무 역량2026년 출제

    dbt를 활용한 데이터 변환 경험이 있다면, 어떤 방식으로 프로젝트를 진행했는지 구체적으로 설명해 주세요.

    답변 미리보기

    dbt를 도입하면서 가장 먼저 한 일은 Staging → Intermediate → Mart 3레이어 구조를 확립하는 것이었습니다. Staging은 소스 원본만…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    DBT 활용 경험이 있는가?
    DBT를 활용한 구체적인 경험이 답에 있어야 합니다. 없으면 면접관이 '프로젝트에서 어떤 역할을 했나요?' 같은 질문을 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    SQL 사용 사례는 무엇인가?
    SQL을 활용한 사례가 답에 등장하는 경향이 있습니다. 없으면 면접관이 '어떤 쿼리를 작성했나요?'를 추가로 묻는 자리가 자주 보입니다.
    語
    03
    효율적인 데이터 모델링을 했는가?
    효율적이고 가독성 있는 데이터 모델 설계의 흔적이 답에 있어야 합니다. 없으면 면접관이 '그 방법이 왜 효과적이었나요?'를 묻는 경우가 흔하게 통합니다.
    本
    04
    프로젝트 진행 방식을 설명할 수 있는가?
    프로젝트 진행 방식에 대한 설명이 답에 있어야 합니다. 없으면 면접관이 '어떤 과정이 있었나요?'를 추가로 묻는 경우가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    토스 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    dbt 레이어 구조화와 SQL 가독성 원칙약 90초재사용 가능한 dbt 매크로와 패키지 활용약 90초대용량 테이블 incremental 모델 설계약 90초
    예시 답변 1
    약 90초

    dbt 레이어 구조화와 SQL 가독성 원칙

    dbt를 도입하면서 가장 먼저 한 일은 Staging → Intermediate → Mart 3레이어 구조를 확립하는 것이었습니다. Staging은 소스 원본만 최소 정제, Intermediate는 비즈니스 로직 조인, Mart는 최종 집계로 역할을 분리했습니다. SQL 가독성을 위해 CTE(Common Table Expression) 분리 원칙을 팀 컨벤션으로 정했고, 하나의 CTE가 단일 목적을 갖도록 네이밍을 명확히 했습니다.

    dbt test로 Not Null·Unique·Accepted Values 테스트를 모델마다 작성해 데이터 품질을 파이프라인에 내장했습니다. 프로젝트 초반에 Intermediate를 건너뛰고 Staging에서 바로 Mart를 만들었다가, 로직이 복잡해질수록 SQL이 읽기 어려워지는 문제를 겪었습니다. 3레이어로 리팩토링 후 온보딩 속도가 빨라졌고, PR 리뷰 시간도 줄었습니다.

    dbt는 SQL을 소프트웨어처럼 관리하는 도구라는 관점이 설계를 바꿨습니다.

    이 결의 특징
    Staging→Intermediate→Mart 3레이어 확립과 CTE 단일 목적 네이밍 컨벤션 팀 정착, dbt test 모델별 작성까지 설계 원칙이 실천 단위로 드러납니다. Intermediate 건너뛰다 복잡해진 경험 후 리팩토링으로 온보딩 속도와 PR 리뷰 시간이 줄었다는 인과가 살아 있습니다.
    이 결이 통하는 자리
    'dbt는 SQL을 소프트웨어처럼 관리하는 도구'라는 관점 전환이 3레이어 설계 결정의 이유로 자연스럽게 연결될 때 통합니다. 리팩토링 전후 팀 영향이 구체 변화로 드러날 때 면접관이 '왜 그 구조를 선택했나요?'를 따로 묻지 않는 자리가 보입니다.
    예시 답변 2
    약 90초

    재사용 가능한 dbt 매크로와 패키지 활용

    여러 모델에서 반복되는 날짜 처리, NULL 치환, 유효 레코드 필터링 로직을 `dbt` 매크로로 추출해 재사용했습니다. 예를 들어 get_active_records(table, deleted_at_col) 매크로를 만들어 소프트 삭제 필터링을 일관되게 적용했습니다. SQL 가독성 측면에서는 컬럼 별칭(alias)을 항상 명시하고, 복잡한 CASE WHEN은 중간 CTE로 분리해 읽기 쉽게 만들었습니다.

    dbt-utils 패키지를 활용해 날짜 스파이닝, 피벗 변환 등 반복 패턴을 표준화했습니다. 프로젝트 진행 과정에서 소스 스키마가 변경될 때마다 하류 모델이 연쇄 수정되는 문제가 있었는데, Source 레이어에 {{ source() }} 매크로를 도입해 소스 정의를 한 곳으로 집중시키자 영향 범위가 크게 줄었습니다.

    `dbt docs generate`로 자동 생성된 계보 문서가 팀 신규 입사자 온보딩에도 유용했습니다.

    이 결의 특징
    get_active_records 같은 재사용 매크로 추출과 dbt-utils 패턴 표준화, source() 매크로로 소스 정의를 한 곳으로 집중시킨 흔적이 있습니다. 소스 스키마 변경 시 하류 모델 연쇄 수정 문제를 구조로 풀었다는 경험이 설계 판단의 근거로 살아 있어 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    이 결이 통하는 자리
    컬럼 별칭 명시·복잡한 CASE WHEN 중간 CTE 분리라는 가독성 원칙이 팀 컨벤션으로 정착된 실천으로 드러날 때 통합니다. dbt docs의 계보 문서가 온보딩에 유용했다는 부가 효과까지 살아 있을 때 유지보수 관점이 설계에 내재화된 자리가 보입니다.
    예시 답변 3
    약 90초

    대용량 테이블 incremental 모델 설계

    이벤트 로그 테이블(일 3,000만 건)을 dbt로 처리할 때 Incremental 모델을 설계했습니다. Full Refresh는 비용과 시간이 커서 updated_at 기반 증분 처리로 전환했고, unique_key를 지정해 중복 없는 Upsert가 보장되도록 했습니다. SQL 가독성을 위해 Incremental 필터 로직을 별도 CTE recent_records로 분리했고, {% if is_incremental() %} 블록이 명확히 드러나도록 정렬했습니다. 초기 설계 시 파티션 컬럼을 `created_at`으로 잡았다가 `updated_at`이 파티션을 건너는 문제를 발견했습니다. 파티션 전략을 이벤트 날짜 기준으로 재설계하고, Lookback 윈도우(var('lookback_days', 3))를 설정해 late-arriving 데이터를 처리했습니다. 결과적으로 Full Refresh 대비 처리 비용 91% 절감을 달성했습니다.

    Incremental 모델은 처음부터 데이터 지연 가능성을 고려한 설계가 중요합니다.

    이 결의 특징
    일 3,000만 건 테이블의 updated_at 기반 Incremental 전환과 unique_key Upsert 보장, 파티션 전략 재설계까지 대용량 처리의 설계 판단이 단계별로 드러납니다. created_at 파티션에서 late-arriving 문제를 발견하고 Lookback 윈도우 변수를 도입한 경험이 구체 흔적으로 살아 있습니다.
    이 결이 통하는 자리
    Full Refresh 대비 처리 비용 91% 절감이라는 수치가 Incremental 설계의 결과로 드러날 때 통합니다. 'Incremental 모델은 처음부터 데이터 지연 가능성을 고려한 설계가 중요하다'는 결론이 파티션 재설계 경험에서 나온 문장으로 읽힐 때 면접관의 신뢰가 생기는 자리가 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹DBT를 활용한 이유는 무엇인가요?
    貳SQL을 사용하면서 어려웠던 점은 무엇인가요?
    參이 프로젝트에서 팀원들과의 협업은 어땠나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 토스 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    HD현대중공업 · 조선설계
    프로젝트 계획 수립 지원 업무에서 데이터 변환 작업을 어떻게 진행할 것인지 설명해 주세요.
    이 질문 보기
    토스 · 데이터 분석가
    DBT와 SQL을 활용하여 효율적이고 가독성 있는 데이터 모델을 어떻게 설계했는지 구체적인 사례를 말씀해 주세요.
    이 질문 보기
    삼성전자 DX부문 · 기구개발·설계
    시뮬레이션 데이터를 변환할 때 어떤 방법론을 사용했는지 설명해 주세요.
    이 질문 보기
    한국관광공사 · 여행·관광
    디지털 전환(DX) 관련 프로젝트를 진행한 경험이 있다면, 그 과정에서 직면한 도전과 그에 대한 해결책을 설명해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 토스 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기