[웹앱 실무 103] 배포 - 배포 사고 대응

아무리 잘 갖춰도 사고는 나요. 자동화하고, 시험하고, 검증하고, 모니터링까지 해도, 언젠가는 배포가 서비스를 무너뜨리는 순간이 와요. 저는 이걸 처음엔 실력이 모자라서라고 여겼는데, 오래 일하다 보니 사고는 피할 수 없고 다만 잘 대응할 뿐이라는 걸 알았어요. 이번 편은 그 사고가 났을 때 어떻게 움직이는가에 대한 이야기예요. 잘 대응하는 팀이랑 우왕좌왕하는 팀은, 같은 사고를 겪어도 피해 크기가 완전히 달라지거든요.

이번 편에서는 사고 대응이 뭔지, 사고가 나면 뭐부터 하는지, 누가 무엇을 맡는지, 사고 중 소통은 어떻게 하는지, 사고가 끝나면 뭘 하는지, 그리고 사고에 강한 팀을 어떻게 만드는지를 풀어 볼게요. 겪고 싶지 않지만 반드시 겪게 되는 일이라, 미리 알아 두면 그 순간이 훨씬 덜 무서워요.

사고 대응이 대체 뭐예요?

사고 대응은 서비스에 문제가 터졌을 때 침착하고 빠르게 정상으로 되돌리는 일이에요. 배포 후 오류가 쏟아지거나, 서비스가 멈추거나, 데이터가 이상해졌을 때, 당황하지 않고 정해진 흐름대로 움직이는 거죠. 저는 사고 대응의 핵심이 기술이 아니라 침착함이라고 봐요. 급박한 상황에서 허둥대면 오히려 사고를 키우거든요.

사고 대응에서 가장 중요한 원칙은 복구가 먼저, 원인은 나중이에요. 불이 났을 때 왜 났는지 조사하기 전에 일단 끄듯, 사고가 나면 원인부터 파헤치려 들지 말고 사용자를 정상으로 먼저 돌려놔요. 앞 편들에서 말한 롤백이 여기서 첫 번째 무기가 되죠. 되돌려서 서비스를 살린 뒤, 여유를 갖고 원인을 봐요.

사고 대응은 혼자 하는 게 아니에요. 급박한 상황일수록 여러 사람이 각자 역할을 나눠 움직여야 하거든요. 한 사람이 다 하려 들면 놓치는 게 생기고 지쳐요. 그래서 사고 대응엔 누가 지휘하고, 누가 손을 쓰고, 누가 알리는지를 정해 두는 게 중요해요. 이 역할 이야기는 뒤에서 더 다룰게요.

사고 대응은 평소에 준비해야 해요. 사고가 터진 순간에 어떻게 하지를 처음 고민하면 이미 늦거든요. 되돌리는 법, 연락할 사람, 확인할 곳을 미리 정해 두고, 가끔 연습까지 해 둬야 진짜 사고 때 몸이 움직여요. 저는 사고 대응을 소방 훈련처럼 여겨요. 불이 안 나길 바라되, 날 때를 대비해 미리 몸에 익혀 두는 거죠.

무엇보다 사고 대응은 사람을 탓하지 않는 마음 위에 서요. 사고가 났을 때 누구 잘못이야부터 따지면, 사람들이 숨기고 방어하느라 대응이 늦어지거든요. 저는 사고를 개인의 실수가 아니라 시스템이 못 막은 것으로 봐요. 그래야 다들 솔직하게 협력해 빨리 수습하고, 나중에 제대로 배우거든요.

사고가 났다는 건 어떻게 보면 그동안 안 보이던 약한 곳이 드러난 거예요. 그래서 저는 사고를 서비스가 성장하는 계기로도 봐요. 아프지만, 그 아픔이 어디가 무른지를 정확히 짚어 주거든요. 사고를 겪을 때마다 그 약한 곳을 하나씩 메우면, 서비스는 점점 단단해져요. 사고 없는 완벽한 서비스를 꿈꾸기보다, 사고에서 잘 배우는 서비스를 목표로 삼는 게 훨씬 현실적이고 건강해요.

