2026년 4월, Anthropic은 Claude Managed Agents를 퍼블릭 베타(public beta)로 출시했습니다. 3주 후 Google I/O에서 Google은 Project Antigravity라는 개발자 스위트(developer suite)로 감싸진 Gemini API 내부의 Managed Agents를 출시했습니다. 만약 여러분이 바이브 코딩(vibe-coding)이 어디로 향하고 있는지(데모를 넘어 프로덕션 단계로) 추적해 왔다면, 이것이 바로 여러분이 기다리던 신호입니다. 두 키노트(keynote)는 서로 다른 단어를 사용했습니다. 두 가격 페이지는 서로 관련이 없어 보입니다. 언론은 이를 경쟁하는 비전으로 다루었습니다. 하지만 이것은 경쟁하는 비전이 아닙니다. 동일한 아키텍처(architecture)이며, 컨테이너 위에 로고만 두 개가 붙어 있을 뿐입니다. 저는 며칠 동안 두 문서 세트를 나란히 놓고 읽었습니다. 수렴(convergence)의 수준이 너무나 노골적이어서 우연이나 단순한 호기심으로 치부하기 어렵습니다. 이는 2026년 AI 인프라에서 실제 가치 포착(value capture)이 실제로 어디에 이루어지고 있는지에 대한 직접적인 신호입니다. 두 문서 세트를 읽으며 저를 놀라게 한 점은, 두 팀 모두 자신들이 무엇을 하고 있는지 정확히 알고 있다는 것입니다. 그들은 우연히 수렴한 것이 아닙니다. 그들은 동일한 문제를 동일한 방식으로 해결했는데, 왜냐하면 실제로 작동하는 방법은 단 한 가지뿐이기 때문입니다. 그리고 그 방법은 모델(model)이 아닙니다. 바로 런타임(runtime)입니다. 요약하자면(TLDR): Anthropic과 Google은 2주 간격으로 관리형 에이전트 플랫폼(managed agent platforms)을 출시했습니다. 브랜딩을 걷어내면 동일한 1개의 아키텍처가 나타납니다: 동일한 샌드박스(sandbox), 동일한 MCP 와이어(MCP wire), 동일한 3축 과금 측정기(3-axis billing meter). 어떤 부분이 여러분을 더 걱정하게 만들지 모르겠습니다: 이것이 얼마나 명백하게 동일한지, 아니면 그 동일함이 실제로 무엇을 점유하도록 설계되었는지 말입니다. 두 키노트 뒤에 숨겨진 다이어그램(Diagram). 두 제품 모두 동일한 물리적 분리를 구현합니다: 모델 "두뇌(brain)"는 벤더의 클라우드에서 실행됩니다. 도구 실행 "손(hands)"은 벤더가 소유한 일시적인(ephemeral) Linux 샌드박스에서 실행됩니다. 지속적인 세션(persistent session)이 이 둘을 몇 시간, 며칠, 또는 몇 주 동안 연결합니다. Anthropic은 이를 "두뇌와 손의 분리(separation of brain and hands)"라고 부릅니다. Google은 굳이 이름을 붙이지 않습니다. 그것은 단지 Managed Agents API가 작동하는 방식일 뿐입니다. 표현은 다르지만, 다이어그램은 동일합니다. 두 시스템 모두에서, 여러분은 에이전트를 프로비저닝(provision)하기 위해 단 한 번의 API 호출을 수행합니다. 그러면 벤더는 자체 데이터 센터에 격리된 Linux 컨테이너를 생성합니다. 모델은 무엇을 할지 결정합니다.

