야크쉐이빙 – 데브옵스 (DevOps) 고민하기

평소 아니 가끔씩이지만 진지하게 이야기하게 될 때가 있다. 특히 이상한모임을 같이 이끌어가는 @haruair 님과는 농담과 진지를 백지장 한 장 차이만큼의 거리를 두고 오고가는 아슬아슬한 대화를 하는 편이다. (그런 농담들은 종종 – 혹은 자주 현실이 되곤 한다.) 어쩌다가 얘기가 나왔는지는 가물가물한데, 데브옵스를 지키는 것이 옳은가에 대해서 얘기를 시작해서 조직의 특성에 따라 굳이 지키지 않아도 되지 않을까 하다가 급 마무리. 음. 아마 이틀쯤 지나서 갑자기 이런 키워드에 잠을 못자는 것은 아닌 것 같고. 침대에서 뒤척이다 구글을 뒤적이다 결국 블로그 창을 열었다. 생각을 정리해야 잠을 잘 수 있을 것 같다는 강한 동기로.

아래의 글 대부분 – 내가 쓰는 말투가 아닌 경우에는 내가 쓴 것이 아니다. 발췌문구마다 주석을 달지는 않겠으나, 참고한 글의 출처는 포스팅 하단에 정리해두려고 한다. 이 글이 이상하거나 이해가 안되는 부분은 스스로 찾아보는 것을 추천한다.

데브옵스(DevOps)란?

여러 글을 훑어본 결과, 데브옵스는 애자일 이나 린 개발 만큼이나 사람들마다 정의도 다르고 개념도 다른것 같다.

데브옵스(DevOps, 개발(Development)과 운영(Operations)의 합성어), 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발방법론. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

위는 위키피디아 한국어 설명의 전부다. 진짜…!@#$%

The specific goals of a DevOps approach span the entire delivery pipeline. They include improved deployment frequency, which can lead to faster time to market, lower failure rate of new releases, shortened lead time between fixes, and faster mean time to recovery in the event of a new release crashing or otherwise disabling the current system. Simple processes become increasingly programmable and dynamic, using a DevOps approach. DevOps aims to maximize the predictability, efficiency, security, and maintainability of operational processes. Very often, automation supports this objective.

그나마 영문판 위키피디아의 설명에서는 개발 전체적으로 배포, 낮은 에러율, 릴리즈관리 등을 데브옵스 접근법으로 점차 동적 프로그래밍 시켜서, 운영 프로세스의 예측성, 효율성, 보안성, 관리성을 최대화하는 것을 목표로 하는 것이라고 구체적으로 기술하고 있다.

Burgess는 데브옵스가 단지 툴들이나 기술에 대한 것이 아님을 명확하게 말했다. “협동은 컴퓨터나 프로그래밍과 전혀 관계가 없다. 협동의 원칙은 정보 교환과 그 목적의 보편적인 문제다.” 협동, 정보교환, 그리고 네트워크 목적은 다른 무엇보다도 더 문화적인 이슈들이다. 마찬가지로 Sussna의 “공감”이란 개념도 이해(다시 말해서, 정보 교환)이며, 이해는 문화적 이슈이다.

기반 체계, 시스템 관리자 및 기업의 IT 부서를 담당한 사람들은 발전해서 그들의 기반 체계를 유지할 수 있는 코드를 작성할 수 있다. 고립되기 보다는, 애플리케이션을 만든 개발자와 협동하고 협력할 필요가 있다. 이런 움직임이 비공식적으로 알려진 “개발운영(DevOps)”이다.

결국은 데브옵스에서 옵스는 – 우리가 한국에서 흔히 개념화되어 있는 사용자를 대응하거나 컨텐츠를 제작해서 딜리버리하는 운영팀이라기보다는 – 개발 전반을 관리하는 운영을 말한다고 봐도 될 것 같다. (잘은 모르지만, 게임쪽에서 나누는 라이브 운영(개발)과도 다른것 같다)

작은 회사에서는 개발팀이 다 품고 있을 업무들, 대표적으로는 QA, 인프라관리, 자산관리 등이 있을 것이고. 결국 소프트웨어 개발과 기술업무지만 비개발파트가 함께 움직여야 한다는, 그래서 그들이 유기적으로 움직일 수 있도록 공감 형성과 개발문화가 중요하다고 이야기 하는 것이다.

데브옵스에서 책임이란?

개인적으로는 읽었던 글들에서 가장 크게 다가왔던 키워드 중에 하나가 책임이었다. 동적 프로그래밍을 통해 그 많은 것을 자동화 한다고 한들, 그것에 대한 퀄리티를 누가 책임질 수 있을까? 그런 프로세스에서의 크리티컬한 문제는 결국은 ‘휴먼에러’가 원인이 되는 상황에서는 그 때는 누구에게 책임을 묻는가?

