플랫폼 관측성과 인시던트 대응 시스템 설계

많은 조직이 관측성 스택은 갖고 있다. Prometheus도 있고, 로그도 쌓이고, APM도 있다. 그런데 장애가 나면 여전히 슬랙에서 "혹시 DB 쪽인가요?"라는 추측부터 시작한다. 이유는 간단하다. 관측성을 데이터 수집 문제로만 보고, **인시던트 대응 시스템**으로 설계하지 않았기 때문이다.

좋은 관측성은 그래프를 많이 그리는 것이 아니다. 누가, 어떤 경보를 받고, 어떤 지표를 먼저 보고, 어떤 로그와 트레이스를 연결하고, 언제 사람을 깨우고, 언제 자동 복구를 시도할지까지 포함한 운영 체계다.

관측성의 목표를 다시 정의하기

관측성의 목적은 “시스템이 내부적으로 무엇을 하는지 이해한다”에서 끝나지 않는다. 프로덕션에서는 더 직접적이어야 한다.

이상을 빠르게 감지한다.
영향 범위를 빠르게 파악한다.
가설을 빠르게 줄인다.
복구 조치를 빠르게 실행한다.
사후 학습을 다음 설계에 반영한다.

즉 관측성은 탐미적 대시보드가 아니라 평균 복구 시간과 잘못된 각성(alert fatigue)을 줄이기 위한 시스템이다.

세 신호는 따로가 아니라 함께 설계해야 한다

[Metrics] -> what is wrong?
   |
   v
[Logs]    -> what happened?
   |
   v
[Traces]  -> where did it happen?

메트릭, 로그, 트레이스는 대체재가 아니다.

메트릭은 이상 감지와 추세 파악에 강하다.
로그는 사건의 구체적 맥락을 준다.
트레이스는 요청 경로와 병목 위치를 보여준다.

문제는 많은 팀이 이 셋을 따로 구축한다는 점이다. 경보는 메트릭에서 오는데, 로그에 trace id가 없고, 트레이스에는 비즈니스 키가 없어서 실제 복구까지 시간이 오래 걸린다.

경보는 많을수록 좋은 것이 아니라 정확할수록 좋다

낮은 품질의 경보는 장애보다 더 빨리 팀을 마모시킨다. 좋은 경보는 다음 속성을 가진다.

사용자 영향과 연결된다.
담당 팀이 행동 가능한 단위다.
일시적 스파이크에 덜 민감하다.
알람 하나가 하나의 가설 공간을 준다.

나쁜 예:

CPU 80% 초과
에러 로그 한 줄 발생
pod 재시작 1회

좋은 예:

결제 API 5분 에러율 3% 초과 + 트래픽 기준치 이상
핵심 checkout flow p95 지연 2배 증가
특정 리전에서 로그인 성공률 급락

경보는 인프라 상태보다 사용자 영향과 가까울수록 좋다.

SLO는 보고서가 아니라 경보 기준선이다

SLO가 문서로만 존재하면 운영에는 도움이 안 된다. SLO는 다음을 연결해야 한다.

무엇이 좋은 서비스인가
어느 정도 실패를 허용할 것인가
예산을 다 쓰면 어떤 대응을 할 것인가

예를 들어 주문 생성 API의 가용성 SLO가 99.9%라면, 경보와 릴리즈 정책도 이 목표와 연결되어야 한다. 에러 버짓을 빠르게 소진하고 있다면 신규 기능보다 안정화 작업을 우선해야 한다.

대시보드는 설명용이 아니라 대응용이어야 한다

운영 대시보드에서 가장 흔한 문제는 정보는 많지만 질문에 답하지 못한다는 점이다. 인시던트 중 대시보드는 최소한 다음 순서로 읽혀야 한다.

현재 영향이 있는가
어느 서비스, 어느 리전, 어느 엔드포인트인가
언제 시작됐는가
포화, 에러, 지연 중 무엇이 원인에 가까운가
최근 배포나 설정 변경이 있었는가

좋은 대시보드는 화면 수가 적어도 된다. 핵심 흐름별로 다음이 한 화면에 이어져야 한다.

트래픽
에러율
지연 분포
종속성 상태
최근 배포 이벤트

런북은 문서가 아니라 실행 경로다

인시던트가 터졌을 때 “이건 위키 어디에 있지?”가 나오면 이미 늦다. 런북은 다음을 명확히 해야 한다.

이 경보가 의미하는 사용자 영향
가장 흔한 원인 후보
첫 5분 안에 확인할 지표와 로그
즉시 가능한 완화 조치
에스컬레이션 기준

