콘텐츠로 이동
1337skills 1337skills - 치트시트

2026년 LLM 관찰성: 추적, 평가, 그리고 OpenTelemetry 전환

· 13 min read · default
aillmobservabilityevaluationopentelemetryagents

팀이 LLM 애플리케이션을 데모에서 프로덕션으로 옮길 때 맨 처음 발견하는 것은 그들이 맹목적으로 비행하고 있다는 것입니다. 모델은 답변을 반환하고, 그 답변은 때때로 잘못되며, 왜 그런지 알 방법이 명확하지 않습니다. 검색이 나빴나요? 도구 호출이 무음으로 실패하고 에이전트가 즉흥적으로 대응했나요? 프롬프트가 3주 전에 변경되어 조용히 품질을 저하시켰나요? 기존 웹 서비스를 사용할 때는 로그, 메트릭, 추적에 도달하여 몇 분 안에 답을 찾을 수 있습니다. 2023년 LLM 애플리케이션을 사용할 때 대부분의 팀은 print 문과 감정을 가지고 있었습니다. 2026년까지 그 격차는 닫혔고, 그것을 닫은 규율은 LLM 관찰성입니다: 언어 모델 애플리케이션을 계측하고, 추적하고, 평가하여 그들의 행동이 보이고, 디버그 가능하며, 측정 가능하게 개선되도록 하는 실행입니다.

이 가이드는 2026년 LLM 관찰성이 실제로 무엇을 의미하는지, 왜 일반적인 애플리케이션 모니터링보다 더 어려운지, 그리고 스택이 어떻게 조합되는지를 다룹니다. 일관성 있는 스레드는 표준입니다 — OpenTelemetry — 이는 독점 SDK의 단편화된 필드를 상호 운용 가능한 것으로 바꾸었으며, 접근 방식을 exemplify하는 세 가지 도구입니다: Arize Phoenix, Langfuse, 그리고 MLflow. 목표는 당신이 무엇을 계측할지, 무엇을 측정할지, 그리고 당신을 잠그지 않을 도구를 어떻게 선택할지에 대해 추론할 수 있도록 남겨두는 것입니다.

LLM 앱이 관찰하기 어려운 이유

기존 관찰성은 세 기둥 위에 있습니다: 로그 (일어난 일), 메트릭 (얼마나, 얼마나 빠르게), 추적 (요청이 시스템을 통과한 경로). LLM 애플리케이션은 세 가지 모두가 필요하지만, 순진한 모니터링을 거의 쓸모없게 만드는 방식으로 일반적인 가정을 깹니다.

첫 번째 문제는 비결정성입니다. 같은 입력이 다른 출력을 생성할 수 있으므로 "한 번 잘못된 것을 반환했습니다"는 당신이 디버거 아래에서 재실행할 수 있는 재현 가능한 버그가 아닙니다. 실제로 잘못된 특정 호출에서 정확히 무엇이 일어났는지 캡처해야 합니다 — 정확한 프롬프트, 정확한 컨텍스트, 정확한 응답 — 왜냐하면 당신이 이를 다시 재현할 수도 없기 때문입니다. 두 번째 문제는 품질의 불투명성입니다. 웹 요청은 성공하거나 오류 코드를 반환합니다; LLM 호출은 텍스트를 반환하는 의미에서 거의 항상 "성공"하는 반면 텍스트는 미묘하게 또는 재앙적으로 잘못될 수 있습니다. 상태 코드는 아무것도 알려주지 않습니다. 품질은 별도로 평가해야 하는 의미론적 속성입니다. 세 번째 문제는 깊이입니다. 현대적 에이전트는 하나의 모델 호출이 아닙니다; 그것은 트리입니다 — 모델이 도구를 호출하기로 결정하고, 도구가 데이터를 반환하고, 모델이 컨텍스트를 검색하고, 중간 결과에 대해 추론하고, 아마도 다른 에이전트로 전달하며, 그 후에만 답변합니다. 최종 답변이 잘못되면, 원인은 그 트리의 모든 노드에 있을 수 있으며, "모델을 호출했고, 응답을 받았습니다"는 flat log는 정확히 당신이 디버깅하는 데 필요한 구조를 숨깁니다.

이 세 가지 속성 — 비결정성, 불투명한 품질, 깊은 호출 트리 — 는 왜 LLM 관찰성이 기존 APM에 대한 치장이 아닌 자체 규율인지를 설명합니다. 중요한 도구는 그들 주변에 구축됩니다.

추적: 호출 트리를 보이게 만들기

