저는 ultracode를 켜 두면 무조건 좋은 줄 알았습니다.

/effort 다이얼에서 제일 높은 단계니까요. 뭐든 더 잘하겠지 — 그렇게 생각하고 한동안 거의 모든 작업을 이 단계로 돌렸습니다.

반은 맞았습니다. 글을 발행하기 전에 검수를 통째로 맡겨 봤더니, 제가 놓친 표기 오류까지 잡아냈습니다. 반은 틀렸습니다. 함수 하나 고치기, 짧은 질문 같은 일은 시간과 토큰만 늘었지 나아진 게 없었습니다.

저는 필요할 때만 프롬프트 창에 ultracode를 입력해 쓰는 편입니다. 왜 이 방법이 더 좋은지, 본문에서 설명해 드리겠습니다.

(여기서 말하는 ultracode는 Claude Code의 설정입니다. 켜는 조건과 버전은 맨 아래 적어뒀습니다.)

더 깊이 생각하는 단계가 아닙니다

먼저 오해 하나를 풀어야 합니다. /effort 다이얼 맨 위 칸이니 추론도 제일 깊을 것 같지만, 그렇지 않습니다. ultracode의 추론은 xhigh 수준이고, 추론 깊이만 보면 max가 더 깊습니다. ultracode가 맨 위에 있는 건 추론을 더 올려서가 아닙니다. xhigh 추론에 워크플로 오케스트레이션을 얹은 단계입니다.

평소의 Claude는 시킨 일을 혼자 처음부터 끝까지 붙들고 답합니다. ultracode를 켜면 이게 달라집니다. 큰 일이 들어오면 직접 답하는 대신, 그 일을 돌릴 스크립트를 스스로 짭니다. 그 스크립트가 서브에이전트 여럿을 백그라운드로 풀어 일을 나눠 맡기고요. 공식 문서의 정의입니다.

A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive.

(동적 워크플로는 서브에이전트를 대규모로 조율하는 자바스크립트 스크립트다. Claude가 당신이 말한 일에 맞춰 스크립트를 쓰고, 런타임이 이를 백그라운드에서 실행하는 동안 세션은 계속 응답한다.)

문서가 '동적 워크플로'라고 부르는 기능입니다. ultracode는 이 기능을 세션 내내 알아서 쓰게 하는 스위치고요 — 켜 두면 굵직한 작업이 들어올 때마다, 제가 시키지 않아도 스스로 워크플로를 계획합니다.

스크립트는 정해진 파이프라인이 아닙니다. 누구에게 무엇을 시키고 결과를 어떻게 합칠지를, 맡긴 일에 맞춰 매번 새로 정합니다. 그리고 이 설계의 핵심은 '여럿이 나눠 한다'보다 '여럿이 서로를 확인한다' 쪽에 있습니다.

it can have independent agents adversarially review each other's findings before they're reported ... so you get a more trustworthy result than a single pass.

(독립된 에이전트들이 보고 전에 서로의 발견을 적대적으로 검토하게 할 수 있어 … 단일 패스보다 더 믿을 만한 결과를 얻는다.)

단점

비쌉니다. 굵직한 작업마다 워크플로가 도니 토큰을 그만큼 더 씁니다. 한 요청이 워크플로 여러 개로 이어지기도 합니다 — 코드를 이해하는 것 하나, 고치는 것 하나, 검증하는 것 하나.

답이 오래 걸립니다. 에이전트 여럿이 단계를 나눠 도는 만큼, 한 번에 답할 때보다 시간이 깁니다. 큰 일에선 기다릴 만하지만, 세션 전체로 켜 두면 짧은 질문에도 필요 이상으로 시간이 걸릴 수 있습니다.

도는 중엔 방향을 못 틉니다. 서브에이전트들이 백그라운드에서 도는 방식이라, 한번 시작하면 "아니, 그거 말고"가 안 됩니다.

No mid-run user input — Only agent permission prompts can pause a run.

(실행 중 사용자 입력은 없다 — 에이전트 권한 프롬프트만 실행을 멈출 수 있다.)

문서 제약 표의 한 줄입니다. 도는 중에 제가 할 수 있는 건 /workflows 화면에서 잠깐 멈추거나 중단하는 것까지입니다. 실행이 스스로 멈춰 묻는 건 승인이 필요한 동작에서 뜨는 권한 프롬프트뿐이고요. 그래서 워크플로에 맡길 땐 하고 싶은 걸 앞에서 다 넣어야 합니다. 중간에 방향을 트는 대화가 아니라, 한 번에 끝내는 주문입니다. 단계 사이에 확인이 필요하면 단계마다 워크플로를 따로 돌리라는 게 문서의 안내입니다.

어떤 작업에 적합한가

문서의 예시 프롬프트들을 묶어 보면 패턴은 다섯입니다. 스크립트는 Claude가 쓰니, 무엇을 원하는지만 말하면 됩니다.

팬아웃 — 여러 항목에 같은 점검. 항목마다 에이전트를 붙여 한꺼번에 훑고, 발견은 서로 확인시킨 뒤 모읍니다. 코드가 아니어도 됩니다 — 폴더의 문서 200개를 하나씩 열어 기한 지난 항목을 추리는 일도 똑같이 팬아웃입니다.

use a workflow — src/routes/ 아래 라우트 핸들러를 전부 훑어 인증 검사가 빠진 곳을 찾고, 각 발견을 교차검증한 뒤 보고해줘

