dbt Wizard vs Claude Code: 동일한 dbt 작업 요청 및 동작 차이점 비교

안녕하세요, 인테지(Intage)의 데이터 엔지니어 카와마(川満)입니다.

이번에는 dbt Labs가 제공하는 dbt 전용 AI 에이전트인 'dbt Wizard'(CLI 버전・베타)를 사용해 보았습니다. 평소 사용하는 Claude Code와 동일한 작업을 요청하여 어떤 동작 차이가 있는지 살펴보겠습니다. 양쪽 모두 백그라운드 모델은 같은 claude-sonnet-5로 통일했기 때문에, 만약 차이가 발생한다면 그것은 '에이전트의 설계'에서 오는 차이라고 볼 수 있습니다.

참고로 Claude Code 측은 CLAUDE.md나 Skills를 준비하지 않은 순수한 상태입니다. 또한, 각 작업은 1회 시도만 진행했으므로 엄밀한 벤치마크라기보다는 경향을 파악하기 위한 기록으로 읽어주시기 바랍니다.

이번 테스트의 재료는 DuckDB 위에서 동작하는 dbt-labs/jaffle_shop_duckdb[1] 프로젝트입니다. 동일한 프롬프트를 두 도구에 던져 아래 포인트를 살펴보겠습니다.

• 실제로 무엇을 변경했는지 (수정 내용)
• 판단의 기준이 되는 부분 (모호한 지시에 어떻게 대처하는지)
• 소요 시간 및 비용
• 디버깅 능력

dbt Wizard란

dbt Labs가 제공하는, dbt 개발에 특화된 AI 에이전트입니다[2]. 현재 시점(2026년 9월) 기준으로 CLI 버전은 퍼블릭 베타, dbt platform (Studio IDE / 홈 탭) 버전은 퍼블릭 프리뷰, 그리고 네이티브 앱인 Wizard Desktop은 프라이빗 베타라는 위치에 있으며, 요금 체계 등을 포함하여 향후 변경될 가능성이 있습니다.

일반적인 코딩 에이전트와 다른 점은 dbt의 네이티브 메타데이터 엔진을 통해 프로젝트를 이해한다는 점입니다[3]. 계통도(lineage)・contracts・테스트・실행 결과 등 dbt 고유의 메타데이터를 기반으로,

• 코드 변경 전 상류/하류에 미치는 영향을 확인한다
• 변경 사항을 리뷰에 올리기 전에 스스로 컴파일 및 빌드하여 검증한다
• 조사 → 변경 → 검증 → 리뷰까지 일련의 워크플로우로 처리한다
• Explore 모드에서는 실제 데이터에 대해 자연어로 질문할 수 있다

와 같은, dbt 프로젝트 운영을 전제로 한 동작 방식이 설계 단계부터 내장되어 있습니다. 백그라운드에서 구동하는 AI 모델은 여러 개 중에서 선택할 수 있습니다. OpenAI・Anthropic (dbt managed 또는 BYOK) 외에도, CLI 버전의 경우 BYOK으로 AWS Bedrock・Google Gemini・Snowflake Cortex・Databricks Unity AI Gateway 등도 이용 가능합니다. dbt platform 버전에서 선택 가능한 프로바이더는 CLI 버전보다 제한적입니다.

결론부터 말씀드리자면

명세가 명확한 작업의 경우, 두 도구 모두 수정 내용은 거의 동일했습니다. 다만, 해석의 여지가 있는 작업에서는 dbt Wizard가 사전 조사나 검증이 더 꼼꼼하여 그만큼 시간과 API 이용료가 소요되었습니다.

설정 없이 이러한 동작 방식을 얻을 수 있기 때문에, dbt 초심자나 운영 규칙이 아직 없는 팀에게는 dbt Wizard가 적합합니다. 반면, 이미 Claude Code에서 CLAUDE.md나 Skills 정비가 진행된 팀은 비용과의 균형을 맞추는 데 어려움을 겪을 수도 있습니다.

검증 환경

• OS: macOS (Apple Silicon)

• 검증 대상 프로젝트:
  jaffle_shop_duckdb

• Python 3.13

• dbt-core 1.11.6 (dbt v1 계열)

• dbt-duckdb 1.10.1

• dbt Wizard: v0.1.1-beta.157

• BYOK, Anthropic API 키 사용

• 모델은
  claude-sonnet-5

• 비교 대상 Claude Code: 역시 claude-sonnet-5

