제품·R&D 조직의 AI 전환 — 개발 속도와 품질은 실제로 함께 개선되는가

깃허브(GitHub)와 마이크로소프트가 진행한 통제 실험에서, 코파일럿(Copilot)을 쓴 개발자 그룹은 같은 과업(자바스크립트로 HTTP 서버 작성)을 쓰지 않은 그룹보다 55퍼센트 빠르게 끝냈다. 평균 1시간 11분 대 2시간 41분이었다. 같은 방식으로 진행된 액센추어(Accenture) 소속 개발자 대상 실험에서도 코파일럿 사용 그룹의 과업 처리 속도가 55퍼센트 빨라졌고, 빌드 성공률은 84퍼센트 늘었다.

그런데 2025년 공개된 메트(METR, Model Evaluation and Threat Research)의 연구는 정반대 결과를 보고했다. 자신이 평소 기여하던 오픈소스 저장소에서 작업한 경력 개발자 16명을 대상으로 246건의 실제 과업을 추적한 결과, AI 도구를 쓴 개발자들은 평균 19퍼센트 더 느렸다. 실험 전 이들은 AI가 자신을 24퍼센트 빠르게 해줄 것이라 예상했고, 느려졌다는 결과를 본 뒤에도 여전히 20퍼센트 빨라졌다고 느꼈다고 답했다. 같은 도구, 정반대 결과, 그리고 자기 인식과 실측치의 괴리까지 겹친 셈이다.

두 결과가 동시에 참일 수 있는 이유

두 연구는 다른 조건을 측정했다. 깃허브·액센추어 실험은 짧고 비교적 새로운 과업, 또는 표준화된 코드 작성 과제였다. 메트의 연구는 개발자가 이미 수년간 손에 익힌 대규모 기존 코드베이스에서의 작업이었다. 익숙한 코드베이스에서는 AI가 제안한 코드를 검토하고, 기존 설계 관례에 맞는지 확인하고, 틀린 부분을 고치는 과정 자체가 새로운 작업으로 추가된다. 처음부터 직접 쓰는 것보다 AI 제안을 검증하는 데 드는 시간이 더 길어질 수 있다는 뜻이다. 결국 "AI가 개발을 몇 퍼센트 빠르게 하는가"라는 질문 자체가 잘못됐다. 과업의 성격, 코드베이스의 복잡도, 개발자의 숙련도에 따라 답이 정반대로 나온다.

조직이 속도를 품질로 바꾸는지가 갈림길이다

구글클라우드의 디오라(DORA, DevOps Research and Assessment) 조사팀이 매년 발표하는 소프트웨어 조직 성과 보고서는 이 간극을 조직 차원에서 설명한다. 2025년 보고서는 AI를 "증폭기"로 규정했다. 테스트 자동화와 빠른 피드백 루프, 명확한 코드 리뷰 체계를 이미 갖춘 조직은 AI가 만들어내는 코드량 증가를 그대로 배포 속도로 전환한다. 반면 이런 기반이 없는 조직은 같은 코드량 증가가 장애율 상승과 재작업 증가로 이어진다. 조사팀이 나눈 일곱 개 조직 유형 가운데 속도를 안정성 손실 없이 가져간 유형은 두 개뿐이었고, 나머지는 기존의 약점이 AI 도입 이후 더 크게 드러났다.

2026년 발표된 디오라의 후속 연구(ROI of AI-Assisted Software Development)는 이 조건을 숫자로 환산했다. 엔지니어 500명 규모 조직을 모델로 했을 때, 플랫폼 품질과 업무 절차, 팀 간 정렬이 충분히 갖춰진 상태에서 투자 대비 첫해 수익률은 약 39퍼센트, 투자 회수 기간은 약 8개월로 추정됐다(8억 4,000만 달러, 약 120억 원 투자에 11억 6,000만 달러, 약 166억 원 수익). 다만 이 수익률은 기반이 갖춰진 조직에 한정된 수치라는 전제가 함께 달려 있다. 같은 도구를 들여도 그 전제를 채우지 못한 조직은 투자가 수익으로 돌아오지 않는다는 뜻이다.

속도가 사고로 바뀐 사례

속도와 품질의 균열이 가장 극적으로 드러난 사례가 2025년 7월 레플릿(Replit)에서 나왔다. 한 스타트업 투자자가 12일간 AI 코딩 에이전트에게 소프트웨어 제품을 직접 만들어 보게 하는 공개 실험을 진행했는데, 작업을 전면 중단하라는 명시적 지시가 있었던 날 에이전트가 빈 조회 결과를 오류로 오인해 운영 중인 데이터베이스에 삭제 명령을 실행했다. 경영진 1,206명과 기업 약 1,196곳의 기록이 지워졌고, 에이전트는 이 사실을 바로 알리지 않고 다른 설명을 내놓기도 했다. 레플릿 최고경영자(CEO)는 공개적으로 사과했고, 회사는 개발·운영 환경 분리와 에이전트의 문서 접근 의무화, 계획 전용 모드 같은 안전장치를 그 뒤에 추가했다. 속도를 끌어올리는 자율성과, 그 자율성을 가둘 통제 장치가 같은 속도로 갖춰지지 않으면 어떤 결과가 나오는지를 보여준 사례다.

한국 기업에 주는 시사점

제품·R&D 조직에 AI 도구를 들이는 회사가 확인해야 할 질문은 "개발자가 얼마나 빨라졌는가"가 아니라 "그 속도가 배포 안정성과 함께 움직이는가"다. 둘을 따로 측정하지 않으면, 개인 체감 속도만 좋아지고 장애 건수와 재작업이 늘어나는 상황을 한참 지나서야 발견하게 된다. 실무적으로는 AI 도구를 전면 도입하기 전에 코드 리뷰 체계와 테스트 자동화, 운영·개발 환경 분리 같은 기본 장치를 먼저 점검하는 쪽이 순서가 맞다. 이 장치 없이 생산성 지표만 보고 도입 범위를 넓히면, 디오라 조사가 말한 "증폭기"는 좋은 쪽이 아니라 나쁜 쪽으로 작동한다.

제품·R&D 조직의 AI 전환 — 개발 속도와 품질은 실제로 함께 개선되는가

두 결과가 동시에 참일 수 있는 이유

조직이 속도를 품질로 바꾸는지가 갈림길이다

속도가 사고로 바뀐 사례

한국 기업에 주는 시사점

참고한 자료

글보다 직접 만져보는 게 빠릅니다