AI 코딩 툴을 매달 바꾸는데, 개발 속도는 왜 그대로일까요?

새 AI 코딩 도구를 설치하면 첫날은 빨라 보입니다. 요구사항을 적으면 파일을 만들고, 화면을 띄우고, 테스트까지 실행합니다. 지난달에 쓰던 도구보다 답도 자연스럽고 수정 범위도 넓습니다.

그런데 프로젝트 일정은 기대만큼 줄지 않습니다. 생성된 코드를 다시 읽고, 빠진 요구사항을 찾고, 기존 기능이 깨지지 않았는지 확인하는 시간이 남아 있기 때문입니다. 새 도구로 옮길 때마다 설정과 규칙을 다시 설명하는 시간도 생깁니다.

AI 코딩 툴이 빨라진 것과 개발팀이 제품을 더 빨리 끝내는 것은 같은 말이 아닙니다. 도구를 비교하려면 코드가 나온 시점이 아니라 검토와 수정, 배포 준비가 끝난 시점을 봐야 합니다.

첫 결과가 빠른 도구와 완료가 빠른 도구는 다릅니다

AI 코딩 도구의 데모는 대개 첫 결과를 보여 줍니다.

• 프롬프트를 입력한 뒤 화면이 열린 시간
• 새 기능의 파일이 생성된 시간
• 에이전트가 작업 완료를 보고한 시간

실제 프로젝트에서 필요한 것은 그 뒤의 시간까지 포함한 결과입니다.

• 요구사항과 다른 부분을 찾아 고친 시간
• 테스트와 코드 리뷰에 든 시간
• 기존 기능의 회귀 오류를 해결한 시간
• 권한·데이터·배포 설정을 확인한 시간
• 다른 사람이 변경 이유를 이해하고 이어받은 시간

에이전트가 20분 만에 코드를 만들었더라도 검토와 재작업에 세 시간이 들면 완료 시간은 세 시간 20분입니다. 반대로 생성은 한 시간이 걸렸지만 수정 없이 검토를 통과했다면 그 도구가 실제로 더 빠릅니다.

체감 속도와 완료 속도는 쉽게 어긋납니다. 2025년 초 숙련된 오픈소스 개발자를 대상으로 한 무작위 연구에서는 AI 사용 시 작업 시간이 19% 늘었지만 참가자들은 빨라졌다고 느꼈습니다.[1] 다만 2026년 후속 업데이트는 최신 도구에서 속도 향상 가능성이 커졌다고 보면서도, 참가자 선택과 병렬 작업 시간 측정 문제 때문에 효과를 신뢰성 있게 추정하기 어렵다며 실험 설계를 바꾸고 있습니다.[1]

이 숫자를 모든 개발팀에 적용할 수는 없습니다. 오히려 중요한 점은 도구가 빠르게 바뀔수록 생산성을 느낌으로 판단하기 더 어려워진다는 사실입니다.

도구를 바꿀 때 숨은 이전 비용이 생깁니다

새 도구의 구독료만 비교하면 전환 비용을 작게 보게 됩니다. 실제로는 다음 작업이 함께 발생합니다.

• 저장소 접근 권한과 비밀정보 범위를 다시 설정함
• 프로젝트 규칙과 금지 사항을 새 형식으로 옮김
• 모델이 사용할 명령과 도구를 다시 연결함
• 팀원이 승인·중단·재개 방식을 새로 익힘
• 기존 대화와 결정 기록을 가져오지 못해 맥락을 다시 설명함
• 새 도구가 만든 변경을 검토하는 기준을 맞춤

이전 비용은 첫날에만 생기지 않습니다. 팀마다 사용법이 달라지면 코드 리뷰 때마다 ‘어떤 지시로 이 결과가 나왔는지’를 다시 확인하게 됩니다. 한 사람의 속도는 올라가도 팀 전체의 검토 비용은 커질 수 있습니다.

