Rain Lag

아날로그 인시던트 신호 철도: AI 시대 장애를 위한 ‘걸어 다니는 종이 NOC’ 만들기

철도 신호 시스템, 예지 정비, AI 기반 자동화를 통해 현대 API와 SDK에서 99.99% 가용성을 목표로 하는 탄탄한 ‘종이 NOC’ 접근법을 어떻게 설계할 수 있는지 살펴봅니다.

아날로그 인시던트 신호 철도: AI 시대 장애를 위한 ‘걸어 다니는 종이 NOC’ 만들기

디지털 인프라는 이제 과거 산업 경제에서 철도가 맡았던 역할만큼이나 사회에 필수적인 기반이 되었습니다. 우리는 “5 9(99.999%)”나 “미션 크리티컬” 같은 말을 자주 하지만, 실제로는 많은 시스템이 여전히 취약합니다. 잘못된 롤아웃, 품질이 떨어지는 모델 업데이트, 클라우드 장애 하나로도 수백만 명이 사용하는 API가 동시에 멈출 수 있습니다.

반대로 철도는 100년이 넘는 시간 동안 “실패를 전제로 한 설계”를 다듬어 왔습니다. 기계식·전기식 신호 시스템은 무엇인가 고장 났을 때 열차가 충돌하지 않고 멈추도록 설계되었습니다. 이 사고방식—설계 단계에서부터 Fail-safe(실패 시 안전), 스트레스 상황에서도 예측 가능하고, 사람이 이해할 수 있는 시스템—은 현대 인시던트 관리에도 놀라울 만큼 잘 들어맞습니다.

이 글에서는 99.99% 가용성을 목표로 하는 인시던트 시스템을 설계하기 위해 다음을 어떻게 활용할 수 있는지 다룹니다.

  • 철도 신호(railway signalling) 원칙을 빌려온 Fail-safe 동작 설계
  • 복잡한 시스템을 사람 눈으로 읽을 수 있는 걸어 다니는 종이 NOC(paper NOC) 만들기
  • AI를 활용한 예방(Preventive)·예측(Predictive)·처방(Prescriptive) 분석 적용
  • 예지 정비(predictive maintenance) 개념을 소프트웨어와 인프라에 이식하기
  • 장애를 피할 수 없다는 전제를 깔고 설계하는 AI 기반 인시던트 대응(incident response)

1. 99.99% 문제: 설계 제약조건으로서의 신뢰성

99.99% 가용성은 연간 약 52분의 다운타임을 의미합니다. 결제, 물류, 헬스케어를 구동하는 API·SDK라면 이 정도도 결코 적지 않은 시간이지만, 이미 상당히 높은 기준입니다.

많은 팀이 하는 대표적인 실수는 신뢰성을 다음처럼 취급하는 것입니다.

  • 단지 측정 지표(SLO)로만 보거나,
  • 아키텍처·프로세스·툴링 전반을 규정하는 설계 제약조건으로 보지 않는 것.

99.99%를 달성하려면 다음과 같은 특성을 가진 시스템이 필요합니다.

  1. 장애가 연쇄적으로 확산되지 않고, 통제 가능한 방식으로 실패할 것
  2. 사람이 빠르게 디버깅할 수 있도록 상태가 명확하게 노출될 것
  3. 텔레메트리와 모델을 통해 성능 저하를 조기 탐지할 것
  4. 자동화된 대응을 하되, 그 로직이 사람이 이해할 수 있을 것

이것은 수십 년 동안 철도 엔지니어들이 살아온 세계이기도 합니다.


2. 철도에서 배우는 안전한 실패(Fail-safe)의 기술

전통적인 철도 신호 시스템은 매우 강력한 아이디어 하나를 중심에 두고 있습니다. “애매하면, 일단 열차를 멈춰라.”

기계식 인터로킹(interlocking), 릴레이 로직, 이후 전자식 시스템까지 모두 다음처럼 설계되어 있습니다.

  • 전선이 끊기거나, 릴레이가 붙은 채로 멈추거나, 전원이 나가면
  • 신호는 자동으로 적색(Stop), 선로는 잠금(Locked) 상태로 돌아가며, 녹색 신호와 충돌 가능성이 있는 경로가 열리지는 않습니다.

여기서 소프트웨어가 가져올 수 있는 핵심 원칙은 다음과 같습니다.

2.1 Fail-safe 기본값

