💡 핵심 인사이트
릴리스 및 배포 관리는 변경 위원회(CAB)로부터 허락을 받은 새로운 소프트웨어나 하드웨어(패치)를, 실제 라이브 운영 서버(Production)에 복사하고 설치하여 고객이 쓸 수 있게 물리적으로 넘겨주는(배포하는) 최종 실행 프로세스입니다.
핵심 목표는 "장애 없이 빠르고 안전하게 코드를 공장 밖으로 출하시키는 것"입니다.

Ⅰ. 릴리스 관리가 왜 어려운가?

개발자의 로컬 노트북이나 테스트 서버(Staging)에서는 완벽하게 돌아가던 코드가, 실제 운영 서버(Live)에만 올리면 펑하고 터지면서 에러를 뿜어내는 일이 비일비재합니다. 운영 서버는 엄청난 트래픽이 들어오고, OS 버전이 다르며, 낡은 DB와 얽혀있기 때문입니다.

따라서 릴리스 관리는 개발자가 그냥 FTP로 파일을 덮어쓰기 하는 것이 아니라, '통합 빌드 ➔ 패키징 ➔ 철저한 테스트 환경 이관 ➔ 운영 서버 롤아웃 ➔ 검증 ➔ 실패 시 롤백' 이라는 거대하고 엄격한 이사(Moving) 작전을 지휘하는 것입니다.

Ⅱ. 배포(Deployment)의 다양한 기법 (무장애 배포 전략)

서비스가 잠깐이라도 멈추면(Downtime) 치명적인 현대 웹 환경에서는, 사용자가 눈치채지 못하게 서버를 살려둔 채로 코드를 갈아 끼우는 고급 배포 기술이 발전했습니다.

1. 빅뱅 배포 (Big Bang Deployment / 일괄 배포)

• 방식: 새벽 2시에 서비스에 "점검 중입니다" 화면을 띄우고(다운타임 발생), 구버전 서버를 싹 지운 뒤 신버전을 통째로 설치하고 기도하며 서버를 켭니다.
• 특징: 옛날 게임이나 은행권에서 하던 고전적이고 가장 위험한 방식입니다. 실패하면 다시 구버전을 깔아야 해서 밤을 새우게 됩니다.

2. 블루-그린 배포 (Blue-Green Deployment)

• 방식: 똑같은 용량의 운영 서버 환경을 두 세트(블루, 그린) 마련합니다. 현재 유저들은 블루(구버전)를 쓰고 있습니다. 엔지니어는 뒤에서 몰래 그린(신버전)에 코드를 다 깔고 완벽히 테스트합니다.
• 전환: 완료되면, 앞단의 라우터(로드 밸런서)의 트래픽 스위치를 딸깍! 하고 '블루 ➔ 그린'으로 한 번에 돌립니다.
• 장점: 무중단(Downtime Zero) 배포가 가능하며, 만약 그린에 문제가 생기면 1초 만에 다시 스위치를 블루로 돌려버리면(롤백) 되므로 매우 안전합니다. 단, 서버를 두 배(2배 비용)로 준비해야 하는 단점이 있습니다.

3. 카나리아 배포 (Canary Release)

• 방식: 광부들이 가스 누출을 확인하러 카나리아 새를 데려간 것에서 유래했습니다.
• 신버전 서버를 딱 1대만 띄워놓고, 전체 접속자의 단 5%의 트래픽만 무작위로 신버전 서버로 흘려보냅니다.
• 장점: 치명적인 버그가 있더라도 5%의 사용자만 피해를 입고 95%는 무사하므로, 고객의 반응과 에러 로그를 살살 간 보면서 안전하게 비중을 늘려(5% ➔ 20% ➔ 100%) 나갈 수 있습니다.

Ⅲ. CI/CD 파이프라인 (현대의 자동화 배포)

과거 ITIL 시대에는 릴리스 매니저가 주말마다 출근해 수동으로 복사했지만, 데브옵스(DevOps) 시대인 지금은 이 배포 과정을 스크립트로 짜서 자동화시킨 CI/CD (지속적 통합/지속적 배포) 파이프라인을 구축합니다. (Jenkins, GitHub Actions 도구 활용) 개발자가 코드를 커밋하면 로봇이 알아서 테스트를 돌리고, 새벽에 블루-그린 방식으로 서버에 밀어 넣고 퇴근합니다.

📢 섹션 요약 비유: 릴리스 관리는 영화관 필름 상영 중 **'필름 갈아 끼우기'**입니다. 빅뱅 배포는 "불 켜고 손님들 내보낸 뒤 영사기 끄고 2편을 트는 것"이고, 블루-그린 배포는 "몰래 옆방에 영사기 2호기를 세팅해 두고, 1편이 끝나는 찰나의 순간에 2호기 렌즈 뚜껑을 열어(무중단) 손님 모르게 2편을 틀어주는 마술"입니다.