DevOps Culture [번역]

이 포스팅은 해당 글을 번역한 글입니다. 스스로 이해될 수 있게 충분히 의역을 하였습니다. DevOps 문화가 어떤 것이고 추구하는 방향이 어떤 것인지 알 수 있습니다.

애자일 소프트웨어 개발 방법론은 요구사항 분석, 테스트 그리고 개발 사이의 사일로를 일부 해소했습니다. 하지만 배포, 운영 및 유지보수 작업은 이런 사일로를 해소하는 범위 내에 포함되어 있지 않습니다. DevOps는 개발 프로세스와 배포, 운영 및 유지보수 사이의 사일로를 제거하고 두 과정이 서로 어우러질 수 있도록 하기 위해 등장했습니다.

DevOps는 많은 운영 도구들과 기존 애자일 엔지니어링 방식의 조합으로 가능해졌지만 이 두 가지만으로 DevOps의 이점을 챙기기에는 부족한 것이 많습니다. 화려하고 다양한 도구들을 사용한다하더라도 올바른 문화가 없다면 DevOps는 단순한 buzzword에 불과합니다.

DevOps 가장 주요한 특징은 개발과 운영 팀 사이의 협업이 긴밀하고 활발하게 일어난다는 것입니다. 그리고 팀 내 혹은 조직적 차원에서 문화를 바꿔나감으로써 서로가 긴밀하게 협업을 할 수 있도록 만들 수 있습니다. DevOps를 가능하게 문화는 다음과 같습니다.

책임을 같이하는 마음 가짐은 개발팀과 운영팀 사이의 긴밀한 협업을 할 수 있도록 도와주는 DevOps 문화의 중요한 측면 중 하나입니다. 개발팀에게서 시스템을 살펴볼 수 있는 역할, 책임을 다른 팀에 넘겨버리게 되면 서비스를 운영하고 유지보수하는데 무관심해지기 쉽습니다. 만약 개발팀에게도 개발부터 배포 운영까지 시스템 전과정에 대해 모니터링하고 살펴볼 수 있는 수단과 책임을 공유하게 된다면 서비스를 운영하는 사람들의 고충을 조금이나마 공유하며 배포 및 유지보수 과정을 간단하게 할 수 있는 방법(e.g. 배포 과정을 자동화하거나 로깅을 개선)에 대해 문제 의식을 가지게 할 수 있을 것입니다. 또한 개발팀에서 프로덕션 시스템을 모니터링하는 과정에서 ObservedRequirements (역자: 간단히 말해 서비스 메트릭을 통해서 얻을 수 있는 고객의 니즈, 행동 패턴에 대한 인사이트)를 얻을 수도 있을 것입니다. 개발팀과 운영팀에서 비즈니스 목표 달성에 대한 책임을 공유하게 된다면, 운영팀에서는 개발자들과 함께 시스템 운영에 필요한 것들을 더 잘 이해하고 이를 달성하기 위해 더욱 잘 협력할 수 있을 것입니다. 실제로 협업은 개발팀에서 운영상 문제(배포와 모니터링 문제)를 인식하게되고 운영팀에서 새로운 자동화 도구를 도입하면서 협업이 시작되는 경우가 많습니다.

위와 같이 책임을 공유하는 문화를 만들기 위해서 조직적인 변화가 필요할 수도 있습니다. 먼저 개발팀과 운영팀 사이의 사일로가 없어야 합니다. 또한 어떤 문제를 해결하는 과정에서 인수 인계 프로세스를 통한 공유나 문서화를 통한 공유는 두 팀이 처음부터 같이 논의를 해나가는 방식에 비할 수 없습니다. 운영팀이 어떤 시스템을 만들어 나가는 과정 처음부터 참여할 수 있도록 리소스 구조를 조정하는 것이 좋습니다. 그리고 인계 방식이나 승인 방식은 책임을 공유하는데 방해가 되고 다른 사람을 비난하는 문화를 만들기 쉽습니다. 이러한 방식 대신에 개발자와 운영자는 시스템이 제대로 동작 안했을 때 둘 모두가 책임질 수 있도록 만들어야합니다. DevOps 문화는 개발자의 역할과 운영자의 역할의 경계를 모호하게 만들고 결국 둘간의 차이를 없앨 수 있도록 하여야 합니다. 한 가지 좋지 않은 방식은 DevOps를 조직에 도입할 때 특정 누군가에게 DevOps라는 역할을 주거나 특정 팀을 만들어 그들을 DevOps 팀이라고 부르는 것입니다. 이렇게 할 경우 원래 DevOps가 목표했던 두 팀간의 사일로를 없애는 것을 할 수 없게 될 것이며 DevOps 문화가 조직적 차원에 퍼져나가게 하지 못할 것입니다.

