614. RPL (IoT 무선 최적 라우팅 알고리즘)

핵심 인사이트: 인터넷 라우터들은 OSPF나 BGP 같은 고급 길 찾기 알고리즘을 쓴다. 전기가 빵빵하니까 길을 찾기 위해 수시로 전국 지도를 업데이트해도 부담이 없다. 하지만 콩알만 한 건전지로 몇 년을 버티며 신호도 툭하면 끊기는 IoT 센서들에게 그 무거운 알고리즘을 돌리라고 하면 하루 만에 방전되어 죽는다. RPL은 이 가난한 센서들을 위해 만든 초경량 우회 길 찾기 시스템이다.

Ⅰ. RPL (Routing Protocol for Low-Power and Lossy Networks)의 개념

개념: 컴퓨팅 파워, 메모리, 배터리(Power)가 극도로 부족하고, 무선 전파의 손실(Lossy)이 매우 잦은 열악한 6LoWPAN 기반 센서 네트워크(WSN/IoT) 환경을 위해 IETF에서 개발한 맞춤형 IPv6 라우팅 프로토콜입니다.
일반적인 인터넷 라우팅 알고리즘(거리 벡터, 링크 상태)의 복잡성을 걷어내고, 오직 "어떻게 하면 에너지를 아끼면서 목적지(대장 노드)로 데이터를 몰아줄 수 있을까?"에 집중합니다.

Ⅱ. 핵심 아키텍처: DODAG (나무 뿌리 구조) 🌟

RPL은 전체 센서들의 길 찾기 지도를 그릴 때, 일반적인 복잡한 거미줄(Mesh) 대신 물이 위에서 아래로 흐르기 좋은 나무 뿌리(Tree) 형태의 방향성 그래프를 만듭니다. 이를 **DODAG(Destination Oriented Directed Acyclic Graph, 목적지 지향성 비순환 그래프)**라고 부릅니다.

DODAG의 생성 원리

산 정상에 전기가 빵빵한 대장(Sink Node / Root)이 있습니다.
대장 노드가 "내가 대장이다!"라는 메시지(DIO)를 주변에 뿌립니다.
그 메시지를 들은 A 센서와 B 센서는 "나는 대장으로부터 1정거장(Hop) 거리구나!"라고 자신의 랭크(Rank, 계급)를 1로 설정하고 다시 주변에 메시지를 뿌립니다.
그 밑에 있는 C 센서는 "아, A와 B를 거치면 대장에게 갈 수 있구나. 내 랭크는 2다"라고 설정합니다.
이런 식으로 산 아래쪽 센서까지 서열(Rank)이 쫙 매겨지며, 거대한 다단계 피라미드 조직도(DODAG)가 순식간에 완성됩니다.

Ⅲ. RPL 라우팅의 동작 특징

상향 트래픽 최적화 (Upward Routing): 수만 개의 센서가 수집한 온도를 대장 노드(Root) 한 곳으로 쏟아부어야 하므로(Many-to-One), 계급(Rank)이 낮은 쪽에서 높은 쪽으로 데이터를 무조건 위로 토스하기만 하면 되는 단순한 구조를 가집니다.
비순환 (Acyclic): 길을 잘못 들어 데이터가 빙글빙글 무한히 도는 현상(루프)을 막기 위해, 데이터는 무조건 자기보다 Rank(계급)가 높은(대장 쪽에 가까운) 노드에게만 전달하도록 철저히 룰을 정해 배터리 낭비를 막습니다.
자가 치유: 만약 직속상관 A 노드가 배터리가 다 돼 죽어버리면, C 센서는 당황하지 않고 즉시 옆에 있던 B 센서 쪽으로 데이터를 올려보냅니다(부모 노드 전환).

Ⅳ. 왜 일반 라우팅(OSPF 등)을 못 쓰는가?

일반 라우터들은 누군가 고장 나면 1초에 한 번씩 "살아있니?" 하고 계속 브로드캐스트를 날려 지도를 최신화합니다(Hello 패킷). 건전지로 버티는 IoT 센서가 1초에 한 번씩 전파를 쏘면 며칠 못 가 방전되므로, RPL은 상태 변화가 있을 때만 찔끔찔끔 지도를 고치는 방식(트리클 알고리즘)으로 극한의 다이어트를 합니다.

📢 섹션 요약 비유: RPL은 산속에 길을 잃은 수만 명의 병사들이 산 정상의 헬기장(Root 노드)으로 탈출하는 다단계 생존 게임입니다. 복잡한 지도를 그릴 체력(배터리)이 없으니, 산 정상에서 헬기가 빛을 비추면 병사들은 무조건 "나보다 헬기 빛이 더 밝게 보이는(Rank가 높은) 앞사람의 등짝"만 보고 수건돌리기 하듯 데이터를 위로, 위로 토스해서 넘깁니다. 앞사람이 쓰러지면 바로 옆사람 등짝을 보고 던집니다.