아날로그 인시던트 스토리 관측 돔: 당신의 시스템을 도는 작은 실패들을 책상 위에서 관찰하는 행성

당신의 전체 시스템을 책상 위에 올려둘 수 있다면 어떨까요?

대시보드도 아니고, 위키에 그려진 다이어그램도 아닙니다. 유리 돔 아래에서 은은히 빛나는 하나의 물리적인 행성입니다. 그 안에는 작은 불빛들, 회전하는 경로들, 위성처럼 떠다니는 실패의 궤도들이 있습니다. 각각의 궤도는 하나의 이야기를 담고 있습니다. 작은 버그, 설정 변경, 부분적 장애가 어떻게 당신의 아키텍처를 통과해 갔는지에 대한 경로 말이죠.

이것이 바로 인시던트 스토리 관측 돔(Incident Story Observatory Dome) 의 아이디어입니다. 당신의 시스템을 도는 작은 실패들을 지켜보는, 책상 크기의 행성입니다.

이건 비유이지만, 매우 강력한 비유입니다. 인시던트를 무작위 폭발이 아니라, 의존성, 피드백 루프, 아키텍처 선택이라는 중력장 안을 통과하는 예측 가능하고 구조화된 궤적으로 다시 보게 만듭니다.

장애가 아니라 궤도로 생각하기

우리는 보통 인시던트를 개별 이벤트로 이야기합니다.

• “Redis가 내려갔어요.”
• “결제 서비스가 타임아웃 났어요.”
• “EU-West 리전에서 부분 장애가 있었어요.”

관측 돔 모델에서는 인시던트를 작은 실패들의 궤도로 생각합니다.

각각의 실패 — 재시도 폭주, 캐시 미스 급증, 잘못 설정된 피처 플래그 — 는 당신 시스템의 중력장으로 진입하는 작은 ‘천체’가 됩니다. 그 경로(인시던트의 궤적)는 숨겨진 구조를 드러냅니다.

• 처음에는 어떤 서비스 근처를 스쳐 지나가는가?
• 어떤 의존성이 그 경로를 휘게 만들고, 증폭시키는가?
• 어디서 에너지를 얻는가(피드백 루프)? 어디서 에너지를 잃는가(서킷 브레이커, 벌크헤드, 스로틀링)?

인시던트를 궤도로 시각화하면, 더 이상 “망가졌다”로 끝나지 않습니다. 그건 관계들 사이를 지나가는 하나의 경로가 됩니다.

돔을 아날로그 의존성 맵으로 보기

대부분의 의존성 맵은 PDF나 자동 생성된 그래프 속에 있지만, 실제로 자세히 보는 사람은 거의 없습니다. 관측 돔은 다릅니다. 의존성을 손에 잡히는 것처럼 만드는 아날로그 시각화입니다.

돔을 당신 시스템의 작은 플라네타리움이라고 상상해 보세요.

• 서비스는 천체: 코어 서비스는 거대한 행성, 보조 서비스는 위성, 외부 API는 멀리서 천천히 움직이는 천체입니다.
• 의존성은 중력: 주 데이터베이스 같은 무거운 의존성은 강한 ‘중력’을 가집니다. 거의 모든 인시던트 경로가 그 주변으로 휘어집니다.
• 트래픽과 부하는 에너지: 트래픽이 많이 지나는 경로는 붐비는 궤도 레인입니다. 그 레인으로 진입한 실패 입자는 가속되거나 불안정해집니다.

돔 안에서 어떤 컴포넌트에 실패 ‘입자’를 하나 투입하면:

• 특정 궤도로 어떻게 끌려 들어가는지 볼 수 있습니다.
• 어떤 천체와 충돌하기 쉬운지 볼 수 있습니다.
• 충돌이 또 다른 실패를 어떻게 전파하는지도 볼 수 있습니다.

이렇게 하면, 머릿속 모델이 박스와 화살표에서 힘의 장과 궤적으로 바뀝니다. 의존성은 더 이상 정적인 선이 아니라, 동적으로 작용하는 영향력이 됩니다.

우주 궤도 설계에서 가져온 사고방식

