에이전트를 위한 데이터 컨텍스트 계층: 신뢰할 수 있는 데이터 시스템 운영

video_id: KhRjivBSwiw title: 에이전트를 위한 데이터 컨텍스트 계층: 신뢰할 수 있는 데이터 시스템 운영 title_original: The Data Context Layer for Agents — Yoni Michael & Brandon Callender, Typedef date: 2026-10-11 channel: aiDotEngineer

URL: https://www.youtube.com/watch?v=KhRjivBSwiw
날짜: 2026-10-11
채널: aiDotEngineer

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

==데이터 에이전트의 병목은 모델의 SQL 작성 능력이 아니라 데이터의 의미·관계·변경 결과를 알려 주는 컨텍스트의 부재다.== 흩어진 구현·데이터·업무 지식을 결정론적으로 추출해 증거가 연결된 그래프로 저장하고 필요한 순간에 작은 서브그래프를 조회해야, 에이전트가 질문응답기를 넘어 데이터 시스템의 신뢰할 수 있는 운영자가 된다.

• 답의 정합성은 grain(행의 의미), 조인의 안전성, 지표 정의, 자산 간 의존성에 달려 있다.
• 이 사실들은 웨어하우스, SQL·변환 코드, BI, 문서, Slack, 사람의 기억에 흩어져 있다.
• SQL과 프로파일에서 계산 가능한 사실은 결정론적으로 만들고, LLM은 요약·분류·명명·모호성 해소에 제한한다.
• 그래프를 만들어도 에이전트가 기존 grep·glob 습관으로 돌아가면 효과가 없으므로 도구 사용률과 반복 성공률을 별도 평가해야 한다.

1. 데이터 에이전트가 실패하는 이유

1.1. Typedef의 문제 정의

1. 목표와 맥락

   1. Typedef 공동 창업자 Yonyi Michael은 창립 엔지니어 Brandon Callender와 약 2시간 워크숍을 열며, 앞부분에서 문제와 원칙을 설명하고 Brandon이 약 90분간 실습한다고 소개했다.
   2. Typedef는 데이터 에이전트가 데이터 플랫폼과 데이터 시스템에서 고난도 작업을 수행하도록 하는 신뢰 계층을 만들고 있다. 데이터 컨텍스트 계층은 그 목표의 핵심 인프라다.
   3. 노트북을 켜고 독일이 1-0으로 지고 있는 월드컵 경기를 보고 싶어 할 참석자들에게 워크숍을 재미있게 진행하겠다고 농담했으며, 발표 자료는 나중에 공유할 수 있다고 했다.

2. 모델보다 컨텍스트

   1. Anthropic의 코딩 에이전트, Codex, Cursor는 저장소 매핑·검색·도구 설계가 좋아져 코드에 강하다.
   2. 데이터에서 에이전트가 자신 있게 틀리면 이사회 자료, 핵심 지표, 모델, 조용히 실패하는 파이프라인에 오류가 들어가 큰 비용이 된다.
   3. 모델은 계속 좋아지지만, 데이터가 무엇을 뜻하고 변경 시 무엇이 깨지는지 모르면 신뢰성으로 이어지지 않는다.

1.2. 일상 업무가 곧 신뢰성 문제다

1. 세 가지 핵심 작업
   1. 영향 분석: 이 변경으로 무엇이 깨지는가.
   2. 조인 추천: 어떤 키가 안전하며 카디널리티와 행 수가 어떻게 바뀌는가.
   3. 안전한 코드 변경: SQL이 컴파일되는지뿐 아니라 지표와 업무 정의가 보존되는가.
2. 이 작업은 데이터 팀의 주변부가 아니라 매일 수행하는 핵심 운영 흐름이다. 에이전트가 이를 안정적으로 하지 못하면 읽기 권한조차 주기 어렵고, 단순 Q&A 에이전트로는 부족하다.

1.3. 분산된 사실과 grain

