AWS에서 서비스를 운영하고 있다면, 장애를 뒤늦게 알아차리는 순간이 한두 번쯤 찾아옵니다. 그런 경험이 쌓이면 자연스럽게 관제 체계를 검토하게 되고, '사람을 더 둬야 하나' 하는 고민도 시작되죠. 그런데 견적서를 받아 드는 순간까지도, 우리에게 실제로 필요한 범위가 어디까지인지는 좀처럼 선명해지지 않습니다.

범위를 정하려면 먼저 짚어야 할 질문이 있습니다. 

장애 대응은 왜 늦어질까요?

관제 인력이 없어서가 아닙니다. 이상 징후가 담당자에게 닿는 '경로'가 설계되어 있지 않기 때문입니다.

실제로 현장에서 만나는 조직 대부분은 이미 CloudWatch에 알람을 걸어두고, 대시보드도 늘 열어두고 있습니다. 그런데도 장애 소식은 고객 문의로 먼저 들어오곤 하죠.

문제는 이 공백을 '사람'으로 메우려 할 때 생깁니다. 관제 도입을 알아보면 받게 되는 견적은 대개 24시간 상주 인력이 기준입니다. 회사 규모에 비해 부담스러운 금액이다 보니 검토는 원점으로 돌아가곤 하죠. 그러다 몇 달 뒤 다음 장애가 터지고 나서야 같은 논의가 다시 시작됩니다.

해법이 '사람을 더 두는 것'만 있는 건 아닙니다. 24시간 상주 관제와 아무 대응도 하지 않는 것 사이에는, 감지와 통보만 떼어내 자동화하는 방법이 있습니다. 파이브클라우드는 이 방법을 표준 상품 '알림팩'으로 정리했습니다. 이상 징후가 감지되면 심각도에 따라 Slack으로, 긴급한 경우 전화로까지 담당자에게 곧바로 알려주는 구성이죠. 사람이 상주하지는 않지만, 앞서 말한 '담당자에게 닿는 경로'를 만들어주는 경량 관제에 가깝습니다.

관제 고민이 좀처럼 풀리지 않는 이유

알람은 켜져 있지만, 새벽에는 볼 사람이 없습니다

문제는 알람이 어디로 가느냐입니다. 이메일함이나 일반 업무 채널로 흘러가면, 근무 시간이 끝난 뒤에는 아무도 열어보지 않습니다. 새벽 3시에 난 장애를 다음 날 출근해서야 알게 되는 이유죠.

중요한 알람이 정보성 알람에 묻힙니다

임계치를 기본값으로 두면 하루에도 수십 건의 알람이 쏟아지는데, 대부분은 당장 조치할 필요가 없는 신호입니다. 이런 알람이 며칠만 쌓여도 사람들은 채널을 열지 않게 되고, 정말 중요한 알람도 그 사이에 묻혀버립니다.

견적은 상주 인력을 전제로 나옵니다

이런 공백을 메우려고 관제를 문의하면, 24시간 3교대 엔지니어 배치를 기준으로 한 금액이 나옵니다. 대규모 트래픽을 다루는 조직이라면 타당한 구조입니다. 하지만 EC2 수십 대와 RDS 몇 대를 운영하는 조직에는 과한 설계죠. 결국 부담스러운 금액에 검토는 원점으로 돌아가고, 몇 달 뒤 다음 장애가 터지고 나서야 같은 논의가 다시 시작됩니다.

세 가지 문제의 뿌리는 같습니다. 무엇을 감시할지, 심각도를 어떻게 나눌지, 각 알람을 누구에게 어떤 채널로 보낼지가 설계되어 있지 않다는 점이죠.

필요한 건 상주 인력이 아니라 전달 체계

관제 업무는 크게 세 단계로 나뉩니다. 이상 징후를 감지하고, 심각도를 판단해 전달하고, 실제로 조치하는 단계죠. 이 중 앞의 두 단계는 사람이 상주하지 않아도 표준화할 수 있습니다. 인지 지연은 두 번째 단계에서 생기고, 비용이 크게 드는 건 세 번째 단계입니다.

