Rain Lag

아날로그 인시던트 스토리 기차역 랜턴 맵: 종이 위에서 드러나는 숨은 신뢰성 블라인드 스폿

신뢰성 블록 다이어그램(RBD), 인시던트 리뷰, 아날로그 테이블탑 맵을 결합해 복잡한 시스템 속에 숨어 있는 신뢰성 리스크를 함께 찾아내고 개선하는 강력한 도구를 만드는 방법.

아날로그 인시던트 스토리 기차역 랜턴 맵: 숨은 신뢰성 블라인드 스폿을 드러내는 테이블탑 종이 네트워크 설계하기

디지털 시스템은 추상적이고, 눈에 보이지 않으며, 방대하게 퍼져 있습니다. 장애가 나면, 그 실패 양상은 머릿속으로 그리기도 어렵고, 당사자 팀 밖 사람들에게 설명하기는 더 어렵습니다. 대시보드, 그래프, 런북은 도움은 되지만, 종종 기존의 머릿속 모델을 도전하기보다는 그대로 강화하는 역할을 합니다.

여기서 아날로그 도구가 놀라운 힘을 발휘할 수 있습니다. 이 글에서는 **“인시던트 스토리 기차역 랜턴 맵(Incident Story Trainyard Lantern Map)”**이라는 아이디어를 소개합니다. 이것은 테이블 위에 펼치는 종이 기반의, 신뢰성 블록 다이어그램(Reliability Block Diagram, RBD)에서 영감을 얻은 시스템 맵으로, 신뢰성에 대한 우리의 숨은 블라인드 스폿을 밝혀주는 도구입니다.

이 과정에서 다음과 같은 핵심 실천들을 하나로 엮어 봅니다.

  • 시스템이 실제로 어떻게 **버티고(또는 죽는지)**를 모델링하는 신뢰성 블록 다이어그램(RBD)
  • 증상만 때우는 게 아니라, 인시던트 리뷰 / 포스트모템을 통해 장애 패턴을 끌어내는 작업
  • 우리가 의존하고 있다는 사실조차 몰랐던 컴포넌트와 패키지를 드러내는 의존성 맵핑
  • 엔지니어, 매니저, 주변 스테이크홀더가 함께 이해를 공유하게 해주는 아날로그, 촉각적 시각화

결과물은 하나의 살아 있는 물리적 맵입니다. 개별 인시던트들이 이 맵 위에서 랜턴이 되어, 우리가 가진 신뢰성 가정과 실제 현실이 어긋나는 지점을 밝혀줍니다.

신뢰성 블록 다이어그램에서 스토리 맵으로

**신뢰성 블록 다이어그램(Reliability Block Diagram, RBD)**은 전통적인 신뢰성 엔지니어링과 안전 필수(safety-critical) 도메인에서 쓰이는 고전적인 도구입니다. 시스템을 블록과 커넥터의 네트워크로 표현하며, 각 블록은 컴포넌트(서비스, 데이터베이스, API, 심지어 사람이나 프로세스까지)를 의미하고, 연결선은 이 컴포넌트들이 어떻게 조합되어 하나의 결과를 만들어내는지를 보여줍니다.

가장 단순한 수준에서 보면:

  • 직렬(Series) 컴포넌트: 시스템이 동작하려면 모두 다 정상이어야 합니다. 하나만 실패해도 전체 실패입니다.
  • 병렬(Parallel) 컴포넌트: 여러 개 중 하나만 살아 있어도 됩니다. 이게 바로 **중복성(redundancy)**입니다.

RBD의 장점은 다음과 같습니다.

  • 의존성을 명시적으로 드러내도록 강제합니다.
  • 다양한 시나리오에서 *“이게 실패하면 어떻게 되지?”*를 쉽게 물어볼 수 있습니다.
  • 어디에 중복성을 추가하거나, 어디부터 하드닝(hardening)을 해야 할지 우선순위를 정하는 데 도움을 줍니다.

하지만 빠르게 움직이는 소프트웨어 조직에서 RBD는 종종 Confluence나 특수 모델링 툴 속 정적인 다이어그램으로만 존재합니다. 강력하긴 하지만, 사회적 도구로 쓰이진 못하는 경우가 많습니다.

인시던트 스토리 기차역 랜턴 맵은 이 RBD의 정신을 가져와, 모두가 둘러앉아 함께 수정하고 확장할 수 있는 공유 아날로그 아티팩트로 바꾸는 시도입니다. 책상, 벽, 화이트보드 어디든 크게 펼쳐 놓고 다 같이 만질 수 있는 형태로 만드는 것입니다.