모델이 셸 명령(shell commands)을 실행하거나, 파일을 편집하거나, 웹을 탐색하거나, 외부 서비스(external service)를 호출하고자 할 때, 이러한 동작들은 해당 컨테이너 내부에서 실행됩니다 (사용자의 서버가 아니라, 사용자가 유지 관리하는 Docker 이미지도 아니며, 사용자가 프로비저닝한 Lambda도 아닙니다). 벤더의 컨테이너, 벤더의 네트워크에서 실행되며, 벤더의 감사 로그(audit logs)에 기록됩니다. 사용자는 모델의 추론(reasoning), 도구 호출(tool calls), 출력값(outputs)과 같은 이벤트 스트림을 돌려받습니다. 사용자는 기계에 절대 직접 접근할 수 없습니다. 접근할 수도 없습니다. 그것이 바로 이 제품의 핵심입니다. '바이브 코딩(vibe-coding)'에서 '프로덕션(production)' 단계로 넘어가는 과정을 경험해 본 사람이라면, 이것이 이미 수동으로 내리고 있었던 바로 그 인프라 결정이라는 점을 인지할 것입니다. 'Vibe Coding, For Real'은 제가 정확히 이러한 트레이드오프(tradeoff), 즉 "런타임(runtime)의 소유권이 누구에게 있는가"가 더 이상 이론적인 문제가 아니게 되는 지점에 몰입하게 된 계기였습니다. 5 Pieces Nobody Renamed Anthropic vs Google: Identical Agent Architecture Components. 일단 '두뇌와 손(brain-and-hands)'이라는 프레임을 받아들이고 나면, 나머지 유사성들은 자연스럽게 드러납니다. 두 플랫폼 모두 5가지 구성 요소를 제공하며, 그 명칭들은 서로 거의 숨기지 않은 번역 수준으로 유사합니다. 휘발성 샌드박스(Ephemeral sandbox). Anthropic은 세션당 새로운 Linux 컨테이너를 프로비저닝하고, 파일을 /workspace에 마운트하며, bash, 파일 작업, 웹 브라우징을 네이티브 도구로 노출합니다. Google도 동일하게 수행합니다: Linux 샌드박스, code_execution 도구, google_search 도구, url_context 도구를 제공합니다. 두 플랫폼 모두 기본적으로 모든 네트워킹을 거부(deny-all)하도록 설정되어 있습니다. 또한 두 플랫폼 모두 시작 시 클라우드 스토리지에서 파일을 마운트하거나 Git 리포지토리(repo)를 클론(clone)할 수 있게 해줍니다. 체크포인팅(checkpointing)을 포함한 상태 유지 세션(Stateful sessions). Anthropic은 연결이 끊겨도 컨테이너의 파일 시스템, 설치된 패키지, 대화 기록을 보존하며, 30일 동안 활동이 없을 때까지 체크포인트를 유지합니다. Google도 Interactions API를 통해 동일하게 수행합니다: previous_interaction_id를 전달하면 서버가 이전의 전체 컨텍스트(context)를 재구성합니다. 두 플랫폼 모두 이를 "상태 유지(stateful)" 실행이라고 부릅니다. 두 플랫폼 모두 에이전트 기본 단위(agentic primitive)로서 기존의 상태 비저장(stateless) API를 버렸습니다. 와이어 프로토콜(wire protocol): MCP.

두 제품 모두 에이전트가 외부 시스템과 통신하는 방법으로 Model Context Protocol (Anthropic이 2024년 말 오픈 소스로 공개한 표준)로 수렴했습니다. 두 제품 모두 자격 증명(credentials)을 위한 Vault를 노출하므로, API 키가 에이전트 프롬프트나 코드에 절대 나타나지 않습니다. 두 제품 모두 네트워크 송신 경계(network egress boundary)에서 자격 증명을 주입합니다. Google은 2026년 5월에 아웃바운드 전용 프라이빗 네트워크 액세스를 위한 "MCP Tunnels"를 추가했습니다. Anthropic은 같은 달에 동일한 이름으로 동일한 기능을 출시했습니다. 만약 특정 워크로드에서 왜 여전히 CLI가 관리형 MCP보다 앞서 있는지 고민해 왔다면, 이러한 수렴은 그 계산 방식을 직접적으로 변화시킵니다. 오케스트레이션 레이어(orchestration layer). 멀티 에이전트 오케스트레이션(Multi-agent orchestration)은 두 생태계 모두에서 거의 정확히 같은 시기에 "덧붙이는 제3자 프레임워크"에서 "네이티브 API 기능"으로 이동했습니다. Anthropic의 버전은 lead_agent가 서브 에이전트(sub-agents) 목록을 선언하고 이들의 병렬 출력을 합성하는 방식입니다. Google의 버전은 Antigravity의 Shared Agent Harness가 단일 프로젝트로부터 병렬 서브 에이전트를 인스턴스화하는 방식입니다. 두 제품 모두 LangGraph, CrewAI, LlamaIndex의 존재 이유를 잠식하고 있습니다. 평가(Evaluator) 및 메모리 레이어. Anthropic은 "Outcomes"를 출시했습니다. 이는 루브릭(rubric)에 따라 에이전트 출력을 점수화하고 통과할 때까지 루프를 도는 두 번째 LLM입니다. Google은 본질적으로 동일한 역할을 수행하는 라이프사이클 훅(lifecycle hooks: post_tool_call, post_turn)을 출시했는데, 이는 확률적 루프(probabilistic loop) 내부의 결정론적 체크포인트(deterministic checkpoints) 역할을 합니다. Anthropic은 세션 간 장기 메모리 통합을 위한 "Dreaming"을 출시했습니다. Google은 "핵심 상태 변수(critical state variables)"를 유지하면서 약 135K 토큰에서 자동 컨텍스트 압축(automatic context compaction)을 제공합니다. 메커니즘은 다르지만 목적은 같습니다. 에이전트가 스스로를 잊어버리거나 확신을 가지고 쓰레기(garbage)를 제출하는 것을 방지하는 것입니다. (참고로, 평가 루프에서는 Opus가 Sonnet보다 눈에 띄게 성능이 좋습니다. 티어를 결정하기 전에 모델 라우팅(model routing)에 이 점을 고려하십시오.) 3축 과금 함정(The 3-Axis Billing Trap). 대부분의 빌더들은 샌드박스 문서로 바로 건너뜁니다. 아키텍처가 본모습을 드러내는 곳은 바로 과금 페이지입니다.

