LangSmith는 AI 애플리케이션의 트레이싱 (Tracing)을 위해 LangChain 및 LangGraph 제작자들이 만든 모니터링 (Monitoring) 및 관찰 가능성 (Observability) 플랫폼입니다.

하지만 LangSmith를 깊이 파고들기 전에, 관찰 가능성 (Observability)과 모니터링 (Monitoring)이 실제로 무엇을 의미하는지 먼저 이해해 봅시다.

**관찰 가능성 (Observability)**은 본질적으로 AI 애플리케이션이 실행되는 동안 이를 면밀히 지켜보는 것, 즉 각 단계에 어떤 입력 (Input)이 들어가고 어떤 출력 (Output)이 나오는지 정확히 추적하는 것을 의미합니다. RAG (Retrieval-Augmented Generation, 검색 증강 생성) 애플리케이션을 예로 들어보겠습니다. 이는 벡터 스토어 (Vector stores), 리트리버 (Retrievers), 문서 (Documents), 임베딩 (Embeddings), 그리고 LLM 그 자체와 같은 여러 구성 요소로 이루어져 있습니다. 여기서 관찰 가능성 (Observability)이란 이러한 구성 요소들 사이를 흐르는 모든 개별 입력 (Input)과 출력 (Output)을 기록 (Logging)하는 것을 의미합니다. 이렇게 하면 무언가 고장 났을 때 (그리고 항상 무언가는 고장 나기 마련입니다), 추측하는 대신 정확히 어디를 살펴봐야 할지 알 수 있습니다.

**모니터링 (Monitoring)**은 관찰 가능성 (Observability)과 비슷하게 들리지만, 실제로는 다른 개념입니다. 모니터링 (Monitoring)은 시스템이나 애플리케이션의 지표 (Metrics)를 전체적으로 추적하는 과정입니다. 예를 들어 다양한 실행 간의 지연 시간 (Latency), 하나의 엔드 투 엔드 (End-to-end) 실행 비용 등과 같은 것들입니다.

요약하자면: 관찰 가능성 (Observability)은 무엇이 왜 일어났는지를 알려주고, 모니터링 (Monitoring)은 전반적으로 상황이 얼마나 잘 수행되고 있는지를 알려줍니다. 두 가지 모두가 필요합니다. 모니터링 (Monitoring)은 무언가 잘못되었다는 것(예: 오후 3시에 지연 시간 급증)을 알리고, 관찰 가능성 (Observability)은 이를 상세히 파고들어 정확히 어떤 구성 요소가 원인이 되었는지 찾아내는 데 도움을 줍니다.

왜 특히 LLM 앱에 이것이 필요한가요?

전통적인 소프트웨어는 예측 가능합니다. 동일한 입력값으로 함수를 호출하면 매번 항상 동일한 출력을 얻습니다. 무언가 고장 나면, print 문을 추가하고, 로그를 확인하고, 해당 라인을 찾아 수정하면 됩니다. 끝입니다.

LLM 애플리케이션은 그렇게 작동하지 않습니다. 출력값이 비결정론적 (non-deterministic)입니다. 동일한 프롬프트 (prompt)라도 실행할 때마다 매번 다른 응답을 생성할 수 있습니다. 따라서 사용자가 "답변이 틀렸어요"라고 불평할 때, 단순히 상황을 재현하여 디버깅 (debug)할 수 없습니다. 로그를 남겨두지 않았다면, 그 정확한 실행 기록은 사라져 버립니다.

파이프라인 (pipeline)은 여러 단계를 거치며, 각 단계에서 조용히 오류가 발생할 수 있습니다. RAG 애플리케이션을 예로 들어봅시다. 앱이 잘못된 답변을 내놓았을 때, 어디서 문제가 발생했을까요?

• 벡터 스토어 (vector store)가 잘못된 문서를 검색했나요?
• 리트리버 (retriever)가 문서의 순위를 제대로 매기지 못했나요?
• 프롬프트 템플릿 (prompt template)에 너무 많은 컨텍스트 (context)가 포함되었나요?
• 올바른 컨텍스트가 있었음에도 LLM이 단순히 환각 (hallucinate)을 일으켰나요?
• 아니면 프롬프트의 변경이 원인이었나요?

관측성 (observability) 없이는 그저 추측하며 사후 수습을 할 뿐, 문제의 정확한 근본 원인 (root cause)을 파악할 수 없습니다. 각 구성 요소를 개별적으로 수동 테스트해야 하는데, 이는 느릴 뿐만 아니라 특정 실행 중에 실제로 어떤 일이 일어났는지를 반영하지 못합니다. 또한 워크플로우 (workflow)나 애플리케이션이 많은 구성 요소를 포함하여 복잡하다면, 문제를 찾는 것은 악몽이 될 것입니다.