1. 웨어하우스에는 행과 값, 변환 코드에는 업무 로직, BI에는 지표·차원·업무 정의, 문서·Slack·사람의 기억에는 tribal knowledge가 있다. 필요한 것은 이 조각을 의미·관계·영향·안전한 조작으로 연결한 중간 표현이다.
2. customer by month 테이블의 한 행은 고객 한 명의 한 달을 뜻한다. 이를 customer by week로 바꾸면 SQL은 여전히 성공해도 하류 합계에서 값이 반복된다.
3. 밤새 행 수가 40% 늘었을 때 유효한 SQL과 아름다운 차트는 “데이터가 더 들어왔다”고 말하게 할 수 있다. 실제 원인은 상류 컬럼 변경으로 one-to-one 조인이 one-to-many로 바뀐 것일 수 있다.
4. grain은 원시 행만으로 알기 어렵다. 따라서 유효한 SQL은 필요조건일 뿐이며 의미론적 컨텍스트가 필수다.

1.4. 코드만 주거나 DB만 주는 방식의 한계

1. DBT·Airflow 프로젝트를 매번 프롬프트에 넣으면 에이전트가 매번 처음부터 재구성한다. 확률적이고 컨텍스트 윈도우에 묶이며 파일 순서가 바뀌면 goose chase가 생긴다.
2. Snowflake·Databricks MCP만 연결하면 행과 샘플은 보지만 행의 의미, 조인의 안전성, 지표 정의는 모른다.
3. 전자는 코드를 읽되 기억이 없고 후자는 값을 보되 의미와 관계가 없다. 지속 가능한 시스템 모델이 필요하다.

2. 데이터 컨텍스트 계층

2.1. 답을 결정하는 네 가지 사실

1. grain: 한 행이 고객·주문·월별 구독 중 무엇을 뜻하는가.
2. 조인 안전성: 키가 고유한가, one-to-one인가 one-to-many인가. 같은 equi-join도 행 보존·차원 조회·행 복제가 될 수 있고, BETWEEN도 안전한 as-of lookup 또는 grain을 폭발시키는 date spine이 될 수 있다.
3. 지표 의미와 관계: metric의 포함·제외 조건과 사용 대시보드를 알아야 한다. SQL predicate 하나가 paid의 정의라면 지우는 순간 trial churn까지 포함하는 다른 지표가 된다.
4. 의존성과 도메인: revenue·product·revops에 어떤 모델이 속하는가. table-level·column-level lineage, 공유 키와 이름 유사성으로 계산할 수 있다.

2.2. 결정론, 증거, LLM

1. 변환 로직을 SQL AST까지 파싱해 구조·관계·의존성·grain을 계산한다. 구현에서 직접 얻은 그래프는 모델의 즉석 추론으로 변하지 않는다.
2. 웨어하우스 프로파일로 조인 키의 uniqueness와 카디널리티를 검증해 이름만 보고 추측하지 못하게 한다.
3. LLM은 업무용 이름, 자산 용도 요약, 도메인 분류, 남은 모호성 해소를 맡는다. 계산·검증 결과와 사람이 읽는 설명을 분리해 핵심 사실 재창작을 막는다.

2.3. 그래프 구조와 운영 시나리오

1. 논리 SQL 모델, 물리 테이블, semantic view, 지표, 대시보드, 소스 시스템을 노드로 만들고 타입이 있는 관계와 provenance를 엣지로 만든다. is materialized by와 has semantic definition 같은 관계로 구현과 의미를 잇는다.
2. 그래프는 한 번 계산한 뒤 커밋마다 변경분을 원자적으로 갱신한다. 500개 이상의 모델을 매번 다시 읽지 않고 필요한 서브그래프만 traversal한다.
3. 모델 grain 변경 전 하류를 걸어 월별 ARR이 주별 행에 반복되어 하류 합계가 4배가 되는지, 보드 대시보드까지 영향이 가는지 계산한다.
4. 마케팅 채널별 ARR을 만들 때 컬럼 이름이 아니라 실제 프로파일로 조인 키를 검증한다. 잘못된 경로가 행을 7배로 fan-out하거나 하류 행의 12%를 버리면 경고한다.
5. predicate 삭제처럼 문법상 무해한 리팩터링이 paid의 의미를 바꾸고 세 대시보드에 전파되는 것을 잡는다. 업무 정의를 YAML 주석이 아닌 1급 제약으로 다룬다.

