"AI가 개발을 3배 빠르게 해준다" — 다들 이 말 믿고 도입했어요.
근데 납기는 왜 그대로일까요?
다들 이렇게 믿죠
믿음 자체는 틀리지 않았어요. GitHub Copilot 도입 연구에서 개발자들은 고립된 코딩 태스크(HTTP 서버 작성 같은 것)를 평균 55% 더 빠르게 완료했어요. Copilot 없이 2시간 41분 걸리던 작업이 1시간 11분으로 줄었어요.
이걸 보면 자연스러운 결론이 나와요. "소프트웨어 개발이 70일 걸리는 프로젝트를 AI로 35일로 줄이자." 타임라인에서 가장 긴 단계를 AI가 압축해주니까요.
근데 데이터가 반대를 가리키고 있었어요
Google의 DORA 팀이 2024년에 발표한 데이터가 흥미로워요. AI 도입으로 개발자 개인의 생산성과 만족도는 올라갔는데, 소프트웨어 전달 안정성과 처리량은 오히려 낮아지는 경우가 관찰됐어요. 개인은 빨라졌는데 팀 전체 결과물의 신뢰성이 떨어진 역설이죠.
이걸 설명해주는 게 "제약이론(Theory of Constraints)"이에요. 핵심 원칙은 간단해요: 어떤 시스템의 전체 성과는 가장 느린 단계 하나가 결정한다. 병목이 아닌 다른 단계를 아무리 빠르게 해봐야 전체 속도는 안 바뀌어요.
그래서 질문을 이렇게 바꿔야 해요: "우리 프로젝트에서 실제로 가장 오래 걸리는 게 진짜 '코딩'인가요?"
병목을 잘못 짚으면
코딩 단계를 AI로 0에 가깝게 줄여도, 요구사항 명확화에 6주가 걸린다면 프로젝트는 6주 미만으로 줄어들지 않아요. 이게 제약이론의 핵심이에요.
도요타가 알고 있던 원칙
이 문제를 정확히 짚은 원칙이 있어요: "병목에는 예측 가능하고 고품질의 입력이 제공되어야 한다." 엘리야후 골드라트의 "The Goal"에서도, 도요타 생산 시스템에서도 반복해서 강조하는 원칙이에요.
"사용자한테 판매 완료되면 이메일 보내줘"라는 요구사항이 들어왔어요. 이걸 구현하려면 뭐가 먼저 결정돼야 할까요:
- 이메일 내용은 뭔가요? 주문 번호? 배송 예정일?
- "완료"가 뭔가요? 결제 승인? 재고 차감? 배송 시작?
- 실패하면 어떻게 해요? 재시도? 담당자 알림?
- 이메일이 안 가도 주문은 유효한가요?
이게 명확하지 않으면 개발자도, AI도 추측으로 구현하거나 질문하기 위해 멈춰야 해요. 코딩 속도가 55% 올라봐야 이 단계에서 막히면 의미가 없어요.
Martin Fowler가 정리한 "Specification by Example"도 같은 맥락이에요: 요구사항은 추상적 설명이 아니라 구체적인 예시(입력 → 기대 출력) 형태로 표현될 때 비로소 완전해진다는 거예요. AI에도 동일해요 — 모호한 지시어는 AI가 빠르게 잘못된 걸 만들게 해요.
| AI만 도입 | 요구사항 명확화 + AI | |
|---|---|---|
| 입력 품질 | 여전히 모호 | 구체적 예시 기반 |
| 코딩 속도 | 빨라짐 | 빨라짐 + 재작업 최소화 |
| 전달 안정성 | 저하 위험 | 유지 또는 향상 |
| 실제 납기 | 변화 없거나 지연 | 단축 가능 |
그럼 어떻게 시작할까요?
- 진짜 병목 찾기
최근 프로젝트의 각 단계별 소요 시간을 솔직하게 적어보세요. "왜 오래 걸렸나?"의 원인도. 요구사항 변경? 재작업? 승인 대기? 거기가 진짜 병목이에요. - "완료의 정의"를 코딩 전에 만들기
기능마다 구체적인 예시를 작성하세요. "사용자 A가 결제 완료하면 → 주문 확인 이메일이 B 형식으로 발송된다." 이 수준의 구체성이 AI에게도, 개발자에게도 고품질 입력이에요. - 불확실성을 코딩 전으로 당기기
"이걸 어떻게 해야 하지?"가 코딩 중에 나오면 이미 늦어요. 기획자/PO와 대화하는 데 1시간을 쓰는 게 2일 재작업을 막아요. - 그 다음에 AI 붙이기
요구사항이 구체적 예시 수준으로 정의된 다음에 AI에게 구현을 맡기세요. 명확한 입력이 있을 때 AI 속도 향상이 비로소 유의미해져요. - 올바른 지표로 측정하기
"빨라졌나?" 대신 "재작업이 줄었나?", "요구사항 변경이 줄었나?"로 측정하세요. DORA의 배포 빈도, 리드 타임, 변경 실패율이 좋은 기준이에요.
