클로드 코드 /fast 와 ultracode 완전 정리 — 「/ultra」라는 명령어는 없습니다

클로드 코드를 쓰다 보면 어디선가 「/ultra 모드」라는 말을 듣게 됩니다. 빠르게 만들어 준다더라, 에이전트를 수백 개 굴린다더라, 하는 이야기와 함께요. 그런데 막상 터미널에 /ultra를 쳐 보면 아무 일도 일어나지 않습니다.

이 글은 그 혼란을 정리합니다. 무엇이 실제로 존재하는 기능이고, 무엇을 언제 켜야 하고, 켜면 요금이 어떻게 되는지까지 문서에 적힌 내용만으로 짚어 보겠습니다.

「/ultra」라는 명령어는 없습니다

먼저 가장 중요한 것부터 바로잡겠습니다. 클로드 코드에 /ultra라는 슬래시 명령어는 존재하지 않습니다. 쳐 봐야 인식되지 않거나 엉뚱한 스킬로 넘어갑니다.

그런데 「울트라」라는 말이 커뮤니티에 도는 데는 이유가 있습니다. 실제로 이름에 그 단어가 들어간 기능이 있기 때문입니다. 다만 하나가 아니라 셋으로 흩어져 있고, 서로 다른 물건입니다.

이름은 셋으로 흩어져 있습니다

정리하면 이렇습니다.

첫째, /effort ultracode. 효율 레벨 메뉴에 들어 있는 항목입니다. 세션 전체를 「알아서 워크플로우를 짜는 모드」로 바꿉니다.

둘째, 프롬프트에 그냥 쓰는 ultracode라는 단어. 이번 요청 하나만 워크플로우로 돌리게 하는 방아쇠입니다. 명령어가 아니라 문장 속의 키워드입니다.

셋째, /code-review ultra. 위 둘과 아무 관계가 없는 별개의 코드 리뷰 명령어입니다. 이름만 비슷합니다.

「/ultra 모드」라고 부를 때 사람들이 실제로 가리키는 것은 대개 첫째와 둘째입니다.

결론부터 — 언제 무엇을 켜나

세부를 읽기 전에 판단 기준만 먼저 드립니다.

지금 답이 빨리 와야 한다면 /fast입니다. 라이브 디버깅, 짧은 수정 반복처럼 내가 화면 앞에 앉아서 기다리고 있는 상황입니다.

지금 일이 너무 크다면 ultracode입니다. 파일 500개 마이그레이션, 저장소 전체 감사처럼 대화 하나로는 못 잡는 규모입니다.

둘은 해결하는 문제가 완전히 다릅니다. 하나는 지연 시간, 하나는 규모입니다. 그래서 같이 켤 수도 있고, 대개는 둘 다 필요 없습니다.

/fast 는 모델을 바꾸는 게 아닙니다

가장 흔한 오해부터 풀겠습니다. fast mode를 켜면 더 작고 빠른 모델로 내려간다고 생각하기 쉽지만, 그렇지 않습니다.

공식 문서의 표현은 분명합니다. fast mode는 다른 모델이 아니라, 같은 Opus를 다른 API 설정으로 돌리는 것입니다. 비용 효율 대신 속도를 우선하는 구성이고, 품질과 능력은 동일합니다. 최대 2.5배 빠른 응답을 얻는 대신 토큰당 단가가 올라갑니다.

즉 「빠른 대신 멍청해지는」 거래가 아닙니다. 「빠른 대신 비싼」 거래입니다.

켜고 끄는 법, 그리고 상태 확인

방법은 두 가지입니다.

하나는 입력창에 /fast를 치고 Tab을 누르는 것. 켜져 있으면 꺼지고, 꺼져 있으면 켜집니다.

다른 하나는 설정 파일에 "fastMode": true를 넣는 것입니다.

지금 켜져 있는지 헷갈릴 때도 /fast를 그냥 한 번 더 실행하면 됩니다. 현재 상태를 알려 줍니다.

한 가지 유의할 점은 VS Code 확장에서는 fast mode를 지원하지 않는다는 것입니다. CLI에서 쓰는 기능입니다.

↯ 아이콘이 말해 주는 것

fast mode가 켜지면 입력창 옆에 작은 ↯ 표시가 붙습니다. 켜졌다는 확인 메시지도 함께 뜹니다.

이 아이콘은 나중에 한 번 더 의미를 갖습니다. 뒤에서 이야기할 한도 초과 상황에서 회색으로 바뀌기 때문입니다. 회색이면 「켜 두긴 했는데 지금은 표준 속도로 돌고 있다」는 뜻입니다.

색만으로 구분하기 어려우면 /fast를 다시 실행해 문장으로 확인하는 편이 확실합니다.

모델을 바꾸면 fast mode도 따라 움직입니다

이 동작이 은근히 헷갈리는 지점입니다.

fast mode를 지원하지 않는 모델로 /model을 옮기면, 클로드 코드가 fast mode를 알아서 끕니다. 반대로 지원하는 Opus로 돌아오면, 저장된 선호 설정이 「켜짐」인 경우 다시 켜집니다.

