서론

"진단 도구의 문항은 모두 어떤 경고나 판정에 연결되어 있을 것이다" —— 그렇게 생각하고 싶어진다. 굳이 답변을 요구하는 데에는 그 답이 어딘가의 분기점을 움직일 것이라고 말이다.

하지만 필자가 공개한 OSS 진단 도구인 「AI 주도 개발 도입 진단 (ai-dev-readiness)」에서는 이런 일이 일어난다. 표준 진단 26문항 중, 어떤 9문항 모두에 계수 0.3 이하의 낮은 평가 —— 레거시 시스템 쇄신, 임베디드·제어 시스템, 태스크 분할 없음, AI 도구 미사용 등 —— 를 나열해도, 종합 스코어의 상한(Cap)은 하나도 발동되지 않으며, 8개의 개발 공정은 모두 "지금부터 활용할 수 있음"으로 분류되어 종합 72점·레벨 4(AI 주도 개발에 적합함)가 된다 (판정식으로부터의 수계산. 도출 과정은 본문에서 제시). 약 28점이 완만하게 깎일 뿐, 캡(Cap)이나 공정별 판정에는 단차가 생기지 않는다. 이는 대충 만든 것이 아니라 의도된 설계다.

본고는 실제로 출제되는 이 9문항을 하나씩 해부한다. "왜 이 문항이 AI 주도 개발 진단에 필요한가", 그리고 "왜 필요한데도 절벽(Cap)이나 관문(Gate)으로 만들지 않았는가". 참고로 나머지 4문항(Q14·Q19·Q31·Q32)은 현재의 어떤 진단 코스에도 출제되지 않는 문항이므로, 본고에서는 개별적으로 다루지 않는다. 예외 없이, 문항의 선정과 계수 또한 필자의 실무 경험과 설계 과정에 기반한 가설이며, 확립된 평가 이론은 아니다.

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

TL;DR (5줄 요약)

• 전체 34문항 중 13문항은 캡(전편)에도 공정별 게이트(제3회)에도 관여하지 않고, 가중 평균만을 움직인다 —— 이 중 실제로 출제되는 것은 9문항이며, 본고에서는 이 9문항을 "평지의 문항"으로 다룬다. 9문항이 project 축 4문항·process 축 2문항·ai 축 3문항에 분포하는 것은 우연이 아니다 ——
• 게이트가 document 축·qa 축의 축 비율을 통째로 참조하기 때문에, 이 두 축의 문항은 자동으로 관문 요원이 된다.
• 평지의 9문항에 거의 최저 평가를 나열해도 종합 72점·Lv4, 캡 발동 제로, 8개 공정 모두 "지금부터 활용할 수 있음"이 된다 (수계산).
• 평지 내부에도 고저차가 있다 —— 답변이 무엇이든 개선 제안이 나오지 않는 Q02, 5지선다 중 3개 선택지에서만 제안되는 Q01.
• 더욱 엄밀히 말하면 "가중 평균만을" 움직이는 것도 아니다 —— Q01·Q02·Q34는 생산성 개선 여지의 추정에, Q01은 기획 단계 경고에 직결된다 (이 3개 문항 주변은 유닛 테스트의 뒷받침이 있다).

1. 세 가지 채점 기구와, 어디에도 속하지 않는 9문항

이 도구의 채점은 세 가지 기구로 이루어져 있다. 가중 평균(원점수), 캡(종합 점수의 상한), 공정별 게이트 조건(8개 공정의 최대 3단계 판정)이다. 뒤의 두 가지가 참조하는 문항은 코드상에서 완전히 열거할 수 있다.

• 캡의 발동 조건 (scoring.ts) 이 참조하는 것은 Q13·Q16·Q25·Q15·Q28·Q06·Q21·Q22의 8문항
• 공정별 게이트의 판정식 (processSuitability.ts) 이 개별적으로 참조하는 것은 Q17·Q07·Q09·Q10·Q15·Q23·Q24·Q29·Q21·Q08·Q20·Q25·Q12·Q26·Q22. 여기에 더해 document 축과 qa 축의 축 비율을 입력값으로 사용한다.

이 두 리스트와 축 비율의 영향 범위를 역산하면, 어느 쪽에도 걸리지 않는 문항은 13문항이다. 다만 그중 4문항(Q14·Q19·Q31·Q32)은 현재의 퀵(Quick)·표준(Standard) 어느 진단 코스에도 출제되지 않으므로, 본고에서는 실제로 출제되는 9문항을 대상으로 한다.

