11.5 로봇 원격 제어 및 클라우드 연동 (Edge-to-Cloud)
방구석에서 잘 도는 로봇을 빌딩 경비 로봇으로 납품하러 가는 순간, 네트워크 엔지니어가 당신의 앞을 막아설 것이다. “우리 건물 보안망에는 외부에서 들어오는 포트가 다 막혀 있는데요?”
DDS 였다면 이 시점에서 수천만 원짜리 VPN 전용선을 깔아야 했다. 하지만 이 장에서는 단돈 5달러짜리 AWS 인스턴스와 Zenoh 라우터를 조합하여 어떠한 방화벽과 NAT(네트워크 주소 변환) 속에서도 로봇을 투명하게 건져 올리는 아키텍처 구축의 묘수를 다룬다.
1. 로봇(Edge)과 관제 서버(Cloud) 간의 Zenoh 라우터 배치 전략
수십 대의 로봇을 관제하기 위한 가장 정석적인 “스타(Star) 토폴로지” 인프라 설계다.
1.0.1 [Runbook] 허브 앤 스포크(Hub and Spoke) 라우팅 전술
가장 위험한 발상은 “클라우드 서비스(관제 대시보드) 프로그램 안에 Zenoh 라우터를 내장해서 띄우는 것” 이다. 라우터와 애플리케이션 코어는 물리적으로 혹은 프로세스 적으로 완전히 분리되어야 한다.
1. [클라우드 백본] 중앙 라우터 배치
AWS 나 GCP 등의 퍼블릭 클라우드에 CPU 2코어 이상의 가상 머신(VM)을 잡고, 오직 zenohd 프로세스만 단독으로 띄운다.
## AWS EC2 (Public IP: 203.x.x.x)
zenohd
2. [엣지 서버] 구역 라우터(Zone Router) 배치
만약 공장(공유기 밑) 안에 로봇이 10대가 있다면, 이 10대가 각자 개별적으로 AWS 로 TCP 커넥션을 맺게 하지 마라! 공장 내부에 라즈베리 파이나 미니 PC를 하나 두고 엣지 라우터를 세운다.
## 공장 내의 로컬 PC (공유기 내부망)
## 자신은 로컬 10대의 통신을 받아주되, 최종 목적지는 AWS 로 터널링한다.
zenohd -e tcp/203.x.x.x:7447
3. [로봇 단말] Client 기반 접속
이제 로봇 10대는 rmw_zenoh 나 zenoh-bridge-dds 를 켤 때, 자신의 공장에 있는 엣지 라우터로 접속한다.
결과적으로 센서 데이터는 [로봇] -> [공장 라우터] 로 먼저 모인 뒤, 단 1개의 거대한 TCP 파이프라인을 타고 압축되어 [AWS 마스터 라우터] 로 쏘아진다. 트래픽 요금과 연결 장애(Connection Drop) 관리를 극적으로 최적화하는 기업형 아키텍처다.
2. NAT 및 방화벽 환경에서 포트 포워딩 없이 ROS2 통신 구성하기
공유기 밑에 있는 네트워크를 뚫기 위해 공유기 비밀번호를 치고 들어가 거대한 포트 포워딩(Port Forwarding) 테이블을 짜던 시대는 끝났다.
2.0.1 [인스펙션] Zenoh 의 리버스 커넥션 (Reverse Connection) 원리
방화벽(Firewall)과 NAT 장비의 절대적인 원칙이 하나 있다: “밖에서 안으로 뚫고 들어오는 건 다 막아도, 안에서 밖으로 나가는 건 함부로 막지 못한다.”
로봇 원격 제어 시연을 갈 때, 빌딩 보안팀에게 IP를 열어달라고 구걸할 필요가 없다.
zenoh-bridge-dds를 로봇에서 기동할 때, 로봇이 외부의 클라우드 라우터(Public IP) 로 먼저 전화를 건다(Connect,-e).- 이 순간 NAT 장비는 내부에서 나간 안전한 TCP 커넥션으로 인식하고 길을 뚫어놓는다.
- 연결이 성립(Handshake)되고 나면, 이 열려있는 TCP 터널을 타고 양방향(Bi-directional) 통신이 일어난다.
- 즉, AWS 에 있는 ROS2 데스크톱이
/cmd_vel조이스틱 퍼블리시(Publish)를 쏘면, 이 커넥션을 “역류” 해서 방화벽을 우회통과하여 로봇의 뇌에 꽂힌다.
이것이 포트 포워딩이나 DMZ 설정 없이 LTE 동글만 꽂힌 로봇이 전 세계 어디서든 클라우드 관제 화면으로 /scan 이미지를 올려보내고 명령을 수신할 수 있는 궁극의 포켓몬(로봇) 박스 아키텍처다.
3. Zenoh 인프라를 활용한 다중 로봇 관제(Fleet Management) 시스템 아키텍처
로봇이 100대가 되면, 조이스틱 100개를 늘어놓고 제어할 수는 없다. 이들을 하나의 거대한 군집(Fleet) 관리 서버로 통합(FMS) 해야 한다.
3.0.1 [Runbook] 데이터 팬-인(Fan-In) 과 다이나믹 트리 전술
AWS 클라우드에 구축된 로봇 통합 관제 서버(백엔드)는 수십 대 로봇의 상태 창을 관리해야 한다. 기존 DDS 기반에서는 서버(Server) 쪽에 수천 개의 Subscriber 를 하드코딩으로 만들어줘야 했다.
하지만 Zenoh 의 Key Expression 와일드카드 를 쓰면 코딩 한 줄로 끝난다.
// [AWS 관제 서버단의 ROS2 코드 (rmw_zenoh 동작 중 가정)]
// 또는 일반 C++ / Go / Python 의 Zenoh Native API 코드
// 로봇이 몇 대가 새로 켜지든 접속하든,
// 이 단 한 줄의 정규식 구독자(Subscriber)가 모든 로봇의 상태 전파를 낚아챈다.
auto sub = zenoh.declare_subscriber("fleet/robot_*/status",
[](const%20zenoh::Sample&%20s) {
// 누가 보냈는지 Key 에서 추출한다 (예: fleet/robot_017/status)
std::string sender = s.get_keyexpr().as_string();
std::string robot_id = extract_robot_id(sender); // "robot_017"
// 로봇 017 번의 DB 데이터 업데이트
update_fleet_database(robot_id, s.get_payload());
}
);
새로운 신형 로봇을 사서 공장에 투입할 때 관제 서버의 코드를 컴파일하고 재기동할 필요가 없다. 로봇이 망에 연결되고 새로운 네임스페이스(fleet/robot_101/...)로 통신을 시작하는 즉시, 관제 서버의 와일드카드 구독망에 낚여 대시보드 화면에 스스로 등장하게(Pop-up) 된다. 진정한 의미의 플러그 앤 플레이(Plug and Play) 아키텍처다.
4. VPN 의존도를 낮추는 경량화된 WAN 통신 구현
DDS 를 원격에서 쓰려면 그 무거운 OpenVPN 이나 WireGuard 를 로봇 보드(Linux)안에 강제로 세팅해야 했다. VPN 암호화(Encryption) 자체만으로도 ARM 코어 하나를 갉아먹는다.
4.0.1 [인스펙션] 프로토콜 레벨의 TLS 스와핑(Swapping)
Zenoh 는 OS 단위의 VPN 터널링을 요구하지 않는다. 자신들의 TCP/UDP 소켓 자체에 인증서(Encryption)를 걸어버릴 수 있다. 통신사 보안망이 아니어도, 공개된 인터넷망(Public WAN) 을 통해 로봇 영상을 던질 때 이 전술을 쓴다.
// zenoh 라우터 설정 (router.json5)
{
listen: {
// 1. 일반 평문 통신 포트 폐쇄!
// endpoints: ["tcp/0.0.0.0:7447"] (X)
// 2. TLS(SSL) 암호화 통신 전용 포트로만 무전 개방!
endpoints: ["tls/0.0.0.0:7447"]
},
// 3. 서버 인증서 바인딩
tls: {
server_private_key: "/var/zenoh/keys/server.key",
server_certificate: "/var/zenoh/keys/server.crt",
// 4. [엔터프라이즈 레벨] 무단 접속 로봇 차단 옵션
// 접속하려는 로봇 클라이언트 측 인증서까지 검사하여 허가한다.
require_client_auth: true,
client_auth_trust_store: "/var/zenoh/keys/trusted_robots.pem"
}
}
이제 로봇 측 브릿지나 클라이언트 코드를 기동할 때는 엔드포인트를 변경해야 한다.
zenoh-bridge-dds -e tls/aws-server-ip:7447
무거운 VPN 시스템 데몬을 쓰지 않아도 AES-256 급의 단단한 암호화가 지원된다. 특히 도커(Docker) 기반으로 로봇 이미지를 말아 배포할 때, 호스트 네트워크나 튜닝 권한(Privileged) 없이도 사용자 공간(User Space) 안에서 모든 보안망 개통이 끝난다는 것은 엄청난 배포 메리트다.