같은 도구를 두고 한쪽은 생산성이 폭발했다 하고 다른 쪽은 오히려 느려졌다고 한다. 양쪽 모두 데이터를 들고 있다. 차이는 무엇을, 어떻게 쟀는가에 있다.
인공지능(AI, Artificial Intelligence) 코딩 도구를 둘러싼 논쟁은 대개 효과가 있느냐 없느냐로 흐른다. 그런데 더 근본적인 질문이 그 아래 깔려 있다. 효과가 있는지를 우리가 제대로 측정하고 있느냐는 것이다.
한쪽에서는 경영진이 실적 발표에서 개발 생산성이 몇 배로 뛰었다고 말한다. 다른 쪽에서는 통제된 실험이 오히려 속도가 느려졌다는 결과를 내놓는다. 흥미로운 점은 양쪽 모두 숫자를 근거로 든다는 사실이다. 그렇다면 문제는 도구가 아니라, 그 도구의 가치를 재는 방식이 얼마나 쉽게 빗나가는가에 있다. 이 글은 그 빗나감이 일어나는 네 가지 지점을 짚는다. 측정 지표의 함정, 실험 설계의 함정, 자기보고의 함정, 그리고 측정 범위의 함정이다.
가장 손쉬운 측정은 눈에 보이는 활동량을 세는 것이다. 작성된 코드 줄 수, 커밋 수, 풀 리퀘스트(PR, Pull Request) 수, 닫힌 티켓 수가 대표적이다. 문제는 활동이 곧 산출이 아니고, 산출이 곧 가치가 아니라는 데 있다.
코드 줄 수가 대표적이다. AI 도구를 도입한 뒤 개발자 한 명당 코드 줄 수가 늘었다면, 그것은 생산성이 아니라 장황함이 늘었다는 뜻일 수 있다. 뒤엉킨 2,000줄 로직을 깔끔한 200줄로 바꾸는 일은 명백한 개선이지만, 코드 줄 수 지표에서는 1,800줄의 손실로 잡힌다. 게다가 코드가 늘면 읽고 유지보수하고 디버깅해야 할 양도 함께 늘어난다. 그 부담은 줄 수 계산에 잡히지 않는다.
커밋과 풀 리퀘스트, 티켓 수도 비슷한 함정을 안고 있다. 어떤 수치든 일단 목표가 되는 순간 좋은 측정값이기를 멈춘다. 커밋 수가 평가 기준이 되면 개발자는 더 작고 더 잦은 커밋을 만들고, 티켓 수가 기준이 되면 하나의 일이 여러 티켓으로 쪼개진다. 숫자는 좋아지지만 그 아래의 실제 작업은 그대로다.
식당의 성과를 “주방에서 홀로 나간 접시 수”로 평가한다고 해보자. 평가가 시작되면 주방은 같은 음식을 더 작은 접시 여러 개에 나눠 담아 내보낼 것이다. 접시 수는 분명히 늘지만, 손님이 더 맛있게 먹었는지, 더 빨리 받았는지는 그 숫자로 전혀 알 수 없다. 세기 쉬운 값과 중요한 값은 다르다.
도구 자체의 사용 신호도 자주 성공 지표로 오해된다. 제안 수락률이 높다는 것은 생성된 코드가 사용자가 받아들일 만큼 그럴듯해 보였다는 뜻일 뿐, 그 코드가 정확한지 안전한지 유지보수하기 좋은지를 말해 주지 않는다. 오히려 시간에 쫓기는 개발자일수록 더 많은 제안을 그대로 수락하며, 그 안에는 위험한 코드도 섞인다. “조직 전체 도입률 90% 달성” 같은 발표 역시 마찬가지다. 그것은 도구가 설치되고 열렸다는 구매·배포의 성과이지, 생산성의 성과가 아니다.
측정 지표를 잘 골랐다 해도, 그 지표를 재는 실험을 어떻게 설계하느냐에 따라 결론이 정반대로 갈린다. AI 코딩 연구에서 가장 자주 인용되는 두 실험을 나란히 놓으면 이 점이 분명해진다.
먼저 자주 인용되는 긍정적 결과가 있다. 깃허브(GitHub)와 마이크로소프트가 함께 수행한 2023년 통제 실험에서, 모집된 개발자들에게 자바스크립트(JavaScript)로 HTTP 서버를 처음부터 구현하게 했더니 코드 도구를 쓴 집단이 그렇지 않은 집단보다 과제를 55.8% 빠르게 끝냈다. 평균 2시간 41분이 걸리던 일이 1시간 11분으로 줄었고, 통계적으로도 유의미했다(95% 신뢰구간 21-89%). 인상적인 숫자다. 다만 이 과제는 빈 화면에서 시작하는 90분짜리 단순 구현이었고, 과제를 끝까지 완료했는지 여부 자체에는 두 집단 간 차이가 없었다.
반대편에는 같은 도구를 현실 조건에서 잰 실험이 있다. 비영리 연구기관 METR(Model Evaluation and Threat Research)이 2025년 수행한 무작위 대조 시험(RCT, Randomized Controlled Trial)에서는, 평균 5년 이상 자기 프로젝트를 다뤄 온 숙련 오픈소스 개발자 16명이 자신의 대형 코드베이스에서 실제 이슈 246건을 처리했다. 각 이슈는 AI 사용을 허용하거나 금지하도록 무작위 배정됐다. 결과는 예상과 반대였다. AI를 허용했을 때 개발자들은 오히려 19% 더 오래 걸렸다.
운전 강습의 첫날 텅 빈 주차장을 도는 일과, 출퇴근 시간 낯선 도심을 통과하는 일은 전혀 다른 능력을 요구한다. 빈 화면에서 새 프로그램을 짜는 속도는, 남이 쓴 거대한 코드를 헤집고 모호한 요구사항을 해석하며 동료와 조율해야 하는 실제 업무의 속도를 거의 예측하지 못한다.
설계의 함정은 여기서 그치지 않는다. 통제군 없는 전후 비교가 흔한 예다. 1월에 도구를 도입했고 6월에 배포가 빨라졌다면 도구의 효과처럼 보인다. 그러나 그 사이 인력을 충원하고, 빌드 체계를 정비하고, 클라우드 제공자를 바꿨다면 무엇이 원인인지 분리할 수 없다. 도구를 쓰지 않은 비교 집단이 없으면, 도구의 효과와 같은 시기에 일어난 다른 변화의 효과가 뒤섞인다.
선택 편향도 산업계 보고서에 자주 끼어든다. 도구를 자발적으로 쓰는 사람과 쓰지 않는 사람을 비교하면, 두 조건이 아니라 서로 다른 두 부류의 사람을 비교하게 된다. 새 도구를 먼저 집어 드는 사람은 대개 실험 의지가 강하고 이미 성과가 높은 편이다. 관찰된 차이가 도구의 속성인지 사람의 속성인지 알 수 없게 된다. 앞의 METR 연구는 2026년 초 후속 데이터에서 이 문제를 정직하게 드러냈다. AI 없이 일하기를 거부하는 개발자가 늘면서 참여자 모집 자체가 어려워졌다는 것이다. 이는 도구가 잘 작동한다는 신호일 수도, 의존이 깊어졌다는 신호일 수도 있어 해석을 더 어렵게 만든다.
마지막으로 기준선을 잘못 잡는 경우가 있다. AI를 쓴 개발자를 “아무 도구도 없는” 개발자와 비교하면, 현실에 존재하지 않는 기준선을 고른 셈이다. AI가 없어도 개발자는 문서를 찾고 동료에게 묻고 검색을 한다. 진짜 물어야 할 질문은 “AI가 무에서 도움이 되는가”가 아니라 “AI가 이미 가진 다른 대안보다 나은가”인데, 이 비교는 드물게만 이뤄진다.
설계의 함정을 피해도 마지막 관문이 남는다. 사람에게 직접 물어보는 방식이다. “개발자의 다수가 AI 도구로 더 생산적이라고 느낀다”는 설문 결과는 도구의 효과를 증명하는 근거로 즐겨 인용된다. 그러나 느낌은 측정이 아니다. 앞서 본 METR 실험은 이 격차를 한 장면에 담아냈다.
자기보고가 체계적으로 어긋나는 데에는 잘 알려진 세 가지 이유가 있다. 첫째는 호손 효과다. 사람은 관찰되고 평가받는다는 사실을 알면 평소와 다르게 일한다. 둘째는 신기 효과다. 새 도구는 새롭다는 이유만으로 더 빠르게 느껴지며, 이 느낌은 보통 몇 주 안에 가라앉는다. 셋째는 사회적 바람직성 편향이다. 특히 그 도구를 경영진이 골랐을 때, 응답자는 설문이 듣고 싶어 한다고 믿는 답을 하는 쪽으로 기운다.
여기에 측정 기간의 문제가 겹친다. 4주짜리 연구가 생산성 향상을 발견했다면, 그것은 4주짜리 향상을 발견한 것일 뿐이다. 정작 중요한 효과(위임한 작업에서의 기량 퇴화, 틀린 제안이 남긴 기술 부채, 협업 방식의 변화)는 몇 주가 아니라 몇 달에 걸쳐 나타난다. 단기 이득을 잡도록 설계된 연구는 연구가 끝난 뒤 무슨 일이 벌어지는지 말해 주지 않는다.
AI는 코드를 더 빠르게 만들어 낸다. 그리고 이 부분은 측정하기 쉽다. 문제는 측정하기 어려운 나머지 절반이다. 생성된 코드를 검토하는 시간, 자신 있게 틀린 제안을 디버깅하는 시간, 그럴듯하지만 안전하지 않은 코드가 만든 취약점, 주변 설계를 무시한 임시방편이 쌓아 올린 기술 부채가 모두 여기에 속한다.
보안은 가장 분명한 사례다. 2021년 발표된 한 보안 연구(흔히 “키보드 앞에서 졸다”로 알려진)는 미국 마이터(MITRE) 재단이 정리한 고위험 약점 상위 25개를 토대로 89가지 시나리오를 만들고, 코드 도구가 생성한 프로그램 1,689개를 검사했다. 그 가운데 약 40%가 취약했다. 더 우려스러운 후속 연구는, AI의 도움을 받은 개발자가 오히려 덜 안전한 코드를 작성하면서도 자신의 코드가 더 안전하다고 믿는다는 점을 보였다. 위험과 자신감이 동시에 커지는 셈이다.
장기적인 유지보수 비용도 서서히 모습을 드러내고 있다. 코드 변경 데이터를 분석하는 한 기업이 2020년부터 2024년까지 약 2억 1,100만 줄의 변경을 추적한 결과, AI 사용이 늘어난 시기에 코드 품질 신호가 일관되게 나빠졌다. 2024년 한 해 동안 다섯 줄 이상이 인접 코드와 겹치는 중복 블록이 여덟 배로 늘었고, 코드를 재사용하기 좋게 정리하는 재구조화의 비중은 2021년 약 25%에서 2024년 10% 미만으로 떨어졌다. 같은 해에 처음으로, 복사해 붙여넣은 코드가 정리·이동된 코드를 넘어섰다.
이 추세가 도구나 모델이 좋아지면 사라질 일시적 현상인지도 검증됐다. 2025년 카네기멜런대학 연구진은 인기 코딩 도구를 도입한 오픈소스 저장소 807개를, 도입하지 않은 비슷한 저장소 1,380개와 짝지어 비교했다(차분의 차분 설계). 도입 직후 개발 속도는 크게 올랐지만 그 효과는 일시적이었다. 반면 정적 분석 경고는 약 30%, 코드 복잡도는 약 42% 늘었고 이 증가는 사라지지 않고 지속됐다. 그리고 바로 그 누적된 복잡도가 장기적으로 속도를 다시 끌어내리는 주된 원인으로 분석됐다. 속도라는 단기 이득과 복잡도라는 장기 비용이 서로 다른 시간 척도에서 움직인 것이다.
측정하기 가장 쉬운 것은 개인의 코딩 속도이고, 그래서 가장 자주 측정된다. 그러나 개인이 30% 빨라져도 팀의 “티켓에서 배포까지” 걸리는 시간이 그대로라면, 애초에 병목은 코드 작성이 아니었다는 뜻이다. 오히려 생성되는 코드가 늘수록 검토해야 할 코드도 늘어, 리뷰 역량이 따라 늘지 않으면 전체 흐름은 더 느려질 수 있다. 파이프라인의 한 단계만 최적화하고 나머지를 무시하는 것은 생산성 연구의 외양을 한 시스템 사고의 실패다.
시스템 수준에서 본 대표적 자료가 이를 뒷받침한다. 약 3만 9천 명을 조사한 2024년 한 대규모 데브옵스(DevOps) 보고서에 따르면, AI 도입이 25% 늘 때 전달 처리량은 약 1.5%, 배포 안정성은 약 7.2% 떨어지는 것으로 추정됐다. 개인의 생산성과 만족도는 올라가는데 팀의 전달 성과는 내려가는, 언뜻 모순돼 보이는 결과다. 보고서가 지목한 원인은 단순하다. AI가 한 번에 더 많은 코드를 만들어 변경 묶음이 커지고, 큰 변경일수록 위험하기 때문이다.
다만 이것이 고정된 결론은 아니다. 측정과 관행이 함께 성숙하면 방향은 바뀐다. 같은 조사의 2025년 후속에서는 AI와 처리량의 관계가 음에서 양으로 돌아섰다. 작은 변경 묶음과 견고한 테스트 같은 기본기가 갖춰지면 시스템 차원의 손해는 줄어든다는 뜻이다.
지금까지의 함정을 뒤집으면, 신뢰할 만한 측정이 갖춰야 할 조건이 자연스럽게 드러난다. 비교를 위한 통제군이나 그에 준하는 준실험 설계, 현실에 실제로 존재하는 기준선(아무것도 없는 상태가 아니라 기존의 대안), 누가 도구를 쓸지에 따른 선택 편향의 통제, 몇 주가 아닌 몇 달 단위의 장기 관찰, 그리고 개인의 속도가 아니라 리드타임·변경 실패율·재작업률 같은 시스템 수준 지표다. 이 가운데 어느 하나라도 빠지면, 도구의 효과와 다른 변화의 효과를 구분하기 어려워진다.
쉽게 잴 수 있는 값은 보고하기도 쉽다. 그래서 보고서에는 자꾸 그 값이 오른다. 그러나 쉬운 값이 중요한 값을 대신해 주지는 않는다. 어떤 작업이 분명히 빨라진다는 것, 그리고 더 잘 쓰는 방법이 존재한다는 것은 사실이다. 더 의미 있는 질문은 그다음에 있다. 무엇이 빨라지는가, 그 과정에서 무엇을 잃는가, 그리고 그 빨라짐이 정말로 우리 팀의 진짜 병목을 푸는가. 측정의 목적은 이미 산 도구를 정당화하는 데 있지 않다. 어디서 이득이고 어디서 비용인지를 분별하는 데 있다.