[웹앱 실무 100] 배포 - 롤백 전략

배포 시리즈가 어느새 백 번째 편에 닿았네요. 그동안 어떻게 잘 내보낼까를 주로 이야기했는데, 이번 편은 조금 달라요. 잘못됐을 때 어떻게 물러설까, 그러니까 롤백 이야기거든요. 저는 배포의 진짜 실력은 잘 나갈 때가 아니라 잘못됐을 때 드러난다고 믿어요. 문제가 났을 때 침착하게 이전으로 돌아갈 수 있느냐가, 배포를 두려운 도박으로 두느냐 편안한 일상으로 만드느냐를 가르니까요.

이번 편에서는 롤백이 뭔지, 왜 앞으로 고치기보다 되돌리는 게 나은지, 실제로 어떻게 되돌리는지, 데이터가 얽히면 왜 어려워지는지, 어떻게 하면 빠르게 되돌릴 수 있는지, 그리고 왜 평소에 되돌리기를 연습해 둬야 하는지를 풀어 볼게요. 롤백은 있어도 안 쓰면 좋은 안전벨트지만, 그 안전벨트가 있어야 겁 없이 달릴 수 있어요.

롤백이 대체 뭐예요?

롤백은 배포한 새 버전에 문제가 생겼을 때, 이전의 멀쩡하던 버전으로 되돌리는 걸 말해요. 새 버전이 오류를 뿜거나 느려지면, 원인을 파헤치기 전에 일단 사용자를 옛 버전으로 되돌려 서비스를 정상으로 만드는 거죠. 그런 다음 여유를 갖고 무엇이 잘못됐는지를 살펴요. 저는 이 일단 되돌리고 나중에 파헤친다는 순서가 롤백의 핵심이라고 봐요.

왜 이 순서가 중요하냐면, 사용자가 겪는 고통을 먼저 멈추기 위해서예요. 문제가 났을 때 원인부터 찾으려 들면, 그 몇십 분 동안 사용자는 계속 깨진 서비스를 써야 하거든요. 되돌리면 사용자는 곧바로 정상으로 돌아가고, 우리는 불 끄는 급박함 없이 차분히 원인을 볼 수 있죠. 불이 났을 때 왜 났는지 조사하기 전에 일단 끄는 것과 같아요.

롤백이 가능하려면 이전 버전이 살아 있어야 해요. 새 버전을 올릴 때 옛 버전을 완전히 지워 버리면, 되돌릴 데가 없어지거든요. 그래서 배포 방식을 짤 때부터 옛 버전을 잠깐 남겨 두는 걸 염두에 둬요. 앞 편에서 블루그린이 되돌리기가 빠르다고 한 것도, 옛 환경인 파랑을 그대로 살려 두기 때문이었죠.

롤백은 실패가 아니라 정상적인 대응이라는 마음가짐도 중요해요. 되돌리는 걸 부끄러운 일로 여기면, 사람들이 되돌리기를 망설이다 피해를 키워요. 저는 팀에 되돌리는 건 잘한 판단이라고 늘 말해요. 문제를 빨리 알아채고 사용자를 지켰으니까요. 되돌리기를 당당하게 할 수 있는 문화가, 배포를 건강하게 만들어요.

그래서 저는 롤백을 배포의 필수 짝꿍으로 여겨요. 나가는 길만 있고 물러설 길이 없는 배포는 늘 조마조마하지만, 언제든 되돌릴 수 있는 배포는 대담해져요. 첫 편에서 배포의 네 기둥 중 하나로 롤백을 꼽은 이유가 이거예요. 되돌릴 수 있다는 확신이 배포의 두려움을 없애 주거든요.

왜 앞으로 고치기보다 되돌려요?

