폭포수 방법론과 애자일 방법론

왜 배우는가: 폭포수 모형과 애자일 방법론은 프로젝트 특성에 맞는 개발 방식을 고르는 문제로 시험에 반복해서 나온다. 실무에서도 요구 변화 정도에 따라 방법론을 선택하고 그 근거를 설명할 수 있어야 한다. 1교시 비교형 문제의 기초 개념이므로 먼저 정리해 두어야 한다.

출제 이력: 제131회 1교시 3번, 제99회 1교시 11번

1. 한 줄 정의와 핵심 키워드

폭포수는 단계를 순차로 진행하는 계획 중심 방법론, 애자일은 짧은 반복으로 변화를 수용하는 적응형 방법론이다.

두 방법론은 같은 소프트웨어를 만든다는 목적을 공유하지만, 개발 순서와 계획을 대하는 태도가 다르다. 폭포수는 앞 단계 산출물이 확정되어야 다음 단계로 넘어가고, 애자일은 기능을 작게 나눠 만들고 확인받는 일을 되풀이한다. 답안 첫 줄에는 위 정의를 쓰고, 아래 키워드를 본문 흐름에 맞춰 배치한다.

• 폭포수 모형
• 순차적 개발
• 계획 중심
• 반복 개발
• 적응형 개발
• 애자일 선언문
• 코드 중심
• 고객 협업

2. 개념 풀이

쉬운 말로 말하면 폭포수는 물이 한 층씩 떨어지듯 앞 단계가 끝나야 다음 단계로 내려가는 방식이다. 애자일은 작은 기능을 빨리 만들어 보여주고, 그 반응을 반영해 다시 고치는 방식이다. 둘 다 결과물을 만드는 것은 같지만, 변화가 생겼을 때 어디서 흡수하느냐가 다르다.

정식 정의로 폭포수 모형(Waterfall model)은 요구분석, 설계, 구현, 시험, 통합, 유지보수 단계를 순차적으로 거치는 소프트웨어 개발 프로세스다. 흐름이 위에서 아래로 계속 떨어지는 것처럼 보여 이 이름이 붙었다. 한 단계가 끝나면 이전 단계로 되돌아가지 않는 것이 원칙이다.

핵심 용어 순차적 개발은 단계마다 완료 기준을 정하고, 다음 단계는 그 기준이 충족된 뒤에 시작하는 방식을 뜻한다. 시험 단계는 구현이 모두 끝난 뒤 시작하는 것이 기본이다. 이 때문에 결함은 후반부에 몰려 발견되는 경향이 있다.

애자일(Agile)은 특정 방법론의 이름이 아니다. 애자일 가치를 따르는 여러 방법론을 통칭하는 말이며, 대표적으로 익스트림 프로그래밍(XP)이 꼽힌다. 스크럼(SCRUM)과 칸반(Kanban)도 애자일과 함께 다뤄진다. 애자일 방법론은 과거에 경량(Lightweight) 프로세스라고도 불렸다.

애자일의 출발점은 애자일 선언문이다. 선언문은 네 가지 가치를 제시한다. 공정과 도구보다 개인과 상호작용, 포괄적인 문서보다 작동하는 소프트웨어, 계약 협상보다 고객과의 협력, 계획을 따르기보다 변화에 대응하기를 더 높이 평가한다. 왼쪽 항목도 가치가 있지만 오른쪽 항목에 더 높은 가치를 둔다는 뜻이다.

적응형 개발은 미리 정한 전체 계획을 따르지 않고, 일정한 주기마다 프로토타입이나 증분을 만들어 필요한 요구를 더하거나 고치며 소프트웨어를 키워 가는 방식이다. 애자일을 적응형 방식이라 부르는 이유가 여기에 있다. 주기 길이는 팀과 제품에 따라 다르지만 짧은 반복 주기를 두는 것이 공통 특징이다.

3. 등장 배경과 필요성

계획이 전혀 없는 개발은 앞일을 예측하기 어렵고 효율이 떨어진다. 반대로 계획에 지나치게 의존하면 형식 절차에 필요한 시간과 비용이 커지고 개발 흐름이 느려진다. 애자일은 이 두 극단 사이에서 타협점을 찾으려는 흐름에서 나왔다.

폭포수 모형은 오래된 체계적 개발 방식으로 자리 잡았다. 흔히 로이스(Royce)의 논문이 이 개념의 출처로 인용된다. 그런데 그 논문은 ‘폭포수’라는 용어를 쓰지 않았고, 오히려 이 모델을 결함이 있는 사례로 제시했다. 답안에서 배경을 쓸 때는 ‘후대에 정리된 모형’이라고 쓰는 편이 정확하다.

