Articlelangchain.com·2026년 7월 7일·0

How Schneider Electric Built Their LLMOps Foundations With LangSmith

Quick Summary

Schneider Electric은 LangSmith를 중심으로 관측성·평가·배포의 세 축을 갖춘 LLMOps 기반을 구축해, 엄격한 보안과 데이터 통제 아래 60개 이상의 AI 제품과 에이전트를 엔터프라이즈 규모로 운영하고 있다.

How Schneider Electric Built Their LLMOps Foundations With LangSmith 관련 대표 이미지

🖼️ 인포그래픽

How Schneider Electric Built Their LLMOps Foundations With LangSmith 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

How Schneider Electric Built Their LLMOps Foundations With LangSmith 내용을 설명하는 본문 이미지

💡 한 줄 요약

Schneider Electric은 LangSmith를 중심으로 관측성·평가·배포의 세 축을 갖춘 LLMOps 기반을 구축해, 엄격한 보안과 데이터 통제 아래 60개 이상의 AI 제품과 에이전트를 엔터프라이즈 규모로 운영하고 있다.

📌 핵심 요약

  • Schneider Electric은 16만 명의 직원과 연 매출 약 400억 유로 규모의 글로벌 에너지 기술 기업으로, 350명의 전문가가 속한 내부 AI Hub를 통해 60개 이상의 에이전트를 개발·운영하고 있다.
  • 회사의 AI 활용은 제품 내 지능 탑재, 전력 수요·생산 예측, 운영 마찰을 줄이는 에이전트형 코파일럿 등으로 나뉘며, 모두 중요 인프라 환경에서 데이터 거주성·사이버보안·품질 통제가 요구된다.
  • 기존 MLOps 방식만으로는 LLM 기반 시스템의 비결정적 동작, 프롬프트·모델 변경 효과 측정, 프로덕션 준비성 검증을 충분히 다루기 어려워 별도의 LLMOps 체계가 필요했다.
  • Schneider의 AI Platform 팀은 LangSmith를 중심으로 관측성, 평가, 배포라는 세 가지 축을 정립하고, 제품별 워크스페이스·평가 데이터셋·SME 주석·성숙도 프레임워크를 운영 루프에 연결했다.
  • One Jo, Customer Success Management Copilot, Digital Energy 문서 처리 에이전트 사례를 통해 실제 운영 추적, 오프라인·온라인 평가, 장기 실행 작업 큐, 제품별 런타임 분리의 효과와 비용을 함께 보여준다.

🧩 주요 포인트

  1. Schneider Electric은 16만 명의 직원과 연 매출 약 400억 유로 규모의 글로벌 에너지 기술 기업으로, 350명의 전문가가 속한 내부 AI Hub를 통해 60개 이상의 에이전트를 개발·운영하고 있다.
  2. 회사의 AI 활용은 제품 내 지능 탑재, 전력 수요·생산 예측, 운영 마찰을 줄이는 에이전트형 코파일럿 등으로 나뉘며, 모두 중요 인프라 환경에서 데이터 거주성·사이버보안·품질 통제가 요구된다.
  3. 기존 MLOps 방식만으로는 LLM 기반 시스템의 비결정적 동작, 프롬프트·모델 변경 효과 측정, 프로덕션 준비성 검증을 충분히 다루기 어려워 별도의 LLMOps 체계가 필요했다.
  4. Schneider의 AI Platform 팀은 LangSmith를 중심으로 관측성, 평가, 배포라는 세 가지 축을 정립하고, 제품별 워크스페이스·평가 데이터셋·SME 주석·성숙도 프레임워크를 운영 루프에 연결했다.
  5. One Jo, Customer Success Management Copilot, Digital Energy 문서 처리 에이전트 사례를 통해 실제 운영 추적, 오프라인·온라인 평가, 장기 실행 작업 큐, 제품별 런타임 분리의 효과와 비용을 함께 보여준다.

🧠 상세 정리

1. Schneider Electric의 AI 운영 배경

Schneider Electric은 에너지 기술 분야의 글로벌 기업으로, 산업·비즈니스·가정의 전기화, 자동화, 디지털화를 통해 지속가능성을 추진한다고 소개된다. 회사 규모는 16만 명의 직원과 연간 약 400억 유로 매출에 이르며, 내부에는 350명의 전문가로 구성된 AI Hub가 운영되고 있다. 이 AI Hub는 이미 60개 이상의 에이전트를 배포해 에너지 소비 최적화, 자산 수명 연장, 개발자 생산성 향상 같은 목표를 지원한다. 글의 출발점은 단순히 생성형 AI를 실험하는 것이 아니라, 대규모 조직과 중요 인프라 환경에서 신뢰 가능한 AI 운영 기반을 어떻게 만들었는지에 있다.

