트레이싱 설계
트레이싱은 “한 요청이 어디서 실패했는지”를 즉시 보여줘야 합니다.
LLM 앱에서는 모델 호출뿐 아니라 검색/툴 호출도 함께 기록해야 합니다.
span 구조 예시
| span | 포함 정보 |
|---|
ingress | 요청 시간, 사용자 컨텍스트, 입력 길이 |
retrieval | 쿼리, top-k, 검색 지연, 문서 ID |
llm_call | 모델명, 토큰 사용량, 응답 시간 |
tool_call | 도구명, 인자, 성공/실패 상태 |
egress | 최종 응답, safety 결과, 총 지연 |
트레이싱 설계 원칙
- 요청 단위 고유 ID를 끝까지 유지
- 개인정보는 저장 전에 마스킹
- 샘플링 정책을 환경별로 분리(dev/stage/prod)
- 재현에 필요한 최소 컨텍스트를 함께 저장
장애 분석 질문
- 실패는 특정 모델에서만 발생하는가
- 검색 품질 하락이 생성 실패로 이어졌는가
- 특정 프롬프트 버전에서 에러가 급증했는가
- 툴 호출 타임아웃이 병목인가
트레이스는 디버깅 로그가 아니라 운영 데이터입니다.
검색 가능한 필드(model, prompt_version, tenant)를 처음부터 설계하세요.