그래서 저는 새 기능이 많다는 이유만으로 진행 중인 프로젝트의 기준 도구를 바꾸지 않습니다. 지금 반복해서 막히는 지점 하나가 무엇인지 먼저 정하고, 새 도구가 그 병목을 줄이는지 확인합니다.

예를 들어 병목이 테스트 작성이라면 테스트 초안의 양보다 검토를 통과한 테스트 수와 수정 시간을 봅니다. 병목이 대규모 코드 탐색이라면 답변 속도보다 잘못 짚은 파일과 누락한 영향 범위를 기록합니다. 측정할 병목이 정해지지 않으면 새 도구의 장점은 인상에 머뭅니다.

프로젝트의 기억은 채팅창 밖에 남겨야 합니다

도구를 바꿀 때 가장 큰 손실은 단축키가 아니라 프로젝트 맥락입니다. 이전 대화 안에만 다음 정보가 있다면 새 에이전트는 같은 실수를 반복합니다.

• 제품이 해결하려는 문제와 이번 작업의 범위
• 수정하면 안 되는 데이터와 기능
• 기술 선택의 이유와 피해야 할 패턴
• 실행해야 할 테스트와 검증 명령
• 사람이 승인해야 하는 작업
• 배포 전 조건과 되돌리는 방법

이 정보는 특정 도구의 기억 기능보다 저장소의 문서, 이슈, 테스트와 변경 기록에 남기는 편이 안전합니다. 코드와 함께 버전 관리하면 어떤 지침이 언제 바뀌었는지 확인할 수 있고, 사람도 같은 기준을 읽을 수 있습니다.

프로젝트 지침을 AGENTS.md 같은 파일에 두는 흐름도 이런 필요에서 나왔습니다. 공개 형식은 프로젝트 구조·빌드 명령·테스트와 코드 규칙을 에이전트에게 전달하는 용도로 설명되고,[2] VS Code는 여러 AI 에이전트가 하나의 저장소 지침을 함께 사용할 때 이 파일을 읽도록 지원합니다.[3]

파일 이름 하나가 모든 문제를 해결하지는 않습니다. 중요한 것은 도구가 아니라 정보의 소유권입니다. 프로젝트의 규칙을 프로젝트가 소유해야 다음 모델과 다음 담당자가 이어받을 수 있습니다.

기준 경로와 실험 경로를 분리합니다

새 도구를 전혀 시험하지 않으면 실제 개선 기회를 놓칩니다. 반대로 새 도구가 나올 때마다 팀의 기본 환경을 바꾸면 프로젝트가 실험장이 됩니다.

두 경로를 분리하면 이 충돌을 줄일 수 있습니다.

기준 경로

진행 중인 고객 프로젝트와 운영 작업에 사용하는 방식입니다. 지원 모델, 권한, 테스트, 리뷰와 배포 절차가 정해져 있고 문제가 생기면 돌아갈 방법이 있습니다.

실험 경로

새 모델과 도구를 작은 작업에서 비교하는 방식입니다. 운영 데이터와 비밀정보를 제외하고, 결과를 이미 알고 있는 작업이나 되돌리기 쉬운 작업을 사용합니다.

실험에서는 같은 종류의 작업을 기준 도구와 새 도구에 각각 맡깁니다. 한 번의 성공적인 데모보다 여러 번 반복했을 때의 결과를 봅니다.

이 표에서 현재 병목이 반복적으로 줄어들 때만 기준 경로로 옮깁니다. 새 도구가 특정 작업에는 뛰어나지만 팀 전체 표준으로 쓰기 어렵다면 보조 도구로 남겨도 됩니다. 모든 도구를 하나로 통일하는 것이 목표는 아닙니다.

병렬 에이전트는 결과보다 검토 순서를 먼저 설계합니다

여러 에이전트를 동시에 실행하면 파일이 만들어지는 속도는 빨라집니다. 하지만 서로 같은 코드를 건드리거나 다른 가정을 하면 검토할 후보와 충돌도 함께 늘어납니다.

