서론

'진단의 종합 점수가 높으면, 어떤 공정부터 AI를 도입해도 괜찮다.' 많은 사람들은 준비도 진단 결과를 그렇게 해석하고 싶어 한다. 종합 점수는 그런 식으로 사용하기 위한 숫자여야 한다.

하지만 필자가 공개한 OSS 진단 도구 'AI 기반 개발 도입 진단(ai-dev-readiness)'에서는 이런 일이 발생한다. 표준 진단 26문항 중 25개에 최고 평가를 주고, '실제 반영 전 사람의 승인이 있습니까?'만 '일부 실시하고 있다'고 답하면, 종합 점수는 **98점・레벨 5(AI 에이전트 활용에 적합)**가 된다. 그럼에도 불구하고 결과 화면의 '공정별 AI 적성'을 보면, '릴리스' 공정만은 '조건을 갖춘 후에 활용'으로 분류된다 (판정식에서 손으로 계산한 예시. 도출 과정은 본문에서 제시함). 종합 점수는 최고 평가대임에도 불구하고 특정 공정에는 제동이 걸린다—이는 버그가 아니라 의도된 설계다.

본고는 '공정별로 독립적인 게이트 조건'이라는 세 번째 채점 메커니즘을 해부한다. 왜 종합 점수와 상한선(cap)과는 별도의 시스템이 필요한지. 그리고 **'왜 이 문항이, 이 공정의 AI 적성을 좌우하는가'**를 8개 공정 각각의 판정식을 기반으로 설명한다. 기준치나 조건 설정은 필자의 실무 경험과 설계 과정에 근거한 가설이며, 확립된 평가 이론은 아니다.

5줄 요약 (클릭하여 전개)

TL;DR (5줄 요약)

• 종합 점수(가중 평균 + 상한선)는 '조직 전체적으로 얼마나 준비되었는지'에는 답하지만, '어떤 공정부터 시작해야 하는지'에는 답할 수 없다—고득점이라도 특정 공정의 전제가 부족할 수 있다 (본고에서는 이를 '종합 점수의 사각지대 문제'라고 부른다).
• 따라서 8가지 개발 공정별로 독립적인 게이트 조건을 설정하여 recommended/conditional/not_recommended라는 최대 3단계로 판정한다.
  세 번째 채점 메커니즘을 구현했다.
• 판정식에는 3가지 유형이 있다—축의 비율로 '면'을 보는 유형(요건 정리・구현), 문항군 평균으로 보는 유형(설계・코드 리뷰・운영), 한 문항이 관문이 되는 유형(테스트・릴리스).
• 가장 까다로운 관문은 릴리스 공정에서, '실제 반영 전 사람의 승인' 계수가 **엄격하게 1.0(＝충분히 실시하고 있음)**이어야만 절대로 recommended가 될 수 있다. '일부 실시'로는 다른 모든 문항이 만점이라도 조건부로 머무른다.
• 판정식이 참조하지만 출제되지 않은 문항의 존재나, 테스트가 부실한 부분까지 솔직하게 공개한다 (본고의 수치 예시 중 다수는 테스트 케이스가 아닌, 식으로부터 손으로 계산된 것이다.)

1. 종합 점수의 사각지대

이 도구의 종합 점수는 **가중 평균(원점수) + 상한선(cap)**이라는 이층 구조다. 가산식의 '우등생 문제'—치명적인 결함을 다른 고득점으로 가려버리는 문제—를 상한선으로 막는 것이 전편의 주제였다.

하지만 이 이층 구조는 둘 다 '조직 전체적으로 어떠한가'라는 질문에 대한 답이다. 진단을 받은 사람이 다음에 알고 싶은 것은 대부분 또 다른 질문이다—'그럼, 어떤 공정부터 AI를 사용하기 시작해야 하는가'.

서두의 예시를 좀 더 자세히 살펴보자. 표준 진단 26문항 중 25개에 최고 평가를 주고, '실제 반영 전 사람의 승인이 있습니까?(Q25)'만 '일부 실시하고 있다(계수 0.6)'었던 팀을 가정해 본다 (팀 규모는 2~5명으로 한다).

