아날로그 리스크 플래닛: 인시던트가 실제로 퍼지는 방식을 책상 위 궤도 모델로 만들기

분산 시스템은 직선으로 장애가 나지 않습니다. 궤도로 장애가 납니다.

느린 DB 쿼리 하나가 한 서비스를 안전한 궤도에서 살짝 밀어냅니다. 그 서비스는 재시도 폭풍에 빠지고, 그 서비스에 의존하던 다른 서비스는 타임아웃이 나기 시작합니다. 큐는 밀려 쌓이고, 서킷 브레이커는 열립니다. 어느새 아주 작은 교란이 전체 장애로 커져버립니다.

대부분의 팀은 이런 상황을 사후에만 봅니다. 서로 안 맞는 로그, 대시보드, Slack 메시지들이 줄줄이 쌓인 상태로요. 그 사이에 빠져 있는 것은 바로 모델—인시던트가 시스템 안에서 어떻게 전파되는지 모두가 같은 그림으로 볼 수 있게 해주는, 구체적이고 공유 가능한 틀입니다.

이걸 여러분의 리스크 지형을 보여주는 책상 위 궤도 모델이라고 생각해 보세요. 서비스는 행성, 의존성은 궤도, 인시던트는 그 궤도를 따라 이동하는 객체입니다. 그리고 중요한 컴포넌트는 “중력 우물(gravity well)”처럼 영향을 끼칩니다.

이 글에서는 다음을 활용해 그 모델을 만드는 방법을 살펴봅니다.

실행 경로에 컨텍스트를 전파하는 크로스컷팅 도구(트레이싱, 디버깅 훅, 테인트 트래킹, 데이터 프로비넌스, 감사 로그 등)
의존성과 중력 우물을 눈에 보이게 만드는 다이어그램
시각(다이어그램)과 데이터(계측)를 결합해 인시던트의 블라스트 반경을 설계·시뮬레이션·제한하는 방법

인시던트는 혼란스럽게 느껴지지만 사실은 패턴이 있다

운영 중인 서비스에서 장애가 터지면, 보통 이야기는 아주 좁은 곳에서 시작합니다.

“X 서비스에 버그가 있었어”
“캐시가 느려졌어”
“배포가 에러를 일으켰어”

하지만 어느 정도 규모가 있는 마이크로서비스 아키텍처에서는, 인시던트는 보통 한 컴포넌트만 고장 난 게 아니라, 연쇄 반응에 가깝습니다. 조금 더 진짜 이야기에 가깝게 말하면 이렇습니다.

“어느 한 지점의 미묘한 변화가 시스템의 여러 부분에 작용하는 힘을 바꿔버렸다.”

핵심은 전파(propagation), 즉 데이터, 요청, 부수 효과가 서비스 사이를 어떻게 움직이는가 하는 문제입니다. 그리고 이게 바로 크로스컷팅 도구들이 보여주려는 것입니다.

크로스컷팅 도구: 인시던트의 궤적을 따라가기

트레이싱, 디버깅 훅, 테인트 프로퍼게이션(taint propagation), 데이터 프로비넌스(provenance), 감사(auditing) 시스템 같은 도구들은 모두 같은 아이디어를 공유합니다.

실행 경로에 컨텍스트를 붙이고, 그 경로가 가는 어디든 함께 따라가게 만든다.

컨텍스트 전파는 어떻게 동작하는가

분산 트레이싱(distributed tracing) 은 각 요청에 트레이스 ID와 스팬 ID를 붙입니다. 요청이 여러 서비스를 지나갈 때, 이 ID들이 함께 따라갑니다.
테인트 프로퍼게이션은 특정 데이터(예: 신뢰할 수 없는 입력)에 표시를 붙여, 그것이 시스템 안에서 어떻게 흐르는지 추적할 수 있게 합니다.
데이터 프로비넌스는 데이터가 어디에서 왔고 무엇을 거쳐 변형되었는지를 추적합니다.
감사(auditing) 는 사용자 행동과 그에 대한 시스템의 반응을 같은 경로 상에서 기록합니다.

