Claude Code v2.1.160이 workflow 키워드를 ultracode로 조용히 변경했습니다. 만약 스크립트된 프롬프트(scripted prompts)를 사용 중이라면, 여러분의 에이전트(agents)는 하룻밤 사이에 동작 방식이 바뀌었습니다.

v2.1.160 변경 로그(changelog)는 6월 2일 02:10 UTC에 공개되었습니다. 40여 개의 항목이 포함되어 있습니다. 대부분은 WSL 수정, IME 다시 그리기 버그, vim p 붙여넣기 수정과 같은 일반적인 내용입니다. 하지만 버전 업데이트에 대한 화려한 홍보도, 마이그레이션(migration) 안내도, Anthropic 블로그 포스트도 없이 중간에 다음과 같은 내용이 묻혀 있었습니다:

dynamic-workflow 트리거 키워드를 workflow에서 ultracode로 변경했습니다. 이제

1. dynamic workflows — 수백 개의 병렬 서브에이전트 (subagents)를 확장(fan out)하는 Anthropic의 프리뷰 기능 — 의 트리거 키워드가 workflow에서 ultracode로 변경되었습니다. 매칭은 정확한 토큰 (exact-token) 방식입니다. 만약 당신의 프롬프트가 "set up the workflow for the bootstrap script"라고 말한다면, 더 이상 해당 기능에 참여(opted in)하지 않게 됩니다. 확장(fan-out) 없이 단일 에이전트 실행만 수행됩니다.

2. 폴백 경로 (fallback path)가 사라진 것은 아닙니다. 릴리스 노트의 두 번째 문장인 "자신만의 언어로 요청해도 여전히 작동합니다"라는 말은, 서브에이전트를 생성할지 여부를 결정하는 분류기 (classifier)가 여전히 작동하고 있음을 의미합니다. 만약 당신의 프롬프트가 "fan out the linter across all packages"라고 말한다면, 여전히 dynamic-workflow 경로를 타게 됩니다. 키워드는 빠른 경로 (fast-path) 트리거였습니다. 느린 경로 (slow path)는 여전히 살아있습니다.

3. 동일한 릴리스에서는 workflow라는 단어를 다시 일반적인 단어로 되돌릴 수 있는 "Workflow keyword trigger"라는 이름의 /config 설정을 추가했습니다. Anthropic은 이전 동작을 유지하기를 원하는 소수의 사용자를 위해 안전장치 (backstop)를 마련했지만, 기본값은 새로운 동작입니다. 이 기본값이 바로 파괴적 변경 (breaking change)입니다.

그리고 네 번째 사항으로, 두 단계 전인 v2.1.158 릴리스에서: /effort ultracode는 어떤 프롬프트에서든 수동으로 dynamic workflows를 요청하는 새로운 방식이 되었습니다. CLI 인터페이스와 프롬프트 인터페이스가 동일한 이름으로 수렴하고 있습니다. "workflow"라는 단어가 영어 단어 "workflow"(개발자가 "우리 CI workflow"와 같이 단순히 언급할 수 있는 단어)와 충돌하여 오탐 (false positives)을 생성했기 때문에, 디스패치 레이어 (dispatch layer)의 어휘에서 제거되고 있는 것입니다.

이것이 이번 이름 변경이 해결하는 실제 문제입니다. 이는 임의적인 결정이 아닙니다. 또한 이미 해당 키워드를 채택한 사용자들에게는 공짜가 아닙니다.

만약 당신이 X를 배포한다면, 당신이 대상입니다

퇴보 (regression)의 범주는 좁고 구체적입니다. 다음 중 하나라도 해당된다면 영향을 받습니다:

