DevOps 란
DevOps 용어의 의미
2009 년, 벨기에의 소프트웨어 개발자인 Patrick Debois 에 의해 생겨난 용어다.
DevOps는 개발(Development)과 운영(Operation)을 합친 단어로, 이 둘 사이의 사일로(분단) 현상을 해결하기 위한 방법론 또는 조직문화에 대한 방향성이다.
DevOps 용어 자체는 직관적이지만, 정확히 DevOps가 무엇이냐는 질문에는 여러가지 정의가 혼용되어 어떤 것이 정확한 정의인지에 대해서는 논쟁이 계속이 이어지고 있다.
우선, 왜 DevOps 가 등장하게 되었는지 알아보자.
DevOps 는 왜 등장하게 되었는가?
기술의 개발과 분업화로 큰 규모의 시스템을 다루는 여러 회사에서는 개발팀과 운영팀을 따로 두고 있다.
운영팀은 일상의 재해(e.g. 정전)에서도 서비스가 중단되지 않도록 장애를 최소화해야 한다. 반대로 개발팀은 고객의 요구에 대해 다양한 최신 기능들을 빠르게 개발해 시스템에 반영해야 한다. 개발자들은 속도에 무게를 두기 때문에 빠르게 새로운 변경점들을 도입하려 한다. 그러나 안정성에 무게를 두는 운영자들은 충분한 테스트나 검증을 거치지 않은 불안정한 프로그램 소스들로부터 시스템을 보호해야 하는 의무가 있다. 이처럼 상이한 목적과 얽혀있는 관계 때문에 일반적으로 둘의 사이는 좋아지기 어렵다.
지금이야 클라우드가 발전해서 웬만한 부분은 개발자들이 직접 배포하고 운영도 할 수 있지만, 시스템이 커지면 여전히 운영팀의 역할이 필요하다. 넷플릭스나 유튜브 같은 무중단 서비스의 경우, 서비스가 유지되는 상태에서 배포를 진행해야 하기 때문에 둘의 커뮤니케이션이 너무나 중요하다.
특히 소프트웨어 회사가 아닌, 소프트웨어가 부서로만 존재하는 회사의 경우 리더나 경영진의 부족한 IT 경험과 지식으로 인해 개발진과 운영진 사이의 갈등이 더욱 심해진다. 심하면 비난문화, 즉 개인이나 조직 수준의 실수에 대해 사람들을 비난하고 헐뜯는 문화가 자리잡기도 한다. 결국 소프트웨어 제품의 출시가 지연되거나 운영되는 서비스가 중단되는 문제를 야기한다.
DevOps 는 무엇이라고 말할 수 있을까?
DevOps 를 폭포수 방법론이나 애자일 방법론처럼 또다른 하나의 개발 방법론으로 보는 것은 옳지 못하다.
DevOps 라는 용어의 창시자이자 devopsdays 의 설립자인 Patrick Debois 는 라디오에서 DevOps를 `협업` 으로 본다고 얘기했으나, 단순히 개발과 운영이 서로 협력하는 것을 넘어서 모든 사일로(분단), 비즈니스의 모든 부분, 나아가 기업 및 조직이 공통의 비즈니스 목표를 달성하기 위해 협력하는 것을 말한다고 했다.
“What is DevOps?” 라는 책에서는 DevOps 환경에서는 운영이 개발의 일부가 된다라고 표현한다. 개발팀에 필요한 운영지식이 코드로써 존재하게 되며, 인프라/시스템 관리자들은 인프라를 유지 관리하는 코드를 작성해 개발자와 협력하게 된다고 말한다.
정리하면,
DevOps는 개발자와 운영자 간의 분단으로 발생하는 문제들을 막고 서로의 입장을 이해하며 소통화는 문화를 말함과 동시에 (사회적 관점)
복잡한 서버 관리와 배포의 잠재적 위험으로 소프트웨어 제품의 출시가 지연되는 문제를 막기 위해 각종 시스템 자동화 관리 툴과 틀라우드 기반 서비스들을 적극적으로 사용하는 것을 의미한다. (기술적 관점)
DevOps 를 그림과 함께 이해해보자
제일 유명한 것은 DevOps toolchain 다이어그램이다. 구글에 DevOps toolchain 이라고 쳐보면, DevOps 의 각 단계 사람들이 많이 사용하는 툴을 예시로 들고 있다.
DevOps 는 실제로 어떻게 적용되고 있을까?
많은 회사들이 DevOps의 중요성에 공감하고 도입을 시도하지만, 정확한 개념이나 방식을 제대로 이해하고 적용하지 못하고 있다. 운영팀의 이름을 DevOps 팀으로 바꾸거나 운영팀과 개발팀 사이에 DevOps 팀을 하나 더 만드는 식의 조치가 난무하고 있다. 사실 DevOps 를 어떻게 적용해야 할지 정확히 파악하기란 어렵다.
다음은 SRE에 대해 알아보자.