Cursor가 클라우드 에이전트 운영 1년 동안 배운 5가지 교훈

Cursor사가 「클라우드 에이전트 (Cloud Agent)」를 1년간 운영해 온 지견을 정리한 블로그 게시물이 공개되었습니다. 로컬에서 동작하는 AI 에이전트를 클라우드로 옮기기만 하면 되는 것 아니냐고 생각할 수도 있지만, 전혀 그렇게 단순한 문제가 아니었던 모양입니다.

본 기사에서는 Josh Ma 씨의 「What we've learned building cloud agents」 내용을 소개합니다.

클라우드 에이전트란

Cursor의 클라우드 에이전트는 Background Agent라고도 불리며, 클라우드 상의 VM에서 코딩 태스크를 자율적으로 실행하는 에이전트입니다. 로컬 에디터에서 지시를 내리면, 클라우드 상에서 환경 구축부터 코드 변경, PR 생성까지 일련의 작업을 수행해 줍니다.

이 1년간의 운영을 통해 팀은 5가지 큰 교훈을 얻었다고 합니다.

교훈 1: 개발 환경이야말로 가장 중요한 프로덕트

이것이 가장 의외이면서도 가장 중요한 포인트입니다.

로컬 AI 에이전트는 개발자가 평소 사용하는 환경을 그대로 사용할 수 있습니다. 의존성 패키지도, 툴도, 설정 파일도 모두 갖춰진 상태가 시작점이죠. 하지만 클라우드 에이전트는 다릅니다. 의존 관계, 툴, 설정을 처음부터 다시 구축해야 합니다.

Cursor사는 다음과 같이 언급했습니다.

에이전트가 똑똑해질수록, 환경 설정(Environment Setup)이 퍼포먼스를 좌우하는 결정적인 요인이 되고 있다

즉, 모델의 성능을 최대한 끌어내기 위한 병목 현상(Bottleneck)은 더 이상 모델 자체가 아니라 「환경」인 것입니다.

구체적으로 필요해지는 인프라는 다음과 같습니다:

사용자 친화적인 환경 구축 툴
VM의 하이버네이션 (Hibernation) 및 재개 (매번 처음부터 시작하는 것은 비효율적)
VM 이미지의 체크포인트 및 복원
엔터프라이즈급 보안 (시크릿 은닉, 네트워크 정책, 인증 정보 관리)

사소해 보이지만, 이 부분이 정비되어 있지 않으면 에이전트는 본래의 힘을 발휘할 수 없다는 뜻입니다.

교훈 2: Durable Execution 아키텍처가 필수

클라우드에서 동작한다는 것은 인프라 장애가 늘 따른다는 것을 의미합니다. 노드가 다운되거나 네트워크가 끊기는 등의 문제 말이죠. 로컬에서는 크게 고려하지 않아도 되는 문제지만, 클라우드에서는 피할 수 없습니다.

Cursor사의 초기 아키텍처는 「work-stealing」 방식이었습니다. 하지만 이 구성으로는 신뢰성을 「1 나인 (1 Nine)」, 즉 90% 정도밖에 달성할 수 없었다고 합니다. 10번 중 1번 실패하는 에이전트는 사실상 쓸모가 없으니까요.

그래서 팀은 Temporal (워크플로 엔진)로 이행했습니다. Temporal이 제공하는 기능은 다음과 같습니다:

자동 재시도 (Automatic Retry)
머신 간의 워크 스케줄링 (Work Scheduling)
노드 장애에 대한 내성

이 이행을 통해 신뢰성은 「2 나인 (2 Nines)」 (99% 이상)을 달성했습니다. 현재의 규모감도 인상적입니다:

하루 5,000만 건 이상의 액션
700만 건 이상의 유니크 워크플로
Cursor 사내 PR의 40% 이상이 클라우드 에이전트에 의해 생성

사내 PR의 4할을 에이전트가 만들고 있다는 것은 상당한 임팩트라고 할 수 있습니다.

교훈 3: 컴포넌트를 분리하라

「한 대의 머신에서 하나의 에이전트 루프를 돌린다」는 심플한 모델로는 한계가 있었던 것 같습니다.

