개발 프로세스의 발전

개발 프로세스

개발 프로세스, 즉 소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle)을 기반으로 만들어졌다.

1. 요구 분석 및 시스템 명시 작성

문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계이다. 개발하고자 하는 성격을 정확히 이해하여 이름 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.

2. 설계

설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다. 크게 시스템, 프로그램, UI 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈 간의 구조를 설계하고, 프로그램 설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계한다.

3. 구현

설계단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용해서 실제 프로그램을 작성한다.
이때 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉜다.

• 구조화 프로그래밍 : 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복 구조의 세가지 제어구조로 표현하며, 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있다.
• 무듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로, 모듈별로 개발과 테스트 및 유지보수가 가능하며, 모듈의 재사용이 가능하다는 장점이 있다.

4. 테스트

테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가하는 일련의 과정이다.
5. 배포 및 유지보수
배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭합니다.
이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지합니다.

• 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행한다.
• 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업을 한다.
• 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업을 한다.
• 예방형 유지보수 : 앞으로 발생할지 모르는 변경 사항을 수용하기 위한 대비 작업을 수행한다.

전통적인 개발 프로세스

기존에 존재하고 있던 개발 프로세스는 워터폴(Waterfall) 방식이 있다.

폭포와 같이 한 방향으로만 프로세스가 진행되는 개발 과정을 뜻한다.
보통 이런 사이클을 가지고 있으며, 유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델이다.

하지만 이러한 방식은 배포되어 유저에게 전달되는 시간이 오래 걸리며, 소프트웨어의 신뢰성 및 안정성을 보장 받기가 힘들고, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있기 때문에 테스트 단계에서 다양한 테스트들을 도입하게 된다.

• 시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인한다. 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발을 한다.
• 알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행된다.
• 베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해본다. 이 과정에서 에러나 버그가 발견되면 수정하는 식으로 한다.

모던 개발 프로세스

전통적인 개발 프로세스에서 벗어나기 위해 만들어진 프로세스 중 하나가 애자일(Asile)방식이다.

이 애자일 방식은 '스프린트(sprint)'라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복한다.
이 방식은 요구사항이 변하는 것을 당연한 전제로 두고 있다.

애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러번의 배포가 가능하다.
이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합하다.

SaaS(Software as a Service)

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

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

DevOps

전통적인 IT 조직 구조로는 개발팀(Dev)과 운영팀(Ops)이 소프트웨어의 개발과 관리 및 유지보수를 담당한다.

• Dev(개발팀) : 잦은 배포 및 업데이트, 애플리케이션을 통해 새로운 기능(리소스)제공
• Ops(운영팀) : 프로덕션 앱의 안정성 확보, 인프라 관리, 모니터링 및 제어

개발팀이 잦은 업데이트를 통해 제품에 변화를 만들어야 한다면, 운영팀은 이런 서비스의 구성의 변경을 최소화해 안정성을 확보하는데, 이 부분은 꽤 상충이 되는 부분이기 때문에 갈등을 야기한다.
이러한 갈등은 제품의 릴리즈 주기를 길어지게 만들기도 한다.

이를 해결하기 위해 나온 개념이 DevOps이다.
DevOps는 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어로이다.

소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 하며, 그렇기 때문에 애자일 개발 프로세스를 기반으로 한 것이라고 볼 수 있다.

DevOps 특징

DevOps는 개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화한다.
즉 코드 통합, 테스트, 배포 과정을 자동화 시키는 것입니다.
이 부분은 지속적으로 유지되어야 할 필요가 있는데, 지속적 통합 및 배포(CI/CD)라고 하며 DevOps의 핵심 원칙이라고 해도 과언이 아니다. 잘 구축된 CI/CD는 애플리케이션의 배포 시간을 크게 단축시킨다.

CI/CD란?

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있다.

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계에서 꾀할 수 있다.

• Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계
• Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
• Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

테스트 및 빌드를 하며 빌드 결과를 통해 빌드가 성공했는지 실패했는지 확인을 하고, 통합 테스트 결과를 통해 개선 방안을 찾는다.

이 지속적인 통합 과정을 통해 개발자는 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달이 가능해지며 지속적인 배포가 가능해진다.

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

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다. 이 부분은 Release - Deploy - Operate 단계에서 꾀할 수 있습니다.

• Release : 배포 가능한 소프트웨어 패키지를 작성
• Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출 (실질적인 배포 부분)
• Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

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

배포 자동화

배포 자동화란 한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다.
배포 자동화가 필요한 이유는 아래와 같다.

• 먼저 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.
• 휴먼 에러(Human Error)를 방지할 수 있다.
  휴먼 에러란, 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들을 뜻합니다. 그 전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예로 볼 수 있습니다.

CI/CD 파이프라인

앞에 내용을 보듯이 SaaS가 모던 개발 프로세스로 개발하기 적합한 소프트웨어임을 확인했다.
그렇다면 개발자가 배포할 때마다 일일히 빌드하고 배포하는 과정을 진행하는 것은 한두 번이면 충분하겠지만, 이러한 과정이 수없이 진행된다면 일일히 이 과정을 수행하는 것이 번잡스럽게 느껴질 것이다.

그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달 된다.
배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료 되고, 그 결과물을 유저가 직접 확인하게 되는 것입니다.

여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다.
이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

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

배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다.

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리하며, 각 단계는 파이프라인 안에서 순차적으로 실행되고 각 단계마다 주어진 작업(Actions)들을 수행한다.

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

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

• Deploy 단계 : Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

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

• 빌드 (소프트웨어 컴파일)
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

로 이루어져 있으며, 이 과정이 실무에서는 반복적인 프로세스이기 때문에 이 부분을 일련의 자동화 단계로 만든다고 볼 수 있다.

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