점진적 출시

출시가 하루짜리 행사이던 시절이 있었습니다. 날을 잡아 새 버전을 서버에 올리면 그 순간부터 모든 사용자가 새 화면을 보았습니다. 잘 돌아가면 좋은 날이고 아니면 나쁜 날이었는데, 나쁜 날의 규모가 문제였습니다. 사용자가 3만 명이면 3만 명이 동시에 깨진 화면을 봅니다.

페이지덱도 그렇게 냈습니다. 태오가 목요일 밤에 새 편집기를 올리고 자기 계정으로 문서 몇 개를 만들어 본 뒤 잘 된다고 판단합니다. 금요일 아침에 문의가 들어오기 시작합니다. 특정 브라우저에서 한글 입력 중에 글자가 사라진다는 내용이었습니다. 태오의 노트북에도 스테이징 환경에도 없던 증상이라 재현하는 데만 반나절이 갔고, 그동안 페이지덱을 쓰는 모든 팀이 그 상태의 편집기를 쓰고 있었습니다. 되돌리려고 이전 버전을 다시 올리자 이번에는 새 편집기로 저장된 문서가 열리지 않았습니다.

여기서 걸리는 것은 실수의 크기가 아니라 실수가 닿는 범위입니다. 출시 전에 아무리 검사해도 못 잡는 것이 남습니다. 특정 브라우저, 특정 회선 속도, 문서가 500개 쌓인 계정, 초대 링크로 들어온 외부 사용자처럼 미리 갖춰 보기 어려운 조건은 늘 실제 사용자 쪽에 있습니다. 검사를 두 배로 늘리는 것으로는 이 구간이 사라지지 않습니다. 사용자 수가 늘수록 이 구간도 같이 넓어집니다. 100명이 쓸 때는 안 나던 증상이 3만 명이 쓰면 하루에 몇 건씩 나오고, 그 몇 건은 미리 갖춰 본 환경에서는 한 번도 재현되지 않습니다.

점진적 출시는 그래서 방향을 바꿉니다. 못 잡는 것이 남는다는 전제를 받아들이고, 대신 그것이 처음 닿는 사람 수를 줄입니다. 3만 명이 아니라 300명이 먼저 보게 해 두면 같은 결함이 나와도 영향을 받는 사람이 100분의 1이고, 알아차리는 데 걸리는 시간도 문의가 쌓이기를 기다리지 않아 훨씬 짧습니다.

제품 축에서 출시 갈래는 만든 것을 사용자 앞에 내놓는 자리입니다. 한 번 내보내는 행위 자체가 릴리스이고, 그 릴리스를 전체에 한꺼번에 열지 않고 범위를 나눠 여는 방식이 점진적 출시입니다. 언제 누구에게 어떤 경로로 알리고 팔지를 묶은 계획은 고 투 마켓이라는 다른 말이 맡습니다. 점진적 출시는 그중 기술적으로 어떻게 여느냐만 다룹니다. 반대쪽 끝에는 더 쓰이지 않는 기능의 제공을 끝내는 제품 일몰이 있는데, 그것도 한 번에 닫지 않고 범위를 좁혀 가며 끄는 편이라 절차의 모양은 비슷합니다.

점진적 출시 아래 묶인 용어는 여섯이고 모두 수단 갈래에 들어갑니다. 여섯 중 하나를 고르는 것이 아니라, 한 번의 출시에서 순서대로 쓰이는 도구들입니다. 아래 순서가 그대로 이 방식의 절차입니다.