• workflow라는 단어를 문자 그대로 포함하고 있으며, 이를 통해 팬아웃 (fan-out)을 트리거하도록 의존하고 있는 CLAUDE.md, 슬래시 명령어 (slash command), 또는 저장된 프롬프트 템플릿 (prompt template)이 있는 경우
• 텍스트에 workflow를 포함하여 프롬프트를 claude --bg로 파이프라이닝하는 CI 작업 (CI job)이 있는 경우 — 당신의 야간 대규모 코드베이스 마이그레이션 (nightly large-codebase migration)은 이제 싱글 스레드 (single-threaded)로 동작합니다
• "workflow를 입력하여 병렬 서브 에이전트 (parallel subagents)를 실행하십시오"라고 기록된 팀 런북 (team runbook)이 있는 경우 — 오늘부터 당신의 온보딩 문서 (onboarding doc)는 틀린 정보가 됩니다
• 해당 키워드를 사용한 블로그 포스트를 작성했거나 5월에 X에 프롬프트를 공유한 경우 — 이를 복사하여 붙여넣는 모든 사람은 조용히 성능 저하를 겪게 됩니다
• 6월 2일에 프롬프트당 토큰 수 (tokens-per-prompt)가 갑자기 급감한 것을 보여주는 빌링 대시보드 (billing dashboard)가 있는 경우 — 빠른 경로 (fast path)가 작동을 멈췄기 때문에 팀이 더 적은 수의 서브 에이전트를 사용하고 있는 것입니다

영향을 받지 않는 클래스:

• 평이한 언어로 "X를 수행하기 위해 N개의 에이전트를 팬아웃 (fan out N agents) 하라"고 말한 경우 — 분류기 (classifier)가 여전히 이를 잡아냅니다
• /effort ultracode를 명시적으로 사용하는 경우 — 이는 이미 새로운 이름이었습니다
• auto 모드 분류기를 켜두고 시스템이 선택하도록 하는 경우 — 작업이 필요할 때 여전히 워크플로 (workflow)를 생성할 것입니다

실무 지침: 오늘 업무 종료 전까지 프롬프트 형태의 모든 파일에서 \bworkflow\b를 grep으로 검색하십시오. 만약 에이전트가 읽는 파일에 해당 단어가 나타난다면, 이전의 동작 방식을 유지할지 여부를 결정하십시오.

이 실패 모드 (failure mode)는 조용히 발생합니다. 에러가 발생하지 않습니다. 대신 더 느리고, 더 저렴하며, 병렬성이 낮은 실행 결과를 얻게 됩니다. 이는 언뜻 괜찮아 보일 수 있습니다 — 기존에 18분 만에 끝나던 마이그레이션이 이제 순차적 (sequential)으로 동작하여 4시간이 걸리게 될 때까지는 말입니다. 또한, 프롬프트의 절반은 싱글 에이전트 (single-agent) 모드로 떨어지고 나머지 절반은 분류기에 걸려 비용이 많이 드는 방식으로 진행됨에 따라, 월말 비용 보고서의 수치가 실제 수행한 작업량과 일치하지 않게 될 때까지는 말입니다.

가장 큰 타격을 입는 특정 팀 유형은 다음과 같습니다: 6주 전에 프롬프트 템플릿 (prompt template)을 확정하고, 관리형 CLAUDE.md를 통해 200명의 엔지니어에게 배포했으며, 일관성을 보장하기 위해 그 위에 CI 게이트 (CI gate)를 설정한 엔터프라이즈 팀 (enterprise teams)입니다. 이러한 팀들은 단순히 템플릿을 수정할 수 없습니다. 리뷰를 거쳐 새 버전을 배포하고, 롤아웃 (rollout)을 검증해야 합니다. v2.1.160 버전이 출시된 시점과 해당 템플릿이 패치되는 시점 사이의 시차는 퇴보 (regression) 현상이 실제로 발생하고, 관찰 가능하며, 그 순간에는 해결할 수 없는 공백기가 됩니다. 자체적으로 CLAUDE.md를 유지 관리하는 소규모 팀은 20분 만에 패치할 것입니다. 하지만 200명 규모의 팀은 패치하는 데 2주가 걸릴 것입니다.

메커니즘 — 왜 해당 키워드가 존재했어야 했고, 왜 사라져야 했는가

