"서브에이전트" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

터미널 두 개에 Claude Code를 띄워 놓고 한쪽 결과를 복사해서 다른 쪽에 붙여넣던 시절이 있었어요. 이번 주 릴리스로 그 복붙이 공식적으로 필요 없어졌습니다.

2.1.232 changelog의 첫 두 줄이 핵심입니다. 서브에이전트 포크가 기본 활성화됐고, 프롬프트에서 @를 입력하면 다른 세션을 이름으로 직접 부를 수 있습니다. 따로 보면 각각 작은 기능인데, 합치면 "세션 하나 = 작업 하나"라는 전제가 무너집니다.

포크: 문맥을 통째로 물려받는 서브에이전트​

기존 서브에이전트의 약점은 기억상실이었습니다. 새 에이전트는 빈 문맥에서 출발하니, 지금까지 대화에서 쌓인 맥락을 프롬프트에 꾹꾹 눌러 담아 전달해야 했습니다. 전달이 부실하면 엉뚱한 결과가 돌아왔습니다.

subagent_type: "fork"로 뜨는 포크 에이전트는 부모의 대화 전체와 프롬프트 캐시를 상속합니다. 지금까지 읽은 파일, 내린 결정, 사용자가 준 피드백을 전부 아는 상태로 출발합니다. 캐시까지 물려받으니 그 문맥을 다시 처리하는 비용도 들지 않습니다.

함께 바뀐 기본값이 하나 더 있습니다. 대화형 세션에서 띄우는 에이전트는 이제 배경 실행이 기본입니다. 에이전트가 도는 동안 메인 세션이 멈춰 기다리지 않고, 끝나면 알림으로 결과가 돌아옵니다. 에이전트의 도구 호출 로그가 메인 문맥을 차지하지도 않습니다. 정리하면 "무거운 조사나 검증은 포크로 떼어 배경에서 돌리고, 메인은 계속 진행한다"가 이제 설정 없이 되는 기본 동작입니다.

@멘션: 세션끼리 직접 대화​

두 번째 변화는 세션 간 통신입니다. 프롬프트에 @를 입력하면 같은 머신에서 돌고 있는 다른 Claude 세션 목록이 뜨고, 이름을 고르면 그 세션으로 메시지가 갑니다. 내부적으로는 SendMessage 도구를 사용합니다.

이걸 받쳐 주는 손질도 같이 들어갔습니다.

• 이름이 정확히 하나의 살아 있는 세션과 일치하면 확인 절차 없이 바로 전달됩니다
• 한 머신의 대화형 세션들은 고유한 이름을 유지합니다. 이미 쓰는 이름으로 시작하면 자동으로 변형된 이름을 받습니다
• /config에 다른 세션에서 오는 메시지를 받을지(수락/보류/거부) 정하는 항목이 생겼습니다

블로그 작업으로 예를 들면 이렇게 됩니다. 포스트 A를 쓰는 세션과 포스트 B를 쓰는 세션을 나란히 띄워 두고, A 세션에서 @세션B 방금 정한 용어 표기를 너도 맞춰 줘라고 보내면 끝입니다. 사람이 두 터미널 사이에서 전서구 노릇을 할 필요가 없습니다. 지시는 각 세션에 직접 하되, 세션끼리 맞출 것은 세션끼리 맞추게 하는 구조입니다.

Opus 4.8 리뷰에서 "한 사람에게 맡기던 일을 한 팀에게 맡긴다"고 썼는데, 이번 릴리스는 그 팀에게 사내 메신저를 지급한 셈입니다. Dynamic Workflows가 한 세션 안의 수직 분업이라면, @멘션은 세션 사이의 수평 분업입니다.

2.1.233: worktree의 GitLab MR, cgroup 메모리 제한​

다음 날 나온 2.1.233에서 운영 관점의 항목 둘이 눈에 띕니다.

GitLab 지원 확대. --worktree 플래그와 claude agents 뷰가 GitLab merge request URL을 인식합니다(MR은 !N으로 표시). 2.1.232에서 이미 GitLab 토큰 계열(glpat- 등) 시크릿 마스킹과 GitLab 플러그인 마켓플레이스 지원이 들어왔으니, 이틀 사이에 GitLab 사용자 대접이 눈에 띄게 좋아졌습니다. GitHub 전용이라 망설이던 조직에는 신호가 될 만합니다.

