숙련 개발자들이 AI 코딩 어시스턴트를 쓴 결과 실제 작업 속도가 19% 느려졌다. 그런데 당사자들은 20% 빨라진 것 같다고 응답했다. dev.to에 공개된 연구 분석 글이 전한 이 수치 하나가, AI-First 전환을 설계하는 입장에서는 상당히 불편한 질문을 던진다. 우리 팀이 지금 느끼는 생산성 향상, 그게 진짜인가?
이 연구가 특히 무거운 이유는 피실험자 구성 때문이다. 튜토리얼을 따라가는 주니어가 아니라, 자신의 코드베이스를 이미 깊이 알고 있는 숙련 오픈소스 기여자들이 대상이었다. 이미 멘탈 모델이 완성된 사람에게 AI 어시스턴트는 레버리지가 아니라 오버헤드였다. 탭 키로 함수 골격을 순식간에 채우는 도파민은 진짜지만, 그 뒤에 따라오는 생성 코드 검증 4분, 미묘한 환각 디버깅 12분, 엉뚱한 방향으로 끌려가는 컨텍스트 스위치는 뇌가 '속도 비용'으로 인식하지 않는다. 느린 부분이 분산되어 있어서 보이지 않기 때문이다.
조직 차원에서 이 문제는 더 위험하다. 커밋 수, PR 수, 코드 라인 수—바이브 기반 지표는 모두 올라간다. 관리자 눈에는 팀이 활발하게 돌아가는 것처럼 보인다. 그러나 실제 처리량이 19% 내려앉아 있다면, 그 신호는 데드라인이 밀리고 버그 카운트가 쌓이기 시작할 때야 비로소 표면에 드러난다. 느낌이 현실을 덮어버리는 구조다.
공교롭게도 같은 시점에 삼성전자 DX부문이 ChatGPT, Gemini Enterprise, Claude 3종을 동시에 사내 공식 도입했다는 소식이 나왔다. 2,500여 명 규모의 파일럿 검증을 거쳐 업무 특성별로 모델을 선택할 수 있게 구조화했다는 점은 눈여겨볼 만하다. 단일 모델 표준화 대신 '업무 목적에 맞는 AI 선택권'을 준 것은 적어도 '하나 도입하면 다 해결된다'는 환상을 피한 설계다. 하지만 도입 발표에서 빠진 것도 있다. 어떤 지표로 생산성 향상을 측정할 것인가, 그 기준이 공개되지 않았다.
여기서 두 사례가 겹쳐 보이는 지점이 있다. 삼성이 파일럿에서 '실효성 검증'을 했다고 밝혔지만, 그 검증이 체감 만족도 조사였는지 실제 태스크 완료 시간 측정이었는지는 알 수 없다. 19% 느려진 숙련 개발자들도 스스로는 20% 빨라졌다고 느꼈다. 만약 삼성의 파일럿 검증 방식도 자기 보고 기반이었다면, 2,500명 규모의 플라시보를 전사 확장한 셈이 된다.
그렇다고 AI 도구를 쓰지 말자는 이야기가 아니다. 연구 자체도 같은 결론을 낸다. 익숙한 코드베이스에서는 오버헤드가 크지만, 처음 써보는 API, 1년에 한 번 만지는 언어, 본 적 없는 프로젝트 구조—이런 '모르는 것의 모르는 것' 영역에서는 생성 속도가 검증 비용을 압도할 수 있다. AI 어시스턴트를 신입 페어 프로그래머로 대우하는 팀—아이디어와 보일러플레이트는 맡기되, 모든 라인을 신규 입사자 코드 보듯 검토하는 팀—이 실제로 레버리지를 뽑아내는 이유다.
팀 리드로서 지금 당장 할 수 있는 것은 하나다. 측정 방식을 바꾸는 것. 'AI 쓰고 나서 생산성이 올랐나요?'라고 팀원에게 물으면 답은 항상 그렇다고 나온다. 대신 같은 유형의 태스크를 AI 사용 전후로 타이머를 켜고 재라. PR 머지 시간, 버그 재발률, 코드 리뷰 라운드 수—이 숫자들이 체감 속도와 같은 방향을 가리킬 때만 그 AI 도구는 진짜 일하고 있는 것이다.
삼성의 3종 동시 도입이 AI-First 전환의 교과서가 되려면 6개월 뒤가 중요하다. 어떤 모델이 어떤 업무 유형에서 실제 처리량을 높였는지, 어떤 조건에서 오히려 느려졌는지를 데이터로 공개할 수 있을 때—그때 이 사례는 진짜 참고할 만한 구조 설계 사례가 된다. 도구를 켠 것과 도구를 설계한 것은 여전히 다른 이야기다.