이 모든 경우에 공통적인 비유를 쓰면:

요청, 이벤트, 데이터 덩어리는 우주선과 같습니다.
컨텍스트(트레이스 ID, 태그, 메타데이터)는 그 우주선의 텔레메트리(telemetry) 입니다.
서비스 호출과 메시지 홉(hop)은 시스템의 궤도를 따라가는 비행 궤적입니다.

인시던트가 발생하면, 이런 도구들은 서비스, 컴포넌트, 머신 경계를 넘어서 이벤트들을 상관관계로 묶어 보여줍니다. 이를 통해 다음을 볼 수 있습니다.

가장 먼저 이상징후가 나타난 지점
그 이후 어떤 다운스트림 서비스들이 영향을 받았는지
재시도, 백프레셔, 타임아웃이 어떻게 블라스트 반경을 키웠는지

컨텍스트 전파가 없으면, 인시던트는 서로 상관없는 로컬 장애처럼만 보입니다. 컨텍스트 전파가 있으면, 시스템 전체를 위한 비행 기록계(flight recorder) 를 가지게 됩니다.

트레이스에서 궤도로: 책상 위의 모델 만들기

이제 다시 비유로 돌아가서, 여러분의 시스템을 책상 위 궤도 모델로 생각해 봅시다.

마이크로서비스들을 책상 위의 행성이라고 상상해 보세요.

핵심 데이터베이스와 공용 인프라: 깊은 중력 우물을 가진 거대한 행성
비즈니스 도메인 서비스: 다양한 궤도를 도는 중간 크기 행성
엣지 API, 어댑터, 잡(job): 주변에 떠 있는 작은 위성들

서비스 의존성은 그 행성의 궤도입니다.

서비스 A가 요청마다 서비스 B를 호출한다면, A는 B를 매우 가까이 도는 타이트한 궤도에 있습니다.
리포팅 서비스가 가끔 데이터 웨어하우스를 질의하는 정도라면, 드문 빈도의 먼 궤도에 있습니다.

인시던트(느려진 DB, 잘못된 배포, 네트워크 분할 등)는 이 미니 태양계에 생긴 교란입니다. 이때 중요한 질문은 다음과 같습니다.

어떤 궤도가 이 고장 난 행성과 교차하고 있는가?
다음으로 어떤 행성들이 안정된 궤도에서 벗어나게 될 것인가?
작은 힘으로도 많은 서비스들을 궤도 밖으로 밀어낼 수 있는 지점은 어디인가?

여기서 트레이스는 실제 궤적입니다. 요청이 이 궤도들을 따라 움직이는 과정을 기록한 실제 경로죠. 그리고 다이어그램은 지도입니다. 무엇이 무엇과 연결될 수 있는지를 보여주는 정적인 뷰입니다.

마이크로서비스 다이어그램을 궤도 지도처럼 그리기

일반적인 아키텍처 다이어그램은 그냥 박스와 화살표에 그치기 쉽습니다. 인시던트 대응에 진짜 도움이 되려면, 다이어그램은 궤도 지도처럼 다음을 강조해야 합니다.

의존성의 방향
누가 누구에게 의존하는가? 호출과 데이터 흐름이 어느 방향으로 가는가?
빈도와 중요도(criticality)
이 경로는 얼마나 자주 사용되는가? 핵심 사용자 요청 경로에 있는가, 아니면 배치 잡에만 쓰이는가?
공유 인프라
어떤 데이터베이스, 캐시, 큐, 서드파티 API가 많은 서비스들이 궤도를 도는 “중앙 행성”인가?

이런 방식으로 마이크로서비스 아키텍처를 그리기 시작하면 다음이 보이기 시작합니다.

