킬 스위치

새 기능을 열었는데 뭔가 잘못됐을 때, 예전에는 고치는 것 말고 방법이 없었습니다. 원인을 찾고 코드를 수정하고 다시 배포하는 순서인데, 여기서 배포 한 번에 20분에서 한 시간이 걸립니다. 원인을 찾는 시간까지 더하면 문제를 인지한 순간부터 멈추기까지 두세 시간이 지나가고, 그동안 사용자는 계속 그 화면을 씁니다.

페이지덱이 새 편집기를 전체 사용자에게 연 날이 그랬습니다. 새벽 두 시에 저장 실패율이 평소의 스무 배로 뛰었고, 온콜이던 태오가 깨어 로그를 봤습니다. 원인이 특정 브라우저에서만 나는 문제라는 것을 알아내는 데 40분이 걸렸고, 수정해 배포하는 데 다시 30분이 걸렸습니다. 그 한 시간 십 분 동안 저장에 실패한 문서가 수백 건이었습니다.

돌아보면 이상한 순서였습니다. 원인을 다 밝혀야 대응할 수 있다는 전제가 깔려 있었는데, 새벽 두 시에 급한 일은 원인 규명이 아니라 피해를 멈추는 것이었습니다. 옛 편집기는 멀쩡히 돌아가고 있었고, 새 편집기로 보내던 사용자를 옛 편집기로 돌려놓기만 하면 저장 실패는 그 자리에서 0이 됩니다.

킬 스위치는 그 순서를 뒤집자는 장치입니다. 먼저 끄고 그다음에 원인을 찾습니다. 새벽에 필요한 것은 배포 파이프라인이 아니라 스위치 하나입니다.

피해를 멈추는 시간과 문제를 고치는 시간을 떼어 놓는 것이 이 장치가 하는 일입니다. 고치는 데 이틀이 걸리더라도 멈추는 데는 몇 초면 되게 만듭니다.

떼어 내는 시간은 세 덩어리입니다.

1. 원인을 밝히는 시간 — 로그를 뒤져 어떤 조건에서 나는 문제인지 알아내는 데 드는 시간입니다. 끄는 판단에는 이게 필요하지 않습니다. 새 기능을 켠 집단에서만 숫자가 나쁘다는 사실만 있으면 충분합니다.
2. 고쳐서 내보내는 시간 — 코드를 수정하고 검사를 통과시키고 배포하는 시간입니다. 킬 스위치는 이미 배포된 코드의 설정값 하나를 바꾸는 일이라 이 과정을 통째로 건너뜁니다.
3. 결정을 기다리는 시간 — 누가 내려도 되는지 정해져 있지 않으면 새벽에 연락할 사람을 찾는 데만 30분이 갑니다. 그래서 스위치를 만들 때 누가 어떤 조건에서 내릴 수 있는지를 함께 적어 둡니다. 보통 온콜 당번에게 사전 승인 없이 내릴 권한을 줍니다.

내리는 판단을 숫자로 걸어 두기도 합니다. 오류율이 정해진 선을 넘으면 사람을 거치지 않고 자동으로 꺼지게 하는 방식인데, 이러려면 관측성이 먼저 있어야 합니다. 지금 시스템에서 무슨 일이 벌어지는지 밖에서 알 수 있는 정도를 말하고, 이게 없으면 나빠진 줄도 모르는 채로 아침을 맞습니다.

스위치를 심을 때 함께 준비하는 것이 끈 뒤의 상태입니다. 껐을 때 사용자에게 무엇이 보이는지가 정해져 있어야 합니다. 새 편집기를 끄면 옛 편집기가 뜨는 식으로 돌아갈 자리를 남겨 두는데, 옛 경로를 이미 지웠다면 스위치를 내려도 빈 화면이 뜰 뿐입니다.

끄는 것으로 해결되지 않는 상황에서는 다른 수단을 씁니다. 무거운 순서대로 셋입니다.

