1년 전 처음 클라우드 Agent를 출시했을 때만 해도, 클라우드 Agent는 로컬 에이전트의 단순한 확장처럼 보였습니다. 하지만 그 이후로 클라우드 Agent의 기능은 크게 확장되었습니다.

이제 클라우드 Agent는 전용 가상 머신에서 자체 환경, 의존성, 네트워크 접근 권한을 갖춘 채 실행됩니다. 여러 작업을 병렬로 처리할 수 있고, 사람의 개입 없이 실행되며, 노트북에서 돌아가는 로컬 에이전트보다 더 긴 작업도 맡을 수 있습니다.

이런 기능이 가능해지면서, 에이전트가 노트북에서 실행될 때보다 환경 설정, 안정성, 오케스트레이션 측면에서 더 큰 과제가 생깁니다.

이 글에서는 클라우드 Agent를 만들며 배운 가장 큰 교훈과, 이 작업이 점점 더 로컬 에이전트를 서버로 옮기는 일이 아니라 그 주변에 운영 레이어를 구축하는 일에 가까워지는 이유를 공유하고자 합니다.

#개발 환경이 곧 제품입니다

지난 1년 동안 저희는 클라우드 Agent의 출력 품질을 좌우하는 가장 큰 단일 요인이, 개발자와 마찬가지로 완전한 개발 환경을 갖추는 것이라는 점을 깨달았습니다.

로컬에서는 로컬 에이전트가 노트북의 개발 환경을 그대로 활용할 수 있기 때문에 이런 부분을 크게 신경 쓰지 않아도 됩니다. 하지만 클라우드에서는 그 모든 것을 처음부터 다시 구성해야 하고, 조금이라도 빠뜨렸을 때 그 사실을 알아차리기가 놀라울 만큼 어렵습니다.

충돌이나 오류 메시지가 뜨는 대신, 대개 드러나는 유일한 신호는 출력 품질이 미묘하게 떨어지는 것뿐입니다. 처음엔 눈치채지 못할 수도 있고, 눈치채더라도 모델 탓이라고 생각할 수 있습니다.

하지만 저희는 거듭해서 같은 원인에 도달했습니다. 바로 클라우드 Agent가 작업을 실행하거나 검증하는 데 필요한 환경을 갖추지 못한 상태라는 점입니다. 1년 전에는 모델이 어차피 환경을 그다지 잘 활용하지 못했기 때문에 이 문제가 덜 중요했습니다. 하지만 모델이 더 똑똑해지면서, 환경 설정은 모델이 잠재력을 온전히 발휘할 수 있는지를 가르는 결정적 요소가 되었습니다.

오늘날 "완전한 환경"에 도달하려면 놀랄 만큼 많은 인프라를 다시 구축해야 합니다:

• 에이전트 환경을 만들기 위한 더 나은 사용자 도구
• 메시지 사이에 에이전트 VM을 효율적으로 최대 절전하고 다시 시작하는 방법
• VM 이미지를 빠르고 안정적으로 체크포인트하고, 복원하고, 포크하는 파이프라인
• 에이전트와 사람 모두가 환경을 해석하고 상호작용할 수 있도록 하는 긴밀한 하네스 및 클라이언트 통합

그리고 클라우드 Agent가 더 많은 작업을 맡게 되면서, PR을 만들고, 의존성을 가져오고, 조사를 수행할 수 있도록 통제된 네트워크 접근도 필요해졌습니다. 시간이 지나면서 저희는 결국 비밀 정보 마스킹, 네트워크 정책, 자격 증명 관리까지 갖춘, 사실상 에이전트를 위한 기업용 IT를 구축하게 되었습니다.

#장시간 실행 에이전트에는 지속 실행이 필요합니다

클라우드 Agent는 로컬 에이전트와는 다른 종류의 안정성 문제를 안고 있습니다. 노트북의 로컬 리소스를 두고 경쟁하는 대신, 클라우드 Agent는 각각 격리된 VM에서 실행됩니다. 덕분에 개발자는 여러 에이전트를 병렬로 더 쉽게 실행하고, 몇 분이 아니라 몇 시간씩 걸리는 장시간 작업을 위임할 수 있습니다.