사고가 나면 뭐부터 해요?

가장 먼저 할 건 사고임을 인정하고 알리는 거예요. 별거 아니겠지 하며 혼자 끌어안다 키우는 경우가 정말 많거든요. 이상하다 싶으면 일단 사고로 선언하고 사람을 모으는 게 나아요. 알고 보니 별것 아니었으면 다행이고, 진짜 큰 거였으면 빨리 모인 게 다행이니까요. 저는 과하게 반응해서 손해 본 적은 없다고 여겨요.

다음은 피해를 멈추는 거예요. 원인을 몰라도 사용자 고통부터 줄여요. 방금 배포가 원인 같으면 되돌리고, 특정 기능이 문제면 그 기능만 잠깐 꺼요. 완벽한 해결이 아니어도, 더 나빠지는 걸 막는 게 우선이에요. 저는 이걸 지혈이라고 불러요. 상처를 완전히 낫게 하기 전에, 피부터 멎게 하는 거죠.

피해를 멈췄으면 상황을 파악해요. 무엇이 언제부터 어떻게 잘못됐는지, 얼마나 많은 사용자가 겪는지를 모니터링이랑 로그로 봐요. 이때 앞 편에서 갖춘 관측 도구들이 진가를 발휘하죠. 상황을 알아야 제대로 된 대응을 할 수 있으니, 추측으로 움직이기보다 실제 데이터를 봐요.

그다음 원인을 좁혀 가요. 사고 직전에 무엇이 바뀌었는지부터 봐요. 대개 사고는 방금 한 변경에서 오거든요. 배포했으면 그 배포를, 설정을 바꿨으면 그 설정을 의심하죠. 저는 최근 변경 목록부터 훑어요. 아무것도 안 바꿨는데 갑자기 사고가 났다면, 바깥 요인이나 서서히 쌓인 문제를 의심하고요.

원인을 찾아 고쳤으면 제대로 복구됐는지 확인해요. 고쳤다고 방심하지 말고, 진짜 정상으로 돌아왔는지를 눈으로 봐요. 앞 편의 배포 후 검증처럼요. 그리고 한동안 더 지켜봐요. 고친 줄 알았는데 다시 터지는 경우가 있거든요. 저는 사고가 확실히 끝났다 싶을 때까지 긴장을 안 풀어요.

누가 무엇을 맡아요?

사고가 커지면 역할을 나누는 게 중요해요. 첫째는 지휘하는 사람이에요. 이 사람은 직접 손을 쓰기보다, 전체를 보며 결정을 내려요. 되돌릴지, 누구를 더 부를지, 지금 뭐가 우선인지를 정하죠. 지휘가 없으면 다들 각자 손대다 서로 부딪히거나 빈틈이 생기거든요. 저는 사고가 커지면 가장 먼저 지휘를 정해요.

둘째는 손을 쓰는 사람이에요. 실제로 되돌리고, 설정을 고치고, 로그를 파는 사람이죠. 이 사람은 대응에 집중할 수 있게, 딴 데 신경 안 쓰게 해 줘야 해요. 그래서 지휘하는 사람이랑 손 쓰는 사람은 나누는 게 좋아요. 한 사람이 결정도 하고 손도 쓰면, 둘 다 어설퍼지거든요.

셋째는 알리는 사람이에요. 지금 무슨 일인지, 얼마나 걸릴지를 안팎에 전하는 사람이죠. 대응하는 사람들한테 바깥 문의가 쏟아지면 집중이 깨지거든요. 그래서 소통을 한 사람이 맡아, 대응하는 사람은 대응에만 집중하게 해요. 이 알리는 역할이 의외로 사고 수습의 속도를 크게 좌우해요.