1. 노출 비율 낮추기 — 퍼센트 롤아웃으로 25퍼센트까지 열어 둔 상태라면 완전히 끄는 대신 1퍼센트로 되돌리는 선택이 있습니다. 소수에게는 남겨 두고 원인을 계속 관찰하고 싶을 때 씁니다.
2. 롤백 — 스위치를 내려도 나아지지 않으면 배포된 코드 자체를 옛 버전으로 되돌립니다. 새 기능이 아니라 공통 부분이 망가진 경우가 여기에 해당합니다.
3. 점검 화면 — 서비스 전체를 닫고 안내 화면만 띄웁니다. 데이터가 계속 망가지고 있어 더 쓰게 두는 것이 더 나쁠 때만 씁니다.

애초에 킬 스위치를 쓸 일을 줄이는 쪽도 있습니다. 카나리 릴리스는 전체의 1퍼센트나 사내 계정 같은 작은 집단에만 먼저 열어 이상을 보는 배포인데, 여기서 걸리면 새벽에 스위치를 내릴 일이 애초에 생기지 않습니다. 킬 스위치는 마지막 방어선이지 첫 번째 방어선이 아닙니다.

"일단 킬 스위치 내리고 원인은 아침에 봅시다."

지금은 피해를 멈추는 것이 먼저고 규명은 나중이라는 뜻입니다.

"이 기능 킬 스위치 없으면 이번 주 배포에는 못 올립니다."

끌 방법이 없는 기능은 출시 조건을 못 갖췄다는 말입니다.

"온콜이 승인 없이 내릴 수 있게 해 두죠."

새벽에 결정권자를 찾느라 시간을 쓰지 말자는 제안입니다.

페이지덱은 새 편집기 사건 뒤에 규칙을 하나 만들었습니다. 사용자 화면을 바꾸는 기능은 끄는 방법이 없으면 출시 검토를 통과하지 못합니다. 지현이 출시 점검표에 "끄는 방법과 끈 뒤에 보이는 화면" 한 줄을 넣었고, 태오는 스위치를 내리는 절차를 문서 한 장으로 적어 온콜 당번이 새벽에도 바로 따라 할 수 있게 해 뒀습니다.

넉 달 뒤 비슷한 일이 다시 났습니다. 이번에는 알림이 울리고 4분 만에 기능이 꺼졌고, 원인은 다음 날 업무 시간에 찾았습니다. 영향을 받은 문서는 열두 건이었습니다.

끄면 없던 일이 된다고 생각하기 쉽습니다. 화면에서 기능이 사라지니 그렇게 보입니다. 하지만 꺼지는 것은 앞으로의 동작뿐이고 켜져 있던 동안 벌어진 일은 그대로 남습니다. 잘못 보낸 알림 메일은 이미 받은 사람 메일함에 있고, 새 방식으로 저장된 데이터는 옛 경로가 읽지 못하는 형태로 쌓여 있을 수 있습니다. 그래서 스위치를 설계할 때 끈 뒤에 남는 것을 함께 정리합니다. 켜져 있던 동안의 데이터를 어떻게 할지 정해 두지 않으면, 끄고 나서 더 큰 문제를 만나게 됩니다.

만들어 두기만 하면 된다고 여기는 것도 흔합니다. 스위치는 심어 두면 계속 거기 있을 것 같지만, 코드가 바뀌는 사이 조용히 망가집니다. 분기를 걷어내면서 한쪽을 지워 버렸거나, 옛 경로가 다른 변경에 딸려 사라졌거나, 설정 화면의 값이 실제 코드와 연결이 끊긴 경우입니다. 한 번도 내려 본 적 없는 스위치는 정작 필요한 새벽에 작동하지 않습니다. 평소에 점검 환경에서 한 번씩 내려 보고, 끈 화면이 제대로 뜨는지 확인해 두는 팀이 실제로 씁니다.