AIREITERCursor의 코디네이터·서브에이전트 구조는 대규모 코드베이스 마이그레이션에 분명 도움이 됩니다. 다만 버튼 한 번으로 전체 코드를 방치한 채 갈아엎는 도구는 아닙니다. 작업을 범위가 명확하고 테스트 가능한 단위로 나눌 수 있을 때 가장 빛을 발하며, 여러 에이전트가 계약·파일·문서화되지 않은 비즈니스 규칙을 공유하기 시작하면 위험도가 빠르게 올라갑니다. ‘Projects’라는 이름도 그대로 받아들이기보다는 신중하게 볼 필요가 있습니다. 현재 공식 자료는 하나의 일관된 Projects 제품 페이지보다 서브에이전트, 비동기 실행, 클라우드 에이전트, 장시간 코딩 작업에 초점을 맞추고 있기 때문입니다.
Cursor Projects 베타가 마이그레이션 팀에 제공하는 것
Cursor의 최신 서브에이전트 문서에 따르면, 상위 Agent가 별도의 컨텍스트 창에서 전문 작업을 수행하도록 업무를 위임할 수 있습니다. 서브에이전트는 결과를 상위 에이전트에 반환하고, 포그라운드나 백그라운드에서 실행할 수 있으며, 사용할 도구와 모델, 파일 쓰기 권한도 개별적으로 설정할 수 있습니다.
마이그레이션에서 유용한 기본 단위가 바로 이 구조입니다. 코디네이터는 전체 범위와 의사결정을 관리하고, 전문 에이전트는 저장소를 탐색하거나 제한된 범위의 변경을 구현하고, 테스트를 실행하거나 결과를 검토합니다. Cursor는 각자 가상 머신과 브랜치, 저장소 클론을 사용하는 클라우드 서브에이전트도 문서화하고 있습니다. 여러 에이전트가 하나의 체크아웃을 동시에 수정하도록 두는 것보다 실질적으로 안전한 방식입니다.
다만 베타라는 점은 중요합니다. 2026년 2월 Cursor 릴리스 토론에서는 비동기 및 중첩 서브에이전트가 발표됐지만, 사용자들은 백그라운드 실행이 불안정하게 트리거된다고 보고했습니다. Cursor 직원은 is_background: true 관련 문제가 Cursor 2.6에서 수정될 예정이라고 답했습니다. 따라서 지원 여부와 동작을 항상 보장되는 제어 계층으로 보기보다는 버전 의존적인 기능으로 다루는 편이 안전합니다.
코디네이션이 효과적인 마이그레이션 워크플로
코디네이터의 가치는 모든 코드를 직접 작성하는 데 있지 않습니다. 전체 순서를 책임지는 역할에 더 가깝습니다. 프레임워크나 언어를 마이그레이션한다면 다음과 같이 역할을 나누는 방식이 효과적입니다.
| 역할 | 유용한 결과물 | 별도 컨텍스트가 필요한 이유 |
|---|---|---|
| 저장소 탐색 에이전트 | 의존성 맵, 진입점, 생성 코드 경계 | 검색 결과가 메인 스레드를 쉽게 뒤덮을 수 있음 |
| 마이그레이션 플래너 | 순서가 정해진 작업 패키지와 불변 조건 | 전체 저장소를 조망하며 계획해야 함 |
| 구현 에이전트 | 하나의 모듈·서비스·워크트리 안에서의 변경 | 범위를 좁히면 관련 없는 수정이 줄어듦 |
| 테스트 에이전트 | 해당 작업 단위에 대한 신규 및 기존 검증 | 테스트 로그는 길고 별도로 처리할 수 있음 |
| 리뷰어 | 회귀, 보안, 코딩 관례 관련 발견 사항 | 새 컨텍스트가 구현 결과에 덜 매몰됨 |
| 코디네이터 | 계약 확인, 충돌 결정, 다음 작업 묶음 | 서로 맞지 않는 결과를 한곳에서 조정해야 함 |
Cursor의 장시간 코딩 보고서도 플래너-워커-저지 구조와 비슷한 접근을 소개합니다. Solid를 React로 전환한 실험에서 Cursor는 3주가 넘는 작업 기간과 약 266,000개의 추가, 193,000개의 삭제가 발생했다고 밝혔습니다. 동시에 세심한 리뷰가 여전히 필요했다고도 명시했습니다. 이 사례는 해당 구조가 대규모 작업을 지속할 수 있다는 근거이지, 마이그레이션이 기본적으로 프로덕션에 안전하다는 증거는 아닙니다.
대규모 코드베이스에서 구조가 빛나는 지점
1. 인벤토리와 의존성 매핑
대규모 마이그레이션은 호출 지점 하나, 빌드 스크립트 하나, 생성 파일 하나, 배포 전제 하나를 놓치는 순간부터 흔들릴 수 있습니다. 전담 탐색 에이전트가 이런 영역을 훑는 동안 코디네이터는 발견 내용을 마이그레이션 장부로 정리할 수 있습니다.
한 에이전트에게 “저장소를 마이그레이션하라”고 지시하는 것보다 나은 이유는 결과를 직접 확인할 수 있기 때문입니다. 영향을 받는 패키지, 의존성 관계, 공개 인터페이스, 테스트 커버리지, 해결되지 않은 가정을 각각 추적할 수 있습니다. Cursor의 현대화 가이드도 Plan Mode, .cursor/plans/, 그리고 .cursor/rules/migration.mdc 같은 마이그레이션 규칙을 권장합니다.
2. 반복적이고 범위가 제한된 변환
지원 중단된 API 호출을 일괄 수정하거나, 독립적인 모듈을 변환하거나, 인터페이스가 안정된 서비스를 마이그레이션하는 작업은 서브에이전트와 잘 맞습니다. 안전한 경계는 단순히 폴더 이름으로 정해지지 않습니다. 다음 조건을 갖춘 작업 단위여야 합니다.
- 담당자와 파일 범위가 명확할 것
- 입력·출력 계약이 문서로 작성돼 있을 것
- 빌드 및 테스트 명령이 정해져 있을 것
- 브랜치 또는 격리된 워크트리를 사용할 것
- 완료 조건이 분명할 것
Cursor 문서도 여러 서브에이전트가 기본 체크아웃을 공유하면 서로의 변경을 덮어쓸 수 있다고 경고합니다. 격리된 워크트리나 클라우드 브랜치를 사용하면 코디네이터나 사람이 병합하기 전까지 변경 사항을 분리해둘 수 있습니다.
3. 유지보수 큐와 백그라운드 검증
유지보수 작업은 자연스럽게 병렬화되는 경우가 많습니다. 불안정한 테스트 조사, 의존성 경고 확인, 문서 업데이트, 풀 리퀘스트 리뷰는 서로 독립적으로 진행할 수 있습니다. 백그라운드 실행을 사용하면 상위 에이전트가 다른 작업을 계속할 수 있고, 클라우드 에이전트는 자체 가상 머신에서 작업을 이어갈 수 있습니다.
리뷰 측면에서는 Cursor의 Agent Review 문서가 Quick과 Deep 모드를 제공합니다. Deep 리뷰는 더 느리고 비용도 높지만, Cursor는 복잡한 로직과 보안 민감 코드, 대규모 리팩터링에 이를 권장합니다. Source Control 워크플로는 가장 최근의 수정분만이 아니라 전체 로컬 변경 세트를 메인 브랜치와 비교합니다.
이런 구조는 유지보수에 유용하지만, 리뷰는 반드시 통과 관문으로 남겨야 합니다. 하위 에이전트가 성공했다고 보고한 것은 통합 테스트 통과나 풀 리퀘스트 승인과 같은 의미가 아닙니다.
코디네이터·서브에이전트 워크플로가 무너지는 지점
여러 영역에 걸친 계약은 안전한 병렬 작업을 제한한다
프론트엔드, 백엔드, 데이터베이스, 서비스 변경은 서로 다른 디렉터리에 있다는 이유만으로 항상 병렬 처리할 수 없습니다. 스키마 변경 하나가 API를 깨뜨릴 수 있고, API 변경이 생성 클라이언트를 무효화할 수 있습니다. 공유 유틸리티 하나 때문에 겉보기에는 독립적인 두 수정이 충돌할 수도 있습니다.
Cursor 포럼의 “Monorepo Execution Plan” 기능 요청은 필요한 규율을 잘 보여줍니다. 범위가 제한된 워커에 전역 요구 사항, API 계약, 스키마 변경 내용을 전달한 뒤 코디네이터가 통합 전에 라우트와 타입, 스키마를 검증해야 한다는 내용입니다. 다만 이 글은 기능 요청일 뿐, 현재 이 워크플로의 모든 부분이 즉시 사용할 수 있는 완성형이라는 증거는 아닙니다.
마이그레이션에서는 구현 에이전트를 실행하기 전에 계약부터 고정하세요. 계약을 변경해야 한다면 호환성 단계를 마련하거나, 해당 변경을 코디네이터가 순차적으로 결정할 다음 작업으로 분리하는 편이 좋습니다.
컨텍스트 격리는 동시에 컨텍스트 손실이기도 하다
서브에이전트는 깨끗한 컨텍스트에서 시작하며, 상위 에이전트와 나눈 대화를 자동으로 물려받지 않습니다. 코디네이터는 관련 규칙과 목표 패턴, 제약 조건, 참고 자료를 명시적으로 전달해야 합니다. 짧게 요약하는 과정에서 몇 시간 뒤 중요한 차이를 만드는 예외 조건이 빠질 수 있습니다.
대화 기억에 의존하지 말고 다음과 같은 지속성 있는 결과물을 사용하세요.
migration-plan.md: 범위와 작업 순서migration-ledger.csv: 패키지별 상태와 예외 사항contracts/: API 및 스키마 스냅샷decisions.md: 기각한 대안과 그 이유- 모든 구현 브랜치에 첨부하는 테스트 보고서
이렇게 하면 오래된 의사결정도 관리할 수 있습니다. 지속적으로 작동하는 코디네이터는 이력을 보존할 수 있지만, 이력이 곧 진실을 의미하지는 않습니다. 의존성 업그레이드나 스키마 변경이 발생했거나 기존 시스템의 새로운 동작을 발견했다면 가정을 다시 검증해야 합니다.
에이전트가 많아질수록 비용과 간섭도 커진다
Cursor 문서는 병렬 서브에이전트 5개를 사용하면 비슷한 단일 에이전트 작업보다 토큰을 대략 5배 사용한다고 추정합니다. 같은 문서에 따르면 관리자가 특정 모델을 차단했거나, 플랜에서 해당 모델을 지원하지 않거나, 레거시 플랜에서 Max Mode가 필요한 경우 모델 선택이 다른 모델로 대체될 수 있습니다. 상위 에이전트의 모델만 보고 예산을 계산해서는 안 됩니다.
실사용자 피드백을 보면 명시적인 제어 루프가 필요한 이유가 분명해집니다.
“너무 적으면 메시지가 영원히 대기열에 쌓이고, 너무 많으면 서로 간섭하기 시작한다” — @siggelabor, X
Reddit 토론에서도 서브에이전트가 예상보다 많은 모델 사용량을 소비했다는 사용자 경험과, 위임을 억제하기 위해 .cursorrules를 사용한다는 사례가 공유됐습니다. 다만 해당 규칙이 항상 보장되는 것은 아니라는 지적도 나왔습니다. 동시 실행 수를 제한하고, 탐색에는 저렴한 모델을 배정하며, 계획과 리뷰에는 더 강력한 모델을 남겨두세요. 다음 작업 묶음을 확장하기 전에 사용량도 확인해야 합니다.
테스트 통과만으로는 마이그레이션 완료를 증명할 수 없다
SWE Refactor Bench 프리프린트는 Cursor Projects를 평가할 때 유용한 경고를 제공합니다. 전체 저장소 마이그레이션 작업 20개를 대상으로 520회 실행한 결과, 마이그레이션 감사와 동작 테스트, 적대적 검증을 모두 통과한 실행은 28회, 5.4%에 불과했습니다. 또한 언어 재작성의 평균 점수는 5.6/100이었던 반면, 빌드 도구체인 재작성은 31.4/100으로 나타났습니다.
핵심은 방법론입니다. 마이그레이션에는 기존 스택을 대체했는지 확인하는 관문과 기존 동작을 보존했는지 확인하는 관문이 모두 필요합니다. 소스와 빌드 클로저에서 기존 스택이 사라졌는지 확인하고, 동작을 비교한 다음, 독립적인 검증으로 숨은 차이를 찾아야 합니다. “CI가 통과했다”는 여러 신호 중 하나일 뿐 최종 판정이 아닙니다.
Cursor를 활용해 더 안전하게 마이그레이션하는 방법
- 기존 시스템의 기준선을 만든다. 코드를 바꾸기 전에 빌드 명령, 공개 인터페이스, 대표 출력, 성능에 민감한 경로, 알려진 예외를 기록합니다.
- 읽기 전용 탐색 에이전트에게 저장소를 매핑하게 한다. 패키지와 생성 산출물, 설정, 배포 스크립트, 테스트 공백을 모두 포함합니다.
- 마이그레이션 계획과 장부를 만든다. 디렉터리만이 아니라 동작과 담당 영역을 기준으로 작업을 나눕니다.
- 범위가 제한된 한 작업 단위로 파일럿을 진행한다. 마이그레이션이 끝난 참고 구현을 만들어 명명 규칙, 오류 처리, 호환성, 테스트 관례를 먼저 확립합니다.
- 격리된 브랜치에서 범위가 제한된 구현 에이전트를 실행한다. 각 프롬프트에 정확한 계약과 수정 금지 경로를 명시합니다.
- 작업 단위마다 로컬 검증을 실행한다. 성공을 보고하기 전에 타입 검사, 단위 테스트, 통합 테스트, 빌드 결과, diff 요약을 요구합니다.
- 독립적인 리뷰를 진행한다. 새 컨텍스트의 리뷰어를 사용하고, 위험도가 높거나 여러 영역에 걸친 변경에는 Deep Agent Review를 선택합니다.
- 단계적으로 통합한다. 코디네이터가 계약을 조정하고, 데이터·인증·인프라·공개 API가 관련된 병합은 사람이 승인합니다.
- 차등 검증을 다시 실행한다. 대표 입력과 실패 경로에서 마이그레이션된 시스템을 기준선과 비교합니다.
- 근거가 나빠지면 멈춘다. 대기열과 충돌, 재시도, 리뷰 지적이 늘어난다면 병렬 작업을 늘리는 것은 진전이 아닙니다.
작업 유형별 Cursor Projects 베타 평가
| 작업 유형 | 적합도 | 권장 방식 |
|---|---|---|
| 서로 독립적인 모듈 전반의 반복 작업 | 높음 | 공유 규칙과 격리된 브랜치를 사용해 구현 에이전트를 병렬 실행 |
| 의존성 또는 프레임워크 업그레이드 | 중상 | 먼저 계획을 세우고 한 모듈에서 파일럿을 진행한 뒤 단계적으로 확대 |
| 테스트가 부족한 대규모 언어 재작성 | 중하 | 인벤토리와 제한된 작업 단위에는 에이전트를 활용하되, 동작 검증은 사람이 주도 |
| 서비스 간 스키마 및 API 마이그레이션 | 중간 | 계약 결정은 순차적으로 처리하고, 계약이 안정된 뒤 구현만 병렬화 |
| 지속적인 테스트·PR·의존성 유지보수 | 높음 | 동시 실행 수와 비용을 제한한 상태에서 백그라운드·클라우드 에이전트를 활용 |
| 일회성 포맷 정리 또는 변경 로그 작성 | 낮음 | 명령어나 스킬을 사용하세요. 서브에이전트는 불필요한 오버헤드를 추가합니다. |
| 테스트가 충분한 결정적 대량 이름 변경 | 중간 | 기계적으로 처리할 수 있고 되돌리기 쉬운 변환이라면 스크립트와 CI를 우선 사용 |
제 판단은 이렇습니다. Cursor의 코디네이터·서브에이전트 구조는 저장소에 테스트 가능한 경계가 있고 팀이 브랜치 격리를 강제할 수 있다면 대규모 마이그레이션에 파일럿으로 도입할 가치가 있습니다. 반대로 문서화가 부족하고 동작 커버리지도 약한 시스템이라면 코디네이터를 자율 구현자가 아니라 인벤토리와 검증을 관리하는 역할로 활용하는 편이 낫습니다.
Cursor Projects 베타 FAQ
Cursor Projects 베타는 Cursor 서브에이전트와 같은 기능인가요?
Cursor의 공식 문서는 서브에이전트, 비동기 실행, 클라우드 에이전트, 멀티 에이전트 코딩을 중심으로 구성돼 있습니다. “Projects”는 버전과 계정에 따라 범위가 달라질 수 있는 베타 명칭입니다.
Cursor 서브에이전트를 병렬로 실행할 수 있나요?
가능합니다. 다만 서로 독립적인 작업이라도 충돌을 피하려면 범위와 계약, 격리된 워크트리를 명시적으로 설정해야 합니다.
서브에이전트가 또 다른 서브에이전트를 만들 수 있나요?
Cursor는 중첩 서브에이전트를 문서화하고 있습니다. 트리가 깊어질수록 코디네이션과 토큰, 검증 오버헤드가 커지므로 제한적으로 사용하세요.
노트북을 닫아도 에이전트가 계속 작업하나요?
클라우드 서브에이전트는 자체 가상 머신에서 작업을 계속할 수 있습니다. 다만 Cursor의 설명에 따르면 로컬 MCP 설정이 클라우드에서 자동으로 재사용되지는 않습니다.
서브에이전트마다 특정 모델을 강제로 지정할 수 있나요?
Cursor는 상속 모델이나 특정 모델 지정을 지원합니다. 하지만 관리자 설정과 플랜, 레거시 플랜 규칙에 따라 다른 모델로 대체될 수 있으므로 실제 사용량을 확인해야 합니다.
서브에이전트가 생성되는 것을 막으려면 어떻게 해야 하나요?
작업 지침과 저장소 규칙을 사용한 뒤, 자신의 플랜과 버전에서 실제로 어떻게 동작하는지 확인하세요. 사용자 보고를 보면 이런 제어가 항상 보장되지는 않습니다.
에이전트 군집을 켜기 전에 내려야 할 결정
마이그레이션 작업 단위 하나를 골라 일주일간 파일럿을 진행하세요. 검증되지 않은 회귀가 늘지 않고, 절약한 시간이 코디네이터의 재작업과 리뷰 시간, 모델 사용량 오버헤드를 넘어설 때만 도입을 확대하면 됩니다. 그렇지 않다면 해당 유형의 변경에는 스크립트와 CI, 또는 단일 에이전트를 사용하는 편이 낫습니다.