상한선은 발동하지 않는다. 전편에서 소개된 6가지 상한선 중 Q25와 관련된 것은 '사람의 리뷰/실제 반영 승인이 없음'(최대 59점)이지만, 이 발동 조건은 답변이 '미실시'일 경우이며, '일부 실시'에서는 발동하지 않는다.

• 원점수는 거의 만점이다. 품질 보증 축(20점) 내에서 Q25의 계수가 0.6이 되는 것뿐이므로, 축 점수는 18.4점이다. 종합은 98.4점, 반올림하여 98점・레벨 5가 된다.
• 그럼에도 불구하고 릴리스 공정은 conditional이다. 후술하겠지만, 릴리스의 recommended 조건은 Q25의 계수가 엄격하게 1.0임을 요구하기 때문이다.

즉, 종합 점수는 모든 문항을 하나의 숫자에 녹여낸 집계값이기 때문에, '특정 공정의 전제가 딱 하나 빠져있다'는 것을 읽어낼 수 없다. 필자는 이를 **'종합 점수의 사각지대 문제'**라고 부른다. 전편의 '우등생 문제'가 영역 간 보완(테스트 0점을 문서 만점으로 가려버리는 것)에 대한 이야기였다면, 이것은 그 스케일을 공정 단위로 축소한 유사 형태이다.

그렇다면 캡(Cap)을 늘리면 해결될까? 그렇지는 않다. 캡은 종합 점수에 대한 제약이므로, "릴리스(Release)만은 기다려라, 하지만 요구사항 정리나 문서는 오늘부터 사용해도 좋다"와 같은 **공정별 농담(濃淡, 밀도 차이)**을 표현할 수 없다. Q25가 일부 실시되었다고 해서 종합 점수를 59점으로 억제한다면, 이번에는 "다른 공정은 문제없이 시작할 수 있다"라는 정보가 손실되고 만다.

이렇게 해서, 세 가지 채점 기구가 나란히 놓이게 된다.

삼층 구조라고 하면 거창하지만, 요컨대 답하고 싶은 질문이 3개이기 때문에 채점 기구도 3개인 것뿐이다.

2. 8개 공정의 판정식

결과 화면에서는 8개 공정이 판정 레벨에 따라 "지금부터 활용 가능", "조건을 갖춘 후 활용", "기반을 갖춘 후"의 3개 그룹으로 분류되어 표시된다 (내부 레벨명은 각각 recommended / conditional / not_recommended).

판정식의 전체상을 먼저 보여준다. 표 중의 document

· qa

는 각각 문서 축(Document axis)·품질 보증 축(QA axis)의 달성 비율(01), Qxx는 개별 설문의 답변 계수(01), avg()는 답변 완료된 설문 계수의 단순 평균이다. conditional 조건은 "recommended에 도달하지 못했을 경우에 평가된다"는 점에 주의해 주길 바란다.

구현부 발췌 (가독성을 위해 줄바꿈 및 정렬. processSuitability.ts)

