커서가 8월 13일 클라우드 에이전트에 '빌드(Builds)'를 넣었어요. 기본 이미지에서 저장소를 기본 브랜치로 복제하고 .cursor/environment.json 의 install 명령까지 돌린 디스크 상태를 미리 떠 두고, 에이전트는 매번 새로 세팅하는 대신 그 스냅숏 위에서 시작해요. 다만 제목이 내건 '3배'의 근거는 본문의 '사내 환경 기준 부팅 10배, 첫 토큰까지 시간 3배' 한 문장뿐이고, 무엇 대비인지도 어떤 저장소에서 쟀는지도 적혀 있지 않아요.
용어 풀이
- 스냅숏
- 어느 시점의 디스크 상태를 통째로 떠서 저장해 둔 사본
- install 명령
- 환경 설정 파일에 적어 두는 의존성 설치 단계. 커서는 이 단계까지 마친 상태를 미리 저장해 둔다
- 커밋 SHA
- 깃 커밋 하나를 가리키는 고유 식별 문자열
운영자 인사이트
스냅숏에 들어가는 건 install 까지고 start·terminals 는 여전히 에이전트가 뜰 때 돌아서, 느린 쪽이 서버 기동이나 마이그레이션이면 체감이 덜해요. 기본 신선도 기준이 24시간이라 하루 묵은 코드에서 시작할 수 있고(0으로 낮추면 매번 최신), 이미 쓰던 환경은 대시보드에서 직접 켜야 해요.
여러 관점으로 보기
- 동작 방식 — 공식 문서 빌드는 정기 일정·설정이나 시크릿 변경·수동 요청·에이전트 요청으로 돌고, 저장할 때 환경 버전과 저장소별 커밋 SHA를 함께 박아 둬요. 실패한 빌드는 활성으로 올라가지 않고 직전 성공분을 계속 써요. Cursor Docs
- 경쟁 제품 — 코덱스 클라우드는 이미 캐시해요 코덱스 클라우드는 셋업 스크립트를 돌린 컨테이너 상태를 최대 12시간 캐시하고, 스크립트·환경변수·시크릿이 바뀌면 캐시를 스스로 버려요. OpenAI Codex Docs
- 경쟁 제품 — 코파일럿은 매번 새로 세워요 깃허브 코파일럿 코딩 에이전트는 깃허브 액션 위의 일회용 환경이라 작업마다 새로 만들고, copilot-setup-steps.yml 안에서 의존성 캐시를 쓰는 정도예요. GitHub Docs