인공지능(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가 생성한 코드를 사용합니다. 그들은 생성된 코드를 보고, "아, 저게 바로 내가 필요한 넛지였어, 여기서부터 사용해야겠어"라고 말합니다.
구현과 팀 역학의 중요성
생산성 향상이 실현되는 방식은 ‘AI 도구 구현 방식’과 ‘개발자 역학 관계’에 따라 달라집니다. 일부 개발자가 기술을 불신하거나 ‘AI가 오류를 잡아낼 걸’로 기대하여 리뷰가 느슨해지면 품질이 저하될 수 있습니다. 또한 AI 도구를 도입하면 코드 리뷰, 테스트, 문서화와 같은 프로세스를 변경해야 할 때가 많습니다. 팀이 새로운 워크플로에 적응하는 동안 이득을 보기 전에 일시적으로 생산성은 떨어질 수 있습니다. 조직은 AI 도구를 구현할 때, 생산성 향상을 확인하기 전에 ‘생산성 지표가 이 시행착오 기간에 하락할 수 있음’을 고려하며, 팀이 이 도구의 작동 방식과 워크플로 적용 방식을 파악하는 시간을 확보해야 합니다.
이러한 균형을 맞추려면 정확도와 일관성이 높은 작업을 정의하고, 적어도 처음에는 해당 사용 사례에 AI를 사용하도록 팀을 교육해야 합니다. AI 코드 생성은 스캐폴딩과 테스트 생성, 구문 수정, 문서 생성에 유용합니다. 팀이 이 작업을 시작하면 더 나은 결과를 얻고, 더 효과적인 도구 사용 방법을 배울 수 있습니다. ‘AI의 영향력을 일주일 만에 측정할 수 없다’는 걸 기억하세요. 팀이 AI 어시스턴트와 함께 리듬을 찾는 시간을 줘야 합니다.
도전 과제 있어도 ‘AI=미래’
지금까지 AI 영향력 측정의 어려움과 잠재 위험을 이야기했지만, GitLab은 ‘AI가 DevSecOps 플랫폼의 진화에 큰 역할을 한다’고 믿습니다. 이것이 바로 GitLab Duo를 구축하는 이유입니다. 그러나 수락률이나 생성된 코드 줄 수를 제시하면서 생산성 측정을 서두르지는 않을 것입니다. 이는 이전의 생산성 사고방식에서 한 걸음 후퇴한 겁니다. 대신 통합 DevSecOps 플랫폼 속 데이터를 살펴보면서 AI 영향력의 완전한 그림을 제시하고자 합니다.
대신 측정할 항목
AI 개발자 도구의 생산성 영향력을 측정하려면 고립된 생산성 지표보다 엔드투엔드 결과에 집중하고, 미묘한 차이를 파악해야 합니다. 그러나 단순한 정량 지표는 AI 개발자 도구로 생산성을 측정할 때 미묘한 차이를 놓치는 경향이 있습니다. 핵심은 ‘AI가 일상 경험에 실제로 미치는 영향과 장기적인 개발 관행을 형성하는 방식’에서 개발자의 정성 피드백과 소프트웨어 개발 라이프사이클(SDLC) 전반의 정량 데이터를 결합하는 것입니다. 그래야만 이러한 도구의 생산성 향상 효과를 정확하게 파악할 수 있습니다. GitLab은 AI를 올바른 방식으로 일하는 걸 대체하는 게 아닌, DevSecOps 도입을 증진하는 수단으로 봅니다. ‘SDLC 관행에서 올바른 근육을 키우는 데 집중하는 조직’이 개발자 코딩 생산성의 잠재 이점을 실제로 활용하는 가장 좋은 위치에 있습니다.
그렇다면 어떤 지표를 대신 사용해야 할까요? GitLab에는 이미 아이디어에서 프로덕션에 이르는 작업의 엔드투엔드 흐름을 조사하여 병목 지점을 파악하는 Value Stream Analytics가 있습니다. Value Stream Analytics는 단일 측정이 아니라 리드 타임, 사이클 타임, 배포 빈도, 프로덕션 결함과 같은 지표를 지속적으로 추적합니다. 이는 개발자 활동보다 비즈니스 성과에 집중합니다. 코드 품질, 협업, 다운스트림 비용, 개발자 경험 전반에 전체적 관점을 취하면서 팀은 이러한 기술이 장기적으로 인간 능력을 대체하는 게 아니라 증강하도록 조정할 수 있습니다.
GitLab의 AI Impact 접근 방식 소개
GitLab은 ‘전체 SDLC를 아우르는 통합 DevSecOps 플랫폼이 되겠다’는 큰 그림이 있습니다. 더 나은 소프트웨어를 더 빠르게 출시하는 지표와 인사이트를 사용해 팀의 역량을 강화하고자 Value Stream Management를 구축했습니다. GitLab Value Stream Analytics와 DORA 지표, GitLab Duo 사용 데이터를 결합하 여 조직에 ‘AI가 SDLC에 미치는 영향’을 완전한 그림으로 제공할 수 있습니다. GitLab은 이 대시보드를 ‘AI Impact’라고 부르는데, ‘GitLab Duo가 생산성에 미치는 영향’을 측정하도록 곧 출시할 예정입니다. 진행 상황을 확인하고 개발 이슈에 피드백을 공유해 주세요.
맺음말
지금까지 AI 생산성 도구의 영향력을 측정하기 어려운 이유와 이를 잘 측정하기 위해 유의할 점을 살펴봤습니다. 아울러 이 한계를 보완하기 위해 GitLab이 개발 중인 ‘AI Impact’ 대시보드를 알아봤습니다. 이 글의 요점은 다음과 같습니다.
첫째, AI 생산성 도구의 영향력을 측정하는 일은 복잡하며, 단순한 지표만으로는 불충분합니다.
둘째, 이 도구의 영향력을 측정할 때 코드 줄 수나 AI 제안의 수락률 등 지표보다 비즈니스 성과에 초점을 맞추어야 합니다.
셋째, 이 도구를 사용할 때 개발 속도를 높일 수 있지만 품질과 유지보수성을 저하해선 안 됩니다.
넷째, 이 도구의 영향력을 잘 측정하려면 다음 두 가지를 잘 결합해야 합니다. SDLC 전반의 정량 데이터, ‘AI가 일상 개발 경험에 미치는 영향과 장기적으로 개발 관행을 형성하는 방식’과 같은 개발자의 정성 피드백입니다.
다섯째, 현재 GitLab은 'AI Impact'라는 대시보드를 개발하고 있습니다. 이는 ‘GitLab Duo가 생산성에 미치는 영향’을 측정하는 기능을 제공할 예정입니다.
이 블로그에는 향후 출시될 제품, 특징, 기능 정보가 포함되어 있습니다. 이 블로그 게시물의 목적은 오직 ‘정보 제공’임을 유의하세요. 구매 또는 계획 수립을 목적으로 이 정보에 의존하지 마세요. 모든 프로젝트와 마찬가지로 이 블로그 및 링크된 페이지에 언급된 사항은 변경되거나 지연될 수 있습니다. 제품, 특징 또는 기능의 개발, 출시 및 시기는 GitLab의 단독 재량에 따라 결정됩니다.
이 포스트는 GitLab의 동의를 받아 공식 블로그의 영문 포스트를 우리말로 번역한 글입니다.