소프트웨어 공학 100 주제 시리즈의 9번째 글이다. (카테고리: 기초와 역사)

한 줄 요약

“폭포수 모델의 원전” 으로 인용되는 Winston Royce 의 1970년 논문에는 ‘waterfall’ 이라는 단어가 한 번도 나오지 않는다. Royce 는 단계를 순서대로 밟는 방식이 “위험하고 실패를 부른다” 고 쓴 뒤, 그 위험을 줄이는 다섯 가지 보완 — 설계 먼저, 문서화, 두 번 만들기, 테스트 계획, 고객 참여 — 을 제안했다.

왜 필요한가

애자일을 소개하는 글은 종종 “1970년 Royce 가 폭포수 모델을 제안했고, 그것이 실패해서 애자일이 나왔다” 는 이야기로 시작한다. 이 서사는 두 가지 점에서 해롭다.

  • 허수아비를 만든다. 아무도 실제로 주장하지 않은 “한 번에 쭉 내려가는 모델” 을 때리면서, 정작 Royce 가 지적한 진짜 위험(늦은 통합, 늦은 피드백)은 놓친다.
  • 원문에 있는 좋은 조언을 버린다. 프로토타입을 먼저 만들어라, 2차 검토자가 코드를 읽게 하라, 고객을 공식적으로 참여시켜라 — 오늘날 애자일 팀이 하는 일과 많이 겹친다.

원문을 직접 읽는 것은 역사 공부이면서 동시에 2차 출처를 믿지 않는 연습이다.

핵심 개념

원문 정보

Winston W. Royce, “Managing the Development of Large Software Systems”, Proceedings, IEEE WESCON, 1970년 8월, pp. 1–9. 원래 TRW 에서 발행되었고, 1987년 ICSE(제9회 국제 소프트웨어 공학 학회) 논문집에 재수록되었다. 재수록본 첫 페이지에 이 사실이 표기되어 있다. 공식 출판사의 공개 원문 링크가 없어 서지 정보로 인용한다.

Royce 는 서두에서 지난 9년 동안 우주선 임무 계획·명령·비행 후 분석용 소프트웨어 패키지 개발을 맡으며 일정·비용 준수에서 성공과 실패를 겪었고, 그 경험에서 얻은 “편견” 을 말하겠다고 밝힌다. 이론이 아니라 대형 정부 계약 프로젝트의 현장 보고다.

그림 1 과 그림 2: 작은 일과 큰 일

그림 단계 Royce 의 평가
1 분석 → 코딩 작고, 만든 사람이 직접 운영하는 내부용 프로그램이면 이것으로 충분하다
2 시스템 요구사항 → 소프트웨어 요구사항 → 분석 → 프로그램 설계 → 코딩 → 테스트 → 운영 큰 시스템을 고객에게 납품하는 경우의 단계

그림 2 가 오늘날 “폭포수” 로 알려진 그림이다. 그리고 그림 3 은 각 단계가 바로 앞뒤 단계와 반복(iteration) 하는 관계를 그린다. 그 장점은 변경 범위를 관리 가능한 수준으로 묶고, 예상치 못한 설계 문제가 생기면 돌아갈 기준선(baseline)을 갖는 것이다.

바로 다음 문장: “위험하고 실패를 부른다”

그림 2·3 을 설명한 직후 Royce 는 이렇게 쓴다.

나는 이 개념을 믿는다. 그러나 위에 기술한 구현은 위험하고 실패를 부른다.

이유는 그림 4 에 있다. 개발 주기 끝의 테스트 단계가 타이밍, 저장 공간, 입출력 같은 현상을 분석이 아니라 실제로 처음 경험하는 시점이다. 이 현상들이 외부 제약을 만족하지 못하면 대개 큰 재설계가 필요하고, 그 변경이 요구사항까지 흔든다. 그러면 개발은 사실상 원점으로 돌아가고, 일정·비용이 최대 100% 초과될 수 있다고 그는 쓴다. 그림 4 의 캡션은 “불행히도 이 프로세스에서 설계 반복은 결코 인접 단계에 국한되지 않는다” 이다.

