4년 전 우리는 프롬프트를 최적화했다. 2년 전엔 도구(tool) 호출 패턴을 설계했다. 지금 프런티어 팀들이 설계하는 것은 ‘컨텍스트 엔진’이다.

패러다임 이동이 다시 한 번 일어나고 있다.

세 신호가 같은 방향을 가리키고 있다

ServiceNow는 자사 AI 전략의 핵심을 ‘Context Engine’이라 명명했다. 기존 AI 플랫폼처럼 모델과 도구를 연결하는 게 아니라, 기업 내부의 맥락 — 프로세스, 정책, 히스토리 — 을 먼저 통합하는 방식이다. 사이드카 어프로치(모델에 도구를 붙이는 방식)에서 벗어나 ‘기업 맥락 기반 AI 네이티브’로 재설계한다는 선언이었다.

시스코는 같은 흐름에서 “멀티 에이전트 인프라 시대”를 공식 선언하며 네트워킹과 보안 레이어를 에이전트 관점에서 전면 재설계하고 있다고 밝혔다. 개별 에이전트의 성능보다 에이전트 간 신뢰 경계와 컨텍스트 공유 방식이 인프라의 핵심 변수라는 것이다.

Grok 4.20은 더 직접적이다. 조정·팩트체크·논리·창의 역할을 맡은 4개의 특화 에이전트가 병렬로 검증한 결과 환각률이 65% 감소했다. 단일 모델에 더 좋은 프롬프트를 주는 게 아니라, 역할이 분리된 에이전트들이 서로의 출력을 맥락 기반으로 교차 검증하는 구조다.

패턴이 보인다. 경쟁이 ‘모델 호출 최적화’에서 ‘컨텍스트 통합 설계’로 이동하고 있다.

도구 호출이 아니라 맥락 통합이 우선이다

많은 팀이 에이전트 오케스트레이션을 여전히 “도구 호출 순서 설계”로 접근한다. 언제 어떤 도구를 부를 것인가. 어느 함수를 먼저 실행할 것인가. 이건 틀린 질문이 아니지만, 충분한 질문도 아니다.

LangChain 창업자 hwchase17은 이렇게 표현했다: “Model-Harness-Task fit”이 에이전트 품질을 결정한다. RL 포스트트레이닝이 모델과 하네스의 fit을 생성하고, 그 fit이 도구 호출의 품질을 좌우한다. 도구를 먼저 고르는 게 아니다. 모델이 작동하는 맥락 구조를 먼저 설계해야 한다.

Anthropic의 Alex Albert는 이를 “model + harness + character = one system”이라 정리했다. 세 요소가 분리된 레이어가 아니라 통합된 하나의 시스템이라는 뜻이다. 에이전트의 역할 정의(character)가 실행 환경(harness)과 함께 설계될 때, 모델의 출력 품질이 올라간다.

MCP context-mode가 컨텍스트를 98% 감축하면서도 품질을 유지할 수 있는 이유도 같다. 전체 정보를 모두 넣는 것이 아니라, 이 에이전트가 지금 이 작업에 필요한 맥락만을 구조화해서 전달하는 것. 이것이 오케스트레이션의 진짜 설계 단위다.

PM이 먼저 점검해야 할 세 가지

에이전트 프로젝트가 막히는 지점은 대부분 비슷하다. 도구가 부족한 게 아니다. 에이전트에게 주어지는 맥락이 부실하다.

내부 지식이 정리되어 있지 않다. 히스토리가 없다. 정책이 문서화되어 있지 않다. 그러니 에이전트는 매번 0에서 시작해야 하고, 동일한 실수를 반복한다.

ServiceNow가 ‘Context Engine’이라 부르는 것을 PM 언어로 바꾸면 이렇다: 에이전트가 일하기 전에 먼저 알아야 할 것들을 체계화하는 작업. 이는 프롬프트 작성보다 어렵고, 도구 통합보다 오래 걸린다. 그러나 이것이 없으면 에이전트는 어떤 모델을 쓰든 비슷한 수준에 머문다.

첫째, 에이전트가 참조할 단일 정보원이 있는가. 여러 팀이 각자 다른 버전의 정책 문서를 갖고 있으면 에이전트는 어느 버전을 따를지 모른다. 메모리 레이어를 설계하기 전에, 에이전트가 믿을 수 있는 단일 소스부터 만들어야 한다.

둘째, 역할이 분리되어 있는가. Grok 4.20이 증명한 것처럼, 한 에이전트가 모든 것을 하려 할 때보다 역할이 분리된 에이전트들이 서로 검증할 때 품질이 올라간다. 무엇을 생성하고 무엇을 검증할지, 역할 경계를 미리 설계해야 한다.

셋째, 컨텍스트 예산이 있는가. 에이전트에게 모든 정보를 주는 것은 도움이 아니라 방해다. 이 에이전트가 이 작업에서 알아야 할 것과 알 필요 없는 것을 분리하는 것 — 이것이 컨텍스트 예산이다. MCP context-mode의 98% 감축은 이 원칙의 구현체다.

도구를 먼저 고르지 말 것

에이전트 오케스트레이션 설계를 시작할 때 많은 팀이 “어떤 도구를 쓸까”를 먼저 묻는다. 더 좋은 첫 질문은 이것이다.

“이 에이전트가 일하기 위해 알아야 할 것은 무엇인가?”

맥락이 설계되면 도구는 따라온다. 역할이 분리되면 검증 구조가 생긴다. 이 순서가 바뀌면, 좋은 도구를 잔뜩 붙여도 에이전트는 제자리를 맴돈다.

ServiceNow, 시스코, Grok이 동시에 컨텍스트 레이어를 설계 출발점으로 가져가는 건 우연이 아니다. 에이전트 시대의 오케스트레이션 경쟁은 이미 ‘도구 호출 최적화’에서 ‘맥락 통합 설계’로 이동했다.

당신의 에이전트 설계는 어느 출발점에서 시작하고 있습니까?