DevOps

*  개발 프로세스의 발전
-  전통적인 개발 프로세스에 도입된 테스트
-  모던 개발 프로세스
-  SaaS
*  DevOps
-  DevOps 특징과 사례

 

개발 프로세스란 소프트웨어 시스템이나 애플리케이션 개발 및 유지보수할 목적으로 수행되는 활동의 절차를 뜻한다.

• 개발 프로세스의 목적은 개발에 대한 전체적인 가이드라인을 제공하는 데에 있다.
• 절차가 있는 개발과 그렇지 않은 개발은 큰 차이가 있을 것이다.

 

개발 프로세스의 발전

개발 프로세스

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

 

1. 요구분석 및 시스템 명세 작성 :
   • 문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계이다.
   • 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.
2. 설계 :
   • 설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다.
   • 크게 시스템, 프로그램, UI 설계로 나뉜다.
     • 시스템 구조설계 : 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계 
       • 예를 들어, 주문 처리 모듈, 재고 관리 모듈, 배송 모듈 등이 시스템의 구성 요소로 포함될 수 있다.
       • 각 모듈의 역할, 인터페이스, 데이터 흐름 등을 설계하고 시스템 전체의 아키텍처를 고려한다.
     • 프로그램설계 : 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계 
       • 주문 처리 모듈은 주문을 받고, 재고를 확인하고, 결제 처리를 하고, 배송을 예약하는 등의 작업을 수행한다.
       • 예를 들어, 주문 처리 모듈에서 주문을 저장하는 데이터 구조, 재고 확인을 위한 알고리즘, 결제 처리를 위한 함수 등을 설계한다.
     • UI(User Interface) 설계 : 사용자 인터페이스 설계로, 사용자가 시스템을 사용하기 위해 보이는 부분을 설계 
3. 구현 :
   • 설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용하여 실제 프로그램을 작성한다.
   • 이때 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉜다.
     • 구조화 프로그래밍 :
       • 조건문, 반복문을 사용하여 프로그램을 작성하고,
       • 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며,
         • 예를 들어, 계산기 프로그램에서는 사용자가 입력한 연산자와 피연산자에 따라 순차적으로 계산을 수행하는 순차구조와, 조건문을 사용하여 특정 조건에 따라 다른 연산을 수행하는 선택구조, 반복문을 사용하여 여러 번의 계산을 수행하는 반복구조 등을 활용한다.
       • 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있다.
     • 모듈러 프로그래밍 :
       • 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법이다.
       • 예를 들어, 온라인 상점 프로그램에서는 상품 관리 모듈, 주문 처리 모듈, 결제 처리 모듈, 배송 관리 모듈 등의 각각의 기능을 독립된 모듈로 구현하고, 이를 조합하여 전체 프로그램을 구성한다.
       • 모듈별로 개발과 테스트 및 유지보수 가능하며, 모듈의 재사용 가능하다는 장점이 있다.
4. 테스트 :
   • 테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가하는 일련의 과정이다. 미처 발견하지 못한 오류를 발견할 수 있기 때문에 매우 중요한 과정이다.
5. 배포 및 유지보수 :
   • 배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭한다.
     • "인수"는 시스템이나 소프트웨어의 개발이 완료되고, 해당 시스템을 사용하거나 운영할 주체(일반적으로 고객이나 사용자)가 해당 시스템을 받아들여 사용하기로 합의한 것을 의미한다. 
     • 인수는 개발자나 제공자가 개발한 시스템을 사용자나 고객에게 전달하는 과정을 의미하며, 이는 일반적으로 시스템의 배포 단계에서 이루어진다.
   • 이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지한다.
   • 유지보수의 유형에는 수정형, 적응형, 완전형, 예방형 총 네 가지가 있다.
     1. 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행 
     2. 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업 
     3. 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업 
     4. 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 수행 

 

무엇을 개발할지 결정하고 요구사항들을 구현 작업에 적합하게 명확하고 조직화된 구조로 바꾸는 과정을 거쳐, 실제 개발에 착수하는 단계는 ‘구현’부터이다.

• 현재 그림 상으로는 이 단계들이 계속 꼬리를 물고 도는 순환 구조로 되어 있지만,
• 실제 개발 환경에서는 환경에 따라 각각의 단계가 또 세밀하게 나뉘어 있기도 하며, 각 단계가 계속해서 반복되기도 한다.

 

