Hwan. 001

** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.

소프트웨어 생명 주기 (Software Development Life Cycle, SDLC)

 소프트웨어의 계획부터 배포에 이르기까지 시간적인 경과를 의미하며, 명확하게 나눠진 여러 단계를 통해 시스템의 품질을 올려 고객의 만족도를 높이는 것이 목적이다. 이런 목적의 달성을 위해 구조적, 정보공학적, 객체지향, CBD(Component-Based Development), Agile, DevOps 와 같은 방법론들과 여러 모델들이 발생하게 되었다.

아래 이미지는 SDLC의 각 과정을 나타낸 그림이다.

구조적 방법론

1970년 발생한 기능 중심의 전통적인 방법론이다. 자세한 내용은 아래에 정리해보았다.

절차

요구사항 분석 - 구조적 분석 - 구조적 설계 - 구조적 프로그래밍

• 요구사항 분석 : 데이터 분석, 시스템 환경 분석, 사용자 요구기능
• 구조적 분석 : DFD 작성, DD 작성, Minispec 작성, DB 분석 (1/2)
• 구조적 설계 : DB 분석 (2/2), DB 설계, 어플리케이션 설계
• 구조적 프로그래밍 : 3개 논리적 구조로 프로그래밍

 ** DFD : 데이터 흐름도, 기능별로 분할하여 표현한 구조도

 ** DD : 자료 사전, 자료의 의미나 단위, 값 등에 대한 사항을 정의

 ** STD : 상태 전이도, 상태가 변경되는 과정과 프로세스를 명시하는 것

 ** NS 차트 : 알고리즘은 순차, 선택, 반복 구조면 설명이 가능하다.

등장 배경

 GOTO 문을 쓰지 말자라는 주장이 호응을 얻으면서 분석과 설계를 구조적으로 하자. 라는 의견으로 확대됨

특징

 데이터 흐름 지향 (DFD/ ERD), 모듈의 분할과 정복에 의한 하향식(Topdown) 설계방식 - 소수의 전문가, 모듈의 구조화를 통한 재사용/ 유지보수성 제고, SDLC 구조를 가진 폭포수 모델이 기본. 단일입구/ 단일 출구의 처리구조를 가짐. 

정형화, 체계화, 모듈화의 장점이 있다.

단점 

 어플리케이션은 여전히 기능적 설계, 기능의 유지보수와 재사용성은 낮음, 프로젝트의 관리 및 조직, 역할 등 방법론적 다른 요소들의 정의가 없음., 단순한 소프트웨어의 개발만 목표로 하여 단위 프로젝트에서만 사용, 데이터의 정보 은닉이 안됨.

모델

 폭포수(Water Fall), v-model

참고 링크

https://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8

정보공학적 방법론

1980년대 발생한 자료 중심의 방법론으로 대규모 정보 시스템을 구축하는데 적합하다.

기업 정보 시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계 및 구축을 하는 데이터 중심의 방법론이다.

자세한 내용은 아래를 보자.

절차 

 정보 전략 계획 수립 단계 - 업무 영역 분석 단계 - 업무 시스템 설계 단계 - 업무 시스템 구축 단계

등장 배경

 정보 시스템은 소프트웨어의 개발과는 달리 하드웨어, 네트워크 등 여러 소프트웨어와 복잡하게 연결되는 대규모 시스템이기 때문에 이러한 시스템을 개발하기 위해서는 장기간, 많은 인력이 소모됨. 그러므로 철저한 계획과 팀워크를 기반으로한 프로젝트의 관리와 이를 위한 잘 짜여진 방법론이 필요하게 됨

특징

