이 문서는 《피닉스 프로젝트》의 전반적인 내용(Part 1, Part 2, Part 3 및 데브옵스 핵심 이론 부록)을 중심으로 IT 관리 방식의 근본적 혁신, 칸반 도입을 통한 흐름 개선, CISO의 인식 변화와 개발/운영 파이프라인으로의 보안 통합, 퍼블릭 클라우드 활용과 데브옵스 배포 파이프라인 구축을 통한 피닉스/유니콘의 배포 성공, 그리고 에릭의 세 가지 방법(Three Ways) 데브옵스 이론을 한국어로 상세히 요약·분석한 페이지입니다.

이 링크를 통해 구매하면 운영자에게 소정의 수수료가 지급될 수 있습니다.

피닉스 프로젝트 (The Phoenix Project) - Gene Kim

개요

챕터별 주요 내용

CHAPTER 1

날짜: 9월 2일 화요일
주요 사건 및 요약:
IT Operations 부서장과 CIO의 경질 및 빌의 승진: 네트워크 장애로 출근길이 늦어진 빌 파머(Bill Palmer, Midrange Technology Operations Director)는 HR VP인 로라 벡(Laura Beck)으로부터 호출을 받고, 기존 CIO인 루크(Luke)와 그의 직속 부하이자 빌의 상사였던 데이먼(Damon)이 경질되었음을 알게 된다. 빌은 CEO 스티브 마스터스(Steve Masters)에 의해 신임 IT Operations VP로 지명된다.
스티브의 강압과 빌의 승진 수락: 빌은 승진이 정치적 희생양이 될 위험이 크고 CIO 직책이 2년마다 갈려나가는 'Career Is Over'의 지름길임을 알기에 완곡히 거절하려 한다. 그러나 스티브는 군(해병대) 출신인 빌에게 애국심과 책임감을 자극하며 "IT가 변기 물 내리는 것처럼 조용히 작동하되, 넘쳐나서 빌딩을 덮치지만 않게 해달라(Keep the lights on)"고 강하게 몰아붙이고, 결국 빌은 강제로 직책을 수락하게 된다.
첫 번째 위기 - 급여 시스템(Payroll) 오류: 부임하자마자 CFO인 딕 랜드리(Dick Landry)로부터 공장 교대 근무 근로자들의 이번 주 급여가 시스템 결함으로 제로(0) 처리되어 급여 지급이 실패할 위기에 처했다는 최고 긴급 사안(Priority: Highest)을 전달받는다.

CHAPTER 2

날짜: 9월 2일 화요일 (오전/오후)
주요 사건 및 요약:
비즈니스적 위기 대면: 빌은 CFO 딕 랜드리와 그의 운영 매니저 앤(Ann)을 만나 급여 시스템 마비 상황을 공유받는다. 당일 오후 5시까지 수정하지 않으면 수동으로 수천 명의 공장 근로자들에게 종이 수표를 배달해야 하며, 이는 노조의 파업과 언론의 뭇매를 맞을 극도의 위기 상황이다. 최악의 경우 지난달 데이터를 재활용하는 Plan B를 3시까지 준비하기로 합의한다.
IT 운영의 혼란과 갈등: 빌이 Building 7(IT Operations의 성지이자 노후화된 공장 개조 건물)에 도착했을 때, Distributed Technology Operations Director인 웨스 데이비스(Wes Davis)와 IT Service Support Director인 패티 맥키(Patty McKee)는 NOC에서 회의 중이었다. 그들은 전날 밤 강행한 스토리지(SAN) 펌웨어 업그레이드 실패로 인해 모든 데이터베이스가 다운된 것을 원인으로 지목하고 벤더사를 갈구며 소방 작업(Firefighting)에 여념이 없다.
신임 승진 사실의 전파와 웨스의 반발: 빌은 그들에게 루크와 데이먼의 해고 및 자신의 승진 소식을 전한다. 오랜 동료였던 웨스는 메인프레임 시절 구식 기술만 다루던 빌이 VP가 된 것에 크게 반발하며 공격적인 태도를 보인다.

CHAPTER 3

날짜: 9월 2일 화요일 (오후)
주요 사건 및 요약:
진짜 원인의 추적: 빌은 웨스, 패티와 함께 핵심 엔지니어인 브렌트 겔러(Brent Geller)의 자리로 간다. 브렌트는 SAN 업그레이드가 실패하여 롤백하던 중 장비가 벽돌(bricked)이 되어 한자를 뿜어내고 있다고 보고한다.
보안(CISO 존)과 개발의 합작 사고 폭로: 앤으로부터 급여 데이터 중 오직 주민등록번호(SSN) 필드만 깨져서 전송된다는 정보를 입수한 빌은 SAN이 아니라 데이터베이스 구조를 변경한 누군가가 있음을 눈치챈다. 조사 결과, CISO 존 페쉬(John Pesche)가 개인정보(PII) 유출 보안 감사를 해결하기 위해 승인 없이 시간 기록 시스템에 토큰화(Tokenization) 제품을 설치하도록 개발자 맥스(Max)에게 강요했고, 맥스는 휴가를 떠나기 직전에 이를 테스트도 없이 밀어붙인 것이 드러난다.
체계적 변경 관리의 완전한 부재: 정식 변경 관리 프로세스를 무시한 채 존의 강요로 이루어진 무단 변경(Unauthorized Change)이 이 모든 사달의 진짜 원인이었다. 5시 데드라인을 넘겨 결국 결산 오류가 담긴 Plan B로 급여 지급을 단행하게 되었고, 빌의 첫날은 처참한 실패로 끝난다. 그날 밤 지역 언론(Elkhart Grove Herald Times) 1면에 Parts Unlimited의 급여 오류와 경영 미숙을 꼬집는 기사가 실린다.

CHAPTER 4

날짜: 9월 3일 수요일
주요 사건 및 요약:
이메일 폭탄과 사내 정치의 난입: 출근하자마자 빌은 500통이 넘는 이메일과 60통이 넘는 음성 메시지에 휩싸인다. 한편, 리테일 담당 SVP인 사라 몰튼(Sarah Moulton)은 CEO 스티브를 참조에 넣고 빌이 회사의 사활이 걸린 'Project Phoenix'의 출시를 가로막고 있다며 맹비난하는 이메일을 보낸다.
피닉스 프로젝트 회의의 충돌: 빌은 10시 긴급 프로젝트 미팅에 참석한다. 이 회의에는 스티브, 사라, 그리고 개발(Application Development) VP인 크리스 알러스(Chris Allers)가 동석했다. 사라는 경쟁사 광고를 예로 들며 당장 피닉스를 출시해야 한다고 스티브를 압박한다.
개발과 운영의 소통 단절과 '돼지 던지기': 크리스는 인프라 테스트 장비가 늦어 다음 주 금요일까지 바로 프로덕션 배포를 하겠다고 선언한다. 빌과 웨스는 운영 장비의 구체적인 사양서도 받지 못했고, 벤더 조달에만 3주가 걸리며, 부하 테스트도 전혀 되지 않았다고 격렬하게 반대한다. 빌은 개발팀이 일정이 쫓기자 테스트를 다 건너뛰고 "담장 너머로 돼지를 던지듯(throwing the pig over the wall)" 운영팀에 떠넘기며 영웅적 밤샘 작업으로 해결하게 만들려는 행태를 비판하지만, 스티브는 약속된 출시일(9월 12일 배포, 13일 마케팅 런칭)을 사수하라고 명령한다.
IT 내부 통제의 붕괴: 빌은 패티가 주재하는 변경자문위원회(CAB) 회의에 가지만, 참석자가 아무도 없어 분노한다. IT 조직 내부에 체계적인 변경 관리가 정착되지 않고 각자 총잡이처럼 시스템을 직접 수정하는 문화에 경종을 울리고자, 빌은 모든 팀장들에게 다음 주 금요일 CAB 회의 참석을 의무화하는 강력한 경고 이메일을 보낸다.

CHAPTER 5

날짜: 9월 4일 목요일
주요 사건 및 요약:
두 번째 대형 위기 - SOX-404 감사 보고서 폭탄: 이른 아침, 빌은 최고 감사 책임자인 낸시 메일러(Nancy Mailer)로부터 긴급 회의 소집 요청을 받는다. Q3 내부 감사 결과, Parts Unlimited의 IT 일반 통제(IT General Controls)에서 무려 952개의 취약점과 16개의 유의한 미비점, 2개의 잠재적 물질적 취약성(Material Weakness)이 발견되었음이 선포된다.
감사 대응을 위한 리소스 고갈: 외부 감사인의 실제 SOX-404 감사가 시작되기 전, 단 3주 안에 이에 대한 대응 조치 계획(Management Response Letter)을 제출해야 하는 절체절명의 상황에 놓인다. 존(John)은 보안 패치 적용을 서두르자고 주장하지만, 웨스는 구식 장비들이 패치 적용 시 전부 다운되어 비즈니스가 멈출 것이라며 반발한다.
WIP(진행 중인 업무)의 관리 불능 상태 인지: 빌은 이 수많은 감사 지적사항을 처리할 인력이 도저히 없음을 깨닫는다. 웨스와 패티에게 현재 IT 부서가 공식/비공식적으로 지고 있는 모든 업무 약속(Commitments)의 목록을 작성하고, 핵심 인력이 어디에 얼마나 투입되고 있는지 현황을 파악하라고 지시한다.

