개발과 운영의 조화 - Devops #1/2

https://bcho.tistory.com/815

개발과 운영의 조화 - Devops #1/2

 

기존 개발 체계의 문제점

전통적인 개발 운영 체계

일반적인 개발 운영 체계는 다음과 같다. 개발팀에 의해서 개발이 끝나면, 시스템은 테스트를 거쳐서 운영팀에 이관되고, 운영팀은 해당 시스템을 배포 및 관리 운영한다.

 

 

 

 

일단 이관된 시스템은, 개발팀이 일체 관여하지 않고, 운영팀에 의해서 현상 유지 된다.

 

문제점 1. 누구의 잘못인가? 불행의 시작

시스템을 운영하다 보면, 반드시 장애가 생기기 마련인데, 문제는 여기부터 시작된다. 개발은 “애플리케이션” 을 볼 수 있지만, 아랫단의 “인프라 시스템”을 볼 수 있는 능력이 없다. 반대로 운영팀은 “인프라 시스템” 을 잘 알지만, “애플리케이션” 자체에 대해서는 잘 모른다.

그러다 보니, 서로 자기 분야의 문제가 아니라고 하면서 서로 책임 미루기를 하게 되고, 문제 해결은 지연된다. 이러한 책임 미루기에 대해서 “Fingerpointyness”라는 말로 표현한 것이 있는데, 정확하게, 누가 어떤 문제를 해결해야 하는지 정의 되지 않은 상황에서, 협업이 없어지고 문제 해결이 엉뚱한 방향으로 가는 현상이다.

 

 

 

[1]

①    Freaking out & find fault 단계 (문제 발견)

자아. 문제가 발생했다. 문제의 내용을 먼저 파악한다. 이때 협업은 없다. 단지 자기 분야에서 문제가 어떤 것인지, 한정된 지식으로 현상 자체를 인지하는 수준이 된다. 근본적인 문제에 대한 원인 파악보다는 대충 파악하는 단계 정도의 수준이 된다. 이 단계에서 누가 문제를 파악할지에 대한 owner ship 자체가 정해지지 않는다.

②    Blaming Covering ass 단계 (욕하기)

그러다가, 어느 정도 문제의 현상 (정확한 원인이 아니라) 정도가 파악되면, 서로 미루기를 한다. “애플리케이션 문제네..”, “데이터 베이스 문제네..” 식으로, 정확한 원인 파악 없이 자기 문제가 아닌 것 처럼, 다른 쪽으로 미루기를 시작하면서, 상대편을 욕하는 단계가 된다. “데이터 베이스 구성을 그렇게 하니까는 그렇지.. 인덱스는 아냐?”. 내지는 “애플리케이션 구조에 맞춰서 배포는 한거야?” 이러면서 문제의 근본적인 원인은 해결되지 않고 시간은 계속 간다.

③    Whining, Hiding. Hurt Ego 단계 (맘 상처 입기)

계속 해서 문제를 서로에게 넘기다 보면, 문제를 숨기거나 상대방을 헐뜯거나 하면서 결국은 서로 상처를 입게 되고, 점점 커뮤니케이션은 없어지고 관계는 악화되어 간다.

④    Figuring it out (문제 원인 분석)

결국 문제를 해결해야 하는 시간이 가까워 오면, 문제를 풀긴 풀어야 하니,  어떻게든지 스스로 서로 모여서 문제를 같이 보게 되거나, 상위 메니져를 통해서 강제적으로 같이 모여서 문제에 대한 원인 분석을 해서 결국은 원인을 파악하게 된다.

⑤    Fixing things (문제 해결)

그리고, 결과적으로 원인 파악 및 문제가 해결된다.

아주 전형적인 개발과 운영간의 장애 처리 프로세스이다. 그나마 똑똑한 팀장을 가지고 있는 조직은 장애나 문제가 발생했을때, “모두 다 모이세요.”해서 초기부터 문제를 같이 보고 해결하거나, 개발팀이나 운영팀 자체가 상대방의 분야를 볼 수 있는 능력을 갖춰서 문제를 해결하는 경우가 많다. 예를 들어 운영팀이 애플리케이션에 대한 장애 대응 능력을 갖거나, 개발자가 OS나, 데이타베이스 또는 미들웨어등에 대한 인프라 운영 능력을 갖는 경우이다.

 

문제점 2. 운영 이슈에 대한 전달 문제

