AI가 시니어 개발자를 19% 느리게 만든 이유

24% 빨라질 줄 알았다

개발자가 코드를 작성하는 모습 — AI 도구의 등장으로 업무 방식이 바뀌고 있다

2025년 7월. AI 안전 연구 기관 METR이 논문 하나를 발표했다. 제목은 "초기 2025년 AI가 경험 많은 오픈소스 개발자 생산성에 미치는 영향 측정"이다. 학술적이고 건조한 제목이다. 하지만 내용은 충격적이다.

연구진은 16명의 시니어 개발자를 모집했다. 이들은 평균 22,000개 이상의 스타를 받은 대형 오픈소스 프로젝트에 수년간 기여한 베테랑들이다. 평균 5년의 해당 프로젝트 경험과 1,500개 이상의 커밋 이력을 가진다.

실험 시작 전 개발자들에게 물었다. "AI 도구를 쓰면 얼마나 빨라질 것 같나?" 평균 응답은 24% 빨라질 것이었다. 합리적인 예상이다. GitHub Copilot, Cursor, Claude Code. 모두 생산성 향상을 약속하는 도구들 아닌가.

결과는 정반대였다. AI 도구를 사용한 그룹이 19% 더 느렸다. 빨라진 게 아니라 느려졌다.

더 충격적인 건 인식의 괴리다. 실험이 끝난 후 개발자들에게 다시 물었다. "AI가 얼마나 도움이 됐나?" 평균 응답은 20% 빨라졌다였다. 실제로는 느려졌는데 빨라졌다고 믿은 것이다.

예측 24% 빠름. 체감 20% 빠름. 실제 19% 느림. 이 숫자들 사이에 무슨 일이 있었을까.

METR 연구의 설계

이 연구가 신뢰할 만한 이유부터 짚어야 한다. AI 생산성 연구는 대부분 설계에 결함이 있다. METR 연구는 다르다.

무작위 대조 시험(RCT). 의학에서 신약 효과를 검증할 때 쓰는 방법론이다. 참여자를 무작위로 두 그룹에 배정한다. 한 그룹은 AI를 쓰고, 다른 그룹은 안 쓴다. 같은 작업을 수행하고 결과를 비교한다.

실제 작업. 인위적인 테스트가 아니다. 개발자들이 직접 자기 프로젝트의 실제 이슈 목록을 제출했다. 버그 수정, 기능 추가, 리팩토링. 총 246개의 실제 작업이 무작위로 배정됐다.

화면 녹화. 모든 작업 과정이 녹화됐다. 개발자가 뭘 했는지, 얼마나 걸렸는지, AI를 어떻게 사용했는지 전부 기록됐다.

이중 맹검 불가능 인정. 의학 실험과 달리 개발자는 자신이 AI를 쓰는지 안 쓰는지 안다. 이 한계를 연구진도 인정한다. 하지만 객관적 시간 측정으로 주관적 편향을 최대한 배제했다.

참여자 프로필도 중요하다. 이들은 주니어가 아니다. 평균 경력이 10년 이상이다. 해당 프로젝트에만 5년 이상 기여했다. 코드베이스를 속속들이 안다. "이 함수는 왜 이렇게 생겼지?"라고 물을 필요가 없는 사람들이다.

AI 도구는 주로 Cursor Pro와 Claude 3.5/3.7 Sonnet을 사용했다. 2025년 상반기 기준 최신 도구들이다. 개발자들은 원하는 도구를 자유롭게 선택할 수 있었다.

시간당 $150의 보상이 지급됐다. 빨리 끝내려고 대충 하거나, 느리게 끝내서 돈을 더 받으려는 동기가 없도록 설계했다.

왜 느려졌나: 5가지 원인

연구진은 19% 느려진 원인을 분석했다. 20가지 가설을 세우고 검증했다. 그중 5가지가 유력한 원인으로 지목됐다.

첫째, AI 출력물 검토 시간. 개발자들은 전체 작업 시간의 **9%**를 AI가 생성한 코드를 검토하고 수정하는 데 썼다. AI가 코드를 써주면 시간이 절약될 것 같지만, 그 코드가 맞는지 확인하는 데 시간이 든다.

