[기고] 성공적인 데브옵스 전략 수립

깃랩의 2021년 글로벌 데브섹옵스(DevSecOps) 조사에 따르면, 응답자 대부분이 데브옵스(DevOps) 또는 데브섹옵스를 사용하여 소프트웨어를 개발하고 있었다.

개발자의 약 60%가 데브옵스를 통해 이전보다 2배 더 빠르게 코드를 릴리스하고 있는 것으로 나타났다.

데브옵스는 많은 비즈니스에 직접적인 영향을 미치고 있다. 그렇다면, 성공적인 데브옵스 전략을 개발하기 위해 필요한 사항들은 무엇인지 살펴보도록 하자.

데브옵스는 무엇인가?

데브옵스는 보다 안전하고 빠르게 소프트웨어를 만들기 위해 개발(Dev)과 운영(Ops)을 통합한 일련의 수행사례들로 이루어져 있다.

데브옵스의 주요 원칙은 자동화를 비롯해 지속적인 통합 및 지속적인 제공, 그리고 피드백에 대한 신속한 대응을 꼽을 수 있다. 민첩한 계획과 코드형 인프라(IaC), 컨테이너화 및 마이크로서비스 등이 있으며, 애플리케이션 라이프사이클 전반의 개발 및 운영 단계에서 품질을 보장하고, 보안을 구현하는 것도 매우 중요하다. 데브옵스 팀에 보안을 통합하는 것을 데브섹옵스라고 한다.

소프트웨어의 높은 품질을 유지하면서도 제공 주기를 단축하기 위해서는 전통적으로 고립된 형태 또는 별도의 실행방식으로 작업을 수행해 온 두 그룹, 즉 개발 팀과 운영 팀의 노력을 자동화하고 통합하기 위한 조직 문화의 변화가 필요하다.

그러나 최상의 데브옵스 프로세스와 문화는 개발 및 운영을 넘어 플랫폼과 인프라 엔지니어링, 보안, 컴플라이언스, 거버넌스, 위험관리, 영업부문(LOB), 최종 사용자 및 고객에 이르기까지 모든 애플리케이션 이해관계자들의 의견을 소프트웨어 개발 라이프사이클에 통합할 수 있도록 확장되고 있다.

성공적인 데브옵스 전략은 고객에게 초점을 맞추는 것이다. 이는 개발 및 릴리스 지연을 정당화하기 위한 방법으로 소프트웨어 품질 향상에만 집중하는 것으로는 충분하지 않다. 또한 가장 중요한 요소인 소프트웨어 소비자를 간과해서는 안 된다.

고객은 문제를 해결할 수 있는 고품질의 제품을 원할 뿐 프로세스에 대해 크게 신경 쓰지 않는다. 성공적인 데브옵스 전략은 팀이 소비자의 입장이 되도록 하는 것이다.

데브옵스의 또 다른 이점은 운영, 보안 또는 프로젝트 관리 팀을 비롯한 다양한 팀들이 애자일(Agile) 환경에서 작업을 수행할 수 있다는 것이다. 개발 팀은 수 년에 걸쳐 애자일 문화를 발전시켜 왔지만, 이러한 상황은 개발 팀에만 한정적으로 진행되었다.

운영 팀은 아직 이러한 수준에 도달하지 못했으며, 동일한 속도로 소프트웨어를 릴리스하기 어렵다는 것이 드러났다. 데브옵스는 이러한 팀을 하나로 결합하여 소프트웨어 제공 속도를 가속화하면서도 품질을 높일 수 있도록 해준다.

데브옵스를 통해 개발주기를 단축함으로써 코드를 더 자주 릴리스할 수 있으며, 이를 통해 코드 결함을 보다 쉽게 발견할 수 있다.

대부분의 상황과 마찬가지로, 의사소통은 데브옵스 전략을 성공적으로 이끄는데 매우 중요하다. 의사소통이 이뤄지지 않으면, 어떠한 비즈니스 팀이라도 제대로 기능할 수 없으며, 데브옵스 팀도 마찬가지다. 좋은 데브옵스 전략은 새로운 시스템을 구현할 때 개발자와 동료들 및 주요 이해관계자들의 피드백을 통합하는 것이다.