CHAPTER 6

날짜: 9월 5일 금요일 (오전/오후)
주요 사건 및 요약:
업무 과부하의 확인: 패티와 웨스가 IT Operations of 핵심 리소스 투입 현황을 보고한다. 회사는 공식적으로 35개의 비즈니스 프로젝트를 진행 중이지만, IT 내부적으로 추적되지 않는 프로젝트만 70개가 넘어 총 105개 이상의 프로젝트가 150명의 인원에게 몰려 있었다. 그중 상당수가 피닉스와 보안 준수 프로젝트에 할당되어 있으며, 일상적인 유지보수(Break-Fix) 작업이 전체 리소스의 75%를 잡아먹고 있었다.
예방 보수의 소홀로 인한 브렌트 병목의 반복: 전날에도 SAN 백업 디스크가 이중화 해제 상태로 방치되어 장애가 발생했고, 브렌트가 또다시 소방수로 차출되어 인터뷰가 지연되었다. 빌은 사소한 일마저 모두 브렌트에게 집중되는 병목 현상을 비판하며 예방 관리 프로세스의 정비를 촉구한다.
포스트잇 변경 관리의 도입: CAB 회의에 다시 모인 기술 담당자들은 기존의 ITIL 기반 관리 툴이 너무 복잡하고 입력 필드가 좁아 쓸 수 없다고 성토한다. 빌은 회의를 10분간 중단시킨 뒤, 모든 계획된 변경 사항을 인덱스 카드(포스트잇)에 직접 손으로 작성해 화이트보드 달력에 붙이게 하는 단순하고 시각적인 변경 관리 방식을 전격 도입한다.
400개가 넘는 변경 카드 폭탄: 그러나 금요일 오후가 되자 다음 주에만 무려 437건의 변경 카드가 쏟아져 들어오며, 빌과 패티는 이 엄청난 변경 작업 규모에 압도된다.

CHAPTER 7

날짜: 9월 5일 금요일 (오후)
주요 사건 및 요약:
이사회 후보자 에릭 리드(Erik Reid)와의 만남: 스티브의 비서 스테이시(Stacy)의 주선으로, 빌은 회사 이사회 멤버로 거론되는 정보기술 전문가 에릭 리드를 만난다. 청바지와 주름진 셔츠 차림의 에릭은 던킨 도넛 박스를 나르고 있는 소탈한 모습으로 첫 등장한다.
에릭의 제조업 비유와 뼈아픈 일침: 에릭은 빌에게 "당신은 IT Operations에 있으면서 정작 '일(Work)'이 무엇인지 모른다"며 그를 데리고 실제 자동차 부품 생산 공장인 MRP-8 공장으로 향한다.
제약 이론(Theory of Constraints)의 소개: 에릭은 1980년대 제조업을 혁신한 제약 이론, 린(Lean), 도요타 생산 방식(TPS), TQM을 언급하며, 공장에서 진행 중인 재고(WIP)야말로 납기 지연과 품질 저하의 주범인 "소리 없는 살인마"라고 강조한다.
IT와 제조 공정의 등가성: 골드랫의 소설 《더 골(The Goal)》에 등장하는 열처리 화로처럼, 모든 개선은 '병목(Constraint)'에서만 의미가 있으며 그 외의 개선은 모두 환상에 불과하다고 지적한다. 에릭은 IT 부서 역시 업무의 릴리즈를 제어해야 하며, 가장 제약이 되는 자원(브렌트)이 오직 전체 시스템의 이익을 위해서만 일하도록 통제해야 한다고 조언한다.
3가지 방법(Three Ways): 에릭은 ① 개발에서 운영으로의 신속한 업무 흐름(First Way), ② 피드백 루프의 단축과 증폭(Second Way), ③ 지속적인 실험과 실패로부터 배우는 학습 문화(Third Way)를 제시하며, IT 운영의 '4가지 유형의 업무'가 무엇인지 스스로 깨더우면 연락하라는 수수께끼 같은 숙제와 전화번호를 남긴다.

CHAPTER 8

날짜: 9월 8일 월요일
주요 사건 및 요약:
스티브의 냉혹한 거절: 빌은 주말 내내 수립한 리소스 현황과 프로젝트 분석 보고서를 들고 스티브와 독대한다. 빌은 피닉스 출시에 맞추어 보안 감사 조치를 병행하는 것은 물리적으로 불가능하며, 현재 인력 상황으로는 둘 다 망칠 수밖에 없으므로 6명의 추가 인력 예산을 요청한다.
자원 부족의 딜레마: 스티브는 피닉스가 이미 1천만 달러나 오버된 상황이며, IT 벤치마크 지표상 타사보다 돈을 더 쓰고 있다는 보고서를 인용하며 예산 증액을 칼같이 거절한다. 필요하다면 다른 현업 부서 VP들을 설득해 예산을 받아내라며 빌의 요구를 일축하고, "칼 한 자루만 들고 총잡이 싸움터에 뛰어들게 만드는 꼴"이라는 빌의 비유에도 요지부동의 태도로 "다들 최선을 다하고 있으니 돌아가서 알아서 해결하라"고 차갑게 말한다.
변경의 분류(Standard, Fragile, Messy Middle): 빌은 실망을 안고 CAB 회의로 돌아온다. 437개의 변경 카드 더미 속에서 해결책을 찾기 위해, 빌과 패티, 웨스는 변경 사항을 세 가지 유형으로 긴급 재정의한다.

깨지기 쉬운 변경(Fragile Changes): PUCCAR(20년 된 정산 프로그램)처럼 변경 시 다운될 위험이 커 반드시 CAB의 사전 승인과 철저한 모니터링이 필요한 항목 (약 50개).
표준 변경(Standard Changes): 정기 세금 테이블 업데이트처럼 과거에 여러 번 성공해 리스크가 낮고 사전 승인된 항목들 (자동 승인).
그 외 변경(Messy Middle): 해당 담당자가 유관 부서들과 합의하고 영향도를 검토해 조율했다면 실질적 검증 후 통과시키는 중간적 항목들.

체계적 통제의 실마리: 이 단순하지만 리스크 중심의 통제 합의 덕분에 격렬한 토론 속에서도 처음으로 전원이 만족하고 미소 짓는 생산적인 CAB 회의로 마무리된다.

CHAPTER 9

날짜: 9월 9일 화요일
주요 사건 및 요약:
Sev 1 신용카드 장애: 빌이 중요 예산 회의 도중 신용카드 결제 시스템 다운이라는 Sev 1 장애 전화를 받고 급히 NOC(Network Operations Center)로 이동합니다.
부서 간 갈등과 책임 전가: 장애 원인을 파악하려는 과정에서 개발팀(크리스), 네트워크팀, 데이터베이스(DB)팀 등 부서별 대표들이 타임라인이나 변경 내역도 없이 서로를 탓하며 책임을 회피(Finger-pointing)하는 극심한 갈등이 발생합니다.
브렌트(Brent)의 임의 복구: 핵심 엔지니어인 브렌트가 독자적으로 문제를 감지하고 사후 승인이나 공유 없이 임의로 시스템을 수정하여 결제 시스템을 복구합니다. 운 좋게 해결은 되었으나, 빌은 통제되지 않는 임의 변경이 시스템의 복잡성을 키우고 근본 원인 파악을 방해함을 지적합니다.
프로세스 통제 지시: 빌은 패티(Patty)에게 Sev 1 장애 시 즉각 타임라인을 파악할 수 있도록 하고, 2주마다 모의 훈련(Fire Drills)을 진행하도록 지시합니다. 웨스(Wes)에게는 브렌트의 무단 변경을 엄격히 통제할 것을 명령합니다.
변경 승인 위원회(CAB) 소집: 패티의 주도하에 포스트잇을 보드에 붙이며 첫 정식 변경관리 회의가 진행됩니다. 이때 배포 예정일인 금요일에 173개의 변경이 폭주하여 발생하는 '변경 충돌' 위험을 시각적으로 발견하고, 일정을 분산시키는 실질적 성과를 거둡니다.
WIP와 작업 유형의 깨달음: 빌은 CAB 보드의 변경 카드를 보며, 변경(Changes)이 비즈니스 프로젝트(Business Projects), IT 운영 프로젝트(IT Operations Projects)에 이어 IT 조직이 다루는 세 번째 작업 유형(WIP)임을 자각합니다.

CHAPTER 10