파이프라인 — 항목마다 여러 단계. 항목 하나하나가 정해진 단계를 차례로 지나갑니다. 서로 부딪치지 않게 각 항목은 격리된 사본에서 바꾸고요. 원고 여러 편을 맞춤법 점검, 서식 정리, 최종 확인 순서로 통과시키는 일을 떠올리면 됩니다.

use a workflow — src/components/ 아래 컴포넌트를 styled-components에서 Tailwind로 전부 옮겨줘. 각 파일은 격리된 사본에서.

조건이 찰 때까지 루프. 점검을 돌리고, 실패한 걸 고치고, 통과하거나 더는 진전이 없을 때까지 반복합니다. 같은 패턴으로 고칠 게 더 안 나올 때까지 훑기도 됩니다.

use a workflow — npx tsc --noEmit 를 돌려, 타입 검사가 통과할 때까지(또는 두 라운드 연속 진전이 없을 때까지) 오류를 계속 고쳐줘

모아서 하나로. 항목마다 리뷰어를 붙인 뒤, 한 에이전트가 결과를 몰아 받아 순위를 매기고 중복을 걸러 한 장으로 만듭니다. 설문 응답 수백 개를 나눠 읽고 한 장으로 간추릴 때도 이 패턴입니다.

use a workflow — 이 PR에서 바뀐 파일을 파일마다 리뷰한 뒤, 결과를 하나로 모아 순위 매기고 중복을 뺀 요약으로 만들어줘

여러 각도로 초안을 잡아 심사. 같은 문제를 독립된 각도로 여러 벌 세워 서로 견준 뒤 제일 나은 걸 고릅니다. 제 감으로는 코드보다 기획·글·의사결정에서 더 쓸모가 있습니다.

리서치 쪽은 이 패턴을 그대로 담은 내장 명령이 있습니다. /deep-research <질문>이 여러 출처를 병렬로 읽어 교차검증하고, 출처 달린 보고서를 돌려줍니다. ultracode를 켜지 않아도 이 명령 하나는 그대로 돌아가서, 감을 잡는 가장 쉬운 입구입니다. 동적 워크플로가 켜져 있어야 하는 건 여기도 같고(아래 '준비'), 웹 검색 도구도 필요합니다.

마음에 드는 흐름은 /이름 명령으로 저장해 두고 다음에 그대로 다시 부를 수 있습니다. 저장된 스크립트를 열어 보면 뼈대는 짧은 자바스크립트입니다 — agent()가 서브에이전트 하나를 돌리고, pipeline()이 목록의 항목마다 서브에이전트를 하나씩 돌립니다.

판단 기준은 세 가지입니다

한 대화가 다 담지 못하는 크기인가. 같은 점검을 여러 항목에 반복하는가. 서로 대조가 필요한가.

하나라도 '그렇다'면 워크플로, 아니면 대화입니다. 대규모 코드 수정, 경쟁사 요금제를 나란히 읽어 대조하는 리서치, 문서 수백 개에서 기한 지난 항목을 훑는 정리 — 다 이 기준에 걸립니다. 발행 전 검수도 같은 이유로 걸립니다. 한 편을 여러 항목으로 나눠 같은 점검을 반복하는 일이니까요.

반대편도 분명합니다. 함수 하나 고치기, 특정 버그 하나 잡기, 메일 한 통 다듬기, 대화하며 방향을 계속 트는 일. 나눌 게 없고, 중간에 끼어드는 이점만 잃습니다. 이런 건 일반 대화가 낫습니다.

문서는 기준 하나를 더 얹습니다. 지금은 작은 일이어도, 저장해 두고 다시 돌릴 순서라면 그것도 워크플로 쪽입니다.

정석은 단발 트리거입니다

세 기준에 걸리는 일이 어쩌다 한 번이라면, 세션 전체를 바꿀 필요가 없습니다. 프롬프트에 ultracode라는 낱말을 넣으면 그 요청 하나만 워크플로로 돌아갑니다. "use a workflow"나 "이건 워크플로로 돌려줘" 같은 평범한 말로도 됩니다. 세션의 effort는 그대로고요.

To run a single task as a workflow without changing the session's effort level, include the keyword ultracode in your prompt.

(세션의 effort를 바꾸지 않고 한 작업만 워크플로로 돌리려면, 프롬프트에 ultracode라는 키워드를 넣어라.)

/effort ultracode로 세션 전체를 켜는 건, 그날 할 일 대부분이 세 기준에 걸릴 때만입니다. 문서는 두 켜는 법에 순위를 매기지 않습니다 — 단발이 정석이라는 건 제 결론입니다. 코딩·잡일·짧은 질문이 섞인 보통의 하루에 상시로 켜 두는 건, 제가 처음에 한 실수를 그대로 반복하는 거라서요.

비용 감을 잡고 싶으면 작은 일 하나로 먼저 시험해 보면 됩니다. 도는 동안 /workflows를 열면 지금 몇 단계에 에이전트가 몇 개 붙어 토큰을 얼마나 쓰는지 보입니다. 폭주는 상한이 막습니다 — 동시에 도는 에이전트는 최대 16개(CPU 코어가 적은 기기에선 그보다 적게), 한 번의 실행에 총 1,000개까지입니다.

일상 작업으로 돌아왔으면 /effort high(원하시는 단계)로 내리면 됩니다. ultracode는 세션 한정이라, 새 세션을 열면 저절로 풀립니다.

준비 — 켜는 조건과 버전

참고한 문서