이 9문항의 배점은 작지 않다. 표준 진단·팀 개발 (개인 개발 보정 없음)의 경우, 출제되는 9문항이 차지하는 비중은 project 축 전체 15점, process 축 25점 중 2/7 (약 7.1점), ai 축 15점 중 3/5 (9점) —— 합계 약 31점. 종합 스코어의 약 3할이 어떤 캡이나 어떤 게이트의 걱정 없이 완만하게 증감하기만 하는 영역이다 (축 내부는 균등 가중치로 가정한 개산·수계산이다).

도입부의 72점 내역도 여기서 나온다. 관문(Gate)에 관여하는 측의 모든 문항을 최고 평가로 설정하고, 평지(Plain)인 9개 문항에 Q01=레거시 시스템 쇄신(0.3), Q02=임베디드·제어 시스템(0.3), Q03=해당 사항 없음(0), Q04=특정 담당자에게 의존(0.3), Q18·Q33·Q27·Q30·Q34=실시하지 않음/이용하지 않음(0)을 나열하면, 축 스코어(Axis Score)는 document 25.0 + qa 20.0 + process 약 17.9 + ai 6.0 + project 약 3.4로 원점수 약 72.2점이다. 캡(Cap)은 무반응, 게이트(Gate)는 8개 공정 모두 recommended, 종합 72점·Lv4가 된다.

참고로 퀵 진단(12문항)에서는 이 9개 문항 중 Q01 단 한 문항만이 출제된다. 나머지 8개 문항은 표준 진단에서만 출제된다. 12문항에 2분이라는 짧은 시간은 결과적으로 '관문의 순회'에 특화된 구성이 된다.

2. 왜 절벽도 관문도 아닌가 —— 「보완 가능한 세계」의 거주자

전편에서 필자는 가중 평균을 「보완 가능한 세계의 모델」이라고 불렀다. 부족한 영역을 다른 강점으로 보완할 수 있다는 전제의 모델이며, 테스트 부재와 같은 보완 불가능한 결락에는 캡(Cap)이라는 별도의 레이어가 필요하다 —— 이것이 전편의 주제였다.

뒤집어 말하면, 보완이 가능한 항목은 가중 평균이야말로 올바른 모델이라는 뜻이기도 하다. 평지의 9개 문항은 모두 다음 중 하나에 해당한다.

① 여건(바꿀 수 없거나 바꾸기 어려운 조건)이다. project 축의 4개 문항 —— 개발 종별, 개발 대상, 기술 스택, 사양 이해의 분포 —— 는 팀의 노력이라기보다 놓인 상황을 측정한다. 레거시 쇄신인 임베디드 시스템이라고 해서 AI 주도 개발이 「성립하지 않는」 것은 아니며, 기대치를 낮추고 신중하게 진행해야 하는 것이다. 불리한 여건은 감점으로 표현하지만, 여건을 이유로 문전박대하지는 않는다. 실제로, **project 축은 캡에도 게이트에도 단 한 문항도 관여하지 않는, 유일한 「축 전체가 통째로 평지」**이다.

② 정도 문제(결여되어도 열화될 뿐, 파탄 나지는 않는다)이다. 태스크의 입도(Q18), 지시 파일의 정비(Q30), AI 도구의 이용 실적(Q27) —— 이것들이 결여된 AI 주도 개발은 비효율적이 될 수는 있지만 불가능해지지는 않는다. 같은 Git 영역이라도 Git 자체의 부재(Q13)는 절벽(상한 49점)이고, 커밋의 입도나 운용의 질은 언덕이다. 같은 ai 축이라도 입력 금지 규칙의 부재(Q28)는 안전의 구멍이기에 절벽(상한 69점)이고, 지시 파일의 부재는 정밀도의 손실이기에 언덕이다. 「파탄 조건」과 「열화 요인」을 별도의 레이어로 분류하는 것 —— 이 선긋기야말로 삼층 구조 설계 판단의 핵심이다.

또 하나, 9개 문항의 분포(project 4 · process 2 · ai 3)에는 구조적인 비밀이 있다. 제3회에서 보았듯이, 공정별 게이트는 document 축과 qa 축의 「축 비율」을 통째로 입력값으로 사용한다. 즉, 이 두 축의 문항은 개별적으로 참조되지 않더라도 축 비율을 변화시킴으로써 자동으로 게이트에 관여하게 된다(README의 Q05조차 요구사항 정리·구현·문서화 공정 판정에 영향을 미친다). 개별 참조되지 않는 한 관문과 무관할 수 있는 것은 project · process · ai 축의 문항뿐이다 —— 평지가 이 3개 축에만 존재하는 것은 게이트 입력 설계의 필연이다.

