연필 지도 오퍼레이션 스튜디오: 런북 없이 시작하는 인시던트 대응을 위한 손그림 서비스 토폴로지

현대 인시던트 대응에는 역설이 있습니다. 데이터는 과거 어느 때보다 많지만, 정작 무슨 일이 실제로 잘못되고 있는지 파악하는 데는 여전히 너무 오래 걸립니다. 대시보드, 로그, 트레이스, 런북, 알람… 모두 도움이 되지만, 동시에 우리를 압도하기도 합니다.

만약 인시던트를 시작하는 가장 빠른 방법이 런북이 아니라, ‘지도’라면 어떨까요?

“오퍼레이션 스튜디오(Operations Studio)”를 열었을 때, 실제 시스템의 라이브 서비스 맵이 화면에 펼쳐진다고 상상해 보세요. 약간은 거칠지만 손으로 스케치한 듯한 아키텍처 다이어그램—전통적인 워룸에서 화이트보드에 그리는 그림 같은 모습입니다. 단, 이 지도는 알람, 메트릭, 트레이스, 트래픽과 실시간으로 연결되어 있습니다.

이것이 바로 “연필 지도 오퍼레이션 스튜디오(Pencil Map Operations Studio)”의 아이디어입니다. 직관적인 손그림 느낌의 서비스 토폴로지에 실시간 데이터를 입혀서, 여러 개의 런북을 뒤지는 대신 시각적으로 인시던트 조사를 시작할 수 있게 하는 것이죠.

이 글에서는 왜 서비스 맵이 중요한지, 이를 관측(Observability) 데이터와 어떻게 통합할 수 있는지, 그리고 왜 손그림 스타일이 인시던트 대응을 더 빠르고 덜 부담스럽게 만들어 줄 수 있는지 살펴보겠습니다.

인시던트 중에 서비스 맵이 ‘추측’보다 강한 이유

알람이 울렸다고 가정해 봅시다. 예를 들어, 체크아웃(결제) 지연(latency)이 급등했습니다. 이때 여러분이 처음으로 묻게 되는 질문은 대부분 이런 게 아닐 겁니다.

“정확히 메트릭 값이 얼마지?”

대부분은 이렇게 시작합니다.

“이 서비스는 누구랑 통신하고, 누가 이 서비스에 의존하지?”

서비스 맵과 디펜던시 그래프(dependency graph)는 이 질문에 즉시 답해 줍니다. 예를 들어, 이런 것들을 보여줍니다.

업스트림·다운스트림 의존성: 어떤 서비스가 checkout-service를 호출하는지, 어떤 데이터베이스를 사용하는지, 어떤 외부 API를 때리는지 한눈에 보입니다.
숨겨진 결합 관계 노출: 모두가 잊고 있던 “작은 헬퍼 서비스”도 그래프에 나타나면서 실제 블라스트 레디우스(blast radius, 영향 범위)를 드러냅니다.
추측 제거: “결제 플로우는 Priya한테 물어봐야 알아” 같은 부족 지식(tribal knowledge)에 기대지 않고, 실제 토폴로지를 눈으로 확인할 수 있습니다.

고스트레스 상황에서는 머릿속에서조차 질문을 하나 더 해야 할 때마다 대응 시간에 지연이 생깁니다. 명확한 서비스 맵은 그 인지적 부담을 하나의 시각적 화면으로 압축해 줍니다.

정적인 다이어그램에서 살아 있는 데이터 기반 맵으로

전통적인 아키텍처 다이어그램은 정적이고 금방 낡으며, 대부분 아무도 열어보지 않는 슬라이드 덱 안에 잠들어 있습니다. 연필 지도 오퍼레이션 스튜디오는 이와 다릅니다. 이 맵은 멋을 위한 “그림”이 아니라 **라이브 컨트롤 서피스(live control surface)**입니다.

이를 위해서는 서비스 맵을 관측 스택(observability stack)과 연결해야 합니다.