// document, qa 는 축 스코어의 달성 비율(0~1), q(id) 는 설문의 답변 계수(미답변 시 null)
// average() 는 답변 완료된 설문만의 단순 평균(모두 미답변 시 null)
{ process: "requirements",
...

보시다시피, 판정식은 공정마다 입력의 입도(Granularity)가 완전히 다르다. 축 전체의 비율로 "면(面)"을 보는 공정도 있고, 설문 몇 개의 평균으로 보는 공정도 있으며, 단 한 문항의 계수가 문지기 역할을 하는 공정도 있다. 이것은 "해당 공정의 AI 활용이 무엇에 의해 제약(Rate-limiting)되는가"의 차이를 식에 투영하려는 의도로 설계한 것이다 —— 이것이 본고의 주장이며, 이후 3개의 장에서 공정별로 확인해 나갈 것이다.

3. 면(面)으로 판정한다

첫 번째 그룹은 개별 설문이 아니라 평가 축 전체의 달성 비율을 주요 입력으로 하는 공정이다. 특정 한 문항으로는 대표할 수 없는, "조직의 면으로서의 축적"이 작용하는 공정이 여기에 해당한다.

요구사항 정리

요구사항 정리의 recommended 조건은 document >= 0.7

따라서, 축 비중(axis ratio)에 대한 요구사항으로는 8개 공정 중 가장 높다. 요구사항 정리에서의 AI 활용(유스케이스 예: "회의록·요구사항 초안 작성")은 기존의 요구사항·사양·배경 정보를 AI에게 문맥(Context)으로 전달할 수 있느냐가 전부이기 때문이다. 문서 축(Document axis)—README나 환경 구축 절차(Q05), 요구사항·사양 정리처(Q06), 설계 판단 기록(Q07), 코딩 규약(Q08), API 사양(Q09, 표준 진단만 해당)—의 달성도가 낮은 조직에서는, AI에게 "초안"을 만들게 하려 해도 전달할 소재가 애초에 존재하지 않는다.

흥미로운 점은, 축 비중 외에도 Q17 "티켓에 목적, 요구사항, 완료 조건이 기재되어 있습니까"의 계수 0.6 이상이 recommended(권장)로 가기 위한 마지막 관문으로 설정되어 있다는 것이다. 문서 축이 0.7을 넘더라도 Q17이 0.6 미만이라면 판정은 conditional(조건부)로 떨어진다(conditional 조건인 document >= 0.4는 충족하기 때문이다). 사양서가 훌륭하더라도, 개별 작업 단위에 목적과 완료 조건이 적혀 있지 않다면 AI에게 의뢰하는 건건마다의 컨텍스트(Context)가 결여된다—즉, 요구사항 정리는 "조직의 면"과 "작업 단위의 점"을 모두 본다는 설계다.

참고로 구현상, Q17이 미응답인 경우에는 이 관문을 면제하는 가드(Guard)가 들어가 있지만, Q17은 Quick(퀵)·Standard(표준) 양쪽 코스 모두에서 출제되므로 일반적인 진단 흐름에서 이 면제가 적용될 일은 거의 없다.

구현

구현 공정은 document >= 0.6 그리고 qa >= 0.6일 때 recommended, document >= 0.35 또는 qa >= 0.35일 때 conditional이 된다. recommended는 AND, conditional은 OR라는 구조에 의도가 담겨 있다.

구현에서의 AI 활용은 "AI에게 코드를 쓰게 하는" 입력 측과 "쓴 것을 검증하는" 출력 측이라는 두 바퀴로 성립한다. 문서가 갖춰져 있더라도 검증 수단(자동 테스트·확인 항목·정적 분석 등의 품질 보증 축)이 없다면, AI의 생성 속도는 그대로 품질 저하 속도가 된다. 반대로 검증이 강력하더라도 문서가 없다면, AI는 엉뚱한 코드를 고속으로 양산한다. 그래서 recommended에는 양쪽 모두를 요구한다. 반면 conditional의 임계치를 0.35라는 낮은 OR로 설정한 것은, 한쪽 날개라도 있다면 "조건을 정비하며 작게 시도해 보는" 입구는 열어두어야 한다는 판단이다. 완전히 0에 가까운 경우에만 not_recommended가 된다.

문서화

전편에서 단 하나 밝혔던 예외—"문서 작성" 공정만은 not_recommended가 되지 않는다—의 실체가 이것이다. 판정식은 Q08 >= 0.6 또는 document >= 0.5 ? recommended : conditional이며, 애초에 삼항 연산자가 not_recommended를 반환하는 분기를 가지고 있지 않다. 이 "최소 응답이라도 not_recommended가 되지 않는" 동작은 유닛 테스트(Unit Test)에서 명시적으로 고정되어 있다(모든 문항에 최소 응답을 한 피스처(Fixture)로 검증. spec-cases.test.ts).

조건이 OR라는 점에도 주목해 주길 바란다. 코딩 가이드라인이나 명명 규칙(Q08)이 정비되어 있는지, 혹은 문서 축 전체가 0.5 이상인지—둘 중 하나만으로 recommended에 도달하는, 8개 공정 중 가장 느슨한 게이트다. 아무리 정비가 늦어진 조직이라도 문서 작성 보조(사양·README·변경 이력 정비)는 AI 활용의 안전한 입구로서 기능한다는, 전편에서 언급한 판단을 식의 형태가 그대로 나타내고 있다.

다만 전편에서는 이 예외가 "유일한 특별 규칙"인 것처럼 기술했다. 실제로는 빙산의 일각이며, 나머지 7개 공정에도 각각 고유한 비대칭성이 심어져 있다. 여기서부터가 본고에서 처음으로 공개하는 부분이다.

4. 설문군의 평균으로 판정한다

다음 그룹은 축 전체만큼 넓지 않고, 한 문항만큼 좁지도 않은—해당 공정에 영향을 미치는 몇 개 문항의 평균으로 판정하는 공정이다.

설계

설계 공정은 avg(Q07, Q09, Q10)의 평균이 0.7 이상이면 recommended, 0.4 이상이면 conditional이 된다. 핵심은 Q07 "중요한 설계 판단이나 기술 선정의 이유가 문서로 남아 있습니까"이다. 설계에서의 AI 활용(유스케이스 예: "설계안 비교·리뷰 관점 도출")에서는 AI가 과거의 의사결정과 외부 제약을 고려할 수 있게 할 수 있는가가 품질을 가른다. ADR(Architecture Decision Record)적인 판단 기록(Q07)과 API·외부 연동 사양(Q09)은 바로 그 재료이다.

판단이 not_recommended으로 표시될 때 나타나는 주석 「설계 판단 기록이 없으면, 과거의 의사결정을 바탕으로 한 제안이 어렵습니다」는 이 설계 의도의 반증입니다. 참고로, 이 주석의 표시 조건이 8개 공정 중 특수하다는 점은 나중에 설명하겠습니다.

(식에 포함된 Q10 「DB 설계나 데이터 항목의 의미가 문서화되어 있습니까?」가 실제로는 판정에 기여하지 않는 부분은 제7장에서 모아서 공개하겠습니다.)

코드 리뷰

코드 리뷰 공정은 avg(Q15, Q23, Q24, Q29) >= 0.6에 더해, Q15 「Pull Request 또는 Merge Request를 통한 리뷰를 수행하고 있습니까?」 단독으로 0.6 이상을 요구하는 혼합형입니다. 정적 분석의 자동 실행(Q24)이나 AI 생성 코드의 인간 검토 규칙(Q29)이 아무리 잘 갖춰져 평균을 높여도, Q15가 0.6 미만이면 recommended이 될 수 없습니다.

그 이유는 간단합니다. AI를 통한 리뷰 보조(변경 내용 요약・검토 관점 제시)는 PR이라는 「리뷰가 삽입되는 장소」가 있어야 비로소 삽입할 수 있기 때문입니다. 리뷰의 장 자체가 운영되지 않는 조직에 AI 리뷰 도구를 도입해도, 출력을 받아들이는 공정이 존재하지 않습니다. 평균으로 「면(面)」을 보면서도, 성립의 전제가 되는 질문 하나만은 단독 게이트로 설정한 것입니다. 즉, 코드 리뷰는 축 비율형과 단문 게이트형의 하이브리드입니다.

참고로 Q15는 앞 편에서 소개했던 캡(Cap) 「인간에 의한 리뷰/본격 승인이 없음」(상한 59점) 발동 조건의 한쪽 날개이기도 합니다. **같은 문항이 종합 점수의 상한과 공정 게이트 양쪽을 장악하는 「이중 책임」**의 예시입니다 (또 다른 예시는 다음 장의 Q25에서, 그쪽은 더욱 극적입니다).

운영

운영 공정은 avg(Q12, Q26, Q22)가 0.6 이상이면 recommended, 0.3 이상이면 conditional이 됩니다. 실질적인 주역은 Q26 「기밀 정보나 개인 정보의 취급 규칙이 있습니까?」입니다. 운영에서의 AI 활용(유스케이스 예시: 「로그 요약・장애 1차 분류 보조」)은 실제 로그나 에러 정보—기밀이나 개인 정보가 가장 많이 혼입되기 쉬운 데이터—를 AI에게 전달하는 행위를 필연적으로 포함합니다. 취급 규칙 없이 이것을 시작하는 것은, 활용이 진행될수록 유출 위험이 쌓이는 구조이며, 그래서 규칙의 존재가 운영 공정의 게이트가 되는 것입니다.

또 다른 입력 Q22 「변경 후에 실시해야 할 확인 항목이 명확합니까?」는 장애 대응의 1차 분류를 AI에 보조시키는 과정에서 「무엇을 확인할지」라는 관점의 형식 지식화에 해당합니다. 참고로, 이 식에는 모든 문항이 미응답일 경우 conditional로 떨어지는 폴백 분기가 있으며, 이것이 예상치 못한 상황에서 효과를 발휘하는 것도 제7장에서 설명하겠습니다.

5. 한 문제가 문지기 역할을 하다

마지막 그룹은 단 하나의 계수가 판정을 지배하는 공정입니다. 여기에 이 도구에서 가장 비대칭적인 두 가지 조건식이 있습니다.

테스트

테스트 공정의 문지기는 Q21 「자동 테스트가 있습니까?」입니다. recommended에는 Q21 >= 0.6이 필요하며, conditional 조건은 다음과 같이 작성되어 있습니다.

✅ conditional 조건: Q21 >= 0.2 또는 Q24 >= 0.6

임계값이 비대칭적이라는 점을 알아차리셨나요? Q21은 0.2—즉 「모른다(계수 0.2)」라고 답만 해도 conditional에 도달합니다. 반면, 대체 입구인 Q24 「정적 분석, Lint, 타입 체크를 자동 실행하고 있습니까?」에는 0.6—「일부 수행」 이상을 요구합니다.

Q21 쪽의 0.2는 앞 편에서 작성한 「파악하지 못하는 것과 존재하지 않는 것은 다르다」라는 계수 설계의 재현입니다. 자동 테스트가 「있는지 아는지 모르는」 사람은, 단지 자신이 파악하고 있지 않을 뿐, 테스트는 존재할 수도 있습니다. 그래서 conditional(조건을 갖춘 후)에 배치한 것입니다. 하지만 「거의 없다(계수 0)」라고 단언된 경우는 이야기가 다릅니다. Q24가 0.6 이상이 아니면 not_recommended로 떨어집니다. 같은 낮은 계수라도, 「무지」는 구제하지만 「부재」는 구제하지 않습니다.

Q24 쪽에 0.6을 요구하는 것은 자동 테스트를 대신하게 하기 위함입니다. 테스트가 없더라도, 정적 분석・Lint・타입 체크가 돌아가고 있다면, AI 생성 코드의 기계적 검증 일부는 성립합니다—다만 「대역」을 맡기는 만큼, 본격적인 운영(0.6 이상)이 조건이 됩니다. 게다가 recommended 쪽에서는 Q24가 출제되는 경우 0.6 이상인 것도 요구합니다. 자동 테스트가 있어도 정적 분석이 돌아가지 않는 상태는, AI에 의한 테스트 코드 생성을 전면적으로 권장하기에는 역부족이라는 판단입니다.

릴리스

그리고 서두의 수수께끼에 대한 답이다. 릴리스 (Release) 공정의 권장 (recommended) 조건은 다음과 같다.

❌ 흔한 설계: Q20 >= 0.6 이고 Q25 >= 0.6 (일부 실시라면, 뭐 그럭저럭 통과시킨다)

✅ 실제 설계: Q20 >= 0.6 이고 Q25 === 1.0 (운영 반영 승인만큼은 만점이 아니면 인정하지 않는다)

Q20 「CI/CD 또는 자동 빌드 메커니즘이 있습니까」는 다른 문항과 마찬가지로 0.6으로 통과시킨다. 하지만 Q25 「운영 반영 전에 인간에 의한 승인이 있습니까」만은, 임계값 비교 (threshold comparison)조차 아닌, 계수 1.0 —— 「충분히 실시하고 있음」 —— 이라는 엄격한 등가 판정이다. 8개 공정의 전체 조건식 중에서 >=가 아닌 ===가 사용된 곳은 여기뿐이다.

왜일까. 본 도구에서는 승인이 「일부 실시」인 상태를, 승인 없이 운영 환경에 도달할 수 있는 경로가 남아 있을 수 있는 상태로 취급한다. 릴리스는 8개 공정 중 유일하게 실패의 영향이 즉각적으로 운영 환경에, 종종 비가역적으로 미치는 공정이다. AI로 릴리스 노트나 절차서의 초안을 만드는 것 자체는 저위험(low risk)일지라도, 그 공정을 「지금부터 활용할 수 있다」고 보증하는 것은 마지막 방어선이 완전할 때로 한정한다. 0.6은 「대체로 되어 있다」는 계수이지만, 방어선의 「대체로」는 구멍과 동의어이기 때문이다.

Q25는 캡 (cap)과의 이중 책임 관계로 인해 극적인 움직임을 보인다. 「실시하지 않음」이라면 캡 발동으로 종합 점수가 59점에 억제되어 당연히 릴리스 공정도 권장 (recommended) 상태가 되지 않는다. 「일부 실시」라면 캡은 피해서 종합 98점까지 도달할 수 있지만, 그럼에도 릴리스의 권장 (recommended) 상태만큼은 절대로 얻을 수 없다. 종합 점수의 사각지대 문제를 가장 선명하게 체현하는 문항이다.

6. 「판단 포인트」는 언제 표시되는가

결과 화면의 각 공정 카드에는 「첫 활용 사례: ~」가 항상 표시되며, 일부 공정에는 추가로 「판단 포인트: ~」라는 주석이 붙는다. 사실 이 주석 (구현상으로는 noteKey)의 부여 규칙도 공정마다 제각각이다.

언뜻 보기에는 모두 같은 「주의 사항」처럼 보이지만, 성질이 두 종류로 나뉜다. 상시 표시되는 4개는 **「해당 공정에서 AI를 사용하기 시작한 후의 운용상의 주의 사항」**이며, 판정이 권장 (recommended)이든 조건부 (conditional)이든 유효하기 때문에 항상 출력한다. 반면, 설계 공정의 주석만은 「왜 낮은 평가를 받았는가」에 대한 이유 설명이며, 권장되지 않음 (not_recommended)일 때 (판정식상 평균이 null이거나 0.4 미만일 때)에만 의미를 가지므로 조건부로 출력한다.

……라고 쓰면 정연하게 들리겠지만, 솔직히 말하면 요구사항 정리, 구현, 테스트의 3개 공정에 주석이 없는 것은 「상시 표시해야 할 정형화된 주의 사항을 아직 정의하지 않았을 뿐」이며, 3가지 패턴이 혼재되어 있다는 것은 설계로서 완전히 정리되지 않은 부분이기도 하다. 하나의 예외 (설계)만이 조건 분기를 가지는 구조는, 전편에서 자책했던 「예외는 예외라고 명시할 수 있는 형태로 가진다」는 실천 측면에서는 낙제점을 면할 수준이지만, 주석 체계 전체의 일관성에는 개선의 여지가 있다.

요약

종합 점수는 모든 문항을 녹여낸 집계값이며, 특정 공정의 전제가 딱 하나 빠져 있는 것 —— Q25의 「일부 실시」와 같은 —— 상황을 반영하지 못한다. 이것이 종합 점수의 사각지대 문제이며, 공정마다 독립된 게이트 조건 (gate condition)이라는 제3의 채점 기제를 둔 이유이다.

채점 기제는 답하고자 하는 질문의 수만큼 필요하다. 하나의 숫자로 모든 질문에 답하게 하려 할 때, 진단은 거짓말을 하기 시작한다.

8개의 판정식은 입력의 입도 (granularity)도, 임계값도, 연산자도 일치하지 않는다. 축 비율의 AND로 양 바퀴를 요구하는 구현, 한 문항을 단독 게이트로 격상시킨 코드 리뷰, 「모름」과 「없음」을 구분하는 테스트의 비대칭 임계값, 그리고 엄격한 일치로만 열리는 릴리스의 문. 이 불일치함은, 각 공정의 AI 활용이 무엇에 의해 제약(limiting factor)받는지가 애초에 제각각임을 반영하는 것이라고 필자는 생각한다. 물론 그 대가로 기제는 3층 구조로 늘어났고, 출제되지 않은 문항을 참조해야 하는 부채도 떠안게 되었다. 판정식을 늘리는 것은 설명 책임을 늘리는 것이기도 하다 —— 본 글이 그 설명의 일부가 된다면 다행이겠다.

Discussion