여기서부터가 본론이다. 9개 문항을 하나씩 「왜 AI 주도 개발 진단에 이 문항이 필요한가」의 관점에서 살펴보겠다.

3. project 축의 4개 문항 —— 축 전체가 통째로 평지

앞서 언급했듯이, project 축(배점 15점)은 4개 문항 모두가 평지다. 이 축은 팀의 실천이 아니라 AI 활용의 토대가 되는 여건을 측정한다.

Q01 「대상 개발은 어떤 종류입니까?」

AI 활용의 효과는 「무엇을 만드는가」에 따라 천장이 달라진다. 신규 개발은 기존 코드의 제약 없이 AI의 생성력을 받아들일 수 있지만, 레거시 쇄신에서는 암묵적 사양과 오래된 기술이 AI로의 컨텍스트 (Context) 공급을 방해한다. 최저점인 0.2가 「기획·검토 단계」인 이유는 진단 대상이 되는 개발의 실체가 아직 존재하지 않기 때문이며, 이 답변은 결과 화면의 「진단은 참고치」 경고(후편에서 소개할 내용)의 발생 원인이기도 하다. 9개 문항 중 유일하게 퀵 진단에도 출제되는, 평지의 대표 격이다.

Q02 「주요 개발 대상은 무엇입니까?」

Q03 「사용 기술은 현재도 널리 사용되는 일반적인 기술입니까」

AI의 제안 품질은 기술의 보급도에 의해 제한된다. 널리 쓰이는 스택이라면 학습 데이터가 풍부하여 제안이 정확해지지만, 독자 프레임워크나 희소 언어에서는 엉뚱한 보완이나 그럴듯한 오류가 늘어난다. 대응하는 개선 제안 imp-Q03「일반적인 기술 스택으로의 전환 검토」(low)가 '지금 당장 전환하라'가 아니라 장기적인 기술 선정 방침으로 쓰여 있는 것도, 이것이 절반은 전제 조건이기 때문이다.

Q04 「시스템 사양을 이해하는 담당자는 복수입니까」

AI 생성물의 검증에는 사양을 아는 사람이 필요하다. 사양 이해가 특정 한 사람에게 의존하고 있으면, AI가 늘린 변경량의 검증이 그 한 사람에게 집중되어 리뷰가 병목 구간이 된다. — AI는 작성 속도를 높이지만, 확인하는 속도는 높여주지 못한다. 팀 전제 플래그(teamShared)가 붙은 설문이라 개인 개발에서는 전편에서 설명한 가중치 감소 보정의 대상이 된다. 개선 제안은 imp-Q04「사양 이해의 사일로화 해소」(low).

4. process 축 2개 문항 — 「Git이 있다」보다 한 단계 위를 측정한다

process 축(배점 25점)은 표준 진단에서 출제되는 7개 문항 중 5개가 관문 요원(Q13・Q15・Q16이 상한, Q17・Q20이 게이트)에 해당하고, 평지는 나머지 2개이다.

Q18 「개발 작업을 몇 시간에서 며칠 정도의 단위로 분할할 수 있습니까」

AI에 위임할 수 있는 작업에는 입자의 상한이 있다. 거친 작업은 지시가 모호해지고, 생성되는 차분(diff)이 거대화되어 검증 불가능한 풀 리퀘스트를 만든다. 반면 몇 시간~며칠 단위로 나뉜 작업은 각각 AI에 요청 및 검증의 단위로서 그대로 기능한다. 티켓 관리 유무(Q16, 상한 관여)가 '그릇'이라고 한다면, Q18은 그 그릇에 담는 내용물의 자르는 방식을 측정한다. — 그릇의 부재는 절벽, 자르는 방식은 언덕, 이라는 분류이다.

Q33 「작은 단위로 잦은 커밋이나, 롤백・리버트 활용이 정착되어 있습니까」

