Claude Code workflowSizeGuideline: Dynamic workflow 규모를 팀 설정으로 고정하는 법 | DAKER 커뮤니티
Claude Code workflowSizeGuideline은 Dynamic workflow가 과하게 커지기 전에 팀의 기본 규모 기준을 설정 파일로 고정해 실행 범위와 검증 비용을 예측하게 돕습니다. 2026년 7월 24일 공식 changelog에는 Dynamic workflow size guideline을 settings 파일에서 설정할 수 있는 workflowSizeGuideline 키와 기본 medium 기준 변경이 기록되어 있습니다. 당신이 오늘 확인할 곳은 DAKER 클로드 코드 디렉터리와 관련 실무 글입니다.
Claude Code workflowSizeGuideline이란, Dynamic workflow의 권장 작업 규모를 설정 파일에서 고정할 수 있게 해 주는 설정 키입니다.
Claude Code workflowSizeGuideline는 무엇이 달라졌나요?
Claude Code workflowSizeGuideline은 Dynamic workflow가 과하게 커지기 전에 팀의 기본 규모 기준을 설정 파일로 고정해 실행 범위와 검증 비용을 예측하게 돕습니다. 작성 기준일 현재 공식 문서와 changelog로 확인했지만, 공개 본문에는 DAKER 정책에 맞춰 DAKER 내부 링크만 남깁니다. 그래서 이 글은 기능 자체보다 팀이 바로 실행할 검증 루틴에 초점을 둡니다.
왜 지금 팀 루틴으로 정리해야 하나요?
2026년 7월 24일 공식 changelog에는 Dynamic workflow size guideline을 settings 파일에서 설정할 수 있는 workflowSizeGuideline 키와 기본 medium 기준 변경이 기록되어 있습니다. 새 기능을 도입할 때 가장 흔한 실수는 도구 이름만 공유하고 완료 기준을 공유하지 않는 것입니다. 오늘은 확인할 화면, 산출물, 로그, 한계를 같은 문장으로 묶어야 합니다.
단계별 사용법은 어떻게 잡으면 좋을까요?
아래 순서는 처음 도입하는 팀이 바로 실행할 수 있는 최소 루틴입니다. 각 단계는 도구 설명이 아니라 팀 작업의 확인 기준으로 쓰는 편이 좋습니다.
- 먼저 팀에서 Dynamic workflow가 필요한 작업과 필요 없는 작업을 나눕니다.
- 기본 규모 기준은 small, medium, unrestricted 같은 운영 단어로 문서화합니다.
- 설정 파일에 workflowSizeGuideline을 둘 때 누가 바꿀 수 있는지 정합니다.
- 큰 작업을 시작하기 전 예상 agent 수, 파일 범위, 검증 명령을 먼저 적습니다.
- 실행 후 실제 agent 수와 검증 시간을 기록해 다음 기준 조정에 반영합니다.
짧은 예시는 어떻게 쓰면 되나요?
작업 요청에는 먼저 목표 화면이나 산출물을 쓰고, 다음 줄에 확인 기준을 적습니다. 마지막 줄에는 확인하지 못한 범위를 남깁니다. 이 세 줄만 있어도 Claude Code 세션의 결과 보고가 훨씬 덜 흐려집니다.
| 구분 | 대화 중 즉석 선택 | settings 파일 기준 |
|---|---|---|
| 규모 일관성 | 사람마다 큰 작업 기준이 달라집니다 | 팀 기본 규모가 반복 실행에 적용됩니다 |
| 비용 예측 | 작업이 커진 뒤에야 비용을 봅니다 | 시작 전에 예상 agent 수와 검증 범위를 둡니다 |
| 예외 관리 | 급한 작업마다 unrestricted가 늘어납니다 | 예외 이유와 종료 조건을 남깁니다 |
이미지 워크플로는 무엇을 보여주나요?
팀장이 큰 리팩터링 요청 앞에서 Dynamic workflow가 필요한지 먼저 나눕니다. 설정 파일 카드에는 workflowSizeGuideline과 기본 medium 기준이 적힙니다. 작업 보드에는 예상 agent 수, 파일 범위, 검증 명령이 함께 표시됩니다.
- 팀장이 큰 리팩터링 요청 앞에서 Dynamic workflow가 필요한지 먼저 나눕니다.
- 설정 파일 카드에는 workflowSizeGuideline과 기본 medium 기준이 적힙니다.
- 작업 보드에는 예상 agent 수, 파일 범위, 검증 명령이 함께 표시됩니다.
- unrestricted 요청은 예외 카드로 분리되어 이유와 종료 조건을 적습니다.
- 마지막 컷에서 팀은 실제 agent 수와 검증 시간을 다음 기준에 반영합니다.
팀 적용 체크리스트는 무엇인가요?
체크리스트의 목적은 더 많은 자동화를 켜는 것이 아니라, 작업이 끝났다고 말할 수 있는 증거를 남기는 것입니다.
- Dynamic workflow를 켤 작업과 단일 agent로 충분한 작업을 구분했나요?
- 팀 설정 파일의 기준이 개인 설정과 충돌하지 않나요?
- unrestricted 기준을 예외 승인처럼 다루고 있나요?
- 실행 전 예상 agent 수와 실행 후 실제 수를 비교하나요?
- 규모 기준 변경 이유를 PR이나 운영 메모에 남기나요?
공식 출처와 내부 링크는 어디에서 확인하나요?
작성 기준일 현재 기능 사실은 공식 공개 문서로 비공개 검증했고, 공개 본문에는 DAKER 정책에 맞는 내부 링크만 남깁니다. 이어서 볼 글은 아래 DAKER 글입니다.
FAQ: 실무자가 자주 묻는 질문은 무엇인가요?
workflowSizeGuideline은 Dynamic workflow를 끄는 설정인가요?
아닙니다. 끄는 설정이 아니라 권장 규모를 팀 기준으로 고정해 작업이 과하게 커지는 상황을 줄이는 운영 설정입니다.
medium 기준이면 충분한가요?
많은 팀은 medium으로 시작해도 됩니다. 다만 파일 범위가 넓거나 검증 시간이 길면 실제 agent 수와 시간을 보고 조정해야 합니다.
unrestricted는 언제 써야 하나요?
정말 큰 조사나 독립 검증이 필요한 예외에만 쓰고, 이유와 종료 조건을 함께 남기는 편이 좋습니다.
오늘 바로 바꿀 규칙은 무엇인가요?
Dynamic workflow를 켜기 전에 예상 agent 수, 파일 범위, 검증 명령을 먼저 적는 규칙부터 적용해 보세요.
오늘은 팀의 Claude Code 작업 요청 한 개를 골라, 목표, 확인 기준, 남은 한계를 세 줄로 다시 써 보세요.