[웹앱 실무 102] 배포 - 모니터링과 알림

배포의 네 기둥 중 마지막이 관측성이라고 첫 편에서 말했잖아요. 이번 편은 그 관측성, 그러니까 지금 서비스에 무슨 일이 벌어지는지 들여다보는 모니터링이랑 알림 이야기예요. 배포를 아무리 잘해도, 배포 이후 서비스가 어떻게 지내는지를 못 보면 문제가 나도 사용자 항의로만 알게 되거든요. 저는 모니터링을 갖추기 전엔 깜깜한 방에서 배포하는 기분이었는데, 갖추고 나서는 불을 켠 것처럼 마음이 놓였어요.

이번 편에서는 모니터링이 뭔지, 무엇을 지켜봐야 하는지, 로그랑 지표랑 추적이 어떻게 다른지, 알림은 언제 울려야 하는지, 쏟아지는 알림에 지치지 않으려면 어떻게 하는지, 그리고 모니터링을 어떻게 시작하는지를 풀어 볼게요. 거창한 도구 이야기가 아니라, 서비스를 눈으로 지켜보는 상식적인 이야기예요.

모니터링이 대체 뭐예요?

모니터링은 서비스가 지금 어떻게 돌고 있는지를 계속 지켜보는 일이에요. 요청이 얼마나 오는지, 오류가 얼마나 나는지, 응답이 얼마나 빠른지 같은 걸 실시간으로 보는 거죠. 사람이 화면 앞에 붙어 있을 순 없으니, 이런 걸 자동으로 모으고 보여 주는 장치를 갖춰 둬요. 그래서 언제든 서비스의 상태를 한눈에 볼 수 있게요.

모니터링이 왜 필요하냐면, 문제를 사용자보다 먼저 알기 위해서예요. 모니터링이 없으면 오류가 나도 누군가 항의할 때까지 모르거든요. 그사이 수많은 사용자가 이미 겪은 뒤죠. 모니터링이 있으면 오류가 늘기 시작하는 순간 바로 알아채, 사용자가 크게 겪기 전에 손쓸 수 있어요. 저는 이 먼저 아는 것이 모니터링의 가장 큰 값어치라고 봐요.

모니터링은 배포 직후에 특히 빛나요. 앞 편에서 배포 후 검증을 이야기했는데, 그 검증을 지속적으로 하게 해 주는 게 모니터링이거든요. 배포하고 나서 오류가 늘지 않는지, 느려지지 않는지를 모니터링으로 지켜보다, 이상하면 되돌리는 거죠. 그래서 모니터링은 롤백을 언제 할지 판단하는 근거가 돼요.

모니터링은 문제를 찾는 것뿐 아니라 이해하는 데도 써요. 서비스가 언제 붐비는지, 어떤 화면이 느린지, 어디서 오류가 잦은지를 알면 어디를 개선할지 보이거든요. 저는 모니터링을 서비스의 건강 검진이라고 여겨요. 아플 때 찾는 것도 있지만, 평소에 들여다보며 약한 곳을 미리 챙기는 거죠.

다만 모니터링도 지나치면 부담이에요. 모든 걸 다 재고 다 보려 하면, 정작 중요한 게 파묻히고 관리도 무거워지거든요. 그래서 저는 정말 중요한 것 몇 가지부터 지켜보기 시작해, 필요에 따라 늘려 가요. 화려한 대시보드보다 매일 실제로 보는 소박한 지표 몇 개가 낫다고 봐요.

무엇을 지켜봐야 해요?

지켜볼 게 많지만, 저는 네 가지부터 권해요. 첫째는 얼마나 많은 요청이 오는가예요. 트래픽 양이죠. 이게 갑자기 확 늘거나 뚝 떨어지면 뭔가 벌어진 신호예요. 늘면 사람이 몰린 거고, 떨어지면 서비스가 접근이 안 되는 걸 수도 있거든요. 평소 흐름을 알아 둬야 이상한 순간을 알아채요.

