아날로그 장애 현장 노트: 도시처럼 시스템을 걸어 다니며 숨은 장애를 찾는 법

현대 시스템은 놀랍도록 옛날 방식으로 망가진다.

클라우드 플랫폼, 컨테이너 오케스트레이션, 자동 복구 메커니즘이 있어도, 실제 장애는 결국 몇 가지 고전적인 질문으로 귀결된다.

무엇이 실패했는가?
왜 실패했는가?
어떻게 하면 사전에 징후를 볼 수 있었을까?
다음에는 무엇을 다르게 할 것인가?

전통적인 신뢰성 공학은 수십 년간 이 질문들과 씨름해 왔다. 통계, 고장 물리(physics-of-failure) 모델, 예측 정비(prognostics)의 공통 목표는 하나다. 시스템이 어떻게, 왜 실패하는지 이해하고 예측하는 것이다.

현대 소프트웨어와 사이버-물리 시스템에서의 차이는 규모와 복잡도다. 이 시스템들은 더 이상 단순한 기계라기보다는 도시처럼 행동한다.

이 복잡함을 이해하려면, 시스템을 정적인 다이어그램으로만 대하지 말고 도시를 걷듯이 직접 걸어봐야 한다. 그때 손에는 **아날로그 장애 현장 노트(analog outage field notebook)**가 있어야 한다.

신뢰성 이론에서 시스템의 거리 지도까지

고전적인 신뢰성 공학에서는 보통 다음과 같은 일을 한다.

컴포넌트 수명을 통계적으로 모델링하고
열 사이클, 진동, 피로와 같은 스트레스·마모를 시뮬레이션하며
남은 사용 가능 수명(remaining useful life)을 추정하는 예측 모델을 만든다

이 모든 것은 실제로 고장이 나기 전에 고장을 보이게 만드는 것에 관한 일이다.

이와 같은 사고방식은 분산 시스템과 사이버-물리 인프라에도 그대로 적용된다. 다만 도구와 현상이 다르게 보일 뿐이다.

베어링 마모 대신, API rate limit과 **큐 백로그(queue backlog)**가 보인다.
납땜 균열 대신, eventual consistency 글리치와 **연쇄 재시도(cascading retries)**가 드러난다.
부식 대신, 설정(config) 드리프트와 미묘한 제어 루프 버그가 나타난다.

많은 팀이 저지르는 실수는, 메트릭 대시보드와 로그에만 의존하는 것이다. 이는 마치 도시의 위성 사진만 보고 “이 동네를 잘 안다”고 주장하는 것과 같다.

숨은 장애가 어디에 숨어 있는지 진짜로 이해하려면, 더 촉감 있는 방법이 필요하다. 시스템을 직접 걸어 다닐 수 있는 방식, 그리고 그때 발견한 것을 적어둘 현장 노트가 필요하다.

사이버-물리 테스트베드: 시스템을 안전하게 걸어볼 수 있는 공간

전력망, 산업용 IoT, 로보틱스, 교통 시스템처럼 복잡하고 안전이 중요한 환경에서는, **사이버-물리 테스트베드(cyber-physical testbed)**가 신발 끈을 조이고 도시로 걸어 들어가는 출입문 역할을 한다.

좋은 사이버-물리 테스트베드는 다음을 가능하게 한다.

현실적인 하드웨어, 네트워크, 제어 소프트웨어로 실세계 조건을 거울처럼 반영하고
고장, 과부하, 엣지 케이스 상황에서 제어 전략과 자동화를 검증하며
프로덕션을 죽이지 않고, 안전하게 결함을 주입할 수 있다 (노드를 끊거나, 센서를 지연시키거나, 제어 메시지를 손상시키는 등)

프로덕션에서 장애가 덮쳐 오기를 마냥 기다리는 대신, 테스트베드에서는 우리가 먼저 장애를 사냥하러 나간다.

주요 컨트롤러가 30초 동안 격리되면 어떻게 될까?
센서의 절반이 오래된(stale) 값을 리포트하면 시스템은 어떻게 행동할까?
뭔가 미묘하게 잘못됐을 때, 실제로 어떤 알람이 울리는가?

도시에서 동네를 걸어 보면, 아직 사고가 나지 않았더라도 사고가 날 것 같은 블라인드 코너와 위험한 교차로가 보인다. 테스트베드에서 시스템을 걸어보면 비슷한 사각지대가 드러난다.

특정 지연 조건에서만 불안정해지는 제어 루프
‘작동은 하지만’ 위험한 과도 상태를 만드는 페일오버
중요한 신호들이 함께 로그에 남지 않아 생기는 모니터링 블라인드 스팟

그러나 걷기만 해서는 충분하지 않다. 시스템이 어떻게 행동하는지에 대한 기록, 나중에 실제 장애가 일어났을 때 다시 찾아볼 수 있는 증거의 흔적이 필요하다.

여기서 등장하는 것이 바로 아날로그 장애 현장 노트다.

아날로그 장애 현장 노트: 왜 아직도 종이가 유리한가

