AI 코딩은 정말 효율을 높였을까? 세 가지 근거를 하나의 결론으로 뭉뚱그리지 말자

한 개발자는 AI 덕분에 10분 만에 프로토타입을 만들었다고 말하고, 다른 개발자는 AI가 수정한 코드를 검토하는 것이 처음부터 직접 작성하는 것보다 느리다고 말합니다. 두 말은 동시에 사실일 수 있습니다. 프로토타입 제작, 성숙한 프로젝트 수정, 장기 유지보수는 같은 종류의 일이 아닙니다. 작업, 완료 기준, 시간 측정 방법을 명시하지 않으면 "효율 향상"을 두고 서로 엇갈린 이야기만 하기 쉽습니다.

기술 리더에게 더 유용한 질문은 "우리 작업에서 AI가 어떤 부분의 노력을 줄였고, 그 일을 어디로 옮겼는가"입니다. 이 글은 METR의 여러 공개 연구를 실마리로 삼아 서로 충돌하는 듯한 결론을 읽는 방법을 설명하고, 팀이 적용할 수 있는 평가 방법을 제시합니다. 자료는 2026년 9월 5일 기준이며, EveryInfra 내부 효율 실험이나 모델 순위는 포함하지 않습니다.

"19% 느려졌다"는 정확히 무엇을 측정했나

METR는 2025년 7월 발표한 연구에서 각자의 오픈소스 프로젝트에 익숙한 개발자 16명에게 실제 작업 246개를 수행하게 하고, 당시 사용할 수 있던 AI 도구의 사용 허용 여부를 무작위로 배정했습니다. 이 연구 조건에서 AI를 사용한 경우 작업 완료 시간이 19% 늘었습니다. 이 연구는 2025년 초의 도구와 특정 작업 상황을 다루며, 2026년의 모든 개발 활동에 일률적으로 적용되는 결과가 아닙니다.

이런 한계를 짚는 것은 결과를 깎아내리기 위해서가 아니라 결과의 쓸모를 지키기 위해서입니다. 대규모 저장소에 익숙한 메인테이너는 프로젝트 관례, 과거의 트레이드오프, 오류가 생기기 쉬운 영역을 이미 알고 있습니다. 모델이 내놓은 첫 수정안이 그럴듯해 보여도 이 배경에 비추어 다시 검토해야 할 수 있습니다. 반대로 낯선 프로젝트에 들어가거나, 일회성 데이터 처리를 하거나, 아이디어를 빠르게 검증하는 경우에는 제약 조건이 다를 수 있습니다.

따라서 이 실험을 근거로 "AI 코딩은 쓸모없다"고 단정하는 것은 근거를 넘어선 해석이며, "프롬프트만 쓸 줄 알면 누구나 효율이 오른다"고 해석하는 것도 마찬가지로 근거가 없습니다. 이 실험은 주관적인 느낌과 작업 완료에 실제로 걸리는 시간이 반드시 일치하지는 않는다는 점을 일깨워 주는 자료로 보는 편이 낫습니다.

당시 Hacker News 토론에서도 독자들은 표본 크기, 프로젝트 숙련도, 이후 재작업 시간을 어떻게 계산할지에 대해 질문했습니다. 이런 의견은 평가 질문을 보완하는 데 도움이 되지만 새로운 실험 결과로 볼 수는 없습니다. 특히 눈에 띄는 경험적 수치를 모든 프로젝트에 적용되는 통계 법칙처럼 제시해서는 안 됩니다.

2026년 후속 자료에서 새로운 비율을 단순히 뽑아낼 수 없는 이유

METR는 2026년 2월 실험 설계 업데이트에서 후속 실험이 참가자와 작업 선정에서 선택 편향을 겪었고, 여러 에이전트를 동시에 실행하면서 시간 추적도 더 어려워졌다고 명시했습니다. 일부 개발자는 AI를 쓰지 못하는 작업에 배정되는 것을 꺼렸습니다. 연구진은 도구가 제공하는 도움이 커지고 있을 수 있지만, 현재 데이터로는 그 증가 폭을 신뢰성 있게 추정하기 어렵다고 밝혔습니다.

