들어가며: 가장 최악의 인시던트는 늘 한 번도 연습해 본 적 없는 것들이다

대부분의 신뢰성 프로그램은 눈에 잘 보이는 것들엔 강합니다. 부하 테스트, 가용성 대시보드, 에러 스파이크에 대한 페이징 같은 것들이죠. 그런데 진짜로 아픈 인시던트는 이상하게도 이런 눈에 잘 보이는 경로에서 잘 나오지 않습니다.

대신 이런 데서 터집니다.

• 분기에 한 번만 호출되는 잘못 설정된 파트너 웹훅
• 특정 레거시 리전에만 적용되는 특이한 결제 흐름
• DNS, 인증, 피처 플래그가 동시에 엇갈려 버리는 부분 장애

즉, 시스템에서 가장 기묘한 엣지 케이스들입니다.

바로 이런 모서리들이야말로 모니터링이 가장 약하고, 플레이북은 두루뭉술하며, 팀은 거의 연습해 본 적이 없습니다. 그리고 이건 신뢰성 도구만으로는 절대 해결할 수 없는 문제입니다.

여기서 **종이 신뢰성 노면전차(Paper Reliability Streetcar)**가 등장합니다. 시스템의 가장 이상한 경로를 따라가는 매일 반복하는 아날로그 루트입니다. 이건 수동이지만 구조화된 의식으로, 다음을 수행합니다.

• 평소에는 잘 건드리지 않는 비직관적 동작들을 의도적으로 실행해 보고
• 설계, 모니터링, 커뮤니케이션의 빈틈을 드러내며
• 엣지 케이스를 가끔 나타나는 재난이 아니라 자주 연습하는 상황으로 바꿉니다.

저기술(low-tech)이지만 고가치인, 시스템과 팀을 위한 신뢰성 웨이트 트레이닝이라고 생각하면 됩니다.

“종이 신뢰성 노면전차”란 무엇인가?

은유는 간단한 데서 시작합니다. 노면전차는 매일 같은 노선을 달리며, 같은 정류장을, 어떤 날씨에도 빠짐없이 지납니다. 여기서 “종이(paper)”라는 말이 의미하는 건 이 노선이 다음과 같다는 겁니다.

• 수동적 – 최소한 초반에는 자동화가 아니라 사람이 직접 돌리는 것
• 스크립트화됨 – 체크리스트, 시나리오, 런북 형태로 명확히 정의된 것
• 반복 가능 – 매일, 매주, 혹은 온콜 교대마다 일정한 주기로 수행되는 것

당신의 종이 노면전차는 고정된 엣지 케이스 시나리오 세트입니다. 이를 가지고:

1. 지금 실제로 일어나고 있는 것처럼 차근차근 따라가 보고
2. 어디가 실제로(또는 가상으로) 망가지는지 관찰하며
3. 설계·툴링·프로세스를 어떻게 개선해야 할지 캡처합니다.

이건 프로덕션에서 하는 카오스 엔지니어링도 아니고, 합성 테스트 스위트도 아닙니다. 오히려 시스템에서 제일 이상한 1%의 동작을 위한 테이블탑(tabletop) 연습에 가깝고, 이걸 충분히 자주 돌려서 팀이 이런 괴상한 상황에 유창하게 대응할 수 있게 만드는 겁니다.

1단계: 매일 도는 아날로그 루트를 정의하라

먼저 당신의 노면전차가 달릴 루트를 설계해야 합니다. 가장 중요한 규칙은 하나입니다. “해피 패스는 피하라.”

좋은 엣지 케이스 소스는 다음과 같습니다.

• 여러 장애가 한꺼번에 얽혔던 과거 인시던트
• 조용히 실패하는 것들 (예: 드롭되는 이벤트, 지연된 잡, 부분 데이터 쓰기)
• 파트너/벤더 의존성 (결제사, SMS 게이트웨이, SSO, CDN 등)
• 정책/지역별 로직 (국가별 규제, 레거시 고객 티어)
• 계정 종료, 구독 재활성화, 데이터 마이그레이션 같은 희귀한 라이프사이클 순간

이걸 아래와 같은 시나리오로 바꿉니다.

