1. 런북은 장애 문서가 아니라 운영 기준서다

LLM 서비스에서는 같은 장애라도 원인이 다양합니다. 모델 지연, 프롬프트 회귀, 벡터 검색 실패, 토큰 폭증, 도구 호출 예외가 비슷한 사용자 불만으로 나타날 수 있습니다. 그래서 관측성 런북은 단순 장애 대응 절차보다, 어떤 신호를 보고 어떤 가설을 먼저 검증할지 정하는 운영 기준서에 가깝습니다.

좋은 런북은 새 담당자도 같은 방식으로 문제를 좁힐 수 있어야 합니다. 즉 시스템 구조 설명, 주요 지표 정의, 오류 분류, 즉시 조치 순서, 사후 회고 기준이 한 문서 안에서 이어져야 합니다.

2. 최소 수집 항목을 명확히 해야 한다

관측성이 약한 팀은 로그를 많이 모으지만 정작 판단에 필요한 연결 정보가 빠져 있는 경우가 많습니다. LLM 런북에서는 요청 단위 식별자와 추적 맥락이 가장 중요합니다. 사용자 입력, 모델 이름, 프롬프트 버전, 도구 호출 단계, 응답 시간, 토큰 사용량, 최종 결과를 같은 트레이스에서 볼 수 있어야 합니다.

  • 요청 메타데이터: 사용자 세션, 기능 이름, 모델 버전, 프롬프트 버전
  • 성능 지표: 전체 지연 시간, 첫 토큰까지 시간, 토큰 사용량, 재시도 횟수
  • 품질 신호: 안전 필터 작동, 거절률, 평가 점수, 사용자 불만 및 수동 리뷰 결과

이 정도가 갖춰져야 특정 배포 이후 어떤 프롬프트 버전이 응답 품질을 떨어뜨렸는지, 아니면 모델은 정상인데 외부 도구 타임아웃이 증가했는지 구분할 수 있습니다.

3. 장애 대응 흐름은 가설 중심으로 작성한다

런북 본문은 "어떤 알림이 오면 어디부터 본다"가 분명해야 합니다. 예를 들어 응답 시간이 급증하면 모델 API 자체 지연인지, 검색 파이프라인 병목인지, 재시도 루프가 생긴 것인지 분리해야 합니다. 또 환각이나 잘못된 도구 선택이 늘어나면 단순히 모델 문제로 넘기지 말고 최근 프롬프트 변경, 컨텍스트 길이, 검색 품질, 정책 필터 변경을 같이 비교해야 합니다.

실제 문서에는 아래 순서가 실용적입니다. 첫째, 영향 범위를 확인한다. 둘째, 최근 배포와 설정 변경을 본다. 셋째, 대표 실패 트레이스를 3~5개 열어 공통 패턴을 찾는다. 넷째, 임시 완화 조치와 장기 수정안을 분리한다. 이 방식이 있어야 런북이 체크리스트가 아니라 판단 도구가 됩니다.

4. 런북에는 평가 체계가 같이 들어가야 한다

LLM 운영은 관측성과 평가가 분리되면 금방 한계가 옵니다. 로그는 무엇이 일어났는지 보여주고, 평가는 그것이 좋은 결과였는지 판정합니다. 따라서 런북에는 프로덕션 트레이스에서 표본을 뽑아 정기적으로 채점하는 방식이 포함되어야 합니다.

예를 들어 고가치 기능은 주간 단위로 응답 정확성, 정책 준수, 도구 선택 적절성, 최종 과업 완료 여부를 점검할 수 있습니다. 이 결과는 단순 보고용이 아니라, 어떤 프롬프트와 오케스트레이션 변경을 롤백하거나 확장할지 결정하는 근거가 됩니다.

5. 사후 회고는 재현 가능한 변경으로 끝나야 한다

런북의 마지막 섹션은 늘 포스트모템과 연결되어야 합니다. 장애를 처리하고 끝내는 것이 아니라, 어떤 경고 조건이 늦었는지, 어떤 로그 필드가 부족했는지, 어떤 테스트가 미리 있었으면 막을 수 있었는지를 남겨야 합니다. 그래야 관측성 체계가 다음 배포에서 실제로 더 강해집니다.

결론적으로 LLM 관측성 런북은 로그 모음집이 아닙니다. 서비스 구조, 신호 표준, 대응 절차, 평가 루프, 회고 기준이 하나로 이어진 운영 문서여야 합니다.

실무 체크포인트

  • 트레이스 하나만 열어도 모델, 프롬프트, 도구 호출, 오류, 토큰 사용량이 이어서 보여야 한다.
  • 장애 대응 절차에는 최근 배포 비교와 대표 실패 트레이스 샘플링 단계가 포함되어야 한다.
  • 운영 로그와 평가 결과를 분리하지 말고 같은 개선 루프로 연결해야 한다.

참고 자료