#softwareengineering > [!abstract] Introduction > 데브옵스*DevOps*라는 단어를 한번쯤은 들어봤을 겁니다. 그러나 그게 구체적으로 무엇을 의미하는지 한눈에 이해하기에는 조금 어려운 부분도 있습니다. 이번 글에서는 개발과 운영의 조화이자 자동화에 대한 절차이자 철학, 그리고 방법론인 데브옵스에 대해 알아봅니다. # Dev vs Ops ## Dev와 Ops 소프트웨어 기업 안에서도 소프트웨어를 만드는 것은 바로 개발팀*Development Team*, 즉 Dev다. 새로운 기능을 구현하거나 버그를 고쳐야 할 경우, 이들이 최전선에 나서 문제를 해결한다. 문제를 해결하는 과정에서 이들은 코드를 작성하고, 이를 개발 환경에 배포한 뒤 테스트한다. 이렇게 테스트를 마치고 나면 코드는 테스팅 팀에 의해 검증되는 QA*Quality Assurance* 환경에 배포된다. 이후 프로덕션 환경으로 배포하기 위해 코드가 IT 운영팀으로 넘어가며 이때부터 IT 운영팀은 코드의 관리와 유지 및 보수를 담당한다. 이 IT 운영팀*IT Operations*이 바로 데브옵스의 '옵스*Ops*'를 담당한다. 이렇게만 보면 기존의 방식으로도 문제없이 일이 잘 흘러갔던 것처럼 보이지만, 이러한 기업들은 대부분 시장의 변화에 제대로 대처하지 못했다. 시장에서 경쟁 우위를 점하기 위해서는 제품을 빠르게 출시하고 높은 서비스 수준을 유지하는 동시에 끊임없는 실험이 필요하다. 이러한 이유로 배포에 오랜 시간을 허용하는 기업은 경쟁에서 불리할 수밖에 없으나 대부분의 기업은 수백, 수천 개의 변경사항을 프로덕션 환경에 매일 배포하는 것은 고사하고 월 또는 분기별로 배포하는 것도 버거워한다. 프로덕션 환경에 배포하는 것은 일상 업무가 아니기에 서비스 중단, 만성적 긴급 작업 그리고 결단이 필요하다. 상황이 이렇게 된 원인은 개발과 운영 사이에 악순환을 일으키는 갈등, 그리고 그로 인해 지속적으로 증가하는 기술 부채*Technical Debt*다. # IT 조직의 두가지 목표 ## 기술 부채 조직이 개발 과정에서 내리는 선택은 미래에 조직이 선택할 수 있는 영역을 축소시키고, 시간이 지날수록 문제를 해결하기 어렵도록 만든다. 아무리 신중히 고려해도 개발 과정에서 내리는 선택의 대가를 지불해야 하며, 이러한 의미에서 기술 부채는 늘어날수록 조직에 불리하다. 이러한 기술 부채를 심화시키는 원인 중 하나가 바로 개발과 운영 부서 간의 경쟁이다. 기본적으로 IT 조직은 빠르게 변화하는 경쟁 환경에 대응하는 동시에 고객에게 안정적이고 신뢰할 수 있는 서비스를 제공해야 하는 딜레마를 마주하게 된다. 개발팀는 빈번한 시장 변화에 대응하고 기능과 변경 사항을 최대한 빠르게 프로덕션 환경으로 배포할 책임이 있고 IT 운영팀은 고객에게 안정적이고 신뢰할 수 있는 서비스를 제공할 책임이 있다. 그러나 이렇게 구성된 개발팀과 IT 운영팀의 목표와 인센티브는 서로 정반대다. 운영팀은 프로덕션 환경에 악영향을 미치는 변경사항을 도입하기가 어렵거나 불가능하고, IT팀도 개발 환경에 악영향을 미치는 변경사항을 도입하기가 어렵거나 불가능하다. 문제는 두 부서가 각자의 부서를 위해 최선을 다하는 것이 전체 조직의 목표 달성에 방해가 된다는 것이다. ## 악순환의 3단계 IT 분야의 악순환은 크게 세 가지 단계로 이루어져 있다. 1단계는 IT 운영에서 시작한다. IT 운영의 목표는 기업이 고객에게 가치를 제공할 수 있게 애플리케이션과 인프라를 운영하고 유지하는 것이다. 일상 업무에서 나타나는 많은 문제는 복잡하고 문서화가 잘 되어있지 않은 취약한 애플리케이션과 인프라로 인해 생기며, 이것이 바로 기업을 괴롭혀온 기술 부채의 정체다. 문제는 이렇게 오류가 발생하기 쉬운 시스템이 가장 중요한 수익 창출 시스템이나 가장 결정적인 프로젝트를 지원한다는 것이다. 그래서 애플리케이션과 인프라를 바꾸지 못하면 고객의 가용, 목표 수익, 보안, 정확한 재무 보고와 같은 기업의 가장 중요한 약속이 흔들린다. 2단계는 이렇게 약속이 위반되면 누군가 그 보상을 해줘야 한다는 상황에서 시작된다. 기술 기업이 무엇을 할 수 있고 무엇을 할 수 없는지, 혹은 무슨 이유로 초기의 약속을 지키지 못했는지 파악하지 못하면 기술 기업은 지키지 못할 약속까지도 허용하게 된다. 결과적으로 개발팀은 또 다른 긴급 프로젝트를 맡게 되고 새로운 문제를 해결해야 한다. 그리고 어쩔 수 없이 약속된 출시 일정을 맞추기 위해 절차나 원칙을 생략하고, 이때 발생한 문제는 시간이 조금 더 있을 때 수정하겠다는 약속과 함께 기술 부채가 된다. 3단계가 되면 모두가 바빠지고 작업 시간이 길어진다. 의사소통의 속도가 느려지고 해야 할 일이 쌓이기 시작한다. 업무와 업무가 점점 더 강하게 묶이기 시작하며 같은 실수여도 더 큰 실패를 초래하게 된다. 결국 모두가 변화를 만드는 것을 더 두려워하게 되며 기업의 생산성은 점점 더 줄어든다. 팀은 종속된 작업이 완료될 때까지 더 오래 기다려야 하며 품질은 계속 낮아진다. 이러한 악순환은 그 순간에는 잘 보이지 않지만 프로덕션 배포 시간이 몇 분에서 몇 시간으로, 몇 시간에서 며칠로, 며칠에서 몇 주로 계속 늘어난다. 심지어 배포된 결과물에도 문제가 많아져 고객에게 영향을 미치는 서비스 중단 횟수가 점점 더 증가한다. 운영팀은 이를 해결하기 위해 더 많은 인력을 투입해야 하고 더 나아가 기술 부채를 상환할 수 있는 능력을 잃어버리게 된다. ## 보아라......결국......파국이다! 그래서 결과는? 제품의 출시 주기가 점점 더 길어지고 진행하는 프로젝트 수가 줄어들며 팀원들의 사기가 저하된다. 작업에 대한 피드백, 특히 고객의 피드백이 느려지거나 약해지며 변화하는 환경에 빠르게 대응하지도 못하고 고객에게 안정적으로 서비스를 제공하지도 못한다. 그래서 시장에서 패배하게 된다. 이것이 IT에서의 실패가 기업 전체의 실패로 이어지는 과정이다. 모든 IT 조직에는 두 가지의 대립하는 목표가 있고, 알게 모르게 모든 회사는 IT 회사다. 모든 회사의 수익 구조는 IT를 중심으로 이루어져 있고 자본 프로젝트 대다수는 IT에 의존하고 있다. 조직의 내부 변화를 위한 기본적인 기제라 말할 수 있는 그 프로젝트가 말이다. 그렇기에 IT에서의 실패는 기업 전체의 실패가 되고, 기업의 직원들이 무력감을 느낄 만한 시스템을 만들어 버리게 된다. # Dev + Ops = DevOps 이러한 개발팀과 운영팀의 약자가 합쳐진 용어인 데브옵스는 바로 이 악순환의 고리를 끊기 위한 문화이자 방향성, 혹은 일종의 운동*movement*이다. 데브옵스는 도구나 기술이 아니라 더 나은 것을 만들기 위한 방법론이다. 데브옵스의 목표는 개발자로 구성된 소규모 팀이 기능을 독립적으로 구현하고, 프로덕션과 유사한 환경에서 정확성을 검증하며, 코드를 프로덕션 환경으로 빠르고 안전하게 배포하는 것이다. 일상적이며 예측 가능한 코드 배포를 통해 모두가 사무실에 있는 업무 시간 안에, 고객이 눈치채는 일 없이 배포를 진행할 수 있다. 그래서 IT 운영팀이 다른 모든 사람들과 마찬가지로 통상적인 업무 시간에 업무를 수행할 수 있게 된다. 모든 사람이 자신의 행동으로 인한 결과를 빠르게 확인할 수 있으며, 코드와 환경이 의도한 대로 동작하고 항상 안전하고 배포 가능한 상태에 있다는 점이 지속적으로 보장된다. 개발자들은 자신의 실수를 보통 몇 분 안에 발견할 수 있게 되며 이를 통해 문제를 신속하게 해결하고 실질적인 학습도 할 수 있게 된다. 이러한 환경에서는 모든 사람이 자기 자신을 생산적이라고 느낄 수 있고, 기술 부채는 눈에 띄게 줄어든다. 그리고 그 결과 모두가 자신의 업무에 주인 의식을 가지고 조직의 목표에 이바지하고 있다는 자신감을 얻으며 이 자신감은 스트레스가 적은 업무 환경과 시장에서의 성공으로 입증된다. --- # 출처 - Kim, G. _et al._ (2021) _The DevOps handbook: how to create world-class agility, reliability, & security in technology organizations_. Second edition. Portland, OR: IT Revolution Press. - Soni, M. (2016) _DevOps for web development: achieve the continuous integration and continuous delivery of your web applications with ease_. 1st ed. Place of publication not identified: Packt Publishing.