애자일, 자동화, DevOps, CI/CD 등의 용어와 기술을 프로젝트를 진행하면서 적용하였고 여러 배포 도구 들을 경험하기는 했지만 관련 내용에 대한 정의 및 방식에 대한 것을 정확히 설명하는 책이 없었는데 이번에 “지속적 배포” 라는 주제로 관련 내용을 학습할 수 있는 책을 읽어 보게 되었습니다.

책은 전체적으로 어렵지 않게 읽을 수 있었습니다. 개발 업무를 하거나 빌드, 배포를 경험했다면 해당 책은 꼮 읽어봐야 할 책이라고 생각합니다. 실제 프로젝트에서도 빌드, 테스트, 배포와 같은 환경에서 어떤 절차와 어떤 개념을 가지고 진행해야 할지 모를때 “지속적 배포” 책은 무조건 도움이 될 수 있습니다. 배포에 대한 스트레스 그리고 설계방법, 그리고 옛날 시스템의 배포 방식등등 여러가지 배포에 대한 역사와 최신 트렌드 및 올바른 배포 방법을 경험해 볼 수 있게 책이 쓰여 있습니다.

“지속적 배포” 책에서 언급된 “힘들수록 더 자주하라” 말이 있는데 자주 반복적으로해서 배포에 대한 스트레스를 줄이고 프로젝트에 더 집중하는 방식을 설명하고 있었습니다. 해당 문장은 현재 제가 진행하는 프로젝트에서 마주치고 있는 문제점을 해결하는 문장이었습니다.  배포는 어렵지만 잘게 나누어서 자주 한다면 틀림없이 업무적 스트레스나 빠른 대처를 진행할 수 있어서 해당 내용은 회사 내부에 꼭 공유를 하고 업무에 적용해 봐야 할 것 같습니다.  책에 이와 같이 강조된 표현이 많은데 꼭 꼽씹어서 읽어보고 업무에 적용하면 많은 도움이 될 것 같습니다.

“지속적 배포” 책에서는 배포와 관련된 전체적인 흐름과 내용등을 이해할 수 있습니다. 그림으로 그리고 해당 내용의 설명으로 쉽게 배포환경을 어떻게 만들고 어떻게 운영되어야 하는지 경험해 볼 수 있습니다.  또한 책 중간에 프로그램 소스로 설명된 부분도 있어서 배포에 관련 자료가 책 전반에 많이 수록되어 있습니다.  그리고 해당 내용 및 그림, 소스등은 내부에 공유하고 같이 공부할 만한 내용이라고 생각합니다. 예제가 많아서 효율적으로 설명하기가 좋으며 스터디 자료로 훌륭합니다.  배포에 문제점과 어려움, 팀원간의 배포 환경에 논의를 하게 된다면  “지속적 배포” 의 내용을 통해 배포 방향 및 시스템 개발을 업그레이드 하는데 많은 도움을 받을 수 있을 거라고 생각합니다.
저도 해당 내용의 핵심을 회사 내부에 공유 및 스터디를 진행하려고 합니다.

“지속적 배포” 책은 좀 더 효율적으로 구성되어 있습니다. 
PART 1. 지속적 배포
PART 2. 개발 이전 단계
PART 3. 개발 단계
PART 4. 개발 이후 단계
PART 5. 사례 연구
로 되어 있는데 
PART 1. 은 지속적 배포가 무엇인지 알수 있는 개념 PART 이고 린, 배포, 릴리스, 최소 요건 등 지속적 배포에서 사용하는 기술 및 관련 개념을 설명하고 있습니다.
PART 2, 3, 4 개발 진행에 따른 기술 및 방법론 및  개념을 설명하고 있습니다. 라이브 기능 리팩터링은 프런트 앤드, 백앤드 , 퍼시스턴스를 구분지어 설명하고 있으며 프로젝트를 하면서 경험하게 되는 배포 환경 및 상황을 설명하고 있습니다. 소스 및 그림 설명도 훌륭합니다. 책 내용 중 처음부터 읽어보는 것도 좋지만 필요 부분을 선택해서 읽어봐도 좋을 것 같습니다.
PART 5는 글로벌 8개 기업의 배포 사례를 설명하고 있습니다. 각 업체에 대한 상황 및 배포 시스템을 어떻게 도입하고 어떻게 배포 환경을 개선 했는지 확인할 수 있습니다. 다른 회사의 배포 환경을 경험하기는 어려운데 해당 부분은 제가 진행하는 프로젝트와 다른 기업에서는 배포를 어떻게 활용하는지 비교하면서 책을 읽어봤는데  현 프로젝트의 문제점 및 개선방향을 도출할 수 있어서 좋았습니다.

배포 관련 책은 어렵거나 배포를 수행하는 시스템을 설명하는 책이 주였는데 오랜만에 근본적인 배포에 대해 고민할 수 있는 좋은 책 이었던 것 같습니다. 프로젝트, 팀과 관련된 환경 및 기술도 좀 더 고민해 볼 수 있었습니다. 책을 통해 좀더 고민이 많아집니다. 프로그래머, DevOps 를 공부한다면 꼭 읽어보기를 추천합니다. 

"지속적 배포"는 단순히 CI/CD 기술을 설명하는 책이 아니라, 팀과 조직, 사고방식 전환까지 요구하는 책이었다. 과거 몇 달 단위로 하던 배포가 이제는 하루에도 여러 번 이뤄지는 현실을 짚으며, 그 과정에서 필요한 익스트림 프로그래밍, 데브옵스, 지속적 통합·전달 같은 실천들을 설득력 있게 풀어낸다.

특히 프로덕션 테스트와 릴리스 전략 부분이 인상 깊었다. 기존의 스테이징 중심 접근을 넘어 기능 토글, 카나리, A/B 테스트 같은 방법을 제시하면서, 왜 점진적이고 안전한 릴리스가 중요한지 구체적으로 보여준다. 이 덕분에 그동안 배포를 단순 이벤트로만 여겨왔던 시각이 확장됐다.

책은 또 자율적인 팀, 이해관계자의 신뢰 같은 문화적 요소를 강조하며, 지속적 배포가 기술 자동화만으로는 불가능하다는 사실을 일깨워준다. 무엇보다 “완벽할 순 없지만 지속적으로 개선할 수 있다”는 메시지는 현실적인 위로이자 동시에 방향을 제시해 주는 말이었다.

결국 이 책은 개인 개발자만이 아니라 조직 전체가 함께 읽고 고민해야 할 책이라는 생각이 든다. 이상과 현실 사이에서 괴리감을 느끼면서도, 우리가 가야 할 길이 분명히 어디인지 다시 확인할 수 있었다.