Git이 있다는 것(Q13, 상한 49점의 절벽)과, Git을 안전장치로서 능숙하게 사용하는 것은 별개이다. AI 활용은 변경량을 확실히 늘리기 때문에, 작게 자른 커밋과 '문제가 생기면 revert로 되돌리는' 운영은, AI 출력을 안심하고 받아들이기 위한 실무상의 생명선이 된다. 평지 9개 문항 중 적은 medium 우선도로, 저평가 시 imp-Q33이 개선 제안에 올라오는 것은 유닛 테스트로 검증되었다. 이 역시 Q13=「Git 외」일 때 출제에서 제외된다(skipCondition).

5. ai 축 3개 문항 — 「안전성」은 절벽, 「활용도」는 언덕

ai 축(배점 15점)에서 절벽이 된 것은 Q28(입력 금지 규칙, 상한 69점)뿐이고, 게이트는 Q29(AI 생성 코드의 리뷰 규칙, 코드 리뷰 공정)뿐이다. 나머지 3개 문항 — 활용의 깊이를 측정하는 설문군 —은 모두 평지이다.

Q27 「AI 코딩 툴을 개발 업무에 사용하고 있습니까」

계수는 팀으로 지속 이용 시 1.0 / 일부 멤버는 0.6 / 시험 이용만은 0.3 / 미사용 시 0이다. 준비도에는 '이미 쓰고 있는지'라는 실적 항목도 필요하다. 이용 실적은 가이드라인 정비나 효과 측정의 전제가 되는 경험치 축적이며, 미사용 상태로는 이후의 체제계 설문이 모두 공상에 그치기 때문이다. 다만 미사용이라도 계수 0의 감점만 하므로 절벽은 아니다. — 안 쓰고 있다는 것은 지연이지, 파탄은 아니다.

Q30 「AI에게 참조시키는 가이드라인이나 지시 파일이 있습니까」

AGENTS.md, CLAUDE.md, Copilot instructions 등, AI가 읽는 것을 전제로 작성된 파일의 유무를 묻는다. 규약이나 설계 방침을 "AI가 읽을 수 있는 형식"으로 번역하여 배치하는 것은, 생성물의 일관성 확보를 인간의 리뷰에 의존하던 방식에서 시스템(Mechanism)으로 옮기는 첫걸음이다. Document 축이 인간을 위한 형식지 (Explicit Knowledge)를 측정하는 반면, Q30은 AI를 위한 형식지를 측정한다. 이 도구에서 가장 AI 주도 개발 (AI-Driven Development) "고유"한 문항 중 하나라고 할 수 있다.

Q34 「AI 도구가 사내 데이터를 안전하게 참조할 수 있는 상태입니까」

계수는 많이 참조할 수 있음 1.0 / 일부 0.6 / 참조할 수 없음 0 / 모름 0.2. AI 출력의 품질은 모델 성능과 더불어 컨텍스트 (Context) 공급량에도 좌우된다. 이는 이 도구 전체를 관통하는 전제이며, Q34는 그 공급로가 개통되어 있는지를 직접 묻는다. "안전하게"라는 단어가 중요한데, 기밀 취급 규칙에 따른 참조임을 문항에서 명시하고 있다 (무질서한 연결은 Q28의 절벽 영역이다). medium 우선순위이며, 낮은 평가 시의 imp-Q34 생성과 계수 정의는 유닛 테스트 (Unit Test)를 통해 검증 완료되었다. 또한 이 문항은 제7장에서 서술할 "생산성 추정으로의 직결"을 가진 3개 문항 중 하나이기도 하다.

6. 평지에도 고저차가 있다 —— 개선 제안 필터의 그라데이션

9개 문항을 "평지"라고 일괄적으로 묶어왔지만, 내부를 들여다보면 취급이 일정하지 않다. 개선 제안 생성 로직 (recommendations.ts의 generateRecommendations)에는 다음과 같은 필터가 구현되어 있다.

// recommendations.ts 에서 발췌 (가독성을 위해 줄바꿈 및 정렬)
const eligible =
coefficient !== null && coefficient < 1
...

이를 바탕으로 하면, 9개 문항은 3개의 계층으로 나뉜다.