📌 2026년 9월에 개최된 dbt Summit 2026 (구 Coalesce)에서 dbt의 명칭이 정리되었습니다[4]. 기존의 dbt Core는 'dbt v1', Fusion 엔진을 기반으로 한 신규 엔진은 'dbt v2'가 되었으며, pip install dbt는 v2를 가리키게 되었습니다. 본 기사의 검증은 Summit 이전에 진행된 dbt v1 계열(dbt-core 1.11.6)로 실시한 것입니다.

프로젝트 구성

dbt-wizard-try/
├── seeds/
│ ├── raw_customers.csv
...

설정 과정에서 어려움을 겪은 점

dbt managed 프로바이더(무료 체험)가 서버 오류로 사용 불가

dbt Wizard는 내부적으로 작동하는 AI 모델의 확보 방법을 선택할 수 있습니다. dbt Labs에서 제공하는 managed 프로바이더를 사용하면, 자체 API 키 없이 무료 체험(Enterprise 외 플랜에서는 30일간/1회 한정으로 최대 $100 상당)을 시도해 볼 수 있습니다[5]. 반면, OpenAI나 Anthropic처럼 자신의 API 키를 등록하여 사용하는 'BYOK (Bring Your Own Key)' 방식도 있습니다[6]. 처음에는 간편한 managed 프로바이더로 시도했습니다. 하지만 여기서 오류에 직면했습니다.

ERROR: dbt-managed model access was denied. Verify your Wizard trial has been
activated or that you have enough funds in your Wizard account to use this
feature, then sign in again with `dbt-wizard login`.

브라우저에서 다시 체험을 시작해 보아도,

Start your dbt Wizard trial
...
Something went wrong starting your trial. Please try again.

서버 측 오류가 발생하여, 결국 이 검증 시점에서는 managed 프로바이더를 사용할 수 없었습니다. CLI나 로컬 설정의 문제가 아니라 dbt platform 서비스 자체에 기인한다고 판단하고, 이후는 BYOK로 검증을 진행했습니다.

참고로, Anthropic API 키를 그대로 등록하더라도 콘솔 측에서 미리 크레딧을 추가(구매)해 두지 않으면 API가 호출되지 않습니다. 이번에는 5달러어치를 충전하여 연결했습니다.

📌 dbt Wizard를 사용해 보려는 분들은 managed 프로바이더의 체험이 원활하지 않을 경우에 대비하여 BYOK 도입 절차(API 키 확보 및 크레딧 충전)도 사전에 파악하고 있는 것이 안전합니다.

비교 규칙

공정한 비교를 위해 각 작업에서 단어 하나 틀리지 않은 동일한 프롬프트를, 동일 모델의 Wizard와 Claude Code 양쪽에 투입했습니다. 이번에는 5가지 작업을 설정했습니다.

아래 각 표에 제시된 '비용'은 dbt Wizard가 BYOK를 통해 소비한 Anthropic API 이용료(Wizard가 표시한 금액)입니다. 이는 dbt Labs에 지불하는 비용이 아닙니다. Claude Code는 저희 팀에서 이미 도입하여 사용하고 있으므로('정액 구독'), '-'로 표기했지만, 같은 모델을 API 종량제로 사용할 경우 비슷한 비용이 발생한다는 점은 감안해 주시기 바랍니다.

작업 1: materialization 변경 — 전제의 오류를 발견할 수 있는가

프롬프트:

models/orders.sql을 view materialization에서 incremental materialization으로
변경해 주세요

사실 이 프롬프트는 저희 측의 확인 부족으로 전제가 잘못되었습니다. dbt_project.yml를 보면 orders.sql은 table로, view

나노하(なのは)는 staging 모델만. 즉 실제로는 'view에서'가 아니라 'table에서'가 올바르며, 이는 필자의 단순한 착각이었습니다. 그렇다고 하더라도 결과적으로 두 도구가 이러한 사소한 실수를 어떻게 처리하는지 볼 좋은 기회가 되었습니다.

두 도구 모두 이 불일치에気づ았습니다.

• dbt Wizard: 구현 전에 선택식 확인 과정을 거쳤습니다. '실제로는 table이지만, 그래도 incremental화를 계속할 것인지', 'incremental 전략은 merge / delete+insert / append 중 어느 것인지', '필터 컬럼은 무엇을 사용할지'의 3가지 질문이었습니다. 각각에 대해 권장안과 트레이드오프 설명이 제공되었습니다. - Claude Code: 전제 조건의 불일치를 한 마디 텍스트로 보고한 후, 질문 없이 자율적으로 merge 전략 및 order_date를 사용하여 필터를 선택하고 구현했습니다.

