Monte Carlo: Building Data + AI Observability Agents with LangGraph and LangSmith
Quick Summary
Monte Carlo는 LangGraph와 LangSmith를 활용해 기업 데이터 품질 사고를 병렬로 조사하고 근본 원인 분석을 빠르게 수행하는 데이터·AI 관측성 에이전트를 구축했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Monte Carlo는 LangGraph와 LangSmith를 활용해 기업 데이터 품질 사고를 병렬로 조사하고 근본 원인 분석을 빠르게 수행하는 데이터·AI 관측성 에이전트를 구축했다.
📌 핵심 요약
- Monte Carlo는 기존 데이터 모니터링·트러블슈팅 도구 경험을 바탕으로, 데이터 이슈를 조사하는 수백 개의 하위 에이전트를 실행할 수 있는 AI Troubleshooting Agent를 만들었다.
- 대기업 데이터 엔지니어들은 실패한 작업, 코드 변경, 의존성 문제를 순차적으로 추적하느라 많은 시간을 쓰며, 이 과정에서 병렬 원인이나 복잡한 연결 관계를 놓칠 수 있다.
- Monte Carlo는 LangGraph를 선택해 알림 발생 후 코드 변경 확인, 타임라인 분석, 의존성 조사, 결과 보고로 이어지는 조사 흐름을 그래프 기반으로 모델링했다.
- LangSmith는 개발 첫날부터 그래프 기반 워크플로를 시각화하고 프롬프트를 빠르게 반복 개선하는 데 쓰였으며, 팀이 도구 설정보다 에이전트 로직과 고객 문제 해결에 집중하도록 도왔다.
- Monte Carlo는 현재 추적 내 버그 위치를 더 잘 파악하고 검증 시나리오와 피드백 메커니즘을 강화해, 에이전트가 실제로 근본 원인을 식별하는지 측정하려 한다.
🧩 주요 포인트
- Monte Carlo는 기존 데이터 모니터링·트러블슈팅 도구 경험을 바탕으로, 데이터 이슈를 조사하는 수백 개의 하위 에이전트를 실행할 수 있는 AI Troubleshooting Agent를 만들었다.
- 대기업 데이터 엔지니어들은 실패한 작업, 코드 변경, 의존성 문제를 순차적으로 추적하느라 많은 시간을 쓰며, 이 과정에서 병렬 원인이나 복잡한 연결 관계를 놓칠 수 있다.
- Monte Carlo는 LangGraph를 선택해 알림 발생 후 코드 변경 확인, 타임라인 분석, 의존성 조사, 결과 보고로 이어지는 조사 흐름을 그래프 기반으로 모델링했다.
- LangSmith는 개발 첫날부터 그래프 기반 워크플로를 시각화하고 프롬프트를 빠르게 반복 개선하는 데 쓰였으며, 팀이 도구 설정보다 에이전트 로직과 고객 문제 해결에 집중하도록 도왔다.
- Monte Carlo는 현재 추적 내 버그 위치를 더 잘 파악하고 검증 시나리오와 피드백 메커니즘을 강화해, 에이전트가 실제로 근본 원인을 식별하는지 측정하려 한다.
🧠 상세 정리
1. 기업 데이터 트러블슈팅의 병목
Monte Carlo는 기업용 데이터·AI 관측성 플랫폼으로, 조직이 데이터와 AI 신뢰성 문제를 모니터링하고 이를 근본 원인까지 추적하도록 돕는다. 원문은 대기업 데이터 엔지니어들이 데이터 알림을 수동으로 조사하는 데 많은 시간을 쓰는 현실에서 출발한다. 실패한 작업을 확인하고, 최근 코드 변경을 추적하며, 문제가 즉시 해결되어야 하는지 또는 우선순위를 낮출 수 있는지 판단하는 과정이 순차적으로 진행되기 때문이다. 이러한 방식은 복잡하게 연결된 데이터 시스템에서 여러 원인을 동시에 보지 못하게 만들고, 근본 원인 식별을 지연시킬 수 있다.
2. 데이터 다운타임을 줄이려는 기회
Monte Carlo의 고객은 주로 데이터가 큰 매출과 직접 연결되는 대기업이며, 잘못되거나 사용할 수 없는 데이터는 수백만 달러 규모의 비즈니스 영향으로 이어질 수 있다. 회사는 이미 포괄적인 트러블슈팅 도구를 갖추고 있었지만, 데이터 다운타임을 더 줄일 방법을 찾았다. 핵심 아이디어는 AI 에이전트가 수백 개의 가설을 동시에 처리하고 추론하게 하여 데이터 품질 사고의 실제 원인을 더 빨리 찾게 하는 것이다. 이 접근은 기존 도구를 대체하기보다, 오랜 기간 축적된 모니터링과 조사 역량 위에 자동화된 병렬 분석 계층을 얹는 방식으로 제시된다.
3. LangGraph로 구현한 다중 경로 조사
Monte Carlo는 조사 프로세스가 자연스럽게 그래프 기반 의사결정 흐름과 맞아떨어졌기 때문에 AI Troubleshooting Agent의 기반으로 LangGraph를 선택했다. 알림이 발생하면 시스템은 코드 변경 확인, 타임라인 분석, 의존성 조사, 결과 보고로 이어지는 구조화된 절차를 따른다. 각 조사 노드는 발견한 내용에 따라 하위 노드를 만들 수 있어, 최근 7일간의 코드 변경, 특정 데이터 파이프라인에 영향을 준 변경, 문제 발생 몇 시간 전의 이벤트 등을 함께 살펴볼 수 있다. 이 구조의 장점은 사람이 한 번에 한 경로를 따라가는 것과 달리, 에이전트가 여러 조사 분기를 병렬로 탐색한다는 점이다.
4. 출시 속도와 고객 시연의 현실적 가치
원문은 LangGraph의 기술적 적합성뿐 아니라 제품 개발 속도도 중요한 가치였다고 설명한다. Monte Carlo의 제품 매니저 Bryce Heltzel은 주요 업계 서밋을 앞두고 4주라는 촉박한 일정 안에서 고객에게 에이전트를 자신 있게 보여줄 수 있었던 점을 강조한다. 자체 솔루션을 처음부터 만들었다면 같은 기간 안에 데모 가능한 수준까지 도달하기 어려웠을 것이라는 맥락이다. 따라서 LangGraph는 단순한 실행 프레임워크가 아니라, 기존 문제 해결 흐름을 빠르게 에이전트 구조로 옮기고 시장 검증까지 연결하게 한 기반으로 다뤄진다.
5. LangSmith를 통한 디버깅과 프롬프트 반복
Monte Carlo는 개발 첫날부터 LangSmith를 사용해 LangGraph로 만든 그래프 기반 워크플로를 시각화하고 디버깅했다. Heltzel은 LangGraph로 에이전트를 만들기 시작하면서 개발 중인 워크플로를 볼 수 있는 도구가 필요했고, LangSmith가 자연스러운 선택이었다고 설명한다. 특히 그는 제품 매니저로서 고객 사용 사례에 대한 깊은 맥락을 바탕으로 프롬프트 엔지니어링에도 직접 관여한다. LangSmith 덕분에 엔지니어링 사이클을 매번 거치지 않고 프롬프트를 빠르게 수정·반복할 수 있었고, 팀은 도구 설정보다 에이전트 로직과 고객 데이터 문제 해결에 더 집중할 수 있었다.
6. 아키텍처와 향후 검증 과제
원문은 Monte Carlo의 아키텍처가 기존 모놀리식 플랫폼과 새로운 AI Agent 스택을 연결하는 확장 가능하고 분리된 구조라고 설명한다. 인증은 Auth Gateway Lambda가 맡고, Monolith Service는 GraphQL과 REST 기반 핵심 API 및 Amazon RDS의 애플리케이션 데이터를 계속 담당한다. AI Agent Service는 Amazon ECS Fargate에서 실행되며, 네트워크 로드 밸런서를 통해 트래픽을 분산하고 컨테이너화된 마이크로서비스가 확장되도록 구성되어 있다. 앞으로 Monte Carlo는 추적에서 버그가 발생하는 위치를 더 잘 파악하고, 각 조사에서 에이전트가 근본 원인을 성공적으로 식별했는지 측정하는 검증 시나리오와 피드백 메커니즘을 강화하는 데 집중하고 있다.
🧾 핵심 주장 / 시사점
- 데이터 품질 사고 대응에서 핵심 병목은 단순한 모니터링 부족이 아니라, 여러 원인 후보를 순차적으로만 조사해야 하는 운영 방식에 있다.
- LangGraph의 가치는 복잡한 조사 절차를 그래프와 병렬 분기로 표현해, 숙련된 데이터 엔지니어의 사고방식을 더 큰 규모로 실행하게 만드는 데 있다.
- LangSmith는 에이전트의 실행 흐름을 관찰하고 프롬프트를 반복 개선하게 해, 제품 담당자와 엔지니어가 고객 문제 해결 중심으로 빠르게 협업하도록 만든다.
✅ 액션 아이템
- 알림이 들어온 뒤 코드 변경 확인, 타임라인 분석, 의존성 조사, 결과 보고를 잇는 LangGraph 기반 흐름을 재현해 병렬 에이전트 탐색력을 검증한다.
- LangSmith로 그래프 기반 워크플로를 지속 시각화해 프롬프트 반복 개선 속도를 높이고 에이전트 로직 집중도를 유지한다.
- 추적 내 버그 위치 정합성, 검증 시나리오 적합도, 피드백 반영 속도 지표를 정의해 근본 원인 식별 성공 여부를 정량 측정한다.
❓ 열린 질문
- 어떤 기준으로 하위 에이전트 병렬 탐색 범위를 정해야 실패 작업·코드 변경·의존성 간의 잠재적 연결을 놓치지 않을까?
- 알림→코드 변경 확인→타임라인 분석→의존성 조사 순서에서 어느 단계가 병목을 만들면 탐색 정확도를 가장 빠르게 잃게 될까?
- 근본 원인 식별을 판단하려면 어떤 피드백 메커니즘과 검증 시나리오 조합이 버그 위치 추적 성능을 신뢰성 있게 입증할 수 있을까?