Cursor 3가 병렬 AI 에이전트를 출시했습니다. 실제로 작동하는 멀티 에이전트 워크플로우를 소개합니다.

2026년 4월 2일, Cursor는 버전 3.0을 출시하며 이를 "에이전트와 함께 소프트웨어를 구축하기 위한 통합 워크스페이스"라고 명명했습니다. 핵심 기능은 Agents Window(에이전트 창)입니다. 이는 모든 리포지토리(repo)에 걸쳐 로컬(local) 또는 클라우드(cloud)에서 실행 중인 모든 활성 에이전트 세션을 한눈에 보여주는 사이드바입니다.

저는 지난 3주 동안 실제 코드베이스에서 이를 실행해 보았으며, 그 경험은 이전의 그 어떤 AI 코딩 도구와도 충분히 다를 만큼 차별화되어 제대로 된 워크스루(walkthrough)를 진행할 가치가 있다고 판단했습니다. 단순한 데모가 아닙니다. 오류가 발생하는 부분까지 포함된 실제 워크플로우입니다.

TL;DR (요약)

1. Agents Window의 실제 정체

Cursor 3 이전에는 창 하나당 하나의 에이전트 세션만 가질 수 있었습니다. 여러 개의 Cursor 창을 열 수는 있었지만, 이들을 통합하여 볼 수 있는 뷰(view)는 없었습니다. Agents Window는 모든 활성 세션을 단일 사이드바 패널로 수집함으로써 이 문제를 해결합니다.

Cmd+Shift+P를 누르고 "Agents Window"를 검색하여 열 수 있습니다. 그러면 현재 실행 중인 모든 에이전트의 목록이 나타납니다: 에이전트를 시작한 작업(task), 대상 리포지토리(repo), 그리고 로컬(local)에서 실행 중인지 클라우드(cloud)에서 실행 중인지 여부를 확인할 수 있습니다. 어떤 세션이든 클릭하여 채팅 기록과 파일 차이(diff)를 확인하고, 에이전트의 방향을 재설정(redirect)할 수 있습니다.

실질적인 변화는 가시성(visibility)입니다. 이전에는 세 개의 에이전트를 병렬로 실행하려면 세 개의 브라우저 탭을 띄우고 끊임없이 Alt-Tab을 눌러야 했습니다. 이제는 세 개의 행이 있는 하나의 패널만 있으면 됩니다.

하지 못하는 것: 에이전트의 출력을 자동으로 병합하지 않으며, 두 에이전트가 동일한 파일에 쓰는 것을 방지하지도 않고, 세션 간의 순서를 강제하지도 않습니다. 그러한 조정(coordination)은 여전히 사용자의 몫입니다. 이것이 바로 단순한 기능이 아닌 워크플로우(workflow)가 필요한 정확한 이유입니다.

2. 두 가지 실행 대상과 각각의 사용 시점

Cursor 3는 에이전트가 실행될 수 있는 두 가지 장소를 제공합니다.

로컬 에이전트 (Local agents)

로컬 에이전트 (Local agent)는 Composer 2 모델을 사용하여 사용자의 열려 있는 워크스페이스 (Workspace) 내에서 실행됩니다. 이 에이전트는 파일 시스템 (File system), 터미널 (Terminal), 그리고 LSP (Language Server Protocol)에 접근할 수 있습니다. 함수 리팩터링 (Refactor)을 요청하면, 에이전트가 파일을 읽고 변경 사항을 작성하며, 사용자는 즉시 차이점 (Diff)을 확인할 수 있습니다. 대부분의 작업에서 프롬프트 (Prompt) 입력부터 편집 완료까지의 왕복 시간 (Round trip)은 5~15초 내외로 소요됩니다.

작업의 시간 범위 (Time horizon)가 짧을 때, 작업이 진행되는 과정을 실시간으로 지켜보고 싶을 때, 또는 사용자가 직접 편집 중인 파일에 작업이 영향을 미칠 때 로컬 에이전트를 사용하세요. Composer 2 모델은 빠르며, 파일에 직접 접근할 수 있기 때문에 사용자의 워크스페이스 상태를 가장 잘 파악하는 모델입니다.

클라우드 에이전트 (Cloud agents)

클라우드 에이전트는 Cursor의 인프라 (Infrastructure)에서 실행됩니다. 노트북을 닫더라도 작업은 계속 유지됩니다. 긴 리팩터링 작업을 큐 (Queue)에 쌓아두고 노트북을 덮은 뒤, 4시간 후에 돌아오면 리뷰 준비가 완료된 PR (Pull Request)을 확인할 수 있습니다. 클라우드 에이전트는 결과물의 스크린샷과 데모 녹화 영상을 생성하므로, 머지 (Merge)하기 전에 검증할 수 있습니다.

작업이 사용자가 계속 지켜보기에는 너무 오래 걸릴 때, 하나 이상의 리포지토리 (Repository)를 넘나들며 작업할 때, 또는 Slack, GitHub, Linear에서 트리거되는 자동화 (Automation)를 실행할 때 클라우드 에이전트를 사용하세요. 또한 Cursor Marketplace에서는 외부 도구 접근을 통해 클라우드 에이전트의 기능을 확장하도록 특별히 설계된 서브 에이전트 (Subagent) 플러그인도 제공합니다.

