클로드 코드 Dynamic Workflow로 낡은 하네스 다이어트하기

여러분, 이번 글에서 다루고 싶은 건 Claude Code의 Dynamic Workflows를 소개하는 데서 끝나지 않습니다. 새 기능을 단순히 써보는 게 아니라, 실제로 오래 쌓인 코딩 에이전트 하네스를 진단하고 정리하는 데 적용해 보겠습니다.

하네스는 코딩 에이전트를 더 안정적으로 쓰기 위해 붙이는 안전장치입니다. CLAUDE.md, AGENTS.md, Skills, Hooks, MCP 설정, allowed tools 같은 것들이 여기에 포함되죠. 문제는 한 번 만든 하네스가 영원히 좋은 상태로 남지 않는다는 점입니다. 모델도 좋아지고, Claude Code나 Codex, Cursor 같은 도구 자체도 계속 진화하잖아요. 그러면 예전에는 꼭 필요했던 규칙이 지금은 중복 지시가 되거나, 오히려 에이전트의 기본 동작을 방해할 수 있습니다.

그래서 Dynamic Workflows를 사용해 두 가지 워크플로우를 만들어 보겠습니다.

• /harness-legacy-scan: 현재 하네스를 읽기 전용으로 감사하고 레거시 항목을 찾는 워크플로우
• /harness-diet: 스캔 리포트를 바탕으로 low-risk 개선만 적용하는 워크플로우

여기서 사용한 프롬프트는 Gist에 공유해 두었습니다.

하네스가 레거시가 되는 이유

예전에는 코딩 에이전트가 지시를 잘 놓쳤기 때문에 강한 울타리가 필요했습니다. 예를 들어 이런 규칙들이 많았습니다.

• 반드시 특정 파일부터 읽어라
• 바로 구현하지 말고 계획부터 세워라
• 테스트 없이 끝내지 마라
• 특정 작업에서는 무조건 특정 절차를 따라라

이런 규칙은 당시에는 유효했습니다. 하지만 시간이 지나면 상황이 바뀌죠. LLM 모델 성능이 좋아지고, Claude Code 같은 코딩 에이전트 자체에 파일 읽기, 코드 수정, 터미널 실행, 메모리, 툴, 스킬 같은 하네스 레이어가 내장됩니다. 결국 우리가 만든 하네스는 코딩 에이전트라는 하네스 위에 다시 얹힌 또 하나의 하네스가 되는 셈입니다.

이때 3개월 전에는 필요했던 규칙이 지금은 불필요할 수 있습니다. 또는 제품에 더 좋은 방식이 들어와서 기존 커스텀 규칙이 중복될 수도 있고요. 그래서 이제는 “어떤 하네스를 더 붙일까”보다 “이미 쌓인 하네스 중 무엇을 덜어낼까”가 중요해지는 시점이라고 봅니다.

Dynamic Workflows란 무엇인가

Dynamic Workflows는 JavaScript 스크립트로 여러 서브 에이전트를 오케스트레이션하는 Claude Code 기능입니다. 사용자가 작업을 요청하면 Claude Code가 그 작업에 맞는 워크플로우 스크립트를 만들고, 이를 백그라운드에서 실행하죠.

여기서 제가 중요하게 보는 건 메인 세션을 계속 쓸 수 있다는 점입니다. 워크플로우는 별도 백그라운드 흐름으로 돌아가고, 사용자는 현재 세션에서 다른 작업을 이어갈 수 있습니다. 대규모 리서치나 감사처럼 오래 걸리고 여러 관점이 필요한 작업에 잘 맞습니다.

실행하는 방법은 크게 세 가지입니다.

1. 프롬프트에 ultracode 키워드를 넣어 워크플로우 실행을 유도합니다.
2. “워크플로우로 이 작업을 진행해줘”처럼 자연어로 요청합니다.
3. effort 설정에서 ultracode 성격의 실행 강도를 선택합니다.

평소에는 모든 작업을 ultracode로 돌릴 필요가 없습니다. 저는 기본 작업은 일반 effort로 두고, 정말 여러 단계와 병렬 검증이 필요한 작업에서만 ultracode나 워크플로우 요청을 쓰는 방식을 권합니다.

/deep-research로 본 워크플로우의 기본 구조

Claude Code에는 기본 내장 워크플로우인 /deep-research가 있습니다. 골격을 먼저 보기 위해 이 기능부터 실행해 봤습니다.

요청 내용은 Claude Code 사용자들이 CLAUDE.md, AGENTS.md, Skills, Hooks를 어떻게 쓰는지, 잘 쓰는 사람들의 공통 패턴과 흔한 실수를 조사해 달라는 것이었습니다. /deep-research는 이 요청을 백그라운드 워크플로우로 실행했죠.

진행 상황은 /workflows 명령어로 확인할 수 있습니다. 실제로 돌려보니 흐름은 다음과 같았습니다.

