[ "한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다." ]
Continuous Deployment, 지속적 배포 (oreilly)
발렌티나 세르빌(Valentina Servile): 방콕에 본사를 둔 소트웍스의 수석 소프트웨어 개발자로, 분산 시스템의 지속적 배포 분야에서 수많은 고객과 협업하며 컨설팅을 해왔다. 여러 다기능 팀에서 근무하며 대규모 분산 시스템과 마이크로서비스, 지속적 배포 프랙티스, 진화하는 아키텍처 등 다양한 기술 스택을 쌓아왔다. 평소 코드 작성은 물론, 다른 동료를 멘토링하는 일을 즐긴다. 소트웍스의 고객사에서 소프트웨어 배포 프랙티스를 개선하고 안정적인 릴리스를 더 자주 수행함으로써 비즈니스 환경 변화에 신속하게 대응할 수 있도록 지원하는 일에 보람을 느낀다.
- thoughtworks 링크에서 저자에 대한 내용과 책 자체에 대한 소개를 좀 더 많이 볼 수 있다. -> 초반 챕터들의 맛보기와 팟캐스트를 이용할 수 있다!
- 🔥 한빛 책 링크
리뷰
이제 github action 의 test code runing 하는 yaml 파일은 꼭 먼저 만들고 시작하게 된다. (물론 린팅 -> 테스팅 단계로) 하지만 이는 어디까지나 “최소한의 규칙 점검” 에 가깝다.
이 책이 묻는 본질은 한층 직설적이다. 우리는 왜 CI/CD를 구성하는가? 『지속적 배포』는 도구 사용법보다 팀이 공동으로 가져야 할 관점과 습관에 집중한다. O’Reilly 특유의 교과서적 정밀함과, 현장에 닿아 있는 실무성의 균형이 돋보인다.
책은 아래와 같은 5개의 파트로 이뤄져 있다. 개념을 모두 뿌려두고, S/W 생명 주기에 맞춰 이를 어떻게 적용하는지의 흐름이다.
- Part 1: CD 개념·배경 정리(Dev/Ops·XP·CI/CD의 계보 포함)
- Part 2: 개발 이전 — 작업 슬라이싱·가치 중심 설계·팀 규칙
- Part 3: 개발 단계 — 트렁크 기반 개발, 기능 토글, 파이프라인
- Part 4: 개발 이후 — 프로덕션 중심 검증·릴리스 전략(카나리 등)
- Part 5: 사례 연구 — N26·TravelPerk·AutoScout24 등 도입기
책의 성격은 “사용법”이라기보다는 "팀 차원의 ‘계몽’과 행동 변화를 유도" 하는 책에 가깝다.
주관적인 하이라이트
트렁크 기반 개발(TBD) - Trunk-Based Development
책의 기본 원리는 명확하다. “더 작게, 더 자주, 더 안전하게.” 배포는 릴리스와 다르며, 코드는 항상 운영 환경에 들어갈 수 있어야 한다. 사용자는 기능 토글(Feature Toggles) 과 카나리(Canary) 등으로 노출을 통제한다.
핵심은 실패를 전제로 설계하는 것이다. “잘못된 커밋의 비율”보다 실패 감지 속도와 우아한 복구(낮은 MTTR) 가 더 중요하다. 긴 브랜치와 늦은 병합이 만들어내는 충돌 비용을 짧은 수명 브랜치 + 잦은 통합으로 끊고, 파이프라인 신뢰도를 높이며 커밋 단위의 책임을 선명하게 만든다.
- 브랜치 수명 제한(예: 1~2일), “Definition of Merge” 합의(필수 체크·리뷰 SLA)
- 메인 브랜치의 항상 배포 가능 상태 보장(빨간 파이프라인 금지 원칙)
- 롤백 대신 롤포워드를 표준화(토글/리버전 플랜 사전 준비)
기능 토글(Feature Toggles)
기능 토글은 미완성 기능도 배포 가능하게 만든다. 최상위/중첩 토글과 확장·축소 패턴으로 노출을 세밀하게 제어하며 배포와 릴리스의 결합을 해체한다. 운영 관점에서 중요한 것은 토글의 수명 관리다. 토글은 채무가 되기 쉽다.
- 토글 분류: 릴리스 토글(기능 노출), 운영 토글(긴급 차단), 실험 토글(A/B), 권한 토글(세그먼트)
- 거버넌스: 토글 생성 시 만료 기준·제거 시점 명시, 대시보드화, “좀비 토글” 주기적 청소
- 프로그레시브 딜리버리: 카나리 → 점진적 확대 → 자동 롤백 조건(에러율/지연/전환율)
작업 슬라이싱 전략
수평 분할(레이어 중심)보다 수직 분할(사용자 가치 단위)을 우선한다. INVEST 원칙(Independent·Negotiable·Valuable·Estimable·Small·Testable) 을 티켓 템플릿에 내장하고, 각 항목을 즉시 쪼갤 수 있는 기준으로 삼는다.
- “완성 기능”이 아니라 가치 흐름의 얇은 조각을 목표로 설계
- 각 슬라이스에 명확한 수용 기준(AC) 과 관측 지표(로그·메트릭·이벤트) 부여
- 인터페이스 변경이 필요한 경우, 백워드 호환과 계약 테스트로 무중단 전환
프로덕션 중심 품질 보증
“승인 절차가 안전을 보장한다”는 착시에서 벗어나야 한다. 운영 환경에서만 검증 가능한 사실(데이터 볼륨/형상, 실제 트래픽 패턴, 네트워크·인프라 구성)을 근거로 프로덕션 테스트를 표준화한다.
- 관측 가능성(Observability): 트레이스·로그·메트릭 일체화, 기능별 SLI/SLO
- 셰도우 트래픽·리플레이, 실사용 세그먼트 기반 실험, 오토 롤백 규칙 사전 정의
- 품질의 단위를 “테스트 통과 여부”에서 “운영 지표의 안정성” 으로 전환
전체 스택 예제와 현실 이슈
React·Spring Boot·SQL로 이어지는 예제는 세션/상태, 클라이언트 캐시 무효화, DB 마이그레이션 같은 현업 난제를 직접 다룬다. 필요하면 파이프라인 일시 중지 → 로컬 검증 같은 우회 전략도 제시한다.
DB는 Expand → Migrate → Contract(전개·이행·축소) 3단계로 안전하게 바꾸고, 배치·백필 작업은 멱등성과 재시도 정책으로 보호한다. 배포 전략은 서비스 성격에 따라 롤링/블루-그린/카나리를 선택한다.
사례 연구에서
핀테크·이동 서비스·이커머스 등 서로 다른 도메인(N26, TravelPerk, AutoScout24 등)의 사례를 통해 CD → 조직 문화 혁신 → 배포 빈도 증가 → 비즈니스 민첩성으로 이어지는 경로가 드러난다. 이 파트는 기술 채택기를 넘어서 조직 변화기에 가깝다.
- “우리의 제약(규제/리스크/조직도)을 토글·카나리·슬라이싱으로 어떻게 흡수할 것인가?” 에 대한 고찰을 준다.
- 또한 규모가 조금 있는 조직에서 “변경 리드타임·배포 빈도·MTTR을 어떤 OKR로 연결할 것인가?” 에 대한 고민포인트가 될 것 같다.
결론
Part 1의 “왜 CD인가” 논증은 독자에 따라 다소 길게 느껴질 수 있다. 또한 관료성이 항상 악은 아니다. 어떤 조직은 git-flow·배치 릴리스를 유지해도 만족할 수 있다. 반대로 문화 성숙 없이 TBD만 밀어붙이면 “배포 담당자”로 책임이 쏠리는 역효과 가 생길 수 있다고 생각한다.
그럼에도 트렁크 기반 개발·기능 토글·프로덕션 검증을 하나의 체계로 묶어, ‘배포 공포증’을 조직의 학습 사이클로 전환한다는 점과 즉시 적용 가능한 패턴과 현실적 우회 전략을 모두 담았기에, 당장 배포 흐름을 개선하려는 팀, 장기적으로 전달 문화를 재정립하려는 조직, 그리고 개인(팀) 모두에게 추천할 만하다.
개인적으로 [PART 3 개발 단계] 가 특히 인상적이었다. JVM(Spring) 환경에서 기능 토글을 코드 레벨로 구현하는 실습이 포함되어 있어, 추상적인 개념이 채워지는 느낌이 있다. 사실 이런 느낌의 코드를 처음봐서 그런것 같다.
목차
[PART 01 지속적 배포]
CHAPTER 01 지속적 배포
_1.1 수개월, 수년마다 한 번 배포
_1.2 며칠마다 한 번 배포
_1.3 지속적 배포
_1.4 익스트림 프로그래밍
_1.5 데브옵스
_1.6 지속적 통합
_1.7 지속적 전달
_1.8 최종 프로덕션 게이트
_1.9 시사점
_1.10 지속적 배포는 위험한가?
_1.11 정리하기
CHAPTER 02 이점
_2.1 원피스 플로와 린 생산
_2.2 DORA 메트릭
_2.3 품질 시프트 레프트
_2.4 정리하기
CHAPTER 03 사고방식의 전환
_3.1 변경사항을 정의하는 것과 적용하는 것
_3.2 진행 중인 작업 숨기기
_3.3 분산 시스템
_3.4 프로덕션 경로 간의 계약
_3.5 배포는 릴리스가 아니다
_3.6 엔드투엔드 전달 라이프 사이클
_3.7 정리하기
CHAPTER 04 최소 요건
_4.1 자율적 다기능 팀
_4.2 이해관계자의 신뢰
_4.3 정리하기
CHAPTER 05 도전 과제
_5.1 배포에 민감한 시스템
_5.2 유저 설치 소프트웨어
_5.3 규제 대상 산업
_5.4 인지 부하
_5.5 정리하기
[PART 02 개발 이전]
CHAPTER 06 예정된 작업 나누기
_6.1 수평 분할 vs 수직 분할
_6.2 지속적 배포를 하면
_6.3 효과적인 수직 분할
_6.4 예제: 그로서루
_6.5 정리하기
CHAPTER 07 프로덕션 빌드
_7.1 배포성 요건
_7.2 테스트성 요건
_7.3 관찰 가능성 요건
_7.4 보안 요건
_7.5 성능 요건
_7.6 (좀 더) 완전한 유저 스토리 템플릿
_7.7 예제: 그로서루 유저 스토리에 CFR 추가
_7.8 정리하기
[PART 03 개발 단계]
CHAPTER 08 플랫폼 아키텍처 재구축
_8.1 유저 스토리
_8.2 그로서루 애플리케이션
_8.3 정리하기
CHAPTER 09 라이브 기능 리팩터링
_9.1 해야 할 일
_9.2 상품 식별 체계
_9.3 현재 상태
_9.4 목표 상태
_9.5 어떻게 목표를 달성할까?
_9.6 확장/축소 구현
_9.7 정리하기
CHAPTER 10 데이터와 데이터 손실
_10.1 해야 할 일
_10.2 현재 상태
_10.3 목표 상태
_10.4 어떻게 목표를 달성할까?
_10.5 이중 쓰기 구현 전략
_10.6 이중 읽기 구현 전략
_10.7 NoSQL
_10.8 정리하기
[PART 04 개발 이후]
CHAPTER 11 프로덕션에서 테스트
_11.1 왜 프로덕션에서 테스트를 해야 하나?
_11.2 어떻게 프로덕션에서 테스트를 할까?
_11.3 스테이징 이후의 스토리
_11.4 정리하기
CHAPTER 12 릴리스
_12.1 안티패턴: 빅뱅 릴리스
_12.2 안티패턴: 부분 배포로 일부만 릴리스
_12.3 릴리스에 기능 토글 응용
_12.4 카나리 릴리스
_12.5 A/B 테스트
_12.6 정리하기
[PART 05 사례 연구]
CASE STUDY A 오토스카우트24
_A.1 오토스카우트24의 당시 상황
_A.2 오토스카우트24의 지속적 배포 도입
_A.3 오토스카우트24의 지속적 배포 구현
CASE STUDY B 오토
_B.1 오토의 당시 상황
_B.2 오토의 지속적 배포 도입
_B.3 오토의 지속적 배포 구현
_B.4 참고 자료
CASE STUDY C N26
_C.1 N26의 당시 상황
_C.2 N26의 지속적 배포 도입
_C.3 N26의 지속적 배포 구현
_C.4 참고 자료
CASE STUDY D 클라이밋파트너
_D.1 클라이밋파트너의 당시 상황
_D.2 클라이밋파트너의 지속적 배포 도입
_D.3 클라이밋파트너의 지속적 배포 구현
CASE STUDY E 모타빌리티 오퍼레이션즈
_E.1 모타빌리티 오퍼레이션즈의 당시 상황
_E.2 모타빌리티 오퍼레이션즈의 지속적 배포 도입
_E.3 모타빌리티 오퍼레이션즈의 지속적 배포 구현
CASE STUDY F 레아 그룹
_F.1 레아 그룹의 당시 상황
_F.2 레아 그룹의 지속적 배포 도입
_F.3 레아 그룹의 지속적 배포 구현
CASE STUDY G 메이즈
_G.1 메이즈의 당시 상황
_G.2 메이즈의 지속적 배포 도입
_G.3 메이즈의 지속적 배포 구현
CASE STUDY H 메이즈
_H.1 트래블퍼크의 당시 상황
_H.2 트래블퍼크의 지속적 배포 도입
_H.3 트래블퍼크의 지속적 배포 구현