Bash 도구 메모리 제한. Linux에서 CLAUDE_CODE_TOOL_MEMORY_LIMIT 환경변수로 Bash 명령에 cgroup 메모리 제한을 걸 수 있습니다(opt-in). 에이전트가 실행한 빌드가 폭주해 메모리를 삼키면 세션까지 같이 죽던 문제의 대응입니다. CI 러너나 공용 개발 서버에서 Claude Code를 돌리는 환경이라면 켜 둘 가치가 있습니다.

하나 더, 방향을 보여주는 항목이 있습니다. Opus 4.8과 그 이후 모델에서 todo/task 추적 도구(TodoWrite, TaskCreate 등)가 기본 비활성화됐습니다. 되살리려면 CLAUDE_CODE_ENABLE_TODO_TOOLS=1을 설정해야 합니다. 신형 모델은 할 일 목록을 도구로 관리시키지 않아도 작업을 놓치지 않는다는 판단이 깔린 변경입니다. 화면에서 todo 목록이 사라졌다면 버그가 아니라 이 변경입니다.

써 보고 느끼는 것​

이 글을 쓰는 세션도 뉴스 수집을 포크 에이전트 여섯에 나눠 맡기고, 결과를 메시지로 돌려받는 흐름으로 작업했습니다. 수집 에이전트들이 배경에서 도는 동안 메인 세션은 기존 포스트 목록을 정리했고, 끝난 에이전트부터 결과가 도착했습니다. 복붙도, 파일 경유도 없었습니다.

체감 요령을 남기면, 포크에는 "지금까지의 문맥이 필요한 일"을, 일반 서브에이전트에는 "문맥이 오히려 편견이 되는 일"(백지 검증, 독립 리뷰)을 맡기는 구분이 유효했습니다. 포크가 기본이 됐다고 전부 포크로 보낼 일은 아니에요. 문맥 상속은 힘이면서 동시에 선입견이니까요.

참고 자료​

• Claude Code CHANGELOG (2.1.232, 2.1.233) - Anthropic, 2026-08-13~14
• Claude Code 공식 문서

또 한 단계 올라갔다​

Skills로 명령어를 통합하고, Routines로 예약 실행을 붙이고, Auto 모드로 권한 판단까지 AI에게 넘기더니, 이번엔 Claude가 오케스트레이션 스크립트를 직접 짜서 서브에이전트 수백 개를 한 세션에서 병렬로 돌리는 Dynamic Workflows가 2026년 5월 28일 Opus 4.8과 함께 공개됐어요.

지금까지의 서브에이전트는 Claude가 대화 턴마다 하나씩 띄우고 결과를 자기 컨텍스트로 받아오는 방식이었습니다. 몇 개까지는 괜찮지만, 500개 파일을 동시에 손봐야 하는 작업에서는 컨텍스트가 먼저 터집니다. Dynamic Workflows는 그 한계를 넘으려고 나온 기능입니다. (Anthropic 발표, TechCrunch)

주의: 이 글의 내용은 전부 리서치 프리뷰 기준입니다. 동작 방식, 한도, 요금 모두 정식 출시 전에 바뀔 수 있습니다. Claude Code v2.1.154 이상이 필요합니다.

한 줄 정의​

공식 문서의 정의는 명확합니다.

"A dynamic workflow is a JavaScript script that orchestrates subagents at scale." — Claude Code Docs

워크플로우는 Claude가 작성하는 자바스크립트 오케스트레이션 스크립트입니다. 사용자가 작업을 설명하면 Claude가 그 작업에 맞는 스크립트를 쓰고, 런타임이 그 스크립트를 백그라운드에서 실행합니다. 스크립트가 도는 동안 대화 세션은 그대로 응답 가능한 상태로 남습니다.

중요한 차이는 누가 계획을 들고 있느냐에 있습니다.

서브에이전트/스킬과 무엇이 다른가​

셋 다 멀티스텝 작업을 처리할 수 있습니다. 차이는 계획의 주체와 중간 결과의 저장 위치입니다.

서브에이전트와 스킬에서는 Claude가 오케스트레이터입니다. 무엇을 띄울지 턴마다 판단하고, 모든 결과가 Claude 컨텍스트로 돌아옵니다. 워크플로우는 그 루프와 분기, 중간 결과를 스크립트 안으로 옮깁니다. 그 결과 Claude 컨텍스트에는 최종 답만 남습니다. 그래서 컨텍스트가 터지지 않습니다.

어떻게 도는가​

작업을 워크플로우로 넘기면 세 단계를 거칩니다.