장애가 터지면, 모두가 바쁘게 뭔가를 하고 있다.

서비스를 재시작하고
기능 플래그(feature flag)를 전환하고
설정을 바꾸고
급히 로그나 알람을 추가한다

정작 빠지기 쉬운 역할은, 누군가가 실시간으로 상황을 기록하는 것이다.

14:02:30 – #support 채널에 첫 사용자 제보 도착
14:03:15 – checkout API (us-east-1 리전) 오류율 스파이크
14:05:03 – 버전 1.4.6으로 롤백
14:06:50 – 지연 시간은 개선되었지만, 오류율은 변화 없음

대부분의 팀은 이런 타임라인을 나중에 슬랙 로그, 티켓 코멘트, 모니터링 기록, 사람들의 기억을 긁어모아 사후 복원하려 한다. 이 수동 복원 과정은 오래 걸리고 고통스럽고, 그 과정에서 중요한 디테일들이 사라진다.

가장 처음 문제를 눈치챈 사람은 누구였는가?
초기 의사결정을 이끈 메트릭 혹은 로그 라인은 무엇이었는가?
어떤 가설을 세웠다가, 실제로 검증하고 버렸는가?
시스템은 정확히 언제부터 회복되기 시작했고, 그 이유는 무엇이었는가?

“아날로그 장애 현장 노트”는 특정한 종이 노트를 뜻한다기보다는, 마인드셋이자 실천 방식이다. 물론 진짜 종이 노트도 놀랍게 잘 작동한다.

심각한 인시던트마다 타임라인을 책임지는 사람을 한 명 지정하고
그 사람이 실시간으로 사건들을 시간·맥락과 함께 기록하며
탐지, 대응, 복구 과정을 순서대로 남긴다

이렇게 시간 순서로 정리된 사람 눈높이의 로그는, 이후 진행할 **장애 포스트모템(post-mortem)**의 골격이 된다.

포스트모템 vs 회고(Retrospective): 목적이 다른 두 도구

사람들은 종종 *회고(retrospective)*와 *포스트모템(post-mortem)*을 같은 말처럼 쓰지만, 신뢰성 향상을 위해서는 이 둘을 구분하는 게 중요하다.

**회고(retrospective)**는 일정 기간이나 프로젝트를 돌아보며, *뭐가 잘됐고, 뭐가 안 됐고, 다음에 뭘 시도할까?*를 묻는다.
균형 잡힌 개선 중심의 대화다.
**포스트모템(post-mortem)**은 특정 장애나 심각한 다운타임 사건을 대상으로, *무엇이 잘못됐는가? 왜 잘못됐는가? 다음에는 어떻게 예방하거나 피해를 줄일 것인가?*를 묻는다.
실패와 인과관계에 초점을 맞춘다.

장애 분석과 신뢰성 학습에는 포스트모템이 더 적합하다. 그 이유는 다음과 같다.

실패를 데이터로 다룬다. 비난의 대상이 아니라, 가치 높은 학습 자료로 본다.
근본 원인과 시스템 패턴을 찾아 들어간다. 표면적인 촉발 요인에서 끝나지 않는다.
구체적인 예방 전략을 만들어낸다. 설계 변경, 자동화, 테스트, 모니터링 개선 같은 실행 가능한 조치를 뽑아낸다.

강력한 포스트모템은 현장 노트나 인시던트 로그에서 가져온 상세 타임라인에 크게 의존한다. 이게 없으면 결국 추측에 기대게 된다.

생각보다 훨씬 중요한 타임라인

장애는 거의 언제나 단일 원인으로 발생하지 않는다. 보통은 작은 일들이 연쇄적으로 맞아떨어진 결과다.

설정 변경으로 용량이 아주 조금 줄어든다.
재시도 정책이 부분 장애 상황에서 부하를 증폭시킨다.
모니터링 룰이 시끄럽다는 이유로, 사실은 중요한 알람을 필터링한다.
수동 롤백이 예전 버그를 다시 끌어들인다.

이 연쇄를 이해하려면, 다음과 같은 시간순 기록이 필요하다.

탐지(Detection): 문제를 언제, 어떤 경로로 처음 알아차렸는가?
대응(Response): 우리가 처음, 두 번째, 세 번째로 한 행동은 무엇이었고, 누가 했는가?
복구(Remediation): 실제로 효과가 있었던 조치는 무엇이었고, 그걸 어떻게 검증했는가?

이 시간적 순서가 없으면, 다음을 구분하기가 매우 어렵다.

실제 원인 사슬의 일부였던 행동 vs 단순한 노이즈
정말로 문제를 고친 변경 vs 자연 회복 타이밍과 우연히 겹친 변경
탐지 부족으로 인한 지연 vs 의사결정이 느려서 생긴 지연

그래서 실시간 가시성(observability)과 인시던트 기록 개선은 사치가 아니라, 신뢰성을 위한 핵심 인프라다.

Observability는 시스템이 무엇을 하고 있는지 보게 해준다.
Incident recording은 사람들이 그에 어떻게 대응하고 있는지 보게 해준다.

