AWS 장애 대응에 반드시 필요한 역할과 기록

장애가 났을 때 손실을 키우는 것은 장애 그 자체보다 그 뒤의 몇 분입니다. 알림은 떴는데 누가 그것을 먼저 봐야 하는지 정해져 있지 않고, 확인은 했는데 어디까지 스스로 손대고 언제 넘겨야 하는지 합의된 적이 없으며, 상황이 정리된 뒤에는 무엇이 원인이었는지 기록이 남지 않는 상태. 이 상태에서는 같은 장애가 다시 와도 매번 처음부터 시작합니다.

이 글은 그 반대편에 있는 구조를 다룹니다. 사람을 24시간 붙이는 이야기가 아니라, 인원이 적어도 무너지지 않는 최소한의 뼈대를 어떻게 세우는가입니다. 그 뼈대는 세 가지입니다. 누가 무엇을 하는지 정한 역할, 무엇을 장애로 볼지 정한 감지, 그리고 나중에 되짚을 수 있게 남기는 기록입니다. 셋 중 하나라도 비어 있으면 그 자리가 다음 장애에서 가장 먼저 무너집니다.

한 가지 먼저 구분해 둘 것이 있습니다. 여기서 말하는 장애는 서비스가 느려지거나 멈추는 운영 가용성 장애입니다. 이름이 비슷한 보안 침해사고 대응은 위협 모델도 절차도 다른 별개의 영역이고, 이 글이 다루는 범위가 아닙니다. 다만 “누가 무엇을 맡을지 미리 나눈다”거나 “준비·탐지·분석·복구 단계로 절차를 나눈다” 같은 체계의 뼈대 개념은 두 영역이 공유하므로, 그 개념은 AWS의 대응 계획 수립 문서를 근거로 참고했습니다.

역할을 먼저 나눕니다

장애 대응에서 역할을 나눈다는 것은 사람을 더 뽑는 일이 아니라, 지금 있는 사람에게 장애 시점의 자리를 미리 지정해 두는 일입니다. 규모가 작은 조직에서는 한 사람이 여러 자리를 겸하는 것이 자연스럽고, 그것 자체는 문제가 아닙니다. 문제는 그 자리가 정해져 있지 않아 서로 상대가 보고 있으리라 여기며 아무도 손대지 않는 구간이 생기는 것입니다.

나눠 둘 자리는 대략 이렇게 정리됩니다.

• 먼저 확인하는 사람 — 알림이 떴을 때 그것을 처음 받아 상황을 파악하는 자리입니다. 이 자리가 비어 있으면 알림은 아무에게도 인지되지 않은 채 흘러갑니다.
• 결정하는 사람 — 대응 방향을 정하고, 서비스를 잠시 내릴지, 이전 상태로 되돌릴지 같은 판단을 내리는 자리입니다. 확인하는 사람과 겸할 수 있지만, 판단 권한이 누구에게 있는지는 분명해야 합니다.
• 실제로 손대는 사람 — 결정된 조치를 시스템에 적용하는 자리입니다. 이 자리에는 필요한 권한이 미리 부여돼 있어야 하고, 장애 순간에 권한을 찾아 헤매는 일이 없어야 합니다.
• 바깥과 소통하는 사람 — 고객·경영진·유관 부서에 상황을 전하는 자리입니다. 대응하는 사람이 소통까지 겸하면 둘 다 늦어지므로, 사람이 있다면 분리해 두는 편이 낫습니다.

이렇게 자리를 나누는 방식은 흔히 역할과 책임을 미리 배정해 두는 매트릭스로 정리됩니다. 실무·결정·통보의 책임을 각 자리에 표로 붙여 두는 것인데, 표의 형식보다 중요한 것은 빈칸이 없는가입니다. 어떤 상황에서 어떤 자리가 비어 있는지 한 번 훑어 두면, 장애 순간에 사람을 찾느라 쓰는 시간이 사라집니다.

무엇을 장애로 볼 것인가

역할을 나눠 두어도 무엇을 신호로 볼지 정해져 있지 않으면 대응이 시작되지 않습니다. 사람의 감이 아니라 지표에 선을 그어 두는 것이 감지의 출발점입니다.

정하는 순서는 대체로 이렇습니다.