저장된 선호가 「꺼짐」이면 모델을 옮겨 다녀도 켜지지 않습니다. 뒤에 설명할 세션별 옵트인을 걸어 둔 경우에도 자동으로 켜지지 않으니, 그때는 /fast를 직접 실행해야 합니다.

이 전환이 일어날 때마다 켜짐·꺼짐 확인 메시지가 뜨므로, 메시지를 흘려보내지 않는 게 좋습니다.

가격 — 여기가 진짜 결정 포인트입니다

문서에 표로 명시된 값입니다. Opus 5와 Opus 4.8 모두 입력 100만 토큰당 10달러, 출력 100만 토큰당 50달러입니다.

중요한 점은 이 단가가 100만 토큰 컨텍스트 창 전체에 걸쳐 평평하다는 것입니다. 컨텍스트가 길어진다고 단가가 더 올라가지는 않습니다.

표준 Opus 요금과 비교하려면 클로드 공식 가격표를 함께 보셔야 합니다. 이 글에서 중요한 것은 절대값이 아니라 「표준보다 비싸다」는 사실 자체입니다.

대화 중간에 켜면 왜 손해인가

이건 꼭 알고 계셔야 하는 함정입니다.

한 대화에서 fast mode를 처음 켜는 순간, 그때까지 쌓인 대화 맥락 전체에 대해 캐시되지 않은 입력 토큰 요금을 fast mode 단가로 한 번 지불합니다.

대화가 깊어진 뒤에 켤수록 그 한 번의 비용이 커집니다. 그래서 문서도 세션 시작 시점에 켜는 편이 싸다고 권합니다.

다행히 이 비용은 대화당 한 번입니다. 켰다 껐다 다시 켜도 반복해서 물지는 않습니다. 결론은 단순합니다 — 쓸 거면 처음부터 켜고 시작하세요.

구독 요금제와 사용 크레딧의 관계

여기가 오해를 많이 사는 부분입니다.

fast mode는 Pro·Max·Team·Enterprise 구독자와 클로드 콘솔 사용자 모두에게 열려 있습니다. 다만 구독 요금제 사용자에게는 사용 크레딧으로만 제공되고, 구독에 포함된 사용량 한도에는 들어가지 않습니다.

다시 말해 요금제에 남은 사용량이 있어도, fast mode 토큰은 첫 토큰부터 크레딧에서 빠져나갑니다. 「어차피 구독료 냈으니 공짜」가 아닙니다.

그래서 계정에 사용 크레딧이 켜져 있어야 fast mode를 쓸 수 있습니다. 개인 계정은 콘솔 결제 설정에서, 팀·엔터프라이즈는 관리자가 조직 단위로 켭니다.

지원되는 모델과 안 되는 환경

fast mode는 Opus 5와 Opus 4.8에서만 동작합니다. Sonnet·Haiku를 비롯한 다른 모델에서는 제공되지 않습니다.

Opus 4.7은 2026년 6월 25일 지원이 중단되고 7월 24일 완전히 제거됐습니다. 지금은 fast mode를 지원하지 않는 일반 모델과 똑같이 취급됩니다.

실행 환경도 제한이 있습니다. Anthropic API와 구독 계정에서만 되고, Amazon Bedrock·Google Cloud Agent Platform·Microsoft Foundry·AWS의 클로드 플랫폼에서는 제공되지 않습니다.

버전에 따라 기본 모델이 다릅니다

fast mode를 켜면 다른 모델에 있다가도 Opus로 자동 전환됩니다. 그런데 어떤 Opus로 가는지는 클로드 코드 버전에 따라 다릅니다.

v2.1.219부터는 Opus 5가 기본입니다. v2.1.154부터 v2.1.218까지는 Opus 4.8이었고, v2.1.142부터 v2.1.153까지는 Opus 4.7이었습니다.

그러니 「분명 fast를 켰는데 모델이 예상과 다르다」면 버전을 먼저 확인해 보시면 됩니다.

참고로 /fast로 fast mode를 끄더라도 모델은 Opus에 그대로 남습니다. 원래 쓰던 모델로 돌아가려면 /model을 따로 실행해야 합니다.

한도에 걸리면 조용히 표준 속도로

fast mode에는 표준 Opus와 별도의 사용 한도가 걸려 있습니다. 지원되는 Opus 모델들이 하나의 한도 풀을 공유합니다.

한도에 닿으면 작업이 멈추지는 않습니다. 자동으로 표준 속도로 내려가고, ↯ 아이콘이 회색으로 바뀌며, 쿨다운이 끝나면 알아서 다시 켜집니다. 그동안은 표준 요금으로 계속 일할 수 있습니다.

기다리기 싫으면 /fast를 눌러 직접 꺼도 됩니다.

사용 크레딧이 떨어지면