모든 LLM 호출에는 비용이 발생합니다. 그리고 다단계 파이프라인에서는 인지하지 못하는 사이에 사용자 요청당 5~10번의 LLM 호출을 수행할 수도 있습니다. 모니터링 (monitoring) 없이는 어떤 단계가 예산을 낭비하고 있는지 알 수 없습니다. 쿼리 재작성기 (query rewriter)인가요? 요약기 (summarizer)인가요? 아니면 최종 답변 생성기 (final answer generator)인가요? API 청구서가 도착하기 전까지는 알 수 없을 것입니다.

이것이 바로 LangSmith가 존재하는 이유입니다.

LangSmith의 핵심 개념에 대해 알아봅시다 -

1. Projects (프로젝트) - LangSmith에서 프로젝트는 단순히 여러분의 AI 애플리케이션 중 하나를 담는 컨테이너입니다. 모든 Trace (트레이스)와 Run (런)은 프로젝트 아래에 기록되므로, 데이터가 조직적으로 관리되고 분리됩니다.

2. Trace (트레이스) - Trace는 사용자가 입력을 보낸 순간부터 앱이 최종 응답을 반환하는 순간까지, 애플리케이션의 완전한 엔드 투 엔드 (end-to-end) 실행을 나타냅니다.

예를 들어, 사용자가 "환불 정책이 어떻게 되나요?"라고 질문한다고 가정해 봅시다.
이 단일 질문은 검색 (retrieval), 재순위화 (reranking), 프롬프트 구성 (prompt construction), LLM 호출 (LLM call), 응답 생성 (response generation)에 이르는 전체 RAG 파이프라인을 트리거합니다. 시작부터 끝까지 이 모든 과정이 합쳐져 하나의 Trace가 됩니다.

1. Runs (런) - 만약 Trace가 전체 여정이라면, Run은 그 과정에 있는 각각의 개별 단계를 의미합니다.

"환불 정책이 어떻게 되나요?"라는 하나의 Trace 내부에서, LangSmith는 이를 다음과 같은 Run들로 세분화합니다:

Trace: "환불 정책이 어떻게 되나요?"

• Run 1: 사용자 쿼리 임베딩 (Embed the user query)
• Run 2: 문서 검색 (Retrieve documents)
• Run 3: 문서 재순위화 (Rerank documents)
• Run 4: 프롬프트 구성 (Construct prompt)
• Run 5: LLM 호출 (LLM call)

LangSmith 설정하기

1단계: LangSmith 계정 생성
smith.langchain.com으로 이동하여 가입하세요. 접속 후, Settings (설정) → API Keys로 이동하여 새로운 API 키를 생성합니다. 생성된 키를 안전한 곳에 복사해 두세요.

2단계: 프로젝트 생성
LangSmith 대시보드에 접속하면 새 프로젝트를 생성합니다. 여러분의 애플리케이션과 일치하는 의미 있는 이름을 지정하세요.

3단계: 패키지 설치
pip install langsmith

4단계: 다음 환경 변수(environment variables)가 설정되어 있는지 확인하세요.

.env
LANGCHAIN_TRACING_V2=true  -- 트레이싱 활성화/비활성화 — 활성화하려면 true로 설정
LANGCHAIN_API_KEY=your-langsmith-api-key
...

정말 이게 전부입니다. 이 세 가지 환경 변수만 있으면 LangSmith가 Trace를 캡처하기 시작하는 데 필요한 모든 준비가 끝납니다.

LangSmith에 의해 추적되는 간단한 LangChain 워크플로우를 실제로 살펴봅시다 -

from dotenv import load_dotenv
from langchain_openai import ChatOpenAI
from langchain_core.prompts import PromptTemplate
...

위 스크린샷은 간단한 Sequential LLM 애플리케이션에 대한 실제 LangSmith 트레이스 (trace)를 보여줍니다.

중앙 패널은 이 트레이스 내부의 6개 실행 (runs)을 세분화하여 보여줍니다 — PromptTemplate이 입력을 포맷팅했고, gpt-4o-mini가 첫 번째 LLM 호출을 수행했으며 (13.68s, 1.1K tokens), StrOutputParser가 출력을 정리했습니다. 그 후 체인 (chain)은 또 다른 PromptTemplate과 gpt-4o를 통한 두 번째 LLM 호출 (4.85s, 1.4K tokens), 그리고 마지막 StrOutputParser로 이어졌습니다. 오른쪽에서는 정확한 입력값 (topic: AI Opportunity in India)과 LLM이 반환한 구조화된 출력 (structured output)을 확인할 수 있습니다.

