3 pillars 가 더 이상 충분하지 않은 이유 — 23분의 인시던트 노트

03:11. 페이저가 울려 일어났다. 알람 본문은 결제 성공률 -2.3% (지난 5분). 우리 SLO 임계는 -1%.

내가 가장 먼저 본 곳 — Grafana 의 핵심 메트릭 대시보드. 모두 초록색. CPU·메모리·QPS·에러율·p95 응답시간 — 정상 범위. 다음 — Loki 로그. 아무것도 비정상 없음. 다음 — Tempo trace. 평균보다 오히려 빨라졌다 (이상한데 깨진 건 아님).

3 pillars 모두 정상 으로 보였다. 그런데 23명의 사용자가 23분 동안 결제를 못 하고 있었다.

이게 2025년의 observability 가 3 pillars 로 안 되는 정확한 모양이다.

무엇이 깨졌는가

23분 후 (사고 발견 시점이 아니라 원인 발견 시점), 진짜 원인이 드러났다. 3시간 전 배포한 새 결제 검증 단계가 특정 카드사 + 특정 거래액 범위 + 특정 시간대 의 조합에서 외부 게이트웨이를 호출하지 않고 silently 거부 하고 있었다.

서버 입장에서는 정상 응답 (HTTP 200, 우리 시스템 안에서는 valid response). 메트릭 입장에서는 에러 아님. 로그 입장에서는 예상된 분기. trace 입장에서는 짧고 깨끗한 trace.

3 pillars 모두 옳았다. 다만 그 옳음이 사용자 경험의 진실 과 어긋나고 있었다.

왜 3 pillars 가 부족했나

3 pillars 가 답하는 질문:
  - "시스템에 무슨 일이 일어나고 있는가?"   (logs)
  - "시스템의 health 가 어떤가?"            (metrics)
  - "이 요청이 어떤 경로로 갔나?"           (traces)

3 pillars 가 답하지 못하는 질문:
  - "*사용자* 입장에서 무슨 일이 있었는가?"
  - "*어떤 변경* 이 이걸 일으켰는가?"
  - "이 인시던트가 *전에 있었던 것* 과 비슷한가?"
  - "이 변경 이후 *조용히 망가진 것* 이 있는가?"

03:11 의 인시던트는 4번째 질문에 답해야 풀렸다 — 3시간 전 배포 이후 한 가지 코드 경로가 silently 망가졌고, 그것이 사용자에게만 보였다. 이 답을 3 pillars 안에서 찾을 수가 없다.

그래서 우리가 추가한 4개

3 pillars 위에 4개의 신호를 추가했다. 대체 가 아니라 그래프 위에 더 올린 거다.

1. Events — 의미 있는 일이 일어났다는 사실

배포·feature flag 변경·DB 마이그레이션·자격 회전 같은 시스템 상태를 바꾸는 단발 사건. metrics 가 시간선 이라면, events 는 그 시간선 위의 marker. 우리는 모든 배포·flag toggle·인프라 변경을 동일한 event stream 에 박는다.

03:11 인시던트가 났을 때, 3시간 전 배포 가 events stream 의 같은 화면에 있었다면 22분이 줄었다.

2. User journeys — 사용자 1명의 한 흐름

특정 사용자 ID 가 세션 시작 → 결제 시도 → 결제 결과 까지 거친 모든 시스템 단계의 합본. 단순 trace 보다 한 단계 위 — 비즈니스 의도 가 라벨로 박혀 있다.

23명의 실패한 사용자의 journey 를 한 화면 에서 비교하면 공통 패턴 이 즉시 보였다. 카드사 X, 시각대 Y, 거래액 Z. 이것이 trace 만으로는 안 보이는 정보.

3. Deploy correlation — 어떤 변경이 이걸 일으켰나

각 배포에 그 배포가 영향을 미친 코드 경로 / 사용자 segment / 메트릭 변화 를 자동 attribution. 이건 무거운 인프라지만, 3시간 전 배포 가 결제 실패율 변화 와 자동 연결 되면 인시던트의 70% 는 5분 안에 풀린다.

4. Similarity matching — 이 인시던트가 전에 본 것 인가

과거 postmortem 을 vector store 에 박아두고, 새 인시던트의 신호 패턴과 유사도 매칭. "6개월 전 비슷한 패턴이 있었음" 이 페이저 알람과 같이 뜨면, 그 6개월 전 postmortem 의 root cause 를 즉시 검토할 수 있다.

이 네 번째가 가장 나중에 추가했고, 가장 효과 컸다. 인시던트는 종종 세 번째 만에야 root cause 를 찾는다. similarity matching 이 첫 번째 발생 시 그것을 두 번째 발생처럼 다루게 해 준다.

6개월 후 — 인시던트 평균 시간

3 pillars 만:
  - 평균 발견 시간 (TTD):       4.2 분
  - 평균 원인 파악 시간 (TTI):  37 분
  - 평균 복구 시간 (TTR):       12 분
  - MTTR 합:                   53 분

3 pillars + 4 추가 신호:
  - TTD:                        3.8 분
  - TTI:                        9 분  ←── 4× 단축
  - TTR:                        11 분
  - MTTR 합:                    23 분

TTD (발견) 와 TTR (복구) 는 거의 안 변했다. 변화는 TTI (원인 파악) 에 다 몰렸다. 3 pillars 는 발견과 복구 를 잘하고, 원인 파악 을 못 한다 — 그게 이번 변화의 한 줄 요약.

우리가 3 pillars 를 버린 게 아니다

logs·metrics·traces 는 여전히 모든 것의 기반 이다. 위 4개를 짓는 데 그 셋이 없으면 시작도 못 한다. 우리가 한 건 그것들 위에 4개를 더 올린 것 — 그리고 팀의 첫 화면 을 metrics 대시보드에서 events + user journeys 로 바꾼 것.

누가 이 글을 읽으면 좋은가

지금 o11y 스택은 다 갖췄는데 인시던트 시간이 줄지 않는 팀. 발견은 빠른데 원인 파악이 30~60분 이면 위 4개 중 한 개 이상이 빠진 상태다. 4개 모두 갖추면 분기당 수 시간의 인시던트 응대 시간 이 사라진다.