기본적으로는 책 내용에 대한 감상을 얘기하지만, 약간의 배경지식을 설명하기도 하기 때문에 제목을 좀 색다르게 지어봤다.

소설 읽기 전 알고 있으면 좋은 것들

이 영상을 반드시 봐야 한다. "봐두면 좋다"가 아니라 "봐야 한다"인 이유는 소설 중간에 대놓고 언급하는 것을 알게 되었기 때문이다.

이 영상은 2009 년의 발표이고, 오늘날 Devops 라고 부르는 무언가를, 공개적으로 소개한 최초의 영상들 중 하나다. "하루에 10번 배포하기"가 이때는 "말도 안되는 것"이었던 시대의 이야기다.

근데 저 영상을 이해하려면 하나 더 알아둬야 하는게 있다. 나를 포함한 오늘날 청소년(?)들은 상상하기 어려운 예전 IT 부서의 모습을 말이다:

개발팀 : 스프링 서버를 만든다. jar 파일로 빌드한다. 운영팀에 전달한다.
운영팀 : jar 파일을 미리 보유중인 서버에 띄운다. 모니터링한다. 

운영팀 : 메모리 릭을 발견한다. 개발팀에 코드 수정을 요청한다.
개발팀 : 그런 일 없다고 한다. 서버 하드웨어 이슈가 의심된다고 회신한다.

이것이 2000년대 전후의 세계 최첨단 IT 시스템이었던 것이다. 이러한 맥락을 알고 있어야 저 영상이 이해가 되고 이 책이 이해가 될 것이다.

본격적인 감상 이야기

"와, 정말 재밌다!"

솔직히 몇몇 부분은 정말 이해하기 힘들었다. 구체적으로 말하자면, NAS 서버의 장애가 대체 무엇을 말하는 것인지 감이 오지 않았다. 약간 체코 소설을 읽으면서 이 사람들은 문화가 좀 다른가...? 그런가보다.. 하고 넘어가는 것처럼, 구체적인 사건들의 영향도나 원인이나 심각도에 대해선 그냥 추측하면서 와 심각한 문제가 터졌나보다~ 하면서 읽어내려갔다.

그럼에도 불구하고, 흡입력이 굉장하다. 주인공 빌은 부서장이 되자마자 서너가지 "심각한" 장애를 보고받기 시작하는데, 그야말로 온 사방 천지가 불길인 세상에서 뭐부터 해야 하는지 혼란스러워하는 모습이 그대로 느껴졌다.

책의 처음부터 끝까지, Devops 라는 표현은 나오지 않는다. 그리고 운영팀과 개발팀이 한 몸이 되는 일도 벌어지지 않는다. 다만 그들이 소통하는 방식, 협업하는 방식이 조금씩 변해간다. 그 모습이 참 멋있고 예쁘고 심금을 울린다.

즐거운 구절들

• 정보 보안팀은 조직의 다른 부서에 어떤 결과가 생길지 생각하지도 않고 항상 사람들에게 거들먹거리며 긴급한 요구를 해댄다. 그래서 우리는 웬만하면 보안팀을 회의에 부르지 않는다. 어떤 일이 일어나지 않도록 하는 제일 좋은 방법이 보안 쪽 사람들을 방에 가만히 두는 것이기 때문이다. 정보 보안팀은 우리가 무엇을 하든 간에 외계에서 온 해커가 조직 전체를 약탈한다고 여긴다.

(보안팀이 진짜 해야할 '일'은 먼 뒤에서 나온다)

• 나는 조용히 끄덕이고 더는 말하지 않았다. 평소에 <라이언 일병 구하기>에 나오는 문구를 좋아했다. '여기 지휘 계통이 있다. 불만은 위로 올라가지, 아래로 내려가지 않는다."

• "한 가지 확실한 건," 에릭이 작업대를 가리키며 말을 이어갔다. "가고자 하는 곳으로 가려면 저 작어 대와 같은 것이 무엇인지 알아내야 하네. IT 운영으로 작업 릴리스를 제어하는 방법을 알아내야 해. 무엇보다 더 중요한 것은 자네가 가진 자원 중 가장 제약이 많은 자원이 하나의 사일로가 아니라 전체 시스템의 목표를 제공하는 작업만을 수행하고 있는지 확인해야 하네."