이러한 개발 프로세스는 다양한 모델이 있으며 어느 정도 규모의 앱을 개발하는지, 혹은 어떤 종류의 앱을 개발하는지를 고려하여 모델을 선택해 사용한다.

전통적인 개발 프로세스

 

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

• 영어에서 주는 직관적인 느낌 그대로, 폭포와 같이 한 방향으로만 프로세스가 진행되는 개발 과정을 뜻한다.
• 실제로 한국어로도 “폭포수 개발 방식” 이라고도 한다.
• 보통 아래와 같은 사이클을 가지고 있으며, 유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델이라고 볼 수 있다.
• 여기서 변형된 모델들이 나오나 보통은 프로세스가 기본 모델에서 추가가 되거나 하나의 프로세스가 세부적으로 나뉘거나 하는 수준에서 그친다.

[그림] 워터폴의 가장 기본적인 모델

 

이런 워터폴 개발 방식은 실제 출시 기한을 정해놓고 순차적으로 프로세스가 진행시켜 애플리케이션(소프트웨어)를 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다.

• 또한 실제 디자인 또는 개발된 화면을 시각적으로 확인할 수 있는 단계는 이미 많은 단계가 지나온 시점이기 때문에 어떤 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 애로 사항이 생기게 된다.
• 대부분 그래서 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장받기가 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있다.

 

 

그래서 전통적인 소프트웨어 개발 프로세스에서는 소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 한다.

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

이 외에도 다양한 테스트가 존재한다.

모던 개발 프로세스

 

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

• 이 애자일 방식은 ‘스프린트(sprint)'라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복한다.
• 이 방식은 요구사항이 변하는 것을 당연한 전제로 두고 있다.
• 따라서 계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발에 착수할 수 있다.
• 애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능해진다.
• 이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합하다.

 

SaaS란?

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

• 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없게 된다.
• 따라서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능하다.
• 또한 공급자가 전체 시스템을 관리하기 때문에 빠른 배포 속도도 보장받을 수 있다.
  
  • 예를 들어, SaaS로 제공되는 프로젝트 관리 플랫폼인 Trello 사용자는 소프트웨어의 업데이트를 수동으로 설치하거나 관리할 필요가 없다.
  • Trello 팀은 새로운 기능을 개발하고 배포할 때, 사용자는 자동으로 업데이트를 받아 실시간으로 새로운 기능을 사용할 수 있게 된다. 

 

아래 그림은 구글의 Gmail 업데이트 로그이다.

• 해당 기간 동안 Gmail은 잦은 업데이트를 했지만 Gmail은 SaaS 방식으로 서비스를 제공하기 때문에, 사용자는 업데이트를 했는지도 모르고 해당 애플리케이션을 사용했을 것임을 유추할 수 있다.

 

전통적인 개발 프로세스 VS 모던 개발 프로세스

그렇다면 전통적인 개발 프로세스는 모던 개발 프로세스에 비해 현저히 떨어지는 프로세스일까? 그렇지는 않다.

• 모던한 개발 프로세스를 따른다 해도 “제대로" 따르지 않는다면 하느니만 못하기 때문이다.
• 아래의 표는 전통적인 개발 프로세스인 워터폴과 모던 개발 프로세스인 애자일의 장점 및 단점을 정리한 표이다.

	워터폴	애자일
장점	- 프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관없이 따르기 쉬움 - 개발 주기가 정해져 있으므로 새로운 프로젝트를 안정적으로 시작 가능 - 요구 사항이 확정되어 있으므로 프로젝트를 실행하기 수월하며, 개발 목표를 자주 변경하지 않아도 됨 - 프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 훨씬 쉬움	- 빠르면서 유연한 개발 과정 - 짧고 반복적인 스프린트로 구성되어 있어 품질에 초점을 맞출 수 있으므로 빠르게 결함을 인지하고 수정 가능 - 스프린트를 통한 짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능
단점	- 개발이 순차적으로 진행되므로 앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어짐 - 테스팅 단계에 이르러서 이슈가 발견되는 경우가 왕왕 있음 - 개발 요구 사항이 초기에 확정되므로 범위 변경이 자유롭지 못함	- 스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요함 (스크럼 프로세스를 관리하고 스크럼 팀이 잘 수행되도록 지원하는 역할을 담당하는 사람) - 고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생 - 팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 애자일론을 채택할 시 문제가 발생