하지만 VM에서 실행된다는 것은 inference provider 장애, pod 교체, EC2 노드 다운 같은 중단 상황에 노출된다는 뜻이기도 합니다.

저희는 처음에 worker 노드가 에이전트를 가져와 완료될 때까지 처리하는 work-stealing 아키텍처로 클라우드 Agent를 만들기 시작했습니다. 로컬에서 잘 작동하던 방식을 서버로 옮겨온 셈이었지만, 이 setup은 취약했고 클라우드 Agent의 초기 베타는 안정성이 종종 9 하나 수준에 머물렀습니다.

클라우드 Agent가 성숙해지면서, 저희는 Temporal이 이미 해결하고 있는 지속 실행 프리미티브(예: retry 메커니즘, 여러 machine에 걸친 작업 스케줄링, node failure 전반에 걸친 내구성)를 상당 부분 직접 다시 만들기 직전까지 갔고, 그래서 대신 Temporal로 마이그레이션했습니다.

현재 Temporal 위에서 실행되는 저희 agent loop는 inference 안정성의 일시적인 문제, pod의 최대 절전과 재개, 그리고 며칠에서 몇 주까지 이어지는 실행도 버틸 수 있습니다. 이 마이그레이션만으로도 안정성은 9 두 개를 넘어섰고, 현재 Temporal은 하루 5천만 건이 넘는 action을 700만 개가 넘는 고유 워크플로우에 걸쳐 처리하고 있습니다. 내부적으로는 PR의 40% 이상이 클라우드 Agent에서 나오고 있으며, 그 비중은 계속 늘고 있습니다.

시간이 지나면서 저희는 Temporal 워크플로우를 더 잘 설계하는 방법을 배웠습니다. version 업그레이드를 더 쉽게 하기 위해, "영구적인" agent 워크플로우에서 단일 task를 완료하면 종료되는 여러 개의 더 짧은 워크플로우로 전환했습니다. 또한 async tool call, 하위 에이전트, inference provider 장애로 인해 기반 가정이 바뀌면서, 시간 초과와 retries를 더 잘 포착할 수 있도록 activity도 분리했습니다.

#에이전트와 머신을 대화 상태에서 분리하기

클라우드 에이전트는 더 이상 하나의 머신에서 하나의 루프만 실행하는 구조가 아닙니다. 이제 에이전트는 한 머신에서 실행될 수도 있고, 여러 머신에 걸쳐 비동기 하위 에이전트를 생성할 수도 있으며, 로컬에서 시작한 뒤 작업을 클라우드에 위임할 수도 있습니다. 하위 에이전트가 상위 에이전트보다 더 오래 실행되거나, 완전히 다른 종류의 pod에서 실행되는 경우도 있습니다.

이를 가능하게 하려면 에이전트 루프, 머신 상태, 대화 상태를 서로 분리된 컴포넌트로 유지하는 것이 중요하다는 점을 확인했습니다. 에이전트 루프는 VM 자체가 아니라 Temporal에서 실행되므로, pod 수명 주기를 독립적으로 관리하고 서로 다른 종류의 pod에서 에이전트를 실행할 수 있습니다. 여기에는 읽기 전용 VM이나 사전 예열된 VM 같은 최적화도 포함됩니다.

대화 측면에서는 저장 및 스트리밍 레이어를 핵심 에이전트 워크플로우와 분리했습니다. 웹과 데스크톱 클라이언트로 대화 업데이트를 스트리밍하는 효율적인 추가 전용 저장 메커니즘도 만들었습니다. 이 레이어는 재시도를 고려해 설계되어, 에이전트 루프의 한 단계가 일부 출력을 스트리밍한 뒤 실패해 다시 시도되더라도 클라이언트가 이를 탐지하고 스트림을 되감아 이전 데이터 대신 새 데이터를 표시할 수 있습니다.

