핫픽스

내보내는 일에 주기가 생기면서 따라온 말입니다. 팀이 2주에 한 번 정해진 날에 배포하기로 하면 범위를 미리 닫고 검수할 시간을 확보할 수 있습니다.

문제는 그 주기가 기다려 주지 않는 사고를 만날 때입니다. 배포한 다음 날 결제 화면에서 카드가 등록되지 않는 것을 발견했다고 해 봅시다. 다음 배포일까지는 13일이 남았고, 그동안 유료로 전환하려던 사람은 전부 돌아갑니다. 하루 열 명이면 13일에 130명이고, 되돌릴 방법이 없습니다.

페이지덱에서도 이 장면이 먼저 있었습니다. 수아가 "고객사가 지금 결제가 안 된다는데요" 하고 알리자 태오가 "다음 배포가 다음 주 화요일인데요" 하고 답했고, 그 뒤로 30분 동안 누가 예외를 승인하는지를 찾느라 아무도 코드를 건드리지 못했습니다.

핫픽스는 그 길을 미리 뚫어 둔 것입니다. 기다리는 비용이 절차를 건너뛰는 위험보다 명백히 클 때만 쓰는 예외 경로를 하나 만들어 두고, 언제 그 경로를 여는지는 사고가 난 자리에서 정하지 않고 미리 적어 둡니다.

이번 사고가 주기를 기다릴 수 있는지 먼저 판정하고, 기다릴 수 없을 때만 아래를 밟습니다. 여섯 단계입니다.

1. 심각도를 매깁니다. 결함이 서비스에 끼치는 영향의 크기를 등급으로 나눈 것이 심각도입니다. 돈이 오가지 않거나 데이터가 사라지거나 보안이 뚫린 경우가 최상위 등급이고, 여기 해당할 때만 핫픽스로 갑니다. 화면이 조금 깨지는 문제는 다음 주기로 넘깁니다.
2. 태울 변경을 한 줄로 못 박습니다. 고칠 대상을 문장 하나로 적고 그 밖의 것은 넣지 않습니다. "어차피 배포하는 김에" 붙은 변경이 두 번째 사고를 만드는 가장 흔한 경로입니다.
3. 지금 돌고 있는 코드에서 갈라 고칩니다. 다음 릴리스용으로 쌓아 둔 코드에 고침을 얹으면 아직 검수하지 않은 변경까지 함께 나갑니다. 운영에 올라가 있는 그 버전을 기준으로 갈라내 거기에만 고침을 얹습니다.
4. 줄인 검증을 돌립니다. 평소 하루 걸리던 것을 한 시간으로 줄이되 비우지는 않습니다. 코드 리뷰는 동료 한 명이라도 반드시 보고, 출시 전 품질을 점검하는 활동인 품질 보증은 고친 부분과 그 주변만 확인합니다. 자동 검증과 배포를 잇는 체계인 CI/CD가 있으면 이 단계가 사람 손을 덜 탑니다.
5. 내보내고 지켜봅니다. 되돌릴 방법을 손에 쥔 채 올립니다. 올린 뒤 30분 동안 오류 발생량과 해당 화면의 사용 지표를 보고, 나아지지 않으면 롤백합니다.
6. 본가지에 다시 심고 기록합니다. 운영 코드에만 얹은 고침은 다음 릴리스용 코드에는 없습니다. 여기서 빠뜨리면 2주 뒤 정규 배포에서 같은 버그가 되살아납니다. 사용자에게 알릴 내용이 있으면 릴리스 노트에 적고, 사고가 컸다면 원인과 개선을 정리한 포스트모템까지 남깁니다.

6번을 빠뜨리는 일이 가장 잦습니다. 불이 꺼지면 다들 원래 하던 일로 돌아가기 때문입니다. 핫픽스를 내보낸 사람이 그날 안에 본가지 반영까지 마치도록 규칙으로 두는 팀이 많습니다.

