Claude Code에는 하나의 프롬프트를 팀으로 전환하는 키워드가 있습니다. ultracode를 입력하면 Claude가 여러 에이전트들을 병렬로 배포하여 사용자의 자료를 읽고 교차 확인하게 하는 작은 프로그램을 작성한 다음, 그 결과를 사용자에게 다시 가져다줍니다. 코디네이터 세션(coordinator session)을 추가하면 다른 세션을 시작하고 실행할 수 있으며, 하나의 채팅으로 열 개의 세션에 달하는 프로젝트를 구동할 수 있습니다. 아래에서는 어떤 경우에 유용한지, 그리고 어떻게 프롬프트해야 하는지를 설명한 다음, 저의 프로젝트 중 하나를 예시로 들어 하나의 워크플로우에서 여러 세션의 팀으로 확장하는 방법을 설명하겠습니다.
FT-4는 Qwen3.5-9B를 LoRA와 GRPO(강화학습 (RL) 방법)로 파인튜닝하여 저의 메모리 시스템을 잘 사용하는 개인 비서로 만들려는 시도입니다. 목표 중 하나는 누구나 실행할 수 있는 작은 모델이므로, 저는 몇 세대 전의 8GB 카드인 자체 GTX 1070 Ti에서 4비트로 테스트했습니다. 트레이닝 GPU 비용을 지불하기 전에, 계획을 최대한 어렵게 공격받아 보고 싶었습니다.
저는 그 작업을 ultracode를 켠 Claude Code 세션 하나에 맡기고 악마의 변호사 역할을 하도록 요청했습니다. 두 시간 만에
프롬프트에 'ultracode'라는 단어를 입력하면 해당 턴이 멀티 에이전트 오케스트레이션(multi-agent orchestration)으로 전환됩니다 (docs). Claude가 워크플로우 스크립트를 작성하고 실행하며, 이 스크립트는 병렬 리더나 회의론자(skeptics)와 같이 작업에 필요한 역할을 가진 서브 에이전트들을 분산시킵니다. 그들의 결과는 채팅으로 돌아옵니다. /effort ultracode를 사용하면 세션 전체 동안 활성화 상태가 유지되며, Claude는 어떤 작업들이 워크플로우를 받을 자격이 있는지 결정합니다. /workflows는 진행 중이거나 완료된 실행 목록을 보여줍니다. 저의 코디네이터(coordinator)는 'ultracode'를 켠 채로 Opus 5.5 모델을 xhigh 노력도(effort)에서 실행했고, 모든 실질적인 작업들이 워크플로우를 받았습니다.
코디네이터 기능은 키워드가 필요 없는 경우도 있습니다. 데스크톱 앱의 세션들은 서로 찾아 메시지를 주고받을 수 있으며 (docs; 네이티브 Windows v2.1.234 이상), Claude가 스스로 이러한 호출을 수행하기 때문에 저는 도구 이름을 타이핑한 적이 없습니다. 제 실행에서는 코디네이터가 더 나아가서: 새로운 세션을 시작하고, 각 세션의 요약본(brief)을 작성하며, 그중 하나가 턴을 마칠 때마다 짧은 메모를 받았습니다. 자식 세션들은 위 스크린샷처럼 사이드바에 중첩되어 나타났는데, 제가 문서화된 곳에서는 발견하지 못한 레이아웃입니다.
사용 시점
Ultracode는 세 가지 상황에서 효과적입니다. 자료가 너무 커서 하나의 컨텍스트(context)로는 처리할 수 없지만 깨끗하게 분할될 때, 각 리더가 부분을 맡을 수 있습니다. 주장들이 오직 반대하는 것만을 임무로 가진 에이전트들을 필요로 할 때. 또는 하루치 GPU 렌탈 비용처럼 누락된 단계가 실제 돈으로 비용을 초래할 때입니다. FT-4는 이 세 가지를 모두 갖추고 있었습니다: 기록, 하네스 코드(harness code), 메모, 실행 파일, 읽어야 할 논문들, 공격해야 할 예측들로 가득 찬 계획, 그리고 아직 지불하지 않은 훈련 렌탈 비용이었습니다.
워크플로우의 크기를 질문에 맞게 조정하세요. /config의 '동적 워크플로우 크기(Dynamic workflow size)' 행은 Claude에게 목표로 할 규모를 알려줍니다(기본값은 medium, 즉 10개 미만의 에이전트를 의미하며, Claude는 이를 초과할 수 있습니다). 25개 이상의 에이전트 또는 예상 토큰 수가 150만 개에 달하면 '대규모 워크플로우(Large workflow)' 경고가 표시됩니다. 제가 처음 검토했을 때는 모든 것을 읽어야 했기 때문에 17개의 에이전트를 사용했습니다. 어떤 GPU를 임대해야 하는지에 대한 질문은 단지 세 개만 필요했고, 그들은 하나의 H200을 가장 먼저 순위에 올렸는데, 이는 학습(training)이 단일 GPU에서 실행되고 GRPO 메모리가 선택을 결정하기 때문입니다.
한 줄 수정이나 이미 답을 알고 오직 타이핑만 남은 경우에 대해서는 이 기능을 건너뛰세요. 모든 서브 에이전트는 자체 컨텍스트를 사용하므로, 워크플로우 비용은 신중하게 한 번의 턴(turn)을 하는 것보다 훨씬 많이 들 수 있습니다. 이 키워드는 -p 실행에서는 작동하지 않으며, Alt+W (macOS에서는 Option+W)를 누르면 하나의 프롬프트에 대해서만 이를 해제할 수 있는데, 이는 단어가 다른 이유로 본문에 나타날 때 도움이 됩니다.
워크플로우 프롬프팅 방법
실패가 어떤 모습인지 알려주세요. 에이전트는 당신이 찾으라고 지시하는 것을 찾아냅니다. 그리고 '이 계획을 검토해라(review this plan)'는 아무것도 명시하지 않습니다. 제 과제에서는 무엇이 무효화하거나, 혼란스럽게 하거나, 결과를 약화시킬 수 있는지, 더 저렴한 경로가 같은 목표에 도달할 수 있었는지, 그리고 2025년에서 2026년의 주요 출처들이 뭐라고 말했는지를 요청했습니다. 첫 워크플로우를 시작하고 7분이 지났을 때, 읽기 전용 독자들(read-only readers)은 제가 훈련시키지 않은 하네스(harness)가 이미 예측 범위 안에 있다는 것을 발견했고, 점수 매기는 사람(scorer)이 결과가 나온 후에 변경되었다는 것도 알게 되었습니다.
에이전트들에게 역할을 부여하고, 그들 중 일부를 회의론자로 만드세요. 제가 실행했을 때 Claude는 스스로 역할을 선택했습니다: 오직 읽기만 할 수 있는 독자들, 초록(abstracts) 대신 논문 전체 텍스트를 읽는 에이전트들, 그리고 기본적으로 반박하도록 지시받은 검증자들(verifiers). 이러한 역할들은 이름으로 요청할 수 있습니다. 두 번째 워크플로우에서는 주장 그룹당 열 명의 회의론자를 보냈고, 각자
Claude가 이 스크립트를 작성해 줍니다. 아래는 제가 검증 패스(verify pass)의 형태를 보여주는 의사 코드입니다. 함수 이름(phase, parallel, agent, log, 그리고 전역 변수 args)과, 에이전트가 산문 대신 JSON을 반환하도록 만드는 schema 옵션은 문서에서 가져온 것이며, 여기에 적힌 정확한 시그니처는 제가 근사치로 표현한 것입니다.
// 의사 코드: 저의 검증 패스의 형태이며 실제 스크립트는 아닙니다.
phase("Verify");
const verdicts = await parallel(
...
schema를 사용하면, 각 회의론자(skeptic)가 하나의 판결(verdict) 필드를 반환하고, 코디네이터는 산문을 파싱할 필요 없이 답변들을 병합할 수 있습니다.
완전성 비평가(completeness critic)로 마무리하세요. 이 비평가는 결과물을 당신의 개요(brief)와 비교하여 아무도 확인하라고 요청하지 않은 항목들을 나열하는 에이전트입니다. 저의 두 번째 워크플로우에서는 비평가가 검토 내용을 제 개요와 비교했고, 최종 보고서에는 10개의 블로커(blockers), 27개의 발견 사항(findings) 및 5개의 실험 결과가 포함되었습니다. 나중에 계획을 세우는 워크플로우에서, 최종 수정 전에 비평가를 배치하자 26개의 주장이 수정되었고, 누락된 항목이 18개 추가되었으며, 제가 결정할 수 있는 사안은 단 5가지로 줄었습니다.
필요할 때 중지하고 나중에 재개하세요. 왜냐하면 일시 중지된 워크플로우는 작업을 마친 모든 에이전트의 작업 내용을 보존하기 때문입니다. 저의 계획 워크플로우는 제가 문자 그대로 "stop we resume tomorrow"라고 입력했을 때 절반 정도 완료되었습니다. 다음 날 아침에 저는 "resume"이라고 입력했고, 단지 하나의 검사 및 최종 수정만 다시 실행되었으며; 독자(readers)와 종합(synthesis)은 캐시에서 가져왔습니다. 같은 세션에 머무르는 한, /workflows에서 실행을 선택하고 p를 누르거나 Claude에게 재실행을 요청하여 워크플로우를 재개할 수 있습니다.
하나의 워크플로우에서 코디네이터로
발견 사항이 하나의 채팅창을 초과하면, 각 조각을 자체 세션으로 만들고, 그 세션에 적용할 개요(brief)를 만드세요. 좋은 개요는 먼저 읽어야 할 발견 사항, 산출물(deliverables), 세션이 건드려서는 안 되는 파일들, 그리고 각 종속성(dependency)의 소유자를 명시합니다. 검토 후 저는 모든 문제에 대해 별도의 세션을 요청하는 한 줄을 입력했습니다. 8분 만에 코디네이터는 8개의 세션을 시작하고, 자체적으로 모든 개요를 작성했으며, 각 세션과 그 세션이 다룬 블로커를 매핑한 표를 게시했습니다.
모든 공유 파일에 한 번에 하나의 작성자(writer)를 지정해 줍니다. 제가 진행한 세션 중 여덟 개가 워크트리(worktree) 없이 같은 체크아웃에서 작동했습니다. 그래서 시작하기 전에 코디네이터는 가장 많은 파일을 가진 세션과 파일 소유권 목록을 합의했습니다. 그 후부터는 해당 세션들이 자체적으로 처리했습니다. 하네스 세션은 스코어러 세션에게 'released'라고 답하거나 여전히 자신이 소유한 부분을 명시해 달라고 요청했고, 필요한 규칙을 가지고 파일을 되돌려 받았습니다. 만약 세 번째 세션이 그 파일에 대해 다섯 개의 변경 요청(change requests)을 보내면, 스코어러 세션이 이를 전달하여 '하나의 작성자가 파일을 보유하도록' 했습니다. 다른 저장소에서 작업하는 한 세션은 자체 워크트리를 사용했습니다.
코디네이터가 중계하고 고정된 형식으로 상태를 요청하게 했습니다. 제 역할은 짧은 답변을 하는 것으로 줄어들었고, 코디네이터는 이를 그대로 적절한 세션에 전달했습니다. 제가 '현재 상황이 어때?'라고 입력하자, 200단어 이내의 네 부분(완료됨, 누락됨, 나에게 결정할 사항, 실행 중)으로 아홉 개의 동일한 답변 요청을 보내고, 무엇이 무엇을 막고 있는지 보여주는 하나의 목록으로 병합했습니다. 또한 정체된 상황도 포착했습니다. 한 세션은 약속된 작업이 구축되지 않은 채 90분 동안 유휴 상태였는데, 제가 가볍게 자극하자 11분 만에 결과를 내놓았습니다.
각 유료 리소스에도 한 번에 하나의 소유자를 지정해 줍니다. 제 세션들은 vast.ai에서 임대한 GPU, 저의 VPS(가상 사설 서버), 그리고 저의 자체 카드를 공유했습니다. 첫 번째 임대인 RTX 5090이 실험을 마쳤을 때, 저는 코디네이터에게 정확히 '다른 세션들에게 메시지를 보내: 그들 중 하나가 이 GPU를 필요로 하니 돈을 낭비하지 말자'라고 말했습니다. 그것은 카드(GPU)를 일곱 개의 세션에 제공했고, 제가 임대를 해제하기 전에 트레이닝 파이프라인 세션이 그 위에서 두 개의 작업을 실행했습니다. 두 번째 임대는 대기열(queue)의 실험들을 처리했습니다. 각 작업은 이전 실행 보고서가 통과했다고 말할 때만 시작되었는데, 보고서 파일은 실패 후에도 존재했기 때문에 파일을 찾는 것만으로는 아무것도 증명하지 못했습니다. GPU가 바쁠 동안, 코디네이터는 유휴 세션들에게 지출을 늘리지 않는 작업을 제공했습니다.
돈 결정은 당신과 함께 유지하고, 하드캡을 설정하세요. 모든 API 지출은 제가 직접 생성하고 충전한 OpenRouter 키를 통해 이루어졌으며, 이 키는 USD 50으로 제한되었습니다. 세션들은 요청할 수는 있었지만 생성할 수는 없었습니다. 제 VPS의 야간 대기열은 키가 최소 USD 9 이상을 유지했을 때만 마지막 실험을 실행했습니다. 지출 승인은 세션 간에 전송되지도 않았습니다. 한 세션이 동료를 통해 제가 '예'라고 전달한 실험을 수행하기를 거부했고, 코디네이터는 두 세션 모두가 자체 채팅창에 진행 승인을 입력해야 한다고 말했습니다. 그 때문에 저는 몇 번의 채팅 전환 비용을 지불하게 되었는데, 저는 이 방식이 좋습니다. 제 돈을 쓰는 세션은 저에게서 '예'라는 말을 들어야 합니다.
기대할 것들
가장 먼저 예상할 것은 결정들이 유지된다는 것입니다. 첫 번째 워크플로우 후 이틀 뒤, 임대한 GPU에서 실행한 테스트는 훈련되지 않은 하네스(harness)의 발견을 확인시켜 주었습니다. 즉, 훈련이 없는 하네스가 '모든 측정 및 검색 지표에서 이미 훈련된 대역과 일치한다'는 것입니다. 이는 모델이 메모리에 저장하기로 결정하는 부분만이 여전히 가치를 더할 수 있는 유일한 장소임을 남겼고, 저는 어떤 훈련 비용을 지불하기도 전에 이를 배웠습니다.
세션들은 또한 무언가를 구축했습니다. 이틀 동안 그들은 스코어러(scorer)와 보상 모듈을 제작했는데, 이 모듈에는 각각 최소 하나의 의도적인 코드 오류로 인해 실패한 189개의 새로운 테스트 케이스가 포함되어 있었습니다. 또한 봉인된 테스트 분할(sealed test splits)을 가진 사용자의 새로운 시뮬레이션 환경과 4비트 서빙에 대한 수정 사항도 만들어냈습니다. 한 세션은 실험 실행을 정확하게 재현하기 위해 자체 세션을 시작했습니다. 네트워크 오류로 코디네이터와 두 자식 프로세스가 동시에 중단되었을 때, 저는 'Riprova'(재시도)라고 입력했고, 각 세션은 무언가를 다시 수행하기 전에 이미 완료된 것을 확인했습니다. 목표는 내내 작고 동일한 카드로 유지되었습니다: 임대가 끝난 후, 마지막 모델 적합(model fit)은 제 GTX 1070 Ti에서 실행되었습니다.
하나의 세션으로 충분할 때
작업이 한 세션 내에서 완료되거나, 또는 10개 세션이 생성하는 결과를 실시간으로 검토할 수 없을 때 코디네이터를 건너뛰세요. 저는 모든 결과에 대한 유일한 승인자였습니다. 토큰 사용량은 측정하지 않았기 때문에 비용을 알려드릴 수는 없습니다. 장기간 운영 시에는 코디네이터 자체의 컨텍스트가 가득 차게 됩니다. 제 것은 2일 만에 소진되었고 요약본으로 이어 나갔습니다.
첫 단계
실행하려는 계획(예: 디자인 또는 사전 등록) 중 하나를 선택하고, ultracode: 이 계획을 반박해 봐라, 주장당 한 명의 회의론자, 기본적으로 반박, 읽기 전용과 같은 내용을 입력하세요.
