아날로그 인시던트 보물 지도 그리기: 대시보드 늘리지 않고 손으로 그리는 루트 원인 헌트 경로

인시던트는 예전에는 거의 괴담처럼 느껴지곤 했습니다.

무언가 잘못됩니다. 대시보드는 비명을 지르고, 차트는 치솟습니다. 사람들은 반쯤 말만 하며 서로를 호출합니다. “DB 문제인가요? 카프카인가? 인그레스 좀 봐줄 사람?” 그러다 불이 꺼지면, 왜 그런 일이 일어났는지 정확히 모른 채 조용히 다음 일로 넘어갑니다.

아직도 이런 모습이 익숙하다면, 이 글이 도움이 될 겁니다.

문제를 해결하려고 대시보드를 더 늘리는 대신, 인시던트를 보물 찾기로, 그리고 당신의 도구들을 진짜 루트 원인을 찾기 위한 보물 지도로 바라보는 접근이 훨씬 낫습니다.

대시보드 관찰에서 보물 찾기로

많은 팀은 대시보드 왕국에서 살고 있습니다.

모든 회의실 한쪽 벽을 채운 Grafana 보드
서비스마다 100개가 넘는 차트
데이터는 넘치지만, 스토리는 부족한 상태

우리는 화면을 멍하니 보면서 빨간 선이 *“문제는 바로 여기야”*라고 말해주길 기대합니다. 하지만 복잡한 시스템은 한 그래프에서만 실패하지 않습니다. 대부분 사건의 연쇄로 실패합니다. 이걸 이해하려면 그림만 보는 게 아니라 경로를 따라가야 합니다.

여기서 **Root Cause Analysis(RCA, 루트 원인 분석)**와 경로 중심 도구들이 등장합니다.

루트 원인 분석: 미스터리가 아니라 지도

루트 원인 분석은 인시던트를 조사하기 위한 구조화된 단계별 접근입니다. 겉으로 드러난 증상만 때우는 대신, 실제 근본 원인까지 체계적으로 파고듭니다.

RCA의 핵심 질문은 세 가지입니다.

정확히 무엇이 일어났는가?
왜 그것이 일어났는가?
다시 일어나지 않게 무엇을 바꿀 수 있는가?

RCA는 IT 유행어가 아닙니다. 다음과 같은 신뢰성과 안전성이 중요한 분야에서 오랫동안 쓰여온 기본 도구입니다.

제조 (조립 라인 장애)
엔지니어링 (구조·기계적 결함)
통신 (네트워크 장애)
사고 분석 (항공, 의료, 운송 등)

이런 규율을 소프트웨어 운영에 도입하면 강력한 이점을 얻습니다. 똑같은 인시던트를 티켓 번호만 바꿔가며 반복해서 겪지 않게 됩니다.

시각적 RCA 기법: 손으로 그리는 헌트 경로

인시던트 조사를 종이에 그리는 보물 지도로 떠올려 보세요. 그래프를 바라보는 대신, 인시던트가 어떻게 전개됐는지를 스케치하는 겁니다.

이를 도와주는 핵심 기법은 세 가지입니다.

1. 5 Why 기법: 경로를 따라 아래로 파고들기

**5 Why(5번의 왜)**는 겉보기에 아주 단순합니다.

문제를 명확히 적는다.
“왜 이런 일이 발생했지?”라고 묻고, 그 답을 쓴다.
나온 답을 가지고 다시 “왜?”라고 묻는다.
이 과정을 루트 원인(혹은 시스템적 제약)에 도달할 때까지 약 5번 반복한다.

예시:

문제: API 지연 시간이 15분 동안 급상승했다.
- 왜? 서비스 X 응답 시간이 급격히 증가했기 때문이다.
- 왜? DB 쿼리 완료를 오래 기다리고 있었기 때문이다.
- 왜? 쿼리가 풀 테이블 스캔을 하고 있었기 때문이다.
- 왜? created_at 컬럼에 인덱스가 없었기 때문이다.
- 왜? 스키마 마이그레이션 프로세스가 배포 전에 필요한 인덱스를 검증하지 않기 때문이다.

이 경우 루트 원인은 “데이터베이스가 느렸다”가 아닙니다. 스키마 마이그레이션 단계에 있는 프로세스상의 구멍입니다.

2. 어골도(이시카와 다이어그램): 지형을 그려보기

**어골도(Fishbone, Ishikawa Diagram)**는 생선 뼈처럼 생긴 다이어그램입니다.