• 대표 지표를 고릅니다. 응답 지연, 오류율, 자원 사용률처럼 서비스의 상태를 대신 말해 주는 값을 몇 개 정합니다. 지표가 너무 많으면 오히려 무엇을 봐야 할지 흐려집니다.
• 임계선을 긋습니다. 각 지표에 대해 어느 수준부터 사람이 봐야 하는지를 숫자로 적습니다. 이 선이 대응을 시작하는 기준이 됩니다.
• 알림 경로를 정합니다. 선을 넘으면 누구에게 어떤 방식으로 통지가 가는지를 정합니다. 앞 절에서 정한 “먼저 확인하는 사람”에게 실제로 닿아야 의미가 있습니다.

여기서 두 가지를 조심하셔야 합니다. 첫째, 임계선을 처음부터 완벽하게 그으려 하지 않는 편이 좋습니다. 실제 장애를 겪을 때마다 “이 선은 너무 늦게 울렸다” 혹은 “이건 장애가 아닌데 울렸다”를 보정해 가는 것이 현실적입니다. 둘째, 알림이 너무 자주 울리면 결국 전부 무시하게 됩니다. 모든 이상이 같은 무게로 쏟아지면 사람은 그중 무엇이 진짜인지 가리기를 포기합니다. 그래서 감지의 목표는 “많이 잡는 것”이 아니라 “봐야 할 것만 울리게 하는 것”입니다.

복구를 어디까지 되돌릴 것인가에 대한 목표도 이 단계에서 함께 정해 둡니다. 얼마나 빨리 복구할 것인지(복구 시간 목표)와 어느 시점의 데이터까지 되살릴 것인지(복구 지점 목표)는 조직이 서비스의 성격에 따라 스스로 정하는 값입니다. AWS Well-Architected 신뢰성 필라가 이 목표의 개념을 정리해 두었는데, 유의할 점은 이 값이 AWS가 보장해 주는 수치가 아니라 조직이 정하고 그에 맞춰 구성을 준비해야 하는 목표라는 것입니다. 목표가 정해져 있어야 장애 순간에 “어디까지 되돌릴 것인가”를 두고 논쟁하지 않습니다.

무엇을 기록하는가

이 글에서 가장 무게를 둔 부분입니다. 역할과 감지가 갖춰져 있어도 기록이 남지 않으면, 조직은 매번 장애를 겪기만 할 뿐 그로부터 배우지 못합니다. 기록은 대응이 끝난 뒤에 여유가 있으면 하는 일이 아니라, 대응의 한 부분으로 처음부터 남기는 것입니다.

남겨야 할 것은 네 갈래입니다.

• 타임라인 — 언제 신호가 떴고, 언제 사람이 인지했으며, 어떤 조치를 몇 시에 했는지를 시간 순으로 적습니다. 이 순서가 남아 있어야 “감지는 빨랐는데 인지가 늦었는지, 인지는 빨랐는데 조치가 늦었는지”를 나중에 구분할 수 있습니다. 어느 구간이 느렸는지 모르면 무엇을 개선해야 할지도 알 수 없습니다.
• 조치 — 실제로 무엇을 바꿨는지를 적습니다. 재시작, 되돌리기, 설정 변경 같은 행위를 남겨 두면, 그 조치가 상황을 해결했는지 아니면 다른 문제를 덮었을 뿐인지를 뒤에서 판단할 수 있습니다.
• 원인 — 표면에 보인 증상과 그 아래의 근본 원인을 구분해 적습니다. “서버가 멈췄다”는 증상이고, “특정 변경 이후 메모리가 서서히 차올랐다”는 원인에 가깝습니다. 이 둘을 뭉쳐 두면 같은 증상이 다른 원인으로 다시 왔을 때 지난 기록이 도움이 되지 않습니다.
• 후속 — 재발을 막기 위한 조치와 그 담당·기한을 붙입니다. 이 항목이 없으면 기록은 사후 감상문으로 끝나고, 같은 장애가 다시 옵니다.

이 네 갈래를 정리한 문서를 보통 포스트모템이라고 부릅니다. 형식보다 중요한 것은 이 문서가 누구의 잘못인지를 가리는 자리가 아니라는 점입니다. 책임을 묻는 문서가 되는 순간 사람들은 사실을 온전히 적지 않게 되고, 그러면 기록의 목적 자체가 사라집니다. 사실을 있는 그대로 남기고, 그 사실에서 다음 조치를 뽑아내는 것이 포스트모템이 하는 일입니다.