왜 굳이 인시던트를 종이 위에 맵핑해야 할까?

팀에는 이미 Jira 티켓, 인시던트 타임라인, 아키텍처 다이어그램이 있습니다. 그럼에도 종이를 하나 더 들여오는 이유는 무엇일까요?

1. 아날로그 맵은 생각을 ‘건설적으로’ 느리게 만듭니다.
물리적인 맵은 자동 조종 모드에서 빠져나오게 합니다. 미묘한 의존성이나 마이크로서비스 묶음을 스크롤로 휙 넘길 수 없습니다. 하나하나 직접 배치하고, 연결하고, 멀리서 전체를 바라봐야 합니다.

2. 역할을 가로지르는 공용 언어를 만들어 줍니다.
엔지니어, SRE, PM, 심지어 임원까지 모두 같은 도형과 화살표를 가리킬 수 있습니다. 복잡한 신뢰성 대화가 지하철 노선도 설명처럼 바뀝니다.
“여기가 메인 간선(line)이고, 여기가 허약한 지선이고, 여기에서 지연이 생겼어요.”

3. ‘그림자 의존성’과 숨은 컴포넌트가 떠오릅니다.
사용자 행동에서 장애 지점까지의 경로를 실제로 그려 나가다 보면, 다음 같은 것들과 마주치게 됩니다.

  • 중요성을 잊고 있던 서드파티 API
  • 수많은 서비스에서 공유하는 라이브러리와 패키지
  • 아무도 제대로 소유하지 않는 일회성 스크립트나 크론 잡(cron job)

이들은 전형적인 신뢰성 블라인드 스폿인데, 디지털 다이어그램에서는 종종 흐릿하게 처리되거나 아예 빠져버립니다.

4. 디지털 도구를 대체하는 게 아니라, 사이를 잇는 브리지입니다.
목표는 서비스 카탈로그나 Observability 플랫폼을 버리는 것이 아닙니다. 서로 다른 관점을 가진 사람들이 중간 지점에서 만날 수 있게 해 주는 브리징 아티팩트를 만들고, 여기서 발견된 내용을 다시 기존 시스템으로 되돌려 주는 것입니다.

기차역(Trainyard) 메타포: 블록, 선로, 분기 스위치

당신의 시스템을 하나의 **기차역(또는 거대한 철도 분기장)**이라고 상상해 봅시다.

  • 기차(Trains) = 사용자 여정, 핵심 워크플로 (예: “결제”, “회원가입”, “데이터 내보내기”)
  • 선로(Tracks) = 서비스, 데이터베이스, 서드파티 연동을 통과하는 의존성 경로
  • 분기 스위치(Switches) = 의사 결정 지점, 피처 플래그, 페일오버 메커니즘
  • 기차역 구역(Yard sections) = 서브시스템 또는 도메인(결제, 인증, 분석 등)

RBD는 이 메타포 안에 자연스럽게 들어맞습니다.

  • 직렬 블록은 하나의 **단일 선로 구간(single-track segment)**입니다. 어느 한 구간이 고장 나면 기차는 지나갈 수 없습니다.
  • 병렬 블록은 갈라지는 복수 노선처럼 보입니다. 한 선로가 막히면 다른 선로로 우회할 수 있습니다.

여기에 “랜턴” 개념을 더해 봅시다. 각 인시던트 리뷰에서 다룬 장애는, 문제가 발생한 기차역 구역 위에 매달린 랜턴 하나가 됩니다. 그 주변만이 아니라, 그 불빛이 어슴푸레 비추는 다른 취약 지점까지 드러나기 시작합니다.

인시던트 스토리 기차역 랜턴 맵 만드는 법

특별한 도구는 필요 없습니다. 준비물은 다음 정도면 충분합니다.

  • 큰 종이(플립차트용, 롤 페이퍼 등)나 화이트보드, 핀보드
  • 여러 색의 포스트잇(또는 스티키 노트)
  • 마커, 테이프, 끈 또는 실(스트링)

1. 중요한 워크플로 하나를 고르기

먼저 단 하나의 핵심 가치 워크플로를 선택합니다. 예를 들면:

  • 사용자 회원가입
  • 결제 및 체크아웃
  • 데이터 인제션 파이프라인
  • 리포트/대시보드 생성

