The Data Context Layer for Agents — Yoni Michael & Brandon Callender, Typedef

한 줄 핵심

데이터 에이전트와 코딩 에이전트가 실제로 신뢰할 수 있게 작동하려면 모델 성능보다 분산된 맥락을 구조화·저장·질의 가능하게 만드는 컨텍스트 레이어가 핵심이라는 점을, 데이터 그래프와 코드 그래프 사례로 보여준다.

시간별 요약

1. 0:00
   데이터 에이전트에 빠진 맥락 데이터 플랫폼에서 에이전트가 복잡한 작업을 수행하려면 모델 자체보다 필요한 맥락을 보강하는 인프라가 중요하다. 이 워크숍은 데이터 시스템을 안전하게 다루기 위한 '데이터 컨텍스트 레이어'의 필요성을 먼저 정리한다.
2. 3:44
   영향 분석, 조인, 그리고 안전한 변경 데이터 에이전트가 자주 실패하는 지점은 변경이 어디에 영향을 주는지, 조인이 안전한지, 메트릭 정의가 바뀌는지를 판단하는 부분이다. 이런 일상적인 데이터 엔지니어링 작업을 신뢰할 수 있어야 에이전트를 실제 운영에 맡길 수 있다.
3. 5:05
   분산된 맥락과 테이블 그레인 데이터에 필요한 정보는 warehouse, 변환 코드, BI 도구, 문서와 Slack에 흩어져 있다. 특히 row 하나가 무엇을 의미하는지인 그레인(grain)을 잘못 해석하면 SQL이 정상이어도 하위 집계가 모두 틀어질 수 있다.
4. 6:29
   유효한 SQL이 잘못된 원인을 설명할 수 있다 파이프라인 row count 급증의 원인은 단순 유입 증가가 아니라 상위 조인 구조가 one-to-many로 바뀐 것일 수 있다. SQL은 실행되지만 의미를 모르기 때문에, 구문만으로는 올바른 근본 원인을 찾을 수 없다.
5. 9:02
   에이전트가 알아야 할 네 가지 사실 정답을 좌우하는 핵심은 그레인, 조인 안전성, 메트릭의 의미, 그리고 어떤 모델이 어떤 것에 의존하는지다. 이 네 가지는 에이전트가 쿼리 시점에 바로 조회할 수 있도록 계산 가능하고 질의 가능해야 한다.
6. 10:13
   조인 의미와 팬아웃 같은 조인 문법도 실제 데이터 관계에 따라 row를 보존하거나 차원을 조회하거나 조용히 폭발시킬 수 있다. 또한 모델 간 도메인 관계는 폴더 이름이 아니라 lineage, 공유 키, 이름 패턴 같은 구조적 신호로 추론할 수 있다.
7. 12:42
   결정적 추출과 데이터 프로파일링 먼저 SQL에서 그레인과 lineage를 결정적으로 추출하고, 조인 안전성은 테이블 프로파일링으로 검증한다. LLM은 비즈니스 명명, 요약, 모호성 해소처럼 사람이 읽는 부분에만 쓰는 것이 안정적이다.
8. 14:16
   질의 가능한 컨텍스트 그래프를 저장하기 컨텍스트 레이어는 최종적으로 그래프로 저장되고, 커밋마다 증분적으로 갱신된다. 그래프는 전체 프로젝트를 다시 읽지 않고도 필요한 서브그래프만 한 번에 가져올 수 있어 규모가 커져도 효율적이다.
9. 17:33
   행동 전에 하위 영향부터 분석하기 변경을 적용하기 전에 그래프를 따라 downstream 의존성을 조회하면 어떤 지표가 얼마나 왜곡되는지 사전에 알 수 있다. 이 pre-flight 방식은 실제 장애가 나기 전에 blast radius를 계산하게 해준다.
10. 19:07
    안전한 조인과 메트릭 정의 조인 추천은 컬럼명 추측이 아니라 키의 유일성을 데이터로 검증해 안전한 경로를 찾는 방식이어야 한다. 메트릭 수정도 SQL 문법상 무해해 보여도 정의의 핵심 조건을 삭제하면 downstream 대시보드 전체의 의미가 바뀔 수 있다.
11. 20:55
    데이터 엔지니어링 작업을 평가하기 에이전트 시스템은 반드시 평가로 검증해야 하며, 실제 데이터 엔지니어링 작업을 난이도별로 만들어 반복 실행해야 한다. 적절한 맥락을 제공했을 때 성공률이 크게 오르며, 단순히 모델을 바꾸는 것보다 맥락 품질이 더 큰 차이를 만든다.
