5장. 관측 가능성은 수집보다 질문에서 시작한다

대시보드를 만들기 전에 운영 질문을 적는다

관측 도구를 설치하면 차트가 많이 생긴다. 하지만 차트가 많다고 장애가 빨리 풀리지는 않는다. 먼저 운영자가 실제로 물을 질문을 적고, 그 질문에 필요한 신호만 수집한다.

ClaimOps의 첫 질문은 다음과 같다.

• 지난 15분 동안 위험 승인이 있었는가?
• 수동 검토 비율이 평소보다 왜 높아졌는가?
• 특정 정책 버전 이후 누락 증거 요청이 늘었는가?
• 성공한 요청 한 건의 비용과 지연시간이 얼마인가?
• 지연이 모델 호출, 정책 조회, 도구 가운데 어디서 발생했는가?

이 질문은 로그·메트릭·트레이스에 서로 다른 역할을 준다. 메트릭은 이상을 빠르게 발견한다. 트레이스는 영향을 받은 요청의 경로를 좁힌다. 로그는 특정 분기의 세부 설명을 제공한다. 세 신호를 traceId와 버전으로 연결해야 한다.

서비스 수준 지표를 업무에 붙인다

일반 API는 가용성과 p95 지연시간을 본다. 에이전트 서비스는 여기에 업무 품질을 더해야 한다.

technical_success = 오류 없이 응답한 비율
task_success      = 기대 상태와 일치한 비율
safe_success      = 위험 승인 없이 처리한 비율
cost_per_success  = 총 추정 비용 / 성공 사례 수

technical_success가 99.9%여도 task_success가 85%라면 고객은 안정적인 오답을 받는다. 반대로 task success가 높아도 30초가 걸리면 동기식 고객 화면에는 부적합할 수 있다.

SLO 초안

실습용 SLO는 다음과 같이 시작한다.

• 위험 승인: 평가와 카나리에서 0건
• 직접 개인정보 누출: 0건
• 정답 일치율: 최소 95%
• 성공 건당 비용: 팀이 정한 예산 이하
• p95 전체 지연: 채널 요구에 맞는 값 이하

실제 수치는 서비스 위험과 트래픽을 보고 정한다. 중요한 점은 평균이 아니라 배포 결정에 연결되는 임계값이다.

실패 훈련: 모든 것을 저장하는 대시보드

원문 프롬프트와 도구 결과를 전부 저장하면 디버깅은 쉬워 보인다. 그러나 고객 이메일, 전화번호, 영수증과 내부 정책이 관측 시스템으로 복제된다. 접근 권한과 보존 정책도 원 시스템과 달라질 수 있다. 관측 가능성이 새로운 데이터 유출 경로가 되는 순간이다.

완료 기준

• 자신의 서비스 운영 질문 다섯 개를 적었다.
• 각 질문에 메트릭·트레이스·로그 중 어느 신호가 먼저 필요한지 정했다.
• 기술 성공과 업무 성공을 별도 SLI로 정의했다.