우주 임무는 작은 변화에도 극도로 민감합니다. 제때 주어진 아주 작은 델타-v만으로도 우주선은 완전히 다른 궤도로 들어갑니다.

인시던트도 마찬가지입니다.

시스템의 아주 작은 교란:

• 미묘한 설정 변경,
• 소소한 성능 저하,
• 잘 눈에 띄지 않는 타임아웃 증가,

이런 것들이 실패를 전혀 다른 경로로 보내 버립니다.

궤도 설계 관점에서 보면, 하나의 인시던트에는 다음이 있습니다.

• 발사 조건(Launch conditions): 실패가 어디서, 어떻게 시작됐는지 (배포, 특정 리전의 이상, 의존성 품질 저하 등).
• 전이 궤도(Transfer orbits): 재시도, 큐, 폴백을 거치며 실패가 영향을 미치는 서비스들의 순서.
• 중력 보조(Gravity assists): 재시도 폭주 같은 피드백 루프가 인시던트의 임팩트를 가속시키는 지점.
• 안정 지점(Stability points): 서킷 브레이커, 레이트 리미트, 로드 셰딩 같은 완화 장치가 실패 에너지를 흡수하거나 튕겨 내는 영역.

이걸 돔 안에 맵으로 그려보면, 비선형 경로가 보이기 시작합니다.

• 특정 트래픽 조건에서 로그 라이브러리의 작은 버그 하나가 CPU 바운드 서비스 전체를 무너뜨리는 경우.
• 재시도 임계값에 대한 작은 설정 변경이, 잠깐의 의존성 이상을 전면적인 재시도 폭주로 바꿔 버리는 경우.
• 한 리전의 지연 시간이 소폭 증가했을 뿐인데, 트래픽이 엉뚱한 방향으로 이동하며 그동안 안전하다고 여겼던 클러스터를 과부하시키는 경우.

즉, 인시던트 궤적 설계(incident trajectory design) 를 연습할 수 있습니다.

• 어디에 ‘탄탄한 중력 우물(강한 복원력 지점)’을 만들 것인가?
• 어떤 ‘전이 궤도’가 취약한 컴포넌트와 위험할 만큼 가깝게 지나가는가?
• 작은 발사 오류(사소한 버그)가 어떻게 치명적인 궤도로 이어질 수 있는가?

시스템 사고: 부품이 아니라 관계의 문제

돔은 시스템 사고(systems thinking) 를 강제합니다.

이제 이런 질문 대신에:

“서비스 X는 왜 실패했지?”

이렇게 묻게 됩니다.

“이 작은 문제가 큰 인시던트로 커지게 만든 관계와 피드백 루프는 무엇이었지?”

이 렌즈로 보면:

• 재시도는 단순한 설정 값이 아닙니다. 특정 궤도 레인에 에너지를 증폭하는 앰프입니다.
• 큐는 단순한 버퍼가 아닙니다. 인시던트 에너지를 저장했다가 나중에 풀어내는, 시간 지연형 중력 우물입니다.
• 피처 플래그는 단순한 토글이 아닙니다. 트래픽과 의존성의 ‘질량 분포’를 갑자기 바꾸어, 비선형적인 변화를 일으키는 장치입니다.

과거 인시던트들의 궤도를 관찰하면, 다음을 배우게 됩니다.

• 어떤 관계들이 양의 피드백 루프를 만드는지.
• 어떤 서브시스템이 충격 흡수 장치로 작동하는지.
• “Degraded but not down(완전히 죽진 않았지만 성능 저하)” 상태 같은 어떤 패턴이 반복해서 통제 불능의 궤도를 만들어내는지.

이 지점에서 돔은 더 이상 장난감이 아니라 사고 도구가 됩니다. 박스들이 아니라, 서로 상호 작용하는 루프들의 시스템으로 시스템을 보게 됩니다.

돔 아래에서의 의존성과 네트워크 분석

돔을 진짜 유용하게 만들려면, 그 안에 네트워크 분석 개념이 녹아 있어야 합니다.

