한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.
기술 면접을 준비하던 시절, 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에서는 실제로 지속적 배포를 도입한 회사들의 사례를 언급한다. 각 회사들이 어떤 상황이나 배경에서 지속적 배포의 필요성을 느꼈는지, 그리고 도입한 이후 어떤 장점을 얻었는지를 언급한다. 회사마다 처한 상황이 다르기도 하고, 또한 나의 상황 혹은 한국의 상황과도 어떤 면에선 차이가 있어서 가볍게 훑고 지나갔지만, 유사한 상황에 놓여 있는 조직이라면 어떻게 대응해 나갔는지 비교해 보기엔 좋을 것 같다는 생각이 들었다.
이 책을 읽으면서 깨달은 것은 지속적 배포라는 것이 단순히 배포 자동화를 넘어서는 조직 전체의 개발 문화와 사고방식을 바꾸는 변화라는 점이다. 특히 이 책은 온전히 기술에만 국한되어 있지 않다. 배포라는 행위 이전에 필요한 많은 프로세스가 있고, 그 프로세스를 어떻게 체계적으로 구축해야 하는지에 대해 상세히 다루고 있다. 이는 곧 모든 내용을 한 번에 받아들이기보다는 본인에게 필요한 부분을 먼저 소화한 후 점진적으로 확장해 가는 접근이 효과적일 거라고 생각한다.
개인적으로 인프라와 관련된 내용이 생소해서 더욱 어렵게 느껴지는 부분도 있었지만, 그럼에도 불구하고 관심 있는 파트부터 하나씩 찾아보면서 점진적으로 확장해 나간다면, 개념적으로 좀 더 부드럽게 받아들일 수 있을 것 같다는 생각이 들었다.
결국 지속적 배포는 단순한 기술적 도구가 아니라, 더 나은 소프트웨어를 더 빠르고 안전하게 사용자에게 전달하기 위한 종합적인 철학이자 문화적 변화라는 것이 이 책이 전하고자 하는 핵심 메시지인 것 같다. 이러한 관점에서 이 책은 지속적 배포를 도입하려는 개발자와 조직 모두에게 실용적인 가이드가 될 수 있지 않을까 싶다.