다만 Royce 는 이 접근을 버리자고 하지 않는다. “근본적으로 건전하다(fundamentally sound)” 고 믿으며, 개발 위험 대부분을 없애려면 다섯 가지 기능을 추가해야 한다고 말한다. 원문의 구조는 “순차 모델 → 그 위험 → 보완책” 이다.

다섯 가지 보완

단계 원문 제목 핵심 내용
1 Program Design Comes First 요구사항과 분석 사이에 예비 프로그램 설계를 넣는다. 틀릴 위험을 감수하고서라도 저장 공간·실행 시간·인터페이스를 먼저 할당한다. 누구나 이해할 수 있는 개요 문서를 쓴다
2 Document the Design 문서화는 “상당히 많이”. 문서가 나쁘면 설계가 나쁘다. 문서가 없으면 아직 설계가 없다. “90% 완료” 증후군 뒤에 숨지 못하게 한다
3 Do It Twice 처음 개발하는 프로그램이라면 고객에게 최종 납품하는 버전이 핵심 설계·운영 영역에서 실제로는 두 번째 버전이 되게 하라. 30개월 프로젝트면 10개월짜리 파일럿 모델을 둘 수 있다
4 Plan, Control and Monitor Testing 테스트는 자원을 가장 많이 쓰고 위험이 가장 큰 단계다. 설계에 참여하지 않은 테스트 전문가, 2차 검토자의 육안 검사, 모든 논리 경로를 최소 한 번 수치로 확인
5 Involve the Customer 요구사항 정의 이후에도 여러 시점에서 고객을 공식적으로 참여시켜 미리 약속하게 한다

3단계에서 Royce 는 파일럿이 전체 과정을 작게 축소해 한 번 해 보는 것이며, 그것이 없으면 프로젝트 관리자는 언제나 심각하게 낙관적인 인간의 판단에 의존하게 된다고 쓴다. 오늘날의 스파이크·프로토타입·워킹 스켈레톤과 같은 목적이다.

결론에서 그는 각 항목이 추가 비용을 들게 한다고 인정하면서도, 자기 경험상 더 단순한 방법은 대형 개발에서 한 번도 성공한 적이 없고, 복구 비용이 다섯 단계 비용을 훨씬 넘었다고 말한다.

오해는 어떻게 굳었나

Craig Larman 과 Victor Basili 의 Iterative and Incremental Development: A Brief History(IEEE Computer, 2003; Basili 의 사이트 사본)는 이 과정을 추적한다.

  • 많은 사람이 Royce 의 논문을 단일 패스 폭포수의 전형으로 잘못 본다. 실제로 그는 오늘날 폭포수 개념과는 다른 접근, 즉 “두 번 하라” 를 권했고, 반복·피드백·적응의 흔적이 있다. 다만 고전적인 반복·증분 개발(IID)은 아니라고 저자들은 평가한다.
  • Royce 의 아들 Walker Royce 는 개인 서신에서, 아버지가 늘 반복적·증분적·진화적 개발의 지지자였으며 논문은 폭포수를 가장 단순한 서술로 제시했을 뿐 가장 단순한 프로젝트 외에는 통하지 않는다고 보았다고 전한다. 나머지 내용은 1960~70년대 정부 계약 모델이라는 제약 안에서 반복적 실천을 서술한 것이라고 한다.
  • 1980년대 미 국방부 표준 DoD-Std-2167 은 엄격한 문서 중심 단일 패스 모델을 요구했다. Brooks 가 의장을 맡은 국방과학위원회 태스크포스의 1987년 10월 보고서가 이를 비판하며 진화적 개발을 권했고, 1988년 2월의 2167A 는 특정 개발 방법을 강제하지 않는다는 문구를 넣었다. 그럼에도 문서 중심 마일스톤 구조 때문에 여전히 폭포수를 암묵적으로 선호하는 것으로 읽혔다.
  • 같은 논문은 Royce 가 일했던 TRW 가 일찍부터 IID 를 도입한 회사였고, 나선형 모델을 만든 Barry Boehm 이 TRW 의 수석 과학자였다고 적는다. Boehm 의 A Spiral Model of Software Development and Enhancement(Computer 21(5), 1988)가 위험 주도 반복 모델의 대표 문헌이다.