프로그래밍을 조금 잘못해서 작은 문제가 생길 수 도 있지만, 그게 정말 회사에 있어 크리티컬한 이슈가 되었을 때는 분명 누군가는 책임을 져야할텐데? 장기적으로는 데브옵스 접근이 옳으나, 당장의 단기적인 그리고 개인적인 책임 소재가 발생했을 때의 부담감을 이겨낼 사람의 비율이 얼마나 될까? 운영은 없어지지않으며 책임은 전가될 때, 서버관리자없다면 당연히 서버개발자가 서버관리자의 역할도 해야되는 것 아닌가?

책임을 공유하는 것은 또 다른 이익을 가져온다. 장애가 나쁜 코드에 의한 것인지, 운영 실수에 의한 것인지 밝해내려 애쓰는, 서로를 손가락질 하는 사후 분석보다는 운영과 개발팀이 함께 장애를 해결하는 사후 분석이 누군가를 탓하는데 집중하기 보다 앞으로 시스템을 보다 견고하게 만드는데 집중할 수 있도록 해준다.

결국은 우리 모두의 책임이라는, 그리고 그렇게 하는 편이 모두에게 좋다는 공감이 필요할 것 같다. 무엇보다 그러한 일이 있을 때마다 사후 분석을 하고 다시 예방해나가는 것을 반복하는 것으로 모두의 책임이라는 것이 학습되어야 될 것같다. 긴 싸움이 되겠군

이런 조직에서 나는?

데브옵스의 정의로만 보자면 나는 아예 조직밖으로 던져지는 사람이나 마찬가지다. 평범한 기획자로서 일하는 프로덕트 매니저가 끼여들 여지는 많지 않아 보인다. 기획을 하긴 하지만, 기획자의 고집을 부리기보단 디자이너, 개발자의 이야기를 더 많이 들어 고집을 꺽는 축에 속하고. 사용자편에 서기에는 내가 그들과 완전히 공감하지는 않는다.(라이트유저와 헤비유저의 차이쯤?) 프로젝트 매니저긴 하지만 관리자라 하기엔 플젝 성공여부에 대한 책임도 지지 않고, 운영자긴 하지만 소프트웨어 개발을 운영하거나 관리하지는 않는다.

커뮤니케이션을 하고는 있지만, 비전과 전략같은 것과는 커뮤니케이션 하고있지도 않다. 그나마 가까운건…. 서비스 설계? 그냥 모바일 서비스 제네럴리스트가 제일 맞을 것 같기도 하고. 제네럴리스트도 필요하다고 말해줄 사람?ㅠㅠ

이런 사람이 어떻게 하면 데브옵스라는 조직에 좀 더 녹아들 수 있을까? 팀이 3-5명 소수일 때에는 그나마 함께한다는 느낌도 있고 개발 이외의 것들은 내가 맡는다는 책임감으로 맡은 일에 최선을 다해왔지만, 조직이 클수록 그리고 개발자의 색이 진한 곳일수록 나의 색을 점점 잃어버려 쓸모없는 사람으로 일한다는 기분이다. 그냥 잡부. 비싼가게에서 허드렛 일하는 아르바이트생. 평생을 이렇게 일할바엔 더 많이, 더 깊게 공부해서 시스템 설계 쪽으로 빠지든지 아예 IT조직에서 나가서 개발이외의 일들을 하든지 하는게 나을 것 같지?

글이 산으로 가는 것 같으니 마무리를 지어야겠다.

• 내가 생각했던 옵스는 데브옵스의 옵스와는 분명히 달랐고,
• 나의 포지션과 역할과 책임은 개발조직과는 거리가 상당하다는걸 (다시 + 정확히) 깨달은 것 같고,
• 아무리 케바케라도 IT 조직이라면 데브옵스 방향이 옳은 것으로 생각을 바꾸었다.

@justinchronicle 님이 올해 호주에서 개발 컨퍼런스의 주제는 운영이었다고 했던 얘기도 기억났으니, 내년에는 이런 주제들을 다루는 글도 쓰고, 세미나도 열어봐야겠다는 To do 를 쌓아두는 걸로, 이제 진짜 자야겠다.

읽었던 글

• 데브옵스(DevOps)가 무엇인지에 대한 재조명
• 데브옵스(DevOps)란 무엇인가?
• IT용어풀이 | 데브옵스(DevOps)
• 위키피디아 – DevOps
• 개발과 운영의 조화 – Devops #2/2
• How ‘DevOps’ is Killing the Developer

글 : 강미경
원글 : http://minieetea.com/2015/11/archives/4240