LangSmith BYOC is now available on AWS, Azure, and Google Cloud

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangSmith BYOC가 AWS 정식 출시(GA), Azure·Google Cloud 베타로 제공되며, 고객 클라우드 계정에 민감 데이터를 유지하면서 LangChain이 데이터 플레인 운영을 맡는다.

📌 핵심 요약

• LangSmith BYOC는 AWS(GA), Azure(Beta), Google Cloud(Beta)를 지원하며, 트레이스·평가·데이터셋·프롬프트·에이전트 배포를 고객의 클라우드 계정에 유지한다.
• LangChain은 인증·조직 및 워크스페이스 설정·과금 메타데이터 등을 담는 컨트롤 플레인을 운영하고, 고객은 민감 데이터를 담는 데이터 플레인을 소유한다. 한 조직은 계정·리전별로 여러 데이터 플레인을 구성할 수 있다.
• BYOC에서는 LangChain이 프로비저닝·확장·플랫폼 및 스키마 업데이트를 담당한다. AWS 이용 팀들은 지속적인 업그레이드, LangSmith Cloud 출시 직후의 새 기능 제공, 자동 확장을 주요 이점으로 꼽았으며, 완전한 통제가 필요한 고객에게는 self-hosted도 계속 제공된다.
• Azure는 전용 가상 네트워크와 비공개 AKS API 엔드포인트를 사용하며 LangSmith Sandboxes 지원은 예정돼 있다. Google Cloud는 출시 시 모든 리전에서 데이터 플레인을 실행할 수 있지만 미국 컨트롤 플레인에서 관리되며, AWS는 기존 VPC와 고객이 선택한 데이터베이스 서브넷을 활용한다.
• self-hosted 이전은 BYOC 데이터 플레인 프로비저닝 후 오픈소스 migration tool로 워크스페이스 리소스를 옮기는 순서다. 이 도구는 원본 인스턴스의 중단이나 데이터 변경을 일으키지 않으며, 트레이스·실행·피드백은 LangChain이 별도로 이전하고 트레이스 이전은 현재 AWS에서 제공된다.

🧩 주요 포인트

1. 컨트롤 플레인과 데이터 플레인의 분리 → 민감 데이터의 저장 위치를 고객이 정하면서 LangSmith 운영 부담을 LangChain에 맡길 수 있고, 컨트롤 플레인에 남는 정보의 범위도 함께 고려해야 한다.
2. 공통 LangSmith 기능과 클라우드별 구현·출시 단계의 차이 → AWS(GA), Azure(Beta), Google Cloud(Beta)를 비교할 때 네트워크 구성, 미국 컨트롤 플레인 관리 여부, 예정 기능을 함께 살펴야 한다.
3. 워크스페이스 리소스와 트레이스·실행·피드백의 분리 이전 → 기존 self-hosted 데이터를 활용할 수 있지만, 현재 AWS에서 제공되는 트레이스 이전과 다른 리소스 이전의 지원 범위를 구분해야 한다.

🧠 상세 정리

1. 3개 클라우드로 확대된 BYOC와 데이터 소유 구조

2026년 11월 3일 발표에 따르면 LangSmith Bring Your Own Cloud(BYOC)는 AWS에서 정식 출시(GA), Azure와 Google Cloud에서는 베타로 제공된다. 트레이스, 평가, 데이터셋, 프롬프트, 에이전트 배포는 고객이 선택한 클라우드 계정에 남고, LangChain이 데이터 플레인의 오케스트레이션과 확장, 플랫폼 업데이트를 담당한다. 컨트롤 플레인은 LangChain이 운영하며 인증, 조직·워크스페이스 설정, 과금 메타데이터, 해시 처리된 API 키, 정적 UI 자산을 보관한다. 고객이 소유하는 데이터 플레인에는 트레이스와 프롬프트뿐 아니라 실험, 에이전트 배포, 워크스페이스 비밀정보 등 민감한 항목이 담긴다. 한 조직은 계정과 리전이 다른 여러 데이터 플레인을 두고 각 데이터 플레인에 워크스페이스를 배치해, 리전·환경·사업부별로 데이터를 분리할 수 있다.

