소개

디지털 시스템은 놀랍도록 아날로그한 방식으로 장애가 납니다.

인시던트가 터지면, 가장 잘 대응하는 팀들은 의외로 굉장히 로우테크한 행동을 합니다. 방 하나를 잡고, 화이트보드에 마커를 들이대고, 벽에 종이를 붙이고, 무엇이 고장 났는지 이해하고 고치기 위한 임시 물리 컨트롤 센터를 만드는 식이죠.

이 공간을 **“아날로그 인시던트 스튜디오 원룸”**이라고 생각해 봅시다. 한 칸짜리 종이 실험실 안에 당신의 신뢰성 실무 전체—아키텍처, 인시던트 플레이북, 워룸 의식, 지속적 개선 워크플로우—를 통째로 넣는 겁니다. 잘 만들어 두면, 시스템이 스트레스 상황에서 어떻게 행동하는지를 보여주는, 살아 있는 공유 모델이 됩니다.

이 글에서는 그 한 공간(또는 한쪽 벽)을 설계하는 방법을 다룹니다. 이 안에 다음이 모두 녹아들어가게 만드는 겁니다.

• 시스템 아키텍처와 인시던트 전략
• 서비스 경계와 의존성 관리
• 복구 우선(Recovery‑first) 설계 관점
• 라이브 인시던트 워룸 운영 방식
• 신호에서 수정까지 이어지는 신뢰성 칸반(Kanban) 워크플로우

스튜디오 원룸 정도의 작은 공간 안에 전부 담을 수 있습니다.

1. 아키텍처는 곧 인시던트 전략이다

의도했든 아니든, 시스템 아키텍처는 인시던트 대응 전략이 글로 적힌 기록입니다. 예를 들어, 다음을 어떻게 설계했는지가:

• 서비스 경계를 어디에 긋는지
• 통신 패턴을 어떻게 고르는지 (동기 vs 비동기)
• 공유 의존성(데이터베이스, 큐, 캐시 등)을 어디에 두는지
• 타임아웃, 재시도, 폴백을 어떻게 처리하는지

…이 모든 것이 장애 상황에서 무슨 일이 벌어지는지를 결정합니다.

아날로그 스튜디오에서는 한쪽 벽이나 메인 패널을 “인시던트 맵으로서의 아키텍처(Architecture as Incident Map)” 전용으로 씁니다.

종이 위에 어떻게 구현할까

1. 시스템을 박스와 화살표로 그립니다.

   • 서비스, 데이터 저장소, 서드파티 API, 큐 등을 그립니다.
   • 핵심 사용자 경로(예: 결제, 회원가입)는 두껍게 표시합니다.

2. 인시던트에 중요한 속성을 덧입힙니다. 각 박스 안이나 옆에 다음을 적습니다.

   • SLO / SLI (예: p95 레이턴시, 에러율)
   • 런북 (짧은 ID나 문서로 가는 QR 코드)
   • 오너십 (담당 팀 이름 / 온콜(온콜 로테이션) 정보)
   • 블라스트 레디우스 태그 (예: "고객 노출", "내부 전용")

3. 알려진 실패 모드를 표시합니다.

   • 색깔 있는 포스트잇을 과거 인시던트에 사용합니다.
     • 빨강: 사용자에게 보이는 장애
     • 주황: 성능 저하
     • 파랑: 니어미스 / 내부 영향만 있는 경우
   • 해당 컴포넌트 위에 붙이고, 날짜와 두세 단어 정도의 라벨을 적습니다.

이렇게 하면 인시던트 관점의 토폴로지가 생깁니다. 시스템이 어디가 약한지, 실패가 어떻게 전파되는지 시각적으로 드러나는 지도입니다.

2. 서비스 경계: 봉쇄 vs 전사적 위기

신뢰성에서 가장 중요한 결정 중 하나는 서비스 사이의 경계를 어디에 긋느냐입니다. 이 경계가 잘려진 방식에 따라, 인시던트가 시스템의 한 구역에만 갇힐지, 아니면 회사 전체가 흔들리는 위기로 커질지가 갈립니다.