대화 세션은 이 흐름 내내 자유롭습니다. /workflows를 실행하면 진행 중인 런의 진행 화면이 뜨고, 단계별 에이전트 수와 토큰 사용량, 경과 시간을 볼 수 있습니다.

패턴 1: Fan-Out​

워크플로우가 시작되면 Claude가 프롬프트를 기준으로 계획을 세우고, 작업을 서브태스크로 쪼갠 뒤 여러 에이전트에 병렬로 펼칩니다. 이걸 fan-out이라 부릅니다. 한 런에서 수십에서 수백 개의 에이전트가 동시에 돕니다.

예를 들어 라우트 디렉토리 전체에서 인증 누락을 감사하라고 하면, 엔드포인트마다 에이전트 하나씩 붙여 동시에 점검합니다.

Run a workflow to audit every API endpoint
under src/routes/ for missing auth checks

프롬프트에 트리거 키워드를 넣으면 Claude Code가 그 단어를 강조 표시하고, 턴 단위로 처리하는 대신 워크플로우 스크립트를 작성합니다. 발표 직후에는 workflow가 트리거였지만, 2026년 6월 2일 v2.1.160에서 트리거 키워드가 ultracode로 바뀌었습니다. 이제 workflow라는 단어만으로는 런이 시작되지 않습니다. 다만 평소 쓰는 말로 워크플로우를 요청하는 건 그대로 동작합니다. (Claude Code Changelog)

패턴 2: 어드버서리얼 검증​

여기가 단순히 에이전트를 더 많이 돌리는 것과 갈리는 지점입니다. 워크플로우는 반복 가능한 품질 패턴을 적용합니다.

에이전트가 발견한 내용을 그냥 보고하지 않습니다. 다른 에이전트가 그 발견을 반박하는 임무를 맡습니다. 한 에이전트가 "이 함수에 race condition이 있다"고 주장하면, 다른 에이전트는 그 주장을 깨는 일을 맡습니다. 반박을 거치고도 살아남은 주장만 사용자에게 전달됩니다.

번들로 제공되는 /deep-research 워크플로우가 이 패턴을 그대로 씁니다. 여러 각도로 웹 검색을 펼치고, 찾은 출처를 서로 교차검증하고, 각 주장에 투표한 뒤, 교차검증을 통과하지 못한 주장은 걸러낸 인용 리포트를 돌려줍니다.

패턴 3: 수렴 반복​

고정된 단계의 파이프라인이 아닙니다. 워크플로우는 답이 더 이상 바뀌지 않을 때까지 반복합니다. 에이전트 수와 반복 횟수는 작업이 실제로 요구하는 바에 따라 실시간으로 정해집니다.

이 수렴 방식 덕분에 단일 패스로는 도달할 수 없는 결과까지 갑니다. 한 번 훑고 끝내는 게 아니라, 발견과 반박을 답이 안정될 때까지 돌리는 구조입니다.

실제 사례: Bun을 Zig에서 Rust로​

가장 인상적인 사례는 Jarred Sumner가 Bun 런타임을 Zig에서 Rust로 포팅한 작업입니다. 약 75만 줄 코드를 11일 만에 옮겼습니다. 파일마다 에이전트를 붙여 수백 개를 병렬로 돌렸고, 파일당 리뷰어를 두 명씩 뒀습니다. (Anthropic 발표)

Anthropic은 이 기능의 목표를 "코드베이스 규모의 마이그레이션을 킥오프부터 머지까지, 기존 테스트 스위트를 합격 기준으로 삼아 수행"하는 것으로 잡았습니다. (TechCrunch) 기존 테스트가 통과 여부를 판정하니, 사람이 일일이 검수하지 않아도 합격선이 정의됩니다.

발표의 표현을 빌리면 분기 단위로 계획하던 일이 며칠 만에 끝납니다. 다만 이건 잘 풀린 사례입니다. 테스트 커버리지가 부실한 코드베이스라면 합격 기준 자체가 흔들립니다.

한도와 제약​

런타임에는 다음과 같은 제약이 있습니다.

수백 개 병렬이라는 표현과 동시 16개가 충돌하는 것처럼 보이지만, 동시 실행은 16개로 묶이고 누적 총량이 런당 최대 1,000개라는 뜻입니다. (Claude Code Docs, MarkTechPost)