작은 팀이면 한 사람이 여러 역할을 겸할 수도 있어요. 다만 지휘랑 손 쓰기만은 되도록 나누는 게 좋아요. 큰 사고일수록 이 구분이 중요하고, 작은 사고면 유연하게 해도 돼요. 저는 사고 규모에 맞춰 역할을 조였다 풀었다 해요. 중요한 건 누가 뭘 하는지 서로 아는 것이지, 형식 그 자체는 아니거든요.

역할은 미리 정해 두면 더 좋아요. 사고가 터진 순간에 누가 지휘하지부터 헷갈리면 시간을 버리거든요. 저는 당번을 정해 두고, 사고 나면 당번이 지휘를 맡게 해요. 그러면 누구 하나 주저하는 일 없이 바로 움직이기 시작하죠. 정해진 사람이 있으면 공백이 안 생겨요.

사고 중 소통은 어떻게 해요?

사고 중 소통의 원칙은 자주, 솔직하게예요. 상황이 어떻든 지금 이렇습니다를 자주 알리는 게, 조용히 있다 다 해결하고 알리는 것보다 나아요. 사람들은 모르는 상태를 가장 불안해하거든요. 저는 진행이 없어도 아직 보고 있습니다라는 소식이라도 꾸준히 전해요. 침묵은 불안이랑 억측을 키우니까요.

소통은 한곳에 모아서 해요. 여기저기 흩어져 이야기하면 누가 뭘 아는지 뒤죽박죽되거든요. 저는 사고가 나면 전용 공간을 하나 열어, 거기서 모든 상황이랑 결정이 오가게 해요. 그러면 나중에 온 사람도 그 공간만 보면 지금까지 무슨 일이 있었는지 따라잡을 수 있어요.

상황을 전할 땐 사실이랑 추측을 갈라요. 오류율이 올랐다는 사실이랑 배포 때문인 것 같다는 추측은 다르거든요. 이걸 섞으면 확인 안 된 추측이 사실처럼 퍼져 혼란을 키워요. 저는 지금 아는 것이랑 아직 모르는 것, 추측하는 것을 나눠 전해요. 솔직하게 이건 아직 모릅니다라고 말하는 게 훨씬 믿음을 줘요.

바깥에 알릴 땐 눈높이를 맞춰요. 기술적인 세세함보다 사용자한테 어떤 영향이고 언제쯤 나아지는지를 전하는 거죠. 사용자는 어느 서버가 어쨌는지가 아니라 내가 언제 다시 쓸 수 있는지가 궁금하거든요. 저는 안팎의 소통을 듣는 사람이 뭘 궁금해하는지에 맞춰 달리해요.

소통에서 사과를 두려워 말아요. 문제를 겪게 해 미안하다는 말은 변명이 아니라 신뢰를 지켜요. 감추거나 남 탓하는 것보다, 솔직히 인정하고 어떻게 하겠다고 밝히는 게 오래 봐서 이득이거든요. 저는 사고 소통에서 정직함이 가장 큰 자산이라고 믿어요. 한 번의 정직한 대응이 여러 번의 신뢰로 돌아와요.

사고가 끝나면 뭘 해요?

사고를 수습했다고 끝이 아니에요. 가장 값진 배움이 그 뒤에 있거든요. 사고가 끝나면 돌아보기를 해요. 무엇이 어떻게 잘못됐고, 어떻게 알아챘고, 어떻게 대응했고, 무엇을 배웠는지를 함께 짚는 거죠. 저는 이 돌아보기를 사고가 준 수업료를 회수하는 자리라고 여겨요. 아팠던 만큼 배워야 본전이니까요.

돌아보기의 핵심은 사람이 아니라 시스템을 본다는 거예요. 누가 실수했나가 아니라 왜 그 실수가 사고까지 이어졌나를 물어요. 사람은 언제나 실수하니, 실수해도 사고가 안 되게 시스템을 고치는 게 답이거든요. 저는 이 실수를 어떻게 막을 수 있었나를 물어, 자동 검사나 안전장치를 보강해요. 탓하기는 아무것도 안 바꾸지만, 시스템 개선은 다음을 막아요.

