AI 코딩 도구를 켜면 코딩이 빨라진다고 느끼는 개발자가 많다. 실제로 대다수가 이미 이런 도구를 일상적으로 쓴다. 그런데 '느낌'과 '실측'이 갈라지는 지점이 있다. 한 무작위 대조 시험(RCT, 참가자를 조건에 무작위 배정해 효과를 비교하는 실험)에서는 숙련 개발자가 AI를 쓸 때 오히려 더 느려졌다 [출처: METR, 2025]. 이 글은 그 격차를 데이터로 살펴본다. 그리고 여러분이 도구를 언제 믿고 언제 검증할지 판단하는 기준을 정리한다.
이 글의 순서
- 도입은 앞서갔지만 확신은 따라오지 못했다
- 생산성 역설 — 체감과 실측 사이
- 도입은 늘어도 신뢰는 내려갔다
- 언제 돕고 언제 방해하나
- 조직에서는 — AI는 증폭기다
- 그렇다면, 어떻게 잘 쓸 것인가
- 결론 — 아직 열린 질문
도입은 앞서갔지만 확신은 따라오지 못했다
도입 속도부터 보자. Stack Overflow의 2025년 개발자 설문(응답 49,009명, 166개국)에서 AI 도구를 쓰거나 쓸 계획이라는 응답은 84%였다 [출처: Stack Overflow, 2025]. 이는 2024년의 76%에서 오른 값이다. 전문 개발자의 51%는 매일 AI 도구를 쓴다고 답했다.
조직 단위 조사도 비슷하다. Google의 DORA 2025 리포트에서는 응답자의 약 90%가 업무에 AI를 쓴다고 답했다 [출처: DORA, 2025]. 이 리포트는 기술 전문가 약 5,000명과 100시간이 넘는 정성 데이터에 기반한다. 요컨대 AI 코딩 도구의 도입은 이미 예외가 아니라 기본에 가깝다.
문제는 도입률이 곧 효과나 신뢰를 뜻하지는 않는다는 데 있다. 도구를 쓰는 것과 그 도구가 실제로 생산성을 올리는 것은 다른 문제다. 이 간극을 흔히 생산성 역설이라 부른다. 다음 절부터 그 역설을 데이터로 뜯어본다.
생산성 역설 — 체감과 실측 사이
가장 반직관적인 근거는 AI 평가 연구기관 METR의 2025년 무작위 대조 시험이다. 숙련 오픈소스 개발자 16명이 실제 이슈 246개를 처리했다 [출처: METR, 2025]. 과제는 평균 약 2시간 분량이었고, 대상은 평균 2만 2천 개 이상의 스타와 100만 줄 이상을 가진 성숙한 리포지토리였다. 결과는 예상과 반대였다. AI 사용을 허용하자 이슈 완료에 19% 더 오래 걸렸다.
인식과 실제의 격차는 더 컸다. 참가자들은 실험 전 AI가 자신을 24% 빠르게 해줄 것으로 기대했다 [출처: METR, 2025]. 실험이 끝난 뒤에도 이들은 AI가 자신을 20% 빠르게 해줬다고 믿었다. 실제로는 느려졌는데도 그렇게 느낀 것이다. 체감 속도와 실측 속도가 반대 방향을 가리킨 셈이다.
다만 조건을 반드시 함께 봐야 한다. 표본은 16명으로 작고, 참가자는 숙련자였으며, 대상은 자신에게 익숙한 대형 코드베이스였다 [출처: METR, 2025]. 사용 도구는 Cursor Pro와 당시 프런티어 모델인 Claude 3.5/3.7 Sonnet이었다. 저자들은 이 결과가 "AI가 대다수 개발자를 느리게 만든다"는 뜻이 아니라고 못박았다. 경험이 적은 개발자나 낯선 코드베이스에는 일반화되지 않는다고도 밝혔다.
무엇을 측정했는지가 중요하다
이 글의 여러 숫자를 오해 없이 읽으려면 한 가지를 기억해야 한다. 연구마다 재는 대상이 다르다는 점이다. METR가 잰 것은 개인의 과제 완료 시간이다 [출처: METR, 2025]. 이는 조직 전체의 생산성이나 전달 성과와 같은 층위가 아니다.
층위를 섞으면 잘못된 결론이 나온다. Stack Overflow와 Fastly의 수치는 개발자의 자기보고 인식이다. DORA의 수치는 조직의 소프트웨어 전달 성과에 대한 상관관계다. Anthropic의 수치는 학습 이해도 시험 점수다. "체감 20% 빨라짐"과 "실측 19% 느려짐"과 "조직 처리량 증가"는 서로 다른 층위의 이야기다. 한 문장에서 인과로 엮지 않는 것이 이 주제를 정확히 읽는 첫걸음이다.
도입은 늘어도 신뢰는 내려갔다
도입이 늘면 신뢰도 함께 오를 것 같지만, 데이터는 그렇지 않다. Stack Overflow 2025 설문에서 AI 답변의 정확성을 신뢰한다는 응답은 약 33%였다 [출처: Stack Overflow, 2025]. 반면 신뢰하지 않는다는 응답은 약 46%로 더 많았다. 도입률 84%와 나란히 놓으면 대비가 뚜렷하다.
불신의 근원은 답변의 미묘한 부정확성에 있다. 같은 설문에서 최대 좌절 요인 1위는 "거의 맞지만 정확히는 아닌" AI 답변으로, 66%가 이를 꼽았다 [출처: Stack Overflow, 2025]. 또 응답자의 45.2%는 AI가 생성한 코드를 디버깅하는 데 시간이 더 걸린다고 답했다. 빠르게 초안을 얻어도 검증과 수정 단계에서 그 시간을 도로 쓰게 되는 셈이다.
전반적 분위기도 식었다. AI에 대한 긍정 정서는 2023~2024년 70%를 넘었으나 2025년에는 60%로 내려왔다 [출처: Stack Overflow, 2025]. 정확성에 대한 신뢰 역시 전년보다 하락했다. 다만 정확한 하락 폭은 1차 출처로 확정되지 않아, 여기서는 "전년보다 낮아졌다"는 방향만 밝힌다.
언제 돕고 언제 방해하나
핵심 질문은 "AI가 도움이 되느냐"가 아니라 "언제 도움이 되느냐"다. 근거들을 모으면 두 축이 보인다. 작업의 유형, 그리고 개발자의 경력이다.
작업 유형에 따라
작업의 성격이 결과를 크게 가른다. Google Chrome 개발자경험팀의 Addy Osmani는 이를 "70% 문제"라는 개념으로 설명한다 [출처: Addy Osmani, 2024]. AI는 해법의 약 70%를 빠르게 만들어 주지만, 마지막 30%가 어렵다는 것이다. 엣지 케이스, 보안, 프로덕션 통합이 그 30%에 해당한다. 이는 실증 연구가 아니라 실무자의 관찰이라는 점을 밝혀 둔다.
METR의 결과도 같은 방향을 가리킨다. 익숙한 대형 코드베이스에서 숙련자가 미묘한 이슈를 다룰 때, AI는 오히려 시간을 늘렸다 [출처: METR, 2025]. 정리하면 이렇다. 반복적이고 정형화된 작업에서는 AI가 초안을 빠르게 뽑아 준다. 그러나 깊은 맥락 이해가 필요한 마지막 구간에서는 사람이 여전히 무게를 진다.
경력에 따라
경력도 결과를 가른다. Fastly의 2025년 설문(미국 전문 개발자 791명)에서, 코드의 절반 이상을 AI 생성으로 출하한다는 비율은 시니어(10년 이상)가 32%였다 [출처: Fastly, 2025]. 주니어(0~2년)는 13%로, 시니어가 약 2.5배 많았다. 다만 이는 미국 한정의 자기보고 설문이라는 한계가 있다. 시니어는 AI 산출물을 자신의 판단으로 걸러 쓸 역량이 더 크다고 해석할 수 있다.
반대편에는 학습과 역량의 문제가 있다. Anthropic의 2026년 통제 실험에서, 주로 주니어인 엔지니어 52명이 낯선 라이브러리를 학습했다 [출처: Anthropic, 2026]. 이해도 시험에서 AI 사용 그룹은 평균 50점, 직접 작성 그룹은 67점으로, AI 그룹이 17%p 낮았다. 여기서 17은 속도 차이가 아니라 이해도 점수 차라는 점에 주의해야 한다.
같은 실험은 사용 방식이 결과를 가른다는 신호도 준다. AI에 개념을 질문한 사람은 65점을 넘겼다 [출처: Anthropic, 2026]. 반면 코드 생성 자체를 위임한 사람은 40점을 밑돌았다. 도구를 어떻게 쓰느냐가 스킬 위축 여부를 좌우한다는 뜻이다.
조직에서는 — AI는 증폭기다
개인을 넘어 조직 단위로 가면 그림이 또 달라진다. DORA 2025 리포트는 AI를 증폭기로 규정한다. 리포트의 표현은 이렇다.
"AI doesn't fix a team; it amplifies what's already there." — DORA, 2025
즉 강한 팀은 AI로 더 좋아지고, 취약한 팀은 기존 문제가 더 드러난다는 것이다 [출처: DORA, 2025]. 전달 성과의 방향도 둘로 갈린다. DORA는 전년과 달리 AI 도입이 소프트웨어 전달 처리량 및 제품 성과와 긍정적 상관을 보였다고 밝혔다. 반면 소프트웨어 전달 안정성과는 여전히 부정적 상관이 이어졌다. 처리량은 오르되 안정성은 흔들릴 수 있다는 뜻이다. 단 이는 상관관계 서술이며, DORA는 강한 테스트·버전 관리·빠른 피드백 같은 통제 장치가 없으면 변경량 증가가 불안정으로 이어진다는 조건을 함께 붙인다.
신뢰 면에서도 신중함은 남아 있다. 같은 리포트에서 AI 생성 코드를 거의 또는 전혀 신뢰하지 않는다는 응답은 30%였다 [출처: DORA, 2025]. 도입이 기본이 된 조직 안에서도, 산출물을 그대로 믿지는 않는다는 뜻이다.
코드 품질 신호도 이 그림과 겹친다. 코드리뷰 도구 업체 CodeRabbit이 오픈소스 PR 470개를 분석하니, AI 공동작성 PR은 PR당 평균 10.83개 이슈, 사람 전용 PR은 6.45개로 약 1.7배 차이였다 [출처: CodeRabbit, 2025]. 다만 이는 벤더 자체 분석이고 표본이 470개로 제한적이다. 코드 분석 업체 GitClear는 2020~2024년 2억 1,100만 줄을 분석해, 코드 처닝이 3.1%에서 5.7%로 올랐다고 보고했다 [출처: GitClear, 2025]. 여기서 코드 처닝은 최초 커밋 후 2주 안에 수정·되돌림되는 신규 코드 비율을 뜻한다. 같은 기간 복붙 라인 비중은 8.3%에서 12.3%로 늘었다. 다만 이 지표들은 AI 채택과 시기가 겹칠 뿐이며 인과가 아닌 상관이라는 점을 함께 봐야 한다.
그렇다면, 어떻게 잘 쓸 것인가
앞의 데이터는 단순한 결론으로 이어진다. 도구를 상황에 맞게, 검증하며 쓰라는 것이다. 아래는 그 원리를 실무로 옮긴 제안이다.
첫째, 출력을 기본적으로 검증하라. "거의 맞지만 정확히는 아닌" 답변이 가장 큰 좌절 요인이었음을 기억하면 된다 [출처: Stack Overflow, 2025]. 빠르게 얻은 초안일수록 프로덕션에 넣기 전 한 번 더 확인하는 것이 이득이다.
둘째, 위임할 것과 직접 할 것을 나눠라. 반복적 초안 작업은 AI에 맡기되, 엣지 케이스·보안·프로덕션 통합 같은 마지막 30%는 여러분이 쥐고 있는 편이 낫다 [출처: Addy Osmani, 2024]. 익숙한 대형 코드베이스의 미묘한 문제라면 AI 의존을 특히 경계할 이유가 있다 [출처: METR, 2025].
셋째, 코드 리뷰를 느슨하게 하지 마라. AI 공동작성 코드에서 더 많은 이슈 신호가 관찰된 만큼, 리뷰는 오히려 강화할 대상이다 [출처: CodeRabbit, 2025]. 넷째, 주니어의 학습을 보호하라. AI에 코드 생성을 통째로 맡기기보다 개념을 질문하는 방식이 이해도를 지키는 데 유리했다 [출처: Anthropic, 2026].
결론 — 아직 열린 질문
이 주제에서 하나 확실한 것은, 아직 확실하지 않다는 사실이다. METR는 2025년 결과를 역사적 자료로 재분류했다 [출처: METR, 2026]. 참가자 대화에 근거해, 2026년 초 현재는 개발자들이 AI로 더 빨라졌을 가능성이 크다고 본다. 그러나 선택 편향 때문에 그 증가 폭에 대한 증거는 매우 약하다고 스스로 밝혔다. 실제로 참가자의 30~50%는 AI 없이 하기 싫은 과제를 애초에 제출하지 않았다. 그래서 METR는 실험 설계를 바꾸는 중이다. 즉 반전은 측정된 수치가 아니라 정성적 관찰이다.
도구와 모델이 빠르게 개선되는 만큼, 오늘의 숫자는 내일 달라질 수 있다. "AI가 개발자를 대체하는가"라는 양극단 질문에도 지금 데이터는 깔끔한 답을 주지 않는다. 데이터가 실제로 말해 주는 것은 조건부다. 언제·무엇을·누가 쓰느냐에 따라 결과가 갈린다. 그러니 결론은 하나의 습관으로 남는다. 상황에 맞게 고르고, 검증하며 쓰는 것이다. 이 질문은 아직 열려 있고, 그 사실을 아는 것 자체가 지금으로선 가장 정확한 태도다.