철도 신호에서 위험한 상태에 도달하기는 안전한 상태에 도달하는 것보다 훨씬 더 어렵게 만들어져 있습니다. 이를 소프트웨어로 옮기면:

  • 인증 또는 설정 상태가 불확실할 때는 **접근 허용이 아니라 기본 거부(deny by default)**로 동작하게 합니다.
  • 의존 서비스에 문제가 생기면 **완전 실패보다는 속도 제한(rate limit)이나 축소 모드(degraded mode)**로 진입하도록 합니다.
  • 새 모델·설정의 검증이 안 되면 이전의 검증된 안정 버전으로 자동 롤백하는 것을 기본값으로 둡니다.

2.2 국지적 독립성과 격리

철도 인터로킹은 보통 구간별로 자율적으로 동작합니다. 한 구간에 문제가 생겨도 전체 네트워크가 동시에 멈추지 않도록 하는 구조입니다.

API·SDK에서도 마찬가지입니다.

  • 경계가 명확한 장애 도메인(bounded failure domain) 을 설계합니다. 특정 리전·테넌트·기능에서 문제가 생겨도 글로벌 장애로 번지지 않도록 합니다.
  • 서킷 브레이커(circuit breaker), 벌크헤드(bulkhead), 부하 차단(load shedding) 패턴을 사용해 피해 범위를 좁힙니다.

2.3 사람이 읽을 수 있는 로직

옛 철도의 릴레이룸은 사실상 비즈니스 룰을 하드웨어로 구현한 것입니다. 엔지니어가 실제 배선을 따라가며 로직을 물리적으로 추적할 수 있었죠. 신뢰성 측면에서 이는 훌륭한 은유입니다.

  • 예를 들어 “언제 자동 롤백을 할 것인가” 같은 핵심 안전 로직은 명시적이고, 검토 가능하게 작성되어야 합니다.
  • 인시던트 상황에서 아무도 전체 흐름을 설명하지 못하는 불투명한 자동화 체인은 피해야 합니다.

이 원칙들이 바로 새로운 개념, 즉 걸어 다니는 종이 NOC의 기반이 됩니다.


3. 걸어 다니는 종이 NOC: 디지털 시스템의 아날로그 뷰

“종이 NOC(paper NOC)”는 의도적으로 로우 테크이며, 사람 중심의 시각화로 운영 환경을 표현하는 방식입니다. 인프라를 위한 철도 신호 다이어그램 같은 것이라고 보면 됩니다.

목표는 단순합니다. 대시보드가 모두 죽어 있어도, SRE가 벽 앞에 걸려 있는 것만 보고도 상황을 읽고, 대응을 조율할 수 있게 만드는 것입니다.

3.1 종이 NOC에 들어가야 할 것들

최소한 다음 내용은 포함되어야 합니다.

  1. 시스템 토폴로지 맵

    • 핵심 서비스와 데이터 저장소
    • 주요 의존성(내부·외부 포함)
    • 리전, 테넌트, 기능별 장애 도메인 경계
  2. 제어 레버(Control Levers)

    • 피처 플래그와 킬 스위치(kill switch)
    • 폴백 모드(읽기 전용, 처리량 축소, 모델 폴백 등)
    • 대표적인 장애 유형별 수동 런북(runbook)
  3. 인시던트 플로우(Incident Flows)

    • 에스컬레이션 트리(누가 어떤 순서로 호출되는지)
    • 커뮤니케이션 템플릿(상태 페이지, 내부 공지 등)
    • 증상별 초기 트리아지 가이드(무엇부터 확인할지)
  4. SLO 및 리스크 개요

    • SLO/SLA 기준선
    • 비즈니스 임팩트에 대한 “레드라인”
    • 알려진 단일 장애 지점(SPOF)

3.2 AI 시대에 굳이 아날로그가 필요한 이유

종이 NOC는 툴이 고장났을 때를 위한 단순 백업 그 이상입니다. 이는 일종의 설계 강제 장치(design forcing function) 입니다.

  • 시스템과 장애 모드를 간단하게 그려낼 수 없다면, 그 시스템은 애초에 안정적으로 운영하기에 너무 복잡한 것일 수 있습니다.
  • 벽에 그려서 설명할 수 없는 자동화라면, 위기 상황에서 신뢰하기엔 지나치게 불투명한 것일 수 있습니다.

이런 의미에서 종이 NOC를 만든다는 것은 신호 박스의 축소 모형을 만드는 것과 비슷합니다. 단순화하는 과정에서 숨은 결합, 불명확한 책임, 부족한 제어 지점이 드러납니다.