둘째는 얼마나 오류가 나는가예요. 오류율이죠. 요청 중 실패하는 비율이 평소보다 높아지면 강한 경고예요. 특히 배포 직후 오류율이 치솟으면, 새 버전에 문제가 있다는 뜻이라 되돌릴 신호가 되죠. 저는 이 오류율을 가장 중요한 지표로 여겨, 늘 눈에 띄는 곳에 둬요.

셋째는 얼마나 빠른가예요. 응답 시간이죠. 오류는 안 나는데 느려지는 것도 사용자한텐 고장이거든요. 여기서 조심할 건, 평균만 보면 속는다는 거예요. 대부분 빠른데 일부가 아주 느리면 평균은 괜찮아 보여도 그 일부 사용자는 고통받죠. 그래서 저는 느린 쪽 끝도 함께 봐요. 가장 느린 사용자들이 어떤지를요.

넷째는 자원이 얼마나 남았는가예요. 서버의 계산 능력이랑 기억 공간, 저장 공간이 바닥나기 전에 알아야 하거든요. 자원이 다 차면 서비스가 느려지다 결국 멈춰요. 저는 자원이 일정 선을 넘으면 미리 알림이 오게 해, 바닥나기 전에 늘리거나 정리해요. 터진 뒤 수습하는 것보다 미리 대비하는 게 훨씬 편하니까요.

이 네 가지에 더해, 저는 서비스마다 진짜 중요한 것을 하나 더 봐요. 쇼핑몰이면 주문 수, 콘텐츠 서비스면 글 올라오는 수 같은 거요. 기술 지표는 멀쩡한데 이 사업의 핵심 숫자가 뚝 떨어지면, 겉으론 안 보이는 문제가 있는 거거든요. 기술이 아니라 사용자 행동을 보는 이 지표가, 숨은 문제를 잡아 줄 때가 많아요.

로그, 지표, 추적은 뭐가 달라요?

관측에는 흔히 세 가지 도구가 있어요. 첫째 로그는 무슨 일이 있었는지 적은 기록이에요. 언제 어떤 요청이 왔고 무슨 오류가 났는지를 글로 남기는 거죠. 문제가 났을 때 정확히 뭐가 잘못됐는지를 파헤치는 데 써요. 상세한 대신 양이 많아, 잘 찾아볼 수 있게 정리해 두는 게 중요해요.

둘째 지표는 숫자로 요약한 상태예요. 앞서 말한 오류율이나 응답 시간처럼, 시간에 따라 변하는 숫자를 재는 거죠. 로그가 낱낱의 사건이라면, 지표는 그걸 모아 그린 흐름이에요. 전체 상태를 한눈에 보고 이상한 순간을 알아채는 데 좋아요. 저는 지표로 이상을 감지하고, 로그로 원인을 파헤쳐요. 둘의 역할이 다르거든요.

셋째 추적은 요청 하나가 거쳐 간 길을 따라가는 거예요. 요청이 여러 서버랑 서비스를 거칠 때, 어디서 시간이 걸렸고 어디서 막혔는지를 이어서 보는 거죠. 특히 여러 조각으로 나뉜 서비스에서 느린 원인이 어느 조각인지를 짚을 때 유용해요. 저는 이 셋을 지표로 알아채고, 추적으로 좁히고, 로그로 확인하는 흐름으로 함께 써요.

이 셋은 서로를 보완해요. 지표만 있으면 이상한 건 아는데 왜인지 몰라 답답하고, 로그만 있으면 세세한데 전체가 안 보여 헤매거든요. 셋을 엮어 두면 이상을 빨리 알아채고 원인까지 좁혀 가요. 저는 처음엔 다 갖추기 어려우면 지표랑 로그부터 시작하라고 권해요. 이 둘만으로도 웬만한 문제는 다뤄지거든요.