세션 도중 크레딧이 바닥나면 클로드 코드가 거절된 요청을 표준 속도·표준 요금으로 다시 시도합니다. 작업 자체는 끊기지 않고, 이 경우에는 쿨다운도 없습니다.

대화형 세션에서는 크레딧 소진 알림이 뜨고 남은 세션 동안 fast mode가 꺼집니다. 저장된 선호 설정은 그대로라서, 크레딧을 채운 뒤 /fast를 실행하면 다시 켜집니다.

비대화형 모드나 에이전트 SDK에서는 같은 내용이 메시지 스트림에 시스템 알림으로 흘러나옵니다. 이쪽은 fast mode가 켜진 상태로 유지됩니다.

세션마다 다시 켜게 만들기

기본 동작은 「한 번 켜면 다음 세션에도 계속 켜짐」입니다. 편하지만 위험하기도 합니다. 켠 걸 잊고 세션 여러 개를 동시에 돌리면 크레딧이 빠르게 소모됩니다.

이걸 막으려면 설정 파일에 "fastModePerSessionOptIn": true를 넣습니다. 그러면 모든 세션이 fast mode 꺼진 상태로 시작하고, 필요할 때만 /fast로 켜게 됩니다.

선호 설정 자체는 보존되므로, 이 옵션을 지우면 원래의 유지 동작으로 돌아옵니다. 팀·엔터프라이즈는 서버 관리 설정으로 조직 전체에 배포할 수 있습니다.

조직 단위로 막혀 있는 경우

팀·엔터프라이즈 조직에서는 fast mode가 기본적으로 꺼져 있습니다. 소유자가 명시적으로 켜 줘야 구성원이 쓸 수 있습니다.

꺼져 있는 상태에서 /fast를 실행하면 「조직에서 비활성화했다」는 메시지가 나옵니다. 조직의 허용 모델 목록에 fast mode용 Opus가 빠져 있으면 「조직 허용 모델이 아니다」라며 거절됩니다.

다만 예외가 하나 있습니다. 이미 허용된 Opus 모델 위에서 돌고 있는 세션이라면, 모델을 바꾸지 않고 현재 모델에서 그대로 fast mode를 켭니다.

반대로 아예 못 쓰게 막고 싶다면 CLAUDE_CODE_DISABLE_FAST_MODE=1 환경 변수를 쓰면 됩니다.

프록시·게이트웨이 뒤에서 안 켜질 때

이건 사내 네트워크에서 자주 만나는 문제입니다.

클로드 코드는 fast mode를 제공하기 전에 조직의 사용 가능 여부를 api.anthropic.com에 직접 물어봅니다. 이 확인 요청은 ANTHROPIC_BASE_URL을 따라가지 않습니다. 그래서 LLM 게이트웨이로 트래픽을 우회시키면서 직접 접속을 막아 둔 망에서는, 추론 요청은 잘 되는데 이 확인만 실패합니다.

실패하면 「네트워크 연결 문제로 fast mode를 쓸 수 없다」는 메시지가 나오고 표준 속도로 돌아갑니다.

해결책은 두 갈래입니다. 망 차단이 원인이면 api.anthropic.com으로의 직접 통신을 허용해 주는 게 정석이고, 그게 어려우면 실패 양상에 맞는 환경 변수를 씁니다. 연결이 거부되는 경우에는 CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORS=1, 요청이 가로채여 엉뚱한 응답이 돌아오는 경우에는 CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK=1입니다.

fast mode 를 쓸 값어치가 있는 순간

문서가 권하는 상황은 명확합니다. 내가 기다리고 있는 작업입니다.

코드를 조금 고치고 바로 결과를 보는 반복 작업, 살아 있는 디버깅 세션, 마감이 코앞인 급한 일. 이런 상황에서는 응답이 몇 초 빨라지는 게 요금보다 값어치가 있습니다.

반대로 내가 자리를 비운 사이 도는 작업에는 의미가 없습니다. 긴 자율 작업, 배치 처리, CI/CD 파이프라인, 비용에 민감한 작업이 여기 해당합니다. 아무도 안 보는 화면이 2.5배 빨라져 봐야 요금만 늘어납니다.

fast mode 와 효율 레벨은 다른 손잡이입니다

둘 다 응답 속도에 영향을 주지만 작동 방식이 다릅니다.

fast mode는 모델 품질을 그대로 두고 지연 시간만 줄입니다. 대가는 요금입니다.

낮은 효율 레벨은 생각하는 시간 자체를 줄입니다. 빨라지고 싸지지만, 복잡한 작업에서는 품질이 떨어질 수 있습니다.

둘은 함께 쓸 수 있습니다. 단순하고 반복적인 작업이라면 fast mode에 낮은 효율 레벨을 조합해 최대 속도를 낼 수 있습니다. 반대로 어려운 작업이라면 효율은 유지한 채 fast mode만 켜는 게 맞습니다.

이제 ultracode — 효율 레벨이 아니라 설정입니다

여기서부터가 두 번째 주제입니다. 그리고 첫 문장부터 정확히 짚고 가야 합니다.