단계	역할	실행 중 보인 특징
Search	검색 범위 수집	6개의 서브 에이전트가 병렬 검색
Fetch	웹 문서 수집	28개의 서브 에이전트가 출처 수집
Verify	적대적 검증	75개의 서브 에이전트가 주장 검토
Synthesize	종합	검색, 수집, 검증 결과를 합성
Report	최종 보고	메인 세션에는 최종 결과만 전달

최종적으로 /deep-research는 28개의 출처와 55개의 주장을 바탕으로 보고서를 만들었습니다. 제가 더 중요하게 보는 건, 메인 에이전트의 컨텍스트에 모든 검색 과정이 그대로 쌓이지 않는다는 점이에요. 많은 서브 에이전트가 각자 작업하고, 메인 세션은 최종 결과만 받아보니까 컨텍스트를 더 효율적으로 쓸 수 있습니다.

Workflows, Skills, Subagents, Agent Teams의 차이

여기서 제가 가장 강조하고 싶은 건 “계획을 누가 들고 있느냐”입니다. 기능 이름만 보면 Subagents, Skills, Agent Teams, Workflows가 비슷해 보이지만, 실제 차이는 플랜을 관리하는 위치에 있죠.

구분	플랜 관리 위치	적합한 작업
Subagents	각 서브 에이전트의 턴 단위	독립적인 작은 조사나 검토
Skills	메인 세션과 스킬 지침	반복 절차, 도메인별 작업
Agent Teams	팀 리드 에이전트	여러 담당 에이전트가 필요한 협업
Dynamic Workflows	JavaScript 워크플로우 스크립트	수십 개 이상의 에이전트가 필요한 리서치, 감사, 검증

워크플로우는 플랜이 스크립트에 들어가기 때문에 규모를 키우기 쉽습니다. Anthropic 공식 문서 기준으로 최대 동시 16개의 서브 에이전트, 하나의 실행에서 누적 1,000개의 서브 에이전트까지 활용할 수 있습니다.

첫 번째 워크플로우: /harness-legacy-scan

첫 번째로 만든 워크플로우는 /harness-legacy-scan입니다. 목적은 내 코딩 에이전트 하네스를 읽기 전용으로 감사하는 거예요. 여기서는 어떤 파일도 수정하지 않고, 현재 하네스 구조의 문제를 찾는 데 집중합니다.

프롬프트에 넣은 목표는 다음과 같습니다.

• 낡은 규칙 찾기
• 중복 지식 찾기
• 과도한 전역 컨텍스트 찾기
• 너무 넓은 Skill 찾기
• 불필요한 Hooks, MCP, allowed tools 점검
• Claude Code, Codex, Cursor 같은 제품 기본 기능과 중복되는 설정 찾기

이 작업은 단일 관점으로 보면 위험합니다. 어떤 규칙은 낡아 보이지만 실제로 중요한 안전장치일 수 있거든요. 그래서 여러 관점의 에이전트를 나눠 설계했습니다.

에이전트	역할
Inventory Agent	하네스 관련 파일과 설정 목록화
Global Context Tax Agent	CLAUDE.md, AGENTS.md, Cursor Rules의 전역 컨텍스트 비용 분석
Skill Curator Agent	Skill 필요성, description 범위, SKILL.md 길이 분석
Product Overlap Agent	Claude Code, Codex, Cursor 기본 기능과의 중복 점검
Safety Permission Agent	Hooks, allowed tools, MCP 권한 과다 여부 점검
Refactor Planner Agent	KEEP, SHRINK, MOVE, SPLIT, CONVERT, DELETE 분류
Adversarial Reviewer	삭제하거나 줄이면 위험한 항목 반박 검토

실행된 워크플로우는 네 단계로 나뉘었습니다.

1. Inventory: 하네스 설정 파일을 로드하고 구조를 파악합니다.
2. Analyze: Skills, product overlap, safety permission 등을 여러 서브 에이전트가 분석합니다.
3. Plan: Refactor Planner가 유지, 압축, 이동, 분리, 삭제 후보를 정리합니다.
4. Adversarial Review: high-risk 항목을 비판적으로 다시 검토합니다.

실제 실행 결과로는 16개의 에이전트가 사용됐고, 109개의 항목이 발견됐으며, 약 160만 토큰을 썼고, 실행 시간은 약 17분이었습니다. 최종 리포트에는 유지해야 할 하네스, 줄여야 할 하네스, 나눠야 할 하네스, 옮겨야 할 하네스, 삭제 후보가 구분되어 정리됐습니다.

두 번째 워크플로우: /harness-diet

두 번째 워크플로우는 /harness-diet입니다. 이 워크플로우는 /harness-legacy-scan 리포트를 바탕으로 실제 하네스를 정리합니다.

여기서 중요한 원칙은 low-risk 개선만 적용한다는 점입니다. 하네스는 삭제를 잘못하면 에이전트의 안전장치가 사라질 수 있죠. 그래서 스캔 결과 전체를 무작정 적용하지 않고, 위험도가 낮은 개선만 자동화 대상으로 삼았습니다.

실행 구조는 크게 두 단계였습니다.

단계	역할
Split	너무 긴 Skill을 reference나 examples로 분리
Refine	불필요한 description, 중복 지시, 넓은 지침을 정리