2. self-hosted의 운영 부담을 줄이려는 목적

원문은 엄격한 규정 준수 경계를 가진 팀들이 그동안 self-hosted LangSmith를 배포하고 유지해 왔다고 설명한다. 이 방식은 데이터를 자체 경계 안에 보관하지만, 상태 저장 서비스 패치와 데이터베이스 구성, 스키마 마이그레이션을 맡을 전담 플랫폼 엔지니어가 필요했다. 여러 환경에서 에이전트 애플리케이션을 운영할 경우 실행 구성요소를 업데이트할 때마다 중단 시간을 조율하고 환경별 맞춤 Helm 배포를 관리해야 하는 부담도 있었다. BYOC에서는 LangChain이 고객의 가상 네트워크 안에 LangSmith를 프로비저닝하고 운영하므로, 데이터는 VPC에 유지하면서 확장과 스키마 업데이트, 런타임 의존성 관리를 맡길 수 있다. 다만 원문은 self-hosted 역시 완전한 통제가 필요한 고객에게 신뢰할 수 있는 선택지로 유지되며, 배포 방식의 선택은 개별 요구에 달려 있다고 명시한다.

3. AWS 이용 경험과 클라우드 공통 기능

LangChain은 8월 AWS BYOC 출시 이후 이용 팀들이 지속적인 업그레이드, 최신 기능 제공, 자동 확장을 주요 이점으로 꼽았다고 전한다. 플랫폼 업데이트를 LangChain이 배포하므로 팀이 유지보수 시간이나 Helm 업그레이드를 직접 관리할 필요가 줄고, 새 기능은 다음 self-hosted 릴리스를 기다리지 않고 LangSmith Cloud 출시 후 곧 BYOC 데이터 플레인에 도달한다는 설명이다. 서비스가 부하에 따라 확장해 사용량 증가에도 안정적인 가동과 원활한 사용 경험을 제공한다는 점도 제시한다. 클라우드 전반에서 트레이스, 실행 경로, 평가, 인사이트와 자체 제공업체 키를 사용할 수 있는 LLM Gateway는 데이터 플레인에서 실행되며, LangSmith 배포는 고객 클러스터에서 동작한다. Engine은 고객 데이터와 고객이 선택한 모델 제공업체를 사용하며, 세 클라우드의 BYOC 데이터 플레인 모두 Managed Deep Agents 엔드포인트를 실행한다.

4. Azure·Google Cloud·AWS의 구현과 제약

BYOC는 공통 LangSmith 경험을 제공하면서도 각 클라우드의 네트워크 정책, ID 모델, 보안 요구에 맞는 기본 구성요소로 구현된다. Azure에서는 전용 가상 네트워크와 비공개 AKS API 엔드포인트를 사용하고, Helm으로 배포하는 Istio와 KEDA가 인그레스 라우팅과 이벤트 기반 확장을 담당하며 시스템 텔레메트리는 Azure Monitor로 전송된다. Azure의 LangSmith Sandboxes 지원은 현재 제공 기능이 아니라 향후 지원 예정으로 안내된다. Google Cloud 데이터 플레인은 출시 시 모든 리전에서 실행할 수 있지만 LangSmith의 미국 컨트롤 플레인에서 관리되며, 리소스 이름은 네임스페이스 범위로 지정해 기존 인프라와의 이름 충돌을 피한다. AWS에서는 기존 VPC 내부에서 실행하고 고객이 선택한 서브넷에 데이터베이스를 배치하며, 보안팀이 애플리케이션 역할별 보안 그룹을 연결해 기존 인그레스·이그레스 검사 정책에 맞출 수 있다.

5. 기존 데이터를 활용하는 단계별 이전

