폭포수 모델

위키백과, 우리 모두의 백과사전.

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이른다.

최초의 "폭포수 모델". 작업의 진전이 위로부터 아래로 폭포수처럼 흐른다.
소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세
구조 · 설계
구현 · 테스팅
배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸
DSDM · 순차점증적 개발 · 반복형 개발
RAD · RUP · 나선 모형
폭포수 모델 · 익스트림 프로그래밍
스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화
품질보증 · 프로젝트 관리
사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러
GUI 디자이너 · 통합 개발 환경

흔히 "폭포수" 개념을 처음으로 사용한 글로 1970년에 윈스턴 W. 로이스 (1929–1995)[1]의 논문이 인용되지만, 실제로 로이스는 그 논문에서 "폭포수"라는 개념을 사용하지는 않았다. 그리고 역설적이게도 로이스는 그 논문에서 이 모델을 결함이 있는, 제대로 동작하지 않는 사례로 제시하고 있다.

모델[편집]

로이스가 제시한 최초의 폭포수 모델은 다음과 같은 단계가 순차적으로 기술되어 있다.

  1. 소프트웨어 요구사항 기술
  2. 소프트웨어 설계
  3. 소프트웨어 구현 (또는 코딩)
  5. 시험과 디버깅
  6. 설치
  7. 소프트웨어 유지보수

폭포수 모델을 따르기 위해서는, 완전히 순차적으로 한 단계, 한 단계를 진행해 나가야 한다. 예를 들어, 가장 먼저 요구사항 기술을 진행하여 이를 확정하여야 하며, 그런 이후에 설계를 진행할 수 있다. 소프트웨어가 설계된 후, 그 설계도(blueprint)가 구현자(또는 코더)에게 따라서 구현해야할 계획으로 전달된다. 따라서 설계가 완전히 완료된 후에 설계에 대한 구현이 코더에 의해 진행될 수 있는 것이다. 이 구현의 마지막 단계에 이르면, 각각의 생성된 컴포넌트를 결합하여, 새로운 기능을 실현시키고 그때까지 발생한 버그를 해결하게 된다(디버깅). ]

그러므로 폭포수 모델은 전 단계가 수행되어 완료되기 전에는 다음 단계로 진행할 수 없도록 제한한다. 그러나, 최초의 원래 폭포수 모델과는 달리 프로세스 일부 또는 많은 부분이 변형된 모델들이 존재하며, 로이스의 최종 모델도 그 중 하나이다.

사용 사례[편집]

폭포수 모델은 미국 국방성 (United States Department of Defense)이나 NASA에 고용된 대규모 소프트웨어 개발 하우스에 의해 널리 사용되었으며, 그외에 다수의 대규모 정부 프로젝트에서 사용되었다. ("표준 폭포수 모델" 참조) 그러나 이를 사용하는 업체나 개발자는 굳이 순수 폭포수 모델과 변형 모델 사이를 구분하여 공식적으로 언급하지 않았기 때문에, 정확히 어떤 모델이 사용되었는지를 정리하는 것은 어려운 일이다.

참고로 미 국방성은 1994년의 MIL-STD-498과 1998년의 IEEE 12207을 통해 폭포수 모델의 제약 조건을 벗어났다.

관련 논의[편집]

소프트웨어 개발 초기에 적절히 사용된 시간은 생명 주기(lifecycle)의 후기에 큰 경제적 영향을 줄 수 있다. 다시 말하면, 경제학적 관점에서 소프트웨어 개발의 초기(요구사항 기술 또는 설계 단계)에 발견된 버그는 후기에 발견된 것에 비해 고치는 시간과 돈, 그리고 노력이 몇배는 적게 들기 마련이다. 관련하여 스티브 맥코넬은 그의 저서, "Rapid Development"에서 "요구사항 상의 결함이 구현이나 유지보수 단계에까지 발견되지 않고 남아 있을 경우, 이를 수정하는 비용은 요구사항 기술 시에 수정하는 것에 비해 최소 50배에서 최대 200배까지 드는 것"으로 예측했다.