이 워크플로가 당신의 **메인 선로(main rail line)**가 됩니다. 시작점과 종료 지점을 크게 그려 넣습니다.

2. 단순 아키텍처가 아니라 ‘의존성 트리’를 그리기

워크플로의 각 단계에 대해 다음 질문을 던집니다.

“사용자가 기대한 결과를 얻으려면, 여기에서 무엇이 꼭 성공해야 하지?”

그리고 다음 요소를 하나씩 블록(포스트잇)으로 추가합니다.

  • 내부 서비스, 마이크로서비스
  • 데이터베이스, 메시지 큐
  • 캐시, 스토리지 계층
  • 서드파티 API, SaaS 도구
  • 공유 패키지, 라이브러리
  • 설정(Configuration), 피처 플래그, 스케줄링된 잡/태스크

이들을 직렬(모두 성공해야 함) 또는 병렬(중복·폴백 경로) 구조로 선을 그어 연결합니다.

이 과정이 결국 하나의 사용자 여정에 최적화된, 종이 위의 신뢰성 블록 다이어그램을 만드는 것입니다.

3. 실제 인시던트를 ‘스토리’로 겹쳐 올리기

이제 인시던트 리뷰 / 포스트모템 자료를 가져옵니다.

특정 인시던트 하나에 대해 다음을 수행합니다.

  1. 직접 관련된 컴포넌트 블록에 굵은 테두리를 치거나, 특정 색 포스트잇으로 교체합니다.
  2. 인시던트의 흐름을 스토리처럼 맵 위에 주석으로 남깁니다.
    • 처음 증상이 나타난 곳은 어디였는가?
    • 실제로 가장 먼저 실패한 컴포넌트는 무엇이었는가?
    • 영향 범위를 키우거나 줄인 요소는 무엇이었는가?
  3. 기여 요인을 작은 포스트잇이나 깃발 형태로 메모합니다.
    • “알람이 안 울림”
    • “런북 내용이 오래됨”
    • “빌링 서비스에 숨은 커플링 존재”

이제 선형 타임라인으로만 있던 인시던트가, **의존성 네트워크 위에 고정된 공간적 내러티브(spatial narrative)**로 변합니다.

4. ‘랜턴’으로 신뢰성 블라인드 스폿 강조하기

각 인시던트마다 랜턴 마커(예: 노란색 동그라미 스티커나 특별한 색 포스트잇)를 루트 원인 또는 영향 증폭 지점에 붙입니다. 그리고 다음을 질문합니다.

  • 이 선로(컴포넌트)를 지나는 **다른 기차(워크플로)**는 무엇이 있는가?
  • 이 주변 블록 중, 같은 컴포넌트/라이브러리/설정을 공유하는 것은 무엇인가?
  • 우리 머릿속 모델에서 이 블록을 **“당연히 항상 살아 있는 것”**처럼 취급하고 있지는 않은가?

이 과정을 여러 인시던트에 반복하면, 다음과 같은 패턴이 보입니다.

  • 여러 워크플로에 등장하지만 공식 다이어그램에는 잘 안 보이는 서드파티 제공자
  • 누구도 명확히 책임지지 않지만 모든 서비스가 의존하는 공유 auth helper 패키지
  • “믿을 만하다”고 여겼지만 사실상 **단일 장애점(single point of failure)**으로 설정된 데이터베이스

랜턴이 몰려 있는 지점이 곧 눈에 보이게 된 신뢰성 블라인드 스폿입니다.

시각을 행동으로: 신뢰성 작업 우선순위 정하기

종이 맵은 다음에 무엇을 할지 바꾸지 못하면 의미가 없습니다.

RBD 스타일의 기차역 맵 위에 인시던트를 충분히 얹었다면, 한 걸음 물러서서 다음을 수행합니다.

1. 가장 중요한 블록을 찾아내기.
다음과 같은 특징을 가진 컴포넌트를 찾습니다.

  • 여러 핵심 워크플로의 경로에 걸쳐 있음
  • 인시던트에 자주 등장함
  • 직렬 체인에서 단 하나의 실패 지점으로 작동함

이들은 곧 레버리지 높은 신뢰성 투자 지점입니다. 여기에 중복을 추가하거나, 페일오버를 개선하거나, SLO·알림 체계를 강화해야 합니다.

