2016년 DevOps Dozen Award에서 ‘Best DevOps Book of the Year’ 수상!
데브옵스의 모든 것을 다루는 책이다. 데브옵스의 유래부터 개념과 데브옵스 실천방법과 사례까지 모두 다루고 있다. 소프트웨어 업계의 구루라 부를 수 있는 저자들이 함께 저술한 이 책은 데브옵스를 이해하는 데 필요한 세 가지 원칙부터 아마존, 구글, 페이스북 등 누구나 알만한 기업들에서 경험한 40가지 이상의 실제 사례와 데브옵스 적용에 필요한 실천방법을 소개한다. 이 책을 통해 데브옵스가 무엇(What)인지 이해하고 데브옵스를 적용하는 방법(How to)도 자연스럽게 익힐 수 있을 것이다.

과거에는 엔지니어링의 여러 분야가 일종의 눈에 띄는 진화를 겪으며, 지속해서 자체 작업에 대한 이해를 “평준화”했다. 특정 엔지니어링 분야(토목, 기계, 전기, 원자력 등)를 두고 있는 대학 교육 과정 및 전문 지원 조직이 있지만, 사실 현대 사회에는 모든 엔지니어링 형태의 장점을 인식하고 여러 전문 분야에 걸쳐 작업할 수 있는 엔지니어링이 필요하다. 고성능 차량 설계를 생각해 보자. 기계 엔지니어의 작업은 어디서 마쳐야 하고, 전기 엔지니어의 작업은 어디서 시작해야 할까? 공기역학 분야의 지식을 가진 사람(창문의 모양과 크기 및 배치에 대해 확실히 체계화된 의견을 갖춘 사람)은 승객 관련 인간공학 전문가와 어디서, 어떻게, 언제 협력해야 할까? 차량 수명에서 엔진과 변속기 재질에 미치는 연료 혼합물과 기름의 화학적 영향은 어떠한가? 자동차 설계에 관해 할 수 있는 다른 질문들이 있지만, 최종 결과는 같다. 현대적인 기술 활동을 성공하기 위해서는 협업을 위한 다양한 관점과 전문 지식이 절대적으로 필요하다. 하나의 분야가 발전하고 성숙하기 위해서는 분야의 기원을 신중히 반영할 수 있는 지점에 도달해야 한다. 그리고 반영된 사항에 관한 다양한 관점을 찾아 통합해서 공동체가 그리는 미래에 유용한 방면으로 적용해야 한다. 『데브옵스 핸드북』은 이러한 관점의 통합을 보여주며, 소프트웨어 엔지니어링과 운영 분야에 대한 관점의 집대성으로 봐야 한다. 독자들이 속한 산업, 조직이 제공하는 제품이나 서비스와 관계없이 모든 경영자와 기술 리더가 생존하기 위해서는 데브옵스 사고방식이 무엇보다도 중요하고 필수적이다.
/2016년 8월 뉴욕 브룩클린에서, 존 앨스퍼(John Allspaw), CTO, Etsy

기술 가치 흐름(Technology value stream), 즉 프로젝트 관리, 개발, QA, IT 운영과 정보 보안에서 업무를 수행하거나 영향을 미치는 모든 사람을 위한 책이다. 대부분의 기술 이니셔티브가 시작되는 비즈니스 리더와 마케팅 리더에게도 도움이 될 것이다. 목표 달성을 위해 기술 조직에 의존해야 하는 비즈니스 리더와 이해관계자라면 이 책에서 가치 있는 내용을 얻어갈 것이다.
더불어 이 책에 기술된 모든 문제(예를 들어, 긴 배포 리드 타임이나 고통스러운 배포)를 경험해 보지 않은 독자도 이 책을 읽어봐야 할 것이다. 운 좋은 위치에 있는 독자도 데브옵스 원칙, 특히 공유된 목표 및 피드백과 지속적인 학습에 관련된 사항을 이해하면 큰 혜택을 볼 것이다.