권한 측면도 짚어둘 만합니다. 세션 권한 모드와 무관하게, 워크플로우가 띄우는 서브에이전트는 항상 acceptEdits 모드로 돌고 파일 편집은 자동 승인됩니다. 긴 런에서 셸 명령이나 MCP 도구로 중간에 멈추고 싶지 않다면, 시작 전에 필요한 명령을 allowlist에 넣어두는 편이 낫습니다.

어떻게 켜고 끄는가​

워크플로우를 작성하게 하는 방법은 두 가지입니다.

발표 시점의 트리거 키워드는 workflow였으나 v2.1.160(2026년 6월 2일)에서 ultracode로 바뀌었습니다. 예전 글이나 영상에서 workflow라고 적으라는 안내를 봤다면 키워드만 바꿔 읽으면 됩니다.

ultracode는 xhigh effort(추론 강도)와 자동 워크플로우 오케스트레이션을 묶은 설정입니다. 켜두면 Claude가 작업마다 워크플로우가 필요한지 알아서 판단합니다. 한 요청이 여러 워크플로우로 갈라질 수도 있습니다. 코드 이해용 하나, 변경용 하나, 검증용 하나 식으로. 그만큼 토큰과 시간을 더 씁니다.

마음에 드는 런이 나오면 /workflows에서 그 런을 골라 s 키로 명령어로 저장할 수 있습니다. 프로젝트의 .claude/workflows/에 두면 저장소를 받은 모두가 쓰고, 홈의 ~/.claude/workflows/에 두면 저만 써요.

끄는 방법도 명확합니다.

• /config에서 Dynamic workflows 토글 끄기
• ~/.claude/settings.json에 "disableWorkflows": true
• 환경변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1
• 조직 전체는 managed settings의 "disableWorkflows": true

요금과 가용성​

• 리서치 프리뷰. Claude Code v2.1.154 이상 필요
• 유료 플랜 전체에서 사용 가능 (Pro는 /config에서 켜야 함). 발표 기준 Max, Team, Enterprise는 기본 활성화
• Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry 지원
• 토큰 소비가 일반 세션보다 크게 많습니다. 에이전트를 수십~수백 개 띄우니 당연합니다

비용 관리 팁도 문서에 있습니다. 큰 런 전에 /model을 확인하고, 강한 모델이 필요 없는 단계는 작은 모델로 라우팅하도록 작업 설명에 명시하면 됩니다.

함께 나온 Opus 4.8은 자기 작업의 불확실성을 더 적극적으로 드러내고, 근거 없는 주장을 덜 한다는 평가입니다. 어드버서리얼 검증 패턴과 맞물려 보면, 모델이 스스로 의심을 표하는 성향이 강해진 게 수백 개 에이전트를 신뢰하는 데 보탬이 됩니다. Fast 모드는 2.5배 속도로 동작하면서 이전 모델보다 3배 저렴해졌습니다. (Anthropic Opus 4.8 발표)

운영자 시각에서 한마디​

Dynamic Workflows의 본질은 에이전트를 더 많이 돌리는 게 아니라 계획을 코드로 옮기는 데 있습니다. 오케스트레이션이 읽고 다시 돌릴 수 있는 스크립트로 굳으면, 매 브랜치마다 같은 리뷰를 같은 방식으로 돌릴 수 있습니다. 일회성 마법이 아니라 반복 가능한 프로세스가 된다는 뜻입니다.

다만 지금은 리서치 프리뷰입니다. 한도도 동작도 바뀔 수 있고, 토큰 비용은 만만치 않습니다. 처음 쓴다면 작은 작업으로 범위를 좁혀 토큰 사용 패턴부터 감을 잡으라는 게 공식 권고입니다.

그래도 방향은 분명해요. 75만 줄 마이그레이션을 11일에 끝냈다는 사례가 과장이 아니라면, 분기 단위 작업의 정의가 다시 쓰이는 중이에요. Skills, Routines, Auto 모드에 이어 이번엔 오케스트레이션 자체가 자동화됐습니다. 따라가는 것만으로도 벅차지만, 한 번쯤 직접 /deep-research부터 돌려보는 게 감을 잡는 가장 빠른 길입니다.

참고 자료​

• Orchestrate subagents at scale with dynamic workflows — Claude Code Docs
• Introducing dynamic workflows in Claude Code — Anthropic Blog
• Introducing Claude Opus 4.8 — Anthropic
• Anthropic releases Opus 4.8 with new 'dynamic workflow' tool (TechCrunch)
• Anthropic Ships Claude Opus 4.8 Alongside Dynamic Workflows, Capped at 1,000 Subagents (MarkTechPost)