또 다른 문제점을 살펴보자, 앞에서도 언급 했듯이, 개발은 운영으로 이관 후에, 서비스에 대해서 더 이상 관심을 갖지 않는다. 그리고, 고객과의 접점도 거의 없다. 그러나 운영은 (단순히 시스템을 운영하는 시스템 운영만이 아닌 실제 서비스 운영을 포함) 계속 해서 사용자와 interaction을 하고, 사용자로부터 끊임 없이 VOC (Voice Of Customer)를 받는다.

 

 

 

 

서비스를 운영하는 입장에서, 사용자의 의견을 들어서 서비스를 개선하고 싶은 것은 당연한 이치이고, 여러 VOC를 모아서 개발팀에 서비스 개선 요청을 하지만, 이미 개발과 운영은 멀어져있는 상태이고, 운영은 명시적으로 개발팀에 요구 사항을 정의할 수 있는 권한이 없기 때문에 (이러한 권한은 일반적으로 서비스 기획팀에서 갖는다). 이러한 개선 요청 요구 사항은 개발팀 입장에서는 추가적인 일이 되고, 개발팀은 이러한 신규 요구 사항에 대해서 저항하거나 또는 거절하게 된다.

 

문제점 3. 변경 요건

서비스가 운영 배포된 후에도, 비즈니스 (기획팀)에 의해서, 계속 해서 서비스에 대한 신규 요구 사항은 나오게 되고, 새로운 변경 요건은 신규 개발과, 테스트 배포 그리고 지속적인 운영을 요구 하게 된다.

 

 

 

 

그런데, 근래의 서비스들의 경우에는 빠른 비즈니스 환경 변화에 따라가기 위해서 많은 변경 요구하게 되고, 이는 필연적으로 잦은 변경 배포를 요구 하게 된다. 제대로 많은 변경으로 인하여 제대로 테스트 시간을 거치지 못한 애플리케이션의 경우에는 잦은 장애를 유발한다.

이런 배경으로 인해서 운영팀은 잦은 배포를 꺼려하게 되고, 조금 더 전통적이고 형식적인 관점에서 주기적인 릴리즈와 테스트를 요구하게 된다. 애플리케이션단에 문제가 있다 하더라도 긴급 배포가 어려운 경우가 많고, 긴급 배포를 했다 하더라도, 개발팀의 실수를 뒷처리 하는 입장으로 인식하기 때문에, 계속 해서 개발팀과 운영팀의 관계는 악화 되어 간다.

 

그러면 해결책은?

그렇다면 구조적으로 이렇게 개와 고양이처럼 앙숙일 수 밖에 없는 개발팀과 운영팀과의 관계는 어떻게 해결 할 것이며, 이 문제로 인해서 발생하는

–         서비스 요구 사항의 신속한 반영의 문제

–         고객의 요구 사항에 민감한 소프트웨어 개발

문제들은 어떻게 극복할 수 있을까?

 

Solution 1. 잘 협업 하자  - 기획과 개발을 합치자.

답은 간단하다. 기획,개발,운영 모두 사이좋게 지내면 된다. 어떻게 사이좋게? 서로 대화도 많이하고 팀웍을 잘 다지면 된다. 이런 활동의 일환으로 시작된 것이 애자일 방법이다. 기획팀과 개발팀을 하나의 팀으로 합쳐서, 요구 사항 변화에 빠르게 반응할 수 있는 구조로 바꾸고, Iterative 개발(반복적)과, Short Release를 이용한 잦은 릴리즈를 통해서 비즈니스의 요구 사항을 신속하게 반영하고, 변화에 잘 대응할 수 있는 구조를 갖추는 것이다.

 

Solution 2. 개발과 운영을 합쳐 버리자. (Devops)

첫번째 솔루션은 분명히 좋은 방법이긴 하지만, 조금 더 최적화 시킬 수는 없을까? 애자일 방법론을 적용해도 여전히 운영과 개발은 앙숙인 관계이다. 그렇다면? 기획과 개발을 합쳐 버렸듯이,

 

이 좋은 개념을 왜 이제야?

간단하게 개발과 운영을 합쳐 버리면 될텐데, 이걸 왜 이제서야 할까? 결론부터 이야기 하면, 예전에는 어려웠다. 개발과 운영은 영역 자체가 매우 상이하고, 요구 되는 기술 능력도 많이 차이가 나기 때문에, 일반적인 엔지니어가 양쪽을 모두 커버하기가 어려웠다.