사회 초년생 시절, 개발 현장에서 직접 서버에 수동으로 배포하는 일을 자주 경험했습니다. ​ 당시 회사에서는 형상관리 도구로 SVN을 사용했고, IDC에 위치한 서버에 직접 접속해 파일을 업로드하는 방식이었습니다. ​ 일을 하면서 이러한 배포 방식이 상당히 비효율적이라고 느껴, 셸 스크립트를 작성해 코드 변경이 있을 때마다 다시 업로드하는 방식을 도입했습니다. ​ 그러나 이 방법은 동료들과 협업 시 파일명 충돌이나 업로드 누락 등의 문제를 야기해 업무에 차질을 빚기도 했습니다. ​ 이 방식의 가장 큰 문제점은 현재 업로드 된 자료가 어떤 버젼인지 확인하기가 어려웠습니다. ​ 이후에는 젠킨스를 활용해 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 도입해 자동으로 변경된 부분만 빌드하고 테스트하며, 검증된 코드만 안정적으로 서버에 배포하는 체계를 구축하는 것이 효과적임을 알게 됐습니다. ​ 이를 통해 배포 오류를 줄이고, 개발 속도를 높이며, 협업 환경에서도 안정적인 운영이 가능해졌습니다. ​ 이러한 가운데 지속적 배포 책이 나왔습니다. 글로벌 8개 기업의 배포사례도 수록 되어져 있는데요. 자세히 알아보도록 하겠습니다.

1) 유럽 온라인 자동차 장터

국내에서 중고차는 엔카가 대표적일 것입니다. 유럽의 경우에는 오토스카우트24라는 업체가 있는데요. 월 사용자가 3천만명이며 43,000여 딜러 파트너사를 보유하고 있습니다. 이 곳은 유저 간에 중고차, 신차, 오토바이, 카라반, 화물차 등의 차량을 온라인으로 사고 팝니다. ​ 또한 직원은 약 800여명이며 개발자는 200명 이상으로 알려져 있습니다. 또한 2,000개 이상의 깃헙 레포와 1000개 이상의 서비스를 취급합니다. ​ 이때 1500개가 넘는 파이프라인을 통해 소프트웨어를 빌드하고 프로덕션에 릴리스하는데요. 평균 빌드 시간은 15분, 평균 배포 시간은 6분 정도로 매달 약 74000개의 파이프라인 작업이 처리되고 있습니다. ​ 이런 규모가 처음 부터 운영된 것은 아니며 2014년 부터 꾸준히 지속적 배포에 관심을 가지고 개선한 것을 책을 통해서 알 수 있었습니다.

2) 독일 디지털 은행

지속적 배포 책에서는 N26 디지털 은행에 대한 사례도 알려주는데요. 작년 기준 80여개국 1500명 이상의 직원을 두고 24개 시장의 800만명의 이상의 고객을 확보했습니다. ​ N26이 가장 많이 투자하고 있는 런타임 플랫폼은 쿠버네티스 입니다. 주로 ArgoCD와 Argo 워크플로로 쿠버네티스에 서비스를 배포하고 선언적 깃옵스 패턴으로 소스코드 뿐만 아니라 환경별 애플리케이션 구성을 추적할 때에 유용하게 사용한다고 합니다. 이로써 은행업의 규제에 대한 문제와 잘 맞은 것을 알 수 있었습니다.

이 포스팅은 한빛미디어에서 책을 받아 읽고 주관적으로 작성 했습니다.

실무에서 DB 마이그레이션과 안전한 배포 방식을 늘 고민해왔는데 책을 읽으며 “배포를 자주 할수록 리스크가 줄고 자동화와 테스트가 강화된다”는 인사이트를 얻었습니다.

프로덕트를 만드는 것만큼이나 중요한 것이 완성된 프로덕트를 잘 운영하는 것이다.

​

대체로 현업에서 일하다 보면, 새로운 것을 만드는 것에는 흥미를 많이 느끼는 개발자가 많지만 정작 가장 중요한 유지 보수 및 운영을 재미없어하는 개발자가 많다는 것을 알게 된다.

​

이유는 간단하다. 새로운 툴을 만들어 낸다는 것은 가장 트렌드가 되는 기술들을 이용하여 신개념의 무엇인가를 만들어내는 일이고, 유지 보수 및 운영을 한다는 것은 새로운 기술을 학습하기보단, 기존에 만들어졌던 산출물을 관리한다는 측면에서 배울 점이 크게 없다고 생각하기 때문이다.

​

하지만, 이는 지극히 경계해야 할 부분이라 생각된다. 새로운 것을 만드는 것과 기존의 것을 유지 보수하며 배울 수 있는 영역이 다르며, 유지 보수 및 운영을 한다고 해서 배울 수 있는 요소가 전혀 없는 것이 아니기 때문이다.

​

개인적으로 필자의 경우에는 유지 보수 / 운영하는 과정을 통해서 배운 점이 훨씬 많았었더랬다.

​

그런 점에서 이번에 출간된 도서인 Continuous Deployment는 유지 보수 / 운영 - 신규 개발을 통틀어 가장 중요한 CI/CD를 다루었다는 점에서 그 의의가 크다.

​

프로젝트를 진행하며 완성된 프로젝트를 지속적으로 배포하고 이를 자동화는 사이클을 반복하다 보면 자신도 모르게 배포 프로세스 + 안정적인 개발에 익숙해질 수 있기 때문이다.

​

이 책은 개발자에게 반드시 필요한 이 부분을 친절히 그리고 명확히 가이드하고 있다.

​

【책 내용 요약】

​

이 책은 지속적인 개발의 장점과 이를 통해서 얻을 수 있는 장점, 나아가 이를 고도화할 수 있는 방법을 제안하고 있다.

​

책의 구조는 다양한 사례를 예로 들어가며 상황에 맞게 저자가 생각했던 팁과 노하우를 요약해두었으며 이를 통해 얻을 수 있는 장단 점을 명확히 하여 독자로 하여금 이해를 돕고 있다.

​

책의 구성은 크게 아래와 같이 구성되어 있다.

• 지속적인 배포
• 개발 이전 단계
• 개발 단계
• 개발 이후 단계
• 사례 연구

​

지속적인 배포에서는 앞서 말한 바와 같이 지속적인 배포가 갖는 장점과 상황에 따른 접근법에 대한 이론적 지식을 정리하였고

​

개발 이전 단계, 개발 단계, 개발 이후 단계에서는 각 단계별 필요한 배포의 방법 이론을 설명하고 있다. 한 가지 예를 들자면 '개발 단계'에서는 신규 기능이 추가가 될 텐데, 어떻게 이를 격리하고 이에 대한 적절한 테스트와 안정적인 서비스 적용 방법이 가능한지 프론트, 백, DB 세 가지 컴포넌트 혼합 환경을 예를 들어 설명하고 있다.