극단적인 예로, 만약 프로그램 설계가 구현이 불가능한 것일 경우, 이것이 설계 단계에서 고쳐지기는 쉬우나 몇달 뒤 구현과 통합이 진행 중에 발견되면, 이를 고치는 것은 불가능하고 그때까지 개발된 모든 코드와 컴포넌트를 버릴 수밖에 없다. 그리고 이러한 논의가 Big Design Up Front (BDUF)와 폭포수 모델의 배경이 되는 중심적인 아이디어이다. 그런 이유로, 폭포수 모델을 따르는 이들은 소프트웨어 개발시 전단계가 100% 완료되고 모두 정확하다는 것을 확인한 후에야 다음 단계로 이행하고자 한다. 소프트웨어 요구사항은 설계가 시작되기 전에 돌과 같이 단단하게 확정되어야 하고, (그렇지 않은 경우, 정확하지 않은 요구사항에 기반한 설계는 버려질 수 있다.) 소프트웨어 설계는 개발자들이 구현을 시작하기 전에 완벽해야만 한다. (그렇지 않을 경우 역시 구현에 쓰이는 시간과 비용은 낭비된다. )

또 다른 논의는 폭포수 모델에 있어서의 문서화에 대한 강조이다. 폭포수 모델에서는 요구사항 기술 및 설계, 그리고 소스 코드에 있어서의 정확하고 완벽한 문서화를 강조한다. 충분히 설계되지 않고, 문서화되지 않은 소프트웨어 프로젝트일수록, 팀 구성원이 떠날 경우에 많은 지식이 사라지고 프로젝트 지속에 더 큰 어려움이 따른다는 것이 그 논지이다. 그러나 반대로 완벽하게 동작하는 설계 문서가 존재할 경우, 새로운 팀원이나 심지어 완전히 새로 구성된 팀에게도 프로젝트를 이전하여 문서 기반으로 수행하는 것이 가능하다.

위 논의에 더하여, 폭포수 모델은 그 간결한 접근 방식으로 인해 선호되기도 한다. 폭포수 모델은 소프트웨어 개발에 구조화된 접근 방법을 제공하고, 쉽게 이해할 수 있고 설명이 가능한 각각의 구분된 단계를 순차적으로 진행하게하며, 그런 이유로 프로세스 상의 마일스톤을 정하는 것도 상대적으로 쉽기 때문이다. 아마도 그것이 소프트웨어 공학 교과서나 교육과정에서 폭포수 모델을 프로세스의 대표적인 예로 삼는 이유일 것이다.

반대로 폭포수 모델의 한계를 지적하는 이들도 존재한다. 그들은 폭포수 모델이 안정적인 요구사항 기반을 가진 프로젝트나 모든 소프트웨어 개발의 문제영역을 완벽히 예측할 수 있는 설계자를 가진 프로젝트에만 맞을 수 있다고 지적한다. 그들은 또한 구현자들이 설계를 완벽하고 정확하게 구현하지 않을 경우, 시스템 통합 단계를 수월하게 진행할 수 없음도 지적한다.

폭포수 모델에 대한 비판[편집]

폭포수 모델에 대한 반대의견을 가진 이들도 많다. 주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지인데, 의미있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험 없이, 각 단계를 완벽히 마무리한 후 다음 단계를 진행하는 것이 불가능하다는 것이다. 예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있다. 또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법은 많지 않다. 만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 설계는 새로운 요구사항을 위해 변경되어야 하고 그때까지 투입된 많은 노력은 무위로 돌아가게 된다.

또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기 어렵다. 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 있을 수 있다. 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 재설계를 택하는 것이 향후 발생할 수 있는 더 큰 문제 상황을 방지하는 데 나은 선택이다. 윈스턴 W. 로이스 박사 역시, 폭포수 모델에 대해 처음으로 설명한 "대규모 소프트웨어 시스템 개발 관리(Managing the Development of Large Software Systems)"[2]라는 글에서, 위 비판과 유사한 "실패를 부를 수 있는 위험한" 사례들을 제시한 바 있다.

