그 전화는 새벽 2시에 걸려왔습니다. 단순한 페이지(page) 알림이 아니라, 우리 보이스 에이전트(voice agent)가 "말하는 도중에 전화를 끊어버렸다"고 말하는 고객이 신고한 실제 지원 녹음 파일이었습니다. 저는 트레이스(trace)를 추출했습니다. LLM 호출은 완벽했습니다. 380ms, 깔끔한 완료, 합리적인 응답. 제가 가진 모든 대시보드(dashboard)는 녹색(green)이었습니다. 고객은 여전히 화가 나 있었고, 제 툴링(tooling)은 그 이유에 대해 아무런 말도 해주지 못했습니다.

그 간극이 바로 제가 이야기하고 싶은 부분입니다. 저는 직업으로 보이스 에이전트(voice agent)를 만듭니다. 전화를 받고, 예약을 잡고, 가끔 운영 환경(production)에서 저를 당황하게 만드는 그런 에이전트 말이죠. 그리고 3년 동안 이 일을 하며 얻은 뼈아픈 교훈은 이것입니다. LLM 호출을 트레이싱(tracing)하는 것은 쉬운 20%에 불과하다는 것입니다. 보이스 에이전트의 실패는 여러분의 트레이서(tracer)가 절대 볼 수 없는 오디오 레이어(audio layer)에 존재합니다.

1주 차: 내 대시보드들이 무엇을 숨기고 있었는지 배우기
LLM이 제품의 전부일 때는 LLM 트레이서(tracer)만으로 충분합니다. 프롬프트(prompt), 완료(completion), 토큰(tokens), 비용(cost), 지연 시간(latency)을 볼 수 있죠. 아름답습니다.

보이스 에이전트는 파이프라인(pipeline)이며, LLM은 그 중간의 한 단계일 뿐입니다. 오디오(audio)가 들어오면, ASR 모델이 이를 전사(transcribe)하고, 엔드포인터(endpointer)가 사람이 말을 멈춘 시점을 결정하며, 오케스트레이션(orchestration)이 컨텍스트(context)를 조립하고, LLM이 응답하며, TTS가 이를 다시 말하고, 그 어딘가에서 바지인 디텍터(barge-in detector)가 사람이 말을 가로챌 때를 감지해야 합니다. LLM 트레이스(trace)는 그 체인의 박스 하나만을 커버합니다. 새벽 2시의 전화가 끊긴 이유는 엔드포인터(endpointer)가 너무 일찍 작동했기 때문입니다. 전사(transcript)는 모델에 도달하기도 전에 절반이 잘려 나갔습니다. 제 트레이서는 질문의 절반에 대해 결점 없는 응답을 기록했을 뿐입니다.

그래서 저는 실제로 무엇이 고장 나는지, 그리고 각 항목에 대해 무엇을 확인해야 하는지 목록을 만들었습니다:

턴 종료 감지 타이밍 (End-of-turn detection timing). 엔드포인터(endpointer)는 사람이 말을 마쳤다고 결정합니다. 너무 성급하면 사용자의 말을 가로막게 되고(제 새벽 2시의 전화처럼), 너무 느리면 에이전트가 죽어 있는 것처럼 느껴집니다. 이것은 LLM 스팬(span)이 아니라 지연 시간과 결정이 결합된 이벤트이며, 대부분의 도구는 이에 대한 개념이 없습니다.

ASR 지연 시간 및 신뢰도 (ASR latency and confidence). 전사(transcription)에 900ms가 걸리거나 신뢰도(confidence)가 0.4로 돌아온다면, LLM의 응답이 즉각적이라 할지라도 여전히 틀릴 수 있습니다. 턴(turn)에 신뢰도 점수가 함께 붙어 있어야 합니다.

끼어들기 감지 (Barge-in detection). 사람이 에이전트의 말을 가로채며 말을 시작합니다. 시스템이 이를 인지했나요? 얼마나 빨리 말을 멈췄나요? 이는 순수 오디오 계층 (audio-layer)의 문제이며, 텍스트 트레이서 (text tracer)에는 보이지 않습니다.

첫 오디오 도달 시간 (Time-to-first-audio). 첫 토큰 도달 시간 (time-to-first-token)이 아닙니다. TTS가 소리를 생성할 때까지 인간은 아무것도 듣지 못합니다. 이것이 실제로 중요한 지연 시간 (latency)이며, 여러분의 LLM 대시보드에 표시되는 모든 것의 하류 (downstream)에 존재합니다.

