인공지능(AI) 기반 생산성 도 구는 ‘반복적인 코딩과 지루한 작업을 자동화하고, 코드를 생성하여 생산성을 향상한다’고 약속합니다. 그러나 조직이 ‘생산성 도구의 AI 영향력’을 측정하는 방법은 아직 제대로 알려지지 않았습니다. 현재 GitLab은 이 문제를 해결할 솔루션을 개발하고 있습니다. ‘AI Impact’라는 ‘Value Stream Analytics’ 기반 대시보드로, 조직이 AI 기능 모음인 ‘GitLab Duo’가 생산성에 미치는 영향력을 이해하는 데 도움이 될 것입니다. AI Impact는 GitLab에서 학습한 AI 영향력 측정 방식의 정점으로, GitLab이 배운 내용을 여러분에게 공유하고자 합니다.
The Pragmatic Engineer 보고서에 따르면, 일반적으로 생산성을 측정하는 일은 간단하지 않고, 전 세계 최고 엔지니어링 팀은 모두 서로 다른 지표를 사용합니다. 모두가 최적화하는 생산성 지표가 다르다면, AI 생산성 도구의 영향력을 어떻게 측정해야 할까요? AI 어시스턴트의 생산성 영향력을 측정하기 어려운 이유와 이 일이 실패하는 이유를 알아봅시다.
결함이 있는 생산성 지표
‘하루에 기여하는 코드 줄 수’나 ‘AI 제안의 수락률’과 같은 단순한 생산성 지표로는 다운스트림 비용을 파악할 수 없습니다. Infoworld 기사에 따르면, GitClear는 "2020년 1월부터 2023년 12월까지 변경된 코드 1억5300만 줄을 분석한 결과, 2024년에는 코드 이탈(작성된 후 2주 이내에 revert 되거나 변경되는 줄의 비율)이 두 배가 될 걸로 예상한다"고 합니다. 따라서 단순히 코드 줄 수를 측정하면 기술 부채가 쌓이고 개발자의 기술이 위축될 위험이 있습니다.
간접적 영향력 정량화의 어려움
AI 개발자 도구의 목표는 개발자가 수고를 덜고 ‘시스템 아키텍처, 설계와 같이 더 가치 있는 작업에 집중하는 것’입니다. 그러나 이렇게 하면 AI가 생성한 코드를 검토, 테스트, 유지 관리하는 데 걸리는 시간과 비교해 얼마나 많은 시간이 절약될까요? 이러한 2차 생산성 향상 효과는 정확히 AI 결과로 보기 어렵기에 가치를 잘못 인식할 수도 있습니다. 해결책은 ‘AI 생산성 도구의 사용 주체를 신중하게 선택하는 것’입니다.
비즈니스 성과 집중의 중요성
궁극적으로 중요한 건 개발자 활동 지표가 아니라 실제 ‘비즈니스 성과’입니다. 리드 타임, 사이클 타임, 프로덕션 결함, 사용자 만족도를 추적하면 ‘병목 현상 위치’를 더 잘 파악할 수 있습니다. AI 도구가 코드를 더 빨리 생성하는데 품질 팀이 변경 사항을 따라잡지 못하면 최종 소프트웨어 제품의 품질은 저하되고, 이는 고객 만족 문제로 이어질 수 있습니다. 더 많은 제품을 출시하는 건 좋게 들리지만 문제 해결에 시간, 비용, 노력이 훨씬 더 많이 들어갈 수 있습니다. 비즈니스 성과를 측정하기란 어렵고, 이러한 측정은 종종 문제의 후행 지표가 되기도 합니다. 품질 결함, 보안 문제, 애플리케이션 성능 측정은 비즈니스에 미치는 영향력을 더 빨리 파악하는 방법입니다.
속도와 품질 간 균형 필요성
AI 코드 생성은 개발 속도를 높이는 잠재력이 있지만, 전반적인 품질과 유지보수성을 희생하면 안 됩니다. 팀은 속도와 실제 비즈니스 문제를 해결하는, 유지 관리할 수 있고 잘 테스트 된 코드를 작성하는 일 사이에 적절한 균형을 유지해야 합니다. 생산성 지표를 최대화하기 위해 품질을 희생하면 안 됩니다. ‘AI가 생성하는 코드 줄 수’나 ‘개발자가 수락하는 AI 제안 수’를 측정하면 문제 있는 결과를 최적화할 수 있습니다. 코드가 더 많다고 반드시 품질이나 생산성이 높아지는 건 아닙니다. 더 많은 코드는 ‘검토, 테스트, 유지 관리할 코드가 더 많다’는 걸 의미하며, 배포 속도가 느려질 수 있습니다.
예를 들어 보겠습니다. AI가 생성한 코드 출력 범위는 ‘개발자가 현재 작업 중인 영역’으로 제한됩니다. 현재 AI 도구는 애플리케이션의 더 넓은 아키텍처(마이크로서비스 아키텍처에서 증폭됨)를 평가하는 기능이 부족합니다. 즉, 생성된 코드의 품질이 좋더라도 더 폭넓은 시스템 변경이 아닌 대상 영역에 삽입되기에 ‘반복 작업’과 ‘코드 부풀리기’가 발생할 수 있습니다. 이는 ‘DRY(반복하지 않기) 원칙’을 사용하는 객체 지향 언어로 설계된 언어에서 문제가 됩니다. 이 분야는 현재 활발히 연구 중이며, GitLab은 AI 기능의 컨텍스트 인식을 향상하기 위해 새로운 접근 방식과 기술을 도입해 기쁩니다.
또 수락률은 오해의 소지가 있을 수 있는데, 안타깝게도 ‘AI 생산성 도구가 성공을 측정하는 주요 방법’이 되고 있습니다. 개발자는 AI가 생성한 제안을 수락한 다음, 이를 대폭 수정하거나 다시 작성해야 할 수도 있습니다. 따라서 최초 수락 여부만으로 ‘제안이 실제로 유용한지 아닌지’ 알 수 없습니다. 수락률은 기본적으로 ‘AI 어시스턴트 품질’을 나타내는 지표이지만, 생산성 지표로 잘못 해석됩니다. 특히 모든 벤더가 수락률을 다르게 측정하고, 이 수치에 기반해 마케팅하면 오해의 소지가 있습니다. GitLab은 이러한 종류의 데이터를 마케팅에 사용하지 않습니다. 실제 경험에 따르면, 개발자는 배우가 신호를 사용하는 방식과 유사하게 AI가 생성한 코드를 사용합니다. 그들은 생성된 코드를 보고, "아, 저게 바로 내가 필요한 넛지였어, 여기서부터 사용해야겠어"라고 말합니다.