자주 배포하는 팀을 위한 릴리스 관리 프로세스

릴리스 관리 프로세스는 변경이 “병합됨”에서 “프로덕션에서 실행 중이며 영향받는 사람들에게 설명됨”에 이르기까지 거치는 일련의 단계다. 자주 배포하는 팀이라면 일곱 단계로 정리된다. 범위 계획, 변경 분리, 빌드와 테스트, 승인, 배포와 검증, 커뮤니케이션, 회고다. 단계마다 이름이 지정된 담당자 한 명과 완료 기준 하나가 필요하며, 그렇지 않으면 그 단계는 조용히 사라진다.

이 가이드는 엔지니어 5명에서 50명 규모에서 매주 또는 매일 배포하고, 프로세스가 방해되지 않기를 바라는 팀을 가정한다.

릴리스 관리 프로세스란 무엇인가

변경이 사용자에게 도달하기까지 따르는 반복 가능한 경로다. 범위, 빌드, 테스트, 승인, 배포, 검증, 공지, 그리고 되돌아보기다. 이를 문서로 남기는 이유는 모든 릴리스가 같은 경로를 따르게 하기 위해서이며, 그러면 휴가 중인 사람, 신입, 새벽 2시의 당직 엔지니어가 누구에게도 방법을 묻지 않고 그것을 실행할 수 있다.

릴리스 관리의 유형에는 어떤 것이 있는가

실무에서는 세 가지 유형이 있다. 지속적 배포, 정기 릴리스, 규제 대상 변경 관리다. 릴리스 전에 얼마나 많은 일이 이루어지는지, 얼마나 자동화되어 있는지가 다르다. 지속적 배포는 병합된 모든 변경을 출시하고, 정기 릴리스는 변경을 묶어 열차에 태우고, 규제 대상 변경 관리는 공식 승인과 감사 기록을 더한다.

대부분의 팀은 이것들이 섞여 있다. SaaS 제품은 지속적으로 배포하면서 모바일 앱은 주간 열차로 내보내고, 감사 담당자가 신경 쓰는 결제 서비스 하나만 공식 변경 기록을 따를 수 있다. 유형은 회사 단위가 아니라 서비스 단위로 고르라. 변경이 점진적으로만 공개되는 곳에서는 릴리스와 공지가 별개의 이벤트가 되며, 이 경우는 피처 플래그 릴리스 노트에서 다룬다.

릴리스 매니저의 책임은 무엇인가

릴리스 매니저는 변경이 프로덕션에 이르는 경로를 책임진다. 릴리스 일정을 관리하고, 변경이 준비되었는지 판단하고, 배포를 실행하거나 감독하고, 롤백을 결정하고, 사용자에게 알리는 일을 챙기고, 이후의 회고를 진행한다.

릴리스 전에는 범위를 확인하고 위험한 변경마다 롤백 경로가 있는지 점검한다. 릴리스 중에는 배포 체크리스트를 실행하고, 프로덕션 지표의 처음 몇 분을 지켜보며 롤백을 일찍 결정한다. 릴리스 후에는 노트가 나갔는지 확인하고, 프로세스에서 고쳐야 할 것을 기록한다.

작은 팀이라면 이 역할을 매주 돌려 맡고, 누구도 구전 지식이 필요하지 않도록 체크리스트를 써 두라. 독립적으로 릴리스되는 패키지가 많은 모노레포는 보통 패키지마다 릴리스 담당자가 한 명씩 필요하며, 그렇지 않으면 이 역할이 병목이 된다.

릴리스 관리의 핵심 KPI는 무엇인가

DORA의 소프트웨어 전달 지표를 추적하고, 직접 만든 지표를 하나 더하라. 사용자에게 알리기까지 걸리는 시간이다. DORA의 연구는 다섯 가지 지표를 꼽으며, 처리량(변경 리드 타임, 배포 빈도, 실패한 배포의 복구 시간)과 불안정성(변경 실패율, 배포 재작업률)으로 나뉜다.

DORA의 가이드는 이를 쉬운 말로 정의한다(dora.dev, software delivery metrics).

예전 자료는 네 가지 핵심 지표를 나열하고 복구를 “time to restore”라고 부른다. 현재의 가이드는 위의 다섯 가지를 쓴다.

