운영 중인 LLM 관측성: 정확도보다 먼저 봐야 할 네 가지

LLM 기능은 같은 입력에도 확률적으로 다른 출력을 만들고, 모델 제공자·검색 인덱스·시스템 프롬프트·도구 API 중 하나만 바뀌어도 품질이 달라질 수 있다. 전통적인 애플리케이션처럼 HTTP 200과 평균 지연만 보면 “정상적으로 빠르게 틀린 답을 생성하는” 장애를 놓친다. 반대로 모든 프롬프트와 응답을 원문으로 저장하면 관측 시스템이 개인정보와 영업비밀을 모으는 새로운 위험이 된다.

좋은 관측성은 많은 로그가 아니라 질문에 답할 수 있는 연결 구조다. “어떤 사용자가 어떤 기능 버전에서 어떤 데이터에 접근했고, 어느 모델과 도구가 어떤 결정을 거쳐 최종 응답을 만들었으며, 비용과 품질은 어땠는가”를 필요한 범위에서 재구성할 수 있어야 한다.

네 축을 분리해 본다

축	핵심 질문	예시 지표
품질	답이 업무 목적에 맞고 근거가 충분한가	평가 점수, 근거 일치율, 재질문·수정률
안전성	금지된 내용·데이터·행동이 노출되거나 실행됐는가	정책 거절률, 민감정보 탐지, 위험 도구 호출
신뢰성	제시간에 성공하고 장애 시 안전하게 실패하는가	성공률, 지연 백분위, 타임아웃, 폴백률
비용·용량	사용자 가치에 비해 비용과 자원이 통제되는가	입력·출력 토큰, 검색·도구 비용, 요청당 총비용

네 축은 서로 충돌할 수 있다. 거절률이 낮아졌다고 품질이 좋아진 것이 아닐 수 있고, 긴 문맥을 넣어 평가 점수가 올라도 지연과 데이터 노출 위험이 커질 수 있다. 릴리스 판단에서는 단일 평균이 아니라 기능·고객군·언어·위험 등급별로 지표를 나눠 본다.

추적 단위를 먼저 정의한다

한 사용자 요청에 trace_id를 부여하고 다음 단계를 자식 구간으로 연결한다.

1. 입력 전처리와 정책 검사
2. 검색 쿼리 생성과 문서 조회
3. 문서 권한 필터와 재순위화
4. 모델 호출과 재시도·폴백
5. 도구 선택, 인자 검증, 승인, 실행
6. 출력 정책 검사와 후처리
7. 사용자 전달과 피드백

각 구간에는 원문 전체 대신 필요한 메타데이터를 우선 남긴다. 예를 들어 model_provider, model_name, prompt_template_version, retrieval_index_version, tool_name, policy_version, latency_ms, token_count, result_status, reason_code다.

사용자·문서 식별자는 접근 통제된 가명값이나 내부 참조로 남기고, 로그만으로 원문 데이터를 복원하지 못하게 한다.

원문 프롬프트를 남기지 않고도 조사할 수 있는 필드

• 요청 기능과 테넌트, 위험 등급, 언어
• 입력 길이, 첨부 수, 민감정보 분류 결과
• 적용된 시스템 프롬프트와 정책의 버전
• 검색된 문서 ID의 해시 또는 접근 통제된 참조, 권한 필터 결과
• 모델·지역·파라미터·재시도·폴백 정보
• 도구 이름, 읽기·쓰기 등 권한 등급, 승인 여부, 실행 결과
• 출력 길이, 인용 수, 정책 검사 결과, 이유 코드
• 사용자가 재생성·수정·신고·취소한 행동
• 요청당 지연과 비용, 실패 단계

원문이 꼭 필요한 품질 조사나 안전 사고에서는 샘플링, 별도 승인, 짧은 보존, 필드 마스킹, 접근 감사가 필요하다. 운영 로그와 평가 데이터셋을 섞지 말고, 연구·개선 목적으로 재사용할 수 있는 데이터의 법적 근거와 고객 약정을 별도로 검토한다.

품질을 운영 지표로 바꾸는 방법

“정확도”는 기능마다 정의가 다르다. 검색 답변은 근거가 실제 문서를 지지하는지, 요약은 핵심 사실을 빠뜨리지 않았는지, 코드 생성은 테스트를 통과하는지, 에이전트는 허용된 목표를 달성했는지 측정해야 한다.

온라인 신호

• 사용자의 재질문, 재생성, 즉시 이탈, 수동 수정
• 인용 링크 클릭과 근거 문서 일치 여부
• 상담원 전환, 작업 취소, 도구 실행 되돌리기
• 신고 사유와 심각도, 고객지원 티켓

오프라인 평가

• 대표 업무와 고위험 경계 사례를 포함한 고정 평가셋
• 모델 변경 때마다 비교하는 회귀 테스트
• 언어·고객군·문서 최신성별 분할 결과
• 사람 평가자 간 일치도와 평가 기준 버전
• 안전 정책과 업무 성공을 함께 보는 다중 점수

온라인 신호는 실제 사용자 행동을 반영하지만 정답이 아닐 수 있고, 오프라인 평가셋은 반복 가능하지만 운영 분포 변화를 놓칠 수 있다. 두 종류를 함께 보고, 평가셋이 운영 데이터에 노출되어 과적합되지 않게 관리한다.

도구 호출은 별도 보안 경계다

LLM이 이메일 발송, 결제, 티켓 수정, 코드 배포처럼 외부 상태를 바꾸는 도구를 호출하면 텍스트 품질보다 권한과 승인 흐름이 중요하다.

