벤더 기고 | 데브옵스를 올바르게 구현하는 방법

* 본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.



데브옵스(DevOps) 도입이 증가하고 있다. 의심의 여지가 없다. 가트너에 따르면, 올해 글로벌 2000 기업의 25%가 데브옵스를 도입해 활용할 전망이다.

문제는 데브옵스로의 전환이 쉽지만은 않다는 점이다. 엔터프라이즈에는 기존 프로세스, 조직, 시스템, 사일로가 가득하기 때문이다. 변화에 대한 저항이 거의 확실히 발생한다.

자동화는 속도와 통일성을 가져다 줄 수 있다. 그러나 가시성과 관리성이라는 도전 과제가 수반되기 마련이다. 데브옵스 생태계가 성숙해지고 있지만 너무나도 많은 툴이 존재하며, 데브옵스를 성공적으로 도입할 수 있도록 해주는 분명한 청사진이 아직 없다. 애자일 선언서(Agile manifesto)는 구체적인 가이드라인이 아니라 높은 차원의 '성명서'에 가깝다

그렇다면 데브옵스 이행의 중요 전제조건은 뭘까? 다른 이들의 성공과 실패에서 무엇을 배울 수 있을까? 지금부터 이에 관한 내용을 소개하겠다.

* 균형 잡힌 추진. 위에서 아래로의 하향식 참여와 몰입이 중요하다. 최고위층이 변화의 필요성을 인식해 승인해야 한다. 그래야 장애물을 제거하고, 올바른 장소에 자원을 투자하고, 권한을 위임할 수 있다. 또 데브옵스를 기업의 우선순위로 추진할 수 있다. 그러면서도 독단적인 강제와 강요는 피해야 한다.

실제 실천은 아래로부터 위로의 상향식이 되어야 한다. 각 팀이 필요한 기술, 시스템 전달 프로세스의 구현 방법, 가장 합리적인 방식을 스스로 파악해야 있어야 한다. 하나로 모든 것을 처리할 수 있는 방법은 없다. 팀의 전문성을 이용, 최상의 토대를 구축해야 한다. 즉 하향식과 상향식이 균형 잡혀야 최상의 결과를 이끌어낼 수 있다.

* 적합한 스킬. 튼튼한 코딩 토대와 더불어 지속적인 통합, 배포, 테스트, 품질, 가상화, 클라우드, 프로비저닝, 조율 및 통일, 모니터링 등과 관련해 하나 이상의 자동화 변화에 친숙해져야 한다.

이는 새로운 방식으로 운영됨에 있어 아주 중요한 부분이다. 가상 데이터센터, 가상 네트워킹, 가상 서버를 유지 관리해야 하며. 효율적인 자원 계획, 원가 모델을 조사해야 하는 상황이 도래한다. 조직의 스킬(전문성과 역량) 구조를 급격하게 바꾸거나 강화해야 하고, 운영에는 코딩 스킬, QA에는 테스트 자동화 스킬을 가져와야 한다는 의미이다. 또 새롭고 실험적인 제품 관리 사고 단계를 도입해야 한다.

또 모든 사람이 비즈니스와 고객에 대한 이해를 높여야 한다. 소규모로 자주 출시하는 출시 관리, 자동화를 통한 안전 관리, 빠르게 변경 사항을 관리 및 조정하는 역량이 필요하다. 여기에 정통한 인재 후보군을 파악하고, 이들에게 필요한 교육과 지원을 제공해야 한다.
이와 함게 기존 인프라를 운영하는 것과 관련된 전문 지식이 무수히 존재하고 있을 것이다. 이를 반드시 유지해야 한다. 그러나 이와 동시에 가장 적절한 최신 툴을 도입하고, 이를 이용할 역량을 구축해야 한다.

* 올바른 측정과 평가. 올바른 측정과 평가가 필요하다. 또 그 결과를 가시화해야 한다. 의심을 없애는 최상의 방법은 결과를 보여주는 것이다. 개념에서 수익화, 매진에서 수익화까지의 시간을 조사해야 한다.

특정 기간의 생산 배포 또는 롤백의 횟수를 평가하는 것이 중요하다. 개발자들이 피드백을 얻는데 소요되는 시간도 측정해야 한다. MTTR, 감사 데이터 제공에 소요되는 시간, 출시 동안 핸드오버 시간을 측정할 수 있을 것이다. 기타 많은 매트릭스를 이용할 수 있다. 기업의 비즈니스 목표에 따라 평가 대상과 방법이 달라질 것이다.

측정은 데브옵스의 핵심 개념 중 하나인 개방된 문화를 조성하는데 도움을 준다. 데이터가 유입되면 효과 있는 데이터, 그렇지 못한 데이터를 확인할 수 있다. 또 매달 배포가 한 차례였다가 매일 배포가 10차례가 된 프로젝트, 정체된 프로젝트에서 성공과 실패의 원인을 파악하는 것도 큰 도움이 된다. 분석 하고, 평가 하고, 변화를 추구하는 과정을 반복하면 된다.

측정과 평가는 목표와 수단을 구분하는 데에도 도움을 준다. 데브옵스는 여러 툴을 구현하는데 목적이 있지 않다. 툴은 다른 목표를 달성하는데 도움을 주는 도구일 뿐이다. 끊임 없이 목표, 이를 위해 시도하는 프로세스, 프랙티스, 툴을 구분하는데 관심을 기울여야 한다.

* 지속적인 커뮤니케이션. 데브옵스의 중요 특성 중 하나는 공동 책임이다. 개발자는 아무 생각 없이 지시 받은 기술을 구현하는데 그쳐서 안 된다. 상당한 충격파가 발생거나, 유용하지 않을 것으로 판단되면, 조기에 의문을 제기해야 한다.

유사하게 데브옵스 환경에서 테스트와 QA는 버그를 찾아 알려주는 것이 목적이 아니다. 결함을 고치고, 서로 협력해 문제를 해결하는 것이 목적이다. 비즈니스 팀은 처음부터 질문에 답을 하고, 의견을 제시해야 한다.

모든 사람이 더 빨리 커뮤니케이션을 하는 것이 더 바람직하다. 커뮤니케이션 경로를 개방된 상태로 유지해야 한다. 사일로를 무너뜨릴 방법, 생산적인 커뮤니케이션과 협력을 구현할 방법을 찾아야 한다. 전체 프로세스를 확인할 수 있어야 한다. 그래야 큰 그림을 그릴 수 있다. 저절로 혼자 되는 일이 아니다. 모든 사람이 목표를 공유해야 한다.

앞서 언급한 모든 것들은 사실 야심 차지만 어려운 목표들이다. 데브옵스의 출발점은 효율성을 높이고, 실수를 줄이기 위한 방편으로 자동화에 초점을 맞추는 것이다. 문화적인 변화를 제대로 달성하기까지 많은 시간이 필요하다. 그러나 매 단계에서 계속 평가를 해나간다면 올바른 방향으로 나아갈 수 있다.


*제비아랩스(XebiaLabs)는 지속적 전달 및 데브옵스용 소프트웨어 전문 기업이다. 제비아랩스의 데브옵션 전략 부문 부사장이자 클라우드, 서비스 딜리버리, 자동화 전문가인 저자는 애플리케이션 딜리버리 플랫폼 자동화 분야에 집중해왔으며 아차피 j클라우드, 리딩 클라우드 라이브러리 등의 오픈소스 프로젝트에 다수 기여한 바 있다. ciokr@idg.co.kr