아날로그 신뢰성 스토리 철도 정비소 나침반

사소한 라우팅 선택이 어떻게 대규모 장애로 번지는지 손으로 그려 보기

현대 시스템은 직관적이지 않은 방식으로 망가집니다. 아주 작은 로컬 라우팅 수정, “임시” 방화벽 규칙, 사소해 보이는 DNS 단축 설정—각각은 따로 보면 별문제 없어 보입니다. 하지만 특정한 압력이 걸리면 이 작은 결정들이 서로 얽히고 증폭되며, 어느 순간 임원과 고객에게 대규모 장애를 설명하고 있는 자신을 발견하게 됩니다.

이 글은 그런 실패 경로가 먼저 여러분을 덮치기 전에, 여러분이 먼저 볼 수 있게 해 주는 실용적인 방법을 소개합니다. 이름은 길지만 아이디어는 단순한 **“아날로그 신뢰성 스토리 철도 정비소 나침반(Trainyard Compass)”**입니다. 시스템을 철도 정비소(철도 차량 기지)처럼 그려 놓고, 그 안에서 기차(트래픽, 의존성, 실패)가 어떻게 움직이는지 이야기를 만들어 보며, 그 아날로그 지도를 신뢰성 리스크를 탐색하는 나침반처럼 사용하는 방식입니다.

기술적으로 일부러 저(低)기술입니다. 종이, 화이트보드, 포스트잇, 그리고 대화. 한 번 선로가 어떻게 연결돼 있는지 보이기 시작하면, 작은 라우팅·인프라 선택이 어떻게 큰 연쇄 장애로 전파되는지 이해하기 훨씬 쉬워집니다.

디지털 세상에 왜 아날로그 지도가 필요한가

대부분의 조직에는 이런 것들은 있습니다.

• 네트워크 다이어그램(대개 금방 낡아버립니다)
• 의존성 그래프(최고로 잘 돼 봐야 부분적입니다)
• 클라우드 대시보드(너무 세세해서 큰 그림을 보기 어렵습니다)

보통 빠져 있는 것은 스토리를 얹을 수 있는, 사람 규모의 비즈니스 리스크 지도입니다. “서버가 어디 있나?” 대신에, 진짜 궁금한 것은 이런 것들입니다.

돈이 어디로 흐르는가? 고객에게 한 중요한 약속은 어디에 자리 잡고 있는가? 그리고 현실적으로 실패가 흘러갈 수 있는 경로는 어디인가?

이 질문은 자동 생성된 다이어그램만으로는 답할 수 없습니다. 다음과 같은 일을 돕는, 공유된 멘탈 맵이 필요합니다.

• 비즈니스 리스크를 시스템과 의존성에 명시적으로 매핑하고,
• 로컬한 결정이 어떻게 글로벌한 실패 경로를 만들 수 있는지 보고,
• 단순한 기술적 완벽함이 아니라 실제 영향도에 따라 신뢰성 작업의 우선순위를 정하는 것.

여기서 철도 정비소 나침반(Trainyard Compass)이 등장합니다.

철도 정비소 비유: 선로, 분기기, 그리고 연쇄 붕괴

여러분의 아키텍처를 철도 정비소라고 상상해 봅시다.

• 기차(Trains) = 트래픽, 잡, 사용자 요청, 데이터 흐름
• 선로(Tracks) = 네트워크 경로, 메시지 큐, 복제 링크, API 호출
• 분기기(Switches) = 라우팅 규칙, DNS 설정, 기능 플래그(feature flag), 로드 밸런서
• 역(Stations) = 서비스, 데이터베이스, 외부 제공자

한가한 시간에는 이 정비소가 꽤 질서 정연해 보입니다. 그러나 부하가 몰리거나 부분 장애가 발생하면, 작은 라우팅 결정—선로 하나를 더 깐다든지, 분기기를 잘못 설정한다든지, 역 하나가 약간 과부하 상태가 된다든지—가 원치 않는 방향으로 기차를 흘려보내 버릴 수 있습니다.