​

【 지속적 배포를 읽고 나서 】

​

개발자가 된다는 것은 언제든 세상에 직면한 문제를 푸는 사람이 된다는 것을 의미한다. 하지만 문제를 푸는 방식에는 여러 접근 방식이 있다. 하나는 새로운 무엇인가를 발명하여 해결하는 방법이고, 하나는 기존에 있던 해결 방법을 고도화하여 좀 더 세련되게 문제를 해결하는 방법이다.

​

필자가 생각하기에 배포는 어찌 보면 기존에 있던 문제 + 새로운 문제를 아주 세련되게 해결하기 위한 하나의 수단이자 개발자가 거쳐야 하는 필수 과정이라고 생각된다.

​

어찌 보면 익숙하지만 어찌 보면 익숙하지 않은 당연한 과정들을 이번 기회를 통해 효율화하고 개선할 방안이 무엇이 있는지 고민해 보는 시간을 갖는 것도 본인의 역량을 키우는 데에 소중한 시간이 될 수 있지 않을까?

​#본 도서는 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

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

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

배포와 릴리스 영역의 대명사인 Lean, DevOps, CI/CD 등의 개념과 장점을 대통합하여 SW를 항상 릴리스 가능한 상태로 유지하는 기술을 다룬다. SW 개발 분야의 반드시 필독해야 할 명작.

이 책은 SW 개발 방법론을 다루는 “리팩터링, 실용주의 프로그래머, 클린 코드, 디자인 패턴” 등의 고전과 어깨를 나란히 하는 명작이다. 그럼에도 앞서 언급한 도서와 달리 저평가된 것 또한 사실이다. 아무래도 제목만보고 SW 개발 전 과정에 덜 중요하게 인식되는 배포라는 단어가 포함되어서 일까?

SW 개발 관련 도서의 최대 취약점은 애매모호한 추상성에 있다. 추상화는 여러 복잡한 내용들을 간결하게 전달할 수 있지만 그만큼의 레벨에 진입하지 못한 독자들에게는 전달력이나 가독성 측면에서 어려움을 안긴다. 실제화된 코드나 경험이 있지 않고는 저자들의 통찰을 쉽게 빼먹기 힘들다.

이 책의 가장 큰 장점은 추상화 개념들을 구체화된 코드로 이해시켜준다는 데에 있다. 그것도 무려 “리액트, 스프링부트, SQL“이라는 각 계층별 현시점 가장 널리쓰이는 예제로 알려준다. 일찍이 이런 책을 본 적이 없다.

구체적인 예시는 직관력을 이용해 이해하기 쉽다는 장점이 있는 반면 숲을 보기 어렵다는 맹점이 있다. 더불어 내가 지금 어디쯤 위치하고 있는지 책을 읽으며 해메기 마련이다. 반면, 추상화된 개념은 전체를 아우르는 숲이나 실무를 접하면 알고 있는 개념만으로 문제를 해결하기 어렵다.

이 책은 이 두마리 토끼를 모두 잡을 수 있는 명작이다. 특히 유관 도서들이 꿋꿋하게 추상성을 지향해 온 반면 이 책은 구체적인 예시를 놓치지 않는다. 코드 수준의 접근은 물론 부록에는 다양한 기업들의 문제점과 해결책을 살펴보는 케이스 스터디 자료를 포함한다.

이 책이 다루는 주요 내용은 배포와 릴리스 영역에서 등장한 Lean, DevOps, CI/CD 등의 개념과 장점을 대통합하여 SW를 항상 릴리스 가능한 상태로 유지하는 기술을 다룬다. 이를 전반부, 중반부, 후반부로 인상깊었던 주요 쟁점을 요약해보려 한다.

전반부에서는 잘개 쪼개는 방식의 장점을 설명한다. 아래 그림의 원피스 플로 개념에서 볼 수 있듯이 큰 배치 방식에서는 작업이 한꺼번에 쌓여 대기하는 동안 비용이 누적되고, 실패나 오류가 뒤늦게 발견될 위험이 있다. 결과적으로 고객 가치 창출 속도가 느려지고, 전체 시스템 효율성이 낮아지는 문제가 발생한다.

이를 개선하기 위해 작은 배치 방식으로 작업을 나누면, 대기 시간과 리드타임이 단축되고, 지속 협업과 피드백이 활성화된다. 마치 컨베이어 벨트처럼 한 번에 하나씩 처리하는 식으로 시스템을 최적화함으로써, 오류 가능성을 줄이고 시장 대응력을 높일 수 있게된다.

또한, 프로듀서-컨슈머 시스템에서는 변경 사항이 어떻게 영향을 미치는지 명확히 파악하고, API 변경의 최소화와 체계적인 테스트 자동화를 적용해야 한다. 단계별로 충분한 테스트와 버전관리 전략을 구축해, API 삭제나 확장 시 컨슈머에 미치는 영향을 줄일 수 있다. 대규모 시스템이나 마이크로서비스 환경에서 API 변경 관리 및 소프트웨어 파이프라인 최적화가 얼마나 중요한지 보여주는 좋은 사례다.

더불어 배포와 릴리스가 명확히 구분되지 않으면, 개발팀은 코드가 실제 사용자에게 언제 노출되는지 확신하지 못해 혼란을 겪을 수 있다. 따라서, 배포와 릴리스를 명확히 분리한 운영 정책, 즉 기능 토글/관리자 설정 등으로 릴리스 시점을 조정할 수 있게 설계해야 한다.

저자는 개발자와 운영팀 간의 커뮤니케이션 프로세스를 강화해, 배포는 자주 하되 릴리스는 전략적으로 결정하는 현대적 배포 문화(CI/CD, 지속적 배포/릴리스 체계)를 채택하는 것이 효과적임을 강조한다.

또한, 아래의 “지속적 배포를 하지 않는 팀의 반복되는 재작업“도 눈여겨 볼 부분이다. 동일 기능에 문제가 반복적으로 발견되면서 재작업이 누적되고, 팀 전체의 생산성이 크게 저하되는 모양을 볼 수 있다.

이를 개선하기 위해 지속적 배포(Continuous Deployment) 및 자동화된 테스트 도입을 통해 기능 개발 후 즉시 배포와 검증이 호환되도록 구조를 개선해야 하며, CI/CD 시스템 등을 활용해 배포 절차를 자동화하고, 모든 코드 변경이 빠르고 안전하게 적용되게 함으로써 반복 재작업의 악순환을 근본적으로 해소할 수 있다.

