Grok 4.20이 공개한 수치는 명확하다. 조정·팩트체크·논리·창의 역할로 나눈 4개 에이전트가 서로의 출력을 병렬 검증했을 때 환각률이 65% 줄었다.

이 결과를 만든 조건이 하나 있다. 4개 에이전트가 같은 맥락을 공유하고 있어야 한다는 것이다. 맥락이 정렬되지 않은 상태에서 여러 에이전트가 같은 질문을 검토하면 검증이 아니라 충돌이 된다. 각자 다른 전제로 출발한 에이전트들이 서로 다른 결론을 내놓을 때, 그 차이는 역할 설계의 문제가 아니라 공유 맥락의 부재에서 시작된다.

사이드카에서 컨텍스트 엔진으로

ServiceNow가 2026년 초 AI 아키텍처를 재설계할 때 선택을 하나 했다. ’사이드카 방식’을 버렸다.

사이드카 구조는 기존 시스템 옆에 AI를 붙이는 형태다. 도입이 빠르고 기존 시스템을 건드리지 않아도 된다. 그러나 ServiceNow의 진단은 달랐다. AI가 기업 맥락에서 실시간으로 작동하지 못하면 에이전트는 결국 고립된 도구로 남는다.

대신 선택한 구조가 Context Engine을 중심에 두는 방식이다. 에이전트가 도구를 실행하기 전에 기업의 프로세스, 권한, 히스토리를 통합적으로 이해하는 계층을 먼저 구성한다. 여기서 만들어진 맥락이 에이전트들의 공통 기반이 된다.

시스코도 같은 시기 같은 결론을 냈다. 멀티에이전트 인프라 시대에 네트워킹과 보안을 전면 재설계해야 한다는 공식 선언은, 결국 에이전트들이 공유하는 맥락 레이어를 어떻게 보호하고 전달할 것인가의 문제다. 도구 연결 이전에 맥락 통로가 먼저 있어야 한다는 전제가 인프라 레이어까지 내려간 것이다.

설계 순서가 결과를 만든다

에이전트 프로젝트를 시작할 때 대부분의 팀이 먼저 하는 일은 도구를 연결하는 것이다. 어떤 API를 붙일지, 어떤 MCP 서버를 쓸지 목록을 정한다. 이 순서가 바뀌어야 한다.

첫 번째 질문은 “이 에이전트가 무엇을 알아야 하는가”다. 기업의 어떤 데이터에 접근하고, 어떤 프로세스 흐름을 이해하며, 어떤 과거 결정을 참고해야 하는가. 이 맥락 지도가 먼저 완성된 뒤에 도구 연결이 들어온다.

MCP context-mode가 토큰 사용량을 98% 줄이는 방식도 같은 원리다. 에이전트가 모든 것을 알려는 시도를 그만두고, 판단에 필요한 맥락만 정확히 가져오도록 설계하는 것이다. 줄어드는 건 토큰 비용이지만, 실제로 일어나는 것은 컨텍스트 품질의 상승이다.

PM이 먼저 만들어야 하는 것

팀이 에이전트를 기획할 때 Context Engine을 먼저 정의하는 방식은 세 가지 질문에서 시작한다.

첫째, 에이전트가 판단의 근거로 삼아야 할 기업 정보가 어디에 있는가. CRM인지, 내부 문서 시스템인지, 운영 로그인지 먼저 파악한다. 둘째, 그 정보를 에이전트가 실시간으로 읽을 수 있는 형태로 정리되어 있는가. 셋째, 맥락이 오래되거나 틀렸을 때 에이전트가 이를 인식하고 멈출 수 있는가.

세 번째 질문이 가장 중요하다. 오래된 맥락 위에서 자신 있게 행동하는 에이전트가 가장 위험하다. Grok 4.20의 65% 개선은 각 에이전트가 같은 최신 맥락을 공유하면서 상대방의 결론을 검증할 수 있었기 때문에 가능했다. 맥락 동기화가 검증 품질의 상한선이다.

ServiceNow가 사이드카를 버린 이유, Grok 4.20이 65%를 만든 구조, 시스코가 인프라 재설계를 선언한 배경이 같은 방향을 가리킨다. 에이전트의 품질은 모델 성능보다 컨텍스트 설계에서 갈린다.

여러분의 에이전트 설계에서 Context Engine을 정의한 시점은 언제입니까?