여기에 상호 의존성을 더해 봅시다. 역들끼리 전력, 신호, 용량을 서로 의존하는 상황입니다. 여기서 네트워크 과학의 Motter–Lai 모델 같은 개념이 유효합니다. 핵심 아이디어는 이렇습니다.

• 구성 요소는 홀로 실패하지 않습니다.
• 하나가 실패하거나 과부하가 되면, 그 부하가 이웃에게 전가됩니다.
• 이웃도 과부하가 되면, 다시 주변을 무너뜨리며 연쇄적인 실패(cascade) 를 만듭니다.

여러분 환경에서 이건 대략 다음과 같이 보일 수 있습니다.

• 라우팅 변경으로 더 많은 트래픽이 보조 리전에 몰립니다.
• 보조 리전의 DB 레플리카가 갑자기 2배의 부하를 받습니다.
• 복제가 밀리면서(read replica lag), 읽기 쿼리가 느려지고 큐가 쌓입니다.
• 다른 서비스들은 재시도를 더 자주 하며 부하를 더 키웁니다.
• 결국 두 리전 모두 성능이 저하되고—상태 페이지에 빨간 불이 켜집니다.

이 장애는 “데이터베이스가 죽었다”에서 시작한 게 아닙니다. 복잡하게 얽힌 네트워크에서 아주 사소한 라우팅 선택에서 시작한 겁니다.

1단계: 토폴로지가 아니라 비즈니스 리스크부터 그리기

선로나 기차를 그리기 전에 먼저 물어봐야 할 질문은 이것입니다. 우리가 진짜 잃고 싶지 않은 것은 무엇인가? 예를 들어:

• 고객이 로그인할 수 있는 능력
• 결제를 받을 수 있는 능력
• 주문 기록의 무결성
• 경고 알림의 적시성

각 핵심 비즈니스 기능에 대해 다음을 적어 둡니다.

• 이게 실패하면 고객에게 무엇이 깨지는지
• 대략적인 금전적·평판 리스크(3단계 정도의 러프한 스케일이면 충분함)
• 시간 민감도(몇 초, 몇 분, 몇 시간 단위인가)

그다음 이 비즈니스 기능들을 이를 떠받치는 시스템들에 연결합니다.

• “로그인은 다음에 의존: 인증 API, 사용자 DB, IdP로 가는 네트워크 경로, DNS”
• “결제는 다음에 의존: 체크아웃 API, 결제 게이트웨이, 메시지 버스, 카드 네트워크, 이메일 제공자”

이렇게 하면 출발점이 비즈니스 중심이 됩니다. 여러분의 철도 정비소는 단순 기술 지도가 아니라, 실제 매출과 고객 약속에 정렬된 구조가 됩니다.

2단계: 철도 정비소를 손으로 그리기

화이트보드나 종이를 준비합니다. 여러 팀에서 엔지니어들을 모읍니다. 그리고 한 가지 비즈니스 기능을 골라 해당 기능에 대한 철도 정비소를 손으로 그려 봅니다. 대충 그려도 되지만, 다음은 꼭 포함하세요.

• 역(서비스 / 컴포넌트): 박스로 그립니다.
• 선로(경로 / 의존성): 화살표로 그리고, “HTTP”, “VPN”, “replication”, “Kafka 토픽” 같은 라벨을 붙입니다.
• 분기기(라우팅과 결정 지점): 로드 밸런서, DNS, 기능 플래그, 페일오버 규칙 등을 표시합니다.

그리고 이렇게 물어봅니다.

• 평상시에는 트래픽이 어디로 간다고 가정하고 있는가?
• 페일오버 같은 비정상 상황에서—이상한 케이스까지 포함해—트래픽이 실제로 갈 수 있는 곳은 어디까지인가?
• 어떤 역이 여러 기차가 공유하는 지점인가? (공유 DB, 공유 큐, 공유 캐시, 공유 네트워크 세그먼트 등)

목표는 정밀함이 아닙니다. 목표는 구조와 상호 의존성에 대한 공유된 이해입니다.

3단계: 추적 매트릭스로 연쇄 시나리오 만들기