1부 ‘세 가지 방법’에서는 데브옵스에 대한 간략한 역사와 수십 년에 걸친 관련 지식 체계로부터 얻은 기초 이론과 핵심 주제를 소개한다. 그 후, ‘세 가지 방법’의 상위 원칙인 흐름, 피드백, 지속적인 학습과 실험을 설명한다.
2부 ‘어디서 시작하는가’에서는 데브옵스를 어디서 어떻게 시작하는지 설명한다. 가치 흐름, 조직 설계 원칙과 패턴, 조직적 도입 패턴과 사례 연구 등의 개념도 살펴본다.
3부 ‘첫 번째 방법: 흐름 개선을 위한 기술적 실천방법’에서는 배포 파이프라인의 기반을 구축해서 ‘흐름(Flow)’ 가속 방법을 설명한다. 즉 빠르고 효과적인 자동화 테스트, 지속적인 통합, 지속적인 전달과 낮은 위험도의 출시를 위한 아키텍처 구현을 설명한다.
4부 ‘두 번째 방법: 피드백을 위한 기술적인 실천방법’에서는 ‘피드백’을 가속하고 증폭시키는 방법에 대해 논의한다. 문제를 발견하고 해결하기 위한 효과적인 프로덕션 텔레메트리를 생성하고, 문제를 더 잘 예측해서 목표를 달성하기 위한 피드백을 활성화하며, 개발과 운영이 안전하게 변경 사항을 배포하고, A/B 테스트를 일상 업무에 통합하고, 작업의 질을 높이기 위한 리뷰와 조정 프로세스를 만드는 방법에 관해 이야기한다.
5부 ‘세 번째 방법: 지속적인 학습 및 실험에 대한 기술적 실천방법’에서는 ‘지속적인 학습’을 가속하는 방법에 관해 설명한다. 올바른 조직 문화를 수립하고, 부서에서 새롭게 학습한 사항을 전체 조직의 개선으로 전환하며, 조직 학습과 개선을 위한 시간을 적절하게 확보하는 방법을 설명한다. 6부 ‘정보 보안, 변화 관리, 컴플라이언스의 기술적 실천방법'에서는 일상 업무에 보안 컴플라이언스를 적절하게 통합하는 방법을 설명한다. 보안 통제 예방책의 공유 소스코드 저장소 및 서비스에 대한 통합, 배포 파이프라인에 대한 보안 통합, 더 효과적인 감지 및 복구를 위한 텔레메트리의 향상, 배포 파이프라인의 보호와 변경 관리 목표의 달성에 관해 설명한다.

데브옵스 핸드북(DevOps Handbook)의 집필은 오랜 여정과 같았다. 데브옵스 핸드북의 기획은 2011년 2월 공동 저자들이 주 단위의 스카이프(Skype) 통화부터 시작됐다. 당시 미완성이었던 책 『The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win』(IT Revolution Press)과 함께 데브옵스 분야의 권위 있는 가이드를 만들자는 비전이 있었다.
드디어 5년 후, 2000시간 이상의 작업 기간을 거쳐 데브옵스 핸드북이 출간됐다. 원래 계획보다 다루는 영역이 더 넓어지면서 엄청나게 오랜 시간이 소요됐지만, 집필 과정은 매우 보람찼고 배움으로 가득했다. 우리 공동 저자들에게는 데브옵스가 진정으로 중요하다는 믿음이 있었다. 저자 각각은 직업 이력에서 더 빨리 ‘깨달음의 순간(aha moment)’에 이르렀고, 많은 독자도 이에 공감할 것이라 생각한다.