• “더 이상 판매하지 않는 요금제(deprecated plan)를 쓰는 고객이, 결제사 부분 장애 중에 상위 요금제로 업그레이드를 시도한다.”
• “서드파티에서 날아온 웹훅이 약간 다른 페이로드로 두 번 발송되고, 우리 시스템은 둘 다 처리한다.”
• “대형 테넌트가 특정 마이크로서비스 하나에서만 레이트 리밋에 걸려, 서비스 간 상태가 일관되지 않게 된다.”

각 시나리오마다 최소한의 아날로그 스크립트를 정의합니다.

• 사전 조건: 시스템에 어떤 상태가 맞춰져 있어야 하는가?
• 트리거: 어떤 액션/이벤트가 시나리오를 시작시키는가?
• 기대되는 올바른 동작은 무엇인가?
• 현재 이해 수준에서 예상되는 실패 모드들은 무엇인가?

처음 루트는 3~5개 시나리오 정도면 충분합니다. 목표는 모든 걸 다 커버하는 게 아니라, 매번 뭔가 “정상적이지 않은 것”을 반드시 연습하는 것입니다.

2단계: 신뢰성을 하나의 ‘정식 프로그램’으로 다뤄라

종이 노면전차는 “그때그때 느낌대로 하는” 연습이 아닙니다. 제대로 된 신뢰성 프로그램의 일부여야 합니다. 즉, 다음이 필요합니다.

• 명확한 오너십 (예: SRE 팀, 플랫폼 팀, 혹은 순환하는 인시던트 캡틴)
• 정해진 주기 (매일, 매주, 온콜 인수인계마다 등)
• 표준 아티팩트: 체크리스트, 실행 로그(run log), 메트릭, 티켓 등

각 실행(run)마다 다음을 수행합니다.

1. 루트에서 하나 이상의 시나리오를 고른다.
2. 스텝 바이 스텝으로 처음부터 끝까지 따라간다.
3. 발견한 것들을 남긴다: 빈틈, 혼란 지점, 없는 메트릭, 애매한 동작 등.
4. 책임자와 기한이 명확한 후속 작업 아이템을 만든다.

이건 단순히 “인시던트 역할놀이”를 하는 게 아닙니다. 당신은 다음을 하는 것입니다.

• 시스템에 대한 정신적 모델(mental model)을 검증하고
• 그 모델을 지원하는 프로세스와 도구가 실제로 어떻게 동작하는지 모니터링하며
• 인시던트로 터지기 전에 실패 모드를 예측합니다.

시간이 지나면, 이 연습이 자연스럽게 신뢰성 로드맵의 입력으로 들어가게 됩니다. 어떤 걸 모니터링해야 할지, 무엇을 재설계해야 할지, 무엇을 자동화해야 할지가 명확해지죠.

3단계: 시나리오는 구체적이고 ‘손으로 만지는’ 수준으로 만들라

노면전차의 가치는 시나리오가 얼마나 구체적이냐에 달려 있습니다. “결제가 실패하면 어떻게 하지?” 정도로는 너무 모호합니다. 대신, 실제 인시던트와 최대한 닮은 손에 잡히는 구체적인 상황을 목표로 해야 합니다.

아래와 같은 여러 레이어를 함께 포함하세요.

• 기술적 현실: 실제 시스템과 실제 상태 (또는 그에 근접한 샌드박스)
• 운영 프로세스: 페이징, 에스컬레이션, 핸드오프, 상태 공유
• 고객 영향: 사용자가 실제로 뭘 보게 되는지, 지원팀은 무엇을 안내하는지, 어떤 SLA가 적용되는지

예를 들어, 좋은 연습은 이런 요소를 포함할 수 있습니다.

• 파트너 API의 부분 장애를 실제 로그 또는 가상 상황으로 시뮬레이션
• 이때 어떤 대시보드/알림에서 무엇이 보이는지 확인
• 내부 인시던트 공지 초안을 작성
• 고객용 상태 페이지(status page) 업데이트 문구 작성
• 진짜로 완전히 복구되었는지 어떻게 검증할지 결정