AWS는 감지와 기록을 어떻게 받쳐 주는가

앞의 세 가지는 조직이 정하는 것이고, AWS의 기능은 그것을 실행 가능하게 받쳐 주는 도구입니다. 도구가 역할이나 판단을 대신하지는 않는다는 전제 위에서 두 가지를 봅니다.

• 감지와 알림 — Amazon CloudWatch — 지표를 지속적으로 확인하고, 앞서 그어 둔 임계선을 넘으면 정해진 경로로 알림을 보내는 부분을 맡습니다. 경보를 만들어 통지를 보내는 방식이 문서에 정리돼 있습니다. 여기서 CloudWatch가 하는 일은 “선을 넘었음을 알리는 것”까지이고, 그 알림을 받아 판단하는 것은 사람의 몫입니다.
• 변경 이력 — AWS CloudTrail — 누가 언제 무엇을 바꿨는가를 기록으로 남기는 부분입니다. 장애 직전에 어떤 설정 변경이 있었는지를 되짚을 출발점을 제공합니다. 한 가지 구분해 둘 것은, CloudTrail이 기본으로 남기는 것은 자원을 만들고 바꾸고 지운 **제어 평면의 변경(관리 이벤트)**이고, 특정 데이터에 접근한 상세 기록(데이터 이벤트)은 별도로 켜야 남는다는 점입니다. CloudTrail 개념 문서가 이 둘을 나눠 설명합니다. “장애 직전에 무엇을 바꿨는가”를 되짚는 데 쓰이는 것은 관리 이벤트입니다.

이 두 도구는 감지와 기록을 받쳐 주지만, 자동으로 대응하는 주체가 아닙니다. 경보가 울려도 받을 사람이 없으면 알림은 쌓이기만 하고, 변경 이력이 남아 있어도 그것을 읽고 원인을 판단하는 것은 사람입니다. 도구를 켜는 것과 대응 구조를 갖추는 것은 다른 일이라는 점을, 다음 절에서 조금 더 풀어 보겠습니다.

”24시간 모니터링”은 “24시간 대응”이 아닙니다

이 두 문장을 하나로 읽는 데서 오해가 시작됩니다. 감시가 24시간이라는 말과 사람이 24시간 대기한다는 말은 서로 다른 층을 가리킵니다.

층을 나눠 보면 이렇습니다.

• 감시 — 기계가 지표를 계속 확인합니다. 시간 제약이 없습니다.
• 알림 — 임계선을 넘으면 정해진 경로로 통지가 나갑니다. 역시 시간 제약이 없습니다.
• 분석과 조치 — 사람이 알림을 받아 원인을 판단하고 손을 댑니다. 여기에는 그 알림을 받을 사람이 있어야 한다는 조건이 붙습니다.

앞의 두 층은 자동화할 수 있지만 세 번째 층은 사람의 시간입니다. 그래서 “24/7 모니터링을 켜 두었다”는 문장은 사실이면서 동시에 야간의 즉시 조치를 전혀 뜻하지 않을 수 있습니다. 거짓이 아니라 다른 층을 말하고 있는 것입니다.

여기서 조직이 정해야 할 것은 분명합니다. 야간이나 주말에 사람의 즉시 대응이 필요한 환경인가를 먼저 판단하고, 필요하다면 그것을 감시를 켜는 것과 별개의 항목으로 설계하는 것입니다. 필요하지 않은 환경이라면 감시와 알림을 켜 두되 “다음 근무 시간에 확인한다”는 규칙을 정해 두는 것으로 충분할 수 있습니다. 어느 쪽이든 알림을 받을 사람과 그 사람이 할 일을 정하지 않은 채 감시만 켜 두는 것이 가장 흔한 실패입니다.

인력이 적은 조직은 무엇부터 세우는가

사람을 24시간 붙일 수 없는 조직이라도 세울 수 있는 최소 구조가 있습니다. 순서는 앞에서 다룬 세 가지 그대로입니다.

