AI가 코드를 작성하고 배포하면 숙련된 개발자는 왜 19% 느려질까

데빈(Devin), 클로드 코드(Claude Code), 깃허브 코파일럿 워크스페이스(GitHub Copilot Workspace) 같은 소프트웨어 에이전트는 이제 작업 설명을 받아 코드베이스를 읽고, 이에 대응하는 코드를 작성하며, 테스트를 통과할 때까지 실행하고, 개발자가 한 줄도 입력하지 않아도 풀 리퀘스트를 연다. Cognition AI가 개발한 Devin은 격리된 클라우드 환경에서 이를 수행한다. 프로덕션 사용자 기반 전체에서 자율적으로 열린 풀 리퀘스트 중 67%가 병합된다. Claude Code는 전체 저장소를 읽고, 여러 파일에 걸친 변경 사항을 계획하며, 테스트 스위트를 실행하고, 각 단계 사이에 지시 없이 반복한다. 이 도구들은 연구 프리뷰가 아닌 실제 프로덕션에서 사용되고 있다.

이들을 이전의 코드 생성 도구와 구분짓는 것은 피드백 루프다. 제안 엔진은 텍스트를 생성하고 멈추지만, 자율 에이전트는 코드를 생성하고 실행하며 결과를 읽고 다시 시도한다. 기본 구조는 모든 도구에서 동일하다: 대규모 언어 모델이 컨텍스트(코드베이스, 이슈 설명, 오류 로그)를 읽고 계획을 생성한 뒤, 셸 명령어, 파일 편집, git 작업 등의 도구를 통해 실행하고 결과를 읽어 수정한다. 에이전트가 성공하거나 리소스 예산을 소진할 때까지 이 루프는 계속된다.

편집기를 대체한 루프

사용 가능한 도구의 자율성 범위는 세 가지 수준으로 나뉜다. 보조 수준에서는 GitHub Copilot이 개발자가 입력할 때 다음 몇 줄을 제안한다. 한 단계 위인 다중 파일 편집기 Cursor는 개발자의 지시에 따라 코드베이스 전체를 재작성하며, 개발자가 지정한 변경을 수행한다. 자율 수준에서는 Devin 및 유사 시스템이 독립적으로 장시간 작동하며, 무엇을 읽고 변경하고 테스트할지 순차적으로 결정하고, 시스템이 혼자 처리할 수 없는 승인만 요청한다.

이 도구들의 진전을 측정하는 평가 프레임워크는 프린스턴대와 스탠퍼드대 연구진이 만든 SWE-bench다. 오픈소스 파이썬 저장소(Django, Flask, scikit-learn)의 실제 버그 리포트를 에이전트에 테스트하며, 에이전트가 올바르게 해결한 비율을 측정한다. 현재 큐레이션된 Verified 하위 집합에서 가장 높은 공개 점수인 96%는 Claude Opus 5가 기록했다. 이 숫자는 실제 소프트웨어 버그를 진단하고, 수정 코드를 작성하며, 프로젝트 자체 테스트를 통과하는지 검증하는 능력이라는 진정한 역량을 나타낸다.

벤치마크가 숨기는 것

96% 점수에는 중요한 단서가 따른다. SWE-bench Verified는 신중하게 선별된 500개 작업에서 추출된다. 연구진이 오염 방지 변형인 SWE-bench Pro(어떤 모델의 학습 데이터에도 등장할 수 없는 문제로 설계됨)를 적용했을 때, Verified에서 80% 이상을 기록했던 이전 모델이 Pro에서는 50% 미만으로 떨어졌다. 일부 벤치마크 성능은 일반화된 문제 해결 능력이 아니라 평가 세트에 대한 친숙도를 반영한다. 이 격차는 알려진 연구 과제일 뿐, 특정 도구에 대한 비판이 아니다.

별도의 연구에서는 설명하기 더 어려운 결과가 나왔다. AI 안전 연구 기관인 METR은 자신의 저장소에서 작업하는 경험 많은 오픈소스 개발자들을 대상으로 무작위 대조 시험을 진행했다. 현재 AI 코딩 도구를 사용하는 개발자는 사용하지 않는 개발자보다 19% 더 느렸다. 독립적으로 추정한 결과 자신이 20% 더 빠르다고 생각했음에도 불구하고 말이다. 원인은 구체적이었다: 에이전트가 잘못된 결과를 냈을 때 다시 프롬프트를 입력하는 시간, 병합 전 출력을 검증하는 시간, 에이전트를 지시하는 것과 에이전트가 한 작업을 따라가는 것 사이를 전환하는 인지적 부담이다. 벤치마크는 에이전트가 잘 정의된 버그를 단독으로 해결할 수 있는지 테스트한다. 무작위 대조 시험은 개발자가 실제 하루 동안 더 빠르게 작업하는지 테스트한다. 이들은 서로 다른 것을 측정하고 있다.

93% 채택이 단 10%의 처리량 증가만 가져온 이유

코드 자율성은 범위가 정해지고 잘 명시된 작업에서 가장 잘 작동한다: 명확한 입력과 출력이 있는 재현 가능한 버그, 정확한 명세가 있는 함수, 정의된 동작이 있는 모듈의 테스트 스위트 등. 범위가 암묵적 아키텍처 지식, 문서화되지 않은 팀 관행, 또는 제품 방향에 대한 결정을 요구하는 작업으로 확장되면 신뢰성이 떨어진다. 모델의 능력 부족 때문이 아니라, 그러한 결정에 필요한 컨텍스트가 시스템에 맞지 않고 코드베이스 파일만으로는 도출할 수 없기 때문이다.

실질적인 변화는 작업이 요구하는 것에 있다. 자율 에이전트와 작업하는 개발자는 에이전트가 실행할 수 있을 만큼 정확한 명세(상세한 이슈 설명, 명확한 테스트 계약, 명시적인 승인 기준)를 작성하는 데 더 많은 시간을 보낸다. 또한 자신이 작성하지 않은 코드를 검토하는 데 더 많은 시간을 보내는데, 이는 코드 작성과는 다른 종류의 주의를 요구한다. 에이전트가 스스로 표시하지 않는 논리 오류, 보안 허점, 아키텍처 이탈을 찾아내야 하기 때문이다. 2026년 12만 1000명의 개발자를 대상으로 한 설문조사에 따르면 93%가 AI 코딩 도구를 정기적으로 사용하고 있었으며, 같은 그룹에서 풀 리퀘스트 처리량은 약 10% 증가했다. 병목 현상이 코드 작성에서 코드 검토로 이동했다.

현재 활발히 개발 중인 다음 단계는 자체 작업 큐를 관리하는 에이전트다: 프로젝트 명세를 받아 하위 작업으로 나누고, 전문화된 모델 간에 위임하며, 인간의 판단이 필요한 결정만 표면화한다. 2026년에는 다중 에이전트 코딩 오케스트레이션을 위한 여러 오픈소스 프레임워크가 출시되었다. 프로덕션 환경에서의 기업 채택은 여전히 제한적이다. Gartner는 올해 시작된 에이전틱 소프트웨어 프로젝트 중 상당 부분이 2028년 이전에 중단될 것으로 전망한다. 통제된 데모가 보여주는 것과 안정적인 대규모 배포에 필요한 것 사이의 차이를 팀들이 발견하게 되면 말이다.

태그: 인공지능, 프로그래밍, AI coding agents, 소프트웨어 개발, 코드 자율화