Scaling Agents in Europe & The Middle East: Lessons from Schneider Electric, Vodafone, and monday.com

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

유럽·중동의 기업들은 에이전트를 운영 단계로 확장하기 위해 공통 플랫폼과 관측·평가·배포 체계를 구축하며, Schneider Electric·Vodafone·monday.com 사례는 이를 서로 다른 방식으로 보여준다.

📌 핵심 요약

• 글에서 대화한 조직 중 35%는 전사 에이전트 플랫폼을 주요 활용 대상으로 꼽았으며, 18%는 문서·백오피스 업무, 12%는 위험·준법·보안 업무, 16%는 중앙 통제 아래 비개발자의 에이전트 구축에 집중했다.
• Schneider Electric은 350명 규모의 AI Hub를 통해 60개 이상의 에이전트를 배포했으며, 엄격한 데이터 거주 요건과 사이버보안 통제 아래 공통 LLMOps 기반을 운영한다.
• Schneider Electric은 제품별로 개발부터 운영까지 하나의 작업 공간을 사용하고, 운영 추적 데이터를 평가에 재활용한다. 계측·오프라인 평가·온라인 평가·피드백을 성숙도 기준으로 삼으며, AI 제품의 약 20%에서 전문가 검토용 주석 큐를 운영한다.
• Schneider Electric은 LangSmith Deployment 참조 아키텍처를 제품별 전용 스택에 적용한다. 견적 관련 문서 처리는 기존 수시간 또는 수일에서 15분을 조금 넘는 수준으로 단축됐지만, 관리할 인프라와 조율할 업그레이드는 늘어났다.
• monday.com은 도구 증가로 Sidekick의 성능이 악화되자 하위 에이전트·범위가 제한된 도구·샌드박스로 구성된 계층형 구조로 재설계했다. Vodafone은 LangGraph 기반 Insight Engine과 Enigma를 운영하고 LangSmith로 관찰·개선하며, 제공된 본문은 Insight Engine 설명 도중 끝난다.

🧩 주요 포인트

1. 전사 에이전트 플랫폼과 비개발자 구축 지원 → 공통 기반의 중복 개발을 줄이면서 중앙 표준 아래 업무별 개발을 분산하는 구조다.
2. 운영 추적 데이터의 평가 재활용과 LLMOps 성숙도 기준 → 실험에서 실제 운영으로 넘어가는 판단을 품질 근거와 피드백에 연결한다.
3. 제품별 전용 스택과 Sidekick의 계층형 구조 → 장애 영향과 도구 사용 범위를 제한하는 설계가 중요하며, 인프라 관리 부담도 함께 고려해야 한다.

🧠 상세 정리

1. 개별 시제품에서 전사 운영 기반으로의 전환

글은 유럽·중동의 에이전트 도입이 눈에 띄는 단일 챗봇보다 여러 사업부에 흩어진 시제품을 운영 환경으로 옮기는 플랫폼 구축에서 출발하는 경우가 많다고 설명한다. 에너지·통신·보험·은행·소매처럼 규제 압력이 다른 산업에서도 시제품 제작은 쉽지만 안정적인 운영은 어렵다는 문제가 공통으로 나타난다. 글에서 대화한 조직의 35%는 전사 에이전트 플랫폼이나 제어 계층을 주요 활용 대상으로 꼽았으며, 이는 전체 시장을 대표하는 통계로 제시된 것은 아니다. 십여 개 이상의 개발 과제가 진행되면 각 팀이 같은 기반을 반복해서 만드는 문제가 드러나고, 검증된 템플릿과 재사용 가능한 프레임워크 또는 중앙 AI Hub의 필요성이 커진다. 수백 개의 개념검증이 있어도 대부분을 실제 운영으로 옮길 경로가 불분명한 상황에서 공통 계층의 책임을 정하는 것이 핵심 과제로 제시된다.

2. 문서 업무의 성과와 통제 아래의 분산 개발

글에서 대화한 조직의 18%는 보험금 청구·인수심사·송장·입찰·조달·급여처럼 기존 문서 기록과 건별 비용이 있는 업무에 집중하고 있다. 보험 약관 검토, 청구 문서 분류, 손해 이력 추출, 송장 검증은 이미 운영 중이며, 여러 사례에서 수시간 걸리던 작업이 수분으로 줄었다고 설명한다. 위험·준법·보안 업무에 집중하는 조직은 12%로, 낮거나 중간 심각도의 보안 경보 분류와 금융범죄 관련 검증 등 감사 의무가 있는 기능의 분석가 부담을 줄이는 데 초점을 둔다. 또 16%는 엔지니어링 인력이 병목이 되는 상황에서 중앙 통제 아래 비개발자가 에이전트를 구성하도록 지원한다. 이 방식에서는 비개발자가 구성·평가·게시를 수행하고 엔지니어가 효과가 확인된 에이전트를 운영 가능한 수준으로 발전시키며, 중앙 조직은 운영 표준을 적용한다.