날짜: 9월 11일 목요일 오전
주요 사건 및 요약:
QA 지연과 갈등: 피닉스 배포 3일 전, QA 디렉터 윌리엄(William)은 새로 발견되는 버그가 수정되는 버그보다 2배 더 많다는 절망적 사실을 보고합니다. 사라는 이로 인한 피닉스 일정 지연을 두고 웨스의 운영팀을 맹공격합니다.
브렌트의 하루 관찰: 빌은 브렌트의 자리를 찾아가 그가 피닉스 프로젝트 대신 물류 부사장의 독촉 등 각 부서의 일상적인 장애 지원 요청(Break-fix)을 처리하느라 정작 중요한 프로젝트 작업을 전혀 하지 못하는 병목(Bottleneck) 현상을 직접 목격합니다.
브렌트 전용 차단막(Shield) 구축: 빌은 브렌트가 피닉스에만 전념할 수 있도록 극약 처방을 내립니다. 브렌트의 수신 전화를 웨스에게로 전환하고, 오직 피닉스 관련 지시 사항만 따르도록 타 부서의 직행 요청을 전면 차단합니다.
한니발 렉터 격리 프로토콜: 빌, 웨스, 패티는 긴급회의를 열어 브렌트 보호 대책을 세웁니다. 레벨 3 엔지니어 3명으로 이루어진 풀을 구성해 브렌트로 향하는 에스컬레이션을 게이트키핑하게 합니다. 브렌트에게는 직접 키보드를 만지지 않고 다른 엔지니어들이 지시대로 타이핑하게 강제함으로써, 머릿속 암묵지를 공유 가능한 지식 문서(Knowledge Base)로 변환하고 전파하도록 합니다.

CHAPTER 11

날짜: 9월 11일 목요일 오후
주요 사건 및 요약:
변경 미완료 사태: 패티는 변경관리 프로세스를 분석하던 중, 승인된 변경 사항 중 무려 60%가 계획대로 실행되지 못하고 다음 일정으로 밀리고 있는 심각한 문제를 보고합니다. 변경이 미완료되는 주된 원인은 다른 인프라 작업(SAN 확장 등) 지연, 장애 발생, 그리고 '브렌트'의 부재 때문이었습니다.
WIP와 공장 재고의 연계: 빌은 에릭(Erik)이 말한 공장 내부의 미완성 재고와 IT 내에 쌓여 있는 미완료 변경 카드가 본질적으로 같은 'WIP(Work in Progress)'라는 것을 깨닫습니다. 무분별하게 유입되어 쌓여가는 WIP가 IT Operations의 전달력과 품질을 갉아먹는 주범임을 직관합니다.
브렌트 의존성 관리: 빌은 패티에게 브렌트의 관여가 필요한 변경 카드를 명확하게 분류하도록 하고, 이를 레벨 3 엔지니어로 대체하거나 우선순위를 사전에 조율할 수 있도록 지시합니다.

CHAPTER 12

날짜: 9월 12일 금요일 ~ 13일 토요일
주요 사건 및 요약:
피닉스 배포 당일 카오스: 개발팀(Chris)의 일정 지연으로 배포가 수 시간 미뤄졌고, 테스트 환경에서조차 애플리케이션이 구동되지 않는 FUBAR(개판) 상황이 연출됩니다. 개발자들은 "내 노트북에선 돌아간다"며 무책임한 방관 자세를 보입니다.
QA 스모크 테스트 실패: QA 디렉터 윌리엄은 개발팀의 무차별적인 소스 변경으로 버전 컨트롤이 완전히 실패해 스모크 테스트(Smoke test)조차 통과하지 못하고 있음을 알립니다.
인프라 및 환경적 문제: 성능 보완을 위해 20대의 서버가 시급히 필요한 상황이지만, 가상화 환경 실패로 물리 서버로 급히 롤백되었고 정작 데이터 센터 내에 랙 공간마저 부족해 케이블을 임의로 뜯어고치는 혼란이 빚어집니다. DB 관련 유지보수 도구도 갖춰지지 않아 수동으로 DB 데이터를 직접 수정하는 감사 리스크가 커집니다.
배포 강행과 POS 전면 마비: 빌은 스티브(Steve)에게 메일과 전화로 배포 1주일 연기를 건의했으나, 스티브는 마케팅 신문 광고 집행과 파트너사 일정을 이유로 거절하고 사라를 설득하라고 책임을 미룹니다. 결국 사라의 독촉으로 배포를 강행한 결과, 데이터베이스 전환 스크립트 오류로 모든 오프라인 매장의 POS(Point of Sale) 시스템이 다운되어 매장들은 카본지와 수동 카드 단말기를 이용해 수동 결제를 처리하는 대혼란에 빠집니다.
보안 사고 발생: 피닉스 웹사이트 결제 세션 오류로 타 고객의 신용카드 정보가 노출되는 초대형 보안 사고가 터지고, 트위터에 스크린샷이 도는 공론화가 진행됩니다. CISO 존(John)이 긴급 투입되어 복구 작업에 동참합니다.

CHAPTER 13

날짜: 9월 15일 월요일
주요 사건 및 요약:
언론 보도와 배포 제한 합의: 피닉스 실패가 대대적으로 기사화되자 스티브는 격노하여 책임자들과의 1대1 면담을 선언합니다. 빌은 임시 안정화를 위해 하루에 코드 배포를 2회로 제한하고 성능 버그만 반영하도록 하자는 크리스의 제안에 전격 합의하며 개발-운영 간의 첫 협력을 이끌어냅니다.
재무 수동 복구 워룸과 PCI 규정 위반 발견: 재무팀(Ann)은 중복 청구된 고객들을 복구하기 위해 임시 워룸을 만듭니다. 이때 존은 재무팀 직원들이 결제 처리를 위해 신용카드 뒤편의 민감 정보인 CVV2 번호를 종이에 수동으로 적어 보관하는 것을 목격합니다. 이는 PCI-DSS 규정의 치명적인 위반이며, 적발 시 막대한 벌금과 카드 거래 정지 처분을 받을 수 있는 사안이었습니다.
빌과 존의 공조: 마침 PCI 감사단이 같은 층을 사용하고 있었기 때문에, 존이 감사단을 다른 건물에 붙잡아두며 시선을 끄는 사이 빌은 재무팀이 민감 데이터를 파기하고 규정을 준수하며 안전하게 작업을 처리할 수 있도록 적극 조력합니다.
보안 인력의 IT Operations 지원: 이 협업을 계기로 빌은 IT Operations의 심각한 과부하를 선언(Saying No)하고, 존은 보안팀 엔지니어 2명을 파견하여 빌이 직면한 SOX-404 대응 계획 수립과 기술 복구 작업을 돕게 합니다.

CHAPTER 14

날짜: 9월 16일 화요일
주요 사건 및 요약:
스티브와의 면담과 항명: POS가 겨우 복구된 화요일 오전, 면담이 이어집니다. 빌은 스티브에게 연기 요청을 묵살한 스티브의 책임을 묻고, 스티브는 IT가 기업 경쟁력의 발목을 잡는다며 불만을 표시합니다.
IT 아웃소싱 및 분할 매각 카드: 스티브는 이사회가 회사 분할 매각 조사를 착수했음을 알리고, IT의 오랜 병목 현상을 타개하기 위해 CFO 딕에게 90일 내에 전체 IT 부서의 아웃소싱(Outsourcing) 업체를 선별하라는 임무를 부여했다고 경고합니다.
크리스와 빌의 동맹: 충격을 받은 빌과 크리스는 점심을 먹으며 외주 개발로 인해 과도한 소스가 한꺼번에 유입되고, 이는 배포 주기를 길게 만들며 대형 실패를 낳고 운영팀이 이를 뒤수습하느라 개선 피드백을 주지 못하는 고질적인 개발-운영 간의 악순환을 분석합니다. 둘은 아웃소싱 저지를 위해 강력한 공동 전선을 구축하기로 맹세합니다.
협업의 첫걸음: 개발팀이 피닉스 배포 완료 파티를 열지만 운영팀은 수동 데이터 복구로 참가하기 힘든 상황이었습니다. 그러나 빌은 부서 간 불신을 깨뜨리기 위해 웨스와 팀원들을 독려해 파티에 강제로 참여시키며 연대감을 형성합니다.

CHAPTER 15

날짜: 9월 17일 수요일
주요 사건 및 요약:
가정의 위기와 프로세스의 가치: 빌은 아내 페이지와 식사하며 무너진 워라밸과 가계 재정, 아웃소싱 압박 속에서 가장(Provider)으로서의 역할을 되돌아봅니다. 한편, CAB 변경 보드 덕분에 현업에서 발생할 뻔한 큰 DB 충돌 장애를 예방했다는 현업 DBA의 메일을 받고 프로세스의 실질적인 가치를 검증합니다.
계획되지 않은 작업(Unplanned Work)의 자각: 패티와 비어있는 변경 보드를 보던 빌은 깨달음을 얻습니다. 지난주 피닉스 장애 복구를 위해 모든 정식 프로젝트와 예정된 변경들이 올스톱되었던 현상을 보며, 에릭이 경고한 가장 무서운 네 번째 작업 유형이 바로 '계획되지 않은 작업(Unplanned Work, 소방 작업)'임을 완전히 이해합니다. 이는 반물질처럼 정상적인 계획 작업을 모두 소멸시키는 가장 파괴적인 속성을 가지고 있었습니다.
에릭의 멘토링과 제약조건 Step 3 (종속): 빌은 에릭에게 전화를 걸어 이 사실을 전달하고 칭찬을 받습니다. 에릭은 간반(Kanban) 보드를 통한 시각화와 1Way(흐름)의 가치를 언급하고, 제약조건 이론(Theory of Constraints)의 Herbie(허비) 개념을 활용하여 브렌트가 조직의 유일한 병목(Constraint)임을 확언합니다.
새로운 과제: 에릭은 제약조건을 식별(Step 1)하고 최대한 활용(Step 2)한 것에 이어, 이제는 병목 자원인 브렌트의 소화 속도에 맞추어 상위의 작업 방출 속도를 제어하는 Step 3 (종속/Subordinate, Drum-Buffer-Rope) 메커니즘을 현업에 적용하라는 과제를 남깁니다.

