LLM 앱을 위한 관측성: 중요한 것을 로깅하기

전통적인 애플리케이션은 작동하거나 오류를 던지거나 둘 중 하나이고, 망가지면 스택 트레이스를 읽습니다. LLM 애플리케이션에는 훨씬 흔하고 훨씬 디버깅하기 어려운 세 번째 상태가 있습니다. 멀쩡히 실행되고, 오류를 반환하지 않으며, 미묘하게 혹은 심하게 틀린 답을 내놓는 상태죠. 잡을 예외가 없습니다. LLM 앱을 위한 관측성은 각 상호작용에 대해 충분히 많은 것을 포착해, "나쁜 답을 내놨다"를 실제로 조사할 수 있는 질문으로 만드는 실천입니다. 이 글은 무엇을, 왜 로깅해야 하는지, 그리고 데이터에 빠져 죽지 않으면서 어떻게 하는지를 다룹니다.

평범한 모니터링으로는 부족한 이유

고전적 관측성은 오류, 지연 시간, 자원 사용을 지켜봅니다. 그것들은 여전히 중요하지만, 언어 모델 특유의 실패 양상을 놓칩니다. 완벽하게 성공한 호출이 틀린 콘텐츠를 반환하는 경우 말이죠. HTTP 상태는 멀쩡하고, 지연 시간은 정상이며, 불나는 곳이 없습니다 — 그런데 출력은 환각이거나, 지시를 벗어났거나, 안전하지 않습니다.

그것을 디버깅하려면 상호작용의 내부를 들여다봐야 합니다. 런타임에 조립된 부분을 포함해 정확히 어떤 프롬프트가 모델에 갔는가? 모델은 무엇을 반환했는가? 어떤 맥락이 검색되어 주입되었는가? 어느 버전의 프롬프트가 라이브였는가? 이 중 무엇도 인프라 지표에서는 보이지 않습니다. LLM 관측성은 각 상호작용의 콘텐츠를 사후에 들여다볼 수 있게 만들기 위해 존재합니다. 무언가 잘못되는 순간, 유일하게 남는 증거는 당신이 로깅한 것뿐이기 때문입니다.

핵심 기록: 상호작용 전체를 포착하기

기반은 무슨 일이 있었는지 재구성할 수 있을 만큼 완전한, 각 모델 상호작용의 기록입니다. 최소한 다음을 의미합니다.

• 해석이 끝난 전체 프롬프트. 템플릿이 아니라, 모든 변수와 검색된 맥락, 대화 이력이 채워진, 실제로 전송된 텍스트입니다. 버그는 당신이 쓴 템플릿이 아니라 조립된 결과에 있는 경우가 아주 많습니다.
• 전체 응답. 당신의 후처리가 형태를 바꾸거나 잘라내기 전, 모델이 반환한 그대로입니다.
• 모델과 매개변수. 어느 모델인지, 그리고 temperature처럼 동작을 좌우하는 설정입니다. 같은 프롬프트라도 이것들에 따라 다르게 동작합니다.
• 프롬프트 버전. 어느 버전의 프롬프트가 라이브였는지, 그래야 퇴보를 특정 변경에 묶을 수 있습니다.

이 네 가지가 있으면 대부분의 "왜 그렇게 했지" 조사가 다룰 만해집니다. 그것들이 없으면 추측할 뿐입니다. 규율은 해석이 끝난 상태를 로깅하는 것입니다. 의도한 템플릿과 실제로 보낸 프롬프트 사이의 틈에 놀랄 만큼 많은 버그가 살기 때문입니다.

모델 호출만이 아니라 사슬 전체를 추적하기

현대의 LLM 앱은 단일 호출인 경우가 드뭅니다. 한 요청이 문서를 검색하고, 모델을 호출하고, 도구를 부르고, 다시 모델을 호출할 수 있습니다. 최종 답이 틀렸을 때 원인은 어느 단계에든 있을 수 있습니다 — 잘못된 검색, 잘못된 형식의 도구 결과, 혹은 모델 자체죠.

그래서 추적(tracing)이 로깅만큼 중요합니다. 트레이스는 한 요청을 처리하는 모든 단계를 하나의 연결된 타임라인으로 묶어, 입력에서 출력까지 요청을 따라가며 어디서 어긋났는지 볼 수 있게 합니다. 잘못된 문서가 검색되었나? 그렇다면 모델은 나쁜 맥락 위에서 올바르게 추론한 것이고, 고칠 곳은 프롬프트가 아니라 검색입니다. 검색은 성공했는데 모델이 그 맥락을 무시했나? 그것은 완전히 다른 수정입니다. 종단 간 트레이스가 없으면, 다단계 시스템은 디버깅이 거의 불가능합니다. 사슬의 어느 고리가 실패했는지 알 수 없기 때문입니다.

시간에 따라 지켜볼 가치가 있는 지표

상호작용별 기록을 넘어, 소수의 집계 신호가 운영 환경에서 시스템이 건강한지를 알려 줍니다.

