AI 코딩 도구가 일상적인 개발 수단이 되면서 코드를 작성하는 데 드는 시간은 빠르게 줄고 있다. 작업의 일부가 짧아진 만큼 개발자는 전과 다른 곳에서 더 오래 기다린다.
코드량 8배, 생산성은 별개
2026년 5월, Anthropic이 프로덕션(실제 서비스에 배포되는 환경)에 머지(코드 변경분을 최종본에 합치는 작업)한 코드의 80% 이상을 Claude가 작성했는데, 2025년 2월만 해도 한 자릿수 초반이었다. 엔지니어 한 명이 하루에 머지하는 코드 줄 수도 2024년보다 8배 늘었다. 그러나 Anthropic은 코드량만으로 생산성을 재면 실제 성과를 과장할 수 있다고 밝혔다.
Google이 새로 작성한 코드 중 AI가 생성한 비율도 2024년 25%에서 2026년 75%로 올랐다. 생성 속도만이 아니다. 목표와 평가 기준이 분명한 모델 학습 실험에서는 Claude가 최적화한 코드의 실행 속도가 시작 코드보다 최대 52배 빨라졌다. 개방형 연구에서도 사람 연구자 두 명이 일주일 동안 격차의 23%를 좁혔고, 에이전트는 누적 800시간의 연산으로 97%를 좁혔다. 다만 과제와 채점 기준은 모두 사람이 정했다.
코드 작성이 8배 빨라져도 개발 전체가 8배 빨라지지는 않는다. 머지된 코드량만으로 어떤 문제를 풀었는지, 사용자가 어떤 가치를 얻었는지를 어떻게 알겠는가. 코드 생성 속도가 빨라질수록 검토와 채택, 목표 설정이 전체 속도를 좌우한다.
리뷰로 옮겨간 병목
코드 생성이 빨라지면서 병목은 다른 공정으로 넘어갔다. 가장 먼저 막힌 곳은 사람의 리뷰였다. AI가 코드를 써도 의도에 맞는지, 안전하고 유지보수할 수 있는지는 사람이 확인해야 한다.
2026년 LinearB 벤치마크에서 에이전트가 만든 PR은 일반 PR보다 첫 리뷰까지 대기 시간의 75백분위 기준으로 5.3배 길었다. 30일 안에 머지된 비율도 AI 생성 PR은 32.7%, 수작업 PR은 84.4%였다. 일일 워크플로 실행량은 프로젝트 평균으로 전년 대비 59% 늘었지만 메인 브랜치(모든 변경사항이 합쳐지는 기준 코드 줄기) 처리량은 중간값 팀 기준으로 7% 줄었다. 실행은 늘었는데, 결과는 따라붙었을까.
오픈소스에서도 선별 자체가 일이 됐다.
- curl은 가짜 취약점 제보가 늘어나자 2026년 1월, 6년간 운영한 버그바운티(보안 취약점을 신고하면 보상금을 주는 제도)를 끝냈다.
- GitHub도 저품질 기여로부터 메인테이너를 보호하기 위해 PR을 막거나 협업자에게만 허용하는 기능을 검토했다.
이런 부담을 자동 리뷰로 덜 수도 있다. Anthropic의 과거 장애를 분석한 결과, Claude 리뷰가 있었다면 프로덕션 버그 약 3분의 1을 배포 전에 찾았을 것으로 추정됐다. 다만 자동 검사는 버그와 보안 결함, 명세 위반은 잡아내도 명세 자체가 잘못됐는지는 판단하지 못한다. 명세부터 사용자 요구와 다르면 코드가 잘 작동해도 제품은 틀린다.
취향과 판단의 경계
인간에게 남은 비교 우위는 연구 취향과 판단이다. 어떤 문제에 자원을 쓸지, 어떤 결과를 믿을지, 언제 그만둘지를 실행만으로 정할 수 있을까.
이 영역에서도 모델은 나아지고 있다. 연구의 다음 단계를 고르는 실험에서 모델이 사람보다 나은 선택을 한 비율은 2025년 11월 51%에서 2026년 4월 64%로 올랐다. 다만 연구자가 잘못된 길로 간 사례만 비교한 결과라 인간의 판단 전반을 대표하지는 않는다.
한편 AI가 혼자 처리하는 작업 시간도 2024년 4분에서 2025년 90분, 2026년 12시간으로 늘었다.
여기서 시간 지평은 AI가 일정 성공률로 혼자 끝낼 수 있는 과제를 사람이 수행할 때 걸리는 시간을 뜻한다.
판단은 여전히 필요하다. 다만 사람이 방향을 잡는 간격이 길어졌고 그만큼 한 번의 판단이 미치는 범위도 커졌다. 낮은 PR 수용률과 줄어든 메인 브랜치 처리량에서 보듯이 AI의 실행 능력은 곧바로 조직의 성과로 이어지지 않는다.
같은 경계는 재귀적 자기개선에서도 드러난다. 재귀적 자기개선은 AI가 개선한 AI가 다시 다음 AI를 개선하는 과정이 반복되며 스스로 성능을 끌어올리는 구조를 말한다. 완전한 재귀적 자기개선을 이루려면 AI가 다음 연구 목표와 평가 기준을 세우고 결과까지 판정해야 한다. 지금 자동화된 것은 연구 실행과 일부 다음 단계 선택까지다. 연구 의제와 최종 판단은 여전히 사람의 몫이다.
이제는 명세가 병목이다
앞으로 AI 성능이 정체될 수도, 사람이 방향을 잡는 부분 자동화가 이어질 수도, 완전한 재귀적 자기개선에 이를 수도 있다. 어느 경우든 코드 생성 속도는 더 이상 핵심 변수가 아니다. 완전 자동화에 가까워질수록 컴퓨트(AI 연산에 필요한 하드웨어 자원)와 전력, 검증 체계가 속도를 결정한다.
Anthropic이 가장 유력하게 보는 부분 자동화 시나리오에서는 100명 조직이 1만~10만 명 규모의 일을 처리한다. 이때는 생성량보다 새 병목을 찾아 운영 방식을 바꾸는 일이 관건이다. Microsoft가 요구사항과 제약, 인수 기준, 예외 조건을 담은 구조화된 명세를 사람과 AI의 공통 기준으로 삼는 것도 그 연장선이다.
가령 ‘로그인 추가’라는 한 줄에는 인증 방식, 세션 만료, 오류 처리, 보안 수준이 빠져 있다. AI는 빈칸을 그럴듯하게 채우지만 그 답이 팀의 정책과 맞는다는 보장은 없다. 요구가 모호하면 긴 회의 대신 완성된 오답이 나온다. 리뷰어는 코드에서 빠진 요구사항까지 역추적해야 한다.
그래서 인수 기준을 버전 관리되는 명세에 담으면 구현과 테스트의 목표가 일치한다. 기준이 없으면 생성된 코드마다 의도를 다시 해석해야 한다. AI가 목표와 인수 기준까지 세우기 전까지 인간의 핵심 업무는 코딩보다 인수 기준을 쓰는 일이다. 코드의 80%를 AI가 작성했다는 수치는 조직이 원하는 결과를 얼마나 명확하게 규정했는지에 좌우된다.
결국 코드가 희소하지 않은 환경에서는 생산성 지표가 기술 역량만큼 조직의 선택을 반영한다. 생성량이 비슷한 팀 사이의 차이는 어떤 결과를 채택했고 이후 얼마나 적게 되돌렸는지에서 나타난다.