CHAPTER 16

날짜: 9월 18일 목요일
주요 사건 및 요약:
매출채권 마비 위기: CFO 딕으로부터 회사의 핵심 고객 청구(Invoicing) 시스템 오작동으로 3일간 청구서가 발행되지 않아 약 5,000만 달러의 현금 회수가 동결되고 분기 실적이 파탄 날 지경이라는 급박한 장애 신고가 접수됩니다.
엄격한 통제와 체계적 대응: 빌은 NOC에 모여 임의 수정을 절대 금지("DO NOT TOUCH ANYTHING WITHOUT MY APPROVAL")시키고, 아폴로 13호의 진 크란츠처럼 오직 가설과 데이터 기반의 검증된 타임라인을 통한 체계적인 디버깅을 진행합니다. 이는 주먹구구식 개입이 시스템을 더 악화시킨다는 점을 인지한 대책이었습니다.
스티브의 무리한 강요와 항명: 밤 9:15, 다급해진 스티브는 빌에게 전화를 걸어 당장 브렌트를 불러 키보드를 쥐여주고 장애를 해결하라고(all hands on deck) 소리칩니다. 빌은 체계적 검증이 되지 않은 상황에서 에이스의 성급한 개입이 문제를 더 키울 것이며(지난 payroll 장애 시 SAN을 임의로 건드려 6시간 연장되었던 사례 언급) 브렌트 개인에 대한 악순환적 의존성을 끊어야 한다며 강력하게 거절합니다.
사직서 제출: 스티브가 경영자의 권력을 앞세우며 강제 집행하려 하자, 빌은 현장의 판단을 묵살하는 비이성적 개입에 더 이상 책임질 수 없다며 단호하게 항명하고 "내일 아침 사직서를 제출하겠다"며 사표를 던지고 전화를 끊습니다. 페이지는 이 상황에 경악과 충격에 빠집니다.

CHAPTER 17

날짜: 9월 22일 월요일
주요 사건 및 요약:
빌의 사임과 IT 부서의 붕괴: 빌이 사임한 지 4일째 되는 주말과 월요일 아침은 평화로웠으나, 회사 IT 부서는 파국을 맞이한다. 스티브가 엔지니어들을 강압적으로 몰아세우고 브렌트(Brent)를 마이크로매니징하여 긴급 문제에 대응하게 했으나, 업무 조정 실패로 인해 재고 관리 시스템이 완전히 마비되고 재무 결산이 불가능해져 CFO가 패닉에 빠진다.
스티브의 사과와 빌의 복귀: 스티브는 이사회와 에릭(Erik)의 뼈아픈 지적을 받은 후, 자신의 미숙함하고 사라(Sarah)에게 마이크로매니징을 맡겼던 과오를 뉘우치며 빌에게 진심으로 사과한다. 스티브는 IT가 기업 경쟁력의 핵심임을 깨달았다며 빌에게 90일 동안 함께 경영 문제로서의 IT를 개혁해 보자고 제안하고, 실패할 경우 1년 치 퇴직금을 약속한다. 빌은 현실적인 가장의 책임과 스티브의 진정성을 확인하고 복귀를 결심한다.

CHAPTER 18

날짜: 9월 23일 화요일
주요 사건 및 요약:
리더십 오프사이트와 취약성 드러내기: 빌이 복귀한 날 아침, 스티브는 IT 리더십 오프사이트 회의를 소집한다. 스티브는 패트릭 렌시오니의 저서 《팀이 빠지기 쉬운 5가지 역능(Five Dysfunctions of a Team)》을 인용하며, 진정한 팀워크와 상호 신뢰를 구축하기 위해 각자의 개인사와 취약성(Vulnerability)을 솔직하게 털어놓는 연습을 제안한다.
스티브의 과거 고백: 스티브는 텍사스 시골의 가난한 면직 공장 노동자 가정에서 자란 배경, 광산 노동 중 청각을 일부 상실한 일, 그리고 군대(ROTC)에서 배운 물류 경영과 부하 직원들로부터 "Asshole of the Decade(10년간 최악의 개자식 상)"로 불릴 정도로 사람들을 독단적으로 몰아붙였던 부끄러운 과거를 고백하며 진정한 신뢰를 쌓기 위해 마음을 연다.

CHAPTER 19

날짜: 9월 23일 화요일 (오프사이트 계속)
주요 사건 및 요약:
리더십 멤버들의 자기 고백과 연대: 리더십 멤버들이 차례로 아픈 상처를 고백한다. 크리스(Chris)는 미숙아 쌍둥이 출생 과정에서 밤낮으로 기도하며 얻은 무조건적인 헌신의 교훈을 나누고, 웨스(Wes)는 외모 콤플렉스와 파혼/이혼 경력, 그리고 외롭게 지속하는 모터스포츠 취미를 고백한다. 패티(Patty)는 미술학도에서 생계를 위해 입사하기까지의 시민불복종 전과 문제를, 빌은 알코올 중독자인 아버지에게서 도망치기 위해 어린 여동생을 두고 가출했던 평생의 죄책감과 이를 극복하고 좋은 아버지가 되기 위해 노력한 일화를 나누며 눈물을 흘린다. 이로 인해 리더들은 서로에 대한 불신을 극복하고 강력한 인간적 신뢰를 구축한다.
프로젝트 동결(Project Freeze) 결정: 리더들은 그동안의 개발과 운영 간 장벽 및 병목을 토론한다. 빌은 IT 운영의 업무를 4가지 유형(비즈니스 프로젝트, IT 운영 프로젝트, 변경, unplanned work)으로 정의하고, 현재 과부하 상태에서 소방 작업을 방지하기 위해 '피닉스 프로젝트를 제외한 모든 배포와 신규 IT 작업을 2주간 전면 중단(프로젝트 동결)'할 것을 제안한다. 스티브는 이를 비즈니스 결단으로 즉시 승인하고 전사적인 무단 작업 압박을 직접 차단하기로 약속한다.

CHAPTER 20

날짜: 9월 26일 금요일
주요 사건 및 요약:
동결의 즉각적 효과와 새로운 장애: 프로젝트 동결 시행 3일 만에 커스틴(Kirsten)으로부터 피닉스 프로젝트가 평소 한 달 동안 해낼 진척을 단 7일 만에 마쳤다는 승전보를 받는다. 그러나 네트워크 벤더의 무단 변경 실수로 전화 시스템이 다운되어 매출에 즉시 타격을 주는 Sev 1 장애가 발생하고, 무단 변경을 감지하기 위한 모니터링 프로젝트의 시급함이 대두된다.
에릭의 공장 비유와 제약 조건의 재정의: 빌은 MRP-8 공장에서 에릭을 만난다. 에릭은 WIP가 마감 준수 성능을 파괴한다는 제조업의 기본을 상기시키며, 제약 조건(Constraint)을 여전히 브렌트라는 '사람'으로 착각하는 빌을 비판한다. 에릭은 '브렌트'가 아니라 '브렌트가 개입해야만 하는 여러 작업 센터(Work Centers)'들이 진짜 제약조건임을 규명하고, 작업 센터의 4요소(기계, 사람, 방법, 측정) 중 브렌트의 역할을 문서화·표준화하여 타인에게 이양하고 자동화할 것을 지시한다.
대기 시간과 가동률: 에릭은 가동률이 90%에 도달하면 대기 시간이 50%일 때보다 9배 증가하고, 가동률이 99%에 달하면 99배로 늘어나는 대기 행렬 공식(Wait time = utilization / idle time)을 인용하며 가동률 제어(Slack Time 확보)의 극적인 중요성을 설명한다. 또한 제약 조건 예방 관리를 수행하는 모니터링 프로젝트(TPM)가 최우선 순위임을 일깨운다.

CHAPTER 21

날짜: 9월 26일 금요일
주요 사건 및 요약:
SOX 감사 회의와 감사 범위(Scope) 축소: 딕(Dick)과 외부 감사 파트너가 동석한 회의에서 IT 보안 미비점들이 대거 논의된다. 그러나 재무 분석가 페이(Faye)가 작성한 통제 맵 덕분에, IT 시스템이 설령 허술하더라도 재무팀의 일간/주간 수동 조정(Manual Reconciliation)이라는 비즈니스 하류 통제(Downstream Controls)가 완벽히 오작동을 잡아내므로 복잡한 IT 시스템 통제들을 감사 범위 밖(Out of Scope)으로 제외하는 데 성공한다.
CISO 존의 정신적 붕괴: 존은 평생 추구해 온 IT 보안과 감사 지적사항들이 비즈니스 관점의 수동 조정 보고서 하나로 쓸모없어진 것처럼 묘사되자 극심한 소외감과 좌절감을 느낀다.
에릭의 신랄한 비판: 에릭은 존에게 "이미 단종된 제품을 위한 QA 테스트를 쓰며 일정을 파괴하는 정치적 위원" 같다고 비난하며, 존이 시스템에 불필요한 무의미한 일을 얹는 방식으로 보안을 강제해 왔음을 폭로한다. 보안의 진짜 성공은 IT 시스템에 일을 추가하는 것이 아니라 불필요한 스코프를 제거해 효율을 높이면서도 비즈니스를 효과적으로 보호하는 것임을 지적하고, 공장의 안전 담당자(Safety Officer)를 찾아가 그녀의 방식을 배우라고 훈계한다. 존은 충격을 받고 3링 바인더를 버려둔 채 떠난다.

