최근에 DevOps(데브옵스)라는 개발방법론이 솔솔 들리고 있다.

데브옵스는 개발(Development) + 운영(Operation)을 합친 말로 개발와 운영의 상호작용을 원할하게 하는데 있다고 합니다. [마이크로소프트웨어]잡지 2013년 12월호에서 신현목님께서 기고한 글(데브옵스와 소프트웨어 시각화)에 보면 다음과 같이 설명이 되어 있다.

데브옵스는 개발자가 행복하게 소프트웨어를 개발할 수 있도록 환경을 구축하는 것이 목적이다 과거의 개발 방법론이나 문화, 운동들이 대부분 소프트웨어의 품질을 높히기 위해 개개인의 능력차를 무시하고 진행된 것이라면, 데브옵스는 개발자의 행복을 가장 우선으로 한다. 개발자가 행복하면 자연스럽게 소프트웨어의 품질을 향상된다는 이론이다.

데브옵스가 조직에 잘 정착되기 위해서는

  1. 소프트웨어를 잘 만드는 개발자
  2. 소프트웨어를 잘 동작하도록 운영하는 운영자

이 두가지가 필수이다.

이러한 것을 만들기 위해서는 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직을 만드는 것이다. 개발 조직이 빠르게 소프트웨어를 개발, 필드, 테스트, 배포, 운영할 수 있도록 최적화 된 사이클의 개발 환경을 갖춰야 하고, 업무프로세스를 정의한 뒤 각 조직 간의 역활을 조율하는 과정이 자동적으로 이루어지는 한편, 이러한 일련의 시스템 운영이 호율적으로 진행되어야 한다. 그래야만 소프트웨어를 잘 만들어내는 개발자 와 소프트웨어가 잘 동작되도록 운영하는 운용자 가 만들어지게 되고 데브옵스가 가동되는 것이다.

애자일방법론하고 유사하지 않은가 싶다. 지금까지 데브옵스에 대한 관련 자료를 보면

  1. 개발자들의 업무적인 질향상으로 품질증대
  2. 개발자와 비개발자(테스터, 운영자)간의 빠른 피드백과 협업으로 인한 품질증대

라고 볼 수 있을 것 같다.

최근들어 개발자들의 업무환경의 질에 대한 많은 방법론과 관련자료들이 나오고 있다. 사실 어떤 서비스를 만들거나, 제품을 만드는 사람이 일을 함에 있어 행복하고 여유가 있어야 좋은 서비스와 제품이 만들어진다.

최근에 우연이 어떤 청담동 헤어디자이너가 블러그에 쓴 글을 보았다. 내용은 대략 이렇다.

우리 헤어숍은 비싸다, 다른데보다 2~3배 정도 비싸다. 그리고 예약은 필수이다. 예전에서 싸게 일할 때는 아침에 문열자마자 미어지는 손님때문에 정신없이 일했다. 하지만 그만큼 손님에게 최선을 다하지 않고 기계적으로 머리를 깍고 있었다. 하지만 지금은 비싼 가격에 예약을 하는 손님에게만 최대한 최선을 다해서 대하고 있다. 그래서 내 자신에게 투자하는 시간이 많이지게 되어 내 기술도 늘어가고 있고, 결국 나도 행복하고, 서비스를 받은 고객도 행복해 한다. 게다가 수입도 몇 배 올랐다

명품과, 좋은 서비스와, 고급의 음식의 특징은 그것을 생산해 내는 사람이 행복하고 여유가 있어서가 아닐까 한다. 고급 갤러리나 일류호텔 음식점등이 정신없고, 북적거리면서 고급의 무언가를 제공해주는 것을 본적이 없다. 하지만 그렇게 업무의 질을 높히기 위해서는 단순히 마음만 단단히 먹거나, 아무런 학습도 없이 진행되지는 않는다.