이는 "이전 실험이 뒤집혔다"는 뜻이 아닙니다. 이전 실험은 여전히 당시 연구한 상황을 설명하며, 후속 자료는 새로운 환경에서는 연구 대상과 측정 방법마저 바뀌고 있다는 점을 일깨워 줍니다. AI를 더 적극적으로 쓰는 사람은 표본에 들어오지 않았을 수 있고, AI에 가장 적합한 작업은 제출되지 않았을 수 있습니다.

기업 파일럿에서 이 문제는 매우 현실적입니다. 결과를 보여 주고 싶은 사용자만 집계하면 실패하거나 중단된 작업을 놓치기 쉽고, AI에 익숙하지 않은 구성원만 참여시키면 학습 단계의 마찰이 장기적인 효과처럼 보일 수 있습니다. 어느 쪽을 택하든 결론이 달라질 수 있습니다.

먼저 작업이 어떤 경로로 파일럿에 들어오는지 기록한 다음 평균 결과를 볼 것을 권장합니다. 누가 참여하지 않았는지, 어떤 작업이 제외되었는지, 제외 사유는 무엇이었는지 기록하세요. 관련 없는 개인 정보를 수집할 필요는 없습니다. 작업 유형별로 분류한 로그가 성공한 데모 몇 개를 보여 주는 것보다 더 많은 것을 설명해 줍니다.

빨리 일하는 것, 많이 만드는 것, 높은 가치를 내는 것은 같은 지표가 아니다

METR는 2026년 5월 기술직 종사자 설문에서 속도와 가치를 한 번 더 구분했습니다. 설문에는 기술직 종사자 349명이 참여했으며, 응답자가 스스로 보고한 업무 가치 배수의 중앙값은 질문 문구에 따라 1.4배에서 2배 사이였고, 스스로 보고한 속도 배수의 중앙값은 3배였습니다. 이는 설문 응답의 주관적 추정치이며, 무작위 실험으로 확인된 팀 생산성 향상이 아닙니다.

두 지표는 왜 다를 수 있습니까? 한 팀이 AI로 내부 데모 페이지를 여러 개 빠르게 만든다고 가정해 보겠습니다. 이 페이지들이 중요한 요구 사항을 확인하는 데 도움이 된다면 가치가 클 수 있습니다. 하지만 어떤 의사결정에도 쓰이지 않는다면 코드 파일과 페이지 수는 늘어도 비즈니스 가치는 따라오지 않을 수 있습니다. 이는 가상의 예시이며 특정 기업의 연구 사례가 아닙니다.

반대로 AI 덕분에 엔지니어가 문서를 찾아보는 횟수가 줄고 도구를 자주 오가지 않게 되면, 프로젝트의 최종 납기는 크게 달라지지 않더라도 업무 경험은 나아질 수 있습니다. 경험 개선은 기록할 가치가 있지만, 그만큼의 인건비 예산을 절감한 것처럼 바꿔 써서는 안 됩니다.

저희는 세 가지 질문을 따로 분명하게 묻는 편을 선호합니다. 같은 작업을 더 빨리 끝냈는가, 같은 기준에 도달하는 데 사람의 노력이 얼마나 들었는가, 완료한 작업이 할 만한 가치가 더 컸는가입니다. 이를 하나의 "효율 향상 배수"로 합치면 오히려 팀이 일하는 방식을 조정하는 데 가장 도움이 되는 정보를 잃게 됩니다.

팀 단위로 평가한다면, 먼저 "완료"부터 정의하기

새 도구를 도입하기 전에 합의된 완료 기준을 정해 두세요. 예를 들어 API 연동 작업이라면 정상 경로가 동작하고, 주요 실패 상황을 설명할 수 있으며, 필요한 테스트를 통과하고, 인수인계받는 사람이 한계를 이해하는 것을 요구할 수 있습니다. 프로젝트에 따라 조건을 더하거나 뺄 수는 있지만, AI 결과물을 본 뒤 결과를 좋아 보이게 하려고 기준을 낮춰서는 안 됩니다.

다음으로 두 종류의 시간을 따로 기록하세요. 첫째는 작업 시작부터 검수까지 걸린 경과 시간으로, 대기 시간을 포함합니다. 둘째는 실제로 사람이 투입한 시간으로, 요구 사항 이해, 컨텍스트 준비, 리뷰, 재작업을 포함합니다. 여러 에이전트가 동시에 실행될 때 개별 머신의 실행 시간(분)을 그대로 더해 사람의 작업 시간으로 볼 수 없으며, 대기 시간을 모두 절약한 시간으로 계산할 수도 없습니다.