• "이제 네 가지 유형의 일이 무엇인지 말해 줄 수 있을 것 같은데?" 에릭이 물었다. "네, 그럴 수 있을 것 같습니다." 나는 자신있게 대답했다. "공장에서 한 가지 카테고리로 피닉스 같은 비즈니스 프로젝트를 얘기해주셨죠. 나중에 내부 IT 프로젝트를 언급하지 않은 것을 깨달았습니다. 그로부터 저는 변경이 또 다른 유형의 일이라는 것을 깨달았습니다. 하지만 피닉스 문제가 일어난 후에야 마지막 유형을 알 수 있었습니다. (...) 계획하지 않은 작업 말입니다."

• "(Flickr의) 올스퍼는 개발을 의미하는 Dev와 운영을 의미하는 Ops가 QA, 비즈니스와 더불어 일하면 놀라운 것을 이룰 수 있는 조직이 된다는 사실을 우리에게 가르쳐 줬지. 또한 코드가 생산되기 전까지는 단지 시스템에 WIP가 틀어박혀 있는 것이기 때문에 어떤 가치도 실질적으로 생성되지 않는 것임을 알았지. 그는 빠른 피처 흐름을 활성화하도록 배치 크기를 계속 줄였어. 한편으로는 환경이 필요할 때마다 항상 사용할 수 있도록 그렇게 했지. 그는 개발 부서가 완성하는 애플리케이션처럼 인프라를 코드처럼 처리할 수 있다는 것을 인식하고 빌드 및 배포 프로세스를 자동화했어. 그렇게 해서 그는 한 단계로 환경 조성 및 배포 절차를 통합할 수 있었지. 우리(공장)가 한 단계로 도색과 양생을 하는 방법을 알아낸 것처럼 말이야."

• 그동안 개발자들이 얼마나 변덕스러울 수 있는지 잊고 있었다. 내가 보기에 그들은 엔지니어라기보다 인디 뮤지션 같았다.

• 나는 내심 웃었다. 이번에는 뭔가 잘못돼서 우리만 밤을 새우는 건 아니다. 사실 정반대다. 모든 일이 잘되고 있어서 사람들이 밤을 새우고 있다.

• 아이러니하게도 개발자 중 한 명이 우리가 그동안 만드느라 정말 고생했던 실시간 추천 기능을 모두 없애자고 제안했다. 그는 고객이 구매할 수 없다면 더 많은 제품을 추천할 이유가 없다고 주장했다.

(여기서부턴 소설 뒤의 부록이다)

• 러츠는 두 종류의 브렌트가 있다고 햇다. 비축자와 공유자.

이 뒤엔 (피닉스 프로젝트의 정신적 뿌리에 해당하는 듯한) 데브옵스 핸드북이라는 책에서 발췌한 챕터들이 있는데, 그 책을 볼 때 정리하는게 나을 것 같아서 따로 여기에 기록하진 않겠다. 대신 중요한 이미지가 하나 있어 이것만 남겨둔다:

데브옵스를 위한 세 가지 방법

(지금 눈치챘는데, Dev 를 비즈니스에, Ops 를 고객에 빗대고 있다)

• 비즈니스가 더 빨리 고객에게 전달되도록 가속화
  • 작업 시각화 (칸반 등)
  • WIP 제한
  • 배치 크기 줄이기
  • 이관 작업 줄이기 (맥락 소실 줄이기)
  • 제약 사항을 지속적으로 식별하며 상황 개선하기
• 오른쪽에서 왼쪽으로, 지속적인 피드백고리를 형성 (feed-back & feed-forward)
  • 텔레메트리 구축
  • 빠르게 문제 해결을 위해 모두가 노력 (스워밍 등)
  • 품질을 다이렉트로 관리 (승인/대기를 줄이기)
  • 추후 동일 작업을 대비한 프로세스 최적화
• 더 빨리 실험하고 더 자주 실패하고 더 많이 배우도록, 조직적 학습을 지원한다
  • 실패해도 비난하지 않는 문화, 배우는 문화 만들기
  • "일상 업무보다 더 중요한 것은 일상 업무의 향상" - 일상 업무의 개선을 제도화
  • 암묵적 지식을 명문화된 지식으로 만들어 전파
  • 일상 업무에 resilience 를 유도하는 환경을 조성 (카오스 몽키 등)
  • 서로 의지하는 지도자와 직원의 관계를 형성

p.s.

한국판 피닉스 프로젝트: