소프트웨어 설계 1강. 소프트웨어 생명주기와 개발 방법론
폭포수 모델을 세상에 그려 보인 사람은, 같은 논문에서 그 방식이 위험하다고 경고했습니다. 시험은 그 그림만 기억하고 경고는 잊었죠.
풀고 시작
폭포수 모델은 반대하려고 그린 그림이었습니다
1970년, 윈스턴 로이스가 대형 소프트웨어 개발을 관리하는 법에 대해 논문을 씁니다. 거기에 요구분석에서 시작해 설계, 구현, 시험, 유지보수로 한 방향으로만 떨어지는 그림이 실렸죠. 우리가 아는 폭포수 모델입니다. 그런데 로이스는 그 그림 바로 아래에 이렇게 씁니다. 이 방식은 위험하며 실패를 부른다고요. 그가 정말 하고 싶었던 말은 앞 단계로 되돌아가는 화살표와 시제품을 반드시 넣으라는 것이었습니다. 업계는 그림만 가져가고 경고는 두고 갔습니다.
폭포수 모델(Waterfall)의 핵심은 각 단계가 끝나야 다음 단계를 시작한다는 것, 그리고 단계마다 산출 문서가 남는다는 것입니다. 요구사항이 명확하고 잘 바뀌지 않는 사업, 예컨대 관공서 시스템에서는 여전히 유효합니다. 문제는 고객이 최종 결과물을 마지막에야 본다는 점이죠. 그래서 프로토타입 모델이 나옵니다. 최종 결과물의 일부를 미리 만들어 보여 주고, 그걸로 요구사항을 확정한 뒤 본 개발에 들어가는 방식입니다.
나선형 모델(Spiral)은 배리 보엠이 1988년에 제안했습니다. 계획 및 정의, 위험 분석, 개발, 고객 평가라는 네 활동을 한 바퀴로 삼아, 나선을 그리며 시스템을 키웁니다. 시험이 좋아하는 포인트는 딱 하나, 위험 분석이 정식 단계로 들어 있는 유일한 모델이라는 사실입니다.
애자일은 계획을 버린 게 아닙니다
2001년 열일곱 명의 개발자가 유타의 스키 리조트에 모여 애자일 선언문을 씁니다. 유명한 네 문장은 이렇게 생겼습니다. 프로세스와 도구보다 개인과 상호작용을, 방대한 문서보다 동작하는 소프트웨어를, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 중시한다.
여기서 오해가 자주 생깁니다. 선언문은 오른쪽 항목에도 가치가 있다고 명시적으로 덧붙입니다. 문서를 쓰지 말라거나 계획을 세우지 말라는 뜻이 아니라, 둘이 충돌할 때 왼쪽을 고르겠다는 우선순위 선언이죠.
| 방법론 | 특징 | 자주 묻는 키워드 |
|---|---|---|
| XP (eXtreme Programming) | 짧은 주기 릴리스, 실천법 중심 | 5가지 가치: 용기·단순성·의사소통·피드백·존중. 페어 프로그래밍, 테스트 주도 개발, 리팩토링 |
| 스크럼 (Scrum) | 스프린트 단위의 반복 개발 | 제품 백로그, 스프린트 백로그, 일일 스크럼, 스프린트 회고, 번다운 차트 |
| 린 (Lean) | 도요타 생산방식에서 옴 | 낭비 제거, 전체 최적화 |
스크럼에서 스크럼 마스터는 팀장이 아닙니다. 일을 시키는 사람이 아니라 팀이 일하는 데 걸림돌을 치워 주는 사람이죠. 우선순위를 정하는 것은 제품 책임자(Product Owner)의 몫입니다. 이 구분이 시험 단골입니다.
소프트웨어 공학이 서 있는 세 다리
소프트웨어 공학의 3요소는 방법(method), 도구(tool), 프로세스(process)입니다. 무엇을 어떻게 만들지가 방법이고, 그것을 지원하는 자동화 수단이 도구이며, 둘을 언제 어떤 순서로 쓸지 정한 것이 프로세스입니다. 좋은 도구를 사도 프로세스가 없으면 제자리인 이유가 여기 있죠.
관련해서 자주 나오는 개념이 CASE(Computer Aided Software Engineering)입니다. 개발 과정을 자동화하는 도구를 통칭하는데, 상위 CASE는 계획과 분석·설계 단계를, 하위 CASE는 구현과 시험 단계를 지원합니다.
다음 강에서는 이 생명주기의 첫 관문인 요구사항을 어떻게 끌어내고 확인하는지 봅니다. 개발이 실패하는 원인의 절반은 코드가 아니라 여기서 만들어집니다.
인출 문제
생각해볼 질문 (정답 없음)
요구사항이 자주 바뀌는 프로젝트에 폭포수를 쓰면 실패한다고들 합니다. 그렇다면 요구사항이 정말 고정된 프로젝트가 존재할까요. 만약 없다면 폭포수 모델은 왜 아직 살아남아 있을까요.