DevOps란 무엇인가?

이 글은 DevOps에 관한 정보를 담고 있는 글이다.

DevOps는 webper 프로젝트에 적용했던 방법론이기도 하고, 예전부터 공부해 보고 싶어서 DevOps에 대한 많은 문서를 공부해보고 나의 생각 및 관련 자료들을 이 포스팅을 통해 정리하였다.

“DevOps란 무엇인가?”에 대한 포스팅을 시작으로 프로젝트 개발시 DevOps를 달성(?)할 수 있는 여러 자동화 툴들과 인프라 구성 방법에 대해서 탐구할 생각이다!! 물론 이들 또한 포스팅으로 정리해 올릴 생각이기 때문에 독자 여러분들이 많은 관심을 주셨으면 좋겠다.

지금부터 DevOps에 대해서 알아가기 위해 긴 여정을 떠나도록 하겠다.

1. DevOps란 무엇인가?

DevOps란 무엇인가에 대해서 소개하기 앞서 DevOps는 “문화”인가? “방법론”인가? “추상적인 개념”인가? “도구”인가? “철학”인가?에 대해서 단 하나로 정의하기는 쉽지 않다. DevOps는 문화이면서, 특정한 목적을 이루는 방법론이고, 철학이기도 하다. 개인적으로는 DevOps는 목적을 이루기 위한 방법론으로써 표현하는 것이 가장 맞는 것 같기도 하다.

DevOps에 관한 많은 글을 읽어본 나의 입장에서 생각해 봤을 때 DevOps를 하나의 카테고리로 구분하기에는 참 쉽지 않다. 각 문서가 설명하는 DevOps에 대한 정의는 각각 다르지만, DevOps를 통해 이루고자 하는 바는 모두 동일하다. 그래서 나는 DevOps를 설명하기위해 하나의 개념으로 정의하기 보다는 DevOps를 통해 이루고자 하는 바를 명시해 주어 이를 통해 독자가 다양한 생각을 할 수 있게끔 제시해주고자 한다.

DevOps는 Dev(개발)와 Ops(운영)를 합쳐 비즈니스(User)의 요구사항을 단기간에 반영할 수 있는 품질 높은 소프트웨어를 만들고자 하는 목적을 가진다. 이를 통해 팀 내의 협업이 증진되는 것은 덤이다.

저자는 DevOps 목적을 이루기 위해 다양한 아키텍처, 자동화 툴, Ias, VCS, Cloud, … 등이 사용될 수 있다고 생각하지만 이러한 방법들이 곧 DevOps라고는 절대 생각하지 않는다. 현재 진행중인 프로젝트의 상황에 맞추어서 잘 사용하면 된다고 생각한다. 하지만 이러한 방법들을 적용하는데 있어서 Best Practice는 존재하니 독자들은 참고하기 바란다.

2. DevOps가 도입되기 전 전통적인 개발 방법론의 문제점과 해결책

전통적인 개발 방법론의 문제점에 대해서 정말 잘 정리해 준 포스팅이 존재한다. 저자는 개발 경력이 짧아서 전통적인 개발 방법론의 문제점에 대해서 절실히 느껴본 적이 없으니 이를 참고해서 글을 작성하도록 하겠다.

전통적인 개발 운영 체계

일반적인 개발 운영 체계는 아래의 그림과 같다. 개발팀에 의해서 개발이 끝나면, 시스템은 테스트를 거쳐서 운영팀에 이관되고, 운영팀은 해당 시스템을 배포 및 관리 운영한다.

운영팀으로 이관된 시스템들은 개발팀이 거의 관여하지 않고, 운영팀에 의해서 운영된다.

Probelm 1. 문제 발생

시스템을 운영하다 보면, 반드시 장애나 이슈가 생기기 마련이다. 개발팀은 애플리케이션을 볼 수는 있지만, 아랫단의 인프라 시스템은 볼 수 있는 능력이 없다. 반대로 운영팀은 인프라 시스템은 잘 알지만, 애플리케이션 자체에 대해서는 잘 알지 못한다.

문제가 발생했을 경우 운영팀과 개발팀에서 문제의 정확한 이유를 도출해내서 관련된 팀에게 문제 처리를 맡기면 되지만 위에 말한 것 처럼 각 팀은 서로의 분야 이외에는 알지 못하기 때문에 본인이 아는 지식 범위 밖에서 문제가 발생된다면 이것은 무조건 나의 잘못이 아니라고 간주해 다른 팀에게 처리를 떠넘기는 상황이 발생한다.

