Cursor가 클라우드 에이전트 개발 환경을 제품처럼 만든 이유

• Cursor 팀이 클라우드 Agent를 운영하면서 깨달은 핵심은 꽤 직설적임. 에이전트에게도 ‘좋은 개발 환경’이 필요하다는 것.

  • 단순히 클라우드 VM 하나를 주는 게 아니라, 로컬 개발자가 쓰는 환경과 최대한 비슷해야 함.
  • repo 안의 빌드·테스트·실행 방법이 암묵지로 남아 있으면 사람도 헤매는데, 에이전트는 더 쉽게 삐끗함.
  • Cursor는 이걸 “개발 환경 자체가 제품이고, 그 사용자는 에이전트”라고 표현함.

• 성과 숫자가 꽤 세다. 12월에는 Cursor 모노레포에 병합된 PR 약 10건 중 1건을 클라우드 Agent가 작성했는데, 지금은 절반 이상을 작성함.

  • 그냥 데모성 자동완성이 아니라 실제 내부 코드베이스에서 병합되는 PR 기준임.
  • 에이전트가 코드를 고치고, 실행하고, 테스트하고, 결과를 증명할 수 있어야 이런 비율이 나옴.

로컬 개발 환경을 클라우드 VM으로 옮기는 일부터 시작함

• 첫 번째 난관은 플랫폼 차이였음. Cursor 개발자 대부분은 Mac에서 일하지만, 클라우드 Agent는 Linux 기반 VM에서 돈다.

  • 그래서 개발 유틸리티와 설정 스크립트를 Ubuntu VM에서도 돌아가게 고쳐야 했음.
  • Cursor 정의 Dockerfile에 핵심 개발 의존성을 넣어서 에이전트용 기본 이미지를 구성함.

• 보안도 그냥 “믿고 맡기자”가 아니었음. 에이전트 환경에 시크릿을 넣을 수 있어야 하지만, 에이전트가 그걸 읽거나 유출하면 바로 사고임.

  • 네트워크 이그레스 제한을 둬서 에이전트가 아무 데나 나가지 못하게 함.
  • git 원격 접근은 범위를 제한하고 프록시를 거치게 만듦.
  • 커밋과 커밋 메시지에 시크릿이 들어갔는지 스캔함.
  • 도구 결과에서는 시크릿 값을 마스킹해서, 에이전트가 시도해도 민감한 값을 직접 볼 수 없게 함.

복잡한 빌드 명령은 anydev 하나로 감쌈

• Ubuntu VM에서 환경이 돌아가게 만든 뒤에도 에이전트는 코드를 제대로 실행하지 못했음.

  • 이유는 뻔함. 빌드 명령, 플래그, 유틸리티 스크립트가 너무 많았고, 함정도 많았음.
  • 사람은 팀의 암묵지로 넘어가지만, 에이전트는 매번 명령을 추론해야 하니 안정성이 떨어짐.

• 처음에는 시스템 각 부분을 빌드하고 실행하는 방법을 스킬로 문서화했지만, 효과가 제한적이었음.

  • 스킬은 “무슨 명령을 써야 하는지” 알려줄 수는 있음.
  • 하지만 명령 자체가 복잡하고 잘못 쓰기 쉬우면, 문서화만으로는 문제가 안 풀림.

• 그래서 Cursor는 anydev라는 CLI를 만들었음. 에이전트가 모든 서비스를 시작하고 일반 유틸리티 스크립트를 실행하는 단일 진입점임.

  • 하위 명령마다 --help 메뉴를 붙여 사용법을 바로 찾을 수 있게 함.
  • 장시간 실행되는 빌드 명령을 감시하고 재시작하는 감독 프로세스도 넣음.
  • 덕분에 모델이 긴 빌드 프로세스를 직접 관리할 필요가 없어짐.

• 이 변화 이후 클라우드 Agent가 로컬 에이전트보다 실질적인 가치를 내기 시작함.

  • 에이전트는 컴퓨터 사용 기능과 recordScreen 도구를 이용해 변경 사항을 끝까지 테스트함.
  • 버그 수정 결과를 Slack에 녹화 데모로 공유하거나, PR 안에 실제 동작 영상을 붙일 수 있었음.
  • 엔지니어가 로컬로 브랜치를 체크아웃하지 않고도 병합과 배포를 결정하는 일이 가능해짐.

환경은 계속 깨지니까, 스스로 진단하고 고치게 만듦