파일럿을 시작할 때는 다음 필드만 담은 기록으로도 충분합니다:

• 작업 유형, 복잡도 평가, 구성원의 코드베이스 숙련도.
• 사용한 도구와 버전, AI 지원 여부, 최종 승인 책임자.
• 첫 버전 생성 시점, 정해진 완료 기준에 도달한 시점, 실제 사람의 투입 노력.
• 리뷰에서 발견된 문제, 재작업 횟수, 이후 발견된 결함.
• 작업의 비즈니스 목적, 최종 채택 여부, 채택되지 않았다면 그 이유.
• 중단되거나 실패했거나 자발적으로 포기한 작업도 기록에서 빠져서는 안 됩니다.

이 체크리스트는 저희가 권장하는 평가 방법이며, METR 실험을 재현한 것이 아니고 작은 표본에서 유의미한 결론을 보장하지도 않습니다. 주된 목적은 작업이 생성, 검증, 인수인계 중 어느 단계에서 막히는지 드러내는 것입니다.

현재 마찰이 대부분 인터페이스 불일치에서 비롯된다면, 더 강력한 모델로 바꿔도 문제가 해결되지 않을 수 있습니다. 예를 들어 SDK가 요청을 구성할 수 있다고 해서 서비스가 같은 파라미터나 응답 방식을 지원하는 것은 아닙니다. 사이트의 OpenAI SDK와 Gemini 마이그레이션 경계에서 이런 호환성 판단을 다루며, 이러한 연동 제약도 파일럿 작업의 완료 기준에 포함해야 합니다.

작은 표본은 홍보용 수치가 아니라 의사결정에 쓰여야 한다

일정 기간 평가한 뒤에는 결과를 작업 유형별로 나눠 보세요. 위험이 낮고 구조가 명확한 작업에서는 사람의 노력이 줄었지만 여러 모듈에 걸친 수정에서는 리뷰가 늘었다면, 다음 단계는 모든 작업에서 일괄적으로 사용을 늘리거나 중단하는 것이 아니라 AI 사용 범위를 조정하는 것일 수 있습니다.

결과를 검토할 때는 작업 난이도와 품질 요구 사항이 바뀌었는지도 확인하세요. 예전에는 오류 처리까지 완전히 해야 했던 작업이 지금은 정상 경로만 완성한다면 둘을 직접 비교해서는 안 됩니다. 예전에는 바로 인계할 수 있는 계획 하나를 내던 작업이 지금은 채택되지 않는 초안 10개를 만든다면, 산출물 증가를 개수만으로 판단해서는 안 됩니다.

도구 비용도 하나의 차원으로 볼 수 있지만, 사람의 리뷰, 실패 후 재작업, 유지보수 투입과 함께 봐야 합니다. 신뢰할 만한 기록이 부족하다면 API 호출 수나 생성된 코드 줄 수를 투자 수익으로 포장하지 말고, 지금은 계산할 수 없다고 인정하세요. 작업 적합성, 실패 시 동작, 비용 지표를 함께 비교하는 방법은 API 선택 가이드를 참고하세요.

METR에는 오해받기 쉬운 연구 결과를 어떻게 전달할지 다룬 과학 커뮤니케이션 노트도 있습니다. 기업 콘텐츠도 마찬가지입니다. 독자가 적합성을 판단하도록 돕는 데는 가장 눈에 띄는 숫자를 고르는 것보다 매력 없어 보이는 한계를 남겨 두는 편이 대개 더 효과적입니다.

"AI 코딩이 효율을 높이는가"라는 질문은 의견 글이 하나 더 나온다고 해서 하나의 답을 갖게 되지는 않습니다. 하지만 팀은 이 질문을 더 답하기 쉬운 형태로 바꿀 수 있습니다. 어떤 작업 유형, 도구 버전, 완료 기준에서 사람의 노력이 줄었는지, 품질이 달라졌는지, 결과가 실제로 채택되었는지를 묻는 것입니다. 작업과 동떨어진 효율 배수를 두고 논쟁하기보다, 이처럼 범위가 정해진 답을 먼저 얻은 뒤 도구 사용 확대를 결정하는 편이 더 유용합니다.