옵저버빌리티

LLM 앱이 호출할 때마다 입력 프롬프트, 응답, 걸린 시간, 비용, 에러를 기록하고, 여러 단계로 도는 에이전트 실행은 트리로 펼쳐 보여주는 시스템이다. 에러 없이 틀린 답이 나오거나 에이전트가 중간에 꼬였을 때 그 답이 왜 나왔는지 거꾸로 따라가 원인을 찾는 데 쓴다. LLM 앱을 실제 사용자에게 내놓을 때부터 필요하다.

에러 없이 틀리는 게 문제다

LLM 앱은 블랙박스에 가깝다. 같은 입력에도 결과가 달라지고, 검색·도구 호출·LLM 호출이 이어지는 체인에서는 어느 단계가 잘못됐는지 겉으로는 알 수 없다. 서버 로그에는 정상 응답으로만 남기 때문에, 실제로 오간 프롬프트와 중간 결과를 남겨야 원인을 찾을 수 있다.

트레이스 하나에 실행 전체가 담긴다

사용자 요청 하나가 트레이스 하나가 되고, 그 안의 각 단계가 하위 기록으로 붙는다. 화면에서 트리를 펼치면 어떤 단계에서 시간이 오래 걸렸는지, 어떤 프롬프트가 들어갔는지 바로 보인다.

SDK나 콜백 하나로 붙인다

보통 도구를 고르고, 앱에 SDK를 넣거나 프레임워크 콜백을 등록하는 순서다. 예를 들어 LangChain 앱에 Langfuse 콜백을 추가하면 에이전트 실행 전체가 트레이스로 남는다. 표준 쪽으로는 OpenTelemetry를 LLM 트레이싱에 맞게 확장한 OpenInference나 OTLP 기반 도구들이 있어, 한 번 계측해 두면 받는 쪽 도구를 바꾸기 쉽다.

개인정보와 비용을 먼저 정한다

프롬프트와 응답에는 사용자 개인정보가 그대로 들어갈 수 있다. 외부 서비스로 보내기 전에 민감한 값을 가리거나, 직접 설치형을 쓰는 게 안전하다. 트래픽이 많으면 기록량도 커지므로 일부만 샘플링하는 방법도 있다.

기록만으로 답의 품질이 저절로 판단되지는 않는다. 트레이스에 사용자 피드백이나 자동 평가 점수를 붙여 두면, 품질이 떨어진 대화만 골라 보는 데 훨씬 편하다.

개발 중엔 디버깅, 운영 중엔 품질·비용 점검

가장 흔한 용도는 이상한 답이 나온 트레이스를 펼쳐 틀린 단계를 찾는 것이다. 앱을 내놓은 뒤에는 나쁜 평가를 받은 대화나 비싸고 느린 호출을 골라 프롬프트와 흐름을 고치는 데 쓴다.