소프트웨어 개발 과정 소개
소프트웨어 개발에는 다양한 방법론이 존재한다. 오늘은 일반적인 소프트웨어 개발 과정을 한기용님의 강의를 참고하여 정리해보도록 하겠다.
소프트웨어 개발 과정의 주요 부분들은 아래와 같다.
- Plan
- Execute/Track
- Manage Source Code
- Test
- Build
위와 같은 과정의 순서대로 하나씩 방법론과 현상황을 공유하고 정리하도록 하겠다.
1. How to Plan
소프트웨어 개발의 특징으로 꼽자면, 요구조건은 계속해서 변화한다는 것과, 디자인 단계에서 모든 문제를 미리 알 수 없다는 것이 대표적이다. 소프트웨어 개발 모델(프로세스)에는 폭포수, 애자일, 나선, 프로토타입, 테스트 드리븐 등 다양한 방법론이 있는다. 그 중 가장 핵심적으로 알아봐야할 모델은 폭포수(Water Fall)과 애자일(Agile)이다. Water Fall 모델과 Agile Model을 소개하고, Agile Model에 포커스하여 세부 방법론에 대해서 이야기하겠다.
(1) Water Fall Model
폭포수 모델은 소프트웨어 개발 모델 중 초창기에 정립된 모델로, 70년대에 고안되었다고 알려져있다. 폭포수 모델은 분석, 설계, 개발/구현, 테스트가 순서대로 이루어진다. 치명적인 단점으로는 대규모 프로젝트일수록 디자인에 걸리는 시간이 길어지며 그 기간 사이에 요구조건이 바뀔 수 있으며 실제 개발에 들어가면 예상 못한 문제들로 디자인을 변경해야할 가능성이 있다는 점이다.
- 분석 : 고객의 요구조건, 시스템 환경 등 타당성을 검토하고 요구사항에 대한 명세 작성
- 설계 : 요구사항 명세를 바탕으로 S/W의 전체 구조와 구조간의 관계, 상세 알고리즘등을 세부 설계
- 개발/구현 : 요구사항 명세를 준수하는 설계에 따라 개발하는 단계
- 테스트: 통합테스트, 인수테스트, 시스템 테스트를 통해 완성된 프로그램을 테스트하는 단계.Water Fall Model의 키워드는 이렇다. 절차적, 단계검증, 하향식 접근, 피드백.
- 장점
- 오랜기간 사용된 모델로써, 사례가 풍부하며 검증된 방식으로 업무 진행이 가능
- 전체 과정이 S/W 생명주기와 일치하여 이해하기 쉽다.
- 각 진행 단계별 산출물(문서)가 확실하여 진행중 및 진행이후에도 관리가 용이함.
- 단점
- 각 단계가 종결되어야 다음 단계가 진행 가능
- 사용자 피드백에 대한 빠른 대응이 어려움
- 테스트 단계에서 발견된 중요 결함은 치명적인 문제가 될 수 있다.
실제로 법제처의 지능형 문석 검색 서비스 개발에 참여할때 PM께서 이러한 구조를 채택하였는데, AI 모델을 연구개발하는 우리로써는 많은 어려움이 있었다. 분석 과정에서 모델 구조를 선정하였어야하는데, 아직 선례가 없던 개발과정이다 보니 다양한 모델을 선정해서 실험 검토를 진행했어야했다. 다만 정리된 데이터가 없었기에 병행해야 하여 애자일 방법을 제안했는데, 감리사 출신인 PM께서는 거부하셨고 결국 프로젝트가 산으로 갔던 기억이 있다…
(2) Agile Model
변화에 유연하게 대처가 불가한 Water Fall Model의 단점을 보완하기 위해서 개발 주기를 단축하고 잦은 업데이트가 가능하도록 하는 방법론이다. 각 단계별 핵심은 지나치게 긴 토론을 지양한다는 점이다. 결국 아무런 계획 없이 개발하는 방법과 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 발생한 모델이라고 볼 수 있다. 따라서 핵심을 말하자면, 특정한 주기 (Sprint)를 이용하여 실질적인 개발을 진행하며 필요 요구를 더하며 수정하는 방법론이라고 볼 수 있다.
Agile 방법의 특징으로는, 개인과의 상호작용을 중시하며 문서보다는 작동하는 소프트웨어를 중시한다는 점이다. 실제로 애자일 개발 방법론을 채택한 스타트업들이 회고를 중요시하고 소통을 중요시하는데에는 애자일 모델의 특성또한 투영된 것이라고 생각한다.
약 2주 정도의 싸이클을 (보통 Sprint라고 부른다) 기준으로 개발을 진행한다. 한싸이클에서 진행되는 단계는 아래와 같다.
- Backlog Prioritization : Gromming이라고도 불리며, 대개 PM이 작업별 중요도와 복잡도를 결정하는 단계이다.
- Planning : 해당 사이클의 작업을 결정한다 (토론 혹은 투표로 진행된다.)
- Daily Standup Meeting : Scrum이라고도 불리는 것 같으며, 하루의 상황을 보고하는 자리이다.
- Retrospective & Demo : 한 사이클맏 진행된 내용을 회고 및 데모한다.Agile Model의 뚜렷한 특징을 꼽자면, 빠른 의사소통과 개발 착수가 아닐까 싶다. 토론은 빠르고 효율적으로 진행되어야 하며, 간소화가 중요하다.
Agile Model의 키워드는 이렇다. 상호작용, 개발 우선, 협력, 변화 대응
- 장점
- 개발 주기를 통해 프로젝트의 방향과 목표를 가늠할 수 있음
- 반복적인 결과물을 통해 수정된 요구사항 및 문제점에 유연하게 대처 가능
- 단점
- 개발자 중심의 방법론으로 기획, 디자이너가 Passive하게 참여될 수 있다.
- 빈번한 수정으로 개발의 피로도가 높음
- 비용 및 시간이 불완전하게 정의 된 채로 진행될 가능성이 있다.
다음은 Agile Model의 각 과정에서 주목할만한 특징과 형태에 대해서 이야기해보겠다.
Planning
위의 Agile Scrum Model 이미지를 보면 Product Back log 이후에 Planning 단계를 거치는데, Planning 단계에서 사용하는 PM은 Sprint Card를 작성하여 구성원들과 작업별 일정을 산정한다. 스프린트 카드의 구성은 PM 별로 상이하지만 한기용님이 제공하신 예시를 사용하겠다.
<스프린트 카드 예시>
- 타이틀 : 작업의 이름
- 세부설명
- 포인트 (플래닝 포커를 통한다. 아래에서 설명하겠다)
- 성공의 정의: Definition of Done
- 체크리스트: 작업이 성공적으로 끝나는데 필요한 세부작업
위의 과정에서 포인트는 일종의 작업별 일정이다. 그런데 왜 포인트라는 표현을 쓰느냐면, 이를 결정하는데에 Planning Poker라는 방식을 사용하기 때문이다. 포인트는 회사마다 정의가 다른데, 1포인트는 1 Full data for a Developer와 같이 산정되어 있다. 개발자들이 모여 작업별로 들어가는 일정을 산정하는데 이에 포인트를 이용해 투표를 하므로 포커라는 말이 쓰였다. 의견이 상이할 경우에는 토론을 진행하지만, 애자일 방식의 특성상 빠른 의견합치를 요구한다. 따라서 토론이 오래걸릴 경우, 작업의 정의가 명확하지 않거나, 작업의 분할이 필요하다는 것을 암시한다.
Daily Standup Meeting
앞에서 언급한 것과 같이 매일 모든 팀원들이 각자 상황을 공유하는 과정이다. 각 보고 당 10-15분 정도로 상황을 공유한다. 보고의 내용은, 마지막 스탠드업 이후의 작업물, 오늘의 작업 내용와 진행중인 목표, 이슈 정도를 공유한다. 이때 신속하고 빠른 의사소통이 중요하다. (길어지는 회의를 막기 위해서 플랭크를 한다는 밈도 있다)
2. How to Execute/Track
대표적인 협업 툴로는 JIRA 와 Trello 등이 있다.
(1) Jira
프로젝트 관리를 위한 전반적인 기능을 제공하는 툴로 호주의 Altassian 이라는 회사에서 개발하였다. 주요 기능으로는 Agile Scrum 관리 툴, SVN (소스코드 컨트롤), Wiki (협업 문서툴) 등이 있다. 많은 수의 회사들이 JIRA를 프로젝트 관리를 위해 사용한다.
(2) Trello
Agile Scrum 관리를 위한 툴로 JIRA에 비해 훨씬 더 직관적인 단순한 인터페이스를 제공한다. JIRA가 최근에 인수를 하여 결국 한식구가 되었다.
3. How To Manage Source Code
소스 버전 컨트롤
소스버전 컨트롤은 아주 중요하다. 개발자 각자가 개발하는 소프트웨어의 소스코드에 발생하는 변경사항들을 관리할 수 있도록 해주는 프로그램이기 때문이다. 소스 버전 컨트롤의 중요성은 다음과 같다.
- 코드 변경사항들을 쉽게 추적 가능하다. (에러 발생시 이전 버전으로 Rollback 또한 가능하다)
- 다수의 개발자가 공동 개발시에, 공유 및 변경이 용이하다.
- 최근 소스 버전 컨트롤 시스템들은 코드 리뷰 기능 또한 지원한다.
- 코드 백업의 역할 또한 수행 가능.
소스 버전 컨트롤 소프트웨어에는 CVS (Concurrent Version System), SVN (SubVersionN)등이 있지만 가장 대표적인 것은 Git/Github 이다. Github은 가장 인기 있는 버전 컨트롤 소프트웨어 이며, 웬만한 오픈소스 소프트웨어들은 Github상에 존재한다. (Github은 2018년, Microsoft에 $7.5B 가격으로 인수되었다.)
코드리뷰
코드리뷰는 주니어 개발자나 새로 온 개발자들을 트레이닝 시키는 최선의 방법이라고 익히 알려져 있다. 이는 취업을 준비하는 개발자 지망생들이 알고리즘 스터디를 만들어 서로의 풀이를 보면서 최적화하고 리뷰하면서 이 효과를 간접적으로 느낄 수 있을 것이다. 다만, 리뷰를 진행하는 개발자들이 시니어들이라는 점에서 바쁜 사람들이라는 점이 애로사항이다. 따라서 애자일 방법론에서는 스프린트 플래닝에 이를 고려해서 테스크를 할당한다.
코드리뷰 팁
(1) 코드리뷰를 요청하는 이
- 요청시 되도록이면 Unit test 단위로 요청하는 것이 제일 좋은 방법이다.
- 주석을 최대한 추가하고 목적과 솔루션을 명시한다.
- 리뷰에 대한 피드백을 감정적으로 받아들이지 않는 자세
(2) 코드리뷰를 하는 이
- 코딩 스타일에 대한 것 보다는 코드 자체에 집중하여 이야기한다.
- 객관적으로 작성하며, 비판적인 어조는 지양하는 것이 좋다.
- 충분히 시간을 들여 도움이 되는 리뷰를 제공하는 것이 장기적으로 좋다.
한기용님이 공유하신 코드리뷰 예시 링크를 함께 첨부한다.
Before : https://github.com/keeyong/2021-code-smells/blob/main/before.py
After : https://github.com/keeyong/2021-code-smells/blob/main/after.py
4. How to Test
TDD (Test Driven Development)
개발을 시작할 때부터 테스트를 어떻게 진해아할 것인지 부터 생각하고 개발에 착수하는 방법론이다. 이러한 방법론은 코드 구성 자체가 테스트에 편리하게 작성되는 효과를 발생시킨다. 또한 개발자 본인이 만들려는 기능에 대해 숙고하게 되는 효과 또한 발생한다. 테스트에는 여러가지 종류가 있는데 그 중 몇가지만 열거하겠다.
(1) Unit Test : 가장 보편적이고 기본적인 테스트 방법론으롸, 모듈의 특정 기능을 테스트하는 방식이다
(2) Integration Test : 다수의 모듈을 통합하여 하는 Unit Test의 한 차원 위의 테스트라고 볼 수 있다.
(3) Acceptance Test : 과다한 트래픽이 몰릴 때, 서버 혹은 기능이 부하를 견딜 수 있는지 테스트하는 것이다.
(4) UI Test : 근래 Selenium 등의 툴을 이용해서 웹페이지 자체의 기능을 테스트하는 것 또한 보편화 되어 있다.
대다수의 IT 기업들이 Unit Test를 포함한 코드 변경을 의무적으로 요구하는 것을 보면, 테스트가 얼마나 중요하게 취급되는지 알수 있다. 이런 기업들에서는 Test가 없으면 아예 코드 체크인이 실패한다고 한다. 테스트가 많을 수록 시스템의 안정성을 증대할 수 있고, 이후 Refactoring이 요구되는 순간이나 신규 엔지니어의 코드 수정에도 굉장히 편리하다는 장점이 있다. 따라서 Sprint Planning 또한 Test 시간을 포함하여 진행해야한다.
5. How to Build
빌드
빌드란 개발자 혹은 팀이 개발한 소프트웨어를 배포를 위한 형태로 만드는 것을 말한다. 배포와 연관된 만큼, 테스트 또한 빌드의 중요한 일부로 포함된다. 개발팀의 규모 혹은 참여자가 많을 수록 더 중요하다. Continuous Integration이라는 것이 있는데, 말 그대로 개발이 끝나기 전부터 지속적으로 빌드를 하는 것이다. 이런 방식을 통하면 소프트웨어의 안정성이 증대된다고 한다.
Continuous Integration
Software Engineering Practice 중의 하나로 위에서 말한 것 처럼 개발이 끝나기 전부터 지속적으로 빌드를 해가는 것이다. 몇가지 기본 원칙이 있는데, 코드 Repository는 하나만(Master, Main) 유지하면서 코드 변경은 최대한 자주 반영한다는 것이다. Test Coverage를 통해 테스트를 최대한 추가하는 것을 지향하며, 빌드를 계속 적으로 수행한다. 이때 빌드는 자동화 하는 경우도 있다.
많은 쇠사들은 빌드가 실패할 경우 빌드가 다시 성공할 때까지 코드 변경을 금지한다고 한다. 즉, 빌드 실패가 발생하면 모든 개발자의 발이 묶이는 족쇄(?)가 된다는 것이다. 따라서 조직이 커지면 빌드만 전담하는 엔지니어가 생기는데 Devops라고 불리며, 주 업무는 빌드 실패의 주원인(개발자)를 찾는 것이다. 역할군이 나뉠정도로 빌드는 중요한 부분이고, 빌드 실패 원인인 개발자에게는 가벼운 패널티를 부과하는 경우도 있다고 한다.
Jenkins (오픈소스 CI 빌드 소프트웨어)
Jenkins는 오픈소스 CI 빌드 소프트웨어이며, CI와 관련한 모든 기능을 지원한다. 직접 지원하는 것은 아니고 플러그인의 형태로 지원하며, Github, Git, SVN 등 대부분의 소스 컨트롤 시스템과 연동된다. 빌드된 소프트웨어의 배포를 위해서도 사용이 가능하다. 재밌는 이야기는 원래 썬 마이크로시스템에서 개발하여 Hudson이라는 오픈소스로 공개되었었는데, 오라클이 썬을 인수하면서 오픈소스화를 취소했다. 이에 불만을 가진 Hudson 개발자가 새로 개발하여 배포한 것이 Jenkins라고…
마무리하며…
오늘은 이렇게 Plan, Execute/Track, Manage Source Code, Test, Build의 보편화된 소프트웨어 개발과정에 대해서 알아봤다. 필자는 사실 이수학점이 남질 않아서 소프트웨어 공학 수업을 듣지 못했는데, 디자인 패턴, 소프트웨어 공학은 취업 이후 꼭 읽어볼 계획을 하고 있다. 이전에 있던 연구조직에서 얼마나 구먹구구식의 진행을 했는지 느낄 수 있었던 학습이었던 것 같다…