• 일반전인 소프트웨어 개발이 아닌 기업의 Biz 전략에 따라 수립된 ISP에 따라 정보시스템 통합에 그 초점이 맞추어짐.
• 따라서, ISP 수립 - 업무영역 분석 - 업무시스템 설계 - 업무시스템 구축 의 순서를 가진다.
• Process는 변하지만 Data는 불변이기 때문에 프로그램 로직은 데이터 구조에 종속적이며(CRUD를 따르며) 데이터 안정성을 추구하기 위한 데이터 구조에 중점을 둔다.
• 기본적으로 정보공학은 공학적 개발 방법론이며 자동화 도욱, CASE 툴을 이용하여 코드의 자동 생성을 목표로 한다.

단점

 어플리케이션은 여전히 기능적 설계, 기능의 유지보수, 재사용성 낮음

객체지향 방법론

 1990년대 발생한 객체 중심의 방법론으로 현실 세계의 개체(Entity)를 하나의 객체(Object)로 만들어, 기계를 조립하듯 객체의 조립을 통해 필요한 소프트웨어를 구현하는 방법론이다. 복잡한 현실 세계를 모델링하며 객체, 클래스, 메시지 등으로 구성되어 있다.

절차

개발 준비 - 분석 - 설계 - 구현 - 테스트 - 전개 - 인도

등장 배경

 구조적 방법론이나 정보공학 방법론 모두 프로세스와 데이터를 분리하여 처리한다는 단점은 이를 통합하여 처리하는  객체 지향의 등장에 가장 큰 배경이 되었다.

특징

재사용성이 뛰어나고 유지보수 비용이 적어 생산성 및 품질을 향상 시킬 수 있다.

추상화, 캡슐화, 상속, 정보은닉 등 객체를 중심으로 프로그래밍 구조를 단순화함

구조적, 정보공학적 방법론은 프로세스와 데이터 분리했지만 객체지향 방법론은 프로세스와 데이터의 통합함 (클래스)

분석과 설계간 차이가 없음.

단점

• 전문가 부족 (?)
• 기본 SW 기술 필요
• 상속이 많으면 성능이 저하되는 단점 
• 다형성이 많으면 유지보수가 어려워진다.

추상화

• 개념 : 현실세계의 사실은 그대로 객체로 표현하기 보다는 문제의 중요한 측면을 주목하여 상세 내역을 없애 나가는 과정
• 역할 : 복잡한 프로그램을 간단하게 해주고 분석의 초점을 명확히 함
• 특징 : 클래스를 이용함으로써 데이터와 프로세스를 함께 추상화 구조에 넣어, 더 완벽한 추상화를 실현함

캡슐화 (정보은닉) 

• 개념 : 객체의 상세한 내용을 객체 외부에 숨기고 단순히 메시지 만으로 객체와의 상호작용을 하게 하는 것.
• 역할 : 객체의 내부 구조와 실체를 분리하여 내부의 변경이 프로그램에 미치는 영향을 최소화하여, 유지보수성을 올림
• 특징 : Public과 Private

상속성

• 개념 : 슈퍼 클래스가 갖는 성질을 서브 클래스에 자동으로 부여하는 것.
• 역할 : 프로그램을 쉽게 확장할 수 있도록 해주는 강력한 수단

다형성

• 개념 : 하나의 인터페이스를 이용하여 서로다른 구현 방법을 제공하는 것
• 역할 : 특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체를 개발하는 수단을 제공

CBD 방법론

2000년대 발생한 컴포넌트 중심의 방법론이다.

** 컴포넌트 : Context와 Interface

** 컨테이너 : 컨포넌트를 구현하기 위한 서비스 런타임 환경

절차

 도메인 분석 - 도메인 설계 - 컴포넌트 추출 - 컴포넌트 설계 - 컴포넌트 구현

특징

• Black Box 재사용 : 인터 페이스를 이요하여 재사용
• 추상화, 캡슐화 : Input과 Output만 있음
• 표준화된 UML을 통한 모델링 및 산출물 작성
• 반복 점진적 개발 프로세스 제공
• 표준화된 산출물 작성 및 컴포넌트 제작 기법을 통한 재사용 성 향상.