아날로그 스튜디오를 사용해 이런 선택들을 명시적으로 드러냅니다.

벽 위에서 봉쇄를 시각화하기

아키텍처 맵에 간단한 범례(legend)를 추가합니다.

• 두꺼운 실선: 강한 경계, 엄격한 계약 및 타임아웃 적용
• 얇은 선: 베스트‑에포트(best‑effort) 호출, 치명적이지 않은 의존성
• 점선: 비동기 또는 결국 일관되는(eventually consistent) 흐름
• 엣지에 아이콘으로 재시도, 서킷 브레이커, 벌크헤드(bulkhead) 표시

그리고 종이 위에 직접 이런 질문을 적고 답을 적어 둡니다.

• "서비스 A가 완전히 실패하면, 제일 먼저 뭐가 깨지나?"
• "이 공유 데이터베이스가 죽었을 때 최악의 경우 블라스트 레디우스는 어디까지인가?"
• "어떤 호출은 리소스를 붙잡고 늘어지지 말고 반드시 빠르게 실패해야 하는가?"

답을 주석처럼 맵에 적습니다. 그러면 다음이 눈에 띄게 드러납니다.

• 숨겨진 결합도
• 공유 리소스에 대한 과도한 의존
• 한 셀의 실패가 전체 그리드를 다운시킬 수 있는 지점

이제 종이 아키텍처는 단순한 정적 다이어그램이 아니라, **신뢰성 위협 모델(reliability threat model)**로 바뀝니다.

3. 포스트모템 이후가 아니라, 설계 초반부터 복구를 고려하라

많은 팀이 기능과 성능을 우선 설계하고, 훨씬 나중에야 복구를 위해 리팩터링해야 한다는 걸 깨닫습니다. 순서가 잘못된 겁니다.

스튜디오에서는 복구를 설계의 1급 항목으로 만들어, 주요 컴포넌트마다 옆에 보이게 둬야 합니다.

복구 패널 만들기

**“Design for Recovery(복구를 위한 설계)”**라는 제목의 섹션을 하나 만들어 행(row)을 다음처럼 구성합니다.

• 컴포넌트 / 기능
• MTTR 목표 (얼마나 빨리 복구해야 하는가?)
• 복구 메커니즘 (롤백, 페일오버, 디그레이드 모드, 캐시 전용 등)
• 사람이 하는 지원 (런북? 테스트 환경? 피처 플래그?)
• 자동화 수준 (수동 / 반자동 / 완전 자동)

아키텍처 맵에서 핵심 경로마다 인덱스 카드 하나를 이 패널에 추가합니다. 그러면 복구 설계가 명시적으로 드러납니다.

• 기능 설계 옆에 복구 설계가 붙어 있게 되고,
• 엔지니어와 비즈니스 이해관계자 모두 이해할 수 있는 언어로 표현됩니다.

아래에는 작은 영역을 두고 **“Recovery Design Debt(복구 설계 부채)”**를 기록합니다.

• 안전한 롤백이 없는 컴포넌트용 포스트잇
• 페일오버 플랜이 없는 공유 의존성
• 디그레이드 모드로 돌릴 수 없는 플로우

이 목록 자체가 신뢰성 백로그의 원천이 됩니다.

4. 워룸: 한 공간에서 운영하는 실시간 인시던트 지휘 센터

인시던트가 발생하면 필요한 것은 워룸(war room) 입니다. 실시간 커뮤니케이션, 공동 트러블슈팅, 빠른 의사결정을 위한 집중된 환경이죠.

아날로그 스튜디오는 언제든지 몇 초 만에 워룸 모드로 전환될 수 있어야 합니다.

좋은 워룸이 하는 일

효과적인 워룸은 다음을 보장합니다.

• 누가 총괄 책임자인지(Incident Commander)가 분명하다.
• 단일한, 공유된 현실 인식(single shared view of reality)을 만든다.
• 컨텍스트 스위칭과 사이드 채널 커뮤니케이션의 혼선을 줄인다.
• 빠르고 되돌릴 수 있는 결정을 지원한다.

