릴리스 후보(RC): 의미와 운영하는 방법

릴리스 후보(RC, release candidate)는 팀이 출시할 준비가 되었다고 믿는 빌드다. 기능이 모두 들어갔고 계획한 테스트를 통과했으며, 누군가 출시를 막을 만큼 심각한 버그를 찾지 않는 한 그대로 최종 릴리스가 된다. 이 라벨은 빌드에 대한 약속이다. 새 기능은 없고 차단 문제의 수정만 있다. 수정이 필요하면 팀은 새 후보를 만들고 시계를 처음부터 다시 돌린다.

소프트웨어에서 릴리스 후보란 무엇인가

정식 출시 전의 마지막 사전 릴리스 단계다. 이 빌드가 최종 버전의 후보이고, 출시는 새로 만드는 것이 아니라 바로 그 빌드를 승격하는 방식으로 이루어진다는 생각이다. 위키백과의 소프트웨어 릴리스 수명 주기 문서도 알파, 베타, 릴리스 후보, 릴리스라는 같은 순서를 설명하며, 이 용어는 오픈 소스 프로젝트와 업체 전반에서 널리 통한다.

베타와 릴리스 후보는 무엇이 다른가

베타는 아직 바뀔 수 있다. 기능이 조정되고 인터페이스가 이동할 수 있으며, 무엇이 빠졌거나 잘못되었는지 배우는 것이 목표다. 릴리스 후보는 그런 식의 변경을 멈췄고, 목표는 출시를 막는 것이 없음을 확인하는 것이다. 실용적인 판별법은 버그 리포트를 받았을 때 팀이 무엇을 하는가이다. 베타에서는 리포트가 설계 변경으로 이어질 수 있다. RC에서는 버그가 출시를 막을 때만 수정으로 이어지고, 나머지는 다음 버전 대기열로 간다.

릴리스 후보의 버전은 어떻게 매기는가

출시하려는 버전에 사전 릴리스 접미사를 붙인다. 시맨틱 버저닝에서는 하이픈 뒤에 점으로 구분한 식별자가 오면 사전 릴리스를 뜻하므로, 2.4.0의 첫 후보는 2.4.0-rc.1, 다음은 2.4.0-rc.2, 출시는 그냥 2.4.0이다.

우선순위는 명세를 따른다. 2.4.0-rc.1은 2.4.0-rc.2보다 낮게 정렬되고, 모든 사전 릴리스는 정식 릴리스보다 낮게 정렬된다. 식별자를 하나씩 비교하고 숫자는 숫자로 비교하므로 rc.10은 rc.9보다 위에 정렬된다. alpha, beta, rc라는 이름도 알파벳순으로 올바른 순서가 되는데, 팀들이 이 이름을 쓰는 이유 중 하나다. 정확한 커밋이 기록되도록 git 태그와 릴리스에서 설명한 대로 후보마다 git에 태그를 붙인다.

릴리스 후보의 종료 기준은 무엇인가

첫 RC를 만들기 전에 적어 둔다. 쓸 만한 기준은 다음과 같다.

• 자동화된 테스트 스위트가 빌드한 바로 그 커밋에서 통과한다.
• 이전 릴리스에서의 업그레이드 경로를 현실적인 데이터로 테스트했다.
• 알려진 이슈를 분류했고, 차단 문제로 평가된 것이 없다.
• 성능과 오류율이 이전 릴리스와 합의한 오차 범위 안에서 일치한다.
• 릴리스 노트 초안을 쓰고 최종 변경 목록과 대조해 검토했다.
• 롤백 경로가 있고 누군가 그것을 읽었다.

후보 하나에서 모든 줄이 참이면 그 후보가 릴리스다. 한 줄이라도 실패하면 수정으로 새 후보가 나오고 점검을 처음부터 다시 한다. 이 흐름을 단계마다 담당자를 두고 일곱 단계로 정리한 내용은 릴리스 관리 프로세스에 있다.

