# AI 보조 코딩에 대해 틀리는 열두 가지 방식 > Clean Markdown view of GeekNews topic #29745. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29745](https://news.hada.io/topic?id=29745) - GeekNews Markdown: [https://news.hada.io/topic/29745.md](https://news.hada.io/topic/29745.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-22T09:20:48+09:00 - Updated: 2026-05-22T09:20:48+09:00 - Original source: [third-bit.com](https://third-bit.com/2026/05/20/twelve-ways-to-be-wrong/) - Points: 11 - Comments: 1 ## Topic Body - **AI 보조 코딩**의 가치는 코드 줄 수, 티켓 수, 만족도 같은 쉬운 숫자로 환원하기 어렵고, 평가 방식에 따라 결론이 왜곡될 수 있음 - **코드 줄 수**와 커밋·Pull Request·티켓 수는 활동량을 재는 값일 뿐이며, 목표가 되는 순간 쉽게 조작되고 품질을 가리지 못함 - **수락률**과 도입률은 제안이 그럴듯했거나 도구가 배포됐다는 신호일 뿐, 정확성·보안성·유지보수성을 보장하지 않음 - 장난감 과제, 통제군 없는 전후 비교, 자발적 사용자 비교, **약한 기준선**은 LLM 효과와 선택 편향을 분리하기 어렵게 만듦 - 생산성 판단에는 리뷰·디버깅·보안·기술 부채·팀 병목·장기 변화를 포함한 **시스템 수준 지표**가 필요함 --- ### 평가 대상과 전제 - **AI 보조 코딩 도구**의 구독 비용 대비 가치를 입증하려 할 때 생성 코드 줄 수, 완료 티켓 수, 개발자 만족도 설문은 각각 다른 방식으로 잘못된 결론을 만들 수 있음 - 핵심 쟁점은 **LLM 보조 코딩의 가치 자체**가 아니라, 그 효과를 평가하는 방식이 얼마나 쉽게 빗나갈 수 있는지에 있음 - 같은 비판은 애자일 개발, 테스트 주도 개발, 다른 소프트웨어 개발 관행에 대한 주장에도 약간만 바꿔 적용 가능함 - 소프트웨어 엔지니어링이 인간과학 분야의 연구 방법을 제대로 받아들였다면 이런 현상 연구에서 훨씬 앞서 있었을 것이라는 결론으로 이어짐 ### 잘못된 생산성 지표 - ## 생성된 코드 줄 수 세기 - **코드 줄 수**는 직접 측정하기 어려운 생산성을 대신하는 대리 지표로 오래전부터 쓰여 왔음 - LLM은 더 많은 코드를 만들 수 있지만, 더 나은 결과를 보장하지는 않음 - LLM 도입 뒤 개발자당 코드 줄 수가 40% 늘어난 팀은 생산성이 아니라 **장황함**을 측정했을 수 있음 - 뒤엉킨 로직 2000줄을 깔끔한 200줄로 대체하는 개선은 코드 줄 수 지표에서는 손실처럼 보임 - 더 많은 코드는 읽고, 유지보수하고, 디버깅해야 할 양을 늘리며, AI가 남기는 미래 부담은 줄 수 계산에 드러나지 않음 - ## 커밋, Pull Request, 티켓 세기 - 2023년 McKinsey는 커밋, Pull Request, 코드 리뷰 같은 활동 수로 개인 개발자 생산성을 측정하는 방식을 제안함 - **Goodhart의 법칙**처럼 측정값이 목표가 되면 더 이상 좋은 측정값으로 작동하지 않음 - 커밋 수가 추적되면 개발자는 더 작고 더 많은 커밋을 만들고, 티켓 수가 추적되면 티켓이 쪼개짐 - 숫자는 좋아져도 기반이 되는 작업은 개선되지 않을 수 있음 - 활동은 산출물이 아니며, 산출물도 곧바로 가치가 되지는 않음 - ## 제안 수락률을 품질 신호로 보기 - LLM 코딩 어시스턴트의 높은 제안 수락률은 도구가 유용하다는 근거로 제시되곤 함 - **수락률**은 생성 코드가 개발자가 Tab을 누를 만큼 그럴듯해 보였는지를 잴 뿐, 정확성·보안성·유지보수성을 재지 않음 - 시간 압박을 받는 개발자는 더 많은 제안을 수락하며, 그 안에는 안전하지 않은 제안도 섞여 있음 - 400명의 개발자를 대상으로 한 기업 연구는 평균 수락률 33%와 높은 개발자 만족도를 확인했지만, 수락된 코드의 정확성이나 보안성은 추적하지 않았음 - 그럴듯해 보이는 것을 보상하는 지표는 실제로 좋은 것을 보상하는 지표가 아님 - ## 도입률을 성공 지표로 보기 - “엔지니어링 조직 전체에서 AI 도구 도입률 90%를 달성했다”는 말은 **구매·배포 성과**이지 생산성 성과가 아님 - 도입률은 도구가 설치되고 열렸는지만 측정하며, 제안이 유용한지, 개발자가 무비판적으로 수락하는지, 수락된 제안이 올바른지는 알려주지 않음 - 높은 도입률과 낮은 제안 품질이 결합되면 개발자는 이점을 얻기보다 도구를 관리하는 데 시간을 쓰게 됨 - IBM의 기업용 AI 코딩 어시스턴트 연구에서는 도구가 종종 순생산성 증가를 만들었지만, 그 이득은 사용자 전체에 균일하지 않았음 - 도입률은 편익보다 측정하기 쉬우며, 바로 그 이유 때문에 보고되기 쉬움 ### 실험 설계의 오류 - ## 인위적인 과제 시간 재기 - 널리 인용되는 GitHub Copilot 연구에서는 사용자가 비사용자보다 과제를 55% 빠르게 완료함 - 과제는 JavaScript로 HTTP 서버를 처음부터 구현하는 일이었고, 제한 시간은 90분이었으며, 개발자에게 그날 다른 의무는 없었음 - 실제 소프트웨어 개발에는 자신이 작성하지 않은 큰 코드베이스 탐색, 모호한 티켓 요구사항 이해, 동료와의 조율, 회의가 포함됨 - **그린필드 장난감 과제**의 속도는 이런 실제 업무의 속도를 예측하지 못함 - 숙련된 오픈소스 개발자를 대상으로 한 무작위 대조 시험에서는 참여자들의 예상과 달리 AI 도구 접근권을 준 경우 과제 완료 시간이 19% 증가함 - ## 통제군 없는 전후 비교 - 1월에 LLM을 쓰기 시작했고 6월에 Pull Request가 더 빨리 배포됐다면 도구가 효과를 낸 것처럼 보일 수 있음 - 같은 기간에 엔지니어 12명을 채용하고, CI 파이프라인을 리팩터링하고, 클라우드 제공자를 바꿨다면 원인을 분리할 수 없음 - 도구를 도입하지 않은 집단이 없으면 LLM의 효과와 동시에 일어난 다른 변화의 효과를 구분하기 어려움 - **내적 타당성**에는 도구가 없었다면 어떤 일이 일어났을지 알 수 있는 신뢰할 만한 반사실이 필요함 - ## 지원자와 비지원자 비교 - LLM 사용을 선택한 개발자와 선택하지 않은 개발자를 비교하면 두 조건이 아니라 서로 다른 두 집단을 비교하게 됨 - 초기 도입자는 후기 도입자나 비도입자보다 실험 의지가 강하고, 새 도구에 익숙하며, 이미 높은 성과자일 가능성이 큼 - **선택 편향** 때문에 관찰된 차이가 도구의 속성이 아니라 사람의 속성일 수 있음 - 이 방식은 실행 비용이 가장 낮아 산업계 AI 생산성 보고서에서 흔한 설계 결함이 됨 - 대형 IT 조직에서 Copilot 사용을 2년간 추적한 종단 연구에서는 도구 도입 전부터 사용자가 비사용자보다 지속적으로 더 활동적이었음 - ## AI와 ‘아무것도 없음’을 비교 - AI 보조 개발자를 아무 도구도 쓰지 않는 통제군과 비교하면 실제 업무에 존재하지 않는 기준선을 고르게 됨 - LLM 어시스턴트가 없는 개발자도 문서, 동료, 스스로 문제를 생각하는 시간을 사용함 - 중요한 질문은 LLM 도구가 개발자가 이미 가진 대안보다 나은지이며, 이런 비교는 드물게 이루어짐 - **약한 기준선**을 고르면 어떤 도구든 좋아 보이지만, 그것이 실제 유용성을 뜻하지는 않음 ### 측정 범위의 누락 - ## 쉬운 절반만 측정하기 - LLM은 코드 생성을 더 빠르게 만들며, 이 부분은 측정하기 쉬움 - 더 어려운 절반은 LLM 생성 코드 검토 시간, 자신 있게 틀린 제안 때문에 잃는 디버깅 시간, 그럴듯하지만 안전하지 않은 코드가 만든 보안 취약점, 주변 설계를 무시한 즉흥적 해결책이 만든 기술 부채임 - GitHub Copilot 코드 연구에서는 생성 코드의 상당 부분에 **보안 취약점**이 있었고, 시간 압박을 받는 개발자가 안전하지 않은 제안을 더 높은 비율로 수락함 - 2025년 주요 LLM 5개 평가에서는 어느 모델도 산업 보안 표준을 충족하는 웹 애플리케이션 코드를 만들지 못함 - AI가 작성한 30만 개 이상의 커밋을 대규모 분석한 결과, 15% 이상이 최소 하나의 품질 문제를 도입했고 그중 거의 4분의 1은 코드베이스에 장기적으로 남았음 - 늘어난 입력만 측정하고 함께 늘어난 비용을 무시하면 측정이 아니라 마케팅이 됨 - ## 개인이 아니라 시스템을 측정해야 함 - 개인의 코딩 속도는 가장 측정하기 쉬워서 자주 측정됨 - AI 도구가 개발자가 코드를 30% 더 빠르게 쓰게 해도, 팀의 티켓-프로덕션 리드타임이 바뀌지 않는다면 병목은 코드 작성이 아니었음 - 생성 코드가 늘면 리뷰해야 할 코드도 늘어나며, AI가 코드 양만 늘리고 리뷰 역량을 늘리지 못하면 **사이클 타임**은 악화될 수 있음 - 전문 개발자 대상 실증 연구에서는 AI 도구가 경험이 적은 기여자의 산출은 늘렸지만, 시니어 개발자는 AI 생성 코드로 인한 코드 리뷰 부하가 6.5% 늘면서 자신의 생산성이 19% 하락함 - 파이프라인의 한 단계만 최적화하고 나머지를 무시하면 생산성 연구처럼 보이는 시스템 사고의 실패가 됨 ### 시간에 따른 효과 왜곡 - ## 개발자에게 생산성이 올랐는지 묻기 - “개발자의 87%가 AI 도구로 더 생산적이라고 느낀다”는 설문 결과는 도구가 작동한다는 근거로 자주 인용됨 - **자기보고**는 세 가지 이유로 체계적인 오해를 만들 수 있음 - Hawthorne 효과 때문에 사람들은 관찰·평가받고 있다는 사실을 알 때 다르게 일함 - 새 도구는 새롭기 때문에 더 빠르게 느껴지는 **신기효과**를 만들며, 이런 느낌은 보통 몇 주 안에 사라짐 - 사회적 바람직성 편향 때문에 응답자는 특히 경영진이 도구를 선택했을 때 설문이 듣고 싶어 한다고 믿는 답을 하는 경향이 있음 - ## 신기효과 기간에만 측정하기 - 4주짜리 연구가 생산성 향상을 찾았다면, 그것은 4주짜리 생산성 향상만 찾은 것임 - 개발자는 초기 기간에 새 도구에 더 몰입하므로 관찰된 성과가 장기 기준선보다 부풀려질 수 있음 - 실제로 중요한 효과는 몇 주가 아니라 몇 달에 걸쳐 나타남 - AI에 위임한 작업에서의 **기술 퇴화**, 틀린 제안에서 쌓이는 기술 부채, 팀 협업 방식의 변화는 장기 관찰이 필요함 - 단기 이득을 탐지하도록 설계된 연구는 연구가 끝난 뒤 무슨 일이 생기는지 말해주지 않음 - Cursor를 도입한 807개 오픈소스 저장소 분석에서는 도입 후 개발 속도가 크게 그러나 일시적으로 증가했고, 코드 복잡도와 정적 분석 경고는 상당하고 지속적으로 증가함 ### 더 나은 해석을 위한 결론 - **생산성 측정**은 단일 숫자나 손쉬운 대리 지표로 환원되기 어려움 - LLM 보조 코딩의 효과를 판단하려면 코드 작성 속도뿐 아니라 리뷰, 디버깅, 보안, 유지보수, 기술 부채, 팀 병목, 장기 변화까지 함께 봐야 함 - 통제군, 현실적인 기준선, 선택 편향 통제, 장기 관찰, 시스템 수준 지표가 없으면 AI 도구의 효과와 다른 변화의 효과를 구분하기 어려움 - 측정하기 쉬운 값은 보고되기 쉽지만, 쉬운 값이 중요한 값을 대신하지는 못함 - 소프트웨어 개발 관행을 평가하려면 인간과학의 연구 방법을 더 진지하게 받아들일 필요가 있음 ### 인용된 주요 자료 - [Kent Beck, “Measuring Developer Productivity: Real-World Examples”](https://tidyfirst.substack.com/p/measuring-developer-productivity): 개발자 생산성 측정의 현실적 예시 - [Catherine M. Hicks, Carol Lee, Kristen Foster-Marks, “The New Developer: AI Skill Threat, Identity Change & Developer Thriving in the Transition to AI-Assisted Software Development”](https://osf.io/preprints/psyarxiv/2gej5_v2): AI 보조 개발 전환에서 기술 위협, 정체성 변화, 개발자 번영을 다룸 - [McKinsey, “Yes, You Can Measure Software Developer Productivity”](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity): 커밋, Pull Request, 코드 리뷰 같은 활동 기반 생산성 측정 제안 - Peng2023: GitHub Copilot 사용자가 HTTP 서버 구현 과제를 55% 더 빨리 완료했다는 연구 - Becker2025: 숙련된 오픈소스 개발자에게 AI 도구 접근권을 제공했을 때 과제 완료 시간이 19% 증가했다는 연구 - Pearce2022: GitHub Copilot 생성 코드의 보안 취약점과 시간 압박 시 안전하지 않은 제안 수락 증가를 평가한 연구 - He2026: Cursor 도입 후 단기 개발 속도 증가와 장기 코드 복잡도·정적 분석 경고 증가를 확인한 연구 - Xu2025: AI 보조 프로그래밍이 경험 많은 개발자의 리뷰 부담과 유지보수 부담을 늘려 생산성을 낮출 수 있음을 다룬 연구 ## Comments ### Comment 58038 - Author: neo - Created: 2026-05-22T09:20:49+09:00 - Points: 2 ###### [Lobste.rs 의견들](https://lobste.rs/s/3ltdmy/twelve_ways_be_wrong_about_ai_assisted) - 작성자는 [Software Carpentry](https://software-carpentry.org/) 창립자 중 한 명이라, LLM이 나오기 훨씬 전부터 **소프트웨어 생산성 측정**을 더 잘하는 방법을 고민해 온 사람임 인용된 METR 연구는 흔히 보이는 이유보다 더 흥미롭다. 많은 사람에게 헤드라인은 “AI가 사람들을 더 느리게 만들었다”였고, 이는 2025년식 LLM이라 계속 좋아지는 중이라는 식으로 반박될 수 있음 하지만 더 흥미로운 결과는, 사후에 본인들이 추정한 값이 실제와 방향조차 맞지 않았다는 점임. 여기에는 대부분의 회사가 무시하는, 어떤 측정에도 근본적인 어려움을 만드는 요소가 있는 듯함 도구가 사람들을 더 생산적으로 만든다는 **막연한 느낌**조차 믿을 수 없음. 사람들은 스스로 알지 못함 이어진 [후속 연구](https://metr.org/blog/2026-02-24-uplift-update/)는 선택 편향 때문에 사실상 실패했음 > The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI 개발자들이 AI 없이 일하기를 거부한다는 건 도구가 잘 작동한다는 뜻일 수도 있고, 도구에 점점 의존하면서 더 어려운 작업을 하는 능력이 완전히 퇴화했다는 뜻일 수도 있음 - 사람들이 실제로 하기 싫은 부분에 LLM을 더 많이 의존하는 경향이 있고, 하기 싫은 일을 할 때는 시간이 항상 훨씬 더 느리게 느껴진다는 게 내 가설임 - “새 도구는 새롭기 때문에 더 빠르게 느껴지고, 그 느낌은 보통 몇 주 안에 사라진다”는 말은 거꾸로인 것 같음 새 도구는 익숙하지 않아서 항상 나를 느리게 만듦. 물론 더 빨라질 **잠재력**은 보이지만, 아직 효과적으로 쓰지 못하기 때문임 - 관련된 효과가 하나 더 있음. 특히 새 도구를 자원해서 써보는 사람들은 열정이 있어서, 부족한 부분을 메우려고 근무 시간 밖에도 더 일함 한동안은 인상적으로 보이지만, 결국 평소 업무 방식으로 돌아가면서 자연스럽게 사라짐 - **측정은 어렵다**. 어떤 의미에서는 AI 보조 코딩을 측정하려는 것 자체가 실수일 수 있음 어떤 작업은 더 빠르게 만들어 주는 게 분명하고, 더 빨라지게 쓰는 방법도 거의 분명히 있을 것임 더 중요한 질문은 그 방법이 무엇인지, 그리고 그 과정에서 무엇을 잃는지가 됨 - **생산성**과 작업 속도 향상은 다름. 어떤 작업이 더 빨라져도, 그 작업이 병목이 아니었거나 속도 향상에 비용이 따른다면 생산성에는 긍정적 영향이 없을 수 있음 원문도 이를 “쉬운 절반만 측정하기”로 다루고 있음 - “다음 주에 매니저가 회사에서 가입한 AI 코딩 도구가 구독료만큼 가치 있다는 걸 보여달라고 한다면, 생성된 코드 줄 수를 측정할 것인가, 닫힌 티켓 수를 측정할 것인가?”라는 질문에 대해, **Claude**는 이미 결제 내역에서 코드 줄 수, 수락률, 토큰 사용량을 측정함 닫힌 티켓 수는 팀의 속도일 텐데, AI 출력은 그중 일부 요소일 뿐이고 Jira가 스프린트 속도를 측정함 어쨌든 이 질문은 매니저가 원하는 산출물이 무엇이라고 생각하느냐에 따라 쉽게 조작될 수 있고, 아마 이미 그렇게 되고 있을 가능성이 큼 - 작성자가 매우 중요한 질문을 빠뜨린 것 같음. “**AI 사용은 어떤 피해를 일으키는가?**”가 그것임 이 질문은 다른 어떤 것보다 더 근본적이라고 봄. 피해는 측정하기가 훨씬 쉽기 때문임. Git forge를 하나 띄워두고, 크롤러들이 피 냄새 맡은 상어처럼 달려드는 걸 보면 됨 스크레이퍼가 인터넷 전체를 DDoS하는 건 측정 가능한 문제이고, 직접 호스팅하는 사람이라면 각자 체감하는 현실임 우리가 제대로 측정하기도 어려워하는 AI의 이른바 이점들이, 크롤러가 일으키는 매우 현실적인 피해를 감수할 만큼 가치가 있는가? 크롤러를 운영하고 그 요청을 처리하는 데 드는 에너지, 학습 비용, 추론 비용, 점점 더 큰 데이터 센터의 필요까지 더하면 어떨까? AI의 그런 이른바 이점들이 이 모든 것을 희생할 만큼 가치가 있는지 묻는 게 훨씬 더 중요한 질문이라고 봄 - 이런 “우리는 X를 이야기해야 한다”식 문제에서 늘 답답한 건, 생태적 피해를 다룬 글에서는 정반대 주장을 봤다는 점임 “이것들이 에너지를 쓰지 않는다 해도 여전히 나쁜 코드를 만들어내니, 그걸 이야기하는 게 훨씬 더 중요하다”거나, “코딩 이야기를 왜 하느냐, 진짜 피해는 감시에 쓰이는 것이다” 같은 식으로 계속 넘어감