정리하면, 오해는 Royce 가 만든 것이 아니라 그림 2 만 떼어 쓴 후대의 인용과 계약·표준 관행이 만들었다.

실무 적용

Royce 의 다섯 단계를 현재 팀의 관행으로 옮겨 보면 생각보다 낯익다.

Royce (1970) 현재 관행 점검 질문
설계 먼저, 자원 할당 아키텍처 스파이크, 성능 예산 지연시간·메모리 목표를 설계 초기에 정했는가?
문서화 ADR, 설계 문서, README 설계 결정이 사람 머릿속에만 있지 않은가?
두 번 만들기 프로토타입, 워킹 스켈레톤 처음 해 보는 핵심 부분을 작게 먼저 끝까지 관통해 봤는가?
테스트 계획·통제 코드 리뷰, 커버리지, CI 작성자가 아닌 사람이 읽는가? 모든 경로가 한 번은 실행되는가?
고객 참여 데모, 사용자 테스트, 인수 기준 요구사항 확정 후에도 고객이 중간 결과를 보는가?

Royce 가 가장 두려워한 것은 “테스트 단계에서 처음으로 실제 현상을 겪는 것” 이었다. 지속적 통합과 이른 배포는 바로 이 순간을 프로젝트 끝에서 매일로 당긴 것이다(CI/CD 참고).

흔한 오해와 함정

  • “Royce 가 폭포수 모델을 만들었다.” 논문에는 waterfall 이라는 단어가 없다. 그는 순차 구현이 위험하다고 쓰고 보완책을 제안했다.
  • “Royce 는 순차 모델을 반대했다.” 이것도 과장이다. 그는 기본 접근이 근본적으로 건전하다고 보았고, 다섯 가지를 추가하라고 했다. Larman·Basili 도 그의 제안을 고전적 IID 로 보지는 않는다.
  • “문서화를 강조했으니 애자일과 정반대다.” 그가 문서를 강조한 이유는 소통, 인수인계, 테스트·운영 인력 활용, 재설계였다. 목적은 오늘날에도 유효하고, 수단(문서의 형태와 양)이 바뀌었을 뿐이다.
  • “폭포수는 이제 쓸모없다.” 요구사항이 안정적이고 변경 비용이 매우 큰 영역(규제 납품, 하드웨어 연동)에서는 단계 게이트가 여전히 쓰인다. 핵심은 Royce 가 경고한 늦은 통합 위험을 다른 방법으로라도 줄이는 것이다.
  • 2차 출처의 그림만 보고 원문을 판단하기. 이 글 전체의 교훈이다.

확인 문제

  1. Royce 가 그림 2 의 순차 구현을 “위험하다” 고 본 핵심 이유는?
  2. Royce 가 제안한 다섯 가지 보완을 나열하라.
  3. “Do It Twice” 는 오늘날 어떤 실천과 목적이 같은가?
  4. Royce 논문이 단일 패스 폭포수의 원전으로 오해된 데 기여한 요인 두 가지는?
  5. Royce 를 “반복 개발의 선구자” 로 부르는 것도 조심해야 하는 이유는?

풀이

  1. 마지막 테스트 단계가 타이밍·저장 공간·입출력 같은 현상을 처음으로 실제 경험하는 시점이라, 거기서 문제가 드러나면 요구사항까지 흔드는 큰 재설계가 필요해지고 일정·비용이 크게(최대 100%) 초과될 수 있기 때문이다.
  2. 프로그램 설계를 먼저, 설계 문서화, 두 번 만들기, 테스트 계획·통제·감시, 고객 참여.
  3. 프로토타입, 스파이크, 워킹 스켈레톤 — 핵심 위험을 작게 먼저 끝까지 관통해 보고 본 개발에 반영하는 것.
  4. 그림 2 만 떼어 인용한 후대 문헌, 그리고 DoD-Std-2167 같은 문서 중심 단일 패스 계약 표준.
  5. Royce 는 기본 순차 접근을 “근본적으로 건전하다” 고 했고, Larman·Basili 도 그의 제안이 반복의 흔적을 담았지만 고전적 IID 는 아니라고 평가한다.

더 읽을거리 (References)