1999년부터 높은 성과를 내는 기술 조직들을 연구해 왔다. 초기 연구 결과로는, IT 운영(IT Operations), 정보 보안(Information Security), 개발(Development) 등 각 기능 그룹 사이의 경계를 넘어서는 것이 조직이 성공할 수 있는 결정적인 열쇠라는 점을 밝혀냈다. 그러나 각 기능 그룹이 서로 추구하는 목표가 달라서 급속도로 성과가 하락하는 심각한 문제가 발생한 적도 있다. 이 문제를 처음으로 목격했던 때를 지금도 기억한다.
2006년, 대규모 항공 예약 서비스의 아웃소싱 IT 운영 그룹을 관리하는 조직에서 일주일 간 일했다. 해당 조직에서는 운영 중인 서비스에 대한 연 단위 대규모 소프트웨어 출시(release) 다운스트림 결과를 설명했다. “각 출시는 고객뿐만 아니라 아웃소싱 그룹에도 엄청난 혼란과 분열을 일으킵니다. 서비스 수준 계약(service level agreement)에 따라 고객에게 영향을 주는 서비스 정지에는 벌금이 부과됩니다. 그 결과 이윤이 미달돼 뛰어난 역량과 경력을 갖춘 직원들이 정리 해고됩니다. 그러면 남은 직원들은 계획에 없던 작업도 수행해야 하고, 장애 복구 작업도 해야 하므로, 늘어나는 고객의 요구 사항을 처리할 수 없게 됩니다. 중간 관리자가 서비스에 대한 계약 협상을 시작하고, 모든 사람들은 3년 내 재입찰로 인해 현재의 계약이 파기될 것이라고 느낄 것입니다.”
이런 상황에서 오는 절망감과 허무함 때문에 도덕성 회복 운동을 시작하게 됐다. 개발은 늘 전략적으로 보이는 반면, IT 운영은 전술적으로 간주되면서도, 위임되거나 완전히 아웃소싱되는 경우가 많다. 이로 인해, 처음 위임하거나 아웃소싱을 했을 때보다 더 악화된 형태로 5 년 안에 다시 돌아온다.
몇 년 전부터 분명 더 나은 방법이 있을 것이라는 사실을 많은 사람이 알고 있었다. 2009 Velocity Conference에서 아키텍처, 기술 사례, 문화 규범에 의해 가능해진 놀라운 결과들이 소개되면서, 지금은 데브옵스(DevOps)로 알려진 사항들에 대한 많은 이야기가 쏟아져 나왔던 때를 기억한다. 당시 논의된 사항들은 모두가 찾고 있던 ‘더 나은 방법’을 명확하게 가리키고 있었기 때문에 나는 무척 흥분됐다. 그리고 ‘데브옵스’라는 용어가 널리 알려졌으면 한 것이 『The Phoenix Project』를 공동 집필하게 된 개인적인 동기 중 하나였다. 『The Phoenix Project』 책을 보고 많은 커뮤니티가 그들만의 '깨달음의 순간'에 이르는 데 어떤 도움을 받았는지 반응했다. 이를 보면 '데브옵스'를 널리 알린게 얼마나 보람찬 경험이었는지 독자 여러분도 상상할 수 있을 것이다.
/진 킴(Gene Kim)

내게 데브옵스로 인한 ‘깨달음의 순간’이 찾아온 것은 2000년에 스타트업에서 일할 때였다. 그곳은 졸업 후 나의 첫 직장이었다. 기술 직원은 나를 포함한 2명밖에 없었기 때문에 네트워킹, 프로그래밍, 고객지원, 시스템 관리까지 모든 업무를 다 수행해야 했다. 우리는 워크스테이션에서 FTP를 통해 직접 소프트웨어를 프로덕션 환경으로 배포했다.
그 후 2004년에는 ThoughtWorks라는 컨설팅 회사에서 약 70명이 참여하는 프로젝트의 첫 업무를 맡게 됐다. 8명의 엔지니어로 구성된 팀에서 유사 프로덕션 환경(production-like environment)으로 소프트웨어를 배포하는 업무였다. 처음에는 스트레스가 정말 심했다. 몇 달에 걸쳐서, 2주가 필요한 수동 배포를 1시간이면 충분한 자동 배포로 전환했다. 이에 따라 정상 업무 시간에도 블루/그린 배포 패턴(blue-green deployment pattern)을 사용해 1000분의 1초 안에 롤포워드/롤백이 가능해졌다.
이 프로젝트는 『Continuous Delivery』(Addison-Wesley, 2000)와 이 책의 저술에 필요한 많은 아이디어를 얻는 데 필요한 영감을 줬다. 나를 포함한 모두가 이 분야에서 주도적으로 일할 수 있게 만든 힘은 어떤 제약이 있어도, 언제나 더 잘 할 수 있는 방법을 찾는 지식이다. 그리고 모든 과정에서 서로를 돕고 싶어 하는 마음이다.
/제즈 험블(Jez Humble)