공식 문서의 표현은 이렇습니다. ultracode는 모델의 효율 레벨이 아니라 클로드 코드의 설정입니다. 모델에는 xhigh를 보내고, 거기에 더해 「의미 있는 작업마다 동적 워크플로우를 짜게」 만듭니다.

그래서 /effort 메뉴에 같이 들어 있지만 성격이 다릅니다. 다른 항목들은 「얼마나 깊게 생각할까」를 정하고, ultracode는 「어떤 구조로 일할까」까지 바꿉니다.

그리고 현재 세션에만 적용됩니다. 새 세션을 시작하면 초기화됩니다.

효율 레벨 사다리를 먼저 봅시다

ultracode의 위치를 이해하려면 사다리 전체를 봐야 합니다.

low는 짧고 범위가 좁으며 지연 시간이 중요한 작업용입니다. medium은 지능을 조금 양보하고 토큰을 아끼는 쪽입니다. high는 균형점이고, Opus 4.7을 제외한 모든 모델의 기본값입니다.

xhigh는 토큰을 더 쓰고 더 깊게 생각합니다. Opus 4.7의 기본값이 이것이었습니다. max는 까다로운 작업에서 성능을 올릴 수 있지만 수확 체감이 있고 과잉 사고에 빠지기 쉽습니다. 문서도 널리 채택하기 전에 시험해 보라고 적어 두었습니다.

그리고 그 위에 얹히는 게 ultracode입니다. 사다리의 한 칸이라기보다 사다리 옆에 붙은 별도 스위치에 가깝습니다.

주의 — 효율 레벨은 모델마다 눈금이 다릅니다

작지만 중요한 단서가 하나 있습니다. 효율 척도는 모델별로 보정되어 있습니다. 같은 high라도 모델이 다르면 실제 값이 같지 않습니다.

그러니 「A 모델에서 medium이 충분했으니 B 모델에서도 medium이면 되겠지」라는 추정은 위험합니다. 모델을 바꿨다면 효율 레벨도 다시 감을 잡아야 합니다.

방법 하나 — 프롬프트에 ultracode 한 단어

세션 설정을 건드리지 않고 이번 작업 하나만 워크플로우로 돌리고 싶을 때 쓰는 방법입니다. 프롬프트 안에 ultracode라는 단어를 넣으면 됩니다.

ultracode: src/routes/ 아래 모든 API 엔드포인트에서 인증 검사 누락을 찾아 줘

입력창에서 이 키워드가 강조 표시되고, 클로드가 턴 단위로 일하는 대신 워크플로우 스크립트를 작성합니다.

「워크플로우로 해 줘」처럼 자기 말로 부탁해도 똑같이 동작합니다. 클로드는 직접적인 요청을 같은 의사 표시로 받아들입니다. 참고로 v2.1.160 이전에는 방아쇠 단어가 workflow였습니다. 지금은 그 단어로는 발동하지 않습니다.

잘못 눌렀을 때 되돌리기

키워드가 강조됐는데 그럴 의도가 아니었다면, 되돌릴 수 있습니다.

윈도우·리눅스에서는 Alt+W, 맥에서는 Option+W를 누르면 이번 프롬프트의 강조가 해제됩니다. 커서가 강조된 단어 바로 뒤에 있을 때 백스페이스를 눌러도 같은 효과입니다.

아예 발동 자체를 막고 싶으면 설정에서 Ultracode 키워드 트리거를 끄면 됩니다.

키워드가 안 먹히는 자리

이 부분은 보안과 직결되어 있어서 눈여겨보실 만합니다.

키워드는 사람이 직접 친 프롬프트에서만 의사 표시로 인정됩니다. 대화형 입력창, IDE 확장 패널, 원격 제어 클라이언트, 그리고 키보드 입력임을 명시한 에이전트 SDK 애플리케이션이 여기 해당합니다.

반대로 다음 경로로 들어온 프롬프트에서는 워크플로우가 발동하지 않습니다. -p로 넘긴 프롬프트, 사람 입력으로 표시하지 않은 SDK 프롬프트, 예약 작업 프롬프트, 그리고 웹훅 페이로드나 풀 리퀘스트 댓글이 대화로 전달된 경우입니다.

마지막 항목이 핵심입니다. 외부에서 흘러들어온 텍스트가 「ultracode」라는 단어 하나로 수백 개 에이전트를 띄우지 못하게 막아 둔 것입니다. v2.1.210 이전에는 이 경로들에서도 발동했습니다.

방법 둘 — /effort ultracode 로 세션 전체

이번엔 세션 전체를 바꾸는 쪽입니다.

/effort ultracode

이렇게 켜 두면 내가 매번 부탁하지 않아도 클로드가 스스로 판단해 의미 있는 작업마다 워크플로우를 짭니다.

세션을 처음부터 그 상태로 시작하려면 claude --effort ultracode로 실행합니다. v2.1.203 이상에서 동작하고, 그 이전 버전에서는 값을 인식하지 못하고 기본 효율로 시작합니다.

