Claude Code의 동적 워크플로우: 111개 에이전트 연구 실행을 통해 배운 점

저는 실제 연구 과제에 Claude Code의 새로운 동적 워크플로우를 Opus 4.8로 사용해 보았습니다.

간단히 말하자면, 에이전트 개수는 흥미로웠지만 실패 처리 방식이 더 유용했습니다.

실행 내용

저는 내장된 워크플로우를 사용했습니다:

/deep-research <연구 질문>

질문은 여러 각도를 필요로 할 만큼 광범위했습니다: 의료 영상 관련 AI 프로젝트 이해, 가능한 사용 사례 비교, 경쟁사 조사, 제품의 약점 식별.

워크플로우를 실행한 후, 저는 다음 명령어로 이를 검사했습니다:

/workflows

이 보기에서는 단계 구조(phase structure), 에이전트 개수(agent counts), 토큰 총합(token totals), 그리고 실행 시간(runtime)을 보여줍니다.

단계별 분석

제 실행은 다섯 개의 단계로 나뉘었습니다:

단계 (Phase)	에이전트 (Agents)	목적 (Purpose)
Scope	1	연구 프레임 정의 (Define the research frame)
...
총합: 111개 에이전트.

중요한 주의사항: 이것은 111개의 에이전트가 동시에 실행되었다는 의미는 아닙니다. 핵심은 워크플로우가 여러 단계에 걸쳐 많은 서브 에이전트를 조정하는 스크립트와 같은 구조를 가졌다는 점입니다.

유용한 실패 처리

Verify 단계에서는 25개의 주장을 추출하여 각 주장을 세 개의 독립적인 에이전트로 확인하려고 시도했습니다.

그러자 실행이 부분적으로 중단되었습니다.

제 경우, 25개 주장 중 17개가 killed 상태로 끝났습니다. 문제는 구조화된 출력 실패(StructuredOutput failure)처럼 보였습니다.

듣기에는 안 좋은 일이지만, 워크플로우의 해석 방식이 유용했습니다.

이는 다음 세 가지로 분리했습니다:

• 확인됨 (confirmed);
• 모순됨 (contradicted);
• 검증되지 않음 (not verified).

17개의 killed된 주장 중 실제로 모순된 것은 2개에 불과했습니다. 나머지 15개는 거짓 주장이 아니라 불완전한 확인이었습니다.

이 구분이 중요합니다.

killed가 자동으로

일반적인 긴 채팅에서는 중간 상태(intermediate state)가 최종 답변으로 압축됩니다. 이는 편리하지만, 약점을 숨길 수 있습니다.

워크플로우(workflow)를 사용하면 계획이 스크립트로 이동합니다. 런타임(runtime)은 모든 것을 채팅 컨텍스트(chat context)에 강제로 밀어넣지 않고도 단계별 상태(phase state), 분기 로직(branch logic), 반복적인 확인(repeated checks), 그리고 실패한 에이전트(failed agents)를 유지할 수 있습니다.

덕분에 프로세스의 품질이 중요한 작업에 더 적합합니다:

• 코드베이스 감사 (codebase audits)
• 대규모 마이그레이션 (large migrations)
• 교차 검증된 연구 (cross-checked research)
• 반복적인 주장 검증 (repeated claim verification)
• 다각도 계획 수립 (multi-angle planning)

모든 작업에 적합한 것은 아닙니다. 작은 수정이나 빠른 디버깅(debugging)에는 과할 수 있습니다.

나의 체크리스트

동적 워크플로우를 실행하기 전에 저는 다음 사항들을 수행할 것입니다:

1. 질문의 범위를 좁힙니다.
2. 먼저 작은 버전으로 실행해 봅니다.
3. 최종 보고서뿐만 아니라 /workflows를 엽니다.
4. 실패(failed), 중단(killed), 모순(contradicted), 미검증(not-verified) 상태를 각각 별도로 조사합니다.
5. killed를 반박(refutation)으로 취급하지 마십시오.
6. 워크플로우가 유용하다는 것이 증명된 후에만 저장합니다.
7. 토큰(token) 사용량을 모니터링합니다.

핵심 요약 (Takeaway)

동적 워크플로우는 단순히 "더 많은 하위 에이전트(subagents)"를 사용하는 것이 아닙니다.

그것은 긴 작업을 조사 가능한 프로세스(inspectable process)로 전환하는 방법입니다.

저의 실행은 부분적으로 실패했지만, 그 실패는 가시적이었습니다. 자동화된 연구 및 코딩 에이전트(coding-agent) 작업의 경우, 불확실성을 숨기는 깔끔한 답변보다 가시적인 실패가 훨씬 더 낫습니다.

Claude Code, 코딩 에이전트 또는 장기 실행 워크플로우를 위해 Opus 4.8을 테스트하고 있다면, 모델 노트와 API 라우팅 세부 정보를 여기에 정리해 두었습니다: Claude Opus 4.8 API for Coding Agents.