또한 앞서 이야기했듯, 어느 정도 규모의 앱을 개발하는지, 혹은 어떤 종류의 앱을 개발하는지를 고려하여 모델을 선택해 사용하기 때문에, 오히려 어떤 상황에서는 체계적인 계획과 문서를 만들고 시작하는 전통적인 개발 프로세스가 더 적합할 수도 있다.

• 밑의 표는 해당 프로세스가 적합한 조직을 나열한 표이다.

	워터폴	애자일
이런 상황에 적합	- 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 경우 - 프로젝트 팀의 경험이 적은 경우 - 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우	- 고성능 소프트웨어 개발 중에서도 특히 소프트웨어 개발을 할 경우 - 고품질의 결과물과 지속적인 개선에 초점을 맞출 경우 - 프로젝트가 완벽히 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 경우
이런 기업 및 팀에 적합	- 개발상의 변경이나 리스크에 덜 민감한 기업 및 팀 - 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 및 팀	- IBM, 시스코, AT&T, 마이크로소프트와 같이 크고 복잡한 회사들이 프로세스를 간소화해 변화에 더욱 신속하게 대응하고자 할 때 - 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀

DevOps

 

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

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

 

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

• 이런 갈등이 빚어지는 구조는 현대 IT 시장에는 맞지 않을뿐더러, 제품의 릴리스 주기를 길어지게 만들기도 한다.
• 그렇기 때문에 DevOps라는 개념이 만들어졌다.

 

DevOps는 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어이다.

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

DevOps 문화

DevOps는 특정한 업무라던지 부서가 아닌 일종의 개발 문화이다.

• 만약 서비스가 중단된다면, 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다.
• 이를 위한 기술과 지식이 제공되기 위해서 훈련과 효과적인 협업체계를 마련하는 것이 매우 중요하다.
• 그러나 실제 실무에서는 업무의 분리를 위해 DevOps팀, 혹은 부서를 두고 있을 수 있다.

[그림] 기능의 분리가 아닌 교차되어 어느 누구라도 해당 업무를 수행할 수 있어야 한다.

 

 

 

DevOps 특징

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

• 즉 코드 통합, 테스트, 배포 과정을 자동화시키는 것이다.
• 이 부분은 지속적으로 유지되어야 할 필요가 있는데, 지속적 통합 및 배포(CI/CD)라고 하며 DevOps의 핵심 원칙이라고 해도 과언이 아니다.
• 잘 구축된 CI/CD는 애플리케이션의 배포 시간을 크게 단축시킨다.

[그림] 애플리케이션 배포에 걸리는 시간

 

DevOps 사례

실제 인터넷상에서 스트리밍이나 사진과 같은 엄청난 트래픽과 다양한 사용자 환경 및 요구에 빠르게 대응하기 위해 배포가 많은 기업 중에 DevOps를 활용하여 성공한 기업들이 많다.

• 미국 최대 온라인 스트리밍 서비스를 제공하고 있는 넷플릭스(Netflex)는 2012년 기준으로 3천만 명이 넘는 가입자를 보유하며 엄청난 스트리밍 트래픽을 아마존 웹 서비스(AWS)에서 10,000여 개 이상의 인스턴스를 10여 명 정도의 Devops팀으로 관리하고 있다.
• 사진 SNS 서비스로 야후에 합병된 Flickr는 초당 40,000 장의 사진이 업로드되는데 DevOps를 통하여 모든 배포 및 운영을 자동화하여 하루에도 10여 번 씩 이상의 배포를 하곤 한다.
• 음악 스트리밍 서비스로 최근 각광을 받고 있는 Spotify도 강력한 DevOps 개발문화를 갖추고 오픈소스 도구를 활용하여 배포와 운영을 자동화하여 관리한다.

 

이렇게 Devops를 통하여 새로운 기능을 시장에 보다 자주 그리고 빨리 출시할 수 있고, 장애발생 시 보다 대응과 시스템의 안정성을 향상할 수 있음을 알 수 있다.