Cursor 3의 병렬 에이전트가 템플릿의 구성 방식을 바꾸는 이유

Cursor 3는 "Build in Parallel(병렬 빌드)"이라는 기능을 출시했습니다. 핵심 개념은 간단합니다. 계획을 단계별로 하나씩 실행하는 대신, Composer가 어떤 단계들이 독립적인지 식별하여 이를 동시 실행되는 서브 에이전트(subagents)로 실행하는 것입니다.

이는 진정한 변화입니다. 그리고 유용한 프로덕션 템플릿(production template)이 어떤 모습을 갖춰야 하는지도 변화시킵니다. 왜냐하면 병렬 에이전트는 단일 스레드(single-threaded) 방식에서는 결코 발생하지 않았던 방식으로 모호한 컨벤션(conventions)에 대가를 치르게 만들기 때문입니다.

무엇이 변했나

Cursor의 2026년 5월 릴리스 노트는 이를 다음과 같이 설명합니다: Composer는 계획을 의존성 그래프(dependency graph)로 분해하고, 공유 쓰기(shared writes)가 없는 브랜치들을 식별하여 이를 비동기 서브 에이전트(async subagents)에게 할당합니다. 사용자는 작업 트리(tree of tasks)가 가장 긴 단일 브랜치가 소요되었을 시간만큼—전체 합계가 아닌—완료되는 것을 지켜보게 됩니다.

이 방식은 실제로 작동합니다. 우리는 일반적인 키트 작업("엔드 투 엔드로 새로운 엔티티 추가: 스키마, API 라우트, 목록 페이지, 상세 페이지, 타입, prompts.md 행")에 대해 테스트를 진행했습니다. 선형 계획(Linear plan): 6분 40초. 병렬 계획(Parallel plan): 2분 10초. 세 개의 서브 에이전트가 세 개의 파일을 동시에 작성하고, 작업이 완료되면 네 번째 서브 에이전트가 인덱스 내보내기(index export)를 연결합니다.

흥미로운 점은 속도 향상이 아닙니다. 세 개의 모델 인스턴스(model instances)가 동시에 코드베이스를 편집할 때 무엇이 망가지는가 하는 점입니다.

즉시 발생한 세 가지 문제

1. 공유 배럴 파일(Shared barrel files). 모든 서브 에이전트가 자신의 새로운 컴포넌트를 packages/ui/src/index.ts에 알파벳 순서로 추가하려고 했습니다. 그들은 서로의 대기 중인 편집 사항을 볼 수 없었습니다. 결과: 세 번의 거의 동시적인 쓰기가 발생했고, 두 번의 쓰기가 세 번째 쓰기를 조용히 덮어씌웠습니다.

해결책: 에이전트의 경로에서 배럴 파일을 완전히 제외하십시오. 이제 우리는 사람이 관리하는 하나의 index.ts를 두고, CLAUDE.md에 금지 목록(forbid-list)을 작성합니다:

## Forbidden files (agents must NEVER edit)
- `packages/ui/src/index.ts` — barrel, hand-curated, edited solo
- `apps/landing/data/component-registry.ts` — gallery wiring
...

2. 병렬 브랜치 간의 컨벤션 드리프트(Convention drift). 한 서브 에이전트는 react-colorful을 선택했습니다. 동일한 작업을 수행하던 다른 에이전트는 react-color를 선택했습니다. 둘 다 작업을 완료했습니다. 이제 당신의 코드베이스에는 두 개의 컬러 피커(color pickers)가 존재하게 됩니다.

수정: .cursorrules 내의 라이브러리 고정(lock)을 계획(plan)이 생성된 후의 코드 리뷰 단계가 아니라

Cursor 3의 Background Agents가 이를 더욱 심화시킵니다. 백그라운드 에이전트(Background Agent)는 사용자가 다른 작업으로 넘어간 지 한참 뒤에야 작업을 마칩니다. 만약 해당 에이전트가 방금 당신이 수정한 배럴 파일(barrel file)에 병합(merge)을 수행한다면, 당신의 포그라운드(foreground) 상태는 잘못된 상태가 되지만 당신은 그 사실을 알지 못합니다.

우리의 새로운 규칙은 다음과 같습니다: 백그라운드 에이전트의 범위를 하나의 기능 디렉토리(feature directory)로 제한하며, 그 외의 영역을 건드리는 것을 금지합니다. 동일한 금지 목록(forbid-list)이 이 역할을 수행합니다. 이 규칙은 에이전트가 포그라운드(foreground)이든 백그라운드(background)이든 상관없이 적용됩니다.

키트 구매자들에게 의미하는 바

키트에는 금지 목록(forbid-list), 고정된 라이브러리(locked libraries), 그리고 의존성 그래프(dependency-graph) 스타일의 프롬프트가 이미 연결된 상태로 제공됩니다. pnpm dlx create-otf-app을 실행하고 Cursor를 열면, Composer가 CLAUDE.md를 읽고 제약 사항을 확인한 뒤, 서로 충돌하지 않는 병렬 작업(parallel work)을 할당합니다.

핵심은 단순히 "Cursor 3가 좋다"는 것이 아닙니다. Cursor 3가 좋은 것은 사실이며, 그것은 새로운 소식이 아닙니다. 진짜 소식은 병렬 에이전트 실행(parallel agent execution)으로 인해 이제는 관례(convention)의 품질이 병목 현상(bottleneck)이 된다는 점입니다. 기계가 읽을 수 있는 관례(machine-readable conventions)를 제공하지 않는 템플릿은 모델이 느려서가 아니라, 사람이 계속해서 에이전트의 뒷처리를 해야 하기 때문에 느리게 느껴지기 시작할 것입니다.

만약 당신만의 키트를 구축하고 있다면, 세 개의 병렬 서브 에이전트(subagents)를 염두에 두고 .cursorrules와 CLAUDE.md를 작성하십시오. 그것이 현재의 기준입니다.