AI로 코드는 늘었는데 소프트웨어 성과는 왜 그대로일까

들어가며: 생성형 AI가 소프트웨어 개발에 도입된 뒤 가장 쉽게 확인되는 변화는 더 많은 코드를 더 빠르게 만들 수 있다는 점이다. 하지만 코드가 늘었다고 해서 사용자가 실제로 이용할 수 있는 소프트웨어도 같은 비율로 늘어나는 것은 아니다. 하버드 연구자 Fiona Chen과 James Stratton이 Jellyfish의 엔지니어링 팀 집계 데이터를 분석한 결과는 이런 직관에 반하는 가능성을 보여준다. AI가 코딩 활동을 늘릴 수는 있지만, 소프트웨어 산출량은 그만큼 증가하지 않을 수 있다는 것이다.

데이터가 보여주는 핵심

제공된 자료에 따르면 분석 대상은 700개가 넘는 소프트웨어 기업이다. commit과 PR 등을 포함한 3억 건 이상의 개별 작업 이벤트와 70만 명이 넘는 직원 기록도 활용됐다. 다만 현재 소재에는 연구의 전체 방법론, 분석 기간, 세부 통계가 포함되어 있지 않다. 따라서 이를 모든 조직에 적용되는 인과관계로 단정하기보다는, AI 도입 이후 개발 프로세스를 점검하게 만드는 중요한 신호로 해석해야 한다.

핵심 내용은 다음과 같다.

• AI는 코드 작성의 부담을 줄이고 변경 또는 커밋의 양을 늘릴 수 있다.
• 변경량이 늘면 코드 리뷰, 테스트, 통합, 유지보수 업무도 함께 증가한다.
• 인간의 Code Review가 여전히 중요한 관문이라면, 새로 생성된 코드는 빠르게 배포되기보다 검토 대기열에 쌓일 수 있다.
• AI의 효과는 코드 라인 수나 생성량이 아니라 PR 처리 시간, 병합, 결함, 릴리스 빈도, 사용자 가치로 측정해야 한다.

병목은 뒤쪽으로 이동한다

기존 개발에서는 코드를 작성하는 시간이 지연의 핵심으로 여겨지는 경우가 많았다. 코딩 보조 도구와 에이전트가 이 단계를 단축하면, 다음에는 리뷰 담당자의 시간이 희소한 자원이 될 수 있다. 리뷰는 문법을 확인하는 작업에 그치지 않는다. 아키텍처의 일관성, 보안 위험, 업무 규칙, 테스트 범위, 장기 유지보수 비용까지 판단해야 한다. 리뷰 인력을 늘리거나 자동화 테스트를 개선하지 않고 변경 우선순위도 정비하지 않는다면, 생성 속도가 빨라져도 대기와 재작업만 커질 수 있다.

코드는 최종 제품이 아니라 중간 산출물이라는 점이 중요하다. 코드가 가치를 가지려면 검증, 통합, 승인, 배포, 유지보수 과정을 거쳐야 한다. AI를 단순히 더 빠른 입력 도구로 사용하면 파이프라인 앞부분의 활동만 늘고 뒷부분의 처리 능력은 그대로 남을 수 있다. 전체 성과를 높이려면 조직의 검토와 배포 체계도 추가된 변경을 감당할 수 있어야 한다.

기업에 주는 의미

기업은 AI 사용률이나 생성 코드량만으로 도입 성과를 설명해서는 안 된다. 코드를 빠르게 만드는 것과 소프트웨어를 더 잘 제공하는 것을 분리해 측정하는 지표가 필요하다. 자동화 테스트, 위험도 기반 리뷰, 작은 변경 단위, 명확한 코드 소유권, 핵심 시스템에 대한 인간의 감독은 실질적인 대응책이 될 수 있다.

개발자에게 AI는 엔지니어링 판단을 없애는 도구가 아니다. 오히려 설계, 리뷰, 우선순위 설정, 복잡성 관리의 중요성을 높일 수 있다. 가장 많은 코드를 만드는 팀보다 가치가 낮은 변경을 빠르게 걸러내고, 신뢰할 수 있는 변경을 실제 소프트웨어로 전환하는 팀이 경쟁력을 가질 가능성이 크다. 현재 소재만으로 Code Review가 유일한 병목이라고 증명할 수는 없다. 그러나 AI 코딩의 다음 단계가 ‘얼마나 많이 작성하는가’에서 ‘조직이 얼마나 안전하게 소화할 수 있는가’로 이동하고 있다는 점은 분명히 시사한다.

출처: OSChina