LLM 앱이 요청 하나를 처리하며 거친 모델 호출, 검색, 툴 실행 같은 모든 단계를 순서대로 기록하는 것으로, 분산 시스템을 디버깅할 때 쓰던 방법을 가져왔다. 에이전트나 RAG처럼 여러 단계를 거치는 앱에서 답이 이상하거나 느리거나 비쌀 때 원인이 된 단계를 찾는 데 쓴다.
| 방법 | 보여주는 것 | 이럴 때 쓴다 |
|---|---|---|
| 일반 로그 | 흩어진 한 줄 기록 | 단순한 단일 호출 앱 |
| 트레이싱 | 단계별 흐름과 입출력 | 에이전트, RAG 같은 여러 단계 앱 |
| 평가(Eval) | 답의 품질 점수 | 프롬프트·모델을 바꾼 뒤 비교 |
사용자 요청 하나가 트레이스이고, 그 안의 각 단계가 스팬이다. 스팬은 다른 스팬을 품을 수 있어서, 대시보드에서는 전체 흐름이 트리 모양으로 보인다.
| 스팬 종류 | 기록되는 내용 |
|---|---|
| LLM 호출 | 프롬프트, 응답, 토큰 수, 걸린 시간 |
| 검색(Retrieval) | 검색어, 가져온 문서 |
| 툴 실행 | 넘긴 인자, 결과, 오류 |
가장 흔한 방법은 트레이싱 도구의 SDK를 설치하고 API 키를 설정하는 것이다. 많은 도구가 주요 LLM 라이브러리를 자동으로 계측해 주고, 직접 만든 함수는 데코레이터를 달면 스팬으로 기록된다. 프록시 방식 도구는 LLM API의 base URL만 바꾸면 호출이 기록되지만, 툴 실행처럼 앱 안에서 일어나는 단계는 잘 보이지 않는다.
답이 이상하다는 신고가 오면 해당 트레이스를 열고 스팬을 위에서부터 펼쳐 본다. 검색 결과가 엉뚱하면 검색 단계를, 검색은 맞는데 답이 틀리면 프롬프트를 고치면 된다.
Langfuse, LangSmith, Helicone, MLflow, Arize Phoenix 같은 도구가 널리 쓰인다. 오픈소스라서 직접 서버에 올릴 수 있는 것도 있다. 표준인 OpenTelemetry 형식으로 데이터를 보내도록 만들어 두면 나중에 도구를 바꾸기 쉽다.
트레이스에는 프롬프트와 응답이 통째로 남기 때문에 사용자 개인정보나 비밀 키가 함께 저장될 수 있다. 운영 환경에서는 민감한 값을 가리고, 트래픽이 많으면 일부 요청만 기록하는 샘플링으로 저장 비용과 부담을 줄인다.
가장 흔한 쓰임은 에이전트를 만들면서 실행할 때마다 트레이스를 열어 보고 단계별로 고치는 것이다. 서비스에 올린 뒤에는 같은 트레이스로 느린 요청과 비용이 큰 요청을 찾아낸다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 에이전트 개발 | 실행할 때마다 트레이스를 열어 어떤 툴을 어떤 인자로 불렀는지 확인하고 프롬프트를 고친다 |
| 사내 문서 검색 같은 RAG 앱 | 답이 틀린 질문의 검색 스팬을 열어 가져온 문서가 맞는지부터 본다 |
| 운영 모니터링 | 스팬의 걸린 시간·토큰 수를 모아 느리거나 비싼 단계를 찾는다 |
| 평가와 연결 | 문제가 된 트레이스를 모아 평가 데이터로 삼고, 프롬프트를 바꾼 뒤 다시 비교한다 |