기초는 LLM 애플리케이션에 적응된 분산 추적입니다. 추적은 하나의 end-to-end 요청을 span의 트리로 캡처하며, 각 span은 하나의 작업입니다: LLM 호출, 도구 호출, 검색 단계, 가드레일 확인. 각 span에 대해 입력, 출력, 타이밍, 토큰 수, 비용, 그리고 모든 오류를 기록합니다. 결과는 답변이 잘못되었을 때 추적을 열고 트리를 따라갈 수 있다는 것입니다 — 검색이 관련 없는 문서를 반환했거나, 도구 호출이 시간 초과되고 에이전트가 추측했거나, 시스템 프롬프트가 기대한 것이 아님을 확인합니다.

이것은 위의 깊이 문제 때문에 정확히 변환합니다. 추적 없이 에이전트는 나쁜 답변을 내보낸 블랙 박스입니다. 추적을 사용하면 그것은 검사 가능한 단계의 시퀀스이며, 디버깅은 트리를 읽는 문제가 되며 추측이 아닙니다. 가장 풍부한 추적 도구는 또한 다중 차례 대화를 재구성하므로 세션에 걸쳐 컨텍스트가 어떻게 축적되었는지 볼 수 있으며, span당 토큰 사용 및 비용을 표시하여 영원한 "우리의 OpenAI 청구서가 왜 그렇게 높은가"라는 질문을 추측이 아닌 쿼리로 바꿉니다.

실질적인 조언은 평가 작업 전에 먼저 추적을 계측하는 것입니다. 왜냐하면 추적은 다른 모든 것을 가능하게 하기 때문입니다. 캡처하지 않은 호출을 평가할 수 없으며, 볼 수 없는 시스템을 디버깅할 수 없습니다. 아래에 논의된 모든 도구는 이러한 이유로 추적으로 시작합니다.

OpenTelemetry 전환

2024년과 2026년 사이 LLM 관찰성의 가장 중요한 구조적 변화는 OpenTelemetry (OTel)로의 수렴입니다. 초기 관찰성 도구는 각각 자신의 SDK를 배포했습니다: 당신은 벤더 X의 라이브러리에 대해 코드를 계측했고, 당신의 추적은 벤더 X의 플랫폼에 잠겼습니다. 도구를 전환하는 것은 모든 것을 다시 계측하는 것을 의미했습니다. OpenTelemetry — 이미 기존 인프라에서 이긴 동일한 벤더 중립 관찰성 표준 — 이를 변경했습니다. 당신의 애플리케이션은 표준 OTLP 형식으로 추적을 내보내고, OTel 호환 백엔드는 그들을 수신할 수 있습니다.

LLM 애플리케이션의 경우, OTel 위에 계층화된 의미론적 규칙은 전송만큼 중요합니다. OpenInference 같은 규칙은 어떻게 LLM span을 표현할지 정의합니다 — 프롬프트가 어디로 가는지, 검색된 문서를 기록하는 방법, 도구 호출을 표시하는 방법 — 추적이 표준 형식으로 전송되지 않기만 하고 의미 있게 해석 가능하도록 합니다. Arize Phoenix는 이를 기반으로 구축됩니다: 표준 OTLP를 통해 추적을 수용하고 OpenInference 규칙을 사용하므로 추가하는 계측이 Phoenix 특화이 아닙니다. 나중에 동일한 추적을 다른 곳으로 보내고 싶으면 할 수 있습니다. Langfuse와 MLflow는 마찬가지로 OTel 호환성을 수용했습니다.

2026년에 도구를 선택하는 사람에게 전략적 의미는 OpenTelemetry 기반 계측을 선호하는 것입니다. 표준에 투자하는 것과 벤더에 투자하는 것의 차이입니다. OTel에 대해 한 번 계측하면 당신의 관찰성 데이터는 이식 가능합니다; proprietary SDK에 대해 계측하면 switching cost를 구입했습니다. 이것은 이 공간에서 가장 중요한 단일 아키텍처 결정이며, OTLP를 고집하기만 해서 제대로 할 수 있습니다.

평가: 당신이 눈으로 볼 수 없는 품질 측정

추적은 일어난 일을 보여줍니다; 평가는 일어난 일이 좋았는지 여부를 알려줍니다. LLM 출력 품질이 의미론적이므로 상태 코드로 주장할 수 없으며, 프로덕션 볼륨의 모든 응답을 수동으로 읽을 수 없습니다. 2026년 대답은 중심에 LLM-as-judge를 가진 기술의 조합입니다.