이 중 어느 것도 생소한 것이 아닙니다. 이것들은 프로덕션 환경에 있는 모든 음성 에이전트가 매일 겪는 실패 모드 (failure modes)입니다. 그리고 툴링 (tooling)에 관한 논의에서는 이들이 거의 언급되지 않습니다.

2주 차: 해당 목록을 기준으로 6가지 도구 검증
저는 제가 사용했거나 진지하게 테스트했던 6가지 관측성 (observability) 도구를 살펴보고, 각 도구에 한 가지 질문을 던졌습니다: 오디오 계층을 실제로 얼마나 볼 수 있는가, 그리고 그 데이터에 도달하기 위해 얼마나 많은 작업이 필요한가. 저는 일반적인 품질이 아니라 음성 에이전트 적합성을 기준으로 점수를 매깁니다. 이 중 몇몇은 매우 훌륭한 도구들이지만, 단순히 저와 같은 파이프라인을 염두에 두고 만들어지지 않았을 뿐입니다.

Langfuse. OpenTelemetry 기반이므로 형식이 사용자와 충돌하지 않습니다. ASR, 엔드포인팅 (endpointing), 첫 오디오 도달 시간 (time-to-first-audio)을 위한 커스텀 스팬 (custom spans)을 부착할 수 있으며, 이는 트레이스 트리 (trace tree)에 나타납니다. 솔직한 견해를 말하자면, 순수 LLM 관측성 측면에서 Langfuse는 제가 나중에 언급할 중간 순위 옵션을 포함하여 이 목록의 대부분보다 더 강력하고 세련되었습니다. 문제는 오디오 계층에 관한 그 어떤 것도 자동이 아니라는 점입니다. 모든 스팬 (span)을 수동으로 계측 (instrument)해야 합니다.

Phoenix (Arize). 동일한 OTel 이야기입니다. 형식에 구애받지 않으며, 커스텀 스팬이 작동하고, 만약 여러분의 영역이 평가 (eval)와 드리프트 (drift)라면 그 부분에 강점이 있습니다. 마찬가지로, 오디오 스팬 (audio spans)은 사용자가 직접 정의하고 방출 (emit)해야 합니다.

Laminar. OTel 네이티브이며 더 최신 도구로, 계측 (instrument)하기 편리합니다. 동일한 패턴을 따릅니다: 여러분이 보내는 오디오 스팬은 모두 수용하지만, 스스로 만들어내지는 않습니다.

Future AGI (traceAI). 저에게 이 목록의 중간쯤에 위치하며, 그 이유를 정확히 밝히고 싶습니다. 이 도구의 트레이싱 (tracing) 레이어인 traceAI는 OpenTelemetry 네이티브이며, 2026년 6월 기준으로 50개 이상의 프레임워크를 위한 인스트루멘터 (instrumentors)를 갖추고 모든 백엔드로 OTLP를 내보냅니다 (리포지토리는 github.com/future-agi/traceAI에서 공개되어 있습니다). 다른 도구들과 마찬가지로 음성 작업을 위해 동일한 이점을 제공하는데, OTel이 기저층 (substrate)이기 때문에 커스텀 오디오 스팬 (audio spans)이 일급 시민 (first-class)으로 취급됩니다. 제가 이 도구에 점수를 준 부분은 평가 (eval) 측면으로, 단순히 텍스트가 아닌 오디오 컨텍스트 (audio context)를 기준으로 턴 (turn)을 점수화한다는 점입니다. 승리하지 못한 부분은 순수 관찰 가능성 (observability)의 사용성 측면이며, Langfuse와 Helicone이 훨씬 더 정교합니다. 저는 의도적으로 이 도구를 목록 중간에 두었습니다. 이는 유능한 옵션이지, 최고의 왕관은 아닙니다.

Helicone. LLM 호출 로깅 (logging), 비용 추적 (cost tracking), 그리고 게이트웨이 수준의 가시성 (visibility) 측면에서 진정으로 탁월하며, 이 그룹 중에서 해당 작업을 수행하기 위해 가장 빠르게 구축할 수 있습니다. 하지만 오디오 레이어에 대해서는 대체로 침묵합니다. 이는 결함이 아니라 집중 분야의 차이입니다. 만약 여러분의 문제가 LLM 비용과 호출 로깅이라면, Helicone이 여기 있는 모든 것보다 나을 수 있습니다. 하지만 여러분의 문제가 새벽 2시에 끊긴 전화라면, 이 도구는 그것을 포착하지 못할 것입니다.

