Claude를 Cursor Cloud Agent를 위한 오케스트레이터(Orchestrator)로 전환하기
요약
Claude를 단순한 채팅 인터페이스가 아닌 Cursor Cloud Agent를 관리하는 제어 평면(Control Plane)으로 활용하는 새로운 아키텍처를 제안합니다. MCP를 통해 여러 에이전트를 오케스트레이션하여 복잡한 워크플로우를 자동화하고 관리 오버헤드를 줄이는 방법을 다룹니다.
핵심 포인트
- AI 클라이언트를 단일 도구 제공자가 아닌 에이전트 함대 관리용 제어 평면으로 전환
- MCP를 활용해 Cursor의 관리형 환경을 원격 컴퓨팅 클러스터처럼 운용
- 작업별로 최적화된 모델(Gemini, Claude 등)과 페르소나를 지정하여 에이전트 생성 가능
- 에이전트의 라이프사이클과 실행 컨텍스트를 정의하여 개입 없는 엔지니어링 구현
자율 에이전트(autonomous agents)의 문제는 코드를 작성하는 능력이 아니라, 대규모로 이들을 관리할 수 없는 우리의 무능력함에 있습니다.
Cursor를 사용해 본 적이 있다면, 작업을 실행해 놓고 본질적으로 '잘 되기를 바라는' 기분을 알고 있을 것입니다. 에이전트를 실행하고 자리를 비우면서, 에이전트가 한 달 치 크레딧 한도를 전부 써버리거나 저장소(repos) 곳곳에 미완성된 브랜치들을 지저분하게 남겨두지 않기를 기도하곤 하죠. 에이전트가 하나일 때는 괜찮습니다. 하지만 여러 저장소나 작업에 걸쳐 복잡한 워크플로우를 오케스트레이션(orchestrate)하려고 하면, 진행 상황을 확인하고, 파일을 검증하며, 비용을 모니터링하는 수동 오버헤드가 자동화의 목적 자체를 무색하게 만드는 병목 현상이 됩니다.
최근 저는 다른 패턴을 시도하기 시작했습니다. AI 클라이언트(Claude 또는 Cursor와 같은)를 단순한 '채팅 인터페이스'가 아니라 '제어 평면(control plane)'으로 취급하는 것입니다. Cursor Cloud Agent MCP를 사용함으로써, '코드와 채팅하기'에서 '함대(fleet)를 오케스트레이션하기'로 전환할 수 있습니다.
아키텍처: 챗봇에서 제어 평면으로
여기서 핵심 아이디어는 디커플링(decoupling, 분리)입니다. 여러분에게는 상위 수준의 오케스트레이터(대화 중인 LLM)와 실행 환경(Cursor Cloud Agents)이 있습니다.
대부분의 사람들은 MCP 서버를 사용하여 AI에게 'Google 검색'이나 '이 파일 읽기'와 같은 단일 도구를 제공합니다. 이는 유용하지만, 실행의 매 단계마다 여전히 사람이 개입(human in the loop)해야 합니다. 이 특정 MCP를 사용하면 Cursor의 관리형 환경을 원격 컴퓨팅 클러스터(remote compute cluster)로 취급할 수 있습니다. 여러분은 에이전트에게 코드를 작성하라고 요청하는 것이 아니라, 기존 인프라에 특화된 작업을 실행하도록 명령하는 것입니다.
함대 정의하기: 에이전트 생성 및 모델 선택
첫 번째 빌딩 블록은 create_agent입니다. 표준 설정에서는 현재 채팅 세션이 제공하는 모델에 갇히게 됩니다. 하지만 여기에서는 각 특정 작업에 대해 페르소나(persona)와 기반 엔진을 정의할 수 있습니다.
단일 통합 인터페이스 내에서 Gemini 2.5 Pro를 사용하여 문서화에 특화된 에이전트를 실행하거나, Claude 3.5 Sonnet을 사용하여 복잡한 로직에 최적화된 에이전트를 실행할 수 있습니다. 이 방식의 묘미는 저장소(repository)와 모드(agent vs plan)를 미리 구성할 수 있다는 점입니다. 덕분에 '오케스트레이터(orchestrator)'는 컨텍스트 윈도우(context window)를 걱정할 필요가 없습니다. 원격 에이전트가 이를 처리하기 때문입니다.
제가 create_agent를 사용할 때는 단순히 프롬프트(prompt)를 주는 것이 아닙니다. 고유한 라이프사이클(lifecycle)을 가진 자율적인 유닛(unit)을 설정하는 것입니다. 저장소 URL을 제공할 수 있으며, autoCreatePR을 활성화할지 여부를 사전에 결정할 수 있습니다. 바로 이 지점에서 '핸즈오프(hands-off, 개입 없는)' 엔지니어링이 시작됩니다.
실행 루프(Execution Loop): 실행 트리거 및 기능 주입
진정한 힘은 create_run에 있습니다. 대부분의 개발자가 이 부분을 놓치곤 합니다. 만약 이 MCP가 단순히 작업을 시작하는 것에 불과하다고 생각한다면, 그것은 과소평가하는 것입니다.
create_run 도구를 사용하면 mcp_servers_json 파라미터를 전달할 수 있습니다. 이것이 핵심입니다. 이는 Cursor Cloud Agent가 격리된 환경에서 자율적으로 실행되는 동안, 실행 컨텍스트(execution context)에 다른 MCP 서버들을 주입할 수 있음을 의미합니다.
다음과 같은 워크플로우를 상상해 보세요:
- Claude에게 명령합니다: '인증(auth) 서비스에 버그 수정(bug-fix) 에이전트를 실행해줘.'
- 오케스트레이터가 MCP를 통해
create_run을 트리거합니다. - 해당 실행(run)에 Jira 인스턴스나 Sentry 로그에 접근할 수 있는 MCP 서버가 주입됩니다.
- Cursor Cloud Agent가 Sentry에서 에러를 자율적으로 읽고, 저장소에서 해당 코드를 찾아 수정하며, PR(Pull Request)을 생성합니다.
여러분은 통합을 위한 코드를 단 한 줄도 작성하지 않고 폐쇄 루프(closed-loop) 자동화 파이프라인을 구축한 것입니다. 도구를 통해 도구를 오케스트레이션하고 있는 것입니다.
관측 가능성(Observability): 아티팩트(Artifacts)와 사용량을 통한 혼돈 관리
엔지니어로서 저는 모니터링할 수 없는 것은 신뢰하지 않습니다. 자율 에이전트는 진행 상황을 '환각(hallucinating)'하기로 악명이 높습니다. 작업이 완료되었다고 말할 수는 있지만, 실제로 약속한 파일들을 생성했는지는 별개의 문제입니다.
list_artifacts 도구가 이 문제를 해결합니다. 이 도구를 사용하면 실행 중에 정확히 어떤 파일들이 생성되거나 수정되었는지 쿼리할 수 있습니다. 채팅 컨텍스트 내에서 파일 경로와 크기를 직접 확인할 수 있습니다. 에이전트가 실제로 지침을 따랐는지 확인하기 위해 git 브랜치를 일일이 뒤져볼 필요가 없습니다.
다음은 비용 문제입니다. 우리는 모두 LLM 기반의 루프가 토큰 소비를 통제 불능 상태로 만드는 것을 본 적이 있습니다. get_agent_usage 도구는 에이전트별, 또는 특정 실행별로 입력(input), 출력(output), 캐시(cache) 토큰에 대한 꼭 필요한 가시성을 제공합니다. 이러한 작업들을 오케스트레이션(orchestrate)하는 동안 실시간으로 비용 소모율(burn rate)을 모니터링할 수 있습니다. 이를 통해 AI는 '블랙박스(black box)' 형태의 비용 센터에서 CI/CD 파이프라인의 측정 가능한 구성 요소로 변모합니다.
거버넌스 (Governance): 킬 스위치 (Kill Switch)
마지막으로, 터미널 작업(terminal operations)에 대해 이야기해야 합니다. AI 에이전트에게 더 많은 자율성을 부여하는 시대에, cancel_run은 아마도 이 세트에서 가장 중요한 도구일 것입니다. 실행이 정체되거나 모니터링 도구를 통해 토큰 사용량이 급증하는 것을 발견하면, 즉시 이를 중단할 수 있는 방법이 필요합니다. 이것은 단순한 '소프트 삭제(soft delete)'가 아닙니다. 폭주하는 프로세스가 계속해서 리소스를 소비하지 않도록 보장하는 터미널 작업입니다.
또한 archive_agent를 사용하여 환경을 정리할 수도 있습니다. 이러한 에이전트들의 라이프사이클(lifecycle)을 관리하는 것—오래된 에이전트를 아카이브하고 필요한 것만 복구하는 것—이 엔지니어링 팀이 자체 자동화 도구로 인해 발생하는 기술 부채(technical debt)에 빠지지 않게 유지해 주는 핵심입니다.
결론 (The Bottom Line)
AI를 '코파일럿 (copilot)'으로 사용하는 것에서 '컨트롤 플레인 (control plane)'으로 사용하는 것으로의 전환은 에이전트 워크플로우 (agentic workflows)에 진심인 사람들에게 다음 단계의 논리적인 진보입니다. 이는 수동적인 프롬프팅 (manual prompting)에서 벗어나 구조화된 오케스트레이션 (structured orchestration)으로 나아갈 것을 요구합니다.
이 MCP를 활용함으로써 여러분은 단순히 기능을 추가하는 것이 아닙니다. Claude나 Cursor가 두뇌 역할을 하고 Cursor Cloud가 근육 역할을 수행하는 인프라를 구축하는 것이며, 이 모든 과정에서 프로덕션급 엔지니어링에 필요한 가시성과 통제력을 유지할 수 있습니다.
전체 설정 및 구성 세부 사항은 여기에서 확인할 수 있습니다: https://vinkius.com/mcp/cursor-cloud-agent. 에이전트를 직접 관리하는 것을 멈추고 오케스트레이션 (Orchestration)을 시작하고 싶다면, 5분 정도의 설정 시간을 투자할 가치가 있습니다.
MCP는 AI 에이전트의 음악입니다. 저희가 그 카탈로그를 만들었습니다. Vinkius MCP Catalog를 확인해 보세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기