3. 관측·평가·비용 통제의 공통 요구

글은 에이전트 확장에서 가장 반복적으로 등장하는 주제로 관측 가능성, 평가, 비용 통제를 제시한다. 관측은 오류를 찾는 기능을 넘어 거버넌스와 지출 관리에 연결되며, 조직들은 수십 개 활용 사례에 걸쳐 추적·평가·프롬프트 관리·주석 큐를 함께 운영하려 한다. 에이전트에 더 넓은 자율성을 부여하기 전에 사용자·모델·토큰·지출·정책을 통합적으로 파악하기 위해 LLM 게이트웨이를 주요 투자 대상으로 두는 흐름도 설명한다. 이러한 요구는 개별 에이전트가 한 번 올바른 답을 내는 것과 여러 에이전트를 지속적으로 관리하는 일이 서로 다른 문제임을 보여준다. 뒤이어 소개되는 기업 사례는 최초 시범 사업을 지난 뒤 이 공통 운영 계층을 실제 조직과 시스템에 어떻게 적용했는지에 초점을 맞춘다.

4. Schneider Electric의 AI Hub와 사업 적용 범위

Schneider Electric은 직원 16만 명과 연간 약 400억 유로의 매출을 보유한 에너지 기술 기업으로, 350명의 전문가로 구성된 AI Hub를 통해 60개 이상의 에이전트를 배포했다. AI 활용은 제품에 지능을 내장해 에너지 소비를 줄이는 일, 수요와 생산을 예측해 더 저렴하고 친환경적인 시간대로 전력 사용을 옮기는 일, 운영 마찰을 줄이는 에이전트형 코파일럿으로 나뉜다. 에이전트는 복잡한 전력망 관리, 고객 성공 업무, 탄소 배출 소프트웨어 조회 등에도 활용되며 중요한 기반 시설의 데이터 거주 요건과 사이버보안 통제를 따라야 한다. AI Hub 안의 AI Platform 팀은 여러 클라우드와 엣지에 걸친 기술 환경에서 개발 속도와 데이터·배포·품질 통제를 함께 지원한다. 본문은 AI Assistant 지원 범위를 한 대목에서 100개 이상 국가의 14만 명으로, 이후 One Jo 설명에서는 107개국의 16만 명으로 제시하며 두 수치의 관계를 설명하지 않는다.

5. 운영 추적 데이터를 평가 자산으로 전환

Schneider Electric은 LangSmith를 자체 보안 경계 안에서 직접 호스팅하며, 환경별로 작업 공간을 나누는 대신 AI 제품마다 개발부터 운영까지 포괄하는 하나의 작업 공간을 둔다. 이 구조에서는 운영 추적 데이터를 개발용 데이터셋으로 되돌려 오프라인 평가에 사용하고, 분야 전문가가 실제 운영 사례에 주석을 달아 데이터셋에 직접 추가할 수 있다. 내부 AI 비서 One Jo의 모든 대화는 추적되며, 운영 추적 기록은 회귀 검증용 데이터셋을 만들고 변화에 따른 성능 이탈을 감지하는 데 체계적으로 재사용된다. 회사는 팀별 데이터셋 규약과 평가기 인터페이스를 표준화하는 오프라인 평가 템플릿도 구축했다. 여기에 계측·오프라인 평가·온라인 평가·피드백 루프를 점수화하는 LLMOps 성숙도 체계를 더해, 60개 이상 제품이 탐색 단계에서 본격적인 운영 단계로 진입할 수 있는지 판단한다.

6. 전문가 참여와 기존 도구 확장의 교훈

Schneider Electric은 평가를 기술팀만의 업무로 두지 않고 분야 전문가가 실제 운영 사례를 검토하도록 연결했다. AI 제품의 약 20%에는 전문가가 참여하는 활성 주석 큐가 하나 이상 있으며, 250명 이상의 고객 성공 관리자가 사용하는 Customer Success Manager Copilot에는 개발 초기부터 전문가가 참여했다. 팀은 이러한 초기 참여가 출시 시점의 높은 품질과 채택에 도움이 됐다고 평가한다. 또한 추적 수준의 관측과 견고한 오프라인 평가가 운영 준비의 전제였으며, 초기에 계측을 생략한 팀은 이후 비결정적으로 발생하는 회귀 문제를 분석할 데이터가 부족해 어려움을 겪었다고 설명한다. 도구 측면에서는 복잡한 내부 평가 프레임워크를 새로 만들기보다 LangSmith SDK 위의 얇은 명령줄 도구, 기존 권한 모델에 맞춘 역할, 공개 API 기반 보고처럼 제공 기능을 확장하는 방식이 더 효과적이었다는 교훈을 제시한다.

