아키텍처

에이전트 오케스트레이션 데이터 파이프라인: Dagster + dbt + MCP 스택 구축하기

글쓴이: IdeaBosque최종 업데이트: 2026年8月28日

핵심 요점

Fivetran과 dbt Labs는 2026년 6월 1일 합병을 완료했다(합산 ARR 약 $600M, 데이터 팀 10만 곳 이상) 그리고 Agents Schema를 출시했다 — 웨어하우스 스키마를 에이전트를 위한 거버넌스된 공유 컨텍스트 계층으로 바꾸는 개방형 표준이다.
Databricks는 자사 Neon 유닛의 데이터베이스 중 80% 이상이 사람이 아닌 AI 에이전트에 의해 프로비저닝된다고 보고했다 — 데이터 스택의 주된 소비자가 이미 분석가에서 에이전트로 옮겨갔다.
새로운 파이프라인을 정의하는 세 가지 에이전트 패턴 — 에이전트가 파이프라인 코드를 작성하고 스캐폴딩하며, 파이프라인이 수정을 제안·적용해 스스로 치유하고, 에이전트가 채팅에서 실행 실패를 트리아지한다 — 이 각각은 렌더링된 대시보드가 아니라 기계 판독 가능한 리니지를 필요로 한다.
스택은 세 개의 거버넌스된 계층으로 구성된다 — 자산 리니지를 담당하는 Dagster, 테스트된 변환과 공유 컨텍스트를 담당하는 dbt, 정책 범위가 지정된 접근을 담당하는 MCP 모듈 — 이를 통해 에이전트는 사람과 동일한 통제 하에 파이프라인의 구조를 읽는다.

데이터 스택은 사람 분석가를 위해 만들어졌다: 파이프라인을 밤새 실행하고, 아침에 대시보드를 읽고, 수치가 이상하면 티켓을 접수한다. AI 에이전트는 데이터를 다르게 소비한다. 합병한 Fivetran + dbt Labs가 말했듯이, 에이전트는 "지속적으로, 병렬로, 기계 속도로 작동한다" — 그리고 이들에게 필요한 것은 파이프라인의 구조(리니지, 테스트, 정의)이지 단순한 출력이 아니다. 단 한 분기 만에 가장 큰 데이터 이동·변환 벤더들은 그 사실을 중심으로 스스로를 재구성했다. Fivetran + dbt 합병은 Agents Schema를 출시하고 dbt Fusion 엔진을 dbt Core v2.0으로 오픈소스화했으며, Databricks는 Electric을 인수해 각 에이전트에 자체 폐기형 Postgres를 부여했다.

이 가이드는 B2B 조달 맥락에서 이 패턴을 구축한다: 공급업체 카탈로그, 가격, 재고를 수집해 RFQ 에이전트에 노출하는 파이프라인이다. 세 가지 계층 — 자산 중심 오케스트레이션을 담당하는 Dagster, 거버넌스된 변환을 담당하는 dbt, 범위가 지정된 에이전트 접근을 담당하는 MCP 모듈 — 와 파이프라인이 스스로를 유지하게 만드는 세 가지 에이전트 패턴을 다룬다. 다 읽고 나면 각 계층이 무엇을 기여하는지, 왜 자산 리니지가 핵심 선택인지, 그리고 사람이 어디에서 루프에 남는지를 알게 될 것이다.

자산 중심 오케스트레이션이 기반이 되는 이유

에이전트를 위한 오케스트레이션 실패의 대부분은 잘못된 멘탈 모델에서 시작된다. 태스크 중심 스케줄러(전통적인 cron+DAG 설계)는 "이 작업이 실행되었는가?"에 답한다. "왜 Acme의 가격이 오래되었는가?"라고 묻는 에이전트에게는 다른 답이 필요하다: "어떤 데이터 자산이 오래되었고, 무엇에 의존하며, 무엇이 그것을 공급하는가?" 이는 자산에 관한 질문이며, 그래서 Dagster의 자산 중심 모델이 단순한 선호가 아니라 이곳의 기반인 이유다.