로컬과 클라우드 간의 전환 (Handoff)은 양방향으로 이루어집니다. 로컬에서 작업을 시작했다가 범위가 확장되었다고 판단되면 클라우드로 넘길 수 있습니다. 반대로 클라우드에서 나온 결과물을 로컬 세션으로 가져와 LSP 컨텍스트 (Context)를 활용해 최종 정리 작업을 수행할 수도 있습니다.

3. 실제 사례: 3개의 에이전트로 분할된 파이프라인 리팩터링

다음은 제가 지난주에 수행한 실제 분할 작업 사례입니다. 해당 서비스는 로깅 (Logging)을 구조화된 JSON으로 교체하고, 에러 핸들링 (Error handling)을 표준화하며, 테스트 커버리지 (Test coverage)를 채워 넣어야 했습니다. 이 세 가지 작업은 서로 다루는 파일이 거의 겹치지 않는 별개의 작업이었습니다.

설정 (Setup)

# 브랜치 충돌을 방지하기 위해 각 에이전트별로 worktree 생성
git worktree add ../refactor-logging feature/structured-logging
git worktree add ../refactor-errors feature/error-handling
...

Git worktree를 사용하면 각 에이전트가 별도의 브랜치에서 자신만의 작업 디렉토리 (working directory)를 갖게 됩니다. 에이전트들이 작업 트리 (work tree)를 공유하지 않으므로, 파일 수준에서의 쓰기 충돌 (write conflicts)이 발생하지 않습니다. Agents Window (에이전트 창)에는 여전히 세 가지 작업이 동일한 사이드바에 표시됩니다.

프롬프트 구조 (Prompt structure)

각 에이전트는 범위가 지정된 프롬프트 (scoped prompt)를 할당받습니다. 로깅 (logging) 에이전트의 경우:

src/services/ 내의 모든 console.log 및 console.error 호출을
src/lib/logger.ts에 있는 구조화된 로거 (structured logger)를 사용하도록 리팩터링하세요. 출력은 반드시
level, message, context 필드를 포함하는 JSON 형태여야 합니다. 함수를 변경하지 마세요.
...

에러 (error) 에이전트의 경우:

src/services/ 내의 모든 try/catch 블록을 src/errors/app-error.ts에 있는
AppError 클래스를 사용하도록 표준화하세요. 원래의 에러를 cause 속성으로 사용하여
다시 던지세요 (Rethrow). 로깅 호출은 변경하지 마세요.
...

테스트 (test) 에이전트의 경우:

Vitest를 사용하여 src/services/에 대한 누락된 단위 테스트 (unit tests)를 추가하세요.
첨부된 lcov.info에 따라 가장 낮은 커버리지 (coverage)를 가진
내보내진(exported) 세 개의 함수를 포함하세요. 소스 파일은 편집하지 마세요.

처음 두 프롬프트에 포함된 "테스트 파일을 건드리지 마세요"라는 제약 조건은 선택 사항이 아닙니다. 이 조건이 없으면 에이전트들이 공유 파일을 건드리는 방향으로 이탈하게 되며, 결국 세 에이전트 모두가 자신들이 src/lib/logger.ts를 소유하고 있다고 생각하는 상황이 발생합니다.

Agents Window에서의 모니터링 (Monitoring in the Agents Window)

세 에이전트가 모두 실행되는 동안, Agents Window는 각 세션의 현재 파일과 마지막 작업 (last action)을 보여줍니다. 에이전트가 실행되는 과정을 계속 지켜보는 것이 아니라, 10분마다 한 번씩 확인하며 에이전트가 동작을 멈췄는지 또는 잘못된 선택을 했는지 체크합니다.

가장 흔한 실패 모드 (failure mode)는 에이전트가 하나의 하위 작업 (subtask)을 완료한 후, 자신의 범위를 벗어난 인접 파일에 대해 "개선 (improvements)"을 시작하는 것입니다. 이를 조기에 포착해야 합니다. 각 세션 탭 내부의 디프 뷰 (diff view)를 통해 에이전트가 커밋 (commit)을 위해 대기열에 올려둔 파일이 정확히 무엇인지 확인할 수 있습니다.

결과 병합하기 (Merging the results)

각 에이전트는 자신만의 브랜치 (branch)에서 실행됩니다. 세 가지 작업이 모두 완료되면, 병합 (merge) 순서가 중요합니다. 먼저 로깅 (logging) 변경 사항을 병합하십시오. 에러 핸들링 (error handling)은 로거 (logger)가 정확해야 하기 때문입니다. 두 번째는 에러 핸들링입니다. 세 번째는 테스트 (tests)입니다. 테스트는 두 기능 모두를 실행하기 때문입니다.

git checkout main
git merge feature/structured-logging
git merge feature/error-handling
...

