07 — M2 STALL

M2 정체의 의미 — scope 경계 결정은 그 자체로 난제

추상적인 얘기가 아니라는 증거가 있다. 내 개인 시스템의 개선 로드맵은 M0부터 M7까지 8개 마일스톤 — 공사로 치면 8단계 일정표 — 로 짜여 있다. 앞의 두 단계는 예정대로 끝났다. 그런데 세 번째인 M2에서 3주를 멈췄다.

• M0 ✓ Baseline Freeze 현재 상태 동결
• M1 ✓ Runtime Drift Sync 설치본·원본 맞추기
• M2 ⚠ 3주 정체 Hook Scope Classifier 검사 적용범위 분류
• M3 Project Installer 프로젝트별 설치기
• M4 Staged Migration 점진 이사
• M5 Self-Evolve Alignment 자가개선 정렬
• M6 Scorecard Split 성적표 분리
• M7 Operationalization 운영 체계화

7.2 M2가 어려운 이유

M2의 질문은 단순하다. 이 자동 검사는 모든 프로젝트용인가, 특정 프로젝트용인가. 회사로 치면 이 규칙이 전사 규정인가 팀 내규인가다. 그런데 한 명짜리 회사에서도 판단이 안 선다.

qa-gate-before-push — 모든 프로젝트에 필요한가? Flutter 프로젝트도? 문서 전용 저장소도? no-localstorage — 웹에서만 의미가 있다. 백엔드 전용 프로젝트에서는 헛검사다. portless-required — 개발 서버가 있는 프로젝트에서만 말이 된다. 라이브러리 프로젝트에서는 무의미하다.

7.3 조직으로 확장하면

규칙 하나마다 적용 범위를 정해야 한다 — 범위 종류가 늘수록 분류 난이도는 지수적으로 커진다

1명 × 1대에서는 개인 범위냐 프로젝트 범위냐의 경계 하나로 M2가 멈췄다. N명 × M대가 되면 개인, 프로젝트, 팀, 회사 네 범위가 겹친다. 범위가 늘수록 이 규칙은 어디 소속인가라는 분류 차원도 같이 는다. 규칙이 50개고 범위가 4종이면, 그 분류 작업만으로 위원회 하나가 필요하다.