Claude Code workflowSizeGuideline, 팀 기준으로 Dynamic workflow 규모를 정리하는 방법 | DAKER 커뮤니티
Dynamic workflow는 편리하지만, 팀 안에서 작업 규모 기준이 제각각이면 실행 범위와 검증 비용이 빠르게 불어나기 쉽습니다. 이럴 때 필요한 것이 workflowSizeGuideline입니다. 설정 파일에 팀의 기본 규모 기준을 담아 두면, 작업을 시작하기 전에 어디까지 실행할지 조금 더 예측하기 쉬워집니다.
2026년 7월 24일 공식 changelog에는 Dynamic workflow size guideline을 settings 파일에서 설정할 수 있는 workflowSizeGuideline 키와 기본 medium 기준 변경이 기록되어 있습니다. 이 글은 그 사실을 바탕으로, 기능 소개보다 팀이 바로 적용할 수 있는 운영 기준에 초점을 맞춰 정리했습니다.
workflowSizeGuideline은 Dynamic workflow의 권장 작업 규모를 설정 파일에서 고정할 수 있게 해 주는 설정 키입니다.
workflowSizeGuideline으로 무엇이 달라졌나요?
이 설정의 핵심은 Dynamic workflow가 과하게 커지기 전에 팀의 기본 규모 기준을 미리 정해 둘 수 있다는 점입니다. 사람마다 큰 작업의 기준이 다르면 같은 종류의 요청도 실행 범위가 달라지기 쉽습니다. 반면 settings 파일에 기준을 두면, 반복되는 작업에서 기본값이 일정하게 적용되어 실행 범위와 검증 비용을 가늠하는 데 도움이 됩니다.
작성 기준일 현재 공식 문서와 changelog로 확인한 내용은 있지만, 공개 본문에는 DAKER 정책에 맞는 링크만 남깁니다. 그래서 이 글도 기능 자체를 길게 설명하기보다, 팀이 실제로 어떤 확인 루틴을 가져가면 좋은지에 집중합니다.
왜 지금 팀 루틴으로 정리할 필요가 있나요?
새 기능이 추가될 때 흔히 생기는 문제는 도구 이름만 공유하고 완료 기준은 공유하지 않는다는 점입니다. workflowSizeGuideline도 마찬가지입니다. 설정 키를 안다고 해서 팀 운영이 바로 안정되지는 않습니다. 어떤 작업에서 Dynamic workflow를 켤지, 시작 전에 무엇을 적을지, 실행 뒤에는 무엇을 기록할지를 함께 정해야 기준이 살아납니다.
도구 이름보다 중요한 것은 완료 기준을 같은 문장으로 공유하는 일입니다.
특히 2026년 7월 24일 changelog에서 기본 medium 기준 변경이 함께 언급된 만큼, 팀이 기존 감각대로만 운영하면 실제 실행 규모와 기대치가 어긋날 수 있습니다. 그래서 지금 시점에는 설정값 자체보다도, 그 설정을 어떤 문맥에서 쓰는지 정리하는 것이 더 중요합니다.
팀에서 바로 쓰기 좋은 최소 운영 루틴
처음 도입하는 팀이라면 복잡한 규칙보다 최소한의 확인 기준부터 갖추는 편이 좋습니다. 아래 순서는 도구 사용법이라기보다 팀 작업의 공통 확인 기준으로 보면 됩니다.
- 먼저 팀에서 Dynamic workflow가 필요한 작업과 필요 없는 작업을 나눕니다.
- 기본 규모 기준은 small, medium, unrestricted 같은 운영 단어로 문서화합니다.
- 설정 파일에 workflowSizeGuideline을 둘 때 누가 바꿀 수 있는지 정합니다.
- 큰 작업을 시작하기 전 예상 agent 수, 파일 범위, 검증 명령을 먼저 적습니다.
- 실행 후 실제 agent 수와 검증 시간을 기록해 다음 기준 조정에 반영합니다.
이 루틴의 목적은 더 많은 자동화를 켜는 데 있지 않습니다. 작업이 끝났다고 말할 수 있는 증거를 남기고, 다음 작업에서 기준을 더 정확하게 다듬는 데 있습니다.
작업 요청은 어떻게 쓰면 좋을까요?
짧은 요청이라도 구조가 있으면 결과 보고가 훨씬 덜 흐려집니다. 가장 단순한 방식은 세 줄로 정리하는 것입니다. 먼저 목표 화면이나 산출물을 적고, 다음 줄에 확인 기준을 적습니다. 마지막 줄에는 이번 실행에서 확인하지 못한 범위를 남기면 됩니다.
목표, 확인 기준, 남은 한계만 분리해도 Claude Code 세션의 결과 보고는 훨씬 선명해집니다.
이 방식은 workflowSizeGuideline과도 잘 맞습니다. 규모 기준이 settings 파일에 있다면, 작업 요청은 그 기준 위에서 무엇을 검증할지 분명히 적는 역할을 하게 됩니다.
대화 중 즉석 선택과 settings 파일 기준의 차이
| 구분 | 대화 중 즉석 선택 | settings 파일 기준 |
|---|---|---|
| 규모 일관성 | 사람마다 큰 작업 기준이 달라집니다 | 팀 기본 규모가 반복 실행에 적용됩니다 |
| 비용 예측 | 작업이 커진 뒤에야 비용을 봅니다 | 시작 전에 예상 agent 수와 검증 범위를 둡니다 |
| 예외 관리 | 급한 작업마다 unrestricted가 늘어납니다 | 예외 이유와 종료 조건을 남깁니다 |
핵심은 즉석 판단을 완전히 없애는 것이 아니라, 기본값과 예외를 구분하는 데 있습니다. 특히 unrestricted는 편의상 자주 쓰기보다, 정말 큰 조사나 독립 검증이 필요한 경우에만 예외처럼 다루는 편이 좋습니다.
이미지 워크플로가 보여주는 운영 흐름
이미지 워크플로의 흐름도 같은 맥락입니다. 팀장은 큰 리팩터링 요청 앞에서 먼저 Dynamic workflow가 필요한지 나눕니다. 설정 파일 카드에는 workflowSizeGuideline과 기본 medium 기준이 적히고, 작업 보드에는 예상 agent 수, 파일 범위, 검증 명령이 함께 표시됩니다.
여기서 unrestricted 요청은 일반 작업과 분리된 예외 카드로 다루고, 이유와 종료 조건을 남깁니다. 마지막에는 실제 agent 수와 검증 시간을 기록해 다음 기준 조정에 반영합니다. 결국 이 흐름은 설정값 하나를 추가하는 일이 아니라, 작업 전 예측과 작업 후 기록을 연결하는 운영 방식에 가깝습니다.
팀 적용 전 확인해 볼 질문
- Dynamic workflow를 켤 작업과 단일 agent로 충분한 작업을 구분했나요?
- 팀 설정 파일의 기준이 개인 설정과 충돌하지 않나요?
- unrestricted 기준을 예외 승인처럼 다루고 있나요?
- 실행 전 예상 agent 수와 실행 후 실제 수를 비교하나요?
- 규모 기준 변경 이유를 PR이나 운영 메모에 남기나요?
이 질문들은 체크리스트이기도 하지만, 팀이 같은 기준으로 회고하고 있는지 확인하는 장치이기도 합니다. 기준이 바뀌는 것 자체는 문제가 아니지만, 왜 바뀌었는지가 남지 않으면 다음 작업에서 다시 같은 혼선이 생기기 쉽습니다.
자주 나오는 질문
workflowSizeGuideline은 Dynamic workflow를 끄는 설정인가요?
아닙니다. 끄는 설정이 아니라 권장 규모를 팀 기준으로 고정해 작업이 과하게 커지는 상황을 줄이는 운영 설정입니다.
medium 기준이면 충분한가요?
많은 팀은 medium으로 시작해도 됩니다. 다만 파일 범위가 넓거나 검증 시간이 길면 실제 agent 수와 시간을 보고 조정하는 것이 좋습니다.
unrestricted는 언제 써야 하나요?
정말 큰 조사나 독립 검증이 필요한 예외에만 쓰고, 이유와 종료 조건을 함께 남기는 편이 좋습니다.
오늘 바로 바꿔 볼 규칙이 있나요?
Dynamic workflow를 켜기 전에 예상 agent 수, 파일 범위, 검증 명령을 먼저 적는 규칙부터 시작하면 됩니다.
참고 자료
DAKER 클로드 코드 디렉터리
Dynamic workflow 작업 줄이기
워크플로 결과 JSON으로 안정화하기
백그라운드 세션 운영법
여러분의 팀에서는 Dynamic workflow 규모 기준을 어떤 방식으로 정리하고 있는지 궁금합니다.