데브옵스 시작하기, 무엇이 필요한가

팀워크, 툴, 기술, 그리고 끈기

데브옵스를 하려는 사람은 많다. 그러나 시작이 가장 어렵다. 어떻게 성공적이고 집중력있는 팀을 조직할 지 판단하기 어렵기 때문이다.

데브옵스는 현업의 요구를 즉각 받아들이고 빠르게 대응하게 해준다. 개발과 운영이 유기적으로 결합돼 개발기관과 출시일정 사이의 차이를 줄여준다.

그러나 데브옵스는 조직에 많은 변화를 요구한다. 어떻게 시작해, 기틀을 잡을 것인가? 팀워크, 툴, 기술, 그리고 무엇보다 끈기가 요구된다.

최근 미국 지디넷은 '데브옵스 핸드북(The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations)’이란 책을 소개했다. 이 책을 저술한 지니 킴, 제즈 험블, 패트릭 드보이스, 존 윌스 등은 데브옵스 시작을 위한 전략의 기초를 제시하고 있다.

저자들은 "데브옵스는 역동적으로 학습하는 조직을 만들 수 있고, 빠른 추격의 성과, 월드클래스 신뢰성과 보안, 경쟁력과 직원 만족도 증진 등을 가능하게 한다"고 설명했다.

1. 가장 큰 영향을 미칠 비즈니스 분야에 데브옵스 노력을 집중하라

저자들은 린(Lean) 스타트업에서 유래한 가치흐름으로서 엔터프라이즈의 더 중요한 부분을 분류한다. 가치 흐름은 IT 영향의 흐름에 따라서 초점을 맞춘다. IT 활용효과가 큰 분야에 데브옵스의 역량을 집중하라는 것이다.

어떤 기술 시도든 빅뱅 접근은 피하는 게 좋다. 조직의 일부 영역에 노력을 집중하고, 시도의 가능성을 검증한 뒤 점차 범위를 확장하는 게 필요하다.

2. 데브옵스 가치 흐름에서 해야하는 업무를 이해하라

데브옵스 조직자는 가치가 고객에게 어떻게 전달되는지 심도있게 이해해야 한다. 무슨 업무가 누구에게 수행되고, 어떤 단계가 흐름을 개선할 수 있는지 알아야 한다.

팀 구성원의 업무들과 전체 업무흐름은 모두에게 합의된 것이어야 하고, 문서화 돼야 한다. 단, 저자들은 프로세스란 진창에 빠지지 않는 게 중요하다고 지적했다.

전형적인 데브옵스 업무흐름은 다음과 같다. 고객의 요청이 있거나, 비즈니스에서 가정한 사안을 현실화할 때 데브옵스 업무가 시작된다. 시간이 지나면, 이 업무는 개발에서 승인되며, 기능들이 코드로 짜여지고, 버전관리 보관소에서 검증된다. 빌드와 통합을 한 후 현업과 유사한 환경에서 테스트를 하고, 현업에 배포한다.

이같은 업무흐름을 통해 가치흐름이 만들어진다는 게 저자들의 설명이다.

3. 데브옵스팀과 리더십을 식별하라

임의의 그룹에 데브옵스를 시도하게 만드는 건 불필요하다. 데브옵스 방식에 가장 강한 열정을 보여주는 개인들을 찾는 게 먼저다. 여러 보수적인 그룹을 바꾸려 하면 초기 단계에서 시간을 허비할 수 있다. 저자들은 데브옵스에 대한 열정있는 직원들을 모아 소규모 팀으로 조직하라고 조언한다. 규모는 5~10명 수준을 넘지 않아야 한다.

4. 중대한 조직으로 키워가라

안정된 지지기반을 만든다는 목적을 갖고 데브옵스를 더 많은 팀과 가치사슬에 확장해야 한다. 작지만 성공을 가속한다는 것을 보여주는 게 조직의 정치 속에서 힘을 얻는데 낫다.

5. 데브옵스 전환의 시도를 특별한 것으로 만들라

일회성 프로젝트가 아니라 데브옵스 전환 시도를 위한 독립된 팀을 만들어야 한다. 데브옵스 조직에 별도의 물리적 공간을 주는 게 좋다. 이는 팀 내 소통의 흐름을 극대화하는데 도움을 준다. 전체 조직의 나머지 구성원에게서 독립시키는 효과도 있다. 데브옵스 노력을 전체 조직과 별개로 유지하자.

6. 데브옵스팀에 명확하고 측정가능한 목표를 갖게 하라

데브옵스팀의 업무 목표는 명확하고 예측가능한 것이어야 한다. 예를 들면, 업현업에서 성공적으로 작동하는 버전 관리 내에서 코드 커밋부터 배포까지 걸리는 시간을 50% 단축하라는 식으로 설정하는 것이다.

7. 다재다능한 팀 구성원을 선택하라

저자들은 특정분야에 정통하게 되면 고립된다고 지적했다. 가치 흐름의 특정 영역만 이해하고 기여하는 특화된 전문가를 만들지 말라고 주문했다.

8. 공유된 데브옵스 툴세트를 사용하라

구성원 전체가 동조화를 유지하는데 도움을 주는 업무설계 게시판과 함게 모두가 같은 우선순위 항목에 따라 같은 툴을 쓰게 하자. 모든 구성원이 발생하는 이슈를 인지하고 준비하도록 유지하게 만들어야 한다. 공유된 목표를 상식으로 만드는 게 중요하다.

이를 통해 개발과 운영은 공유된 업무 대기행렬을 만들게 된다. 예를 들어, 개발측은 이슈트래킹에 지라(JIRA)를 쓰는데 운영측은 서비스나우(ServiceNow)를 쓰는 모습이 없어질 수 있다.

9. ‘프로젝트’가 아니라 ‘서비스와 프로덕트’에 투자하라

프로젝트 사고방식에서 개발과 테스트팀은 하나의 프로젝트에 배정됐다가 작업 종료 혹은 자금소진 후에 또 다른 프로젝트에 다시 배정된다.

프로젝트 방식은 모든 종류의 실망스러운 결과를 이끌어낸다. 개발자는 장기적인 결말을 볼 수 없다. 전체 소프트웨어 수명주기 가운데 가장 이른 단계만 가치를 매기고, 자금을 지불하게 한다. 안타깝게도 이는 성공적인 프로덕트 혹은 서비스에서 가장 비싼 부분이기도 하다.

프로젝트는 일회성이다. 지속적이지 않다. 반면 프로덕트는 지속성을 갖는다.

10. 느슨하게 연결된 아키텍처를 만들어라

서비스오리엔트아키텍처(SOA)에선 이미 익숙한 개념이다. 시스템의 일부 요소를 수정 혹은 변경할 때 나머지 요소에 영향을 주지않아야 한다는 것이다.

빈틈없이 통합된 아키텍처는 아주 작은 변경에도 전체 시스템을 죽게 만들 수 있다. 이는 대규모의 장애를 만들어낸다. 시스템 구성요소들이 상호 간에 어떤 상황변화에 주고 받는 영향을 최소화하는 게 요구된다.