사회 초년생 시절, 개발 현장에서 직접 서버에 수동으로 배포하는 일을 자주 경험했습니다. 당시 회사에서는 형상관리 도구로 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 워크플로로 쿠버네티스에 서비스를 배포하고 선언적 깃옵스 패턴으로 소스코드 뿐만 아니라 환경별 애플리케이션 구성을 추적할 때에 유용하게 사용한다고 합니다. 이로써 은행업의 규제에 대한 문제와 잘 맞은 것을 알 수 있었습니다. 이 포스팅은 한빛미디어에서 책을 받아 읽고 주관적으로 작성 했습니다. |
|
프로덕트를 만드는 것만큼이나 중요한 것이 완성된 프로덕트를 잘 운영하는 것이다. 대체로 현업에서 일하다 보면, 새로운 것을 만드는 것에는 흥미를 많이 느끼는 개발자가 많지만 정작 가장 중요한 유지 보수 및 운영을 재미없어하는 개발자가 많다는 것을 알게 된다. 이유는 간단하다. 새로운 툴을 만들어 낸다는 것은 가장 트렌드가 되는 기술들을 이용하여 신개념의 무엇인가를 만들어내는 일이고, 유지 보수 및 운영을 한다는 것은 새로운 기술을 학습하기보단, 기존에 만들어졌던 산출물을 관리한다는 측면에서 배울 점이 크게 없다고 생각하기 때문이다. 하지만, 이는 지극히 경계해야 할 부분이라 생각된다. 새로운 것을 만드는 것과 기존의 것을 유지 보수하며 배울 수 있는 영역이 다르며, 유지 보수 및 운영을 한다고 해서 배울 수 있는 요소가 전혀 없는 것이 아니기 때문이다. 개인적으로 필자의 경우에는 유지 보수 / 운영하는 과정을 통해서 배운 점이 훨씬 많았었더랬다. 그런 점에서 이번에 출간된 도서인 Continuous Deployment는 유지 보수 / 운영 - 신규 개발을 통틀어 가장 중요한 CI/CD를 다루었다는 점에서 그 의의가 크다. 프로젝트를 진행하며 완성된 프로젝트를 지속적으로 배포하고 이를 자동화는 사이클을 반복하다 보면 자신도 모르게 배포 프로세스 + 안정적인 개발에 익숙해질 수 있기 때문이다. 이 책은 개발자에게 반드시 필요한 이 부분을 친절히 그리고 명확히 가이드하고 있다. 【책 내용 요약】 이 책은 지속적인 개발의 장점과 이를 통해서 얻을 수 있는 장점, 나아가 이를 고도화할 수 있는 방법을 제안하고 있다. 책의 구조는 다양한 사례를 예로 들어가며 상황에 맞게 저자가 생각했던 팁과 노하우를 요약해두었으며 이를 통해 얻을 수 있는 장단 점을 명확히 하여 독자로 하여금 이해를 돕고 있다. 책의 구성은 크게 아래와 같이 구성되어 있다.
지속적인 배포에서는 앞서 말한 바와 같이 지속적인 배포가 갖는 장점과 상황에 따른 접근법에 대한 이론적 지식을 정리하였고 개발 이전 단계, 개발 단계, 개발 이후 단계에서는 각 단계별 필요한 배포의 방법 이론을 설명하고 있다. 한 가지 예를 들자면 '개발 단계'에서는 신규 기능이 추가가 될 텐데, 어떻게 이를 격리하고 이에 대한 적절한 테스트와 안정적인 서비스 적용 방법이 가능한지 프론트, 백, DB 세 가지 컴포넌트 혼합 환경을 예를 들어 설명하고 있다. 【 지속적 배포를 읽고 나서 】 개발자가 된다는 것은 언제든 세상에 직면한 문제를 푸는 사람이 된다는 것을 의미한다. 하지만 문제를 푸는 방식에는 여러 접근 방식이 있다. 하나는 새로운 무엇인가를 발명하여 해결하는 방법이고, 하나는 기존에 있던 해결 방법을 고도화하여 좀 더 세련되게 문제를 해결하는 방법이다. 필자가 생각하기에 배포는 어찌 보면 기존에 있던 문제 + 새로운 문제를 아주 세련되게 해결하기 위한 하나의 수단이자 개발자가 거쳐야 하는 필수 과정이라고 생각된다. 어찌 보면 익숙하지만 어찌 보면 익숙하지 않은 당연한 과정들을 이번 기회를 통해 효율화하고 개선할 방안이 무엇이 있는지 고민해 보는 시간을 갖는 것도 본인의 역량을 키우는 데에 소중한 시간이 될 수 있지 않을까? #본 도서는 "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
이 책은 SW 개발 방법론을 다루는 “리팩터링, 실용주의 프로그래머, 클린 코드, 디자인 패턴” 등의 고전과 어깨를 나란히 하는 SW 개발 관련 도서의 최대 취약점은 애매모호한 추상성에 있다. 추상화는 여러 복잡한 내용들을 간결하게 전달할 수 있지만 그만큼의 레벨에 진입하지 못한 독자들에게는 전달력이나 가독성 측면에서 어려움을 안긴다. 실제화된 코드나 경험이 있지 않고는 저자들의 통찰을 쉽게 빼먹기 힘들다. 이 책의 가장 큰 장점은
이 책은 이 이 책이 다루는 주요 내용은 배포와 릴리스 영역에서 등장한 Lean, DevOps, CI/CD 등의 개념과 장점을 대통합하여 SW를 항상 릴리스 가능한 상태로 유지하는 기술을 다룬다. 이를
이를 개선하기 위해 작은 배치 방식으로 작업을 나누면, 대기 시간과 리드타임이 단축되고, 지속 협업과 피드백이 활성화된다. 마치 컨베이어 벨트처럼 한 번에 하나씩 처리하는 식으로 시스템을 최적화함으로써, 오류 가능성을 줄이고 시장 대응력을 높일 수 있게된다. 또한, 더불어 저자는 개발자와 운영팀 간의 커뮤니케이션 프로세스를 강화해, 배포는 자주 하되 릴리스는 전략적으로 결정하는 현대적 배포 문화(CI/CD, 지속적 배포/릴리스 체계)를 채택하는 것이 효과적임을 강조한다. 또한, 아래의 “ 이를 개선하기 위해 지속적 배포(Continuous Deployment) 및 자동화된 테스트 도입을 통해 기능 개발 후 즉시 배포와 검증이 호환되도록 구조를 개선해야 하며, CI/CD 시스템 등을 활용해 배포 절차를 자동화하고, 모든 코드 변경이 빠르고 안전하게 적용되게 함으로써 반복 재작업의 악순환을 근본적으로 해소할 수 있다. 파트2 이후로는 기능 추가가 단순한 UI 버튼 배치만으로 끝나지 않고 각 레이어의 여러 컴포넌트가 서로 얽혀 있어 변경이 복잡하게 전파되기에, 프론트엔드, 백엔드, 퍼시스턴스(데이터 저장소)를 아우르는 통합 설계와 일관된 인터페이스, 공통 이벤트 처리 구조를 도입함으로써 수정 범위와 복잡성을 줄일 필요가 있음을 보여준다. 이를 통해 테스트 자동화 및 코드 리뷰를 통해 전체 업데이트 상황을 체계적으로 점검하고, 변경 사항이 모든 계층에 올바르게 적용됐는지 검증하는 프로세스가 필요함을 알 수 있다. 아래 이미지는 소프트웨어 개발에서 기능 구현 시 CFR(예: 보안, 성능, 테스트 등) 고려가 소홀하면, 실제 배포 및 운영 과정에서 장애, 유지보수 난이도, 품질 저하 등 다양한 문제가 반복적으로 발생할 수 있다. 따라서, 주요 CFR 요소별 체크리스트를 만들어, 모든 기능 개발 단계마다 선행 점검 및 검증을 필수화하는 체계를 갖춰야 한다. 이어지는 아래 데이터베이스와 API 설계 변화, 그리고 확장·이동·축소 등 여러 시나리오에서 products 테이블과 basket 테이블, 그리고 장바구니 추가 API가 어떻게 변경되는지를 단계별로 보여주는 예시를 보자. 데이터베이스와 API가 확장·축소·구조 변경될 때마다 products와 basket 테이블, 그리고 연동 API에 대한 수정 사항이 다수 발생하여 시스템 전반에 복잡한 연관 효과가 이어질 수 있기에, 테이블과 API 설계를 모듈화・추상화하여, 각 확장/축소/이동 단계에서 영향 범위를 최소화하는 방식으로 리팩터링과 구조 개선을 병행해야 한다. 또한, 특히, 개인적으로는 프로덕션에서 테스트를 수행하는 방식이 궁금했기에 파트4를 가장 눈여겨 보았다. 웹 브라우저 환경에서 쿠키와 헤더를 이용한 기능 토글 정보 전달 방식의 차이를 예시가 이 파트를 설명하는 좋은 예시이다. 즉, 프로덕션 환경에서 기능 토글이나 쿠키 등 사용자별 조건 데이터를 활용해 실제 서비스 운영 중에 브라우저의 쿠키 또는 요청 헤더에 특정 값을 넣어, 사용자의 요청에 따라 다르게 동작하는 화면이나 기능(추천 상품 등)을 동적으로 노출함으로써, 프로덕션 환경 자체에서 안전하게 새로운 기능이나 개선 사항을 테스트할 수 있도록 설계해야 함을 보여준다.
그 외에도 위에 다루지는 않았지만 DORA 성과지표 관리, 빠르게 파이프라인을 유지하는 스킬, 스테이트리스 유지, 이벤트 기반 아키텍처 전환, 동시성과 롤백 최소화, 하드 스킬 외에도 조직 문화 중심의 좋은 싫든 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에서는 실제로 지속적 배포를 도입한 회사들의 사례를 언급한다. 각 회사들이 어떤 상황이나 배경에서 지속적 배포의 필요성을 느꼈는지, 그리고 도입한 이후 어떤 장점을 얻었는지를 언급한다. 회사마다 처한 상황이 다르기도 하고, 또한 나의 상황 혹은 한국의 상황과도 어떤 면에선 차이가 있어서 가볍게 훑고 지나갔지만, 유사한 상황에 놓여 있는 조직이라면 어떻게 대응해 나갔는지 비교해 보기엔 좋을 것 같다는 생각이 들었다. 이 책을 읽으면서 깨달은 것은 지속적 배포라는 것이 단순히 배포 자동화를 넘어서는 조직 전체의 개발 문화와 사고방식을 바꾸는 변화라는 점이다. 특히 이 책은 온전히 기술에만 국한되어 있지 않다. 배포라는 행위 이전에 필요한 많은 프로세스가 있고, 그 프로세스를 어떻게 체계적으로 구축해야 하는지에 대해 상세히 다루고 있다. 이는 곧 모든 내용을 한 번에 받아들이기보다는 본인에게 필요한 부분을 먼저 소화한 후 점진적으로 확장해 가는 접근이 효과적일 거라고 생각한다. 개인적으로 인프라와 관련된 내용이 생소해서 더욱 어렵게 느껴지는 부분도 있었지만, 그럼에도 불구하고 관심 있는 파트부터 하나씩 찾아보면서 점진적으로 확장해 나간다면, 개념적으로 좀 더 부드럽게 받아들일 수 있을 것 같다는 생각이 들었다. 결국 지속적 배포는 단순한 기술적 도구가 아니라, 더 나은 소프트웨어를 더 빠르고 안전하게 사용자에게 전달하기 위한 종합적인 철학이자 문화적 변화라는 것이 이 책이 전하고자 하는 핵심 메시지인 것 같다. 이러한 관점에서 이 책은 지속적 배포를 도입하려는 개발자와 조직 모두에게 실용적인 가이드가 될 수 있지 않을까 싶다. |
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다."지속적 배포
뛰어난 과학 저술가 "스티븐 존슨"은 2012년에 출간된 ＜탁월한 아이디어는 어디서 오는가＞에서 "탁월한 아이디어"가 나타나는 방식을 설명 했습니다. 그 중에 가장 인상 깊었던 부분은 "태양의 흑점, 전기 배터리, 전화, 전보, 증기기관, 사진, 진공관, 라디오" 같은 발견과 발명이 세계 곳곳에서 동시 다발적으로 나타났다는 점인데요. 그 이유는 "탁월한 아이디어"를 이끌어낼 만한 과학적 토대나 기술이 알려진 후, 그걸 사용한 선구자들이 동일한 결과를 내놨기 때문입니다. ＜지속적 배포＞를 읽는 내내, "탁월한 아이디어" 돌출 과정에 대한 이미지가 머릿속을 떠나지 않았습니다. "지속적 배포"는 소프트웨어 공학 분야에서 "탁월한 아이디어"라 불릴만한 결과이자, 또다른 탁월한 아이디어를 돌출할 수 있는 과정으로 보였기 때문입니다. 1995년, 프레드릭 브룩스는 ＜맨 먼스 미신＞ 20주년 판을 내놓으면서 의미심장한 주장을 했습니다. "구축(빌드)이란 은유는 그 자체의 유용함의 한계를 넘어 너무 오래 사용되었다. 이제 다시 바뀌어야 할 때가 되었다", "소프트웨어를 구축이 아니라 성장 시켜라" 비슷한 시기, 실무에서는 가볍고 반복적인 프로세스가 소프트웨어 개발에 더 유용하다는 이론을 체계화한 사람들이 있었습니다. 그리고 2001년 그들이 모여서 "애자일 소프트웨어 개발 선언"이란 걸 만들었지요. 그 중 XP(익스트림 프로그래밍)이라는 방식의 실천법에 CI(지속적 통합)이 등장합니다. CI의 철학은 궁극적으로 CD를 지향하고 있었습니다. 그래서 이러한 개념은 "린 소프트웨어" 개발 방식의 발전과 더불어서 DevOps라는 새로운 용어로 정의 되기 시작했고, 이 책 ＜지속적 배포＞에도 언급된 ＜디지털 트랜스포메이션 엔진＞을 통해 CD(지속적 배포)가 기업 생존에 근본적이고 중요한 개념임이 증명하기에 이르렀습니다. ＜지속적 배포＞는 이와 같은 변화의 결과와 같은 책입니다. 저자는 "지속적 배포"의 개념적 설명을 명확하게 하고 실무에서 어떻게 적용할지도 소스코드 레벨에서 설명하고 있으며, 그 과정에서 발생할 문제점들도 상당히 구체적으로 제시하고 있습니다. 그럼에도 불구하고 이를 완성한 다수의 서비스들에 대해서 그 예를 들어 줌으로써 "지속적 배포"가 단순히 누군가의 이론이 아니라 실제 결과를 내고 있는 "탁월한 아이디어"임을 증명해 주고 있군요. 이 정도로 완성도 있는 책을 누군가 쓸 수 있다면, "지속적 배포"라는 개념은 이제 가설이 아니라 법칙이고 사실임을 받아들여야 할 때가 아닌가 싶었습니다. 뿐만 아니라 "지속적 배포"라는 개념은 "미래를 만들어갈 사람들"에게 중요한 토대라고 생각했습니다. 최근 몇년간 IT업계의 변화는 현기증이 날정도로 빨랐습니다. 우리 선배들은 상상하지도 못했던 일들을 우리는 AI를 통해 눈으로 보고 손으로 만질 수 있게 되었거든요. 이러한 변화가 현재는 단순히 AI자체를 사용하는 서비스(예를 들어 채팅화면을 통해 정보를 검색하고 정리해주거나 이미지, 동영상을 만들어 주는 서비스가 있죠. )로 나오고 있지만, 이제 점차적으로 이미 우리가 사용하던 소프트웨어 자체에 영향을 주게 될 것입니다. 이런 식의 변화는 많은 걸 바꾸게 될 텐데요. 이런 변화의 시대에 대해 "나심 니콜라스 탈레브"는 "불확실성"에 대해 말하는 저서 ＜블랙스완＞에서 "블랙스완"이라고 명명했습니다. ＜블랙 스완＞은 우리가 당연하게 여겼던 상식이 파괴되는 현상을 말하는데요. 탈레브는 한 농장에 살고 있는 칠면조를 예로 듭니다. 1000일 동안 매일 모이를 넣어 주던 농장주인이 도살자로 변하게 되는 추수감사절 전날이 바로 "블랙 스완"인 셈이죠. 탈레브는 다른 저서 ＜안티프래질＞에서 이런 변화를 바람으로도 비유했는데요. "바람은 촛불 하나는 꺼뜨리지만 모닥불은 살린다"라고 말합니다. 블랙스완 시기에 농장주 손에 붙잡힌 칠면조가 '촛불'이라면, 이런 상황을 간파하고 농장을 탈출한 칠면조는 "모닥불"이 됩니다. "지속적 배포"는 AI로 빠르게 변화하는 시대에 우리와 우리가 일하는 회사를 "모닥불"로 변화시킬 "탁월한" 토대가 아닐까 싶습니다. 우리가 지금까지 고수해왔던 소프트웨어 개발 방식은 우리에게 닥칠 상황에선 너무 느린 방식이거든요. 그래서, ＜지속적 배포＞를 읽는 이번달 내내, 회사 동료들에게 ＜지속적 배포＞ 책 이야기를 했습니다. 필독서이며, 개인의 생존과 우리 조직의 생존을 위해 매우 중요한 책이라고 말이죠. |
|
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."  이번에 읽은『지속적 배포』는 자동화 기술을 넘어, 개발 조직 전체의 경쟁력을 좌우하는 핵심 문화임을 보여주는 책입니다. 저자는 자신이 겪은 실무 경험과 사례를 바탕으로, 왜 우리가 지속적 배포를 도입해야 하는지 다양한 각도에서 풀어내고 있습니다. 책을 읽어나가다 보면, 배포가 빨라진다는 차원을 넘어 시장 변화에 빠르게 대응하고 장애와 위험을 신속하게 극복하는 토대가 바로 '지속적 배포'임을 자연스럽게 체감하게 됩니다. 실제로 발생했던 장애 사례들을 통해 독자들이 깊이 공감할 수 있는 이야기를 전하며, "배포 자동화가 참 귀찮고 어려울 수도 있지만, 결국 현장에서 반드시 필요하겠구나"라는 생각을 저절로 들게 합니다. 이 책의 가장 큰 장점은 기능 토글, 롤아웃/롤백, 카나리 배포, A/B 테스트 등 실무 핵심 개념들을 직관적인 그림과 다이어그램으로 시각화하여 설명한다는 점입니다. 글로만 보면 어려웠던 배포 전략이 머릿속에 선명하게 남고, 복잡한 배포 시나리오를 쉽게 파악할 수 있도록 돕습니다. 덕분에 저 역시 기존에 잘 몰랐던 카나리 배포와 A/B 테스트의 차이, 어떤 상황에서 어떻게 쓰면 좋은지 잘 이해할 수 있었습니다. 마지막 장에서는 오토스카우트24, 오토 등 (제가 잘 모르지만 잘 나가는 회사들이네요) 여러 IT 기업들이 겪은 사례를 바탕으로, 각기 다른 환경에서 지속적 배포가 실제로 도입되고 정착된 과정을 소개합니다. 실제 현업에서 참고할 수 있을 만큼 구체적이었습니다. 책은 저자의 진솔한 경험과 시행착오에서 쌓아온 노하우와 현장에서만 얻을 수 있는 조언이 담겨 있었습니다. 다만, 배포 자동화나 CI/CD 개념에 익숙하지 않은 입문자에게는 전문 용어가 다소 어렵게 느껴질 수 있어, 기본적인 개발 경험이 있는 분들에게 더 큰 도움이 될 것 같습니다. 『지속적 배포』는 개발자와 엔지니어만을 위한 책를 넘어서 팀과 조직 전체, 나아가 고객 경험까지 변화시킬 수 있는 근본적 문화로서의 지속적 배포를 설득력 있게 전달하고 있습니다. '지속적 배포'라는 문화가 정착되면 서비스 장애나 변화가 두렵지 않게 된다는 저자의 말처럼, 이 책은 새로운 성장 방향을 구체적으로 그려볼 수 있는 든든한 가이드가 되어줄 것입니다.    #지속적배포 #IT #개발 #데브옵스 #DevOps #CI #CD #배포자동화 #한빛미디어 #리뷰 #서평 |
|
지속적 배포는 단순히 배포를 빠르게 하는 기술이 아니라, 개발과 운영을 연결하는 조직 문화의 변화를 요구하는 중요한 주제라는 사실을 이 책을 통해 다시 확인할 수 있었습니다. 이 책은 기초부터 심화까지 균형 있게 다루고 있으며, 글로벌 기업들의 사례를 통해 각 조직 환경에 맞는 적용 방법을 고민할 수 있도록 돕습니다. 금융권과 같이 보수적인 환경에서도 충분히 활용 가능한 방법론을 제시하고 있다는 점에서 실질적인 참고서로 손색이 없다 생각합니다. 지속적 배포를 학습하려는 개발자와 운영자뿐 아니라, 조직 차원에서 안정적이면서도 민첩한 개발 문화를 정착시키고자 하는 분들께 꼭 읽어보시기를 권하고 싶습니다. |
|
[ "한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다." ] Continuous Deployment, 지속적 배포 (oreilly)
리뷰이제 github action 의 test code runing 하는 yaml 파일은 꼭 먼저 만들고 시작하게 된다. (물론 린팅 -＞ 테스팅 단계로) 하지만 이는 어디까지나 “최소한의 규칙 점검” 에 가깝다. 이 책이 묻는 본질은 한층 직설적이다. 우리는 왜 CI/CD를 구성하는가? 『지속적 배포』는 도구 사용법보다 팀이 공동으로 가져야 할 관점과 습관에 집중한다. O’Reilly 특유의 교과서적 정밀함과, 현장에 닿아 있는 실무성의 균형이 돋보인다. 책은 아래와 같은 5개의 파트로 이뤄져 있다. 개념을 모두 뿌려두고, S/W 생명 주기에 맞춰 이를 어떻게 적용하는지의 흐름이다.
책의 성격은 “사용법”이라기보다는 "팀 차원의 ‘계몽’과 행동 변화를 유도" 하는 책에 가깝다. 주관적인 하이라이트트렁크 기반 개발(TBD) - Trunk-Based Development책의 기본 원리는 명확하다. “더 작게, 더 자주, 더 안전하게.” 배포는 릴리스와 다르며, 코드는 항상 운영 환경에 들어갈 수 있어야 한다. 사용자는 기능 토글(Feature Toggles) 과 카나리(Canary) 등으로 노출을 통제한다. 핵심은 실패를 전제로 설계하는 것이다. “잘못된 커밋의 비율”보다 실패 감지 속도와 우아한 복구(낮은 MTTR) 가 더 중요하다. 긴 브랜치와 늦은 병합이 만들어내는 충돌 비용을 짧은 수명 브랜치 + 잦은 통합으로 끊고, 파이프라인 신뢰도를 높이며 커밋 단위의 책임을 선명하게 만든다.
기능 토글(Feature Toggles)
기능 토글은 미완성 기능도 배포 가능하게 만든다. 최상위/중첩 토글과 확장·축소 패턴으로 노출을 세밀하게 제어하며 배포와 릴리스의 결합을 해체한다. 운영 관점에서 중요한 것은 토글의 수명 관리다. 토글은 채무가 되기 쉽다.
작업 슬라이싱 전략수평 분할(레이어 중심)보다 수직 분할(사용자 가치 단위)을 우선한다. INVEST 원칙(
프로덕션 중심 품질 보증“승인 절차가 안전을 보장한다”는 착시에서 벗어나야 한다. 운영 환경에서만 검증 가능한 사실(데이터 볼륨/형상, 실제 트래픽 패턴, 네트워크·인프라 구성)을 근거로 프로덕션 테스트를 표준화한다.
전체 스택 예제와 현실 이슈React·Spring Boot·SQL로 이어지는 예제는 세션/상태, 클라이언트 캐시 무효화, DB 마이그레이션 같은 현업 난제를 직접 다룬다. 필요하면 파이프라인 일시 중지 → 로컬 검증 같은 우회 전략도 제시한다. DB는 Expand → Migrate → Contract(전개·이행·축소) 3단계로 안전하게 바꾸고, 배치·백필 작업은 멱등성과 재시도 정책으로 보호한다. 배포 전략은 서비스 성격에 따라 롤링/블루-그린/카나리를 선택한다. 사례 연구에서핀테크·이동 서비스·이커머스 등 서로 다른 도메인(N26, TravelPerk, AutoScout24 등)의 사례를 통해 CD → 조직 문화 혁신 → 배포 빈도 증가 → 비즈니스 민첩성으로 이어지는 경로가 드러난다. 이 파트는 기술 채택기를 넘어서 조직 변화기에 가깝다.
결론Part 1의 “왜 CD인가” 논증은 독자에 따라 다소 길게 느껴질 수 있다. 또한 관료성이 항상 악은 아니다. 어떤 조직은 git-flow·배치 릴리스를 유지해도 만족할 수 있다. 반대로 문화 성숙 없이 TBD만 밀어붙이면 “배포 담당자”로 책임이 쏠리는 역효과 가 생길 수 있다고 생각한다. 그럼에도 트렁크 기반 개발·기능 토글·프로덕션 검증을 하나의 체계로 묶어, ‘배포 공포증’을 조직의 학습 사이클로 전환한다는 점과 즉시 적용 가능한 패턴과 현실적 우회 전략을 모두 담았기에, 당장 배포 흐름을 개선하려는 팀, 장기적으로 전달 문화를 재정립하려는 조직, 그리고 개인(팀) 모두에게 추천할 만하다. 개인적으로 [PART 3 개발 단계] 가 특히 인상적이었다. JVM(Spring) 환경에서 기능 토글을 코드 레벨로 구현하는 실습이 포함되어 있어, 추상적인 개념이 채워지는 느낌이 있다. |