시니어 개발자일수록 이 검토가 까다롭다. 코드가 "작동하는지"만 보는 게 아니라 "올바른지"를 본다. 테스트 커버리지, 엣지 케이스, 코드 스타일, 성능. 기준이 높을수록 검토 시간이 길어진다.

둘째, 컨텍스트 전환 오버헤드. AI와 대화하려면 코딩 모드에서 프롬프팅 모드로 전환해야 한다. "이 함수를 리팩토링해줘"라고 입력하고, 기다리고, 결과를 확인하고, 다시 수정 요청하고. 이 과정이 시간 한 시간에 수십 번 반복된다.

하버드 비즈니스 리뷰에 따르면 컨텍스트 전환 후 원래 작업으로 돌아오는 데 평균 23분이 걸린다. AI와의 상호작용이 이 전환을 계속 유발한다. 물론 23분씩 걸리진 않지만, 작은 중단이 누적되면 큰 손실이 된다.

셋째, 프로젝트 고유의 암묵적 규칙. 대형 오픈소스 프로젝트에는 문서화되지 않은 규칙이 있다. "이 폴더의 파일은 이 패턴을 따른다", "이 API는 이렇게 사용한다", "이 명명 규칙을 지킨다". 시니어 개발자는 이걸 체득하고 있다.

AI는 모른다. AI가 생성한 코드는 기술적으로 맞지만 프로젝트 관례와 다를 수 있다. 이걸 맞추려면 수정이 필요하다. 처음부터 직접 쓰는 게 더 빠를 수도 있다.

넷째, 도구 학습 곡선. 개발자들의 AI 도구 사용 경험은 평균 약 50시간 수준이었다. 충분하지 않다. Cursor의 모든 기능을 활용하려면 더 오랜 숙련이 필요하다. 도구를 "사용"하는 것과 "잘 사용"하는 것은 다르다.

다섯째, 과신. 개발자들은 AI가 맞다고 가정하는 경향이 있었다. AI 출력을 처음에는 신뢰하고, 나중에 문제가 생기면 디버깅한다. 하지만 AI가 미묘하게 틀린 코드를 생성하면 디버깅이 더 어렵다. "왜 이 코드가 안 되지?"보다 "이 코드는 맞는데 왜 안 되지?"가 더 시간이 오래 걸린다.

56%는 어디서 왔나

여기서 의문이 생긴다. "AI가 개발자를 56% 빠르게 만든다"는 연구도 있지 않나? 이 숫자는 어디서 왔을까.

2023년 Microsoft Research, GitHub, MIT 공동 연구다. 95명의 프로그래머에게 JavaScript로 HTTP 서버를 구현하라고 했다. Copilot을 쓴 그룹은 71분, 안 쓴 그룹은 161분이 걸렸다. 55.8% 빨라졌다. 반올림하면 56%다.

두 연구의 결론이 완전히 다르다. 한쪽은 56% 빠름, 다른 쪽은 19% 느림. 무엇이 다른가.

항목	56% 빠름 연구 (2023)	19% 느림 연구 (2025)
참여자	Upwork 프리랜서 95명	오픈소스 메인테이너 16명
작업	HTTP 서버 구현 (새 프로젝트)	기존 프로젝트 이슈 해결
코드베이스	제로에서 시작	100만 줄 이상 기존 코드
경험	다양함	해당 프로젝트 5년 이상
AI 도구	GitHub Copilot	Cursor + Claude 3.5/3.7

핵심 차이는 작업의 성격이다. 56% 연구는 제로에서 새로 만드는 작업이다. AI가 보일러플레이트 코드를 빠르게 생성하면 도움이 된다. 19% 연구는 기존 코드를 수정하는 작업이다. 100만 줄의 레거시 코드를 이해하고, 그 맥락에 맞게 수정해야 한다.

또 다른 차이는 전문성 수준이다. Upwork 프리랜서 중 상당수는 경력이 짧다. 이들에게 AI는 "못하는 것을 하게 해주는" 도구다. 시니어 개발자에게 AI는 "이미 잘하는 것을 도와주는" 도구다. 후자가 훨씬 어렵다.