2. 중요 인프라에서 AI를 확장할 때의 요구

Schneider의 AI 프로그램은 크게 세 방향으로 설명된다. 첫째는 실내 제어기의 열 학습처럼 제품 자체에 지능을 넣어 에너지 소비를 줄이는 방식이고, 둘째는 수요와 생산을 예측해 고객이 더 저렴하고 친환경적인 시간대에 전력을 사용하도록 돕는 방식이다. 셋째는 더 복잡한 전력망 관리, 고객 성공 업무, 탄소 배출 소프트웨어 질의처럼 운영 마찰을 줄이는 에이전트형 코파일럿이다. 이 에이전트들은 중요 인프라 안에서 작동하므로 데이터 거주성, 사이버보안, 품질 보증, 가드레일이 핵심 조건이 된다.

3. 기존 MLOps에서 LLMOps로 전환해야 했던 이유

Schneider는 기존의 전통적 MLOps 접근만으로는 LLM 기반 시스템을 자신 있게 운영하기 어렵다고 판단했다. 원문은 주요 위험으로 원시 애플리케이션 로그 이상의 에이전트 동작 디버깅 한계, 프롬프트나 모델 변경의 정밀한 측정 부족, 생성형 AI와 에이전트 시스템의 프로덕션 준비성 검증 어려움을 든다. 특히 에이전트는 실행 과정이 복잡하고 비결정적일 수 있어, 결과만 보는 방식으로는 품질 저하나 회귀를 설명하기 어렵다. 그래서 Schneider는 별도의 LLMOps 규율을 세우고, LangSmith와 LangChain 생태계를 기반으로 관측성·평가·배포 역량을 체계화했다.

4. 관측성: 제품별 워크스페이스와 운영 트레이스 재사용

첫 번째 축인 관측성은 ‘무슨 일이 일어나고 있는지 볼 수 있는 상태’를 만드는 데 초점을 둔다. Schneider는 LangSmith를 자체 호스팅 방식으로 운영하며, 기업 보안 경계 안에서 데이터 프라이버시와 내부 정책 준수를 유지한다고 설명한다. 핵심 설계 선택은 환경별 워크스페이스가 아니라 AI 제품별 워크스페이스를 두고, 그 안에 개발·QA·사전 운영·운영 환경을 함께 묶은 점이다. 이 구조 덕분에 운영 트레이스를 도메인 전문가가 주석 처리하고 데이터셋으로 밀어 넣은 뒤, 새 에이전트 버전의 오프라인 평가에 다시 사용할 수 있다.

5. One Jo 사례: 전사 AI Assistant의 회귀 데이터와 드리프트 감지

One Jo는 Schneider Electric 내부 AI Assistant 사례로 제시되며, 107개국에 배포되어 직원들을 지원한다. 모든 대화는 LangSmith를 통해 추적되며, 동시에 엄격한 데이터 프라이버시 기준을 유지한다고 설명된다. 운영 트레이스는 단순 감사 로그로 끝나지 않고 회귀 평가 데이터셋을 채우는 데 체계적으로 재사용된다. 이를 통해 팀은 새 모델이나 프롬프트 반복이 실제 사용 사례에서 더 나아졌는지 검증할 수 있고, 시간에 따른 성능 변화나 드리프트도 빠르게 감지해 대응할 수 있다.

6. 평가: 오프라인 평가, 성숙도 프레임워크, SME 참여

두 번째 축인 평가는 ‘출시해도 되는지 결정할 수 있는 상태’를 만드는 과정으로 설명된다. Schneider는 LangSmith SDK 위에 얇은 평가 CLI를 만들고, Azure와 AWS용 Agentic RAG GitHub 템플릿을 제공해 각 AI squad가 같은 데이터셋 관례와 평가자 인터페이스로 실험하도록 표준화했다. 또한 60개 이상의 AI 제품에서 추적과 평가 도입 상태를 보기 위해 LLMOps 성숙도 모델을 만들고, LangSmith API 기반의 자동 보고를 GitHub workflow로 생성한다. 여기에 SME 역할을 LangSmith의 맞춤 권한으로 연결해, 도메인 전문가가 개발자 수준의 표면에 노출되지 않고 주석 큐와 데이터셋에 참여할 수 있게 했다.

7. CSM Copilot 사례: SME가 품질 형성에 직접 참여한 제품