기다리는 1시간이 그대로 손해로 쌓이는 문제에만 씁니다. 결제가 안 되는 상태, 로그인이 막힌 상태, 사용자 데이터가 지워지는 상태, 남의 정보가 보이는 상태가 여기 해당합니다. 페이지덱 기준으로 결제가 막히면 하루 매출이 통째로 비고, 남의 문서가 보이면 시간이 갈수록 피해 본 계정이 늘어납니다.

반대로 우회할 방법이 있는 문제는 해당하지 않습니다. 버튼 위치가 잘못됐거나 목록 정렬이 뒤집힌 문제는 불편하지만 일을 막지는 않습니다. 기능을 추가하는 변경도 아무리 급해도 이 경로로 나가지 않습니다.

한계는 셋입니다.

1. 걸러 내던 장치를 스스로 끕니다. 평소 릴리스를 더디게 만들던 검수와 대기가 실수를 잡아내던 그물이었습니다. 그물을 걷고 나가면 고친 것이 다른 곳을 깨뜨려도 나간 뒤에 압니다. 핫픽스가 두 번째 핫픽스를 부르는 이유입니다.
2. 사람을 씁니다. 한밤중 배포에는 고치는 사람, 리뷰하는 사람, 지켜보는 사람이 동시에 붙습니다. 정해진 시간에 장애 연락을 받는 당번인 온콜이 있어도 그 한 사람으로는 끝나지 않습니다.
3. 잦아지면 주기가 무너집니다. 한 달에 다섯 번씩 핫픽스가 나가는 팀은 사실상 예외 경로로 배포하는 셈이고, 정규 릴리스에 붙은 검수는 의미를 잃습니다. 이때 고칠 것은 핫픽스 절차가 아니라 버그가 그만큼 나가는 이유입니다.

"이건 핫픽스로 나갑니다. 결제 막힌 지 40분 됐어요."

주기를 기다리지 않고 지금 내보내겠다는 선언이고, 근거는 경과 시간입니다.

"핫픽스에 그거 같이 태우지 마세요. 고침 하나만 갑니다."

검증을 줄인 배포에 검증 안 된 변경을 얹지 말라는 제지입니다.

"핫픽스 나간 거 본가지에 머지됐나요?"

운영에만 얹은 고침이 다음 릴리스에서 사라지지 않았는지 확인하는 말입니다.

페이지덱에서 돌아간 장면은 이렇습니다. 금요일 오후 4시에 수아가 고객사 세 곳에서 같은 결제 오류를 받았다고 알렸고, 지현이 심각도를 최상위로 매겨 핫픽스를 결정했습니다. 태오가 운영에 올라가 있는 버전에서 갈라내 한 줄을 고쳤고, 다른 개발자 한 명이 15분 만에 리뷰를 마쳤습니다.

5시 20분에 배포가 끝났고, 30분 동안 결제 성공률이 원래 수치로 돌아오는 것을 확인한 뒤에야 다들 퇴근했습니다. 그다음 주 월요일에 지현이 회고를 열어 이 버그가 검수를 통과한 이유를 짚었습니다.

핫픽스를 "빨리 배포하는 방법" 으로 읽는 경우가 많습니다. 실제로 빠르게 나가니 그렇게 보이기 쉽습니다. 하지만 빠른 것은 결과이고 실체는 절차를 줄인 예외입니다. 속도를 이유로 쓰기 시작하면 급하지 않은 변경까지 이 경로로 나가 반년 뒤에는 정규 릴리스가 형식만 남고, 사고가 나도 무엇이 언제 나갔는지 아무도 설명하지 못합니다.

핫픽스가 롤백보다 나은 선택이라는 오해도 잦습니다. 되돌리는 것은 후퇴처럼, 고쳐서 내보내는 것은 전진처럼 느껴지기 때문입니다. 실제로는 원인을 모르는 채 내보낸 고침은 그것이 맞는지도 확인되지 않은 채 나갑니다. 원인이 분명하고 고침이 한 줄이면 핫픽스가 빠르지만, 원인을 모르면 먼저 되돌려 피를 멈추고 원인은 그다음에 찾습니다.