돌아보기에선 구체적인 할 일을 뽑아야 해요. 다음엔 잘하자 같은 다짐은 아무것도 안 바꾸거든요. 이 검증 항목을 추가한다, 이 알림을 만든다, 되돌리기를 자동화한다 같은 실제로 할 일을 정하고, 누가 언제까지 할지까지 적어요. 저는 돌아보기가 할 일 목록으로 끝나지 않으면 반쪽이라고 봐요.

사고 기록은 남겨서 함께 봐요. 무슨 일이 있었고 어떻게 대응했고 무엇을 고치기로 했는지를 적어, 팀이 공유하는 거죠. 그러면 비슷한 사고가 났을 때 그 기록이 길잡이가 되고, 새 팀원도 과거의 아픔에서 배워요. 저는 이 사고 기록들을 팀의 소중한 자산으로 여겨요. 겪은 사고가 헛되지 않게요.

돌아보기는 안전한 분위기에서 해야 해요. 탓하는 자리가 되면, 다들 솔직히 말 안 하고 방어만 하거든요. 그럼 진짜 원인이 안 드러나 배울 게 없죠. 저는 돌아보기에서 솔직히 말해도 안전하다는 믿음을 지키려 애써요. 실수를 드러내도 벌받지 않아야, 사람들이 진짜 문제를 꺼내 놓거든요.

사고에 강한 팀은 어떻게 만들어요?

사고에 강한 팀은 사고를 숨기지 않아요. 작은 이상도 편하게 꺼내 놓고, 사고를 배움의 기회로 여기죠. 반대로 사고를 부끄러운 것으로 여기는 팀은, 문제를 숨기다 키워요. 저는 팀에 사고는 누구나 겪고, 잘 대응하면 된다는 분위기를 심으려 해요. 이 분위기가 사고 대응의 가장 밑바탕이거든요.

강한 팀은 미리 준비하고 연습해요. 되돌리는 법을 연습하고, 사고 상황을 가짜로 겪어 보고, 역할을 미리 정해 두죠. 앞 편에서 말한 일부러 문제를 일으켜 보는 연습도 그 하나예요. 저는 이런 준비가 진짜 사고 때의 침착함을 만든다고 믿어요. 겪어 본 상황은 덜 무섭거든요.

강한 팀은 배운 걸 실제로 반영해요. 돌아보기에서 뽑은 할 일을 미루지 않고 고쳐, 같은 사고를 두 번 안 겪죠. 반대로 배우기만 하고 안 고치면, 같은 사고가 반복돼 사람들이 지쳐요. 저는 사고에서 나온 개선을 새 기능만큼 중요하게 다뤄요. 이게 쌓여야 서비스가 점점 튼튼해지거든요.

강한 팀은 지식을 나눠요. 되돌리는 법도, 대응하는 법도, 시스템 구조도 여러 사람이 알게 해요. 한 사람한테 묶여 있으면 그 사람 없을 때 마비되니까요. 저는 사고 대응이 특정 영웅한테 의존하지 않게, 지식을 팀에 고루 퍼뜨려요. 누가 있든 대응할 수 있는 팀이 진짜 강한 팀이거든요.

정리하면, 사고 대응은 침착하게 복구를 먼저 하고 원인은 나중에 보는 일이에요. 역할을 나누고, 자주 솔직하게 소통하고, 끝나면 사람이 아니라 시스템을 돌아보며 배우죠. 무엇보다 탓하지 않고 준비하고 나누는 문화가 사고에 강한 팀을 만들어요. 다음 편에서는 이 배포 시리즈를 마무리하며 배포에서 흔한 실수들을 한자리에 모아 볼게요.