전달 체계를 나누는 기준은 우편함과 화재경보기를 떠올리면 쉽습니다. 우편함은 하루 한 번만 확인해도 되지만, 화재경보는 자는 사람도 깨워야 하죠. 알람도 이 원칙대로 나눕니다.

• Critical: 서비스에 즉시 영향을 주는 이상. Slack 알림과 전화가 동시에 나갑니다.
• Normal: 추이를 지켜봐야 하는 신호. 일반 채널에 쌓아두고 근무 시간에 확인합니다.

이렇게만 나눠도 야간 장애를 알아차리는 시점이 몇 시간 단위로 앞당겨집니다. 전화까지 가는 알람을 의도적으로 좁히니, 앞서 말한 알람 피로도 함께 줄어들고요.

파이브클라우드는 클라우드 도입과 운영 단계에 맞춰 세 가지 상품을 제공합니다. 환경 분석과 인프라 설계·구축을 맡는 구축팩, 실시간 감지와 통보를 맡는 알림팩, 전담 기술지원까지 포함하는 운영팩입니다. 이 중 대부분의 조직에 가장 먼저 필요한 건 알림팩입니다.

알림팩이 '표준 상품'이라는 건 온보딩이 가볍다는 뜻이기도 합니다. 감시 항목 정의부터 SNS 연동, 전용 Slack 채널 개설, 알람 설정과 테스트까지 절차가 정해져 있어 2시간 안에 세팅이 끝납니다. 내부에서 같은 작업을 처음부터 설계하는 것과 비교하면 차이가 크죠.

[참고] 관제를 어디까지 맡길지, MSP라는 개념부터 정리해두고 싶다면?
👉 클라우드 MSP, 정확히 무엇인가요? 역할부터 비용까지를 함께 보세요!

도입 전에 확인해야 할 세 가지 기준

알림 체계를 검토한다면, 견적을 받기 전에 아래 세 가지부터 내부에서 정리해 두세요. 필요한 범위가 훨씬 빨리 좁혀집니다.

감시할 리소스가 몇 개인가

EC2, RDS, ELB, EKS 노드까지 포함해 실제로 상태를 봐야 하는 리소스를 세어봅니다. 이 숫자가 알림팩 티어를 정하는 기준입니다. 모르는 채로 견적을 요청하면 과한 구성으로 이어지기 쉽습니다.

월 몇 건의 기술지원이 필요한가

지난 3개월간 외부 도움이 필요했던 이슈를 세어봅니다. 분기에 한두 건이라면 브론즈로 충분하고, 매주 문의가 생긴다면 골드 이상이나 운영팩을 검토하는 게 합리적입니다. 기술지원 횟수는 매월 갱신되어, 필요에 따라 조정할 수 있습니다.

새벽에 전화를 받을 사람이 정해져 있는가

가장 자주 빠지는 항목입니다. Critical 알람이 전화로 울렸을 때 받을 담당자와 순번이 정해져 있지 않으면, 통보 체계를 갖춰도 대응은 늦어집니다. 알람 설계보다 수신자 목록이 먼저인 이유죠.

[참고] 실제로 구축부터 운영 지원까지 파이브클라우드의 AWS MSP를 도입한 사례가 궁금하다면? 
👉 AWS 구축부터 운영지원까지! MSP 서비스를 함께 보세요!

새벽에 EC2가 멈추면, 지금 누구의 휴대폰이 울리나요?

알람 채널에는 읽지 않은 메시지가 몇 건이나 쌓여 있나요?

두 질문에 바로 답하기 어렵다면, 견적보다 알람 구조 점검이 먼저입니다. 다만 이 설계를 내부에서 처음부터 잡으려면 생각보다 손이 많이 갑니다.

파이브클라우드 알림팩은 정해진 온보딩 절차로 이 과정을 대신하고, 월 5만 원부터 시작할 수 있습니다. 감지와 통보만 맡기는 구성이라 상주 관제와는 비용의 자릿수가 다르죠. 상주 관제는 아직 이르다고 판단했던 조직도 부담 없이 시작할 수 있는 이유입니다. 구축이나 전담 기술지원이 필요하다면 구축팩·운영팩과 함께 구성할 수도 있습니다.