이 글은 Bjorn Roche의 “The AI productivity gap”에서 시작되었습니다. 아래 언급된 백분율은 저자의 예시 모델이며, 보편적인 측정치는 아닙니다.

AI는 한 단계를 가속화할 뿐 — 전체 업무를 가속화하는 것은 아니다

기술 기업들 사이에는 반복되는 기대치가 있습니다. 만약 AI가 코드를 훨씬 더 빠르게 작성한다면, 전체적인 결과물(deliverables) 또한 비슷한 속도로 나타나야 한다는 것입니다. 이 전제는 직관적으로 보이지만, 실제 엔지니어링 업무의 구성 요소에 부딪히게 됩니다.

새로운 코드를 작성하는 것은 업무의 일부일 뿐입니다. 그전에 누군가는 불완전한 요구사항을 이해하고, 시스템의 동작을 조사하며, 솔루션의 한계를 결정하고, 다른 사람들과 선택 사항을 협상해야 합니다. 그 후에는 코드 읽기, 디버깅 (debugging), 리뷰 (review), 테스트 (testing), 통합 (integration), 배포 (deploy), 문서화 (documentation) 및 회의가 이어집니다. AI는 이미 이러한 여러 단계에서 도움을 주고 있지만, AI의 이점은 전체 소요 시간이 보통 더 짧은 지점, 즉 비교적 정의된 의도를 코드로 변환하는 과정에서 가장 명확하게 나타납니다.

특정 활동을 가속화하는 것과 전체 흐름(flow)을 가속화하는 것 사이의 이러한 차이가 바로 AI 생산성 격차입니다.

Roche의 모델: 시니어는 15%, 주니어는 25%

Roche는 간단한 연습을 제안합니다. 시니어 개발자의 경우, AI 도입 전 새로운 코드를 작성하는 데 하루 1.5시간이 소요된다고 추정합니다. 설령 도구가 이 시간을 30분으로 줄여준다고 가정하더라도(매우 공격적인 속도 향상임에도 불구하고), 일일 총 업무 시간은 8시간에서 6.75시간으로 줄어듭니다. 절약된 시간은 1.25시간으로, 약 15%입니다.

주니어 개발자의 예시 시나리오에서는 코드 작성에 더 많은 시간이 집중되어 있습니다. AI 도입 전 2.75시간에서 도입 후 1시간으로 줄어듭니다. 이 경우 하루 업무 시간은 8시간에서 6시간으로 줄어들어, 25%의 이득을 얻게 됩니다.

이 수치들을 벤치마크 (benchmark)로 취급해서는 안 됩니다. 이 예시의 핵심은 계산 방식에 있습니다. 즉, 전체적인 영향력은 도구가 실제로 가속화하는 프로세스의 비중에 의해 제한된다는 점입니다. 만약 사이클의 70%가 여전히 해석, 결정, 조정 및 검증을 요구한다면, 코드 생성 단계에서의 국소적인 개선이 자동으로 3배 더 빠른 생산 공장으로 이어지지는 않습니다.

병목 현상은 공유된 추론 (shared reasoning)에 있다

숙련된 업무에서는 사람이 빠르게 타이핑한다고 해서 시간이 사라지는 것이 아닙니다. 시간은 아직 준비된 답이 없는 질문들로 흘러갑니다. 어떤 문제를 해결할 가치가 있는지, 어떤 데이터가 신뢰할 수 있는지, 어떤 변경이 다른 영역을 망가뜨릴 수 있는지, 무엇을 단순화할지, 팀에게 무엇을 설명할지, 그리고 프로덕션 (production) 환경에서 결과를 어떻게 검증할지와 같은 질문들 말입니다.

이러한 작업들은 국소적인 컨텍스트 (context), 분산된 결과, 그리고 종종 모호한 요구사항을 가집니다. AI는 대안을 탐색하고, 신호를 요약하며, 초안을 생성하는 데 도움을 줄 수 있습니다. 그럼에도 불구하고, 요약본이 중요한 조건을 놓치지는 않았는지, 계획이 아키텍처 (architecture)에 부합하는지, 그리고 변경 사항이 사용자에게 안전한지를 누군가는 반드시 인지해야 합니다.

또한 생산성 보고서에서 흔히 누락되는 비용이 있는데, 바로 AI로 생성된 저품질 콘텐츠입니다. 지나치게 긴 사양서, 목적이 불분명한 작업, 또는 완벽해 보이지만 결정 사항을 숨기고 있는 문서 등은 작성자의 시간을 읽고 실행해야 하는 사람의 시간으로 전가할 수 있습니다. 다른 사람의 업무량을 늘리는 개인의 이득은 시스템의 이득이 아닙니다.

이것이 채용에 관한 논의를 바꾸는 이유

만약 AI가 주니어 전문가들이 비례적으로 더 많은 시간을 소비하는 단계에서 더 많은 도움을 준다면, "더 이상 주니어를 채용할 필요가 없다"는 결론은 주의가 필요합니다. Roche의 주장은 이와 반대입니다. 이들은 AI를 이해력을 대체하는 수단이 아니라 학습, 검토 및 실험을 위한 도구로 사용할 때 큰 혜택을 얻을 수 있습니다.

건강한 팀은 문제를 분해하고, 정확하게 도움을 요청하며, 결과물을 검토하고, 경험(repertório)을 쌓을 수 있는 유능한 인재를 계속 양성해야 합니다. 신규 전문가의 유입을 줄이는 것은 이번 분기에는 효율적으로 보일 수 있지만, 미래에는 경험의 결핍을 초래할 수 있습니다.

코드 카운팅의 함정에 빠지지 않고 생산성을 측정하는 방법

생성 속도를 목표로 삼는 대신, 리더십은 다음과 같은 흐름을 관찰할 수 있습니다:

• 업무가 어디에서 대기 중인가? 요구사항, 승인, 환경, 검토 및 인시던트(incident)는 "코드 부족"과는 다른 병목 현상을 보여줍니다.
• 절약된 시간이 품질로 돌아왔는가? 더 유용한 테스트, 더 나은 검토, 더 명확한 문서화는 구체적인 결과물입니다.
• 도구가 업무를 줄였는가, 아니면 재배치했는가? 자료를 생성하는 사람과 그 이후에 이를 해석, 검토 및 수정해야 하는 사람을 비교해 보십시오.
• 팀이 학습했는가? 아무도 유지보수할 수 없는 빠른 결과물은 다음 변경 시점에 이자(비용)를 청구하게 됩니다.

AI는 시간이 지남에 따라 업무의 더 많은 부분을 개선하는 경향이 있습니다. 그때까지 가장 유용한 기대치는 마법 같은 생산성 도약이 아닙니다. 추가적인 속도를 활용하여 학습 주기를 단축하고, 기계적인 작업을 줄이며, 여전히 기술적 판단과 협업에 의존하는 영역에 더 많은 공간을 확보하는 것입니다.

출처: Bjorn Roche — The AI productivity gap.