이러한 상황들을 개념으로 정의한 것이 있는데 이게 Fingerpointyness 이다. Fingerpointyness란 정확하게 누가 어떤 문제를 해결해야 하는지 정의되지 않은 상황에서, 협업이 없어지고 문제 해결이 엉뚱한 방향으로 가는 현상을 의미한다.

Fingerpointyness의 절차는 아래의 그림과 같으며, 자세히 알아보자.

Freaking out & find fault (문제 발견) : 문제가 발생하고 내용을 파악하는 단계이다. 자기 분야에서 문제가 어떤 것인지, 한정된 지식으로 현상 자체를 인지하는 수준이다.
Blaming Covering ass 단계 (욕하기) : 정확한 원인이 아닌 문제의 현상이 파악되면 본인이 아는 지식 범위 이외일 경우 서로 미루기를 한다. 문제가 미루어진 쪽이 문제의 원인이라면 다행이지만 아닌 경우 서로 미루게 되면서 문제의 근본적인 원인은 해결되지 않고 시간만 계속 간다.
Whining, Hiding, Hurt Ego 단계 (맘 상처 입기) : 계속해서 서로에게 문제를 넘기다 보면, 문제를 숨기거나 상대방을 헐뜯거나 하면서 결국은 서로는 상처를 입게 되고, 점점 커뮤니케이션은 없어지고 관계는 악화된다.
Figuring it out (문제 원인 분석) : 문제가 해결되어야 하는 시간이 가까워져 오면, 문제를 풀긴 풀어야 하니 어떻게든지 스스로 모여서 문제를 같이 보게 되거나, 상위 매니저를 통하여 강제적으로 모여 문제에 대한 원인 분석을 해서 결국 원인을 파악하게 된다.
Fixing things(문제 해결) : 결과적으로 원인 파악 및 문제가 해결된다.

결국엔 문제가 해결되어 다행이지만, 팀 간에 남겨진 협업 문제는 해결되지 못하고 점점 쌓여만 간다…

Problem 2. 운영 이슈에 대한 전달 문제

개발팀은 서비스를 배포한 후 운영에는 거의 관심을 두지 않기 때문에, 고객과의 접점이 거의 없다. 하지만 User의 요구사항(VoC)을 받는 쪽은 운영팀이기 때문에 이러한 요구사항을 전달받아 개발팀에게 넘겨주게 되는데… 개발팀이 당연히 좋아할 일이 없다.(비즈니스(User)의 요구사항을 전달할 권한이 없는 운영팀이 일을 주어서 개발팀의 일이 늘어나는데 어떠한 개발자가 좋아하겠는가??) 결국 이러한 운영팀의 요구사항들은 개발팀에게 거절되기 쉽고 서비스기획(비즈니스) 팀에게 넘어가게 된다.

수 많은 소프트웨어가 존재하는 현 시대에 소프트웨어가 살아남기 위해서는 사용자의 요구사항을 즉각적으로 반영해야만 하는데 개발과 운영의 분리는 이러한 트렌드와의 거리를 점점 멀어지게 한다.

Problem 3. 변경 요건

서비스가 운영 배포된 후에도, 비즈니스(기획팀)에 의해서, 서비스에 대한 신규 요구 사항은 계속적으로 나오게 되고, 새로운 변경 요건은 신규 개발과, 테스트 배포 그리고 지속적인 운영을 요구 하게 된다.

하지만 잦은 요구사항은 코드의 잦은 변경과 배포를 요구하게 되고 제대로된 테스트를 거치지 못한 경우 잦은 장애를 유발하게 된다.

이러한 배경으로 인해서 운영팀은 잦은 배포를 꺼려하게 되고, 조금 더 전통적이고 형식적인 관점에서 주기적인 릴리즈와 테스트를 요구하게 된다. 더 잦은 장애가 발생됨으로 인해서 장애에 대한 적절한 대응책이 없다면 개발팀과 운영팀의 관계는 더 악화 되어 간다.

Solution

우리는 어떠한 방식으로 위의 문제들을 해결할 수 있을까??

결론은 개발팀과 운영팀 사이에 존재하는 벽을 허물고 팀 간에 협업을 통해 비즈니스(User)의 요구사항을 단기간에 반영할 수 있는 높은 품질의 소프트웨어를 개발해야 한다.

이러한 문제들을 해결하기 위해서 나온 것이 DevOps이다. 즉, 개발과 운영을 합쳐 사용자의 의견에 민감하게 반응하는 높은 품질을 소프트웨어를 만들자는 목적을 가진다.

하지만 개발과 운영.. 하나만 제대로 하기에도 벅찬데 어떻게 2개를 한번에 한다는 말인가??

