로봇 서비스는 단순히 로봇이 움직인다고 완성되지 않습니다. 요청이 들어오고, 적절한 로봇이 배정되며, 건물 설비와 외부 시스템이 연결되고, 예외 상황까지 감당해야 비로소 하나의 서비스가 됩니다. Physical AI플랫폼 부서의 이승연님은 K RaaS(Robot as a Service) 안에서 이러한 흐름을 설계하는 일을 맡고 있습니다.
이기종 로봇을 하나의 플랫폼 위에 연결하는 인터페이스 표준화, 고객 시나리오를 빠르게 설계·배포할 수 있게 하는 Service Builder & Runtime Engine, 그리고 로봇 기능을 실제 고객 경험으로 전환하는 비즈니스 프로세스 아키텍팅까지. 이승연님에게 K RaaS가 어떤 방식으로 ‘로봇 기능’을 ‘서비스’로 바꾸고 있는지 들어봤습니다.
먼저 현재 속한 조직의 역할을 소개해 주세요.
제가 속한 Physical AI플랫폼 부서는 다양한 제조사의 로봇을 하나의 플랫폼에서 통합 운영할 수 있도록 하는 멀티 벤더 이기종 로봇 오케스트레이션 플랫폼 K RaaS와 원천 기술을 직접 개발하고 운영하는 조직입니다. 즉, 로봇 H/W용 솔루션, 클라우드 기반 플랫폼 그리고 외부 시스템을 연계 통합하는 핵심 아키텍처와 실행 구조를 설계합니다. K RaaS는 이기종 로봇을 수용하는 인터페이스 구조, 로봇 서비스를 실행하는 Runtime Engine, 고객 서비스 시나리오를 정의하는 Service Layer, 제조사 로봇 H/W를 고도화하는 솔루션과 에이전트 개발, 그리고 현장 적용을 통해 로봇의 개별 기능을 실제 고객이 필요로 하는 서비스로 전환해 주는 플랫폼입니다.
그 안에서 본인 담당하고 있는 역할은 무엇인가요?
저는 플랫폼 안에서 고객의 비즈니스 흐름을 정의하고, 로봇과 플랫폼을 결합해 실제 문제를 해결하는 역할을 맡고 있습니다. 구체적으로는 제조사마다 다른 로봇 인터페이스를 플랫폼 표준으로 변환하는 구조를 설계·개발하고, 플랫폼이 어떤 방식으로 고객 문제를 해결할지 정의합니다. 핵심은 단순 기능 개발이 아니라, 로봇이 서비스 흐름 안에서 어떻게 동작해야 하는지를 End-to-End로 설계하는 것입니다. 이를 위해 로봇, 모바일 앱, 플랫폼, 외부 시스템을 연결하는 기술 구조(API, 데이터 흐름, 인터페이스 등)를 설계하고, 로봇 운영 자동화와 고객 경험 개선을 함께 고민하고 있습니다.
몇 가지 예로 Robot Service Builder, Runtime Engine, KT 대 고객 앱 “사장이지” 개발을 수행해 왔습니다. 최근에는 KT BizCore 플랫폼을 위한 MCP Server 개발을 통해 Agent 기반 서비스 확장에도 기여하고 있습니다.
서비스 설계하는 아키텍트로서, 가장 중요하게 보는 기준은 무엇인가요?
가장 중요하게 보는 기준은 “서비스의 완결성” 입니다. 고객 입장에서 중요한 것은 개별 로봇 기능이 아니라, 하나의 서비스가 끊김 없이 끝까지 수행되는 경험이기 때문입니다. 예를 들어 호텔 컨시어지 서비스라면 단순히 로봇이 이동하는 것이 아니라, 고객 요청이 들어오고, 호텔 시스템을 통해 물품 상태를 확인하고, 적절한 로봇이 배정되어 픽업과 전달까지 완료되는 전 과정이 하나의 서비스입니다. 또 실제 현장에서는 엘리베이터 지연, 네트워크 문제, 로봇 장애, 사용자 미응답 같은 예외 상황도 반드시 발생합니다. 그래서 서비스 설계 단계에서는 단순히 기능을 나열하는 것이 아니라, 로봇의 하드웨어 특성을 검토하고, 흐름이 끊기지 않는지, 운영 가능한 구조인지, 예외를 어떻게 해소할 수 있는지를 함께 고려하고 있습니다.
이번 K RaaS에서는 왜 ‘로봇 기능’이 아니라
‘서비스 플로우’와 ‘비즈니스 프로세스’를 함께 설계해야 했나요?
로봇을 단순히 제어하는 것만으로는 서비스가 완성되지 않기 때문입니다. 로봇의 주행이나 개별 기능은 각 제조사가 담당하며, K RaaS는 그 위에서 여러 로봇과 시스템을 연결해 실제 서비스를 만들어내는 역할을 합니다. 예를 들어 Last Mile 배송 서비스는 단순 이동만으로 끝나지 않습니다. 주문 수신부터 로봇 배차, 보안게이트·엘리베이터 같은 빌딩 설비 연동, 도착 알림과 사용자 상호작용, 그리고 장애·예외 처리까지 포함된 하나의 비즈니스 프로세스로 설계되어야 합니다. 현장은 로봇, 사람, 설비가 함께 움직이고 예외도 자주 발생하기 때문에, 기능 제어만으로는 안정적인 서비스 운영이 어렵습니다. 그래서 K RaaS는 로봇 기능이 아니라 서비스 플로우와 비즈니스 프로세스 단위로 설계하는 접근을 선택했습니다.
K RaaS에서 여러 제조사 로봇을 하나의 흐름으로 엮기 위해서
인터페이스 표준화를 위해 많은 노력을 하셨다고 들었습니다.
현재 로봇 시장은 제조사마다 인터페이스가 모두 다릅니다. 절대적인 글로벌 표준도 현재는 없는 상태입니다. 때문에, 새로운 로봇이 추가될 때마다 별도 개발이 필요하고, 멀티벤더 이기종 로봇의 통합 운영도 사실상 어렵습니다. 그래서 저희는 TCP, MQTT, HTTP 기반의 표준 인터페이스 메세지셋과 Adaptation 구조를 제공합니다. 로봇 상태, 위치, 배터리 같은 Telemetry 데이터와 임무·제어·이벤트 메시지를 수집·변환·중계하는 Mediation Layer가 다양한 로봇을 수용하는 핵심 구조입니다. 또 제조사의 연동 부담을 줄이기 위해, 실제 연동 경험을 바탕으로 Simple Connect라는 솔루션도 개발했습니다. 튜토리얼 기반의 단계별 가이드와 가상 테스트, 실로봇 검증 환경을 제공해 제조사가 더 빠르게 K RaaS에 연동할 수 있도록 지원하고 있습니다. 또한, 최근 시장에서 채택률이 올라가고 있는 OpenRMF와 같은 오픈 프레임워크도 적용 중이며, 멀티 로봇 협업과 운영 효율 향상을 위해 확장해 나가고 있습니다.
K RaaS 핵심 기술로, Service Builder & Runtime Engine이 소개됩니다.실제로 이 기능의 필요성을 가장 크게 느꼈던 순간은 언제였나요?
기존에는 고객 요구가 달라질 때마다 개발자가 시나리오를 개별 구현해야 했습니다. 예를 들어 같은 공장 순찰 서비스라도 로봇 배정 우선순위, 고객 알림 방식, 로봇 반응 동작, 보안 정책, 자동 복귀 조건 등이 고객마다 달랐습니다. 이 방식은 확장성이 낮고 개발 비용이 크며, 서비스 적용 속도도 느리다는 한계가 있었습니다. 그래서 저희는 UI 기반으로 고객별 서비스 시나리오를 정의하고, 액션을 체이닝(Chaining)해 실행할 수 있는 Service Builder & Runtime Engine 구조를 개발했습니다. 이를 통해 고객별 맞춤 시나리오를 더 빠르게 구성·배포할 수 있게 되었고, 개발 및 운영에 필요한 리소스와 비용을 줄이면서 전반적인 운영 효율도 함께 높일 수 있었습니다.
앞으로 K RaaS 플랫폼이 어떤 방향으로 발전하면 좋을까요?
K RaaS는 AI Agent 기반의 자율적 운영 구조로 확장하는 방향으로 나아가고 있습니다. 사전에 정의된 서비스 플로우를 기반으로 실행하는 구조가 중심이었다면, 향후에는 Agent가 상황에 따라 동적으로 판단하고 흐름을 조정할 수 있는 구조로 발전해 갈 수 있다고 봅니다. 로봇 상태 변화, 환경 변화, 고객 요청 변화에 따라 서비스 흐름을 유연하게 조정하고, 최적의 선택을 스스로 판단할 수 있는 구조가 만들어진다면, 대규모 Physical AI 커버리지를 감당하고 고객의 비즈니스와 운영 구조를 실질적으로 혁신할 수 있는 수준으로 발전할 수 있다고 생각합니다.
이 일이 특히 흥미롭거나 어렵게 느껴지는 점은 무엇인가요?
가장 흥미로운 점은 소프트웨어가 실제 물리 세계의 동작으로 이어진다는 점입니다. 설계한 흐름이 현장에서 로봇의 움직임과 서비스 경험으로 바로 연결되기 때문에 일반적인 소프트웨어 개발과는 또 다른 몰입감이 있습니다. 동시에 어려운 점도 분명합니다. 로봇 상태, 외부 시스템, 서비스 정책과 규제, 운영 환경까지 함께 고려해야 하기 때문입니다. 특히 이기종 로봇을 하나의 플랫폼 안에서 자연스럽게 동작시키고, 단순 제어를 넘어 유의미한 서비스로 만들어야 한다는 점에서 더 넓은 관점의 사고와 빠르게 변화하는 Physical AI 기술, 시장 그리고 정책에 대한 지속적인 이해와 학습이 필요합니다.
이 분야를 함께 연구·개발하기 위해 필요한 역량이나 경험은 무엇일까요?
단순한 개발 역량을 넘어, 로봇 디바이스(HW)와 운영체제(ROS2), 그리고 시스템 아키텍처 전반에 대한 이해를 바탕으로 설계할 수 있는 역량이 필요하다고 생각합니다. 이러한 기반 위에서 이벤트 기반 구조와 분산 시스템에 대한 이해, API 및 인터페이스 설계 경험, 그리고 여러 시스템을 연결하는 설계 능력이 함께 요구됩니다. 더 나아가 VLA(Vision-Language-Action) 모델과 같은 Physical AI 영역의 기술을 이해하고, 실제 서비스에 맞게 파인튜닝하여 적용해보는 경험도 점점 중요해지고 있습니다. 결국 중요한 것은 기능 중심이 아니라, 고객의 니즈와 업무 흐름을 이해하는 노력과, 이를 시스템으로 풀어내는 역량이라고 생각합니다. 좋은 플랫폼 개발자는 기술을 구현하는 사람을 넘어, 비즈니스와 기술을 연결하는 역할을 해야 한다고 생각합니다.
앞으로 함께할 동료나 이 분야를 준비하는 연구원·개발자·취업준비생에게
꼭 전하고 싶은 말이 있다면요?
통신사는 Physical AI 분야에서 하드웨어 자체를 제조하는 회사는 아닙니다. 대신 제조사가 잘 제작한 로봇 하드웨어 위에 AI 솔루션, K RaaS와 같은 플랫폼, 네트워크·클라우드 인프라, 그리고 구축 역량을 결합해 고객의 비즈니스 현장에서 실제로 동작하는 서비스를 만들어내는 역할을 하고 있습니다. 현실적으로는 일부 영역에서 파트너사의 도움을 받기도 하지만, Physical AI 생태계와 전체 메커니즘을 이해하려는 노력은 결국 서비스 품질에 큰 차이를 만듭니다. 또한 LLM, VLM과 같은 Foundation Model에 대한 이해와 이를 실제 서비스에 적용해보는 경험은 향후 기술 선택과 서비스 설계를 고민하는 데 중요한 자산이 될 것이라고 생각합니다.