폭포수 시기에는 문서로 설계를 고정한 뒤 구현하는 방식이 주류였다. 이는 대형 시스템에서 일정과 책임을 명확히 하는 데 유리했다. 그러나 요구가 개발 중에 바뀌면 앞 단계 산출물을 다시 고쳐야 하므로 변경 부담이 커졌다.

애자일은 이런 한계를 줄이기 위해 등장했다. 애자일 방법론은 문서 중심이 아니라 코드 중심, 즉 실질적인 코딩을 통한 방법론이라는 점에서 고전 방법론과 구별된다. 작은 변경을 자주 릴리스하고 사용자 피드백으로 결함을 드러내는 방식이 핵심 관행이다.

애자일은 요구 변화를 흡수하고 빠른 피드백으로 가치를 전달하기 위해 등장했다.

필요성은 환경에 따라 다르다. 요구가 안정적이고 규제 요건이 많은 프로젝트는 폭포수의 명확한 단계와 문서가 유리하다. 요구 변화가 잦은 서비스나 시장 반응이 중요한 제품은 짧은 주기의 애자일이 맞다. 두 방법론은 우열이 아니라 프로젝트 특성에 따른 선택이다.

위 표에서 폭포수는 전체 범위를 먼저 고정하고 관리하는 데 강하다. 애자일은 변화를 주기 단위로 흡수하는 데 강하다. 이 두 특성이 곧 방법론 선택 기준이 된다.

4. 구성요소·원리·절차

폭포수 모형의 구성요소는 단계, 단계별 산출물, 단계 사이의 검토 게이트다. 각 단계는 앞 단계의 산출물을 입력으로 받는다. 검토를 통과해야 다음 단계로 넘어가는 구조가 원리의 핵심이다.

위 표는 단계마다 산출물이 하나씩 대응한다는 점을 보여 준다. 답안에서는 산출물 이름을 함께 적어야 단계 구분이 명확해진다.

폭포수의 원리는 세 가지다. 첫째는 단계 순차성이다. 이전 단계가 끝나야 다음 단계가 시작된다. 둘째는 요구 동결(requirements freeze)이다. 요구분석이 끝나면 요구 변경은 별도 변경 절차를 거친다. 셋째는 산출물 기준선이다. 문서가 다음 단계의 입력이자 검토 기준이 된다. 이 세 원리 때문에 초기 단계의 오류가 후반부로 갈수록 비용을 키운다.

폭포수 절차는 다음과 같다.

• 요구사항을 수집하고 요구사항명세서로 확정한다.
• 명세서를 기준으로 설계를 마치고 설계 검토를 받는다.
• 설계에 따라 구현하고 단위 시험을 수행한다.
• 통합 후 시험 단계에서 결함을 검출하고 수정한다.
• 시스템을 배포하고 유지보수 단계로 이행한다.

애자일의 원리는 반복(iteration)과 증분(increment)이다. 짧은 주기마다 동작하는 소프트웨어를 만들고, 그 결과로 요구를 더하거나 고친다. 대표적인 틀인 스프린트(Sprint)는 고정된 주기다. 스프린트 기간은 1개월 이내로 두는 것이 Scrum의 기준이다.

애자일 절차는 다음과 같다.

• 고객 가치 순으로 제품 백로그(Product Backlog)를 정리한다.
• 스프린트 계획에서 이번 주기에 개발할 항목을 고른다.
• 설계, 개발, 시험을 짧은 주기로 함께 수행한다.
• 스프린트 검토에서 고객 피드백을 받는다.
• 회고를 거쳐 개선 사항을 다음 계획에 반영한다.

애자일의 시험은 개발과 분리되지 않는다. 이 점이 폭포수의 후반 집중 시험과 가장 크게 다르다.

폭포수는 계획 주도형, 애자일은 변화 주도형 방법론이다

5. 관련 법령·기준·표준

따라서 이 절은 방법론의 기준이 되는 문서와 수치를 정리한다. 개발 수명주기 프로세스의 국제 표준으로는 ISO 12207 수명주기 프로세스 표준이 참조된다. 애자일 선언문은 방법론의 가치 기준을 제시한다.

위 표에서 스프린트 기간은 방법론 권고 수치다. 프로젝트 규모와 팀 상황에 따라 더 짧게 정할 수 있다. 폭포수 단계 수는 문헌마다 통합과 배포를 나누거나 합쳐 세는 차이가 있다. 답안에는 단계 이름을 빠짐없이 적는 것이 안전하다.

기준 문서의 최신 판을 확인한 뒤 답안에 반영하는 것이 바람직하다.

6. 유형과 비교

폭포수 모델과 애자일 방법론은 출발점이 다르다. 폭포수는 계획을 먼저 세우고 그대로 따르는 계획 중심 방법이고, 애자일은 변화를 전제로 짧은 주기마다 결과를 확인하는 적응형 방법이다. 아래 표는 두 방법을 같은 기준으로 맞춘 것이다.