아날로그 인시던트 스토리 트레인야드 오러리

오늘날 대부분의 장애는 하나의 전등 스위치가 탁 꺼지는 모습과는 다르다. 오히려 슬로 모션으로 벌어지는 열차 사고에 가깝다. 한 대의 열차가 탈선하고, 그 힘에 끌려 다음 열차가 선로에서 벗어나고, 사람들이 상황을 완전히 이해하기도 전에 기차역 절반이 엉망이 된다.

대규모 엔터프라이즈 시스템에서도 **연쇄 장애(cascading failure)**의 본질은 이와 같다. 과부하된 큐, 오래된 캐시 항목, 잘못 설정된 기능 플래그 같은 아주 작은 국지적 결함이 서비스, 데이터 스토어, 비즈니스 프로세스를 가로질러 전파된다. 처음에는 사소한 불편으로 보이던 일이 곧 여러 계층에 걸친 장애로 확산되고, 이해하기도 어렵고 설명하기는 더 어려운 상황으로 바뀐다.

디지털 대시보드, 트레이스, 인시던트 타임라인은 분명 도움이 되지만, 결국 화면 위의 추상화에 머문다. 만약 이런 연쇄 장애를 물리적인 움직임으로 볼 수 있다면 어떨까? 책상 위에 작은 모형을 올려 두고, 살짝 태엽을 감아 돌리면 결함이 시간이 지나며 시스템 전체를 어떻게 파고드는지 눈앞에서 지켜볼 수 있다면?

그래서 등장한 것이 **아날로그 인시던트 스토리 트레인야드 오러리(Analog Incident Story Trainyard Orrery)**다. 이는 시계장치에서 영감을 얻은 테이블탑 시각화 장치로, 연쇄 장애를 손으로 만질 수 있는 기계적 이야기로 바꿔준다.

연쇄 장애가 위험한 이유 (그리고 왜 그렇게 보이지 않는지)

연쇄 장애는 엔터프라이즈 시스템에서 가장 위험한 리스크 유형 가운데 하나다. 그 이유는 이들이 다음과 같은 특성을 갖기 때문이다.

• 분산됨(Distributed) – 어느 한 서비스가 ‘장애의 소유자’가 아니다. 여러 곳에서 증상이 동시에 나타난다.
• 시간 의존적(Temporal) – 문제가 한 순간에 터지는 게 아니라, 몇 분에서 몇 시간에 걸쳐 전개된다.
• 다층적(Layered) – 인프라, 플랫폼, 비즈니스 로직이 서로 미묘한 방식으로 얽혀 상호작용한다.

전형적인 패턴은 대략 이렇게 흘러간다.

1. 국지적 결함이 발생한다. (예: 의존 서비스가 느려짐, 배치 잡이 시간을 초과함, 서킷 브레이커 설정 오류 등)
2. 상위 서비스는 재시도나 폴백 등으로 문제를 보완하려 하지만, 그 과정에서 공통 컴포넌트에 대한 부하를 증폭시킨다.
3. 큐가 가득 차고, 캐시가 뒤엉키며, 트래픽이 우회되면서 2차 장애가 겉보기에 무관한 서비스들에서 발생한다.
4. 이 서비스들을 기반으로 하는 비즈니스 프로세스 역시 차례로 실패하며, 결국 고객이 체감하는 문제로 이어진다.

시스템 내부에 있는 사람 입장에서는, 마치 어두운 방에서 도미노가 쓰러지는 걸 보는 느낌에 가깝다. 첫 번째 도미노가 쓰러지는 것도 보고, 마지막 도미노가 바닥에 누워 있는 것도 보지만, 그 사이에 무슨 일이 있었는지는 메트릭과 로그, 절반쯤 가설에 그친 추측들 속에 흐릿하게 묻힌다.

이런 사건을 제대로 이해하려면, 단순히 데이터만으로는 부족하다. 팀은 **장애가 시간과 의존성 그래프를 따라 어떻게 움직이는지에 대한 정신적 모델(mental model)**이 필요하다.

시간과 의존성을 동시에 시각화하기

대부분의 도구는 아래 둘 중 하나는 잘한다.

• 의존성 다이어그램: 누가 누구와 통신하는지는 잘 보여주지만, 언제 문제가 생겼는지는 보여주지 못한다.
• 타임라인: 언제 무슨 일이 일어났는지는 보여주지만, 그것이 시스템 구조와 어떻게 연결되는지는 담지 못한다.

