LLM 관측성(LLM Observability)은 AI 모델을 품은 애플리케이션이 실제로 어떻게 동작하는지를 추적·측정·진단하는 기술과 실천을 말한다. 어떤 프롬프트가 들어갔고, 모델이 무엇을 답했으며, 어떤 도구를 어떤 순서로 호출했고, 비용과 지연은 얼마였는지를 눈으로 볼 수 있게 만드는 일이다.
전통적인 서버는 "요청이 들어오면 정해진 코드가 정해진 답을 낸다". 그래서 로그와 지표만 봐도 대체로 원인을 짚을 수 있었다. 그런데 LLM 앱은 다르다. 같은 입력에도 매번 조금씩 다른 답이 나오고, 실패가 500 에러가 아니라 "그럴듯하지만 틀린 답"으로 조용히 지나간다. 나는 이 지점에서 기존 모니터링이 무력해지는 걸 여러 번 봤다. 화면상 아무 문제가 없는데 사용자만 이상하다고 하는 상황 말이다.
LLM 앱의 장애는 터지지 않고 새어 나온다.
에러 코드 없이 품질만 서서히 나빠지기 때문에, "무엇이 왜 그렇게 나왔는지"를 재구성하는 추적(trace)이 관측성의 심장이 된다.
트레이스추적 호출 흐름 전체 재현 |
평가evals 품질을 점수로 측정 |
비용토큰 지연·요금 실시간 파악 |
피드백루프 실사용을 개선에 반영 |
왜 기존 모니터링으로는 부족한가
기존 APM은 "느린 요청"이나 "에러율 상승"을 잘 잡는다. 하지만 LLM 앱의 진짜 문제는 대개 200 OK와 함께 온다. 응답 시간도 정상, 상태 코드도 정상인데 답의 내용이 틀렸거나 무례하거나 엉뚱한 도구를 불렀다. 이건 인프라 지표로는 절대 안 잡힌다. 내용 자체를 봐야 하기 때문이다.
에이전트가 문제를 키운다
단발성 질문·응답이라면 그나마 낫다. 요즘 앱은 에이전트가 여러 단계를 거친다. 검색을 하고, 도구를 부르고, 그 결과로 다시 판단하고, 또 다른 도구를 부른다. 이 중 세 번째 단계에서 잘못된 검색 결과를 받아 전체 결론이 어긋났다면, 최종 답만 봐서는 원인을 절대 알 수 없다. 그래서 각 단계를 하나의 사슬로 이어 붙여 통째로 들여다보는 트레이스가 필수다.
관측성을 이루는 축
- 트레이싱 — 하나의 사용자 요청이 프롬프트, 모델 호출, 도구 실행, 재시도를 거치며 어떻게 흘렀는지 시간순으로 재구성한다. 디버깅의 출발점이다.
- 평가(evals) — 정답이 딱 떨어지지 않는 출력의 품질을 점수화한다. 규칙 기반 검사, 다른 모델로 채점하기, 사람 검수를 섞어 쓴다.
- 비용·지연 계측 — 토큰 사용량, 응답 시간, 요청당 요금을 추적한다. LLM 비용은 방심하면 순식간에 불어나므로 실시간 가시성이 중요하다.
- 사용자 피드백 — 좋아요·싫어요, 재질문, 이탈 같은 실제 신호를 모아 품질 판단의 근거로 삼는다.
전통 관측성과 LLM 관측성
| 항목 | LLM 관측성 | 전통 관측성 |
|---|---|---|
| 주 관심 | 출력 내용·품질 | 지연·에러율 |
| 실패 형태 | 조용한 오답 | 명시적 에러 |
| 판정 | 평가로 채점 | 임계값 알람 |
| 재현성 | 비결정적 | 대체로 결정적 |
어디서부터 시작할까
거창하게 시작할 필요는 없다. 내가 권하는 순서는 이렇다. 우선 모든 모델 호출에 트레이스를 붙여 무슨 프롬프트가 오가는지 눈으로 보는 것부터 한다. 이것만 해도 "왜 이런 답이 나왔지"의 절반이 풀린다. 그다음 실제 사용 로그에서 실패 사례를 모아 작은 평가 세트를 만든다. 완벽한 벤치마크가 아니라, "우리 서비스에서 이건 꼭 맞아야 한다"는 예시 모음이면 충분하다.
표준화 측면에서 반가운 흐름도 있다. 분산 추적의 사실상 표준인 오픈텔레메트리(OpenTelemetry) 계열에 생성형 AI 호출을 담는 관례가 자리를 잡아 가고 있어서, 특정 벤더에 묶이지 않고 트레이스를 남기기가 점점 쉬워지고 있다. 관측성을 나중이 아니라 처음부터 설계에 넣는 팀이, 결국 AI 기능을 자신 있게 배포하는 팀이 된다.
개발 흐름을 바꾼다
관측성을 제대로 갖추면 LLM 앱을 개발하는 방식 자체가 바뀐다. 예전에는 프롬프트를 조금 고치고 "느낌상 나아진 것 같다"며 배포하는 일이 흔했다. 근거가 감이었다는 뜻이다. 트레이스와 평가 세트가 있으면 이야기가 달라진다. 프롬프트나 모델을 바꿨을 때 실제 사용 사례에서 품질이 올랐는지 내렸는지를 숫자로 비교할 수 있다. 감이 아니라 증거로 결정하게 되는 것이다.
특히 실사용 로그에서 문제가 된 사례를 모아 두면, 그것이 곧 회귀 테스트가 된다. 다음에 무언가를 바꿀 때 "예전에 틀렸던 이 사례들이 여전히 맞나"를 자동으로 확인할 수 있다. 나는 이 되먹임 고리가 있느냐 없느냐가, AI 기능을 계속 개선하는 팀과 한 번 만들고 방치하는 팀을 가른다고 본다. 관측성은 사후 대응 도구가 아니라 개선의 엔진에 가깝다.
자주 묻는 질문
LLM 관측성은 기존 APM 도구로는 안 되나요?
지연과 에러율 같은 인프라 지표는 기존 APM으로도 됩니다. 하지만 LLM 앱의 실패는 대부분 정상 응답 코드와 함께 오는 '조용한 오답'이라, 출력 내용과 프롬프트·도구 호출 흐름을 들여다보는 별도의 관측성이 필요합니다.
평가(evals)는 꼭 필요한가요?
정답이 하나로 떨어지지 않는 출력을 다룰수록 필수에 가깝습니다. 규칙 기반 검사, 다른 모델을 이용한 채점, 사람 검수를 조합해 품질을 수치로 만들어야 개선 여부를 객관적으로 판단할 수 있습니다.
에이전트 앱에서 관측성이 특히 중요한 이유는?
에이전트는 검색·도구 호출·재판단을 여러 단계 거치기 때문에, 최종 답만 봐서는 어느 단계에서 어긋났는지 알 수 없습니다. 단계 전체를 하나의 트레이스로 이어 봐야 원인을 짚을 수 있습니다.
관측성을 도입하면 비용도 관리되나요?
네. 토큰 사용량과 요청당 요금, 지연을 실시간으로 계측하면 어떤 기능이 비용을 잡아먹는지 드러납니다. LLM 비용은 방심하면 빠르게 불어나므로, 관측성은 품질뿐 아니라 비용 통제에도 직접 기여합니다.
댓글 0