머리: 문제 자체 (예: "체크아웃 실패율 20% 증가")
뼈대: 잠재 원인 카테고리 (예: 사람, 프로세스, 도구, 인프라, 코드, 외부 요인 등)

각 카테고리 아래에 세부 원인을 적고 서로 연결해 나갑니다.

이 시각적 구조 덕분에:

여러 관점을 강제로 검토하게 되어 (“또 DB겠지”로 끝나지 않고)
원인이 몰려 있는 영역이 한눈에 보이고
허술한 런북, 약한 테스트, 취약한 의존성 같은 시스템적 문제를 드러낼 수 있습니다.

3. 타임라인 분석: 흔적을 따라가기

타임라인 분석은 인시던트 여정을 기록하는 작업입니다.

무엇이 가장 먼저 일어났는가?
그 다음에는?
누가, 언제 무엇을 했는가?

이를 위해 시간 순서대로 다음을 정리합니다.

시스템 이벤트 (배포, 재시작, 오토스케일링 동작 등)
사용자에 보이는 증상 (에러, 지연 시간 급증 등)
사람의 행동 (롤백, 설정 변경, 완화 조치 등)

화이트보드에 타임라인을 그리면, 화살표를 그리고 주석을 달며 “괜찮았던 상태”에서 “불이 난 상태”까지 이어지는 흐름을 실제 선으로 따라갈 수 있습니다.

이 세 가지 기법을 함께 쓰면, 당신은 아날로그 인시던트 보물 지도 그리는 사람이 됩니다. 목적지를 찍어 맞히는 게 아니라, 실제로 그곳까지 이어지는 경로를 그려 나가는 사람이 되는 겁니다.

시정 조치: X 표시가 찍힌 곳

RCA만 하고 끝낸다면 그건 그냥 이야기일 뿐입니다.

마지막이자 가장 중요한 단계는 **시정 조치(Corrective Actions)**입니다. 인시던트 재발 가능성을 줄이기 위한 구체적인 변화입니다.

좋은 시정 조치는 다음과 같습니다.

구체적이다 – “필수 인덱스 누락 마이그레이션을 차단하는 lint 규칙 추가”처럼 명확해야 합니다.
책임자가 있다 – 담당자 혹은 담당 팀이 지정되어야 합니다.
기한이 있다 – 마감일이나 목표 스프린트가 있어야 합니다.
검증 가능하다 – 완료 여부와 효과를 나중에 확인할 수 있어야 합니다.

시정 조치에는 다음과 같은 유형이 있습니다.

기술적 조치 – 타임아웃, 재시도, 벌크헤드, 더 나은 기본값 추가 등
프로세스 개선 – 리뷰 방식 변경, 체크리스트 추가, 플레이북 개선 등
조직적 조치 – 소유권 명확화, 온콜 구조 개선 등
가시성(Observability) 강화 – 당시 없어서 힘들었던 핵심 로그/메트릭/트레이스 추가 등

보물 찾기는 루트 원인을 찾는 데서 끝나지 않습니다. 발견한 그 지점에 새로운 안전 장치를 묻어두는 때에 비로소 완성됩니다.

왜 대시보드를 더 늘릴 필요가 없는가

현대 Observability에서 가장 흔한 함정 중 하나는, 문제를 대시보드를 하나 더 만들면 해결할 수 있다고 믿는 겁니다.

실제로 필요한 것은 패널을 더 많이 만드는 것이 아니라, **더 나은 경로(Path)**입니다.

도움이 되는 것은 다음을 한데 모은 통합 Observability 플랫폼입니다.

메트릭(시간 기반 데이터: CPU, 지연 시간, 에러 카운트)
로그(텍스트 이벤트, 컨텍스트, 에러 메시지)

여기에 다음이 더해진 플랫폼입니다.

단순하지만 강력한 검색 (서비스, 엔드포인트, 사용자, Trace ID로 필터링)
빠른 필터링 (시간 범위, 에러 코드, 버전, 리전 등)

이 정도면 57번째 대시보드를 만들지 않고도 인시던트의 경로를 추적하는 데 충분합니다.

새로운 대시보드 없이도 가능한 경로 예시

POST /checkout의 5xx 에러 스파이크를 발견한다.
지난 30분 동안 해당 라우트의 로그만 필터링한다.
공통된 에러 패턴과 특정 Trace ID를 발견한다.
그 Trace ID에 해당하는 분산 트레이스를 열어본다.
어떤 서비스나 호출이 느리거나 실패하는지 확인한다.
그 서비스의 로그와 메트릭으로 다시 넘어가서 확증한다.