같은 가이드는 이 지표들을 목표로 삼지 말라고 경고한다. “연말까지 모든 것을 하루에 여러 번 배포한다” 같은 목표를 세우면 팀이 숫자를 조작하게 되며, 이 지표들은 회사 전체로 뭉뚱그리는 것이 아니라 애플리케이션이나 서비스별로 읽도록 되어 있다. 이 모두를 개선하기 위한 실용적인 조언은 변경 하나하나의 크기를 줄이는 것이다. 작은 변경일수록 리뷰하기도, 파이프라인을 통과시키기도, 복구하기도 쉽기 때문이다.

릴리스 커뮤니케이션은 릴리스 관리 프로세스에서 어디에 들어가는가

여섯 번째 단계이며, 다른 모든 단계처럼 담당자와 완료 기준이 있다. 노트가 사용자가 읽는 곳에 발행되었고, 내부 팀에 공유되었다는 것이다. 팀들이 가장 자주 건너뛰는 단계인데, 배포 도구는 코드가 반영되는 순간 성공이라고 보고하기 때문이다.

이 단계를 일정대로 지키는 가장 저렴한 방법은 릴리스가 출시될 때가 아니라 변경이 병합될 때 항목을 쓰는 것이다. pull request에는 이미 제목, 작성자, 연결된 issue, 맥락이 있다. 그것으로 만든 초안은 일주일 뒤에 기억에 의존해서 쓰는 대신 편집하는 대상이 된다. 이것이 체인지로그 자동화의 발상이다. 병합할 때 초안을 만들고, 사람이 승인하도록 보류하고, 하나의 원본에서 모든 곳에 발행한다. Changeloop도 이렇게 동작하며, 병합된 pull request로 AI가 항목 초안을 만들고 무엇이든 발행되기 전에 승인을 위해 보류해 둔다.

미리 계획해 둘 만한 변형이 두 가지 있다. 지원과 영업에는 고객과 다른 노트가 필요하며, 내부용 릴리스 노트가 그 용도다. 장애 대응으로 나가는 릴리스에는 평소의 초안 작성 과정을 거칠 시간이 없으므로, 긴급 릴리스 노트에 설명된 대로 짧은 템플릿을 준비해 두라. 고객용 버전의 출발점이 되는 형태는 릴리스 노트 템플릿에서 얻을 수 있다.

프로세스를 가볍게 유지하려면

기계가 확인할 수 있는 모든 완료 기준은 자동화하고, 판단이 필요한 일에만 사람을 쓰라. 녹색 파이프라인, 대시보드의 배포 마커, 병합된 pull request마다의 체인지로그 초안 항목은 확인 가능하다. 롤백 계획이 믿을 만한지, 노트가 고객에게 이해되는지는 사람이 해야 한다.

프로세스를 시험하려면 지난달의 릴리스 하나를 골라, 팀 밖의 누군가가 기록만 보고도 무엇이 출시되었는지, 누가 승인했는지, 어떻게 검증했는지, 사용자에게 언제 알렸는지 말할 수 있는지 물어보라. 빈틈이 있다면 그것이 다음 개선 과제다.

FAQ

릴리스 관리와 변경 관리의 차이는 무엇인가? 릴리스 관리는 일련의 변경을 빌드하고, 테스트하고, 배포하고, 공지하게 만든다. ITIL에서 말하는 변경 관리는 변경 하나하나를 둘러싼 승인과 위험 프로세스다. 자주 배포하는 팀은 승인을 코드 리뷰와 자동 검사에 녹여 넣는다.

얼마나 자주 릴리스해야 하는가? 테스트와 롤백 경로가 허용하는 만큼 자주, 많은 웹 팀에게는 매일 또는 그 이상이다. DORA의 지침은 변경 하나하나의 크기를 줄이라는 것이며, 작은 변경이 리뷰하고 복구하기 더 쉽기 때문이다.

작은 팀에도 릴리스 매니저가 필요한가? 책임은 필요하지만 직함이 꼭 필요한 것은 아니다. 엔지니어들 사이에서 역할을 돌려 맡고, 당번인 사람에게 문서로 된 체크리스트를 주고, 일곱 단계 하나하나를 누군가 맡고 있도록 하라.

릴리스 체크리스트에는 무엇이 들어가야 하는가? 범위 확인, 출시 커밋에서의 녹색 파이프라인, 지정된 롤백 경로, 기록된 승인, 배포 후 스모크 체크, 기준선과 비교한 지표, 발행된 릴리스 노트, 지원팀 공유, 그리고 예정된 회고다. 한 페이지로 유지하라.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, 릴리스 노트 템플릿