문제가 났을 때 사람들은 흔히 얼른 고쳐서 새로 배포하자는 유혹에 빠져요. 이걸 앞으로 고치기라 하는데, 급한 상황에서 이건 위험한 선택일 때가 많아요. 급하게 짠 수정은 충분히 검증 안 된 채 나가서, 문제를 더 키우기 십상이거든요. 불난 집에 또 불씨를 던지는 격이 될 수 있어요.

반면 되돌리기는 이미 잘 돌던 것으로 가는 거라 안전해요. 옛 버전은 사용자가 멀쩡히 쓰던 검증된 상태니까요. 그러니 급할수록 새것으로 앞서가기보다 옛것으로 물러서는 게 확실해요. 저는 사고가 나면 고칠 수 있을 것 같아도 일단 되돌린 뒤, 안전해진 상태에서 제대로 고쳐 다시 내보내요.

되돌리기가 더 빠르기도 해요. 원인을 찾아 고치고 검증해 다시 배포하려면 한참 걸리는데, 되돌리기는 준비만 돼 있으면 몇 분이면 되거든요. 사용자 고통을 멈추는 속도로 보면, 되돌리기가 앞으로 고치기보다 압도적으로 빨라요. 급한 상황에서 이 속도 차이는 피해 크기를 크게 가르죠.

다만 되돌릴 수 없는 경우도 있어요. 앞 편에서 본 것처럼 데이터를 이미 지워 버렸으면, 옛 버전으로 돌아가도 쓸 데이터가 없어 못 돌아가거든요. 그래서 롤백을 전제로 배포하려면, 되돌릴 수 있는 방식으로 데이터를 다뤄야 해요. 이 이야기는 뒤에서 더 자세히 할게요.

물론 되돌리기가 만능은 아니에요. 되돌리면 새 기능도 함께 사라지니, 임시 후퇴일 뿐 근본 해결은 아니거든요. 그래서 되돌린 뒤엔 반드시 원인을 제대로 고쳐 다시 나가야 해요. 저는 되돌리기를 급한 불을 끄는 임시방편으로, 앞으로 고치기를 충분히 검증한 뒤의 근본 해결로 나눠 써요. 순서가 중요한 거지, 앞으로 고치기가 나쁜 건 아니에요.

롤백은 실제로 어떻게 해요?

가장 확실한 롤백은 흐름을 옛 버전으로 되돌리는 거예요. 블루그린이라면 문지기한테 다시 파랑으로 하면 되고, 카나리라면 새 버전 비율을 0으로 내리면 돼요. 옛 버전이 그대로 살아 있으니, 흐름만 바꾸면 순식간에 정상으로 돌아가죠. 저는 이 흐름 되돌리기가 가장 빠르고 깔끔한 롤백이라고 봐요.

옛 산출물로 다시 배포하는 방식도 있어요. 첫 편에서 말한 산출물 보관 덕분에, 이전 산출물이 어딘가 저장돼 있으면 그걸 다시 꺼내 올려 되돌릴 수 있거든요. 새로 빌드할 필요 없이 검증됐던 그 산출물을 그대로 쓰니 안전하죠. 다만 다시 배포하는 만큼 흐름 되돌리기보단 조금 느려요.

많은 배포 도구는 버튼 하나로 이전 배포로 되돌리는 기능을 갖고 있어요. 최근 배포들을 목록으로 보여 주고, 그중 멀쩡하던 걸 골라 누르면 그 상태로 돌아가 주죠. 저는 새 도구를 쓸 때 이 되돌리기 기능이 어디 있는지부터 찾아 둬요. 급할 때 이걸 처음 찾으면 이미 늦거든요.

롤백은 자동으로 걸어 둘 수도 있어요. 배포 후 오류가 확 늘거나 응답이 느려지면, 사람이 손대기 전에 파이프라인이 스스로 이전으로 되돌리게요. 저는 중요한 서비스엔 이 자동 되돌리기를 꼭 붙여요. 새벽에 아무도 안 볼 때 문제가 나도, 시스템이 알아서 물러서 피해를 막아 주거든요.