품질 측정 지료

 기능에 대한 이해가 편함, 변경이 편함, 컴포넌트간의 결합도(응집도는 이미 컴포넌트를 만들때 고려됨)

Agile 방법론

 2001년 발생한 방법론으로 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론이다. 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합하다.

애자일 방법론의 대표적인 종류로는 XP (익스트림 프로그래밍), 스크럼과 칸반 보드, 크리스탈 등이 있다.

** TDD는 XP의 하위 항목이다.

등장 배경

기존 개발 방법론의 한계와 SW 개발 환경의 변화로 인한 새로운 방법론이 필요

절차

사용자 스토리 - (계획 -> 개발 -> 승인 테스트)의 과정을 반복

DevOps

2009년 발생한 방법론이다. Agile의 한계를 극복하기 위해 나왔으며, 방법론을 실현하기 위한 다양한 도구들이 발생되어 기존의 방법론들 보다 좀 더 명확하고 직관적으로 변했다고 생각한다.

다양한 파이프 라인들을 통해 부서나 팀원 간의 문제 발생 요소를 최소화하면서 결과물의 품질과 개발 효율을 높인다.

좀 더 많은 정보는 아래 글을 참고하면 좋을 것 같다.

https://hwan001.co.kr/200?category=1081020 

** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.

XP ?

 XP(익스트림 프로그래밍)은 애자일 방법론의 유형 중 하나로 미국의 소프트웨어 엔지니어인 캔트 벡이 제안한 소프트웨어 개발 방법론이다.

비즈니스 상의 요구사항이 계속해서 바뀌는 경우에 사용하면 효율적인 개발 방법이며, XP라는 약칭으로 불린다.

XP는 5가지의 가치와 12개의 기본 원리(또는 실천 방법)와 1~3주 정도의 반복 주기(Iteration)가 존재하며, 개발 문서 보다는 소스 코드를 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 둔다.

또한 12가지 기본 원리 중 하나인 테스트 기반 개발(TDD; Test Driven Develop)를 통해 프로그래머들이 코딩 전에 테스트 코드를 작성하기 때문에 반복적인 프로토 타입의 전달 시에 버그가 상대적으로 적은 데모를 경험할 수 있게 해준다.

켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했다.

실천 방법에만 집중하고 가치와 원칙을 무시한다면, XP를 제대로 실천하고 있다고 하기는 어렵다고 생각한다.

아래에서는 각 가치와 원칙을 정리해보겠다.

XP의 5가지 가치

 xp에서는 아래 5가지의 가치를 추구한다.

• 용기 (Courage) 
• 단순성 (Simplicity) 
• 의사소통 (Communication)
• 피드백 (Feedback)
• 존중 (Respect)

가치의 실현을 위해서는 자신감있게 개발하고 빠르게 피드백하며, 테스트에 부합하지 못할 경우 코드를 리펙토링(용기)할 수 있도록해야 한다. 또한 단순성을 위해서 필요한 최소한의 작업만을 해야하고 개발자-관리자-고객 간의 원활한 소통(의사소통)을 하여 소통에 대한 빠른 피드백을 전달해야 한다.

마지막으로는 팀원 서로간의 상호 존중해야 한다.

XP의 12가지 기본 원리

  XP에는 12가지의 기본 원리가 존재한다.

•  짝 프로그래밍 (Pair Programming)
• 공동 코드 소유 (Collective Ownership)
• 지속적인 통합 (CI; Continuous Intergration)
• 계획 세우기 (Planning Process)
• 작은 릴리즈 (Small Release)
• 메타포어 (MetaPhor)
• 간단한 디자인 (Simple Design)
• 테스트 기반 개발 (TDD; Test Driven Develop)
• 리팩토링 (Refactoring)
• 40시간 작업 (40-Hour Work)
• 고객 상주 (On Site Customer)
• 코드 표준 (Coding Standard)

 먼저 짝 프로그래밍은 개발자 2인이 짝으로 코딩한다는 원리이다.

