연필로 그려 넣은 장애 예측 달력: 대시보드가 눈치채기 전에 내일의 장애를 스케치하기

월요일 아침, SRE 워룸에 들어갔더니 벽에 아주 단순한 종이 달력이 걸려 있다고 상상해 보세요. 날짜마다 손으로 그린 아이콘이 적혀 있습니다. 목요일에는 번개 표시, 토요일에는 슬픈 표정의 라우터, 한 달 중간쯤에는 느낌표가 잔뜩 모여 있습니다.

그 아래에는 이런 문장이 적혀 있습니다. “전력망 불안정 예상. 네트워크 브라운아웃 가능성 있음. 지금 완화 전략을 준비할 것.”

너무 저기술(low‑tech) 같아서 정말 쓸모가 있을까 싶지만, 이 달력은 꽤 높은 확률로 맞아떨어집니다. 그 덕분에 온콜 로테이션은 한결 평온해지고, 장애는 더 작아지며, 대시보드는 대부분 당신이 이미 예상하고 있던 일을 확인해 줄 뿐입니다.

이게 바로 **장애 예측(failure forecasting)**의 정신입니다. 즉, 대시보드가 알기 전에 내일의 장애를 미리 그려보는 것이죠.

이 글에서는 SRE 팀이 **AI, 기존 자동화 도구, 신뢰성 공학( reliability engineering)**을 어떻게 결합해 장애를 사전에 예측하고, 그 영향이 커지기 전에 시스템과 프로세스를 어떻게 다듬을 수 있는지 살펴보겠습니다.

반응형 대시보드에서 선제적 ‘장애 예측 달력’으로

대부분의 SRE 팀은 반응형(reactive) 세계에서 일합니다.

메트릭이 이미 나빠진 뒤에야 대시보드에 신호가 나타나고,
임계값이 넘어가야 알람이 울리며,
사용자가 고통을 느껴야 장애가 선언됩니다.

대시보드는 필수적이지만, 본질적으로 현재와 과거를 말해 줄 뿐입니다. 대시보드는 이렇게 말해주지 않습니다. “목요일 오후: X 리전에 연쇄 장애(cascading failure) 발생 위험이 높음.”

**장애 예측 달력(failure forecast calendar)**은 이와 정반대에서 출발합니다. 이런 질문을 던지죠.

오늘 우리가 알고 있는 것—시스템, 환경, 과거 이력에 대한 모든 정보를 바탕으로—내일 가장 가능성이 높은 장애는 무엇이며, 얼마나 심각할 것인가?

요즘 SRE들은 이 질문에 점점 더 정교하게 답할 수 있는 도구를 갖고 있습니다. 바로 AI, 자동화, 신뢰성 모델링이 만나는 지점입니다.

왜 SRE 팀은 지금 AI와 자동화를 통합해야 하는가

신뢰성 워크플로에 AI를 넣는 일은 더 이상 실험적인 R&D가 아니라, 빠르게 경쟁 우위의 필수 조건이 되어가고 있습니다. 시스템은 더 복잡해졌고, 의존성은 더 불투명하며, 장애 패턴은 외부 요인과 더 깊게 얽혀 있습니다.

지금 시작해야 하는 이유는 명확합니다.

데이터는 숙성 시간이 필요합니다. 모델은 과거 데이터, 반복, 피드백 루프를 통해 개선됩니다. 시작이 빠를수록 더 많은 신호를 쌓을 수 있습니다.
워크플로도 변해야 합니다. 반응형 운영에서 예측 기반 SRE로 전환하려면 문화와 프로세스 변화가 필요합니다. 하루아침에 바뀌지 않습니다.
툴체인은 이미 AI를 받아들일 준비가 되어 있습니다. 기존 플랫폼들은 ML과 예측 기능을 계속 추가하고 있습니다. 현재 사용 중인 도구에 이런 기능을 얹는 건 생각보다 마찰이 적습니다.

목표는 ML로 SRE를 대체하는 것이 아니라, **SRE를 증강(augment)**하는 것입니다.

AI는 잠재적인 장애를 *“지금 불이 난 문제”*가 아니라 *“내일의 문제”*로 표면 위로 끌어 올려 줍니다.
자동화는 반복적인 완화 작업을 실행하고, 사람은 예외 케이스, 설계, 개선에 집중하게 합니다.

