저는 매일 클라우드 운영 (Cloud Ops)의 일부를 실행하기 위해 AI 에이전트를 사용합니다. 또한 제가 지금 실행하고 있는 정확한 설정이 올해 말이면 창피할 정도로 원시적으로 보일 것이라고 확신하며, 이것이 파격적인 주장이라고 생각하지도 않습니다. 벤더(Vendors)들은 자신들의 로드맵을 통해 우리에게 그 사실을 공개적으로 말하고 있습니다. 여러분은 릴리스 노트 (Release notes)를 단순한 변경 로그 (Changelog)가 아닌 추세선 (Trend line)으로 읽기만 하면 됩니다.

올해 플랫폼들이 출시한 것들을 증거로 삼아 그 근거를 제시하겠습니다.

6개월 뒤에 보게 될 "원시적"인 모습

모든 세대의 도구는 다음 세대가 등장하여 소급적으로 구식처럼 보이게 만들기 전까지는 최첨단 (State-of-the-art)처럼 느껴집니다. 스택 트레이스 (Stack trace)를 채팅창에 복사해서 붙여넣는 것이 미래처럼 느껴졌던 때를 기억하시나요? 그게 18개월 전의 일입니다. 클라우드 자격 증명 (Cloud credentials), 몇 가지 MCP 도구, 그리고 가드레일 (Guardrails)로 가득 찬 시스템 프롬프트 (System prompt)를 갖춘 현재의 최상위 스택은 정확히 똑같은 방식으로 노후화될 것이며, 로드맵은 어떤 축을 따라 변화할지를 알려줍니다.

축 1: 메모리 (Memory)가 부가 기능에서 네이티브 (Native)로 전환됩니다. 올해 AWS Bedrock AgentCore, Azure Foundry Agent Service, 그리고 Vertex는 모두 관리형 장기 메모리 (Managed long-term memory)를 출시했습니다. 오늘날 대부분의 운영 에이전트 (Ops agents)는 사실상 기억상실증에 걸린 상태와 같습니다. 모든 세션이 차갑게 시작되어, 동일한 인프라를 다시 발견하고, 동일한 "저 인스턴스는 건드리지 마세요"라는 규칙을 다시 배웁니다. 로드맵의 방향은 명확합니다. 지난주의 장애 상황, 환경의 특이점, 그리고 어떤 알람이 항상 오탐 (False positives)인지 기억하는 에이전트가 등장할 것입니다. 그것이 현실이 되는 순간, 상태가 없는 (Stateless) 에이전트는 메모를 전혀 하지 않는 주니어처럼 보일 것입니다.

축 2: 도구 사용 (Tool use)이 표준화되고 심화됩니다. MCP는 Anthropic의 흥미로운 프로토콜에서 Google이 Vertex 전반에 걸쳐 배포하고 모든 진지한 플랫폼이 채택하고 있는 무언가로 변했습니다. 오늘날의 에이전트는 수동으로 연결된 5~6개의 도구를 호출합니다. 그 궤적은 에이전트가 스스로 조합하는 수백 개의 표준화된 도구로 향하고 있습니다. 저의 현재 "여기 당신의 6가지 함수가 있습니다"라는 설정은 그 옆에서 모델 T를 수동으로 돌리는 것처럼 보일 것입니다.

축 3: 컨텍스트 윈도우 (Context Window)가 더 이상 제약 사항이 되지 않습니다. Claude Opus 5가 1M(100만) 토큰 컨텍스트를 갖추고 Bedrock에 출시되었습니다. 100만 토큰은 에이전트가 귀하의 전체 인프라 상태, 한 달 치의 로그, 그리고 전체 런북 (Runbook)을 한 번에 컨텍스트 내에 유지할 수 있음을 의미합니다. 모델에 입력하기 전에 상태를 요약하고 잘라내기 (Summarize-and-truncate) 위해 제가 구축했던 모든 조잡한 임시방편들 — 그 모든 종류의 배관 작업 (Plumbing) — 은 컨텍스트의 희소성이 사라지는 날 죽은 코드가 될 것입니다.

축 4: 거버넌스 (Governance)가 플랫폼 내부로 이동합니다. AWS는 올해 에이전트 관측성 (Observability) 및 정책 집행 (Policy enforcement)을 Bedrock의 일급 기능 (First-class features)으로 출시했습니다. 현재 저의 가드레일 (Guardrails)은 수공업적입니다. 맞춤형 폭발 반경 (Blast-radius) 제한, 수동으로 만든 승인 게이트, 자체 제작한 상태 검증 루프 (State-verification loop) 같은 것들 말이죠. 로드맵에 따르면 거버넌스는 코드가 아니라 구성하는 플랫폼 기본 요소 (Platform primitive)가 될 것입니다. 그렇게 되면 제가 직접 만든 안전 장치는 본질적으로 쉘 스크립트(Shell scripts) 더미에 불과해 보일 것입니다.

여기서 로드맵이 유난히 신뢰할 수 있는 이유