같이 알아보자.

3. DevOps와 같은 좋은 개념이 왜 이제서야 발전하게 되었는가?

개발과 운영을 동시에 하는것은 당연히 어렵다. 개발과 운영은 영역 자체가 매우 상이하고, 요구되는 기술 능력도 많이 차이나기 때문에, 일반적인 엔지니어가 양쪽을 모두 커버하기가 어렵다.

하지만 근래에는 조금 쉬워졌다. 이러한 이유는 다음과 같다.

인터넷의 발전

인터넷의 엄청난 발전 덕분에 우리는 원하는 정보 대부분을 인터넷을 통해 얻을 수 있다. 아니 전부라고 해도 이상하지 않다. 과거에는 주로 서적 및 교육을 통해서 지식을 얻었다면 요즘은 인터넷, 오픈 소스, Youtube, SlideShare 등의 다양한 플랫폼들을 통해서 지식을 습득할 수 있게 되었다. 본인이 원하는 정보는 다 인터넷 속에 있으니 이 얼마나 좋은 시대인가??

오픈 소스의 발전

인터넷이 발전하면서, IT의 흐름이 크게 바뀐 것중에 하나는 더 이상 오라클이나 IBM과 같은 대형 벤더의 주도 기술이 아니라 페이스북이나 구글과 같은 거대 B2C 서비스가 IT의 흐름을 이끌기 시작했고, 이러한 업체들이 오픈소스를 적극적으로 후원 및 장려하기 시작했다. 오픈 소스에서 많은 지식들을 배울 수 있으며, 전세계의 개발자들과 이야기할 수도, 일을 할 수도 있게 되었다.

좋은 도구들의 발전

오픈 소스의 발전으로 인해, 좋은 툴들이 많아 졌다. 개발에 관련된 툴 뿐만 아니라, 빌드, 배포, 모니터링에 대한 툴도 많아졌기 때문에, 운영 업무에 해당 하는 부분들을 상당 부분 자동화를 할 수 있게 되었다.

클라우드의 등장

클라우드 컴퓨팅의 가장 큰 특징 중의 하나는 사용자가 인프라(서버 설치, 네트워크 케이블 구성)를 구성할 필요가 없이, 간단하게 책상 앞에 앉아서 웹사이트를 몇번 클릭 하는 것만으로도 지구 반대편의 데이터 센터에 서버, 스토리지 구성, 네트워크 구성이 가능하게 되었다는 것이다.

결론

개발을 할 때 필요한 모듈을 오픈 소스를 조합해서 만들 수 있으며, 좋은 도구들을 통해서 빌드나 배포등을 쉽게 자동화할 수 있게 되었고, 클라우드를 통해 개발자도 네트워크, 서버등에 대한 설정들을 할 수 있어지고, 부족한 정보들은 인터넷을 통해 얻을 수 있게 되었다. 결과적으로 개발자가 할 수 있는 영역이 더욱 더 넓어져 인프라에 대한 전문 지식 없이도, 인터넷과 오픈 소스 그리고 클라우드의 도움을 받아서, 운영을 같이할 수 있는 환경이 마련됬다는 것이다.

4. DevOps를 도입함으로써 얻는 장점은 무엇인가?

DevOps를 도입함으로써 팀은 다양한 혜택들을 얻을 수 있다. 물론 DevOps가 장점만 가져다 주는 건 아니지만, DevOps를 도입하기에 적절한 비즈니스 환경을 가지고 있는 조직의 경우 실보다는 득이 훨씬 많을 것이라고 생각된다. (나는 DevOps 찬양론자가 아니다.)

DevOps를 도입함으로써 얻을 수 있는 혜택에 대해서 몇가지 정리해 보았는데 참고 해 보자.

Speed (속도)

DevOps를 도입한 팀은 운영과 개발에 경계가 없어짐으로 작업 속도가 빨라지고 고객을 위해 더 빠르게 혁신하고, 시장 변화에 더 잘 적응하고, 좀 더 효율적으로 비즈니스 성과를 창출할 수 있다. 예를 들어 MSA와 CI/CD를 사용하면 팀에서 서비스를 주도적으로 운영하여 업데이트를 좀 더 빠르게 릴리스 할 수 있다.

Rapid Delivery (신속한 전달)

DevOps는 릴리스의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 개선할 수 있다. 새로운 기능의 릴리스와 버그 수정 속도가 빨라질수록 비즈니스(User)의 요구에 더 빠르게 대응하여 경쟁 우위를 강화할 수 있다. 이 과정에서 CI(Continuous Integration) / CD(Continuous Delivery)를 사용할 수 있는데 이는 빌드에서 배포까지 소프트웨어 릴리스 프로세스를 자동화하는 방식입니다.