파트2 이후로는 보다 구체적인 실전 사례를 포함한다. 아래 그림은 전자상거래 예시를 바탕으로 장바구니 추가 버튼 기능이 여러 레이어(프론트엔드, 백엔드, 퍼시스턴스)에 걸쳐 어떻게 변경되는지를 보여준다. 또한, 기능 구현 시 각 연관된 요소가 어떻게 영향을 받고, 모든 레이어의 업데이트가 필요한 복잡한 현실을 시각적으로 설명하는 좋은 예시이다.

기능 추가가 단순한 UI 버튼 배치만으로 끝나지 않고 각 레이어의 여러 컴포넌트가 서로 얽혀 있어 변경이 복잡하게 전파되기에, 프론트엔드, 백엔드, 퍼시스턴스(데이터 저장소)를 아우르는 통합 설계와 일관된 인터페이스, 공통 이벤트 처리 구조를 도입함으로써 수정 범위와 복잡성을 줄일 필요가 있음을 보여준다.

이를 통해 테스트 자동화 및 코드 리뷰를 통해 전체 업데이트 상황을 체계적으로 점검하고, 변경 사항이 모든 계층에 올바르게 적용됐는지 검증하는 프로세스가 필요함을 알 수 있다.

아래 이미지는 소프트웨어 개발에서 각 유저 스토리에 대해 기능 요건(CFR)이 어떻게 영향을 미치는지를 층별로 표현한 구조도이다.

기능 구현 시 CFR(예: 보안, 성능, 테스트 등) 고려가 소홀하면, 실제 배포 및 운영 과정에서 장애, 유지보수 난이도, 품질 저하 등 다양한 문제가 반복적으로 발생할 수 있다. 따라서, 주요 CFR 요소별 체크리스트를 만들어, 모든 기능 개발 단계마다 선행 점검 및 검증을 필수화하는 체계를 갖춰야 한다.

이어지는 중반부는 이 책의 하이라이트라고 할 수 있는 구체적인 예제 중심의 솔루션이 등장한다.

아래 데이터베이스와 API 설계 변화, 그리고 확장·이동·축소 등 여러 시나리오에서 products 테이블과 basket 테이블, 그리고 장바구니 추가 API가 어떻게 변경되는지를 단계별로 보여주는 예시를 보자.

데이터베이스와 API가 확장·축소·구조 변경될 때마다 products와 basket 테이블, 그리고 연동 API에 대한 수정 사항이 다수 발생하여 시스템 전반에 복잡한 연관 효과가 이어질 수 있기에, 테이블과 API 설계를 모듈화・추상화하여, 각 확장/축소/이동 단계에서 영향 범위를 최소화하는 방식으로 리팩터링과 구조 개선을 병행해야 한다.

또한, 데이터 손실도 중요한 이슈이다. 아래 그림은 데이터베이스 스키마 변경과 이중 쓰기 전략의 기본 원리를 설명한다. 새로운 컬럼 추가 후, API・UI에서 두 컬럼을 모두 지원하여 안정적으로 데이터 이전을 수행하는 전략을 보여주는 예시이다.

특히, 개인적으로는 프로덕션에서 테스트를 수행하는 방식이 궁금했기에 파트4를 가장 눈여겨 보았다. 웹 브라우저 환경에서 쿠키와 헤더를 이용한 기능 토글 정보 전달 방식의 차이를 예시가 이 파트를 설명하는 좋은 예시이다.

즉, 프로덕션 환경에서 기능 토글이나 쿠키 등 사용자별 조건 데이터를 활용해 실시간 테스트(A/B 테스트 등)를 수행하는 방식을 강조한다.

실제 서비스 운영 중에 브라우저의 쿠키 또는 요청 헤더에 특정 값을 넣어, 사용자의 요청에 따라 다르게 동작하는 화면이나 기능(추천 상품 등)을 동적으로 노출함으로써, 프로덕션 환경 자체에서 안전하게 새로운 기능이나 개선 사항을 테스트할 수 있도록 설계해야 함을 보여준다.

후반부는 파트5 사례연구이다. 오토스카우트24, N26 같은 글로벌 기업들이 지속적 배포를 도입하면서 생긴 긍정적 효과와 시행착오를 다루며 지속적 배포가 어떻게 조직 문화 및 업무 프로세스에 영향을 미치는지 실제 사례와 함께 상세히 안내한다. 진정한 DevOps 문화를 파악할 수 있게 도움을 주는 사례이다.

그 외에도 위에 다루지는 않았지만 DORA 성과지표 관리, 빠르게 파이프라인을 유지하는 스킬, 스테이트리스 유지, 이벤트 기반 아키텍처 전환, 동시성과 롤백 최소화, 하드 스킬 외에도 조직 문화 중심의 소프트 스킬 등 한페이지 한페이지가 모두 주옥같은 내용이 가득하다.

좋은 싫든 AI 시대가 도래했다. 커서와 같은 바이브 코딩 도구를 사용한 이라면 모두 느끼겠지만 커서에게 지시를 내릴 때도 잘개 쪼개어 통합하는 스킬이 중요하다.

SW 공학 방법론이 너무 추상적이기에 개발 실무에서 시간 대비 얻는 것이 미약하여 외면되어 왔지만 AI의 등장으로 코딩 및 실무 중심 서적보다 더욱 중요한 위치로 자리매김하는 중이다. 바이브 코딩 도구라는 유능한 부하직원이 생겼기에 설계능력은 앞으로 매우 중요해질 것이다. 그런 점에서도 이 책은 필독서라 하겠다.

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

기술 면접을 준비하던 시절, CI/CD를 명확하게 이해하지는 못했지만 Vercel이나 Github Action을 통해서 ‘딸깍 배포’를 경험하며 대략적인 의미를 짐작할 순 있었다. 당시의 사이드 프로젝트는 긴밀한 배포가 필수적이진 않아서 그 필요성이 크게 피부에 와닿지는 않았다. 하지만 이전에 다니던 회사에서 터미널로 고군분투하며 배포하던 서버 개발자의 모습이 떠올라, CI/CD 환경을 구축하고 ‘딸깍’하는 게 개발자 경험에 크게 영향을 미친다는 걸 심정적으로 받아들일 수 있었다(심지어 어렵게 배포했더니 한 줄 누락됐다고 다시 배포해달라는 요청은 덤).

