개발 ① Waterfall의 재평가 (06/10)

AI 시대의 프로젝트 방법론 · Ep.06

폭포수를 비웃던 팀이,
요구 확정 없이 표류했다.

개발 ① Waterfall의 재평가 · HFC Consulting

---

킥오프에서 젊은 팀장이 선언했다. "우리는 폭포수처럼 문서에 파묻히지 않겠습니다. 빠르게 만들고 빠르게 고치겠습니다." 여섯 달 뒤, 팀은 세 번째로 같은 화면을 다시 만들고 있었다. 발주 부서마다 요구가 달랐고, 확정된 것이 없었으므로 무엇을 만들어도 틀린 것이 됐다. 그들이 버린 것은 문서가 아니라, 착수 전에 합의한다는 원칙이었다.

Waterfall은 소프트웨어 역사에서 가장 오래 조롱받은 이름이다. 조롱을 걷어내고 다시 보면, 누명과 실제 한계가 뒤섞여 있다. 재평가가 필요하다 — 특히 AI가 전제를 바꾼 지금.

전제 — 뒤로 갈수록 비싸지는 세계의 합리

폭포수의 논리는 수정 비용 곡선 위에 서 있다. 요구 단계의 오류를 운영 단계에서 고치면 비용이 수십 배가 된다는 것 — 그래서 앞 단계를 확정하고 도장을 찍은 뒤에 다음 단계로 내려간다. 코드 한 줄이 비싸고 통합이 느리던 시대에 이것은 교리가 아니라 산수였다. 문서가 많았던 것도 같은 이유다. 사람 사이에 의도를 전달할 수단이 문서뿐이었다.

균열 — 산수가 바뀌었다

AI는 그 비용 곡선을 눌러 버렸다. 코드는 다시 만드는 것이 고치는 것보다 쌀 때가 있고, 화면 하나를 세 가지 안으로 만들어 비교하는 것이 문서로 세 안을 기술하는 것보다 빠르다. "뒤로 갈수록 비싸다"는 전제가 생산 구간에서는 무너진 것이다. 이 지점에서 폭포수의 순차 구조는 생산 구간에 한해 근거를 잃는다.

존속 — 누명과 실제 한계를 가른다

여기서 정확해야 한다. 폭포수가 받아 온 비난의 절반은 누명이다. "문서가 많아서 실패했다"는 진단은 틀렸다 — 실패의 실제 원인은 피드백의 지연, 즉 만든 것을 너무 늦게 보여준 것이었다. 반대로 폭포수가 남긴 실질적 유산은 지금도 유효하다. 착수 전 요구의 합의와 책임의 명확화, 단계라는 개념이 주는 검증의 관문, 그리고 발주자-수급인 구조에서 계약과 검수의 기준점(사업분야 SI에서 다룬 세계다). 규제 도메인과 대형 SI에서 이 뼈대는 선택이 아니라 환경이다.

재구성 — 폭포수의 뼈대에 짧은 심장박동을

요소	판정	AI 시대의 형태
착수 전 요구 합의	존속 — 오히려 강화	합의 단계는 순차 유지, 프로토타입을 합의의 도구로 활용
단계별 검증 관문	존속 — 형태 변경	단계말 일괄에서 상시 자동 게이트로 (3화 참조)
생산 구간의 순차 진행	화석	생산 구간은 짧은 반복으로 — 만들어 보고 판단
빅뱅 통합·이행	화석	조기·상시 통합, 이행 리허설 반복
전달 수단으로서의 문서	축소	기술 문서는 줄이고 결정 기록(ADR)은 늘린다

판별 기준 한 줄 — 그 절차가 "합의와 책임"을 위한 것이면 지키고, "생산의 순서"를 위한 것이면 다시 설계한다. 폭포수의 실패는 전자를 후자와 한 몸으로 묶은 데 있었고, AI 시대의 기회는 둘을 분리할 수 있게 된 데 있다.

예상 반론과 대응

반론 1. "그래도 폭포수는 죽은 방법론 아닙니까."
대응. 국내 공공·금융 조달의 상당수가 지금도 단계·산출물·검수 구조를 요구한다. 그 환경에서 일하는 조직에게 폭포수의 뼈대는 사망 선고가 아니라 계약 조건이다. 죽은 것은 교조적 적용이지 구조가 아니다.

반론 2. "합의는 순차, 생산은 반복이라면 그것은 애자일 아닙니까."
대응. 가까워 보이지만 출발점이 다르다. 애자일은 요구의 불확실성을 전제로 반복을 설계했고, 여기의 재구성은 합의된 요구를 전제로 생산만 반복한다. 그리고 애자일 자체도 AI 앞에서 재평가가 필요하다 — 그것이 바로 다음 편이다.

Waterfall 재평가 체크포인트 — 합의·책임 장치와 생산 순서 장치의 분리 / 요구 합의 단계는 순차 유지 / 생산 구간은 반복 전환 / 통합·이행은 조기 반복 / 문서는 전달용 축소, 기록용 강화

방법론의 역사에서 가장 낡았다고 불리는 것 안에, 가장 오래 갈 원칙이 들어 있었다. 재평가란 그런 것을 골라내는 일이다. 폭포수의 재판이 끝났으니 다음 피고를 부른다. 2주 스프린트가 길게 느껴지는 시대 — Agile은 살아남는가.

※ 본 연재의 비교·재구성 원칙은 일반적 참고용이며, 조직의 표준과 사업 특성에 맞는 조정이 필요합니다.

📎 더 읽을거리
· Royce, "Managing the Development of Large Software Systems" (1970, PDF) — 흔히 폭포수의 기원으로 인용되지만, 원문은 이미 반복의 필요를 말하고 있다
· 애자일 소프트웨어 개발 선언 (한국어) — 폭포수에 대한 역사적 반명제

HFC Consulting의 관점

25년간 폭포수의 세계에서 일했고, 그 뼈대가 어디서 힘을 발휘하고 어디서 발목을 잡는지 보아 왔습니다. 조달 환경 안에서의 방법론 재설계가 고민이라면 사업 조건을 보내 주십시오.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI 시대의 프로젝트 방법론
◀ 이전 편 (05/10) 관리 ④ 변경·형상: 변경통제위원회의 속도 문제
다음 편 ▶ (07/10) 개발 ② Agile은 살아남는가
연재 전체 보기 →