오늘 전혀 다른 세 곳에서 같은 결론이 나왔습니다.

ServiceNow는 기업 AI를 “사이드카” 방식에서 Context Engine 방식으로 전환했습니다. 맥락을 먼저 쌓고, 그 위에서 에이전트가 작동하는 구조입니다.

Grok 4.20은 조정·팩트체크·논리·창의 에이전트 4개가 같은 질문을 병렬 검증하는 구조를 도입해 환각률을 65% 낮췄습니다. 모델을 바꾼 것이 아닙니다. 검증 컨텍스트를 역할별로 분리한 것입니다.

OpenAI Codex Chronicle은 매 작업마다 재설명이 필요 없도록 사용자 화면 활동을 자동으로 컨텍스트로 축적하는 메모리 레이어를 공식 제품으로 출시했습니다.

세 사례는 서로 다른 회사, 다른 제품입니다. 그런데 결론이 같습니다.

에이전트 경쟁에서 이기는 팀은 더 좋은 모델을 쓰는 팀이 아닙니다. 더 좋은 컨텍스트를 설계한 팀입니다.

왜 지금인가: 모델 격차가 좁혀지는 속도

GPT-5.5, Claude 4.7, Gemini 3.1. 올해 상반기만 해도 세 모델이 경쟁적으로 출시됐습니다. 그런데 이미 실무 PM들 사이에서 “어떤 모델을 쓰느냐”보다 “어떻게 운영하느냐”라는 질문이 훨씬 더 많이 나오고 있습니다.

모델 간 성능 격차는 빠르게 줄어들고 있습니다. Google Cloud Trends 2026 보고서는 이를 공식화했습니다: “워크플로우 > 모델”. 모델 선택보다 오케스트레이션 설계가 핵심 경쟁력이라는 선언입니다.

Ethan Mollick의 146개 경제팀 재현 실험이 이를 뒷받침합니다. Claude Code와 Codex를 이용한 에이전트 팀은 인간 중간값에 가까운 성과를 냈고, 편차는 인간보다 훨씬 좁았습니다. 에이전트 AI의 진짜 가치는 “최고 성능”이 아니라 “좁은 편차의 일관된 양질” 에 있다는 것을 실험으로 확인한 겁니다.

좁은 편차를 만드는 것. 그것이 바로 컨텍스트 설계입니다.

한국에서 벌어지는 일: 업스테이지 × 다음 인수의 진짜 의미

어제(2026년 5월 7일), 업스테이지가 카카오로부터 AXZ(다음 운영사)를 인수했다고 발표했습니다.

표면적으로는 검색 시장 재편 이야기입니다. 하지만 업스테이지가 직접 붙인 키워드가 결정적이었습니다. “context AI”.

Solar LLM의 추론 능력에 다음의 20년치 한국어 검색 DB와 뉴스 아카이브를 결합하겠다는 것이 핵심 전략입니다. 업스테이지는 “질문의 맥락과 뉘앙스에 답하는 검색”을 목표로 명시했습니다.

이것은 단순한 M&A가 아닙니다. 한국 시장에서 가장 먼저 Context-first를 전략으로 선언한 AI 플랫폼이 탄생한 것입니다.

PM으로 20년을 보내면서 반복해서 봐온 패턴이 있습니다. 기술 경쟁이 성숙 단계에 접어들면, 차별화는 항상 데이터·컨텍스트·도메인 레이어로 이동합니다. 지금 에이전트 시장이 정확히 그 지점에 와 있습니다.

근본 원인: 왜 컨텍스트가 1차 변수인가

에이전트 시스템 실패 원인을 분석하면 패턴이 있습니다.

모델 환각? 사실이지만 표면입니다.
잘못된 도구 선택? 더 깊이 들어가야 합니다.
컨텍스트 없이 추론을 시작한 것. 이것이 근본입니다.

Andrej Karpathy는 올해 Sequoia Ascent 2026에서 이렇게 말했습니다.

“outsource thinking but not understanding”

생각의 실행은 에이전트에게 위임할 수 있습니다. 하지만 이해는 인간이 쥐고 있어야 한다는 뜻입니다. 그 ‘이해’가 에이전트에게 전달되는 방식이 바로 컨텍스트 레이어입니다.

에이전트에게 잘못된 컨텍스트를 주면 어떻게 됩니까.

  • 의도가 없으면 경계가 없습니다.
  • 경계가 없으면 루프가 생깁니다.
  • 루프가 생기면 비용이 폭발합니다.

이것은 기술 문제가 아닙니다. 설계 문제입니다.

같은 GPT-5.5를 사용하는 두 팀을 가정해보겠습니다. 한 팀은 에이전트에게 전체 DB를 던집니다. 다른 팀은 작업에 필요한 컨텍스트만 정제해서 전달합니다. 결과 차이는 모델 성능이 아니라 컨텍스트 설계에서 납니다.

