AI가 우리 회사 일을 빠르게 만들어 줄 거라고요? 아마 아닐 겁니다

"AI 도입하면 개발 속도 10배"라는 말, 정말일까요?

요즘 어딜 가든 AI 이야기뿐입니다. 경영진 회의에서는 "우리도 AI 도입해서 생산성 두 배 만들자"는 말이 나오고, 개발팀에는 "Copilot 쓰니까 이제 더 빨리 만들어야지"라는 압박이 들어오죠. 그런데 정작 현장에서는 "음... 코드 짜는 건 좀 빨라진 것 같은데, 왜 출시 일정은 그대로지?" 하는 의문이 자꾸 듭니다. Frederick Van Brabant라는 개발자가 쓴 이 글은 바로 그 의문에 대한 정면 반박이에요. 결론부터 말하면, AI는 여러분의 "프로세스"를 빠르게 만들어 주지 않는다는 겁니다.

여기서 말하는 프로세스가 뭐냐면, 코드 한 줄 짜는 행위가 아니라 "아이디어가 떠올라서 → 기획되고 → 디자인되고 → 개발되고 → QA 거치고 → 배포되어서 → 고객 손에 들어가기까지"의 전체 흐름을 말해요. 우리가 흔히 말하는 SDLC(소프트웨어 개발 생애주기)죠. 글쓴이는 이 전체 사슬에서 AI가 단축시키는 구간은 사실 아주 일부에 불과하다고 지적합니다.

병목은 코딩이 아니라 그 앞과 뒤에 있다

생각해 보세요. 새 기능 하나를 만든다고 할 때, 실제로 IDE 열고 코드 치는 시간이 전체의 몇 퍼센트나 될까요? 글쓴이의 경험에 따르면 그 비중은 생각보다 작아요. 대부분의 시간은 요구사항을 정의하는 회의, 디자인 시안 받기, 사이드 케이스 논의, 코드 리뷰 기다리기, QA 환경에 배포해서 테스트하기, 그리고 프로덕션 릴리스 승인 받기에 쓰입니다.

AI가 코드를 30% 빨리 짜준다고 칩시다. 그런데 코딩이 전체 프로세스의 20%라면, 전체 일정은 고작 6% 단축되는 셈이에요. 게다가 AI가 짠 코드는 검토에 더 시간이 걸릴 수 있고, 미묘한 버그를 끼워 넣어서 QA가 길어질 수도 있죠. 글쓴이는 이런 현상을 솔직하게 인정해야 한다고 말합니다. "AI 도입 = 출시 빨라짐"이라는 단순 등식은 현실에서 잘 성립하지 않는다는 거예요.

특히 인상 깊은 지적은 "속도의 병목은 보통 사람과 사람 사이에 있다"는 부분입니다. PM이 기획서를 마무리하는 데 3일이 걸리고, 디자이너가 시안을 그리는 데 일주일이 걸리고, 법무팀 검토가 2주 걸린다면, 개발자가 코드를 하루 만에 짜든 반나절 만에 짜든 전체 일정에는 큰 차이가 없거든요. 흔히 말하는 "이론적 최대치(theoretical maximum)" 개념인데요, 어떤 시스템이든 가장 느린 단계의 속도가 전체 속도를 결정한다는 거예요. 공장의 컨베이어 벨트를 생각하면 쉽습니다. 한 공정만 빨라져 봐야 다른 공정 앞에 재고만 쌓이는 거죠.

그럼 AI는 쓸모없는 걸까?

글쓴이가 AI 반대론자는 아니에요. 오히려 "개별 개발자의 작업 속도"를 높이는 데는 분명히 도움이 된다고 말합니다. 보일러플레이트 코드를 자동으로 채워주거나, 익숙하지 않은 라이브러리의 사용법을 즉석에서 알려주거나, 단위 테스트 코드를 빠르게 뽑아내는 일은 확실히 빨라졌어요. 다만 그것이 조직 전체의 출시 주기 단축으로 연결된다고 착각하지 말자는 게 핵심입니다.

진짜 프로세스를 빠르게 하고 싶다면 AI 도입보다 먼저 봐야 할 것들이 있어요. 예를 들면 의사결정 단계가 너무 많지는 않은지, 코드 리뷰가 며칠씩 방치되지는 않는지, CI/CD 파이프라인이 30분씩 걸리지는 않는지, QA 환경이 부족해서 배포 줄을 서는 건 아닌지 같은 것들이죠. 이런 구조적 문제를 두고 AI만 도입해 봐야 "개발자만 빨라지고 나머지는 그대로"인 기형적 상태가 됩니다.

업계의 비슷한 목소리들

사실 이런 회의론은 점점 늘어나고 있어요. METR이라는 연구 기관에서 발표한 실험에서는 시니어 오픈소스 개발자들이 AI를 썼을 때 오히려 작업 시간이 19% 늘어났다는 결과도 나왔습니다. 본인들은 빨라졌다고 느꼈는데 실제 측정값은 반대였다는 거죠. 코드를 처음부터 생성하는 데는 빨라도, 기존 코드베이스를 이해하고 AI 출력을 검증하고 다듬는 데 더 많은 시간이 들었기 때문이에요.

DORA(DevOps Research and Assessment) 리포트나 Accelerate 같은 책에서 오래전부터 강조한 것과도 일맥상통해요. 고성과 조직의 비결은 "개발자 개인의 타자 속도"가 아니라 배포 빈도, 변경 리드 타임, 장애 복구 시간, 변경 실패율 같은 흐름 지표를 개선하는 거였거든요. AI는 이 중 어느 것 하나를 자동으로 개선해 주지 않습니다.

한국 개발자에게 주는 시사점

한국 IT 조직은 특히 의사결정 단계가 많고 품의 라인이 긴 곳이 많죠. "AI 도입했으니 일정 단축해 달라"는 요구가 위에서 내려오는 경우도 흔할 거고요. 이때 "코드 짜는 시간만 줄어들 뿐 전체 일정은 다른 병목으로 결정된다"는 사실을 데이터로 보여줄 수 있어야 합니다. 자신의 팀에서 최근 출시한 기능 몇 개를 골라 단계별 소요 시간을 측정해 보세요. 코딩 비중이 의외로 작다는 걸 알게 될 거예요.

또 하나, AI 도구를 도입할 때 "개발자 생산성"만 KPI로 잡지 말고, 리드 타임이나 배포 빈도 같은 흐름 지표를 함께 봐야 진짜 효과를 측정할 수 있습니다. 그래야 "AI 썼는데 왜 더 빨라지지 않지?"라는 허망한 결론 대신, 진짜 병목을 찾아 개선할 수 있거든요.