LLM-as-judge는 rubric에 대해 출력을 채점하기 위해 유능한 모델을 사용합니다: 이 답변이 검색된 컨텍스트에 충실한가 (즉, hallucinated이 아닌), 질문과 관련이 있는가, reference 대비 올바른가, 유독하거나 안전하지 않은가? DeepEval같은 도구는 이 작업에 대한 많은 연구 기반 메트릭을 가져왔으며, 관찰성 플랫폼은 점차 추적 데이터에 직접 평가를 접어넣습니다. 따라서 span은 입력 및 출력과 함께 "hallucination: detected" 라벨을 가질 수 있습니다. 이 통합의 강력함은 당신이 프로덕션 트래픽을 정확히 나쁜 점수를 받은 호출로 필터링할 수 있다는 것입니다. 그들의 추적을 열고, 원인을 확인하세요 — "품질이 떨어졌습니다"에서 "여기가 구체적인 깨진 검색입니다"로 루프를 닫습니다.

평가는 다른 목적을 제공하는 두 가지 모드에서 실행됩니다. 오프라인 평가는 배포하기 전에 선별된 데이터세트를 통해 실행합니다: 당신은 대표 입력 (종종 실제 추적에서 수집)을 조립하고, 당신의 파이프라인을 실행하고, 결과를 채점하고, 이전 버전과 비교합니다. 이것이 당신의 regression gate입니다 — 프롬프트 또는 모델 변경이 도움이 되었는지 해쳤는지 사용자가 느끼기 전에 알려줍니다. 온라인 평가는 라이브 프로덕션 트래픽에 대해 실행되어 실제 호출을 샘플링하고 지속적으로 채점하므로 당신의 오프라인 데이터세트가 예상하지 못한 드리프트 및 emerging failure modes를 포착합니다. 성숙한 설정은 둘 다 사용합니다: 오프라인은 변경을 gate하고, 온라인은 현실을 모니터링합니다. Phoenix, Langfuse, 그리고 DeepEval 기반 플랫폼은 모두 이 dual model을 지원하며, 추적 백엔드와 쌍을 이루는 것이 채점을 대시보드의 숫자가 아닌 실행 가능하게 만듭니다.

프롬프트 관리 및 피드백 루프

세 번째 기능이 스택을 완성합니다: 프롬프트 및 버전 관리. LLM 행동은 프롬프트에 의해 지배되며, 프롬프트는 지속적으로 변경됩니다 — 종종 배포를 소유한 엔지니어가 아닌 사람들에 의해 편집됩니다. 버전 없이, 3주 전 품질 regression은 추적 불가능합니다; 버전을 사용하면 평가 점수의 드롭을 그것을 유발한 정확한 프롬프트 revision에 correlate할 수 있습니다. Langfuse는 프롬프트 버전 관리와 built-in playground를 추적 및 eval과 함께 first-class features로 취급하는 것으로 주목할 만하며, 이는 그렇지 않으면 열린 상태로 유지되는 루프를 닫습니다: 추적에서 문제를 관찰하고, 가설을 형성하고, playground에서 프롬프트를 편집하고, 데이터세트에 대해 변경을 평가하고, 점수가 더 나은 버전을 배포합니다 — 모두 한 시스템 내에서.

이 루프 — trace, evaluate, adjust, re-evaluate — 는 LLM 관찰성의 실제 요점입니다. 개별 기능은 그를 위한 수단입니다. 자신의 애플리케이션이 무엇을 했는지 볼 수 있고, 좋았는지 측정할 수 있고, 변경 사항을 특정 revision에 attribute할 수 있고, 데이터에 대해 수정 사항을 검증할 수 있는 팀은 LLM 개발을 vibes 기반 iteration에서 engineering discipline로 변환했습니다. 그 변환, 그 이상으로 단일 기능보다, 2026년 스택이 전달하는 것입니다.

비용 및 토큰 관찰성

LLM 관찰성을 일반적인 모니터링과 분리하는 한 가지 차원이 자체 처리를 받을 자격이 있습니다: 비용. 모든 LLM 호출에는 토큰으로 측정되는 가격이 있으며, agentic 시스템에서는 단일 사용자 요청이 수십 개의 모델 호출로 분기할 수 있습니다 — retrieval reformulations, tool-use reasoning, multi-agent handoffs, retries. 집계 청구서는 계측 없이 보이지 않는 이유로 급상승할 수 있으며, "우리의 inference 비용이 이번 달에 3배가 되었습니다"는 추적이 직접 답하는 질문입니다. 각 span이 토큰 수와 비용을 기록하기 때문에 당신은 feature뿐만 아니라 특정 특정 에이전트의 reasoning의 특정 단계에 spend를 attribute할 수 있습니다. 팀은 routinely 발견합니다, 오직 계측 후에만, 단일 poorly-bounded retrieval loop 또는 over-eager re-ranking step이 token consumption의 불균형한 share를 차지한다는 것입니다.