LangSmith. 여섯 가지 도구 중 가장 LLM 중심적이며, 기본적으로 오디오 인지 능력이 가장 낮습니다. 만약 여러분이 LangChain 생태계에서 활동한다면 긴밀한 통합을 경험할 수 있습니다. 하지만 음성 파이프라인 (voice pipeline)을 이 안에서 읽기 쉽게 만들기 위해서는 가장 많은 적응 과정을 거쳐야 할 것입니다.

이 도구들을 나란히 배치해 보니 나타나는 패턴은 거의 지루할 정도였습니다. OpenTelemetry 네이티브 도구들 (Langfuse, Phoenix, Laminar, traceAI)은 모두 오디오 레이어를 표현할 수 있습니다. 왜냐하면 OTel은 스팬 (span)이 LLM 호출을 감싸고 있는지, 아니면 엔드포인터 (endpointer)의 결정인지에 대해 상관하지 않기 때문입니다. LLM 중심 도구들 (Helicone, LangSmith)은 자신들이 만들어진 목적에는 더 날카롭지만, 그 외의 모든 것에 대해서는 더 조용합니다. 이 목록에 있는 그 누구도 즉시 사용 가능한 (out of the box) 음성 에이전트 관찰 가능성 (voice-agent observability)을 제공하지 않습니다. 이들 모두는 여러분이 직접 오디오 스팬 (audio spans)을 정의해야만 합니다.

3주 차: 실제로 성과를 낸 계측 (instrumentation)
해결책은 도구를 교체하는 것이 아니었습니다. 오디오 레이어 (audio layer)를 먼저 계측 (instrument)하고, LLM 트레이스 (trace)는 이미 해결된 문제로 취급하기로 결정한 것이었습니다. 실제로 그랬으니까요. 구체적으로, 이제 모든 턴 (turn)은 ASR (지연 시간과 신뢰도를 속성으로 포함), 엔드포인터 결정 (2시의 끊김 현상을 포착했을 타이밍 포함), 그리고 첫 오디오 도달 시간 (time-to-first-audio)에 대한 스팬 (spans)을 방출합니다. 이것은 순수한 OpenTelemetry이므로, 제가 지정하는 어떤 백엔드 (backend)로든 데이터가 전달됩니다. 여섯 가지 도구 모두가 훌륭하게 처리하는 유일한 부분인 LLM 스팬 (span)은 이제 제 속성 중 가장 비중이 낮습니다.

출시된 기능, 그리고 그 새벽 2시의 트레이스를 추출하던 과거의 나에게 해주고 싶은 말
출시된 기능: 엔드포인터 (endpointer)의 결정이 일급 시민 (first-class)이자 추적 가능한 이벤트가 되는 음성 파이프라인 (voice pipeline), 그리고 이전에는 오류가 있는 통화 상황에서도 초록색으로 빛나던 대시보드가 이제는 그 원인이 된 조기 발화 스파이크 (early-fire spike)를 보여주는 대시보드입니다. 오디오 레이어 (audio-layer) 버그에 대한 실제 원인 파악 시간 (Mean-time-to-the-real-cause)은 "녹음본을 듣고 추측하기"에서 "스팬 (span) 읽기"로 바뀌었습니다. 새벽 2시 유형의 장애는 이제 저장된 쿼리 (saved query)가 되었습니다.

과거의 나에게 해주고 싶은 말: LLM 트레이스 (trace)를 쳐다보는 것을 멈추세요. 그것은 항상 초록색이었을 것입니다. 통화가 제대로 작동하는지, 사람이 언제 말을 멈추는지, 답변을 얼마나 빨리 듣는지, 중단 (interruption)이 감지되었는지 등을 실제로 결정하는 시스템의 부분은 당신이 전혀 계측 (instrument)하지 않았던 부분입니다. 당신의 예산과 팀에 맞는 OpenTelemetry 네이티브 도구를 무엇이든 선택하세요. 도구 간의 선택은 사람들이 생각하는 것만큼 중요하지 않습니다. 그 다음에는 대시보드를 비교하는 대신, 오디오 스팬 (audio spans)을 방출하는 데 일주일을 쓰세요. LLM 레이어 (layer)는 이미 해결된 문제입니다. 새벽 2시에 당신을 호출하는 것은 바로 음성 레이어 (voice layer)입니다.