로드맵은 끊임없이 거짓말을 합니다. "곧 출시 예정 (Coming soon)"의 절반은 결코 출시되지 않습니다. 그런데 왜 이번 로드맵은 믿을 만할까요? 이 네 가지 축은 슬라이드 위의 추측성 기능이 아니기 때문입니다. 그것들은 이미 출시되었으며, 단지 불균등하게 배포되어 있을 뿐입니다. 메모리 (Memory)는 존재합니다. MCP는 존재합니다. 100만 토큰 컨텍스트도 존재합니다. 플랫폼 거버넌스도 존재합니다. 이 중 어느 것도 공상 과학이 아닙니다. 단지 오늘, 당신의 에이전트 안에 이 모든 것이 한꺼번에 들어있지 않을 뿐입니다. 베팅의 핵심은 "이것이 발명될 것인가"가 아니라, "얼마나 빨리 기본값 (Default)이 될 것인가"입니다. 그리고 모든 주요 클라우드가 동시에 같은 방향으로 밀어붙이기 시작하면 기본값은 빠르게 움직입니다. AWS, Azure, Google이 독립적으로 동일한 12개월 안에 메모리 + MCP + 거버넌스로 수렴하고 있다면, 그것은 로드맵상의 약속이 아니라 하나의 흐름 (Current)입니다.

함정: 오늘을 위해 과도하게 구축하지 마세요

이것이 실질적인 결과이며, 제가 단순히 뉴스에 고개를 끄덕이는 대신 이 글을 쓰는 이유입니다. 만약 해당 플랫폼이 곧 메모리 (memory), 표준화된 도구 (standardized tools), 거대한 컨텍스트 (huge context), 그리고 거버넌스 (governance)를 흡수할 것이라는 점을 알고 있다면, 지금 당신이 할 수 있는 최악의 행동은 이 중 어느 하나라도 직접 깊고 맞춤화된 (bespoke) 버전을 구축하는 것입니다. 에이전트 메모리 저장소 (agent memory store)나 커스텀 도구 라우팅 레이어 (custom tool-routing layer)를 수작업으로 만드는 데 소비하는 매 시간은, 플랫폼이 곧 당신에게 무료로 제공할 무언가를 만드는 시간이며, 당신이 만든 버전은 더 열등하고 유지보수되지 않은 상태일 것입니다.

전환기 속에서 살아남는 것은 배관 (plumbing)이 아닙니다. 그것은 바로 '정책 (policy)'입니다. 즉, 에이전트가 무엇을 할 수 있도록 허용되는지, 어느 정도의 폭발 반경 (blast radius)을 허용할 것인지, 무엇에 인간이 개입해야 하는지, 그리고 행위자 (actor)와 독립적으로 상태 (state)를 어떻게 검증할 것인지와 같은 것들입니다. 이것들은 기능 (features)이 아니라 결정 (decisions)이며, 기반이 되는 에이전트가 아무리 좋아지더라도 그 가치는 유지됩니다. 이것이 바로 우리가 ZopNight에 스케줄링 (scheduling)과 복구 (remediation) 기능을 구축할 때, "무엇이 안전한 행동이고 무엇이 그 실행 취소(undo)인가"를 지속 가능한 핵심 (durable core)으로 취급하고, 그 아래의 모델은 교체 가능한 (swappable) 것으로 취급한 정확한 이유입니다. 왜냐하면 모델은 곧, 그리고 반복적으로 교체될 것이기 때문입니다.

그래서 실제로 무엇을 해야 하는가

"미래를 기다리는 것"이 아닙니다. 그렇게 하면 결국 2년 뒤처지게 됩니다. 지금 당장 오늘의 원시적인 (primitive) 에이전트를 실행하십시오. 왜냐하면 운영 근육 (operational muscle) — 즉, 무엇을 위임할지, 경계선이 어디인지, 계획을 어떻게 검토할지 — 이 복리로 쌓이는 요소이기 때문입니다. 하지만 이를 얇게 (thin) 구축하십시오. 플랫폼의 기본 요소 (primitives)가 출시되는 즉시 그것에 의존하고, 당신의 코드는 정책 레이어 (policy layer)에만 머물게 하며, 당신이 작성하는 모든 스캐폴딩 (scaffolding)은 6개월의 유효 기간을 가진다고 가정하십시오.

제가 오늘 실행하고 있는 에이전트는 진정으로 유용하면서도 동시에 진정으로 원시적입니다. 올가을이 되면 부끄러운 수준이 될 것입니다. 그리고 이미 릴리스 노트 (release notes)를 통해 어느 부분이 그렇게 될지 확인했습니다. 저는 기억 상실증에 걸린 에이전트에 6개의 도구를 직접 배선(hand-wiring)하고 있는 것보다, 에이전트가 얼마나 발전했는지에 대해 부끄러움을 느끼는 쪽을 택하겠습니다.

이 네 가지 축(axes) 중 무엇이 실제로 가장 먼저 도달할 것이라고 생각하시나요 — 메모리(memory), 표준화된 도구(standardized tools), 컨텍스트(context), 아니면 거버넌스(governance)일까요? 저는 그 순서에 대해 계속해서 의견이 갈리곤 하는데, 귀하의 팀이 무엇을 가장 먼저 체감할지는 전적으로 귀하가 어떤 클라우드(cloud)를 가장 깊게 사용하고 있는지에 달려 있다고 생각합니다.