해결 방향: Context-first 에이전트를 설계하는 3가지 패턴

100 Agents 프로젝트를 운영하면서 확인한 컨텍스트 설계 패턴입니다.

패턴 1: 컨텍스트 압축 — 필요한 것만 넘긴다

MCP context-mode는 에이전트 시스템의 토큰 비용을 98% 감축하는 오픈소스 서버입니다. HN에서 10일 이상 연속으로 상위권을 유지했고, 한국어 커뮤니티까지 확산됐습니다. 이 정도 관심은 단순한 기술 트릭이 아닙니다. 실제 운영에서 비용 문제를 직접 해결하기 때문입니다.

원리는 간단합니다. 에이전트가 필요한 컨텍스트 조각만 동적으로 주입하고, 불필요한 전체 맥락을 제거합니다. “모든 것을 알게 한다”는 접근 대신, “지금 이 작업에 필요한 것만 알게 한다”는 설계입니다.

# 나쁜 예: 전체 지식베이스를 컨텍스트로 전달
context = load_entire_knowledge_base()      # 수백만 토큰, 비용 폭발

# 좋은 예: 현재 작업 관련 컨텍스트만 추출
context = retrieve_relevant_context(
    task=current_task,
    top_k=5
)                                           # 수백 토큰, 비용 통제

98% 감축이라는 수치는 과장이 아닙니다. 대규모 에이전트 시스템에서 컨텍스트 압축은 비용 최적화의 가장 직접적인 레버입니다.

패턴 2: 역할별 컨텍스트 분리 — 에이전트마다 다른 렌즈를 준다

Grok 4.20이 환각률을 65% 낮춘 방법은 단일 에이전트에게 더 강한 모델을 투입한 것이 아닙니다. 조정·팩트체크·논리·창의 에이전트 4개가 각각 다른 역할 컨텍스트를 가지고 병렬 검증하는 구조입니다.

각 에이전트는 같은 질문을 받지만, 다른 렌즈로 봅니다. 이것이 멀티에이전트 설계의 핵심입니다. 하나의 에이전트가 모든 것을 알 필요가 없습니다. 적절한 역할의 에이전트가 적절한 컨텍스트로 검증하는 구조가 단일 강력한 에이전트보다 강합니다.

100 Agents 프로젝트에서 22개 크론 에이전트를 운영하면서 확인한 것도 같습니다. 에이전트 팀의 성능은 개별 에이전트의 지능보다, 역할과 컨텍스트 핸드오프 설계 에서 결정됩니다. 오케스트레이터가 “누가 무엇을 알아야 하는가”를 잘 설계했을 때 전체 시스템의 품질이 올라갑니다.

패턴 3: 지속 메모리 레이어 — 매번 재설명하지 않는다

OpenAI Codex Chronicle의 핵심은 단순합니다. 사용자가 매 작업마다 “나는 이런 사람이고, 이런 코드베이스를 씁니다”를 재설명할 필요가 없습니다. 화면 활동이 자동으로 컨텍스트로 축적되기 때문입니다.

이것이 에이전트 메모리의 본질입니다. 메모리를 “저장소”가 아니라 “컨텍스트 재사용 레이어” 로 보는 관점입니다. 좋은 에이전트는 새로운 대화를 시작할 때도 이전 컨텍스트에서 출발합니다.

ServiceNow Context Engine이 정확히 이 방향입니다. 사이드카 방식은 에이전트 옆에 도구를 붙이는 것입니다. Context Engine은 기업 전체의 맥락이 에이전트의 출발점 이 되는 구조입니다. 이것이 “기업 AI 네이티브 전환”의 실제 의미입니다.

Context-first를 설계한다는 것

세 패턴을 관통하는 질문이 하나 있습니다.

이 에이전트는 작업 시작 시 어떤 컨텍스트를 받는가?

이 질문에 명확하게 답할 수 있다면, 이미 Context-first 설계를 하고 있는 겁니다. 답하기 어렵다면 — “일단 다 넘기자”라는 접근을 하고 있을 가능성이 높습니다.

Context-first는 기술적으로 어렵지 않습니다. 설계 결정의 우선순위 문제입니다. 모델 선택 전에 컨텍스트 경계를 먼저 그리는 것. 도구 추가 전에 어떤 맥락이 에이전트의 출발점이 될 것인지 결정하는 것.

기술은 점점 비슷해지고 있습니다. 남는 것은 설계입니다. 그리고 설계의 첫 번째 변수는 모델이 아니라 컨텍스트 입니다.

당신의 에이전트는 지금 어떤 컨텍스트로 시작하고 있습니까? 너무 많은 것을 알아서 느리거나, 너무 적게 알아서 환각을 내거나 — 둘 중 어느 쪽이 더 가까운가요?