이제 이 그림을 바탕으로, 어떻게 일이 잘못될 수 있는지에 대한 스토리를 만듭니다. 이를 체계적으로 하기 위해 위협·취약성 추적 매트릭스(threat & vulnerability traceability matrix) 를 사용합니다.

가장 단순한 형태의 매트릭스는 다음을 연결합니다.

• 취약점 / 약점(Vulnerabilities / Weaknesses) →
• 방아쇠 이벤트(Triggering Events) →
• 전파 경로(Propagation Path) →
• 사고 전형 / 비즈니스 영향(Incident Archetype / Business Impact)

간단한 예시는 다음과 같습니다.

이제 팀이 함께 다음을 따라가 봅니다.

1. 작은 로컬 선택을 하나 고릅니다. NAT 규칙, 기능 플래그, 새로운 라우팅 정책, 공유 큐 등.
2. 그럴듯한 트리거를 하나 만듭니다. 페일오버, 트래픽 급증, 부분적인 클라우드/ISP 장애, 잘못된 설정의 배포 등.
3. 기차를 따라갑니다. 부하는 어디로 흘러가는가? 어떤 분기기가 자동으로 어떻게 전환되는가? 어떤 공유 역들이 타격을 받는가?
4. 사고 전형에 이름을 붙입니다. 이건 “재시도 폭풍(retry storm)”인가, “페일오버 연쇄(failover cascade)”인가, “느린 부분 장애(slow partial outage)”인가, “조용한 데이터 손상(silent corruption)”인가, 아니면 다른 무엇인가?

이걸 문서화하면 추적성이 생깁니다. 사소한 문제가 어떻게 확대되어, 이름 붙일 수 있는 구체적 사고 패턴으로 발전하는지 한눈에 볼 수 있습니다. “어딘가 문제가 있을지도 모른다”보다 훨씬 행동 가능성이 높습니다.

4단계: 신뢰성을 레드팀 연습처럼 다루기

보안팀은 방어 체계를 점검하기 위해 레드팀(red teaming) 을 사용합니다. 신뢰성 팀도 아키텍처와 라우팅 결정을 대상으로 같은 방식을 쓸 수 있습니다.

신뢰성 레드팀 세션에서는:

• 한 그룹이 “블루팀(blue team)” 역할을 하며 시스템이 어떻게 동작해야 하는지 설명합니다.
• 다른 그룹이 “레드팀(red team)” 이 되어 “이걸 어떻게 spectacular하게(극적으로) 망가뜨릴 수 있을까?”를 묻습니다.

레드팀이 찾는 것은 대략 이런 것들입니다.

• 숨은 병목이 될 수 있는 단일 공유 역(공유 리소스)
• 장애 시 비대칭적인(asymmetric) 동작을 하는 분기기(예: fail‑open vs fail‑closed)
• 드물게만 존재하는 경로(수동 페일오버, 비상 매뉴얼에만 나오는 절차 등)
• 재시도, 타임아웃, 백프레셔(backpressure)가 불분명하거나 서비스마다 제각각인 지점

마인드셋 전환이 핵심입니다.

목표는 시스템이 견고하다는 걸 증명하는 게 아닙니다. 프로덕션에서 깨지기 전에, 종이 위에서 먼저 부숴 보는 것입니다.

이런 “적대적” 프레이밍은 팀이 제약과 미지의 영역을 더 솔직하게 이야기하게 만들고, 더 나은 보호장치가 필요한 라우팅 선택을 드러나게 합니다.

5단계: 안전한 ‘카오스 환경’에서 연습하기

생각만으로는 부족합니다. 팀은 실제로 실패 경로를 다루는 연습을 해야 합니다. 하지만 풀스케일 GameDay는 부담이 큽니다.

• 운영 준비와 조율이 복잡합니다.
• 프로덕션에서 실행하기에는 리스크가 큽니다.
• 카오스 엔지니어링에 익숙하지 않은 팀에겐 위압적입니다.

먼저 더 작은 규모의 안전한 카오스 환경(safe chaos environment) 과 가이드된 연습부터 시작할 수 있습니다.