내게 있어 데브옵스는 ‘깨달음의 순간’에 대한 집대성이다. 2007년 애자일 팀에서 데이터 센터 마이그레이션 프로젝트를 진행했다. 애자일 팀이 높은 생산성으로 짧은 시간 내 많은 일을 해내는 것이 부러웠다.
나의 다음 업무는 운영에 칸반(Kanban)을 적용해 보고, 칸반의 적용이 팀의 역동성에 어떤 변화를 주는지를 실험하는 것이었다. 이후 Agile Toronto 2008 Conference에서 해당 실험에 대한 IEEE 논문을 발표했지만 애자일 커뮤니티에서 큰 반향을 일으키진 못했다고 느꼈다. 애자일 시스템 관리 그룹(Agile system administration group)을 시작했으나 인간적인 측면을 간과했던 것이다.
2009 Velocity Conference에서 존 앨스퍼(John Allspaw)와 폴 해먼드(Paul Hammond)가 발표한 ‘10 Deploys per Day’를 본 뒤, 다른 사람들도 나와 비슷한 생각을 갖고 있음을 확신했다. 그래서 첫 번째 DevOpsDays 콘퍼런스를 열기로 결심했고, 그 과정에서 데브옵스라는 용어가 탄생했다. DevOpsDays 콘퍼런스의 에너지는 독특하고 전염성이 있었다. 콘퍼런스 덕분에 사람들의 삶이 더 나아졌다고 감사하기 시작하면서 그 영향력을 이해할 수 있었다. 그때부터 데브옵스를 알리는 걸 멈춰본 적이 없다.
/패트릭 드부아(Patrick Debois)

2008년 퍼펫 랩스(Puppet Labs)의 설립자 루크 케니스(Luke Kanies)를 처음 만났을 때, 나는 구성 관리(configuration management)와 모니터링(Tivoli4)에 대한 대규모 레거시 IT 운영 사례에 중점을 둔 컨설팅 비즈니스를 하고 있었다. 루크는 구성 관리(CM)를 주제로 한 O’Reilly Open Source Conference에서 퍼펫(Puppet)에 대해 발표하고 있었다.
처음에는 콘퍼런스장 뒤쪽에서 시간을 보내며, ‘스무 살짜리가 구성 관리에 대해 뭘 얘기할 수 있겠어?’라고 생각했다. 어쨌든 난 말 그대로 일생을 세계에서 가장 큰 몇몇 기업에서 CM과 기타 운영 솔루션에 대한 아키텍트 역할을 하며 일해왔다. 그러나 루크가 발표를 시작하고 5분쯤 지난 뒤 난 맨 앞줄로 이동했고, 내가 지난 20년 간 해온 일이 잘못됐음을 깨달았다. 루크는 지금은 2세대 CM이라 부르는 걸 설명하고 있었다.
발표가 끝난 뒤 루크와 커피를 한잔할 수 있었다. 나는 현재 우리가 코드로서의 인프라(infrastructure as code)라고 부르는 것에 대해 열광했다. 그러나 루크는 자신의 아이디어를 설명하며 더 나아가 운영자가 소프트웨어 개발자처럼 행동해야 한다고 믿고 있다는 이야기를 시작했다. 운영자가 소스 관리에서 구성 사항을 유지하고 워크플로우에 CI/CD 전달 패턴을 도입해야 한다는 것이다. 당시 오래된 IT 운영자였던 나는 “그 아이디어는 레드 제플린처럼 운영자들과 함께 사장될거요.”라고 대답했다. (나는 명백히 틀렸다.)
그로부터 1년 후인 2009년, O’Reilly의 다른 콘퍼런스인 Velocity Conference에서 애자일 인프라스트럭처(Agile Infrastructure)에 관한 앤드류 클레이 샤퍼(Andrew Clay Shafer)의 발표를 보게 됐다. 앤드류는 일을 벽 너머로 던지는 비유적 표현으로 개발자와 운영자 사이의 벽을 보여줬다. 이 상징적인 그림을 ‘혼란의 벽(the wall of confusion)’이라 불렀다. 발표에서 보여준 아이디어는 1년 전 루크가 내게 말하고자 했던 것을 코드화한 것이다. 마치 번쩍이는 아이디어와 같았다. 그 해 말, 나는 겐트(Ghent)에서 열린 DevOps Days에 초대된 유일한 미국인이 되었다. 콘퍼런스가 끝날 무렵, 내 몸속에는 데브옵스의 피가 흐르고 있었다.
/존 윌리스(John Willis)

