AI 코딩 에이전트: 실제 팀에서 측정할 수 있는 결과

AI 코딩 에이전트는 입력하는 동안 한 줄을 자동완성하는 도구가 아니다. 목표를 주면, 버그를 고치든 엔드포인트를 추가하든 모듈을 리팩토링하든, 단계를 계획하고 저장소 전체의 파일을 수정하고 테스트를 실행하고 실패에 대응해 diff가 눈에 띄기 전에 여러 번 반복한다. 이 루프가 AI 코딩 에이전트와 문장을 완성해주는 AI 어시스턴트의 실제 차이점이다. 스프린트 계획 방식 자체를 바꾸고, 단지 타이핑 속도만 빠르게 하는 게 아니다. 이 글은 벤더 슬라이드가 주장하는 효과가 아니라, 5~50명 팀의 실제 엔지니어링에서 무엇이 바뀌는지 측정한다.

AI 코딩 에이전트와 자동완성을 구분하는 것

인라인 제안 도구는 입력할 때 다음 토큰 몇 개를 예측한다. 매 줄마다 사람이 개입한다. AI 코딩 에이전트는 다르게 작동한다. 저장소의 관련 부분을 읽고, 계획을 수립하고, 여러 파일을 수정하고, 테스트 모음을 실행하고, 실패 출력을 읽고, 때로 사람이 한 발자국도 봉사하지 않고 다시 시도한다.

이미 알려진 워크플로를 생각해보자. grep, Ctrl+F, git blame, 그리고 나서 그 파일을 수정한 사람한테 슬랙 메시지. AI 에이전트는 첫 세 단계를 grep 명령을 입력하는 것보다 빠르게 실행할 수 있는 도구로 대체한다. 슬랙 메시지를 없애진 않는다. 누군가는 여전히 그 diff를 신뢰해야 한다.

Cursor의 Agent 모드, GitHub Copilot의 에이전트 모드, Claude Code, Devin, Replit Agent 모두 이 정의에 맞다. 자율성 수준은 다르다. Cursor와 Copilot은 에디터에 더 가깝게 머물고 대부분의 단계에서 사람의 승인을 기대한다. Devin은 클라우드 환경 내에서 더 멀리 떨어져서 실행한 후 PR을 건넨다.

실제 루프의 개략적인 모습은 이렇다:

1. 읽기: 목표와 관련된 파일 찾기
2. 계획: 하나의 diff가 아닌 수정 수열 초안 작성
3. 편집: 계획이 필요한 파일들 전체에 변경 적용
4. 실행: 테스트 모음 또는 범위가 정해진 부분집합 실행
5. 다시 읽기: 실패 출력 분석
6. 3-5단계 반복 (테스트 통과 또는 예산 소진까지)

6단계가 마케팅이 끝나고 엔지니어링이 시작되는 지점이다. 재시도 예산이 없는 루프는 같은 함수를 다섯 가지 방법으로 다시 쓰며 한 시간을 태워버릴 수 있다. 예산이 빡빡한 루프는 반쯤 끝난 것을 건네주고 '완료'라고 한다. 어느 실패 사례도 벤치마크 점수에 나타나지 않는다.

숫자가 정직해지는 순간: 13.86%에서 현재까지

Cognition이 처음 Devin의 결과를 발표했을 때, 에이전트는 실제 GitHub 이슈의 13.86%를 미지원으로 종료했고, 당시 최신 기술은 2% 미만이었다. 하나의 숫자로 전체 스토리였다. 에이전트는 실제 엔드-투-엔드 작업을 할 수 있지만, 아직 신뢰할 수 없었다. 기술 보고서는 여전히 공개되어 있으며, 어떤 벤더의 현재 벤치마크 슬라이드를 신뢰하기 전에 읽어볼 가치가 있다. 테스트가 어떻게 범위가 정해졌는지 정확하게 보여주기 때문이다.

2년 후, 최고 성능 에이전트는 SWE-bench Verified 같은 큐레이션된 벤치마크에서 85~90%를 넘는다. 필드의 초기 리더보다 대략 2.5배 빠른 토큰 처리량으로 실행된다. 실제 도약이다. 큐레이션된 벤치마크일 뿐이다. 명확한 해결책과 명확한 테스트가 있는 이슈로 구축되었다. 팀의 백로그는 큐레이션되지 않는다. "명확하게 지정된 GitHub 이슈를 해결한다"와 "인증 미들웨어가 왜 그렇게 연결되어 있는지 이해한다" 사이의 간격은 에이전트가 오후를 절약해주는지, 아니면 낭비하게 하는지를 결정한다.

Terminal 중심의 벤치마크는 순수 코드 수정 벤치마크와 약간 다른 이야기를 말한다. 명령을 실행하고 출력을 올바르게 읽는 능력으로 에이전트를 채점하기 때문에, 실제 디버깅 세션 중에 일어나는 일에 더 가깝다. 도구가 하나에서는 잘 하고 다른 하나에서는 평범할 수 있다. 벤더가 한 개의 숫자만 발표한다면, 경쟁자의 다른 테스트의 숫자와 비교하기 전에 어떤 벤치마크인지 물어보자.

