[기고] 데브옵스 방법론의 4가지 핵심 원칙

현태호 깃랩 코리아 지사장

소프트웨어 개발 방법론으로 널리 사용되는 데브옵스(DevOps)는 보안(데브섹옵스) 및 비즈니스(비즈데브옵스)처럼 다른 영역들을 포함한다 처음 접한 초보자들에게는 다소 혼란스러울 수 있다.

중요한 것은 기업이 소프트웨어 개발 방식을 개선할 수 있는 데브옵스 방법론의 4가지 핵심 원칙이다.

1. 소프트웨어 개발 라이프사이클 자동화

2. 협업과 의사소통

3. 지속적인 개선 및 낭비 최소화

4.짧은 피드백 루프를 통해 사용자 요구에 대한 집중 강화

■ 데브옵스 핵심 원칙 검토

약 15년 전에 개발 및 운영을 원활하게 통합하기 위한 새로운 개념이 등장했다. ‘데브옵스’라는 용어는 2009년, 이 방법론의 최초 권위자로 알려진 패트릭 드부와(Patrick Debois)에 의해 만들어졌다.

데브옵스에는 애자일(Agile) 소프트웨어 개발 원칙들이 다수 포함되어 있지만, 개발 및 운영 사일로(Silo)를 제거하는 데 특히 중점을 두고 있다. 이후 데브옵스는 소규모 비즈니스에서 기존 시스템을 사용하는 엔터프라이즈에 이르기까지 거의 모든 규모의 기업들에게 계속해서 널리 확산되었다.

다른 방법론과 마찬가지로, 데브옵스는 기업들의 고유한 요구사항과 환경에 적응할 수 있으며, 가장 중요한 비즈니스 요건에 따라 조정이 가능하다. 이와 같이 데브옵스에는 다양한 특징들이 존재하지만, 핵심에는 다음과 같은 4가지 필수 원칙이 있다.

■ 소프트웨어 개발 라이프사이클 자동화

모든 데브옵스 팀을 위한 핵심은 자동화이다. 데브옵스 이전의 소프트웨어 개발 프로세스는 모든 단계에 걸쳐 사람이 개입(및 물리적 핸드오프)해야 하는 매우 수동적인 과정이었다.

사람이 개입해야 하는 이러한 프로세스로 인해 기업들은 1년에 한 번 새로운 코드를 업데이트하거나 릴리스하는 것도 쉬운 일이 아니었으며, 보통 많은 기업들의 릴리스 주기는 18개월 또는 24개월에 이르렀다.

오늘날 소위 ‘엘리트 데브옵스 팀’의 경우에는 하루에도 여러 번 코드를 릴리스하고 있으며, 이는 대부분 자동화 덕분에 가능해졌다.

데브옵스에서 자동화의 성능과 중요성을 이해하기 위해서는 소프트웨어 테스트를 살펴보는 것이 좋다. 소프트웨어 테스트는 릴리스 지연 원인으로 희생되거나 종종 간과되는 경우가 많은 인정받지 못하는 단계이다.

하지만 소프트웨어 테스트의 중요성은 의심의 여지가 없으며, 테스트를 하지 않는 기업들은 릴리스가 실패하거나 실제로 안전하지 않은 코드를 공개할 위험을 안게 된다. 테스트는 모든 데브옵스 단계 중 아마도 가장 번잡한 실무 단계일 것이다.

테스트 사례를 작성하고, 수많은 테스트를 실행하고, 결과를 분석한 다음, 다시 개발자와 연락해 수정 작업을 진행해야 한다. 이로 인해 팀이 코드가 제시간에 릴리스되지 않는 가장 큰 원인으로 테스트를 지적하는 것이다.

코드가 작성될 때 가장 기본적인 소프트웨어 테스트를 수행하고, 이를 자동화할 수 있다고 생각해 보자. 테스트 자동화는 전체 프로세스 속도를 크게 향상시킬 수 있으며, 소프트웨어 테스터를 통해 피해를 가중시킬 수 있는 코드 품질 문제를 발견할 수 있다.

테스트는 데브옵스에서 가장 극적인 자동화의 ‘성공사례’ 중 하나이지만, 유일한 것은 아니다. 지속적인 통합은 새로운 코드를 기존 코드로 이동시키는 프로세스를 자동화할 수 있으며, 지속적인 배포는 릴리스를 자동화하는데 도움이 된다.

또한 코드형 인프라(Infrastructure as Code)를 사용하면, 개발자 환경의 프로비저닝 프로세스를 쉽게 자동화할 수 있다.

■ 협업 및 의사소통

뛰어난 데브옵스 팀은 자동화를 수행하고 있지만, 최고의 데브옵스 팀은 협업과 의사소통에 중점을 둔다. 데브(개발)와 옵스(운영)를 결합(또한 보안과 테스트, 이해관계자 등)한 이 개념 자체는 팀의 협업이 가장 중요하다. 명확하고, 규칙적인 의사소통이 이뤄지지 않는다면, 이를 달성할 수 없다.