동적 워크플로 (Dynamic workflows)는 모델 기능 (model feature)이 아닙니다. 이는 디스패치 기능 (dispatch feature)입니다. Claude Code가 프롬프트를 읽을 때, 텍스트를 빠른 분류기 (fast classifier)에 통과시켜 한 가지를 결정합니다: 이 실행이 병렬 서브 에이전트 하네스 (parallel-subagent harness)를 생성해야 하는가, 아니면 단일 에이전트 (single agent)로 실행되어야 하는가? 분류기에는 세 가지 입력값이 있습니다:

1. 프롬프트 내 트리거 키워드 (trigger keyword)의 존재 여부 — 빠른 경로 (fast path), 지연 시간(latency) 거의 없음
2. 프롬프트의 의미론적 의도 (semantic intent) — 느린 경로 (slower path), 모델 기반 분류 (model-based classification)
3. /effort 설정 및 CLI 상의 명시적인 --ultracode 플래그

트리거 키워드가 존재하는 이유는 모델 기반 분류기 (model-based classifier)를 사용하는 비용이 저렴하지 않기 때문입니다.

has_trigger_keyword 단계는 이전에는 workflow를 매칭했습니다. v2.1.160부터는 ultracode를 매칭합니다. 분류기 (classifier) 단계는 여전히 일반적인 영어 요청을 잡아냅니다. 따라서 팬아웃 (fan-out) 기능이 사라지는 것은 아닙니다. 다만 키워드를 사용했을 때 무료였던 프롬프트들이, 이제는 모호한 프롬프트당 한 번의 분류기 호출 비용을 지불하게 된 것입니다.

왜 키워드를 변경해야 했을까요?

반대 의견 — "이것은 아무 일도 아닌 것이며, 분류기(classifier)는 여전히 작동한다"

앞으로 48시간 동안 이 이름 변경을 옹호하는 사람들로부터 다음과 같은 반박을 보게 될 것입니다. 분류기가 여전히 일반적인 영어 요청을 포착하므로, 이상할 정도로 문자 그대로(literal) 명령하지 않았던 사용자라면 사용자 경험(UX)은 변하지 않았다는 논리입니다. Anthropic의 문서에 따르면 다음과 같습니다:

동적 워크플로(Dynamic workflows)는 세 가지 방식으로 트리거될 수 있습니다: 프롬프트 내의 키워드, /effort ultracode 설정, 또는 본인의 언어로 병렬 작업을 요청하는 방식입니다.

그들의 주장은 이렇습니다. 만약 당신이 프롬프트 템플릿에 "workflow X"라고 작성했다면, 그것은 잘못된 방식이었다는 것입니다. 당신이 의도한 바에 따라 "X를 수행하기 위해 서브 에이전트들을 팬아웃(fan out)하라"라고 작성했어야 했다는 논리입니다. 즉, 해당 키워드는 항상 파워 유저를 위한 지름길(shortcut)이었을 뿐, 보장된 계약(contract)이 아니었다는 것입니다.

저는 이 주장을 완전히 받아들이지 않습니다. 해당 키워드는 문서화되어 있었습니다. 사람들은 그것을 기반으로 시스템을 구축했습니다. 분류기 경로(classifier path)는 결코 공짜가 아닙니다. 빠른 경로(fast path)를 사용하지 않는 모든 프롬프트에 200~400ms의 지연 시간을 추가하며, 분류기의 미검출률(false-negative rate)은 실재하는 문제입니다. Anthropic은 분류기의 재현율(recall) 수치를 공개하지 않는데, 이는 모델이 업데이트됨에 따라 매주 변하기 때문입니다. 만약 당신의 프롬프트가 "새로운 인증 훅(auth hook)을 사용하도록 모든 컴포넌트를 리팩터링하라"라고 되어 있고, 이것이 팬아웃(fan-out)을 트리거할 것이라고 가정한다면, 당신은 분류기가 적절한 임계값(threshold)을 맞추기를 도박처럼 기대하고 있는 것입니다. 이는 키워드를 사용하는 것보다 더 불확실한 계약입니다.