병렬 실행이 유리한 작업은 경계와 완료 조건을 나눌 수 있어야 합니다.

• 서로 다른 조사 자료를 모음
• 독립된 테스트 사례를 작성함
• 구현안과 반대 관점의 리뷰를 분리함
• 충돌하지 않는 모듈을 각각 수정함

반대로 하나의 데이터 모델과 API 계약을 여러 에이전트가 동시에 바꾸면 통합 비용이 커질 수 있습니다. 이때는 구현 속도보다 결정권자를 먼저 정해야 합니다. 누가 공통 인터페이스를 확정하고, 어떤 테스트가 통합 여부를 결정하며, 충돌하면 어느 변경을 버릴지 명확해야 합니다.

에이전트 세 개가 세 개의 답을 만들었다면 생산성이 세 배가 된 것이 아닙니다. 검증 기준으로 한 답을 빠르게 고를 수 있을 때 병렬 실행의 이득이 생깁니다.

도구를 바꾸기 전에 일곱 가지를 묻습니다

새 AI 코딩 도구를 팀의 기준으로 채택하기 전에는 다음 질문에 답할 수 있어야 합니다.

1. 지금 줄이려는 병목을 한 문장으로 말할 수 있는가
2. 첫 결과가 아니라 검토·재작업을 포함한 완료 시간을 측정했는가
3. 기존 저장소·IDE·CI와 함께 쓸 수 있는가
4. 권한과 비밀정보 접근 범위를 제한할 수 있는가
5. 지침과 작업 기록을 프로젝트에 남길 수 있는가
6. 다른 팀원이 같은 결과를 재현할 수 있는가
7. 기대와 다르면 기존 방식으로 돌아갈 수 있는가

일곱 질문 가운데 답하지 못한 항목이 있다면 도구가 나쁘다는 뜻은 아닙니다. 아직 팀의 기준으로 옮길 준비가 되지 않았다는 뜻입니다. 실험 경로에서 더 확인하면 됩니다.

오래 남는 것은 도구 사용법보다 완료 기준입니다

AI 코딩 도구는 앞으로도 자주 바뀔 것입니다. 어떤 도구는 사라지고, 익숙한 제품 안에 더 나은 기능이 들어오며, 같은 모델도 업데이트 뒤 다른 결과를 냅니다.

모든 변화에 뒤처지지 않으려고 매번 환경을 바꾸면 숙련이 쌓이기 어렵습니다. 반대로 기준 도구를 영원히 고정하면 더 나은 작업 방식을 놓칩니다.

제가 택하는 기준은 단순합니다. 새 도구는 실험 경로에서 적극적으로 시험하되, 진행 중인 프로젝트는 측정된 개선이 있기 전까지 기준 경로를 유지합니다. 프로젝트 규칙과 테스트, 변경 이유와 복구 방법은 도구 밖에 남깁니다.

그러면 모델을 바꿔도 같은 완료 기준으로 결과를 비교할 수 있습니다. 새 도구가 실제 병목을 줄이면 채택하고, 그렇지 않으면 데모 경험으로 남기면 됩니다.

AI 도구를 잘 쓰는 팀은 가장 많은 제품을 설치한 팀이 아닙니다. 도구가 바뀌어도 무엇을 끝냈다고 볼지, 누가 확인할지, 문제가 생기면 어떻게 돌아갈지를 잃지 않는 팀입니다.

출처

• [1] https://metr.org/blog/2026-02-24-uplift-update/ — METR, We are Changing our Developer Productivity Experiment Design(2026년 8월 16일 확인)
• [2] https://agents.md/ — AGENTS.md, 공개 형식 안내(2026년 8월 16일 확인)
• [3] https://code.visualstudio.com/docs/agent-customization/custom-instructions — Visual Studio Code, Use custom instructions(2026년 8월 16일 확인)