이전에는: 두 플랫폼 모두 단순한 백만 토큰당 가격 책정 방식을 사용했습니다. 냅킨 위에서도 월간 청구액을 추산할 수 있을 정도였습니다. 여러분의 FinOps 팀도 비교적 안심할 수 있었습니다. 이후에는: 두 회사 모두 정확히 같은 시점에 토큰 전용 과금 방식을 버렸으며, 이를 세 가지 동시 미터링 (metering) 방식으로 대체했습니다: 1. 소비된 토큰 (입력 및 출력, 반복되는 컨텍스트에 대한 공격적인 캐시 할인 적용) 2. 활성 런타임 초 (Active runtime seconds): Anthropic은 상태가 'running'인 컨테이너 시간당 약 0.08달러를 청구합니다. Google은 Vertex/AI Studio를 통해 본질적으로 동일한 방식으로 컨테이너 시간을 청구하며, 사용자 입력을 기다리는 유휴 상태(idle) 동안에는 미터링이 일시 중지됩니다. 3. 특정 도구 호출 (Specific tool calls): 웹 검색은 다른 모든 비용 외에 쿼리당 1센트 미만의 비용으로 청구됩니다. 두 시스템 모두 유휴 시간은 무료입니다. 사람의 확인을 기다리는 시간도 무료입니다. 시계는 에이전트가 활발하게 추론하거나 실행할 때만 돌아갑니다. 이는 기존의 컨테이너 시간 모델보다 의미 있는 개선입니다.

수치를 계산해 보면 두 가격 페이지 모두에서 나타나는 기묘한 2차 효과가 있습니다: 더 저렴한 모델이 더 많은 비용을 발생시킬 수 있다는 점입니다. Opus나 Pro가 1회 만에 해결할 문제를 해결하기 위해 5번의 반복 (iteration)이 필요한 Haiku나 Flash 에이전트는 결국 5배의 런타임 초, 5배의 도구 호출, 그리고 토큰 절감액의 상당 부분을 소모하게 됩니다. 이제 최적화 문제는 더 이상 "가장 저렴한 모델을 선택하라"가 아닙니다. "런타임 미터가 절감액을 잡아먹지 않을 정도로 작업당 실패율이 낮은 모델을 찾아라"가 되었습니다. 두 벤더 모두 여러분의 워크로드에 어떤 모델이 적합한지 알려주는 대시보드를 제공하지 않습니다. 청구서를 받고 나서야 알게 될 것입니다. 😅

실제로 갈라지는 지점: 3가지 실질적인 차이점. 이것들이 여러분의 선택에 영향을 미쳐야 하는 요소들입니다.

컴플라이언스 태세 (Compliance posture). Anthropic의 Managed Agents는 현재 형태로는 데이터 제로 보존 (Zero Data Retention) 또는 HIPAA BAA 적용 대상이 아닙니다. 지속적인 체크포인트 (checkpoint)가 어딘가에는 존재해야 하며, 그 장소가 바로 Anthropic의 스토리지이기 때문입니다.