목표는 인시던트 한가운데에서 실제로 써야 할 **근육 기억(muscle memory)**을, 맥락 속에서 약간의 시간 압박을 두고, 그러나 생각할 여유는 있는 상태에서 연습하는 것입니다.

4단계: 엣지 케이스 드릴로 커뮤니케이션의 빈틈을 드러내라

가장 큰 놀라움은 기술적인 것보다 사람에게서 나오는 경우가 많습니다.

이 아날로그 연습을 돌리다 보면, 종종 이런 문제들이 드러납니다.

• 중요한 벤더와의 통합(Integration)을 누가 소유하는지 아무도 모른다.
• 지원팀과 엔지니어링 팀이 같은 실패를 서로 다른 용어로 부른다.
• 법무나 컴플라이언스 제약을 인시던트 커맨더가 전혀 모르고 있다.
• 파트너의 SLA나 에스컬레이션 경로가 불명확하거나, 사실상 희망 사항에 가깝다.

그래서 일부 시나리오는 의도적으로 외부 파티나 다른 내부 팀을 명시적으로 포함하도록 설계해야 합니다.

• “업스트림 프로바이더가 전체 요청 중 0.1%에 대해 잘못된 형식의 데이터를 반환한다. 우리는 무엇을 할 것인가? 누구에게 연락할 것인가?”
• “주요 고객 한 곳이 SSO 설정을 변경한 뒤, 그 고객의 통합이 깨졌다. 우리는 어떻게 그들과 조율할 것인가?”

루트를 돌면서 이런 마찰 지점을 꾸준히 기록합니다.

• 빠져 있는 연락처/연락망 리스트
• 책임이 애매한 영역
• 팀 간 우선순위가 충돌하는 부분

그리고 이걸 기술 부채 못지않게 중요한 신뢰성 작업으로 취급합니다. 기술적 수정과 동일한 백로그에 올려서 관리해야 합니다. 시스템의 신뢰성은 결국 그것을 떠받치는 **사회적 그래프(사람과 조직의 연결)**만큼만 확보될 수 있습니다.

5단계: 인사이트를 구체적인 개선으로 연결하라

노면전차가 그저 “흥미로운 대화거리”만 쏟아내고 끝난다면, 그건 엔지니어링이 아니라 연극에 가깝습니다.

각 실행(run)의 마지막에는 반드시 다음이 있어야 합니다.

• 짧은 디브리핑 (10–15분 정도)
• 다음과 같은 구체적인 결과 리스트:
  • 신규 또는 개선된 알림/메트릭
  • 업데이트된 런북과 에스컬레이션 경로
  • 명확해진 오너십과 문서화
  • 설계 변경이나 기술 부채 티켓

그리고 이 결과들을 눈에 잘 띄게 만드세요.

• 인시던트 관리 도구나 신뢰성 백로그에 모두 기록합니다.
• source:streetcar 같은 태그를 붙여, 나중에 영향도를 리포트할 수 있게 합니다.
• 정기적인 신뢰성 리뷰나 인시던트 회고(Postmortem/Retro)에서 다시 꺼내 봅니다.

몇 주만 지나도 다음과 같은 변화를 느낄 수 있어야 합니다.

• 실제 인시던트에서 “뭐가 뭔지 전혀 모르겠는” 구간이 줄어들고
• 트리아지와 완화(mitigation)까지의 시간이 빨라지며
• 엔지니어링, 운영, 지원, 프로덕트, 법무 등 여러 팀 간 정렬(alignment)이 개선됩니다.

노면전차는 약점을 발견하는 **정문(Front door)**일 뿐이고, 진짜 가치는 그 약점을 하나씩 체계적으로 닫아 나갈 때 생깁니다.

6단계: 시스템 사고와 설계 디테일을 연결하라

엣지 케이스를 정의하는 일은 아키텍처 문제이면서 동시에 디자인 문제이기도 합니다.

먼저 **시스템 사고(Systems Thinking)**를 활용해 다음을 수행합니다.

• 핵심 플로우와 주요 의존성을 맵으로 그려 보고
• 결합도, 재시도 로직, 백프레셔가 실패할 만한 지점을 찾고
• 리전별, 벤더별, 테넌트별로 어떤 실패 도메인(failure domain)이 존재하는지 이해합니다.