동시에 핵심 SRE 원칙과도 맞아야 합니다.

• 자동화: 반복 작업은 스크립트와 도구가 하고, 사람은 판단과 조정을 맡는다.
• 신뢰성: 속도 vs 안전(에러 버짓, 블라스트 레디우스)을 균형 있게 본다.
• 운영 우수성: 명확한 역할, 커뮤니케이션 규칙, 인시던트 이후 학습을 갖춘다.

물리적 워룸 레이어 구성하기

원룸 실험실의 일부를 “Incident Live Board(실시간 인시던트 보드)” 용으로 예약합니다.

1. 인시던트 헤더

   • 인시던트 ID, 시작 시각, 커맨더, 사용 중인 커뮤니케이션 채널
   • 영향을 받은 SLO, 사용자 영향 요약

2. 타임라인 스트립

   • 가로 선 하나를 그리고 여기에 타임스탬프가 있는 메모를 붙입니다.
     • 신호: 알림(alert), 고객 제보
     • 액션: 롤백, 설정 변경 등
     • 주요 관찰: 메트릭 변화, 로그 특징적인 패턴

3. 가설 & 실험 컬럼

   • 왼쪽: 현재 가설 (예: "결제 타임아웃 – 의존성 X 문제")
   • 오른쪽: 테스트/실험 내용과 결과

4. 결정 & 안전장치

   • 지금까지 내린 중요한 결정을 크게, 눈에 띄게 적습니다.
   • 안전 관련 제약 사항 ("데이터베이스 Y에 대한 변경은 승인 없이는 금지")

이미 벽에는 아키텍처와 복구 설계가 붙어 있으므로, 워룸에서는 다음을 할 수 있습니다.

• 영향받은 컴포넌트를 손가락으로 바로 가리키며 논의
• 이미 적어둔 SLO와 블라스트 레디우스 태그를 기반으로 트레이드오프 논의
• 즉흥이 아니라, 사전에 고민해 둔 복구 경로 중에서 선택

워룸을 그때그때 급조하는 게 아니라, 미리 설계된 인시던트 스튜디오를 활성화하는 셈입니다.

5. 칸반: 신뢰성 밸류 스트림을 시각화하기

신뢰성 관련 작업은 기능 요청, 기술 부채, 불끄기(소방) 작업 사이에서 자주 묻혀 버립니다. 스튜디오 안의 칸반 보드는 모든 작업을 하나의 흐름으로 보여 줍니다. 흐름은 이렇게 이어집니다.

Signal → Investigation → Fix → Hardening → Learning
(신호 → 조사 → 수정 → 강화 → 학습)

왜 인시던트/신뢰성 업무에 칸반인가?

칸반 보드는 다음을 아주 잘 드러냅니다.

• 전체 밸류 스트림에 걸친 진행 중인 작업(WIP)
• 티켓이 쌓여 흐름을 막는 병목 구간
• 너무 많은 일을 동시에 진행해 결국 아무 것도 끝나지 않는 오버커밋

신뢰성 관점에서는 다음을 직접적으로 개선합니다.

• 인시던트 후속 액션이 사라지지 않고 끝까지 추적된다.
• 긴급 소방과 장기 구조적 개선 사이의 균형을 맞출 수 있다.

“진행 중”을 더 세분화하기

To Do / In Progress / Done 같은 단순한 흐름 대신, **“In Progress(진행 중)”**을 인시던트 · SRE 업무에 맞게 더 잘게 나눕니다. 예를 들어:

1. To Do

   • 새 알림, 인시던트 후속 조치, 신뢰성 개선 아이템

2. Triage / Analysis (트리아지 / 분석)

   • 범위, 영향, 오너십을 명확히 하는 단계

3. Design / Plan (설계 / 계획)

   • 접근 방식을 결정하고 이해관계자와 리뷰

4. Implementation (구현)

   • 코드 작성, 인프라 변경, 자동화 스크립트 작성

5. Verification (검증)

   • 테스트, 스테이징 검증, 게임데이(Game Day) 수행