Dagster에서는 생산하는 것 — supplier_catalog, normalized_prices, availability_snapshot — 과 그 의존성을 선언한다. 그러면 오케스트레이터는 전체 리니지 그래프를 알게 된다. Dagster의 Declarative Automation은 고정된 일정이 아니라 상류가 변경될 때 자산을 갱신하게 하므로, "오래됨"이 시스템이 추론할 수 있는 속성이 된다. 이 리니지 그래프야말로 에이전트가 추측 없이 잘못된 수치를 근원까지 추적하는 데 필요한 것이다.

import dagster as dg

@dg.asset(group_name="procurement")
def supplier_catalog(context: dg.AssetExecutionContext) -> dg.MaterializeResult:
    rows = fetch_supplier_feed()  # NetSuite, EDI, CSV drop, etc.
    write_bronze("supplier_catalog", rows)
    return dg.MaterializeResult(metadata={"row_count": len(rows)})

@dg.asset(deps=[supplier_catalog], group_name="procurement",
          automation_condition=dg.AutomationCondition.eager())
def normalized_prices() -> None:
    # dbt owns the transformation logic; Dagster owns the lineage + trigger
    run_dbt(select="normalized_prices")

deps와 automation_condition이 핵심이다: 에이전트(그리고 아래의 자가 치유 루프)는 이 그래프를 데이터로 읽을 수 있다. Airflow도 반대 방향에서 같은 결론에 도달했다 — Airflow 3.2는 Common AI Provider와 자산 인식 스케줄링을 추가했다 — 그리고 통합은 현실이다: Prefect는 2026년 7월 Dagster를 인수했다. 어떤 오케스트레이터로 표준화하든 요구사항은 동일하다: 불투명한 태스크가 아니라 선언된 리니지를 가진 자산이어야 한다.

dbt가 변환과 거버넌스된 컨텍스트를 담당하는 이유

Dagster는 작업을 트리거하고 리니지를 추적하지만, 비즈니스 로직을 담아서는 안 된다. 그것은 dbt의 몫이며, 그곳에서는 모든 변환이 테스트, 문서, 시맨틱 정의가 첨부된 버전 관리 SQL 모델이다. 에이전트에게 이는 부가 기능이 아니라 신뢰 경계 그 자체다. dbt 자체의 입장은 변환 계층이야말로 에이전트 파이프라인을 신뢰할 수 있게 만드는 것이라는 것이다: 정의되지 않고 테스트되지 않은 테이블에 SQL을 작성하는 에이전트는 혼돈을 더 빨리 자동화할 뿐이다.

합병 이후 추가된 것 중 가장 중요한 것은 Agents Schema다: 지표 정의, 시맨틱 모델, dbt 리니지, 비즈니스 문서를 일반 SQL 테이블로 저장하는 지정된 웨어하우스 스키마다. 모든 에이전트가 "보유 재고"가 무엇을 의미하는지 각자 다시 유도하는 대신, 그 정의는 에이전트가 참조하는 단일한 거버넌스된, 고객 소유의 장소에 존재한다. 이는 거버넌스된 커넥터 모듈의 데이터 측 대응물이다 — 어긋나는 에이전트별 사본이 아니라 단일한 정책 범위의 공유 컨텍스트 소스다.

-- models/marts/availability_snapshot.sql
select
    sku,
    warehouse_id,
    on_hand - allocated as available_qty,   -- the governed definition
    updated_at
from {{ ref('normalized_inventory') }}

-- schema.yml: the test that gates the agent's trust
-- - name: available_qty
--   tests: [not_null, {dbt_utils.accepted_range: {min_value: 0}}]

실패한 테스트는 에이전트가 그 행을 근거로 견적을 내서는 안 된다는 신호다. 모든 모델에 대한 기계 판독 가능한 통과/실패라는 이 하나의 사실이, 사람이 매 단계를 지켜보지 않아도 다음 두 패턴이 작동하게 한다.

에이전트가 연결되는 곳: 데이터베이스 로그인이 아닌 MCP 모듈

에이전트는 결코 원시 웨어하우스 자격 증명을 가져서는 안 된다. 에이전트가 호출해야 하는 것은 소수의 타입이 지정된 도구 — get_availability(sku, warehouse), get_tier_price(sku, customer_tier), list_substitutes(sku) — 를 노출하는 거버넌스된 MCP 모듈이며, 각각은 테스트된 dbt 모델에 매핑되고 정책 범위, 속도 제한, 감사 로깅을 지닌다. 이는 ERP 및 커머스 커넥터에 사용되는 것과 동일한 모듈 패턴을 파이프라인 자체의 출력에 적용한 것이다. 이는 폭발 반경을 작게 유지한다: 에이전트는 availability_snapshot을 읽을 수 있지만 임의의 SQL을 실행할 수는 없으며, 모든 호출이 기록된다.