12. 22:32
    다섯 가지 컨텍스트 엔지니어링 패턴 가능하면 결정적으로 추출하고, 결론보다 증거를 저장하며, 전체를 프롬프트에 우겨 넣지 말고 그래프를 탐색하게 해야 한다. 또한 도구 표면은 통제하고, 신뢰할 수 있는 에이전트를 위해 평가 인프라를 초기에 계속 운영해야 한다.
13. 26:31
    Brandon의 코딩 에이전트 워크숍 이후 파트는 코딩 에이전트에 컨텍스트 레이어를 실제로 붙이는 실습이다. Quadrant 코드베이스를 예제로 삼아, 그래프 기반 도구와 평가 방법을 직접 구성해 본다.
14. 29:06
    같은 이름을 가진 두 가지 타입 텍스트 검색만으로는 동일한 이름의 심볼을 구분할 수 없고, 에이전트는 자주 잘못된 후보를 먼저 선택한다. 코드의 의미는 문자열보다 구조와 관계 속에 있으므로, 구조적 맥락이 없으면 검색은 불안정해진다.
15. 31:35
    코드 맥락을 추출·저장·질의하기 코드 컨텍스트도 데이터 컨텍스트와 마찬가지로 추출하고, 저장하고, 반복 질의하는 방식으로 다뤄야 한다. 단순 검색 목록보다 심볼 간 관계를 탐색 가능한 그래프가 에이전트에 훨씬 유리하다.
16. 34:08
    구문, 심볼 해석, 그리고 의미 첫 단계는 Treesitter 같은 도구로 구문 구조를 파싱하는 것이고, 다음 단계는 Rust의 resolver와 같은 방식으로 심볼의 정체성을 확정하는 것이다. 그 다음에야 LLM으로 의미를 요약하는 단계로 넘어갈 수 있다.
17. 36:22
    노트북 1: 코드 그래프 만들기 첫 번째 노트북은 Quadrant의 일부 crate를 대상으로 심볼을 추출하고 그래프의 기초를 세우는 과정이다. 목표는 전체 코드베이스를 다루기보다, 워크숍에서 직접 실행 가능한 축소판을 만드는 것이다.
18. 39:28
    정식 심볼 정체성 해석하기 rung 0의 단순 텍스트 검색은 재export나 중복 이름을 구분하지 못하지만, canonical location을 알면 원래 정의 위치로 되돌릴 수 있다. 이 해석이 있어야 그래프가 정확한 탐색 단위가 된다.
19. 41:15
    노드와 엣지를 Neo4j에 적재하기 추출한 심볼과 관계를 노드와 엣지로 변환해 Neo4j에 적재하면 실제 그래프를 탐색할 수 있다. 관계의 provenance와 타입이 살아 있어야 에이전트가 의미 있는 경로를 따라갈 수 있다.
20. 42:09
    블라스트 레디우스 도구 만들기 특정 함수나 타입을 바꾸면 무엇이 깨지는지 downstream 의존성을 따라 계산하는 도구를 만든다. 같은 이름의 심볼이라도 canonical identity가 다르면 영향 범위도 달라진다.
21. 44:08
    에이전트를 그래프에 연결하기 간단한 system prompt와 도구 설정만으로도 에이전트가 검색과 blast radius 조회를 여러 턴에 걸쳐 사용할 수 있다. 구조화된 그래프가 있으면 Cypher 같은 질의도 자연스럽게 생성된다.
22. 46:01
    추가 그래프 도구 작성하기 필요한 도구는 더 만들 수 있고, 자연어 요청에서 자동으로 Cypher 질의를 생성하게 할 수도 있다. 스키마와 엣지 타입을 잘 정의하면 도구 확장이 쉬워진다.
23. 47:10
    Fenic으로 만드는 의미 요약 rung 2에서는 LLM이 코드 심볼의 역할을 한 문장으로 요약해 그래프에 붙인다. 이렇게 생성한 의미는 감사 가능하고, 잘못된 설명도 나중에 수정할 수 있다.
24. 48:56
    유지보수와 언어 한계 그래프를 실시간으로 재구성할지, 캐시할지, 증분 갱신할지는 비용과 최신성의 균형 문제다. 동적 언어나 Python처럼 타입 해석이 어려운 언어는 더 힘들지만, 보조 도구를 붙여 확장할 수 있다.
25. 53:53
    데이터 엔지니어링 평가와 범위 데이터 컨텍스트 레이어는 runtime에서 특히 유용하며, 벤치마크도 실제 규모의 데이터 아키텍처를 써야 의미가 있다. Mattermost 같은 대형 dbt 프로젝트를 활용해 오류 수정과 새 작업 생성 같은 시나리오를 평가한다.