책의 추천사에도 언급되어 있듯이, 과거 매주 한 번이나 매일 한 번 정도였던 릴리즈가 이제는 매초 한 번 릴리즈를 밀어붙이는 회사도 있을 정도로 배포의 경계가 완전히 달라졌다. 실제로 모 회사에서는 하루에 300번 이상 배포를 하는 날도 있다고 하는데, 이처럼 지속적으로 배포할 수 있는 환경을 잘 구축하는 건 기능을 잘 만드는 것과 마찬가지로 중요해졌다. 현재의 업무 환경에서는 Jenkins를 통해 배포 환경을 구축하고 사용하고 있지만, 지속적 배포라는 개념을 다소 추상적으로만 받아들인 부분도 있고, 다른 회사들은 어떤 배포 환경에서 개발자가 작성한 코드가 사용자에게 당도하기까지 어떤 흐름을 구성하는지 궁금했다. 그런 측면에서 단순히 기술을 넘어 지속적 배포가 어떤 가치를 가졌고, 어떤 환경 구성을 통해 실무에 온전히 정착시킬 수 있는지 알고 싶어 이 책을 읽게 되었다.

개발자라면 더욱 여실히 느끼겠지만 기술은 빠르게 변화하고 있다. 배포 환경 또한 크게 다르지 않다. ‘데브와 옵스 사이의 장벽’이라는 과거 분리된 환경의 이야기부터 현재의 지속적 배포에 이르기까지, 다양한 변화 속에서 배포 환경은 진화해 왔다.

가장 인상적이었던 부분은 프로덕션 배포에서 수동 승인 절차를 제거한다는 것이 개발자가 코드를 작성하는 사고방식 자체를 바꿔야 한다는 지적이었다. 실제로 프로덕션에 해당되는 브랜치에 불필요한 커밋이 있는 걸 종종 봐왔고, 나 또한 몇 가지 테스트를 한다는 명목으로 부주의하게 병합한 적도 있었다. 수동 승인 절차가 있을 땐 다시 병합하면 될 일이지만, 완전한 지속 배포의 흐름에 놓인다면 하나의 커밋이 가지는 무게감이 완전히 달라질 수 있다는 것이다.

이어지는 맥락에서 언급된 그릇된 보안 의식(sense of security)에 대한 부분이 특히 인상적이었다. 개발자가 코드를 짤 때 프로덕션 배포에 다른 누군가의 수작업이 필요하다는 사실을 아는 것과 모르는 것에는 큰 차이가 있다는 것이다. 변경 사항의 정의와 적용 사이의 구분이 사라지면 코드를 작성하는 행위 자체가 달라진다고 말하는데, 요약하자면 ‘개발이 끝난 이후’라는 단계는 존재하지 않는다는 것이다. 말 그대로 개발 단계에서부터 모든 품질 보증 단계를 완료하여 프로덕션에서 발생할 이슈를 미리 해결해야 한다는 의미로, 의식의 큰 차이가 생긴다는 것이었다. 이런 의식의 변화만을 위해 지속적인 배포 환경을 만드는 것은 아니겠지만, 개발 품질을 바라보는 관점이 완전히 달라질 수 있다는 점에는 충분히 공감할 수 있었다. 또한 새로운 기능을 개발할 때 단순히 별도의 기능 브랜치를 만들어 작업한 경우가 대부분이었는데, 이 책에서 언급하는 기능 토글이나 확장/축소 패턴으로 접근하는 방식은 새로웠다.

배포와 릴리즈를 나눠서 보는 시각도 구체적이고 실용적이었다. 가시성이나 이해관계자 등 여러 차이가 있지만, 간단히 말해 성능 개선을 위한 리팩토링은 프로덕션 배포이고 A/B 테스트를 위한 서비스의 변경은 릴리즈라고 볼 수 있다. 즉 엔드 유저까지 맞닿아 있는 동작이라면 릴리즈에 해당되는 건데, 실제 액션 자체는 비슷하다 보니 이 경계가 모호하게 느껴지기도 한다. 다만 이를 구분하고 다르게 바라보려는 시각은 충분히 의미가 있다고 생각한다.

잦은 통합을 위해 수명이 짧은 브랜치와 기능 브랜치, 그리고 TBD(Trunk Based Development)를 다루는 부분에서는 특히 TBD에 대해 다시 살펴볼 기회가 되었다. 지속적 배포를 위한 고려 사항으로는 서버 내 세션이나 인스턴스, 상태에 대한 언급 외에도 클라이언트 사이드에서의 캐시 무효화 등 실무에서 익숙하게 마주하는 구체적인 부분도 함께 다뤄져 있어 실용적이었다.

지속적 배포를 위해 개발 전 단계에서의 이론적 기반도 체계적으로 제시되어 있다. 수평 분할보다 수직 분할의 이점을 강조하거나, 효과적인 수직 분할을 위해서 기능을 단순한 형태로 축소하기 위한 익숙한 MVP 또한 언급된다. 그리고 유저 스토리를 세분화하기 위한 INVEST 원칙(Independent, Negotiable, Valuable, Estimable, Small, Testable)은 의미 있는 유저 스토리를 위해서 어떤 관점에서 접근해야 하는지에 대한 가이드라인을 제시한다.

프로덕션에서의 배포를 다양한 전략으로 관리하는 방법 또한 흥미로웠다. 최상위 토글이나 중첩 토글을 통해 기존 기능의 증분이나 신규 기능을 관리하거나, 확장/축소 패턴으로 숨기기, 버전 관리 브랜치 안에 숨기기 등의 방법이 있었다. 또한 이런 방식으로 커버가 어려운 부분은 파이프라인을 일시적으로 중지하고 로컬에서 검증하는 방법 또한 제시되어 있다. 확실히 지속적 배포라는 건 도입 전과 후에 관점과 행동에서 다양한 차이를 가져올 수 있다는 걸 다시금 깨달을 수 있었다. ‘지속적(Continuous)’이라는 말이 가진 무게감을 여러 장치를 통해 몸소 느낄 필요가 있다는 말처럼 느껴졌다.

파트 2까지는 전반적인 개념과 원칙을 설명했다면 파트 3에서는 ‘그로서루’라는 가상의 회사를 통해 실제 배포의 흐름을 구체적으로 설명한다. 새로운 기능을 추가하는 경우와 기존 라이브 기능의 기술 부채를 해결하기 위한 리팩토링의 경우로 크게 나누고, 프론트엔드와 백엔드 각각의 예시 코드를 통해 이해를 돕는다. 이론적 설명과 실제 구현 사이의 간극을 이 파트를 통해 효과적으로 메워주었다.

파트 4에서는 프로덕션에서의 테스트 필요성을 체계적으로 설명한다. 이 책의 전반적인 흐름은 무언가 해야 한다는 액션을 제안하고 그에 따른 근거를 제시하는 형식으로 구성되어 있는데, 그 근거가 간소화되어 있더라도 그 액션에 대한 공감대가 형성되어 있는 사람이라면 다소 장황하게 느껴질 수 있었다. 예를 들어 프로덕션 테스트의 근거로 데이터 볼륨의 정확도, 형상의 정확도, 실제 요청 패턴이나 네트워크 구성, 혹은 애플리케이션 구성 등을 제시하고 있는데, 사실 프로덕션에서 테스트가 필요한 자연스러운 이유였다.

