AI 주도 개발의 감별 진단 — 실패의 오독과 층별 모델

AI 주도 개발의 실패 패턴을 나열하기 전에, 한 단계 더 나아간 질문이 필요합니다. AI 코딩 툴을 도입한 지 반년. PR 수는 2배, 개발자 만족도 설문조사는 높은 평가. 하지만 릴리스는 늘지 않고, 운영 장애는 미세하게 증가하며, 리뷰 담당 시니어는 지쳐가고 있습니다. 이것은 '실패'일까요? 아니면 '순조로운 상태'일까요? 본 기사는 판정 그 자체를 일단 유보하고, '잘 되지 않는다'는 것은 무엇인가 / 원인은 어디에 있는가를 의료의 감별 진단 (Differential Diagnosis)에 따라 분해합니다.

PR이 3배가 되었는데 릴리스가 늘지 않는다, 그것은 '실패'인가

AI 코딩 툴 도입 후 6개월. 문득 다음과 같은 상황에 놓여 있지는 않습니까?

• PR 수는 주당 2~3배로 증가했다
• 개발자 설문조사의 만족도는 전년 동월 대비 대폭 향상되었다
• 하지만 릴리스 빈도는 변하지 않았거나, 오히려 미세하게 감소했다
• 리뷰 담당 시니어 엔지니어 2명이 "이제 한계다"라고 말하기 시작했다
• 운영 인시던트(Incident) 건수는 미세하게 증가했으나, 경미한 것들뿐이다
• 경영진으로부터 "결국 무엇이 개선되었는가?"라는 질문을 받고 있다

여기서 많은 팀은 이지선다의 상황에 놓입니다. "AI 툴이 별로니까 철수한다" 또는 "아직 제대로 활용하지 못하고 있을 뿐이니 추진한다". 하지만 둘 다 오진의 리스크를 내포하고 있습니다. 철수한다면, 원인이 AI가 아니라 리뷰 설계나 온보딩 설계에 있었을 경우 문제는 계속 남게 됩니다. 추진한다면, 정말로 툴이 미스매치였을 경우 상처를 더 깊게 만들 뿐입니다.

이 기사가 답하는 2가지 질문

• "잘 되지 않는다"는 것은 무엇을 의미하는가? — 무엇을 관측해야 "실패"라고 판정할 수 있는가. 반대로 무엇을 관측해도 판정할 수 없는가.
• 그 원인은 어디에 있는가? — 개인·팀·조직·툴 중 어느 계층에 문제가 있는가. 어느 계층부터 개입해야 하는가.

이 두 가지 질문에 대한 답은 기존의 관련 기사 4편에서는 정면으로 다루고 있지 않습니다. 이유는 단순합니다. 그것들은 "실패 패턴 카탈로그", "조직 병목 현상 분석", "개인 페르소나 유형화", "재건 플레이북"으로, 모두 "실패했다고 판정된 이후"의 이야기이기 때문입니다.

기존 기사	다루는 영역	본 기사와의 관계
생성 AI 코딩이 확실히 실패하는 8가지 패턴	실패 증상 카탈로그	본 기사의 "증상의 층"의 구체적 사례집
...	...	...

본 기사의 역할은 위 4편의 상위 개념으로서의 진단 프로세스를 제시하는 것입니다. 독자는 본 기사를 읽은 후, 자사의 상황을 진단하고 다음에 어떤 처방전 기사를 읽어야 할지 판단할 수 있는 상태가 됩니다.

"잘 되지 않는다"의 3가지 오독

실패를 판정하기 전에, 무엇을 보고 있는가를 의심해야 합니다. 현장에서 빈번하게 발생하는 3가지 오독을 차례대로 해결하겠습니다.

오독 1: 속도의 착각

"AI 덕분에 개발이 빨라졌다"고 느낄 때, 그 "속도"는 정말로 실측되고 있습니까? METR가 2025년 7월에 공개한 RCT(무작위 대조 시험)는 경험이 풍부한 OSS 개발자 16명을 대상으로, AI 사용 시와 비사용 시의 태스크 완료 시간을 비교했습니다[1:1].

• 개발자가 사전에 예상한 단축률: −24% (AI로 빨라질 것이라 예상)
• 실측된 변화: +19% (실제로는 느려졌다)
• 태스크 완료 후의 사후 지각: −20% (끝난 후에도 "빨라졌다"고 느끼고 있음)
• 사후 지각과 실측의 차이: 39 포인트

