서론

'성숙도 진단'이라고 하면 많은 사람이 떠올리는 채점 방법은 아마 다음과 같을 것이다. 체크 항목마다 점수를 매기고, 가중치를 두어 합산한 뒤, 총점으로 레벨을 판정하는 방식이다. 세상의 자기 진단 도구 대부분은 이러한 **가점 방식 (加点式, 가중 평균)**으로 설계되어 있으며, 직관적으로도 공정해 보인다.

하지만 'AI 주도 개발 (AI-Driven Development)에 얼마나 적합한 조직인가'를 측정하는 맥락에서 이 방식을 그대로 사용하면, 'Git조차 사용하지 않는데 종합 70점'이라는 진단 결과가 태연하게 발생해 버린다. 문서화가 완벽하고, 티켓 관리가 잘 이루어지며, AI 이용 가이드라인도 정비되어 있지만——버전 관리(Version Control)가 없는 경우다. 이 팀에 AI 에이전트(AI Agent)를 통해 대량의 코드 변경을 흘려 넣었을 때 어떤 일이 벌어질지는 상상하기 어렵지 않다.

본고에서는 '왜 가점식 평가만으로는 AI 주도 개발의 적합성을 측정할 수 없는가', '그 대책으로서 **병목 방식 (Bottleneck Method, 캡/상한)**이라는 채점 설계는 어떻게 만드는가'를 정리한다. 소재로는 필자가 최근 공개한 자작 OSS 진단 도구인 'AI 주도 개발 도입 진단 (ai-dev-readiness)'의 채점 로직을 구현 예시로 사용하지만, 주인공은 도구가 아니라 평가 설계의 사고방식이다. 어디까지나 필자의 실무 경험과 자작 도구의 설계 과정에 기반한 고찰이며, 확립된 평가 이론의 소개가 아니라는 점을 미리 밝혀둔다.

5줄 요약 (클릭하여 확장)

TL;DR (5줄 요약)

• 가점 방식 (가중 평균)의 성숙도 평가에는, '특정 분야가 괴멸적으로 약하지만 다른 분야는 우수한' 팀을 과대평가해 버리는 구조적인 허점이 있다.
• AI 주도 개발에는 '결여되면 다른 강점이 기능하지 않는' 전제 조건 (버전 관리, 인간 리뷰, 사양의 형식지화, 테스트, AI 입력 규칙)이 존재한다.
• 대책은 단순하다. Math.min(원점수, 상한)
  ——치명적인 결락을 검출하면 종합 스코어에 **상한 (Cap)**을 걸기만 하면 된다.
• 캡(Cap)은 가중 평균의 대체재가 아니라 병용 대상이다. 일반적인 개선도는 가점 방식으로 연속적으로 표현하고, 치명적인 결락만을 상한으로 표현하는 이층 구조로 만든다.
• 필자는 이 설계를 자작 진단 도구인 ai-dev-readiness에 구현했다 (6종의 캡, 결정론적 채점, 경계값을 포함한 유닛 테스트로 검증).

1. 가점식 평가의 구조적인 함정——'우등생 문제'

먼저, 가점식의 무엇이 문제가 될 수 있는지 구체적으로 살펴보자.

가상의 두 팀을 흔히 있는 5개 영역의 가중 평균 (각 20점 만점, 총 100점)으로 채점했다고 가정하자.

가점식에서는 테스트가 전혀 존재하지 않는 팀 A가 '80점 = 우량', 모든 영역이 적당한 팀 B가 '60점 = 개선 여지 있음'으로 판정된다. 하지만 AI 주도 개발의 실무 감각으로는 이 서열이 역전될 수 있다. AI가 생성한 변경 사항을 검증할 수단을 갖지 못한 팀 A는, AI의 출력 속도가 빨라질수록 리스크가 가속화되기 때문이다.

이것은 필자가 '우등생 문제'라고 부르는 현상으로, 일반화하면 다음과 같다.