애자일방법론이나 데브옵스도 결국 학습이 필요하고 변화를 받아들여야 가능하다. 공유소스관리, 지속적인 통합(빌드,배포,테스트), 스크럼등 기술과 관련 개념을 공부하고 업무에 적용시키는 학습노력이 필요하다. 무엇보다도 개발자들이 소통, 즉 커뮤니케이션에도 많은 신경을 써야 한다. 좋은 개발자는 비 개발자하고도 원할하게 소통이 가능해야 한다.

또한 회사에서도 경영진이나 비개발자들도 개발자들이 개발에 전념할 수 있는 환경을 만들어 주는 것도 중요하다. 잦은 전화응대, 어수선한 근무환경등은 배제되어야 한다.

데브옵스는 개발자/테스트/운영에서 빠른 소통과 협업을 통해서 양질의 SW서비스를 빠르게 제공하는데 그 목적이 있다. 그래서 그런지 최근에는 유명 SW주기가 점점 빨라지고 있다. 파이어폭스, 우분투, 안드로이드, 애플등을 보면 제품릴리즈 주기가 6개월에서 12개월 사이로 상당히 빨라지고 있다.

과거 윈도우 OS를 보면 얼마나 개발주기가 길었던가? 제품릴리즈가 3,4년은 넘었었다. 지금은 빠르게 변화하고 빠르게 고객의 니즈에 맞추어서 제품과 서비스가 변화되어야 한다. “차기 소프트웨어개발계획 3계년계획” 따위는 이제 사라지는 추세다. 조금 더 빠르게 고객의 니즈에 맞게 움직일 수 있게 가볍게 조직을 정비해야 한다.

데브옵스가 그 해결책이 될 수도 있다. 애자일 2013 에서 기조연설자인 진 킴이 발표한 데스옵스의 3가지 주요 요소만이라도 기억하자!

  1. 흐름 (The flow)
  2. 지속적인 피드백 (Consistent feedback)
  3. 끊임없는 학습 (Continual learning)

devops

그렇다면 어떻게 하면 데브옵스를 사용하는 것일까? 일단, 내부적으로 데브옵스의 방향에 대한 충분한 공감대가 있어야 한다. 즉 개발자와 비개발자간의 충분한 공감대가 형성되어야 한다. 그리고 나서 그에 맞는 적정한 툴을 사용하도록 한다.

개발자와 비개발자간의 협업을 위한 툴에는 트렐로(Trello)라는 좋은 툴이 있다. 보통 비개발자들은 개발자들에게 요청하게 되는데 과연 잘 진행되고 있는지, 완료일정은 언제인지, 어디까지 진행되고 있는지에 대해 많이 궁금해 한다. 트렐로를 업무를 통합하면 비개발자도 얼마든지 개발자의 진행을 확인할 수 있다.

또한 보다 상세한 개발내용이 필요할 경우 레드마인(Redmine)이라는 이슈관리 툴을 이용해서 개발자간의 업무진행을 상세히 공유할 수 있다. 레드마인은 github와 연동이 가능하여 소스레벨까지 확인이 가능하다.

** 핵심은 개발자들의 모든 진행사항은 공유되어야 한다. **

팀의 모든 업무는 정해진 툴을 이용하여 명확하게 명시하는 것이 좋다. 또한 개발자들의 업무향상을 위해 반복적이고 소모적인 개발업무들은 충분히 오픈소스의 툴로 해결할 수 있다. 테스트나 데모서버에 소스를 올리는 것을 개발자가 하는 것이 아닌 툴로서 자동화가 이루어져 한다.

TDD, Git, Github를 이용하고 Jenkins를 통해서 테스트 및 버전관리와 품질관리를 함으로써 불필요한 소모적인 업무를 줄일 수 있고, 결국 개발자들이 보다 중요한 일에 집중할 수 있게 된다.

데브옵스는 공감만으로 진행되지 않는다. 그에 맞는 적절한 방법(도구)를 찾아서 시행하는 것이 중요하다고 생각된다. 비록 시행착오를 겪을지라도…