MCP만 붙이면 「어떤 고객이 불만이었나」에서 멈춥니다, AI Engineer 컨텍스트 그래프 발표대로 오늘 에이전트 도구를 조회와 교차 조회로 나눕니다 | DAKER 커뮤니티

에이전트에 MCP 서버를 몇 개만 붙이면 회사 시스템이 열린 것처럼 느껴집니다. 그런데 AI Engineer 채널이 2026년 10월 9일 공개한 Merge 공동창업자·CTO Gil Feig의 발표 「Why Your Company Needs a Context Graph (and How to Build It)」는 다른 질문을 던집니다. 「지난주 고객 A가 왜 불만이었나」는 라이브 조회로 답할 수 있지만, 「지난주에 어떤 고객들이 불만이었나」로 바꾸면 같은 도구 연결로는 페이지를 넘기다가 시간 제한에 걸릴 수 있습니다. 해커톤이나 대회에서 도구를 붙인 에이전트를 쓰는 분이라면, 오늘 도구 목록을 단순 조회용과 교차 조회·분석용으로 나누는 한 가지 작업부터 하는 편이 서버를 더 붙이는 일보다 먼저입니다.

밝은 나무 책상 위의 실사풍 생성 이미지. 가운데에 닫힌 검정 노트북이 있고 왼쪽에는 사람 실루엣 아이콘이 있는 흰 카드, 오른쪽에는 펼쳐진 빈 카드 무더기가 있으며, 가운데에 조회와 교차 조회를 오늘 나눕니다라는 한글 문구가 있고 왼쪽 위에 DAKER 공식 로고가 있습니다
설명용 생성 이미지입니다.

발표가 말하는 컨텍스트 그래프는 무엇입니까

발표는 AI Engineer World's Fair 2026(샌프란시스코)에서 녹화됐고, 길이는 약 15분입니다. Feig는 컨텍스트 그래프를 노드·간선 다이어그램이 아니라 회사의 두뇌로 정의합니다. 구성 요소는 넷스위트·지라처럼 다른 시스템에 있는 서드파티 데이터, 회사가 넣은 구조화 정보와 정적 문서, 에이전트 사용 중에 쌓이는 메모리, 그리고 일을 어떻게 할지 적는 스킬입니다. 그래프라는 단어를 특정 저장 형식으로 고정하지 않고, 질문에 맞춰 무엇을 가져올지 고르는 층으로 설명합니다.

ai.engineer 발표 정리 페이지도 같은 선을 따릅니다. 접근 권한만으로는 어떤 정보가 중요한지, 회사가 그 정보를 어떻게 해석하는지를 알려 주지 않습니다. 기록은 사업을 설명하고, 메모리와 스킬은 무엇을 가져오고 어떻게 쓸지를 정한다는 구분입니다.

도구는 컨텍스트가 아니라고 발표자는 마무리에서 정리합니다. 컨텍스트 그래프는 도구뿐 아니라 데이터, 동기화한 데이터, 회사가 가진 절차까지 포함해 회사 전체에서 추론하게 돕는다는 뜻입니다.

질문이 한 글자만 바뀌어도 접근 방식이 달라집니다

발표의 핵심 예시는 짧습니다. 「지난주 고객 A가 왜 불만이었나」라면 에이전트는 젠데스크에서 그 고객의 티켓을 조회하면 됩니다. 발표 예시에서는 API 동기화가 깨졌다는 내용의 티켓이 세 건 있었고, 그것으로 질문에 답할 수 있었습니다. 고객과 기간이 이미 주어져 있으므로 라이브 조회가 맞습니다.

같은 문장을 「지난주에 어떤 고객들이 불만이었나」로 바꾸면 고객 이름이 입력이 아니라 답이 됩니다. 에이전트는 고객을 가로질러 티켓을 살펴야 합니다. 기간을 일 년으로 늘리면 티켓을 한 번에 약 100건씩 수천 번 넘기다가 시간 제한에 걸릴 수 있다고 발표자는 설명합니다. MCP가 도구를 열어 주더라도, 그 도구는 원본 API의 접근 패턴을 그대로 물려받습니다. 페이지 단위로 티켓을 주는 API가 에이전트 뒤에 붙었다고 해서 갑자기 의미 검색 API가 되는 것은 아닙니다.

그래서 Feig는 의미 검색이나 넓은 분석이 필요하면 관련 서드파티 데이터를 로컬에서 통제하는 컨텍스트 저장소로 동기화하고, 벡터 데이터베이스로 의미 검색을 옮기라고 말합니다. 반대로 스트라이프에서 특정 고객 한 명을 조회하거나 한 번의 행동을 실행하는 경우에는 라이브 MCP가 여전히 맞다고 구분합니다.