• 중심 노드(Critical nodes, 높은 차수): 인바운드/아웃바운드 의존성이 많은 서비스는 더 크고 밝은 행성으로 표현됩니다.
• 높은 매개 중심성(High betweenness) 컴포넌트: 최단 경로들 사이에 자주 끼어 있는 서비스(예: 인증, 라우팅, 결제 게이트웨이)는, 실패 궤도가 수많은 서비스를 스치게 만드는 ‘목’ 역할을 하는 지점으로 드러납니다.
• 취약한 링크(Fragile links): 지연 시간에 민감하거나 복원력이 낮은 연결은, 쉽게 노이즈에 깨지는 얇고 부서지기 쉬운 궤도 경로로 시각화됩니다.

돔 안에서 인시던트 시나리오를 돌려 보면:

• 어떤 노드를 살짝 건드렸을 때 가장 복잡한 궤도가 생성되는지 파악할 수 있습니다.
• 서로 다른 인시던트가 반복해서 지나가는 경로(‘뜨거운 궤도 레인’)를 알아낼 수 있습니다.
• 작아 보이는 컴포넌트가 실제로는 결정적인 환승 허브 역할을 하는지 발견할 수 있습니다.

시간이 지나면, 당신의 돔은 살아 있는 인시던트 지도(incident atlas) 가 됩니다. 작은 실패들이 주로 어디를 지나고, 어디에서 폭발하는지 기록하는 지도입니다.

소프트웨어를 위한 ‘의존성 이론’을 향해

대부분의 엔지니어링 팀은 성능에 대한 이론, 테스트에 대한 이론, 배포에 대한 이론을 가지고 있습니다.

하지만 진짜 의존성 이론을 가진 팀은 드뭅니다.

인시던트 스토리 관측 돔은 그러한 이론을 개발하기 위한 물리적 비유입니다. 이를 통해 다음을 할 수 있습니다.

• 아키텍처 실험: 새로운 의존성을 추가하면? 새로운 캐싱 레이어를 도입하면? 중력장은 어떻게 변하는가?
• 구조 비교: 모놀리식, 마이크로서비스, 모듈러 모놀리스를 서로 다른 행성계로 생각해 봅니다. 하나의 거대한 행성 vs. 많은 작은 행성들 vs. 별자리처럼 묶인 구조.
• 신뢰성 트레이드오프 비교: 다음과 같은 선택을 했을 때 실패 궤도가 어떻게 달라지는지 살펴볼 수 있습니다.
  • 공용 서비스를 하나 더 추가하는 경우,
  • 하나의 서비스를 여러 작은 서비스로 쪼개는 경우,
  • 핵심 기능을 중앙집중화할지, 로컬에 둘지 결정하는 경우.

의존성 이론은 곧 시스템의 모양이 다음을 어떻게 규정하는지 이해하는 일입니다.

• 어떤 유형의 인시던트가 발생하는지,
• 그 인시던트들이 어떤 경로를 따라 이동하는 경향이 있는지,
• 얼마나 빨리 탐지하고 얼마나 쉽게 가두어 둘 수 있는지.

돔은 이 이론을 보고, 설명할 수 있는 매개체가 됩니다. 새로운 팀원, 리더십, 그리고 무엇보다도 스스로에게요.

LLM과 에이전트는 ‘미션 컨트롤’이다

그렇다면 LLM과 에이전트 기반 도구는 어디에 들어갈까요? 이들은 당신 책상 위 행성을 위한 미션 컨트롤(mission control) 입니다.

돔이 궤도 모델이라면, 미션 컨트롤은 다음을 담당합니다.

• 지속적인 관측(Continuous observation): 로그, 트레이스, 메트릭, 이벤트를 수집해 새로운 실패 입자가 시스템 어디에 진입했는지 추론합니다.
• 궤도 예측(Trajectory prediction): 현재 부하와 설정에서, 서비스 A에서 이상 징후가 포착되면 가장 가능성 높은 인시던트 궤도를 추정합니다.
  • “15분 안에 auth, 그 다음 user profile, 그 다음 checkout에 영향을 줄 가능성이 높습니다.”
• 궤도 수정 제안(Suggested maneuvers): 중간에 궤도를 수정하기 위한 액션을 제안합니다.
  • 재시도 한도를 낮추거나,
  • 특정 리전에서 부하를 줄이거나,
  • 특정 피처 플래그를 일시 비활성화하거나,
  • 특정 의존성을 페일오버하도록 유도하는 등.