스티브 맥코넬 역시 그의 저서, Code Complete (폭포수 모델의 광범위한 사용을 비판하고 있는 책)에서 설계 상의 "못된 문제(wicked problem)" — 설계나 구현을 끝내기 전에는 완전히 알 수 없는 요구사항이나 제약조건의 문제 -에 대해 논한 바 있다. 이런 문제가 의미하는 바는 소프트웨어 개발에서 하나의 단계만을 완성하는 것은 불가능하며, 따라서 폭포수 모델을 사용하여 다음 단계로 이행하는 것이 불가능하다는 것이다.

또한 데이빗 파나스(David Parnas)는 그의 글, "합리적인 설계 프로세스: 어떻게 그리고 왜 속이게 되는가 (A Rational Design Process: How and Why to Fake It)"에서 아래와 같이 쓴 바 있다.[3]

“[시스템의] 세부 사항 중 많은 부분은 우리가 [시스템의] 구현을 진행할 때라야 비로소 우리 눈에 보이기 시작한다. 그리고 그렇게 알게 된 것 중 일부는 우리의 기존 설계를 무효로 만들고, 다시 전 단계로 돌아갈 수밖에 없게 만든다. ”

폭포수 모델의 배경이 되는 아이디어는 "두 번 검토해보고, 한번 실행하라(measure twice; cut once)."는 단순한 격언이지만, 그에 반대하는 이들은, 신중히 검토하는 와중에도 지속적으로 소프트웨어 요구사항이나 문제 자체의 양상이 변화하기 때문에, 이 아이디어가 비현실적이라고 말한다.

수정 모델들[편집]

순수 폭포수 모델에 제기된 문제들과 비판에 대한 반응으로, 다수의 수정 폭포수 모델이 소개되었다. 이 수정 모델로 순수 폭포수 모델의 문제점을 일부 또는 전부 해결할 수 있을 것이다. 참고로, 스티브 맥코넬의 책, Rapid Developement: 프로젝트 쾌속 개발 전략 중 "생명주기 계획(lifecycle planning)" 장에서 다양한 수정 폭포수 모델에 대해 다루고 있다.

사시미(Sashimi) 모델[편집]

사시미 모델은 (일본의 음식인 사시미가 생선회를 겹쳐 내놓듯이, 이 수정 모델은 각 단계가 겹쳐서 진행된다는 의미에서 이러한 이름이 붙었다.) 처음으로 피터 디그레이스(Peter DeGrace)에 의해 고안되어 소개되었다. 때로 이 모델은 "겹친 단계를 가진 폭포수 모델" 또는 "피드백 있는 폭포수 모델"이라고 인용되곤 한다. 사시미 모델에서 각 단계들이 서로 겹쳐 있기 때문에, 문제점에 대한 정보는 그 전단계에서 파악될 수 있다. 예를 들어, 사시미 모델에서 설계와 구현 단계는 겹쳐져서 진행되기 때문에, 구현 상의 문제는 설계가 완료되기 이전에 발견된다. 사시미 모델의 이런 점은 폭포수 모델의 한계점을 완화하는 데 도움을 준다.

각주[편집]

  1. ↑ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
  2. ↑ "Managing the Development of Large Software Systems" Archived 2016년 3월 15일 - 웨이백 머신, Dr. Winston W. Royce (PDF file)
  3. ↑ "A Rational Design Process: How and Why to Fake It" Archived 2008년 9월 20일 - 웨이백 머신, 데이빗 파나스 (PDF 파일)

같이 보기[편집]

더 읽을 거리[편집]

외부 링크[편집]

위키미디어 공용에 관련된
미디어 분류가 있습니다.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=폭포수_모델&oldid=35676793"