진 킴(Gene Kim)

여러 번의 수상 경력이 있는 CTO이자 연구원이며, 『The Phoenix Project』(IT Revolution Press, 2018)의 저자다. IT Revolution의 설립자로 DevOps Enterprise Summit Conference를 주최하고 있다.

제즈 험블(Jez Humble)

졸트 상을 수상한 『신뢰할 수 있는 소프트웨어 출시』(에이콘, 2013)와 획기적인 책인 『Lean Enterprise』(O'Reilly, 2015)의 공동 저자다. 효과적인 엔지니어링 사례의 구현을 통해 조직이 가치 있는 고품질의 소프트웨어를 자주, 그리고 안정적으로 전달하는 것을 돕는 데 중점을 두고 있다.

패트릭 드부아(Patrick Debois)

소프트웨어 개발에 애자일 기법과 프로젝트 관리, 시스템 관리를 이용해 프로젝트와 운영 사이의 격차를 해소하는 독립적인 TI 컨설턴트다.

존 윌리스(John Willis)

35년 이상을 IT 관리 업계에서 일해왔다. 여섯 권의 IBM Redbook을 저술했으며, Chain Bridge Systems의 설립자이자 수석 아키텍트다. 현재는Docker, Inc에서 에반젤리스트로 있다.

소프트웨어 관련 모든 분야가 빠르게 변하고 있습니다. 개발 언어부터 프로세스, 개발 조직과 문화 모두가 변하고 있습니다. 데브옵스 또한 이러한 변화 중 하나로 기존의 소프트웨어 개발 방법과 다르게 지속적이고 발전적인, 그리고 협업 중심의 개발자 문화에 중점을 두고 있습니다.
데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 의미합니다. 데브옵스는 소프트웨어 개발조직과 운영조직 간의 협력을 통해 소프트웨어 제품과 서비스를 빠른 시간에 개발하고 배포하는 것을 목적으로 하고 있습니다. 이 책은 데브옵스에 대한 역사와 개념부터 실제 사례까지 전반적인 내용을 포함하고 있어, 데브옵스에 관심 있는 사람이라면 누구에게나 좋은 참고서가 될 것이라 생각합니다.
이 책을 통해 데브옵스의 개념과 더불어, 실제 개발에서 활용 가능한 다양한 개념과 원칙들에 익숙해 지기를 바라며, 이를 토대로 새로운 개발 문화가 만들어지기를 계기가 되기를 바랍니다. 데브옵스라는 새로운 조류를 파악하기 위한 독자들의 노력에 이 책이 조금이나마 도움이 되기를 바랍니다.

김영기

현재 삼성전자 네트워크 사업부에서 SCM을 포함한 개발 인프라를 담당하고 있다. 개발자 역량 강화와 조직 구성, 시스템 관리, 데이터베이스, 테스트와 애자일 등 SW 개발 관련 분야에 대해 초심을 잃지 않으려 노력하고 있다. 지능망(IN)과 모바일 애플리케이션 개발, 정적 분석과 SW 구조 분석 등의 업무를 담당했으며 소프트웨어 개발과 개발 문화에 관심을 갖고 있다. 시스템 관리, 데이터베이스, 테스팅과 애자일 관련 다수의 인증을 보유하고 있다. 인프라 개선을 위해 필요한 경우, 직접 웹으로 내부 사이트를 제작하거나 유틸을 제작하기도 한다.

김나리

현재 배달앱 스타트업 요기요&배달통 기술연구소에서 스크럼 마스터를 맡고 있다. 제품개발을 위한 Cross-functional team인 스쿼드(Squad)를 중심으로 애자일 프랙티스 활용 및 협업 중심의 개발 문화 정착을 위해 다양한 시도를 하고 있다. 이전에는 소셜 네트워킹 서비스 기획 및 프로젝트 관리자로서 커리어를 쌓았으며, 스크럼을 경험한 후 기획자에서 스크럼 마스터로 역량을 확장했다.