Reliability (안전성)

DevOps는 최종 사용자에게 지속적으로 긍정적인 경험을 제공하는 한편 더욱 빠르게 안정적으로 제공할 수 있도록 어플리케이션 업데이트와 인프라 변경의 품질을 보장한다. CI/CD와 같은 방식을 사용하여 각 변경 사항이 제대로 작동하며 안전한지 테스트하고, Monitoring과 Logging방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있다.

Scale (확장)

DevOps는 개발자가 규모에 따라 인프라와 개발 프로세스를 운영 및 관리한다. 자동화와 일관성이 지원되므로 위험을 줄이면서 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있다. 예를 들어 Iac(Infrastructure as Code)를 사용하면 개발, 테스트 및 프로덕션 환경을 반복 가능하고 더 효율적인 방식으로 관리할 수 있다.

Improved Collaboration (협업 향상)

주인의식 및 책임과 같은 가치를 강조하는 DevOps 모델에서는 Product/Service 개발에 좀 더 효과적인 팀을 구축한다. 개발자와 운영팀은 긴밀하게 협업하고, 많은 책임을 공유하며, 워크플로를 결합한다. 이를 통해 비효율성을 줄이고 시간을 절약하고 소프트웨어의 품질을 높일 수 있다.

Security (보안)

DevOps는 제어를 유지하고 준수하면서 신속하게 개발을 진행할 수 있다. 자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술을 사용함으로써 보안을 그대로 유지하면서 DevOps 모델을 도입할 수 있다. 예를 들어 Iac와 코드형 정책을 사용하면 규모에 따라 규정 준수를 정의하고 추적할 수 있다.

5. DevOps의 특징은 무엇인가?

DevOps에는 아주 다양한 특징들이 있지만, 몇 가지만 정리해보도록 하겠다.

Product-Based Teams Over Component Teams (Product 기반 팀 구조)

DevOps는 기존의 Dev, QA, Ops 등으로 이루어진 Component 기반의 팀 대신에, Product/Service 기반의 팀 구조를 사용한다. Product/Service 기반의 팀 구조를 도입하게 된다면 개발과 운영 사이의 사일로를 제거할 수 있어 DevOps를 성공적으로 도입할 수 있는 확률이 높아진다.

Automating repetitive tasks (반복적인 작업의 자동화)

모든 수작업은 자동화된 작업에 비해 위험이 증가되기 때문에, DevOps 팀은 자동화에 집착해야 한다. 이러한 자동화 작업 툴들은 주로 운영 업무에서 많이 쓰이는데, 일반적으로 우리가 CI(Continuous Integration)이나 CD(Continuous Delivery)등을 이용해 다루는 빌드, 배포, 테스트 자동화들이 이에 속한다. 반복적인 작업의 자동화를 통해서 개발 자원들의 작업 효율을 높이고 빠른 서비스 업데이트를 가능하게 하며, 자동화 시스템 구축을 통해서 전체 시스템에 대한 이해도를 높일 수 있게 한다.

Widely Shared Metrics (전체에 공유되어지는 지표)

DevOps는 팀 전체가 기준으로 삼을 수 있는 서비스에 대한 공통적인 지표(Metric)가 필요하다. 서비스를 개발하고 개선했을 때, 이를 평가하고 현재의 서비스의 진행 상태 (성공 여부, 시스템의 안정성, 사용자의 반응 등)를 인지할 수 있는 기준이 필요하다는 것이다. 또한 이러한 데이터를 기반으로 하는 의사 결정은 DevOps 조직의 주요 측면 중 하나이다.

Teamwork Over Individual Work (개인적인 업무 보다는 팀워크)

DevOps 팀은 높은 수준의 전문성과 엔지니어링을 필요로 한다. 전문성은 올바른 일을 할 수 있는 능력, “아니오”라고 말할 수 있는 용기, 기꺼이 도움을 요청하고, 정중하게 동의하지 않으며, 서로 개방적이고 정직한 협업을 할 수 있는 능력을 반영한다. 팀 내의 구성원들이 동의하지 않거나 논쟁하거나 비판할 때 서로를 무시해서는 안되고 사람이 아니라 아이디어에 동의하지 않아야 한다.

Fail Fast Over Delayed Learning (빠른 실패를 통한 학습)

