Hook

대부분의 자가 진단 도구는 동일한 방식으로 점수를 매깁니다. 질문에 답하고, 가중치를 곱한 뒤, 모두 합산합니다. 총점이 높을수록 준비가 더 잘 된 것입니다.

하지만 이 모델에는 구조적인 결함이 있습니다. Git을 사용하지 않으면서 문서화, AI 정책, 프로젝트 적합성에서 만점을 받은 팀은 높은 점수를 받을 수 있습니다. 그러나 버전 관리(Version Control)가 없다면, AI가 생성한 모든 대규모 변경 사항은 되돌릴 수 없는 덮어쓰기가 됩니다. 다른 분야에서 아무리 뛰어난 성과를 내더라도 이를 보완할 수 없습니다.

이를 '우등생 문제(honor student problem)'라고 부릅니다. 가산 방식의 점수 산정(Additive scoring)은 평균치를 보상하지만, 실제로 중요한 것은 가장 약한 연결 고리이기 때문입니다. 이 글에서는 치명적인 전제 조건이 누락되었을 때 총점을 제한하는 점수 모델을 어떻게 설계했는지, 그리고 왜 전체 메커니즘이 단 하나의 Math.min()으로 수렴하는지에 대해 설명합니다.

Target Audience

다음과 같은 개발자 및 기술 리드(Tech leads):

• AI 지원 개발(AI-assisted development)을 위한 준비도/성숙도 평가를 평가(또는 구축)하고 있는 분
• 점수 산정, 순위 지정 또는 평가 로직을 설계하며 가중 평균의 실패 모드(Failure modes)에 관심이 있는 분
• 실제 오픈 소스 구현에 기반한 "작은 설계 결정이 가져오는 큰 결과"에 관한 글을 즐기는 분

Key Sections

1. 우등생 문제 (The Honor Student Problem)

• 전형적인 준비도 평가의 작동 방식: 카테고리별 가중 평균
• 실패 모드: 한 분야의 치명적인 약점이 다른 분야의 강점에 의해 희석됨
• 구체적인 예시: Git 미사용 + 나머지 모든 항목 완벽 = 가산 방식 점수 산정 하에서 높은 점수
• 이것이 AI 주도 개발에서 더 중요한 이유: AI는 변경 사항의 양을 배가시키므로, 누락된 안전장치는 평균화되어 사라지는 것이 아니라 증폭됩니다.

2. 병목 점수제 (Bottleneck Scoring): 진보를 위한 평균, 전제 조건을 위한 제한