CHAPTER 22

날짜: 9월 29일 월요일
주요 사건 및 요약:
칸반(Kanban) 시범 도입과 생산성 혁신: 존이 출근하지 않는 가운데 패티는 공장을 직접 방문한 뒤 서비스 데스크 업무에 칸반 보드를 설계 및 도입한다. 반복적인 4대 서비스 요청(이전, 계정 생성/제거, 신규 PC 지급, 패스워드 초기화)을 칸반을 통해 시각화하고 진행 중인 작업(WIP)을 엄격히 제한한 결과, 빌의 노트북 교체가 조기 완료되는 등 납기 예측 능력이 비약적으로 상승하고 오류율이 급감한다. 또한 브렌트를 무단 변경 요청(drive-bys)으로부터 보호하기 위한 칸반 격리 체계를 웨스와 구상한다.
프로젝트 포트폴리오의 이원화와 우선순위 정렬: 빌과 패티, 웨스는 프로젝트 동결을 부분 해제하기 위한 로드맵을 작성한다. 비즈니스 우선순위 5대 프로젝트를 확정하고, 73개의 내부 IT 프로젝트는 '제약 조건(브렌트)의 용량을 늘리는 작업', '브렌트 없이 가능한 작업' 등으로 재분류하여 관리한다. 이 과정에서 퇴출 예정인 BART 데이터베이스의 무의미한 업그레이드 프로젝트 등을 걸러내며 불필요한 리소스 낭비를 막는다.

CHAPTER 23

날짜: 10월 7일 화요일
주요 사건 및 요약:
핸드오프(Handoff)에 숨겨진 대기 시간 병목: 브렌트가 45분이면 끝난다고 호언장담했던 피닉스 테스트 환경 구축 작업이 일주일 이상 지연되는 문제가 발생한다. 패티가 작업 세부단계를 추적한 결과, 이 태스크는 단순 작업이 아니라 6개 부서 간 20단계가 넘는 핸드오프가 얽힌 복합 프로젝트였다. 대기 행렬 공식에 따라, 모든 가용 자원들이 90% 이상 가동 중일 경우 작은 작업들도 각 큐에 갇혀 며칠씩 누적 대기 시간이 발생한 것이다.
워터 스파이더(Water Spider) 역할 도입: 패티는 제조업의 '워터 스파이더' 개념을 벤치마킹하여, 완료된 태스크를 다음 작업 센터로 즉시 물리적으로 나르고 가이드하여 대기 시간을 극적으로 단축할 원활화 전담자(PM+에이전트) 제도를 도입한다. 또한 이 프로세스를 표준화하여 임의로 인프라를 구축해 병목을 고착화하는 '인프라 눈송이(snowflake)' 문제를 방지하기로 합의한다.

CHAPTER 24

날짜: 10월 11일 토요일
주요 사건 및 요약:
소방 해소와 주말의 평화: 빌은 마침내 주말에 장애 호출에서 벗어나 가족들과 호젓하게 핼러윈 호박밭 나들이와 외식을 즐기며일 상적인 행복을 체감한다.
만취한 존과의 만남과 뼈아픈 조언: 밤늦게 전화해 U-Haul 트레일러에 짐을 싣고 회사를 그만둔 채 떠나겠다는 만취한 존을 찾아 'Hammerhead Saloon'으로 향한다. 존은 회사가 자신의 보안 공헌을 무시했다고 신세 한탄을 한다. 빌은 진실을 말해주는 것이 우정이라는 신념하에 존에게 "피닉스 긴급 PCI 대응을 제외하면, 솔직히 보안 부서는 회사 생존에 도움을 주기보다 늘 과도하고 불필요한 업무 부담(WIP)만을 얹어주었을 뿐"이라고 냉정하게 피드백한다. 존은 만취해 잠들고 빌은 그를 귀가시킨다.
존의 복귀 조짐: 월요일 밤, 존은 자신의 오만을 깨달았다는 솔직한 고백과 함께 다음 날 아침 8시 딕과의 미팅에 함께 참석하자는 문자를 빌에게 보낸다.

CHAPTER 25

날짜: 10월 14일 화요일
주요 사건 및 요약:
새로운 모습의 존과 딕 인터뷰: 삭발하고 단정한 패션으로 3링 바인더 대신 빈 메모 노트 한 권만 쥐고 복귀한 존은 빌과 함께 딕을 만난다. 존은 딕에게 겸손하게 그의 직무와 Parts Unlimited의 핵심 목표 지표(매출, 시장점유율, 자산이익률 등)가 무엇이며 어떤 위협이 존재하는지 묻는다. 딕은 경쟁사 대응을 위한 피닉스의 사활적 시급성, 매장 재고 품절 데이터 왜곡, 이관 누락 등으로 인한 재무제표 작성 지연 리스크를 털어놓는다.
에릭의 피드백과 비즈니스 리스크 정렬: 에릭은 빌에게 W. Edwards Deming의 '계통에 대한 이해(Appreciation for the System)' 개념을 설명하며, IT 리스크를 비즈니스 성과의 선행 지표(Leading Indicator)로 정의해 내는 작업(예: 오일 교체 준수율이 배송 납기율의 선행지표가 되는 자동차 물류의 비유)이 바로 '제1방법(First Way)'의 핵심 스코핑(Scoping) 작업이라고 조언한다. 또한 존에게 감사 파트너와 미팅하여 회사가 감사 결과를 어떻게 미련 없이 제외(Out of scope)했는지를 분석함으로써, IT의 보안 스코프를 최적화할 수 있는 가치 사슬 지도를 구축하라고 과제를 준다.

CHAPTER 26

날짜: 10월 17일 금요일
주요 사건 및 요약:
비즈니스 오너 인터뷰와 피닉스의 구조적 한계 직시: 빌과 패티는 딕의 목표 지표 아래에 있는 실무 오너들을 인터뷰한다. 영업 VP 론(Ron)은 전화와 MRP 장애로 수백만 달러의 즉각적 계약이 취소되는 고충을 토로하며 딕에게 전화해 IT 모니터링 예산 배정을 촉구한다. 상품 기획 담당 매기(Maggie)는 재고 품절(Stockout) 정보의 극심한 데이터 부정확성으로 인해 예측이나 A/B 테스트 마케팅이 무력화되었고, 수천만 달러의 투자(WIP)가 긴 개발 기간(1년 초과)으로 묶여 10%의 사내 자본 허들 레이트(Hurdle Rate)를 충족시키지 못한다고 지적한다. 더욱이 피닉스느느 일정 압박으로 데이터 분석과 보고서 기능을 뒤로 미루고 있었다. 빌은 피닉스가 현 상태로는 실패할 운명이며 릴리즈 주기를 대폭 줄이고 피드백을 강화해야 함을 실감한다.

CHAPTER 27

날짜: 10월 21일 화요일
주요 사건 및 요약:
비즈니스-IT 정렬 분석과 존의 5가지 보안 통합 제안: 빌과 패티, 웨스, 존, 크리스가 모여 비즈니스 가치 사슬와 IT의 리스크/대응책을 일치시킨 분석 프레임워크를 작성한다. 존은 자신의 뼈아픈 분석을 토대로 획기적인 보안 통합 로드맵을 발표한다.

하류 재무 통제(Manual Reconciliation)에 기반하여 복잡하고 무거운 SOX-404 IT 감사 범위의 대폭 제거.
보안 점검을 배포 파이프라인의 초기 단계에 자동 검증으로 통합(Shift-Left).
변경 관리 프로세스에 규제 준수 대상을 명확히 매핑하여 임의 변경을 차단하고 증적을 자동화.
회사에 독극물과 같은 개인정보 위험 요소인 '카페테리아 POS' 등 비핵심 자산의 결제 데이터 처리를 외부 아웃소싱하여 위험 원천을 제거.
위 조치들로 세이브한 여유 리소스를 피닉스의 기술 부채(Technical Debt)를 상환하는 데 재투자.

30분 만의 역사적 합의: 리더들은 존의 이 혁신적인 제안들이 보안을 걸림돌로 만드는 것이 아니라 개발/운영의 자연스러운 흐름으로 스며들게 함을 인정하고 30분 만에 만장일치로 합의한다.

CHAPTER 28

