LangSmith는 LangChain과 LangGraph로 구축한 애플리케이션의 개발, 테스트, 모니터링, 디버깅을 위한 통합 플랫폼입니다. 특히 AI 에이전트를 구축할 때 에이전트의 행동을 추적하고 성능을 분석하는 데 매우 유용합니다.
12장에서 에이전트의 한계로 “예측 불가능성”과 “테스트·디버깅의 까다로움” 을 꼽았습니다. 15장은 그 문제에 대한 답입니다.
LangSmith가 기록하는 것은 이렇습니다.
- 각 노드의 실행 과정과 소요 시간
- 도구 호출 내역과 결과
- LLM 프롬프트와 응답
- 상태 변화 기록
이러한 실행 추적으로 에이전트가 어떤 결정을 내렸는지, 어떤 경로로 작업을 수행했는지 명확하게 파악할 수 있습니다. 여기에 성능 분석 도구가 더해집니다.
- 응답 시간과 지연 시간 측정
- 토큰 사용량 및 비용 추적
- 성공률과 오류율 모니터링
연동은 환경변수만으로
LangGraph는 LangSmith와 환경변수를 활용해 매우 간단하게 연동할 수 있습니다.
홈페이지에서 회원가입한 뒤 [Get started with Tracing]을 고르면 연동 안내 화면이 나옵니다. [Generate API Key]로 키를 만들고, 3번 항목의 환경변수를 복사해 .env에 붙여 넣습니다.
LANGSMITH_TRACING=true
LANGSMITH_ENDPOINT="https://api.smith.langchain.com"
LANGSMITH_API_KEY="<발급받은 키로 교체>"
LANGSMITH_PROJECT="langgraph-agent-book"
OPENAI_API_KEY="<your-openai-api-key>"
주의할 점이 두 가지입니다.
- 안내에 나오는
LANGSMITH_API_KEY는 본인의 API 키로 교체해야 합니다. - 다른 LLM 프로바이더를 쓴다면 해당 모델에 맞는 환경변수를 적용하면 됩니다.
LANGSMITH_PROJECT에 지정한 이름이 대시보드에서 프로젝트 이름이 됩니다. 환경변수를 추가한 뒤 에이전트를 실행하면 자동으로 대시보드 화면으로 이동하고, 에이전트의 데이터를 불러오는 작업이 기록됩니다.
대시보드에서는 실행 내역과 함께 RUN COUNT, TOTAL TOKENS(7,714 / $0.01), MEDIAN TOKENS, ERROR RATE, % STREAMING, LATENCY(P50/P99) 같은 통계를 한눈에 봅니다.
트레이스 뷰 — 네 가지 항목을 읽는다
구동이 끝난 항목을 클릭하면 트레이스 뷰(trace view) 로 들어갑니다. 여기서는 에이전트가 수행한 모든 단계와 각 단계에 들어간 agent, tools, get_tax_base, get_market_value_rate, get_tax_deduction 등이 계층적으로 표시되어, 단계가 순차적 또는 병렬로 실행되는 과정을 시각화해 보여줍니다.
주목해야 할 항목은 넷입니다.
15.1 Input(입력)
에이전트나 도구에 전달되는 입력 데이터입니다. 사용자의 원본 질문뿐 아니라 함수 실행에 전달되는 입력 파라미터도 확인할 수 있어, 에이전트가 어떤 정보를 기반으로 판단하고 있는지 파악할 수 있습니다.
여기서 확인되는 것이 흥미롭습니다. get_tax_deduction 도구의 Input을 보면 이렇게 들어가 있습니다.
{"question": "내가 10억짜리 집을 2채 가지고 있다면 공제액은 얼마인가요?"}
에이전트가 원래 질문을 ‘내가 10억짜리 집을 2채 가지고 있다면 공제액은 얼마인가요?’ 와 같이 도구의 목적에 맞게 변경해 질문하는 것을 볼 수 있습니다. 이는 에이전트가 얼마나 지능적으로 도구를 활용하는지 보여주는 중요한 지표입니다.
12장에서 stream 출력으로 확인했던 “LLM이 도구마다 질문을 스스로 바꿔 만든다”는 동작이, LangSmith에서는 모든 실행에 대해 기록으로 남는다는 차이가 있습니다.
15.2 Output(출력)
각 단계에서 생성된 결과물과 최종적으로 에이전트가 생성한 답변을 봅니다. get_tax_deduction의 출력은 9억 원입니다.
도구별 출력을 살펴보면 에이전트가 계산에 필요한 정보를 올바르게 수정했는지 평가할 수 있습니다. 도구 호출을 올바른 경로로 했는지, 그리고 이름 기반으로 어떤 도구가 응답했는지 추적할 수 있어, 출력 데이터를 분석하면 에이전트의 추론 과정에서 발생한 오류나 개선 가능성을 발견할 수 있습니다.
15.3 TOTAL TOKENS(토큰 사용량)
12,789 tokens / $0.02659475 같은 값이 표시됩니다. 해당 요청에서 사용된 총 토큰 수와 그에 따른 비용을 나타냅니다.
이 항목의 진짜 값어치는 자동화입니다.
LangSmith는 각 LLM 제공업체의 API 응답에 포함된 토큰 사용량을 자동으로 기록하기 때문에, 개발자가 별도의 토큰 계산 로직을 작성할 필요가 없습니다.
모델별로 토큰을 세는 방식이 다릅니다. GPT-4는 tiktoken을, Claude는 자체 토크나이저를 쓰는데 LangSmith가 이를 대신 파싱합니다. 9장에서 tiktoken이 OpenAI 전용이라 다른 모델에 쓰면 오류가 난다고 했던 문제가, 여기서는 플랫폼이 흡수합니다.
또한 입력 프롬프트 토큰과 출력 토큰을 구분해 표시하므로 비용 구조를 더 상세히 분석할 수 있습니다. 8장에서 손으로 usage_metadata를 뒤져 계산했던 그 값들입니다.
예를 들어 특정 도구가 불필요하게 많은 토큰을 소비한다면, 해당 도구의 프롬프트나 실행 방식을 개선해서 비용을 절감할 수 있습니다.
15.4 LATENCY(지연 시간)
18.11s 같은 값입니다. 전체 요청을 처리하는 데 소요된 시간으로, 사용자 경험에 직접적인 영향을 미치는 중요한 지표입니다. 지연 시간이 길면 사용자 만족도가 떨어지므로 지연이 발생하는 지점을 식별하고 최적화할 필요가 있습니다.
단계별 소요 시간도 볼 수 있습니다.
agent 1.76s
tools 3.70s
get_tax_deduction 3.70s ← 병목
get_house_tax 9.09s
그림 15-11을 보면
get_tax_deduction단계에서 3.70초가 소요되는 것을 확인할 수 있는데, 이는 전체 지연 시간에 상당한 영향을 주는 지점이라고 해석할 수 있습니다. 이러한 정보를 바탕으로 최적화가 필요한 지점을 식별하고 개선할 수 있습니다.
15.5 LangSmith를 활용한 에이전트 평가
LangSmith는 모니터링 외에도 LLM 기반 애플리케이션의 평가(evaluation) 에서 핵심적인 역할을 합니다. 실행 과정을 추적하는 것을 넘어, 에이전트의 출력 품질을 체계적으로 평가하고 개선하는 데 필수적입니다.
| 기능 | 내용 |
|---|---|
| LLM Judge 패턴 | 가장 큰 장점. LangChain 허브에는 이미 검증된 평가 프롬프트(relevance, 정확성 등)가 준비되어 있어, 개발자가 평가 체계를 처음부터 구축할 필요 없이 신뢰성 높은 평가 프레임워크를 바로 활용할 수 있다 |
| 평가 결과 기록과 분석 | 시간에 따른 성능 변화를 일관되게 측정할 수 있다. 특히 프롬프트가 변경되었을 때 성능 저하가 없는지 객관적으로 평가할 수 있다 |
| Human-in-the-loop + 자동화 | 사람 평가자의 피드백을 수집·관리하는 인터페이스를 제공하면서도 자동화된 평가를 동시에 수행한다. 주관적 평가와 객관적 평가의 균형 덕분에 대규모 에이전트 시스템에서 일관성과 효율성을 함께 확보할 수 있다 |
| 대규모 실험과 비교 분석 | 서로 다른 프롬프트·모델·하이퍼파라미터를 사용한 여러 버전의 에이전트를 동일한 기준으로 평가·비교할 수 있다. A/B 테스트 기반의 점진적 개선을 가능하게 한다 |
| 결과 시각화 | 복잡한 평가 데이터를 직관적으로 이해하게 해준다. 개발팀뿐 아니라 비기술적 이해관계자에게도 성능과 개선 방향을 명확히 전달하는 데 도움이 된다 |
책은 15장을 이렇게 닫습니다.
이러한 LangSmith의 평가 기능은 4부에서 더 자세히 다룰 예정입니다. 다양한 평가 지표, 골든 데이터셋 구축 방법, 실제 LangSmith를 활용한 평가 구현 사례까지 심층적으로 살펴볼 것입니다.
정리
- 에이전트의 예측 불가능성은 관측으로 다룬다. LangSmith는 노드 실행·도구 호출·프롬프트·상태 변화를 전부 기록한다.
- 연동은 환경변수 다섯 줄이다. 코드를 고칠 필요가 없다.
- 트레이스 뷰에서 읽을 것은 Input / Output / TOTAL TOKENS / LATENCY 네 가지다.
- Input을 보면 에이전트가 도구마다 질문을 어떻게 바꿔 넣었는지 드러난다. 도구를 지능적으로 쓰는지 보는 지표다.
- 토큰 계산은 플랫폼이 대신한다. 모델마다 다른 토크나이저를 신경 쓰지 않아도 되고, 입력·출력 토큰이 나뉘어 나온다.
- LATENCY는 단계별로 본다. 어느 도구가 병목인지 숫자로 나온다.
- 평가에서는 LLM Judge 프롬프트를 허브에서 가져다 쓰는 것이 출발점이다. 프롬프트를 바꿨을 때 성능이 떨어지지 않았는지 객관적으로 확인할 수 있다.