어떤 방식이든 공통으로 챙길 건 되돌린 뒤에도 확인하는 거예요. 되돌렸다고 방심하지 말고, 진짜 정상으로 돌아왔는지를 눈으로 봐야 해요. 가끔 되돌렸는데도 여전히 이상한 경우가 있거든요. 옛 버전 문제가 아니라 다른 데 원인이 있을 수도 있고요. 저는 롤백도 배포처럼 마지막엔 실제로 열어 확인하는 걸 잊지 않아요.

데이터가 얽히면 왜 어려워요?

코드만 되돌리는 건 쉬워요. 진짜 어려운 건 데이터가 얽혔을 때예요. 새 버전이 데이터 모양을 바꿔 놨는데 코드만 옛 버전으로 되돌리면, 옛 코드가 새 모양의 데이터를 못 알아봐 또 깨지거든요. 그래서 데이터를 다루는 배포는 되돌리기를 미리 설계해 둬야 해요. 이게 롤백에서 가장 신경 쓰이는 부분이에요.

앞 편에서 말한 더하고 나중에 지우는 순서가 여기서 빛을 발해요. 데이터를 더하기만 한 단계에선, 옛 코드가 쓰던 것도 그대로 있으니 언제든 깔끔하게 되돌아갈 수 있거든요. 반대로 지우기부터 해 버렸으면, 되돌아갈 데이터가 없어 롤백이 막혀요. 그래서 저는 되돌릴 수 있는 순서로만 데이터를 바꿔요.

이미 새 모양으로 쌓인 데이터도 문제예요. 새 버전이 돌면서 새 형식으로 저장한 데이터를, 옛 버전이 못 읽을 수 있거든요. 그래서 데이터 형식을 바꿀 땐, 옛 버전도 새 형식을 견딜 수 있게 미리 만들어 두거나, 새 형식이랑 옛 형식을 둘 다 읽게 해 둬요. 이렇게 해 두면 되돌려도 데이터를 안 잃어요.

정말 위험한 건 데이터를 망가뜨리는 버그예요. 새 버전이 데이터를 잘못 저장하거나 지워 버리면, 코드를 되돌려도 망가진 데이터는 그대로거든요. 이건 롤백으로 못 풀어요. 그래서 저는 데이터를 건드리는 배포일수록 백업을 꼭 확인하고, 문제가 크면 백업에서 되살리는 것까지 염두에 둬요. 코드 롤백이랑 데이터 복구는 다른 이야기라는 걸 잊으면 안 돼요.

그래서 저는 데이터를 바꾸는 배포를 가장 신중하게 다뤄요. 코드는 되돌리면 그만이지만 데이터는 되돌리기 어렵거나 불가능하니까요. 이런 배포는 작은 단계로 쪼개고, 각 단계마다 되돌릴 수 있는지를 확인하고, 되돌릴 길이 없는 지우기 같은 건 맨 마지막에만요. 이 신중함이 데이터를 지키는 마지막 방패예요.

롤백을 빠르게 하려면요?

롤백은 빠를수록 좋아요. 되돌리는 데 오래 걸리면, 그동안 사용자 고통이 이어지니까요. 가장 빠른 건 앞서 말한 흐름 되돌리기라, 저는 중요한 서비스엔 옛 버전을 살려 두는 방식을 미리 갖춰 둬요. 블루그린처럼요. 되돌릴 때 새로 뭔가를 만들지 않고 이미 있는 걸로 흐름만 바꾸는 게 속도의 핵심이에요.

둘째는 되돌리는 법을 미리 정해 두는 거예요. 급할 때 어떻게 되돌리지를 그제야 고민하면 이미 늦어요. 저는 배포 전에 이번 배포는 이렇게 되돌린다는 걸 손에 쥐고 나서야 새 버전을 올려요. 되돌리는 명령이 뭔지, 버튼이 어디 있는지, 누가 누를 수 있는지를 미리 확인해 두는 거죠.