56% 연구의 저자들도 이 한계를 인정한다. "이 결과는 특정 조건에서의 실험이며, 모든 개발 상황에 일반화할 수 없다"고 명시했다. 하지만 마케팅 자료에서는 이 문구가 빠지기 일쑤다.

인식과 현실의 간극

METR 연구에서 가장 흥미로운 부분은 인식의 왜곡이다.

실험 전 예측: 24% 빨라질 것. 실험 후 체감: 20% 빨라졌음. 실제 측정: 19% 느려졌음.

개발자들은 화면 녹화를 봤다. 시간 측정 결과를 알았다. 그런데도 "AI가 도움이 됐다"고 느꼈다.

왜 이런 괴리가 생길까. 심리학에서 말하는 여러 편향이 복합적으로 작용한다.

확증 편향. 사람들은 자신의 기존 믿음을 확인하는 정보를 더 잘 기억한다. "AI가 이 함수를 잘 짜줬다"는 기억은 남고, "AI 때문에 2시간 디버깅했다"는 기억은 희미해진다.

몰입 효과. AI와 대화하는 과정이 재미있다. 새로운 도구를 쓰는 건 흥미롭다. 이 긍정적 경험이 생산성 평가를 왜곡한다. "재미있었으니 효율적이었을 것"이라고 착각한다.

비용 정당화. Cursor Pro는 월 $20다. 돈을 내고 쓰는 도구가 쓸모없다고 인정하기 싫다. "돈 내고 쓰는데 도움이 안 됐다"보다 "돈 낸 만큼 도움이 됐다"가 심리적으로 편하다.

사회적 압력. "요즘 AI 안 쓰면 뒤처진다"는 분위기가 있다. AI가 도움이 안 됐다고 말하면 "네가 못 쓴 거 아니야?"라는 반응이 돌아온다. 도움이 됐다고 말하는 게 안전하다.

이 편향들은 개인 차원에서 끝나지 않는다. 조직으로 확산된다.

개발자가 "AI가 생산성을 높여준다"고 보고한다. 매니저가 이를 근거로 AI 도구 도입을 결정한다. 전사적으로 Cursor 라이선스를 구매한다. 비용이 발생한다. 이제 "AI가 도움이 됐다"고 말해야 하는 압력이 더 커진다.

시니어가 더 느린 이유

왜 하필 시니어 개발자인가. 주니어라면 결과가 달랐을까.

아마 그렇다. METR 연구진도 이 점을 인정한다. "이 결과는 경험 많은 개발자에게 특정적이며, 초보자나 새로운 코드베이스에서 일하는 개발자에게는 다를 수 있다."

시니어 개발자가 AI로 느려지는 이유는 이미 빠르기 때문이다. 역설적이다. 설명해 보겠다.

시니어 개발자는 자기 프로젝트를 안다. 어떤 파일이 어디 있는지, 어떤 함수가 무슨 일을 하는지, 어떤 패턴을 써야 하는지 체득하고 있다. 머릿속에 멘탈 모델이 있다.

이 상태에서 코드를 짜면 빠르다. 생각하는 속도로 타이핑한다. 중간에 검색하거나 문서를 볼 필요가 없다. 플로우 상태에 들어가면 몇 시간이 순식간에 지나간다.

AI를 도입하면 이 플로우가 깨진다. "AI한테 시켜볼까?"라는 생각이 끼어든다. 프롬프트를 작성한다. 결과를 기다린다. 결과를 검토한다. 수정을 요청한다. 이 과정에서 플로우가 끊긴다.

주니어 개발자는 다르다. 멘탈 모델이 없다. 검색하고, 문서 보고, 시행착오하는 시간이 길다. 이 과정에서 AI가 도움이 된다. "이 에러 뭐야?"라고 물으면 AI가 답해준다. 검색 시간이 줄어든다.

비유하자면 이렇다. 시니어 개발자는 오프라인 지도를 갖고 있다. 어디로 가야 하는지 안다. AI가 "이 길로 가세요"라고 말해도 "아니, 내가 아는 길이 더 빨라"다. 확인하고 무시하는 시간이 추가된다.

주니어 개발자는 지도가 없다. AI가 "이 길로 가세요"라고 하면 따라간다. 최적 경로는 아닐 수 있지만, 혼자 헤매는 것보다는 낫다.