이 둘이 있어야, 우리는 실패로부터 효과적으로 배울 수 있다.

분산 시스템을 도시처럼 걷는다는 것

대규모 분산 시스템은 엉성하지만 살아 있는 도시와 비슷하게 행동한다.

서비스들은 각자 다른 신뢰도와 트래픽 패턴을 가진 **동네(neighborhood)**를 이룬다.
의존성은 잘 지어진 것도 있고 허술한 것도 있는 도로와 다리다.
데이터 저장소와 큐는 터미널과 창고가 되어 병목과 정체가 생기는 지점이 된다.

숨은 장애 모드가 어디에 사는지를 알려면, 시스템의 **지리(geography)**를 배워야 한다.

좁은 다리, 즉 **단일 장애 지점(SPOF, Single Point of Failure)**은 어디인가?
여러 고속도로가 합류하는, 즉 공유 의존성 때문에 핫스팟이 되는 구간은 어디인가?
아무도 소유하지 않고, 아무도 모니터링하지 않지만 모두가 의존하는 **어두운 골목(dark alley)**은 어디인가?

여기서 설계 선택—예컨대 일관성 모델, 타임아웃, 배포 패턴, 백프레셔(backpressure) 전략—은 곧 장애가 터질 때의 행동 양상을 직접적으로 결정한다.

지나치게 공격적인 재시도는, 작은 지연을 스스로에게 거는 DDoS로 키워 버릴 수 있다.
강한 일관성 요구는, 단일 노드 장애를 전역 스톨(global stall)로 확대시킬 수 있다.
잘못 튜닝된 헬스 체크는, 일시적인 지연 때문에 건강한 인스턴스를 계속 퇴출시킬 수 있다.

이 패턴들을 선명하게 보려면, 다음과 같은 접근이 필요하다.

호기심을 갖고 프로덕션 시스템을 걸어 본다. 하나의 요청을 서비스 간에 끝까지 따라가 보고, 하나의 제어 신호를 엔드 투 엔드로 추적해 보고, 큐와 캐시를 교차로와 진입 램프 보듯이 들여다본다.
**테스트베드와 카오스 실험(chaos experiment)**을 통해, 실제 사용자에게 피해 주기 전에 “사고 시나리오”를 가상으로 만들어 본다.
인시던트가 발생하면 아날로그 장애 현장 노트 습관을 유지해, 포스트모템이 실제로 일어난 일에 근거해 작성되도록 한다.

실천으로 엮어 보기: 작게 시작하는 실용 패턴

아주 작게 시작하더라도, 신뢰성 측면에서 큰 수확을 얻을 수 있다. 예를 들어 다음과 같은 패턴이다.

도시 지도 그리기
- 핵심 서비스, 데이터 플로우, 외부 의존성을 문서화한다.
- 장애가 전파되기 쉬운 명백한 “다리”와 “교차로”를 식별한다.
가능한 범위에서 테스트베드를 만들거나 활용하기
- 중요한 경로와 제어 루프를 최대한 비슷하게 재현한다.
- 지연, 패킷 손실, 부분 장애, 잘못된 데이터 같은 현실적인 실패를 주입한다.
인시던트 시 아날로그 현장 노트 마인드셋 적용하기
- 큰 장애에는 반드시 인시던트 서기(scribe)를 지정한다.
- 탐지·대응·복구 단계를 시간 순서대로 기록하게 한다.
그냥 회고가 아닌, 진짜 포스트모템 진행하기
- 무엇이, 왜 잘못됐는지에 초점을 맞춰 깊게 파고든다.
- 최소 몇 가지는 구체적인 예방 조치를 추출한다.
학습 내용을 설계와 운영에 되먹이기
- 타임라인이 흐릿했던 부분은 Observability를 강화한다.
- 아키텍처에서 취약한 “다리”를 단순화하거나 보강한다.
- 실제로 경험한 장애 모드를 재현하는 테스트나 시뮬레이션을 추가한다.

결론: 도시를 모니터링만 하지 말고, 직접 걸어라

신뢰성은 단순히 더 많은 대시보드, 더 많은 알람, 더 많은 이중화 장비를 두는 문제가 아니다. 중요한 것은 **상황 인식(situational awareness)**이다. 즉, 시스템이 어떻게, 왜 실패하는지에 대한 직관적이면서도 증거 기반의 감각이다.

인프라를 직접 걸어볼 수 있는 도시로 여기고, 위험한 동네를 안전하게 탐험하는 도구로 사이버-물리 테스트베드를 활용하고, 포스트모템을 현실에 단단히 연결해 줄 아날로그 장애 현장 노트를 유지하면, 우리는 신뢰성 공학의 진짜 목표에 더 가까이 다가간다.

단지 장애를 고치는 데서 그치지 않고, 다음 장애가 더 짧고, 더 작거나, 아예 일어나지 않게 만들 만큼 충분히 잘 이해하는 것.

이미 시작에 필요한 도구는 갖추고 있다. 호기심, 걸어볼 시스템, 그리고 뭔가를 적을 수 있는 도구 하나. 나머지는 연습의 몫이다.