LangSmith Bring Your Own Cloud (BYOC)가 이제 AWS(GA), Azure(Beta), Google Cloud(Beta)에서 실행됩니다. 사용자의 트레이스(traces), 평가(evals), 데이터셋(datasets), 프롬프트(prompts), 에이전트 배포(agent deployments)는 선택한 자체 클라우드 계정에 유지되며, LangChain은 오케스트레이션 및 스케일링부터 플랫폼 업데이트까지 데이터 플레인(data plane)을 관리해 줍니다.
BYOC가 LangSmith를 분리하는 방식
사용자가 직접 LangSmith를 운영하는 수고 없이 에이전트가 실행되는 위치와 텔레메트리(telemetry)가 저장되는 위치를 결정할 수 있습니다. 이를 가능하게 하기 위해 BYOC는 LangSmith를 두 부분으로 분리합니다. LangChain은 인증(auth), 조직 및 워크스페이스 구성(org and workspace config), 결제 메타데이터(billing metadata), 해시된 API 키(hashed API keys), 정적 UI 에셋을 포함하는 제어 플레인(control plane)을 운영합니다. 사용자는 트레이스, 프롬프트, 데이터셋부터 실험(experiments), 에이전트 배포, 워크스페이스 비밀(workspace secrets)에 이르기까지 모든 민감한 정보를 담는 데이터 플레인(data plane)을 소유하게 됩니다.
하나의 조직은 여러 개의 데이터 플레인을 가질 수 있으며, 각 데이터 플레인은 특정 계정과 리전(region)에 위치하고 자체 워크스페이스를 보유합니다. 이를 통해 지역, 환경 또는 사업 단위별로 데이터 플레인을 분리할 수 있습니다.
예를 들어, 플랫폼 팀은 프로덕션(production) 및 스테이징(staging) 데이터 플레인을 별도의 AWS 계정에서 운영할 수 있으며, Azure를 표준화한 사업 단위는 자체적이고 분리된 BYOC 배포를 Azure에서 실행할 수 있습니다. 각 팀의 트레이스는 해당 팀이 소유한 계정에 저장됩니다.
BYOC를 구축한 이유
지금까지는 엄격한 규정 준수 경계(compliance boundaries)를 가진 팀들이 자체 호스팅(self-hosted) LangSmith를 배포하고 유지 관리해 왔습니다. 이는 데이터를 자체 경계 내에 보관했지만, 상태 저장 서비스(stateful services) 패치, 데이터베이스 구성, 스키마 마이그레이션(schema migrations)을 수행하기 위해 전담 플랫폼 엔지니어들이 필요했습니다.
BYOC를 사용하면 LangChain이 자체 가상 네트워크(virtual network) 내부에 LangSmith를 프로비저닝하고 운영합니다. 여러 환경에 걸쳐 에이전트 애플리케이션을 실행하는 팀을 가정해 봅시다. 자체 호스팅 방식에서는 실행 구성 요소(execution components)의 모든 업데이트가 각 환경에서 다운타임을 조정하고 사용자 지정 Helm 롤아웃(custom Helm rollouts)을 관리해야 함을 의미했습니다. BYOC를 사용하면 데이터 플레인의 데이터는 VPC 내에 유지되는 동안 LangChain이 스케일링, 스키마 업데이트 및 런타임 종속성(runtime dependencies)을 처리합니다.
AWS 고객들이 경험한 내용
BYOC를 AWS에서 출시한 이후, 많은 팀이 BYOC를 통해 자체 클라우드에 LangSmith를 운영하기로 선택했습니다. 그들은 세 가지 주요 이점을 언급합니다:
지속적인 업그레이드. LangChain은 플랫폼 업데이트를 배포하므로, 팀들은 더 이상 유지보수 기간을 계획하거나 Helm 업그레이드를 관리할 필요가 없습니다.
최신 LangSmith 기능. 새로운 기능들은 LangSmith Cloud에서 출시된 직후 BYOC 데이터 플레인에 곧 도달하며, 다음 자체 호스팅 릴리스를 기다릴 필요가 없습니다.
자동 확장(Automatic scaling). 서비스는 부하에 따라 확장되므로, 사용량이 증가함에 따라 팀들은 일관된 가동 시간과 원활한 경험을 얻습니다.
이러한 수요 때문에 저희는 Azure와 Google Cloud에도 BYOC를 빠르게 도입하여, 팀들이 어떤 클라우드를 운영하든 동일한 경험에 접근할 수 있도록 했습니다.
각 클라우드별 BYOC 구현 방식
각 클라우드는 자체 네트워크 정책, ID 모델 및 보안 요구 사항을 가지고 있으므로, BYOC는 각 클라우드의 고유 빌딩 블록으로 구축됩니다. 세 가지 클라우드 모두에서 BYOC 데이터 플레인은 Managed Deep Agents 엔드포인트를 실행합니다.
Azure: BYOC는 전용 가상 네트워크 내부에 데이터 플레인을 운영하며 비공개 AKS API 엔드포인트를 사용합니다. 저희는 Ingress 라우팅 및 이벤트 기반 확장을 위해 Istio와 KEDA를 Helm으로 배포하고, 시스템 텔레메트리는 Azure Monitor로 전송됩니다. Azure용 LangSmith Sandboxes 지원이 곧 제공될 예정입니다.
LangSmith Data Planes settings page listing two Azure BYOC data planes
Google Cloud: 출시 당시 Google Cloud 데이터 플레인은 모든 리전에서 운영할 수 있으며 LangSmith의 US 제어 평면(control plane)에서 관리됩니다. 리소스는 네임스페이스 범위 이름(namespace-scoped names)을 사용하므로 기존 인프라와 충돌하지 않습니다.
AWS: BYOC는 기존 VPC 내부에 운영되며, 데이터베이스는 사용자가 선택한 서브넷에 위치합니다. 보안 팀은 각 애플리케이션 역할에 자체 보안 그룹을 연결할 수 있으므로, 데이터 플레인은 이미 실행 중인 Ingress 및 Egress 검사 정책에 맞게 구성됩니다.
처음부터 다시 시작하지 않고 자체 호스팅 환경에서 이전하기
자체 호스팅(Self-hosted) LangSmith는 데이터가 저장되는 위치에 대한 완전한 제어권을 제공했지만, 상당한 유지보수 오버헤드가 필요했습니다. BYOC(Bring Your Own Control) 방식은 데이터를 고객님의 계정에 보관하고 저희가 인프라를 운영하며, 기존의 자체 호스팅된 데이터도 가져올 수 있습니다.
이 이동 과정은 두 부분으로 나뉩니다. 워크스페이스 리소스는 오픈 소스 마이그레이션 도구를 통해 이동하며, 이 도구는 자체 호스팅 인스턴스에서 데이터를 읽어오면서도 이동하는 동안 해당 인스턴스를 손대지 않고 활성 상태로 유지합니다. 모든 클라우드 환경에서 사용자 및 역할(users and roles), 데이터셋(datasets), 실험(experiments), 프롬프트(prompts)를 포함합니다. 또한 주석 큐 구성(annotation queue config), 자동화 규칙(automation rules), 대시보드(dashboards), 플릿 리소스(Fleet resources)도 함께 가져옵니다.
트레이스(traces), 실행 기록(runs), 피드백은 LangChain이 내부 도구(internal tooling)를 사용하여 별도의 단계로 이동시킵니다. 트레이스 마이그레이션은 오늘 AWS에서 이용 가능합니다.
LangChain과 LangGraph는 오픈 소스입니다. BYOC의 기반이 되는 Terraform 모듈은 github.com/langchain-ai/terraform에서 공개되어 있으며, 마이그레이션 도구 역시 마찬가지입니다. 데이터 플레인에 있는 LLM Gateway는 기본적으로 11개 제공업체(providers)의 모델을 호출하며, OpenAI 또는 Anthropic과 호환되는 모든 엔드포인트도 지원하므로 클라우드는 물론 그 뒤의 모델 제공업체도 선택할 수 있습니다.
시작하기
AWS, Azure 또는 Google Cloud에서 BYOC 데이터 플레인을 프로비저닝하려면 영업팀에 문의하십시오. 문서는 아키텍처, 공유 책임 모델(shared responsibility model), 마이그레이션, 사용법, FAQ의 일반 질문 등을 다루며, API 레퍼런스에는 Create Data Plane API가 포함되어 있습니다.