성숙한 DevOps 팀은 실수로부터 배우기 위해 post mortems을 수행하고 관련된 자료들은 조직 전체에 공유되어진다. 여기에는 효과적인 피드백 루프와 높은 수준의 자동화를 필요로 한다. 이 외에도 성숙한 DevOps 팀은 서로를 신뢰하고 서로 도전하며 지속적인 개선을 추구하는 문화를 가지고 있다. 실수가 빨리 공유되어지고 이를 철저히 분석함으로써 조직은 한 걸음 더 성장할 수 있는 기회를 빨리 접한다.

6. DevOps ToolChain

DevOps ToolChain이란 DevOps를 적용하기 위해 도와주는 특정한 툴들의 조합이다.

DevOps는 기술 보다는 관행에 가깝기 때문에 소프트웨어 개발의 모든 단계를 정의할 수 있는 단일 도구는 없어 DevOps의 적용을 도와주는 Tool들의 집합인 ToolChain이 형성되었다.

ToolChain을 적절히 활용하면 DevOps의 목적인 비즈니스(User)의 요구사항을 단기간에 반영할 수 있는 품질 높은 소프트웨어를 만들 수 있는 확률이 높아진다. ToolChain에 속해있는 Tool들을 DevOps를 이루기 위한 Best Practice라고 보아도 좋지만 이를 사용한다고 해서 DevOps가 도입되는 것은 아니라고 생각한다. 즉, ToolChain을 사용하여 빠른 배포, 코드의 품질 향상 등의 목적을 이룰 수 있지만 이들을 도입한다고 해서 무조건적으로 이루어지는 것은 아니기 때문에 팀 내에서 DevOps를 이루기 위한 노력을 꾸준히 해야된다.

일반적으로 Toolchain이란 tool들이 연속적으로 실행되고 각각의 tool에 대한 결과 또는 출력이 다음 tool에 대한 시작 환경 또는 입력이 되는 것을 의미하지만, 요즘 toolchain은 연속으로 실행되지 않는 관련있는 툴들의 집합을 언급할 때도 사용된다.

DevOps를 위한 핵심 카테고리들에 대해서 알아보고 관련된 특정 tool에 대해서도 알아보자.

표현 방식

Category

Specific Tool Involved

Planning (기획)
- GitLab
- Tasktop
- CollabNet’s VersionOne
- Trello
- Azure Boards
Issue Tracking (이슈 추적)
- Atlassian’s Jira
- JetBrains’ YouTrack
- Zendesk
Source Control (소스 코드 관리)
- Git
- GitHub
- GitLab
- Bitbucket
- Subversion
Build Tools (빌드 도구)
- Maven / gradle
- MSBuild
- Rake
- JFrog Artifactory
- NuGet
Tesing Tools (테스팅 도구)
- JUnit
- xUnit.net
- Selenium
- Jasmine
- Cucumber
Continuous Integration (지속적인 통합)
- Jenkins
- Travis CI
- Circle CI
- AWS CodePipeline
- Concourse
Continuous Deployment(Delivery) (지속적인 전달(배포))
- Spinnaker
- Octopus Deploy
- AWS CodeDeploy
Configuration-Management Tools (설정 관리 도구)
- Terraform
- BOSH
- Chef
- Ansible
- Puppet
Cloud Playform (클라우드 플랫폼)
- Amazon Web Service(AWS)
- Microsoft Azure
- Google Cloud Platform
- Container Schedulers(k8s, Docker Swarm, …)
- Heroku
Monitoring and Logging Tools (모니터링 및 로깅 도구)
- ELK Stack
- Pinpoint
- Zipkin
- New Relic
- Prometheus
Communication Tools (의사소통 도구)
- Slack
- Microsoft Teams
- Google Hangouts
- Zoom
Knowledge Sharing Tools (지식 공유 도구)
- GitHub Pages
- Confluence
- Jekyll
- Google Sites

위의 다양한 카테고리들은 DevOps를 수행하는데 전반적으로 도움이되는 카테고리들이다. DevOps ToolChain은 팀에서 지속 가능한 방식으로 고객에게 지속적으로 가치를 제공하고 차별화를 지원하는 위치에서 사용되어져야 한다고 생각한다.

DevOps ToolChain은 DevOps를 이루기 위한 Best Practice이지만, 이는 DevOps의 목적을 이루기 위한 하나의 수단일 뿐이지 유일한 수단이 아니라는 점을 다시 한번 강조하며 이번 포스팅을 마치도록 하겠다.

다음에는 DevOps를 이루기 위한 중요한 부분인 CI/CD 시리즈로 찾아뵙도록 하겠습니다. 꾸벅~

참고