• 가중 평균을 유지합니다 — 이는 지속적인 개선을 표현하는 데 유용합니다.
• 두 번째 레이어를 추가합니다: 부재 시 총점을 제한하는 치명적인 전제 조건(Fatal preconditions).
• 전체 메커니즘은 Math.min(baseScore, cap)으로 축소됩니다.
• 비유: 리비히의 최소량 법칙 (Liebig's law of the minimum, 길이가 짧은 판자가 하나 있는 나무통)

3. 6가지 전제 조건과 그 제한값 (The Six Preconditions and Their Caps)

• 버전 관리(Git) 없음 → 49로 제한
• 문서화된 사양(Specs) 거의 없음 → 49로 제한
• 작업/티켓 관리(Task/Ticket Management) 없음 → 59로 제한
• 인간의 검토 / 운영 승인(Production Approval) 없음 → 59로 제한
• 자동화된 테스트 및 변경 체크리스트(Change Checklist) 없음 → 59로 제한
• AI에 입력해서는 안 되는 사항에 대한 규칙 없음 → 69로 제한
• 여러 제한 사항이 동시에 발생할 경우, 가장 낮은 제한값이 적용됨 (최악의 병목 현상에 의해 속도가 제한됨)

4. 왜 49, 59, 69인가 — 레벨 상한선으로서의 제한값 (Caps as Level Ceilings)

• 100점 만점 척도, 5개 축: 문서화 (Documentation) 25 / 프로세스 (Process) 25 / 품질 보증 (Quality Assurance) 20 / AI 활용 (AI Usage) 15 / 프로젝트 적합성 (Project Fit) 15
• 5개 레벨 (Lv1: 0–29 … Lv5: 85–100)
• 제한값은 의도적으로 레벨 경계선(50, 70) 바로 아래에 위치함: 제한값은 "해당 결함을 안고 있는 상태에서 도달할 수 있는 가장 높은 레벨"을 인코딩함

5. 작동 증명: 설계 문서로서의 테스트 케이스 (Test Cases as Design Documentation)

• 모든 답변이 최대치일 경우 → 100, Lv5
• Git은 없지만 나머지는 완벽할 경우 → 49(Lv2)로 강제 조정
• 여러 제한값이 동시에 존재할 경우 → 최솟값(49)이 적용됨
• Vitest 단위 테스트(Unit Tests)를 통해 결정론적 점수 산정(동일한 입력에 동일한 출력)을 보장함

6. 동일한 원칙에서 도출된 설계 결정 사항들

• "모름"은 0이 아니라 0.2로 점수를 매김 — 모르는 것과 없는 것은 다름
• 1인 개발자: 팀 단위 질문(예: PR 리뷰 관행)은 0.5배의 가중치를 부여함
• 권장 사항은 영향도(축 점수 / 축당 질문 수 × 미충족 정도)에 따라 우선순위가 지정되며, 현재 / 1개월 / 3개월 로드맵으로 구성됨
• 강점 선택 시 축의 다양성을 강제함
• AI 적합성을 위해 평가된 8가지 개발 단계 중, 문서화는 "권장되지 않음"이 될 수 없는 유일한 단계임

7. 도구 자체에 대하여 (간략히)

• 완전한 클라이언트 사이드 정적 앱 (Fully client-side static app): TypeScript, React 19, Vite 8, Tailwind CSS 4, shadcn-ui; GitHub Pages
• 외부 전송 없음 (Zero external transmission) — 답변은 LocalStorage/IndexedDB에 저장되며, Playwright E2E 테스트를 통해 자동으로 검증됨
• 버전 관리되는 점수 산정 로직 (Scoring logic versioned, SCHEMA_VERSION); 오래된 결과에는 "구버전 (outdated version)" 배지가 표시됨
• 5개 언어 지원, MIT 라이선스, 방금 출시됨 — 자랑할 만한 사용량 수치는 없으며, 그렇지 않은 척하지도 않음

예상 길이

2,000–2,400 단어 (설계 심층 분석 / 엔지니어링 결정 기술서)

톤 노트 (Tone Notes)

• 이 글은 "하나의 설계 결정에 대해 솔직하게 검토하는" 글입니다. 주인공은 도구가 아니라 점수 모델입니다. 도구는 주로 마지막에 언급되는 구현 수단으로서 다루세요.
• 공감할 수 있는 함정으로서 '우등생 문제 (honor student problem)'를 먼저 제시하세요. 대부분의 독자는 가산 방식의 루브릭 (additive rubric)을 구축했거나 사용해 본 경험이 있습니다.
• 결함을 직관적으로 느낄 수 있도록 코드 스타일의 Before/After 다이어그램 (Git을 사용하지 않는 팀을 위한 가산 점수 vs 상한선이 있는 점수)을 사용하세요.
• 구현 방식이 거의 부끄러울 정도로 단순하다는 점(Math.min)을 솔직하게 밝히세요. 가치는 코드가 아니라 상한선 (caps)을 선택하는 데 있습니다.
• 프로젝트를 과장하지 마세요. 이것은 2026년 7월에 발행된 개인용 오픈 소스 (OSS) 도구이며 아직 실적이 없습니다. "방금 출시한 프로젝트"라는 어조가 적절합니다.
• 독자들이 자신의 팀에서 평균값에 가려져 버려지고 있는 병목 현상 (bottleneck)이 무엇인지 이름을 붙여보도록 질문을 던지며 마무리하세요.

SEO / 발견 가능성

• 주요 키워드: "AI 준비도 평가 (AI readiness assessment)", "점수 시스템 설계 (scoring system design)", "가중 평균의 문제점 (weighted average problems)"
• 보조 키워드: "성숙도 모델 점수 산정 (maturity model scoring)", "병목 점수제 (bottleneck scoring)", "자가 평가 도구 설계 (self-assessment tool design)"
• 일반화 가능한 교훈 (모든 평가 시스템에서의 상한선 vs 평균)은 이 글을 AI 분야를 넘어 공유 가능하게 만듭니다. 어떤 종류의 루브릭 설계자라도 자신에게 해당된다고 느낄 수 있도록 서두를 구성하세요.