클라우드 Agent 환경을 구축한 방법
클라우드 Agent가 변경 사항을 테스트할 수 있도록 컴퓨터를 제공하기로 했을 때, 첫 단계는 에이전트가 자체 코드베이스에서 변경 사항을 제대로 테스트할 수 있게 하는 것이었습니다.
클라우드 Agent가 모노레포에서 작동하도록 하면서, 개발 환경 자체가 하나의 제품이며 그 사용자는 에이전트라는 사실을 깨달았습니다. 클라우드 환경을 로컬 개발 환경과 동일하게 만들고, 에이전트가 암묵지 없이도 코드를 실행하고 테스트할 수 있을 만큼 repo를 이해하기 쉽게 하며, 코드베이스의 변화에 맞춰 환경을 안정적으로 유지해야 합니다.
이 환경을 구축하면서 업무 방식도 바뀌었습니다. 12월에는 클라우드 Agent가 Cursor 모노레포에 병합된 PR 약 10건 중 1건을 작성했습니다. 현재는 절반 이상을 작성합니다.
7-day rolling share of merged PRs from cloud agents
클라우드 환경을 로컬 개발 환경에 맞추기
repo에서 클라우드 Agent가 원활하게 작동하도록 하려면 먼저 repo가 클라우드 VM에서 잘 작동해야 했습니다. 이 단계는 원격 개발 환경을 처음 설정해 본 엔지니어라면 누구나 익숙할 것입니다.
대부분의 Cursor 개발자는 Mac에서 로컬 개발을 하지만, 클라우드 VM은 Linux에서 실행됩니다. 따라서 다양한 개발 유틸리티와 설정 스크립트가 Ubuntu VM에서도 작동하도록 플랫폼 독립적으로 만들어야 했습니다. 클라우드 Agent의 기본 이미지로 사용되는 Cursor 정의 Dockerfile에 핵심 개발 종속성을 추가했습니다.
또한 보안 팀과 협력하여 사용자가 필요한 시크릿을 에이전트 환경에 안심하고 주입할 수 있도록 클라우드 Agent 제품에 보안 기능을 추가했습니다. 이러한 기능에는 네트워크 이그레스 제한, 범위가 제한되고 프록시를 통한 git 원격 접근, 커밋 및 커밋 메시지의 시크릿 스캔, 그리고 에이전트가 시도하더라도 시크릿 값을 읽지 못하도록 하는 도구 결과의 시크릿 마스킹이 포함됩니다.
에이전트를 위한 더 간단한 인터페이스
Ubuntu VM에서 개발 환경을 구축한 뒤에도 에이전트는 여전히 코드를 제대로 실행하지 못했습니다. 개발 환경이 복잡했고 수많은 빌드 명령, 빌드 플래그, 유틸리티 스크립트를 익히고 기억해야 했기 때문에 놀랄 일은 아니었습니다.
시스템의 여러 부분을 빌드하고 실행하는 방법을 스킬로 작성했지만, 효과는 제한적이었습니다. 스킬로 올바른 명령을 문서화할 수는 있었지만, 명령 자체가 복잡하고 실수하기 쉬운 함정으로 가득했습니다.
이 복잡성을 줄이기 위해 에이전트가 모든 서비스를 시작하는 데 사용할 수 있는 anydev라는 CLI를 만들었습니다. 일반적인 유틸리티 스크립트도 anydev를 통해 실행하도록 했고, 각 하위 명령어의 사용법을 설명하는 여러 --help 메뉴도 anydev에 추가했습니다. anydev에는 장시간 실행되는 빌드 명령을 모니터링하고 재시작하는 감독 프로세스도 있어, 이 책임을 모델에서 완전히 덜어줍니다.
anydev 덕분에 에이전트가 코드를 안정적으로 실행할 수 있을 만큼 개발 환경이 단순해졌습니다. 스킬은 사용법을 문서화하는 데 도움이 되었지만, 더 큰 변화는 에이전트가 더 이상 특수한 다단계 빌드 명령을 다루고, 숨겨진 함정을 피하고, 장시간 실행되는 프로세스를 관리할 필요가 없어졌다는 점이었습니다.
이때부터 각자 컴퓨터를 갖춘 클라우드 Agent가 로컬 에이전트보다 실질적인 가치를 제공하기 시작했습니다. 컴퓨터 사용 기능, recordScreen 도구, 그리고 제대로 작동하는 개발 환경을 갖추면서 에이전트는 이제 변경 사항을 처음부터 끝까지 테스트하고 사용자에게 작업 결과의 정확성을 입증할 수 있었습니다.
누군가 버그 보고서를 수정했을 때는 Slack에서, 변경 사항이 담긴 PR을 열었을 때는 PR에서 에이전트가 녹화한 데모를 공유할 수도 있었습니다. 이제 많은 작업에서 엔지니어는 로컬로 브랜치를 체크아웃하지 않고도 클라우드 Agent가 작성한 코드를 자신 있게 병합하고 배포할 수 있었습니다.
자가 복구 환경
에이전트 주변 환경은 끊임없이 변하므로, 환경을 정상적으로 운영하려면 실행 방식과 접근 가능한 리소스를 지속적으로 업데이트해야 합니다.
문제가 발생하는 비정상 환경을 진단하고 복구하기 위해 Cursor Cloud MCP를 구축했습니다. 에이전트 루프를 다시 구축하지 않고도 인터페이스를 변경할 수 있는 동적 검색 도구를 제공한다는 점에서 MCP를 선택했습니다. 클라우드 Agent는 이를 사용해 자체 환경의 설정 실패, 이그레스 정책, 변경된 시크릿 등을 점검합니다. 이를 통해 문제가 발생하는 즉시 진단하고 해결하며, 비정상 환경을 더 빠르게 복구할 수 있습니다.
Cursor Cloud MCP를 도입한 후에는 주기적으로 실패를 점검하고, 오류가 일시적인지 중요한지 구분해 기억하며, 근본 원인을 분석하고, 높은 확신이 있을 때 문제 해결을 위한 PR을 열 수 있는 자동화인 Cloud Doctor를 설정했습니다.
에이전트 경험 개선
환경 상태가 양호해도 에이전트는 변경 사항을 검증하는 데 시간이 오래 걸리거나 불필요하게 복잡한 경로를 택할 때가 있습니다. 잘못된 스킬을 사용하거나 VM에서 피할 수 있는 문제를 겪거나, 필요 이상으로 오래 걸리는 워크플로우를 따를 수 있습니다.
이 경우에도 Cursor Cloud MCP를 사용합니다. Cloud Doctor 에이전트는 트레이스를 분석해 다른 에이전트가 어디서 잘못되었는지, 어떤 스킬이나 명령이 혼란을 초래했는지, 어떤 워크플로우가 지속적으로 느린지 파악합니다. 이러한 발견 사항을 바탕으로 Cloud Doctor 에이전트는 스킬을 수정하고, 경로를 단순화하거나, 다음 에이전트가 더 쉽게 작업할 수 있도록 환경을 변경합니다.
이러한 반복을 통해 에이전트 자체의 개발자 경험도 계속 개선됩니다. 환경 상태가 양호하고 자가 복구 기능을 갖추면 에이전트는 안정적으로 실행되고, 개발자는 더 중요한 작업을 클라우드 Agent에 맡길 수 있습니다.
이를 통해 내부적으로 클라우드 Agent 도입을 확장할 수 있었고, 이제 클라우드 Agent가 배포하는 코드 대부분을 작성합니다.
클라우드 Agent를 위한 환경 준비하기
클라우드 Agent의 생산성은 대부분 환경에 달려 있습니다. 코드베이스가 준비되었는지 확인하려면 다음 세 가지 질문에 답해 보세요.
- 에이전트가 개발자와 동일한 도구와 데이터에 접근할 수 있나요?
- 에이전트가 개발자의 실제 작업 방식을 문서화한 스킬을 찾을 수 있나요?
- 에이전트가 핵심 워크플로우를 테스트하고 검증할 수 있나요?
환경 준비에 도움이 필요하시면 문의해 주세요.
또는 자세히 알아보려면 Faire가 클라우드 Agent를 통해 주간 PR 처리량을 두 배로 늘린 방법을 읽어 보세요.