그 다음 로우 레벨 디자인 디테일을 적용합니다.

• 정확한 입력, 상태, 상태 전이를 명시하고
• “열화/부분 장애 상황에서 우리가 무엇을 보장할지”를 계약(Contract)으로 문서화하고
• 실제 API, 큐, 플래그 수준에서 시나리오 체크리스트를 작성합니다.

예를 들어, 다음과 같이만 쓰지 마세요.

“레이트 리밋 때문에 대형 고객이 문제를 겪을 수 있다.”

대신 이렇게 정의합니다.

“테넌트 A가 서비스 X의 API 레이트 리밋 95%에 도달한 상태에서, 서비스 Y가 점검 모드(maintenance)에 들어간다. 그 결과 웹훅이 지연되고 대시보드 데이터가 20분 동안 오래된 상태가 된다. 이 상황을 어떻게 감지하고, 어떻게 커뮤니케이션하며, 어떻게 복구할 것인가?”

종이 노면전차는 이런 고수준 관점과 저수준 관점이 실제로 만나서 검증되는 곳입니다.

7단계: 일회성이 아니라 ‘상시 운행’으로 만들어라

이런 류의 연습이 실패하는 가장 흔한 패턴은, 이걸 특별 이벤트로 취급하는 겁니다.

• “지난 분기에 인시던트 게임 데이 한 번 했으니까, 이제 괜찮겠지.”

하지만 실제 시스템과 조직은 끊임없이 변합니다. 새로운:

• 기능(Features)
• 팀
• 벤더
• 고객

…이 등장할 때마다, 새로운 엣지가 생깁니다.

그래서 노면전차는 반드시 다음과 같아야 합니다.

• 상시적 – 신뢰성 운영 모델의 일부로 항상 돌아가는 것
• 예측 가능 – 캘린더에 박혀 있고, 모두가 기대하는 루틴
• 진화하는 – 시나리오가 추가·폐기·개선되며 계속 갱신되는 것

이걸 워크플로우에 깊게 심기 위해, 다음을 고려하세요.

• 온콜 온보딩의 표준 과정으로 포함하기
• 인시던트 커맨더(Incident Commander) 트레이닝의 일부로 만들기
• 주요 인사이트를 정기적으로 리더십에 리포트하기

잘만 운영되면, 노면전차는 스탠드업이나 회고만큼이나 자연스러운 일상이 됩니다. 시스템이 맞닥뜨릴 가장 기묘한 1%의 현실을 조금씩 더 잘 다루게 만드는, 조용하지만 계속 작동하는 힘입니다.

마무리: 신뢰성은 ‘모서리’에서 결정된다

시스템의 진짜 신뢰성은 해피 패스에서 측정되지 않습니다. 다음과 같은 순간에 드러납니다.

• 벤더의 SLA가 조용히 어겨졌을 때
• 3년 동안 아무도 손대지 않은 코드 경로를 레거시 고객이 밟았을 때
• 서로 “희귀하다”고 여겼던 일들이 동시에 여러 개 터졌을 때

모든 엣지 케이스를 사전에 예측할 수는 없습니다. 하지만 엣지에서 살아가는 연습을 할지 말지는 선택할 수 있습니다.

종이 신뢰성 노면전차는 그걸 가능하게 해 주는, 단순하지만 강력한 아날로그 방법입니다.

• 시스템에서 가장 기묘한 시나리오들을 따라가는 매일(또는 매주) 루트
• 기술·운영·커뮤니케이션의 빈틈을 드러내는 구조화된 프로그램
• 이상한 상황을 구체적인 개선으로 바꿔 주는 반복 가능한 엔진

작게 시작하세요. 엣지 케이스 세 개를 고르고, 글로 정리한 다음, 이번 주에 팀과 함께 한 번 끝까지 걸어가 보세요. 그리고 또 합니다. 그 다음에도 또 합니다.

시간이 지나면, 예전에는 “말 그대로 사고”처럼 느껴지던 인시던트들이 이제는 이미 한 번쯤 돌려 봤던 드릴처럼 느껴지기 시작할 겁니다. 그리고 바로 그때, 비로소 진짜 신뢰성에 가까워졌다고 말할 수 있습니다.