S4) Unit 10. [Deploy]개발 프로세스

 📣 개발 프로세스의 발전

𝟭. 개발 프로세스

✔️ 개발 프로세스는 소프트웨어 개발 생명주기를 기반으로 만들어졌다.

개발 프로세스

1️⃣ 요구 분석 및 시스템 명세 작성 : 문제분석 단계로, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계

➰ 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.

 

2️⃣ 설계 : 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다.

➰ 시스템, 프로그램, UI(User Interface) 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계하고, 프로그램설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계한다.

 

3️⃣ 구현 : 설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용하여 실제 프로그램을 작성한다.

➰ 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉜다.

    ㄴ 구조화 프로그래밍 : 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며, 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉽다.

    ㄴ 모듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로, 모듈별로 개발과 테스트 및 유지보수 가능하며, 모듈의 재사용 가능하다는 장점이 있다.

➰ 실제 개발에 착수하는 단계

 

4️⃣ 테스트 : 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가한다.

➰ 미처 발견하지 못한 오류를 발견할 수 있다.

 

5️⃣ 배포 및 유지보수 : 스템이 인수되고 설치된 후(배포) 일어나는 커스터마이징, 구현, 테스트 등을 포함하며 소프트웨어 생명 주기 중 가장 긴 기간을 차지한다.

➰  유지보수의 유형에는 수정형, 적응형, 완전형, 예방형이 있다.

    ㄴ 수정형 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행한다.

    ㄴ 적응형 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업을 한다.

    ㄴ 완전형 : 시스템의 성능을 향상하기 위한 개선 작업을 한다.

    ㄴ 예방형 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 한다.

 

𝟮. 전통적인 개발 프로세스

✔️ 워터폴 방식 : 한 방향으로만 프로세스가 진행되는 개발 과정

➰ 유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델

➰ 실제 출시 기한을 정해놓고 순차적으로 프로세스가 진행시켜 소프트웨어를 완성해 배포하기 때문에 실제로 유저에게 전달되는 시간이 오래걸린다.

➰ 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 한계가 있다.

➰ 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장 받기가 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있다.

테스트 단계에 다양한 테스트를 도입하기도 한다.

1️⃣ 시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인하고, 만족하지 않으면 다시 요구분석 단계로 돌아가 새로 개발을 하기도 한다.

2️⃣ 알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행된다.

3️⃣ 베타 테스트 : 객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해보고 에러나 버그가 발견되면 수정하는 방식으로 진행된다.

 

𝟯. 모던 개발 프로세스

✔️ 애자일 방식 : 스프린트 라고 불리는 짧은 주기의 개발 사이클을 계속 반복하는 방식

➰ 요구사항이 변하는 것을 전제로 두기 때문에 중간에 뒤로 회귀할 수 없는 전통 개발 프로세스보다 효율적이다.

➰ 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능하며, 이 방식은 SaaS를 개발하는데 적합하다.

 

𝟰. SaaS 란?

✔️ 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식

➰ 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없어서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능하다.

➰ 사용자는 업데이트를 했는지도 모르고 해당 애플리케이션을 사용할 수 있다.

 

𝟰. 전통 개발 프로세스 VS 모던 개발 프로세스

 

	전통(워터폴)	모던(애자일)
장점	- 프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관 없이 따르기 쉽다. - 개발 주기가 정해져 있어 새로운 프로젝트를 안정적으로 시작 가능하다. - 요구 사항이 확정되어 있어 프로젝트를 실행하기 수월하며, 개발 목표를 자주 변경하지 않아도 된다. - 프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 쉽다.	- 빠르면서 유연한 개발 과정 - 짧고 반복적인 스프린트로 구성되어 있어 품질에 초점을 맞출 수 있으므로 빠르게 결함을 인지하고 수정 가능하다. - 스프린트를 통한 짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능하다.
단점	- 개발이 순차적으로 진행되므로 앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어진다. - 테스팅 단계에 이르러서 이슈가 발견되는 경우가 종종 있다. - 개발 요구 사항이 초기에 확정되므로 범위 변경이 자유롭지 못하다.	- 스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요하다. - 고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생한다. - 팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 애자일론을 채택할 시 문제가 발생한다.
상황	- 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 경우 - 프로젝트 팀의 경험이 적은 경우 - 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우	- 고성능 소프트웨어 개발 중에서도 특히 소프트웨어 개발을 할 경우 - 고품질의 결과물과 지속적인 개선에 초점을 맞출 경우 - 프로젝트가 완벽히 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 경우
기업	- 개발상의 변경이나 리스크에 덜 민감한 기업 및 팀 - 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 및 팀	- IBM, 시스코, AT&T, 마이크로소프트와 같이 크고 복잡한 회사들이 프로세스를 간소화해 변화에 더욱 신속하게 대응하고자 할 때 - 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀

---

 📣 DevOps

𝟭. DevOps

✔️ 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어로, 소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 하며, 그렇기 때문에 애자일 개발 프로세스를 기반으로 했다고 볼 수 있다.

 

𝟮. DevOps의 문화

✔️ 일종의 개발 문화로, 만약 서비스가 중단된다면 누구든지 문제점을 진단하고 시스템을 복구해서 운영할 수 있는 절차를 알고 있어야한다.

 

𝟯. DevOps의 특징

✔️ 개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화한다.

➰ 코드 통합, 테스트, 배포 과정을 자동화 시키는 것

=> 이를 지속적으로 유지하는 것을 지속적 통합 및 배포(CI/CD)라고 하며 DevOps의 핵심 원칙이다.

 

𝟰. DevOps의 사례

✔️ 스트리밍이나 사진 같은 엄청난 트래픽과 다양한 사용자 환경 및 요구에 대응하기 위해 배포가 많은 서비스

---

 📣 CI/CD

𝟭. CI/CD 란?

✔️ CI : 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다.

➰ 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포에 통합된다.

➰ 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

 

✔️ CD : 지속적인 서비스 제공 및/또는 지속적인 배포를 의미한다.

➰ 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

 

𝟮. CI/CD의 단계

✔️ 앱의 유지보수 단계에서 지속적 통합 및 지속적 전달을 단계별로 할 수 있다.

 

1️⃣ 지속적 통합(Continuous Integration, CI)

✔️ 개발자를 위한 자동화 프로세스

➰ 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작한다.

➰ 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합하고, 이때 기본적인 테스트도 작동시킬 수 있다.

➰ 지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있고, 코드를 머지하기 전 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있다.

 

2️⃣ 지속적 배포(Continuous Delivery/Deployment, CD)

✔️ 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함

➰ 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있다.

➰ 가장 흔한 사례 : Github Page => 정해둔 디렉터리에 정해진 방식에 따라 잘 커밋하기만 하면, Github Page가 알아서 해당 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해서 Github Page 서버에 업로드한다.

 

𝟯. CI/CD의 영역

✔️ 지속적인 서비스 제공은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다.

➰ CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미한다.

---

 📣 CI/CD 파이프라인

𝟭. 배포 자동화

✔️ 한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것

✔️ 배포 자동화의 장점

➰ 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.

➰ 휴먼 에러를 방지할 수 있습니다.

    ㄴ 휴먼 에러 : 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수

 

𝟮. CI/CD 파이프라인

✔️ 배포 과정을 자동화시키는 방법

배포 과정

➰ 원격 저장소에 push ->  코드가 빌드 및 테스트, 릴리즈를 거쳐 배포 서버로 전달 -> 배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 됨

➰ 여기서 자동화를 할 수 있는 부분은 코드가 빌드되면서 최종적으로 배포가 되는 단계 까지이다.

 

𝟯. CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

파이프라인을 구성하는 기본 단계와 수행 작업

1️⃣ Source 단계 : 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업

2️⃣ Build 단계 :  Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공하고 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업

3️⃣ Deploy 단계 : Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업

 

𝟰. CI/CD 파이프라인을 구성 요소 및 장점

✔️ '빌드', '테스트', '릴리스', '배포', '규정 준수 및 유효성 검사' 로 구성

➰ 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다 더 빠르고 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여준다.