중요한 건 이걸 남긴다고 끝이 아니라 볼 수 있어야 한다는 거예요. 로그를 잔뜩 쌓아 두고 찾아볼 수 없으면 없는 거나 마찬가지거든요. 저는 관측 도구를 갖출 때, 필요할 때 원하는 걸 빨리 찾을 수 있는지를 꼭 확인해요. 쌓는 것보다 꺼내 보는 게 훨씬 중요하니까요.

알림은 언제 울려야 해요?

모니터링이 지켜보는 거라면, 알림은 이상할 때 사람을 부르는 거예요. 사람이 온종일 화면을 볼 순 없으니, 정해 둔 선을 넘으면 알림이 와서 사람을 부르게 하는 거죠. 오류율이 확 오르거나, 서비스가 응답을 안 하거나, 자원이 바닥나려 할 때요. 좋은 알림은 문제를 사용자보다 먼저 사람 손에 쥐여 줘요.

알림에서 가장 중요한 원칙은 울리면 진짜여야 한다는 거예요. 별것 아닌 걸로 자꾸 울리면, 사람들이 또 헛알림이겠지 하고 무시하게 되거든요. 그러다 진짜 알림도 놓치죠. 그래서 저는 알림을 정말 사람이 지금 움직여야 할 때만 울리게 해요. 울렸으면 반드시 대응이 필요하다는 믿음이 있어야 알림이 힘을 가져요.

알림은 심각도에 따라 나눠 둬요. 당장 새벽에라도 깨워야 할 급한 것이랑, 아침에 보면 되는 덜 급한 것을 갈라야 하거든요. 다 똑같이 급하게 울리면, 정작 진짜 급한 걸 구분 못 해요. 저는 서비스가 멈춘 수준만 사람을 깨우고, 나머지는 업무 시간에 보게 나눠요. 밤잠을 지키는 것도 오래 일하는 데 중요하거든요.

알림엔 무엇을 해야 할지도 담으면 좋아요. 그냥 오류율 높음만 울리기보다, 어디를 보고 무엇부터 확인하라는 안내가 함께 오면 대응이 빨라지거든요. 저는 알림에 관련 화면 링크랑 첫 대응 안내를 붙여 둬요. 급박한 순간에 어디부터 봐야 하지를 헤매지 않게요.

알림은 받을 사람이 분명해야 해요. 모두한테 가는 알림은 아무도 안 챙기는 알림이 되기 쉽거든요. 서로 남이 보겠지 하니까요. 그래서 저는 알림마다 누가 책임지고 볼지를 정해 둬요. 지금 당번인 사람한테 또렷이 가게 해서, 내 알림이라는 주인 의식이 생기게요.

알림 피로는 어떻게 막아요?

알림 피로는 알림이 너무 자주, 별것 아닌 걸로 와서 사람이 지쳐 무시하게 되는 걸 말해요. 이건 모니터링의 가장 큰 적이에요. 알림을 무시하기 시작하면, 아무리 잘 갖춘 모니터링도 있으나 마나가 되거든요. 저는 알림 피로를 적극적으로 막아야 할 문제로 다뤄요. 그냥 두면 반드시 나빠지니까요.

첫째 방법은 헛알림을 꾸준히 줄이는 거예요. 울렸는데 아무 대응도 필요 없던 알림은, 그때그때 기준을 손봐 안 울리게 해요. 저는 헛알림이 오면 귀찮아도 그 자리에서 원인을 없애요. 방치하면 헛알림이 쌓여 진짜를 파묻거든요. 알림 하나하나가 믿을 만한지를 꾸준히 챙기는 거죠.

둘째는 비슷한 알림을 묶는 거예요. 한 문제로 알림이 수십 개 쏟아지면, 그게 곧 피로거든요. 그래서 같은 원인의 알림은 하나로 모아 보내고, 이미 아는 문제는 잠깐 조용히 시켜요. 저는 문제를 인지했으면 관련 알림을 잠재워, 대응하는 동안 딴 알림에 안 파묻히게 해요.