라우터·요약기·스킬이 없으면 검색 결과가 그대로 쌓입니다

동기화 조회와 라이브 조회를 둘 다 갖게 되면 다음 문제는 합치는 일입니다. 검색 결과를 에이전트 프롬프트에 그대로 부으면 안 됩니다. 발표는 라우터가 들어온 질문을 적절한 처리기로 보내고, 요약기가 동기화 경로와 라이브 경로에서 모은 정보를 줄여 다시 에이전트에 돌려준다고 설명합니다.

그 앞에 스킬과 메모리가 있습니다. 「불만 고객」의 정의는 회사마다 다릅니다. 어떤 회사는 열린 티켓 수이고, 티켓이 긍정 피드백일 수도 있으며, 어떤 회사는 퀄트릭스 설문부터 보라고 정할 수 있습니다. 스킬은 그 회사의 절차를 적습니다. 고객이 행복한지 어떻게 판단할지, 그래서 어느 시스템을 먼저 볼지가 스킬에 들어갑니다. 발표자가 말하는 흐름은 질문이 들어오면 라우팅하고, 관련 스킬·메모리를 확인한 뒤, 그에 맞춰 동기화 저장소와 라이브 조회를 고르고, 요약한 뒤 돌려보내는 순서입니다.

마법은 없다고 발표자는 말합니다. 데이터 접근과 업무 규칙을 맞춰 두면 결과가 따라온다는 뜻입니다.

컨텍스트에는 네 층이 있습니다

Feig는 에이전트에 넘어가는 것은 모두 컨텍스트라고 넓게 정의하고, 네 층을 나눕니다. 아래는 발표에서 말한 역할만 옮긴 것입니다.

층역할발표에서 강조한 점
프롬프트·스킬·메모리과제와 데이터 출처 선택회사마다 다른 절차를 여기에 둡니다
라이브 API 호출단순 조회·단일 행동추가하기 쉽고, 이 구조에서는 동기화보다 운영 비용이 낮은 편이라고 설명합니다
캐시·동기화 데이터의미 검색·넓은 질문데이터베이스와 지속 동기화가 필요하고 최신성을 유지하는 비용이 듭니다
파생 컨텍스트요약·추출·재사용고객 티켓 전체를 가져왔을 때 요약을 저장해 두면 같은 질문을 다시 처리할 때 반복을 줄입니다

선택 흐름도 발표에 있습니다. 스킬·메모리와 맞으면 먼저 실행하고, 외부 데이터가 필요 없으면 바로 답을 만듭니다. 맞지 않거나 외부 데이터가 필요하면 캐시·동기화 데이터가 서비스 수준에 맞게 신선한지 확인합니다. 신선하면 캐시를 쓰고, 아니면 라이브 API를 호출합니다. 충분한 컨텍스트가 모일 때까지 반복한 뒤, 발견한 내용을 메모리에 남길 수 있고, 답을 생성합니다.

출처·시각·권한은 답과 함께 남겨야 합니다

발표 후반의 강조점은 추적 가능성입니다. MCP 결과든 벡터 데이터베이스에 넣은 동기화 데이터든, 출처를 버리지 말라고 말합니다. 남겨야 할 항목으로 어디서 가져왔는지, 언제 가져왔는지, 어떤 식별자와 범위로 가져왔는지, 누가 어떤 권한으로 접근했는지, 변환했는지와 원래 형태, 무엇으로 무효가 되는지(예: 한 달이 지나면 쓰지 않음)를 꼽습니다. 비즈니스 결정을 내리는 답일수록, 버전이 바뀌거나 오래될 수 있는 데이터일수록 이 기록이 필요합니다.

Feig가 Merge 블로그 「What everyone is getting wrong about context graphs」에서도 같은 방향을 이어 갑니다. 컨텍스트 그래프를 한 번 그려 두는 다이어그램이 아니라, 요청마다 어떤 시스템을 볼지, 라이브인지 캐시인지, 호출자가 볼 권한이 있는지, 모델이 쓸 수 있게 어떻게 묶을지를 정하는 런타임 조율 층으로 정의합니다. 블로그는 지연 시간·비용·호출 한도·신뢰·모델이 감당할 분량이라는 예산을 함께 적고, 계정 요약 캐시의 신선 창을 15분으로 두는 예시와 티켓을 전체 이력이 아니라 최근 5건만 가져오는 예시를 보여 줍니다. 발표의 Acme 상태 요약 예시도 같은 한계를 지킵니다. 캐시에 계정 요약이 없으면 CRM을 라이브로 보고, 지원 상호작용은 신선하면 캐시·아니면 라이브로 보되 티켓은 다섯 건만 가져와 파생 요약을 만듭니다.