이렇게 메트릭, 로그, 트레이스를 가로질러 하나의 경로를 따라갔습니다. 새로운 대시보드는 전혀 만들지 않았습니다.

분산 트레이싱: 그 자체가 보물 지도

RCA가 조사 방법이라면, **분산 트레이싱(Distributed Tracing)**은 인시던트의 수작업 보물 지도에 해당합니다.

Jaeger, Zipkin, OpenTelemetry, Grafana Tempo 같은 도구는 하나의 요청이 시스템 전체를 어떻게 흐르는지 시각화합니다.

각 Span은 여정의 한 단계입니다. (예: 인증 서비스, 장바구니 서비스, 결제 게이트웨이 호출 등)
각 단계에서 소요 시간, 에러, 재시도, 컨텍스트를 서비스 간에 걸쳐 볼 수 있습니다.

인시던트 상황에서 트레이스는 발자국을 따라가는 것과 같습니다.

요청이 어디에서 느려졌는가?
어느 서비스가 에러를 일으켰는가?
재시도 폭풍(retry storm)이나 연쇄 장애가 있었는가?

이런 시각적 흐름은 RCA에 매우 잘 맞습니다.

트레이스를 Export하거나 스크린샷으로 남긴 뒤, 사후 리뷰에서 위에 직접 그림을 그려 넣을 수 있습니다.
문제 있는 Span 하나하나가 5 Why나 어골도 다이어그램의 노드가 됩니다.
트레이스의 타임스탬프를 당신이 만든 타임라인 분석과 정렬해서 볼 수 있습니다.

분산 트레이스는 단지 뭔가 잘못됐다는 사실만 보여주는 게 아닙니다. 어디서, 어떻게 경로를 따라가다 잘못됐는지를 보여줍니다.

반응형에서 선제적 대응으로: 헌트 경로를 관행에 녹이기

대시보드를 멍하니 보는 반응형 대응에서 벗어나, 선제적인 헌트 경로 중심 대응으로 넘어가려면 다음을 인시던트 프로세스에 아예 박아 넣어야 합니다.

사후 리뷰 때는 항상 무언가를 그린다.
- 5 Why 체인
- 어골도 다이어그램
- 트레이스와 타임라인을 결합한 스케치
패널이 아닌 경로에서 출발한다.
- Observability 플랫폼의 검색 기능을 첫 진입점으로 삼고
- 메트릭, 로그, 트레이스를 오가며 스토리를 구성한다.
트레이싱을 1급 시민으로 대우한다.
- OpenTelemetry나 유사한 도구로 서비스에 트레이싱을 심고
- Trace ID가 로그와 메트릭 전체에 잘 전파되게 한다.
시정 조치를 ‘협상 불가’ 요소로 취급한다.
- 시정 조치가 정의되고, 책임자가 있고, 추적 가능해질 때까지 인시던트는 끝난 것이 아니다.
다른 산업의 관행을 가져온다.
- 제조, 항공, 의료 등의 RCA 체크리스트를 참고하고
- 그들의 엄격함을 우리 인시던트 프로세스에 맞게 변형해 적용한다.

이 과정을 거치다 보면, 팀의 기본 반응이 “대시보드부터 다 열어봐”에서 “이 인시던트의 경로는 어떻게 되지?”로 바뀌게 됩니다.

결론: 보물 지도 그리는 사람이 되라

현대 시스템은 정적인 차트만 바라보며 디버깅하기에는 너무 복잡합니다. 필요한 것은 스냅샷이 아니라 스토리, 패널이 아니라 경로입니다.

다음을 결합하면:

구조화된 루트 원인 분석 (5 Why, 어골도, 타임라인 분석)
실제로 시스템과 프로세스를 바꾸는 시정 조치
단순하지만 강력한 검색이 가능한 통합 Observability 플랫폼
실제 요청 흐름을 시각화해 주는 분산 트레이싱 도구

…인시던트는 반복되는 악몽에서, 매번 시스템을 더 튼튼하게 만들어 주는 구조화된 보물 찾기로 바뀝니다.

당신의 조직에서 아날로그 인시던트 보물 지도 그리는 사람이 되세요.

경로를 스케치하고
“왜?”를 계속해서 물으며
트레이스와 타임라인을 지도처럼 활용하고
시정 조치로 X 표시가 있는 지점을 남기세요.

더 많은 대시보드는 필요 없습니다. 필요한 것은 더 나은 지도와, 그 지도를 따라 루트 원인까지 끝까지 가는 연습입니다.