언급할 가치가 있는 두 번째 반박도 있습니다. 새로운 키워드인 ultracode 자체가 너무 많은 의미를 담고 있다는 점입니다. 이는 /effort 레벨의 이름이자, CLI 플래그이며, 아마도 미래의 설정 네임스페이스(config namespace)가 될 것입니다. Anthropic은 하나의 식별자를 네 가지 접점(surfaces)에서 재사용하고 있습니다. 이는 명명 일관성(naming-consistency) 관점에서는 우아할지 모르나, 디버깅 관점에서는 실수하기 쉬운 구조(footgun)입니다. 누군가 "왜 내 프롬프트가 팬아웃 되었나요?"라고 물었을 때, 이제 답변은 "키워드가 일치했기 때문입니다"가 아니라 "ultracode라는 이름을 가진 네 가지 요소 중 하나가 실행되었기 때문입니다"가 될 것입니다.

정확한 진단은 이렇습니다. 이름 변경은 전체적으로는 긍정적이지만, 그 비용은 기존 키워드를 기반으로 구축한 초기 사용자(early adopters)들이 전적으로 부담하게 됩니다. 마이그레이션(migration) 도구도 없고, 기존 키워드가 나타날 때 경고도 없으며, 프롬프트가 퇴보했을 때 이를 알려줄 텔레메트리(telemetry)도 없습니다. 당신이 직접 마이그레이션 도구가 되어야 합니다.

플레이북(The playbook) — 오늘 무엇을 해야 하는가

네 단계입니다. 그중 두 단계는 점심 식사 전에 완료해야 합니다.

1. 프롬프트 표면(prompt surface) 감사

Claude Code와 통신하는 모든 리포지토리(repo)에서 다음을 실행하세요:

rg -i --type-add 'prompt:*.{md,mdx,txt,prompt}' -t prompt -t yaml -t json \"\bworkflow\b\" --glob '!**/node_modules/**' \...

이 명령은 프롬프트 템플릿, 슬래시 명령어(slash command), 또는 스킬(skill) 형태를 가진 모든 파일에서 workflow라는 단어를 찾아냅니다. 문맥(context)에 따라 필터링하세요. 대부분의 일치 항목은 트리거 키워드가 아닌 일반 영어 단어일 것입니다. Claude 관련 토큰 옆의 프롬프트 형태 파일에 있는 항목들이 바로 마이그레이션해야 할 대상입니다.

2. 일치 항목별 결정: 패스트 패스(fast path) 유지, 분류기(classifier)로 전환, 또는 반전(invert)

각 일치 항목에 대해 세 가지 선택지가 있습니다. 수정한 줄 옆에 어떤 것을 선택했는지 기록하세요:

• 패스트 패스(Keep fast path) 유지 — workflow를 ultracode로 교체합니다. 트리거는 동일한 방식으로 작동하지만, 새로운 키워드 아래에서 실행됩니다. 기존 키워드가 제공했던 결정론적 팬아웃(deterministic fan-out) 동작을 원하는 경우 이 방법을 사용하세요.
• 분류기(Drop to classifier)로 전환 — 키워드를 삭제하고 일반 영어로 병렬 작업을 요청하도록 프롬프트를 다시 작성합니다. 팬아웃(fan-out)이 적절한 결정이었는지 확신할 수 없고, 실행 시마다 분류기(classifier)가 결정하도록 하고 싶을 때 이 방법을 사용하세요.
• 반전(Invert) — workflow를 일반 단어로 바꾸고 /config를 통해 트리거를 비활성화합니다. 프롬프트 템플릿이 실수로 패스트 패스(fast path)를 실행하고 있어 이를 중단시키고 싶을 때 이 방법을 사용하세요.

3. 공유 템플릿의 /config 설정 고정

새로운 /config 설정인 "Workflow keyword trigger"는 기본적으로 꺼져 있습니다 (키워드가 이제 ultracode로 변경되었기 때문입니다). 하지만 팀에서 기존 키워드를 표준으로 사용하고 있으며 30일간의 유예 기간을 두고 싶다면, 이 설정을 다시 켤 수 있습니다. 이 설정은 프롬프트(prompt) 단위가 아닌 설치(install) 단위로 적용되므로 ~/.claude/settings.json에 저장됩니다:

{
  "trigger": {
    "workflow_keyword": true
...