셋째는 문제를 빨리 알아채는 거예요. 되돌리기가 아무리 빨라도 문제를 늦게 알면 소용없거든요. 그래서 배포 직후 오류랑 응답 속도를 지켜보고, 이상하면 바로 알림이 오게 해 둬요. 빨리 알아채야 빨리 되돌리죠. 이 지켜보기 이야기는 뒤 모니터링 편에서 자세히 다룰게요.

넷째는 망설임을 줄이는 거예요. 되돌릴지 말지 오래 고민하다 때를 놓치는 경우가 많거든요. 저는 어떤 상황이면 무조건 되돌린다는 기준을 미리 정해 둬요. 오류가 이만큼 늘면, 응답이 이만큼 느려지면 고민 없이 되돌린다고요. 기준이 있으면 급박한 순간에 판단이 빨라져요.

다섯째는 되돌리기를 자동화하는 거예요. 사람의 판단이랑 손을 거치지 않고, 정해 둔 조건이 되면 시스템이 스스로 되돌리게요. 가장 빠르고 확실한 방법이죠. 다만 자동 되돌리기는 조건을 잘못 잡으면 멀쩡한데도 되돌리는 일이 생기니, 기준을 신중히 잡아야 해요. 저는 명백한 상황엔 자동을, 애매한 상황엔 사람 판단을 두는 식으로 섞어요.

롤백 연습은 왜 해야 해요?

롤백은 급할 때 처음 하면 반드시 실수해요. 그래서 저는 평소에 되돌리기를 연습해 두라고 강하게 권해요. 아무 일 없는 평온한 날에 일부러 되돌려 보는 거예요. 되돌리는 명령이 진짜 먹히는지, 몇 분이나 걸리는지, 되돌린 뒤 정상인지를 미리 겪어 두면, 진짜 사고 때 당황하지 않아요.

연습을 안 하면 되돌리기 기능이 실제론 고장 나 있는 걸 사고 때 알게 돼요. 옛 버전이 안 남아 있거나, 되돌리는 명령이 바뀌었거나, 권한이 없거나요. 이런 걸 가장 급한 순간에 발견하면 정말 아찔하죠. 저는 되돌리기도 정기적으로 점검해야 하는 안전장치라고 봐요. 소화기를 사 두고 작동하는지 안 보면 정작 불날 때 안 터지는 것과 같아요.

연습은 팀 전체가 하는 게 좋아요. 되돌리기를 한 사람만 할 줄 알면, 그 사람이 없는 날 사고가 나면 마비되거든요. 저는 팀원 모두가 돌아가며 되돌리기를 해 보게 해서, 누가 있든 되돌릴 수 있게 만들어요. 롤백 지식이 팀에 고루 퍼져 있어야 진짜 안전망이 되니까요.

더 나아가, 일부러 문제를 일으켜 보는 연습도 있어요. 평소에 가짜로 사고를 내 보고, 우리 시스템이 잘 견디는지 되돌리기가 잘 되는지를 확인하는 거죠. 무섭게 들리지만, 통제된 상황에서 미리 겪어 두면 진짜 사고 때 훨씬 침착해져요. 저는 이런 연습이 강한 팀을 만든다고 믿어요.

정리하면, 롤백은 문제가 났을 때 이전으로 물러서는 배포의 필수 짝꿍이에요. 급할 땐 앞으로 고치기보다 일단 되돌려 사용자 고통을 먼저 멈추고, 옛 버전을 살려 둬 빠르게 되돌리며, 데이터는 되돌릴 수 있는 순서로 다뤄요. 무엇보다 평소에 연습해 둬야 진짜 사고 때 힘을 발휘하죠. 다음 편에서는 배포한 뒤 그게 진짜 잘 됐는지 확인하는 배포 후 검증 이야기로 넘어가 볼게요.