Google의 제품은 Vertex AI의 기존 컴플라이언스 엔벨로프 (compliance envelope)를 통해 경로를 제공하며, 이는 GCP (Google Cloud Platform)의 엔터프라이즈 실적 덕분에 범위가 더 넓습니다. 만약 귀하가 의료, 국방, 또는 규제 대상 금융 분야에 종사한다면, 이번 분기에 가장 중요한 것은 바로 이 격차입니다. 바로 셀프 호스팅 (self-hosted) 탈출구입니다. Anthropic은 컴플라이언스 문제를 인식하고 2026년 5월에 셀프 호스팅 샌드박스 (self-hosted sandboxes)를 출시했습니다. 즉, 두뇌는 그들의 클라우드에 머물되, Cloudflare, Modal, Vercel, Daytona와 같은 파트너를 통해 손은 귀하의 인프라로 이동하는 방식입니다. Google은 이에 상응하는 제품을 출시하지 않았습니다. 실행을 귀하의 네트워크 경계 내에 유지하는 것이 타협 불가능한 조건이라면, 현재는 Anthropic이 승리하고 있습니다. 개발자 접점 (developer surface) 측면을 보겠습니다. Google은 데스크톱 앱 (Antigravity 2.0), agy CLI, 그리고 Python SDK를 양방향 동기화가 가능한 단일 생태계로 묶었습니다. 반면 Anthropic은 API를 출시하고 생태계가 접점을 구축하도록 내버려 둡니다. 이것이 기능인지 버그인지는 귀하가 정제된 벤더 소유의 IDE를 원하는지, 아니면 자체 도구로 감싸서 사용할 유연한 API를 원하는지에 따라 전적으로 달라집니다. 그 외의 모든 것들: 샌드박스 모델 (sandbox model), 빌링 축 (billing axes), MCP, 멀티 에이전트 (multi-agent), 평가 (evals), 메모리 (memory), 볼트 (vault), 체크포인트 (checkpoints). 동일한 제품입니다. 왜 이들이 수렴했는가: 이것은 우연이 아닙니다. 이는 문제의 자연스러운 형태이며, 그 형태를 이해하는 것이 귀하를 덜 순진한 구매자로 만듭니다. 만약 귀하가 2026년의 파운데이션 모델 (foundation-model) 벤더라면, 모델 자체는 스택에서 가장 쉽게 범용화 (commoditized)되는 레이어입니다. 고객들은 저렴한 작업에는 Haiku를, 중간 작업에는 Sonnet을, 어려운 작업에는 Opus를, 멀티모달 (multimodal)에는 Gemini를, 그리고 남은 것은 무엇이든 GPT를 사용하도록 경로를 지정합니다. 그들은 분기별로 벤치마크를 수행하고 매달 경로를 바꿉니다. 모델은 빌려 쓰는 것입니다. 런타임 (runtime)은 모든 도구 호출 (tool call)과 체크포인트와 함께 락인 (lock-in)을 축적합니다. 따라서 두 벤더 모두 당연한 선택을 했으며, 동일한 아키텍처적 해답을 가지고 동시에 런타임을 향해 손을 뻗었습니다. 왜냐하면 실제로 작동하는 아키텍처적 해답은 단 하나뿐이기 때문입니다. 사실, 다르게 표현해 보겠습니다. 런타임 역학 (runtime dynamic)은 빌더들이 가장 느리게 내재화하는 요소이며, 잠시 시간을 내어 깊이 생각해 볼 가치가 있습니다.