이것은 비용을 월간 surprise에서 당신이 최적화할 수 있는 engineering metric으로 바꿉니다. 당신은 offline evaluation에서 두 프롬프트 버전의 토큰 비용을 그들의 품질 점수와 나란히 비교할 수 있으며, quality-versus-cost tradeoff를 explicit하게 만듭니다. 당신은 per-request token budgets에 대한 alert를 설정할 수 있고 runaway agent를 청구서를 실행하기 전에 포착할 수 있습니다. 그리고 당신은 expensive-but-low-value 호출을 식별할 수 있습니다 — 실제 돈을 들고 답변을 드물게 변경하는 호출 — 및 그들을 prune합니다. 2026년에, cost observability는 관찰성 스택의 first-class part로 취급됩니다. 왜냐하면 LLM economics는 usage-based이고 usage는 traces 없이 opaque이기 때문입니다. quality를 최적화하면서 token cost를 무시하는 팀은 문제의 반을 최적화하고 있습니다.

도구 선택하기

세 가지 reference 도구는 다른 시작점에 매핑되며, 올바른 선택은 당신의 팀이 이미 어디에 있는지에서 따릅니다. Arize Phoenix는 OpenTelemetry 기반 추적, 평가, 그리고 특히 retrieval debugging으로 시작하며, 특히 embeddings와 RAG 행동을 검사하기 위한 강한 지원이 있습니다; OTel 기반 portability와 deep RAG/agent debugging이 우선순위일 때 자연스러운 fit입니다. 그리고 notebook에서 self-hosted server로 편하게 실행합니다. Langfuse는 추적을 first-class prompt management와 product-analytics sensibility와 쌍을 이루므로, full observe-edit-evaluate loop를 하나의 self-hostable, MIT-licensed package에 원하는 팀에 강합니다. MLflow는 가장 널리 채택된 ML platform을 LLM tracing과 evaluation으로 확장하므로, 이미 MLflow를 ML lifecycle의 나머지에 표준화했으며 trace와 trace-data ownership을 위한 하나의 플랫폼을 원하는 조직에 최소 resistance의 경로입니다.

이 세 개 이상으로, landscape는 DeepEval과 Confident AI를 evaluation-first end에, OpenTelemetry support를 가진 Comet Opik, 그리고 others를 포함합니다 — 그러나 선택 criteria는 일관적입니다. OpenTelemetry 기반 계측을 고집하세요. 당신의 데이터가 sensitive하면 도구가 self-host할 수 있다는 것을 확인하세요. 추적, 평가, prompt management가 bolted-on silos가 아닌 함께 작동하는지 확인하세요. 왜냐하면 value는 루프에 있고 parts에 있지 않습니다. 그리고 주어진 당신의 기존 스택으로 friction을 최소화하는 도구로 시작하세요. 당신이 실제로 배포하는 관찰성은 설정하기로 의도한 이상적인 도구를 이깁니다.

결론

LLM 관찰성은 2026년에 real discipline이 되었습니다. 왜냐하면 프로덕션 LLM 애플리케이션은 non-deterministic, semantically opaque, structurally deep합니다 — 세 가지 속성이 일반적인 모니터링을 패배시킵니다. 그들에게 답하는 스택은 agent call tree를 보이게 하는 추적, 당신이 eyeball할 수 없는 품질을 측정하는 평가 (LLM-as-judge, offline과 online), 그리고 변경 사항을 원인에 attribute하는 prompt versioning입니다. OpenTelemetry는 전체 물건을 상호 운용 가능하게 만든 connective tissue이며, Phoenix, Langfuse, 또는 MLflow같은 OTel 기반 도구를 선택하는 것은 벤더 대신 표준으로 구매하는 방법입니다. 추적을 먼저 계측하고, 평가를 위에 계층화하고, prompt management로 루프를 닫으세요. 그러면 LLM app은 때때로 misbehave하는 블랙 박스에서 당신이 실제로 engineering할 수 있는 시스템으로 변환됩니다.

참고 자료 및 리소스

도구

배경 및 분석

관련 1337skills 치트시트