workspace-manager/.workspace-ops/shared/speed-evaluation.md

Speed Evaluation

목적

일간/주간 작업 평가에서 속도를 별도 축으로 평가한다. 커밋 수 자체가 아니라, AI 지원이 없었다면 일반 개발자와 시니어 개발자가 같은 범위를 처리하는 데 어느 정도 걸렸을지와 비교한다.

기본 원칙

• 속도 평가는 생산성 단정이 아니라 관측 가능한 git 기록 기반의 추정치다.
• sync 커밋은 그 자체를 평가 항목으로 삼지 않고, sync로 반영된 실제 내용을 확인해 표준화/하네싱, AI 작업 가능성, 정렬/기획, 검증 등의 축에 반영한다.
• agent-ops, 표준화/하네싱, 문서/roadmap 정리, 제품 코드 구현, 테스트/검증을 변경 내용 기준으로 분리한다.
• 미커밋 변경은 작업 중인 유효 payload로 보고 커밋된 변경과 함께 속도/품질 평가에 반영한다.
• 미커밋 상태 자체를 위험, 누락, 감점 사유로 언급하지 않는다.
• 자동화된 반영 자체가 아니라 반영된 공통 규칙, 진입 파일, 스크립트, 출력 형식, ignore 정책의 의미를 평가한다.
• AI-first 개발에서 agent가 안전하게 작업할 수 있는 하네싱을 빠르게 구축하는 것은 제품 구현 이전의 보조 작업이 아니라 속도 기반 자체를 만드는 작업이다.
• 배율은 넓은 범위로 제시하고, 근거가 약하면 신뢰도를 낮음으로 둔다.
• archive 디렉터리는 사용자가 명시적으로 요청하지 않으면 읽지 않는다.

속도 축

축	의미	주요 근거
속도 종합평가	전체 작업 흐름이 AI 미사용 대비 얼마나 빠르게 진행됐는지의 최종 평가	전체 커밋/working payload 범위, repo 확산도, 실질 변경 비율, 검증 근거
표준화/하네싱 속도	여러 repo에 공통 실행 레일, 규칙, 진입 파일, 절차 체계를 깐 속도	agent-ops, rules, entry files, version, reflected file set
AI 작업 가능성 구축 속도	agent가 암묵지 없이 작업할 수 있도록 탐색/라우팅/출력/제외 기준을 명시한 속도	skills, target discovery, output format, entry files, ignore policy
제품 진척 속도	실제 제품 코드, 테스트, 사용자 기능이 전진한 속도	코드 변경 파일, 테스트 변경, 실행 검증
정렬 속도	roadmap, milestone, README, 책임 경계가 정리된 속도	roadmap/current, 활성 milestone, 문서 변경
검증 속도	변경 후 테스트나 상태 확인이 붙은 정도	test 파일, CI 로그, 로컬 검증 기록

속도 종합평가는 작업 속도 표의 첫 행에 반드시 포함한다. 첫 행의 판단 칸에는 속도 등급, 10점 만점 점수, 보정 이유를 한 문장으로 쓴다. 세부 축이 빠르면 그 속도 가치를 인정한다. 검증 근거가 부족하면 검증 위험만 종합평가에 보정한다. 제품 구현이 적다는 이유만으로 표준화/하네싱 중심 작업의 속도나 품질을 낮게 평가하지 않는다.

AI 미사용 대비 추정 기준

아래 표는 기본 휴리스틱이다. 실제 분석에서는 변경 난이도, repo 수, 테스트 유무, 반복 작업 자동화 여부를 반영해 조정한다.

작업 유형	일반 개발자 AI 미사용 기준	시니어 개발자 AI 미사용 기준	AI 사용 시 빠름 판정 예시
단일 repo README/문서 갱신	0.5-1.5시간	0.25-1시간	2-4배
roadmap/milestone 재정리	1-3시간	0.5-2시간	2-5배
cross-repo 책임 경계/계획 정렬	3-8시간	1.5-4시간	2-6배
cross-repo 표준화/하네싱 구축	4-12시간	2-6시간	3-8배
공통 agent-ops 규칙 반영 1개 repo	0.5-1시간	0.25-0.5시간	3-8배
5개 이상 repo 공통 정책 반영	4-8시간	2-4시간	4-10배
제품 코드 구현 + 테스트	변경 범위별 별도 산정	변경 범위별 별도 산정	diff와 검증 근거 없으면 판정 보류

sync 해석 원칙

• sync: 커밋은 별도 점수 항목으로 쓰지 않는다.
• sync: 커밋의 변경 파일, 원천 버전, 원천 커밋 내용을 확인해 어떤 품질 축에 기여했는지 분류한다.
• 평가 문구에서 sync only로 끝내지 말고, rules/entry files/ignore 정책/output format/version처럼 반영 내용을 쓴다.
• 내용이 단순 version bump이면 version alignment 또는 auditability 근거로만 사용한다.

sync payload 분류

payload	반영할 평가 축
rules, entry files, skill routing, target discovery, ignore policy, output format	AI 작업 가능성, 표준화/하네싱
scripts, sync procedure, install/init tooling	표준화/하네싱, 실행 가능성
roadmap/current/milestone/README/GUIDE	정렬/기획, 실행 가능성
version-only bump	검증/감사 가능성, 일관성/드리프트 방지
product code/test	제품 진척, 구현/제품 품질, 검증

출력 표

분석 결과에는 다음 표를 포함한다.

속도 항목	관측 근거	일반 개발자 AI 미사용 대비	시니어 AI 미사용 대비	판단
속도 종합평가	<전체 범위와 시간대>	<예: 4-8배>	<예: 2-4배>	<예: 빠름, 8/10. 표준화/하네싱 전파가 빠르고 검증 위험만 보정>
표준화/하네싱	<근거>	<예: 4-8배>	<예: 2-4배>	<평가>
AI 작업 가능성	<근거>	<예: 4-8배>	<예: 2-4배>	<평가>
제품 진척	<근거>	<예: 판정 보류>	<예: 판정 보류>	<평가>
정렬/기획	<근거>	<예: 2-4배>	<예: 1.5-3배>	<평가>

필요하면 신뢰도: 높음/중간/낮음을 한 문장으로 덧붙인다.