4. AI를 활용한 예방·예측·처방 분석

철도 업계는 정기 점검 중심에서 센서 데이터 기반의 **예지 정비(predictive maintenance)**로 전환하고 있습니다. 선로와 차량에 설치된 센서가 데이터를 수집하고, 모델이 고장을 예측해 필요한 지점에만 정비를 수행합니다.

API·SDK 인프라에서도 같은 개념을 적용할 수 있습니다. 여기서는 AI를 세 층위로 나누어 볼 수 있습니다.

4.1 예방 분석(Preventive Analytics)

목표: 고장 발생 가능성을 줄이는 것.

  • 정적 분석(static analysis)으로 위험한 코드 변경을 배포 전에 포착
  • 구성 린팅(config linting)으로 위험한 패턴(예: 타임아웃 미설정, 무제한 재시도)을 검출
  • 트래픽 폭주, 리전 장애 같은 시나리오의 “What-if” 시뮬레이션

4.2 예측 분석(Predictive Analytics)

목표: 사용자가 체감하기 전에 고장을 예측하는 것.

  • 레이턴시, 에러율, 리소스 사용률(time-series) 기반 모델로 전조 신호 감지
  • 배포 패턴 이상 탐지(롤백 빈도, 카나리 배포의 드리프트 등)
  • 서비스·리전별 헬스 스코어를 산출해 라우팅·용량 결정에 반영

4.3 처방 분석(Prescriptive Analytics)

목표: 완화(mitigation) 조치를 추천하거나 자동 실행하는 것.

  • 부하 상황에서 최적의 스로틀링·라우팅 변경을 제안
  • 과거 패턴을 바탕으로 롤백, 페일오버, 기능 비활성화 등을 추천
  • 사람 승인 범위 내에서 서킷 브레이커 임계값을 동적으로 튜닝

무엇보다 중요한 점은 모든 처방적 행동이:

  • 신호 인터로킹처럼 명확한 가드레일(guardrail) 아래에서 동작하고,
  • 종이 NOC에 그대로 투영 가능한 형태의 제어 흐름으로 표현되어야 한다는 것입니다.

5. 소프트웨어와 인프라를 위한 예지 정비

철도에서 예지 정비는 자산이 실제로 고장 나기 전에 수리함으로써 다운타임을 줄이고 안전성을 높입니다. 소프트웨어 세계에서 “자산”은 다음을 포함합니다.

  • 서비스와 데이터베이스
  • CI/CD 파이프라인
  • SDK 통합 및 클라이언트 애플리케이션

5.1 중요한 것은 모두 계측하라

예지 정비를 잘하려면 다음이 필요합니다.

  • 고품질 텔레메트리: 로그, 메트릭, 트레이스, 이벤트
  • 명확한 소유권: 모든 핵심 자산에는 책임 팀과 SLO가 존재
  • 구성 변경 이력: 인시던트를 변경 사항과 상관관계로 추적 가능

5.2 사용자 영향에 초점을 맞춘 모델

모든 이상 징후가 중요한 것은 아닙니다. 모델은 다음과 상관성이 높은 신호에 집중해야 합니다.

  • SLO 위반(레이턴시, 에러율, 가용성)
  • 인시던트 트리거(알람, 축소 모드 진입, 페일오버 등)

이상적인 예지 정비 엔진은 다음과 같이 말할 수 있어야 합니다.

“이 리전의 에러 패턴과 리소스 포화 양상이 과거 인시던트 직전 양상과 유사합니다. 향후 30분 내 SLO 위반 가능성이 높습니다.”

5.3 선제적 조치

리스크가 임계값을 넘으면 다음과 같은 행동을 취할 수 있습니다.

  • 용량 이동 (오토스케일링, 콜드 스탠바이 활성화)
  • 더 건강한 리전으로의 선제적 트래픽 재라우팅
  • 중요도가 낮은 고객·기능에 대한 조기 레이트 리밋팅

이는 선로 센서가 미세한 균열을 감지했을 때 탈선 사고가 나기 전에 보수 공사를 하는 것과 같습니다.


6. AI 기반 인시던트 대응: 가드레일이 있는 자동화

AI 기반 자동 인시던트 대응은 탐지·복구 시간을 크게 줄일 수 있지만, 철도 신호와 동일한 Fail-safe 사고방식으로 설계되어야 합니다.

