소개: 장애가 열차 시각표가 되는 순간

평일 오전 8시 45분, 운영실에 들어간다고 상상해 보자. 화이트보드는 사라졌다. 그 자리에 **카드보드로 만든 ‘스토리 열차 시각표 벽’**이 걸려 있다. 열(column)은 서비스와 도구, 행(row)은 하루의 분(minute), 그리고 수십 장의 포스트잇—각각이 하나의 경보다.

각 경보는 하나의 “열차”다. 발차 시간(경보가 발생한 시각), 선로(해당 서비스), 그리고 종착역(온콜 엔지니어의 정신력)이 있다. 오전 9시 부분 장애처럼 피크 시간대가 되면 시각표는 곧바로 혼돈으로 폭발한다. 여러 도구가 같은 근본 원인에 대해 각각 자기만의 경보를 쏟아낸다. 카드보드 벽은 너무 빨리 꽉 차서, 어느 순간부터는 패턴이 전혀 보이지 않는다.

이것이 바로 수동 스케줄링 실패 리듬의 모습이다. 사람 손으로 경보를 하나하나 포스트잇으로 붙이며 묶고, 중복 제거하고, 의미를 해석하려 애쓰는 것. 그리고 이 방식은—예상 가능하게도—가장 필요한 그 순간에 가장 크게 실패한다.

이 글에서는 카드보드로 만든 장애 스토리 열차 시각표 벽이라는 비유를 통해, 경보를 어떻게 묶고(grouping), 노이즈를 중복 제거하고(deduplication), 임계값을 어떻게 튜닝할 것인지를, 실제 피크 타임에 실패 리듬이 서로 충돌하기 훨씬 이전에 준비해야 하는 이유를 풀어본다.

카드보드 벽 문제: 따로인 것처럼 보이는 경보, 실제로는 하나의 Incident

카드보드 벽에서 각 경보는 제각각의 이벤트처럼 보인다.

• payment-api CPU 사용률 급상승
• mobile-gateway 오류율 급등
• orders-service 지연 시간 증가
• 세 개의 모니터링 도구에서 동시에 실패한 synthetic 체크

몇 번의 장애만 겪어본 사람이라면, 이게 하나의 근본 문제에서 나온 증상일 수 있다는 걸 금세 눈치챈다. 예를 들면 데이터베이스 과부하, 잘못된 배포, 혹은 상위(업스트림) 공급자 이슈 같은 것들이다.

하지만 카드보드 벽은 그걸 모른다. 벽이 아는 건 시간과 서비스 이름뿐이다.

자동화된 시스템에서도, 이 카드보드 벽의 순진한 버전은 모든 경보를 별개의 문제로 취급하는 경보 파이프라인이다. 같은 근본 이슈에 대해 계속해서 페이지를 울리고, 티켓을 여러 개 열고, incident 채널을 스팸으로 도배한다.

해결의 출발점은 지능적인 그룹핑과 클러스터링이다.

1. 공통 근본 원인, 영향받는 서비스, 시간 패턴으로 묶기

“경보 1개 = Incident 1개”라고 생각하는 대신, 클러스터 관점으로 봐야 한다.

잘 설계된 incident 플랫폼은 다음 기준으로 경보를 묶는다.

• 공유된 근본 원인 신호

  • 동일한 하위 의존성 (예: 동일한 DB 클러스터나 리전을 참조하는 모든 경보)
  • 유사하거나 동일한 에러 시그니처·예외 메시지
  • 동일한 배포, 기능 플래그, 설정 변경과 연관

• 겹치는 영향 서비스 집합

  • 강하게 결합되어 있거나 동일한 요청 경로에 있는 마이크로서비스 집합
  • 동일 비즈니스 기능(예: 모두 ‘결제/체크아웃’ 플로우와 관련된 서비스)

• 시간적 근접성과 패턴

  • 짧은 시간 창 안에서 동시에 터지는 경보들
  • 일정한 순서(예: 업스트림 타임아웃 → 큐 적체 → 고객 노출 오류)