단일 장애점(SPOF): “작고 단순해 보이지만” 거의 모든 요청이 반드시 거쳐가는 서비스
숨은 결합(hidden coupling): 그냥 캐시, 피처 플래그 시스템, 인증/인가 Provider 하나만 공유하는 것 같지만, 그것이 고장 나면 동시에 같이 죽는 서비스들
에스컬레이션 경로: 낮은 우선순위 서비스에서 시작된 장애가 어떻게 사용자에게 보이는 장애까지 거슬러 올라오는지

이 다이어그램이 곧 여러분의 아날로그 궤도 모델입니다. 종이, 화이트보드, 모델링 도구 어디에 그리든, 인시던트 전파 경로를 직관적으로 볼 수 있게 해주는 책상 위 축소판입니다.

중력 우물(Gravity Wells): 작은 문제가 큰 장애로 커지는 지점

시스템 안에도 “질량”이 더 큰 부분들이 있습니다.

인증/인가 서비스
중앙 사용자/프로필 데이터 저장소
결제 게이트웨이와 빌링 시스템
공용 캐시 계층, 설정/피처 플래그 서비스
메시징 백본, 서비스 메시(mesh)

이들은 중력 우물(gravity well) 입니다. 연결이 많거나, 비즈니스적으로 매우 중요한 서비스로, 시스템 전체의 동작에 강한 영향을 미칩니다.

이게 중요한 이유는 다음과 같습니다.

중력 우물의 지연 시간이 조금만 늘어나도 대규모 타임아웃이 발생할 수 있습니다.
중요한 서비스에서 사용하는 공유 라이브러리에 미묘한 버그 하나만 있어도 시스템 전체 에러로 번질 수 있습니다.
중앙 컴포넌트가 포화되거나 Rate Limit에 걸리면, 재시도 폭풍, 큐 적체, 사용자 가시 장애로 연쇄적으로 이어질 수 있습니다.

다이어그램에서 이런 중력 우물을 의도적으로 표시해 두세요. 더 큰 노드, 다른 색상, ‘Critical’ 같은 라벨 등으로요. 이렇게 하면 다음을 할 수 있습니다.

인시던트가 어디에서 시작되거나 증폭될 가능성이 높은지 예측
그 주변에 보호막과 버퍼(서킷 브레이커, 벌크헤드, 캐시 등)를 설계
중복성, 스케일링, 카오스 테스트에 어디부터 투자해야 할지 결정

리스크를 구체화하기: 시각 모델 + 계측을 함께 쓰기

시각 모델만으로는 충분하지 않습니다. 도구만으로도 부족합니다. 둘을 함께 쓸 때 힘이 생깁니다.

1단계: 궤도 지도를 그린다

모든 서비스와 공유 컴포넌트를 나열합니다.
호출, 데이터 플로우, 의존성을 방향성을 가진 엣지로 그립니다.
다음을 표시합니다.
- 중력 우물(연결 수가 많거나 비즈니스적으로 중요한 컴포넌트)
- 동기식 vs 비동기식 상호작용
- 핵심 사용자 요청 경로

2단계: 계측(instrumentation)을 매핑한다

각 노드와 엣지에 대해 자문해 보세요.

이 경로를 따라 트레이스 ID를 전파하고 있는가?
그 ID로 로그와 메트릭을 연관 지어서 볼 수 있는가?
중요한 데이터 흐름에 대해 데이터 라인리지/프로비넌스를 추적할 수 있는가?
민감한 액션에 대해 감사 훅(auditing hooks) 이 걸려 있는가?

이렇게 하면 인시던트가 터졌을 때, 어떤 궤적은 보이고, 어디는 여전히 블라인드 스팟인지가 드러납니다.

3단계: 인시던트 궤적을 겹쳐 본다

과거 인시던트를 테스트 케이스로 써보세요.

트레이스와 로그를 이용해 실제 장애의 경로를 재구성합니다.
그 궤적을 궤도 지도 위에 그립니다.
신호가 처음 나타난 지점과 그것이 어떻게 퍼져 나갔는지 표시합니다.

그러면 패턴이 보입니다.