수정 내용은 config() 블록에서 materialized='incremental' 및 unique_key='order_id', incremental_strategy='merge'를 지정하는 것이었습니다. 게다가, orders를 가져오는 CTE에 is_incremental()을 사용한 차분 추출 조건(order_date가 기존 데이터의 최대값보다 새로운 것만 대상으로 함)을 추가했습니다. 이 수정 내용은 두 도구 모두 바이트 단위까지 완벽하게 일치했습니다.

태스크 2: 신규 모델 추가 — 거의 동일한 구현으로 수렴

프롬프트:

models 폴더 아래에 monthly_customer_revenue라는 새로운 모델을 추가해 주세요.
customer_id, year_month (주문 월, YYYY-MM 형식), monthly_revenue (그 달의 총 주문 금액)
의 3개 컬럼을 가진 테이블로 만들어 주세요. 아울러 schema.yml에도
...

이 태스크는 사용자 확인 없이 두 도구 모두 즉시 구현했습니다. 설계 판단도 거의 동일했습니다.

• 기존 집계 모델을 재사용하고, 재집계하지 않음
• year_month은 strftime(order_date, '%Y-%m')으로 계산 - 여러 컬럼에 대한 unique 제약 조건의 경우,
  이 프로젝트에서라는 사실을 인지하고 외부 패키지 없이 dbt 표준의 dbt_utils가 없는 환경에서도 작동하도록 식을 전달하는 형태(column1 || '-' || column2를 유니크 키로 취급)로 구현했습니다. 최종적으로 이 방식에 두 도구 모두 같은 결론으로 도달한 것이 흥미로운 지점이었습니다.

다만, 이 dbt_utils 미도입 환경에 대처하는 과정은 달랐습니다.

• dbt Wizard: 구현 전에 packages.yml의 유무를 확인하고, dbt_utils가 설치되지 않았음을 사전에 파악한 후 처음부터 unique 테스트 + 식 지정 접근 방식을 선택했습니다. - Claude Code: 처음에는 schema.yml에 dbt_utils 테스트를 작성했지만, 직후 packages.yml을 확인하여 미설치임을 알게 되었습니다. 실제로 스스로 수정하여 dbt build를 실행하고 에러를 겪기 전에 unique 테스트 + 식 지정 버전으로 변경했습니다.

즉, '처음부터 알고 회피한' Wizard와 '일단 작성했다가 깨닫고 수정한' Claude Code라는 차이가 있었으며, 결과적인 구현은 같았지만 도달하는 과정이 달랐습니다.

또 다른 큰 차이는 구현 후에 dbt build를 실행할지 여부였습니다.

• dbt Wizard: '개발 중에는 dbt build 금지, 검증은 별도 단계'라는 설명을 반환하며 이 자리에서는 미실행 (compile만). 공식 문서에서는 '리뷰 전에 스스로 컴파일/빌드하여 검증할 것'이라고 되어 있기 때문에[3:1], 이는 이번 CLI 버전(beta.157)에서 관찰된 동작으로 기록해 둡니다.
  
  dbt Wizardによるタスク2の実装報告、compileまでで留めている様子

dbt Wizard의 구현 보고입니다. '실제 빌드 및 테스트 실행은 검증 단계에서 진행해 주세요'라며 compile까지만 남겨두었습니다.

Claude Code: 그 자리에서 dbt build까지 실행하며, 추가된 24개 테스트가 모두 PASS하는 것을 자체 확인했습니다.

Claude Code는 그 자리에서 dbt build까지 실행하여, 추가된 24개 테스트가 모두 PASS하는 것을 자체 확인하고 있었습니다.

Claude Code 역시 커맨드 실행마다 승인하는 설정이므로, 이 차이는 권한 설정이 아니라 도구 측의 판단에 따른 것입니다. Wizard가 검증 단계까지 자동으로 진행하지 않는 것은 안전 지향적이라고 이해할 수 있지만, '그 자리에서 작동했는지 알고 싶다'는 사용자에게는 한 단계 더 거치는 점에 유의해야 합니다.

또 다른 점은 테스트 범위에도 차이가 있었습니다. dbt Wizard는 요청된 범위만 엄격하게 구현한 반면, Claude Code는 요청을 넘어 3개 컬럼 전체에 not_null을 추가했습니다.

지금까지의 내용을 정리하면 다음과 같습니다.

태스크3: 테스트 추가 — 제약 조건에 대한 대응이 완벽하게 일치

프롬프트:

orders 모델의 amount 컬럼이 음수 값이 되지 않도록 검증하는 dbt test를 추가해 주세요.