이렇게 해서 “모든 것이 불타고 있다” 상태에서 “이건 이미 알고 있었고, 지난주에 방화선을 쳐 놨다” 상태로 옮겨갈 수 있습니다.

지금 가진 것부터 활용하기: Ansible, Terraform, PagerDuty 그리고 친구들

선제적 신뢰성(proactive reliability)을 시작하는 데, 새로운 플랫폼이나 연구소 같은 환경이 필요한 건 아닙니다. 많은 팀이 이미 **기본 블록(building blocks)**을 갖고 있습니다.

Ansible – 설정 변경, 패치, 복구 플레이북을 자동화
Terraform – 인프라를 코드로 정의해, 재현/확장/이동을 예측 가능하게 수행
PagerDuty(또는 유사한 인시던트 도구) – 알림, 런북, 사후 분석(postmortem)을 중앙 집중화

이 도구들은 **예측 기반 SRE 루프(forecast‑driven SRE loop)**로 들어가는 현실적인 입구입니다.

패턴 탐지 – 기존 모니터링 데이터를 사용해 패턴을 찾습니다. 예: 특정 날씨 조건이나 이벤트 동안 CPU가 반복적으로 치솟는 패턴 등.
발생 가능성 모델링 – 기본적인 통계나 ML 도구로 발생 가능성을 모델링합니다. (단순 회귀나 분류 모델만으로도 꽤 유용할 수 있습니다.)
완화 조치 자동화 – 다음과 같이 코드로 옮깁니다.
- Ansible 플레이북: “위험 점수(risk score) > X면, 노드 N개를 미리 워밍(pre‑warm)한다.”
- Terraform 모듈: “리전 A의 위험 점수가 높으면, 리전 B에 로드를 옮기거나 용량을 늘린다.”
- PagerDuty 룰: “모델이 Y 이상의 확률로 장애를 예측하면, 특정 런북이 딸린 ‘사전 인시던트(pre‑incident)’를 자동으로 연다.”

시간이 지나면서 자동화는 현재 알람에 반응하는 것에서, 예측된 시나리오를 기준으로 실행하는 것으로 무게 중심을 옮기게 됩니다.

일일 장애를 예측하기: 전력망(Electrical Grid) 사례

장애 예측은 추상적으로 들리기 쉽지만, 전력 시스템 같은 도메인에 대입해 보면 훨씬 명확해집니다.

예를 들어 **전력망(electrical grid)**을 생각해 봅시다.

기온이 높아지면 냉방 수요가 폭증해 변압기(Transformer)에 부담을 줍니다.
폭풍은 송전선을 끊고, 국지적 정전을 만들어 냅니다.
많은 눈이나 얼음은 물리 인프라에 직접적인 피해를 줍니다.

전력 회사들은 외부 요인, 특히 날씨를 모델링해 일일 장애 발생 건수를 상당히 정확하게 예측할 수 있다는 것을 배웠습니다. 예를 들면 다음과 같습니다.

날씨 예보를 가져옵니다. (기온, 풍속, 습도, 강수량, 낙뢰 가능성 등)
과거 정전(outage) 데이터와 그리드 토폴로지(망 구조)를 결합합니다.
모델을 학습시켜 “이 날씨 예보라면, R 리전에서 내일 N건의 장애가 발생할 가능성이 높다”는 식으로 예측하게 합니다.

SRE 팀도 같은 패턴을 재현할 수 있습니다.

시스템에 영향을 주는 외부 요인을 식별합니다. (예: 지역 전력 안정성, 인터넷 백본 혼잡, 대형 이벤트, 계절별 트래픽, 규제 작업 창구 등)
이런 요인을 과거 인시던트 및 알람 데이터와 함께 모델에 넣습니다.
리전/도메인/서비스 단위로 **일일 인시던트 위험 예측(daily incident risk forecast)**을 생성합니다.

출력은 다음처럼 단순할 수 있습니다.

“US‑East: 향후 48시간 내 용량 관련 인시던트 발생 확률 70%.”
“APAC: 예상 트래픽 증가로 인한 레이턴시 SLO 위반 위험 증가.”

이게 바로 연필로 그린 달력이지만, 이제는 데이터로 구동되는 버전입니다.