셋째는 사람이 아니라 조건을 보게 하는 거예요. 순간적으로 튀는 값 하나하나에 울리기보다, 일정 시간 이상 이상하면 울리게 하는 거죠. 잠깐 튀었다 돌아오는 건 대응할 필요가 없으니까요. 저는 몇 분간 계속 선을 넘을 때만 울리게 해서, 순간의 흔들림에 사람이 시달리지 않게 해요.

넷째는 알림을 정기적으로 돌아보는 거예요. 어떤 알림이 자주 울렸고 그게 쓸모 있었는지를 가끔 점검해, 쓸모없는 건 고치거나 없애요. 알림은 한번 만들고 방치하면 점점 소음이 되거든요. 저는 알림 목록을 살아 있는 것으로 여기고, 서비스가 변하면 알림도 같이 다듬어요.

모니터링을 어떻게 시작해요?

처음부터 완벽하게 갖추려 하지 마세요. 저는 가장 중요한 몇 가지부터 시작하라고 권해요. 오류율이랑 응답 시간, 이 둘만 지켜봐도 큰 사고는 대부분 잡히거든요. 여기에 서비스가 살아 있는지 확인하는 기본 알림 하나만 붙여도, 깜깜하던 방에 불이 켜져요. 작게 시작해 필요할 때 늘려 가면 돼요.

요즘은 모니터링을 쉽게 도와주는 서비스가 많아요. 코드에 몇 줄만 넣거나 설정 몇 개만 하면, 오류랑 성능을 알아서 모아 보여 주죠. 처음부터 직접 다 만들려 하기보다, 이런 기성 서비스로 시작하는 게 훨씬 빨라요. 저는 작은 팀일수록 남이 만들어 둔 걸 잘 갖다 쓰라고 권해요. 우리는 서비스를 만드는 데 집중하고요.

모니터링은 배포랑 엮어 두면 특히 좋아요. 언제 배포했는지가 지표 위에 표시되면, 지표가 이상해졌을 때 배포 때문인지를 바로 알 수 있거든요. 저는 배포 시점을 모니터링에 표시해, 배포랑 문제의 관계를 한눈에 봐요. 배포하자마자 오류가 올랐다면 범인이 뚜렷하니까요.

무엇보다 모니터링은 실제로 봐야 살아요. 잘 갖춰 두고 아무도 안 보면 소용없거든요. 저는 팀이 매일 잠깐이라도 지표를 함께 보는 습관을 들여, 평소 흐름에 익숙해지게 해요. 평소를 알아야 이상한 순간이 눈에 들어오니까요. 모니터링은 도구가 아니라 지켜보는 습관이에요.

한 가지 덧붙이면, 지표를 볼 땐 혼자 판단하지 말고 기준선을 정해 두는 게 좋아요. 오류율이 평소 얼마인지를 미리 알아 둬야, 지금 숫자가 정상인지 이상인지 가늠이 되거든요. 기준선 없이 숫자만 보면 이게 높은 건가 싶어 매번 헷갈려요. 저는 각 지표의 평소 범위를 팀이 함께 알아 두고, 그 범위를 벗어날 때 움직여요. 평소를 아는 것이 이상을 아는 것의 출발이에요.

정리하면, 모니터링은 서비스에 무슨 일이 벌어지는지 지켜보는 배포의 마지막 기둥이에요. 요청이랑 오류랑 속도랑 자원을 지켜보고, 로그랑 지표랑 추적으로 알아채고 좁히고 확인하죠. 알림은 진짜일 때만 울리게 해 피로를 막고, 작게 시작해 실제로 보는 습관을 들이면 돼요. 다음 편에서는 그럼에도 사고가 났을 때 어떻게 대응하는지를 이야기해 볼게요.