여기서도 두 도구는 같은 결론(일회성 SQL 어설션 = singular test, dbt_utils 미사용)에 도달했습니다. 수정 내용은 'orders에서 amount < 0인 행을 추출하는 SQL을 tests/ 아래에 배치하고, 1행이라도 반환되면 실패, 0행이면 합격'이라는 것입니다.

세부적인 차이는 이 두 가지뿐입니다.

태스크4: 버그 수정 — '손상된 코드의 해석'에서 판단이 정반대

여기서 이번에 가장 확연한 차이가 나타난 태스크입니다.

단순한 오타가 아니라, 일부러 '보기에는 그럴듯한 리네임'을 심었습니다. stg_orders.sql의 컬럼 order_date를 order_placed_date로 변경하여, 이를 직접 참조하는 하류의 orders.sql 및 customers.sql이 손상되는 상태를 만들었습니다. 컬럼 이름만 보면 의도적인 설계 변경인지 단순한 사고인지 구별하기 어려운 점이 핵심입니다.

이번에 심은 버그. stg_orders.sql에서 order_date를 order_placed_date로 리네임하여, 하류 모델을 손상시켰습니다.

이 상태에서 원인에는 일절 언급하지 않고 다음과 같이만 요청했습니다. 두 도구가 '무슨 일이 일어났는지'뿐만 아니라 '어떻게 고쳐야 하는지'까지 어떻게 판단하는지 보기 위함입니다.

프롬프트:

dbt build가 실패하므로 고쳐주세요.

두 도구 모두 근본 원인(stg_orders.sql에서의 리네임)을 특정하는 것은 일치했지만, 수정 방향성이 정반대였습니다.

Claude Code: 리네임을 '의도하지 않은 변경'으로 간주하여, 되돌리는(rollback) 방향으로 수정했습니다. 그 결과 코드는 원래 상태와 완전히 일치할 때까지 돌아갔습니다.

Claude Code는 stg_orders.sql의 리네임을 그대로 되돌려, 28개 테스트가 모두 PASS하는 것을 확인했습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

dbt Wizard: '사용자 의도적인 변경'으로 해석하여, 리네임을 유지한 채 하류의 2개 파일에서 새로운 컬럼 이름을 기존 이름으로 별칭(alias)을 지정하여 흡수하는 방향으로 수정했습니다 (변경 파일 수가 이쪽이 더 많음).

dbt Wizard 구현 보고. 리네임을 의도적인 변경으로 해석하고, orders.sql 및 customers.sql의 2개 파일을 변경하여 별칭(alias)으로 흡수하고 있음

둘 다 dbt build는 모든 테스트를 통과하여 '작동상으로는 올바르지만', 불확실한 상황에서 어느 쪽에 의존할지라는, 코드의 정확성과는 다른 축에서 도구의 성격 차이가 나타났습니다. 원인 조사 방법도 대조적이어서, Wizard는 git status / git diff로 커밋되지 않은 차분(diff)을 통해 추적했고, Claude Code는 모델 전반에 걸쳐 컬럼 참조 위치를 검색하는 접근 방식의 차이도 보였습니다. 또한, 태스크 1에서는 선택식 확인 과정을 거친 Wizard가, 정말 의도가 모호한 이 태스크에서는 확인 없이 '의도적인 변경'으로 판단하여 진행한 점도 대조적이었습니다.

개인적으로는 이 상황에서는 Wizard의 판단이 사용자 의도에 더 부합한다고 느낍니다. 상류(stg_orders.sql)에서 추가된 컬럼명 변경을 무효화하고 되돌리는 것보다, 그 변경을 존중하면서 하류에서 별칭 처리하여 공개 컬럼명을 유지하는 것이 '상류의 설계 변경을 하류에서 흡수한다'는 일반적인 유지보수 작업 감각에 가깝기 때문입니다. 물론 이번 케이스는 필자가 의도적으로 심어 놓은 리네임이었기에 결과적으로 Claude Code의 '되돌리기(rollback)'가 정답이었지만, 실제 업무에서 정말 의도적인 리네임이 발생한 상황을 가정한다면 Wizard와 같은 동작 방식이 더 신뢰할 수 있다고 느꼈습니다.

태스크 5: 모호한 요구사항 — '분석의 깊이'에 차이가 나타남

태스크 1~4를 통해 '단순 작업은 거의 같고, 해석의 여지가 있는 상황에서 차이가 발생한다'는 경향을 발견했기 때문에, 일부러 기준을 명시하지 않은 모호한 태스크를 추가했습니다.

프롬프트:

customers 테이블에 일정 기간 주문이 없는 고객을 churned(이탈) 고객으로 판정하는 로직을
추가해 주세요.