--settings나 에이전트 SDK 제어 요청으로 "ultracode": true를 넘기는 방법도 있습니다.

설정 파일과 환경 변수로는 고정할 수 없습니다

여기에 함정이 하나 있습니다.

영구 저장되는 effortLevel 설정과 CLAUDE_CODE_EFFORT_LEVEL 환경 변수는 ultracode 값을 받지 않습니다. max도 마찬가지로 세션 전용입니다. 설정 파일에는 low·medium·high·xhigh만 넣을 수 있습니다.

더 헷갈리는 경우가 있습니다. 환경 변수가 xhigh가 아닌 다른 값으로 설정되어 있으면, 요청은 그 값으로 나가고 ultracode의 워크플로우 기능은 잠자코 비활성 상태가 됩니다. 이때 ultracode를 고르면 환경 변수가 덮어쓰고 있다는 경고가 뜹니다.

「분명 켰는데 워크플로우를 안 짠다」 싶으면 환경 변수부터 확인해 보세요.

동적 워크플로우가 실제로 하는 일

ultracode가 부르는 「동적 워크플로우」의 정체는 자바스크립트 스크립트입니다.

내가 설명한 작업에 맞춰 클로드가 스크립트를 쓰고, 별도의 런타임이 그걸 백그라운드에서 실행합니다. 그동안 내 세션은 계속 반응합니다.

핵심 차이는 계획을 누가 들고 있느냐입니다. 서브에이전트나 스킬을 쓸 때는 클로드가 턴마다 다음에 뭘 할지 정하고, 중간 결과가 전부 컨텍스트 창에 쌓입니다. 워크플로우는 반복문·분기·중간 결과를 스크립트가 직접 들고 있어서, 클로드의 컨텍스트에는 최종 답만 남습니다.

이게 규모를 감당하게 해 주는 구조적인 이유입니다.

단순히 에이전트를 더 굴리는 게 아닙니다

계획이 코드로 옮겨지면 반복 가능한 품질 패턴을 걸 수 있습니다.

예를 들어 여러 에이전트가 서로의 발견을 적대적으로 검증한 뒤에만 보고하게 하거나, 하나의 계획을 여러 각도에서 독립적으로 초안 잡아 서로 견주게 할 수 있습니다.

단순히 한 번 훑는 것보다 신뢰할 만한 결과가 나오는 이유가 여기 있습니다. 물량이 아니라 구조가 품질을 만듭니다.

/workflows — 진행 상황을 들여다보는 창

워크플로우는 백그라운드에서 돌기 때문에 별도의 창으로 봅니다.

/workflows

실행 중·완료된 워크플로우 목록이 나오고, 하나를 고르면 진행 화면이 열립니다. 단계별로 에이전트 수, 토큰 총량, 경과 시간이 보입니다.

단계를 파고들면 개별 에이전트가 받은 프롬프트와 최근 도구 호출, 결과까지 읽을 수 있습니다. 입력창 아래 작업 패널에도 한 줄 요약이 뜨는데, 아래 방향키로 초점을 옮기고 엔터로 펼칠 수 있습니다.

진행 화면에서 쓰는 키

이 화면의 조작키는 외워 두면 편합니다.

위아래 방향키로 단계나 에이전트를 고르고, 엔터나 오른쪽 방향키로 파고듭니다. Esc나 왼쪽 방향키로 한 단계 나옵니다. 내용이 넘칠 때는 j와 k로 스크롤합니다.

f는 상태별 필터, p는 일시정지와 재개, x는 선택한 에이전트를 멈추는 키입니다. 초점이 실행 전체에 있으면 x가 워크플로우 전체를 멈춥니다. r은 실행 중인 에이전트를 재시작하고, s는 이 실행의 스크립트를 명령어로 저장합니다.

상한 — 동시 16개, 전체 1000개

런타임이 거는 제약도 알아 두면 좋습니다.

동시에 도는 에이전트는 최대 16개입니다. CPU 코어가 적은 기기에서는 그보다 줄어듭니다. 한 번의 실행에서 쓸 수 있는 에이전트는 총 1000개가 상한입니다. 폭주하는 반복문을 막는 안전장치입니다.

이 밖에도 실행 중에는 사용자 입력을 받을 수 없습니다. 에이전트 권한 요청만이 실행을 멈출 수 있습니다. 단계 사이에 사람의 승인을 넣고 싶다면 각 단계를 별도의 워크플로우로 나눠야 합니다.

스크립트 자체는 파일 시스템이나 셸에 직접 접근하지 못하고, 모듈도 불러올 수 없습니다. import()가 들어 있으면 실행 전에 실패합니다. 읽고 쓰고 명령을 실행하는 건 에이전트의 몫이고, 스크립트는 조율만 합니다.

비용과 「큰 워크플로우」 경고