또한 기술 자체에 대한 습득 경로가 교육이나 서적으로 제한 되어 있었고, 인터넷을 통해서 요즘 처럼 이렇게 쉽게 정보를 얻기가 어려웠다.

 

인터넷의 발전

인터넷은 더욱더 발전해서, 내가 필요한 자료는 인터넷에서 찾을 수 있을뿐만 아니라, 오픈소스 커뮤니티에서 남들이 만든 코드를 보고 배울 수 도 있고, YouTube에서 강의를 들을 수 도 있으며, Slideshare에서 요약된 PPT를 볼 수 도 있다. 지식을 습득할 수 있는 채널이 다양해지고, 쉬워졌다.

 

오픈 소스의 발전

인터넷이 발전되면서, IT의 흐름이 크게 바뀐 것중에 하나는 더 이상 오라클이나 IBM과 같은 대형 벤더 주도의 기술이 아니라 페이스북이나 구글과 같은 거대 B2C 서비스가 IT의 흐름을 이끌기 시작했고, 이러한 업체들이 오픈소스를 적극적으로 후원 및 장려하기 시작했다. 오픈 소스를 통해서 전세계의 개발자들과 함께 이야기를 할 수 도, 일을 할 수 도 있고,  또 오픈 소스를 잘하면 이런 구글이나 페이스북과 같은 좋은 회사에도 취직할 수 있다. 그래서 개발자들이 오라클이나 SAP와 같은 엔터프라이즈 제품을 공부하지 않고, 오픈소스를 개발하면서 “논다(enjoy~)”

 

오픈소스 Stitching

이렇게 오픈소스가 발전하다 보니, 요즘 개발은 하나의 프로그램 언어로 하나부터 열까지 모두 개발하는 것이 아니라, 여러 오픈소스들을 모아다가 합쳐서, 하나의 서비스를 만드는 형태로 바뀌고 있다. 

이제 모두 내가 개발할 필요도 없이 찾아서 조합 하면 되고, 문제가 있는 오픈소스는 내가 직접 고치거나, 오픈 소스 개발자들에게 부탁해서 수정을 할 수 있다. 솔루션에 대한 선택 기회가 넓어지고,  코드 자체 개발 뿐만 아니라, 효율적으로 오픈소스 솔루션을 조합 및 구현하는 개발 형태의 중요성이 높아지고 있다.

 

좋은 도구들

오픈소스의 발전으로 이루어진 혜택중의 하나가, 좋은 툴이 많아 졌다는 것이다. 개발에 관련된 툴 뿐만 아니라, 빌드,배포에 대한 툴과, 모니터링에 대한 툴도 많아졌기 때문에, 운영 업무에 해당 하는 이런 부분을 상당 부분 자동화를 할 수 가 있다.

 

클라우드의 등장

클라우드 컴퓨팅의 가장 큰 특징 중의 하나는 사용자가 인프라 (서버 설치, 네트워크 케이블 구성) 구성할 필요가 없이, 간단하게 책상 앞에 앉아서 웹사이트를 몇번 클릭 하는 것만으로 지구 반대편의 데이터 센터에 서버, 스토리지 구성, 네트워크 구성이 가능하게 되었다는 것이다.

더 이상 개발자는 새로운 기술을 익히는 데, 책을 뒤져가면서, 새로운 교육을 들어가면서 지식을습득할 필요가 없다. Googling 만 하면 개발에 대해 필요한 자료를 다 얻을 수 있다.

개발을 할때는 필요한 모듈을 오픈 소스를 조합해서 만들 수 가 있으며, 여러가지 좋은 도구들을 통해서 빌드나 배포등을 손쉽게 자동화할 수 있으며, 클라우드를 통해서 개발자도 네트워크, 서버등에 대한 설정들을 할 수 있다. 인프라에 대한 지식이 부족하면 이것 또한 인터넷을 검색하면 된다.  결과적으로 개발자가 할 수 있는 영역이 더욱 더 넓어졌다.

바꿔 말하면, 인프라에 대한 전문 지식이 없이도, 인터넷과 오픈 소스 그리고 클라우드의 도움을 받아서, “운영” 을 겸업 할 수 있는 환경이 마련 되었다는 것이다.

 

---

[1] https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

 

2편 글 링크 - http://bcho.tistory.com/817

출처: https://bcho.tistory.com/815 [조대협의 블로그]