대회 참가자에게 이 구분이 필요한 이유

도구를 많이 붙인 에이전트는 데모에서는 잘 보이지만, 평가나 제출 직전에 넓은 질문을 던지면 호출이 늘어나고 시간 제한에 닿는 경우가 있습니다. 발표의 교훈은 모델이 약해서가 아니라, 질문이 요구하는 접근 방식과 도구가 물려받은 API 패턴이 맞지 않을 때 생긴다는 점입니다. 단일 식별자로 한 건을 보는 경로와, 조건을 만족하는 여러 건을 모으는 경로를 미리 나눠 두면, 프롬프트를 고치기 전에 데이터 경로부터 점검할 수 있습니다.

스킬 한 줄을 적는 일도 같은 맥락입니다. 대회 과제에서 「이상 탐지」, 「적합」, 「우선 검토」처럼 사람마다 다르게 읽는 말이 있으면, 에이전트가 어느 파일·어느 열·어느 기준을 먼저 볼지 스킬에 고정해 두는 편이 매번 길게 설명하는 것보다 안정적입니다. 발표가 고객 행복을 회사마다 다르게 정의하라고 한 것과 같은 종류의 작업입니다.

오늘 할 일: 에이전트 도구 목록을 조회와 교차 조회로 나눕니다

발표의 기술을 그대로 재현하지 않아도, 대회·해커톤에서 도구를 붙인 에이전트를 쓰는 분은 아래 순서로 옮길 수 있습니다. 이 매핑은 발표 원문이 아니라 발표의 조회·동기화 구분을 참가자 작업에 맞게 정리한 것입니다.

  1. 에이전트가 호출하는 도구·MCP·스크립트 이름을 한 장에 적습니다.
  2. 각 항목 옆에 질문이 「이미 아는 한 건을 조회·실행」인지, 「여러 건을 가로질러 찾거나 비교」인지 표시합니다. 전자는 라이브 후보, 후자는 동기화·인덱스 후보입니다.
  3. 교차 조회 후보마다 「신선해도 되는 최대 시간」과 「한 번에 가져올 최대 건수」를 적습니다. 발표의 티켓 다섯 건 한도와 같은 형태의 한도입니다.
  4. 도메인 용어 정의를 스킬 한 줄로 적습니다. 예: 이 대회에서 「이상」은 무엇을 의미하는지, 어떤 파일을 먼저 보는지.
  5. 답이 나온 뒤에는 사용한 도구 이름, 가져온 시각, 식별자, 요약했는지 여부를 로그에 남깁니다. 발표가 말한 출처 기록의 최소 형태입니다.

이렇게 나눈 목록이 있으면 도구를 더 붙일지, 로컬에 사본을 둘지, 프롬프트만 고칠지 이야기가 구체해집니다. 「에이전트가 틀렸다」는 느낌 대신, 라이브로 풀 질문인지 동기화가 필요한 질문인지부터 구분해 볼 수 있습니다.

발표를 읽을 때 조심할 점

발표는 특정 벤더의 노드 저장 형식을 추천하지 않습니다. 기술 선택은 에이전트와 이야기하라고 말하며, 구조와 역할에 초점을 둡니다. Merge의 Gateway·Unified·Agent Handler 소개는 발표 말미의 제품 소개이므로, 이 글의 본론은 조회·동기화·스킬·출처라는 구조에 두고 제품 비교는 하지 않습니다.

블로그의 15분 신선 창이나 지연 시간 예산 수치는 운영 예시이지, 모든 팀에 같은 숫자를 쓰라는 측정 결과가 아닙니다. 대회 환경은 보통 공개 API 호출 한도와 제출 마감이 따로 있으므로, 신선 한도와 가져오기 건수는 자기 과제 규칙에 맞게 다시 정해야 합니다. 파생 요약은 손실이 있고 원본이 바뀌면 낡을 수 있다는 점도 발표와 블로그가 함께 경고합니다.

마무리

이 발표가 남기는 메시지는 단순합니다. 도구를 연결하는 일과 질문에 맞는 조각을 고르는 일은 다릅니다. 한 건 조회와 여러 건 교차 조회를 같은 경로로 취급하면, 에이전트는 열린 것처럼 보여도 넓은 질문에서 멈춥니다. 여러분의 에이전트 도구 목록에서 교차 조회로 표시한 항목은 몇 개입니까? 나눈 기준이나 출처 로그에 남긴 필드를 댓글로 알려 주시면 다른 참가자에게도 좋은 점검표가 됩니다.

출처