마지막 파트 5에서는 실제로 지속적 배포를 도입한 회사들의 사례를 언급한다. 각 회사들이 어떤 상황이나 배경에서 지속적 배포의 필요성을 느꼈는지, 그리고 도입한 이후 어떤 장점을 얻었는지를 언급한다. 회사마다 처한 상황이 다르기도 하고, 또한 나의 상황 혹은 한국의 상황과도 어떤 면에선 차이가 있어서 가볍게 훑고 지나갔지만, 유사한 상황에 놓여 있는 조직이라면 어떻게 대응해 나갔는지 비교해 보기엔 좋을 것 같다는 생각이 들었다.

이 책을 읽으면서 깨달은 것은 지속적 배포라는 것이 단순히 배포 자동화를 넘어서는 조직 전체의 개발 문화와 사고방식을 바꾸는 변화라는 점이다. 특히 이 책은 온전히 기술에만 국한되어 있지 않다. 배포라는 행위 이전에 필요한 많은 프로세스가 있고, 그 프로세스를 어떻게 체계적으로 구축해야 하는지에 대해 상세히 다루고 있다. 이는 곧 모든 내용을 한 번에 받아들이기보다는 본인에게 필요한 부분을 먼저 소화한 후 점진적으로 확장해 가는 접근이 효과적일 거라고 생각한다.

개인적으로 인프라와 관련된 내용이 생소해서 더욱 어렵게 느껴지는 부분도 있었지만, 그럼에도 불구하고 관심 있는 파트부터 하나씩 찾아보면서 점진적으로 확장해 나간다면, 개념적으로 좀 더 부드럽게 받아들일 수 있을 것 같다는 생각이 들었다.

결국 지속적 배포는 단순한 기술적 도구가 아니라, 더 나은 소프트웨어를 더 빠르고 안전하게 사용자에게 전달하기 위한 종합적인 철학이자 문화적 변화라는 것이 이 책이 전하고자 하는 핵심 메시지인 것 같다. 이러한 관점에서 이 책은 지속적 배포를 도입하려는 개발자와 조직 모두에게 실용적인 가이드가 될 수 있지 않을까 싶다.

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

소프트웨어 업계에서 배포는 여전히 가장 큰 두려움 중 하나다. 코드 품질이나 기능 구현보다도 “안전하게 배포할 수 있는가”가 팀의 성숙도를 결정짓는 경우가 많다. 이 책은 바로 그 지점을 파고든다. 단순히 CI/CD 도구 사용법을 알려주는 안내서가 아니라, 조직이 왜 지속적 배포를 선택해야 하고, 어떤 방식으로 도입할 수 있는지 전체 맥락을 짚어 준다.

책은 지속적 배포의 배경과 흐름을 차근차근 짚어 가며 시작한다. 익스트림 프로그래밍, 데브옵스, 지속적 통합과 전달 같은 흐름이 결국 어디로 수렴하는지 보여주면서, 지속적 배포가 단순한 유행어가 아니라 필연적인 진화임을 설득한다. 특히 “배포는 릴리스가 아니다”라는 메시지가 인상 깊다. 코드가 언제든 운영 환경에 반영될 수 있는 상태로 유지된다는 점은 단순히 기술의 문제가 아니라, 팀 사고방식의 전환을 요구한다.
 
실무적인 챕터들도 잘 짜여 있다. 백로그 분할을 어떻게 해야 점진적인 배포가 가능한지, 데이터 손실을 최소화하기 위해 어떤 전략이 필요한지, 기능 토글이나 카나리 릴리스 같은 릴리스 패턴이 실제로 어떻게 활용되는지 구체적인 사례와 함께 설명한다. 추상적인 원칙만이 아니라 “그로서루” 같은 예제 애플리케이션을 통해 현장에서 마주칠 문제를 풀어내는 방식이 현실적이다.
 
글로벌 기업들의 실제 사례는 이 책의 메시지를 더욱 설득력 있게 만든다. 오토스카우트24, N26, 트래블퍼크 등 각기 다른 도메인의 조직들이 어떻게 지속적 배포를 도입했고, 어떤 조직적·문화적 변화를 만들어냈는지 읽다 보면, 이 개념이 단순히 기술 스택의 문제가 아니라 비즈니스 경쟁력과 직결된 전략임을 실감하게 된다.
 
이 책은 단순히 CI/CD 구축 방법론을 설명하는 안내서가 아니라, 개발자와 팀이 변화에 어떻게 대응하고 성장해야 하는지를 보여주는 로드맵에 가깝다. 기술적 디테일과 조직 문화, 그리고 실제 사례까지 한 권에 담겨 있어, 지금 당장 배포 프로세스를 개선하고 싶은 팀뿐만 아니라 장기적으로 소프트웨어 전달 문화를 새롭게 정립하고자 하는 이들에게도 유효하다. 지속적 배포를 고민하는 모든 팀에게 이 책은 가장 든든한 길잡이가 되어 줄 것이다.
 

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

이 책은 현대 소프트웨어 개발의 핵심인 지속적 배포(Continuous Deployment)를 심도 있게 다루는 실무 지침서입니다.

단순히 배포 자동화 기술을 나열하는 데 그치지 않고, 안정적이고 신속한 배포 시스템을 구축하기 위한 개발 문화, 전략, 구체적인 실천 방법을 균형 있게 제시합니다.

이 책의 가장 큰 장점은 '왜' 지속적 배포가 필요한지부터 시작하여 '어떻게' 실무에 적용할 수 있는지까지 체계적으로 안내한다는 점입니다.

책의 핵심 주제인 트렁크 기반 개발(Trunk-Based Development)과 기능 토글(Feature Toggles)에 대한 설명은 이론과 실용성을 겸비했습니다.

여러 개발자가 하나의 '트렁크' 브랜치에서 협업하며 발생하는 충돌을 최소화하고, 기능 토글을 이용해 미완성된 기능도 안전하게 프로덕션 환경에 배포하는 전략은 독자들에게 새로운 통찰을 제공합니다.

또한, 리액트(React), 스프링 부트(Spring Boot), SQL을 아우르는 실전 예제 코드를 통해 실제 프로젝트에 적용해 볼 수 있도록 돕습니다.

더 나아가 글로벌 기업들의 실제 사례를 통해 지속적 배포가 어떻게 기술 문화를 혁신하고 비즈니스 성과로 이어지는지 생생하게 보여줍니다.

이 책은 지속적 배포를 처음 접하는 입문자보다는 어느 정도 개발 및 배포 경험이 있는 엔지니어, DevOps 담당자, 그리고 효율적인 개발 문화를 만들고자 하는 팀 리더에게 더 큰 울림을 줄 것입니다.