즉, 느려지고 있는데도 "빨라졌다"고 느끼고 있는 상태가 데이터로 나타났습니다. METR는 2026년 2월 속보에서 "자기 선택 편향 (Self-selection bias, 30~50%의 태스크에서 개발자가 AI 이용을 거절함)과 재현 어려움"을 이유로 결과의 정확도를 "very weak evidence"로 낮추었습니다[2]. 다만 "지각과 실측이 어긋난다"는 핵심은 재현 연구 측에서도 부정되지 않았습니다.

여기서 작용하는 심리학 개념이 **더닝-크루거 효과 (Dunning-Kruger effect)**입니다. Kruger와 Dunning이 1999년에 발표한 고전적 연구는 능력이 낮은 영역에서 사람은 자신의 무능을 인식하지 못한다는 것을 보여주었습니다[3]. 참고로 이 효과는 2022년 Frontiers의 논문에서 "회귀 평균에 의한 아티팩트 (artifact)\

PR 수가 늘어났다, 커밋 수가 늘어났다, 코드 라인 수가 늘어났다. 이것들을 「성과」라고 부르기 위해서는 한 단계 더 높은 검증이 필요합니다.

개발자 생산성 플랫폼인 Faros AI가 2025년 7월에 공개한 「AI Productivity Paradox」 리포트(1,255개 팀, 10,000명 이상의 개발자 대상)에서는, AI 도입 후 다음과 같은 현상이 관찰되었습니다[5].

지표	변화	해석
머지(Merge)된 PR 수	+98%	양은 늘어났다
...