2. 어디에 ‘병렬 선로’를 깔지 결정하기.
특정 컴포넌트 하나에 위험이 과도하게 몰려 있다면, 가능한 병렬 경로를 설계하고 맵 위에 표시합니다.

  • 대체 데이터 스토어
  • 백업/보조 제공자
  • 캐시나 강건한 degrade 모드(기능 축소 모드)

이 아이디어들을 실제 아키텍처와 로드맵에 다시 반영합니다.

3. 맵이 ‘안개 낀 구역’처럼 느껴지는 곳에 관측성을 강화하기.
맵 어딘가가 “여기쯤 ETL 스크립트가 돌고 있을 듯…” 정도로만 표현된다면, 그건 다음이 필요하다는 신호입니다.

  • 더 명확한 소유권과 문서화
  • 더 나은 계측(instrumentation)과 메트릭
  • 명료한 인시던트 런북

아날로그 맵은 기술적인 약점뿐 아니라, 공유된 이해의 공백까지 함께 보여 줍니다.

피드백 루프 만들기: 인시던트 → 맵 → 설계 → 인시던트

진짜 힘은 이 맵을 단발성 워크숍 산출물이 아니라, 다음 세 가지를 잇는 지속적인 피드백 루프로 사용할 때 나옵니다.

  1. 구조적 모델링(RBD / 의존성 트리).
    실패가 어떻게 전파되는지, 어디에 중복을 더하는 게 효과적인지 이해하는 원리 기반 관점을 제공합니다.

  2. 엄밀한 인시던트 리뷰.
    포스트모템은 단순한 스토리타임이 아니라, 맵을 업데이트하는 입력값입니다.

    • 새로운 블록 추가
    • 새로 발견된 연결선 표시
    • 패턴을 드러내는 새로운 랜턴 추가

  3. 반복적인 설계와 우선순위 설정.
    랜턴 클러스터와 중요한 직렬 경로는 다음에 영향을 줍니다.

    • 신뢰성 로드맵
    • SLO·에러 버짓 정책
    • ‘Day 2’(운영·개선) 엔지니어링 우선순위

시간이 지나면 맵의 형태 자체가 변하는 것을 보게 됩니다.

  • 단일 선로 구간이던 곳에 중복 경로가 생깁니다.
  • 고위험 랜턴 클러스터는 완화 조치가 진행되며 점점 줄어듭니다.
  • 새로운 블라인드 스폿이 가끔씩 생기긴 하지만, 이미 그것을 찾고 고치는 문화가 자라난 상태입니다.

이런 식으로 조직은 단순한 화재 진화 모드에서 벗어나, 체계적인 신뢰성 개선 문화로 옮겨가게 됩니다.

결론: 신뢰성을 ‘함께’ 눈에 보이게 만들기

복잡한 시스템은 복잡한 방식으로 실패합니다. 신뢰성 블록 다이어그램과 인시던트 리뷰 같은 도구들은 구조와 데이터를 제공하지만, 여전히 중요한 의존성들을 눈앞에 두고도 못 보는 경우가 많습니다.

인시던트 스토리 기차역 랜턴 맵—즉, 시스템과 그 실패 양상을 담은 유형의 테이블탑 종이 네트워크—을 만들면 다음을 이룰 수 있습니다.

  • 흩어진 인시던트 지식을 하나의 공유 시각 내러티브로 통합합니다.
  • 조용히 막대한 리스크를 품고 있으면서도 눈에 잘 띄지 않던 컴포넌트, 패키지, 서드파티 서비스를 드러냅니다.
  • 신뢰성 작업을 정말 중요한 곳에 우선 배치할 수 있는 공용 아티팩트를 팀에 제공합니다.

무엇보다, 지속적인 피드백 루프를 만들게 됩니다. 인시던트는 기차역의 새로운 구석을 비추고, 맵은 설계와 우선순위를 안내하며, 개선된 시스템은 더 적고 더 선명하며 더 배울 게 많은 인시던트로 이어집니다.

시작하는 데 화려한 도구는 필요 없습니다. 큰 종이 한 장, 포스트잇 묶음, 그리고 팀이 가진 가정을 정말로 테이블 위에 올려놓을 의지만 있으면 됩니다. 블라인드 스폿은 이미 존재합니다. 이 맵은 그저, 우리가 그것을 함께 볼 수 있게 도와줄 뿐입니다.

아날로그 인시던트 스토리 기차역 랜턴 맵: 종이 위에서 드러나는 숨은 신뢰성 블라인드 스폿 | Rain Lag