컨텍스트가 핵심: 리전별 데이터와 로컬 현실

예측은 **문맥(context)**만큼만 정확해집니다. 리전별 데이터는 예측 정확도를 극적으로 높여 줍니다.

전력망을 예로 들면:

기후 특성이 다릅니다. (열대/온대/건조 등)
인프라의 연식과 품질이 다릅니다.
도시 밀도와 수요 패턴이 다릅니다.

디지털 인프라도 같은 관점으로 생각할 수 있습니다.

지역 기후와 전력 인프라: 고온 + 취약한 전력망이 있는 리전의 클라우드 리전은, 온화하고 안정적인 리전과 스트레스 상황에서 전혀 다르게 동작합니다.
네트워크 토폴로지: 피어링 구조, 해저 케이블, 지역 ISP마다 고유한 리스크를 갖고 있습니다.
사용자 행동 패턴: 공휴일, 문화 행사, 업무 패턴이 리전별로 트래픽에 다른 영향을 줍니다.

모델이 어디에 무엇이 있는지, 그 장소가 어떤 특성을 갖는지를 명시적으로 반영할수록, 장애 예측은 더 날카로워지고, 사전 예방 조치는 더 정확히 목표를 겨냥하게 됩니다.

하드웨어·통신 분야의 신뢰성 예측: 무엇을 기반으로 설계할 것인가

SRE 바깥 세계를 보면, 특히 통신과 전자 분야에서 신뢰성 예측은 이미 핵심 전문 분야입니다.

라우터, 기지국, 중요 부품을 선택할 때 엔지니어들은 다음을 살펴봅니다.

MTBF/MTTF (Mean Time Between/To Failure, 평균 고장 간격/평균 고장 시간)
환경 등급(Environmental ratings) – 허용 온도, 습도, 진동 내구성 등
비슷한 배포 환경에서의 현장 고장 데이터(field failure data)

이것들은 단순한 구매 체크리스트가 아니라, **시스템 차원의 신뢰성 모델(system‑level reliability model)**의 입력값입니다.

이 무선 장비가 해안가, 염분 많은 환경의 타워 위에서 다섯 번의 여름을 버틸 수 있을까?
이 스토리지 하드웨어가 이 데이터센터의 고도와 온도 조건에서 허용 가능한 에러율을 유지할 수 있을까?

SRE도 이런 사고방식을 차용할 수 있습니다.

하드웨어와 핵심 서드파티 컴포넌트를 고정된 블랙박스가 아니라, 고장 분포를 가진 확률 변수로 취급합니다.
벤더 데이터, 현장 인시던트 히스토리, 환경 요인을 사용해 고장률을 예측합니다.
이 예측을 용량 계획, 예비 부품 전략, 배포 선택에 녹여 넣습니다.

실제 환경에서 더 높은 예측 신뢰성을 가지는 부품을 선택하는 것만으로도, 반복해서 발생하는 장애 유형 전체를 미리 없앨 수 있습니다.

설계 라이프사이클에 신뢰성 예측을 녹여 넣기

장애 예측이 가장 강력해지는 시점은 설계 라이프사이클 초반입니다.

지금까지는 보통 이렇게 진행됩니다.

설계 → 구축 → 배포 → 장애 관찰 → 패치 & 우회

지향해야 할 방향은 이렇습니다.

설계 → 신뢰성과 장애 모드 모델링 → 아키텍처/컴포넌트 선택 → 더 탄탄한 시스템 배포

실제로 연결할 수 있는 지점들은 다음과 같습니다.

아키텍처 리뷰 시 이런 질문을 던집니다. “예측 모델은 뭐라고 말하나?”
- 트래픽을 두 배로 늘리면, 어떤 컴포넌트의 고장 확률이 임계치를 넘어서는가?
- 이 서비스를 다른 리전에 옮기면, 1년 기준 장애 위험은 어떻게 바뀌는가?
장비/벤더 선정 시:
- 스펙/비용뿐 아니라 실제 배포 환경에서의 장기 신뢰성 모델을 기준으로 공급자를 비교합니다.
용량 및 DR(Disaster Recovery) 계획 시:
- 예측 모델을 사용해 시나리오를 테스트합니다. 예: “5일간의 폭염 + 전력 불안정이 겹치면 무슨 일이 벌어지는가?”

