LLM 애플리케이션을 디버깅하기 어려운 이유
기존 로깅만으로 LLM 애플리케이션을 충분히 파악하기 어려운 이유, RAG 및 에이전트 파이프라인의 실패를 진단하는 데 필요한 정보, 추적 데이터 모델을 이해합니다.
LLM 애플리케이션을 디버깅하기 어려운 이유은(는) CoddyKit의 무료 AI Engineering Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AI Engineering Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
LLM 디버깅의 고유한 과제
전통적인 소프트웨어는 결정적으로 실패합니다. 동일한 입력이 주어지면 항상 동일한 출력을 생성하고, 스택 추적은 실패한 줄을 직접 가리킵니다. LLM 애플리케이션은 이러한 가정을 깨뜨립니다. 동일한 프롬프트도 호출할 때마다 서로 다른 출력을 만들 수 있고, 실패가 조용히 발생하는 경우가 많으며(예외 대신 잘못된 답변이 반환됨), 원인이 연쇄 과정에서 5단계 앞서 사용된 프롬프트에 숨어 있을 수도 있습니다. 표준 로그 기록 및 디버깅 도구는 이런 상황을 처리하도록 설계되지 않았습니다.
비결정성 때문에 재현이 어렵습니다
LLM 출력은 기본적으로 비결정적입니다. temperature=0으로 설정해도 일괄 처리와 수치 정밀도 때문에 동일한 프롬프트에서 약간씩 다른 출력이 나올 수 있습니다. 따라서 버그는 간헐적으로 발생합니다. 20%의 확률로 실패하는 프롬프트도 한 번만 실행하면 시험 모음을 통과할 수 있습니다. 특정 실패를 재현하려면 입력뿐 아니라 실패 당시의 정확한 입력, 모델 매개변수, 출력까지 기록해야 합니다.
import json
import time
def logged_llm_call(client, messages, model, temperature, **kwargs):
request_id = f'{int(time.time() * 1000)}-{id(messages)}'
response = client.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
**kwargs
)
# Log EVERYTHING needed to reproduce this exact call
log_entry = {
'request_id': request_id,
'model': model,
'temperature': temperature,
'messages': messages,
'response': response.choices[0].message.content,
'finish_reason': response.choices[0].finish_reason,
'usage': response.usage.model_dump(),
'timestamp': time.time()
}
write_to_trace_store(log_entry)
return response조용한 실패: 망가진 것이 아니라 잘못된 것
가장 교묘한 LLM 실패는 조용한 실패입니다. API 호출은 성공하고(HTTP 200, 예외 없음) 답변만 잘못되었거나, 환각을 포함하거나, 불완전하거나, 주제에서 벗어납니다. 애플리케이션은 아무 문제가 발생했다는 표시 없이 잘못된 답변을 처리하여 사용자에게 반환합니다. 예외와 오류 코드만 감시하는 기존 모니터링으로는 이러한 실패를 절대 발견할 수 없으므로 출력 품질에 대한 의미 기반 모니터링이 필요합니다.
# This succeeds with HTTP 200 but returns wrong information
response = client.chat.completions.create(
model='gpt-4o',
messages=[{'role': 'user', 'content': 'What is the boiling point of water at sea level?'}]
)
output = response.choices[0].message.content
# response.status_code: None (not relevant - always 200 if we got here)
# No exception thrown
# But if output is '90 degrees Celsius', it is WRONG and your app will serve bad data
# You need semantic validation:
def validate_boiling_point_answer(text: str) -> bool:
return '100' in text # Rough check - real validation is more sophisticated다단계 연쇄 과정: 어디에서 잘못되었을까요?
RAG 처리 과정이나 에이전트 연쇄 과정에서 최종 응답의 실패는 관련 없는 청크를 반환한 검색 단계로 거슬러 올라갈 수 있습니다. 이 검색 문제는 핵심 문장을 두 청크로 나눈 청크 분할 전략에서 비롯되었을 수 있고, 이는 다시 기술 용어를 제대로 처리하지 못한 임베딩 모델에서 비롯되었을 수 있습니다. 단계별 추적이 없으면 잘못된 최종 답변만 보일 뿐, 어느 단계에서 오류가 발생했는지 특정할 방법이 없습니다.
# Without tracing: you see only the final wrong answer
def rag_pipeline_naive(query):
chunks = retrieve(query) # step 1 - might return bad chunks
context = format_context(chunks) # step 2 - might truncate key info
answer = generate(query, context) # step 3 - LLM gets bad context
return answer # WRONG - but why?
# With tracing: you can see each step's input and output
def rag_pipeline_traced(query):
with trace_span('retrieve') as span:
chunks = retrieve(query)
span.set_attribute('num_chunks', len(chunks))
span.set_attribute('top_chunk_score', chunks[0]['score'] if chunks else 0)
with trace_span('format_context') as span:
context = format_context(chunks)
span.set_attribute('context_length', len(context))
with trace_span('generate') as span:
answer = generate(query, context)
span.set_attribute('answer_length', len(answer))
return answer # Now you can diagnose: was retrieve the problem?토큰 수와 비용의 뜻밖의 변화
계측이 없으면 월별 청구서가 도착할 때까지 토큰 수와 비용을 알 수 없습니다. 부주의로 시스템 프롬프트가 500토큰에서 5000토큰으로 늘어나거나, 검색 함수가 5개가 아니라 20개의 청크를 반환하거나, 반복문이 LLM을 10번이 아니라 100번 호출할 수 있습니다. 이 모든 상황이 비용을 조용히 배로 늘립니다. 모든 LLM 호출을 계측하여 프롬프트 토큰, 완성 토큰, 예상 비용을 기록하고 이상 징후를 실시간으로 확인할 수 있게 하십시오.
COST_PER_1K = {'gpt-4o': {'input': 0.005, 'output': 0.015},
'gpt-4o-mini': {'input': 0.000150, 'output': 0.000600}}
def compute_cost(model: str, usage) -> float:
pricing = COST_PER_1K.get(model, {'input': 0.005, 'output': 0.015})
input_cost = (usage.prompt_tokens / 1000) * pricing['input']
output_cost = (usage.completion_tokens / 1000) * pricing['output']
return input_cost + output_cost
def instrumented_call(client, model, messages):
response = client.chat.completions.create(model=model, messages=messages)
cost = compute_cost(model, response.usage)
# Alert if single call is unexpectedly expensive
if cost > 0.10: # more than 10 cents for one call
print(f'WARNING: Expensive LLM call: ${cost:.4f} ({response.usage.prompt_tokens} prompt tokens)')
metrics.record('llm_cost_usd', cost, tags={'model': model})
metrics.record('llm_prompt_tokens', response.usage.prompt_tokens)
return response지연 시간: 어느 단계가 느릴까요?
사용자는 LLM 지연 시간을 하나의 대기 시간으로 경험하지만, 실제로는 벡터 데이터베이스 질의, 문서 검색, 프롬프트 조합, API 네트워크 호출, 토큰 생성, 응답 구문 분석 등 여러 개별 단계의 합입니다. 단계별 시간 측정이 없으면 느린 응답이 느린 검색기 때문인지 느린 LLM 호출 때문인지 알 수 없습니다. 각 단계를 지연 시간 측정으로 계측하여 실제 병목을 찾으십시오.
import time
from contextlib import contextmanager
@contextmanager
def timed(name: str, metrics_client):
start = time.monotonic()
try:
yield
finally:
elapsed_ms = (time.monotonic() - start) * 1000
metrics_client.histogram(f'step_latency_ms', elapsed_ms, tags={'step': name})
if elapsed_ms > 2000: # flag steps taking more than 2 seconds
print(f'SLOW STEP [{name}]: {elapsed_ms:.0f}ms')
# Usage
def rag_with_timing(query, metrics):
with timed('embed_query', metrics):
query_embedding = embed(query)
with timed('vector_search', metrics):
chunks = vector_db.search(query_embedding, top_k=5)
with timed('llm_generate', metrics):
answer = generate(query, chunks)
return answer실제로 필요한 정보
LLM 애플리케이션의 모든 실패를 진단하려면 다음 정보를 수집하고 저장해야 합니다. 완전한 입력 프롬프트(시스템 메시지와 모든 메시지), 사용한 모델과 매개변수(temperature, max_tokens), 완전한 출력, 토큰 수와 예상 비용, 단계별 지연 시간, 모든 도구 호출과 그 결과, 그리고 하나의 사용자 요청에 속한 모든 단계를 연결하는 세션 또는 요청 ID입니다. 이것이 실행 가능한 최소 추적 데이터 세트입니다.
from dataclasses import dataclass, field
from typing import Optional
import time
@dataclass
class LLMTrace:
request_id: str
session_id: str
step_name: str
model: str
temperature: float
system_prompt: str
user_messages: list[dict]
response: str
finish_reason: str
prompt_tokens: int
completion_tokens: int
cost_usd: float
latency_ms: float
tool_calls: list[dict] = field(default_factory=list)
error: Optional[str] = None
timestamp: float = field(default_factory=time.time)
def is_anomalous(self) -> bool:
return (
self.cost_usd > 0.10 or
self.latency_ms > 10000 or
self.finish_reason == 'length' or # was cut off
self.error is not None
)요청 ID를 사용한 추적 상관관계 연결
하나의 사용자 요청이 여러 서비스에서 10번의 LLM 호출을 발생시킬 수 있습니다. 모든 호출에 전달되는 상관관계 ID가 없으면 이러한 호출을 하나의 추적으로 묶을 수 없습니다. 모든 사용자 요청의 진입점에서 고유한 요청 ID를 삽입하고, 이후의 모든 LLM 호출, 데이터베이스 질의, 로그 메시지에 전달하십시오. 이렇게 하면 특정 사용자 요청의 전체 실행 경로를 재구성할 수 있습니다.
import uuid
from contextvars import ContextVar
# Thread-safe request ID propagation using context variables
request_id_var: ContextVar[str] = ContextVar('request_id', default='unknown')
def handle_user_request(query: str):
# Set request ID at the entry point
req_id = str(uuid.uuid4())[:8]
request_id_var.set(req_id)
return rag_pipeline(query)
def get_current_request_id() -> str:
return request_id_var.get()
# Every LLM call logs with the same request_id
def log_llm_call(model, prompt, response):
logger.info('LLM call', extra={
'request_id': get_current_request_id(), # automatically correlates all calls
'model': model,
'prompt_length': len(prompt),
'response_length': len(response)
})LLM 관측성 구성 요소
LLM 관측성 구성 요소는 세 계층으로 이루어집니다. 로그 기록은 모든 LLM 호출의 구조화된 기록을 수집합니다(LangSmith, Langfuse, 사용자 지정 로그). 측정 지표는 요청 수, 평균 지연 시간, 오류율, 일일 비용처럼 시간에 따른 집계 수치를 추적합니다. 추적은 하나의 요청 안에서 단계들이 인과적으로 연결된 과정을 기록합니다. 이 세 가지 축을 함께 사용하면 실패를 진단하고, 성능 저하를 포착하며, 성능을 최적화하는 데 필요한 가시성을 확보할 수 있습니다.
품질 저하에 대한 알림
오류가 이진적인 상태(정상/고장)로 나타나는 전통적인 소프트웨어와 달리 LLM 품질은 점진적으로 저하됩니다. 프롬프트를 변경하면 예외가 발생하지 않아도 답변 품질이 85%에서 70%로 떨어질 수 있습니다. 매일 운영 환경의 응답 일부를 대상으로 자동 평가(LLM-as-judge 점수 매기기)를 실행하여 품질을 감시하십시오. 이동 평균 품질 점수가 기준값 아래로 떨어지면 사용자가 불만을 제기하기 전에 알림을 보내십시오.
관측성 실천 시작하기
운영 장애가 발생할 때까지 관측성 추가를 미루지 마십시오. 다음 세 가지 최소 단계부터 시작하십시오. (1) 모든 LLM 호출의 전체 입력, 출력, 토큰 수를 데이터베이스나 파일에 기록합니다. (2) 모든 사용자 상호 작용에 요청 ID를 할당하고 모든 로그 항목에 포함합니다. (3) 처리 과정에 단계별 시간 측정을 추가합니다. 이 세 가지만으로도 디버깅 작업의 80%를 몇 시간이 아니라 몇 분 안에 해결할 수 있습니다.
빠른 확인
이 수업에서 LLM 앱을 디버깅하기 어려운 이유에 대한 이해도를 확인해 보십시오.
수업 요약
이 수업에서는 다음을 배웠습니다. 비결정성 때문에 LLM 버그는 간헐적으로 발생하며 전체 요청 맥락을 수집하지 않으면 재현하기 어렵습니다. 조용한 실패(성공한 API 호출에서 잘못된 답변이 반환되는 경우)는 기존 오류 모니터링을 우회하므로 의미 기반 품질 검사가 필요합니다. 또한 요청 ID 상관관계를 활용한 단계별 추적이 다단계 RAG 및 에이전트 처리 과정의 실패를 진단하는 데 필요한 최소 조건입니다. 다음으로 LangSmith를 사용하여 추적을 구현해 보겠습니다.
AI 튜터와 함께 Python을(를) 배우세요 — 무료
브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.
- 코스
- 30
- 레슨
- 120
자주 묻는 질문
“LLM 애플리케이션을 디버깅하기 어려운 이유” 강의는 무료인가요?
네 — “LLM 애플리케이션을 디버깅하기 어려운 이유” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AI Engineering Academy 강의 전체를 잠금 해제할 수 있습니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“LLM 애플리케이션을 디버깅하기 어려운 이유”에서 뭘 배우나요?
기존 로깅만으로 LLM 애플리케이션을 충분히 파악하기 어려운 이유, RAG 및 에이전트 파이프라인의 실패를 진단하는 데 필요한 정보, 추적 데이터 모델을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 AI Engineering Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
AI Engineering Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 AI Engineering Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“LLM 애플리케이션을 디버깅하기 어려운 이유” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 AI Engineering Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 AI Engineering Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- LLM 애플리케이션을 디버깅하기 어려운 이유
- LangSmith를 활용한 추적
- 모델에 구애받지 않는 관측성을 위한 Langfuse
- 지연 시간, 비용, 품질 저하 알림