개발 프로세스, 즉 소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle)을 기반으로 만들어졌다.
요구분석 및 시스템 명세 작성 : 문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계다. 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.
설계 : 설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다. 크게 시스템, 프로그램, UI(User Interface) 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계하고, 프로그램설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계한다.
구현 : 설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용하여 실제 프로그램을 작성한다. 이때 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉩니다.
테스트 : 테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가한다. 미처 발견하지 못한 오류를 발견할 수 있기 때문에 매우 중요한 과정이다.
배포 및 유지보수 : 배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭한다. 이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지한다. 유지보수의 유형에는 수정형, 적응형, 완전형, 예방형 총 네 가지가 있다.
무엇을 개발할지 결정하고 요구사항들을 구현 작업에 적합하게 명확하고 조직화된 구조로 바꾸는 과정을 거쳐, 실제 개발에 착수하는 단계는 ‘구현’부터다. 현재 그림 상으로는 이 단계들이 계속 꼬리를 물고 도는 순환 구조로 되어 있지만, 실제 개발 환경에서는 환경에 따라 각각의 단계가 또 세밀하게 나뉘어져 있기도 하며, 각 단계가 계속해서 반복되기도 한다.
이러한 개발 프로세스는 다양한 모델이 있는데 어느 정도 규모의 앱을 개발하는 지, 혹은 어떤 종류의 앱을 개발하는 지를 고려하여 모델을 선택해 사용한다.
기존에 존재하고 있던 개발 프로세스는 워터폴(Waterfall) 방식이 다. 영어에서 주는 직관적인 느낌 그대로, 폭포와 같이 한 방향으로만 프로세스가 진행되는 개발 과정을 뜻하고 실제로 한국어로도 “폭포수 개발 방식” 이라고도 한다.
보통 이런 사이클을 가지고 있으며, 유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델이라고 볼 수 있다. 여기서 변형된 모델들이 나오나 보통은 프로세스가 기본 모델에서 추가가 되거나 하나의 프로세스가 세부적으로 나뉘거나 하는 수준에서 그친다.
이런 워터폴 개발 방식은 실제 출시 기한을 정해놓고 순차적으로 프로세스가 진행시켜 어플리케이션(소프트웨어)를 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다. 또한 실제 디자인 또는 개발된 화면을 시각적으로 확인할 수 있는 단계는 이미 많은 단계가 지나온 시점이기 때문에 어떤 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 에로 사항이 생기게 된다. 대부분 그래서 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장 받기가 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있다.
그래서 전통적인 소프트웨어 개발 프로세스에서는 소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 한다.
애플리케이션을 사용할 때, 접속하는 순간 “새로운 버전이 존재하니 업데이트를 하세요” 라는 문구와 함께 게임 자체가 꺼지게 된다. 이러한 점은 대부분의 모바일 애플리케이션이 사용하는 전달 방식의 한계다.
애플리케이션이 접속할 시, 이런 현상을 보이는 이유는 다양한 테스트 방식을 도입했음에도 사용자가 항상 최신 상태로 업데이트를 해줘야 하고, 버그 수정(patch)된 버전을 유저에게 즉각적으로 전달하기가 어렵다.
그런 전통적인 개발 프로세스에서 벗어나기 위해 만들어진 프로세스 중 하나가 애자일(Agile) 방식이다. 이 애자일 방식은 ‘스프린트(sprint)' 라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복한다.
이 방식은 요구사항이 변하는 것을 당연한 전제로 두고 있다. 따라서 계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발에 착수할 수 있다.
애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능하고 이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합하다.
SaaS는 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식이다. 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없다.
띠라서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능합니다. 또한 빠른 배포 속도도 보장 받을 수 있다.
그렇다면 전통적인 개발 프로세스는 모던 개발 프로세스에 비해 현저히 떨어지는 프로세스일까요? 그렇지는 않다. 모던한 개발 프로세스를 따른다 해도 “제대로" 따르지 않는다면 하느니만 못하기 때문이다.
장점
단점
이런 상황에 적합
이런 기업 및 팀에 적합
장점
단점
이런 상황에 적합
이런 기업 및 팀에 적합