1. 피처 플래그 — 코드는 이미 서버에 올려 둔 채로 기능만 켜고 끄는 스위치입니다. 나머지 다섯 단계가 전부 이 스위치 위에서 돌아가기 때문에 여기부터 심습니다. 새 편집기를 만들 때 "새 편집기 플래그가 켜져 있으면 새것, 아니면 옛것" 이라는 분기를 코드에 넣어 두고, 배포한 뒤에도 스위치는 꺼 둔 상태로 시작합니다.
2. 다크 런치 — 사용자 화면에는 아무것도 보이지 않게 두고 새 코드만 뒤에서 돌려 봅니다. 새 저장 방식으로도 같이 저장해 보되 화면에 보여 주는 것은 옛 결과입니다. 실제 사용량과 실제 데이터로 부하와 오류만 먼저 재는 단계라, 결과가 틀려도 사용자는 모릅니다. 화면을 바꾸지 않고 안쪽 구조만 갈아 끼우는 작업에서 특히 쓸모가 큽니다. 옛 경로와 새 경로가 같은 답을 내는지 실제 요청으로 대조할 수 있기 때문입니다.
3. 카나리 릴리스 — 처음으로 진짜 사용자에게 여는 단계입니다. 전체의 1퍼센트나 사내 계정처럼 아주 작은 집단에만 스위치를 켜고, 그 집단에서만 오류율과 응답 속도가 나머지와 다른지 봅니다. 이름은 탄광에서 유독가스를 먼저 알아채던 카나리아에서 왔습니다. 소수가 먼저 겪어 나머지를 지키는 자리라는 뜻입니다. 누구를 이 집단에 넣을지는 미리 정해 둡니다. 사내 계정처럼 문제가 나도 바로 말해 줄 수 있는 쪽을 먼저 넣고, 계약 규모가 크거나 장애에 민감한 고객사는 마지막 단계까지 빼 두는 팀이 많습니다.
4. 퍼센트 롤아웃 — 카나리에서 이상이 없으면 비율을 단계적으로 올립니다. 1퍼센트에서 5, 25, 50, 100으로 가는 식이고 단계마다 최소 몇 시간에서 하루를 둡니다. 곧장 100으로 가지 않는 이유는 어떤 결함은 사용자 수가 일정 규모를 넘어야 드러나기 때문입니다. 서버가 버티지 못하는 지점이나 특정 조건의 계정에서만 나는 오류가 그렇습니다. 1퍼센트에서 300명이 보던 화면을 25퍼센트로 올리면 7500명이 보는데, 이 사이에서 처음 드러나는 문제가 대부분 부하 쪽입니다.
5. 킬 스위치 — 올리는 도중 숫자가 나빠지면 기능만 즉시 끕니다. 플래그를 끄는 일이라 배포를 다시 하지 않고 몇 초 만에 끝납니다. 끄고 나서 원인을 찾으면 되기 때문에, 원인을 다 밝힌 뒤에 대응하던 순서가 여기서 뒤집힙니다. 누가 언제 내릴 수 있는지를 미리 정해 두지 않으면 정작 필요한 새벽에 결정권자를 찾다가 시간을 씁니다.
6. 롤백 — 스위치를 꺼도 해결되지 않을 때 쓰는 마지막 수단입니다. 배포된 코드 자체가 문제를 일으켜 옛 버전으로 되돌리는 조치라, 플래그를 끄는 것보다 무겁고 이미 새 방식으로 쌓인 데이터를 어떻게 할지까지 따라옵니다. 점진적 출시를 제대로 하면 롤백까지 갈 일이 줄어듭니다.

절차에서 빠지기 쉬운 것은 단계 사이에 무엇을 보느냐입니다. 비율을 올리는 판단은 시간이 아니라 숫자로 합니다. 새 기능을 켠 집단과 끄고 있는 집단을 나란히 놓고 오류율, 응답 속도, 저장 성공률처럼 미리 정해 둔 항목을 비교합니다. 이때 시스템 안에서 무슨 일이 벌어지는지 밖에서 알 수 있는 정도를 관측성이라고 부르는데, 관측성이 갖춰지지 않은 팀은 1퍼센트에 열어 놓고도 나빠졌는지 모릅니다. 그러면 단계를 나눈 의미가 없어지고 문의가 들어올 때까지 기다리는 옛 방식으로 돌아갑니다.

마지막 단계는 100퍼센트 도달이 아니라 정리입니다. 전원에게 열린 뒤에는 코드에서 분기와 플래그를 걷어내고 옛 경로를 지웁니다. 이 작업을 미루면 다음 출시가 그만큼 복잡해집니다. 실무에서는 플래그를 심을 때 치울 날짜를 함께 적어 두고, 그 날짜가 지나면 담당자에게 알림이 가도록 걸어 둡니다.

"일단 1퍼센트로 열어 두고 내일 아침에 오류율 보고 올릴게요."

배포는 이미 끝났고 지금은 노출 비율만 올리는 단계라는 뜻입니다. 다음 단계로 갈지는 하루치 숫자를 보고 정하겠다는 말입니다.

"그 기능 플래그 꺼 주세요. 결제 쪽에서 오류 올라와요."

