2024년 초, 독립 컨설턴트로 일하는 한 콘텐츠 PM이 고객 리포트 자동화 파이프라인을 다른 플랫폼으로 이전하려 했습니다. 파이프라인 자체는 단순했습니다. 고객사 데이터를 끌어와 요약하고, 주간 보고서를 만들어 발송하는 흐름이었습니다. 그런데 이전 견적을 내보려고 코드를 들여다보니, 실행 환경의 API 방식과 상태 저장 구조가 특정 플랫폼에 깊이 맞춰져 있었습니다. "처음부터 다시 짜야 한다"는 결론이 나왔고, 그는 이전을 포기했습니다. 기능도 가격도 그대로였습니다. 그냥 이미 올라가 있었습니다.

이 장면은 Cloudflare가 2025년 여름 내놓은 공식 발표를 이해하는 출발점이 됩니다. 이 회사는 자신을 "에이전트·앱·업무 전체를 위한 운영체제"로 공식 정의했습니다. 기술 커뮤니티 Hacker News에서 400점 이상의 반응이 달린 이 발표는, 한 회사가 스스로를 인프라에서 운영체제로 격상시키는 선언이었습니다.

배관 회사가 지반이 되기까지

Cloudflare는 오랫동안 인터넷의 배관 역할을 맡았습니다. 전 세계 수백만 사이트의 트래픽을 걸러주고, 악성 요청을 막고, 콘텐츠를 지리적으로 가까운 서버에서 빠르게 내보내는 일을 했습니다. 이상적인 배관은 사용자가 그 존재를 의식하지 못할 때 가장 잘 작동합니다. Cloudflare가 가진 경쟁력의 배경에는 그 회사가 '눈에 보이지 않는다'는 사실이 있었습니다.

그런데 지난 몇 년 사이, 이 회사는 다른 종류의 층을 조용히 쌓았습니다.

2017년에 서버 없이 코드를 실행하는 환경인 Workers를 내놓았습니다. 개발자가 Cloudflare의 엣지 서버 네트워크 위에서 직접 코드를 돌릴 수 있게 됩니다. 2022년에는 S3 규격과 호환되는 객체 스토리지 R2가 나왔습니다. AWS S3에 비해 데이터 전송 비용이 낮다는 이유로 이미 상당수 개발자가 채택했습니다. Durable Objects는 분산된 엣지 환경에서 상태를 일관되게 유지할 수 있게 해주는 구조입니다. 에이전트처럼 대화 맥락이나 작업 진행 정보를 기억해야 하는 경우에 필요한 레이어입니다. 여기에 AI 모델 추론을 엣지에서 직접 처리하는 Workers AI, 키-값 쌍을 저장하는 KV까지 더해졌습니다.

각각의 출시는 독립적인 기능 추가처럼 보였습니다. 이번 발표는 이것들이 분리된 도구가 아니라 하나의 통합된 실행 환경 — 에이전트와 앱과 업무 흐름 전체가 그 위에서 돌아가는 단일 기반 — 을 이룬다고 정식으로 선언합니다. 배관이 지반이 된 것입니다.

운영체제라는 비유는 기술적 설명보다 전략적 포지셔닝에 가깝습니다. OS는 응용 프로그램이 그 위에서 돌아가는 아래층입니다. macOS를 Linux로 바꾸기 어려운 이유는 기능이 부족해서가 아닙니다. 그 위에 쌓인 소프트웨어, 설정, 작업 방식이 하나의 생태계를 이루기 때문입니다. OS를 교체하는 것은 그 생태계 전체를 재조립하는 일입니다. Cloudflare가 이 비유를 선택했다는 것은, 에이전트와 업무의 아래층이 되겠다는 방향을 공식화한 표현입니다.

에이전트가 만드는 다른 의존 구조

기존 SaaS 도구를 옮기는 것과 에이전트 인프라를 옮기는 것은 다른 종류의 일입니다.

Notion을 다른 도구로 이전할 때는 데이터를 마크다운으로 내보내고 새 앱에 가져오면 됩니다. 인터페이스를 다시 익히는 수고가 있지만, 축적한 정보는 이식됩니다. 이 이전에서 가장 큰 비용은 '학습'입니다.

에이전트는 다릅니다. 에이전트는 실행 환경의 구조 안에 박혀 작동합니다. Workers 위에서 돌아가는 에이전트는 Workers의 요청-응답 처리 모델을 전제로 작성됩니다. Durable Objects로 상태를 관리하는 에이전트는 그 API 방식으로 상태 로직 전체가 짜여 있습니다. R2에 중간 산출물을 저장하는 에이전트는 R2의 접근 방식을 따릅니다. 이 에이전트들을 다른 플랫폼으로 이전한다는 것은 각 계층을 하나씩 교체해야 한다는 뜻입니다. 데이터를 옮기는 게 아니라, 에이전트를 다시 씁니다.

더 들여다보면, 이 의존은 보이지 않아서 쌓이는 속도가 빠릅니다. 에이전트 하나가 파이프라인 하나를 자동화합니다. 그 파이프라인이 다른 파이프라인과 연결됩니다. 6개월 뒤에는 고객 응대 초안 생성, 보고서 요약, 일정 알림이 모두 같은 실행 환경 위에 올라가 있습니다. 이 시점에서 플랫폼을 바꾸는 것은 도구 하나를 교체하는 일이 아니라, 업무 방식 자체를 재설계하는 일과 같아집니다.