Alert: checkout-error-rate-high
1. Verify user impact on checkout success dashboard
2. Check deployment timeline in last 30 minutes
3. Correlate trace latency on payment dependency
4. If payment timeout dominant, enable fallback or rate limiting
5. If DB saturation dominant, scale read replicas or shed noncritical traffic

런북이 길다고 좋은 것이 아니다. 인시던트 중에는 짧고 행동 가능한 문서만 읽힌다.

상관관계를 심어야 추측이 줄어든다

메트릭, 로그, 트레이스, 배포 이벤트, 비즈니스 키가 서로 연결되어야 한다.

로그에 trace_id, span_id, tenant_id, order_id를 남긴다.
트레이스에 HTTP route, DB statement class, external dependency 이름을 남긴다.
배포 시스템 이벤트를 대시보드에 찍는다.
에러율 급등 시 상위 예외 유형과 릴리즈 버전을 바로 볼 수 있게 한다.

이 연결이 없으면 인시던트 대응은 결국 경험 많은 한두 명의 직감에 의존한다.

포스트모템은 책임 추궁이 아니라 피드백 루프여야 한다

장애 대응 체계가 성숙하려면 포스트모템이 기술 설계와 운영 절차를 바꿔야 한다. 좋은 포스트모템 질문은 다음과 같다.

무엇이 처음 감지되었고, 무엇은 보이지 않았는가
왜 경보가 너무 늦었거나 너무 시끄러웠는가
어떤 런북이 비어 있었는가
어떤 지표나 태그가 있었으면 추적이 빨라졌는가
재발 방지를 위해 코드, 인프라, 문서 중 무엇을 바꿀 것인가

결과물은 문서가 아니라 변화여야 한다.

실전 운영 체크리스트

핵심 사용자 흐름마다 SLI/SLO가 정의돼 있는가
경보가 인프라 상태보다 사용자 영향에 가까운가
경보마다 명확한 담당 팀과 런북이 연결돼 있는가
로그와 트레이스에 공통 correlation key가 있는가
대시보드에 배포/설정 변경 이벤트가 함께 보이는가
알람 피로도를 주기적으로 리뷰하는가
포스트모템 액션이 실제 티켓과 우선순위로 이어지는가

마무리

관측성은 수집 도구의 조합이 아니라 장애를 감지하고, 범위를 좁히고, 복구하고, 학습하는 운영 시스템이다. 메트릭, 로그, 트레이스, 경보, 런북, SLO, 포스트모템이 따로 놀면 툴은 많아도 대응은 느리다. 반대로 이 요소들이 하나의 대응 경로로 연결되면, 같은 도구로도 훨씬 더 적은 추측과 더 빠른 복구가 가능해진다.

운영 환경에서 어려워지는 지점

관측성이 사고 대응에 도움이 되려면 telemetry가 서비스 소유권과 사용자 영향 질문에 연결되어 있어야 한다.
운영 의사결정 경로 없이 메트릭, 로그, 트레이스만 늘어나면 팀은 대시보드에 잠긴다.
좋은 대응은 도구만큼 runbook, 심각도 규칙, 커뮤니케이션 흐름에도 달려 있다.

중요한 아키텍처 결정

대시보드를 늘리기 전에 핵심 사용자 여정과 SLI를 정의한다.
알림은 원시 메트릭 과잉이 아니라 실행 가능한 증상과 error budget 중심으로 설계한다.
관측 신호를 사고 역할, escalation 경로, postmortem 피드백과 연결한다.

실무 예시

효과적인 사고 흐름은 사용자 영향에서 시작해 빠르게 좁혀간다.

증상 -> 영향받은 여정 -> 담당 서비스 -> 최근 변경 -> 완화 옵션 -> 커뮤니케이션 업데이트

피해야 할 안티패턴

대응 책임자 없이 모든 기술 메트릭에 알림을 거는 것.
사고에서 아무도 쓰지 않는 트레이스와 로그를 수집하는 것.
postmortem을 비난 문서처럼 다루는 것.

운영 체크리스트

알림 피로와 확인 시간(ack time)을 검토한다.
페이징, 완화, 롤백 훈련을 실행한다.
실제 사고 뒤 대시보드 유용성을 감사한다.
사고 건수뿐 아니라 반복 원인과 해결 클래스도 추적한다.

최종 판단

플랫폼 관측성은 이해까지 걸리는 시간과 완화까지 걸리는 시간을 줄일 때 성공이다. telemetry 양만 늘린다고 그 목표가 달성되지는 않는다.

다음으로 읽기 좋은 글

🚀 DevOps

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다