❌ 가점식의 암묵적 전제: 각 영역의 점수는 서로 독립적이며, 부족한 영역은 다른 영역의 강점으로 '보완'할 수 있다.

✅ AI 주도 개발의 실태: 일부 영역은 다른 영역의 전제 조건이 되어 있으며, 결여되면 다른 영역의 점수 자체가 의미를 잃는다.

가중 평균은 '보완 가능한 세계'의 모델이다. 가중치를 조정해도 본질은 변하지 않는다. 품질 보증(Quality Assurance)의 가중치를 2배로 높인다 해도, 다른 항목이 만점이라면 팀 A는 여전히 고득점이 된다. '중요도의 차이'는 가중치로 표현할 수 있지만, '전제 조건이라는 사실'은 가중치로 표현할 수 없다. 이것이 가점식의 구조적인 한계라고 필자는 생각한다.

2. AI 주도 개발의 '전제 조건'은 왜 보완 불가능한가

그렇다면 AI 주도 개발에서 '결여되면 전체가 성립하지 않는' 조건이란 구체적으로 무엇인가. 필자가 도구의 채점 설계에 있어 전제 조건 (= 캡 발동 조건)으로 선택한 것은 다음의 관점이다.

공통점은, 이것들이 **"AI를 빠르게 만드는 요소"가 아니라 "AI의 속도를 안전하게 받아내는 요소"**라는 점이다. 가점 방식의 세계관에서는 "테스트가 없는 만큼 문서로 보완하면 된다"라는 거래가 성립해 버리지만, 실제로는 문서가 아무리 충실해도 테스트 부재의 리스크는 1밀리미터도 줄어들지 않는다. 보완이 통하지 않는 항목은 가산이 아니라 제약으로 다룰 필요가 있다——이것이 병목(bottleneck) 방식의 출발점이다.

Math.min

이라는 소박하고 강력한 연산

3. 병목 방식의 구현——설계 이야기가 이어졌으니, 구현으로 넘어가겠다. 결론부터 말하자면, 병목 방식의 핵심은 허탈할 정도로 단순하며, 원점수와 캡(cap) 값의 Math.min을 취하는 것뿐이다.

필자의 도구에서는 다음 6종류의 캡을 정의하고 있다.

실제 구현을 간략화하면 다음과 같은 형태가 된다 (설명을 위해 타입이나 조건 판정을 생략한 의사 코드(pseudo code)이며, 그대로 동작하는 것은 아니다).