배포를 되돌리지 말고 스위치만 내려 달라는 요청입니다. 몇 초 만에 끝나는 조치라 원인 파악보다 먼저 합니다.

"이건 다크 런치로 먼저 돌려 볼게요. 화면엔 안 보입니다."

사용자에게는 옛 결과를 그대로 보여 주면서 새 코드만 뒤에서 함께 돌려 부하와 오류를 재겠다는 뜻입니다.

페이지덱이 문서 저장 방식을 새로 바꿉니다. 태오가 플래그를 심어 배포하고 사흘 동안 다크 런치로 돌립니다. 새 방식과 옛 방식이 같은 결과를 냈는지 비교했더니 1만 건 중 4건이 달랐고, 원인은 표가 들어간 문서였습니다. 고치고 다시 사흘을 돌려 차이가 0이 된 뒤에 사내 계정부터 켭니다.

그다음 주에 지현이 비율을 1퍼센트로 올립니다. 반나절 만에 저장 실패가 평소의 세 배로 뜨고, 태오가 킬 스위치를 내립니다. 켜져 있던 시간은 5시간이고 영향을 받은 계정은 12개였습니다. 수아가 그 12개 팀에 먼저 연락해 상황을 알리는데, 이 규모라면 전화 한 통씩으로 끝납니다. 원인은 오래 쓰던 계정의 옛 형식 문서였고, 고친 뒤 다시 1퍼센트부터 시작해 나흘에 걸쳐 5, 25, 50, 100으로 올렸습니다. 100퍼센트가 된 다음 주에 태오가 플래그와 옛 저장 경로를 코드에서 지웁니다.

같은 작업을 옛 방식으로 했다면 목요일 밤 배포 한 번으로 3만 명이 그 저장 실패를 겪었을 겁니다. 두 방식의 차이는 결함을 막았느냐가 아닙니다. 결함은 양쪽 다 났고, 달랐던 것은 그것을 겪은 사람이 12명이었는지 3만 명이었는지입니다.

점진적 출시를 하면 출시 전 검사를 줄여도 된다고 여기는 경우가 가장 많습니다. 어차피 1퍼센트에게만 열 테니 문제가 있어도 거기서 걸린다는 생각인데, 단계를 나눴으니 안전해졌다는 느낌이 들어서 자연스럽게 빠지는 오해입니다. 실제로는 두 장치가 잡는 것이 다릅니다. 자동 검사는 만든 사람이 예상한 조건에서 코드가 맞게 도는지를 보고, 점진적 출시는 예상하지 못한 조건이 실제 사용자 쪽에 있을 때 그 피해 범위를 줄입니다. 앞쪽을 건너뛰면 1퍼센트에 속한 300명이 자동 검사가 걸렀어야 할 결함까지 대신 겪습니다. 그런 일이 몇 번 반복되면 그 집단은 단순히 먼저 쓰는 사람들이 아니라 늘 깨진 것을 보는 사람들이 되고, 페이지덱처럼 사내 계정을 카나리로 쓰는 팀에서는 동료들이 먼저 지칩니다.

플래그를 심어 두는 것만으로 절차가 갖춰진다고 보는 오해도 흔합니다. 스위치가 있으면 언제든 끌 수 있으니 안심이 되기 때문입니다. 문제는 켜고 끄는 판단을 무엇으로 하느냐가 비어 있다는 점입니다. 올릴 비율과 단계 사이의 대기 시간, 어떤 숫자가 얼마나 나빠지면 내릴지를 미리 정해 두지 않으면 결국 감으로 올리게 되고, 나빠졌는지도 문의가 들어와야 압니다. 여기에 치우지 않은 플래그가 쌓이는 문제가 겹칩니다. 플래그 하나가 경로를 둘로 가르므로 열 개가 남아 있으면 이론상 조합이 1024가지가 되고, 그중 실제로 검사해 본 조합은 몇 개뿐입니다. 한참 뒤에 나는 버그가 어느 조합에서 나는지 아무도 모르는 상태가 이렇게 만들어집니다. 새로 들어온 사람에게는 이 코드가 왜 이렇게 갈라져 있는지 설명할 방법도 없습니다. 스위치를 심는 일과 치우는 일을 한 묶음으로 보지 않으면 몇 달 뒤에 남는 것은 안전장치가 아니라 아무도 손대기 싫어하는 분기 덩어리입니다.