에이전트를 많이 띄우니 토큰도 많이 씁니다. 같은 일을 대화로 처리할 때보다 의미 있게 많이 든다고 문서가 못 박아 두었습니다. 사용량과 한도에도 다른 세션과 똑같이 반영됩니다.

그래서 큰 작업에 바로 뛰어들기 전에 작은 조각으로 먼저 돌려 보라고 권합니다. 저장소 전체 대신 디렉터리 하나, 넓은 질문 대신 좁은 질문으로요.

클로드 코드도 스스로 경고합니다. 에이전트가 25개를 넘거나 예상 토큰이 150만을 넘으면 작업 패널에 「Large workflow」 경고가 뜹니다. 다만 이건 권고일 뿐 실행을 멈추지는 않습니다.

한 가지 유의할 점 — ultracode를 켠 세션에서는 이 경고가 뜨지 않습니다. 이미 큰 실행에 동의한 것으로 보기 때문입니다.

규모 가이드라인을 미리 정해 두기

클로드가 워크플로우를 쓸 때 목표로 삼을 에이전트 수를 미리 알려 줄 수 있습니다.

small은 5개 미만, medium은 15개 미만, large는 50개 미만을 겨냥합니다. unrestricted는 가이드라인 없이 작업 크기에 맞춰 정하게 둡니다.

v2.1.219 이상에서 기본값은 medium입니다. 설정에서 「동적 워크플로우 크기」 값을 고르거나 /config workflowSizeGuideline=small로 바꿉니다.

중요한 것은 이게 상한이 아니라 조언이라는 점입니다. 클로드에게 참고 사항으로 전달될 뿐이라, 프롬프트가 다른 규모를 요구하면 그쪽이 이깁니다. 진짜 상한은 앞서 본 동시 16개·총 1000개입니다.

마음에 든 실행은 명령어로 저장합니다

이게 워크플로우의 가장 실용적인 쓸모라고 생각합니다.

한 번 잘 돈 워크플로우는 /workflows에서 고른 뒤 s를 눌러 저장할 수 있습니다. 저장 위치는 두 곳입니다. 프로젝트의 .claude/workflows/는 저장소를 받은 모든 사람이 함께 쓰고, 홈 디렉터리의 ~/.claude/workflows/는 모든 프로젝트에서 나만 씁니다.

저장하면 다음 세션부터 /이름으로 실행됩니다. 브랜치마다 돌리는 리뷰 같은 절차를 매번 같은 구조로 반복할 수 있게 됩니다.

이름이 겹치면 프로젝트 쪽이 이깁니다. 플러그인으로 배포하면 /플러그인이름:워크플로우이름 형태로 이름 공간이 분리됩니다.

저장한 워크플로우에 값 넘기기

저장된 워크플로우는 args라는 이름으로 입력을 받을 수 있습니다.

매번 스크립트를 고치는 대신, 실행할 때 조사할 질문이나 대상 경로 목록, 설정 객체를 넘기면 됩니다. 예를 들어 「이슈 1024, 1025, 1030에 대해 /triage-issues를 돌려 줘」라고 말하면 클로드가 그 목록을 구조화된 데이터로 넘겨줍니다.

스크립트 쪽에서는 별도 파싱 없이 바로 배열·객체 메서드를 쓸 수 있습니다. 값을 안 넘기면 args는 정의되지 않은 상태가 됩니다.

중단하고 다시 이어붙일 때의 규칙

이 규칙은 꽤 반직관적이라 따로 설명이 필요합니다.

멈춘 워크플로우는 재개할 수 있고, 이미 끝난 에이전트는 보통 캐시된 결과를 돌려줍니다. 그런데 무엇이 살아남는지를 정하는 규칙이 두 개 있습니다.

첫째, 멈출 때 아직 돌고 있던 에이전트는 저장되지 않습니다. 재개하면 처음부터 다시 돕니다.

둘째, 재생은 에이전트가 시작된 순서를 따릅니다. 캐시된 결과는 「끝내지 못한 첫 에이전트」에서 멈추고, 그 뒤에 시작된 에이전트는 이미 끝났더라도 전부 다시 돕니다.

그래서 잘게 쪼갠 워크플로우가 유리합니다

앞의 두 번째 규칙이 실무에서 뜻하는 바를 예로 들어 보겠습니다.

스크립트가 A·B·C·D를 그 순서로 띄웠고, B가 아직 돌고 있을 때 내가 멈췄다고 합시다. 재개하면 A는 캐시에서 돌아옵니다. B는 못 끝냈으니 다시 돕니다. 그런데 C와 D도 다시 돕니다. B보다 나중에 시작했기 때문입니다. 둘 다 멈추기 전에 끝났는데도요.

여기서 실용적인 교훈이 나옵니다. 작은 에이전트 여럿으로 펼친 워크플로우가 긴 에이전트 하나짜리보다 진행 상황을 더 많이 지켜 냅니다.

그리고 재개는 같은 세션 안에서만 됩니다. 워크플로우가 도는 중에 클로드 코드를 종료하면 다음 세션에서는 처음부터 시작합니다.