자율적인 팀이 되도록 만드는 것이 조직적 차원에서 할 수 있는 가치 있는 또다른 일 중 하나입니다. 효과적으로 협업하기 위해서는 복잡한 의사 결정 프로세스 없이 개발자와 운영자가 어떤 결정을 내리고 변경 사항을 적용할 수 있어야 합니다. 자율적인 팀을 조직에서 만든다는 것은 팀을 신뢰하고, 위험을 관리하는 방식을 변경하고, 실패에 대한 두려움이 없는 환경을 만드는 것이 포함됩니다. 예를 들어, 개발팀에서 테스트 환경에 배포하기 위해 승인 절차를 작성해야한다면 그 팀은 그만큼 속도가 느려질 수 밖에 없습니다. 이와 같이 매뉴얼하게 운영팀에서 변경사항들을 체크하는 방식 대신에 감사가 가능한 형태로 버전 관리 시스템을 이용하여 개발팀이 배포하게 만들 수도 있습니다. 변경 사항이 생긴다면 프로젝트 관리 도구에서 관리되고 있는 티켓과 연결 시킬 수도 있습니다. 이처럼 승인 과정을 없애면서 배포를 자동화할 수 있고 테스트 주기를 단축할 수 있습니다.

DevOps 문화를 도입하면서 가져올 수 있는 효과 중 하나는 프로덕션 환경에서 새로운 코드를 추가하기가 이전보다 더욱 쉬워진다는 것입니다. 이것이 가능해지기 위한 조건 중 하나는 먼저 프로덕션에 배포되는 코드들이 안전하다는 것을 확신할 수 있고, 이것이 가능하기 위해서는 개발 과정에서 퀄리티를 높이는 것을 가치있게 여기는 문화가 필요합니다. 품질이라하면 성능이나 보안적인 측면도 포함합니다. ContinuousDelivery나 SelfTestingCode와 같은 기법들은 정기적으로 위험도가 낮은 코드들을 프로덕션 환경에 배포하도록 도와줍니다.

팀이 피드백을 중요하게 여기는 것도 중요합니다. 피드백의 목표는 개발팀과 운영팀이 협업 과정을 개선하고 시스템을 지속적으로 개선하는 것입니다. 프로덕션 환경 모니터링 과정도 이슈를 진단하고 잠재적인 개선 사항을 발견할 수 있는 중요한 피드백 루프 중 하나입니다.

자동화는 DevOps 문화의 초석이며 협업을 촉진할 수 있는 수단입니다. 테스트나 서비스의 설정 및 배포와 같은 작업을 자동화하면 사람들이 다른 중요한 활동에 집중할 수 있도록 만들고 휴먼 에러를 줄일 수 있습니다. 자동화가 만드는 또다른 한 가지 유용한 것은 자동화를 도와주는 스크립트나 테스트가 현재 시스템의 최신 문서 역할을 해줍니다. 예를 들어 SnowflakeServer (역자: 간단히 말해 아주 특수하게 설정되고 특수한 방식으로 배포된 서비스, 그래서 조금만 변경해도 바로 장애가 발생하는 상태에 놓여있다)와 관련된 추측을 없앨 수 있고 개발팀과 운영팀에서 현재 서버가 어떻게 구성되어있는지 동일한 뷰를 가져갈 수 있습니다.