MAKE IT SIMPLE
SDD 워크플로우 실전기 4 - AI로 개발했더니, 오히려 워터폴로 돌아갔다 본문
AI로 개발했더니, 오히려 워터폴로 돌아갔다
1편("기획서와 코드 사이를 잇고…")·2편("잔존률은 높은데, 절반이 뒤집혔다")·3편("git blame으로는 AI 기여도를 셀 수 없었다")의 후속입니다. 이번 글은 지표가 아니라, 한 분기에 가까운 프로젝트를 AI 워크플로우로 마치고 팀 전체가 남긴 회고에서 출발한다.
반년 가까이 결제·정산이 걸린 큰 기능을 AI 워크플로우로 만들었다. PRD 초안도, 스펙도, 테스트 코드도 상당 부분을 AI가 뽑았다. 프로젝트가 끝나고 팀 전체가 모여 회고를 했는데, 각자 관점은 달라도 이상하게 한 곳으로 수렴하는 문장이 있었다.
"AI로 빠르게 갈 줄 알았는데, 앞을 제대로 안 정하면 뒤가 통째로 흔들린다."
그러니까 우리는 더 애자일해진 게 아니었다. 오히려 옛날 워터폴에 가까워졌다.
정확히 말하면 워터폴로 돌아가자는 뜻은 아니다. 다만 AI가 추상적인 결정을 빠르게 하위 산출물로 구체화하기 때문에, 예전보다 앞단 기준선의 품질이 훨씬 중요해졌다는 뜻이다.
AI는 창조보다 구체화를 잘한다
한 팀원이 회고에서 이렇게 정리했다. AI는 없는 것을 창조하기보다, 많은 정보를 빠르게 처리하고 구체화하는 데 강하다. 그래서 중간에 방향을 자주 트는 애자일보다, 앞단을 정하고 내려가는 워터폴과 오히려 잘 맞는다.
처음엔 반대로 기대했다. AI가 초안을 빠르게 뽑아주니 더 자주, 더 유연하게 바꿀 수 있을 거라고. 실제로 초반 속도는 붙었다. 혼자였으면 이 기간에 PRD를 다 못 썼을 거라는 말이 여러 번 나왔고, 방대한 범위를 파악하고 다른 팀에 공유할 문서를 만드는 초반 작업은 확실히 편해졌다.
그런데 앞단 정책이 흔들리자 그 여파가 다르게 왔다. 사람만 있을 때는 기획이 바뀌어도 "어차피 아직 손으로 안 짰으니까" 하고 넘어갈 여유가 있었다. AI는 이미 앞단 문서를 근거로 스펙과 코드를 저 아래까지 빠르게 구체화해 둔 뒤였다. 앞이 한 칸 움직이면 뒤가 열 칸 다시 짜여야 했다.
숫자가 이걸 보여준다. 한 파트에서 티켓당 평균 커밋이 3.8개였는데, 그중 신규 작업은 14%, 나머지 86%가 정합·수정이었다. 초반에 PRD만 보고 잡은 아키텍처가 후반에 "이걸 왜 이렇게 짰지" 싶을 만큼 갈아엎였다. 기능은 빙산의 일각이었고, 몸통은 안정화였다. 다른 파트에서도 전체 티켓의 절반 이상이 처음엔 없던, 개발하다 파생·발견된 수정이었다.
게이트는 "PRD 확정"이 아니라 "돈의 규칙이 굳는 시점"
그래서 착수 게이트를 다시 봐야 했다.
흔한 실수는 PRD를 통째로 하나의 덩어리로 보고 "확정됐다/안 됐다"를 판단하는 것이다. 실제로는 영역마다 굳는 속도가 다르다. 레이아웃·목록·필터 같은 구조는 앞에서 일찍 굳었다. 반면 정산·환불·수수료·연장처럼 돈이 흐르는 도메인은 오픈 직전까지 흔들렸다.
여기서 배운 규칙이 하나 있다. 돈이 흐르는 부분은 PRD만 보고 구조를 확정하면 안 된다. 프런트는 백엔드 스펙이 확정되는 시점을 게이트로 잡고, 그 스펙을 보고 짜야 코드가 깨끗하게 나왔다. PRD로 미리 짠 구조는 예외 처리와 정합 과정에서 대부분 다시 쓰였기 때문이다. 결제 금액이 큰 도메인은 정상 흐름보다 예외 처리·안정화에 몇 배의 시간이 들었는데, PRD는 기능과 플로우를 담을 뿐 이 예외 상황을 담지 못한다.
그러니 착수 게이트는 "PRD 다 썼어?"가 아니라 이렇게 물어야 했다. "돈의 규칙이 굳었어? 백엔드 스펙이 나왔어? 항목별 진행률은?" 전체를 뭉뚱그리지 않고 항목별로 쪼개 봐야 리스크가 보였다.
물론 정책을 100% 정하고 착수할 수는 없다. 개발 중 누락은 그때 다시 정하면 된다. 다만 회고에서 합의한 방향은 분명했다. 착수 시점의 완성도 퍼센트를 지금보다 높여야 한다. 흥미롭게도 우리가 쓴 AI 도구조차 "완성도가 일정 수준 이상 확보된 뒤 개발하라"고 권고하고 있었다.
앞단 완성도의 비용은 사람이 치른다
앞단을 덜 정하고 내려가면, 그 미정의 부담은 사라지지 않는다. 뒤로 밀려 결국 사람에게 돌아온다.
AI에게 "엣지 케이스까지 다 써달라"고 해도, 정의되지 않은 부분은 그대로 남는다. 그 미정 항목은 인수 테스트와 QA 단계에서 "이건 정의가 안 됐다"는 멘션으로 되돌아왔다. 검증 책임은 AI에게 위임되지 않고 사람에게 회귀했다.
역할 자체가 움직였다. 기획자가 이렇게 말했다. AI가 초안을 써주니 기획자는 이제 문서를 '쓰는 사람'이 아니라 '무엇이 맞는지 정하는 사람'이 됐다고. 어떤 정책이 옳은지 결정하고 방향을 조망하는 역할이 훨씬 커졌다.
그런데 여기 그늘도 있었다. 예전엔 손으로 한 땀씩 써서 정책을 다 외웠는데, 이제는 정책을 물어보면 기획자도 AI에게 되물어야 한다. 회고에서 나온 가장 솔직한 문장이 이거였다.
"문서는 있었지만, 장악하지는 못했다."
내가 만든 문서인데 내 것 같지 않은 불안. AI로 앞단 문서를 많이 만든 사람이라면 익숙한 감각일 것이다. 그래서 "무엇을 안 할지 정하는 것"도 하는 것만큼 중요해졌다. 감이 아니라 빈도와 비용을 근거로 대서 자르고, 자른 걸 기록으로 남기는 일이.
뒷단의 안전망: 내 AI는 내 코드의 구멍을 못 잡는다
앞단을 완벽히 굳힐 수 없다면, 뒷단에 그물을 촘촘히 쳐야 한다. 여기서 AI가 크게 기여한 두 가지가 있었다.
첫째는 테스트 코드다. 이 프로젝트에서 전체 코드의 약 46%가 테스트 코드였다. 손으로 다 짰으면 불가능한 양이다. 정책 번복이 잦은 영역에서, 케이스별 테스트는 정책이 뒤집힐 때 어디가 깨지는지 즉시 잡아냈다. 프로덕션에 나가기 전 큰 회귀와 크래시가 없었던 건 이 안전망 덕분이라는 말이 반복해서 나왔다.
둘째는 조금 반직관적이다. 자기 AI는 자기가 짠 코드의 구멍을 못 잡는다. 정확히 말하면 못 잡는다기보다, 같은 프롬프트·같은 맥락·같은 구현 가정을 공유하기 때문에 같은 사각지대를 반복하기 쉽다. 그래서 우리는 이런 구조를 만들었다. PR을 올리면, 팀원 여럿이 각자의 AI로 상대의 코드를 리뷰한다. 한 PR을 서로 다른 사람의 서로 다른 AI 서너 개가 훑는 셈이다. 혼자서는 놓쳤을 엣지 케이스와 조용한 실패(silent failure)가 이 "리뷰 대 리뷰" 구조에서 댓글로 드러났다.
테스트 자동 생성이 안전망이라면, 교차 리뷰는 그 안전망에 뚫린 구멍을 메우는 두 번째 그물이었다. 하나만으론 부족했다.
그리고, AI 문서 기반 개발은 QA를 문서 검증으로 되돌릴 수 있다
낙관만 적으면 회고가 아니다. 분명한 다운사이드도 있었다.
QA 담당자의 회고가 뼈아팠다. QA가 못했다는 얘기가 아니다. QA의 무게중심이 제품 검증에서 문서 오류 검증으로 밀렸다는 뜻이다. AI가 작성한 문서를 근거로 개발하다 보니, 문서 자체의 오류를 잡는 데 많은 시간이 들었다. 문서가 틀리면 그걸 확인하고, 고쳐지면 해소됐는지 다시 확인하는 반복 작업이 쌓였다. 그 결과 미리 만들어 둔 테스트 코드와 자동화를 정작 이번엔 하나도 쓰지 못했다.
수정이 잦을수록 할루시네이션도 늘었다. 상위 모델로 돌리면 줄긴 했지만 비용이 컸다. AI가 과거에 스스로 적어둔 정책을 나중에 애매하게 이해해서, 자기가 만든 정책과 충돌하는 새 정책을 올리는 일도 있었다. 그때마다 사람이 다시 정리해야 했다.
그리고 SSOT(단일 진실 공급원) 문제. PRD 하나로 모든 걸 담으려 하자 정합성이 깨졌다. 문구 하나를 맞추려 디자인 파일과 PRD와 SDK 스펙을 전부 대조해야 했고, "디자인과 문구가 다르다"는 티켓이 다수 나왔다. 다음 프로젝트의 숙제는 분명하다. PRD는 정책의 추상화 레벨로 두고, UI/UX SSOT를 분리하되, 그 위치를 시작 전에 픽스하는 것.
정리하면
- AI 워크플로우는 애자일의 속도보다 워터폴식 기준선에 더 민감했다. AI는 창조보다 구체화를 잘하기 때문에, 앞단이 흔들리면 이미 아래까지 구체화된 뒷단이 통째로 흔들린다.
- 착수 게이트는 "PRD 확정"이 아니라 "돈의 규칙이 굳는 시점"이다. 영역마다 굳는 속도가 다르니 항목별 진행률로 봐야 한다. 돈이 흐르는 도메인은 백엔드 스펙 확정 시점을 중요한 게이트로 봐야 한다.
- 앞단 완성도의 비용은 사람이 치른다. 미정 항목은 AI가 아니라 QA와 기획자에게 회귀한다. 기획자의 정체성은 '쓰는 사람'에서 '정하는 사람'으로 이동했다.
- 뒷단 안전망은 테스트 자동화 + 교차 AI 리뷰의 세트다. 내 AI는 내 코드의 구멍을 못 잡으니, 남의 AI가 봐야 한다.
- AI 문서 기반 개발은 QA를 문서 검증으로 되돌릴 수 있다. 문서 오류를 잡는 반복 작업이 늘고, 준비한 자동화를 못 쓰는 상황이 생긴다.
AI가 앞단을 빠르게 처리해줄수록, 역설적으로 앞단을 제대로 정하는 일의 가치가 올라갔다. 빨라진 건 손이지, 결정이 아니었다.
'AI' 카테고리의 다른 글
| SDD 워크플로우 실전기 3 - git blame으로는 AI 기여도를 셀 수 없었다 (0) | 2026.07.10 |
|---|---|
| SDD 워크플로우 실전기 2 - 스펙 번복률 측정하기 (0) | 2026.07.09 |
| SDD 워크플로우 실전기 1 - AI 기여도 측정하기 (0) | 2026.07.09 |
| AI가 코드를 짜주는 시대, 왜 TDD가 더 중요해졌나 (0) | 2026.02.05 |