한빛미디어

[ "한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다." ]

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) 환경에서 기능 토글을 코드 레벨로 구현하는 실습이 포함되어 있어, 추상적인 개념이 채워지는 느낌이 있다. 사실 이런 느낌의 코드를 처음봐서 그런것 같다.