Cursor사는 3개의 컴포넌트를 독립적으로 관리하는 설계로 이행했습니다:

컴포넌트	실행 장소	역할
에이전트 루프	Temporal 상	태스크 실행 제어
...

이 분리를 통해 얻은 이점은 다음과 같습니다:

「readonly」 VM: 읽기 전용 VM에서 고속으로 상태 확인
「prewarmed」 VM: 사전에 환경 구축이 완료된 VM을 풀(Pool)로 유지하여 즉시 이용
서브 에이전트의 독립적인 라이프사이클: 부모 에이전트가 종료되어도 서브 에이전트가 처리를 계속할 수 있음

마이크로서비스 (Microservices)의 사고방식과 유사하지만, 에이전트 특유의 「대화 상태 (Conversation State)」라는 개념이 있다는 점이 흥미로운 부분입니다.

교훈 4: 하네스 (Harness)는 단계적으로 간소화하라

초기 버전에서는 에이전트의 행동을 엄격하게 제어했다고 합니다:

commit/push 조작을 강제
멀티 리포지토리 로직을 하드코딩
행동 패턴을 결정론적(Deterministic)으로 제어

하지만 모델이 똑똑해짐에 따라, 이러한 접근 방식은 오히려 역효과를 낳게 되었습니다.

현재의 접근 방식은 "도구를 건네주고 판단은 에이전트에게 맡기는 것"입니다. GitHub CLI나 파일 시스템 등의 도구를 제공하면서, 결정론적인 하네스 로직 (Harness Logic)은 줄여나가고 있습니다.

하지만 모든 것을 통째로 맡기는 것도 아닙니다. 컴퓨터 유즈 (Computer Use, GUI 조작)와 같은 특수한 태스크에는 전용 서브 에이전트 (Sub-agent)와 특화된 프롬프트 (Prompt)를 준비하고 있다고 합니다.

이러한 균형 감각은 에이전트 개발에 있어 공통된 과제라고 생각합니다. 가드레일 (Guardrail)을 너무 늘리면 유연성이 상실되고, 너무 줄이면 폭주할 위험이 있습니다. 모델의 진화에 맞춰 이 균형을 계속해서 조정해 나가는 것이 중요합니다.

교훈 5: 자기 수복하는 환경으로 (향후 전망)

마지막은 향후 전망입니다.

현재의 클라우드 에이전트는 환경에 문제가 있으면 그대로 실패하거나, 인간에게 도움을 요청하는 두 가지 선택지 중 하나로 흐르기 쉽습니다. 시크릿 (Secret)이 부족하거나, 네트워크 액세스가 차단되는 등의 문제에 부딪히면 막다른 길에 다다르게 됩니다.

Cursor사가 지향하는 것은 에이전트가 스스로 환경 문제를 감지하고 수복하는 "자기 수복 (Self-healing)" 메커니즘입니다. "일일이 가르쳐주는 방식"도 "방임"도 아닌, 자율적으로 문제를 해결할 수 있는 에이전트의 모습입니다.

요약

Cursor사의 1년간의 지견을 정리하면 다음과 같습니다:

환경이 전부다: 에이전트의 성능은 모델이 아니라 환경에 의해 결정된다 -
Durable Execution: Temporal과 같은 워크플로우 엔진 (Workflow Engine)으로 신뢰성을 확보 -
관심사의 분리 (Separation of Concerns): 에이전트 루프 (Agent Loop), 머신 상태 (Machine State), 대화 상태 (Conversation State)를 독립적으로 관리 -
하네스의 간소화: 모델이 똑똑해질수록 제어를 줄이고 도구를 전달 -
자기 수복: 환경 문제를 자율적으로 감지하고 수복하는 방향으로

개인적으로 가장 와닿았던 부분은 "환경이 병목 (Bottleneck)이다"라는 이야기입니다. 로컬 AI 코딩 도구를 사용할 때 당연하게 느껴졌던 "환경이 갖춰져 있다"라는 전제가, 클라우드에서는 최대의 과제가 됩니다. Claude Code나 Cursor를 로컬에서 사용할 때의 쾌적함은 사실 환경이 잘 갖춰져 있었기 때문이라는 것을 새삼 느꼈습니다.