메트릭과 알람 (예: Prometheus)
- 노드 크기나 테두리에 CPU, 에러율, 트래픽 볼륨 등을 반영합니다.
- 알람 상태에 따라 노드 색을 바꿉니다: 초록(정상), 주황(경고), 빨강(알람 발생), 회색(알 수 없음).
트레이스 (예: Jaeger)
- 엣지(서비스 간 호출선) 두께로 호출 빈도를 표현합니다.
- 현재 지연(latency)에 크게 기여하는 핫 패스(hot path)를 하이라이트해 보여줍니다.
서비스 메쉬 (예: Istio, Kiali 기반 시각화)
- 카나리, 블루-그린 배포, 재시도, 타임아웃 같은 실제 라우팅 규칙을 주석(annotations) 형태로 보여줍니다.
- mTLS, 서킷 브레이커, 레이트 리밋(rate limit) 같은 정책을 YAML 속이 아니라 맵 위에서 직접 확인합니다.
인시던트 시스템 (PagerDuty, Opsgenie 등)
- 오픈된 인시던트가 있는 노드에 배지를 붙입니다.
- 노드를 클릭하면 현재 인시던트, 관련 런북, 온콜(on-call) 담당자 정보로 바로 이동합니다.

이렇게 하면 여러 대시보드를 Alt+Tab으로 왔다 갔다 하는 대신, 하나의 토폴로지 화면을 돌아다니면서 주요 신호(signal)를 모두 같은 맵 위에서 확인할 수 있습니다.

마이크로서비스 시각화: 카오스에서 이해로

마이크로서비스 아키텍처는 종종 의존성이 얽히고설킨 **털실 뭉치(hairball)**처럼 느껴집니다. Istio, Prometheus, Jaeger, Kiali 같은 도구들은 이미 많은 데이터를 보여주고 있지만, 문제는 이 데이터를 “탐색 가능하게” 만드는 것입니다.

효과적인 연필 지도 오퍼레이션 스튜디오는 다음과 같은 기법을 사용합니다.

논리적 그룹화: 도메인(예: “checkout”, “search”, “identity”)이나 팀 소유권 기준으로 서비스를 클러스터링합니다.
트래픽 가중 엣지: 호출량이 많은 경로는 굵게, 거의 사용되지 않는 경로는 가늘게 표현합니다.
에러 인지 스타일링: 특정 호출 경로의 에러율이 치솟으면 엣지를 빨간색으로 표시합니다.
시간 제어(Time controls): 타임라인을 스크럽(scrub)해서 인시던트 전후로 토폴로지의 행동이 어떻게 변했는지 볼 수 있습니다.

결과적으로, 전체를 조망하는 조감도이면서 동시에 개별 서비스와 핵심 상호작용까지 파고들 수 있는 화면이 됩니다. 이런 질문에 빠르게 답할 수 있게 되죠.

“payment-gateway가 장애나 성능 저하를 겪고 있으면, 어떤 사용자 여정(user journey)이 위험해지지?”
“이건 국지적 문제인가, 아니면 더 큰 연쇄 장애(cascading failure)의 일부인가?”

2D vs 3D: 왜 인터랙티브 그래프가 중요한가

정적인 다이어그램은 구조를 보여줄 수는 있지만, 인시던트는 시간에 따라 전개됩니다. 여기서 인터랙티브 2D, 3D 그래프가 강력해집니다.

2D에서

혼잡한 구역을 **팬(pan)과 줌(zoom)**으로 자유롭게 이동하면서도 전체 컨텍스트를 잃지 않습니다.
시그널 기준 필터링: “알람이 있는 노드만 보여줘”, “에러가 많이 나는 엣지만 보여줘” 같은 뷰를 바로 만들 수 있습니다.
임팩트 오버레이: 성능이 저하된 서비스의 모든 소비자(consumer)를 하이라이트해서 영향 범위를 보여줍니다.

3D에서

세 번째 축을 안정성 지표로 활용할 수 있습니다. 예를 들어, 높이 = 에러율 또는 지연 시간.
계층(tier) 분리: 프론트엔드, 백엔드, 데이터 스토어, 외부 서비스 등을 층(layer)으로 나누어 쌓아 올립니다.
깊이를 사용해 시간 변화나 트래픽 볼륨을 표현할 수 있습니다.

3D는 그저 화려한 시각 효과가 목적이 아닙니다. 핵심 개념을 유지한 채, 더 많은 정보를 공간적으로 인코딩하는 데 목적이 있습니다. 직관적인 카메라 컨트롤과 좋은 기본값을 함께 제공하면, 복잡한 시스템이 오히려 더 “길 찾기 쉬운 공간”처럼 느껴지게 할 수 있습니다.

리스크와 블라스트 레디우스를 위한 실시간 토폴로지 뷰

