금요일 오후 3시 40분, 간편결제 선택 화면 개편을 앞둔 배포 승인 회의가 시작됐다. 화면에는 새 버전과 함께 ‘사용자 5% 카나리’라는 문구가 적혀 있었다.
개발자 현우가 계획표를 열었다.
“스테이징 검증은 끝났습니다. 운영에 배포한 뒤 사용자 5%부터 새 화면을 열면 됩니다.”
서비스 기획자 지민이 물었다.
“5%에서 문제가 없으면 바로 전체 공개하는 건가요?”
“오류율과 응답 시간이 사전에 정한 범위 안이면 확대할 수 있습니다.”
운영 담당자 수진이 결제 문의 현황을 살펴보며 말했다.
“결제 성공률이 떨어지거나 특정 결제수단 문의가 늘어도 오류율은 정상일 수 있지 않나요?”
지민도 한 가지를 더 물었다.
“얼마 동안 봐야 하나요? 결제가 적은 시간대라면 5%를 열어도 판단할 자료가 부족할 것 같은데요.”
현우가 계획표의 빈칸을 확인했다.
“관찰 조건과 확대 기준은 아직 적혀 있지 않습니다.”
“문제가 보이면 다음 범위로 안 넓히는 건가요, 기능 플래그를 끄는 건가요?”
“우선 확대를 멈춥니다. 신호가 심각하면 바로 이전 화면으로 돌릴 수 있습니다.”
지민이 계획표의 ‘5%’ 옆에 메모를 남겼다.
“그럼 비율보다 먼저 확대와 중단 조건부터 정해야겠네요.”
계획표에는 시작 비율만 있고, 전체 공개를 결정할 관찰 항목과 중단 행동은 비어 있었다.
배포와 공개의 시점을 나누는 방법
배포는 새 코드와 설정, 실행 결과물이 목표 환경에서 실행되도록 반영하는 과정이다. 운영 환경에 새 버전이 배포되면 해당 코드는 그 환경에서 실행된다.
공개는 실제 사용자나 대상 집단이 새 기능을 이용하게 하는 상태다. 단순한 서비스에서는 배포와 공개가 동시에 일어난다. 기능 플래그나 트래픽 조건을 사용하는 서비스에서는 코드가 운영에 있어도 기능 노출을 늦추거나 일부 사용자에게만 열 수 있다.
기능 플래그는 이미 배포된 코드에서 조건에 따라 기능의 동작이나 노출을 바꾸는 장치다. 이 사례는 이전 화면 코드가 남아 있고 데이터 구조를 바꾸지 않았기 때문에 플래그를 끄면 기존 화면 경로를 다시 사용한다. 모든 변경이 같은 방식으로 돌아가는 것은 아니다.
이 구조에서는 배포와 공개 상태를 따로 보고한다.
새 버전은 운영 환경에 배포됐습니다. 현재는 일부 사용자에게만 새 화면을 공개했습니다.
‘릴리스’라는 말은 조직에 따라 배포 묶음, 출시 승인, 사용자 공개를 함께 가리키기도 한다. 회의에서는 어느 상태를 뜻하는지 확인해야 한다.
이 구분은 장애 보고에도 영향을 준다. 운영 배포는 끝났지만 기능을 아무에게도 열지 않았다면 사용자 영향은 아직 없을 수 있다. 반대로 일부 사용자에게 공개한 상태라면 새 기능을 경험한 대상과 그렇지 않은 대상을 나눠 확인해야 한다. 같은 버전이 운영에 있어도 실제 사용자 경험은 노출 조건에 따라 달라진다.
기능 플래그를 꺼도 새 코드는 운영 환경에 남아 있다. 사용자의 진입 경로만 기존 화면으로 돌린다. 코드나 설정 자체를 이전 상태로 되돌려야 하면 롤백을 따로 검토한다.
새 버전의 첫 노출 범위
배포 계획에서 말하는 범위는 하나가 아니다.
배포 범위는 새 버전이 반영된 서버나 환경의 범위다. 노출 범위는 실제로 새 기능이나 버전을 경험하는 사용자와 요청의 범위다.
코드는 전체 서버에 배포하되 일부 사용자에게만 기능을 열 수 있다. 반대로 일부 서버에만 새 버전을 두고 요청의 일부를 보낼 수도 있다. 서버 비율·요청 비율·사용자 비율은 같은 숫자가 아닐 수 있다.
그래서 “5% 배포”라는 표현만으로는 계획을 이해하기 어렵다.
전체 사용자 중 5%인가요, 전체 요청 중 5%인가요, 아니면 실행 서버 중 일부인가요?
사용자 5%를 골라도 특정 지역이나 단말에 치우칠 수 있다. 새 버전 서버가 전체의 일부여도 트래픽 분배 방식에 따라 실제 요청 비율은 달라진다.
배포 회의에서는 숫자와 단위를 함께 기록해야 한다. “서버 두 대”, “결제 요청의 일부”, “선정한 사용자 집단”은 모두 작은 범위처럼 보이지만 관찰되는 현상은 다르다. 사용자가 고정된 대상인지, 요청마다 새 버전과 이전 버전을 오갈 수 있는지도 결과 해석에 영향을 준다.
롤아웃은 새 버전이나 기능이 닿는 범위를 서버·트래픽·사용자 집단에 걸쳐 넓혀 가는 과정이다. 처음부터 전체에 적용할 수도 있고, 작은 범위에서 시작해 관찰하며 확대할 수도 있다.
일괄·롤링·카나리의 차이
일괄 배포는 서버 측 대상 전체를 한 변경 구간에서 새 버전으로 교체한다. 절차와 서버 버전 관리가 단순한 편이지만, 문제가 있으면 처음부터 넓은 범위가 영향을 받는다. 영향 대상이 작고 복구가 단순한 변경에서는 일괄 방식이 적합하다.
롤링 배포는 실행 대상을 여러 묶음으로 나누어 순차 교체한다. 한 시점에 바뀌는 대상 수는 줄지만, 배포 중 이전 버전과 새 버전이 함께 요청을 처리해도 되는지 확인해야 한다.
롤링과 카나리는 초점이 다르다.
롤링은 실행 대상을 어떤 순서로 교체하는지에 초점을 둔다. 카나리는 작은 실제 노출 범위에서 결과를 본 뒤 다음 범위로 확대하는 방식이다. 서버를 롤링으로 교체하면서 첫 묶음에 들어오는 실제 트래픽을 카나리로 관찰할 수도 있다.
카나리에는 세 요소가 필요하다.
1. 처음 노출할 대상
2. 관찰할 신호와 조건
3. 확대하거나 중단할 기준
5%라는 숫자는 첫 번째 항목의 일부만 알려 준다.
카나리에서 관찰할 신호
초기 대상에는 이번 변경의 위험이 드러날 주요 사용 조건이 포함돼야 한다.
간편결제 화면을 검증하면서 결제 이용자가 적은 시간대만 보면 판단할 거래가 부족하다. 주요 결제수단이 카나리 대상에서 거의 사용되지 않는다면 해당 경로의 문제도 드러나지 않는다.
관찰 항목은 기술 신호와 업무 신호를 함께 둔다.
개발팀은 새 화면 요청의 오류와 응답 지연을 본다. 기획·운영팀은 결제 성공률과 주요 결제수단 실패, 고객 문의를 확인한다. 프로그램이 오류 없이 응답해도 사용자가 결제를 끝내지 못할 수 있기 때문이다.
관찰 종료 조건도 배포 전에 적는다. 단순히 시간을 채우는 대신 주요 결제수단과 사용 조건에서 필요한 거래가 발생했는지 담당자가 확인한다.
누가 판정할지도 정해야 한다. 개발 담당자는 기술 신호를, 기획·운영 담당자는 결제 성공과 문의 변화를 확인할 수 있다. 여러 신호가 서로 다른 방향을 보일 때 최종 확대·중단 결정을 내릴 책임자도 필요하다. 담당자가 정해져 있지 않으면 이상 신호를 발견하고도 다음 행동이 늦어진다.
다음 범위로 확대할 조건은 세 묶음으로 정리할 수 있다.
- 기술 오류와 지연이 사전에 정한 허용 범위 안에 있는가
- 결제 성공률과 주요 결제수단에서 새로운 이상이 없는가
- 정한 관찰 시간과 거래 조건을 충족했는가
고정된 보편 수치는 없다. 서비스 중요도와 변경 위험, 평소 변동 폭을 바탕으로 기준을 정한다.
이상 신호가 나오면 먼저 확대를 멈춘다. 신호가 경미하면 현재 범위에서 원인을 확인하고, 사용자 피해가 크거나 빠르게 늘면 즉시 기능을 차단한다. 코드나 설정을 이전 상태로 돌려야 할 때 롤백을 선택한다.
중단 조건은 경고 문구가 아니라 행동 조건이다. 예를 들어 ‘결제 성공률 확인’만 적으면 누가 어떤 결과에서 멈출지 알 수 없다. 배포 전에 허용 범위, 확인 담당자, 중단 뒤 첫 행동까지 연결해야 실제 의사결정에 쓰인다.
두 환경을 준비하고 트래픽을 바꾼다
블루그린 배포는 현재 버전 환경과 새 버전 환경을 함께 준비한다.
기존 환경을 블루, 새 환경을 그린이라고 부른다고 하자. 사용자는 현재 블루 환경을 이용한다. 팀은 그린 환경에 새 버전을 배포하고 기능·설정·외부 연결을 확인한다. 준비가 끝나면 사용자 요청을 그린 환경으로 전환한다.
새 환경에서 문제가 발견되면 트래픽을 기존 환경으로 다시 돌리는 선택지가 있다. 다만 기존 환경이 현재 데이터와 호환돼야 실제 복귀 경로가 된다.
두 환경을 함께 운영하려면 추가 자원과 관리 비용이 든다. 설정이나 외부 연결이 다르면 전환 뒤 예상하지 못한 결과가 나타날 수 있다. 두 환경이 데이터를 공유하는지, 별도로 동기화하는지에 따라 복귀 난도도 달라진다.
카나리와 블루그린을 함께 사용할 수도 있다. 새 환경을 준비한 뒤 전체 트래픽을 한 번에 넘기지 않고 일부부터 전환해 관찰하는 방식이다.
방식마다 처음 영향을 받는 범위와 이전 버전을 유지하는 비용이 다르다. 전략 이름보다 중단·복귀 조건을 함께 확인해야 한다.
공연 과정으로 보는 배포
배포는 새 무대 장치와 대본을 공연장에 설치하는 일, 공개는 실제 관객에게 새 연출을 보여 주는 상태와 닮았다. 카나리는 소규모 프리뷰 뒤 객석을 넓히고, 블루그린은 기존 무대와 새 무대를 함께 준비한 뒤 공연 무대를 바꾸는 방식으로 이해할 수 있다.
이미 관객이 경험한 결과는 이전 무대로 돌아가도 사라지지 않는다. 실제 소프트웨어에서는 트래픽과 데이터, 외부 시스템의 상태까지 함께 움직인다.
되돌린다는 말의 범위
장면의 결제 화면 개편은 이전 화면 코드가 남아 있고 데이터 구조도 바꾸지 않았다. 따라서 기능 플래그를 끄면 기존 화면으로 비교적 빠르게 돌아간다.
그러나 기능 차단, 트래픽 복귀, 롤백은 서로 다른 범위를 다룬다.
기능 플래그를 끄면 사용자는 새 화면에 들어가지 않지만 새 코드는 운영에 남아 있다. 트래픽을 기존 환경으로 돌리면 새 환경의 사용은 멈추지만 두 환경이 공유한 데이터는 그대로 남는다. 롤백은 문제가 있는 버전이나 설정을 이전에 정상 동작을 확인한 상태로 되돌린다.
애플리케이션 버전을 되돌려도 이미 바뀐 데이터와 외부로 전달된 결과는 남을 수 있다. 이미 발송된 알림처럼 외부에 전달된 결과는 코드 롤백으로 회수되지 않는다. 데이터 구조가 바뀌었다면 이전 코드가 새 데이터와 맞지 않을 수도 있다.
배포 전에는 다음 질문까지 확인해야 한다.
어떤 버전과 설정을 되돌릴 수 있고, 데이터와 외부 결과에는 어떤 추가 복구가 필요한가요?
롤백 계획에는 실행 가능 여부도 포함된다. 이전 버전 파일이 남아 있는지, 이전 설정을 다시 적용할 권한과 담당자가 있는지, 복귀 뒤 어떤 기능을 확인할지 정한다. ‘롤백 가능’이라는 한 칸보다 되돌릴 대상과 확인 절차가 적힌 계획이 실제 대응에 도움이 된다.
확대와 중단 조건을 적은 배포 계획
회의 초반 현우는 이렇게 말했다.
“사용자 5%부터 열면 됩니다.”
이 문장을 실제 판단이 가능한 계획으로 바꾸면 다음과 같다.
새 결제 화면은 운영 환경에 배포한 뒤 실제 결제 사용자의 일부에 먼저 공개한다. 사전에 정한 시간과 거래 조건 동안 기술 오류와 결제 성공률을 관찰한다. 기준을 벗어나면 확대를 멈추고, 사용자 영향이 크면 기능 플래그를 끈다.
이 계획에는 시작 범위, 관찰 조건, 확대 기준과 중단 뒤의 행동이 들어 있다. 전체 공개 시점도 시계만 보고 정하지 않는다. 관찰 조건을 충족했고 대응 담당자가 남아 있는 시간인지 함께 확인해야 한다.
회의에서는 다음 세 문장으로 배포 위험을 나눈다.
1. 새 버전은 처음에 전체 대상 중 어디까지 노출되나요?
2. 어떤 기술·업무 신호가 나쁘면 확대를 멈추나요?
3. 중단 뒤 이전 버전이나 기존 환경으로 돌아갈 수 있는 범위는 어디까지인가요?
점진 배포의 핵심은 천천히 바꾸는 데 있지 않다. 작은 범위에서 관찰한 뒤 다음 행동을 결정하는 데 있다.
