데브옵스 핸드북을 읽고

책 전면

왜

4월부터 배포 파이프 라인을 관리하는 일을 시작했다. 따라서 직무를 둘러싼 줄기를 일단 파악하려고 산 책이다. 개인적으론 데브옵스를 IT만의 이슈라고 생각했는데 책의 내용을 보면 도요타에 대한 이야기가 참 많이 나오는 게 대학시절로 돌아간 기분이 들었다. 도요타는 현대적 제조업 경영의 스탠더드를 성립한 회사였고 그 지위를 아직도 뺏기지 않은 최고의 프랙티스다. 최근엔 테슬라를 공부해본 투자자들이 SW뿐만 아니라 제조관리도 테슬라의 강점이 있다는 이야기를 들었는데 나중에 별도로 공부해볼 만한 이슈다.

누구를 위한 책

그렇다고 이 책이 공장을 포함하는 광범위한 범위를 다루는 책은 아니다. 이 책을 통해 향상하려는 프랙티스는 분명히 IT서비스 개발과 운영이다. 나아가 고객에게 가치를 Delivery 하는 최종 접점을 향하여 조직운영을 혁신하는 방법을 다루는 책이다. 여기엔 개발과 배포를 어떻게 할 것인지에 대해 필요한 원칙, 전술적 방법, 전략적 지향점이 포함되어 있다. 따라서 이런 실행을 위해 사용되는 오픈소스나 방법론 소프트웨어 이념 등이 짤막하게 등장할 뿐이지 코드나® 코드를 짜는데 참고할만한 플로우 차트는 일절 없다. (사실 핸드북이라길래 그런 것도 있는 줄 알았다) 이 책은 조직운영에 대한 이야기가 주류를 이룬다. 주니어들도 읽어보면 도움은 될 수도 있지만, 조직의 문화를 관리하며 관행을 컨트롤할 수 있는 위치에 있는 이사들이나 시니어들에게 필요한 조언이 중심이 된다. 물론 팔로워도 자신들이 뭘 팔로우하는 건지는 알아야 하지 않겠는가. 때문에 이 책은 누구에게나 도움이 될 거라 생각한다.

이 책에서 제시하는 전략의 큰 덩어리

• (개발에서 고객까지) 작업흐름을 가속하기
• (고객에서 개발까지) 피드백을 가속하기
• (실패할 때만 배우는 건 부족하다) 학습과 실험을 유발하기

끝! 핵심만 따지면 이거다. 그리고 나머지 덩어리들은 논지를 부드럽게 하고 전략을 완성하기 위한 전술들의 나열이다. 그리고 거기 포함된 주요한 키워드들은 다음과 같다.

유의미한 개선 목표 설정, 콘웨이의 법칙, WIP 리밋을 걸기, 배치작업 크기 줄이기, 느슨하게 연결된 컴포넌트 설계, 스워밍 활동, 6개월 전에 망가뜨린 것을 책하지 말고 몇 분내에 피드백을 제공하기, 휴먼에러를 배제하는 설계(건프라 조립을 해보면 이런 게 보인다), 비난 없는 포스트모템, 지역적 발견을 전체의 개선으로 전환(미 해군 원자로 운영에 쓰는 지식공유체계 사례가 나온다), 카오스 몽키, 게임데이, 리더와 팔로워는 서로를 필요로 한다(리더는 실무를 하지 않고, 팔로워는 일의 맥락과 권한이 없다), 그린필드, 브라운필드, 가장 혁신적인 그룹부터 데브옵스를 시작하라, 작은 물고기는 작은 연못에서 큰 물고기가 되는 법을 배운다, 가치흐름 매핑 생성, 개선활동은 기술 부채를 제거하기 위한 세금, 두 달 동안 신규 기능 개발을 중단하겠다고 말해야 했던 리더의 용기, 팀원들이 제너럴리스트가 되어야 한다, 긍정적 혼란의 촉진, 피자 두 판의 법칙, 자체 서비스 운영 플랫폼이 없으면 클라우드는 비싼 호스팅 2.0, 개발회의에 운영을 초청하기, 자동화할 수 있는 업무, Singgle source of truth, 복구보다는 재구축이 쉬운 인프라가 좋다, 테스트 자동화를 위한 설계, 두려움은 정신의 살인범, 안돈 코드, 병합 난이도를 올리는 기존 깃 플로우, 트렁크 기반 개발 패러다임(이 책에서 가장 재밌게 봤던 부분이다), 배포 프로세스 자동화를 위한 전술, 스모크 테스트, 개발에게 셀프 배포를 할 수 있게 하라, 블루-그린 배포 전략, 여러 버전의 앱을 요청을 다 처리할 수 있도록 유연하게 구성, 다크런치, 페이스북 게이트키퍼, 마이크로 서비스, 교살자 애플리케이션 패턴, “모든 상황에 적합한 아키텍처는 없다. 서비스 크기가 x1 x10 x100 이 될 때마다 각각의 답이 존재한다”, culture of causalty, LRR과 HRR의 사용 - (운영으로 핸드 오프전 사전 체크리스트의 운영), A/B 테스트, 모든 활동에 달러 가치를 부여한 CEO, 변경 크기와 위험은 비선형적 관계에 있다. 자주 통합을 해야 하는 이유, just culture(고의가 아니면 용서한다), 프로덕션에 실패 주입, “지속 가능한 경쟁우위는 더 빨리 배우는 능력뿐”