6. Rollout / Monitor (배포 / 모니터링)

   • 배포, 메트릭 관찰, 피처 플래그 조정

7. Done / Documented (완료 / 문서화)

   • 코드 머지, 문서 업데이트, 인시던트 후속 액션 클로즈

이처럼 세밀한 흐름은 팀이 다음을 할 수 있게 해 줍니다.

• 신뢰성 작업이 어디에서 막혀 있는지 정확히 파악
• 칼럼별 WIP 제한 설정 (예: Implementation에 사람당 2개까지만)
• 단순 처리량이 아니라 흐름(Flow) 자체를 최적화

중요한 건, 이 보드의 카드들을 다음에 연결하는 것입니다.

• 특정 인시던트 (카드에 인시던트 ID 기록)
• 특정 아키텍처 컴포넌트 (서비스 이름, 모듈 이름 등)
• 특정 복구 역량 (예: "기능 Z 롤백 기능 추가")

이렇게 하면 칸반이 아키텍처와 워룸에서 드러난 문제들을 실제로 해결하는 실행 엔진이 됩니다.

6. 한 공간을 지속 학습 시스템으로 바꾸기

이 아날로그 인시던트 스튜디오 원룸의 요소들을 함께 쓰면, 닫힌 학습 루프가 만들어집니다.

1. 아키텍처 맵이 인시던트 전략과 취약 지점을 인코딩합니다.
2. 서비스 경계 & 의존성 설계가 실패가 어디서 봉쇄되고 어디서 연쇄될지 보여 줍니다.
3. 복구 설계 패널이 복구를 설계 초기와 계획 단계부터 고려하게 만듭니다.
4. 워룸 레이어가 인시던트 발생 시 실시간 지휘 센터로 활성화됩니다.
5. 칸반 보드가 배운 내용을 구체적인, 우선순위가 매겨진 작업으로 전환합니다.

시간이 지나면 벽 위에서 패턴이 눈에 들어오기 시작합니다.

• 특정 의존성 주변에 인시던트가 몰린다면 → 리팩터링하거나 벌크헤드를 도입해야 할 신호
• 카드가 "Verification" 칼럼에서 자꾸 멈춘다면 → 더 좋은 테스트 환경에 투자해야 할 신호
• 워룸에서 반복되는 수작업이 많다면 → 스크립트와 런북으로 자동화해야 할 신호

이게 바로 아날로그 방식의 숨은 힘입니다. 도구 안에 파묻혀 잘 안 보이던 패턴이, 물리적으로 눈에 띄게 드러납니다.

결론

인시던트 대응과 신뢰성을 개선하는 데 복잡한 툴체인이 꼭 필요한 것은 아닙니다. 필요한 것은 아키텍처, 인시던트, 복구, 실행이 한데 모여 있는 의도적으로 설계된 공유 공간입니다.

한쪽 벽이나 방 하나를 아날로그 인시던트 스튜디오 원룸으로 다루면 다음을 할 수 있습니다.

• 아키텍처와 실패 모드를 즉각 눈에 보이게 만든다.
• 더 나은 경계와 의존성 설계를 통해 인시던트를 봉쇄한다.
• 문제가 터진 뒤가 아니라, 초기에 복구를 설계한다.
• SRE 원칙에 맞는 더 좋은 워룸을 운영한다.
• 인시던트에서 얻은 학습을 꾸준한 신뢰성 개선 스트림으로 전환한다.

시작은 작게 해도 됩니다. 화이트보드 하나, 마커 몇 개, 포스트잇 몇 장이면 충분합니다. 사용자 여정 하나, 핵심 서비스 하나, 반복되는 실패 모드 하나만 먼저 맵으로 그려 보세요. 그 과정을 반복하다 보면, 그 한 방이 팀이 가진 도구 중 가장 가치 있는 신뢰성 도구가 될 겁니다. 그 안에는 시스템만이 아니라, 모든 것이 위태로울 때 여러분이 어떻게 생각하고, 대응하고, 학습하는지까지 함께 인코딩되어 있기 때문입니다.