개발 프로세스란?
모든 소프트웨어 개발은 최종적으로 "배포(Deply)"를 목적으로 한다. 배포된 소프트웨어와 일련의 수익모델을 통해 수익을 창출해야 하기 때문이다. 개발 프로세스는 이러한 개발 및 유지보수의 목적으로 수행되는 활동을 절차적으로 정리한 모델을 말한다.
전통적 개발 프로세스 vs 모던 개발 프로세스
전통적인 개발 프로세스 모델로는 대표적으로 워터폴(Waterfall) 방식이 있다.
워터폴 방식은 예외적인 상황을 최소화하여 팀의 규모나 상황에 관계없이 정확한 결과물을 제공하는 것을 전제로 한다.
워터폴 방식은 이름에서도 알 수 있듯, 요구분석 => 설계 => 개발 => 테스트 => 유지보수의 선형적 모형을 갖고 있다.
워터폴 개발 방식은 실제 출시 기한을 정해놓고 프로세스가 진행되며, 실제 사용자 에러를 줄이기 위해 다양한 테스트를 도입하여 활용하기도 한다. (시스템 테스트, 알파테스트, 베타 테스트 등)
모던 개발 프로세스 모델로는 대표적으로 애자일(Agile) 방식이 있다.
해당 모델은 요구사항이 언제든지 변할 수 있는 것을 전제로 한다.
애자일 방식은 요구분석 => (디자인 => 개발 => 테스트) => 배포의 과정이 반복되는 형식이다. 요구분석에서 배포까지 이르는 과정은 아주 짧은 주기를 반복하여 진행되는데 이 일련의 과정을 스프린트라고 부른다.
워터폴 방식과 애자일 방식은 각각 장단점이 있으며, 프로젝트에 성격에 따라 취사선택 되어야 한다.
이에 따른 비교는 아래의 도표에서 확인할 수 있다.
| Waterfall | Agile | |
| 장점 | 1. 프로세스의 주기가 길고 순서가 명확하여 팀의 규모에 관계없이 채택하기가 좋다 2. 안정적인 프로젝트 시작/종료 및 진행이 수월하고 프로젝트 수정사항이 적다 3. 리스트 통제에 용이하다. |
1. 빠르면서 유연한 개발이 가능하다. 2. 짧고 반복적인 스크립트의 중첩이기에, 결함 발견 및 수정이 용이하다. 3. 유연한 프로젝트 수정이 가능하다 |
| 단점 | 1. 개발 속도가 느리고, 유연성이 떨어진다. 2. 테스팅 단계에서 발견된 이슈 때문에 지연되는 경우가 있다. |
1. 빠른 스프린트 주기에 적응하기 위한 시간이 필요하다 2. 주기적으로 요구사항에 맞춰 프로젝트를 수정하는데서 발생하는 어려움이 있다. |
| 상황 | 1. 제한적인 시간과 자원으로 인해 프로젝트를 효율적으로 통제해야 하는 경우 2. 높은 예측 가능성과, 순차적인 프로젝트 라임라인, 프로젝트 팀 경험이 적은 경우에 용이한 방법론이다. |
1. 엔터프라이즈급 프로젝트에서 프로세스를 세분화하여 관리해야 할 때 2. 고품질의 결과물과 지속적이 개선이 필요한 경우 |
CI / CD (지속적인 통합(Continuous Integration), 지속적인 배포(Continuous Deployment))
CI/CD의 대두는 DevOps문화의 확산에 따른 결과로 볼 수 있다.
본 개념을 살펴보기 전에, 용어부터 정리하고 내용을 전개해보고자 한다.
1. DevOps (Devlope + Operations) : 개발과 운영의 경계를 허물고, 필요한 경우 해당 문제을 빠르게 파악하고 개선하는 개발 문화
2. CI (지속적인 통합(Continuous Integration)) : 개발자를 위한 자동화 프로세스
3. CD (지속적인 배포(Continuous Deployment)) : 지속적인 서비스 제공이라고도 부르며, 운영팀이 맡은 프로세스를 자동화 한 것
얼핏 들으면, 그냥 개발자가 운영까지 떠안게 되는 무게로 보인다.
DevOps 문화가 단순히 업무의 과중이 아닌 운영을 고려한 개발, 개발을 고려한 운영, 그리고 문제 상황에 대한 통합적 이해와 협업이 가능할 수 있도록 도운 개념은 "자동화" 개념이다. 따라서, DevOps 문화에서 CI / CD를 파악할 때에는 반드시 어떤 것을 자동화하여 업무 효율성을 높일 것인지 파악하는 것이 중요하다.
CI (지속적인 통합(Continuous Integration))
Code : 개발자가 코드를 원격 코드 저장소(ex.github)에 push하는 단계
Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정
위의 과정을 아주 짧은 주기로 코드 저장소에 push하고, 테스트 및 빌드하여 빌드 결과를 파악하고, 이러한 통합 과정을 활용하여 끊임없이 문제를 파악하고 개선하는 것이 CI의 핵심이다.
이를 위해 모든 팀원이 한 레포지토리를 통해 해당 프로젝트를 관리하고 잦은 이슈쉐어를 통해 프로젝트를 함께 개선하는 것이 중요하다.
CD(지속적인 배포(Continuous Deployment))
Release : 배포 가능한 소프트웨어 패키지를 작성
Deploy : 실질적인 배포 부분
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지
종전까지 위의 과정(배포를 위한 일련의 과정)은 상당히 어려운 영역이라 많은 고민이 필요했다.
하지만 클라우드 기술 발전과 함께 자동화 기술이 발전함에 따라 운영팀은 CI와 CD를 종합적으로 고려하여 빠르게 배포할 수 있는 여건이 마련되게 되었다.
SaaS와 CI/CD 파이프라인
SaaS는 Software as a Service의 약자로, 소프트웨어를 하나의 제품(구매)이 아닌 서비스(구독)으로 바라보고 개발하는 개념이다.
소프트웨어 자체를 완성된 형태로 배포하여 사용자의 로컬에 제공하는 SaaP(Software as a Production)과 대조되는 개념이다.
CI/CD 파이프라인은 각기 독립된 의미로 사용되는 CI와 CD를 통합하여 하나의 업무 프로세스로 만든 모델이다.
CI/CD 파이프라인은 다음의 업무를 자동화한다.
1. 빌드 (소프트웨어 컴파일)
2. 테스트 (호환성 및 오류 검사)
3. 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
4. 배포 (개발에서 프로덕션 환경으로의 변환)
5. 규정 준수 및 유효성 검사
이러한 일련의 자동화 과정을 통해 여러 이슈를 빠르게 발견하고, 수정하며, 배포까지 물밑에서 끊임없이 최신화할 수 있게 된다.
'개발이론' 카테고리의 다른 글
| Optimization(최적화) (0) | 2023.03.30 |
|---|---|
| TDD(Test-driven Development) : JS (0) | 2023.03.29 |