• 첫 토큰까지의 시간을 포함한 지연 시간. 스트리밍 경험에서는 출력이 시작되기까지 걸리는 시간이 전체 완료 시간과는 별개로, 사용자가 실제로 느끼는 것인 경우가 많습니다.
• 토큰 사용량. 요청당 소비된 토큰은 비용과 직결되며, 프롬프트와 맥락이 자라면서 슬금슬금 늘어납니다. 이를 지켜보면 비싼 드리프트를 일찍 잡습니다.
• 오류 및 거부율. 하드 실패와, 모델이 거절하거나 얼버무리는 더 부드러운 양상 둘 다입니다. 거부율 상승은 흔히 조사할 가치가 있는 프롬프트나 정책 문제를 신호합니다.
• 처리량과 볼륨. 기준 트래픽이 있어야 이상 징후가 그것에 대비되어 두드러집니다.

이것들은 답이 좋은지는 알려 주지 않습니다 — 시스템이 정상적으로 동작하는지만 알려 줍니다. 이것들은 조기 경보 계층입니다. 지표가 움직이면 상호작용별 로그로 가서 이유를 찾습니다. 단일 시점이 아니라 추세로 추적하세요. 수치는 자기 자신의 이력에 대비될 때만 의미를 갖기 때문입니다.

활동이 아니라 품질을 판단하기

가장 관측하기 어려운 것은 출력이 실제로 좋은지입니다. 대조할 정답이 대개 하나로 정해져 있지 않기 때문입니다. 몇 가지 실무적 접근이 품질을 적어도 부분적으로 보이게 만듭니다.

사용자 신호가 있을 때 포착하세요 — 명시적인 좋아요·싫어요, 혹은 사용자가 재시도하거나 떠나거나 출력을 편집하는 암묵적 신호 말이죠. 이것들은 잡음이 많지만 실재하며, 살펴볼 가치가 있는 상호작용으로 당신을 안내합니다. 대표적인 입력의 선별된 세트를 유지하고, 롤아웃 전에 새 프롬프트나 모델 버전을 그것에 돌려, 운영 환경에서 퇴보를 발견하는 대신 의도적으로 품질을 비교하세요. 그리고 실제 상호작용을 정기적인 주기로 표집해 사람이 검토하세요. 실제 출력을 일상적으로 조금씩 읽는 것이 어떤 지표로도 드러나지 않는 드리프트를 잡아냅니다. 요점은 판단을 완전히 자동화하는 것이 아니라, 깜깜이로 나는 일을 멈추는 것입니다.

책임 있게 로깅하기

전체 프롬프트와 응답을 포착한다는 것은 사용자가 입력한 무엇이든 포착한다는 뜻이고, 거기에는 개인정보나 민감 정보가 들어 있을 수 있습니다. 관측성이 조용한 데이터 보존 문제가 되어서는 안 됩니다.

처음부터 프라이버시를 설계에 넣으세요. 무엇이 저장되는지 파악하고, 가능한 곳에서는 민감한 필드를 마스킹하거나 저장을 피하며, 로그가 영원히 쌓이지 않도록 보존 한도를 설정하고, 누가 읽을 수 있는지 통제하세요. 여기엔 진짜 긴장이 있습니다. 로그가 풍부할수록 디버깅은 나아지지만, 그 로그가 유출되면 노출도 커집니다. 이를 우연이 아니라 의도적으로 해소하세요. OpenAI와 Anthropic의 제공사 문서는 그들 자신의 데이터 처리를 설명하며 이는 그림의 일부지만, 당신이 저장하는 것을 통제하는 책임은 당신에게 있습니다.

작게 시작해 키우기

첫날부터 완전한 관측성 플랫폼이 필요한 것은 아니며, 그런 척하는 것은 영영 시작하지 않는 좋은 방법입니다. 모든 상호작용에 대해 핵심 기록 — 해석이 끝난 프롬프트, 응답, 모델, 프롬프트 버전 — 을 로깅하는 것부터 시작하세요. 그 한 걸음만으로도 초기 디버깅의 대부분이 가능해집니다. 시스템이 단일 호출을 넘어 자라면 추적을 더하세요. 추세가 의미를 가질 만큼 트래픽이 쌓이면 집계 지표를 더하세요. 프롬프트와 모델을 본격적으로 튜닝하게 되면 품질 평가를 더하세요. 각 계층은 자기 자리를 벌어들입니다. 한꺼번이 아니라, 애플리케이션이 실제로 자라는 순서대로 쌓으세요.

정리

LLM 앱은 전통적 모니터링이 볼 수 없는 방식으로 실패합니다 — 성공한 호출이 틀린 답을 반환하는 식으로요 — 그래서 관측성은 둘러싼 인프라만이 아니라 각 상호작용의 내부를 들여다봐야 합니다. 해석이 끝난 전체 프롬프트와 응답을 모델·프롬프트 버전과 함께 로깅하고, 다단계 요청을 종단 간으로 추적하며, 지연 시간과 토큰 사용량을 추세로 지켜보고, 품질을 가정하는 대신 표집할 방법을 찾으세요. 처음부터 프라이버시를 설계에 넣어 그렇게 하고, 시스템이 자람에 따라 계층을 키우세요. 그 보상은 "나쁜 답을 내놨다"가 어깨를 으쓱하는 일이 아니라, 답할 수 있는 질문이 된다는 것입니다.