옵저버빌리티(Observability, 관측 가능성)는 시스템이 남긴 기록을 연결해 “안에서 무슨 일이 일어났는지” 설명할 수 있는 능력입니다. LLM(Large Language Model, 대규모 언어 모델)을 사용하는 서비스라면, 답변 하나가 어떤 문서를 참고하고 어떤 모델과 도구를 거쳐 만들어졌는지 추적할 수 있어야 합니다.
LLM 서비스는 서버가 정상이어도 실패할 수 있습니다. 응답 코드는 200이고 지연 시간도 짧은데, 사용자에게 오래된 규정을 안내할 수 있습니다. 반대로 답변은 맞았지만 내부에서 여러 번 재시도해 예상보다 많은 시간과 비용을 썼을 수도 있습니다.
그래서 LLM 옵저버빌리티의 목표는 실행 과정, 답변 품질, 소요 시간, 비용을 같은 요청의 맥락으로 연결하는 것입니다. 이 글에서는 먼저 무엇이 보이지 않는지 살펴보고, 요청 하나를 추적하는 방법과 평가·운영 체계를 연결하는 순서로 설명합니다. 아래의 시간·비용·장애 사례는 이해를 위한 가상 예시입니다.
LLM 애플리케이션의 여러 처리 단계를 하나의 흐름으로 관찰하는 모습을 표현한 AI 생성 이미지입니다.
1. 응답 코드 200이 업무 성공을 뜻하지 않는 이유
사내 정책을 안내하는 챗봇을 생각해 보겠습니다. 사용자가 출장비 정산 기준을 물으면, 시스템은 관련 문서를 찾고 모델에 전달한 뒤 답변을 보여 줍니다. API 서버, 검색 서버, 모델 API가 모두 정상 응답했으니 운영 대시보드는 초록색입니다.
그런데 검색된 문서가 지난해 규정이라면 어떻게 될까요? 모델은 제공받은 문서를 충실하게 요약했지만 사용자에게는 틀린 안내가 전달됩니다. 이 경우 네트워크 오류도, JSON 파싱 오류도 없습니다. 전달에 성공한 응답과 사용자의 문제를 해결한 응답이 달라진 것입니다.
이런 차이는 기존 서비스에도 있습니다. 구글의 SRE 문서 역시 명시적인 HTTP 오류뿐 아니라 잘못된 내용을 반환하는 암묵적인 실패를 설명합니다. LLM 시스템에서는 생성된 문장을 대상으로 성공을 판단해야 하므로 이 문제가 더 자주 운영의 중심으로 올라옵니다. Google SRE: 분산 시스템 모니터링
성공을 적어도 세 단계로 나누면 무엇이 빠졌는지 보입니다.
예를 들어 에이전트가 “접수했습니다”라고 답해도 실제 업무 시스템에 접수 내역이 없다면 업무 성공으로 세면 안 됩니다. 반대로 권한 없는 요청을 적절히 거절했다면 정책을 지킨 정상 결과일 수 있습니다. 모든 거절을 오류로, 모든 문장 생성을 성공으로 분류하면 지표가 엉뚱한 방향으로 움직입니다.
LLM 옵저버빌리티가 필요한 첫 번째 이유는 여기에 있습니다. 서비스가 살아 있다는 사실과 서비스가 제 역할을 한다는 사실을 따로 확인해야 합니다.
2. 모델 호출 바깥에서 답변이 결정된다
실제 LLM 애플리케이션은 모델 하나로 끝나지 않습니다. RAG(Retrieval-Augmented Generation, 검색 증강 생성)를 사용한다면 질문과 관련된 외부 문서를 찾아 모델의 입력에 함께 넣습니다. 도구를 사용하는 에이전트라면 모델의 출력에 따라 검색이나 업무 API 호출이 이어집니다.
사내 정책 챗봇의 요청 하나를 따라가면 대략 다음 과정이 나타납니다.
- 사용자를 인증하고 열람할 수 있는 문서 범위를 결정합니다.
- 질문을 검색에 적합한 형태로 바꾸고 관련 문서를 찾습니다.
- 검색 결과를 다시 정렬하고, 길이 제한 안에 들어갈 문서 조각을 선택합니다.
- 시스템 지시문, 대화 이력, 문서를 조합해 모델을 호출합니다.
- 필요한 경우 도구를 실행하거나 다른 모델로 전환합니다.
- 결과 형식과 정책을 검사하고 사용자에게 응답합니다.
같은 질문에서도 이력의 길이, 검색 인덱스, 접근 권한, 선택된 문서가 달라질 수 있습니다. 모델에 전달되는 입력이 달라지면 답변 역시 바뀔 수 있습니다. 따라서 품질이 나빠졌다는 이유만으로 가장 먼저 모델을 교체하는 접근은 원인과 비용을 함께 놓칠 수 있습니다.
모델 API의 요청·응답만 저장한 경우에는 검색 전에 적용된 권한 필터나 문서를 제외한 이유를 알기 어렵습니다. 게이트웨이 로그만 보면 대화가 몇 번의 모델 호출로 이어졌는지 모를 수 있습니다. 애플리케이션의 의미를 아는 위치에서 검색, 문서 선택, 모델 호출, 도구 실행이라는 작업 단위를 기록해야 합니다.
이때 관측 범위를 과장해서는 안 됩니다. 우리가 추적하는 것은 애플리케이션에서 관찰한 입력 조건, 호출 순서, 결과와 상태입니다. 일반적인 API 계측으로 모델 내부의 비공개 추론 과정이나 가중치 수준의 판단 원인까지 복원할 수 있는 것은 아닙니다.
3. 메트릭·로그·트레이스를 같은 질문에 연결한다
관측 데이터는 보통 메트릭, 로그, 트레이스로 설명합니다. 중요한 것은 세 종류를 각각 많이 쌓는 일이 아니라, 하나의 문제를 조사할 때 서로 이어지는가입니다.
메트릭(Metric)은 시간에 따라 집계한 숫자입니다. 요청 수, 오류 비율, 지연 시간 분포처럼 “얼마나 자주, 얼마나 크게 발생하는가”를 알려 줍니다. 로그(Log)는 개별 사건의 기록입니다. 예외가 났거나 검색 결과가 비었을 때 구체적인 상태를 남길 수 있습니다.
트레이스(Trace)는 요청이 여러 작업을 거치는 경로입니다. 그 안의 스팬(Span)은 시작과 끝을 가진 작업 하나를 뜻합니다. 같은 트레이스 안에서 검색 스팬, 모델 호출 스팬, 도구 실행 스팬의 관계를 보면 어느 단계가 늦거나 실패했는지 좁혀 갈 수 있습니다. OpenTelemetry: 트레이스와 스팬
예를 들어 메트릭에서 “새 배포 이후 응답 지연이 증가했다”는 사실을 찾고, 해당 구간의 트레이스를 열어 모델 호출의 재시도를 발견한 뒤, 연결된 로그에서 제한 오류의 종류를 확인하는 식입니다. 모델 호출 기록과 로그를 시간만으로 대조하는 것보다 같은 trace_id로 연결하는 편이 조사 범위를 명확하게 만듭니다.
품질 평가는 이 실행 기록에 연결하는 또 하나의 분석 결과입니다. 평가 점수를 별도 표에 저장하더라도 어떤 요청과 응답을 평가했는지 식별할 수 있어야 합니다. 점수만 낮고 해당 답변의 검색 결과나 프롬프트 버전을 찾을 수 없다면 개선할 위치를 결정하기 어렵습니다.
여러 서비스와 비동기 작업을 통과할 때는 추적 문맥을 전달해야 합니다. OpenTelemetry의 문맥 전파는 이런 연결을 다룹니다. 하나의 대화에 여러 요청이 있는 경우에는 대화 ID로 요청들을 묶되, 요청 트레이스 하나를 며칠 동안 열린 상태로 유지하는 설계와는 구분하는 것이 좋습니다. OpenTelemetry: 문맥 전파
4. 느린 답변을 고치려면 시간을 나눠 봐야 한다
사용자가 체감한 응답 시간이 6.4초라는 사실만으로는 개선 방향이 정해지지 않습니다. 검색을 빠르게 해야 할 수도 있고, 모델의 재시도 정책을 바꿔야 할 수도 있습니다. 아래는 첫 모델 호출이 시간 초과된 뒤 재시도한 가상의 요청입니다.
공식 문서를 바탕으로 재구성한 가상 실행 타임라인입니다. 모델의 논리적 호출 아래 실제 시도와 재시도 대기를 구분했습니다. 근거: OpenTelemetry 트레이스, GenAI 스팬 규약. 시간은 측정 결과가 아닌 예시입니다.
이 요청에서는 검색과 결과 재정렬이 합쳐서 0.5초, 모델 호출과 재시도 대기가 합쳐서 5.5초입니다. 검색을 절반으로 줄여도 절감되는 시간은 0.25초입니다. 어떤 개선부터 시작할지 타임라인이 알려 주는 셈입니다.
SDK가 내부적으로 재시도한다면 최종 성공만 보이는 경우도 있으므로, 논리적 모델 호출의 전체 시간과 실제 시도 횟수를 구분해야 합니다. 현행 OpenTelemetry GenAI 스팬 규약도 자동 재시도를 포함한 논리적 작업의 기간을 다루도록 설명합니다. 개별 시도를 나눈 하위 스팬이나 이벤트의 제공 여부는 계측 구현을 확인해야 합니다.
첫 응답과 전체 완료는 다른 경험이다
스트리밍 응답에서는 첫 내용이 보일 때까지의 대기와 전체 답변이 끝날 때까지의 대기를 나눠 봅니다. TTFT(Time To First Token)는 첫 토큰이 나오기까지의 시간을 뜻하지만, 무엇을 시작점과 끝점으로 잡았는지 확인해야 비교가 가능합니다.
모델 서버 안에서 측정한 첫 토큰 시간, API 클라이언트가 받은 첫 스트리밍 조각의 시간, 사용자의 화면에 첫 내용이 표시된 시간은 서로 다릅니다. 네트워크로 전달되는 한 조각에 여러 토큰이 들어갈 수도 있고, 내용 없는 초기 조각이 먼저 올 수도 있습니다. 현행 GenAI 규약도 클라이언트의 첫 조각 지연과 서버의 첫 토큰 지연을 구분합니다. OpenTelemetry GenAI 메트릭 규약
앞의 예시에서 두 번째 모델 호출을 시작한 뒤 0.4초 만에 첫 조각을 받았다고 해 보겠습니다. 모델 클라이언트에서는 빠르게 보이지만, 요청 시작부터는 이미 4.0초가 지났습니다. 브라우저 표시까지는 추가 시간이 들 수 있습니다. 사용자 체감 지표와 모델 호출 지표를 함께 둬야 하는 이유입니다.
평균 지연만으로도 부족합니다. p95가 8초라면 해당 집계 대상의 약 95%가 8초 이내에 처리됐다는 뜻입니다. 짧은 질문과 긴 문서 요약, 스트리밍과 비스트리밍 요청을 한데 섞으면 해석이 어려워지므로 업무 유형과 모델 등 의미 있는 범위로 나눠 봅니다. 병렬 호출이 있다면 하위 스팬 시간을 모두 더한 값도 전체 응답 시간과 같지 않습니다.
5. 토큰을 세는 이유는 청구서 설명을 넘어서야 한다
토큰은 모델이 입력과 출력을 처리할 때 사용하는 단위입니다. 한글 한 글자나 단어 하나와 항상 일치하지 않습니다. LLM API 비용을 이해하려면 사용한 모델, 입력·출력 사용량, 캐시 적용 여부와 실제 청구 규칙을 연결해야 합니다.
하지만 운영자가 알고 싶은 질문은 “오늘 토큰을 몇 개 썼는가”에서 더 나아갑니다. 같은 수의 요청인데 비용이 늘었다면 긴 문서가 더 많이 들어갔는지, 대화 이력이 누적됐는지, 비싼 모델로 전환됐는지, 도구 호출 뒤 모델을 다시 호출했는지 구분해야 합니다.
요청별 추정 비용은 청구되는 사용량을 겹치지 않는 항목으로 나누어 계산하는 방식이 기본입니다.
요청의 추정 비용
= 모든 모델 호출의 청구 항목별 사용량 × 해당 단가의 합
+ 검색·도구 등 추가 사용 비용
캐시 토큰이 전체 입력 토큰에 포함되는 공급자에서는 둘을 그대로 더하면 중복 계산됩니다. 추론용 토큰도 공급자의 출력 사용량에 포함되는지 확인해야 합니다. 단가의 적용 날짜와 모델 식별자를 남기고, 추정액은 실제 청구 내역과 대조해야 합니다. 재시도 중 연결이 끊겨 사용량을 받지 못했다면 이를 0원으로 처리하기보다 사용량 미확인으로 구분하는 편이 정확합니다.
싼 요청이 싼 업무를 만들지는 않는다
같은 1,000개 질문과 같은 성공 기준으로 두 구성을 평가했다고 가정해 보겠습니다. 다음 비용은 특정 모델의 실제 요금이 아닌 계산 예시입니다.
구성 B는 전체 지출이 30% 낮지만 성공한 결과 하나를 얻는 비용은 더 높습니다. 이 지표의 분자는 실패한 요청에 쓴 돈도 포함한 전체 비용이고, 분모는 같은 대상에서 성공한 건수입니다. 여러 대화 턴이 필요한 업무라면 질문 한 건 대신 업무 한 건을 기준으로 묶어야 합니다.
따라서 비용을 줄이는 변경은 품질과 함께 평가해야 합니다. 검색 문서를 줄여 토큰을 아꼈는데 필요한 예외 조항을 놓쳤다면 절감액만으로 배포를 판단하기 어렵습니다. 사용자 유형이나 질문 난도가 달라진 트래픽을 비교하면서 모델 변경의 효과라고 단정해서도 안 됩니다.
6. 답변 품질도 어디에서 실패했는지 나눠 측정한다
“답변 품질 점수 0.7”이라는 숫자만 보면 고칠 위치가 모호합니다. 무엇과 무엇을 비교해 얻은 점수인지 알아야 합니다. RAG에서는 적어도 검색 결과, 답변의 근거, 최종 정답성을 나눠 볼 수 있습니다.
이 구분은 LangSmith의 공식 RAG 평가 문서에서도 확인할 수 있습니다. 도구가 달라도 비교 대상부터 정하는 원칙은 같습니다. LangSmith: RAG 애플리케이션 평가
첫 사례의 오래된 출장비 문서를 떠올려 보겠습니다. 답변이 그 문서에 충실하다면 근거 충실성 평가는 높을 수 있습니다. 그러나 현행 규정과 비교한 정답성 평가는 낮아야 합니다. 근거가 있다는 사실이 그 근거의 최신성이나 정확성까지 보장하지는 않습니다.
검색 결과가 좋았더라도 최종 프롬프트에 넣는 과정에서 문서가 잘릴 수 있습니다. 그래서 검색한 문서와 실제 모델에 전달한 문서 조각을 구분하면 검색기 문제와 입력 조립 문제를 나눌 수 있습니다. 문서 ID뿐 아니라 개정 번호나 인덱스 버전도 함께 기록할 이유입니다.
자동 평가에도 검증이 필요하다
출력 스키마나 필수 필드, 도구 인자 형식처럼 규칙이 명확한 부분은 코드로 검사할 수 있습니다. 내용의 타당성처럼 단순한 규칙으로 판단하기 어려운 부분에는 사람 검토나 LLM을 평가자로 쓰는 방식이 도움이 됩니다.
다만 LLM 평가자의 점수도 측정 도구의 출력입니다. 답변 순서나 길이에 따른 편향이 연구되어 있으며, 평가 프롬프트와 모델이 바뀌면 점수의 기준도 달라질 수 있습니다. 사람에게 검토받은 사례와의 일치도를 확인하고, 평가 모델·기준·버전을 함께 관리해야 합니다. MT-Bench의 LLM 평가자 연구, 평가자를 사람의 피드백에 맞추는 방법
운영에서는 전체 트래픽을 평가했는지 표본만 평가했는지도 중요합니다. 어려운 질문만 골라 검사한 점수를 전체 서비스의 정답률로 표시하면 안 됩니다. 평가 대상 수, 선택 방식, 평가 실패와 미평가 건수를 같이 보여 줘야 숫자의 의미가 유지됩니다.
사용자의 싫어요나 상담원 전환도 유용한 신호지만 정답률과 동일하지는 않습니다. 틀린 답변을 받아도 피드백하지 않는 사람이 있고, 정확한 답변이 기대와 달라 불만을 표시할 수도 있습니다. 여러 신호를 교차해 조사 대상을 찾는 편이 낫습니다.
7. 버전을 남겨야 변화의 원인을 좁힐 수 있다
LLM 시스템에서 배포되는 것은 애플리케이션 코드만이 아닙니다. 프롬프트, 모델 선택 규칙, 검색 인덱스, 문서 조각을 나누는 방식, 도구의 입력 스키마, 정책과 평가 기준도 결과를 바꿉니다.
예를 들어 금요일부터 특정 질문의 실패가 늘었다고 해 보겠습니다. 같은 시간에 모델과 프롬프트를 모두 바꾸고 검색 인덱스도 갱신했다면, 날짜별 평균만으로 원인을 구분하기 어렵습니다. 각 요청에 당시 적용된 버전을 남기면 실패가 어떤 조합에 몰리는지 볼 수 있습니다.
아래는 저장할 맥락을 설명하기 위한 개념적 JSON 예시입니다. OTLP 전송 형식이나 바로 실행하는 SDK 코드는 아닙니다. app.*는 이 글에서 정한 애플리케이션 속성이고, 모델·버전·ID 값은 모두 가상입니다.
{
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"service.name": "policy-assistant",
"service.version": "2026.09.15-2",
"gen_ai.operation.name": "chat",
"gen_ai.request.model": "policy-model-alias",
"gen_ai.response.model": "policy-model-2026-09",
"gen_ai.prompt.name": "policy-answer",
"gen_ai.prompt.version": "v18",
"app.retrieval.index_version": "index-42",
"app.retrieval.selected_refs": ["policy-17@rev-8"],
"app.policy.version": "policy-rules-6",
"app.model.attempt_count": 2,
"app.outcome": "answered",
"app.content_capture": false
}
OpenTelemetry의 GenAI 규약은 요청 모델과 응답 모델, 프롬프트 이름과 버전 등 여러 맥락을 정의합니다. 다만 2026년 9월 15일 확인 기준 관련 스팬·메트릭 문서는 Development 상태입니다. 실제 도입 시 계측 라이브러리와 규약 버전을 고정하고, SDK가 어떤 필드를 제공하는지 확인해야 합니다. 모델의 실제 버전을 공급자가 알려 주지 않는 경우에도 임의로 추정해 채워 넣지 않습니다. OpenTelemetry GenAI 스팬 규약
관측된 연관성만으로 인과관계가 확정되는 것은 아닙니다. 새로운 버전에서 실패가 많더라도 그 버전에 어려운 요청이 더 많이 배정됐을 수 있습니다. 같은 평가셋의 전후 비교나 조건을 맞춘 실험으로 확인해야 합니다. 당시 문서와 도구 응답이 보존되지 않았다면 똑같은 상황을 재현하는 데 한계가 있다는 점도 기록해야 합니다.
8. 운영에서 발견한 실패를 다음 배포의 시험 문제로 만든다
운영 데이터만 보고 수정하거나, 고정된 평가셋만 보고 배포하면 각각 놓치는 부분이 있습니다. 운영 트래픽에는 개발 중 예상하지 못한 질문이 들어오고, 평가셋은 같은 조건에서 변경 전후를 비교할 수 있게 해 줍니다.
오프라인 평가는 준비한 사례로 변경을 검증하는 과정입니다. 온라인 평가는 운영 중의 실제 요청과 결과를 분석하는 과정입니다. 온라인 평가가 반드시 사용자의 응답 경로를 막고 즉시 실행되어야 하는 것은 아닙니다. 비동기로 평가하고 결과를 원래 요청에 연결할 수 있습니다. LangSmith: 평가 흐름
공식 문서를 바탕으로 재구성한 관측과 평가의 연결 구조입니다. 근거: LangSmith 평가 흐름, 평가 개념. 운영 사례의 재사용에는 데이터 최소화와 별도 검토가 필요합니다.
출장비 사례라면 실패한 답변과 연결된 트레이스에서 문서 개정 정보를 확인합니다. 사람이 현행 규정과 기대 답변을 검토하고, 민감한 정보를 제거해 회귀 평가셋에 추가합니다. 문서 선택 로직을 고친 뒤 이 질문뿐 아니라 기존의 정상 사례도 다시 검사합니다.
특정 실패 한 건만 고치면서 다른 질문의 품질을 떨어뜨릴 수 있기 때문입니다. 평가셋에는 흔한 질문, 예외 조건이 많은 질문, 근거가 부족해 답변을 보류해야 하는 질문을 함께 포함하는 편이 좋습니다. 정답이나 정책이 바뀌면 평가셋 역시 버전을 올려야 합니다.
이 과정에서 옵저버빌리티는 장애 조사 자료를 다음 품질 개선의 입력으로 바꿉니다. 운영 트레이스와 평가 사례 사이에 연결이 있으면 “이 시험 문제는 어떤 실제 실패 때문에 추가했는가”도 설명할 수 있습니다.
9. 관측 데이터를 모으는 순간 새로운 데이터 경계가 생긴다
LLM의 프롬프트와 응답에는 질문뿐 아니라 내부 문서, 계약 내용, 코드와 개인정보가 포함될 수 있습니다. 이를 모두 로그 플랫폼으로 보내면 원래 애플리케이션과 다른 권한 체계를 가진 저장소에 민감한 데이터 사본이 생깁니다.
따라서 옵저버빌리티는 수집 범위와 접근 통제를 함께 설계해야 합니다. 기본적으로는 지연, 상태, 사용량, 버전과 허용된 식별자를 수집하고, 원문이 필요한 조사에 대해 별도의 제한된 경로를 두는 방식이 현실적입니다. OpenTelemetry의 GenAI 규약도 입력·출력 내용 수집을 명시적 선택 사항으로 다룹니다.
공식 문서를 바탕으로 재구성한 예시 설계입니다. 원문은 애플리케이션에서 기본 수집하지 않고, 필요한 경우 별도 정책을 적용합니다. 근거: 민감한 데이터 처리, Collector 구조.
내용을 수집해야 한다면 목적, 항목, 보존 기간과 접근 권한부터 정합니다. 인증 헤더와 비밀키는 수집 대상에서 제외하고, 원문에 대한 마스킹은 가능하면 데이터가 프로세스 밖으로 나가기 전에 적용합니다. Collector에서 추가 필터링을 해도 그 앞의 SDK 버퍼나 디버그 로그에 원문이 남는 문제까지 자동으로 없어지지는 않습니다. OpenTelemetry: 민감한 데이터 처리
사용자 ID를 해시로 바꿨다고 모든 데이터가 익명화되는 것도 아닙니다. 같은 사람의 기록을 계속 연결할 수 있거나 다른 속성과 결합해 식별할 수 있다면 여전히 접근과 보존 정책이 필요합니다. 원문 저장소의 참조 ID를 기록할 때도 접근용 토큰이나 서명된 다운로드 URL을 함께 로그에 남기지 않도록 설계합니다.
보안 관측과 권한 검사는 역할이 다르다
도구 호출이 가능한 시스템이라면 호출한 도구, 허용·거부 결과, 적용한 정책 버전, 재시도와 승인 결과를 관측할 수 있습니다. 이런 기록은 이상한 행동의 조사와 정책 개선에 도움이 됩니다.
그러나 호출을 기록했다고 허용되지 않은 작업이 예방되는 것은 아닙니다. 접근 제어는 도구를 실행하는 서버가 검사해야 하고, 관측 데이터는 그 판단과 실행 결과를 설명해야 합니다. 차단 횟수가 늘었다고 공격이 늘었다고 바로 결론 내리는 것도 이릅니다. 정책 변경으로 정상 요청이 더 많이 차단된 것일 수 있습니다.
10. 데이터를 많이 수집할수록 잘 보이는 것은 아니다
관측 데이터를 저장하고 검색하는 데에도 비용이 듭니다. 입력과 출력이 긴 LLM 서비스는 본문을 무제한 기록하거나 모든 토큰마다 이벤트를 남기면 수집량이 크게 늘어날 수 있습니다. 결국 필요한 증거를 얼마나 안정적으로 남길지가 설계의 핵심입니다.
첫 번째는 메트릭의 카디널리티, 즉 구분되는 값 조합의 수입니다. 사용자 ID, 요청 ID, 질문 원문을 메트릭 라벨에 넣으면 요청마다 새로운 시계열이 만들어질 수 있습니다. 서비스, 작업 유형, 제한된 모델 분류처럼 범위가 관리되는 라벨을 사용하고, 개별 요청 식별자는 트레이스나 접근이 통제된 기록에서 찾는 편이 적합합니다. Prometheus: 메트릭과 라벨 이름
두 번째는 샘플링, 즉 일부 요청을 선택해 보관하는 정책입니다. 요청 시작에 결정하는 방식은 비용을 일찍 줄일 수 있지만 그 요청이 나중에 실패할지는 모릅니다. 요청의 결과를 보고 선택하는 방식은 느린 요청이나 오류를 남기기 쉽지만, 선택 전 데이터를 모아 둘 자원과 시간이 필요합니다. OpenTelemetry: 샘플링
여기에는 자주 놓치는 조건이 있습니다. 앞단에서 이미 버린 트레이스를 뒤의 수집기가 복구할 수는 없습니다. 몇 분 뒤 비동기 품질 평가에서 실패로 판정됐더라도 트레이스가 이미 삭제됐다면 관련 실행 기록을 볼 수 없습니다. 평가 지연과 보존 기간을 함께 설계하거나, 적절한 기간 동안 최소 메타데이터를 유지해야 합니다.
오류 요청을 의도적으로 많이 남긴 표본에서 계산한 오류율도 전체 서비스의 오류율은 아닙니다. 운영 지표를 어떤 수집 경로와 모집단에서 계산하는지 명시하고, 진단용 트레이스 표본과 전체 요청 집계를 구분해야 합니다.
세 번째는 수집기 자체의 상태입니다. Exporter 전송 실패, 대기열 증가, 수집 거절이나 드롭을 감시하지 않으면 “문제가 없어서 데이터가 없는지, 관측 시스템이 고장 나서 없는지” 알기 어렵습니다. Collector의 내부 텔레메트리는 이런 상태를 확인하는 데 사용합니다. OpenTelemetry Collector 내부 텔레메트리
11. 대시보드는 담당자의 다음 행동을 정할 수 있어야 한다
CPU와 메모리, 모델 지연과 품질 점수를 한 화면에 모았다고 운영 체계가 완성되지는 않습니다. 지표가 나빠졌을 때 누가 무엇을 확인하고 어떤 조치를 할지까지 연결되어야 합니다.
구글 SRE의 지연, 트래픽, 오류, 포화도는 여전히 좋은 출발점입니다. 외부 모델 API를 사용하는 경우에는 애플리케이션 대기열, 동시 요청, 공급자의 제한 응답 등이 자원 부족을 이해하는 단서가 됩니다. 자체 모델을 운영한다면 추론 서버의 대기열과 GPU 메모리 등도 관측 범위에 들어갑니다.
그 위에 LLM 업무의 성공 기준과 비용을 추가합니다. 아래는 도입할 때 작성할 수 있는 운영 질문의 예입니다.
서비스 수준 목표인 SLO(Service Level Objective)도 이 구분 위에서 정해야 합니다. 대화형 안내에는 첫 내용이 보이는 시간과 정상 완료 비율이 중요할 수 있고, 비동기 보고서 생성에는 정해진 시간 안에 기준을 충족한 결과가 나오는 비율이 더 적절할 수 있습니다.
품질 목표에는 평가 대상과 방법이 따라야 합니다. “전체 요청의 정답률 95%”라고 쓰면서 실제로는 하루 20건의 편의 표본만 검사했다면 목표와 측정이 어긋납니다. 표본 기반 추정인지, 모든 요청에서 확인 가능한 업무 결과인지 구분하고 표본 수와 불확실성을 함께 봐야 합니다.
알림에서 원인 검증까지 한 번 연결해 보기
정책 안내의 낮은 평가가 늘었다는 신호를 받았다고 가정해 보겠습니다. 담당자는 먼저 평가 대상 수와 평가자 버전이 바뀌었는지 확인합니다. 그다음 실패 요청을 프롬프트·모델·인덱스 버전별로 나눠 보고, 문제가 모인 요청의 트레이스에서 실제 선택 문서의 개정 정보를 확인합니다.
새 검색 인덱스에 구버전 문서가 함께 들어간 것이 원인 후보라면 이를 검증합니다. 문서 선택 조건을 수정한 뒤 기존 평가셋과 새 실패 사례를 함께 실행하고, 제한된 배포에서 품질과 지연·비용이 개선되는지 확인합니다. 기록이 연결되어 있어야 이 조사가 추측의 반복에서 벗어납니다.
12. 현실적인 시작은 중요한 요청 하나를 끝까지 보는 것이다
처음부터 모든 모델과 모든 도구를 계측하려 하면 데이터 양과 운영 규칙을 정하는 일부터 커집니다. 먼저 자주 쓰이면서 실패했을 때 영향이 큰 업무 하나를 골라, 다음 질문에 실제로 답할 수 있는지 확인하는 방식이 좋습니다.
첫째, 성공의 뜻을 정합니다. 어떤 응답을 성공으로 세고, 어떤 거절을 정상으로 보며, 무엇을 사람이 검토해야 하는지 합의합니다. 이 정의가 없으면 품질 점수와 알림을 해석할 기준도 없습니다.
둘째, 실행 경로를 연결합니다. 요청 진입, 검색, 모델 호출과 주요 도구 실행을 하나의 문맥으로 묶고 지연·상태·사용량·버전을 남깁니다. 프레임워크가 자동으로 남기는 범위와 직접 계측해야 하는 업무 단계를 확인합니다.
셋째, 품질 평가를 붙입니다. 사람이 검토한 정상·실패 사례로 평가 기준을 만들고, 운영 중 발견한 문제를 같은 요청의 트레이스에서 조사할 수 있게 합니다. 평가 점수뿐 아니라 평가 실패와 누락도 기록합니다.
넷째, 실제로 기록이 연결되는지 시험합니다. 테스트 환경에서 모델 시간 초과, 검색 결과 없음, 도구 실패, 사용자 취소, 스트리밍 중단을 각각 확인합니다. 재시도가 한 번의 성공 뒤에 숨지 않는지, 중간에 끊긴 요청의 지연과 상태가 남는지 검증합니다.
다섯째, 수집과 조회의 경계를 확인합니다. 준비한 비밀값과 개인정보용 가상 표식이 텔레메트리로 나가지 않는지, 권한 없는 운영자가 원문을 조회할 수 없는지 점검합니다. 정상 표본과 실패 표본이 의도한 정책대로 남는지도 확인합니다.
OpenTelemetry는 이런 계측과 전송을 공통 방식으로 연결할 수 있는 기반입니다. 수집된 신호를 저장하고 탐색하는 백엔드, LLM 평가와 프롬프트 분석 도구는 운영 조건에 맞게 조합할 수 있습니다. 선택한 도구 이름보다 중요한 것은 품질이 나쁜 응답 하나를 골랐을 때 그 요청의 실행·버전·비용까지 따라갈 수 있는가입니다.
마무리: 좋은 답변을 지속해서 제공하려면 과정을 설명할 수 있어야 한다
LLM 옵저버빌리티가 필요한 이유는 실패의 형태가 다양하기 때문입니다. 서비스는 응답했지만 정보가 틀릴 수 있고, 답변은 맞았지만 불필요한 재시도로 느리고 비싸질 수 있습니다. 같은 코드라도 문서와 프롬프트, 도구와 모델 구성이 달라지면 결과가 바뀔 수 있습니다.
실행 기록을 연결하면 문제의 위치를 좁힐 수 있습니다. 품질 평가를 연결하면 응답 성공과 업무 성공의 차이를 확인할 수 있습니다. 비용과 버전을 함께 보면 변경이 실제로 개선인지 검증할 수 있습니다. 그리고 수집 데이터의 접근과 보존을 설계해야 그 관측 체계도 신뢰할 수 있습니다.
첫걸음은 중요한 사용자 요청 하나를 선택해 어떤 조건에서, 어떤 과정을 거쳐, 얼마의 시간과 비용으로, 어떤 결과를 만들었는지 설명할 수 있게 만드는 일입니다. 그 연결이 갖춰지면 운영에서 발견한 실패가 다음 배포의 품질을 높이는 근거가 됩니다.
참고한 공식 문서와 연구
'일반IT > AI' 카테고리의 다른 글
| Claude vs ChatGPT, 하나만 구독한다면? 코딩·사용량·비용 비교 (0) | 2026.09.15 |
|---|---|
| GPT-6 Astra 출시: ChatGPT·Codex·API에서 무엇이 달라지나 (1) | 2026.09.07 |
| 알려진 공격 검증하기: Promptfoo 회귀 테스트 (0) | 2026.09.04 |
| 발견을 방어로 바꾸기: Testcase와 정책 승격 (0) | 2026.09.03 |
| 새로운 공격 찾아내기: Garak과 PyRIT (0) | 2026.09.03 |