• 중요한 토폴로지를 (축소판이라도) 반영한 스테이징 또는 샌드박스 환경을 준비합니다.
• 스크립트화된, 폭발 반경이 작은 실험을 수행합니다: 의존성을 잠깐 끊어 보기, 네트워크 링크를 느리게 하기, DNS 오구성을 시뮬레이션하기 등.
• 여러분이 만든 아날로그 지도를 시나리오 스크립트로 사용합니다. “지난주에 스케치해 본 그 연쇄 시나리오를 이번엔 진짜 환경에서 따라가 보자. 현실이 스토리와 얼마나 맞는지 보자.”

이 워크숍을 통해 팀은 다음을 할 수 있습니다.

• 아날로그 철도 정비소 지도를 검증하거나 수정합니다.
• 숨어 있던 커플링이나 예상치 못한 경로를 발견합니다.
• 탐지, 커뮤니케이션, 완화(mitigation)를 연습합니다.

이건 단순히 다이어그램을 만드는 게 아니라, 장애 대응의 근육 기억(muscle memory) 을 만드는 작업입니다.

6단계: 연습에서 신뢰성 문화로 성장시키기

시간이 지나면, 작은 워크숍에서 출발해 다음과 같은 성숙한 형태로 발전할 수 있습니다.

• 특정 사고 전형 하나에만 스코프를 둔 반(半)정기적 미니 GameDay (예: “재시도 폭풍 데이”)
• 공유 철도 정비소 지도와 추적 매트릭스를 유지·관리하는 크로스팀 신뢰성 위원회
• 새로운 라우팅 변경이나 의존성이 도입될 때마다, 철도 정비소 지도를 기준으로 한 사전 배포 리스크 리뷰

물론 풀스케일 GameDay도 여전히 중요합니다. 특히 조직 전체의 준비 상태를 검증하는 데 유용합니다. 하지만 이제 그것은 지속적인 신뢰성 매핑 실천(continuous reliability mapping practice) 안에 있는 도구 중 하나일 뿐, 1년에 한 번 열리는 특별 행사에 그치지 않습니다.

이상적인 문화에서는:

• 의미 있는 라우팅·인프라 결정이 있을 때마다, 자연스럽게 이런 질문이 나옵니다. “이건 우리 철도 정비소에 어떤 새로운 기차와 분기기를 추가하는 거지?”
• 팀들이 새로운 서비스와 의존성 변화를 수시로 손으로 매핑합니다.
• 비즈니스 리더들도 자신들의 매출이 실제로 어떤 선로를 타고 흐르는지 이해하고 있습니다.

결론: 탈선하기 전에 철도 정비소부터 그려라

장애는 좀처럼 크고 명백한 실패에서 시작되지 않습니다. 대개는 시스템의 상호 의존성에 대한 전체 그림 없이 내린, 작고 로컬한 선택에서 시작됩니다.

아날로그, 스토리 중심 접근법—철도 정비소 나침반(Trainyard Compass)—을 활용하면 다음을 할 수 있습니다.

• 비즈니스 리스크를 시스템과 경로에 명시적으로 매핑하고,
• 아주 작은 라우팅·인프라 선택이 어떻게 전파되는지 보고,
• 추적 매트릭스로 취약점을 구체적인 사고 전형과 연결하고,
• 레드팀식 신뢰성 세션으로 종이 위에서 아키텍처를 극한까지 몰아붙여 보고,
• 풀스케일 GameDay 전에 카오스 워크숍에서 안전하게 연습할 수 있습니다.

완벽한 툴링이 없어도 시작할 수 있습니다. 필요한 건 화이트보드, 적절한 사람들이 한자리에 모이는 것, 그리고 이런 질문을 던질 용기입니다.

이 작은 분기기 하나가 잘못 꺾이면, 어떤 기차를 어떤 역으로 보낼 수 있을까? 그리고 그 충돌이 실제로 얼마나 심각해질 수 있을까?

이 질문을 꾸준히 던지다 보면, “작은 변경”이 아주 큰 장애를 불러온 사건에 대한 포스트모텀을 쓰는 대신, 그 시간에 신뢰성 자체를 개선하는 데 더 많은 에너지를 쏟게 될 것입니다.