• 에이전트 주변 환경은 가만히 있지 않음. 설정, 접근 권한, 시크릿, 네트워크 정책이 계속 바뀜.

  • 이런 변화가 쌓이면 어느 순간 에이전트가 실패하는데, 실패 원인을 사람이 매번 파야 하면 확장성이 없음.
  • Cursor는 이를 위해 Cursor Cloud MCP를 만들었음.

• MCP를 고른 이유는 에이전트 루프를 다시 만들지 않고도 동적으로 도구 인터페이스를 바꿀 수 있기 때문임.

  • 클라우드 Agent는 MCP를 통해 자기 환경의 설정 실패를 점검함.
  • 이그레스 정책이 막혔는지, 시크릿이 바뀌었는지 같은 문제도 확인함.
  • 문제가 생기면 더 빨리 진단하고 비정상 환경을 복구할 수 있음.

• 여기에 Cloud Doctor라는 자동화도 붙임.

  • 주기적으로 실패를 점검함.
  • 오류가 일시적인지 중요한 문제인지 구분해서 기억함.
  • 근본 원인을 분석하고, 확신이 높으면 문제 해결 PR까지 열 수 있음.

sequenceDiagram
    participant 에이전트
    participant 개발환경
    participant 클라우드MCP
    participant 클라우드닥터
    participant 저장소
    에이전트->>개발환경: 코드 실행과 테스트 시도
    개발환경-->>에이전트: 설정 실패 또는 정책 오류 반환
    에이전트->>클라우드MCP: 환경 상태와 접근 정책 점검 요청
    클라우드MCP-->>에이전트: 실패 원인과 복구 단서 제공
    클라우드닥터->>클라우드MCP: 반복 실패 트레이스 분석
    클라우드닥터->>저장소: 환경 수정 PR 생성

에이전트의 개발자 경험도 계속 개선함

• 환경이 정상이어도 에이전트가 느린 길로 돌아가거나 잘못된 스킬을 쓰는 문제가 남음.

  • VM에서 피할 수 있는 문제를 괜히 맞닥뜨릴 수 있음.
  • 필요 이상으로 오래 걸리는 워크플로우를 따라가기도 함.

• Cloud Doctor는 다른 에이전트의 트레이스를 분석해서 이런 병목을 찾아냄.

  • 어떤 스킬이나 명령이 혼란을 일으켰는지 확인함.
  • 어떤 워크플로우가 반복적으로 느린지 잡아냄.
  • 그 결과를 바탕으로 스킬을 고치거나 실행 경로를 단순화함.

• 결론은 꽤 실용적임. 클라우드 Agent를 잘 쓰고 싶다면 코드베이스가 세 가지 질문에 답할 수 있어야 함.

  • 에이전트가 개발자와 같은 도구와 데이터에 접근할 수 있는가.
  • 에이전트가 실제 작업 방식을 문서화한 스킬을 찾을 수 있는가.
  • 에이전트가 핵심 워크플로우를 직접 테스트하고 검증할 수 있는가.

기술 맥락

• Cursor가 고른 선택은 “에이전트를 더 똑똑하게 만들자”보다 “에이전트가 실수하기 어려운 환경을 만들자”에 가까워요. 복잡한 빌드 플래그와 여러 스크립트를 그대로 두면 모델은 매번 작업 절차를 추론해야 하거든요. 그래서 anydev 같은 단일 CLI를 만들어 실행 경로를 좁힌 게 핵심이에요.

• MCP를 붙인 이유도 비슷해요. 클라우드 환경은 시크릿, 네트워크 정책, 의존성, 권한이 계속 바뀌기 때문에 실패 원인을 고정 문서로만 관리하기 어렵거든요. Cursor Cloud MCP는 에이전트가 자기 환경을 조회하고 진단할 수 있는 동적 인터페이스 역할을 해요.

• Cloud Doctor는 운영 자동화에 가까워요. 실패 트레이스를 보고 일시적인 오류와 구조적인 문제를 나눈 뒤, 확신이 높으면 환경 수정 PR까지 만들어요. 이건 에이전트가 코드만 쓰는 게 아니라, 에이전트를 둘러싼 개발 시스템 자체를 점점 고치는 구조예요.

• 여기서 중요한 건 규모예요. PR 10건 중 1건에서 절반 이상으로 늘었다는 건, 에이전트 도입이 개인 생산성 도구 단계를 넘어 팀 워크플로우에 들어갔다는 뜻이에요. 한국 팀들도 AI 코딩 도구를 붙일 때 먼저 봐야 할 건 프롬프트가 아니라 빌드·테스트·시크릿·권한 흐름일 가능성이 커요.