2.4. 평가와 다섯 가지 원칙

1. 실제 데이터 작업을 쉬운 것부터 어려운 것까지 만들고 실제 환경의 격리된 clone에서 여러 번 실행한다. pass/fail와 영향 분석용 LLM-as-judge를 함께 쓴다.
2. 같은 모델과 task에서 컨텍스트 접근만 바꾼 평가에서 작업 성공률이 약 35포인트 상승했다.
3. 결정론 우선, 결론보다 증거, prompt stuffing보다 traversal, 큐레이션한 도구 표면 소유, 초기부터 지속적인 eval이 다섯 원칙이다.
4. 모델 교체나 일반 MCP 추가보다 정확한 컨텍스트가 결과를 크게 바꾼다.

3. Rust 코드베이스 실습

3.1. 준비와 세 레벨

1. Brandon은 Quadrant Rust 프로젝트에 원리를 축소 적용한다. QR 코드의 GitHub 저장소에 코드와 Jupyter notebook이 있고, 로컬에는 Neo4j용 Docker Compose 또는 Docker가 필요하다. OpenRouter 키는 선택 사항이며 오프라인·Colab 실행도 가능하다.
2. 약 다섯 개 crate에서 타입·trait·함수와 위치를 추출해 심볼 관계를 엣지로 만들고, 한 번 계산한 구조를 여러 번 질의한다.
3. 레벨 1은 grep·glob·raw string, 레벨 2는 임베딩과 lexical·semantic search를 이용한 평면 코드 RAG, 레벨 3은 정체성 있는 심볼과 타입이 있는 엣지를 가진 traversible graph다.
4. Rung 0은 Tree-sitter AST, Rung 1은 Rust 컴파일러와 rustdoc JSON을 이용한 canonical symbol resolution, Rung 2는 LLM을 통한 의미 부여다.

3.2. Notebook 1의 단계

1. posting list를 ripgrep하면 정확히 일치하는 두 곳과 posting list view·iterator가 나온다. 텍스트에는 정체성, crate, 호출 관계, 영향 범위가 없다.
2. Tree-sitter로 Rust 항목을 추출하고 rustdoc 정보로 export를 원래 정의의 정식 이름·파일·라인까지 연결한다. full-text search는 여전히 평면 목록이므로 관계를 매번 추론해야 한다.
3. 심볼과 관계를 Neo4j 노드·엣지로 적재하고 Cypher로 조회한다. blast radius 도구는 정식 이름으로 의존 항목과 변경 시 깨질 항목을 파일·라인과 함께 반환한다.
4. 같은 이름의 두 posting list도 canonical resolution이 다르면 서로 다른 blast radius를 갖는다. Pydantic 기반 에이전트에 search, blast radius, 구현·메서드 조회 도구를 연결해 질문에 답한다.
5. 스키마와 노드·엣지를 시스템 프롬프트에 주면 에이전트가 “trait을 구현하는 모든 구조체와 해당 trait”을 Cypher로 바꿔 실행한다.
6. Fenic은 DataFrame 연산과 LLM을 결합한다. 종류·정식 이름·docstring으로 Rust 항목의 용도를 한 문장으로 요약하고, 결과를 graph에 넣어 위치·관계뿐 아니라 기능과 의도도 조회한다. 생성 설명은 감사·수정 가능하다.

4. 에이전트 도구 사용과 평가

4.1. graph보다 grep을 먼저 쓰는 이유

