Claude Code v2.1.154로 업데이트하면 /config에 새로운 행 Dynamic workflows가 나타난다. 이를 활성화하면 Claude는 이제 한 번에 최대 16개의 에이전트를 병렬로 실행하는 JavaScript 스크립트를 작성할 수 있다. 이것이 모두가 속닥거리는 기능이다. 공식 문서는 이것이 무엇을 하는지 설명한다. 하지만 실제로 신경 써야 할 것은 설명하지 않는다: 이 기능이 필요한가, 아니면 이미 가지고 있는 서브에이전트로 충분한가?
이것이 바로 문제다. Claude Code 워크플로우는 연구 미리보기로 출시되었으며, 문서는 조언이라기보다 참고 자료처럼 읽힌다. 그래서 우리는 번들로 제공되는 /deep-research 워크플로우를 직접 콘텐츠 파이프라인에서 실행했고, 실제 수치를 기록하고 솔직한 결론을 내렸다. 요약하면: 에이전트를 수동으로 추적할 수 있다면 아직 워크플로우가 필요하지 않다. 정말로 필요한 사람들은 소수다. 어느 그룹에 속하는지 알아보자.
주요 내용:
- Claude Code 워크플로우는 서브에이전트를 대규모로 조율하기 위해 Claude가 작성하는 JavaScript 스크립트다(연구 미리보기, v2.1.154+, 모든 유료 플랜).
- 한 대화가 조율할 수 있는 것보다 더 많은 에이전트가 필요할 때만 필요하다. 그렇지 않으면 서브에이전트로 충분하다.
- 현재 한 가지 워크플로우가 제공된다: /deep-research. 세션은 반응성을 유지하면서 백그라운드에서 실행된다.
- 워크플로우는 토큰을 많이 소비한다. 하나를 권장하기 전에 실제 실행을 측정했다(아래 수치 참조).
Claude Code 워크플로우란 무엇인가?
Claude Code 워크플로우는 서브에이전트를 대규모로 조율하는 JavaScript 스크립트다. 작업을 설명하면 Claude가 스크립트를 작성하고, 런타임이 백그라운드에서 이를 실행하는 동안 채팅 세션은 반응성을 유지한다. Claude Code의 연구 미리보기 기능이며, Claude Code v2.1.154+ 필요하고, 모든 유료 플랜에서 실행된다(Pro, Max, Team, Enterprise, API 및 Bedrock/Vertex/Foundry).
일상적인 예로 설명하자면 이렇다. 주방 카운터에 가서 원하는 음식을 설명한다고 생각해보자. 셰프가 레시피를 작성하고 뒷주방의 많은 요리사들에게 건네주며, 그들이 일하는 동안 당신은 카운터에서 계속 이야기한다. 당신은 각 요리사를 세세하게 관리하지 않는다. 레시피가 관리한다. 그 레시피가 워크플로우고, 요리사들이 서브에이전트이며, 뒷주방에서 실행되는 것이 런타임이다.
워크플로우는 다른 에이전트가 아니다. 에이전트들에게 무엇을 해야 하는지, 어떤 순서로 해야 하는지, 결과로 무엇을 해야 하는지 알려주는 스크립트다. 이 차이는 이 글에서 무엇보다 중요하며, 다음 섹션에서 구체적으로 설명하겠다.
이는 최근 fast mode 연구 미리보기 같은 Anthropic의 다른 연구 미리보기 드롭과 함께 제공된다: 조기에 출시되고, 토글 뒤에 있으며, 여전히 거친 부분이 있다. 미리보기이므로 미리보기처럼 취급하자. 전체 명세는 공식 워크플로우 문서에 있다.
워크플로우 vs 서브에이전트 vs 스킬: 누가 계획을 관리하는가?
이 세 가지를 구별하는 가장 깔끔한 방법은 한 가지 질문을 하는 것이다: 누가 계획을 관리하는가? 스킬은 Claude가 필요에 따라 로드하는 패키지된 지침과 지식이다. 서브에이전트는 위임된 작업 하나를 수행하는 별도의 컨텍스트다. 워크플로우는 한 번에 최대 16개의 서브에이전트를 조율하는 오케스트레이션 스크립트다. 같은 도구 모음, 세 가지 다른 역할.
공식 문서가 암시하지만 나란히 배치하지 않는 비교는 다음과 같다:
한 Claude 대화가 여전히 전체 계획을 머리에 담을 수 있다면 워크플로우가 아니라 서브에이전트를 원한다. 당신 자신이 추적할 수 있는 것보다 더 많은 에이전트를 생성하기 시작하면, 누가 무엇을 어떤 순서로 하는지 계획이 대화의 범위를 벗어난다. 그것이 워크플로우를 교차하는 선이다.
첫 번째 부분에 대해 더 알고 싶은가? 우리의 스킬 튜토리얼은 Claude가 필요에 따라 로드하는 패키지된 지식 포장에 대해 다룬다. 그리고 기본 오케스트레이션 대신 전체 에이전트 프레임워크를 사용할지 말지를 고민 중이라면, 그 비교도 도움이 된다. 우리의 솔직한 의견: 기본 프리미티브는 프레임워크가 가치를 입증하기 전에 생각하는 것보다 훨씬 더 멀리 간다.
Claude Code 워크플로우가 정말 필요한 시점은 언제인가?
(a) 작업이 한 대화가 조율할 수 있는 것보다 더 많은 에이전트가 필요하거나, (b) 일회성 프롬프트 대신 재실행 가능한 코드로 오케스트레이션을 저장하려고 하거나, (c) 여러 에이전트가 서로의 작업을 확인하는 대립적이거나 교차 검증된 검토가 필요할 때 Claude Code 워크플로우가 필요하다. 이 중 어느 것도 해당하지 않으면 서브에이전트로 충분하다. 여기서는 솔직해야 한다.
문서가 입 밖으로 꺼내지 않을 부분이지만 우리는 말할 것이다: 아직 워크플로우가 필요하지 않을 가능성이 높다. 소수의 서브에이전트를 일반적인 대화 전반에서 조율하면 일상 업무를 처리한다. 워크플로우는 졸업하는 업그레이드가 아니다. 하나의 특정 문제 형태를 위한 도구다: 한 사람의 뇌가 추적할 수 있는 것보다 더 많은 에이전트.
다음 체크리스트를 통해 자신을 점검해보자. 다음 중 하나 이상에 "예"라고 답하면 워크플로우가 필요할 가능성이 높다:
- 작업이 한 대화가 추적할 수 있는 것보다 더 많은 에이전트가 필요하다.
- 일회성 프롬프트가 아니라 재실행 가능한 코드로 오케스트레이션을 원한다.
- 여러 에이전트가 서로를 검증하는 대립적이거나 교차 검증된 검토가 필요하다.
- 반복적인 코드베이스 감사나 500개 파일 마이그레이션처럼 동일한 멀티에이전트 작업을 반복해서 실행할 것이다.
네 가지 모두 아니라고 답했는가? 서브에이전트를 유지하자. 토큰을 절약하고, 디버깅 가능성을 유지하고, 아무것도 잃지 않는다. 명세 중심의 사람들은 좋은 CLAUDE.md 모범 사례에서 이 패턴을 인식할 것이다: 계획을 한 번 적어두고, 재실행 가능하게 만들고, 다시 타이핑하지 말자. 워크플로우는 그 아이디어를 계획 자체가 실행하기 위해 런타임이 필요한 지점까지 밀어붙인 것이다.
이미 가진 워크플로우: /deep-research
/deep-research는 미리보기에서 제공되는 유일한 번들 워크플로우다. 질문과 함께 호출하면 서브에이전트를 병렬로 분산시켜 주제를 연구하고, 그들의 발견을 서로 교차 검증하고, 세션이 사용 가능한 상태를 유지하면서 백그라운드에서 합성된 하나의 답변을 컨텍스트로 반환한다.
그것이 전체 인터페이스다. 내부적으로는 여러 단계를 거친다: 질문을 연구 스레드로 분해하고, 각 에이전트를 생성해 각각을 추적하고, 에이전트들이 서로의 약한 주장을 잡아낼 수 있도록 교차 검증이나 검토 단계를 실행한 다음, 최종 답변을 채팅으로 합성한다. 실행 중에 이를 조종하지 않는다. 질문하고, 작동하고, 보고된다.
이것은 그렇지 않으면 열 개의 탭을 열고 오후를 낭비할 지저분한 연구 질문에 정말 유용하다. 이미 연구 도구를 연결하고 있다면, 최고의 MCP 서버에 대한 우리의 정리가 이런 종류의 분산형 연구와 잘 어울린다. 하지만 "유용하다"와 "토큰 청구서를 낼 가치가 있다"는 같지 않으며, 이는 정확히 우리가 측정하려고 한 것이다.
워크플로우를 자체 파이프라인에서 실행한 결과
우리의 /deep-research 실행은 4개 단계에 걸쳐 9개의 서브에이전트를 생성했고, 100만 토큰을 조금 넘게 소비했으며, 벽시계 시간으로 약 8분이 걸렸다. 가치가 있었는가? 빠른 질문의 경우 가능성이 없다. 그렇지 않으면 수십 개의 에이전트를 손으로 조율해야 하는 연구 작업의 경우, 그것이 자신을 보상했다. 다음이 솔직한 분석이다.
우리의 파이프라인에서, 당신이 지금 읽고 있는 이 글은 멀티에이전트 시스템으로 생산되었다: 연구, 브리프, 작성, 검증, 번역, 출판이 각각 별도의 서브에이전트로 실행된다. 따라서 우리는 이미 위의 체크리스트에서 "한 대화에 포함하기에 너무 많은 에이전트"라는 세상에 살고 있다. 이것이 우리를 대립된 테스트 케이스가 아니라 올바른 테스트 케이스로 만들었다.
우리는 이미 연구 중인 라이브 키워드에 대해 /deep-research를 실행했고 전체 실행을 기록했다:
...