이전에는 IT의 역할이 보다 체계화되고 명확했지만, 앞서 언급한 바와 같이 전문가들은 고립된 방식으로 일하는데 익숙했다. 그러나 데브옵스는 이러한 모델과 작업을 보다 협업적으로 변화시켰다. 이제 팀들은 기대치와 요구사항 및 마감일에 대해 보다 명확한 의사소통이 이뤄지도록 해야 한다.

데브옵스는 변화에 대한 의지에서 비롯된다. 팀은 비즈니스 요구사항과 기능이 발전하고, 변화함에 따라 기존의 일부 관행들을 버리고, 하나의 결과물에만 집중하지 않고 다음 단계로 나아갈 수 있도록 좀 더 개방적인 자세를 취해야 한다.

또한 팀은 실패를 받아들여야 하지만, 낙담해서는 안 된다. 일부 실패는 있을 수 있으며, ‘페일 패스트(Fail Fast)’ 개념(문제가 있지만, 쉽게 해결할 수 있음)은 데브옵스의 핵심이다. 새로운 기술을 시도할 때 실패의 가능성을 받아들여야 하며, 창의력을 발휘하는 것을 두려워하지 않아야 한다. 최고의 팀은 함께 협력하고, 아이디어를 교환하고, 작업 방식의 한계를 뛰어넘어 보다 창의적인 코드를 작성하는 팀이다.

표준 로드맵을 구축하면, 데브옵스 팀은 기업이 구상하고 있는 제품에 대한 높은 수준의 전략적 청사진을 얻을 수 있다. 이는 소프트웨어 라이프사이클 전반에 걸쳐 모든 이해관계자들에게 중요한 참조 포인트가 된다. 또한 운영 팀은 이러한 로드맵을 통해 개발 팀이 테스트할 수 있는 코드를 언제 준비할 수 있는지 알 수 있다.

데브옵스 로드맵을 수립할 때는 객관적인 목표를 명확하게 정의해야 한다. 로드맵을 위한 공동의 목표가 무엇인지 팀과 의논해야 한다.

이러한 목표에는 엔지니어링 및 운영 팀 조정능력 향상과 단일 정보 소스 생성이 포함될 수 있다:

가장 효과적인 프로세스를 기반으로 사람들이 시간이 지난 후에도 참조할 수 있도록 개발 및 릴리스 성공사례에 대한 저장소를 구축한다. 이는 향후 데브옵스 노력을 개선하는데 도움이 된다.

또한 집중적인 단기 목표와 계획을 수립해야 한다. 기업들은 일반적으로 2개월 ~ 6개월 간의 제품 로드맵을 계획하고 있다.

기업들이 로드맵을 수립할 때 가장 많이 저지르는 실수는 텍스트만 사용하는 것이다. 워드 문서나 스프레드 시트만 사용하면, 이해관계자들이 최우선 순위가 무엇인지, 어떤 이니셔티브가 다른 팀에 의존하고 있는지, 또는 누가 무엇을 책임지고 있는지 명확하게 파악하지 못할 수 있다.

컬러 코딩이나 그래프를 이용해 시각적 로드맵을 작성하면, 이해관계자들이 제품 계획을 보다 쉽게 이해할 수 있다. 또한 로드맵은 변화하는 기업의 문화와 비즈니스 모델을 반영하여 최신 상태로 유지되어야 한다.

변화는 쉽지 않고, 개발 및 운영을 통합하는데 따른 약간의 충돌 또한 발생할 수 있지만, 성공적인 데브옵스 팀을 구축하기 위해서는 관계자들 모두 양측 간의 통합과 협업이 필요하다는 점을 명심해야 한다. 작은 제품이나 구성요소를 시작으로 빌드하여 점진적으로 데브옵스로 전환하는 것이 좋다.