시스템에 있는 코드는 누구나, 언제나 수정이 가능(공동 코드 소유)해야하며 매일 여러번씩 소프트웨어를 통합하고 빌드(CI)해야한다.

 XP에서는 고객이 요구하는 가치를 정의하고 개발자가 필요한 내용이 무엇인지, 어떤 부분에서 지연될 수 있는지를 알려주어야한다.(계획 세우기) 또한 작은 릴리즈를 위해서는 작은 시스템을 먼저 만들고, 짧은 주기로 업데이트 해야한다.

 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자의 의사소통을 원활하게 하며 (메타포어), 간단한 디자인은 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리이다.

 테스트 기반 개발(TDD)은 위에서도 잠깐 언급했지만, 다른 애자일 방법론과 차이를 두게 하는 중요한 부분이다.

개발자는 TDD를 위해 작성해야 하는 프로그램에 대한 테스트를 먼저 작성해야하며, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성해야 한다.

 리팩토링은 프로그램의 기능을 변경하지 않으면서 중복을 제거하고 기능을 단순화하는 등의 최적화에 대한 내용이고 40시간 작업은 말 그대로 주 40시간 미만의 작업을 통해 개발자의 피로도를 관리하여 실수를 줄인다는 의미이다.

고객상주는 개발자의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 의미이고, 마지막 코드 표준은 효과적인 공동작업을 위해 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리이다.

정리 및 느낀점

 애자일 방법론의 여러 유형 중 하나인 XP에 대해서 정리해보았다.

기존의 여러 전통적인 방법론들(폭포수, 나선형 모델)과 비교하면 훨씬 복잡하지만 위의 기본 원리들이 잘 실행되고 가치들도 잘 지켜진다면, 기존의 단점을 없애면서도 생산성과 결과물의 완성도 등을 높일 수 있는 획기적인 방법이라는 생각이 들었다.

 하지만 각 가치를 추구하면서도 12가지 기본 방법들을 지켜나가려면 팀원 개개인과 고객, PM등 프로젝트의 구성원 모두가 XP에 대해서 잘 이해하고 있어야하고, 원칙과 가치만 존재하기 때문에(같은 용어여도 사람마다 생각하는 게 다를 수 있을 것 같다.) 현실의 프로젝트에 적용하기는 쉽지 않겠다는 생각이 들었다.

데브옵스가 시장에서 많이 활용되어지는 이유 중 하나라고 생각한다.

참고자료

• https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.

MSA (Micro Service Architecture) ?

 DevOps를 공부하면서 MSA라는 단어를 많이 듣게 되었다.

처음 단어를 들었을 때는 별로 깊게 생각하지 않았었기 때문에 (다시 생각해보면 조금 부끄럽지만) AWS와 GCP와 같은 클라우드 플랫폼을 말하는 거라고 생각했었다. 하지만 우연히 다시 검색해본 MSA의 설명은 충격적이었다.

MSA : Micro Service Architecture

기존의 MA(Monorithic Architecture)는 모든 모듈이 하나의 서비스 내에 종속되어 있다.

이런 구조는 프로젝트의 개발과 빌드, 배포 등의 작업에 장점이 있지만, 만약 출시된 프로그램에 새로운 기능이 추가된다면 해당 모듈 하나를 적용하기 위해 모든 서비스를 다시 빌드하고, 배포해야 한다.

또한 추가된 기능이 기존의 프로젝트 구조와 맞지 않다면, 하나의 기능을 추가하기 위해 프로젝트 전체를 뜯어 고쳐야할 수 도 있다.

하지만 MSA는 각 기능을 독립적으로 분리하여 (단일 컴포넌트) 여러 서비스의 조합으로 하나의 시스템을 구축하며 각각의 서비스가 의존적이지 않기 때문에(API 기반) 변경이 필요한 하나의 모듈만을 수정 후 배포할 수 있다. 또한 이런 특성으로인해 각 서비스의 확장도 간단하다. 