신뢰성 모델링이 설계 단계에 일찍 등장할수록, 운영 환경에서의 ‘뜻밖의 장애’는 줄어들고, 인시던트 달력은 혼돈스럽게 반응하는 대신, 지루할 만큼 정확한 모습에 가까워집니다.

예측은 대시보드를 대체하지 않고, 보완한다

대시보드와 장애 예측은 서로 다른 역할을 수행합니다.

대시보드: 지금 무슨 일이 벌어지고 있는가? SLO 대비 현재 상태는? 블라스트 레디우스(blast radius, 영향 범위)는 어디까지인가?
예측(포캐스트): 내일이나 다음 주에 무엇이 벌어질 가능성이 높은가? 어떤 완화 조치를 미리 스케줄해야 하는가? 다음 분기 동안 어디가 가장 취약한가?

둘을 함께 쓰면 새로운 운영 모드를 만들 수 있습니다.

**예측 계층(forecasting layer)**이 고위험 구간을 플래그합니다.
자동화 계층(automation layer)(Ansible, Terraform, CI/CD, 런북)이 시스템을 준비합니다. 스케일 아웃, 로드 쉬프트, 패치, 하드닝 등을 수행하지요.
**모니터링 계층(monitoring layer)**이 실제 상황을 확인하며, 예측과의 차이를 잡아냅니다.
SRE 팀은 이 차이를 해석하고, 모델을 개선하며, 예측과 완화 전략 모두를 반복적으로 다듬습니다.

목표는 완벽한 예측이 아니라, 의미 있고 행동 가능한 선견지명을 갖는 것입니다.

고임팩트 인시던트의 20–30%만이라도, 충분히 일찍 정확히 예측해 선제적으로 대응할 수 있다면, 다운타임, 스트레스, 인적 소모는 엄청나게 줄어듭니다.

어디서부터 시작할까: 현실적인 스타팅 체크리스트

자신만의 “연필로 그린 장애 예측 달력”을 만들기 위해 처음부터 모든 것을 바꿀 필요는 없습니다. 작게 시작하세요.

인시던트 유형 하나를 선택합니다. (예: 용량 포화, 전력 관련 장애, 계절성 트래픽 스파이크 등)
관련 외부 데이터를 수집합니다. (날씨, 이벤트 캘린더, 클라우드/ISP 상태 이력, 트래픽 계절성 등)
간단한 모델을 만듭니다. 기초적인 상관 분석이나 규칙 기반 위험 점수(rule‑based risk score)만으로도 충분히 시작할 수 있습니다.
자동화에 연결합니다.
- 고위험일에 실행할 사전 런북 하나.
- 위험 임계값을 기준으로 트리거되는 Ansible 플레이북 또는 Terraform 플랜 하나.
피드백 루프를 닫습니다.
- 예측 vs 실제 인시던트를 비교합니다.
- 임계값을 조정하고, 피처를 개선합니다.

시간이 지나면서, 더 많은 인시던트 유형, 더 많은 리전, 더 정교한 ML 모델로 범위를 넓혀갈 수 있습니다.

결론: 내일의 인시던트를, 그들이 먼저 그려지기 전에 우리가 먼저 그리기

벽에 걸린 연필 스케치 달력은 향수 어린 이미지가 아니라, **“지금을 더 잘 보는 것보다, 조금이라도 앞을 내다보는 것이 더 가치 있다”**는 사실을 상기시켜 줍니다.

AI 기반 예측, 검증된 자동화 도구, 설계 단계의 신뢰성 모델링을 받아들인 SRE 팀은 다음과 같은 변화를 경험하게 됩니다.

뜻밖의 장애가 줄어듭니다.
장비와 아키텍처를 더 현명하게 선택합니다.
소방 활동(Firefighting)에서 엔지니어링으로 무게 중심을 옮깁니다.

대시보드는 언제나 중요할 것입니다. 하지만 무언가가 망가졌다는 사실을 가장 먼저 알려주는 도구가 되어서는 안 됩니다.

내일의 인시던트를 오늘부터 스케치하기 시작하세요. 그리고 시스템이, 전혀 예상치 못한 소식을 들려주는 대신, 당신이 이미 알고 있던 것을 조용히 확인해 주도록 만드십시오.