서버리스 에이전트

에이전트를 만드는 것은 쉽지 않다.

1년 전만 해도 우리는 컨텍스트와 메모리를 직접 관리해야 했고, RAG와 벡터 데이터베이스를 고민해야 했으며, 도구 사용 정확도를 아주 세심하게 조정해야 했다. Claude Code / Claude Agent SDK의 등장이 이 모든 것을 바꿔놓았다. 이제 점점 더 많은 팀이 Claude Agent SDK + VM을 사용해 곧장 에이전트를 만들기 시작하고 있다. 그렇다면 문제가 더 단순해졌을까? 아니다.

VM에서 Claude Code를 실행하는 것은 여전히 매우 까다로운 일이다.

1. 모든 사용자 세션에는 독립된 VM이 필요하다. 어떤 시나리오에서는 VM의 영속성 능력이 유용할 수 있지만, 그것은 동시에 VM을 업그레이드하고 오케스트레이션하기 어렵게 만든다. 예를 들어 사용자 입장에서는 VM에 설치한 소프트웨어가 몇 달 뒤에도 여전히 쓸 수 있기를 바란다. 하지만 VM에서 오케스트레이션 계층과 통신하는 부분 역시 업그레이드를 롤아웃할 수 있어야 한다.

2. 대규모로 VM을 생성하고 오케스트레이션하는 것. 단일 k8s 클러스터는 수천 개 정도의 pod 오케스트레이션을 지원하는데, 이는 애플리케이션 서비스 클러스터에는 충분하다. 하지만 모든 세션마다 claude code pod를 띄워야 하는 시나리오에는 그다지 충분하지 않다.

3. k8s 솔루션을 쓰면 k8s가 가져오는 지연시간에 부딪혀 1초 이내의 성능을 달성하기 어렵다.

4. e2b 솔루션을 쓰면 영속성을 직접 해야 하고, 파일 업로드 / 다운로드가 둘 다 매우 느리다.

5. e2b 솔루션은 특정 네트워크 환경 요구사항을 충족할 수 없고, 사설 배포가 번거롭다.

이 문제들을 우리는 어떻게 푸는가? 역사에서 배워보자. 달력을 10여 년 전인 2012년으로 되돌려보면, 세상에는 서버리스도 없었고, k8s도 없었으며, docker도 없었다. 백엔드 엔지니어는 서비스를 돌리기 위해 물리 머신 위에서 서비스 프로세스를 손으로 유지해야 했다. 그 시절 ssh와 ansible은 서버 엔지니어의 표준 도구였다. 서비스 프로세스는 물리 머신 위의 온갖 도구 환경에 크게 의존했다. 물리 머신들 사이에서 일관된 도구 환경 구성을 달성하는 것은 매우 까다로웠고, 대규모 스케일링은 팀이 한참 미리 준비해야 하는 큰 작업이었다. 나는 아직도 기억한다. 한 엔지니어가 머신 하나의 환경을 바꾸고 다른 머신들의 환경에 동기화하는 것을 잊어버려, 프로덕션에서 추적하기 매우 어려운 유령 버그를 일으켰던 일을. 그 시기는 매우 고통스러운 옛 시절이었다.

2012년, docker가 나타났다. Docker는 모든 도구 환경을 하나의 이미지로 패키징해, 환경 불일치 문제를 풀었다. 커뮤니티는 물리 머신 위의 가상 머신에서 돌아가는 서비스 프로세스를 물리 머신 위의 프로세스처럼 관리할 수 있다는 것을 점차 깨달았다. 하지만 docker 오케스트레이션은 여전히 엔지니어링 팀이 오케스트레이션 시스템을 구축할 것을 요구했다. 그리고 docker 안의 서비스 프로세스가 물리 머신의 네트워크 및 파일 시스템과 결합되고 나면, 오케스트레이션은 매우 고통스러운 일이 되곤 했다.

2014년, 무상태(stateless) 서비스가 주류 흐름이 되기 시작했다. 그해에 Kubernetes와 AWS Lambda가 탄생했다. 둘은 각자 다른 각도에서 무상태 서비스의 미래를 그려냈다. 무상태 서비스란 서비스 로직이 네트워크 주소와 결합되는 것을 피하고, 더는 로컬에서 영속 파일 시스템에 의존하지 않는다는 것을 의미했다.

그 뒤로 클라우드 네이티브의 10년이 이어졌고, 무상태 서비스의 물결은 다음과 같은 방대한 클라우드 네이티브 인프라를 낳았다:

• 서비스 게이트웨이 Istio/Linkerd/Envoy/Treafik
• CI/CD 플랫폼 Argo CD / Flux
• 관측성 플랫폼 Prometheus/Grafana/ELK Stack
• 호출 체인 분석 Jaeger/Zipkin/OpenTelemetry
• 스토리지 Rook/MinIO/JuiceFS

그리고 우리는 지금 새로운 시작점에 서 있다. 10년 전, 컴퓨트 단위는 java/python api 서비스 프로세스였다. 올해부터 이 컴퓨트 단위는 코딩 에이전트가 되었다.

ACFS는 물리 머신 위에서 서비스 프로세스를 손으로 유지하던 시대와 같다. E2B는 Docker와 같다. 작업 오케스트레이션 플랫폼, 관측성 플랫폼, 분산 상태 영속 스토리지 능력이 없다면, 확장성은 코딩 에이전트에게 여전히 어려운 일이다. 그리고 내가 기대하는 Serverless Agent Infra는 다음과 같은 능력을 갖는다:

1. 코딩 에이전트의 세션과 작업 디렉터리를 컨텍스트를 잃지 않고 적절히 영속화할 수 있다.
2. 초고속이어서, 코딩 에이전트를 100ms 안에 일하게 만들 수 있다.
3. 사람이 이해하기 쉬운, 에이전트 행동에 대한 Logging / Metric / Tracing을 갖춰, 사람이 에이전트의 행동 패턴을 이해하고 조정하기 더 쉽게 만든다.
4. 개발자가 더는 가상 머신, 컨테이너, 그 밖의 운영 세부사항을 신경 쓸 필요가 없어, 대규모 오케스트레이션을 매우 쉽게 만든다.

나는 이런 능력을 충족할 수 있는 모든 인프라가 이미 준비되어 있다고 생각한다. 예를 들어 firecracker는 microVM의 성능과 안정성을 검증했고, 분산 관측성 플랫폼과 파일 스토리지 시스템에도 선택지가 많다. 하지만 e2b로 claude code를 감싸 써본 경험이 있는 개발자로서, 이것들을 한데 통합하는 것은 여전히 매우 어렵다. 예를 들어 E2B 안의 claude code가 OOM에 의해 예기치 않게 중단되었을 때, 엔지니어가 이를 모니터링하기 어렵고, 그때의 현장과 로그를 얻기는 더욱 어렵다.

나는 2026년 이후의 개발자들이 이런 고통스러운 과정을 거치지 않아도 되기를 바란다. 2026년의 대부분 엔지니어가 더는 ssh로 물리 머신을 손수 초기화할 필요가 없어진 것처럼 말이다.

이것이 VM0의 꿈이다. 언젠가 나는 이렇게, 손에 잘 맞는 API를 통해 코딩 에이전트를 운전할 수 있기를 바란다:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})