1. 역할부터 정합니다. 한 사람이 여러 자리를 겸하더라도, 장애가 났을 때 누가 먼저 보고 누가 결정하는지를 문장으로 적어 둡니다. 이것은 비용이 들지 않고 가장 먼저 효과가 납니다.
2. 감지를 겁니다. 대표 지표 몇 개에 임계선을 긋고, 그 알림이 실제로 사람에게 닿는지 한 번 시험해 봅니다. 알림이 도착하지 않는 감시는 없는 것과 같습니다.
3. 기록의 틀을 만들어 둡니다. 장애가 났을 때 채울 타임라인·조치·원인·후속의 빈 양식을 미리 만들어 두면, 대응하는 사람이 무엇을 남겨야 할지 고민하지 않아도 됩니다.

이 최소 구조의 목표는 완벽한 대응이 아니라 무너지지 않는 대응입니다. 인원이 적어도 세 가지가 갖춰져 있으면 장애를 겪을 때마다 조금씩 나아지고, 세 가지가 없으면 사람을 더 붙여도 매번 같은 자리에서 헤맵니다. 대응 자체를 밖에 맡기는 방식을 검토 중이시라면, 무엇이 포함되고 무엇이 별도인지를 운영을 맡긴다는 것의 범위에서 먼저 확인해 보시는 편이 순서에 맞습니다.

대응이 끝난 뒤, 재발을 막기

장애가 진정되면 대응은 끝난 것처럼 느껴지지만, 배우는 일은 그 뒤에 시작됩니다. 앞에서 남긴 포스트모템을 다음 행동으로 잇는 절차가 없으면 기록은 서랍에 들어가고, 같은 원인이 다시 옵니다.

이 절차는 거창할 필요가 없습니다. 포스트모템의 후속 조치 항목을 실제 할 일 목록으로 옮기고, 각각에 담당과 기한을 붙이는 것이면 됩니다. 중요한 것은 이 조치가 “언젠가 하면 좋은 일”이 아니라 기한이 있는 일이 되는 것입니다. 기한 없는 재발 방지책은 대개 실행되지 않습니다.

한 가지 덧붙이면, 재발 방지 조치를 정할 때 표면 증상만 없애는 데 그치지 않도록 주의하셔야 합니다. 서버를 재시작해 상황이 풀렸다면 그것은 증상을 없앤 것이고, 왜 그 서버가 그렇게 됐는지를 규명해 손대는 것이 근본 조치입니다. 앞 절에서 원인을 증상과 구분해 기록해 둔 이유가 여기서 드러납니다.

어디서부터는 외부와 함께 봅니다

조직 안의 역할·감지·기록으로 대부분의 대응은 무너지지 않게 됩니다. 다만 원인이 한 계층에 머무르지 않고 여러 계층을 넘나들 때는 내부의 힘만으로 규명이 어려워집니다. 애플리케이션이 느린데 그 원인이 코드에 있는지 인프라 구성에 있는지 데이터베이스에 있는지가 갈리지 않는 상황이 대표적입니다.

이런 경우에는 같은 장애가 반복되기 전에 원인을 한 번 제대로 규명해 두는 편이 낫습니다. 빌드업웍스의 AWS 장애·안정화 — 원인 규명은 24시간 출동을 파는 서비스가 아니라, 반복되는 장애의 원인을 계층을 넘나들며 짚어 그 결과를 기록으로 남기는 방식입니다. 앞에서 강조한 기록이 있어야 이 규명이 가능하다는 점에서, 내부 구조와 외부 규명은 서로 맞물려 있습니다.

다음 단계

지금 우리 조직의 대응 구조에서 역할·감지·기록 중 무엇이 비어 있는지부터 확인하시는 것이 순서상 먼저입니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 지금 어디가 비어 있는지를 정리해 드립니다. 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

반복되는 장애의 원인을 한 번 규명해 두어야 하는 단계라면 AWS 장애·안정화 — 원인 규명에서 그 방식이 무엇을 다루고 무엇을 다루지 않는지 확인해 보십시오. 지표·알림·변경 이력이 한 화면에서 어떻게 보이는지 먼저 눌러 보고 싶으시면 아래 데모를 열어 보시고, 우리 환경에 맞는 구조가 궁금하시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS Well-Architected 신뢰성 필라 — 재해 복구 목표(RTO/RPO)
• Amazon CloudWatch — 이메일을 보내는 경보 만들기
• AWS CloudTrail 개념 — 관리 이벤트와 데이터 이벤트
• AWS Security Incident Response — 대응 계획 수립과 테스트
• AWS Security Incident Response Guide (백서)