#언제 물러서야 하는지 알기

클라우드 Agent 하네스를 만든다는 것은 어떤 동작을 결정적으로 처리할지, 또 어떤 부분을 에이전트에게 맡길지를 끊임없이 다시 판단하는 일입니다.

초기에는 에이전트를 그다지 신뢰하지 않았기 때문에, 하네스가 작업이 끝날 때마다 결과를 다시 확인하고, 강제로 커밋한 뒤 푸시했습니다. 모델이 더 똑똑해지면서 우리는 하네스에 있던 로직을 에이전트가 제어하는 도구로 옮기기 시작했습니다. 1년 전만 해도 multi-repo 설정에는 하드코딩된 하네스 동작이 필요했습니다. 이제는 에이전트에게 repo 레이아웃을 알려주고, 브랜치와 PR를 위한 도구를 노출한 다음, 작업을 어떻게 할지는 에이전트가 스스로 판단하게 할 수 있습니다.

CI Autofix에서도 같은 일이 있었습니다. 이전 버전의 클라우드 Agent 하네스에는 작업 실패 로그를 가져와 VM에 기록하는 로직이 들어 있었습니다. 이제는 에이전트에게 GitHub CLI 접근 권한만 주고, 큰 출력은 검색할 수 있도록 자동으로 파일에 기록합니다. 에이전트에게 보내는 알림도 훨씬 단순해졌고, 이런 흐름은 앞으로도 계속될 것으로 보고 있습니다.

하네스가 사라지는 것은 아닙니다. 다만 그 안에 들어가는 내용이 바뀌고 있을 뿐입니다. 지금은 컴퓨터 사용이 좋은 예입니다. 우리 클라우드 Agent 하네스에는 컴퓨터 사용을 위한 전용 하위 에이전트 유형이 있고, 여기에 자체 모델 routing, custom prompting, 화면 녹화가 포함됩니다. VNC와 Chrome은 환경에 속하며, 이 환경은 parent agent와 하위 에이전트가 함께 공유합니다. 덕분에 parent agent는 예를 들어 Playwright script를 실행하는 방식으로 이를 직접 사용할 수 있습니다. 모델이 아직은 컴퓨터 사용을 스스로 처리할 만큼 충분히 준비되지 않았기 때문에 이런 scaffolding을 사용하지만, 언제 이를 호출할지는 여전히 에이전트가 제어합니다.

클라우드 에이전트는 로컬 에이전트와는 다른 종류의 프롬프트를 하네스에서 필요로 하기도 합니다. 우리는 이들이 더 자율적으로 동작하도록 유도하는데, 막혀서 대기하는 비용이 훨씬 더 크기 때문입니다. 로컬에서는 에이전트가 멈춰서 권한을 기다리고 있다는 걸 바로 알 수 있지만, 클라우드에서는 몇 시간 동안 그대로 대기하다가 사용자가 나중에 다시 확인할 때까지 방치될 수 있습니다.

#자가 복구 에이전트 환경

앞으로 저희는 에이전트를 일일이 도와주거나 완전히 손을 떼는 이분법적 선택을 넘어서고자 합니다. 더 나은 방식은 에이전트가 자신을 둘러싼 시스템을 이해할 수 있는 도구를 제공하는 것입니다.

저희는 클라우드 Agent가 시크릿 누락, 네트워크 접근 차단, 혹은 그 밖에 환경이 작업 진행을 막고 있는 상황을 보고하고, 이어서 스스로 복구하는 방식으로 대응할 수 있기를 바랍니다. 최근 연구 블로그에서는 이를 달성하는 한 가지 접근 방식으로 “autoinstall”을 소개했습니다.

클라우드 Agent는 지난 몇 달 사이 크게 개선되었고, 이러한 변화 속도는 앞으로 더 빨라질 것으로 보고 있습니다. Cursor 클라우드 Agent는 팀이 기반 인프라를 직접 구축하거나 유지 관리하지 않고도 이 폭넓은 기능을 활용할 수 있게 해줍니다.