연쇄 장애는 이 둘의 교차점에 존재한다. 즉, 시간에 묶여 있으면서 의존성의 그물망을 타고 움직이는 현상이다.

여기에서 물리적인, 시계장치 같은 모델이 힘을 발휘한다. 만약 다음과 같이 할 수 있다면:

• 컴포넌트를 기어, 선로, 궤도, 열차 칸에 대응시키고,
• 시간을 회전 운동에 대응시킨다면,

추상적인 시스템 동역학을 연속적인 기계 이벤트로 눈앞에서 드러낼 수 있다. 정적인 아키텍처 다이어그램 대신, **움직이는 이야기(story-in-motion)**를 갖게 되는 셈이다.

행성에서 패킷까지: 왜 ‘인시던트용 오러리’인가?

**오러리(orrery)**는 태양계를 기계적으로 표현한 모형이다. 복잡하게 얽힌 기어와 팔이 행성을 태양 주변 궤도 위에서 규칙적으로 움직이게 한다. 수 세기 동안 사람들은 이 장치를 통해 복잡한 천체 역학을 손으로 돌려볼 수 있는 구체적 대상물로 바꾸어 이해해 왔다.

이처럼 기계적인 시각화(오러리 같은)는 강력하다. 이유는 다음과 같다.

• 질서 있는 움직임을 강제한다 – 모든 것은 명확한 규칙에 따라 움직인다.
• **주기성과 위상(phase)**를 눈에 보이게 만든다 – 언제 궤도가 정렬되는지 한눈에 보인다.
• 원래는 보이지 않는 **힘(중력, 공명 등)**을 기어비와 연결 구조라는 형태로 드러낸다.

인시던트 스토리 트레인야드 오러리는 이 아이디어를 그대로 가져온다. 행성 대신 서비스와 비즈니스 기능을, 중력 대신 지연(latency), 부하(load), 장애 전파를 사용한다. 태양을 도는 천체 대신, 복잡한 선로와 분기, 측선 사이를 움직이는 열차를 배치한다.

여기서 기차역(trainyard) + 오러리라는 하이브리드 은유를 택한 것은 의도적이다.

• 기차역 메타포는 라우팅, 혼잡, 충돌을 표현하기 좋다. 연쇄 장애를 나타내기에 적합하다.
• 오러리 메타포는 시간, 순서, 주기를 표현하기 좋다. 인시던트가 어떻게 전개되는지 모델링하는 데 이상적이다.

내 책상 위의 트레인야드 오러리를 상상해 보기

책상 위에 놓인 나무 받침대를 떠올려 보자. 그 위로 반짝이는 금속 선로가 격자처럼 올라와 동심원 형태를 이루고 있다. 안쪽 링은 코어 인프라를, 바깥 링으로 갈수록 고객 접점 서비스와 비즈니스 프로세스를 표현한다.

받침대 아래에는 전체 시스템을 움직이는 시계장치(clockwork) 메커니즘이 숨겨져 있다.

• 중앙의 **구동 기어(drive gear)**는 최초 인시던트 트리거를 나타낸다.
• 그 주변의 2차 기어들은 중요한 의존성(데이터베이스, 캐시, 메시지 버스 등)을 나타낸다.
• 바깥쪽의 기어들은 선로 위를 움직이는 **열차 칸(train car)**을 구동한다. 각 열차에는 서비스나 기능 이름이 적혀 있다.

태엽 키를 감으면, 시스템이 움직이기 시작한다.

특정 지점에서 작은 색깔 토큰 하나가 선로 위로 떨어진다. 이게 바로 최초 결함이다. 메커니즘이 돌아가면서 다음과 같은 일이 벌어진다.

• 토큰이 한 분기점에 도달하는데, 이 분기점은 재시도를 매우 공격적으로 수행하는 서비스를 나타낸다. 이 지점에서 토큰이 세 개의 작은 토큰으로 나뉜다. 곧, 증폭된 부하를 의미한다.
• 분리된 토큰들은 여러 선로로 흩어져 나간다. 이는 인접 서비스들을 나타내며, 이 서비스들은 오류 플래그가 켜지면서 열차가 서서히 느려지기 시작한다.
• 메커니즘 내부 깊숙한 곳, 데이터베이스를 뜻하는 기어가 특정 표시 구간에 도달하면서 미끄러지기 시작한다. 이는 지연 증가나 부분 장애를 상징한다.
• 가장 바깥 링에서는 한 비즈니스 프로세스 열차가 건널목 앞에서 멈춰 선다. 주문이 완료되지 못하거나, 리포트가 생성되지 않는 상황이다.