MSA에서의 조직 구조와 단점

 기존의 개발 조직 구조는 기능(또는 소프트웨어 생명주기의 단계)과 역할을 기준으로 기획, 개발, 운영 등의 팀을 나누어 하나의 시스템을 이루었다. 이러한 방식은 인력관리와 운영 등의 관점에서는 효율적이지만, 각 조직간의 커뮤니케이션과 협업을 통한 생산성과 변화에 대한 대응 등의 관점에서는 비효율적이었다.

 MSA에서의 조직 구조는 각각의 팀이 하나의 서비스를 맡는다.

각 팀은 서로간의 의존성이 적기때문에 각 서비스의 확장, 변경등의 지속적인 개발과 유연한 운영이 가능하고 요청에 대한 피드백이 빨라진다. 하지만 MSA에도 단점이 많다.

우선 MSA 자체는 여러 독립적인 서비스가 이루어져 하나의 시스템을 원활하게 운영해야 하기 때문에 최대한 방어적인 코딩이 필요하고 각 서비스마다 DB가 존재할 경우 분리된 DB들 간의 트랜젝션과 데이터의 동기화 문제가 존재하며 각 서비스가 도메인과 API를 기반으로 통신하기 때문에 인터페이스의 개발에도 신경을 써야한다. 또한 통합 테스트와 배포가 어려울 수 있다. 조직의 관점에서도 인력을 관리하기 어려워지고, 개발자들은 인프라에 대한 운영과 각 서비스에 대한 테스트도 진행해야한다.

팀원 개개인의 숙련도가 중요해질 수 밖에 없는 구조이다.

MSA 단점의 보완

 MSA에서의 단점인 분리된 여러 DB 문제와 통합테스트, 배포에 대한 부분은 AWS, GCP와 같은 클라우드 서비스와 쿠버네티스가 등장하면서 많은 부분이 상쇄되었다.

 쿠버네티스에서는 pod의 형태로 각 컴포넌트, 서비스들을 관리하며 배포와 테스트 자동화를 구축할 수도 있다.

또한 각 서비스 간의 (인그레스를 통한 도메인 중심의) 통신을 지원하기 때문에 DB와 데이터를 하나의 pod 형태로 관리할 수 있다.

 그 결과로 결합도가 낮아져 설계 구조의 변경도 비교적 쉬워졌고 변화에 대한 대응과 확장도 용이해졌으며 그 외의 다양한 단점들도 많은 부분이 상쇄되었다.

팀원 개개인의 숙련도만 충분하다면 기업 입장에서는 MSA를 선택하지 않을 이유가 없다고 생각한다.

참고 링크

• http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/
• https://www.samsungsds.com/kr/insights/msa_architecture_edm.html
• https://suzyalrahala.tistory.com/49

** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.

DevOps ? 

 최초 데브옵스의 개념은 2009년 O'Reilly에서 주회한 Velocity 컨퍼런스에서 등장했다고 한다.

당시 루디코프 사의 엔지니어 2명이 '10+ Deploys per Day : Dev and Ops Cooperation at Flickr' 라는 이름으로 프레젠테이션했다.

 이 발표에선 전통적인 조직의 개발과 운용 부서는 서로 대립되는 구도에 놓인다고 했다.

가장 큰 이유는 각 부서의 입장 차이인데 개발 부서는 변화를 원하지만 운용 부서에서는 서비스의 안정을 위해 시스템의 큰 변화를 원치 않기 때문이다. 하지만 이런 대립 관계가 심화되면 아래의 과정을 거쳐 음의 무한반복 사이클(악순환)이 생기 때문에 조직에 많은 문제가 발생한다.

1. 운용 부서에서는 안정성을 이유로 개발 부서의 변화 의견을 거부한다.

2. 개발 부서는 임의로 내용을 변경하고 해당 내용을 운용 부서에 전달하지 않는다.

3. 운영 부서가 인지하지 못한 변화로 서비스에 예기치 못한 사고가 발생한다.

4. 위 과정이 반복되면 갈등이 더 심화되며, 심화된 갈등으로 더 깊의 음의 무한 반복 상태에 놓인다.

이런 문제를 해결하기 위해 발표에선 몇가지 도구와 문화, 그리고 변화에 대응하기 위한 지표를 제시하였지만 초반엔 기존의 기업 문화가 남아있어 많은 비난을 받았었다. 하지만 변화의 흐름이 빠른 현재는 DevOps 적용에 대한 긍정적인 신호들이 많이 보인다.

 DevOps는 Development 팀과 Operations 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성(Continuous  Integration)을 추구한다. 이런 노력들은 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 되며, 필요한 기능의 변경 및 추가 작업을 더 빠르고 지속적으로 배포(Continuous Deployment)할 수 있게 된다.

DevOps 와 Agile 방법론

 위의 이미지는 위키피디아에서 가져왔다. 개인적으로 DevOps의 위치를 가장 잘 요약한 그림이라고 생각한다.

방법론에 대한 자료를 조사하면서 Agile 방법론에 대한 내용을 많이 볼 수 있었는데 대부분은 DevOps가 Agile의 발전된 버전이라는 예시를 들었다. (정확한 비교는 아니라고 생각하지만 초반에 개념 이해에 도움을 줬다.)

 소프트웨어 개발 방법론은 말 그대로 소프트웨어 만드는 방법에 대한 이론이다.

규모가 큰 소프트웨어의 개발을 위해서는 기획 의도와 구성, 절차 등을 미리 작성해둘 필요가 있기 때문에 전통적인 방법론(waterfall, CBD, 객체지향)들이 연구되고 프로젝트에 적용되었다. 하지만 전통적인 방법론들은 절차를 중시하여 설계 되었기 때문에 빠른 변화에 민첩하게 대응하기 어려웠다.

여기서 빠른 변화에 대한 대응을 위해 계약과 절차보다는 고객과의 상호작용과 협력을 더 중시하는 Agile 방법론이 발생하게 된다.

 Agile과 DevOps의 지향점은 근본적으로 같지만 각 방법론의 목표와 실천 방식은 차이가 있다.

Agile은 빠른 프로토타입, 반복과 피드백을 통한 지속적인 퀄리티 향상을 추구하며 고객과의 상호작용에 초점을 두는 반면 DevOps는 상호작용을 포함하여 개발팀과 운영팀 간의 긴밀한 협력 관계를 구현할 수 있는 도구(파이프라인)의 구축을 추구한다. 또한 Agile은 각 상황별 장단점이 있는 다양한 방법론을 사용하는 등 여러 케이스를 나누고 각 케이스별 실천법을 다루지만 DevOps는 각 실천법들의 장점을 채택하여 하나의 체계로 녹여낸다는 차이점이 있다. 

 Agile은 눈에 보이지 않는 형이상학적 개념을 강조한다. DevOps 또한 동등한 개념과 가치를 중요하게 생각하지만, 도구와 프로세스 정규화 등을 통해 눈에 보이는 성과를 만들어 낼 수 있다. (이런 부분들 때문에 DevOps가 Agile의 발전형이라는 말이 나온 것 같다.) 하지만 업무 프로세스를 정규화하고 다양한 도구들을 사용해 환경을 구축한다고 하더라도 결국은 그걸 사용하는 사람들의 적극성과 이해도가 가장 중요하다.

 그러므로 DevOps는 개발-운영팀은 물론 조직 내의 공통된 문화로 정착 되어야 하며, DevOps의 파이프라인은 각 부서의 특성과 문화를 고려하여 설계, 구축한 뒤에도 꾸준한 관리와 교육 훈련이 진행되어야 한다.

