-
AI를 붙였는데 왜 더 느려졌을까 — 생산성 J-커브라는 구덩이IT 2026. 7. 19. 21:00
AI 코딩 도구를 팀에서 사용할 수 있게 된다. 다들 코드를 빨리 쓴다고 좋아한다. 그런데 분기 지표를 열어 보니 배포 처리량은 오히려 줄고, 장애는 늘어난다. "뭘 잘못한 걸까" 싶은 순간이다. 결론부터 말하면, 이건 흔한 경로다. 잘못한 게 아니라 거쳐야 하는 구덩이를 지나는 중이다.
체감은 올랐는데 측정값은 먼저 떨어진다
구글의 DORA(DevOps Research and Assessment, 소프트웨어 개발과 배포 성과를 해마다 정량 측정하는 연구 프로그램)가 2024년 리포트에서 실측한 숫자가 있다. AI 도입이 25% 늘어날 때, 배포 처리량(throughput, 얼마나 자주 빨리 배포하는가)은 약 1.5% 줄고, 배포 안정성(stability, 배포가 장애 없이 안정적인가)은 약 7.2% 떨어졌다. 같은 조사에서 응답자의 75.9%가 업무 일부에 이미 AI를 쓰고 있다고 답했고, 75%가 생산성이 올랐다고 느꼈다. 손끝의 체감은 올랐는데 팀의 전달 지표는 내려간 것이다.
이 어긋남이 글의 출발점이다. 직관은 "좋은 도구를 넣었으니 숫자도 올라야지"라고 말하지만, 실제 데이터는 한동안 반대로 움직였다. 왜 이게 오히려 자연스러운지를 풀어 본다.
곡선은 곧바로 위로 가지 않는다 — J-커브
다이어그램 설명. 새 기술을 들이면 성과 곡선이 곧바로 우상향하지 않는다. "AI 도구 도입" 직후 "초기 생산성 하락 — 구덩이" 구간을 먼저 지나고, "적응 — 학습·결과 검증·워크플로우 재설계"를 거친 뒤에야 "생산성 이륙"에 닿는다. 알파벳 J자를 닮은 궤적이라 J-커브라 부른다. 핵심은 구덩이가 실패의 신호가 아니라 경로의 일부라는 점이다. 가장 흔한 오해는 도입하자마자 곡선이 뛸 거라 기대하는 것인데, 그 기대가 정상적인 구덩이 구간을 "실패"로 오독하게 만든다.
구덩이의 정체 — 빨라진 손이 더 큰 위험을 만든다
다이어그램 설명. DORA가 안정성 하락의 원인으로 지목한 연결 고리를 풀어낸 그림이다. "AI가 코드 작성을 쉽게 만든다"가 출발점이고, 손이 빨라지니 "한 번에 커지는 변경 묶음"으로 이어진다. 한 번에 합치는 변경이 클수록 "커진 변경에 비례해 늘어나는 위험"이 따라오고, 그 끝이 "배포 안정성 하락"이다. 같은 리포트는 작은 변경 묶음(small batch, 한 번에 합치는 코드 양을 작게 쪼개는 것)과 탄탄한 테스트라는 기본기가 여전히 안전장치라고 짚는다. 놓치기 쉬운 점은 원인이 AI 코드의 품질이 아니라는 것이다. AI가 만든 코드를 못 믿겠다는 응답이 39.2%였지만, 진짜 범인은 불신이 아니라 묶음이 커진 데 있다.
구덩이를 메우는 세 가지 적응
구덩이가 깊고 얕은 차이는 적응 속도에서 갈린다. 첫째는 학습 곡선이다. 새 도구에 어떻게 지시해야 잘 듣는지, 어떤 작업에 통하고 어떤 작업엔 안 통하는지 감을 익히는 데 시간이 든다. 둘째는 결과 검증 부담이다. AI가 빨리 내놓은 코드를 사람이 다시 읽고 의심하고 고치는 비용이 새로 생긴다 — 작성은 빨라졌지만 검증이라는 일이 통째로 늘었다. 셋째는 워크플로우 재설계다. 코드 리뷰 방식, 변경을 작게 쪼개는 규칙, 테스트 자동화처럼 일하는 순서 자체를 다시 짜야 효과가 붙는다.
이 세 가지는 새로 등장한 숙제가 아니다. 경제학자 브린욜프슨과 동료들은 2021년 논문에서 범용 기술(general purpose technology, 전기나 컴퓨터처럼 모든 산업에 두루 퍼지며 후속 혁신을 끌어내는 기반 기술)이 효과를 내려면 눈에 잘 안 보이는 보완 투자가 반드시 필요하다고 정리했다. 업무 프로세스 재설계, 새 제품과 방식의 공동 발명, 사람에 대한 교육이 그것이다. 이 투자는 회계 장부에 잘 안 잡혀서, 초기에는 생산성이 실제보다 낮게 측정되고 나중에 열매를 거둘 때 높게 측정된다 — 그래서 곡선이 J자를 그린다.
더 오래된 사례도 있다. 1987년 경제학자 로버트 솔로는 "컴퓨터 시대는 어디서나 보이는데 생산성 통계에서만 안 보인다"고 꼬집었다. 컴퓨터가 사무실에 깔린 뒤에도 생산성 지표는 한참 잠잠하다가, 조직이 일하는 방식을 바꾸고 기술이 충분히 퍼진 1990년대에야 뚜렷이 올랐다. 도입과 효과 사이의 시차는 신기술의 예외가 아니라 기본 속성에 가깝다.
"우리만 느린 게 아니다" — 기대 관리가 핵심
개인이 AI를 자기 일에 들이는 과정도 똑같이 J자를 그린다. 처음 몇 주는 오히려 손이 더 가고, 결과를 못 믿어 두 번 일하고, 어디에 써야 할지 몰라 헤맨다. 이 구간에서 "AI 별거 없네"라며 손을 떼면 이륙 직전에 곡선을 버리는 셈이다. 구덩이를 끝까지 통과한 사람만 J자의 위쪽을 만난다.
조직 차원에서 가장 위험한 건 기술이 아니라 기대다. 도입하자마자 지표가 뛸 거라고 약속하면, 정상적인 구덩이 구간이 "도입 실패"로 보고된다. 경영진에게 전해야 할 메시지는 분명하다. 초기 하락은 손실이 아니라 통행료이며, 측정값이 잠시 내려가는 건 적응이 진행되고 있다는 신호다. "우리 조직만 느린 게 아니다"라는 한 문장이, 구덩이를 견디고 이륙까지 가게 하는 가장 값싼 투자다.
참고한 공개 자료:
- DORA | Accelerate State of DevOps Report 2024 — https://dora.dev/research/2024/dora-report/
- Announcing the 2024 DORA report | Google Cloud Blog — https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
- DORA Report 2024 – A Look at Throughput and Stability (RedMonk) — https://redmonk.com/rstephens/2024/11/26/dora2024/
- Brynjolfsson, Rock, Syverson, "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies" (NBER w25148) — https://www.nber.org/papers/w25148
- Productivity paradox — Wikipedia — https://en.wikipedia.org/wiki/Productivity_paradox
- The Solow Productivity Paradox (Brookings) — https://www.brookings.edu/articles/the-solow-productivity-paradox-what-do-computers-do-to-productivity/
이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.
'IT' 카테고리의 다른 글
AI 결과물을 믿게 만드는 검증 3종 — 이진·정량·정성, 그리고 운영 중 검증 (0) 2026.07.20 AI 시대의 일하는 법 — 생산은 AI에게 넘기고 사람은 검증에 집중한다 (0) 2026.07.20 의도부채(Intent debt) — 혼자 에이전트와 일할 때 사라지는 것 (0) 2026.07.20 생성 속도는 전달 속도가 아니다 — AI 코드가 쌓는 새로운 기술부채 (0) 2026.07.19 AI를 켰더니 19% 느려졌다 — 검증세라는 숨은 비용 (0) 2026.07.19 토큰 맥싱(token maxxing)의 함정 — 많이 쓴 사람이 이긴다는 착각 (1) 2026.07.18 AI 도입 후 찾아오는 정체기 — 진짜 벽은 입력과 출력의 마찰이다 (0) 2026.07.18 AI로 10배 더 만드는데, 왜 결과를 아무도 안 믿을까 — 이해부채와 이해의 항복 (0) 2026.07.18 외부 시스템마다 도구를 손으로 만들면 안 끝난다 — OpenClaw가 MCP로 남의 도구를 꽂아 쓰는 법 (0) 2026.07.17 텍스트만 뱉는 에이전트는 그림을 못 그린다 — OpenClaw가 미디어 생성을 프로바이더 추상화로 푼 방법 (1) 2026.07.17