소프트웨어 개발 방법론
소프트웨어 개발 방법론이란 소프트웨어 개발에 대한 체계적인 접근 방식을 의미합니다. 소프트웨어 개발 방법론은 소프트웨어 개발 과정에 필요한 단계, 활동, 산출물, 순서 등을 정의하고 설명합니다.
소프트웨어 개발 방법론의 일반적 단계
- 요구사항 분석
- 소프트웨어가 해결해야 할 문제와 고객의 요구사항을 파악하고 정의하는 단계입니다.
- 다양한 이해관계자 간에 상충할 수 있는 요구사항을 고려해, 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계입니다.
- 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계입니다.
- ex) 기능 요구사항, 비기능 요구사항
- 설계
- 소프트웨어의 구조와 기능, 인터페이스, 알고리즘 등을 대략적으로 설계하는 단계입니다.
- ex) 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계
- 구현 또는 코딩
- 설계한 내용을 프로그래밍 언어로 작성하여 실제로 동작하는 소프트웨어를 만드는 단계입니다.
- 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계입니다.
- ex) 인터페이스 개발, 자료구조 개발, 오류 처리
- 테스트
- 구현 단계에서 만들어 낸 소프트웨어가 오류나 결함 없이 예측했던 대로 동작하는 지 검증하는 단계입니다.
- ex) 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
- 유지보수
- 시스템이 인수되고 설치된 후에 일어나는 모든 활동을 의미합니다.
- 배포된 소프트웨어의 성능을 개선하거나 새로운 기능 및 요구사항을 정의하고, 변화에 대응해 수정 및 업데이트하는 등 배포 이후에 일어나는 모든 과정을 일컫습니다.
- ex) 예방, 완전, 교정, 적응 유지보수
대표적으로 사용 되는 소프트웨어 개발 방법론의 종류
폭포수 모델(Waterfall Model)
- 가장 전통적이고 오래된 모델입니다.
- 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 순으로 단계가 진행 됩니다.
- 각 단계는 순차적으로 진행되며, 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있는 모델입니다.
- 모델의 적용 사례와 성공 사례가 가장 많습니다.
- 단계별 정의와 산출물이 명확합니다.
- 요구사항 변경에 대한 대처가 어렵습니다.
- 계획이 명확하고 변경이 적은 프로젝트에 적합합니다.
애자일 모델(Agile Model)
- 고객의 피드백을 빠르게 반영하며, 잦은 변화에 유연하게 대응하는 모델입니다.
- 작은 단위로 개발하고 테스트하며 지속적으로 개선하는 모델입니다.
- 사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델입니다.
- 요구사항이 자주 바뀌고 협업이 많이 필요한 프로젝트에 적합합니다.
소프트웨어 개발 방법론 선택 시 고려할 사항
프로젝트의 특성
- 프로젝트의 목적, 규모, 복잡도, 기간, 예산 등을 모두 고려하여 적절한 모델을 선택해야 합니다.
- 명확하고 안정적이며, 변화할 여지가 적은 요구사항이 있는 단순한 프로젝트라면 폭포수 모델이 적합할 수 있습니다.
- 불확실하고 요구되는 기능에 변화가 일어날 가능성이 높거나, 잦은 변화가 일어나는 복잡한 프로젝트라면 애자일 모델이 적합할 수 있습니다.
고객 참여도
- 고객이 프로젝트에 얼마나 관여하고 피드백을 제공할 수 있는지 고려해야 합니다.
- 고객이 최초 목표 수립과 요구사항 제시 이후에는 프로젝트와 밀접하지 않거나, 상대적으로 소극적으로 참여하는 상황에서 최종 결과물을 제공해야 한다면 폭포수 모델이 적합할 수 있습니다.
- 고객이 프로젝트와 아주 밀접하게 있거나, 빠르고 잦은 피드백을 원한다면 애자일 모델이 적합할 수 있습니다.
팀의 역량과 문화
- 팀의 인원 수, 역할, 책임, 기술 수준, 협업 방식 등을 고려해 적절한 모델을 선택해야 합니다.
- 팀의 규모가 크고 계층 구조를 갖고 있고, 상대적으로 낮은 기술 수준과 협업이 중요하지 않은 환경을 갖고 있다면 폭포수 모델이 적합할 수 있습니다.
- 팀의 규모가 작고 자율적이며, 상대적으로 높은 기술 수준과 협업이 잦은 환경이라면 애자일 모델이 적합할 수 있습니다.
소프트웨어 개발 방법론을 선택해 적용하는 것은 프로젝트의 성공과 실패에 큰 영향을 끼치는 아주 중요한 결정입니다.
소프트웨어 개발 방법론을 최초에 선택한 이후에도 변경할 수는 있습니다.
하지만 이후에 변경하는 과정은 쉽지 않고 비용 또한 많이 들 수 있습니다.
예를 들어 폭포수 모델에서 애자일 모델로 변경하게 된다면 팀의 구성과 각자의 역할, 작업 방식, 문화, 그리고 도구와 기법 등을 모두 바꾸고 팀원 모두 새롭게 교육을 해야 합니다. 또한 고객과의 일정이나 계약 또한 조정이 필요할 수 있습니다.
따라서 프로젝트의 특성과 규모, 고객의 참여도와 팀의 역량, 문화 등을 충분히 분석하고 비교해 최적의 모델을 선택해야 합니다.
애자일 방법론
애자일 방법론의 등장 배경
애자일 방법론은 요구사항이 변화하는 것을 당연한 전제로 두고, 변화하는 요구사항에 민첩하게 대응하며 개발을 수행하는 소프트웨어 개발 방법론으로, 문서에 의존하기보다는 코드 지향적으로 효율적인 개발을 지향하는 목적에서 탄생했습니다.
애자일 방법론은 특정 방법론을 가리키는 것이 아니라 뒤에서 살펴볼 스크럼(Scrum), 익스트림 프로그래밍(XP), 칸반(Kanban) 등 좋은 것을 빠르고 낭비 없게 만드는 다양한 방법론 전체를 일컫습니다
정리하자면 애자일 방법론은 절차보다는 사람이 중시되어 변화에 유연하고 신속하게 대처하면서 효율적으로 빠르게 시스템을 개발할 수 있는 방법론입니다. 작업 단위를 세분화해 개발 기간이 짧고 산출물 확인이 신속하게 이루어지며, 개발 완료 시 바로 피드백을 받기 때문에 개발과 피드백에 유연하게 대응할 수 있습니다.
폭포수 방법론과 애자일 방법론의 차이
애자일 방법론과 대비되는 폭포수 방법론은 요구분석부터 기획, 개발, 테스트, 출시까지 순차적으로 진행하여 마치 폭포가 떨어지는 식으로 순차적인 단계를 밟는 전통적인 개발 방법론입니다.
폭포수 방법론은 기획단계에서 프로젝트 전체를 대상으로 플래닝을 진행한 후 프로젝트 전체에 대한 기획문서가 나온 후 일괄적으로 개발에 들어가는 진행방식을 띄고 있어, 개발을 진행하면서 발생하는 기획단계에서 예측할 수 없는 이슈들에 대해 유연하게 대응하기 어렵습니다.
이렇듯 폭포수 방법론의 문제점은 요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하기 힘들다는 것입니다.
대응하지 못한 이슈들이 엉키게 되면 아래와 같은 문제점들이 발생하여 프로젝트에 참여한 모든 구성원들이 어려움을 겪게 됩니다.
- 코드 품질 저하
- 요구사항이 충족되지 않음
- 기대 이하의 산출물
- 시간 지연
- 프로젝트 종료에 관한 낮은 예측 정확도
이처럼 폭포수 방법론과 같은 기존 방법론은 문서 및 절차 위주로 진행되기 때문에, 변화에 민감하게 대응하지 못하고 개발 주기가 빠르지 못하다는 단점이 있습니다. 빠르게 변화하는 시장에 민감하게 대응해야 하는 시장 적시성과 잦은 배포의 중요성이 점차 대두되면서 애자일 방법론이 폭포수 방법론을 대체하기 시작했습니다.
전통적인 개발 방법론인 폭포수 방법론과 애자일 방법론의 차이를 정리해 보겠습니다.
폭포수 방법론은 요구분석, 기획등 전체 프로젝트에 대한 모든 문서를 만들고, 해당 작업들이 모두 끝난 이후 개발에 들어갑니다. 문서와 절차의 중요성이 큰 방법론입니다. 그러나 고객의 요구에 민감하게 반응하기 어렵다는 단점이 있습니다.
반면 애자일 방법론은 고객의 요구사항들을 충족하기 위해 시장에 민감하게 반응하며 개발하는 방법론입니다. 따라서 애자일 방법론에서는 문서가 아닌 코드로 보여주는 것이 중요시되고, 전체가 아닌 기능 단위의 프로토타입을 기반으로 개발이 진행됩니다. 좀 더 작은 단위로 개발을 해서, 해당 부분을 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈처리에 대한 기민한 대응을 하기 위함입니다.
애자일 방법론을 구체화하기 위한 도구들
애자일 방법론을 활용하기 위한 도구들은 여러 가지가 있습니다. 그중 가장 많이 사용하는 두 가지 도구인 스크럼(Scrum)과 칸반(Kanban) 대해서 좀 더 자세하게 알아보도록 하겠습니다.
먼저, 설명에 들어가기 전에 기억하셔야 할 단어를 알려드릴게요. 스크럼은 “스프린트 기반", 칸반은 “WIP”입니다. 스크럼은 스프린트를 기반으로 애자일 방법론을 실행하고, 칸반은 Work In Process(WIP)를 제한하여 애자일 방법론을 실행합니다.
스크럼(Scrum)
스크럼은 스프린트 작업 단위를 부여하며 스프린트는 보통 2주를 기준으로 하고, 팀의 특성에 맞춰 줄이거나 늘릴 수 있습니다.
한 스프린트가 시작하는 월요일 하루에 걸쳐 해당 스프린트 기간 동안 작업할 수 있는 개발자 개개인의 시간들을 모두 합쳐 총 작업시간을 책정하고, 스프린트 동안 할 작업들을 추산하는 플래닝을 진행합니다. 매일 오전 약 15분 정도의 데일리 미팅을 진행해 오늘 할 일을 공유하고 어제 한 일을 간단히 리뷰합니다. 또한 해당 스프린트가 끝나는 주의 금요일에는 그동안 플래닝을 통해 진행했던 작업들에 대한 회고를 진행합니다.
플래닝은 PO(product owner), 스크럼 마스터(Scrum Master), 개발자가 참여하여 플래닝 포커를 통해 진행합니다. PO는 고객을 대변하는 비즈니스 담당자입니다. 비즈니스의 입장에서 필요한 기능들을 말하는 역할을 담당합니다. 스크럼 마스터는 개발의 측면에서 PO가 말한 비즈니스 기능들을 개발 가능한 단위로 쪼개고 조율하는 역할을 합니다. 스크럼 마스터는 개발자들이 번갈아 가면서 맡기도 합니다.
기능을 분리할 때는 가능한 한 작은 단위로 분리하는 것이 좋습니다. 예를 들어, 관리자 페이지 개발보다는 관리자 페이지 내 회원가입기능 중 이메일 인증 부분 개발이 더 작은 단위로 분리되었다고 할 수 있습니다.
플래닝 포커 진행 순서
가능한 작은 단위로 쪼개진 각 카드들을 가지고 개발자들이 모여 앉아 한 카드에 대해 개발 시간이 얼마나 걸릴지를 추정하는 작업인 플래닝 포커를 시작합니다.
플래닝 포커를 진행하는 방식은 모든 “개발자”들이 포커 게임을 하듯 해당 기능을 구현하는 데 필요한 사항을 고려하여, 본인이 해당 이슈카드를 맡았다고 생각했을 때 걸릴 추정 시간을 남들이 보지 못하게 동시에 제시하는 것입니다. (날짜 단위는 0.5h, 1h, 2h, 3h, 4h, 5h, infinite까지 존재하며, 팀의 특징에 따라 day나 point로 바뀌기도 합니다.) 이때 중요한 것은, 플래닝 포커는 어떤 기능 개발을 누가 맡을지 미리 정하지 않은 채로 진행되어야 합니다.
예를 들어 <관리자 페이지 내 로그인 부분 개발>이라는 이슈카드에 대해서, 철수는 3h, 순이는 1h, 영자는 5h를 제시했다고 가정해 봅시다. 그럼 가장 긴 시간을 제시한 영자와 가장 짧은 시간을 제시한 순이가 그 자리에서 바로 본인이 왜 그렇게 추정했는지 팀원들을 상대로 설명을 합니다.
그러고 나서 다시 플래닝 포커를 진행합니다. 이번에는 철수는 2h, 순이는 2.5h, 영자는 3h을 제시했다고 가정하겠습니다. 간격이 줄어들긴 했지만 아직 일치하지 않기 때문에, 가장 짧은 시간을 제시한 철수와 가장 긴 시간을 제시한 영자가 다시 의견을 제시합니다.
이 작업을 모든 개발자가 만장일치가 나올 때까지 진행합니다. 이때 핵심은 모든 이슈카드에 대해 만장일치가 되어야 한다는 것입니다. 이런 방식으로 한 스프린트에 필요한 모든 이슈카드에 대해 플래닝을 하는 작업은 생각보다 시간이 많이 들고 어려운 작업입니다. 하지만 반드시 꼭 진행해야 하는 가치가 있는 작업입니다.
스프린트 진행
이렇게 플래닝을 통해 시간 추정이 완료된 모든 이슈카드들은 이번 스프린트 기간 동안의 작업시간만큼 계산하여 스크럼보드 상 Backlog에서 Todo로 옮겨지며, Todo에 있는 모든 카드는 해당 스프린트 동안 완료해야 하는 목표가 됩니다.
개발자들은 Todo에 있는 이슈카드를 끌어다 In progress 부분에 옮겨두고 한 스프린트 기간 동안 개발을 진행합니다.
어떤 카드를 선택할지는 본인 마음입니다. 먼저 선택하는 사람이 본인이 더 하고 싶은 카드를 들고 가서 시작하면 됩니다. 단, 한 팀원 당 한 개의 이슈카드만 In progress에 담아 진행할 수 있으며 해당 카드에 대한 작업이 모두 완료되어 Done으로 옮겨진 이후에만 Todo에서 새로운 이슈카드를 시작해 In progress로 옮길 수 있습니다.
스프린트는 플래닝을 통해 해당 스프린트에 진행할 작업을 정하고 시간을 추정했기 때문에, 플래닝 때 정해진 작업을 스프린트 기간 내에 완료하는 것을 목표로 달립니다. 따라서 스프린트 중간에 들어오는 이슈카드는 무조건 다음 스프린트를 위한 BackLog의 상단으로 들어가게 되며 해당 스프린트 기간 동안에는 고려하지 않습니다. 플래닝 때 고려된 이슈카드들을 기준으로 시간을 산정했고 약속한 기간 내에 끝내는 것을 약속했기 때문입니다.
회고
이렇게 스프린트를 진행한 후 스프린트 마지막날 스프린트 기간 동안 진행한 작업들을 플래닝 내용을 가지고 회고를 합니다. 이슈가 있었던 부분, 잘한 점, 부족했던 점, 아쉬웠던 점, 더 나아졌으면 하는 점 등등 많은 의견들이 오가는 자리입니다. 다과와 커피를 함께하며 스프린트를 진행하는 동안 발생했던 이슈가 다음 스프린트 때는 고려될 수 있도록 서로의 경험을 공유하는 무겁지 않게 팀워크를 다지는 시간이기도 입니다.
칸반(Kanban)
칸반 방식의 핵심은 WIP(Work In Progress) 제한입니다. ****칸반과 스크럼의 가장 두드러지는 차이는 칸반은 스크럼처럼 스프린트처럼 약속된 업무 종료일이 없다는 것입니다.
칸반도 스크럼과 마찬가지로 새롭게 들어온 이슈카드에 대해 시간을 추정하는 작업을 합니다. 그러나 스크럼과는 달리 플래닝을 하는 날이 따로 정해져 있지 않고 매일 오전 약 15분 정도 진행되는 데일리 미팅에서 새롭게 들어온 이슈카드의 기능을 구현하기 위한 요구사항을 분석하고 시간이 얼마나 걸릴지 플래닝을 진행합니다.
하지만, 앞서 말한 것처럼 해당 이슈카드가 언제 시작되어서 언제까지 기능을 완료할지는 스크럼처럼 정해진 기간이 명확하지 않습니다. 이슈카드는 정해진 종료 기한 없이 Backlog에 쌓이게 되고, 연속적인 일의 흐름에서 급한 작업단위의 순서대로 In progress에 이슈카드를 넣고 처리합니다. 그렇다고 한 명의 개발자가 모든 작업을 가져와 In progress에 동시에 넣고 진행할 수 없으며, 이는 실제 작업하는 방식을 고려하더라도 불가능합니다.
따라서, 개발팀의 인원과 특성을 고려하여 In Progress에 넣을 수 있는 이슈카드의 개수가 제한되는데, 이를 WIP(Work In Progress) 제한이라고 부릅니다. 개발자들은 미리 정한 WIP에 여유가 있을 때에만 백로그에서 이슈카드를 In Progress로 옮겨와 작업을 진행할 수 있습니다. 칸반 방식은 이러한 WIP 제한을 통해 쏟아져 들어오는 이슈카드들 속에서 허우적거리며 개발이 제대로 진행되지 않을 수 있는 위험을 방지합니다.
언제 스크럼을 선택하고 언제 칸반을 선택하나요?
주로, 프로젝트 같은 종료일이 정해져야 하는 업무가 많이 발생하는 경우는 스크럼, 지속적인 업무를 다루며 프로젝트 개발 및 Ops까지 함께 다뤄야 하는 상대적으로 작은 단위의 팀에서는 칸반을 사용하는 것이 효율적입니다.
Hotfix를 대하는 스크럼과 칸반의 차이
Hotfix는 지금 당장 수정해서 실제 돌아가는 Production 서비스에 바로 배포를 내보내야 하는 플래닝 시점에 미리 예측되지 않았던 긴급한 버그나 오류 이슈를 뜻합니다. 운영되고 있는 서비스라면 고객이 마주친 버그인 경우가 많습니다. 스크럼과 칸반에는 이 Hotfix를 다루는 관점이 다르며 아래에서 좀 더 상세하게 살펴보도록 하겠습니다.
스크럼에서는 HotFix는 해당 스프린트에 “절.대.” 넣지 않습니다.
운영 중인 서비스라면 개발자가 돌아가며 긴급한 Hotfix 수정을 하고 배포를 하는 sustainment 업무를 돌아가며 맡기도 합니다. 하지만 기본적으로 아주 매출에 직접적인 영향을 미치는 Top Priority급 Hotfix가 아니라면, 스프린트 진행 중 발생하는 모든 Hotfix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 스프린트의 업무가 됩니다.
반면, 칸반에서는 HotFix 또한 바로 프로젝트 backlog에 쌓습니다.
쌓인 Hotfix를 바로바로 처리할 수 있습니다. 해당 프로젝트를 끝내기 위해 처리해야 할 이슈카드로 동일하게 취급합니다. 이는 시간추정을 통해 이슈카드를 언제까지 처리할지 약속하지 않기 때문에 가능한 일입니다.