날짜: 10월 27일 월요일
주요 사건 및 요약:
체계적 개선의 실질적 성과: IT 부서는 비약적으로 안정화된다. 심각한 Sev 1 장애율은 3분의 2 이상 감소했고 복구 시간도 절반 이하로 떨어졌다. 칸반 보드를 통한 대기열 청소와 브렌트 보호 장치 덕분에 프로젝트 병목이 눈에 띄게 완화되었다.
두 번째 피닉스 배포 장애와 스키마 충돌: 금요일 밤 피닉스의 단순 버그 수정 배포가 단행되나, 운영 데이터베이스 마이그레이션 도중 실패한다. 6시간의 사투 끝에 토요일 새벽 5시 42분에 겨우 임시 롤포워드 배포에 성공한다. 원인을 규명한 결과, 프로젝트 동결 해제 직후 무단 적용된 사라의 마케팅 BI 모듈을 지원하기 위해 브렌트가 운영 환경의 DB 스키마를 수동으로 변경한 것이 크리스 팀의 소스 코드와 충돌을 일으킨 것으로 밝혀진다. 이는 개발과 운영 환경의 철저한 동기화가 이루어지지 않을 때 흐름이 파괴됨을 시사한다.

CHAPTER 29

날짜: 11월 3일 월요일
주요 사건 및 요약:
사라의 일탈 적발과 응징: 월요일 전체 회의에서 스티브는 IT의 전반적 지표 개선을 칭찬하나, 존의 모니터링을 통해 적발된 사라의 심각한 규정 위반을 논의한다. 사라는 IT 부서를 건너뛰고 클라우드 벤더와 데이터 분석 계약을 무단으로 맺어 고객 정보 보안 정책과 데이터 무결성 정책을 위반했다. 스티브는 사라에게 일체의 독자적 IT 사업 진행을 금지하고 빌, 크리스와 협력하여 과제를 해결하라고 명령한다. 사라는 퇴장하며 회장 밥(Bob)을 업고 스티브의 입지가 약하다고 협박한다.
에릭의 피드백과 제2방법(Second Way): 에릭은 피닉스 배포의 대형 사고를 지적하며, 9개월 주기의 대규모 릴리즈(Civil War era cannons) 대신 단일 부품 흐름(Single-piece flow)에 가깝게 배치 크기를 최소화하고 릴리즈 주기를 단축해야 피드백 루프를 강화(제2방법)할 수 있다고 조언한다. 또한 제약 조건인 브렌트를 설계 초기 단계(Herbie처럼)에 투입하여 배포 및 구성 품질을 처음부터 검증해야 한다고 조언한다.
피닉스 SWAT 팀의 탄생: 크리스는 배포 복잡도 때문에 다음 피닉스 출시를 격월로 늦추자고 제안하지만, 스티브는 홀리데이 쇼핑 시즌(30일 미만 남음)이 코앞이라 매출 손실을 볼 수 없다고 분개한다. 빌은 양측의 딜레마를 타개하기 위해, 대규모 릴리즈를 정지하는 대신 고객 추천과 재고 할인 프로모션 등 핵심적인 매출 성장 기능만 단기 릴리즈로 신속하게 구현하기 위해 핵심 정예 요원을 차출한 '피닉스 SWAT 팀'을 조직할 것을 제안한다. 크리스, 웨스, 패티, 존이 모두 이에 호응하며 새로운 돌파구를 찾는다.

CHAPTER 30

날짜: 11월 3일 월요일
주요 사건 및 요약:
에릭의 공장 견학과 택트 타임(Takt Time): 빌은 에릭과 함께 다시 MRP-8 공장을 방문한다. 에릭은 공장을 하나의 유기적인 시스템으로 바라봐야 하며, 빌이 개별 작업 센터 관리자(IT 팀장)가 아닌 전체 공장 설계자나 공장장(비즈니스 리더)처럼 생각해야 한다고 강조한다. 그는 고객 수요를 맞추기 위한 생산 주기인 '택트 타임(Takt Time)' 개념을 설명하며, 환경 구축 지연으로 배포 주기가 길어지는 현상이 택트 타임을 초과하여 비즈니스 가치를 저해하고 있다고 지적한다.
도요타의 단일 분 단위 금형 교체(SMED)와 일체형 공정: 도요타가 3일 걸리던 금형 교체 시간을 10분 미만으로 단축한 역사(SMED)를 소개하며, MRP-8 공장에서 도장(Paint)과 베이킹(Bake)이라는 두 가지 제약 조건을 '자전거 체인과 기어'를 활용한 하나의 일체형 기계로 통합하여 리드 타임을 1달에서 1주일 미만으로 줄인 혁신 사례를 들려준다.
하루 10회 배포 목표와 배포 파이프라인: 에릭은 2009년 Flickr의 존 올스포(John Allspaw)와 폴 해먼드(Paul Hammond)가 발표한 '하루 10회 이상의 개발-운영 협업 배포' 사례를 인용하며, 빌에게 하루 10회 배포를 목표로 삼으라고 주문한다. 이를 위해 코드 체크인부터 운영 배포까지의 모든 과정(배포 파이프라인)에서 개발, QA, 운영이 하나의 공동체로 협업해야 하며, 환경 구축을 코드화(Infrastructure as Code)하여 자동화하고 제약 조건인 브렌트의 머릿속에 있는 지식을 자동화 빌드 절차로 인코딩하여 사람의 수동 개입을 없애야 한다고 가르친다. 또한 속도 자체가 목적이 아니라 시장 변화에 빠르게 반응하고 더 큰 위험을 감수하기 위한 민첩성과 지속적 실험이 비즈니스의 핵심 생존 무기임을 역설한다.

CHAPTER 31

날짜: 11월 3일 월요일 (SWAT 팀 킥오프)
주요 사건 및 요약:
배포 프로세스 매핑과 병목 인식: 빌은 젖은 몸으로 프로젝트 유니콘(SWAT 팀) 킥오프 미팅에 참여한다. 10회 배포 목표에 대해 팀원들(특히 웨스)이 불가능하다며 반발하자, 빌은 배포에 수반되는 구체적인 단계를 화이트보드에 그리게 한다. 개발 코드 커밋부터 운영 이관까지의 흐름을 그린 결과, 100개가 넘는 단계와 부서 간 수많은 핸드오프가 존재함이 밝혀진다.
가치 흐름 지도(Value Stream Map)와 문제 가시화: 패티는 제조업의 가치 흐름 지도 기법을 적용하여 각 단계별 소요 시간과 대기열(WIP)을 기록한다. 빌이 이전 배포에서 실패했던 지점들에 빨간 별표를 치자, 보드 전체가 빨간 별로 가득 찬다. 이를 통해 환경의 비표준화와 동기화 실패, 수동 패키징 및 배포 스크립트 작성에 따른 재작업(Rework)과 낭비(Waste)가 병목의 핵심 원인임이 가시화된다.
환경 표준화 및 패키징 자동화 합의: 팀은 해결책을 도출한다. 첫째, 브렌트와 개발팀 윌리엄(William)이 협력하여 가상 머신(VM) 기반의 공통 빌드 절차를 구축함으로써 개발, QA, 운영 환경을 완전히 표준화한다. 둘째, 매 2~3주 스프린트 주기마다 배포 가능한 코드뿐만 아니라 동일한 환경 구성 코드까지 버전 관리 시스템(Version Control)에 함께 체크인하도록 규정을 변경한다. 셋째, 윌리엄 팀에서 패키징 생성을 전담하고 코드 완료 시 QA 환경으로 자동 배포되도록 자동화 툴을 만들기로 합의하여 브렌트의 작업 부하를 크게 덜어준다. 또한 보안 준수를 위해 존의 보안 팀원도 이 파이프라인에 포함시키기로 결정한다.

CHAPTER 32

날짜: 11월 10일 월요일
주요 사건 및 요약:
프로젝트 유니콘(Unicorn)의 쾌속 전진: SWAT 팀은 프로젝트명을 '프로젝트 유니콘'으로 정하고, 레거시 피닉스 시스템의 복잡한 굴레에서 벗어나 깨끗하게 분리된 코드베이스에서 작업을 시작한다. 아키텍처팀의 승인 절차를 피해 가기 위해, 이들은 기존 데이터베이스를 직접 건드리지 않고 오픈소스 도구를 활용하여 필요한 데이터만 복사한 독립된 신규 데이터베이스를 구축한다. 이로 인해 피닉스 시스템이나 다른 핵심 업무에 영향을 주지 않고 안전하게 개발과 테스트를 독립적으로 가동할 수 있게 된다.
환경 표준화의 실질적 효용: 브렌트와 윌리엄 팀이 개발한 공통 VM 환경 구축 덕분에, 신규 개발자가 환경을 세팅하고 빌드하는 데 기존 3~4주일이 걸리던 작업이 단 몇 분 만에 완료된다. 모든 개발자가 동일한 운영체제, 라이브러리 버전, DB 세팅을 공유하게 되었고, QA 환경도 몇 분 만에 동일하게 동기화되어 즉각적인 피드백 루프가 형성된다. 팀은 속도에 자신감을 얻어 스프린트 주기를 3주에서 2주로 단축한다.
브렌트 납치 사건과 빌의 결단: 유니콘이 승승장구하던 중 브렌트가 갑자기 이틀 동안 잠적한다. 조사 결과, 사라와 재무 VP 딕이 회사 분할(Breakup) 계획을 검토하는 비밀 태스크포스(Project Talon)의 인프라 실사 작업을 위해 브렌트를 디모인(Des Moines)으로 강제 징집한 것이었다. 빌은 디모인에 있는 브렌트에게 전화를 걸어, 회사의 분할을 막고 독자 생존할 유일한 열쇠는 유니콘의 성공뿐이라며 당장 복귀하라고 지시한다.
스티브의 지지와 브렌트 회수: 빌은 스티브를 찾아가 브렌트 없이는 유니콘이 실패하며 4분기 실적 달성도 불가능하다고 보고한다. 스티브는 이사회와의 약속(이번 분기 실적에 따른 분할 보류)을 상기하며 분노하고, 디모인에서 브렌트를 즉시 복귀시키고 재무팀 태스크포스에는 다른 차선책 엔지니어를 배치하도록 조치한다.