권한은 어떻게 흐르나

이 부분은 조심해서 읽으실 필요가 있습니다.

내 권한 모드는 워크플로우를 띄울 때의 승인 창만 통제합니다. 워크플로우가 만들어 내는 서브에이전트들은 내 세션 모드와 무관하게 항상 acceptEdits 모드로 돕니다. 파일 편집이 자동 승인된다는 뜻입니다. 도구 허용 목록은 내 것을 그대로 물려받습니다.

허용 목록에 없는 셸 명령, 웹 요청, MCP 도구는 실행 도중에도 승인을 물어볼 수 있습니다. 긴 실행에서 이걸 피하려면 에이전트가 쓸 명령을 시작 전에 허용 목록에 넣어 두는 게 좋습니다.

claude -p나 에이전트 SDK에서는 물어볼 사람이 없으므로, 설정한 권한 규칙을 따라 대화형 확인 없이 진행합니다.

실행 전 승인 창

CLI에서는 실행 전에 계획된 단계 목록과 함께 선택지가 뜹니다. 그냥 실행할지, 이 프로젝트에서 이 워크플로우는 앞으로 묻지 않을지, 원본 스크립트를 먼저 읽을지, 취소할지입니다. Ctrl+G로 편집기에서 스크립트를 열 수도 있고, Tab으로 프롬프트를 손볼 수도 있습니다.

언제 이 창이 뜨는지는 권한 모드에 달려 있습니다. 기본 모드와 편집 수락 모드에서는 매번 뜹니다. 자동 모드에서는 첫 실행에만 뜨고, ultracode가 켜져 있으면 아예 건너뜁니다. 권한 우회 모드와 claude -p, 에이전트 SDK에서는 묻지 않고 바로 시작합니다.

워크플로우를 아예 끄는 방법

필요 없다면 꺼 둘 수도 있습니다.

개인 설정에서는 설정 창의 「동적 워크플로우」를 끄거나, ~/.claude/settings.json에 "disableWorkflows": true를 넣거나, CLAUDE_CODE_DISABLE_WORKFLOWS=1 환경 변수를 씁니다. 조직 전체는 관리 설정이나 관리자 페이지에서 처리합니다.

끄면 어떻게 되는지도 알아 두시면 좋습니다. 기본 제공 워크플로우 명령어가 사라지고, ultracode 키워드가 발동하지 않으며, /effort 메뉴에서 ultracode 항목 자체가 없어집니다.

참고로 워크플로우를 쓸 수 없는 상태에서 --effort ultracode를 넘기면, 워크플로우 없이 xhigh 효율만 설정됩니다.

기본으로 딸려 오는 워크플로우 — /deep-research

직접 만들기 전에 맛보기로 돌려 볼 게 하나 있습니다.

/deep-research 노드 v20과 v22 사이에 권한 모델이 무엇이 달라졌나

여러 각도로 웹 검색을 펼치고, 찾은 출처들을 서로 교차 검증한 뒤, 인용이 달린 보고서를 돌려줍니다. 교차 검증에서 살아남지 못한 주장은 걸러져 있습니다.

v2.1.196부터는 검증 에이전트가 한도 초과나 API 오류로 어떤 주장을 확인하지 못한 경우, 그걸 「반박됨」으로 세지 않고 「미검증」으로 표시합니다. 확인 못 한 것과 틀린 것을 구분하는 셈입니다.

이 명령어는 내가 부를 때만 돕니다. v2.1.218 이전에는 클로드가 스스로 시작할 수도 있었습니다. 웹 검색 도구가 있어야 동작합니다.

이름이 비슷해 헷갈리는 것들

마지막으로 이름 정리입니다.

/code-review ultra는 지금까지 이야기한 것들과 전혀 다른 명령어입니다. 현재 브랜치나 깃허브 풀 리퀘스트를 대상으로 다중 에이전트 클라우드 리뷰를 돌립니다. /ultrareview는 같은 기능의 옛 이름입니다.

/deep-research는 기본 제공 워크플로우이고, ultracode는 워크플로우를 짜게 만드는 방아쇠입니다. 앞엣것은 이미 만들어진 스크립트, 뒤엣것은 스크립트를 만들게 하는 신호입니다.

그리고 다시 한번, /ultra는 없습니다.

실제로 이렇게 씁니다 — SVIL 작업 사례

이론만으로는 감이 안 잡히니 실제로 판단했던 사례를 남깁니다.

오늘 강의 시리즈 19편을 한 세션에서 이어 발행했습니다. 회차당 본문 2만 자 이상에 이미지가 12장씩, 전부 합쳐 이미지 228장을 만들어야 하는 작업이었습니다. 규모만 보면 워크플로우를 띄우기 딱 좋아 보입니다.

그런데 쓰지 않았습니다. 이유는 단순합니다. 이미지 생성은 로컬 GPU 한 장에서 순차로 도는 작업이라, 에이전트를 16개로 펼쳐도 병목이 하나도 안 풀립니다. 오히려 큐가 엉킬 위험만 늘어납니다.