6.1 ‘눈먼 자동화’가 아니라 ‘지루한 일 자동화’

자동화에 적합한 후보는 다음과 같습니다.

  • 초기 트리아지(인시던트 분류, 연관 가능성이 높은 컴포넌트 식별)
  • 상황 컨텍스트 수집(최근 배포, 설정 변경, 시스템 헬스)
  • 사전 승인된, 되돌리기 쉬운(reversible) 런북 조치 실행

반대로 피해야 할 것은:

  • 경계 없이 스스로 변형되는 복구 로직
  • 검증 없이 공격적으로 재구성하여 피해 범위를 키울 수 있는 조치

6.2 설계 단계부터 사람을 루프 안에 넣기

  • AI가 제안하는 조치는 반드시 이유와 설명을 포함하도록 합니다.
  • 영향도가 큰 변경에는 사람의 최종 승인을 요구합니다.
  • 모든 자동화 의사결정을 종이 NOC에 투영 가능한 형태로 기록해, 인시던트 대응자가 사건의 흐름을 한눈에 볼 수 있게 합니다.

6.3 인시던트 이후: 학습 루프

모든 장애는 다음을 위한 데이터입니다.

  • 예측 모델 개선
  • Fail-safe 설계 검증
  • 아날로그 표현(종이 NOC) 개선 입력(실제 상황과 얼마나 잘 맞았는지)

이는 철도가 사고 이후 규칙과 신호 기준을 지속적으로 업데이트하는 방식과 같습니다.


7. 피할 수 없는 장애를 전제로 한 설계

아무리 잘해도 장애는 발생합니다. 안개, 눈, 기계 결함이 철도에서 피할 수 없듯, 소프트웨어에서도 예외는 없습니다.

탄력적인(resilient) 시스템이란 다음을 의미합니다.

  1. 고장 상황을 이해할 수 있게 돕는 명확한 시각화(디지털·아날로그 모두)
  2. 런북, 훈련, 인시던트 커맨드 구조 등 탄탄한 프로세스
  3. 의존성 그래프부터 라우팅 정책까지, 모든 설계가 언젠가는 고장 날 것을 전제로 만들어져 있는 상태

이를 하나로 묶어주는 몇 가지 실천 방안을 정리하면:

  • 종이 NOC에 문서화된 장애 모드를 실제로 실행해 보는 **게임 데이(Game Day)**를 운영합니다.
  • 대응 인력을 순환 배치해 “신호 엔지니어(signal engineer)” 역할을 맡깁니다. 이들은 자동화가 지속적으로 Fail-safe이고 이해 가능한지 책임지는 사람들입니다.
  • 정기적으로 **“벽을 함께 걷기(walk the wall)”**를 합니다. 시스템이 진화해 종이 모델에 더 이상 들어맞지 않는다면, 시스템이든 모델이든 그 어느 한쪽을 다시 맞을 때까지 리팩터링해야 합니다.

결론: 나만의 인시던트 철도 만들기

현대의 API와 SDK는 기존 사회 기반시설에 버금가는 수준의 신뢰성을 요구받고 있습니다. 철도 신호 시스템이 보여주는 메시지는 분명합니다. 신뢰성은 대시보드가 아니라 철학입니다.

  • 실패를 전제로 하고,
  • 기본값을 안전으로 두며,
  • 시스템의 행동을 눈에 보이고 이해 가능하게 만드는 것.

이를 위해 다음을 결합해 보십시오.

  • 철도식 Fail-safe 설계
  • 시스템 이해를 물리적으로 구현한 걸어 다니는 종이 NOC
  • AI 기반 예방·예측·처방 분석
  • 소프트웨어와 인프라 전반에 적용한 예지 정비
  • 인시던트 대응을 위한 가드레일이 있는 자동화

이렇게 하면 사람의 통제권을 유지한 채, 99.99%에 가까운 안정적인 가용성에 한 걸음 더 다가갈 수 있습니다.

점점 더 불투명해지는 AI 시스템의 시대에, 아날로그 인시던트 신호 철도라는 사고방식은 우리에게 상기시킵니다. 진정한 신뢰성은 시스템을 벽에 그려 보고, 실패 경로를 따라가며, 문제가 생겼을 때 어디를 당겨야 할지 아는 것에서 시작된다는 사실을 말입니다.

아날로그 인시던트 신호 철도: AI 시대 장애를 위한 ‘걸어 다니는 종이 NOC’ 만들기 | Rain Lag