이것이 바로 LangSmith를 강력하게 만드는 핵심입니다. 무언가 잘못되었을 때, 추측할 필요 없이 트레이스를 열어 정확히 어디에서 문제가 발생했는지 확인하면 됩니다.

LangSmith는 LangChain 및 LangGraph와 함께 별도의 설정 없이 즉시 작동합니다. 하지만 파이프라인 (pipeline)에 이러한 프레임워크의 네이티브 구성 요소가 아닌 컴포넌트가 포함되어 있다면, LangSmith가 이를 자동으로 트레이싱 (trace)하지는 않습니다. 그런 경우에는 함수를 @traceable 데코레이터 (decorator)로 감싸면 LangSmith가 다른 실행과 마찬가지로 이를 캡처합니다.

from langsmith import traceable
from openai import OpenAI

...

@traceable 데코레이터는 LangSmith에게 "이 함수를 하나의 실행으로 취급하고, 입력과 출력을 기록하라"고 지시합니다. 어떤 Python 함수나 프레임워크와도 함께 작동합니다.

LangSmith의 대안

Langfuse
Langfuse는 오픈 소스이며 셀프 호스팅 (self-hostable)이 가능하므로, 데이터가 귀하의 인프라를 절대 벗어나지 않습니다. LangChain뿐만 아니라 모든 LLM 프레임워크와 작동하며, 프롬프트 버전 관리 (prompt versioning) 및 평가 (evaluation) 기능이 내장되어 있습니다. 데이터 프라이버시가 중요한 경우 최고의 선택입니다.

Helicone
Helicone은 애플리케이션과 LLM 제공업체 사이에서 프록시 (proxy) 역할을 합니다. 베이스 URL (base URL) 하나만 변경하면 토큰 (tokens), 비용 (cost), 지연 시간 (latency) 등 모든 요청을 자동으로 로깅하기 시작합니다. 코드 변경이 필요 없습니다. 전체적인 관측성 (observability) 설정을 구축하기보다 깔끔한 비용 및 사용량 가시성만을 원하는 팀에게 가장 적합합니다.

Arize Phoenix
Phoenix는 클라우드나 데이터 공유 없이 완전히 로컬 (locally)에서 실행됩니다. 단순히 트레이싱 (tracing)을 넘어 임베딩 시각화 (embeddings visualization) 및 데이터셋 분석 (dataset analysis) 기능을 제공합니다. 프로덕션 모니터링 (production monitoring)과 더불어 본격적인 평가 (evaluation) 또는 미세 조정 (fine-tuning) 작업을 수행하는 ML 팀에 가장 적합합니다.

결론

이제 시야를 넓혀 우리가 다룬 내용을 살펴보겠습니다.

우리는 하나의 단순한 진실로부터 시작했습니다. LLM 애플리케이션은 근본적으로 전통적인 소프트웨어와 다르다는 점입니다. 이들은 비결정론적 (non-deterministic)이며, 다단계 (multi-step) 과정을 거치고, 소리 없이 실패합니다. 잘못된 답변은 에러 (error)를 발생시키지 않습니다. 그저 사용자가 제품 사용을 중단할 때까지 조용히 사용자의 신뢰를 갉아먹을 뿐입니다.

관측성 (Observability)과 모니터링 (monitoring)은 이에 맞서는 당신의 방어 수단입니다. 관측성은 모든 단계에서 무엇이 왜 일어났는지를 알려줍니다. 모니터링은 시간이 지남에 따라 시스템이 얼마나 잘 작동하는지를 알려줍니다. 당신에게는 두 가지 모두가 필요합니다. LangSmith는 이 두 가지를 모두 제공하며, 거의 제로에 가까운 설정 노력만으로 LangChain 및 LangGraph와 네이티브하게 통합되는 깔끔한 UI에 담아 제공합니다.

LLM 앱에 관측성을 추가하기 가장 좋은 시점은 그것이 필요해지기 전입니다. 왜냐하면 프로덕션에서 무언가 고장 나고 사용자가 불만을 제기할 때쯤이면, 당신은 바로 그 실행 시점의 트레이스 (trace)가 있었기를 간절히 바랄 것이기 때문입니다.