self-hosted에서 BYOC로 옮길 때는 먼저 BYOC 데이터 플레인을 프로비저닝하고, 이어 오픈소스 migration tool로 워크스페이스 리소스를 이전한다. 이 도구는 기존 self-hosted 인스턴스에서 데이터를 읽지만 해당 인스턴스의 중단이나 데이터 변경을 일으키지 않는다고 설명된다. 모든 지원 클라우드에서 사용자와 역할, 데이터셋, 실험, 프롬프트를 옮길 수 있으며, 주석 작업 대기열 설정과 자동화 규칙, 대시보드도 이전 대상에 포함된다. 트레이스, 실행, 피드백은 이 작업과 별개로 LangChain이 내부 도구를 사용해 이전하며, 트레이스 이전은 현재 AWS에서 제공된다. 따라서 원문이 설명하는 이전은 모든 데이터를 단일 도구로 한 번에 옮기는 과정이 아니라, 워크스페이스 리소스 이전과 LangChain이 수행하는 별도 데이터 이전으로 구성된다.

6. 개방형 플랫폼 구성과 도입 경로

원문은 LangSmith를 공급업체 종속 없이 에이전트를 구축하고 실행할 수 있는 개방적이고 유연한 플랫폼으로 제시한다. LangChain, LangGraph, Deep Agents 같은 오픈소스 프레임워크를 사용하면서 데이터와 모델, 인프라의 소유권을 유지할 수 있다는 설명이다. LLM Gateway는 기본적으로 11개 모델 제공업체와 연결되며, OpenAI 또는 Anthropic 호환 엔드포인트도 지원한다. 이번 확장으로 BYOC는 AWS, Azure, Google Cloud에서 제공되고, github.com/langchain-ai/terraform에 공개된 Terraform 모듈과 오픈소스 이전 도구를 활용한다. 도입을 위해서는 영업팀에 연락해 데이터 플레인을 프로비저닝하도록 안내하며, 문서에는 아키텍처, 공동 책임 모델, 이전, 사용법, FAQ가 있고 API 레퍼런스에는 Create Data Plane API가 포함돼 있다.

🧾 핵심 주장 / 시사점

• BYOC의 핵심은 데이터 소유와 운영 책임의 분리다. 민감 데이터는 고객 계정에 유지하지만 인증·설정·과금 관련 정보는 LangChain의 컨트롤 플레인에 있으므로, 데이터 경계는 정보 유형별로 이해해야 한다.
• 세 클라우드에서 공통 기능을 제공한다는 설명이 출시 단계와 세부 지원 범위까지 같다는 뜻은 아니다. Azure의 예정 기능과 Google Cloud의 미국 컨트롤 플레인 관리 조건은 클라우드 선택에 영향을 줄 수 있다.
• 기존 self-hosted 데이터를 활용할 수 있어 이전 시 처음부터 다시 구성할 필요는 줄어들지만, 워크스페이스 리소스와 트레이스·실행·피드백의 이전 경로가 달라 전체 이전 가능 범위를 따로 판단해야 한다.

✅ 액션 아이템

• AWS(GA), Azure(Beta), Google Cloud(Beta)의 출시 단계와 네트워크 구성, 미국 컨트롤 플레인 관리 여부를 기준으로 클라우드 적합성 검토.
• self-hosted의 완전한 통제 요구와 LangChain이 제공하는 BYOC 프로비저닝·확장·업데이트 운영 범위를 비교해 배포 방식 평가.
• 오픈소스 migration tool의 워크스페이스 리소스 이전 범위와 현재 AWS에서 제공되는 트레이스 이전을 구분해 기존 데이터 이전 가능 범위 확인.

❓ 열린 질문

• Google Cloud 데이터 플레인이 미국 컨트롤 플레인에서 관리되는 조건은 필요한 데이터 경계에 부합하는가?
• Azure(Beta)의 LangSmith Sandboxes 지원이 예정 단계라는 점은 클라우드 선택에 어떤 영향을 주는가?
• 현재 AWS에서 제공되는 트레이스 이전과 별도로 수행되는 트레이스·실행·피드백 이전은 self-hosted 전환 요구를 충족하는가?