도구를 먼저 연결하는 팀과 컨텍스트를 먼저 설계하는 팀이 있다.

결과는 처음엔 비슷해 보인다. 6개월 후가 다르다.

첫 번째 팀의 에이전트는 기능이 많아질수록 점점 느려지고, 예측이 안 되고, 어디서 틀렸는지 파악하기 어려워진다. 두 번째 팀의 에이전트는 기능이 늘어도 일관되게 작동한다. 그 차이는 모델이 아니다. 컨텍스트 설계에서 난다.

세 곳에서 같은 결론이 나왔다

올해 에이전트 오케스트레이션 분야에서 가장 주목받은 발표들을 보면 공통점이 있다.

ServiceNow는 Context Engine을 공개하며 “사이드카 방식을 버리고 기업 맥락을 AI의 기반으로”라는 메시지를 냈다. 단순히 모델에 도구를 추가하는 방식에서, 기업의 맥락 자체를 AI가 처음부터 이해하도록 설계하는 방식으로의 전환이다.

MCP(Model Context Protocol)의 컨텍스트 98% 감축 오픈소스 서버는 에이전트 토큰 비용을 즉각 낮췄다. 핵심은 “더 많은 컨텍스트”가 아니라 “더 좋은 컨텍스트”였다. 불필요한 정보를 줄이고 에이전트가 판단에 실제로 필요한 신호만 남기는 구조적 접근이다.

Grok 4.20은 에이전트 4개를 병렬로 붙이는 검증 구조로 환각률 65%를 줄였다. 단일 모델을 더 크게 만든 게 아니다. 각자가 다른 역할을 맡고(조정·팩트체크·논리·창의) 서로를 검증하는 흐름을 설계한 것이다.

세 사례 모두 도구 추가가 아니라 컨텍스트 구조 설계를 먼저 했다.

에이전트가 실패하는 이유

팀이 에이전트 도입 후 6개월 안에 포기하는 패턴을 보면 공통 원인이 있다.

에이전트에게 “이 데이터를 분석해줘”라는 도구 호출은 있는데, 에이전트가 ‘왜 이 분석이 필요한지’, ‘어떤 기준으로 결론을 내야 하는지’, ‘이전 실행에서 무엇이 있었는지’를 전혀 모른다. 그 상태에서 아무리 좋은 모델을 써도 출력 품질이 들쭉날쭉하고, 오류가 발생해도 추적이 안 된다.

LangChain의 Harrison Chase(@hwchase17)는 이것을 “model-harness fit”으로 표현했다. 모델과 하네스를 분리해서 생각하는 건 잘못된 분해라는 것이다. 도구 선택보다 컨텍스트 구조가 먼저 결정되어야 모델이 하네스 안에서 제대로 작동한다.

Hugging Face도 “하네스·스캐폴드·에이전트 용어를 제대로 이해해야 한다”는 블로그를 냈다. 용어 정리는 사소해 보이지만, 설계 경계와 책임을 명확히 하는 작업이다. 컨텍스트를 누가 만들고 누가 소비하는지가 불분명한 시스템은 언제나 의도치 않은 방식으로 실패한다.

PM이 먼저 물어야 할 질문

에이전트 설계를 시작할 때 가장 흔한 실수는 “어떤 도구를 연결할까”를 먼저 묻는 것이다.

올바른 설계 순서는 반대다.

1단계: 에이전트가 판단하기 위해 무엇을 알아야 하는가? 필요한 컨텍스트를 열거한다. 이전 실행 기록, 사용자 의도, 비즈니스 제약, 현재 상태. 이것이 먼저 정의되지 않으면 어떤 도구를 연결해도 에이전트는 올바른 판단을 내리지 못한다.

2단계: 그 컨텍스트를 어떻게 구조화할 것인가? 에이전트가 소비하기 좋은 형태로 정보를 설계한다. 평문 덩어리가 아니라 역할별 신호로 분리한다. ServiceNow Context Engine이 “사이드카 방식을 탈피했다”고 말한 것이 이 단계의 중요성을 가리킨다.

3단계: 컨텍스트가 준비된 후, 어떤 도구가 필요한가? 도구는 마지막에 연결한다. 이 순서를 지키면 도구 목록이 늘어도 시스템이 흔들리지 않는다.

OpenAI Codex Chronicle이 화면 활동 기반 컨텍스트를 자동으로 축적하는 설계를 선택한 이유도 여기 있다. 매번 사용자가 설명하지 않아도 에이전트가 작업 흐름을 이해하게 만드는 것, 그게 컨텍스트 설계가 해결하는 문제다.

실전 적용: 컨텍스트 패키지를 먼저 구성하라

100 Agents 프로젝트에서 22개 에이전트를 운영하면서 가장 효과가 컸던 설계 결정은 “모든 에이전트 호출 전에 컨텍스트 패키지를 먼저 구성하는 단계”를 넣은 것이었다.

// 에이전트 호출 전 컨텍스트 패키지 구성
const context = {
  task: currentTask,
  history: recentRuns.slice(-3),                      // 최근 3회 실행 요약
  constraints: teamConstraints,                        // 비즈니스 제약
  availableTools: toolRegistry.forTask(currentTask)   // 이 태스크에 필요한 도구만
};

await agent.run(context);

도구 목록 전체를 넘기지 않는다. 태스크에 맞는 도구만 선택해서 컨텍스트에 포함한다. 실행 기록 전체가 아니라 최근 3회의 요약만 넘긴다. 이 단순한 변화만으로 응답 일관성이 높아지고 토큰 비용이 줄었다.

MCP 컨텍스트 98% 감축 서버가 같은 원리다. “필요한 것만 남기는” 구조적 결정이 모델 업그레이드보다 성능에 더 직접적인 영향을 미친다.

에이전트 오케스트레이션의 다음 경쟁 축

Google이 Cloud Next 2026에서 Gemini Enterprise Agent Platform을 공개하면서 “에이전트 OS” 개념을 공식화했다. LangChain은 fanout-and-synthesize 패턴과 adversarial verification 패턴을 “재사용 가능한 오케스트레이션 표준”으로 정리했다. 공통점은 모두 컨텍스트 흐름을 먼저 설계하고 도구를 나중에 배치한다는 것이다.

에이전트 경쟁의 다음 전선은 더 큰 모델이 아니다. 더 정확한 컨텍스트 구조다.

ServiceNow가 Context Engine을 꺼낸 이유, MCP가 컨텍스트 98%를 줄인 이유, Grok이 역할별 검증 구조를 선택한 이유가 모두 같은 방향을 가리킨다. 도구보다 컨텍스트가 먼저다.

당신 팀의 에이전트 설계에서 컨텍스트 구조를 먼저 정의한 적이 있습니까?