CHAPTER 33

날짜: 11월 11일 화요일
주요 사건 및 요약:
사라의 정치적 공격과 클라우드 피벗(Cloud Pivot): 브렌트가 유니콘으로 복귀하자 사라는 이사회 의장 밥 스트라우스(Bob Strauss)에게 메일을 보내 빌이 회사 분할 태스크포스의 필수 자원을 탈취하고 방해했다며 공식적으로 고발한다. 스티브는 이에 흔들리지 말고 계획대로 진행하라고 빌을 격려한다. 한편, 유니콘의 타겟 추천 알고리즘이 예상보다 50배 느리게 작동하는 심각한 성능 지연 문제가 발생한다. 이를 위해 100만 달러 규모의 서버 하드웨어를 구매하는 대신, 개발팀의 제안에 따라 가상화 이미지를 활용해 퍼블릭 클라우드(Cloud)로 전개하여 필요한 시간 동안 수백 개의 가상 서버를 기동하고 비용을 지불하는 유연한 클라우드 아키텍처로 피벗한다.
보안 자동화(Shift-Left)의 증명: 존의 보안 팀은 클라우드 전개에 따른 데이터 노출 리스크를 방어하기 위해, 보안 자동화 테스트를 개발팀의 QA 자동화 테스트 파이프라인에 직접 내재화한다. 이를 통해 개발자가 코드를 커밋할 때마다 보안성 검증이 실시간으로 수행되어 이전의 수동 보안성 리뷰(최소 1주일에서 한 달 소요)에 비해 엄청난 가시성과 보안 커버리지를 확보하게 된다.
SOX-404 감사 종결과 1차 마케팅 성공: 존은 빌이 정착시킨 변경 관리 프로세스를 입증 자료로 제시하여, 지루하게 이어져 오던 3년 반복 SOX-404 외부 감사 지적사항을 완전히 종결시키는 쾌거를 거둔다. 유니콘 팀은 Thanksgiving 1주일 전 전체 고객 중 1%를 대상으로 한 타겟 메일 발송 테스트에서 기존 캠페인 대비 5배 이상 높은 경이적인 반응률(구매 전환율 6%)을 기록하며 대성공을 예고한다. 스티브는 전체 팀을 칭찬하고 사라의 방해 공작에 경고를 보낸다.

CHAPTER 34

날짜: 11월 28일 금요일
주요 사건 및 요약:
추수감사절 트래픽 폭주와 운영 중심 설계: 추수감사절 당일 유니콘 캠페인 대성공으로 웹사이트 트래픽이 폭주하여 전자상거래 시스템이 다운되는 Sev 1 비상사태가 발생한다. 빌의 팀과 개발팀은 긴급 롤아웃을 통해 실시간 추천 엔진 기능을 일시 차단(2시간 소요)하여 결제 시스템을 안정화한다. 이후 개발진은 이 차단 기능을 수동 배포 없이 몇 분 만에 온오프할 수 있는 '기능 토글(Feature Toggle)' 설정으로 리팩토링하여 운영 안정성을 확보한다.
블랙 프라이데이 매장 병목과 주말 대응: 블랙 프라이데이 아침, 유니콘 이메일 쿠폰을 인쇄한 인파가 매장으로 몰려들며 인기 고마진 상품들이 완판된다. 매장 직원들이 수동으로 물류창고 재고를 확인하고 발송 처리를 하느라 결제 대기줄이 길어지자, 빌의 팀은 주말 동안 밤샘 작업을 통해 매장 직원용 쿠폰 자동 교차 배송 포털과 고객용 계정 직접 배송 양식 페이지를 단 이틀 만에 개발 및 배포하여 위기를 해결한다.
흑자 전환과 사라의 아웃소싱 덫: 월요일 회의에서 스티브는 유니콘의 활약으로 매장과 웹 매출이 역대 최고치를 경신했으며, Parts Unlimited가 전년도 중순 이후 처음으로 분기 흑자(Profitability)를 달성했다고 선언한다. 사라는 IT 부서의 성공을 시기하며, 경쟁사의 주문 제작(Build-to-order) 서비스 출시로 자사 매출이 타격을 입었다고 공격하며 이를 처리하지 못하는 레거시 공장 및 IT를 아웃소싱하고 회사를 분할해야 한다고 재차 주장한다.
MRP 레거시 인소싱(Insourcing) 결단: 경쟁사에 대응하기 위해서는 3년 전 비용 절감을 이유로 아웃소싱했던 구형 메인프레임 MRP(제조 자원 계획) 시스템의 변경이 시급했다. 그러나 아웃소싱 벤더는 개발 슬롯 부재와 엄격한 계약 조항을 핑계로 feasibility 연구에만 5만 달러와 6개월을 요구하며, 변경 배포까지 최소 18개월이 걸린다는 통보를 보내와 IT 제약 조건이 벤더에 묶여 있음이 드러난다. 빌은 계약을 중도 해지하고 100만 달러의 위약금을 지불하더라도 해당 메인프레임 개발 자원(6명)을 회사로 인소싱하여 주도권을 되찾고 90일 안에 주문 제작 시스템을 구축하겠다는 대담한 계획을 제시한다. 사라는 위험이 크다며 강력히 반대하고 의장 밥에게 확인하자고 종용하지만, 스티브는 사라에게 "당신의 보고 라인은 밥이 아니라 나다. 이 원칙을 따르지 못하겠다면 사임하라"고 일갈한다. 스티브는 빌의 인소싱 계획을 적극 승인하고 법무팀과 Dick을 배정하여 실행을 지시한다.

CHAPTER 35

날짜: 1월 9일 금요일
주요 사건 및 요약:
제3방법(Third Way)의 체계적 정착: 추수감사절과 블랙 프라이데이의 대성공 이후 회사는 평화를 찾는다. 장애 발생률은 급감했고, 빌의 팀은 가동 용량의 15%를 예방적 기술 부채 상환 및 모니터링 보완 프로젝트에 성공적으로 투자하고 있다. 팀은 넷플릭스의 카오스 멍키(Chaos Monkey)를 모방한 프로젝트 나할(Project Narwhal)을 가동하여 시스템에 인위적으로 실패를 주입하며 복구 탄력성을 실험하는 한편, 존의 보안팀은 보안 취약점을 무작위로 침투시키는 '이블 카오스 멍키(Evil Chaos Monkey)'를 가동하여 시스템을 극도로 견고하게 단련한다. 빌은 이것이 실패를 통해 학습하고 숙련도를 높이는 '제3방법'의 제도적 정착이라고 설명한다.
회사의 부활과 사라의 퇴출: 스티브의 집에서 열린 축하 파티에서 스티브는 Parts Unlimited가 역대급 실적을 기록하여 주가가 폭등하고 있고, 이사회 의장 밥도 회사 분할 계획을 완전히 철회했음을 전한다. 또한 사라 몰튼은 책임을 지고 회사에서 영구 퇴출(휴직 처리 후 이직 대기)되었음이 밝혀진다.
빌의 파격적인 COO 승진 코스: 스티브는 빌에게 CIO 자리를 비워두고, 향후 2년 동안 영업, 마케팅, 생산, 공급망 관리 등 비즈니스 핵심 부서를 순환 근무하는 특수 훈련 코스를 제안한다. 스티브는 "10년 후의 모든 유능한 COO는 반드시 IT 시스템을 intimate하게 이해해야 한다. IT 비즈니스 맥락을 모르는 COO는 껍데기에 불과하다"는 미래적 비전을 밝히며, 빌이 이 도전을 완수할 경우 3년 안에 회사의 차기 COO로 승진시킬 것임을 약속한다. 빌은 이 제안을 기쁘게 받아들인다.
조직의 세대교체와 에릭의 제안: 빌은 자신의 후임으로 패티를 차기 IT 운영 VP로 승진시키고, 2년 후 자신이 COO 단계로 갈 때 패티를 차기 CIO로, 웨스를 차기 IT 운영 VP로 앉히는 승계 구도를 계획한다. 파티에 참석한 멘토 에릭은 빌의 성공을 축하하며, 자신은 board 멤버로 참여하는 대신 회사의 대주주로 직접 투자할 예정이라고 밝힌다. 에릭은 전 세계 100만 명의 IT 노동자들의 삶을 개선하기 위해 parts unlimited의 변화 과정을 담은 경영 서적을 저술해 달라고 청하며, 그 책의 이름을 《데브옵스 핸드북(The DevOps Handbook)》으로 명명한다. 빌은 흔쾌히 이를 약속한다. 파티 말미에 패티가 빌에게 급한 표정으로 전화를 걸어오며 이야기는 또 다른 운영 과제의 시작(클리프행어)과 함께 마무리된다.

