독일 텔레콤의 LMOS: 기업 AI 팀이 플랫폼에 실제로 원하는 것

아룬 조셉(Arun Joseph)이 InfoQ에서 설명한 것처럼, 에이전트 컴퓨팅 계층은 실제 프로덕션 환경에서 구현되어 가동 중인 에이전트, ADL(Architecture Description Language), 그리고 중앙 기능 카탈로그로 구성됩니다.

간단히 말해.

Arun Joseph은 InfoQ에서 Deutsche Telekom의 엔터프라이즈 AI 플랫폼(LMOS)을 설명했습니다. 이는 "도구 난립(tool sprawl)"을 핵심 추상화 집합으로 대체하는 계층이며, 일시적인 에이전트를 도입하는 에이전트 정의 언어(ADL)를 소개합니다. 핵심: 에이전트 컴퓨트는 클라우드 제공업체가 기본 제공하지 않는 누락된 계층입니다.

사실

InfoQ는 2026년 8월 3일 Deutsche Telekom의 LMOS에 대한 Arun Joseph의 프레젠테이션을 게시했습니다. 세 가지 핵심 주장: (1) 기업은 잘못 관리되는 LLM/에이전트 도구의 난립("tool sprawl")을 겪고 있음; (2) 필요한 것은 공통 추상화가 있는 "에이전트 컴퓨트" 계층; (3) LMOS는 ADL과 영속적 서비스 대신 일시적인 에이전트를 제안.

우리의 해석

Joseph의 주장은 새롭지 않음—QCon AI Boston(게시물 #1211)과 Cloudflare Agents Week(게시물 #1766)도 같은 이야기를 다름. 그러나 통신 운영자가 수십 년간 유지해온 레거시 코드를 관리해야 한다는 점에서 흥미로움. LMOS는 벤더의 키노트가 아닌 실제 프로덕션 경험담.

이 패턴이 아키텍처에 미치는 영향

• 영속성보다 일시성. 에이전트는 세션 간 상태가 없음; 상태는 데이터 플레인(벡터 DB, 비즈니스 DB, 이벤트 로그)에 존재. 이는 "장기 대화로 인한 컨텍스트 누수" 문제를 방지하고 수평 확장을 용이하게 함. 인지 비용: 에이전트 호출을 객체가 아닌 순수 함수 호출로 생각해야 함.
• ADL을 계약으로. 에이전트를 프롬프트가 아닌 소비/생산으로 정의. 두 팀이 상호 운용 가능한 에이전트를 작성할 수 있음. 이는 MCP의 진정한 약속을 내부적으로 적용한 것이며, 더 강력한 타입 시스템을 제공.
• 핵심 플랫폼 vs 도구 난립. 각 팀이 LangChain, LlamaIndex 등으로 도구를 연결하는 대신, 중앙 capability 카탈로그(공유 observability 및 정책 포함)를 도입. 이는 애플리케이션이 아닌 플랫폼의 역할.

내부 구조

LMOS는 아직 공개되지 않음. 가장 유사한 오픈소스 프로젝트는 MCP + 레지스트리(Anthropic MCP 허브, Cloudflare AI 게이트웨이, Portkey)입니다. 차별점: Deutsche Telekom은 데이터 플레인(통화, 청구, 내부 CRM)을 통제—클라우드 제공업체가 아웃소싱할 수 없는 사용 사례이며, 플랫폼의 내부화가 구조적으로 필요.

결론

에이전트 프레임워크와 진정한 플랫폼을 구분하는 테스트: 에이전트 계층이 Python 코드 작성 없이 에이전트를 정의하고, 서비스를 재배포하지 않고도 배포할 수 없다면 플랫폼이 아닌 SDK입니다. LMOS는 프로덕션 플랫폼이 LangChain보다 Airflow에 더 가까움을 시사.

주목할 점

LMOS 또는 ADL의 오픈소스 공개 가능성; 운영 메트릭(프로덕션 에이전트 수, 지연 시간, 작업당 비용) 공개; DMA/데이터 주권 하 유럽 통신사에서의 채택.