1. graph 도구를 기존 도구와 함께 줘도 모델은 학습된 반사 행동대로 grep·glob·파일 읽기를 먼저 한다. 더 좋은 도구라는 사실만으로 후훈련 습관을 이기지 못한다.
2. query_graph보다 search라는 이름을 쓰고 여러 키워드 검색 입력과 ripgrep 유사 결과를 제공해 기존 행동과 맞춘다.
3. 첫 호출이 빈 결과면 도구를 고장으로 판단하고 돌아가므로 첫 요청부터 위치·관계·근거를 유용하게 반환해야 한다.

4.2. Notebook 2와 반복 평가

1. 같은 모델에 graph tools를 준 에이전트와 파일 탐색 도구만 준 대조군을 만든다. gold는 graph 결과를 복사하지 않고 소스와 교차검증한다.
2. 답을 구조화해 결정론적 scorer로 비교하고 scorer 자체를 unit test한다. LLM-as-judge만 쓰면 분산과 비용이 커진다.
3. pass@k는 여러 실행 중 한 번이라도 맞힌 비율이고 pass^k는 모든 실행에서 맞힌 비율이다. 다섯 번 반복했을 때 한 번 맞히는 점수는 비슷할 수 있지만 pass^k에서 graph 에이전트가 약 두 배 좋았고, 평균 토큰은 약 3.1배 적었다.
4. 도구 adoption도 측정한다. 지시 없는 프롬프트에서 34%였던 사용률을 프롬프트와 스킬 조정 후 72%로 높이는 식이다. 우수한 도구를 3분의 1만 쓰면 3분의 1짜리 도구일 뿐이다.

4.3. 정직한 eval과 trace

1. 실제 corpus에 버그 diff를 주입하고 올바른 모델을 수정하게 한다. 쉬운 질문은 문제 위치를 알려 주고 어려운 질문은 대시보드 숫자가 두 배가 됐다는 증상만 줘 root cause를 역추적한다.
2. 에이전트는 테스트 브랜치 이름과 git diff, main 복귀로 shortcut할 수 있으므로 실행 환경과 harness를 격리한다. 데이터·DB·샘플의 일관성도 보장한다.
3. 점수판만 믿지 않는다. search가 잘못된 파일 경로를 반환했는데 총점은 graph 우세처럼 보인 사례가 있었다. trace에서 호출·인자·반환값을 읽고, 어려운 eval과 harness 강화 후 재실행한다.

5. Q&A와 확장 설계

5.1. 갱신 비용, 언어, repository 경계

1. 이상적인 graph는 main 기준 canonical form으로 저장하고 로컬 수정은 별도 복사본에서 변경분만 incremental reindex한다. 컨텍스트가 커질수록 런타임 재독해보다 이 방식의 이득이 커진다.
2. 가장 큰 가치는 inference time에 graph tool을 조회하는 순간 나타난다. 전체 의미를 재도출하지 않고 필요한 사실만 가져온다.
3. Rust는 컴파일러가 심볼 해소를 제공해 선택했다. Python의 동적 디스패치와 런타임 타입은 더 어려우므로 Tree-sitter, 정적 해석, 타입 검사를 조합해야 한다. ingestion을 언어별 모듈로 만들면 graph 구조와 도구 인터페이스는 유지할 수 있다.
4. 여러 repository와 HTTP 경계를 넘으려면 어느 언어가 어느 경계에서 호출하는지 분류하는 boundary classifier가 필요하다.

5.2. semantic search, catalog, semantic layer

1. Cursor의 semantic search는 관련 코드 위치를 찾지만, 에이전트가 파일을 다시 읽어 관계를 추론해야 한다. graph는 함수의 call site와 의존성을 명시적 엣지로 한 번에 보여 준다.
2. 카탈로그는 warehouse의 물리 자산·컬럼·프로파일을 제공한다. DBT를 파싱해 Snowflake 테이블과 연결하고 카탈로그 정보를 graph에 넣으면 카탈로그와 lineage가 함께 작동한다.
3. context graph는 Salesforce·Stripe·Fivetran·Airflow·BI까지 연결한다. 사람이 모델을 추가할 때마다 갱신해야 하는 semantic layer의 부담을 변경분 재계산으로 줄인다.