고객이 자신의 MCP 서버를 귀사의 Vault에 연결하고, 자격 증명(credentials)을 키 관리 시스템(key management system)에 저장하며, 귀사의 샌드박스 시맨틱스(sandbox semantics)에 맞춰 에이전트 프롬프트(agent prompts)를 작성하고, 귀사의 이벤트 스키마(event schema)에 따라 감사 파이프라인(audit pipeline)을 설정한 뒤, 귀사의 스토리지 계층(storage layer)에 30일간의 체크포인트 상태(checkpoint state)를 축적하고 나면, 벤더를 교체하는 일은 더 이상 오후 한때의 설정 변경 작업이 아니라 클라우드 마이그레이션(cloud migration)처럼 보이게 됩니다. 즉, 수개월이 걸리는 프로젝트, 부서 간 승인, CFO의 개입 등 모든 복잡한 과정이 수반됩니다. 이 과정에서 발생하는 부수적인 피해는 제3자 오케스트레이션(orchestration) 생태계입니다. LangChain, LangGraph, LlamaIndex, CrewAI와 같은 프레임워크들은 상태가 없는(stateless) 모델 API와 사용자가 직접 프로비저닝한 상태가 있는(stateful) 실행 환경을 결합하기 위해 존재했습니다. 하지만 두 벤더 모두 이 두 부분을 흡수해 버렸습니다. 이제 접착제 계층(glue layer)에는 붙일 것이 아무것도 남지 않았습니다. 지난 6개월 동안 두 생태계 모두를 다뤄본 결과, 두 회사 모두 스택의 더 많은 부분을 흡수하기 위해 조용히 API를 확장해 나가는 패턴이 이미 관찰되었습니다. 관리형 런타임(managed runtime) 발표는 놀라운 사건이라기보다 이미 진행 중이던 일의 공식화에 가까웠습니다. 출시 사이의 2주 간격은 출시 일정상의 우연이었을 뿐입니다. 근본적인 결정은 두 팀 모두가 아마도 독립적으로, 동일한 화이트보드 문제를 응시한 끝에 몇 달 전에 이미 내린 것이었습니다. (에이전트와는 상관없는 짧은 여담을 하자면: 제 아파트 근처의 빵집은 3년 동안 주인이 두 번 바뀌었습니다. 새로운 주인들은 각자 독립적으로 똑같은 에스프레소 머신과 똑같은 크로와상 레시피를 들여왔습니다. 그들은 서로 대화한 적이 없었습니다. 때로는 단 하나의 정답만이 존재하며, 수렴(convergence)이란 두 개의 별개 팀이 그 정답을 찾아냈을 때 나타나는 현상일 뿐입니다.)

확정하기 전에 해야 할 4가지 사항

1. 에이전트 런타임을 그 본질 그대로 마이그레이션 리스크(migration risk)로 취급하십시오.
2. 프롬프트, 도구(tools), MCP 서버가 이식 가능(portable)하도록 설계하십시오. 상대측에 대응되는 기능이 없는 벤더 전용 이벤트 유형이나 오케스트레이션 프리미티브(orchestration primitives)를 사용하는 순간, 탈출 비용(exit cost)은 두 배로 뜁니다.
3. 중요한 상태(state)의 유일한 복사본을 벤더의 체크포인트 내부에만 두지 마십시오.

당신이 실제로 중요하게 생각하는 것들(출력값(outputs), 감사 추적(audit trails), 중간 산출물(intermediate artifacts))은 당신이 제어할 수 있는 저장소에 영구적으로 보관하십시오. 벤더의 세션 상태(session state)는 신뢰할 수 있는 원천(source of truth)이 아닌 캐시(cache)로 취급하십시오. 토큰(token) 단위가 아닌 작업(task)당 실행 비용(runtime cost)을 측정하십시오. 3축 과금 방식(3-axis billing) 때문에 토큰 비용은 청구서에서 가장 정보 가치가 낮은 숫자가 됩니다. 모든 에이전트 실행(agent run)에 작업 유형(task type)과 모델 선택(model choice) 태그를 지정한 다음, 토큰 열(column)보다는 실행 시간(runtime-seconds)과 도구 호출(tool-call) 열을 더 주의 깊게 살펴보십시오. 더 나은 데모를 보여주는 쪽이 아니라, 지금 당신에게 필요한 컴플라이언스 태세(compliance posture)를 갖춘 쪽을 선택하십시오. 데모는 서로 대체 가능하지만, 컴플라이언스 문서(compliance docs)는 그렇지 않습니다. 만약 관리형 런타임(managed runtime)을 도입하기 전에 에이전트 프롬프트(agent prompts)를 어떻게 구조화할지 여전히 고민 중이라면, 제가 만든 프롬프트 계약 프레임워크(prompt contracts framework)를 먼저 읽어볼 가치가 있습니다. 프롬프트 아키텍처(prompt architecture)에 대해 구조화된 접근 방식을 가지고 시작하면 평가(evaluation)가 더 깔끔해집니다. 즉, 당신이 무엇을 넘겨주고 있는지 정확히 알게 될 것입니다.