소프트웨어 개발 이론에 대한 아주 유명한 그림이 있습니다.

고객이 원하는 것을 분석하고 제공하는 것은 정말 어려운 일입니다. 게다가 고객이 원하는 것은 시간이 지날수록 바뀌기도 합니다. 고객의 요구사항을 분석하고 그리고 변화해가는 요구사항에 대응해나가기 위해서 과거부터 다양한 소프트웨어 개발 프로세스들이 존재해왔습니다.

폭포수 모델(Waterfall Model)

위에서 아래로 물이 떨어지는 것처럼,

폭포수 모델 단계

• 요구 사항 분석
• 소프트웨어 설계
• 소프트웨어 구현
• 테스트 및 디버깅
• 배포
• 유지 보수

의 단계를 순차적으로 수행하는 모델입니다.

단계별로 구분이 뚜렷해서 이해하기 쉬운 모델이지만, 너무 이상적인 상황을 가정한 모델이기도 하고 개발 도중에 발생하는 여러 가지 상황들과 고객의 요구사항 변화에 대응하기가 너무 힘들다는 단점이 존재합니다.  (하지만 일반 회사의 윗 사람들은 좋아하는 방식이기도 합니다. 다른 모델에 비해 일정 관리가 수월하기 때문이죠.)

나선형 모델(Spiral Model)

선형 모델 단계

• 목표 설정
• 위험 분석(Risk 분석, 프로토타입)
• 엔지니어링(요구사항 분석,점 설계, 구현, 테스트)
• 다음 단계 계획[/su_box]

나선형 모델은 위의 4단계를 반복하는 프로세스입니다. 폭포수 모델에 위험 분석 단계를 추가하고, 각 단계를 반복 수행하면서 프로젝트의 리스크를 최소화할 수 있는 모델로, 대규모 프로젝트에 적합하다고 알려져 있습니다.

다만 프로젝트가 요구하는 과정이 많아져서 프로젝트 일정이 길어질 수 있으며, 성공 사례가 드물다는 단점이 있습니다.

애자일(Agile)

나선형 모델과 비슷하게 일정한 주기를 가지고 끊임없이 프로토타입(Prototype)을 만들고 그 때마다 요구사항을 체크해나가면서 프로젝트를 진행해나가는 방법입니다.

나선형 모델과 애자일의 목적

나선형 모델 목적 : 위험도 최소화
애자일 : 끊임없이 변화하는 고객의 요구사항에 유연하게 대처하는 것[/su_box]

그러기 위해서 애자일에서는 고객과 팀원간 꾸준한 교류를 하고 개발에 불필요한 문서 등은 최소화(Document-Oriented가 아닌 Code-Oriented)하고 팀원간 협업을 강조하고 있습니다. 민첩함을 높이기 위해 소규모의 팀을 선호하는 경향이 있습니다.

스크럼(Scrum)

30일마다 프로토타입을 만드는 애자일 방법론.
개발 주기를 30일로 잡고, 이를 스프린터(Sprint) 또는 이터레이션(Iteration)이라고 부른다.
매일 15분씩 회의를 하며 이슈나 우선사항을 서로 공유한다.

XP(eXtreme Programming)

의사소통, 피드백, 단순함, 용기, 존중에 가치를 두고 있는 방법론.
고객과 2주 정도의 반복 개발을 하며 테스트를 무척 강조한다.

애자일도 다양한 단점을 갖고 있습니다. 문서 중심이 아니다보니 설계 문서 등이 작성되지 않아 지원성(Supportability) 문제가 발생할 수 있으며, 멤버들의 기억력에 의존하는 경향이 있어 시간이 지나면 요구사항의 필요성, 설계의 방향 등에 대한 세부사항을 잊는 경우도 발생할 수 있습니다. 컴포넌트를 유지보수하기보다는 처음부터 다시 작성하는 경향을 갖게 될 수 있으며 이를 NIH(Not implemented Here) 증후군이라고 부릅니다.

불필요한 것들을 많이 줄이고 없애다보니 인프라 구조 등을 버리게 되는 상황도 발생할 수 있으며, 이는 대규모 프로젝트에 적합하지 않은 상황을 만들기도 합니다. 팀간 인터페이스 공유가 제대로 되지 않아 인터페이스 수정이나 리팩토링(Refactoring)에 어려움을 겪기도 하는 단점이 있습니다.