더 빠르고 안정적인 소프트웨어 제공을 고민하는 모든 개발 조직에게 필독서가 될 만한 책입니다.

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

뛰어난 과학 저술가 "스티븐 존슨"은 2012년에 출간된 <탁월한 아이디어는 어디서 오는가>에서 "탁월한 아이디어"가 나타나는 방식을 설명 했습니다. 그 중에 가장 인상 깊었던 부분은 "태양의 흑점, 전기 배터리, 전화, 전보, 증기기관, 사진, 진공관, 라디오" 같은 발견과 발명이 세계 곳곳에서 동시 다발적으로 나타났다는 점인데요.

그 이유는 "탁월한 아이디어"를 이끌어낼 만한 과학적 토대나 기술이 알려진 후, 그걸 사용한 선구자들이 동일한 결과를 내놨기 때문입니다.

​

<지속적 배포>를 읽는 내내, "탁월한 아이디어" 돌출 과정에 대한 이미지가 머릿속을 떠나지 않았습니다. "지속적 배포"는 소프트웨어 공학 분야에서 "탁월한 아이디어"라 불릴만한 결과이자, 또다른 탁월한 아이디어를 돌출할 수 있는 과정으로 보였기 때문입니다.

​

1995년, 프레드릭 브룩스는 <맨 먼스 미신> 20주년 판을 내놓으면서 의미심장한 주장을 했습니다. "구축(빌드)이란 은유는 그 자체의 유용함의 한계를 넘어 너무 오래 사용되었다. 이제 다시 바뀌어야 할 때가 되었다", "소프트웨어를 구축이 아니라 성장 시켜라"

비슷한 시기, 실무에서는 가볍고 반복적인 프로세스가 소프트웨어 개발에 더 유용하다는 이론을 체계화한 사람들이 있었습니다. 그리고 2001년 그들이 모여서 "애자일 소프트웨어 개발 선언"이란 걸 만들었지요. 그 중 XP(익스트림 프로그래밍)이라는 방식의 실천법에 CI(지속적 통합)이 등장합니다. CI의 철학은 궁극적으로 CD를 지향하고 있었습니다. 그래서 이러한 개념은 "린 소프트웨어" 개발 방식의 발전과 더불어서 DevOps라는 새로운 용어로 정의 되기 시작했고, 이 책 <지속적 배포>에도 언급된 <디지털 트랜스포메이션 엔진>을 통해 CD(지속적 배포)가 기업 생존에 근본적이고 중요한 개념임이 증명하기에 이르렀습니다.

​

<지속적 배포>는 이와 같은 변화의 결과와 같은 책입니다.

저자는 "지속적 배포"의 개념적 설명을 명확하게 하고 실무에서 어떻게 적용할지도 소스코드 레벨에서 설명하고 있으며, 그 과정에서 발생할 문제점들도 상당히 구체적으로 제시하고 있습니다. 그럼에도 불구하고 이를 완성한 다수의 서비스들에 대해서 그 예를 들어 줌으로써 "지속적 배포"가 단순히 누군가의 이론이 아니라 실제 결과를 내고 있는 "탁월한 아이디어"임을 증명해 주고 있군요. 이 정도로 완성도 있는 책을 누군가 쓸 수 있다면, "지속적 배포"라는 개념은 이제 가설이 아니라 법칙이고 사실임을 받아들여야 할 때가 아닌가 싶었습니다.

​

뿐만 아니라 "지속적 배포"라는 개념은 "미래를 만들어갈 사람들"에게 중요한 토대라고 생각했습니다.

​

최근 몇년간 IT업계의 변화는 현기증이 날정도로 빨랐습니다. 우리 선배들은 상상하지도 못했던 일들을 우리는 AI를 통해 눈으로 보고 손으로 만질 수 있게 되었거든요. 이러한 변화가 현재는 단순히 AI자체를 사용하는 서비스(예를 들어 채팅화면을 통해 정보를 검색하고 정리해주거나 이미지, 동영상을 만들어 주는 서비스가 있죠. )로 나오고 있지만, 이제 점차적으로 이미 우리가 사용하던 소프트웨어 자체에 영향을 주게 될 것입니다. 이런 식의 변화는 많은 걸 바꾸게 될 텐데요.

이런 변화의 시대에 대해 "나심 니콜라스 탈레브"는 "불확실성"에 대해 말하는 저서 <블랙스완>에서 "블랙스완"이라고 명명했습니다. <블랙 스완>은 우리가 당연하게 여겼던 상식이 파괴되는 현상을 말하는데요. 탈레브는 한 농장에 살고 있는 칠면조를 예로 듭니다. 1000일 동안 매일 모이를 넣어 주던 농장주인이 도살자로 변하게 되는 추수감사절 전날이 바로 "블랙 스완"인 셈이죠.

탈레브는 다른 저서 <안티프래질>에서 이런 변화를 바람으로도 비유했는데요. "바람은 촛불 하나는 꺼뜨리지만 모닥불은 살린다"라고 말합니다. 블랙스완 시기에 농장주 손에 붙잡힌 칠면조가 '촛불'이라면, 이런 상황을 간파하고 농장을 탈출한 칠면조는 "모닥불"이 됩니다.

​

"지속적 배포"는 AI로 빠르게 변화하는 시대에 우리와 우리가 일하는 회사를 "모닥불"로 변화시킬 "탁월한" 토대가 아닐까 싶습니다. 우리가 지금까지 고수해왔던 소프트웨어 개발 방식은 우리에게 닥칠 상황에선 너무 느린 방식이거든요.

​

그래서, <지속적 배포>를 읽는 이번달 내내, 회사 동료들에게 <지속적 배포> 책 이야기를 했습니다. 필독서이며, 개인의 생존과 우리 조직의 생존을 위해 매우 중요한 책이라고 말이죠.

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

이번에 읽은『지속적 배포』는 자동화 기술을 넘어, 개발 조직 전체의 경쟁력을 좌우하는 핵심 문화임을 보여주는 책입니다. 저자는 자신이 겪은 실무 경험과 사례를 바탕으로, 왜 우리가 지속적 배포를 도입해야 하는지 다양한 각도에서 풀어내고 있습니다.

책을 읽어나가다 보면, 배포가 빨라진다는 차원을 넘어 시장 변화에 빠르게 대응하고 장애와 위험을 신속하게 극복하는 토대가 바로 '지속적 배포'임을 자연스럽게 체감하게 됩니다. 실제로 발생했던 장애 사례들을 통해 독자들이 깊이 공감할 수 있는 이야기를 전하며, "배포 자동화가 참 귀찮고 어려울 수도 있지만, 결국 현장에서 반드시 필요하겠구나"라는 생각을 저절로 들게 합니다.

