「AI로 개발 생산성이 2배가 된다」라는 이야기를 자주 듣게 되었다. 하지만 현장에서 수개월 사용해 보고도 그 정도의 비약적인 변화를 실감하지 못하는 사람이 많을 것이다. 소프트웨어 개발 관리자인 Bjorn Roche가 작성한 「The AI Productivity Gap」은 그 위화감을 소박한 덧셈으로 설명해 주는 기사다. 엔지니어나 테크 리드(Tech Lead)가 AI 도입 효과를 경영진에게 설명하거나, 자신들의 페이스를 재검토할 때 도움이 되는 관점을 제공한다.

이 기사는 AI 코딩 툴을 부정하는 것이 아니다. 오히려 효과는 진짜라고 인정한 상태에서, 「효과가 진짜라 하더라도 개발 전체는 그렇게 빨라지지 않는다」라는 한 단계 더 깊은 이야기를 하고 있다. 이하, 원문 기사의 주장을 정리하고 마지막에 필자(나)의 보충 설명을 덧붙인다.

Roche의 출발점은 심플하다. AI가 빠르게 만드는 부분은 주로 「새로운 코드를 작성하는」 부분이지만, 그 작업은 개발자의 하루 중에서 의외로 작은 비율만을 차지한다.

말하자면 당연한 이야기지만, 놓치기 쉬운 사실이기도 하다. 엔지니어의 시간은 요구사항 이해, 시스템 설계, 코드 리뷰 (Code Review), 후배 지도, 그리고 회의에 상당량이 할애된다. 디버깅 (Debugging)이나 기존 코드의 독해(Reading)도 비중이 크다. 순수하게 신규 코드를 타이핑하고 있는 시간은 생각보다 짧다.

따라서 코딩을 AI로 빠르게 하더라도, 하루 전체로 보면 줄일 수 있는 시간은 한정적이다. 이 부분이 기사 제목에 있는 「생산성의 갭 (Productivity Gap)」의 핵심이다. 툴 단독의 효과와 팀 전체의 아웃풋 (Output) 증가는 동일하지 않다.

Roche는 이 직관을 대략적인 시간 배분 추정치로 보여주고 있다. 어디까지나 설명을 위한 개산(Approximation)이라는 전제로 읽어주길 바란다.

시니어 엔지니어의 하루(8시간)를 다음과 같이 설정한다.

• 코드를 쓰는 시간: 1.5시간 → AI 도입 후 0.5시간
• 그 외(설계, 리뷰, 디버깅, 회의 등): 6.5시간 → 6.25시간

합계로 보면 줄일 수 있는 것은 약 15%에 그친다. 코딩 자체는 3분의 1로 줄어들더라도, 원래 그곳에 사용하던 시간이 적기 때문에 전체에 미치는 임팩트는 작다.

반면, 주니어 엔지니어는 다음과 같다.

• 코드를 쓰는 시간: 2.75시간 → AI 도입 후 1.0시간
• 그 외: 5.25시간 → 5.0시간

이쪽의 감소 폭은 약 25%이다. 주니어는 코딩에 소비하는 비율이 원래 크고, 회의나 리뷰 등의 주변 업무가 적은 만큼 AI의 혜택을 비율로서 크게 받을 수 있다.

숫자 그 자체보다 구조를 파악해 두고 싶다. AI의 효과는 「코딩이 하루에서 차지하는 비율」에 강하게 얽매인다. 이 비율이 큰 사람일수록 전체적인 성장도 커진다.

여기서부터 Roche는 자주 들리는 설을 비꼰다. 「AI가 주니어의 일을 해주니까, 우리 회사는 시니어만 채용한다」라는 것이다.

그의 추정치가 보여주는 것은 반대의 구도다. AI로부터 비율상 큰 이득을 보는 쪽은 주니어이며, 게다가 툴을 단순한 지름길이 아닌 학습 도구로 사용한다면 그 효과는 더욱 늘어난다. AI를 이유로 주니어를 배제한다는 판단은, 혜택이 가장 큰 계층을 놓치는 결과가 될 수 있다.

이 지적은 채용이나 육성 논의와 직결된다. AI가 있기 때문에 오히려 젊은 인재가 배우면서 직접 손을 움직일 수 있는 환경의 가치는 높아지고 있다고도 읽을 수 있다.

기사의 종반부에서는 생성된 문서에 대해서도 짧게 언급하고 있다. AI가 작성하는 문서는 정보를 너무 많이 담으려는 경향이 있어, 인간이 작성한 것보다 읽어내는 데 시간이 더 걸릴 수 있다는 지적이다.

코딩이 빨라지더라도 그 주변에서 읽는 시간과 확인하는 시간이 늘어난다면, 상쇄되는 효과는 더욱 줄어든다. 생산성을 일부분만으로 측정하는 것의 위험성을 다른 각도에서 보강하는 이야기가 된다.

여기서부터는 나(필자)의 견해다. Roche의 숫자는 엄밀한 측정이 아니라 어디까지나 직관을 가시화하기 위한 개산이다. 실제 시간 배분은 직종, 팀, 다루는 기술에 따라 크게 달라지며, AI가 리뷰나 디버깅을 빠르게 할 여지도 있다. 따라서 15%나 25%라는 값을 액면 그대로 사용하는 것은 피하고 싶다.

그럼에도 이 기사의 뼈대는 실무에서 유효하다고 생각한다. 생산성을 측정하려면 코딩 단독이 아니라 하루 전체를 봐야 한다. 병목 현상 (Bottleneck)이 회의나 리뷰에 있다면 그 부분을 개선하지 않는 한 AI만으로는 극적인 변화가 일어나지 않는다. 툴의 효과와 조직의 아웃풋을 혼동하지 말 것. 이 세 가지 점은 AI 투자 기대치를 현실적으로 유지하는 데 있어 짚어둘 가치가 있다.

화려한 비약이 아닌 착실한 상향. 그것이 이 기사의 차분한 결론이며, 과도한 기대에 휘둘리지 않기 위한 좋은 보조선이 된다. 🧭

출처: Bjorn Roche의 「AI 생산성 격차 (The AI Productivity Gap)」(뉴스레터 『Leadership in Tech』에서 소개됨)

원문: https://bjorg.bjornroche.com/management/ai-productivity-gap/