그 경계는 에이전트별 상태가 자리 잡는 곳이기도 하다. Databricks의 Electric 인수 — 에이전트 샌드박스 내부의 WASM Postgres(PGlite)를 중앙의 거버넌스된 상태와 동기화하는 것 — 가 존재하는 이유는 에이전트가 작업 컨텍스트를 위해 "수천 개의 작고 폐기 가능한 데이터베이스"를 필요로 하기 때문이며, 이는 영속적이고 거버넌스된 테이블과는 분리되어 유지된다. 원칙은 이렇다: 영속적이고 공유되며 거버넌스된 데이터는 MCP 모듈 뒤에 두고, 빠르게 변하는 실행별 스크래치 컨텍스트는 에이전트 자체의 샌드박스에 둔다.

이 스택이 가능하게 하는 세 가지 에이전트 패턴

리니지(Dagster), 테스트된 정의와 공유 컨텍스트(dbt + Agents Schema), 범위가 지정된 접근(MCP)이 갖춰지면 세 가지 패턴이 실용적이 된다:

에이전트형 개발. 에이전트는 기존 리니지 그래프에 맞춰 새로운 자산과 변환을 스캐폴딩한다 — dbt 모델을 초안하고, 스키마 테스트를 제안하고, Dagster 자산을 연결한다. Dagster는 Claude Code와 Codex를 위한 dagster-io/skills와 Compass Slack 어시스턴트를 제공하며, Bruin은 같은 목적의 MCP 서버를 노출한다. 사람이 검토하는 것은 빈 파일이 아니라 풀 리퀘스트다.
자가 치유 파이프라인. 스키마 테스트가 실패하거나 상류 자산이 깨지면, 에이전트는 리니지를 읽고, 실패한 모델을 격리하고, 수정을 제안한 뒤 카나리 실행에서 적용하거나 PR을 제출한다. Dagster가 의존성 그래프를 알고 dbt가 어떤 테스트가 실패했는지 아는 덕분에, 수정은 맹목적인 재시도가 아니라 리니지를 인식한 것이 된다.
에이전트형 문제 해결. 실패가 발생하면 에이전트는 실행 로그와 메타데이터를 읽고 Slack이나 Teams에서 예상 원인과 제안된 수정을 응답한다 — 이는 Dagster Compass와 Snowflake Cortex가 구축된 패턴이다. 온콜 디버깅은 대시보드를 읽는 것에서 에이전트의 진단을 검토하는 것으로 옮겨간다.

이 중 어느 것도 사람을 제거하지 않는다. 적용되는 모든 변경은 테스트 게이트, 카나리, 또는 리뷰를 거친다 — 이는 dbt Summit 2026 기조연설이 에이전트가 프로덕션 데이터를 만지도록 허용하는 대가로 규정한 것과 동일한 규율이다.

한눈에 보는 스택

대표적인 구축 사례

NetSuite를 운영하고 두 개의 창고와 세 개의 공급업체 카탈로그를 가진 한 유통업체는 사람이 손으로 재고를 확인하지 않고도 견적을 낼 수 있는 RFQ 에이전트를 원했다. 병목은 모델이 아니라 파이프라인이었다. 우리는 카탈로그, 가격, 재고 자산을 명시적 리니지와 함께 Dagster에 선언했고, 가격 및 가용성 로직을 "판매 가능 재고"의 정의를 고정한 Agents Schema를 갖춘 테스트된 dbt 모델로 옮겼으며, 읽기 전용으로 범위가 지정된 MCP 모듈을 통해 세 가지 타입이 지정된 도구를 노출했다. 자가 치유 루프는 이제 아침 견적 실행 전에 깨진 공급업체 피드를 감지하고 수정이 포함된 PR을 제출한다. 에이전트의 첫 응답이 장애 알림이 아니라 진단이기 때문에 파이프라인 장애에 대한 온콜 시간이 줄었다. 에이전트는 테스트를 통과한 데이터에 대해서만 견적을 내거나 거부한다 — 테스트에 실패한 행을 근거로 견적을 내는 일은 결코 없다.