책의 가장 큰 장점은 기능 토글, 롤아웃/롤백, 카나리 배포, A/B 테스트 등 실무 핵심 개념들을 직관적인 그림과 다이어그램으로 시각화하여 설명한다는 점입니다. 글로만 보면 어려웠던 배포 전략이 머릿속에 선명하게 남고, 복잡한 배포 시나리오를 쉽게 파악할 수 있도록 돕습니다. 덕분에 저 역시 기존에 잘 몰랐던 카나리 배포와 A/B 테스트의 차이, 어떤 상황에서 어떻게 쓰면 좋은지 잘 이해할 수 있었습니다.

마지막 장에서는 오토스카우트24, 오토 등 (제가 잘 모르지만 잘 나가는 회사들이네요) 여러 IT 기업들이 겪은 사례를 바탕으로, 각기 다른 환경에서 지속적 배포가 실제로 도입되고 정착된 과정을 소개합니다. 실제 현업에서 참고할 수 있을 만큼 구체적이었습니다.

책은 저자의 진솔한 경험과 시행착오에서 쌓아온 노하우와 현장에서만 얻을 수 있는 조언이 담겨 있었습니다. 다만, 배포 자동화나 CI/CD 개념에 익숙하지 않은 입문자에게는 전문 용어가 다소 어렵게 느껴질 수 있어, 기본적인 개발 경험이 있는 분들에게 더 큰 도움이 될 것 같습니다.

『지속적 배포』는  개발자와 엔지니어만을 위한 책를 넘어서 팀과 조직 전체, 나아가 고객 경험까지 변화시킬 수 있는 근본적 문화로서의 지속적 배포를 설득력 있게 전달하고 있습니다. '지속적 배포'라는 문화가 정착되면 서비스 장애나 변화가 두렵지 않게 된다는 저자의 말처럼, 이 책은 새로운 성장 방향을 구체적으로 그려볼 수 있는 든든한 가이드가 되어줄 것입니다.

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

한빛미디어에서 멋진 소프트웨어 공학책을 보내주셨다. 정말 바쁘고 힘든 직장생활에도 불구하고 (사실 출퇴근만 4시간이 넘게 걸린다) 이렇게 좋은 기회로 책을 받게 되어서 의무(?)감으로 열심히 틈틈히 읽고 있습니다.

어디에 내놓아도 다 어울릴만한 문장인데요. 

'힘들수록 더 자주하라' 

귀찮을 만큼 반복적으로 나오는 문장입니다. 그만큼 중요하다는 의미를 갖고 있는데요.

실무에서 사람이 일일이 귀찮게 해야 하는 일들을 힘들다고 표현한 것이죠. 그래서 자주 하지 않는 상황을 초반부터 순서도를 반복적으로 보여주며 여기에서는 이렇게 해야해. 그리고 다음은 이렇게 해야 하지. 결국 사람이 손을 대는 부분이 없어지게 되는거야 하고 설명을 상세히 해줍니다.

어떤 부분에서는 '어! 지지난 프로젝트에서 구축했었던 배포환경과 동일한 부부이네!'하고 공감이 가는 부분도 있습니다. 물론 앞부분에서 비슷한 상황을 읽게 되지만 뒤로 갈 수록 뭔가 더 엄청난 자동화가 일어나고 있죠.

중반 이후로는 경험해보지 못한 부분이 많아서 그냥 앞으로 겪거나 해야할 경험을 간접적으로 하게되는 것 같았습니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위한 책을 협찬 서평입니다.

지속적 배포는 단순히 배포를 빠르게 하는 기술이 아니라, 개발과 운영을 연결하는 조직 문화의 변화를 요구하는 중요한 주제라는 사실을 이 책을 통해 다시 확인할 수 있었습니다. 이 책은 기초부터 심화까지 균형 있게 다루고 있으며, 글로벌 기업들의 사례를 통해 각 조직 환경에 맞는 적용 방법을 고민할 수 있도록 돕습니다. 금융권과 같이 보수적인 환경에서도 충분히 활용 가능한 방법론을 제시하고 있다는 점에서 실질적인 참고서로 손색이 없다 생각합니다.

지속적 배포를 학습하려는 개발자와 운영자뿐 아니라, 조직 차원에서 안정적이면서도 민첩한 개발 문화를 정착시키고자 하는 분들께 꼭 읽어보시기를 권하고 싶습니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위한 책을 협찬 서평입니다.
 

『지속적 배포, 트렁크 기반 개발부터 자동화 배포, 기능 토글까지 실무에서 통하는 안전한 시스템 구축 가이드』는 '더 자주, 더 작게, 더 안전하게'라는 핵심 원칙을 바탕으로 현대 소프트웨어 개발의 필수 요소인 지속적 통합(CI)과 지속적 배포(CD)의 모든 것을 담아낸 실용적인 지침서입니다. 단순히 이론을 나열하는 데 그치지 않고, 코드 작성부터 사용자에게 전달되는 전 과정에 걸쳐 반복적이고 자동화된, 그리고 신뢰성 높은 시스템을 구축하는 노하우를 풍부하게 제시합니다.

이 책은 CI/CD 파이프라인의 역사적 배경을 짚어주며 독자의 이해를 돕고, 곧바로 실무에 적용할 수 있는 구체적인 전략들을 소개합니다. 특히 트렁크 기반 개발, 자동화된 배포 시스템 구현, 그리고 기능 토글 같은 핵심 개념들을 실제 사례와 함께 상세히 다루고 있습니다. 이는 개발팀과 운영팀의 경계를 허물고, 빠른 피드백을 통해 고객 중심의 시장 대응을 가능하게 하는 데 큰 도움이 됩니다.

이 책의 가장 큰 강점은 실용성입니다. 빌드와 테스트 자동화, 스테이징 및 프로덕션 환경으로의 자동 승격 등 현장 엔지니어와 DevOps 담당자가 직접 맞닥뜨리는 문제에 대한 현실적인 해법과 조언이 가득합니다. 소프트웨어 출시 과정의 반복성과 신뢰성을 확보하고, 코드베이스를 항상 배포 가능한 상태로 유지하는 다양한 프랙티스는 팀의 생산성과 효율성을 한 단계 끌어올리는 데 기여할 것입니다.

자동화된 배포 시스템 구축을 고민하는 모든 엔지니어와 DevOps 담당자, 그리고 민첩하고 효율적인 개발 문화를 정착시키고자 하는 모든 조직에게 이 책은 단순한 참고서가 아닌, 실제 시스템에 바로 적용 가능한 필수 실무 가이드가 될 것입니다.