• 읽기와 쓰기 도구를 분리하고 기본 권한은 읽기로 둔다.
• 모델이 생성한 인자를 스키마와 업무 규칙으로 다시 검증한다.
• 금액, 수신자, 삭제, 권한 변경 등 고위험 행동은 사람 승인을 요구한다.
• 승인 화면에는 모델 설명이 아니라 실제 실행될 대상과 변경 내용을 보여 준다.
• 도구 자격 증명은 사용자·테넌트 범위를 넘지 않게 제한한다.
• 중복 실행을 막는 멱등성 키와 취소·보상 절차를 준비한다.

도구 호출 로그에는 선택 이유 문자열보다 tool_name, 권한 등급, 인자 분류, 승인자, 실행 결과, 외부 시스템의 작업 ID가 더 중요하다. 안전한 기본값을 제품 요구사항에 넣는 방법은 Secure by Default 제품 설계와 연결된다.

실패 모드와 탐지 신호

실패 모드	탐지 신호	확인할 내용
공급자·모델 변경 후 품질 회귀	지연은 정상인데 재질문·신고가 특정 버전에서 증가	모델·프롬프트·평가 버전을 연결했는가
검색 권한 필터 누락	다른 테넌트 문서 참조 또는 민감 문서 조회 증가	검색 전후 권한 검증과 문서 접근 로그가 있는가
재시도 폭주	요청당 모델 호출 수와 비용 급증	재시도 상한, 지수 백오프, 전체 시간 예산이 있는가
안전 필터 과잉	특정 언어·고객군의 거절률과 이탈률 급증	이유 코드와 세그먼트별 기준선을 보는가
도구 인자 조작	예상하지 않은 수신자·경로·금액으로 실행 시도	서버 측 스키마·권한·업무 검증을 하는가
로그가 민감정보 저장소화	프롬프트 원문 조회·내보내기 증가	마스킹, 보존, 접근 승인과 감사가 있는가
비용 최적화가 품질 저하	저가 모델 전환 뒤 폴백·수정률 증가	요청당 총비용과 업무 성공률을 함께 보는가

특히 평균값은 장애를 숨긴다. 한 언어 또는 긴 문서 요청에서만 품질이 무너져도 전체 평균 변화는 작을 수 있다. 상위 지연, 고비용 요청, 안전 신고가 많은 세그먼트를 별도 큐로 검토한다.

릴리스 게이트와 롤백

모델, 시스템 프롬프트, 검색 설정, 도구 정책은 모두 독립 배포물로 취급한다.

배포 전

• 변경 대상과 버전을 식별하고 이전 조합을 재현할 수 있는가.
• 고정 평가셋과 최근 운영 표본에서 기준선을 통과했는가.
• 비용·지연·거절률의 허용 변화 범위를 정했는가.
• 쓰기 도구의 권한과 승인 흐름이 바뀌지 않았는가.
• 로그 스키마와 마스킹이 새 필드를 처리하는가.

배포 후

• 작은 트래픽부터 카나리로 비교하는가.
• 품질·안전·지연·비용 중 하나라도 임계값을 넘으면 자동 중지하는가.
• 공급자 상태와 내부 검색·도구 장애를 분리할 수 있는가.
• 프롬프트만 이전 버전으로, 모델만 이전 버전으로 각각 롤백할 수 있는가.
• 이미 실행된 외부 작업을 되돌리거나 검토할 목록을 만들 수 있는가.

운영 대시보드의 최소 구성

• 기능·모델·프롬프트 버전별 성공률과 지연 백분위
• 입력·출력 토큰, 검색·도구 호출, 요청당 총비용
• 정책 거절·출력 차단의 이유 코드와 사용자 재시도
• 검색 문서 수, 빈 검색률, 권한 필터 탈락률, 인용 일치율
• 도구 선택률, 승인률, 실패율, 취소·보상률
• 재생성·수정·신고·상담원 전환율
• 로그 누락, 추적 단절, 마스킹 실패, 데이터 보존 초과
• 공급자·지역·언어·테넌트별 이상 분포

이 데이터를 기존 관측 플랫폼에 넣을 때 일반 애플리케이션 로그와 LLM 전용 이벤트를 같은 추적 ID로 연결하되, 접근 권한과 보존 정책은 분리하는 것이 좋다. 수집 구조는 보안 로그 파이프라인의 최소 요건을 기준으로 잡을 수 있다.

사고 대응 질문

• 문제가 특정 모델, 프롬프트, 검색 인덱스, 도구 정책 중 어디서 시작됐는가.
• 어떤 테넌트와 데이터 분류가 영향을 받았는가.
• 잘못된 응답만 생성됐는가, 외부 시스템 변경까지 실행됐는가.
• 원문을 보지 않고도 영향 범위를 계산할 메타데이터가 있는가.
• 기능 비활성화, 읽기 전용 전환, 폴백 모델 중 가장 안전한 조치는 무엇인가.
• 사용자 통지, 데이터 삭제, 공급자 문의가 필요한가.

참고 기준

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications 2025
• OpenTelemetry Generative AI semantic conventions
• Google Cloud SRE

최종 판단

운영 중인 LLM의 관측성은 모델 호출 수를 세는 일이 아니다. 품질, 안전성, 신뢰성, 비용을 같은 요청 흐름에서 비교하고, 데이터와 도구 권한이 어디까지 사용됐는지 재구성하는 능력이다.

원문을 무조건 저장하지 않아도 버전·이유 코드·권한·결과를 잘 설계하면 대부분의 운영 질문에 답할 수 있다. 가장 먼저 할 일은 현재 기능의 요청 한 건을 끝까지 추적해 어느 단계의 버전과 결과가 빠져 있는지 확인하는 것이다.