장애 상황에서 가장 중요한 질문은 두 가지입니다.

지금 당장 뭐가 깨져 있나?
아무것도 하지 않으면 앞으로 뭐가 더 깨질까?

실시간, 토폴로지 인지(topology-aware) 뷰는 이 두 질문에 답하는 데 도움을 줍니다.

임팩트 하이라이팅(Impact highlighting): 장애가 난 데이터베이스를 선택하면, 영향을 받는 모든 서비스와 사용자 플로우가 한 번에 하이라이트됩니다.
리스크 프리뷰(Risk preview): 노드 위에 마우스를 올려두면, 그 노드가 완전히 다운됐을 때 어떤 서비스와 기능이 영향을 받을지 미리 볼 수 있습니다.
연쇄 장애 탐지(Cascading failure detection): auth 슬로우다운 → checkout의 재시도 폭주 → DB 포화(saturation) 같은 장애 체인을 시각적으로 포착할 수 있습니다.

이렇게 하면 긴 인시던트 문서를 읽고 머릿속으로 블라스트 레디우스를 추론하는 대신, 그래프 위에서 영향 범위가 어떻게 확장되는지 눈으로 직접 확인할 수 있습니다. 이 시각 피드백은 다음과 같은 더 나은 결정을 뒷받침해 줍니다.

어디에 레이트 리밋을 적용해야 할지
어디에서 기능 디그레이드(기능 축소)를 할지
어떤 지점에 완화(mitigation) 작업을 집중할지

런북을 다시 생각하기: 스크립트에서 시각적 출발점으로

런북은 유용하지만, 단점도 분명합니다.

금방 낡고 실제 시스템 상태를 따라가지 못합니다.
어떤 런북을 열어야 하는지 미리 알고 있어야 한다는 전제를 깔고 있습니다.
대개 실제 혼란 상황이 아니라 차분한 환경에서 이상적인 시나리오를 기준으로 작성됩니다.

연필 지도 오퍼레이션 스튜디오는 런북을 없애는 것이 아니라, 런북에 도달하는 경로를 바꾸는 것입니다.

예전에는 이렇게 시작합니다.

시작: “위키에서 ‘checkout latency’ 런북 검색하기.”

이제는 이렇게 시작합니다.

시작: “맵에서 checkout 영역을 연다. 뭐가 빨간지 본다. 가장 뜨거운 지점을 클릭한다.”

그다음, 노드나 엣지에서:

해당 서비스에 연관된 런북으로 점프할 수 있고(존재한다면),
과거 인시던트 기록과 그때 효과가 있었던 조치들을 볼 수 있으며,
그 서비스의 SLO와 에러 버짓(error budget)을 바로 확인할 수 있습니다.

이렇게 되면 런북이 ‘필수’가 아니라 ‘선택적’ 도구가 되는 워크플로우가 만들어집니다.

자주 발생하고 잘 알려진 장애에는 기존 런북이 여전히 도움이 됩니다.
하지만 처음 보는 복합 장애나 신규 장애 모드에는, 맵이 기존 스크립트에 문제를 억지로 끼워 맞추지 않고 마찰이 적은 시각적 출발점을 제공합니다.

이 효과는 신뢰성 지표에도 그대로 나타납니다.

MTTA(Mean Time to Acknowledge, 인시던트 인지까지의 평균 시간) 감소: 엔지니어가 문제 영역을 한눈에 파악합니다.
MTTR(Mean Time to Resolve, 복구까지의 평균 시간) 감소: 원인 추적이 바로 “맞는 동네”에서 시작됩니다.
탄력성(resilience) 향상: 연습된 장애뿐 아니라, 새로운 장애 모드에도 대응하는 능력이 높아집니다.

왜 손그림 스타일이 도움이 되는가

언뜻 들으면 “손그림 스타일”은 단순한 시각적 장식처럼 들릴 수 있습니다. 하지만 실제로는 그 이상입니다.

1. 가설적 진실(provisional truth)을 전달한다

정교하고 직선으로 반듯하게 그려진 다이어그램은 완전하고 정확한 진실처럼 보이기 쉽습니다. 반대로 연필 스케치 스타일의 맵은 우리에게 이렇게 상기시켜 줍니다.

“이건 현실 그 자체가 아니라, 현실을 설명하는 모델일 뿐이다.”

