Hacking Culture by Jesse Robins
QCon San Francisco 2012에서 Chef로 유명한 Opscode의 공동창업자인 Jesse Robins가 발표한 내용입니다. Chef나 Opscode에 대한 홍보가 섞여있고, 내용은 어디선가 들어봤을 법한 내용들이었지만, 자신의 이야기를 곁들여서 재미있고 한층 더 마음에 와닿게 설명을 하고 있는 것 같습니다.
Velocity 2009
요즈음 유행하고 있는 DevOps라는 개념이 처음 나온 것은 Velocity 2009에서의 John Allspaw가 발표한 “10 Deploys per Day: Dev and Ops Cooperation at Flicker” (Slides)라는 강연입니다. Jesse Robins의 강연도 이 강연의 일부 내용을 다시 소개하고 있는 것 같군요.
Continuous Delivery
장기간에 걸친 커다란 변경은 위험하기 때문에 작은 양의 코드를 좀 더 자주 배포해야한다는 개념을 Change monster라는 그림을 통해 설명하고 있습니다.
결국 더 빠르게 비즈니스 가치로 이어지고, 버그를 방지할 수 없는 한 버그를 더 빨리 고칠 수 있으며, 개발자들은 자신이 변경한 것을 바로 볼 수 있기 때문에 즐겁게 일할 수 있다는 내용입니다.
DevOps
‘테스트는 통과했으니 이제 운영자의 책임이야’, ‘제가 필요로 하는 권한이 없어’ 같은 전통적인 개발-운영의 문제를 풀기 위해서는 단지 도구가 아니라 서로 신뢰하는 환경이 필요하다고 얘기하고 있습니다.
조직 구조가 제품의 구조를 결정한다는 얘기를 Conway’s law를 빌려 이야기 하고 있습니다.
하나하나 설명하기는 힘들지만, 아래의 그림 한장이 DevOps의 전체 스택을 보여주는 것 같군요.
Changing Culture
Toyota Production System (이하 TPS)이 한창 유행할 때 모두가 이를 벤치마킹해서 똑같은 시스템을 만들었지만, 가장 핵심적인 요소라고 할 수 있는 누구든지 문제의 해결을 위해서 라인을 정지시킬 수 있는 것은 따라하지 못했다고 얘기하면서 문화의 중요성을 강조합니다.
문화를 바꾸기 위한 다섯가지 조언을 하고 있습니다.
1. Start small, build trust & safety
작은 것은 위협도 되지 않거니와 무시해도 좋다고 생각하기 때문에 거부감을 가지지 않습니다. 사람들에게는 그저 실험이라고 얘기하라고 하고 있습니다.
2. Create champions
자신이 일으키는 변화를 신뢰하고 지원하는 관리자가 있어야 합니다. 그리고, 주변 사람들 모두에게 credit을 주고, 변화와 관련된 사람들에게 특별한 상태 (예를 들어 ‘이달의 직원’)를 주어 그들이 새로운 변화에 대해 더욱 많은 이야기들을 하도록 해야합니다.
3. Use metrics to build confidence
변화를 지지할 수 있는 KPI (예를 들어, MTTR)를 찾아서 그것을 통해 사람들에게 가치를 보여주고, 나중에는 변화하지 않을 경우의 비용을 보여주는 용도로 사용합니다. 사람들에게 변화와 관련한 이야기를 들려줄 때 데이터를 가지고 이야기합니다.
4. Celebrate successes
사람들과 문제를 극복한 사례에 대해 긍정적인 면을 이야기 합니다. 절대로 문제를 만들어낸 사람들에 대해서는 이야기 하지 않습니다.
5. Exploit compelling events
언젠가는 변화를 위한 중요한 기회가 자연스럽게 찾아오게 됩니다. 중요한 것은 이 때 ‘I told you so’가 아니라 ‘What do we do now’라고 이야기할 수 있어야 합니다.
Hacking Permission
어떤 사람들은 스스로의 시간을 털어서 다른 사람들에게 도움이 되는 옳은 일을 하려고 하지만 보통 권한이 없기 때문에 그렇게 하지 못합니다. 그들에게 “site directors”와 같은 권한을 주라고 얘기합니다.
Don’t Fight Stupid, Make More Awesome
이 강연에서도 언급했다시피 변화를 일으키는 것에는 많은 시간과 인내심이 필요한데, 이 문구를 되새기면 언제든지 다시 힘을 낼 수 있을 것 같은 느낌이군요.