AI가 도움이 되는 경우

그렇다면 AI는 언제 도움이 되는가. METR 연구에도 AI가 유용했던 사례가 있다.

새로운 코드베이스 탐색. 처음 보는 프로젝트에서 "이 함수가 뭐 하는 거야?"라고 물으면 AI가 설명해준다. 코드 리딩 시간이 줄어든다.

보일러플레이트 생성. 반복적인 코드를 대신 써준다. 테스트 파일 템플릿, API 엔드포인트 뼈대, 설정 파일. 창의성이 필요 없는 작업에서 AI가 시간을 절약해준다.

문법 오류 수정. 오타, 세미콜론 누락, 괄호 짝 맞추기. IDE의 린터보다 더 적극적으로 잡아준다.

다른 언어/프레임워크. 주력 언어가 아닌 코드를 다룰 때 AI가 도움이 된다. 파이썬 개발자가 급하게 Go 코드를 수정해야 할 때, AI가 번역기 역할을 한다.

공통점이 보인다. AI는 개발자의 전문성이 낮은 영역에서 도움이 된다. 전문성이 높은 영역, 즉 자기가 잘 아는 코드를 다룰 때는 방해가 될 수 있다.

Augment Code의 분석도 비슷한 결론을 내린다. "AI 도구는 전문성 격차를 메우는 역할을 한다. 전문성이 이미 높으면 메울 격차가 없다."

조직 차원의 시사점

개인 개발자뿐 아니라 조직에도 시사점이 있다.

첫째, AI 도구 ROI 재검토. "개발자 생산성 56% 향상"이라는 마케팅 문구를 믿고 도입했다면 재검토가 필요하다. 실제 생산성을 측정하고 있는가? 개발자의 체감이 아니라 객관적 지표로?

측정 방법도 중요하다. "AI 사용 후 PR 수가 늘었다"는 좋은 지표가 아닐 수 있다. PR이 늘었지만 버그도 늘었다면 총생산성은 떨어진 것이다. 리드 타임, 변경 실패율, 서비스 복구 시간 같은 DORA 메트릭을 함께 봐야 한다.

둘째, 팀별 차별화. 모든 팀에 같은 도구를 적용할 필요가 없다. 레거시 시스템을 유지보수하는 시니어 팀과 신규 프로젝트를 개발하는 주니어 팀은 다르다. 전자는 AI 도움이 적을 수 있고, 후자는 클 수 있다.

셋째, 교육 투자. AI 도구를 "그냥 쓰라"고 하면 안 된다. 효과적인 사용법을 교육해야 한다. METR 연구의 개발자들은 평균 50시간 정도만 AI를 사용해 봤다. 더 오래 사용하면 결과가 달라질 수 있다.

어떤 조직은 AI 페어 프로그래밍 세션을 운영한다. 시니어가 주니어에게 "AI를 이렇게 쓰면 더 효과적이다"를 보여준다. 도구 숙련도가 올라가면 생산성도 올라갈 수 있다.

넷째, 기대치 관리. "AI 도입하면 개발 속도 2배"라는 기대를 심어주지 말아야 한다. 실제 효과는 작업 종류, 개발자 경험, 코드베이스 특성에 따라 크게 다르다. 과장된 기대는 실망으로 이어지고, 실망은 도구 자체에 대한 반감으로 이어진다.

AI 도구 회사들의 반응

METR 연구가 발표되자 AI 도구 업계가 술렁였다. 반응은 크게 세 가지로 나뉜다.

"연구 설계가 잘못됐다" 일부는 연구 방법론을 비판한다. 16명은 너무 적다, 오픈소스 프로젝트는 특수한 환경이다, 도구 숙련도가 낮았다. 유효한 비판이지만, 같은 논리로 "56% 빠름" 연구도 비판할 수 있다. 그쪽은 Upwork 프리랜서 대상이었고, 단일 작업이었고, 제로 스타트였다.