// 실제 구현을 간략화한 설명용 코드
type CapRule = {
  id: string; // 예: "no_git"
...

설계상의 포인트는 세 가지가 있다.

① 복수 해당 시 최소값을 취한다. 병목이 두 개 있을 때, 전체를 제약하는 것은 '더 심각한 쪽'이다. 실제로 유닛 테스트에서는 "Git 미사용(상한 49점)과 티켓 관리 없음(상한 59점)이 동시에 해당할 경우, 종합 스코어는 49점이 된다"는 것을 검증했다. 상한을 평균 내거나 합산하여 감점하지 않는다——**"통의 수위는 가장 낮은 판자에 의해 결정된다"**는 원리이며, 낮은 판자가 두 장 있다고 해서 수위가 가장 낮은 판자 한 장분보다 높아지지는 않는다.

② 발동한 캡의 ID를 결과에 포함한다. 진단을 받은 측에게 중요한 것은 "왜 점수가 상한에 걸렸는가"이다. 캡 ID를 결과에 남김으로써, "귀하의 종합 스코어는 Git 미사용으로 인해 49점으로 제한되었습니다. 우선 이 부분부터 해결하십시오"라는 개선 순서의 제시로 직결시킬 수 있다.

③ 캡은 감점이 아니라 상한으로 설정한다. "Git 미사용 시 일괄 50점 감점"과 같은 감점 방식도 생각할 수 있지만, 그렇게 하면 원래 점수에 따라 영향도가 달라져 버린다 (원점수 60점인 팀과 95점인 팀 사이에서 "Git 미사용의 심각성"이 달라지는 것은 부자연스럽다). 상한 방식이라면 **"다른 요소가 아무리 뛰어나도, 이 상태에서는 49점이 천장이다"**라는 메시지가 점수 그 자체에 새겨진다.

이 로직의 효과는 테스트 케이스의 실례를 보면 이해하기 쉽다.

"나머지가 모두 만점"이어도 49점이다. 가점 방식이라면 틀림없이 고득점이 될 케이스가 레벨 2(후술)에 머물게 된다. 이 동작이야말로 병목 방식의 존재 의의다.

4. 캡만으로는 진단이 되지 않는다——가중 평균과의 이층 구조

여기까지 읽으면 "그럼 전부 캡(Cap)으로만 판정하면 되는 것 아닌가"라고 생각할 수도 있지만, 그것도 극단적이다. 캡은 불연속적인 규칙 (Discontinuous Rule) 이기 때문에, 캡만으로 구성하면 "조건을 충족하는가 충족하지 않는가"의 계단식 평가가 되어, 매일의 개선이 점수에 반영되지 않는 진단이 되어버린다.

❌ 캡만 사용 시: 개선해도 점수가 움직이지 않는 "커트라인 리스트 (Cut-off list)"가 된다.

❌ 가중 평균만 사용 시: 치명적인 결함이 묻혀버리는 "우등생 문제"가 발생한다.

✅ 가중 평균 + 캡의 이층 구조: 연속적인 개선도를 원점(Raw score)으로 표현하고, 치명적인 결함만을 상한선(Cap)으로 표현한다.

필자의 툴에서는 원점(rawScore) 측은 솔직한 가중 평균으로 설계되어 있다. 5개 축의 배점은 다음과 같다.

전체 34문항(간이 진단은 12문항, 표준 진단은 26문항 사용)의 각 설문에는 4지 선다형 답변 계수를 할당한다.

축 점수는 Σ(가중치 × 계수) / Σ(가중치) × 축 배점의 가중 평균이며, 5개 축의 합계가 원점이 된다. 이 위에 전절의 캡이 얹어지는 이층 구조다.

세부적으로 몇 가지 판단이 망설여졌던 점이 있어, 설계 의도와 함께 공유하고자 한다.

"모른다"를 0점으로 처리하지 않는다. "실시하지 않음(0)"과 "모름(0.2)"을 구분하는 이유는, "파악하지 못하고 있는 것"과 "존재하지 않는 것"은 다르기 때문이다. 다만 1.0이나 0.6에는 훨씬 못 미치는 낮은 계수로 설정했다. 자신의 팀 상태를 파악하지 못하고 있다는 사실 자체가 AI 도입 판단의 장애물이라고 생각하기 때문이다 (이 계수 설정이 최적인지는 솔직히 아직 확신이 없다).

개인 개발에서는 팀 전제 설문의 가중치를 절반으로 줄인다. PR 리뷰 운용이나 티켓 관리와 같은 설문은 팀 개발을 전제로 한 항목이다. 개인 개발자가 이러한 항목들로 인해 일률적으로 감점되는 것은 진단으로서 불공평하므로, 팀 전제 플래그가 붙은 설문은 개인 개발의 경우 가중치를 0.5배로 하는 보정을 넣었다. 0으로 만들지 않는 것(설문 자체를 삭제하지 않는 것)은, 개인 개발에서도 변경 이력이나 태스크 정리(Task organization)는 AI 활용의 토대가 된다는 판단 때문이다.

5. 점수를 "다음 행동"으로 변환하기

점수를 내고 끝난다면 진단 툴로서 미완성이다. 점수 설계만큼이나, 점수를 행동으로 변환하는 층 (Layer) 에 설계 판단이 집약되어 있으므로 그 부분도 소개하고 싶다.

레벨 판정과 "할 수 있는 일 리스트"

종합 점수는 5단계 레벨로 변환된다.

여기서 캡 값(49, 59, 69)이 레벨 경계(50, 70)의 바로 아래에 배치되어 있다는 점을 눈치챈 사람도 있을 것이다. Git을 사용하지 않는다면 아무리 노력해도 Lv2에 머물고, 리뷰어가 없다면 Lv3에 머문다 —— 캡 값은 레벨 정의와 연동되어 "그 결함을 가진 채로 도달할 수 있는 상한 레벨"을 표현하고 있다. 참고로 경계값 처리(29점은 Lv1, 30점은 Lv2, 49점은 Lv2, 50점은 Lv3...)는 실수가 발생하기 쉬우므로, 유닛 테스트(Unit test)를 통해 모든 경계값을 명시적으로 검증하고 있다.

권장 액션의 우선순위 지정

미달성(계수가 1 미만) 설문을 "개선 후보"로 추출하여, 다음의 영향도에 따라 나열한다.

// 실제 구현을 간략화한 설명용 코드
// "해당 설문을 만점으로 만들었을 때 종합 점수가 몇 점만큼 개선되는가"의 근사치
const impact = (axisPoints / questionsInAxis) * (1 - coefficient);

이를 우선순위(high / medium / low의 고정 카탈로그 값) → impact 내림차순으로 정렬하여, "즉시 / 1개월 이내 / 3개월 이내"의 3단계 로드맵으로 정리한다. 캡 발동 조건과 관련된 항목은 당연히 "즉시"로 떠오른다. 전술한 테스트 케이스와 같이, Git을 사용하지 않는 팀에게는 "즉시 실시"의 최우선 항목으로 Git 이행이 제시된다.

강점 선정에도 "편향 방지"를 넣는다

과제뿐만 아니라 강점도 최대 3가지를 제시하지만, 여기에도 작은 설계 판단이 있다. 계수 1.0(없으면 0.6 이상)의 설문에서 배점이 큰 순서대로 고를 때, 같은 축에서 여러 개를 선택하지 않도록 하고 있다. 단순히 상위 3개를 선택하면 배점이 큰 축(문서 25점)에 강점이 집중되어 '강점이 실질적으로 하나의 영역밖에 없다'는 결과가 나오기 쉽기 때문이다.

예외 규칙은 '예외임'을 명시할 수 있는 형태로 보유한다

또 하나, 8가지 개발 공정(요구사항 정리~운영) 각각에 대해 AI 적성을 3단계(recommended / conditional / not_recommended)로 판별하는 기능이 있는데, '문서 작성' 공정만은 not_recommended가 되지 않는다는 특별 규칙을 넣었다. 아무리 정비가 늦어진 조직이라도 문서 작성 보조는 AI 활용의 진입점으로서 기능을 할 수 있다는 판단이다. 이러한 종류의 예외는 조건 분기 깊숙한 곳에 숨기면 유지보수가 불가능해지므로, 질문 정의 및 판별 조건을 데이터로 표현하고(데이터 구동), diagnose()

본체는 각 로직을 합성하는 것만 하는 얇은 계층으로 구성하고 있다.

6. 구현 예시로서의 ai-dev-readiness—채점 로직을 '검증 가능'하게 유지하기

마지막으로, 이러한 설계들을 구현한 툴 본체에 대해 언급하겠다. 서두에서 말했듯이 이 글의 주인공은 평가 설계의 사고방식이지만, **'채점 로직의 설계 사상은 그것을 검증 가능한 구현이 있어야 비로소 신뢰할 수 있다'**고 생각하기 때문에 그 부분에 초점을 맞춰 소개한다.

① 결정론적인 스코어링. 같은 입력에 대해서는 항상 같은 출력을 반환하도록 설계하여, diagnose(input) === diagnose(input)
이 성립함을 테스트로 보장하고 있다. 진단 툴에서 결과가 흔들리면, 캡 발동 설명도 로드맵도 신뢰할 수 없게 되기 때문이다. 도메인 로직(domain/assessment/)은 프레임워크 비의존적으로 분리되어 있으며, 캡 발동 조건・레벨 경계값・비용 보정 분기를 유닛 테스트로 포괄적으로 검증하고 있다.

② 답변 데이터를 외부 전송하지 않는다. 이 진단은 '리뷰를 하고 있는지', '사양이 존재하는지'와 같은 조직의 개발 프로세스 내부 사정을 입력시키는 툴이다. 민감한 정보이므로, 답변 및 결과는 일절 서버에 전송하지 않고 브라우저 내 스토리지로만 완결시키고 있다. 그리고 '외부 전송 제로'를 구두 약속으로 하지 않고, Playwright의 E2E 테스트로 실제 네트워크 요청을 감시하여 자동 검증하고 있다.

③ 채점 로직의 버전 관리. 질문이나 채점식은 앞으로도 조정할 것이므로, SCHEMA_VERSION / QUESTION_VERSION / SCORING_VERSION을 부여하고, 로직 변경 후 과거 기록 결과를 보면 '이전 버전' 배지가 붙는 구조로 만들었다. 채점 기준이 바뀌었는데 스코어만 비교되는 사고를 막기 위해서다.

참고로, 공개한 지 얼마 안 된 개인 개발 툴이라 이용 실적을 자랑할 단계는 아니다. 캡 발동 조건이나 상한값(49/59/69)의 타당성도 현시점에서는 필자의 실무 경험에 기반한 가설에 불과하다. 진단을 사용해 보고 '이 조건은 치명적이라고 할 수 없다', '이 상한은 너무 엄격하다'와 같은 이견이 있다면, 오히려 그것이야말로 본문의 논의를 이어가고 싶은 부분이다.

요약

가점식 성숙도 평가가 널리 사용되는 것은, '각 항목의 달성도는 서로 독립적이며 합산 가능하다'는 전제가 많은 경우에서 어느 정도 성립하기 때문이다. 그러나 AI 구동 개발의 적성 평가에서는 이 전제가 무너진다. 버전 관리・인간 리뷰・사양의 형식지화・테스트와 같은 항목은 '가점 요소'가 아니라 '전제 조건'이며, 이것이 없으면 다른 항목 점수가 의미를 잃는다.

평가 설계에서는 '얼마나 되어 있는가(가산으로 표현)'와 '성립 조건을 충족하고 있는가(상한으로 표현)'를 별도의 레이어로 설계할 필요가 있다.

구현 자체는 Math.min(기본 점수, 상한)

이는 Math.min(기본 점수, 상한)이라는 한 줄로 요약될 수 있을 만큼 단순하다. 어려운 것은 구현이 아니라, "무엇을 전제 조건으로 간주할 것인가", "그 상태에서 도달할 수 있는 상한을 어디에 설정할 것인가"라는 판단이며, 바로 그 지점에 평가 도구의 설계 사상(Design Philosophy)이 드러난다. 본고에서 제시한 6가지 캡(Cap)과 상한값은 필자의 가설이지만, "가중 평균에 상한 레이어를 겹치는" 구조 자체는 AI 주도 개발(AI-driven development)에 국한되지 않고, 보완 불가능한 전제 조건을 포함하는 모든 자기 진단(Self-diagnosis) 설계에 응용할 수 있는 사고방식이라고 생각한다.

참고

• ai-dev-readiness (GitHub 리포지토리) — 본고에서 소개한 채점 로직의 구현체 (MIT 라이선스)
• AI 주도 개발 도입 진단 (데모 사이트) — GitHub Pages에서 동작. 로그인 불필요 · 답변은 외부로 전송되지 않음
• Vitest — 채점 로직의 단위 테스트(Unit Test)에 사용
• Playwright — "외부 전송 제로"의 E2E 검증에 사용

Discussion