여기서 일어나고 있는 것은 **Goodhart의 법칙 (Goodhart's Law)**의 전형적인 사례입니다. Charles Goodhart가 1975년에 금융 정책의 맥락에서 제시하고, Marilyn Strathern이 1997년에 "When a measure becomes a target, it ceases to be a good measure (지표가 목표가 되는 순간, 그것은 더 이상 좋은 지표가 아니다)"라고 정형화한 경험칙입니다[6]. PR 수를 「생산성 지표」로 목표화하는 순간, 개발자와 AI의 협업은 해당 지표를 최대화하는 방향으로 최적화됩니다. 1 PR당 인지 부하(Cognitive Load)가 늘어나고, 리뷰 부하가 늘어나며, 가치 창출은 다른 지표로 측정하지 않으면 보이지 않게 됩니다.

조직 병목 현상의 이동과 측정 축의 전환에 대해서는 별도의 기사에서 상세히 다루고 있습니다. 본 기사에서는 「양만을 관측하는 것은 오독이다」라는 점만 기억해 주십시오.

오독 3: 만족도의 착각

「개발자가 AI를 마음에 들어 한다」, 「사용해 보니 호평이다」라는 내용도 그 자체만으로는 실패 판정의 근거가 될 수 없습니다. SPACE 프레임워크[7]의 원저자(Forsgren, Storey, Maddila 등)는 5개 축(Satisfaction / Performance / Activity / Communication / Efficiency) 중 Activity 단독으로 측정하는 것이 가장 위험하다고 경고합니다. Satisfaction 단독 측정도 마찬가지입니다. 최소 3개의 축을 조합해야 비로소 의미를 갖습니다.

Anthropic이 2026년에 공개한 학습자 대상 연구에서는, AI를 능동적으로 활용하는 그룹(수정·검증을 동반함)과 통째로 맡겨버리는 그룹 사이에서 사후 테스트 점수 차이가 **Cohen's d=0.738 (중~대 효과 크기, p=0.010)**로 관찰되었습니다[8]. 이는 만족도가 높은 그룹이라 할지라도, 능동성이 낮으면 성과가 나오지 않는다는 것을 시사합니다.

만족도는 오너십(Ownership)·능동성·성장감을 통합한 결과로서는 유의미하지만, 단기적으로 높은 점수를 얻도록 설계하기 쉽다는 함정이 있습니다. 벤더(Vendor)가 만족도를 높이는 UX 설계에 최우선 순위를 두는 경제적 합리성도 존재합니다.

감별 진단이라는 발상 — 의료 진단학으로부터의 유추

여기서 잠시 의료 세계로 시점을 옮겨보겠습니다. 의사는 환자의 주소(Chief Complaint, 증상 호소)를 듣는 즉시 투약을 시작할까요? 그렇지 않습니다. 「가슴이 아프다」라는 동일한 주소로부터 의사는 심근경색, 폐색전증, 대동맥 박리, 역류성 식도염, 대상포진, 근골격계 통증 등 여러 후보를 머릿속에 나열합니다. 이를 **감별 진단 (Differential Diagnosis)**이라고 부릅니다[9].

감별 진단의 프로세스는 4단계로 정리할 수 있습니다.

• 증상 관찰: 주소와 소견을 다각적으로 수집한다.
• 후보 리스트 작성: 증상으로부터 생각할 수 있는 원인을 망라적으로 열거한다.
• 검증 검사: 각 후보에 대해 관측 가능한 지표(혈액 검사, 영상 등)로 좁혀 나간다.
• 확정 진단과 개입: 1~2개의 후보로 압축한 뒤 치료 방침을 결정한다.

소프트웨어 개발 세계에서 이 프로세스를 응용한 것이, SRE 업계에서는 Dan Slimmon이 블로그에서 논하고 있는 「인시던트 발생 시의 감별 진단」입니다[10]. 본 기사는 이를 AI 주도 개발의 실패 진단으로 확장합니다.

5 Whys가 단독으로 위험한 이유

「왜를 5번 반복하는」 선형 RCA, 이른바 5 Whys는 Taiichi Ohno가 도요타 생산 방식에서 확립한 기법입니다[11]. 제조업 현장에서는 강력하며 지금도 유효한 도구입니다. 하지만 복잡계(여러 독립적인 원인이 시차를 두고 겹치는 계)에서는 단독 운용이 위험합니다.

• Toyota 스스로가 「개별 사안용」으로 한정: Minoura 등은 사내 문서에서 "QC 스토리의 일부이며, 시스템적인 원인 분석에는 별도의 기법을 병용할 것"이라고 주의를 환기하고 있습니다[12]
• Sidney Dekker의 비판: 복잡계(Complex Systems)에서는 "근본 원인"이 하나로 수렴되지 않으며, 마지막에 답에 도달한 사람의 인지 편향 (Cognitive Bias)을 반영할 뿐이라고 지적합니다[13]
• John Allspaw의 비판: 전 Etsy CTO인 Allspaw는 소프트웨어 사고 분석의 맥락에서 "왜(Why)를 물을수록, 편리한 가설로 수렴해 버린다"며 "Infinite Hows"를 제창했습니다[14]

5 Whys를 전면 부정할 필요는 없습니다. 오히려 "증상 → 즉시 5 Whys"는 감별 진단의 단계 2(후보 리스트 작성)를 건너뛰는 행위이며, AI 주도 개발의 실패 진단에서는 피해야 할 입구라고 다시 정의해야 합니다.

더블 루프 학습과의 연결

Chris Argyris와 Donald Schön은 1970년대에 **싱글 루프 학습 (Single-loop Learning) vs 더블 루프 학습 (Double-loop Learning)**을 제창했습니다[15].

• 싱글 루프: "PR 수가 줄었다 → AI 사용법을 바꾼다"와 같이, 목표를 주어진 것으로 보고 수단을 수정함
• 더블 루프: "애초에 PR 수를 성과 지표로 삼아도 되는가?"와 같이, 목표 그 자체를 다시 질문함

"잘 되지 않는다"는 진단은 종종 더블 루프의 질문을 요구합니다. "실패란 이 수치가 낮아지는 것인가?"를 다시 묻지 않는 한, 오독의 함정에서 벗어날 수 없습니다.

증상의 층 × 원인의 층 — 이축 진단 모델

여기서부터가 본 기사의 핵심입니다. AI 주도 개발의 실패를 진단하기 위해, 증상을 4개 층, 원인을 4개 층으로 나누어 이축(Two-axis)으로 생각합니다.

증상의 층

층	관측 대상	관측 지표 예시	주의 사항
개인 감각층	속도·만족도·주관적 평가	설문 조사·체감 속도	단독으로는 오독률 최고
...

CodeRabbit의 리포트에 따르면, AI 생성 PR은 인간 생성 PR과 비교하여 1 PR당 문제 수가 1.7배, XSS 취약성이 2.74배 관찰되었습니다[16]. GitClear가 211M 행(2.1억 행)을 분석한 리포트에서는, 복사-붙여넣기(Copy-paste) 코드 비율이 8.3%에서 12.3%로, 리팩터링(Refactoring) 비율이 25%에서 10% 미만으로 변했다는 관측치도 나왔습니다[17].

이것들은 모두 벤더(Vendor) 발표 수치이며 독립적인 검증은 존재하지 않기 때문에, 본문의 각 인용 부분과 각주에서 그 취지를 명시하고 있습니다 (이하, 본 기사의 벤더 데이터는 동일하게 취급함).

DORA 2024에서는 "AI 채택이 25% 증가하면, 딜리버리(Delivery)의 안정성이 7.2% 저하된다"는 상관 데이터가 보고되었습니다[18]. DORA 2025에서는 모집단 약 5,000명, AI 사용률 90%의 조사에서 "The Great Amplifier (AI는 기존의 조직 역학을 증폭한다)"라는 메시지와 7가지 조직 아키타입(Archetype)이 제시되었습니다[19].

원인의 층

층	무엇이 원인인가	주요 개입 권한 보유자	관련 기존 기사
인터랙션 양식층	프롬프트 설계·CLAUDE.md·능동 vs 수동	개발자 본인 / 테크 리드	mismatch-personas
...

Edmondson의 1999년 논문 이후, 심리적 안전성(Psychological Safety)은 조직 퍼포먼스의 기반으로 다뤄져 왔습니다[20]. AI 주도 개발에서는 이것이 새로운 형태로 흔들립니다. "AI에게 쓰게 했다"라고 공언하는 것에 대한 주저함이나, "내가 썼다"라고 표명하는 것에 대한 압박감 감소가 오너십(Ownership) 희박화를 낳는 사례가 보고되고 있습니다.

이축 매트릭스의 읽는 법

증상의 층과 원인의 층은 다대다 (Many-to-Many) 관계에 있습니다. 동일한 증상(예: 운영 장애 미세 증가)이 여러 가지 서로 다른 원인 층에서 발생할 수 있기 때문입니다.

• 운영 장애 미세 증가 + 개인 감각층은 양호 → 코드 품질층의 문제인가, 리뷰 WIP 층의 문제인가, 혹은 둘 다인가
• 리드 타임(Lead Time) 보합 + PR 수 2배 → 제약·WIP 층(리뷰 정체)이 가장 유력한 후보
• 개발자 만족도 높음 + 리텐션(Retention) 악화 → 팀 심리층(오너십)인가 조직 아키타입층인가

이 맵 위에서 진단하기 때문에, "도구 탓", "개인 탓", "프로세스 탓"이라는 단선적인 사고에서 벗어날 수 있습니다.

앞서 언급한 증상들을 여기서 다시 한번 이 두 축에 배치해 보겠습니다. "PR 2배"는 증상의 팀 전달층 (Team Delivery Layer) 활동 지표이며, "리드 타임(Lead Time) 정체"는 팀 전달층의 결과 지표입니다. 두 지표의 괴리가 시사하는 바는 원인의 **제약·WIP 층 (Constraint/WIP Layer)**의 혼잡입니다. "시니어의 피로"는 증상의 **개인 감각층 (Individual Perception Layer)**이며, 원인은 **팀 심리층 (Team Psychology Layer, 책임의 편중)**과 **조직 아키타입층 (Organizational Archetype Layer, 평가 제도의 왜곡)**의 중첩으로 해석할 수 있습니다. "경영진의 질문"은 조직 아웃컴(Outcome) 층의 지표가 아직 측정 축에 올라오지 않은 상태임을 나타냅니다.

이러한 재진단을 거치고도 원인의 층을 하나로 좁힐 수 없는 경우가 대부분입니다. 그것이 올바른 상태이며, 오히려 하나로 좁혀졌다고 느낄 때야말로 오진을 의심해야 할 순간입니다.

오진의 3가지 패턴 — 실례를 통해 배우는 "원인의 층을 잘못 짚는 경우"

이론만으로는 부족하기 때문에, 공개된 3가지 사례를 차례대로 살펴보겠습니다. 모든 사례의 1차 정보 URL은 각주에 기재합니다.

오진 1: 모델 성능 저하라고 생각했으나, 3가지 독립적인 변경 사항이 시차를 두고 겹쳐 있었던 경우

2026년 4월, Claude Code 사용자들로부터 "모델의 품질이 떨어졌다"라는 보고가 늘어났습니다. Anthropic은 4월 23일 공개된 포스트모템(Post-mortem)에서 다음과 같이 설명했습니다 [21].

• 보고된 증상: "이전보다 머리가 나빠졌다", "코드 품질이 저하되었다"라는 주관적 평가의 급증
• 당초 의심했던 원인: 모델 본체의 교체 또는 내부적인 양자화 (Quantization)
• 실제 원인:
  2026년 3~4월에 걸쳐 단계적으로 전개된 3가지 독립적인 변경 사항이 시차를 두고 겹쳐 있었음
  • reasoning effort 파라미터의 내부 기본값 변경
  • 프롬프트 캐싱 (Prompt Caching) 층의 버그
  • 출력 장황함 (Verbosity) 조정

이는 **증상의 층 (개인 감각 + 코드 품질) → 원인의 층 (인터랙션 양식 + 도구 내부)**을 1:1로 결합해 버리는 전형적인 오진 패턴입니다. "모델이 저하되었다"라는 단일 원인 가설에 매몰되면, 사용자 측에서 할 수 있는 대처는 "타사 도구로 갈아타는 것"밖에 남지 않습니다. 실제로는 사용자 측의 프롬프트 설계나 CLAUDE.md 구성에 문제가 있는 케이스와, 벤더 측의 독립적인 변경 사항이 겹치는 케이스를 구분하지 못한 채 "도구가 나쁘다"라고 귀인(Attribution)되기 쉽습니다.

교훈: "도구가 나쁘다"라고 결론 내리기 전에, 사용자 측 / 벤더 측에서 무엇이 동시에 변했는지를 나열하십시오. 동시성에 대한 확인 없이는 원인 층을 특정할 수 없습니다.

오진 2: "잘 되고 있다"고 생각했으나, 단순한(naive) 예측기에 패배한 경우

2026년 5월, Zenn에 다음과 같은 글이 공개되었습니다 [22]. 귤의 수확량 예측 모델을 AI로 구현했더니, **MAPE (평균 절대 퍼센트 오차) 12.5%**를 달성했습니다. "성공했다"라고 판단하려던 단계에서, 만약을 위해 베이스라인(평균값만을 반환하는 naive 예측기)과 비교해 본 결과, naive 예측기가 **MAPE 9.3%**로 더 우수했다는 사례입니다.

이는 전형적인 베이스라인 부재로 인한 오독으로, 머신러닝 영역에서는 고전적인 실수이지만 AI 코딩 문맥에서도 빈번하게 발생합니다.

• "AI가 작성한 코드의 테스트 통과율 95%": AI 없는 템플릿 생성으로도 통과율이 92%일 수 있음
• "AI 리뷰어 도입으로 문제 탐지율 향상": 단순 정적 분석(Static Analysis)의 정밀도 향상이 동시기에 있었을 가능성
• "AI 보조 번역 품질이 높음": 기존 번역 메모리(Translation Memory)로도 충분했을 가능성

시니어 엔지니어로서 경험을 쌓을수록 절감하게 되는 것은, AI가 없는 베이스라인을 병렬로 측정하는 것의 중요성입니다. 비교 대상을 사전에 고정해 두지 않으면, "잘 되고 있다"도 "잘 안 되고 있다"도 판정할 수 없는 채 시간만 흘러가게 됩니다.

오진 3: "쓸모없다"고 판단하여 철수했으나, 원인은 다른 층에 있었던 경우

이 패턴은 공개된 사례가 놀라울 정도로 적다는 사실 그 자체가 중요합니다. 철수한 팀은 철수 관련 글을 쓰지 않습니다. 글을 쓸 동기를 가진 것은 남아서 싸우고 있는 팀 혹은 철수를 권하는 벤더에 한정됩니다. 이는 선택 편향(Selection Bias)으로서 무시할 수 없는 구조이며, 본 기사의 한계 중 하나이기도 합니다.

그럼에도 방증은 수집할 수 있습니다. 150,000행의 AI 생성 코드를 작성한 후 시니어 개발자가 AI 사용을 중단했다는 기사는, 도구가 아니라 리뷰 문화와 설계 판단의 문제에 대부분을 할애하고 있습니다[23].

또한, 한층 더 극단적인 사례로 Replit / SaaStr의 운영 DB 삭제 사고[24]나 PocketOS의 Cursor-Opus 연동에서의 9초 DB 삭제 사고[25]가 있습니다. 이것들은 흔히 "도구가 폭주했다"라고 귀속되기 쉽지만, 원인의 층(Layer)을 정밀 조사하면,

• 권한 분리의 미비 (조직 아키타입 층)
• 확인 프롬프트 스킵 (인터랙션 양식 층)
• 운영 / 스테이징 환경의 혼재 (운영 층)

등, 도구 단독이 아닌 복합 원인이 떠오릅니다.

교훈: "도구를 사용할 수 없다"를 결론으로 내리기 전에, 인터랙션 설계 · 권한 설계 · 운영 환경의 3개 층을 각각 독립적으로 검사하십시오. 이를 건너뛰고 철수하는 것은 다른 조직에서 똑같은 함정에 빠지는 결과로 이어지기 쉽습니다.

진단 프로토콜 — 실행 가능한 4단계

지금까지의 논의를 내일부터 바로 사용할 수 있는 절차로 바꿉니다. 최소 구현은 스프레드시트 + EM(Engineering Manager) + 개발자 대표 + 제3자 퍼실리테이터(사외 멘토 등)의 3명이면 충분히 운영 가능합니다. 50명을 넘는 규모에서는 Faros AI / Jellyfish / LinearB 등의 생산성 플랫폼을 병용하는 선택지가 생기지만, 그것은 "진단의 정밀도"와 "측정 피로 리스크"를 저울질하는 판단입니다.

Step 1: 증상을 SPACE의 최소 3개 축으로 관측

SPACE 프레임워크의 5개 축(Satisfaction / Performance / Activity / Communication / Efficiency) 중, 최소 3개 축을 조합하여 관측합니다. 원저자(Forsgren 등)가 ACM Queue 2021에서 명시한 경고입니다[7:1].

해도 좋은 조합	해서는 안 되는 조합
Satisfaction + Performance + Activity	Activity 단독 (PR 수만 측정)
...	...

DX Core 4(Speed / Effectiveness / Quality / Business Impact)도 유사한 다축 사고방식을 가지고 있어 보조적으로 병용할 수 있습니다[26]. 단, DX Core 4는 제창처(DX 사)의 벤더 프레임워크이므로, 자사 보고 수치를 인용하는 것은 피하고 프레임워크 차용에만 그칩니다.

Step 2: 후보가 되는 원인 층을 3개 이상 열거

감별 진단의 Step 2입니다. 관측된 증상으로부터, 4개의 원인 층 중 최소 3개를 후보로 작성합니다.

예: 증상이 "PR 2배 증가 + 리드 타임 정체 + 시니어 피로"라면, 후보는

• 제약 · WIP 층: 리뷰 WIP가 늘어나 병목이 발생함
• 인터랙션 양식 층: PR 사이즈가 너무 커서 리뷰에 시간이 오래 걸림
• 팀 심리 층: 시니어가 "AI 코드의 리뷰 책임"을 혼자 짊어지고 있음
• 조직 아키타입 층: 평가 제도가 PR 수를 보고 있기 때문에 작위적으로 늘어나고 있음

여기서 주의할 점은, "도구가 원인"을 첫 번째 후보로 두지 않는 것입니다. 원인의 층별 모델에서 도구 고유의 문제는 인터랙션 양식 층에 종속됩니다.

Step 3: 각 후보에 대해 관측 가능한 지표와 임계값 결정

후보별로 Yes / No를 판정할 수 있는 검사를 설계합니다. 아래 표의 수치는 어디까지나 예시이며, 자 조직의 지난 6개월간의 분포로부터 캘리브레이션 (Calibration) 하여 사용하십시오. PR 사이즈 500행은 Google Engineering Practices의 200-300행에 비해 완만한 편이며, 조직의 언어 · 모노레포 구조에 따라 타당한 값이 크게 달라집니다.

후보	검사	임계값 예시 (캘리브레이션 필요)
리뷰 WIP 과잉	1인당 동시 리뷰 PR 수	3 이상이면 양성
...	...	...

이 프로세스는 굿하트의 법칙(Goodhart's Law)에서 벗어날 수 없습니다. 검사 자체가 목표가 되면 검사도 퇴화합니다. 검사 세트를 정기적으로 교체하는 것이 현실적인 대처입니다.

Step 4: 확정 진단과 개입 — 기존 기사로의 송객 맵

검사로 1~2개의 원인층(cause layer)을 좁힐 수 있다면, 여기서 비로소 개입책을 결정합니다. 본 기사의 역할은 여기까지이며, 구체적인 개입책은 기존 기사로 송객(referral) 합니다.

확정된 원인층	읽어야 할 기존 기사
인터랙션 양식층 (개인 특성이 큼)	Claude Code 미스매치 5 페르소나
...

이와 같이, 본 기사를 출발점으로 하여 진단 결과에 따른 처방전 기사를 읽으러 가는 구조로 되어 있습니다.

운용 빈도: 분기별 + 이벤트 발화형 권장

진단 프로토콜을 매월 돌리면 측정 피로가 발생합니다. 분기 1회 정기 진단 + 중대 인시던트(incident) 발화 시 임시 진단의 조합이 현실적인 해답입니다. 철수 판단, 조직 개편, 대규모 툴 도입을 앞두고 있을 때는 정기 진단의 틀 안에서 앞당겨 실시합니다.

또한, 철수 판단 그 자체의 문서화(철수 범위·증상·감별 원인층·개입 시도 이력·대안·재도입 조건의 6개 항목)는 본 기사의 스코프(scope) 외이며, 별도의 기사에서 다룹니다. "잘 되지 않는 것"을 진단하는 것까지가 본 기사의 영역입니다.

진단의 한계 — "잘 되지 않는 것"을 완전히 판정할 수는 없다

지금까지 일정한 진단 프로세스를 제시했지만, 그 전체는 다음과 같은 한계를 안고 있습니다. 솔직하게 공개합니다.

철수자는 기사를 쓰지 않는다

"AI를 철수했다"는 사례의 공개 데이터는 극도로 적습니다. 철수자는 자사의 판단을 공개할 동기가 부족하며, 기사를 쓰는 쪽은 남아 있는 팀이거나 철수를 권하는 벤더(vendor)에 편중됩니다. 이러한 선택 편향(selection bias)은 본 기사의 사례 섹션에서도 완전히 극복하지 못했습니다. "철수하지 않아서 다행이다"와 "철수해서 다행이다"의 비율을 공개 데이터로부터 추정하는 것은 불가능에 가깝다고 생각하십시오.

METR의 모집단 편향

지각 vs 실측의 39포인트 격차는 강력한 에비던스(evidence)이지만, n=16·OSS 숙련자라는 한정적인 조건하의 것입니다. 상용 개발·주니어 층·신규 프로젝트에서는 다른 결과가 나올 수 있다고 METR 스스로가 유보를 달고 있습니다. 후속 보고에서는 재현 불가능성도 지적되고 있습니다.

Dunning-Kruger 효과는 방법론적 비판을 받고 있다

1999년의 Kruger & Dunning 논문은 인용 횟수가 많은 고전이지만, 2022년 Frontiers의 논문에서 "효과의 대부분은 회귀 평균에 의한 아티팩트(artifact)"라는 방법론적 비판을 받았습니다. 본 기사에서는 "AI 사용 시 주관적 평가와 객관적 성과가 괴리될 수 있다" 정도의 약한 근거로 다루고 있습니다.

Goodhart의 법칙으로부터 벗어날 수 없다

검사 세트를 설계하는 이상, 검사 자체가 목표가 되는 운명을 가집니다. 완전히 Goodhart 저항성을 가진 측정은 존재하지 않습니다. 정기적인 교체와 다중 축의 조합을 통해 증상을 완화할 수 있을 뿐입니다.

복잡계에서는 원인이 하나로 수렴하지 않는다

Dekker가 지적하듯이, 복잡계(complex system)에서 "근본 원인"은 탐색 프로세스의 종점에서 구성되는 것이지, 객관적으로 동일시할 수 있는 단일 원인이 아닙니다. 본 기사의 이축 모델(two-axis model) 또한 원인을 "여러 층의 중첩"으로 표현하고 있는 이유가 바로 이것입니다. 하나로 좁히려고 시도하는 순간, 오진의 리스크가 급증합니다.

벤더 데이터의 독립 검증 불가능성

CodeRabbit·GitClear·Faros AI·DX Core 4의 데이터는 모두 벤더 발표치이며, 독립적인 검증은 존재하지 않습니다. 본 기사에서는 모든 벤더 수치에 "벤더 발표치"를 명시하였으며, 여러 벤더의 수치가 모순되는 경우에는 방향성만을 채택하고 있습니다.

귀속 회피가 어카운터빌리티(accountability) 희박화로 전이될 리스크

"툴 / 개인 / 프로세스 그 어디에도 귀속되지 않는다"라는 태도는 조직 내에서 "결국 누구의 잘못도 아니다"라는 알리바이로 전이되기 쉬운 구조를 가집니다. 본 기사의 이축 모델은 원인의 분산을 의도하지만, 진단 결과에 대한 의사 결정자와 설명 책임을 지는 사람은 반드시 지명해야 합니다. 원인 층별표의 "주요 개입 권한 보유자" 열은 이를 위한 최소한의 지침입니다.

측정 피로와 "그러니까 아무것도 하지 않겠다"는 핑계화

지속적인 관측은 **측정 피로 (measurement fatigue)**를 낳습니다. 분기별 진단 + 이벤트 발화형을 권장하는 이유가 바로 이것입니다. 동시에, 한계 공개가 "복잡계니까 아무것도 하지 않는다", "Goodhart의 함정이니 측정하지 않는다"라는 핑계로 전이되지 않도록, 진단은 불완전하지만 개입의 전제로서 필수적이라는 입장을 명시해 둡니다.

요약 — 실패를 판정하기 전에, 무엇을 보고 있는지 질문하라

서두의 두 가지 질문에 대해 여기서 최종적으로 답하겠습니다.

"잘 되지 않는다"는 것은 무엇을 의미하는가?

그것은 증상의 4개 층(개인적 감각 · 코드 품질 · 팀 전달 · 조직적 결과) 중, 여러 층에서 동시에 이상이 관측되는 상태입니다. 단 하나의 층에서만 나타나는 이상은 실패라고 판정할 수 없습니다. 개인적 감각 층만 나쁜 경우, 원인은 상호작용 양식 (Interaction Style) 층의 개선만으로 해결되는 경우가 많으며, 조직적 결과 층이 나쁘다면 경영 판단 수준의 개입이 필요합니다.

그 원인은 어디에 있는가?

원인은 4개 층(상호작용 양식 · 제약 / WIP · 팀 심리 · 조직 아키타입)의 **중첩 (Superposition)**으로서 존재합니다. 원인을 하나로 좁히려는 욕구는 오진의 신호입니다.

오늘부터 시작할 수 있는 체크리스트를 남깁니다.

• PR 수 · 커밋 수 · 코드 라인 수만으로 "성과"를 판정하고 있지는 않은가
• 개발자 만족도 설문조사를 단독으로 "성공"의 근거로 삼고 있지는 않은가
• SPACE 프레임워크의 최소 3개 축으로 관측하고 있는가
• "도구 탓" 혹은 "개인 탓"이라며 하나의 층으로 귀속시키고 있지는 않은가
• 철수 판단을 내리기 전에, 상호작용 설계 · 권한 설계 · 운영 환경을 독립적으로 검사했는가
• 평가하는 지표가 목표화되어 있지는 않은가 (Goodhart의 법칙)

진단 없이 개입하는 것은 증상을 보지 않고 약을 처방하는 의사와 다를 바 없습니다. AI 주도 개발이 "잘 되지 않는다"고 느껴질 때, 우선 관측과 감별 진단부터 시작하십시오.

참고로, 본 기사는 진단에서 완결됩니다. 진단 결과를 분기별 AI 이용 가이드라인 · 런북 (Runbook) · 승인 프로토콜 개정으로 반영하는 AI 거버넌스 정비는 별개의 문제이며, 다른 기사의 스코프(Scope)입니다. 본 기사의 역할은 그 입구 직전에 있는 "애초에 무엇이 일어나고 있는가"를 읽어내는 눈을 기르는 데 있습니다.

관련 기사