1~2분 정도의 움직임만으로, 이 오러리는 인시던트의 시간적 이야기 전체를 들려준다. 최초의 작은 결함에서부터 눈에 보이는 비즈니스 영향에 이르기까지의 여정을.

이 모델이 팀에게 보여주는 것들

트레인야드 오러리 같은 아날로그 모델은 대시보드나 트레이스를 대체하지 않는다. 대신, 고스트레스 인시던트 상황에서 팀이 흔히 놓치는 것을 제공한다. 바로 지금 무슨 일이 일어나고 있으며, 왜 그런지에 대한 공유되고 직관적인 이야기다.

구체적으로, 이 모델은 팀에 다음과 같은 도움을 준다.

1. 인시던트 이전에 리스크를 추론하기

중요 컴포넌트를 두드러진 기어와 선로에 매핑해 두면 다음과 같은 것들이 드러난다.

• 여러 선로와 교차하는 단일 장애점(SPOF, Single Point of Failure)
• 문서상으로는 독립적으로 보이지만 실제로는 긴밀하게 얽힌 서비스 간의 강한 결합(tight coupling)
• 재시도, 타임아웃, 스케줄 잡이 서로를 강화하는 숨겨진 피드백 루프

팀은 오러리를 천천히 돌리며 이렇게 물어볼 수 있다.

“이 기어가 멈추면, 그다음에는 무엇이 영향을 받지?”

이렇게 하면 추상적인 리스크 논의를 손으로 만져보는 시나리오 플래닝으로 바꿀 수 있다.

2. 장애 중 커뮤니케이션 정렬하기

인시던트가 한창일 때 언어는 쉽게 혼란스러워진다. 한 팀은 “DB는 멀쩡하다”고 말하고, 다른 팀은 “API가 죽었다”고 하고, 또 다른 팀은 그저 에러율 상승만 보고 있을 수 있다.

오러리는 이런 상황에서 **물리적인 커뮤니케이션 기준점(anchor)**이 될 수 있다.

• 인시던트 리드는 손가락으로 가리키며 말할 수 있다. “우리는 결함이 여기서 시작되었다고 보고 있고, 지금은 이 바깥 링의 세 프로세스를 막고 있습니다.”
• 이해관계자는 모델의 진행 상황을 보면서, 직접 눈으로 확인한 움직임을 바탕으로 질문을 던질 수 있다. 복잡한 차트를 해석하는 대신 말이다.

심지어 단순화된 상징적 버전만 있어도, 모두가 발생 순서와 영향 범위에 더 빨리 합의하는 데 도움이 된다.

3. 인시던트 스토리 캡처 및 리플레이

사건이 끝난 뒤 팀은 보통 포스트 인시던트 리뷰(사후 분석 보고서)를 작성한다. 하지만 글과 스크린샷만으로는 연쇄 장애의 역동적인 느낌을 제대로 전하기 어렵다.

트레인야드 오러리를 사용하면 인시던트를 기계적인 리플레이로 재현할 수 있다.

• 선로에 색깔 표시를 해서 타임라인을 표현할 수 있다. (예: “5분 시점에 이 서비스가 느려졌고, 12분 시점에 이 서비스가 실패했다.”)
• 특정 고장 모드를 모델링하기 위해 어떤 기어가 ‘미끄러지거나’ 멈추도록 설정할 수 있다.
• **완화 조치(traffic drain, 기능 플래그 토글, 수동 라우팅 변경 등)**를 떼었다 붙일 수 있는 열차나 토큰으로 표현할 수 있다.

이렇게 하면 사후 분석 과정이 정적인 문서에서 벗어나, 장애가 어떻게 전개되었고 우리가 어떤 대응을 했는지를 보여주는 구체적인 데모로 바뀐다.

나만의 아날로그 인시던트 모델 설계하기

이 아이디어를 실천하는 데 꼭 공방이나 CNC 머신이 필요한 것은 아니다. 작은 것부터 시작해도 충분하다.

1. 팀에 잘 맞는 메타포를 고른다.

   • 선로와 분기, 측선이 있는 기차역(trainyard)
   • 여러 바늘과 복잡한 기구를 가진 시계(clock)
   • 궤도와 기어가 있는 오러리(orrery)