4대 핵심 테마 종합 분석

1. 피닉스 대재앙 극복과 데브옵스/클라우드 배포 파이프라인 구축 (Part 3의 승리)

배포 파이프라인 매핑: 대규모 빅뱅식 릴리즈의 참사를 겪은 후, 가치 흐름 지도(Value Stream Map)를 그려 100단계가 넘는 배포 단계의 병목을 규명했다.
환경 표준화 및 자동화: 빌드 과정을 가상 머신(VM) 이미지로 표준화하여 개발, QA, 운영 환경을 100% 일치시켰으며, 이를 통해 개발자가 환경을 구축하는 데 수 주가 걸리던 고통을 단 몇 분으로 해결했다.
퍼블릭 클라우드 활용: 대규모 연산이 필요한 추천 알고리즘의 한계를 극복하기 위해 물리적 서버 투자 대신 퍼블릭 클라우드를 채택하여 탄력적인 자원 확장과 비용 최적화를 동시 실증했다.
운영 중심 설계 (Design for Operations): 장애 시 코드의 재배포 없이 기능을 켜고 끌 수 있는 '기능 토글(Feature Toggle)'의 적용 등 실무 운영 안정성을 코드로 보장하는 사상을 체계화했다.

2. 세 가지 방법(Three Ways)의 실천과 피드백 가속화

제1방법 (흐름의 가속): 칸반 보드 전면 적용, 진행 작업(WIP) 제한, 환경 구성 코드화(Infrastructure as Code)를 실현하여 배포 리드 타임을 분 단위로 단축했다.
제2방법 (피드백 강화): 보안 취약점 자동 테스트를 개발/QA 빌드 파이프라인에 주입(Shift-Left)함으로써 개발자가 실시간으로 보안 피드백을 받게 했다. 또한 운영 데이터베이스 스키마와 소스 코드 동기화 구조를 정착시켜 마이그레이션 실패를 방지했다.
제3방법 (지속적 학습과 실험): 프로젝트 나할(Chaos Monkey)과 이블 카오스 멍키(Security Attacks)를 운영 환경에 적극 도입하여 장애를 인위적으로 주입하며 시스템의 안티프래질(Antifragility)을 실험하고 학습을 일상화했다.

3. IT 기반의 비즈니스 턴어라운드와 아웃소싱의 제약 해결 (인소싱 결단)

비즈니스 성과 연계: 프로젝트 유니콘 마케팅 프로모션을 성공적으로 이끌어 역대 최다 판매고 및 다분기만의 흑자 전환을 성공시켜 IT가 비용 부서가 아닌 매출 성장의 견인차임을 입증했다.
핵심 제약의 인소싱: 주문 제작(Build-to-order) 비즈니스 구현의 병목이었던 아웃소싱 MRP(메인프레임) 벤더의 일정 지연(18개월 소요 통보)에 대응하여, 100만 달러의 중도 해지 위약금을 지불하면서까지 자원을 사내로 인소싱(Insourcing)하는 대담한 결정을 내려 기술적 주도권을 탈취했다.

4. 리더십의 진화와 캐릭터들의 운명

스티브의 리더십 전환: IT를 부속품이나 소모품이 아닌 전기처럼 도처에 존재하는 기업 생존의 핵심 역량으로 인식했다.
빌의 COO 승진 코스: 빌은 단순 CIO가 아닌 비즈니스 전반(영업, 마케팅, 생산, 공급망)을 체계적으로 순환 근무하여 3년 안에 차기 COO(최고운영책임자)로 성장하는 초고속 훈련 과정에 진입했다. "IT를 이해하지 못하는 최고 경영진은 빈 껍데기"라는 비즈니스-IT 완전 통합론을 보여준다.
조직의 세대교체: 빌은 후임으로 패티를 차기 IT 운영 VP 및 예비 CIO로, 웨스를 차기 IT 운영 VP로 정렬하여 신뢰 기반의 조직 승계 로드맵을 완성했다.
사라 몰튼의 영구 퇴출: 비즈니스 부서와 IT의 정보 격차를 악용해 정치적 분할(Talon)과 무단 독자 IT 계약을 일삼던 사라 몰튼은 불명예 퇴출을 맞이했다.
에릭의 멘토링과 DevOps Handbook 저술 제안: 에릭은 보드 참여 대신 최대 투자자 자리를 취하며, 빌에게 자신의 경험을 토대로 전 세계 IT 노동자의 삶을 혁신할 《데브옵스 핸드북》 저술을 의뢰한다.

부록: 데브옵스의 이론적 기초 (세 가지 방법 - The Three Ways)

데브옵스는 물리적 제조업의 린(Lean) 생산 원리, 제약 이론(Theory of Constraints), 도요타 카타(Toyota Kata) 등을 IT 소프트웨어 및 서비스 가치 사슬에 이식한 결과물이다. 이는 다음의 세 가지 방법으로 요약된다.

1. 제1방법: 흐름의 원칙 (The Principles of Flow)

목적: 비즈니스 개념/요구사항이 개발(Dev)을 거쳐 운영(Ops) 및 최종 고객에게 이르는 흐름(왼쪽에서 오른쪽)을 극대화하여 배포 리드 타임을 단축한다.
실천 항목:
작업의 시각화 (Kanban): 지식 노동의 특성인 보이지 않는 업무 흐름을 시각적 카드로 관리하여 병목과 대기열을 즉각 확인한다.
진행 작업(WIP) 제한: 멀티태스킹에 따른 컨텍스트 스위칭 비용을 최소화한다. "시작하는 것을 멈추고, 끝내는 것을 시작하라(Stop starting, start finishing)."
배치 크기 축소: 대규모 빅뱅식 릴리즈 대신 단일 부품 흐름(Single-piece flow)에 기반하여 지속적 배포(Continuous Deployment)를 실행함으로써 릴리즈 리스크를 극소화한다.
핸드오프 및 대기열 제거: 부서 간 문서 전달 및 승인 지연 시간을 제거하기 위해, 테스트/인프라 구축/보안 점검 과정을 완전히 자동화 및 셀프서비스화한다.
제약 조건 승격: 전체 가치 사슬에서 가장 느린 지점(예: 환경 구축, 배포 승인)을 집중적으로 해결하여 글로벌 최적화를 달성한다.

2. 제2방법: 피드백의 원칙 (The Principles of Feedback)

목적: 하류(운영/고객)에서 상류(개발/기획)로 흐르는 빠르고 지속적인 피드백 루프(오른쪽에서 왼쪽)를 구축하여, 결함을 초기에 발견하고 해결 가능한 안전한 작업 체계를 구축한다.
실천 항목:
안돈 코드(Andon Cord)와 스워밍(Swarming): 빌드 오류나 배포 문제 감지 시 즉시 라인을 멈추고 팀이 모여 원인을 규명(Swarming)하여 결함이 하류로 흘러가지 않게 한다.
품질의 원천 관리 (Shift-Left): 거리를 둔 결재선이나 사후 승인 위원회에 의존하는 대신, 품질 및 보안 검증을 빌드 단계에 자동화하고 피어 리뷰를 정착시켜 작업 주체가 품질을 최종 책정한다.
하류 부서를 위한 최적화 (Design for Operations): 운영에 수반되는 안정성, 모니터링 텔레메트리, 기능 토글, 성능 확보 등 비기능적 요구사항을 기획 단계부터 비즈니스 기능만큼 우선시한다.

3. 제3방법: 지속적인 학습과 실험의 원칙 (The Principles of Continual Learning & Experimentation)

목적: 안전하게 실패하고 배울 수 있는 고신뢰성 조직(Generative Culture)을 구축하고, 개인의 배움을 전사적 지식으로 자산화하여 시장 내 안티프래질(Antifragility)을 확보한다.
실천 항목:
제네러티브 문화 구축 (Westrum Typology): 공포 기반의 실패 은폐 문화(병리적)를 넘어, 실패를 성찰과 공유의 기회로 삼는 고신뢰성 공유 문화(동반적/제네러티브)를 구축한다.
블레임리스 포스트모템 (Blameless Post-mortem): 사건 발생 시 책임자 문책이 아닌 '시스템의 어떤 취약성이 문제를 초래했는가'에 초점을 맞춰 원인을 찾고 재발을 방지한다.
일상 업무의 개선을 위한 정기적 투자 (Improvement Kata): 하루 중 일정 시간(예: 15%)을 기술 부채 제거와 도구 개선 등 일상 업무 고도화에 명시적으로 할당한다.
탄력성 주입 (Chaos Engineering): 카오스 멍키 주입 등을 통해 운영 중인 시스템에 인위적으로 실패와 공격을 흘려보냄으로써 극도의 내결함성을 가진 강인한 시스템을 연습한다.
로컬 배움의 글로벌 자산화: 개별 팀의 문제 해결 기록을 전사 공유하고 라이브러리 및 표준 설정 코드로 동기화하여 전사적 역량을 평준화한다.