5.3. gold 데이터와 비즈니스 비전

1. 고정 eval은 특정 commit, 주입 diff, 기대 결과를 하나의 snapshot으로 묶어야 한다. 코드가 바뀔 때마다 질문을 바꾸면 같은 작업을 더 잘하게 됐는지 알 수 없다.
2. 실제 새 버그는 계속 채굴하되 핵심 회귀 세트는 같은 corpus와 task로 둔다. 100% 통과하는 eval은 지나치게 쉬울 수 있다.
3. 업무 담당자가 “대시보드가 깨졌다”고 말하면 agent가 세 단계 위의 잘못된 select, 지난주 변경, Airflow 실행, 담당 팀을 추적하고 해결 정보가 채워진 티켓을 올바른 팀에 보내는 것이 장기 그림이다.
4. “AR은 어디에서 오나?”라는 질문에 Stripe 원천 데이터가 Salesforce lead 데이터와 결합되어 특정 모델에서 계산된다는 lineage를 답하는 것이 온톨로지형 비전이다.
5. graph가 커질 때 storage보다 먼저 문제가 되는 것은 전체 분석과 warehouse 재조회 compute다. 500개 모델을 다시 컴파일·프로파일링하지 않도록 incremental indexing을 처음부터 1급 요소로 둬야 한다.

주요 발언 모음

“The model isn't the bottleneck. The missing context to make these agents actually effective is the important part.”

“Valid SQL isn't enough. The semantics are actually very, very important when you're trying to get an agent to be effective.”

“The real goal is to have it be a lot more deterministic.”

“Store evidence, not conclusion.”

“Traversal always beats prompt stuffing.”

“An elegant tool that gets reached for a third of the time is just a third of a tool.”

“Never trust your own scoreboard. Read the traces, find the artifact, harden the harness, and rerun.”

“The agent will grep anyway.”

핵심 데이터 & 수치

• 워크숍 약 2시간, Brandon 실습 약 90분.
• one-to-one가 one-to-many가 되면 실제 유입 없이도 행 수가 40% 늘 수 있다.
• 월별 ARR이 주별 행에 반복되면 하류 합계가 4배가 될 수 있다.
• 잘못된 조인은 행을 7배로 늘리거나 하류 행의 12%를 버릴 수 있다.
• 컨텍스트 제공 시 작업 성공률이 약 35포인트 상승했다.
• 다섯 번 반복한 pass^k에서 graph 에이전트가 grep 대조군보다 약 2배 좋았다.
• graph 방식의 평균 토큰 사용량은 약 3.1배 적었다.
• 목표 도구 사용률을 34%에서 72%로 올리는 방식으로 adoption을 측정했다.
• Mattermost의 공개 DBT 프로젝트는 약 300~350개 모델이며, 실습은 약 5개 Rust crate를 사용했다.

결론 및 시사점