실제 구현에서는 이렇게 관련 경보들을 하나의 Incident로 클러스터링한다. 카드보드 벽에는 20장의 포스트잇으로 보이던 것이, 논리적으로는 하나의 “열차 노선”—많은 신호가 달린 하나의 Incident—가 된다.

그 결과:

• Incident 티켓과 페이지 수가 줄어든다.
• 관련된 모든 컨텍스트가 한 곳에 모여 트리아지가 빨라진다.
• 조각난 노이즈가 아니라, 무슨 일이 벌어지는지에 대한 하나의 서사가 생긴다.

짧은 시간에 쏟아지는 여러 경보: 20개가 아니라 열차 1대

카드보드 벽을 보다 보면 금세 하나의 패턴을 발견한다. 무언가 진짜로 깨질 때, 경보는 한 개만 뜨지 않는다.

트래픽 스파이크나 부분 장애가 나면 보통 이렇게 이어진다.

• 기준선 임계값 초과 경보
• synthetic 체크 실패
• 오류율 경보
• 지연 시간(latency) 경보
• 커스텀 비즈니스 메트릭 경보

이 모든 게 같은 서비스에 대해 60초 안에 연달아 터질 수 있다.

시스템 관점에서는 이것이 하나의 Incident일 가능성이 압도적으로 크다. 이를 여전히 각각의 독립된 경보로 취급하는 것은, 온콜 엔지니어를 과부하시키고 이미 스트레스가 큰 Incident를 인지적 총격전으로 바꾸는 지름길이다.

경보 설계에서 기억할 만한 좋은 경험칙은 이렇다.

같은 서비스에 대해 짧은 시간 창 안에서 발생하는 여러 경보는 보통 하나의 Incident이며, 그렇게 다뤄야 한다.

툴링 관점에서 이는 다음을 의미한다.

• 시간 기반 상관(correlation) 윈도우를 설정한다. (예: 동일 서비스/의존성에 대한 경보를 5–10분 내에 발생한 것은 하나로 묶기)
• 이를 하나의 활성 Incident 객체로 모으고, 그 안에 여러 기여 경보를 첨부한다.
• 페이지는 Incident 단위로만 보내고, 그 Incident에 붙는 개별 경보에는 별도 페이지를 보내지 않는다.

이렇게 해야 카드보드 벽의 핵심 실패—“양(量)을 중요도와 혼동하는 것”—을 없앨 수 있다.

중복 제거(Deduplication): 새로운 열차인가, 메아리인가

이미 오전 09:02에 payments-db 장애에 대해 커다란 빨간 포스트잇을 카드보드 벽에 붙여 두었다고 해보자.

09:03, 09:04, 09:05에 또 다른 경보들이 도착한다.

• 인프라 모니터링 도구에서
• APM 도구에서
• synthetic 테스트 제공업체에서

벽은 순식간에 본질적으로 같은 정보로 채워진다. 다만 관찰자가 다를 뿐이다.

2. 컨텍스트와 동적 기준선에 기반한 중복 제거 적용하기

순진한 중복 제거는 경보 이름이나 서비스 이름만 본다. 하지만 진짜 Incident 상황에서는 이 정도로는 충분치 않다. 더 견고한 dedup 엔진은 다음을 함께 고려한다.

• 컨텍스트 메타데이터

  • 환경 (prod vs. staging)
  • 리전 / 존
  • 인스턴스 그룹, 파드, 클러스터 ID
  • 배포 버전, 활성화된 기능 플래그 상태

• 동적 기준선(dynamic baseline)

  • 이 메트릭이 이 요일, 이 시각에 보통 어떤 값이었는가?
  • 지금 패턴이 기존 이상징후의 연장선인가, 완전히 새로운 형태의 이상인가?

이를 통해 시스템은 다음 질문에 답할 수 있게 된다.
“이게 진짜 새로운 Incident인가, 아니면 기존 Incident를 다른 렌즈로 본 것일 뿐인가?”