항상 등장하는 같은 중력 우물
비슷하게 반복되는 타임아웃, 폴백(fallback) 체인
항상 2차·3차로 “불이 번지는” 서비스들

이제 이 모델은 이론이 아니라, 실제 데이터에 기반한 모델이 됩니다.

블라스트 반경을 설계·시뮬레이션·제한하기

컨텍스트 전파 도구로 뒷받침된 궤도 모델을 만들고 나면, 인시던트에 수동적으로 대응하는 대신 애초에 블라스트 반경을 작게 설계할 수 있습니다.

블라스트 반경을 줄이는 설계

벌크헤드(bulkhead) 를 추가해, 한 서비스가 다른 서비스에 밀어 넣을 수 있는 부하의 상한을 둡니다.
서킷 브레이커(circuit breaker) 를 활용해, 재시도가 쌓이기 전에 빠르게 실패하도록 합니다.
강화된 디그레이드 모드(degradation mode) 를 도입해, 중력 우물이 이상 동작할 때 기능 일부를 우아하게 끌 수 있게 합니다.
Fan-out 감소: 하나의 요청이 동기식으로 열 개의 서비스를 호출하는 설계를 피합니다.

장애를 시뮬레이션하기

중력 우물을 타겟으로 카오스 실험을 진행합니다.
트레이스와 메트릭을 보면서, 이 “인시던트” 가 여러분의 궤도를 어떻게 따라가는지 관찰합니다.
실제로 일어난 일을 기준으로 다이어그램을 업데이트합니다.

리스크를 명확하게 커뮤니케이션하기

아날로그 궤도 모델은 엔지니어만을 위한 것이 아닙니다. 이해관계자들에게 설명할 때도 훌륭한 도구입니다.

왜 작아 보이는 컴포넌트가 큰 장애를 만들 수 있는지
어디에 신뢰성 투자를 하고 있으며, 그 이유는 무엇인지
아키텍처 변경이 전체 시스템 리스크에 어떻게 영향을 미치는지

시각적·모델 기반 접근법은 추상적인 신뢰성 개념을 구체화합니다. PM이 스팬(span)이 뭔지 몰라도, “이 중앙의 큰 행성이 흔들리면 주변 모든 궤도가 함께 틀어진다”는 이야기는 곧바로 이해할 수 있습니다.

결론: 다음 장애 전에 당신의 리스크 플래닛을 만들라

인시던트는 무작위 로컬 장애가 아니라, 전파의 이야기입니다.

다음과 같은 일을 함으로써:

실행 경로에 컨텍스트를 전파하는 크로스컷팅 도구(트레이싱, 테인트 트래킹, 프로비넌스, 감사)를 사용하고
의존성 중심 다이어그램을 궤도 지도처럼 그리고
중력 우물과 공통 전파 경로를 식별하면

…여러분의 아키텍처는 더 이상 박스와 화살표의 모음이 아니라, 리스크가 실제로 어떻게 움직이는지를 보여주는 책상 위 아날로그 모델이 됩니다.

이 모델은 여러분이 다음을 하는 데 도움을 줍니다.

작은 교란이 어떻게 큰 장애로 커지는지 이해하기
더 작은 블라스트 반경을 설계하고 테스트하기
팀 간에 리스크와 신뢰성을 명확하게 커뮤니케이션하기

책상 위에 진짜 3D 조형물을 둘 필요는 없습니다(물론 재미있기는 할 겁니다). 잘 유지되는 다이어그램 하나가, 고품질 트레이스와 프로비넌스 데이터에 기반하고 있다면, 그 자체로 아날로그 리스크 플래닛입니다.

가장 중요한 사용자 여정 하나부터 시작하세요. 트레이스를 거세요. 맵을 그리세요. 중력 우물을 표시하세요. 그리고 스스로에게 물어보세요. “여기서 뭔가 잘못되면, 그다음에는 무엇이 궤도에서 이탈할까?”

바로 그 지점이, 다음 신뢰성 투자를 해야 할 곳입니다.