김승준 강사님
소프트웨어 프로젝트 관리 방법론
Waterfall(폭포수 모델)
소프트웨어를 개발할 때 단계별로 차근차근 진행하는 방법. 단계는 보통 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 배포 및 유지보수로 나뉜다.
- 장점: 각 단계를 끝내고 나서 다음 단계로 넘어가기 때문에 관리가 쉽고 과정이 명확하다.
- 단점: 한 번 진행한 단계로 돌아가기 어렵고 중간에 요구사항이 변경되면 대응하기 힘들다.
Agile(애자일)
Waterfall 모델의 단점을 보완. 하나의 큰 프로젝트를 작은 반복 작업(Iteration) 으로 나눠서 점진적으로 개발해나가는 방식이다.
- Scrum: Agile 방법론으로 작업을 2주에서 4주 정도의 짧은 기간(스프린트)으로 나눠서 관리.
- 장점: 빠르게 결과물을 확인할 수 있고, 요구사항이 중간에 바뀌어도 유연하게 대응할 수 있다.
- 단점: 경험이 많은 팀원이 필요하고, 프로젝트의 규모가 클 때는 관리가 복잡해질 수 있다.
DevOps(데브옵스)
소프트웨어를 개발하는 개발팀(Dev)과 실제 운영하는 운영팀(Ops)이 함께 협력해서 더 빠르고 효율적으로 시스템을 배포하고 관리하는 방법.
- 코드 작성부터 배포, 운영까지 전 과정을 자동화하고 지속적인 통합(CI)과 지속적인 배포(CD) 라는 방식을 통해 언제든지 새로운 기능을 배포할 수 있다.
Waterfall과 Agile의 비교
- Waterfall: 요구사항을 처음부터 끝까지 고정한 상태에서 진행하는 선형적 방식.
- Agile: 요구사항은 변할 수 있고, 대신 시간이 고정되어 있다. 각 스프린트마다 새로운 기능이나 요구사항을 반영해서 점진적으로 개발하는 방식이다.
머신러닝의 5단계
- 문제 정의
- 데이터 준비
- 데이터 모델링
- 모델링 평가
- 모델 개선 및 유지보수
제안서 작성
프로젝트를 수행하기 위해 작성하는 문서로, 프로젝트의 목표, 범위, 수행 방법 등을 설명한다. 제안서를 쓸 때는 5W1H 원칙을 따르는 게 좋다.
1. What
2. How
3. Why
위 세 가지를 명확하게 설명하는 것이 중요한데, 특히 '왜'는 제안서의 시작에서 가장 먼저 다뤄져야 한다. 프로젝트의 정당성을 설명하고 그 이유가 명확해야지 제안서가 설득력을 가지기 때문.
RFP (Request for Proposal)
프로젝트를 수행할 사업체를 선정하기 위해 프로젝트 소유자가 작성하는 문서. 제안 요청서.
MVP (Minimum Viable Product)
최소 기능 제품. 소프트웨어나 제품을 개발할 때 가장 최소한의 기능만을 갖춘 제품을 빠르게 출시해서 시장의 반응을 보는 방식. 개발 초기 단계에서 모든 기능을 구현하기보다 꼭 필요한 핵심 기능만 구현해서 빠르게 출시하는 게 목적이다. 이후 사용자 피드백을 통해 제품을 개발하고 발전시킬 수 있다.
Enterprise Architecture
기업의 비즈니스와 IT 운영을 전략적으로 일관성 있게 정리하는 개념. 비즈니스 목표와 IT 시스템을 어떻게 연결해서 운영할지에 대한 전략을 세우는 것.
- 비즈니스와 IT가 따로 놀지 않고 서로 긴밀히 연결되어야 한다는 점을 강조. 이를 통해 기업은 목표를 더 효율적으로 달성할 수 있다.
- 엔터프라이즈 아키텍처는 광범위하고 복잡한 영역이므로 소규모 프로젝트나 초기 단계에서는 바로 적용하기 어려울 수 있다.
소프트웨어 테스트의 종류
- 기능 테스트: 소프트웨어가 요구된 기능을 제대로 수행하는지 확인.
- 비기능 테스트: 성능, 보안, 사용성 같은 비기능적인 부분을 평가.
- 단위 테스트: 소프트웨어의 개별 요소나 모듈이 정확하게 작동하는지 확인.
- 통합 테스트: 개별적으로 테스트된 모듈들이 함께 작동할 때 문제가 없는지 확인.
- 시스템 테스트: 전체 시스템이 사용자의 요구사항을 충족하는지 테스트.
V-model
소프트웨어 개발 과정과 테스트 과정을 V자 형태로 나타낸 모델.
- 왼쪽: 분석 및 설계 단계. 요구사항 분석과 시스템 설계 과정을 다룬다.
- 오른쪽: 테스트 단계. 코딩 이후에 이뤄지는 테스트 과정을 보여준다.
특징은 각 개발 단계에 대응하는 테스트 단계가 있다는 점이다.
테스트 피라미드 (Test Pyramid)
소프트웨어 테스트의 비용과 복잡도를 시각적으로 나타낸 개념이다. 피라미드의 아래쪽일수록 작은 단위의 테스트를 의미하고, 테스트 시간이 짧고 비용이 적게 든다. 반면, 위쪽으로 갈수록 통합된 시스템 테스트로, 더 많은 시간이 필요하고 복잡도와 비용이 증가한다.
Traditional vs. Agile Testing
전통적 테스트에서는 개발이 끝난 후에 테스트가 시작되지만, 애자일 테스트는 개발 과정과 동시에 이루어진다는 특징이 있다. 애자일 방식에서는 작은 기능 단위로 개발과 테스트를 반복적으로 수행하므로 지속적으로 오류를 발견하고 수정할 수 있다.
Agile Testing Quadrants
- Q1: 기술적 테스트 - 코드 수준에서 자동화된 테스트를 수행.
- Q2: 비즈니스 관점의 테스트 - 사용자 시나리오를 기반으로 시스템이 제대로 작동하는지 확인.
- Q3: 탐색적 테스트 - 다양한 상황에서 시스템이 어떻게 반응하는지 수동으로 테스트.
- Q4: 성능 및 보안 테스트 - 시스템의 성능, 보안 취약성을 평가.
배포 방안
- 롤링 배포(Rolling Deployment): 전체 시스템을 한 번에 교체하는 것이 아니라 새로운 버전을 점진적으로 배포해서 기존 시스템과 교체.
- 블루/그린 배포(Blue/Green Deployment): 두 개의 환경(Blue/Green)을 준비. 하나의 환경에서 새로운 버전을 테스트한 후에 문제가 없으면 트래픽을 새로운 버전으로 전환.
- 카나리 배포(Canary Deployment): 새로운 버전을 소수의 사용자에게 먼저 배포해서 문제가 없는지 확인한 후, 점진적으로 전체 사용자에게 확대 적용.