후자라면 이 경보는 새로운 페이지가 아니라 Incident를 풍부하게 만드는(enrichment) 이벤트가 된다.

그 결과, 다음이 크게 줄어든다.

• 중복된 알림
• 중복 티켓
• 서로 겹치거나 충돌하는 대응 스레드

동적 임계값: 트래픽의 ‘일상적인 리듬’에 맞추기

시각표 벽이 가장 붐비는 때는 피크 타임이다. 아침 로그인 러시, 점심 주문, 업무 종료 시점 정산 처리 등. 사용자는 새벽 3시에 행동하는 방식과 오전 9시에 행동하는 방식이 다르다. 마찬가지로, 임계값도 시간대에 따라 달라져야 한다.

“요청 수가 분당 10,000건을 넘으면 경보” 같은 정적 임계값은 트래픽의 자연스러운 리듬을 전혀 이해하지 못한다. 오전 9시에는 그게 평소일 수도 있지만, 새벽 3시에 그 수치라면 DDoS일 수도 있다.

3. Adaptive Baseline/동적 임계값 도입하기

Adaptive baseline은 시간에 따른 정상 패턴을 학습하고 거기에 맞춰 조정한다.

• 이미 바쁜 시간대에는 더 높은 부하·지연을 허용
• 한적한 시간대에는 작은 스파이크도 더 민감하게 감지
• 평일 vs. 주말, 계절/캠페인에 따른 패턴 인지

동적 임계값의 효과는 다음과 같다.

• 예상 가능한 변동(일일 피크 사용량 등) 동안 오탐(false positive)을 줄인다.
• 비정상적인 시간대에서는 민감도를 높여 작은 이상도 놓치지 않는다.

결국 디지털 시각표는 러시아워의 붐빔과 진짜 탈선 사고를 구분할 줄 아는 수준에 도달한다.

지속적인 튜닝: 네트워크가 바뀌면 시각표도 바뀌어야 한다

서비스는 계속 진화한다. 아키텍처는 바뀌고, 팀은 새로운 의존성을 추가하고, 오래된 것을 퇴역시키고, 핵심 경로를 리팩터링한다.

하지만 카드보드 벽은 누가 다시 쓰지 않는 이상 그대로다. 경보 룰도 마찬가지다. 정기적으로 다시 보고 튜닝하지 않으면, 현실과 점점 어긋나기 시작한다.

4. 경보 룰을 주기적으로 재검토하고 다듬기

경보 튜닝을 일회성 프로젝트가 아니라 정기적 관행으로 만들어야 한다.

• 분기마다, 혹은 큰 Incident 이후에 시끄러운(noisy) 경보를 리뷰한다.
• 스스로에게 묻는다: “이 경보가 탐지, 진단, 완화에 실제로 도움이 되었는가?”
  도움이 되지 않았다면, 기준을 조정하거나, 다른 방식으로 바꾸거나, 아예 폐기한다.
• 경보를 현재 비즈니스·기술 우선순위와 정렬시킨다. 지금 고객에게 정말 중요한 것에 초점을 맞춘다.

이렇게 해야 Incident “시각표”가 작년에 깔린 선로가 아니라, 지금 실제로 달리고 있는 선로와 맞아떨어진다.

많은 도구, 하나의 문제: 그룹핑과 Dedup이 필수인 이유

현대 스택에서는 보통 여러 겹치는 도구를 함께 쓴다.

• 인프라 모니터링
• APM / 트레이싱
• 로그 분석
• Synthetic 모니터링
• 보안 모니터링

장애가 나면, 이 도구들은 각자 다음을 수행한다.

• 같은 근본 증상을 감지하고
• 거의 동일한 경보를 쏘고
• 같은 온콜 팀에 에스컬레이션한다.

그래서 대규모 경보 폭주 상황은, 여러 도구가 같은 이슈를 반복 보고해서 생기는 경우가 많다.

