Greg Wilson의 'Twelve Ways to Be Wrong'을 깊이 읽는다. 왜 같은 도구가 +55%와 -19%라는 정반대 결과를 동시에 만들어내는가. 줄 수·커밋 수·수락률·도입률 — 우리가 매일 들이대는 잣대가 어떻게 우리를 속이고 있는지, 16편의 논문과 1984년 Goodhart 법칙까지 거슬러 올라가 풀어낸다.
다음 주 월요일, 매니저가 회의실로 당신을 부른다. 회사가 지난 분기에 도입한 AI 코딩 도구의 ROI를 증명하라고 한다. 구독료가 만만치 않다.
당신은 어떻게 답할 것인가?
매니저가 흡족한 표정을 짓는다. 보고서가 잘 통과될 것 같다.
그런데 이 네 가지 답변은 모두 다른 방식으로 틀렸다.
2026년 5월 20일, 소프트웨어 공학 교육의 거장이자 Software Carpentry의 창립자 Greg Wilson이 The Third Bit에 짧지만 무거운 글을 올렸다. 제목은 "Twelve Ways to Be Wrong About AI-Assisted Coding" — AI 코딩 측정에서 흔히 저지르는 12가지 방법론적 오류를 정리한 일종의 체크리스트다.
이 글은 단순한 비평이 아니다. Wilson 자신이 밝히듯, "이 비판들은 작은 수정만 거치면 애자일, 테스트 주도 개발 등 지난 20년간 우리가 떠들었던 거의 모든 소프트웨어 공학 관행에 적용할 수 있다." 소프트웨어 공학이 인접 학문(심리학, 사회학, 통계학)에게 측정 방법론을 배웠더라면 우리는 지금보다 훨씬 멀리 와 있었을 것이라는 자성의 글이기도 하다.
이 글에서는 Wilson의 12가지 항목을 하나씩 깊이 풀어내고, 각각이 어떤 논문·역사적 배경에서 나왔는지, 그리고 2026년 현재 한국·세계 기업이 어떤 함정에 빠져 있는지를 사례와 함께 살펴본다.
1883년 영국 물리학자 로드 켈빈(Lord Kelvin)은 글래스고에서 한 강연에서 이렇게 말했다.
"무엇이든 측정할 수 있다면 당신은 그것에 대해 무언가를 알고 있는 것이다. 측정할 수 없다면 당신의 지식은 빈약하고 만족스럽지 못한 것이다."
이 말은 한 세기 동안 경영학과 공학의 종교가 되었다. 피터 드러커의 "측정할 수 없으면 관리할 수 없다(What gets measured gets managed)"가 그 정점이다.
그런데 드러커는 이 말을 한 적이 없다. 출처를 추적한 학자들은 모두 빈손으로 돌아왔다(이는 Beck 2023에서도 지적된다). 진짜 드러커는 "중요한 모든 것이 측정될 수 있는 것은 아니며, 측정되는 모든 것이 중요한 것도 아니다"에 가까운 사람이었다.
소프트웨어 공학은 처음부터 이 인용 오류 위에 세워졌다.
핵심은 이것이다. 개발 생산성을 측정하려는 시도는 50년이 넘었고, 그 50년이 가르쳐준 유일한 교훈은 "단일 지표는 거짓말한다"는 사실이다.
2021년 6월 GitHub Copilot 베타가 공개되었다. 2022년 11월 ChatGPT가 세상을 흔들었고, 2023년 GitHub Copilot Chat이, 2024년 Cursor·Windsurf·Aider 같은 AI-IDE가, 그리고 2025년에는 Claude Code·Codex·Devin 같은 코딩 에이전트가 폭발적으로 등장했다.
각 회사가 자사 도구가 얼마나 대단한지 증명하려고 발표한 연구가 쏟아졌다. 그리고 거의 모두가 Wilson이 말하는 12가지 함정 중 하나에 빠져 있다.
빌 게이츠가 1990년대에 했다는 말이 있다. "줄 수로 프로그래머의 생산성을 측정하는 것은 무게로 비행기 제작 진척도를 측정하는 것과 같다." 이 말도 출처는 불분명하지만, 통찰은 정확하다.
LLM은 줄 수를 늘리는 데 천재적이다. 같은 일을 더 장황하게 쓰는 것이 그들의 본성이다. 그래서 AI 도구 도입 후 1인당 줄 수가 40% 늘었다는 보고를 받으면, 그것은 생산성 향상이 아니라 말 많아짐(verbosity)이 측정된 것이다.
앞서 본 Peng 2023의 55% 숫자가 바로 이 함정의 대표 사례다.
과제 조건을 보자:
| 요소 | 연구 환경 (Peng 2023) | 실제 개발 현실 |
|---|---|---|
| 코드베이스 | 없음 — 백지에서 시작 | 수년 묵은 100만 줄짜리 레거시 |
| 요구사항 | 명확한 사양서 1쪽 | 모호한 지라 티켓, 3명의 이해관계자 |
| 시간 | 90분 단일 작업 | 회의·리뷰·코드 읽기로 잘게 쪼개진 하루 |
| 외부 의존성 | 표준 라이브러리만 | 사내 SDK, 외부 API, 인증 시스템 |
| 정답 | 명확히 동작 vs 비동작 | "잘 되는 것 같은데..." |
90분짜리 백지 HTTP 서버에서 55% 빠른 도구가 — 1만 줄짜리 결제 모듈의 미묘한 race condition을 고치는 데에는 19% 느릴 수 있다. 두 가지 모두 진실이고, 둘 다 측정 가능하지만, 어느 것도 일반화할 수 없다.
1월에 Copilot을 도입하고 6월에 PR이 더 빨리 머지된다고 치자. 도구가 효과가 있는 것일까?
같은 5개월 동안 일어난 다른 일들:
이 모든 변화 중에서 Copilot의 효과만 따로 분리해낼 방법은 없다. 통계학에서 말하는 내적 타당성(internal validity)은 비교 가능한 통제군을 요구한다. "그게 없었더라면 어떻게 됐을까(counterfactual)"를 추정할 수 없는 비교는 인과 추론이 아니라 그저 이야기다.
"개발자의 87%가 AI 도구로 더 생산적이라고 응답했습니다." — 어딘가 들어본 문장
Liang et al. 2024 (ICSE)는 이 같은 자가 보고가 왜 체계적으로 오도(誤導)되는지를 정리했다. 세 가지 편향이 동시에 작동한다.
1924~1932년 미국 호손 공장 실험에서 발견. 사람은 관찰되고 있다는 사실 자체로 행동이 바뀐다. 설문에 답하는 순간 평소와 다른 자신을 떠올린다.
새 도구는 새롭다는 이유만으로 빠르게 느껴진다. 같은 도구를 6개월 쓰면 그 느낌은 사라진다. 4주짜리 설문은 4주짜리 신기함을 측정할 뿐이다.
회사가 비싸게 도입한 도구를 "별로 안 좋은데요"라고 답할 직원은 드물다. 익명이라고 안내해도 마찬가지다. 특히 관리자가 도구를 선택했다면 더욱.
Becker 2025: 개발자들은 자신이 24% 빨라졌다고 느꼈지만, 실제 측정에서는 19% 느려졌다. 43%포인트의 인식-실제 간극. 자가 보고는 이 정도로 신뢰할 수 없다.
2023년 7월, McKinsey가 한 보고서를 발표했다. 제목은 "Yes, You Can Measure Software Developer Productivity". 커밋 수, PR 수, 리뷰 수 같은 활동 지표로 개인 개발자의 생산성을 매길 수 있다고 주장했다.
소프트웨어 커뮤니티가 들고일어났다. Kent Beck(TDD의 창시자, Beck 2023)과 Gergely Orosz가 즉각 반박 글을 올렸다.
이유는 단 하나의 법칙으로 요약된다.
Goodhart의 법칙 (1984):
"측정이 목표가 되는 순간, 그것은 더 이상 좋은 측정이 아니다."
개발자들이 자신의 커밋 수가 추적된다는 것을 알면 어떤 일이 벌어지는가?
이것이 1984년에 영국 경제학자 Charles Goodhart가 영국 통화정책을 분석하며 발견한 패턴이다. 영국 정부가 통화량 지표 M3를 목표로 삼자, 시장은 M3에 잡히지 않는 통화로 옮겨갔다. 측정 가능한 모든 것은 결국 게임화된다.
코드 생성은 빠르고 측정하기 쉽다. 그러나 그 뒤에 따라오는 일들:
Pearce et al. 2022 (IEEE S&P)의 "Asleep at the Keyboard?"가 가장 유명하다. CWE Top 25(가장 위험한 25가지 소프트웨어 약점)를 유도하는 시나리오에서 Copilot에게 코드를 짜게 했더니, 89개 시나리오 중 40%가 취약한 코드를 만들었다. 더 무서운 발견은 — 시간 압박 하에 있는 개발자일수록 안전하지 않은 제안을 더 쉽게 받아들인다는 것이다.
Liu et al. 2026은 GitHub 공개 저장소에서 AI 작성 표시가 있는 커밋 30만 개 이상을 분석했다. 15% 이상이 최소 하나의 품질 이슈를 도입했고, 그중 거의 1/4이 코드베이스에 장기적으로 남았다. 측정에서 빠진 비용이 결국 누적된다.
"엔지니어링 전사에서 AI 도구 도입률 90%를 달성했습니다."
이것은 조달(procurement) 성과지 생산성 성과가 아니다. 도구를 설치하고 켰다는 것과, 그 제안이 유용하다는 것은 완전히 다른 명제다.
Weisz et al. 2025 (CHI'25)는 IBM의 사내 AI 코딩 어시스턴트를 1년간 추적했다. 결론은 "평균적으로는 생산성 향상이 있지만, 그 효과는 사용자 그룹마다 균일하지 않다"였다. 어떤 그룹에는 큰 도움, 어떤 그룹에는 효과 없음, 또 어떤 그룹에는 부담만 늘었다. 도입률 90%라는 단일 숫자는 이 분포를 완전히 가린다.
"Copilot을 자발적으로 쓰는 개발자들이 안 쓰는 개발자들보다 30% 생산성이 높다." — 산업계에서 가장 흔한 보고다.
문제는 두 집단이 처음부터 달랐다는 것이다. 신기술을 자발적으로 받아들이는 사람들은:
Stray et al. 2026 (HICSS-59)은 한 대형 IT 조직에서 Copilot 도입 전과 후 2년을 추적했다. "Copilot을 쓴 사람들은 도구가 도입되기 전부터 이미 다른 동료보다 활발했다." 이들이 Copilot 도입 후에도 활발한 것은 — 그들이 활발한 사람이었기 때문이지, Copilot 덕분이 아닐 수 있다.
이런 함정을 피하려면 무작위 통제 실험(RCT)이 필요하다. 이는 비싸고 어렵다. 그래서 산업 보고서는 거의 항상 자기 선택 편향을 피하지 못한다.
개인의 코딩 속도는 측정하기 가장 쉽다. 그래서 측정된다. 그런데 티켓에서 프로덕션까지의 시간(cycle time)이 변하지 않는다면, 개인 속도가 아니라 다른 곳이 병목이었다는 뜻이다.
코드 생성이 30% 빨라졌는데 코드 리뷰가 30% 더 걸리게 됐다면, 시스템 전체의 처리량은 그대로다. 오히려 분량이 많아진 PR을 리뷰해야 하는 시니어가 새로운 병목이 된다.
Xu et al. 2025는 이 효과를 정량화했다. 제목 자체가 강렬하다 — "AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden."
이것을 시스템 사고(systems thinking)의 실패라고 부른다. Theory of Constraints(엘리야후 골드랫, 1984)가 30년 넘게 가르쳐온 교훈 — 병목 외 어디를 최적화하든 처리량은 늘지 않는다 — 이 AI 도구 평가에서도 그대로다.
생산성을 제대로 보려면 DORA 4대 지표 같은 시스템 지표를 봐야 한다:
| DORA 지표 | 의미 | AI 도입 후 변화? |
|---|---|---|
| 배포 빈도 (Deployment Frequency) | 얼마나 자주 배포되는가 | 코드 생성 속도와 별개로 측정해야 |
| 변경 리드 타임 (Lead Time for Changes) | 커밋부터 프로덕션까지 시간 | 리뷰 병목으로 오히려 증가 가능 |
| MTTR (Mean Time to Restore) | 장애 복구 시간 | AI 생성 코드의 복잡도 증가가 영향 |
| 변경 실패율 (Change Failure Rate) | 배포 후 장애 발생률 | He 2026: Cursor 도입 후 증가 사례 보고 |
4주짜리 연구가 발견한 생산성 향상은 — 4주짜리 생산성 향상이다.
He et al. 2026 (MSR'26)이 Cursor AI IDE를 도입한 807개 오픈소스 저장소를 분석했다. 제목이 모든 것을 말해준다 — "Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity."
신기함 기간이 지나야 보이는 효과들:
GitHub Copilot은 자랑스럽게 발표한다: "개발자들이 우리 제안의 35%를 받아들입니다." 더 많이 받아들일수록 좋은 도구라는 인상을 준다.
그런데 수락은 "그럴듯해 보임"을 측정하는 것이지, "맞음"을 측정하지 않는다. 개발자가 Tab을 한 번 누른다는 것은:
Pearce 2022가 발견한 충격적인 부속 결과: 시간 압박 상태의 개발자는 보안에 취약한 제안조차 더 많이 받아들였다. 즉, 마감이 임박할수록 수락률이 올라가는데, 그 올라간 수락률은 그 도구가 더 좋아져서가 아니라 그저 덜 까다로워졌기 때문이다.
Bakal et al. 2025는 Zoominfo에서 400명의 개발자를 추적했다. 평균 수락률 33%, 만족도 높음. 그러나 — 받아들여진 코드의 정확성·보안성은 추적되지 않았다.
"좋아 보이도록 보상하는 지표는, 좋도록 보상하는 지표가 아니다."
마지막 함정은 가장 미묘하다. "AI 사용 vs 아무 도구도 안 씀"의 비교는 실제로는 존재하지 않는 시나리오를 측정한다.
AI 도구 없이 일하는 개발자도 다음을 쓴다:
진짜 비교 대상은 "AI 도구 vs 기존의 모든 보조 수단들의 합"이다. 그러나 이 비교가 거의 이루어지지 않는 이유는 — 그렇게 측정하면 AI의 추가 효과가 매우 작아지기 때문이다.
약한 베이스라인은 어떤 도구도 좋아 보이게 만든다.
이제 우리가 가진 도구상자를 들고, 산업계에서 가장 화제가 된 두 연구를 다시 보자.
| 항목 | 내용 | 어떤 함정과 닿는가 |
|---|---|---|
| 참가자 | 모집된 95명, 대부분 1~5년차 | 함정 8 (자기 선택 편향) |
| 과제 | JavaScript HTTP 서버, 90분 | 함정 2 (인공적 과제) |
| 비교군 | Copilot 사용 vs 미사용 | 함정 12 (약한 베이스라인) |
| 측정 지표 | 완료 시간 | 함정 6 (쉬운 절반만) |
| 결과 | 55.8% 시간 단축 | 함정 10 (단기 측정) |
이 연구가 잘못된 것은 아니다. 다만 측정한 것이 무엇인지를 정확히 이해해야 한다. "초보~중급 개발자가 익숙한 언어로 명확한 사양의 백지 과제를 90분 내에 끝낼 때, AI 자동완성이 도움이 된다." 이 명제는 참이다. 이것을 "AI는 개발자를 55% 더 생산적으로 만든다"로 일반화하는 순간, 진실은 영업 자료가 된다.
| 항목 | 내용 | 어떻게 함정을 피했나 |
|---|---|---|
| 참가자 | 평균 5년+ 경력 OSS 메인테이너 16명 | 진짜 시니어를 대상으로 함 |
| 과제 | 자기 자신의 프로젝트의 실제 이슈 246개 | 함정 2를 정면 해결 (실제 코드베이스) |
| 비교군 | 무작위로 issue별 AI 허용/금지 배정 | 같은 개발자, 같은 프로젝트, 다른 조건 |
| 측정 | 시간, AI 사용 시간, 자체 평가 | 인식과 실제를 동시에 측정 |
| 결과 | AI 사용 시 19% 더 느림. 그러나 본인은 24% 빨라졌다고 느낌 | 함정 4를 직접 폭로 |
METR 연구는 거의 모든 함정을 의식적으로 피한 설계다. 그래서 결과는 "AI는 도움이 안 된다"가 아니라 — "베테랑 개발자가 자기 코드베이스에서 일할 때, 현재 세대 AI 도구는 도움보다 부담이 더 크다"이다.
두 연구는 모두 진실이다. 다른 모집단, 다른 과제, 다른 컨텍스트.
2026년 현재 한국의 많은 IT 조직이 AI 코딩 도구 도입 ROI를 보고해야 하는 상황에 있다. 이 보고서들에서 가장 흔히 발견되는 패턴:
Wilson이 글의 머리말에서 던진 핵심 메시지는 이것이다.
"소프트웨어 공학이 인접 인간 과학(심리학, 사회학, 통계학)에게 이런 종류의 것들을 어떻게 연구하는지 배웠더라면, 우리는 지금보다 훨씬 멀리 와 있을 것이다."
다음은 그가 명시적으로 추천하지는 않았지만, 그의 12가지 함정을 피하기 위해 필요한 진짜 방법론들이다.
개발자가 자신의 일·도구·환경에 만족하는가. 단순한 "더 빠르나요?"가 아닌, 번아웃·웰빙까지 포함
실제 산출물의 품질과 영향력. 코드가 의도한 결과를 달성했는가, 안정적인가
커밋·PR 같은 활동 지표. 오직 이것만 보지 않을 것을 명시함
팀 협업, 코드 리뷰, 지식 공유의 건강함
흐름 상태(flow), 중단의 빈도, 컨텍스트 스위칭 비용
SPACE의 핵심 원칙: 한 차원만 보지 말 것. 활동(A)이 늘었는데 만족(S)이 떨어지고 효율(E)이 나빠졌다면, 그것은 좋은 변화가 아니다.
개인이 아닌 전달 파이프라인을 본다.
AI 도입 전후가 아니라 — AI 도입 그룹 vs 동일 시점의 비도입 그룹을 동시에 본다.
| 함정 | 빌려와야 할 방법 | 인접 학문 |
|---|---|---|
| 자가 보고 편향 | 행동 데이터와 자기 보고의 동시 측정 | 심리학, 행동경제학 |
| 자기 선택 편향 | 무작위 통제 실험 (RCT) | 의학, 농학 |
| 호손 효과 | 블라인드 설계, 자연 실험 | 사회심리학 |
| Goodhart 효과 | 다중 지표, 메타 측정 | 통화경제학 |
| 신기함 효과 | 종단(longitudinal) 연구, 6~12개월 추적 | 발달심리학 |
| 컨텍스트 의존성 | 표본의 다양성, 외적 타당성 사전 검증 | 통계학, 역학 |
이것이 Wilson이 글 말미에 "원하면 1일짜리 연구 방법론 교육 워크숍을 연결해주겠다"고 적은 이유다. 소프트웨어 공학 커뮤니티는 이런 방법론을 거의 가르치지 않는다.
2026년 5월 현재의 풍경:
Wilson의 글이 던지는 가장 깊은 질문은 — "우리는 무엇을 좋은 소프트웨어 개발이라고 부를 것인가?"다.
만약 좋은 개발이 "빠르게 더 많은 코드를 짜는 것"이라면, AI 도구는 명백한 승리다. 만약 좋은 개발이 "적절한 시기에 적절한 문제를 정의하고, 미래 6년 동안 유지보수할 수 있는 시스템을 만드는 것"이라면, 답은 훨씬 복잡하다.
스스로의 AI 도구 평가 보고서를 체크리스트로 점검해보자.
| # | 함정 | 핵심 문제 | 해독제 |
|---|---|---|---|
| 1 | 코드 줄 수 | 장황함 ≠ 생산성 | 가치 전달 지표 |
| 2 | 인공적 과제 타이밍 | 백지 과제 ≠ 현실 | 실제 코드베이스 RCT |
| 3 | 통제군 없는 전·후 | 다른 변수와 혼동 | 동시 통제군 |
| 4 | "더 생산적이냐" 설문 | 호손·신기함·바람직성 편향 | 행동+자가보고 병행 |
| 5 | 커밋·PR·티켓 수 | Goodhart의 법칙 | 다중 지표, 메타 측정 |
| 6 | 쉬운 절반만 측정 | 리뷰·보안·부채 누락 | 전체 수명주기 비용 |
| 7 | 도입률을 성과로 | 설치 ≠ 유용 | 실제 이익 분포 |
| 8 | 자원자 vs 비자원자 | 자기 선택 편향 | 무작위 배정 |
| 9 | 개인만 측정 | 시스템 병목 무시 | DORA, 파이프라인 |
| 10 | 신기함 기간 측정 | 4주 효과의 환상 | 6~12개월 종단 |
| 11 | 수락률 = 품질 | 그럴듯함 ≠ 옳음 | 정확성·보안 사후 추적 |
| 12 | 아무것도 안 함과 비교 | 약한 베이스라인 | 현실적 대안과 비교 |
이 글은 AI 코딩 도구를 비난하는 글이 아니다. Wilson 자신도 머리말에 명시한다 — "이 글은 AI에 관한 것이 아니라, 사람들이 AI를 어떻게 평가하는지에 관한 것이다."
AI 코딩 도구는 진짜로 어떤 일에는 강력하다. 어떤 사람에게는 인생을 바꿀 만큼. 그러나 어떤 일, 어떤 사람, 어떤 조건에서 그러한지를 정확히 알기 위해서는 — 잘못된 잣대 12개를 먼저 내려놓아야 한다.
피터 드러커가 진짜로 한 말은 — "가장 위험한 것은 잘못된 답을 가진 채 일하는 것이 아니라, 잘못된 질문을 가진 채 일하는 것이다."
2026년 우리가 던져야 할 질문은 "AI는 우리를 X% 더 빠르게 만들었는가?"가 아니다. "AI는 우리가 만드는 시스템과, 그 시스템을 만드는 사람들을 어떻게 바꾸고 있는가?"다.
이 글의 모든 인용은 원문 "Twelve Ways to Be Wrong About AI-Assisted Coding" (Greg Wilson, The Third Bit, 2026-05-20)의 참고문헌에서 가져왔다. Greg Wilson은 Software Carpentry의 창립자이자 Beautiful Code, Teaching Tech Together 등의 저자로, 소프트웨어 공학 교육과 연구 방법론에 평생을 바쳐온 학자다.