워크플로우가 진행되는 동안 여러 에이전트가 병렬로 스킬을 개선했습니다. 그리고 변경 후에는 개선된 스킬이 정상 동작하는지도 확인하는 검증 단계가 이어졌죠.

최종 적용 리포트 결과는 다음과 같습니다.

• 약 10개의 Skill 정리
• 신규 reference 12개 추가
• 일부 항목 보관 처리
• SKILL.md 본문이 약 2,600줄에서 약 1,800줄로 감소
• 약 760줄 절감
• 활성 Skill 수가 29개에서 28개로 감소
• notion-workspace Skill 보관 처리

특히 notion-workspace Skill은 최근 제 컨텍스트 관리 방식이 Notion 중심에서 Obsidian과 로컬 wiki 중심으로 옮겨갔기 때문에, 더 이상 자주 쓰지 않는 레거시 스킬로 판단되어 보관 처리됐습니다. 이처럼 하네스 다이어트는 무조건 줄이는 작업이 아니라, 현재 업무 방식과 맞지 않는 하네스를 다시 배치하는 작업이라고 보면 됩니다.

워크플로우 저장과 재사용

생성된 워크플로우는 저장해서 재사용할 수도 있습니다. 워크플로우를 한 번 실행한 뒤, 다음에도 다시 쓰고 싶다면 워크플로우 화면에서 S 키를 눌러 저장하면 됩니다.

저장하면 .claude/workflows/ 폴더 아래에 JavaScript 파일이 생성됩니다. 예를 들어 다음과 같은 형태가 되죠.

.claude/workflows/harness-legacy-scan.js
.claude/workflows/harness-diet.js

이후 Claude Code를 다시 실행하면 저장된 워크플로우를 슬래시 명령처럼 다시 쓸 수 있습니다. 저는 /harness-legacy-scan과 /harness-diet를 각각 저장해서 재사용 가능한 루틴으로 만들어 두었습니다.

추천 운영 방식

두 워크플로우를 하나로 합칠 수도 있습니다. 하지만 저는 처음부터 합치기보다 분리해서 운영하는 방식을 권합니다.

/harness-legacy-scan
→ 리포트 확인
→ 사람이 결과 검토
→ /harness-diet
→ 적용 리포트 확인
→ smoke test

이 구조가 안전한 이유는 진단과 적용 사이에 사람의 판단이 들어가기 때문입니다. 특히 Hooks, MCP, allowed tools처럼 권한과 연결된 설정은 자동으로 바꾸기보다 먼저 리포트로 보고 판단하는 편이 낫죠.

운영 주기는 한 달에 한두 번 정도면 충분합니다. 하네스는 한 번 만들고 끝나는 자산이 아니에요. 모델도 진화하고, Claude Code 자체도 진화하고, 우리 업무 방식도 바뀝니다. 제가 생각하는 좋은 하네스는 계속 쌓기만 하는 게 아니라, 주기적으로 검토되고 갱신되는 구조를 가진 하네스입니다.

실무 적용 체크리스트

Dynamic Workflows로 하네스 다이어트를 적용하려면 다음 순서로 진행해 보면 좋겠습니다.

1. 먼저 /harness-legacy-scan으로 읽기 전용 리포트를 만듭니다.
2. 리포트에서 high-risk 항목과 low-risk 항목을 분리합니다.
3. Hooks, MCP, allowed tools는 자동 수정 대상에서 제외합니다.
4. 전역 지침, 너무 긴 Skill, 넓은 description부터 정리합니다.
5. 삭제보다는 archive, 이동, 분리, 압축을 우선합니다.
6. /harness-diet 적용 후 실제 자주 쓰는 작업으로 smoke test를 합니다.
7. 결과가 안정적이면 저장된 워크플로우를 월 1-2회 반복 실행합니다.

마무리

결론부터 말하면, Claude Code Dynamic Workflows는 단순히 많은 서브 에이전트를 띄우는 기능이 아닙니다. 플랜을 JavaScript 워크플로우 스크립트가 들고 있기 때문에, 검색, 수집, 검증, 리팩토링 계획, 적대적 리뷰처럼 여러 단계가 필요한 작업을 안정적으로 반복할 수 있게 해줍니다.

이 글에서는 그 장점을 하네스 다이어트에 적용해 봤습니다. 먼저 /harness-legacy-scan으로 낡은 하네스와 중복 지시를 읽기 전용으로 찾고, 그 결과 중 low-risk 항목만 /harness-diet로 정리했죠. 실제 결과로 스킬과 reference가 재구성되고, 불필요한 본문이 줄고, 오래된 Skill이 보관 처리됐습니다.

제가 말하고 싶은 건, 앞으로 중요한 건 하네스를 더 많이 쌓는 게 아니라 이미 쌓인 하네스가 지금도 유효한지 주기적으로 확인하는 것이라는 점입니다. Dynamic Workflows를 활용하면 이 점검을 일회성 정리가 아니라 반복 가능한 운영 루틴으로 만들 수 있다고 봅니다.