임계값(threshold), 기준일, 구현 장소 모두 지정하지 않았습니다. 목표로 한 논점은 3가지입니다.

• 이탈 판정의 임계값을 며칠/몇 개월로 할 것인가 -
  기준일을 어떻게 설정할 것인가 — 이 데이터셋은 2018년 1~4월의 정적 히스토리 데이터이므로, 단순히 '오늘'을 기준으로 하면 모든 고객이 이탈 처리되어 버립니다 -
  구현 장소(기존 모델에 컬럼 추가인지, 신규 모델인지)

결과적으로 2와 3에 대해서는 두 도구 모두 완전히 동일한 판단(기존 customers.sql에 컬럼 추가, 기준일은 데이터셋 내 최신 주문일)에 도달했습니다. dbt 프로젝트가 정적 히스토리 데이터를 다루고 있다는 맥락을 두 도구 모두 올바르게 이해하고 있었던 것입니다.

차이가 나타난 부분은 구현의 체계성과 분석의 깊이였습니다.

• dbt Wizard: 임계값을 {{ churned_customer_days_since_last_order }}와 같은 변수로 분리하고, SQL 본문에 하드코딩하지 않은 설계로 한 후, 실제 데이터로 90일/30일을 비교 검증하여, 90일은 의미 있는 구분이 되지 않는다는 점을 자발적으로 지적했습니다. 다만, 최종 임계값은 90일로 유지되었습니다.

dbt Wizard 구현. 임계값을 하드코딩하지 않고 변수로 분리하고 있음

• Claude Code: SQL에 '90'일의 임계값을 그대로 직기했습니다.

Claude Code 구현. 임계값 90을 SQL에 직기함

Wizard는 구현 도중에 한 번 만든 CTE(Common Table Expression) 이름을 '혼란스럽다'고 스스로 인지하고 리네임하는 등, 자기 검토의 모습도 보였습니다. 무엇보다 '선택한 임계값이 실제로 의미 있는 구분을 만들어내는지'를 데이터로 뒷받침한 후에 보고하는 자세는 단순히 코드를 작성하는 것을 넘어 분석 작업으로서 높은 질을 느낄 수 있게 했습니다. Claude Code 측 역시 DuckDB에 직접 쿼리하여 분포는 확인했지만, 숫자를 본 것만으로는 한 단계 더 나아간 검증은 하지 않았습니다. 실제로 Claude Code의 90일 구현에서도 주문 기록이 있는 고객 중 이탈자는 0명이었습니다. 즉, Claude Code의 구현은 동작은 하지만 실질적으로 의미 없는 구분이었던 것입니다.

이번 5가지 태스크를 통해 dbt Wizard의 '분석적인 마무리 정교함'이 가장 두드러진 장면이었습니다.

총괄

사양이 명확한 태스크(1~3)에서는 두 도구 모두 거의 동일한 출력을 보였지만, 해석의 여지가 있는 상황에서는 일관되게 dbt Wizard가 '운영에 적용 가능한 형태'를 의식한 행동을 보여주었습니다.

그럼에도 불구하고, CLAUDE.md나 Skills를 전혀 정비하지 않고 사전 조사/영향 범위 고려/임계값 변수화와 같은 'dbt 운영을 아는 사람의 작법'이 처음부터 재현된다는 점은 dbt Wizard의 명확한 강점입니다. dbt 초보자나, 에이전트 정비에 손댈 시간이 없는 팀에게는 설정 제로(zero)로 이 수준을 얻을 수 있다는 가치가 크다고 생각합니다.

앞서 언급했듯이, 저희 팀은 Claude Code를 도입하여 사용하고 있고, dbt 개발/운영 규칙도 팀 내에서 어느 정도 정립되어 있기 때문에, 현시점에서는 새로 dbt Wizard용 API 이용료(또는 dbt 사용 크레딧)를 쌓아 올리는 것보다, Claude Code 측의 Skills를 충실하게 하여 동등한 행동을 재현해 나가는 것이 우선순위가 높다고 생각합니다. dbt Wizard는 아직 등장한 지 얼마 안 된 도구이기도 하므로, 향후 개발 업데이트에 기대를 하고 싶습니다.

이번 관찰을 통해 Claude Code의 Skills에 추가하면 좋을 작법은 다음과 같습니다.

• 테스트를 작성하기 전에
  packages.yml
  을 확인하여 이용 가능한 패키지를 파악하는 것 - 임계값 등의 파라미터는 SQL에 직접 기입하지 않고,
  var
  로 분리하는 것 - 변경 후에는
  dbt build
  로 검증한 후에 보고하는 것 - 버그 수정 전에
  git diff