RC가 통과하면 빌드를 어떻게 해야 하는가

같은 산출물을 승격한다. 태그에서 다시 빌드하지 않는다. 다시 빌드하면 다른 의존성이나 컴파일러 출력이 섞여 들어올 수 있고, 진행한 테스트는 원래 빌드에 대한 것이기 때문이다. 많은 팀이 다시 태그를 붙이거나 레지스트리 라벨을 다시 가리키는 방식으로 후보의 이름을 바꿔서, 테스트한 바이트가 사용자가 내려받는 바이트가 되게 한다.

패키지는 일반 사용자가 실수로 받지 않도록 후보를 별도 채널에 게시한다. npm에서는 npm publish --tag rc가 기본 latest 태그를 그대로 두므로 @rc를 요청한 사람만 후보를 받는다. 컨테이너 이미지와 모바일 빌드에도 사전 릴리스 태그, 단계적 롤아웃, TestFlight 같은 트랙이라는 다른 이름의 같은 개념이 있다.

릴리스 후보의 릴리스 노트는 어떻게 쓰는가

노트는 첫 RC부터 시작하고 후보와 보조를 맞춰 유지한다. 테스터는 무엇이 바뀌었는지, 무엇을 확인해야 하는지, 무엇이 고장난 것으로 알려졌는지를 알아야 하며, 일찍 초안을 쓰면 마지막에 아무도 기억하지 못하는 항목을 찾아낼 수 있다. 최종 버전으로 오해하지 않도록 페이지나 GitHub 릴리스를 사전 릴리스로 표시하고, GA가 나오면 완성된 글을 GA 릴리스로 옮긴다. 구성과 내용은 소프트웨어 릴리스 노트에, GitHub 쪽은 GitHub 릴리스 노트에 있다.

SaaS 팀에도 릴리스 후보가 필요한가

지속적으로 배포하는 팀에는 거의 필요 없다. 프로덕션 배포가 곧 테스트이고 기능 플래그가 누가 변경을 보는지 통제하기 때문이다. 릴리스 후보가 제값을 하는 경우는 사용자가 소프트웨어를 직접 설치하고 배포로 되돌릴 수 없을 때, 즉 라이브러리, 데스크톱과 모바일 앱, 자체 호스팅 제품, 오래 쓰이는 클라이언트가 있는 API다. 변경을 점진적으로 공개하는 호스팅 제품이라면 같은 역할을 하는 것이 단계적 롤아웃이며, 이를 소통의 관점에서 다루는 글이 피처 플래그 릴리스 노트다.

FAQ

소프트웨어에서 RC는 무슨 뜻인가? RC는 릴리스 후보(release candidate)의 약자다. 테스트에서 차단 버그가 나오지 않으면 팀이 최종 버전으로 출시할 생각인 빌드를 말한다. 알파와 베타 단계 뒤, 정식 출시 앞에 온다.

릴리스 후보는 프로덕션에 쓸 만큼 안정적인가? 스테이징이나 제한된 프로덕션 환경에서 테스트하는 용도로는 대체로 그렇지만, 테스트가 끝나지 않았을 수 있다는 점에서 최종 릴리스에는 없는 위험이 따른다. 아직 수습 기간에 있는 프로덕션 품질의 코드로 취급한다.

릴리스 하나에 릴리스 후보는 몇 개가 적당한가? 필요한 만큼이며, 대부분의 릴리스는 하나에서 셋이면 된다. 후보가 길게 이어진다면 동결을 너무 일찍 선언했거나 테스트 범위가 문제를 뒤늦게 잡고 있다는 뜻인 경우가 많다.

릴리스 후보가 변경 없이 그대로 최종 릴리스가 될 수 있는가? 그렇다. 그것이 의도한 결과다. 최종 릴리스는 마지막 후보와 같은 빌드여야 하고, 이름이나 라벨만 GA로 바뀐다.

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

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