트렁크 기반 개발

하나하나 다 소개할 수는 없고 생각이 다 이야기할 수는 없다. 상당히 광범위한 내용을 다루는 책이다 보니 무엇을 앵커로 잡아야 할까 고민이 많이 되는데 지금 당장 머릿속에 강렬하게 남은 이미지는 트렁크 기반 개발 패러다임이다. 지금까지 깃 플로우 말고 다른 전략이 있다고 생각도 못하고 있었는데 HP 프린터 개발자들이 도입한 이 전략은 논쟁적이나 이 책에서 좋다고 추천하고 있다.(더 찾아보니 무려 역사가 20년!! 짧다면 짧다) 트렁크 기반 개발을 하면 기존 깃 플로우와 다른 점은 다음과 같다.

• 기능 개발, 디버그 등 작업별로 브랜치를 만들지 않는다.
• Trunk(Main, Master)에 직접 커밋한다.
• 브랜치가 생성되는 유일한 지점은 운영으로 배포할 때다.

이 전략은 작업의 격리성을 떨어트려 작은 변경이 개발자 모두에게 영향을 끼치게 된다. 하지만 별도의 머지 작업이 없고 관리 포인트를 극단적으로 줄여준다. 따라서 이 전략을 쓰는 팀은 각각의 커밋이 유효하게 동작할 수 있도록 유기적으로 협력을 해야 하고 안전을 위한 다음의 룰을 준수해야 한다.

• 상시적 페어 프로그래밍
• 커밋된 트렁크가 항상 빌드될 수 있음을 보장하는 효과적 파이프라인
• 소규모 배치 작업

굉장히 매력적이고 충격적인 작업방식인 만큼 트렁크 기반 개발은 개인적으로 더 공부해볼 예정이다.

직무 융합의 시대

데브옵스를 바라보는 이 책의 내용에서 한 발자국 물러나 이 책이 설명하고 있는 전략에 대해 이야기해보자. 개발과 운영이 더 긴밀하게 붙는 현상. Convergence라 불러도 손색이 없는 트렌드는 devops에서만 벌어지는 일이 아니다. 아니라 개발자 내에서도, 아티스트 업에서도, 영업과 PR에서도 벌어지고 있다고 들었다. 내가 생각하기에 원인은 다음과 같다.

• 기술의 발전으로 한 사람이 더 많은 일을 할 수 있음
• 직무의 명확한 구분에서 오는 이익보다 일을 다음 사람에게 전달하고 피드백하는 비용이 더 큼
• 명확한 구분이 필수적인 책임과 계약을 중심으로 이뤄지는 활동은 관료화의 원인
• 느슨한 결합과 그 결합을 조율하는 융합적 인간과 조직 구성이 생산성 향상에 도움이 됨.

융합의 시대에 나는 뭘 할 수 있을까? 어디로 가야 할까? 스페셜리스트를 지나 다시 제너럴리스트의 시대? 제너럴 한 것은 비용을 줄이는 접근(예를 들어 AI)에서 자유로울 수 없으니까. 그런 고민이 깊어지는 밤이다.