실제로 변하는 2주일: AI 코딩 에이전트로 온보딩하기

가장 명확한 측정 가능한 승리는 시니어 엔지니어가 더 빨리 배포하는 것이 아니다. 주니어 엔지니어의 첫 2주다. 100K LOC 저장소의 새 입사자는 예전에 첫 날들을 읽으며 썼다. 어느 서비스가 이 테이블을 소유하는지, 어디서 이 이벤트가 발행되는지, 왜 이 함수 하나가 관련 없어 보이는 세 개의 호출 사이트를 가지는지.

"환불 로직이 어디에 구현되어 있는가"를 초 단위로 답할 수 있는 AI 코딩 에이전트는 그 경사를 완전히 제거하지 않는다. 순수한 검색이었던 부분을 깎아낸다. 온보딩에 에이전트를 연결한 팀은 두 번째나 세 번째 주가 아닌 며칠 안에 첫 의미 있는 PR이 올라온다고 보고한다. 주로 새 입사자가 코드베이스 자체가 답할 수 있는 질문으로 시니어 엔지니어의 슬랙 답장을 기다리지 않기 때문이다.

예상 가능한 실패 모드는 이렇다. 팀이 에이전트를 쓰여진 아키텍처 문서 대체물로 취급하는 대신 그것을 탐색하는 더 빠른 방법으로 본다. "어디" 질문을 잘 답하는 에이전트도 여전히 주니어에게 "왜 우리가 3년 전에 명백한 대안보다 이것을 선택했는가"를 말할 수 없다. 그 맥락은 사람에게 또는 ADR 파일에 산다. diff 히스토리만으로는 아니다.

감정 조사가 아닌 시간으로 측정하자. 새 입사자의 첫 커밋에서 두 번째 서비스를 건드리는 첫 커밋까지의 시간을 추적하자. 그 숫자가 12일에서 5일로 이동하는 것은 매니저에게 보고할 수 있는 실제 결과다. "온보딩 경험이 더 부드럽게 느껴진다"는 그렇지 않다.

벤치마크 테이블이 건너뛰는 질문: 다중 저장소

대부분의 공개 비교는 단일 저장소에서 하나의 명확한 작업에 대해 에이전트를 테스트한다. 20명 이상의 팀은 거의 그렇게 작동하지 않는다. 체크아웃 버그는 프론트엔드 저장소, 결제 서비스 저장소, 공유 타입 패키지에 닿을 수 있다. 세 개의 분리된 장소다. 에이전트는 수정안을 제안하기 전에 이것들 전체를 생각해야 한다.

단일 저장소 자동완성 도구는 이것을 해결할 필요가 없다. 자연어 검색 중심으로 구축된 코드베이스 채팅 도구는 그렇다. 개발자가 실제로 묻는 질문 "이것은 어디에서 검증되는가"는 저장소 경계를 거의 존경하지 않기 때문이다. 에이전트가 에디터에 열려있는 파일만 볼 수 있다면, 다중 저장소 질문은 한 가지 일관된 답변 대신 세 개의 분리된 끊겨진 세션으로 변한다.

이것이 벤더가 선택한 데모 저장소가 아닌 자신의 다중 저장소 설정에 대해 롤아웃 전에 모든 에이전트를 테스트해야 하는 실제적 이유다. 단일 저장소 벤치마크에서 경쟁자와 동일해 보이는 도구가 세 개의 코드베이스 전체에서 세 개의 다른 소유자와 추적해야 할 때 아주 다르게 작동할 수 있다.

구체적인 테스트는 이렇다. 지난 분기에서 실제로 두 개의 저장소에 걸쳐 있던 버그를 선택하자. 어느 파일이 중요한지에 대한 힌트 없이 찬바람으로 에이전트를 지적하자. 세 개의 분리된 세션과 결과를 함께 연결하는 사람이 필요하다면, 그것이 벤더의 랜딩 페이지의 숫자가 아니라 실제 다중 저장소 점수다.

코드 리뷰가 병목이 되고, 코드는 아니다

모두가 권장하지만 거의 측정하지 않는 이것을 건너뛴다. 에이전트의 자율 모드를 켜고 자유롭게 PR을 열도록 하자. 20,574건의 실제 AI 코딩 에이전트 세션에 대한 대규모 분석은 91.49%의 가시적 에이전트 해결책이 실제로 사용 가능하기 전에 명시적 사용자 수정이 필요함을 보였다. 에이전트는 무언가를 완료했다. 거의 최종적인 무언가였다.

그 숫자는 전체 롤아웃 질문을 재구성한다. 제약은 "에이전트가 코드를 쓸 수 있는가"였다. "팀에 그것이 10번 중 9번 수정이 필요함을 잡을 리뷰 용량이 있는가"였다. 5팀 중 3팀은 이를 과소평가하고 에이전트가 관련되기 전보다 더 긴 리뷰 큐로 끝난다.

해결책은 에이전트를 끄는 것이 아니다. 그것이 감시받지 않고 만질 수 있는 것을 범위정하는 것이다.

• 감시받지 않고 안전하게 실행: 기존 실패 테스트가 있는 명확한 지정 버그, 의존성 범프, 죽은 코드 제거, 포매팅 및 lint 수정.

• 병합 전에 항상 검토, 후가 아니라: 인증, 청구, 데이터베이스 마이그레이션, 또는 공개 API 계약을 만지는 모든 것.

• 따로 추적: 각 범주에 대한 수정률. 청구 인접 PR에 lint 수정보다 두 배 높은 수정률이 필요하다면, 그것은 리뷰 헤드카운트를 추가하지 않고 에이전트의 범위를 더 좁혀야 한다는 신호다.

대부분의 팀은 이 범주화를 완전히 건너뛰고 모든 에이전트가 열린 PR에 한 가지 리뷰 정책을 적용한다. 그것을 분리하는 팀은 한 달 내에 더 긴 것이 아닌 더 짧은 리뷰 큐를 보고한다.

Cursor, Claude Code, Devin, Tabnine: 각각이 실제로 구축된 것

이 네 가지는 거의 항상 잘못된 축에서 비교된다. 그들은 교환 가능하지 않으며, 차이는 어떤 단일 벤치마크 점수보다 더 중요하다.

• Cursor는 에디터에 가장 가깝게 유지된다. 강한 인라인 완성과 다중 파일 편집용 에이전트 모드, 대부분의 단계에서 사람이 승인함. IDE의 순간적인 제어를 잃지 않고 에이전트 도움을 원하는 팀에 좋은 맞음.

• Claude Code는 터미널 우선으로 실행되고, 넓은 저장소 맥락과 범위가 정해진 작업에 한 번 거의 손을 놓지 않음. 전체 기능 분기를 위임하고 스트림 제안이 아닌 diff로 결과를 검토하는 것이 편한 엔지니어에게 좋은 맞음.

• Devin은 자율성이 가장 멀다. PR을 건네기 전에 마이그레이션이나 분류 같은 범위가 정해진 작업에서 클라우드 환경 내에서 작동한다. 명확하고 반복 가능한 작업에 좋은 맞음, 모호한 제품 결정은 아니다.

• Tabnine은 자율성이 아닌 배포에 차별화된다. 온프렘이나 에어갭 옵션과 위의 여러 개를 기본값으로 배제하는 제3자 클라우드로 독점 코드를 보낼 수 없는 팀을 위한 영 코드 보유.

이들 중 어느 것도 시니어 엔지니어의 머리 속에 있는 "왜"를 대체하지 않는다. 모두 검색했던 "어디"와 "무엇"을 깎아낸다. 그들 사이를 선택하는 것은 이번 달에 누가 더 똑똑한지보다 덜 중요하고, 기저 모델이 빠르게 수렴하고, 팀이 견딜 수 있는 실패 모드에 대해 더 중요하다. Cursor 제안을 거절하는 데 드는 비용은 초 단위, 감시받지 않고 20분 동안 실행된 Devin PR을 거절하는 데 드는 비용은 더 크다.

팀에 롤아웃하기 전에 측정할 세 가지

벤더 벤치마크를 건너뛰고 자신의 저장소에서 세 가지를 측정하자.

1. 첫 정답까지의 시간 - 지난 주 팀이 물은 다섯 개의 실제 질문, 데모 질문이 아니다. 슬랙 히스토리에서 직접 뽑자. 판매 엔지니어가 데모할 것보다 더 정직하다.

2. 수정률 - 첫 20개 에이전트가 열은 PR에, 도구에서 자체 보고하지 않고 그들을 검토하는 누군가로 추적함. PR이 하나의 작은 댓글을 필요로 하는 것은 완전한 재작성이 필요한 것과 다르게 개수하는 것. 둘 다 분리하여 추적하자.

3. 다중 저장소 정확도 - 코드베이스가 둘 이상의 저장소에 걸쳐 있다면, 명시적으로 테스트함. 위의 섹션에서 찬바람 테스트 방법을 사용하고 결과를 검증하는 데 사람이 얼마나 오래 걸리는지 시간을 측정하자.

이것을 건너뛰고 동료의 게시물을 기반으로 채택하고 있다. 측정을 먼저 하는 팀은 보통 벤더의 기본값보다 에이전트를 더 좁게 범위정하는 것으로 끝내고, 한 달 후 그것과 더 행복해한다.

팀이 이번 분기에 하나를 켜야 하는가?

온보딩 고통이 실제이고 측정 가능하게 주 단위로 측정된다면, 네. 거기서 시작하자. 최고의 효과, 최저 위험 장소다. 어쨌든 시니어 엔지니어를 방해할 주니어 엔지니어의 질문이었을 것이기 때문이다.

실제 병목이 리뷰 용량이라면, 자율 PR 모드를 먼저 켜면 그 병목을 더 나빠지게 할 것이다. 뭔가 더 빨라지기 전에. 온보딩과 명확하게 지정된 버그 수정으로 범위정하자. 견딜 수 있는 수정률을 측정한 후 확장하고, 전에 아니다.