Agoda의 엔지니어링 팀은 AI 코딩 도구를 홍보하는 데 상당한 시간을 투자한 후 회고를 진행했다. 결론은 다소 불편하다.
개인 개발자 효율성은 향상되었지만, 프로젝트 전체 전달 속도는 거의 변하지 않았다.
이것은 Agoda만의 문제가 아니다. Faros AI는 여러 회사의 데이터를 종합하여 놀라운 수치를 제시했다.
AI 채택률이 높은 팀은 PR 병합량이 98% 증가했고, 작업 완료량이 21% 증가했다. 그러나 동시에 PR 리뷰 시간은 91% 증가했다.
산출량은 늘었지만 리뷰는 느려졌다. 두 효과는 거의 상쇄된다.
진짜 병목 현상은 무엇인가
Agoda 엔지니어링 팀의 판단은 "코딩은 소프트웨어 전달의 주요 병목 현상이 결코 아니었다"는 사실에 문제가 있다는 것이다.
AI 자동 완성으로 코드 작성 속도가 빨라졌다. 하지만 코드 작성은 파이프라인의 한 단계일 뿐이다. 그 앞에는 요구사항 분석, 시스템 설계, 기술 방안 조정이 있고, 뒤에는 코드 리뷰, 테스트, 통합, 배포가 있다.
중간 단계의 속도를 세 배로 높인다고 해서 전체 파이프라인이 세 배 빨라지는 것은 아니다.
AI로 인해 코드 산출량이 폭증하면 "이 코드를 소화하는" 능력이 새로운 걸림돌이 된다.
- 각 PR의 코드 양이 늘어난다(AI가 생성한 코드는 종종 간결하지 않다)
- 코드 리뷰에서 검토해야 할 것이 더 많아진다
- 하지만 시니어 엔지니어의 시간은 한정적이다
병목 현상이 "코드 작성 속도 저하"에서 "코드 리뷰 속도 저하"로 이동했으며, 실제 전달 속도는 개선되지 않았다.
더 깊은 문제: 명세(Specification)
Agoda의 엔지니어 Leonardo Stern은 더 나아가 진정한 희소 자원이 리뷰가 아니라 명세, 즉 모호한 비즈니스 요구사항을 명확하고 실행 가능한 기술 사양으로 변환하는 능력이라고 주장한다.
이전에는 엔지니어가 코드를 작성하는 데 많은 시간을 할애했기 때문에 명세가 다소 모호해도 "작성하면서 명확해졌다".
이제 모호한 요구사항을 AI에 던지면 AI는 "사용 가능해 보이지만" 방향이 잘못된 코드를 생성한다. 그런 다음 명세를 수정하고 AI가 다시 생성하며, 이 과정을 반복한다. 표면적으로는 코드 산출량이 높지만, 실제로는 코드로 시행착오를 겪고 있으며 효율성이 높지 않다.
충실도가 높은 요구사항 명세가 핵심 엔지니어링 산출물이 되고 있다. 코드 자체가 아니라 '무엇을 원하는지 설명하는 방법'이 중요하다.
Stern의 '그레이 박스' 접근법
Stern은 두 가지 극단 사이에 위치한 '그레이 박스'라는 작업 방식을 제안했다.
- 화이트 박스: AI가 생성한 모든 코드 라인을 검토하며, 구현 세부 사항에 대해 완전한 책임을 진다
- 블랙 박스: AI가 작성한 코드를 바로 배포하며, 결과에 대해 책임을 지지만 프로세스에는 관여하지 않는다
- 그레이 박스: 두 가지 핵심 지점, 즉 정확한 명세 작성과 결과가 명세와 일치하는지 검증에 개입한다
그레이 박스의 핵심 논리는 AI가 문제를 해결하기 위해 어떤 방법을 사용하는지 이해할 필요는 없지만, '무엇이 해결된 것으로 간주되는지' 명확히 말할 수 있고 그것이 실제로 해결되었는지 검증할 수 있어야 한다는 것이다.
이 방법의 본질은 엔지니어의 시간과 주의를 AI가 가장 취약한 부분, 즉 의도 정의와 결과 검증에 집중시키고 구현 세부 사항에는 집중하지 않도록 하는 것이다.
엔지니어의 역할은 어디로 가고 있는가
전통적인 소프트웨어 엔지니어 역할의 가정에서는 '좋은 코드를 작성하는 것'이 핵심 경쟁력이었다.
이제 그 가정이 흔들리고 있다. AI가 품질 좋은 코드를 작성할 수 있을 때, 엔지니어의 희소성은 어디서 오는가?
Agoda와 같은 회사의 사례를 보면, 답은 다음 방향으로 움직이고 있다.
- 비즈니스 문제를 정확한 기술 사양으로 변환할 수 있는 사람
- 효과적인 검증 계획을 설계할 수 있는 사람
- AI가 생성한 코드가 실제로 올바른 문제를 해결하는지 판단할 수 있는 사람
이는 '코드를 작성하는 능력이 더 이상 중요하지 않다'는 의미가 아니다. 코드 작성 능력은 희소 자원에서 기본 요건으로 이동했으며, 진정한 차별화는 더 상류에 있다는 의미다.
Stern의 말을 빌리자면: 인간의 권위가 '코드 작성'에서 '의도 정의'로 이동하고 있다. 이는 추상화 수준의 상향 이동이지, 기술의 소멸이 아니다.
경영진은 이 문제를 어떻게 봐야 하는가
엔지니어링 관리자에게 Agoda의 연구는 직접적인 행동 지침을 제공한다. AI의 가치를 코드 산출량으로 측정하지 마라.
PR 수, 코드 라인 수, 작업 완료 수는 모두 AI 도구 덕분에 좋아 보일 것이다. 하지만 전달되는 기능이 늘지 않고, 빨라지지 않았으며, 품질이 개선되지 않았다면, 이 숫자는 단지 숫자에 불과하다.
진정으로 추적할 가치가 있는 지표는 기능 출시 주기, 프로덕션 결함률, 요구사항에서 전달까지의 종단 간 시간이다. 이 숫자들은 AI가 실제로 팀을 돕고 있는지, 아니면 단지 GitHub에서 데이터를 부풀리는 데 도움을 주고 있는지 알려준다.
다음에 누군가 PR 병합량을 AI 도구의 ROI로 보고한다면, "그럼 리뷰 시간은 어떻습니까?"라고 물을 수 있다.
출처: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)