1. 데이터 에이전트의 실패 원인은 모델보다 grain·조인·지표·의존성 컨텍스트의 부재에서 먼저 찾아야 한다.
2. 업무 의미를 기억과 문서에만 두지 말고 SQL·프로파일·lineage에서 계산 가능한 사실로 바꿔야 한다.
3. 구현에서 얻는 구조와 증거는 결정론적으로 저장하고 LLM은 의미 표현에 제한해야 한다.
4. 전체 프로젝트 대신 타입 그래프에서 필요한 서브그래프만 traversal해야 한다.
5. 영향 분석은 장애 설명이 아니라 변경 전 blast radius를 보여 주는 안전장치여야 한다.
6. 조인 추천은 컬럼 이름이 아니라 uniqueness와 카디널리티의 증거에 근거해야 한다.
7. SQL 컴파일 성공만으로 metric 의미 보존을 판단하면 안 된다.
8. 도구 이름·입력·출력·첫 호출의 보상을 모델의 기존 습관에 맞춰야 한다.
9. 도구 품질, 사용률, 반복 성공률, 토큰 비용을 별도 측정해야 한다.
10. pass@k보다 pass^k가 운영 에이전트의 일관성을 잘 보여 준다.
11. eval은 고정 snapshot, 결정론적 scorer, 격리 환경, trace 검증을 갖춰야 한다.
12. 점수판만 보지 말고 잘못된 경로·인자·반환값을 trace에서 읽어야 한다.
13. Rust에서 시작해 Python·다중 언어·서비스 경계로 ingestion을 확장할 수 있다.
14. 데이터 카탈로그는 물리 자산을, graph는 변환·업무·lineage를 제공하므로 함께 사용해야 한다.
15. 확장성의 핵심은 저장 공간보다 변경분만 재계산하는 incremental indexing이다.
16. 코드·문서·이슈·외부 시스템의 의미를 graph에 담으면 담당 팀과 근본 원인을 연결할 수 있다.
17. 최종 목표는 질문응답기가 아니라 데이터를 안전하게 읽고 수정하며 결과를 설명하는 운영자다.
18. 작은 실습으로 구조 추출과 도구 평가를 검증한 뒤 실제 데이터 제약을 추가해야 한다.
19. 모델이 강해질수록 컨텍스트와 평가가 더 많은 업무를 맡기는 기반으로 중요해진다.
20. 신뢰할 수 있는 에이전트는 더 큰 모델이 아니라 최신 증거 graph와 반복 검증 루프에서 나온다.

마지막 20줄 핵심 요약

1. 데이터 에이전트의 핵심 병목은 모델보다 데이터 의미를 연결하는 컨텍스트다.
2. 신뢰성은 SQL 실행 성공이 아니라 행의 의미와 업무 정의를 보존하는 데서 나온다.
3. grain은 한 행이 무엇을 뜻하는지 나타내며 하류 집계의 전제가 된다.
4. one-to-one 조인이 one-to-many가 되면 실제 유입 없이도 행 수와 지표가 부풀 수 있다.
5. 코드만 읽히면 의미가 없고 DB만 보여 주면 관계와 업무 정의가 없다.
6. 데이터 컨텍스트에는 grain, 조인 안전성, 지표 의미, 의존성 정보가 필요하다.
7. SQL 구조와 lineage는 결정론적으로 추출하고 데이터 프로파일로 조인을 검증해야 한다.
8. LLM은 자산 이름과 요약, 분류, 모호성 해소처럼 의미 표현에 집중해야 한다.
9. 타입 graph는 최신 데이터 시스템의 노드와 provenance 엣지를 함께 저장한다.
10. 작업마다 전체 저장소를 넣지 말고 필요한 서브그래프만 traversal해야 한다.
11. graph는 변경 전 blast radius와 안전한 조인 경로를 근거와 함께 제공한다.
12. metric predicate를 지우는 작은 리팩터링도 하류 대시보드의 의미를 바꿀 수 있다.
13. Rust 실습은 Tree-sitter와 rustdoc JSON으로 구조와 심볼 정체성을 추출한다.
14. Neo4j와 Cypher는 심볼 관계를 저장하고 blast radius 도구를 가능하게 한다.
15. 모델은 새 graph보다 익숙한 grep을 먼저 쓰므로 도구 설계와 프롬프트가 중요하다.
16. 첫 호출부터 유용한 결과를 주고 검색처럼 보여야 도구 이탈을 줄일 수 있다.
17. pass@k보다 pass^k와 도구 adoption이 반복 운영의 신뢰성을 더 잘 측정한다.
18. eval은 고정 snapshot, 결정론적 scorer, 격리 환경, trace 검증을 갖춰야 한다.
19. 확장성의 핵심은 저장 공간보다 변경분만 재색인하는 incremental indexing이다.
20. 궁극적으로 에이전트는 데이터를 설명하고 안전하게 수정하는 시스템 운영자가 되어야 한다.