2. 시스템의 계층을 물리적 구조에 매핑한다.

   • 안쪽 링: DB, 큐, DNS, 인증(Auth) 같은 코어 인프라
   • 중간 링: 공용 서비스와 플랫폼 레이어
   • 바깥 링: 고객 접점 애플리케이션과 비즈니스 워크플로

3. 시간을 ‘움직임’으로 표현한다.

   • 회전, 특정 지점을 지나가는 횟수, 다이얼의 틱(tick) 등

4. 장애 전파를 기계적 상호작용으로 인코딩한다.

   • 한 기어가 멈추면 바깥 링의 움직임이 느려지거나 멈춘다.
   • 한 레버(재시도 정책이나 스로틀링 정책)가 내려가면 ‘트래픽’이 다른 선로로 우회한다.

5. 실제 팀 의식(ritual)에 녹여 활용한다.

   • 아키텍처 리뷰:

     “이 캐시가 실패하면 두 계층 바깥에 있는 매출 리포팅에 어떤 영향이 가는지 보여줘.”

   • 인시던트 프리모텀(pre-mortem):

     “모델을 돌려 보면서 아직 완화하지 못한 현실적인 연쇄 장애 경로를 세 가지 찾아보자.”

   • 포스트 인시던트 리뷰:

     “우리가 지금 이해하고 있는 순서대로, 실제로 무슨 일이 있었는지 물리적으로 다시 재생해 보자.”

목표는 ‘현실을 1:1로 복제하는 것’이 아니다. 목표는 **공유된 이해(shared understanding)**를 만드는 것이다.

디지털 세상에서 아날로그 스토리 모델이 여전히 중요한 이유

처음 보면, 클라우드 네이티브 분산 시스템을 이해하기 위해 시계장치 데스크 모델을 쓰자는 얘기는 시대착오적으로 들릴 수 있다. 하지만 바로 그 대비가 핵심이다.

물리적 모델은 다음과 같은 효과를 준다.

• 속도를 살짝 늦춰 주어, 노이즈 대신 구조를 보게 한다.
• 각자의 대시보드에 파편화되지 않고, 하나의 공유 객체를 중심으로 협업하게 만든다.
• 보이지 않고 차원이 높은 행동을 시작–중간–끝이 있는 구체적인 이야기로 바꾸어 준다.

시스템이 커지고 상호 연결이 많아질수록 연쇄 장애는 더 자주, 더 복잡하게 일어날 것이다. 이런 상황에서 탁월한 대응을 하는 조직은 더 정교한 도구만 가진 조직이 아니다. 장애가 시간과 의존성 위를 어떻게 흐르는지에 대한 풍부한 정신적 모델을 갖춘 조직이다.

아날로그 인시던트 스토리 트레인야드 오러리는 이런 정신적 모델을 구축하는 하나의 방법이다. 현대 장애의 가장 포착하기 어려운 측면을, 손으로 집어 들 수 있는 물건으로 바꾸는 시도다.

결론

연쇄 장애는 복잡하고, 동시에 보기가 어렵기 때문에 위험하다. 하나의 작은 국지적 장애가 인프라와 비즈니스 로직의 여러 층을 타고 번지면서, 사소한 glitch를 대형 장애로 증폭시킨다.

시계장치와 천체 역학에서 아이디어를 가져온 트레인야드 오러리 개념은 이러한 역학을 손에 잡히는 형태로 바꾸는 방법을 제시한다. 의존 관계를 시각적으로 배치하고, 시간에 따라 움직이게 함으로써, 인시던트 내러티브를 물리적 이야기로 만든다. 누가 먼저 실패했고, 그다음은 누가 실패했으며, 한 서비스의 고통이 어떻게 다른 서비스의 장애로 이어졌는지를 보여준다.

실제 아키텍처를 완벽히 복제한 기계 장치를 만들 필요는 없다. 거칠고 단순한 아날로그 스토리 모델만으로도 팀이 리스크, 커뮤니케이션, 복구 전략에 대해 생각하는 방식을 바꿀 수 있다. 고속이고, 금방 사라지는 장애가 늘어나는 세상에서, 작지만 의도적인, 눈에 보이는 시계장치 하나가 인시던트 대응 체계에 꼭 필요했던 ‘마지막 퍼즐 조각’일지도 모른다.