한화 Beyond 9기 교육을 들으면서 배우는 것에 대해 나름대로 정리를 해보려고 한다. 기반기술부터 백엔드, 프론트엔드, 데브옵스 등 여러가지를 배우는데 듣고 넘기는 것이 아닌 블로그 포스팅을 통해 내 것으로 만들고 복습을 반복하고자 시작한다.
프로그램 : 컴퓨터 명령어가 나열된 원시 (소스) 코드
애플리케이션 : 컴퓨터의 OS (윈도우, 리눅스, macOs 등) 위에서 동작하는 컴퓨터 프로그램
소프트웨어 : 컴퓨터 저장장치에 저장된 '특정한 목적과 기능'을 수행하게끔 만들어진 컴퓨터 프로그램
프로세스 : 주어진 일을 해결하기 위해 수행되는 일련의 절차
-> 요구사항 수집, 설계, 구현, 테스팅, 배포, 유지보수에 이르는 소프트웨어 생명주기 전체를 포괄하는 것

큰 프로젝트에는 여러 어려움이 있는데 예를 들면,
1. 개발 과정이 복잡하다.
2. 참여 인력이 많다.
3. 개발 기간이 길다.
위와 같은 어려움을 해결하기 위해선
- 개발의 복잡성을 줄이기 위한 방법과 기술
- 개발에 참여하는 팀을 구성하고 관리하는 효율적인 방법
- 프로젝트를 효율적으로 관리하기 위한 체계
이런 3가지의 필요성이 생기게 된다.
요구사항 → 설계 → 구현 → 테스트 → 문서로 정리
- 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의
- 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
- 고품질의 소프트웨어 제품 생산을 목적으로 함
요구사항 → 설계 → 구현 → 테스트 → 배포 및 유지보수 -> 문서로 정리
말그대로 절차를 순서대로 진행하고 단계가 완료돼야 다음 단계로 갈 수 있다.
장점
1. 구조가 명확하고 이해하기 쉬움
2. 각 단계가 명확한 구분으로 문서화가 잘 된다.
3. 큰 규모의 프로젝트나 변경이 거의 없는 프로젝트에 적합하다.
단점 (간단하게 말해서 이상적이다.)
1. 변화에 대응하기 어렵고 유연성이 부족하다.
2. 피드백을 과정 후반에야 받을 수 있어, 초기 설계 오류의 수정이 어렵다.
3. 프로젝트 초기 단계에서 정확한 요구사항을 파악하기 어렵다.
폭포수 모델은 사실 이상적인 상황을 고려했기 때문에 완벽하게 이뤄지기 어렵다.
그래서 변화에 대해 유연하게 대응하며 짧은 개발 Cycle (스프린트)을 통해 지속적으로 제품 개선하는 모델인 애자일 모델을 사용하기도 한다.
장점
1. 빠르게 변화하는 요구 사항에 유연하게 대응할 수 있다.
2. 정기적인 피드백을 통해 고객의 요구사항을 더 잘 반영할 수 있다.
3. 팀원 간의 긴밀한 협력과 의사소통이 장려된다.
단점
1. 프로젝트의 규모가 커지면 관리가 복잡해질 수 있다.
2. 문서화가 충분히 이루어지지 않을 수 있어, 프로젝트에 대한 이해도가 낮은 새로운 팀원의 참여가 어려울 수 있다.
3. 초기에 최종 비용과 시간을 추정하기 어려울 수 있다.
이건 애자일 모델에서 더욱 나아간 모델로만 알고 있었다.
애자일 모델을 기반으로 스프린트 동안 목표를 달성하기 위해 협력하는 프레임워크.
계획, 검토, 미팅 등 정기적인 회의를 가진다.
스프린트 중간에도 계속 회의를 진행하면서 보완해야할 점이나 개선해야할 점을 확인할 수 있는 프레임워크라고 보면 되는 것 같다.
장점
1. 팀 구성원 간의 높은 수준의 협력과 의사소통을 촉진한다.
2. 빠른 피드백 루프를 통해 제품을 지속적으로 개선할 수 있다.
3. 복잡한 프로젝트를 더 효과적으로 관리할 수 있다.
단점
1. 스크럼의 성공은 팀 구성원의 경험과 자기 조직화 능력에 크게 의존한다.
2. 일정한 규모 이상의 대규모 프로젝트에는 적용하기 어려울 수 있다.
3. 엄격한 일정과 빈번한 회의로 인해 일부 팀원이 스트레스를 받을 수 있다.
| 구분 | 폭포수 | 애자일 |
|---|---|---|
| 추가 요구 사항의 수용 | 추가 요구사항을 반영하기 어려운 구조 | 추가 요구 사항을 수용할 수 있는 구조 |
| 릴리즈 시점 | 최종 완성된 제품을 릴리즈 | 수시로 릴리즈 |
| 시작 상태 | 시작 단계에서의 완성도가 매우 높음 | 시작 단계는 미흡, 점차 완성도가 높아짐 |
| 고객과의 의사소통 | 사용자와 산출물의 근거 중심, 대화 부족 | 처음부터 사용자의 참여 유도, 대화를 통한 개발 진행 |
| 진행 상황 점검 | 단계별 산출물에 대한 결과로 개발의 진척 상황을 점검 | 개발자와 사용자는 개발 초기부터 진행 상황 공유 |
| 분석/설계/구현 진행 과정 | 분석/설계/구현 과정이 명확 | 하나의 단계 또는 반복 안에 분석/설계/구현 과정이 모두 포함되어 동시에 진행 |
| 모듈(컴포넌트)통합 | 구현이 완료된 후에 모듈 간의 통합 작업을 수행 | 개발 초기부터 빈번한 통함, 문제점을 빨리 발견하고 수정하는 방식 |
나선형, 반복점증적, 프로토타이핑 모델 등 몇 가지 더 있긴 하지만 이는 추후에 추가하려고 한다.