이번 학기 소프트웨어 공학 수업의 첫번째 챕터는 소프트웨어 프로세스(Software Process)이다.
- software development process
- software development life cycle
- software development model
등등 비슷한 의미를 가지는 용어들이 존재한다. 용어가 어찌됐건, 중요한 것은 소프트웨어 결과물의 생산성에 초점을 두는 개념이란 것이다.
Waterfall Model
첫번째 개발 프로세스 방법론은 Waterfall model이다.
말 그대로 수직적인 소프트웨어 프로세스이고, 고전적인 방법이다.
이 모델의 특징은 수행되는 각 활동이 겹치지 않으며, 동시에 진행되지도 않는다.
그래서 이 단계를 거슬러올라가는 일이 없고, 매 단계에서 결과를 확인하고 다음 단계로 넘어간다.
이 때문에, 수정을 해야하는 상황에서는 앞 단계에서 다시 작업을 한 후에 다시 돌아와야 한다.
Waterfall model의 개발 생명 주기(Development Life cycle)를 설명해보겠다.
-
첫번째 단계는 요구사항 분석 및 정의(Requirement analysis and definition)이다.
이 단계에서는 시스템의 세부 요구사항과 시스템 명세서를 작성한다. 대표적인 예시로 SRS(Software Requirements Specification)을 이야기할 수 있는데, 여기에는 소프트웨어의 개발 목적과 전반적인 설명, 필요한 기능, 기대 성능 등을 세부적으로 작성한다. -
두번째 단계는 시스템 및 소프트웨어 디자인(System and software design)이다. 이 단계에서는 전반적인 시스템의 구조(System Architecture)를 만들고, 이 때 하드웨어 및 시스템 요구 사항을 지정한다. 설계단계는 보통 시스템 아키텍처, 프로그램 설계, 인터페이스 설계로 구분된다.
쉬운 예시로 프로그램에 사용되는 기능을 동작하게 하기 위한 Class 등의 디자인 패턴 등을 설계하는 단계라고 할 수 있겠다. -
세번째 단계는 개발 및 단위 테스트(Implementation and unit testing)이다. 이 단계에서는 위에서 명시한 프로그램 레이아웃과 코딩표준을 준수하며 개발에 들어간다. 동시에 단위 테스트를 진행하여 기능 명세서에 부합하는지를 확인한다.
-
네번째 단계는 통합과 시스템 테스트(Integration and system testing)이다. 이 단계에서는 개발이 완료된 모듈들을 통합하여 전체 시스템이 요구사항을 만족하는지 확인한다. 크게 개발 현장에서 직접 테스트하는 '알파 테스트'와 실 사용자가 테스트하는 '베타 테스트'로 테스트 과정이 나뉜다. 이 과정에서 문제를 수정하고 소비자에게 제품을 출시한다.
-
마지막으로 다섯번째 단계는 이행과 유지보수(Operation and maintenance)이다. 이 단계에서 이미 시스템은 출시가 되어 소비자들이 실질적으로 사용을 하고 있다. 유지보수를 통해 이전 단계에서 발견하지 못했던 버그나 에러를 수정하여 프로그램의 품질을 향상시키거나, 새로운 요구사항을 충족하기 위해 시스템을 고친다. 이 과정이 프로그램 생명 주기에서 가장 긴 시간을 차지한다.
정리하자면 Waterfall model은 다른 공학 프로세스 모델과 비슷하기 때문에 가장 직관적으로 프로세스를 이해할 수 있다.(ex. 건축 프로세스)
Waterfall model의 확장 버전(extension of waterfall)으로 V-Model이 존재한다.
V-model은 Waterfall model의 프로세스에서 분석 및 설계와 같은 개발 단계마다 그에 상응하는 테스트 단계가 존재하는 프로세스를 가진다. 단순히 코드 뿐 아니라 요구사항과 설계도 테스트 할 수 있다는 특징을 가진다. 이 부분은 참고만 해놓자.
사실 Waterfall Model은 강력하고 체계적이지만 당연히 장점이 있다면 단점도 있다.
건축과 같은 경우는 완벽한 설계를 처음에 만들고, 탑 다운 방식으로 진행하는 것이 매우 효율적인 분야이다. 하지만 소프트웨어는 끊임없이 사용자와 상호작용하며 기능 및 성능 요구사항이 계속 바뀌기도 하고, 디자인 수정도 다분하다.
하지만 Waterfall model은 고객의 요구사항에 따라 즉각적으로 피드백을 반영하기가 어렵고, 하드웨어와 다르게 언제든 변경 사항을 적용할 수 있다는 의미인 소프트웨어(software), 그 자체의 유연성을 살리기가 어려워진다. 단계별로 거스르거나 유기적으로 동작하는 프로세스가 아니기 때문에, Waterfall 방식의 개발 프로세스는 많은 인력과 시간을 필요로 하는 만큼 유지보수에도 시간과 비용이 다른 유연한 프로세스보다 상대적으로 많이 소모된다.
Agile Methodologies
위와 같은 문제를 해결하기 위해 좀 더 유연한 프로세스 개발 방법론이 만들어졌고, 그 중 하나가 애자일 방법론(Agile Methodologies)이다.
애자일 방법론은 쉽게 이야기하면, 반복적으로 짧은 주기의 프로세스를 순환시키면서 소프트웨어 개발을 진행하는데, 여기서 핵심은 협업이 원활하게 유기적으로 이루어지도록 만드는 것이다.
위 그림에서 애자일 방법론의 취지를 정확하게 이해할 수 있다.
- 프로세스와 도구 < 개인과 상호작용
- 포괄적 문서 < 작동하는 제품
- 계약 협상 < 소비자와의 협력
- 계획 < 변화에 대응
즉, 틀보다는 유기적으로 상황에 대응하는 것이 애자일의 기본 이념이다.
쉽게 이야기하면
- 프로세스와 툴보다는 팀으로써 커뮤니케이션을 통한 협업과 개인 역량을 밀자.
- 쓸데없이 문서 작성하는데 시간 들이지 말고, 실제 작동하는 프로그램을 우선시하자.
- 고객이 실제로 원하는 제품을 만들자
- 계획은 계획이고 세상은 언제나 변하니, 변화에 대응할 수 있도록 조직을 유연하게 만들자
라고 볼 수 있다.
이 애자일 이념을 담은 Agile Manifesto에서 이 내용들을 확인해볼 수 있다.
물론 프로세스와 도구, 문서, 계획과 같은 것들이 중요하지 않다고 이야기하는 것이 아니다. 단지 그것보다 더 중요하고 실질적인 가치를 우선시하겠다는 이념이다.
애자일 개발 프로세스에서도 세부적으로 나눠지는 개발 프로세스 방법론들이 존재한다.
- Extreme Programming (XP)
- Scrum Methodology
- Lean Software Development
Extreme Programming (XP)
1. 계획 단계(Planning)
XP는 User Story를 바탕으로 End User의 관점에서 계획을 수립하게 된다. 역시나 이 방법론도 애자일 기반이기 때문에, 이후 과정은 반복적이고 빠르게 순환된다.
2. 디자인 단계(Design)
CRC(Class Responsibility Collaborator) Model
XP에서는 소프트웨어 디자인을 하면서 CRC(Class Responsibility Collaborator) Model을 사용한다.
위 그림은 CRC 카드인데, CRC 카드에는
- Class Name: 객체명,
- Responsibilities: 객체의 책임,
- Collaborators: 객체가 자신의 책임을 다하기 위하여 포함해야하는 다른 객체의 이름
이렇게 3가지가 명시된다.
이런 카드들을 연결하여 소프트웨어의 시스템을 디자인한다.
Spike Solution
또 Spike Solution이라는 개념이 있는데, Spike Solution은 유저 스토리 중 기술적으로 어려운 문제를 해결하기 위해 고안된 것으로, 이 문제를 처리하기 위한 목적을 제외한 모든 조건을 무시하고 만드는 프로그램이다.
Spike Solution은 기술적인 문제를 줄이고 유저 스토리를 가지고 추정한 개발 일정에 대한 신뢰도를 높일 수 있도록 하기 위해 진행된다.
3. 구현 단계(Coding)
Pair Programming
이렇게 빠르게 계획과 디자인을 수립하고서 구현에 진입하게 되는데, XP에서는 Pair Programming을 사용한다.
문자 그대로 Pair Programming은 2명이서 짝을 지어 함께 프로그래밍을 하는 것이다.
비유적인 표현이 아니라, 진짜로 그렇다.
가장 일반적인 방법은 한 명은 Driver, 한 명은 Navigator가 되어 Driver는 소스코드를 타이핑 하고, Navigator는 작성되는 소스코드를 실시간으로 리뷰하고 가이드하는 역할이다.
Pair Programming의 장점으로는 지식 공유 및 성장 측면에서 팀이 빠르게 성장할 수 있도록 돕고, 문서보다 직접 같이 일하면서 커뮤니케이션이 깊어진다는 점이 있다. 그리고 가장 중요한 장점으로 실시간 코드 리뷰를 통해 작은 타이핑 실수부터, 설계 결함까지 소스코드에 대한 피드백을 바로바로 받아 일정한 수준의 코드 품질을 유지하면서 안정적인 개발 프로세스를 가져갈 수 있다.
Pair Programming의 실제 모습이 궁금하다면 아래 링크의 Kakao Tech의 글을 참고하면 좋을 듯 하다.
나의 페어 프로그래밍 탐험기
Refactoring
Refactoring은 쉽게 이야기하면, 겉으로 보이는 기능의 차이는 없지만 내부 코드 구조를 재구성하는 것을 의미한다. 코드 가독성을 높이기 위해 작게는 변수명부터 파일 분리 등의 재구성을 하기도 하고, 유지보수성을 높이기 위해 코드의 재사용성에 중점을 둔 코드를 만들기도 한다.
프로그램이 커질수록 구조가 복잡해지기 때문에, Refactoring은 좋은 설계 구조를 만든다는 점에서 꼭 필요한 작업이다.
이 작업도 XP에서는 구현 단계에서 이루어진다.
Refactoring 예시
4. 테스트 단계(Test)
TTD(Test-Driven Development)
이 단계에서 XP는 TTD 개발 방법론으로 테스트 과정을 진행한다.
TTD는 테스트가 주도하는 개발 방식으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드, 즉 구현 내용을 작성하는 방식이다.
TTD는 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.
Scrum Methodology
Scrum 방법론도 Agile 기반의 방법론으로써, XP와의 가장 큰 차이점은 Scrum은 프로젝트 관리에 중점을 둔다는 점이다.
프로세스에 대해 간단하게 설명하면, Scrum에서는 제품에 포함할 기능에 대한 우선 순위를 부여한다. 그리고 1-4주 정도의 주기로 Sprint를 진행한다. Sprint를 통해 빠르게 우선 순위에 집중해서 생산성을 높이고 실질적으로 가장 급하고 중요한것들을 먼저 처리할 수 있게 된다. 그리고 주기가 끝나는 시점에 Sprint Review를 진행하여 Stakeholder, 고객, 제품 책임자에게 시연하고, 이후 회고(Retrospective)를 통해 이번 Sprint를 돌아보고 개선점을 찾는다. 그리고 이 과정을 계속 반복한다.
이렇게 오늘 Waterfall Model과 Agile Methodologies의 차이점과 특징을 알아보는 시간을 가지며, 소프트웨어 개발 프로세스에 대해 이해해보게 되었다.
실제로 큰 규모의 프로젝트를 해본적은 없지만, 작은 규모에서도 개발 방법론에 대한 이해도가 높으면 분명 생산성과 방향 설정에서 많은 도움을 얻을 수 있다는 것은 이전 프로젝트를 통해 느꼈다. 그래서 이 내용의 수업이 굉장히 흥미로운 부분이 많았다고 생각한다. 다음 포스트에서는 소프트웨어 테스팅에 대해 이야기 해보려 한다.