이런 인식은 잘못된 확신(false confidence)을 줄이고, 인시던트 대응 중에 건전한 회의와 검증을 유도합니다.

2. 압박 속에서 엔지니어가 생각하는 방식과 맞아떨어진다

워룸에서는 사람들이 자연스럽게 화이트보드와 마커를 집어 들고 흐름을 그리기 시작합니다. 스케치 느낌의 디지털 맵은 이런 익숙한 경험과 맞닿아 있어서 더 직관적으로 느껴지고, 온보딩도 덜 부담스럽습니다.

약간 삐뚤빼뚤한 선, 미묘한 흔들림이 실제 화이트보드 그림과 비슷한 느낌을 줍니다.
동그라미, 화살표, 간단한 메모를 얹어 주석을 다는 행위가 자연스럽습니다.

3. 시각적 위압감을 줄인다

너무 폴리시(polished)하고 초밀도 정보로 가득 찬 시각화는 오히려 “쉽게 건드리기 어려운”, 지나치게 공식적인 화면처럼 느껴질 수 있습니다. 손그림 스타일은 보다 가벼운 심리적 진입 장벽을 제공하고, 자유로운 탐색과 실험을 장려합니다. 이는 오퍼레이션 스튜디오에 우리가 가장 바라는 특성이기도 합니다.

나만의 연필 지도 오퍼레이션 스튜디오 설계하기

이런 스타일의 인시던트 대응으로 옮겨가고 싶다면, 다음과 같은 설계 원칙을 고려할 수 있습니다.

홈 화면을 토폴로지로 삼아라
인시던트의 첫 진입점이 알람 테이블이 아니라 서비스 맵이 되도록 만드세요.
복제하지 말고 통합하라
Istio, Prometheus, Jaeger, Kiali, 인시던트 도구에서 이미 존재하는 데이터를 끌어오세요. 이 맵은 또 하나의 데이터 사일로가 아니라, 기존 데이터에 대한 렌즈여야 합니다.
설정보다 상호작용을 우선하라
엔지니어가 관계를 보기 위해 복잡한 설정 파일을 수정하기보다, 드래그·줌·필터·클릭 등 직접 조작으로 탐색할 수 있어야 합니다.
부분적인 지식 상태를 전제로 설계하라
일부 레거시 서비스는 초기에 완전히 맵에 반영되지 않을 수도 있습니다. 이럴 때는 그런 불확실성을 숨기지 말고, 점선 노드나 흐릿한 엣지처럼 시각적으로 드러내세요.
런북은 한 걸음 옆에 두되, 출발점은 항상 맵으로
런북은 맵에서 한 번의 클릭으로 접근 가능해야 합니다. 하지만 인시던트의 1단계는 항상 맵을 여는 것이어야 합니다.

결론: 스크립트보다 맵이 먼저다

시스템이 점점 더 분산되고 동적으로 변할수록, 정적인 문서와 선형 런북만으로는 속도를 따라가기 어렵습니다. 변하지 않는 것은 **“무엇이 무엇과 연결되어 있는지 이해해야 한다”**는 우리의 기본적인 필요입니다. 특히, 그 연결들이 실패할 때는 더더욱 그렇습니다.

연필 지도 오퍼레이션 스튜디오는 서비스 토폴로지를 인시던트 대응의 주요 인터페이스로 격상시킵니다.

라이브 서비스 맵으로 누가 누구에게 의존하는지에 대한 추측을 없앱니다.
통합된 관측 데이터로 알람, 메트릭, 트레이스를 하나의 탐색 가능한 그래프 위에 올립니다.
2D/3D 인터랙티브 시각화로 복잡한 마이크로서비스 웹을 실제로 걸어 다닐 수 있는 지형처럼 만듭니다.
토폴로지 인지 실시간 뷰로 리스크, 블라스트 레디우스, 연쇄 장애를 눈에 보이게 만듭니다.
런북 없이 시작하는 인시던트 플로우를 통해, “어떤 문서를 열어야 하지?”를 고민하기 전에 맥락과 전체 그림부터 보게 합니다.

실제 현장에서는, 다음 인시던트가 발생했을 때 여러분의 첫 행동이 위키 스크롤이 아니라 이렇게 바뀌게 됩니다.

맵을 연다.
가상의 연필을 집는다.
그리고 서비스들 사이 연결선 위에서, 실제 문제가 살고 있는 그 지점부터 문제를 추적하기 시작한다.