"우리 도구는 다르다" AI 도구 회사들은 자사 제품이 METR 연구의 한계를 극복했다고 주장한다. "우리는 컨텍스트를 더 잘 이해한다", "우리는 프로젝트 전체를 분석한다", "우리는 개발자 워크플로우에 더 자연스럽게 통합된다". 마케팅 문구다. 독립적 검증이 필요하다.

"곧 나아질 것이다" 가장 흔한 반응이다. Claude 4.5, GPT-5.3이 나오면 다를 것이다. 모델 성능이 올라가면 환각이 줄고, 컨텍스트 이해가 좋아지고, 코드 품질이 올라간다. 맞는 말이다. 하지만 "곧 나아질 것"은 현재 도구의 한계를 인정하는 것이기도 하다.

IBM의 분석가는 이렇게 말했다. "METR 연구는 AI 도구가 쓸모없다는 게 아니라, 어디에 쓰면 효과적인지 더 정교하게 이해해야 한다는 것을 보여준다."

연구의 한계

METR 연구도 완벽하지 않다. 연구진이 인정하는 한계가 있다.

표본 크기. 16명은 통계적으로 충분하지만, 대표성을 담보하기엔 적다. 특정 유형의 개발자만 참여했을 수 있다. AI에 회의적인 사람이 더 많이 참여했을 가능성도 있다.

특수한 환경. 대형 오픈소스 프로젝트는 일반 기업 코드베이스와 다르다. 품질 기준이 높다. 코드 리뷰가 엄격하다. 스타트업에서 빠르게 MVP를 만드는 상황과는 다를 수 있다.

2025년 상반기 도구. Claude 3.5/3.7, Cursor Pro가 주로 사용됐다. 2026년의 Claude 4.5나 GPT-5.3은 성능이 다를 수 있다. AI 발전 속도가 빠르므로, 6개월 후에는 결과가 달라질 수 있다.

화면 녹화 효과. 녹화된다는 걸 알면 행동이 달라진다. "평소에 하던 대로"가 아니라 "잘 보이게"를 의식할 수 있다. 이게 AI 사용 패턴에 어떤 영향을 줬는지 알기 어렵다.

연구진은 후속 연구를 예고했다. 같은 방법론으로 반복 실험해서 AI 도구 발전에 따른 생산성 변화를 추적할 계획이다. 2025년 하반기, 2026년 상반기 데이터가 나오면 추세가 더 명확해질 것이다.

결론: 도구가 아니라 맥락이다

AI 코딩 도구가 개발자를 56% 빠르게 만드는가, 19% 느리게 만드는가. 정답은 **"상황에 따라 다르다"**이다.

새 프로젝트를 시작하고, 보일러플레이트가 많고, 익숙하지 않은 언어를 쓰고, 경험이 적다면 AI가 도움이 된다. 56% 연구의 조건이다.

기존 프로젝트를 유지보수하고, 맥락 의존적인 수정이 필요하고, 코드베이스를 깊이 알고, 경험이 풍부하다면 AI가 방해가 될 수 있다. 19% 연구의 조건이다.

도구 자체가 좋거나 나쁜 게 아니다. 맥락이 결정한다.

이건 AI에만 적용되는 게 아니다. 모든 도구가 그렇다. 망치는 못을 박을 때 좋은 도구다. 나사를 돌릴 때는 나쁜 도구다. 망치가 좋으냐 나쁘냐를 물으면 답이 없다. "무엇을 하느냐"를 먼저 물어야 한다.

AI 코딩 도구도 마찬가지다. "AI가 생산성을 높이나?"가 아니라 "어떤 상황에서 AI가 생산성을 높이나?"를 물어야 한다.

METR 연구가 던지는 진짜 메시지는 이것이다. 체감과 실제는 다르다. 개발자 본인이 "빨라졌다"고 느껴도 실제로는 느려졌을 수 있다. 조직이 "생산성이 올랐다"고 믿어도 데이터는 다를 수 있다.

측정하라. 체감 말고 데이터로. 마케팅 문구 말고 실제 환경에서. 그래야 AI 도구가 정말 도움이 되는지, 비싼 장난감인지 알 수 있다.

시니어 개발자가 19% 느려진 건 AI 탓이 아니다. AI를 잘못 적용한 탓이다. 도구를 탓하기 전에 쓰임새를 돌아봐야 한다.

출처: