클라우드플레어가 'AI 에이전트의 운영체제'를 선언했습니다 — 그런데 같은 날 Deno는 정반대 답을 내놨습니다

클라우드플레어가 자사 플랫폼을 “AI 에이전트를 위한 오픈 운영체제"라고 부르기 시작했습니다. 마케팅 문구 하나 바뀐 것처럼 보이지만, 인프라 업계에서 ‘운영체제’라는 말은 그렇게 가볍게 쓰이지 않습니다. 그 자리를 차지한 회사가 그 위에서 돌아가는 모든 것의 규칙을 정하니까요. 공교롭게도 비슷한 시점에 Deno는 자체 호스팅 가능한 에이전트 런타임을 들고 나왔습니다. 두 선택지가 나란히 놓인 김에, 에이전트 인프라가 어디로 가고 있는지 한번 짚어보겠습니다.

솔직히 말씀드리면, 이 주제로 커뮤니티 반응을 훑어봤는데 최근 30일 안에 의미 있는 토론이 거의 잡히지 않았습니다. 개발자 커뮤니티가 아직 이 변화를 본격적으로 소화하지 못했다는 뜻이겠죠. 그래서 오늘은 여론 정리 대신 구조를 뜯어보는 쪽으로 갑니다.

왜 하필 ‘운영체제’라는 단어인가

운영체제가 하는 일을 한 줄로 줄이면 이렇습니다. 프로그램이 돌아갈 공간을 주고, 상태를 기억해주고, 다른 프로그램과 안전하게 대화하게 해주는 것.

에이전트도 똑같은 게 필요합니다. 코드가 실행될 장소, 대화 맥락과 작업 진행 상황을 붙잡아둘 메모리, 외부 도구를 호출할 통로, 그리고 며칠씩 걸리는 작업을 중간에 끊기지 않게 이어가는 스케줄러. 지금까지 이걸 만들려면 컨테이너 오케스트레이션에 큐, 데이터베이스, 워크플로 엔진을 각각 붙여야 했습니다.

클라우드플레어의 주장은 이겁니다. 그거 전부 우리가 이미 갖고 있다. 엣지 로케이션 수백 곳, 밀리초 단위로 뜨는 Workers 런타임, 그리고 결정적으로 Durable Objects가 있다는 거죠.

Durable Objects가 진짜 핵심인 이유

Durable Objects는 클라우드플레어가 수년간 밀어온 기술인데, 에이전트를 만나면서 갑자기 존재 이유가 선명해졌습니다.

일반적인 서버리스 함수는 기억을 못 합니다. 요청 하나 처리하고 사라지죠. 그래서 상태는 항상 바깥의 데이터베이스에 맡겨야 했습니다. Durable Objects는 반대입니다. 이름표를 붙인 객체 하나가 전 세계에서 딱 하나만 존재하고, 그 객체가 자기 상태를 직접 들고 있습니다. 요청이 어디서 오든 그 객체 하나로 모입니다.

에이전트 하나에 Durable Object 하나. 이 매핑이 이상하리만치 잘 맞습니다. 에이전트의 대화 기록, 진행 중인 작업, 도구 호출 상태가 전부 그 객체 안에 있고, 동시성 문제도 알아서 정리됩니다. 두 사용자가 같은 에이전트를 동시에 건드려도 경쟁 상태를 걱정할 필요가 없습니다. 한참 멈춰 있던 에이전트가 깨어나 하던 일을 이어가는 것도 자연스럽습니다.

직접 만들어보면 압니다. 이걸 손으로 구현하려면 정말 성가십니다.

편해질수록 나가기 어려워집니다

문제는 여기서 시작됩니다. Durable Objects는 이식 불가능한 원시 요소입니다.

Postgres를 쓰다가 다른 곳으로 옮기는 건 귀찮지만 가능합니다. S3 API도 호환 구현체가 널려 있죠. 그런데 Durable Objects에 대응하는 게 다른 클라우드에는 없습니다. AWS에도 GCP에도 없고, 직접 만들 수도 없습니다. 클라우드플레어의 글로벌 네트워크가 라우팅과 유일성 보장을 해주기 때문에 성립하는 물건이라서요.

에이전트 로직 전체를 Durable Objects 위에 올렸다면, 그건 애플리케이션 코드가 아니라 클라우드플레어 종속 코드입니다. 나중에 옮기려면 마이그레이션이 아니라 처음부터 다시 짜야 합니다.

여기에 스토리지, 캐시, 벡터 DB, 게이트웨이가 하나씩 얹히면 어떻게 될까요. ‘운영체제’라는 표현이 정확해집니다. 윈도우용으로 짠 프로그램이 리눅스에서 안 돌아가는 것과 같은 종류의 종속입니다. 다만 이번엔 그 운영체제를 한 회사가 소유하고, 가격도 그 회사가 정합니다.

Deno의 대답: 그냥 내 서버에서 돌리면 안 되나

Deno가 내놓은 답은 정확히 반대 방향입니다. 자체 호스팅 가능한 에이전트 런타임. 상태 지속성과 격리된 실행 환경 같은 핵심 기능은 제공하되, 그걸 내 인프라 위에서 돌리게 하겠다는 겁니다.

트레이드오프는 뻔합니다. 엣지 300곳에 자동 배포되지 않습니다. 무한 확장도 공짜가 아니고, 운영 부담은 온전히 내 몫이죠. 클라우드플레어가 몇 년간 다듬어온 걸 직접 감당해야 합니다.

대신 얻는 게 있습니다. 코드가 어디서 돌아갈지, 데이터가 어느 관할권에 머무를지 내가 정합니다. 가격 정책이 바뀌어도 나갈 문은 열려 있고요. 규제 산업이나 자체 데이터센터를 굴리는 조직이라면 협상거리가 아니라 그냥 필수 조건입니다.

같은 시기에 정반대 제품이 나왔다는 사실 자체가 신호입니다. 시장이 한 방향으로만 가는 게 아니라는 뜻이니까요.

그래서 무엇을 골라야 하나

정답은 없습니다. 대신 기준은 세울 수 있습니다.

프로토타입을 빠르게 검증하거나 스타트업이 초기 제품을 내놓는 단계라면 클라우드플레어가 합리적입니다. 인프라 고민을 몇 주 절약해서 제품에 쓰는 게 이 시점에는 명백히 이득입니다. 락인은 나중에 걱정할 문제고, 애초에 살아남아야 걱정할 자격이 생깁니다.

반대로 에이전트가 회사의 핵심 제품이고 몇 년 단위로 굴러갈 거라면 계산이 달라집니다. 상태 관리 계층을 얇은 인터페이스로 감싸두는 정도의 방어는 해둘 만합니다. 완벽한 추상화는 어차피 불가능하지만, 나중에 바꿔야 할 파일이 300개냐 30개냐의 차이는 큽니다.

의료, 금융, 공공처럼 데이터 위치가 법으로 묶인 영역이라면 선택지가 사실상 정해져 있습니다.

반복되는 패턴입니다

새로운 컴퓨팅 계층이 등장할 때마다 같은 일이 벌어졌습니다. 처음엔 여러 회사가 조각을 하나씩 만듭니다. 그다음 누군가 그 조각을 묶어 ‘플랫폼’이라 부릅니다. 그 위에서 개발이 쉬워지고, 다들 올라탑니다. 그리고 몇 년 뒤 사람들은 자기가 그 플랫폼 없이는 아무것도 못 한다는 걸 깨닫습니다.

클라우드나 모바일 앱스토어에서 이미 본 장면입니다. 에이전트 인프라는 지금 두 번째 단계에 막 들어섰습니다.

이번에 좀 다른 건, 대안이 같은 타이밍에 나왔다는 점입니다. 클라우드 초기에는 자체 호스팅 대안이 한참 뒤에야 등장했고, 그땐 이미 늦었죠. 이번에는 선택할 여지가 있는 상태에서 시작합니다.

편리함에는 가격표가 붙어 있습니다. 지금 안 보인다고 나중에 청구서가 안 오는 건 아니고요. 저도 아직 어느 쪽이라고 딱 잘라 말하진 못하겠습니다. 다만 지금 고르는 쪽이 3년 뒤에도 견딜 만한지는 한 번쯤 따져보고 넘어가는 게 낫습니다.