7. 제품별 배포 격리와 장기 실행 작업의 성과

Schneider Electric은 모든 에이전트를 하나의 중앙 실행 환경에 모으지 않고, Agent Server와 Postgres·Redis로 구성된 LangSmith Deployment 참조 아키텍처를 표준으로 삼는다. 각 AI 제품은 전용 스택을 사용하며 개발한 팀이 운영도 책임지므로, 잘못된 배포 하나가 전사 에이전트 전체에 영향을 주는 단일 장애 지점을 줄인다. Digital Energy 부문의 문서 처리 에이전트는 견적 요청과 사양을 분석하며, 과거 수시간 또는 수일 걸리던 작업을 15분을 조금 넘는 시간에 완료한다. 이런 장기 실행 백그라운드 작업에는 작업 큐 기반 배포 모델이 도움이 된다고 설명하지만, 제품별 스택은 관리할 인프라와 조율할 업그레이드를 늘리는 대가도 따른다. 회사는 이 관리 부담을 추가 투자 영역으로 보고 있으며, 도구 선택에서는 LangChain 생태계의 통합성과 다른 프레임워크를 함께 사용할 수 있는 유연성을 긍정적으로 평가한다.

8. monday.com과 Vodafone 사례에서 확인되는 범위

서두에서 monday.com은 범용 단일 에이전트였던 Sidekick에 도구를 추가할수록 성능이 나빠지는 문제를 운영 중 발견한 사례로 소개된다. 이에 Sidekick을 하위 에이전트, 범위가 제한된 도구, 샌드박스로 이루어진 계층형 시스템으로 다시 구성했다고 설명하지만, 제공된 본문에는 별도의 상세 사례가 이어지지 않는다. Vodafone은 3억 4천만 명 이상의 고객을 지원하고 유럽 전역에 데이터센터를 운영하며, 엔지니어의 기반 시설 운영을 돕기 위해 LangChain과 LangGraph로 Insight Engine과 Enigma를 구축했다. 두 비서는 LangSmith로 관찰하고 개선하며, 상세 설명이 시작되는 Insight Engine은 자연어 질의를 SQL로 바꿔 데이터센터 모니터링 시스템의 성능 지표를 조회한다. 이를 통해 엔지니어와 운영 담당자는 이전에 맞춤형 대시보드를 통해서만 얻던 정보를 질의할 수 있지만, 본문은 재고 데이터 관련 요청의 전달 경로를 설명하는 문장 도중 끝나므로 해당 경로나 Enigma의 세부 기능은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 전사 플랫폼과 분산 개발은 함께 추진된다. 중앙 조직이 공통 기반과 운영 표준을 제공하고, 업무별 팀이 그 위에서 에이전트를 구성하는 형태다.
• Schneider Electric의 개선 체계는 운영 추적 데이터를 평가 데이터로 되돌리고 전문가 검토와 성숙도 판단에 연결하는 반복 구조에 기반한다.
• 제품별 배포 격리와 Sidekick의 계층형 재설계는 에이전트 확장에서 경계를 명확히 하는 설계의 중요성을 보여주며, 배포 격리에는 인프라 관리 부담이 따른다.

✅ 액션 아이템

• 전사 에이전트 플랫폼 도입 검토 시 공통 기반의 중복 개발과 중앙 표준 아래 비개발자 구축 지원 필요성을 함께 검토.
• Schneider Electric 사례를 기준으로 운영 추적 데이터의 평가 재활용과 LLMOps 성숙도 기준 적용 가능성을 점검.
• 제품별 전용 스택의 장애 영향 제한과 인프라 관리 부담을 비교하고, Sidekick의 계층형 구조를 도구 사용 범위 설계의 참고 사례로 검토.

❓ 열린 질문

• 전사 에이전트 플랫폼에서 중앙 표준과 비개발자 구축 지원의 범위를 어떻게 정할 것인가?
• 운영 추적 데이터의 평가 재활용과 LLMOps 성숙도 기준을 실제 운영 전환 판단에 어떻게 연결할 것인가?
• 제품별 전용 스택의 장애 영향 제한 효과와 늘어나는 인프라 관리 부담을 어떻게 비교할 것인가?