롤백

배포한 코드에 문제가 있다는 사실을 알았을 때, 한동안 길은 하나뿐이었습니다. 원인을 찾아 고치고 다시 배포하는 것입니다. 문제는 그 사이에 걸리는 시간입니다. 원인을 못 찾으면 한 시간이 두 시간이 되고, 그동안 사용자는 깨진 화면을 계속 봅니다.

페이지덱도 겪었습니다. 태오가 문서 저장 방식을 바꾼 배포를 올린 뒤 저장이 스무 번에 한 번씩 실패했습니다. 화면에는 저장됐다고 뜨는데 실제로는 안 들어간 경우여서 문의가 곧 들어왔습니다. 태오가 40분 동안 원인을 찾았지만 특정 조건에서만 나는 문제라 재현이 안 됐습니다. 그 40분 동안 글을 쓰던 사람들은 계속 글을 잃었습니다.

여기서 순서를 뒤집은 것이 롤백입니다. 원인 규명과 복구를 분리하고 복구를 먼저 합니다. 지금 돌아가는 코드를 어제 돌아가던 코드로 되돌리면 문제는 그 자리에서 멈춥니다. 왜 그랬는지는 사용자가 정상 화면을 보는 상태에서 천천히 찾습니다.

되돌릴지 정하는 기준을 배포 전에 적어 두고, 그 기준에 닿으면 판단을 생략하고 실행하는 순서로 굴러갑니다. 새벽에 기준을 만들기 시작하면 이미 늦습니다.

1. 기준과 권한을 배포 전에 정합니다. 오류율이 평소의 세 배를 넘으면, 저장 성공률이 99퍼센트 아래로 내려가면처럼 숫자로 적습니다. 누가 되돌릴 수 있는지도 함께 적습니다. 정해 두지 않으면 정작 필요한 새벽에 결정권자를 찾는 데 시간을 씁니다.
2. 더 가벼운 수단이 있는지 먼저 봅니다. 문제가 특정 기능에만 있으면 킬 스위치로 그 기능만 끕니다. 코드를 배포한 채 기능만 켜고 끄는 스위치가 피처 플래그이고, 킬 스위치는 그 플래그를 급하게 내리는 장치입니다. 플래그로 해결되면 롤백까지 가지 않습니다.
3. 되돌릴 지점을 지목합니다. 직전 배포 버전을 쓰는 것이 기본이고, 그것도 의심되면 그 앞 버전까지 봅니다. 배포마다 버전을 남기지 않은 팀은 이 단계에서 막힙니다.
4. 되돌리고 확인합니다. 확인은 화면을 열어 보는 것이 아니라 1번에서 정한 숫자가 원래 자리로 돌아왔는지 보는 것입니다. 돌아오지 않으면 원인이 이번 배포가 아니라는 뜻이고, 그때는 장애 대응 절차로 넘어갑니다. 장애 대응은 문제가 터졌을 때 복구하고 재발을 막는 활동입니다.
5. 그사이에 쌓인 데이터를 정리합니다. 새 코드가 만든 기록을 옛 코드가 읽지 못할 수 있어서, 되돌린 뒤 그 기록을 옮기거나 지우는 작업이 따라옵니다. 이 단계가 롤백을 가볍지 않게 만듭니다.
6. 기록을 남깁니다. 언제 무엇을 왜 되돌렸고 다시 올릴 조건이 무엇인지 적습니다. 이 줄이 없으면 같은 코드가 이틀 뒤에 그대로 다시 올라갑니다.

잘 맞는 자리는 셋입니다. 배포된 코드 자체가 원인일 때, 원인을 아직 모를 때, 영향을 받는 사용자가 많을 때입니다. 특히 두 번째가 그렇습니다. 원인을 모르는 채 고쳐 올리는 일은 도박이지만, 되돌리기는 어제 돌아가던 상태로 가는 것이라 결과가 예측됩니다.

한계는 네 가지입니다.

1. 데이터 구조가 바뀐 배포 — 새 칸을 만들어 값을 쌓기 시작했다면 코드만 되돌려도 그 값은 남습니다. 옛 코드가 그 칸을 모르면 읽다가 또 실패합니다. 그래서 구조를 바꾸는 배포는 되돌릴 방법을 미리 같이 만들어 둡니다.
2. 밖으로 이미 나간 일 — 보낸 메일, 승인된 결제, 외부 시스템에 전달된 주문은 코드를 되돌려도 되돌아오지 않습니다.
3. 문제가 작을 때 — 버튼 문구가 틀린 정도라면 전체를 되돌리는 것은 과합니다. 그 부분만 고쳐 즉시 내보내는 편이 빠릅니다.
4. 되돌릴 대상이 없을 때 — 처음 나가는 기능은 직전 버전이 없습니다. 플래그를 꺼서 없던 상태로 만드는 것이 유일한 길이라, 새 기능은 플래그를 심어 두고 내보냅니다.

아주 작은 집단에만 먼저 열어 이상을 살피는 카나리 릴리스와 그 비율을 단계적으로 올리는 퍼센트 롤아웃을 쓰는 팀은 롤백까지 갈 일이 드뭅니다. 문제가 1퍼센트 구간에서 잡히면 플래그를 내리는 것으로 끝납니다.

"원인 찾는 건 나중에 하고 먼저 롤백합시다."

복구를 원인 규명보다 앞에 두자는 제안입니다.

"이건 롤백으로 안 돼요. 새 칸에 데이터가 이미 쌓였습니다."

코드만 되돌리면 옛 코드가 새 데이터를 읽다 또 실패한다는 지적입니다.

"저장 성공률 99퍼센트 아래로 떨어지면 묻지 말고 되돌리기로 정해 뒀습니다."

기준과 권한을 배포 전에 합의해 뒀다는 확인입니다.

페이지덱은 그 저장 사고 이후로 배포 문서에 되돌리기 기준 한 줄을 넣습니다. 태오가 배포를 올릴 때 어떤 숫자가 어디까지 내려가면 되돌릴지 적고, 지현이 그 줄만 확인한 뒤 배포를 승인합니다.

같은 저장 방식을 두 달 뒤에 다시 올렸을 때는 실패가 열 분 만에 잡혔고 되돌리기까지 3분이 걸렸습니다. 원인은 그다음 주에 찾았는데 특정 브라우저에서만 나는 문제였고, 그 조건을 알고 올린 세 번째 배포는 문제가 없었습니다.

롤백이 팀의 실패를 보여 주는 기록이라고 보는 경우가 가장 많습니다. 되돌렸다는 사실이 남으니 그렇게 읽힙니다. 하지만 되돌릴 수 있다는 것은 준비가 되어 있다는 뜻입니다. 되돌리기를 흠으로 다루면 팀은 급하게 고쳐 올리는 쪽을 고르고, 검증이 덜 된 코드가 장애 중에 또 하나 얹힙니다. 세어야 할 숫자는 되돌린 횟수가 아니라 문제를 알아채고 정상으로 돌아가기까지 걸린 시간입니다.

언제든 되돌릴 수 있다고 믿는 것도 흔합니다. 버튼 하나로 끝나는 배포 도구를 쓰다 보면 그렇게 느껴집니다. 그런데 코드는 되돌아가도 데이터와 외부로 나간 일은 앞으로만 갑니다. 되돌리기를 무제한 보험으로 다루면 구조를 바꾸는 배포를 되돌릴 방법 없이 올리고, 정작 필요한 순간에 앞으로 고쳐 나가는 수밖에 없게 됩니다.