DevOps
DevOps란?
회사에선 프로젝트를 가지고 온다. 개발자는 코드를 짠다. 그리고 애플리케이션이 생성되어 고객에게 전달된다.
...라는 간단한 흐름으로 개발이 진행되지는 않는다.
개발자는 개발만 진행하는 것이 아닌 외적인 일에도 많은 시간을 할당한다.
기능들에 대해 테스트도 진행해봐야 하고 고객에게 전달할 수 있도록 프로젝트를 Build도 해야 하며 운영 서버에서도 제대로 애플리케이션이 작동하는지 검수해야 하며 이를 위해 Build 한 프로젝트를 서버에 배포도 해야 한다.
운영 서버에서 애플리케이션이 수행될 수 있도록 DB를 세팅하고 Server에 대한 설정도 수행해야 하며 HW에 대한 관리도 필요할 것이다. 또한 운영 과정에서 생기는 문제점이나 생길 수 있는 문제점을 확인하기 위해 모니터링 과정도 수행해야 한다.
회사는 개발자가 모든 일을 처리하기에는 무리가 있다고 생각하여 보통 "운영(Ops)" 조직과 "개발(Dev)"조직으로 나누어 관리하는 경우가 많다.
하지만 이렇게 운영 팀과 개발 팀으로 나뉘어 프로젝트가 수행될 경우 많은 부작용을 가지고 온다.
이런 부작용을 해결하기 위해 나온 방법론이 DevOps이다.
많은 기업에서 DevOps 직군을 모집하는 것을 봤을텐데, 사실 DevOps는 신규 기술이나 직군이라기보다는 신규 Framework, 혹은 방법론에 가깝다.
DevOps는 개발과 운영을 잘 융합하여 한 팀에서 운영과 개발을 동시에 수행할 수 있도록 하는 SW 개발 방법론이다.
DevOps는 운영과 개발 과정을 합치고 간단화 시켜 조금 더 빠르고 품질 좋은 개발을 수행하며 운영되고 있는 SW의 관리를 쉽게 하는 것을 목표로 한다.
DevOps의 목적을 달성하기 위해 여러 가지 툴(Jenkins, Docker, Cloud 등)을 활용할 수 있는데 이러한 기술들을 활용한다고 무조건 DevOps 개발 방법이라고 말할 수 없다.
DevOps는 어디까지나 "방법론", 즉 철학에 가깝기 때문에 현재 상황에서 가장 적절한 툴을 활용해서 DevOps의 목적을 달성할 수 있다면 오래된 툴을 활용한다 하더라도 훌륭하게 DevOps 개발을 수행했다고 말할 수 있을 것이다.
즉, DevOps란 "개발자가 직접 User와 끊임없이 상호작용하며 개발부터 운영까지 모든 것을 담당해 품질 높은 SW를 만들기 위한 개발 방법론"이라고 정리할 수 있는 것이다.
그림으로 보는 DevOps
DevOps에 대해 꽤 재밌는 그림이 있길래 가지고 왔다.
DevOps와 과정에서 활용하는 툴을 가장 깔끔히 정리한 그림이 아닐까 싶다.
DevOps는 사실상 개발의 끝이 존재하지 않는다. 개발한 Application의 배포가 끝나 운영 단계에 들어갔다 하더라도 계속해서 User의 피드백을 받아 수정 사항 및 새로운 기술을 개발해야 하기 때문이다.
따라서 위 그림같이 뫼비우스 띠처럼 끝나지 않는 개발이라고 표현하는 것이 적절할 것 같다.
먼저 뫼비우스 띄 안의 글씨를 보자.
Real-Time Communication 단계에서는 고객의 지속적인 피드백을 받고 이를 통해 피드백을 처리하기 위한 개발 계획을 짠다. 이후 개발을 진행하고 이를 Build한다.
이렇게 Build한 SW에 대하여 CI/CD 과정을 통해 테스트하고 운영 서버에 배포하게 되는 것이다.
이 과정에서 수많은 기술들이 활용되는데 이런 기술들은 Cloud Native Architecture를 설명할 때 더욱 자세히 다루도록 하겠다.
개발팀과 운영팀 분리로 인해 발생하는 문제점
DevOps 개발 방법론을 적용하기 이전에는 개발팀과 운영팀이 따로 운영되었다. 그렇다면 이렇게 따로 운영되는 개발팀과 운영팀은 어떤 문제점을 가지고 왔을까?
User와의 접점 빈도 차이에서 발생하는 문제점
개발팀은 SW에 대한 개발을 진행하기 때문에 User와의 접점이 많이 존재하지는 않지만 운영팀은 개발된 SW를 실제 활용하는 서버에 배포하고 유지보수(관리)하는 역할을 담당하기 때문에 User와의 접점이 많다고 볼 수 있다.
그리고 이런 User와의 접점 빈도에 대한 차이는 생각보다 많은 문제점을 가지고 온다.
먼저 변경사항에 대한 갈등이 발생한다.
최근 시장의 Trend 변화는 매우 빠른 편이며, SW는 이에 적응하기 위하여 잦은 변경 사항을 가지게 된다.
그리고 이 변경 사항은 개발팀이 아닌 운영팀에 요청이 들어가게 되며 운영팀은 고객으로부터 변경사항 요청을 받아 개발팀에 전달하게 된다. 개발팀 입장에서는 자신의 업무를 추가할 권한이 없는 운영팀에서 업무를 추가시킨다는 불만감을 가지게 될 것이다. 하지만 운영팀 입장에서도 계속 접점을 가지는 고객으로부터 요청이 들어와 전달한 것밖에 없기 때문에 개발팀의 불만은 머리로는 이해가 가더라도 심정적으로까지 이해하기는 쉽지 않다.
여기에서 두 번째로 애플리케이션 안정성에 대한 문제점이 생긴다.
결국 개발팀은 추가적인 요구사항을 처리할텐데 이 과정에서 시간이 부족한 경우 제대로 된 테스트 기간을 갖지 못하는 경우도 존재하게 된다. 결국 개발팀 입장에서는 불안정한 SW를 운영팀 측에 전달할 것이다.
운영팀 입장에서 SW를 배포하는 것이 쉬운 일은 아니기 때문에 SW가 정상 작동할 때 까지 반복해서 애플리케이션을 배포하는 데에는 무리가 존재한다. 또한 문제가 생길 경우 고객으로부터 직접 컴플레인을 받는 팀이기 때문에 최대한 안정적인 SW를 배포하고 싶을 것이다.
즉, 운영팀 입장에서는 잦은 배포에 대한 난이도와 고객으로부터의 컴플레인에 대한 부담감 때문에 안정적인 SW를 받길 원할 것이다. 하지만 개발팀에서 준 불안정한 SW는 이런 기대감을 깨버릴 것이며, 운영팀은 어떻게 해서든 이 불안정한 SW를 수정하여 운영 서버에 적용시켜야 하기 때문에 개발팀의 들러리라는 느낌을 받을 수도 있을 것이다.
마지막으로 새로운 기술 도입에 대한 생각의 차이이다.
개발자는 새로운 기술을 도입하여 혁신적인 프로젝트를 진행하기 원할 것이다. 하지만 운영팀 입장에서 새로운 기술을 활용하다가 에러가 발생하거나 문제가 생길 경우 고객으로부터 컴플레인을 받는 것은 자신들이기 때문에 새로운 기술 도입에 보수적일 수밖에 없다. 즉, 운영팀은 조금 오래된 기술이라도 안정감 있는 기술 사용을 원하는 것이다.
배경지식 차이에 의해 발생하는 의사소통의 불편함
개발팀과 운영팀은 협업해야 하는 팀들이기에 적극적인 의사소통을 통해 정보를 공유해야 한다. 문제는 운영팀과 개발팀의 전문 분야가 다르다는 점이 의사소통을 어렵게 한다는 점이다.
운영팀은 Software의 배포와 운영에 큰 관심을 두기 때문에 "Server, OS, DB" 같은 인프라에 대한 배경지식이 풍부할 것이다. 하지만 개발팀 입장에서는 이미 로컬 컴퓨터에 구축된 인프라에서 애플리케이션을 개발하면 되기 떄문에 인프라 지식에 대한 필요성이 적다.
반대로 애플리케이션 자체에 대해서는 개발팀 입장에서는 직접 구현해야 하는 SW이므로 많은 배경지식을 가지고 있지만 운영팀은 개발팀에서 전달받은 Application을 배포만 하면 되기 때문에 Application 자체에 대해 알아야 할 필요성은 낮다
이처럼 두 팀이 가지고 있는 배경지식에 차이가 존재하고, 이러한 배경지식의 차이는 의사소통의 어려움 혹은 소통의 단절을 가지고 올 것이다.
Fingerpointyness
마지막으로 Fingerpointyness라는 문제이다.
위에서 말했듯 개발팀은 "인프라"에 대한 지식이 적으며 운영팀은 "애플리케이션" 자체에 대한 지식이 적다.
이렇다 보니 만약 문제가 발생했을 경우 서로 자기 분야의 문제가 아니라며 다른 팀에게 책임을 미루면서 문제 해결이 지연될 수 있다. 이런 서로 책임을 떠넘기며 문제 해결이 지연되는 현상을 Fingerpointyness라고 한다.
Fingerpointyness는 문제가 발생했을 경우 누가 이를 해결해야 하는지 정해지지 않는 상황에서 문제와 연관된 팀들끼리 문제 발생 이유를 다른 팀에게 떠넘기며 문제 해결 과정이 엉뚱한 방향으로 가는 현상을 말한다.
그렇다면 Fingerpointyness의 각 단계를 알아보자.
1. Freaking out & Finding Fault
문제가 발생했을 경우 문제의 내용을 먼저 파악하는 과정이다.
이 때 다른 팀과의 협업 없이 각 팀마다 문제를 파악하게 되고, 각 팀이 가진 배경 지식의 차이가 있기 때문에 팀끼리 생각하는 문제의 원인이 다를 있다.
또한 문제를 파악하는 주체도 정해져있지 않기 때문에 다른 팀이 문제를 처리할 것이라며 문제 파악 자체가 늦어질 수도 있다.
2. Blaming Covering ass
1번 과정을 통해 만약 문제의 원인이 어느 정도 파악되었다고 가정하자.
그렇지만 이 경우 다른팀과 협업을 한 것도 아니며 자신들의 한정된 지식으로 파악한 문제이기 때문에 정확한 원인이 아닐 수도 있다.
그나마 팀들이 생각한 문제의 원인이 같을 경우 손쉽게 처리되겠으나 만약 서로가 생각하는 문제의 원인이 다르다면, 심지어 다른 팀에서 관리하는 문제라고 생각하면 정확한 문제 파악을 하려 하기보다는 다른 팀으로 미루기를 시작한다.
그리고 이 과정에서 시간은 계속 간다.
3. Whining, Hiding, Hurt Ego
서로 문제를 떠넘기는 과정에서 상대방을 헐뜯거나 일부 사실을 숨기면서 결국은 서로 상처를 입게 되고 이는 단절된 의사소통과 악화되어 가는 팀간의 관계라는 결과를 가지고 온다.
4. Figuring it out & Fixing things
결국 문제를 해결은 해야하니 어떻게든 문제를 해결하긴 할 것이다.
이 과정에서 3번 과정을 통해 관계가 악화된 팀들끼리 모여 원인 분석을 하고, 결국 문제의 원인을 찾아 해결할 수 있을 것이다.
이 과정에서 남은 것은 관계가 악화된 팀, 문제가 빨리 해결되지 않아 불평을 갖는 User만이 있을 뿐이다.
DevOps의 발전 이유
위와 같은 문제점의 해결 방법은 매우 간단하다.
그냥 개발과 운영을 1팀에서 처리하면 되는 것이다. 실제로 DevOps가 유행하기 이전에는 위와 같은 문제점을 발생시키지 않기 위해서 개발팀이나 운영팀 자체가 상대방의 분야를 볼 수 있는 능력을 갖춰 문제를 해결하는 경우도 많았다.
하지만 운영과 개발 모든 것에 대해 아는, 흔히 말하는 "풀 스택"이라는 것이 절대로 쉽지만은 않다. 그리고 이 어려운 과정을 쉽게 수행하기 위하여 만들어진 것이 바로 DevOps 방법론이다.
그렇다면 왜 최근에서 이 DevOps가 발전할 수 있었을까?
Open Source의 발전
인터넷이 발전하면서 생긴 IT 흐름에 가장 큰 변화 중 하나는 Oracle, IBM 같은 대기업이 흐름을 주도하지 않고 구글, 페이스북 같은 B2C 서비스가 흐름을 주도하고 있다는 점이다.
그리고 이 B2C 업체는 Open Source를 적극적으로 후원 및 장려하는데, B2C이다보니 이전과는 달리 전 세계의 뛰어난 개발자들의 머리가 모여 집단 지성의 힘이 발휘되어 더욱 성능 높은 Open Source들이 개발 및 공유되었다.
오픈 소스가 발전하면서 협업 툴이나 CI/CD 툴들도 큰 발전을 이루었다. 특히 빌드, 배포, CI/CD와 모니터링에 대한 툴이 많아졌기 때문에 운영 팀이 했던 업무의 상당수가 자동화 가능해졌으며 원래 운영을 위해 필요했던 인프라 배경지식만큼 가지고 있지 않아도 어느 정도의 운영이 가능해진 것이다.
Cloud의 등장
클라우드 컴퓨팅의 가장 큰 특징 중 하나는 사용자가 인프라를 구축할 필요가 없다는 점이다.
원래라면 서버를 위한 컴퓨터를 사서 OS를 설치하고 애플리케이션에 맞는 서버 구축을 수행해야 했지만 현재는 AWS 같은 클라우드 서버에 대한 설정 방법만 알면 바로 사용할 수 있다.
즉, 개발자는 운영을 위해 HW나 서버 설정에 대한 배경지식을 과거 운영팀만큼 알지 않아도 Cloud를 활용하여 간단히 서버를 설정하고 활용할 수 있게 되는 것이다.
즉, 인프라에 대한 전문 지식이 없더라도 클라우드의 도움을 받아 HW 및 서버를 설정하고 모르는 부분은 인터넷을 통해 검색하며 Open Source를 활용함으로써 쉽게 운영을 수행할 수 있는 환경이 마련된 것이다.
DevOps 특징
Cross Functional Team
1개의 팀에서 모든 것을 다 할 수 있는 사람을 뽑는 것이 아닌 프로세스 담당자들을 모아 1개의 팀으로 모으라는 의미이다.
말이 좀 어려운데, 그냥 1개의 팀에서 개발부터 배포까지 모든 것을 수행할 수 있도록 만들라는 의미이다
과거에는 1개 프로젝트의 단계별로 팀을 구성하였다. 개발팀(Dev), 품질팀(QA), 운영팀(Ops) 등으로 나뉘어 이 팀들이 협업을 통해 애플리케이션을 개발하는 이른바 "Component 기반의 팀"을 구성하였다.
하지만 DevOps는 1개의 팀에서 모든 프로젝트 단계를 수행하는 이른바 Product 기반의 팀으로 구성하기 때문에 팀 내의 협업과 의사소통을 통해 애플리케이션을 개발한다.
1개의 팀에서 모든 개발 과정이 수행되므로 의사소통이 원활해지고 빠른 피드백 반영이 가능해졌다는 장점이 존재한다.
Widely Shared Metrics
팀원 모두가 알고 있는 공통적인 지표가 필요하다는 것이다.
DevOps에서는 1개의 팀에서 Product 개발에 대해 담당한다. 즉, 팀원들 모두가 서비스가 개선되었다는 점을 인지할 수 있는 공통된 지표가 필요해졌다.
기존 개발에서는 애플리케이션을 개발하고 운영으로 전달만 하면 됐기 때문에 사용자들의 SW에 대한 만족도에 대한 피드백이 개발팀까지 직접 전달되기 어려웠다. 하지만 DevOps에서는 1개의 팀에서 모든 개발 과정이 수행되며 자연스럽게 운영에서 발생한 SW에 대한 만족도 피드백이 직접 DevOps 팀에 들어오게 된다.
따라서 DevOps에서는 사용자의 만족도를 파악하기 위한 공통된 Metric이 필요하며 DevOps팀은 이런 공통된 지표를 통해 팀 전체가 고객이 느끼는 SW 만족도나 성능을 주기적으로 파악하여 개선이 필요한 부분이나 개선 여부 등을 파악할 필요성이 생겼다.
Automating repetitive tasks
반복적인 일을 자동화하라는 것이다. 개인적으로는 DevOps를 도입할 때 가장 중요한 점이 아닐까 싶다.
DevOps에서는 원래라면 여러 개의 팀에서 진행되어야 했던 프로젝트 업무를 오로지 1개의 팀에서 모두 수행해야 한다.
아마존의 CEO 제프 베조스가 말한 "피자 두 판의 법칙"을 고려해보자면 DevOps로 개발 방법을 바꿨다고 팀에 속한 인원을 늘리는 것은 그렇게 추천할만한 일은 아니다.
인원을 늘릴 수 없다면 결국 업무를 줄이는 수밖에 없으며, 업무를 줄이기 위한 가장 간단한 방법은 "반복 작업의 최소화"이다.
반복적인 작업에 투입되는 시간을 줄임으로써 우수한 개발 자원의 낭비를 줄일 수 있고 일의 효율을 증가시킬 수 있다.
반복적인 작업이 줄어든 시간 만큼 애플리케이션 서비스에 대한 Update는 빨라질 것이며, 이는 User의 요구사항을 조금 더 빠르게 처리할 수 있다는 장점을 가지고 온다.
또한 반복적인 작업은 Human Error가 발생할 확률이 가장 높은 작업인데 자동화를 통해 Human Error를 줄일 수 있다는 장점을 가져오며 자동화 시스템을 구축하면서 전체 시스템에 대한 이해도를 높일 수도 있다는 부가적 장점 또한 가지게 된다.
Regular Release
짧은 주기로 정기 배포를 진행해 빠르게 서비스 기능을 개선하고 고객들의 VoC(Voice of Customer;고객 요구사항)를 반영해 나가는 것이다.
System Release는 매우 많은 협업이 필요하다.
일단 개발이 끝나야하고, 릴리즈에 대한 테스트 및 배포 과정을 거쳐 고객에게 전달된 이후 다음 Release를 위한 요구사항 파악 및 기능 정의 과정을 거쳐 다시 개발팀에게 요구사항으로 들어가야 한다.
기존 개발과정에서는 이런 System Release 단계를 수행하는 팀이 모두 다른 팀이었기에 외부 팀에게 결과물을 전달해야 했으며 결과물을 만든 사람과 결과물을 받는 사람이 다른 팀이기에 의사소통이 원활하지 못했고, 이에 따라 릴리즈 흐름이 매끄럽지 못하다는 단점을 가지고 왔다.
하지만 DevOps는 1개 팀에서 System Relase의 모든 단계가 이뤄지기 때문에 릴리즈의 흐름이 자연스러워졌으며, 이는 언제 어떤 방식으로 어떻게 협업을 진행해야 하는지 명확해져 정기적인 Release를 가능하게 만들었다.
이런 정규적인 Release는 고객의 만족도를 높이며 개발의 협업 난이도를 감소시키는 장점을 가지고 왔다.
Fail Fast Over Delayed Learning(빠른 실패를 통한 학습)
DevOps는 Agile 방식과 동일하게 많이 시도하며 실패를 통해 학습하는 개발 방식을 가진다.
여기에서 Agile 방식보다 더욱 발전된 점은 DevOps팀은 Agile 방식과 다르게 1개의 팀에서 모든 개발 과정이 이뤄지기 때문에 실패에 대한 피드백이 더욱 쉽다는 것이다.
DevOps에서는 장애나 이슈가 발생했을 경우 이를 즉시 팀원들에게 공유해야 한다.이를 "Post Moreterms(후처리)" 과정이라고 말한다.
이 후처리 과정은 2가지의 큰 장점을 가진다.
먼저 심각한 문제에 대한 사전 예방이다.
DevOps에서는 1개의 팀에서 모든 개발을 수행하는데, 이는 다른 말로 1개의 팀에 각 분야의 전문가가 존재한다는 의미와 동일하다. 즉 팀원들은 서로 다른 배경지식을 가지고 있어 문제의 궁극적인 원인을 파악할 확률이 높아진다.
기존 개발 방법에서는 작은 문제가 생겼을 때 이를 인지한 팀이 대수롭지 않을 것이라 넘겼던 문제가 커질 가능성이 존재했다. 하지만 DevOps에서는 문제가 크든 작든 Post Moreterms를 통해 문제를 공유하기 때문에 각 분야의 전문가가 에러 상황을 공유할 수 있으며 이는 발생한 에러가 더욱 심각한 문제로 발전하기 이전 사전에 문제를 차단할 수 있다는 장점을 가지고 온다.
예를 들어 운영 팀에서 비정상적인 경로로 권한이 없는 기능을 수행할 수 있음을 발견했는데, 그렇게 중요한 기능이 아니라 천천히 처리해도 되겠다는 생각으로 넘어갔다고 가정하자. 그런데 알고 보니 이 기능이 개인정보 관리 기능과 연동되어 있어 개인정보 보호법 위반으로 처벌받을 수 있는 문제였을 경우 사태가 심각해질 것이다. 하지만 DevOps에서는 이 문제를 즉시 팀 내에 전달할 수 있으므로 빠르게 보안팀이 해당 문제를 인지해 개인정보 보호에 대한 문제가 발생할 수 있음을 알리고 사태가 커지기 전 빠른 대응이 가능해질 것이다.
두 번째로 빠른 문제 해결이다.
이전에 발생했었던 문제였다면 과거에 해결했던 방법대로 빠르게 문제 해결을 수행할 수 있을 것이다. 만약 처음 발생하는 에러일 경우 팀의 모든 인원이 문제를 인지하고 이 문제를 각 분야의 전문가들이 철저히 분석하여 해결하기 떄문에 조직 모두가 성장 가능하며 동시에 다시는 같은 이슈가 발생하지 않게 만들어 SW의 안정성을 가지고 올 수도 있다.
위 장점은 하나의 부가적인 장점을 가지고 오는데, 바로 신기술의 도입에 대한 장벽이 낮아지는 것이다.
DevOps 팀이 새로운 기술을 적용하다 에러가 발생했을 경우 이 내용을 빠르게 공유해서 해결할 수 있기 때문에 신기술 적용에 대한 부담감이 없어지며 신기술에 대한 이해도가 생겨 팀 전체의 수준이 한 단계 높아지는 부가적 장점을 가지고 오기도 한다.