Why ?

 DevOps는 문화이자 방법론이다. 최근의 공고를 보면 DevOps 엔지니어를 구한다는 글도 꽤 자주 보인다.

그런데 위의 엔지니어가 DevOps 방법론을 적용하고 조직에 어떤 문화를 만들어 주는 사람이나 역할을 지칭한다면 뭔가 이상하다. Agile 엔지니어 또는 객체지향, CBD 엔지니어라는 말은 들어본 적 없기 때문이다.

 DevOps 엔지니어는 왜 필요할까?

당연히 정답은 없겠지만 여러 자료를 찾아보고 고민하면서 내가 내린 결론은 단순했다.

DevOps 자체로도 업무 범위가 넓고, 개발자나 운영자가 기존의 업무와 병행해서 하기 어렵기 때문이다. (팀의 능력이 뛰어나다면 가능은 하겠지만, 기존 팀의 업무에 추가로 적지 않은 양의 업무가 부여된다면 많은 문제가 생길 것 같다.) 또한 파이프 라인이 존재하기 때문에 기존의 방법론들보다는 해야할 일이 명확하고 가시성이 좋다.

 DevOps 에서 파이프 라인은 자동화된 프로세스의 세트(CI/CD, 인프라와 툴체인 등)를 의미한다.

이런 파이프 라인은 소프트웨어의 생명 주기의 전체 과정에 관여하게 되는데, 이런 환경을 구성하려면 다양한 도구들을 다뤄야 한다. 또한 그렇게 환경을 만든 이후에도 해당 인프라를 안정적으로 관리, 모니터링하며 지속적인 교육과 홍보를 해야한다.

 위 모든 업무를 기존의 업무와 병행하며 하기엔 물리적으로 힘들어보인다.

기존 팀에게 해당 업무를 부여할 경우, 효율을 올리기 위해 하는 업무가 오히려 팀의 발목을 잡는 것이다.

How ?

 DevOps를 직접 구현해야 한다면 핵심 과제는 크게 문화와 파이프 라인이라는 2가지 범주로 나눠진다고 생각한다.

문화를 구현하는 방법은 (많은 실천법들이 있긴하지만) 너무 추상적이다. 하지만 이 중 파이프라인을 구현할 도구들은 이미 많이 있다. 아래 이미지는 소프트웨어 생명 주기의 각 단계 별로 해야하는 역할과 그 역할을 수행할 수 있는 툴들을 NetApp 이라는 업체에서 정리한 내용이다. 각 툴들이 하나의 연결 고리를 이루며, 모든 체인이 엮어 유기적으로 작동하면 'DevOps 툴체인'을 이룬다.

 DevOps 팀은 각 도구들을 조직의 환경에 맞게 적절히 활용하여 툴체인을 현실에 구현하고 유지, 관리 해야한다. 

또한 이러한 툴들을 개발-운영 부서가 적극적으로 사용할 수 있도록 지속적으로 사용법을 교육, 문서화하고 장기적으로는 이러한 업무 방식을 조직내에 문화화(enculturation) 시켜야한다.

 하지만 구체적인 방법들을 여기서 전부 작성하기엔 여백이 부족하다. 문화화를 위한 여러 실천법 (칸반과 스크럼 등) 과 파이프 라인을 구축하기 위한 툴의 사용법 등은 하나씩 공부하면서 앞으로 다른 글들을 통해 다뤄보겠다.

참고 자료 링크

• https://ko.wikipedia.org/wiki/%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4
• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=ydot&logNo=22153632304
• https://m.blog.naver.com/sundooedu/221193074730
• https://engineering-skcc.github.io/devops/DevOps1-%EC%95%A0%EC%9E%90%EC%9D%BC%EA%B3%BC%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4/​
• https://multicore-it.com/46
• https://www.netapp.com/ko/devops-solutions/what-is-devops/