Customer Success Management Copilot은 Schneider Electric의 서비스 사업 부문에서 사용되는 에이전트형 AI 솔루션 중 하나로 소개된다. 이 부문은 데이터센터와 건물의 자산 성능 관리를 위해 상태 기반 유지보수, 24시간 원격 모니터링, 전문가 지원을 제공한다. CSM Copilot은 250명 이상의 Customer Success Manager가 계정이나 계약에 대한 인사이트를 더 빠르게 생성하도록 돕는다. 특히 이 제품은 초기부터 SME가 LangSmith를 활용해 출력물을 검토하고 주석을 제공하며 시스템 동작을 함께 형성했기 때문에, 첫 배포 시점부터 높은 품질과 사용자 채택을 달성했다고 설명된다.

8. 배포: 제품별 런타임과 장기 실행 작업 처리

세 번째 축인 배포에서는 스트리밍, 장기 기억, human-in-the-loop 상호작용, 백그라운드 처리 같은 요구가 있는 에이전트를 위해 LangSmith Deployment 참조 아키텍처를 표준화했다. Schneider는 중앙집중형 에이전트 런타임을 두지 않고, 각 AI 제품이 자체 전용 스택을 운영하도록 선택했다. 이 결정은 ‘만든 팀이 운영한다’는 원칙과 단일 장애 지점 회피라는 두 가지 이유에서 비롯된다. Digital Energy의 Specification Document Intelligence 사례에서는 고객 견적 요청 문서와 PDF를 분석해 주석을 자동 추가하며, 평균 15분가량 걸리는 장기 실행 작업을 태스크 큐 모델로 안정적으로 처리해 기존 수 시간 또는 수일 걸리던 견적 흐름을 단축했다.

9. 성과와 교훈: 기본 기능 활용, 자체 호스팅의 비용

Schneider는 LangChain과의 협업을 통해 LangChain 생태계 기반의 60개 이상 AI 제품을 개발 또는 운영 중이며, 엔지니어링과 SME 커뮤니티 전반에서 약 200명의 활성 LangSmith 사용자를 확보했다고 밝힌다. 가장 중요한 교훈은 트레이스 수준의 관측성과 실제 오프라인 평가 규율 없이는 에이전트형 제품이 프로덕션 준비 상태에 도달하기 어렵다는 점이다. 또 하나의 교훈은 복잡한 내부 프레임워크를 먼저 만들기보다 LangSmith SDK 위의 얇은 CLI, 기존 권한 모델에 매핑한 맞춤 역할, 공개 API 기반 예약 보고처럼 기본 기능을 우선 활용하는 편이 낫다는 것이다. 자체 호스팅은 강력했지만 Helm 차트 업그레이드, EKS 수명주기 관리, 버전 고정, 네트워크 정책 디버깅 같은 운영 비용도 동반한다고 정리한다.

🧾 핵심 주장 / 시사점

  • 이 사례의 핵심은 LLMOps를 단순 모니터링 도구가 아니라 제품 생애주기 게이트, 도메인 전문가 참여, 회귀 평가, 운영 배포 구조를 잇는 관리 체계로 설계했다는 점이다.
  • 제품별 워크스페이스와 제품별 런타임은 운영 부담을 늘리지만, 실제 사용 트레이스를 평가 루프로 되돌리고 장애 범위를 특정 유스케이스로 격리하는 데 유리한 선택으로 제시된다.
  • Schneider의 경험은 대규모 기업에서 에이전트를 확장하려면 모델 성능 자체보다도 관측 가능한 실행 기록, 반복 가능한 평가, SME 주석, 운영 책임 분리가 먼저 갖춰져야 함을 보여준다.

✅ 액션 아이템

  • 기존 MLOps의 한계를 보완하려면 관측성·평가·배포 세 축을 분리하고, 프롬프트·모델 변경의 효과를 정기적으로 측정한다.
  • 연 매출 400억 유로 규모의 운영 조건에서 60개 이상의 에이전트를 다룰 때 데이터 거주성·사이버보안·품질 통제를 제품별 워크스페이스 정책으로 정합성 있게 반영한다.
  • One Jo·Customer Success Management Copilot·Digital Energy 사례를 기준으로 오프라인·온라인 평가와 장기 큐·런타임 분리 운영의 비용·성능 변화를 함께 비교한다.

❓ 열린 질문

  • 350명 AI Hub 운영 체계에서 60개 이상의 에이전트를 얼마나 세분화해 제품별 워크스페이스를 설계해야 할까?
  • SME 주석이 들어간 평가 데이터셋에서 오프라인 지표와 온라인 지표가 충돌할 때 우선 순위를 어떻게 정해야 할까?
  • 중요 인프라에서 장기 실행 작업 큐 분리가 실제로 성능 향상인지 비용 효율인지 판단하려면 어떤 지표를 언제 비교해야 할까?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.