마지막 병합 후에만 실행하는 것이 아니라, 각 병합이 끝날 때마다 테스트 스위트 (test suite)를 실행하십시오. 만약 테스트 병합이 실패한다면, 이전의 두 병합 중 어떤 것이 문제를 일으켰는지 알아야 합니다.

4. 오케스트레이션 (orchestration) 시 주의사항

병렬 에이전트 (parallel agents)는 상태 (state)를 공유하지 않는 작업에서 순차적 에이전트 (sequential agents)보다 빠릅니다. 하지만 단일 에이전트 세션에서는 피할 수 있는 세 가지 범주의 실패를 유발합니다.

파일 충돌 (File conflicts)

두 에이전트가 동시에 동일한 파일에 쓰기 작업을 수행하면, 두 에이전트 모두 인지하지 못하는 병합 충돌 (merge conflict)이 발생합니다. 유일하게 신뢰할 수 있는 예방법은 프롬프트 스코핑 (prompt scoping)입니다. 각 에이전트에게 자신이 소유한 디렉토리 목록과 건드려서는 안 될 명시적인 목록을 제공하십시오. 워크트리 (worktrees)는 파일 시스템 레벨에서 도움이 되지만, 두 에이전트가 서로 다른 브랜치에서 동일한 경로를 편집하는 것을 방지하지는 못합니다.

만약 이 단계를 건너뛰어 충돌이 발생했다면, 세 번째 에이전트에게 해결을 요청하지 마십시오. 병합 충돌은 수동으로 해결하십시오. 에이전트가 3-way 충돌 (three-way conflict)을 올바르게 해결하는 데 필요한 컨텍스트 (context)는 대개 유용한 프롬프트에 담을 수 있는 범위를 넘어섭니다.

브랜치 분기 (Branch divergence)

충분히 오래 실행되는 에이전트는 수동 리베이스 (rebase)가 필요한 방식으로 메인 (main) 브랜치에서 분기되기 시작합니다. 월요일 아침에 시작된 4시간짜리 클라우드 에이전트 작업은, 작업이 끝났을 때 에이전트가 보지 못했던 12개의 커밋 (commits)이 포함된 메인 브랜치로 돌아올 수 있습니다. 특히 활발하게 사용되는 리포지토리 (repos)에서는 병합 전 리베이스를 위한 시간을 확보하십시오.

# 에이전트 브랜치를 병합하기 전에 리베이스하십시오
git checkout feature/structured-logging
git rebase main
...

비용 상한선 (Cost ceiling)

비용 상한선 (Cost ceiling)

병렬로 실행되는 세 개의 에이전트는 하나가 실행될 때보다 토큰을 세 배 빠르게 소모합니다. 로컬 에이전트 (Local agents)는 사용자의 Cursor 구독 할당량을 사용합니다. Cursor는 클라우드 에이전트 (Cloud agents)에 대해 컴퓨팅 시간만큼 별도로 비용을 청구하지만, 작성 시점의 공개 문서에는 분당 요율이 명시되어 있지 않습니다. 첫 실행 시에는 각 에이전트가 2시간 이내에 완료될 수 있도록 범위를 설정하세요. 해당 실행을 통해 실제 토큰 및 시간 비용을 파악할 수 있으며, 이후 더 긴 작업에 대해 조정할 수 있습니다.

에이전트 창 (Agents Window) 버전 3.4에는 세션당 비용을 보여주는 내장 디스플레이가 없습니다. 전체 사용량은 계정 설정에서 확인할 수 있습니다. 세션별 비용 가시성이 필요한 경우, 작업 시작 시간을 기록하고 세션이 종료된 후 계정 사용량을 확인하십시오.

결론 (The bottom line)

에이전트 창 (Agents Window)은 마법이 아닙니다. 여전히 직접 설계해야 하는 병렬 작업을 위한 조정 인터페이스 (Coordination surface)로 취급하십시오. 이 기능이 실제로 저에게 효과가 있었던 규칙은 다음과 같습니다: 각 에이전트를 당신이 건네주는 파일만 읽는 풀 리퀘스트 (Pull request) 리뷰어처럼 대하십시오. 범위를 정하고, 브랜치를 만들고, 다시 범위를 정한 다음, 실행하십시오.

진정한 이득은 단일 작업의 속도가 아닙니다. 이득은 이전에 순차적으로 세 번의 오후가 걸렸던 세 개의 독립적인 작업이 이제는 한 번의 오후 만에 끝난다는 점입니다. 오케스트레이션 비용 (Orchestration tax)은 실제로 존재하지만, 적절한 유형의 작업에서는 3배의 속도로 보답합니다.

여러분은 어떤 종류의 작업을 에이전트 간에 나누고 계신가요? 처음 90분 동안의 댓글 스레드에서는 보통 제가 시도해보지 않은 접근 방식들이 나타나곤 합니다. 아래에 여러분의 의견을 남겨주세요.

GDS K S · thegdsks.com · X에서 팔로우 @thegdsks

병렬 에이전트는 에이전트 사이의 연결 부위 (Seams)를 직접 설계할 때에만 더 빠릅니다.