26. 57:33
    에이전트는 결국 grep을 고른다 아무리 좋은 그래프 도구를 줘도 에이전트는 여전히 익숙한 grep과 파일 읽기로 돌아가려 한다. 문제는 도구의 우수성만이 아니라, 모델의 후학습된 습관을 이길 수 있게 실제로 그 도구를 쓰게 만드는 것이다.
27. 1:00:20
    에이전트의 습관에 맞춰 도구 설계하기 도구 이름을 search처럼 익숙하게 만들고, 반환 형식도 grep과 비슷하게 맞추면 사용률이 올라간다. 첫 호출에서 바로 유용한 결과를 내야 에이전트가 그 도구를 다시 찾는다.
28. 1:02:07
    공정하게 에이전트 비교하기 두 에이전트에 같은 모델을 주고, 하나는 그래프 도구를, 다른 하나는 파일 탐색 도구를 쓰게 해 비교한다. 좋은 벤치마크는 실제 작업 질문을 바탕으로 하고, 정답 데이터는 소스코드와 교차 검증해야 한다.
29. 1:04:24
    결정적 점수화와 증거 이상적인 평가는 가능한 한 LLM-as-judge에 덜 의존하고, 정답과 증거를 결정적으로 채점할 수 있어야 한다. 평가기는 답의 내용뿐 아니라 필요한 근거를 모두 인용했는지도 확인해야 한다.
30. 1:06:32
    한 번의 정답보다 반복적 일관성 한 번 맞히는 것보다 여러 번 실행했을 때 계속 맞히는지가 더 중요하다. pass@k와 같은 지표로 일관성을 보면, 그래프 기반 접근이 더 적은 토큰으로 더 안정적으로 동작함을 확인할 수 있다.
31. 1:08:40
    그래프 도구 채택률 측정하기 도구가 실제로 쓰이는지 확인하려면 trace를 분석해 어떤 툴이 호출됐는지 집계해야 한다. adoption률이 높아져야 도구 개선이 실질적인 성과로 이어진다.
32. 1:14:08
    호출 그래프, 카탈로그, 그리고 데이터 벤치마크 심볼 그래프보다 한 단계 높은 수준으로는 call graph가 있고, 데이터 쪽에서는 catalog와 context graph가 서로 보완적이다. 평가용 데이터셋은 실제 레포와 런타임 환경이 함께 갖춰져야 하며, 벤치마크 인프라 구축이 어렵다.
33. 1:21:08
    트레이스를 읽고 점수판을 의심하기 점수판만 보면 방향성은 맞아도 하위 오류를 놓칠 수 있으므로, trace를 직접 읽어 실제 경로를 확인해야 한다. 숫자를 높이는 것보다 하드한 평가를 만들고 하네스를 고치는 것이 먼저다.
34. 1:25:40
    Rust를 넘어 더 작은 질문으로 확장하기 Rust는 컴파일러 덕분에 rung 1을 쉽게 만들 수 있었지만, Python처럼 구조가 느슨한 언어는 훨씬 어렵다. 그래서 인제스트 과정을 모듈화해 언어가 달라도 같은 그래프 구조를 재사용할 수 있어야 한다.
35. 1:31:36
    경계, 인덱싱, 그리고 안정적인 평가 스냅샷 마이크로서비스나 HTTP 경계를 넘는 문제는 더 어렵고, 경계를 분류하는 추가 계층이 필요하다. 평가용 골드 데이터는 변경되는 코드와 분리된 고정 스냅샷으로 관리해야 비교가 가능하다.
36. 1:39:20
    온톨로지와 더 넓은 데이터 컨텍스트 비전 최종 비전은 그래프 위에 온톨로지 계층을 얹어, 어디에 무엇이 있고 무엇을 의미하는지까지 정리하는 것이다. 이렇게 하면 데이터 팀뿐 아니라 비기술 사용자도 같은 맥락에서 에이전트와 상호작용할 수 있다.

실무 인사이트

• 데이터·코드 에이전트의 성능은 모델 교체보다 맥락의 결정성, 증분 갱신, 그래프 탐색 가능성에서 더 크게 좌우된다.
• 실무 적용에서는 도구를 더 많이 붙이기보다, 에이전트가 첫 호출부터 자주 쓰게 되는 좁고 강한 도구를 설계하는 편이 효과적이다.
• 평가 체계는 한 번의 정답률보다 반복 실행 일관성, 도구 채택률, 근거 인용 여부를 함께 봐야 운영 신뢰도를 판단할 수 있다.