Q02의 제외는 설계 판단으로서 이해할 수 있다. "주요 개발 대상"은 주어진 조건 중의 조건이며, "임베디드(Embedded)를 그만두고 웹(Web)을 만들어라"라는 제안은 개선 액션이 될 수 없다. 하지만 그 결과, 임베디드·제어 시스템이라고 답한 사용자는 약 2.6점(project 축 15점의 1/4 × 계수 차이 0.7)을 잃으면서도, 그 이유를 결과 화면의 어떤 개선 제안에서도 알 수 없다. 필자는 이를 "무언의 감점"이라 부른다. 게다가 아이러니하게도, 카탈로그상의 imp-Q02 "개발 대상 도메인의 기술적 특성 파악"은 도메인 변경을 요구하지 않는 형태로 정성껏 작성되어 있다. 즉, 목적지가 있는 제안문을 준비해 놓고는 필터가 출구를 막고 있는 것이다. 표시하지 않을 거라면 정의를 삭제해야 하며, 이는 부채 (Debt)라고 불려도 할 말이 없다.

Q01의 3가지 값 제한은 조금 더 타당성이 있다. 개선 제안 imp-Q01 "개발 단계에 따른 AI 활용 계획 수립"이 의미를 갖는 것은, 기반 정비가 선결 과제가 되는 레거시 쇄신, 기획 단계, 유지보수의 3가지 선택지이기 때문이다. 반면 "기존 시스템에 대한 기능 추가" (계수 0.9)는 만점은 아니지만 제안 대상에서 제외되는데, 잃는 점수는 약 0.4점이다. 이 정도의 감점에 제안을 내는 것은 노이즈라는 판단으로 읽힌다.

또 다른 비대칭성에 대해서도 언급해 둔다. 강점 선정 (selectStrengths)에는 Q02 제외와 같은 특별 대우가 없으며, 출제되는 9개 문항은 모두 계수에 따라 최대 3개의 "강점"으로 선택될 수 있다. 즉, Q02는 "칭찬받을 수는 있어도, 지적받지는 않는" 문항이다. 웹 개발이라면 "AI 지원과 친화성이 높은 개발 대상이다"라고 표시될 수 있지만, 임베디드 개발에 대한 언급은 어디에도 없다.

7. "가중 평균에만 영향을 미친다"는 말은 과장이다 —— 제4의 채널

지금까지 "평지의 9개 문항은 가중 평균을 통해서만 종합 점수에 영향을 미친다"라고 써왔다. 캡(Cap)과 게이트(Gate)에 관한 한 이는 정확하지만, 종합 점수의 외부까지 시야를 넓히면 정확하지 않다. 9개 문항 중 3개 문항은 개발 생산성 개선 여지(추정치) 계산 시, 문항 ID로 직접 참조된다.

// costReduction.ts 에서 발췌 (가독성을 위해 줄바꿈 및 정렬)
const c =
(answers.Q01 === "new_development" ? 3 // 신규 개발이라면 +3
...

후편에서 소개한 「AI 활용을 통한 개발 생산성 개선 여지」(0~45%로 클램핑(clamping)되는 추정 범위)는, 종합 점수 대역에서 기준치를 결정한 후 이 보정치를 가감산한다. 즉, Q01·Q02·Q34는 종합 점수라는 우회로를 거치지 않고, 추정치로 직결되는 전용선을 가지고 있다. 요건(무엇을 어떤 체제로 만들고 있는가)과 컨텍스트(context) 공급로(Q34)야말로 생산성 효과의 기대치를 가장 크게 좌우한다는 설계 판단의 표현이다. 또한 Q01은 기획·검토 단계라고 답했을 경우 결과 화면에 경고를 띄우는 planningPhaseWarning의 유일한 발생원이기도 하다.

요약

요건과 정도 문제로 구성된 이 설문군은 결여되어도 파탄 나지 않으며, 다른 항목으로 보완할 수 있고, 연속적으로 개선된다. 그렇기에 가중 평균이라는 「보완 가능한 세계의 모델」에 거주하게 하여, 종합 점수의 약 3할을 경고 없이 완만하게 증감하는 평지로 남겨두었다.

채점 설계의 사상은 무엇을 관문으로 삼았는지뿐만 아니라,

무엇을 관문으로 삼지 않았는지에도 동일한 농도로 나타난다.

다만, 평지는 관리를 소홀히 하면 황폐해진다. 제안문을 가지고 있으면서 영원히 침묵하는 Q02, 테스트가 부족한 제외 규칙——완만하다는 것과 설명되지 않는다는 것은 다르다. 감점에는 이유의 표시가, 제외에는 근거의 테스트가 수반되어야 하며, 그곳이 이 평지의 개수 예정지다. 9개 문항 각각의 「왜 필요한가」에 설득력이 있었는지, 진단을 직접 사용해 본 후의 이견을 꼭 들려주길 바란다.

Discussion