충분한 인시던트 이력 데이터가 쌓이면, LLM 기반 미션 컨트롤은 다음을 할 수 있습니다.

• 과거 인시던트와 유사한 궤도 패턴을 인식합니다.
• 런북을 위한 “만약에” 시나리오를 시뮬레이션합니다.
• 위험한 궤도가 애초에 생기기 어렵도록, 더 나은 중력장(의존성 구조, 한계값, 완화 전략) 을 설계하는 것을 도와줍니다.

돔은 아날로그 프론트엔드이고, LLM/에이전트는 그 뒤에서 작동하는 디지털 브레인입니다.

돔의 사고방식을 팀에 들여오기

실제로 유리 돔을 하나 만들 필요는 없습니다(물론 만들면 재미있을 겁니다).

관측 돔의 사고방식을 도입하려면, 다음부터 시작해 보세요.

1. 인시던트를 궤도로 다시 이야기하기

   • 포스트모템에서 다음을 묘사해 보세요.
     • 실패가 어디에서 “발사”되었는지.
     • 어떤 서비스들을 차례로 통과했는지.
     • 어떤 피드백 루프가 이를 증폭시켰는지.
     • 어디에서 최종적으로 흡수되거나 소멸되었는지.

2. 중력 천체와 전이 궤도 맵 만들기

   • 다음을 식별합니다.
     • 코어 데이터 스토어(거대한 행성).
     • 공용 인프라(붐비는 궤도 허브).
     • 취약한 링크(얇고 쉽게 끊어지는 연결).

3. 궤도 형성을 위한 설계하기(trajectory shaping)

   • 다음을 추가하거나 튜닝합니다.
     • 서킷 브레이커와 벌크헤드를 ‘대기권 마찰’처럼.
     • 레이트 리미트를 ‘탈출 속도 조건’처럼.
     • 폴백 경로를 대체 궤도로.

4. 미션 컨트롤 강화하기

   • LLM/인시던트 도구에 다음을 공급합니다.
     • 의존성 그래프,
     • 인시던트 히스토리,
     • 런북과 완화 옵션,
     • SLO와 비즈니스 우선순위.
   • “뭐가 고장 났지?”가 아니라 “이 궤도는 어디로 향하고 있지?”라고 물어보세요.

결론: 망가지는 모습을 더 잘 지켜보는 방법

모든 시스템은 끊임없는 작은 실패의 비를 맞으며 살아갑니다. 나쁜 입력, 일시적인 타임아웃, 시끄러운 이웃(노이즈를 일으키는 다른 워크로드), 부분 배포 등. 대부분은 인시던트로 이어지지 않습니다. 당신이 만들어 둔 복원 메커니즘이 그 궤도를 조용히 소멸시키기 때문입니다.

하지만 어떤 실패는 아슬아슬한 궤도로 미끄러져 들어가, 아주 나쁜 타이밍에 아주 잘못된 서비스들 가까이를 스치고 지나갑니다.

인시던트 스토리 관측 돔은 그 보이지 않는 구조를 눈에 보이게 만드는 방법입니다. 인시던트를 놀람이 아니라, 시스템의 모양에 이미 새겨져 있는 경로로 보게 하는 방법입니다. 의존성과 피드백 루프, 완화 전략을 실험하면서, 손으로 만질 수 있을 것처럼 이해할 수 있게 해 줍니다.

그리고 LLM·에이전트 기반 미션 컨트롤이 성숙해질수록, 우리는 그 궤도를 단순히 지켜보는 것을 넘어 조종할 수 있게 될 것입니다. 책상 위 작은 행성을, 문제가 생길지언정 그 문제가 예측 가능하고 잘 가두어지는 시스템을 설계하는 실험실로 바꿔 줄 것입니다.

결국 돔은 장비가 아니라 사고방식에 가깝습니다. 당신의 시스템을 상호 작용하는 천체들로 이루어진 작은 태양계로 보고, 인시던트를 연구하고 예측하며, 미리 대응 전략을 설계할 수 있는 궤도로 보는 것. 그렇게 함으로써, 그것들이 지구(프로덕션)로 추락해오기 전에 대비하는 것입니다.