자동화가 운영 작업의 더 많은 부분을 맡게 될수록, 인간에게 남는 판단 중 하나는 그 자동화가 어떤 기반 위에서 돌아가는가를 평가하는 일입니다. 어느 플랫폼 위에 올라갈 것인지, 그 플랫폼이 방향을 틀었을 때 어떻게 대응할 것인지를 결정하는 역할은 에이전트가 대신할 수 없습니다. 그 판단을 하려면, 먼저 지금 어디 위에 서 있는지를 알아야 합니다.

이식 비용을 미리 추정하는 법

"지금 얼마나 얽혀 있나"를 확인하는 가장 실용적인 방법은 이식 비용을 한 번 직접 추정해 보는 것입니다. 현재 돌아가는 에이전트 파이프라인을 다른 인프라로 이전하는 데 실제로 얼마의 시간이 걸리는가를 계산해 보는 것입니다.

이 추정이 막막하게 느껴진다면, 이미 의존이 시작됐다는 신호입니다.

구체적으로 확인해야 할 항목들이 있습니다.

실행 환경 특수성: 에이전트 코드가 특정 플랫폼의 API 규약에 맞춰 작성됐는가, 아니면 HTTP나 OpenAPI처럼 이식 가능한 표준으로 추상화됐는가. 추상화 계층이 하나 있으면 이식 비용이 절반 이하로 줄어드는 경우가 많습니다. 반대로 플랫폼 고유의 객체나 메서드를 에이전트 핵심 로직에서 직접 호출하고 있다면, 이전은 처음부터 다시 쓰는 일과 같습니다.

상태 데이터의 위치와 형식: 에이전트가 처리 중에 쌓는 상태 — 대화 맥락, 작업 진행 정보, 중간 산출물 — 가 플랫폼 전용 구조에 저장되는가, 아니면 JSON이나 SQL처럼 이식 가능한 형식으로 뽑을 수 있는가. Durable Objects처럼 플랫폼 고유의 상태 모델은 그 형식 자체가 다른 환경에서 재현하기 어렵습니다. 상태가 외부로 뽑히지 않으면, 에이전트를 이전해도 그 에이전트가 기억하던 맥락은 이전되지 않습니다.

인증 레이어의 독립성: 접근 제어가 플랫폼 고유 방식으로 묶여 있는가, 아니면 독립적인 시스템으로 관리되는가. 인증이 플랫폼에 묶이면, 에이전트 로직을 옮겨도 인증 레이어를 별도로 다시 설계해야 합니다. 특히 여러 에이전트가 하나의 인증 체계를 공유하는 경우, 그 체계가 플랫폼 전용이면 이전 비용은 에이전트 수에 비례해 늘어납니다.

이 항목들 중 두 개 이상이 특정 플랫폼에 얽혀 있다면, 그 플랫폼은 이미 지반입니다.

그 환경 위에서 일하는 것 자체가 잘못은 아닙니다. Cloudflare Workers 위에서 에이전트를 돌리는 것은 분명히 이점이 있습니다. 글로벌 엣지 네트워크, 낮은 레이턴시, 스토리지와 AI 추론까지 하나의 환경에서 해결됩니다. 인프라를 직접 조립하는 수고를 크게 줄여줍니다. 그 편리함은 실재합니다. 다만 그 편리함이 의존으로 굳은 뒤에야 보인다는 점이 문제입니다. '지금 어디 위에 서 있나'를 아는 것과 모르는 것은, 선택지가 생겼을 때 전혀 다른 위치를 만들어 냅니다.

에이전트 인프라를 고를 때 달라져야 할 계산

기존 SaaS 도구를 선택할 때 기능과 가격이 주된 기준이라면, 에이전트 인프라를 선택할 때는 이탈 비용을 추가해야 합니다.

이탈 비용이란 해당 플랫폼의 가격이 오르거나, 서비스 약관이 변경되거나, 회사가 전략 방향을 바꿨을 때 빠져나오는 데 드는 시간·비용·위험의 합입니다. 현재 지출보다 미래 선택지의 폭이 더 큰 판단 기준입니다.

"무료 플랜이 있으니 일단 써보자"는 판단이 에이전트 인프라에서는 2년 후에 전혀 다른 무게를 갖습니다. Cloudflare가 운영체제를 자처하는 순간, 이 회사 위에서 에이전트를 돌리는 결정에는 이전보다 더 많은 것이 포함됩니다. 기능이 충분하고 가격이 합리적이더라도, 그 판단에는 "이 회사의 전략이 바뀌었을 때 나는 어떻게 되는가"가 들어가야 합니다.

이 계산을 도구 선택 단계에서 하는 것과, 에이전트가 이미 깊이 박힌 뒤에 하는 것은 들어가는 힘이 다릅니다. 빌드를 시작하기 전에 한 가지 질문을 해두면 됩니다. 6개월 후에 이 에이전트를 다른 곳으로 옮긴다면 얼마나 걸리는가. 그 답이 즉각 나오지 않는다면, 구조를 한 번 더 보고 짓는 편이 낫습니다.