규모가 크다고 워크플로우가 답은 아닙니다

앞 사례에서 얻은 교훈이 이겁니다. 펼칠 수 있는 일이라야 펼치는 의미가 있습니다.

병목이 단일 자원 하나에 있다면 — GPU 한 장, 하나의 API 한도, 순서를 지켜야 하는 디스크 쓰기 — 에이전트를 늘려도 얻는 게 없습니다. 토큰만 몇 배로 씁니다.

반대로 파일 500개를 각각 독립적으로 고치는 일이나, 서로 다른 각도의 검색 결과를 교차 검증하는 일처럼 작업 단위가 서로를 기다리지 않는 경우라면 제값을 합니다.

대신 그 세션에서 실제로 쓴 것은 발행 직전 자동 검사였습니다. 섹션 수·이미지 수·푸터 유무·플레이스홀더 잔존 여부를 스크립트가 검사하고, 미달이면 발행을 멈추게 했습니다. 실제로 두 건이 걸렸습니다 — 23섹션짜리 원고 하나와 이미지가 한 장 모자란 원고 하나였습니다.

두 기능을 같이 켤 때

fast mode와 ultracode를 동시에 켜는 건 가능하지만, 조합이 늘 좋은 건 아닙니다.

ultracode가 하는 일은 대체로 내가 자리를 비운 사이 백그라운드에서 도는 작업입니다. 그런데 fast mode의 값어치는 내가 기다리고 있을 때 나옵니다. 방향이 서로 어긋납니다.

게다가 워크플로우의 모든 에이전트는 기본적으로 내 세션의 모델을 씁니다. fast mode를 켜 두고 에이전트 수십 개를 띄우면 요금이 그만큼 곱해집니다.

큰 실행 전에는 /model을 한 번 확인하시고, 굳이 최상급이 필요 없는 단계는 더 작은 모델을 쓰게 요청하는 편이 낫습니다.

핵심 정리

길었으니 요약하겠습니다.

/ultra라는 명령어는 없습니다. 실제로 있는 것은 /effort ultracode, 프롬프트 속 ultracode 키워드, 그리고 이름만 비슷한 /code-review ultra입니다.

/fast는 모델을 낮추지 않습니다. 같은 Opus를 최대 2.5배 빠르게 돌리고 토큰당 10달러·50달러를 받습니다. 세션 시작할 때 켜야 싸고, 구독 요금제에서는 사용 크레딧에서 빠집니다.

ultracode는 효율 레벨이 아니라 클로드 코드 설정입니다. xhigh에 더해 워크플로우 조율을 붙이고, 세션이 끝나면 사라집니다. 동시 16개, 총 1000개 상한이 걸려 있고 중단 후 재개에는 순서 규칙이 있습니다.

그리고 규모가 크다고 답이 워크플로우인 건 아닙니다. 펼칠 수 있는 일인지부터 보셔야 합니다.

오늘 해 보실 것

세 가지만 권해 드립니다.

첫째, /fast를 한 번 실행해 지금 상태를 확인해 보세요. 켜 둔 줄 모르고 계셨다면 크레딧이 새고 있었을 수 있습니다.

둘째, 설정에서 「동적 워크플로우 크기」가 뭘로 되어 있는지 보세요. 기본은 medium이지만 예전 버전에서 올라오셨다면 unrestricted일 수 있습니다.

셋째, /deep-research로 평소 궁금하던 것 하나를 돌려 보세요. 워크플로우가 어떻게 생겼는지 가장 싸게 확인하는 방법입니다.

SVIL은 저시력 사용자를 위한 접근성 도구와 AI 에이전트 워크플로우를 연구합니다. 도구를 정확히 아는 것이 결국 작업 시간을 아끼는 가장 빠른 길이라고 생각합니다.

출처

이 글의 사실 관계는 아래 문서에서 확인했습니다.

• Claude Code Docs — Speed up responses with fast mode: https://code.claude.com/docs/en/fast-mode
• Claude Code Docs — Orchestrate subagents at scale with dynamic workflows: https://code.claude.com/docs/en/workflows
• Claude Code Docs — Model configuration (효율 레벨·ultracode): https://code.claude.com/docs/en/model-config
• Claude Code Docs — Create custom subagents: https://code.claude.com/docs/en/sub-agents
• Claude Code Docs — Settings: https://code.claude.com/docs/en/settings
• Claude Code Docs — Environment variables: https://code.claude.com/docs/en/env-vars
• Claude Code Docs — Permission modes: https://code.claude.com/docs/en/permission-modes
• Claude 공식 가격표: https://platform.claude.com/docs/en/about-claude/pricing
• Claude Code 로컬 변경 이력(changelog) — 버전별 도입·변경 시점 대조

버전에 따라 동작이 달라지는 항목이 많아, 본문에 해당 버전 번호를 함께 적어 두었습니다. 2026년 8월 9일 기준입니다.

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/