그룹핑과 중복 제거 없이 가면:

• 모든 보고를 새로운 사건으로 취급하게 되고
• 온콜 인력의 주의를 ‘문제 해결’이 아니라 ‘경보 관리’에 소모하게 되며
• Incident 채널은 중복되고, 상충되거나, 부분적인 관점들로 뒤덮인다.

반대로, 지능적인 그룹핑과 Dedup을 적용하면 도구와 팀을 가로질러 하나의 통합 Incident 스토리를 갖게 된다.

데이터 위생(Data Hygiene): 날것의 시간 필드로 선로도를 어지럽히지 말 것

백엔드에서는 Incident 파이프라인이 타임스탬프, 라벨, 메트릭, 피처 같은 데이터 위에서 돌아간다. “나중을 위해” 모든 걸 다 남겨두고 싶어지는 유혹이 있다.

하지만, 만약 모델이나 룰이 **날것의 시간 정보(정확한 타임스탬프, 초 단위 메트릭 등)**를 더 의미 있는 범주형 피처(예: “러시아워 vs. 비피크”, “배포 전 vs. 배포 후”, “평일 vs. 주말”)로 이미 변환하고 있다면, 모든 데이터셋에 원시 필드를 유지할 필요는 없다.

5. 파생 정보에 불과한 원시 시간 피처는 제거·통합하기

목표는 데이터셋을 다음과 같이 유지하는 것이다.

• 깨끗하게: 같은 요인을 두 번 표현하는 중복 피처 제거
• 목적 지향적으로: 실제 의사결정에 기여하는 피처에 집중
• 읽기 쉽게: 엔지니어가 epoch 마이크로초 숫자보다, incident_window_type = peak_hour 같은 표현을 훨씬 직관적으로 이해할 수 있다.

이는 선로도를 다시 그리는 일과 비슷하다. 열차 시각표에 필요한 건 열차가 보통 언제 다니는지이지, 철로에 깔린 침목 하나하나의 GPS 좌표가 아니다.

결론: 카드보드 벽을 은퇴시킬 때

카드보드로 만든 장애 스토리 열차 시각표 벽은 좋은 비유이자, 동시에 경고장이기도 하다. Incident 대응이 아직도 카드보드에 포스트잇을 붙이는 느낌이라면, 아마 이런 상태일 것이다.

• 경보 하나하나를 별개의 위기로 취급하고
• 같은 근본 문제에 대해 반복해서 페이지를 울리며
• 가장 명료함이 필요한 순간에, 노이즈에 허덕이고 있을 가능성이 크다.

이 단계를 넘어서려면 다음이 필요하다.

1. 근본 원인, 공유 서비스, 시간 패턴을 기반으로 한 지능적인 그룹핑
2. 컨텍스트 메타데이터와 동적 기준선에 기반한 중복 제거(deduplication)
3. 짧은 시간에 같은 서비스에서 터지는 여러 경보를 하나의 Incident로 통합하는 시간 윈도우 상관 분석
4. 정상적인 트래픽 리듬을 이해하는 Adaptive Baseline / 동적 임계값
5. 실제 운영 중인 시스템과 계속 동기화되도록 하는 정기적인 룰 튜닝
6. 여러 도구에서 나오는 신호를 하나의 일관된 스토리로 합치는 크로스-툴 통합
7. 원시 시간 피처를 의미 있는 범주형 피처로 정리한 깨끗하고 목적 있는 데이터셋

이걸 잘 해내면, Incident 타임라인은 더 이상 과밀한 시각표처럼 보이지 않는다. 대신 Incident마다 하나의 선로가 깔려 있고, 첫 징후부터 최종 해결까지 읽기 쉬운 스토리가 생긴다.

피크 타임이 여전히 바쁘다는 사실은 변하지 않는다. 하지만 이제 팀이 씨름하는 대상은 카드보드 벽이 아니라, 실제 열차(서비스)를 조종하는 일이 된다.