데브옵스의 원칙이 너무 단순하게 들릴 수도 있지만, 대부분의 경우와 마찬가지로 악마는 디테일에 있다.

즉, 단순해 보일지라도 상당한 시간과 노력이 필요하다. 개발자는 코드를 작성하여 운영환경으로 배포해야 하고, 운영 전문가들은 툴과 컴플라이언스, 클라우드에 중점을 두어야 하며, 보안 팀은 코드가 안전한지 확인해야 한다.

데브와 옵스, 그리고 보안(Sec)은 우선순위가 동일하지 않고, 동일한 ‘언어’를 사용하지 않을 수 있으며, 매우 다른 관점에서 문제 해결에 접근할 가능성이 높다. 예를 들어, 데브와 보안은 부분적으로 격차가 여전히 넓기 때문에 실제로 의사소통과 협업이 쉽지 않다.

팀을 하나로 모으기 위해서는 노력이 필요하고, 때로는 사고의 전환이 필요하다. 2021년 글로벌 데스섹옵스 설문조사 결과에 따르면, 데브옵스를 성공시키기 위해서는 팀의 의사소통이 필요하다.

반면, 데브옵스 자체가 더 나은 의사소통과 더 만족스러운 개발 환경을 만드는 것으로 나타났으며, 이는 ‘닭이 먼저냐, 달걀이 먼저냐’와 같은 상황이다.

■ 지속적인 개선 및 낭비 최소화

린(Lean) 및 애자일을 포함한 초기 소프트웨어 개발 방법론에 크게 의존하고 있는 데브옵스는 낭비를 최소화하고, 지속적인 개선에도 중점을 두고 있다.

테스트와 같은 반복적인 작업을 자동화하여 시간을 낭비하지 않도록 하거나 새로운 코드를 릴리스하는데 필요한 단계를 줄이고, 기능을 최적화하기 위해 데브옵스 팀은 계속해서 성능 지표를 측정하여 개선이 필요한 영역을 결정한다.

팀은 릴리스 시간을 지속적으로 개선하고, 평균 복구 시간(MTTR)과 발견되는 버그 수 및 기타 여러 지표들을 줄이기 위해 노력해야 한다.

■ 짧은 피드백 루프를 통해 사용자에 대한 집중 강화

마지막으로 알아야 할 데브옵스 원칙은 실제 사용자를 이 프로세스의 모든 단계에 참여시키는 것이 중요하다는 점이다.

데브옵스 팀은 자동화와 의사소통 및 협업의 개선, 그리고 지속적인 개선을 통해 실제 사용자가 진정으로 원하는 것이 무엇인지, 그리고 어떻게 이를 제공할 것인지에 집중할 수 있다. 사용자의 마음을 파악하는 것은 매우 까다로운 일이며, 팀이 이를 달성하기 위한 프로세스를 구현하는 것은 상당한 어려운 과정이 될 것이다.

또 다른 어려운 부분은 사용자 피드백이 수집된 후 시간을 낭비하지 않고, 신속하게 이를 제공할 수 있어야 한다는 것이다.

이것이 바로 짧은 피드백 루프가 중요한 이유이며, 팀은 갈수록 피드백 루프를 단축하는데 더 많은 노력을 집중시켜야 한다.

■ 데브옵스 모델 및 수행사례의 이점

팀이 데브옵스를 올바르게 수행하면 어떻게 될까? 깃랩의 2021년 설문조사에 따르면, 개발자들의 60%가 데브옵스 덕분에 코드 릴리스 속도가 최소 2배 이상 빨라졌다고 응답했다. 또한 데브옵스 모델의 또 다른 이점으로 개선된 코드 품질, 시장출시시간 단축, 향상된 계획 등이 제시되었다.

이외에도 설문조사 응답자들은 성공적인 데브옵스 실행방식으로 개발자의 만족도를 높이는데 도움이 되었으며, 행복한 개발자가 더 생산적임을 보여주는 과학적인 데이터가 있다고 응답했다.

데브옵스 채택과 성공은 글로벌 팬데믹의 영향으로 도약의 발판을 마련했다. 깃랩의 설문조사에 따르면, 팀은 ‘어떻게 협력해야 하는가’라는 일부 문화적 문제들을 극복하고, ‘어떻게 올바른 기술을 채택할 것인가’라는 사고방식으로 발전하고 있다.

데브옵스의 미래는 쿠버네티스(Kubernetes), 데브옵스 플랫폼, AI 및 머신러닝 등과 같은 첨단 기술과 연계하여 생각해 볼 수 있을 것이다.

우선은 코드 검토에서 시작하여 프로세스를 간소화하기 위해 지속적인 데브옵스 플랫폼 채택과 같은 보다 지능적인 툴 선택에 이르기까지보다 스마트한 AI 및 머신러닝 기반 의사결정과 더욱 확장된 자동화 등을 기대할 수 있을 것이다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.