109. RTS/CTS 메커니즘과 은닉 노드 문제 (Hidden Node Problem)

핵심 인사이트 (3줄 요약)

  1. 본질: 은닉 노드 문제는 물리적으로 서로 전파가 닿지 않는 두 단말기가 중앙의 AP(Access Point)에게 동시에 데이터를 전송하여 발생하는 보이지 않는 충돌 현상이다.
  2. 해결점 (RTS/CTS): 송신 전에 짧은 제어 프레임인 RTS(송신 요청)와 CTS(송신 허가)를 교환함으로써, 보이지 않는 노드들에게도 통신 예약 상태를 방송하여 매체 접근을 원천 봉쇄한다.
  3. 실무 융합: 가상 반송파 감지(Virtual Carrier Sense) 개념인 NAV(Network Allocation Vector) 타이머를 도입하여, 전력 낭비 없이 공간의 점유권을 보호하는 무선 네트워크의 핵심 예약 시스템이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

무선 네트워크는 벽이나 장애물, 거리에 따라 전파가 닿는 범위(Coverage)가 한정적이다. 기본 CSMA/CA 알고리즘은 단말기 스스로 매체를 감지(Carrier Sense)하여 비어있을 때만 전송을 시작하지만, 이 감지 범위는 오직 '자기 주변'에 국한된다. 만약 A와 C가 중간에 있는 B(AP)에게 데이터를 보내고 싶은데, A와 C 사이의 거리가 너무 멀어 서로의 전파가 닿지 않는다면 심각한 모순이 발생한다. A 입장에서는 채널이 비어있다고 판단하여 B에게 송신하고, C 역시 채널이 비었다고 판단하여 B에게 송신한다. 결국 중간에 위치한 B의 안테나에서는 A와 C의 데이터가 격렬하게 충돌하여 파괴된다. 서로가 서로에게 숨겨진(Hidden) 존재이기 때문에 발생하는 이 현상이 바로 '은닉 노드 문제(Hidden Node Problem)'이다.

이 도식은 은닉 노드 문제의 물리적 발생 구조와 충돌 메커니즘을 명확히 시각화한다.

┌────────────────────────────────────────────────────────┐
│            [은닉 노드 문제의 물리적 공간 배치]         │
├────────────────────────────────────────────────────────┤
│                                                        │
│   (전파 도달 범위)             (전파 도달 범위)        │
│  ┌─ - - - - - - ┐            ┌─ - - - - - - ┐          │
│  │              ▼            ▼              │          │
│ [Node A] ════> [Node B (AP)] <════ [Node C] │          │
│  │ (송신)      (충돌 발생!)        (송신)   │          │
│  └─ - - - - - - ┘            └─ - - - - - - ┘          │
│                                                        │
│ * 핵심 모순: A와 C는 서로의 전파 범위 밖에 있음.         │
│ * 현상: A가 전송 중이어도 C는 Carrier Sense 시 '조용하다'│
│         고 착각(CS 실패)하고 B에게 데이터를 쏘아버림.  │
└────────────────────────────────────────────────────────┘

이 구조도의 핵심은 통신 채널의 유휴 상태를 판단하는 단말기의 '청력(Carrier Sense)'이 모든 공간을 포괄하지 못한다는 데 있다. 유선 이더넷은 케이블이 하나로 이어져 있어 지구 끝에서 발생한 신호도 반드시 감지할 수 있지만, 무선은 그렇지 않다. CSMA/CA의 랜덤 백오프 알고리즘만으로는 서로의 존재를 모르는 A와 C가 동시에 난수 대기(Backoff)를 끝내고 B를 향해 데이터를 발사하는 것을 절대 막을 수 없다. 이를 방지하려면 A와 C가 서로 직접 대화할 수 없더라도, 중간에 있는 B를 스피커로 활용하여 "지금 A가 쓸 거니까 넌 조용히 해!"라고 알려주는 간접적인 예약 시스템이 필수적이었다.

📢 섹션 요약 비유: 큰 산을 사이에 두고 양쪽 골짜기에 사는 두 사람이 산 정상에 있는 사람에게 동시에 소리를 질러, 정상에 있는 사람은 양쪽 소리가 섞여 아무 말도 못 알아듣게 되는 현상과 같습니다.


Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

은닉 노드 문제를 해결하는 아키텍처의 핵심은 짧은 핸드셰이크 프레임(RTS/CTS)과 가상 타이머(NAV)의 결합이다.

구성 요소영문 명칭 (Full Name)역할 및 동작 원리비유
RTSRequest To Send송신자가 수신자에게 보내는 매우 짧은 '송신 요청' 프레임대관 신청서
CTSClear To Send수신자가 송신을 허락하며 주변에 뿌리는 '허가' 프레임대관 승인 및 공지
Duration 필드MAC Header Field데이터 송신 완료까지 걸리는 총 예상 시간 기록대관 시간 (2시간)
NAVNetwork Allocation Vector다른 노드들이 Duration을 읽고 스스로 멈추는 내부 타이머내 시계에 알람 맞추기

이 흐름도는 RTS/CTS 교환을 통해 은닉 노드(C)가 어떻게 A의 송신을 인지하고 대기(NAV) 상태로 빠지는지 보여준다.

[RTS / CTS 제어 프레임 교환을 통한 충돌 방지 시퀀스]

[Node A (송신)]           [Node B (AP)]              [Node C (은닉 노드)]
     │                         │                              │
     ├─(1) RTS 프레임 송신 ───>│                              │
     │  (Duration: 100ms)      │                              │
     │                         ├─(2) CTS 프레임 브로드캐스트 ─>│ (A에게는 허가, C에게는 경고)
     │<── CTS 프레임 수신 ─────┤  (Duration: 90ms)            │
     │                         │                              ├──> (3) NAV 타이머 설정!
     ├─(4) 본 데이터 송신 ────>│                              │    (90ms 동안 무조건 침묵)
     │                         │                              │
     │<─(5) 최종 ACK 수신 ─────┤                              │
     │                         │                              │
     │                         │                              └──> (6) NAV 종료, 채널 감시 재개

이 메커니즘의 핵심은 가상 반송파 감지(Virtual Carrier Sense)의 구현이다. 1단계: A가 B에게 보낼 데이터의 길이를 계산해 RTS(요청)를 날린다. 2단계: B는 A에게 CTS(허가)를 날리는데, 전파의 특성상 이 CTS는 B 주변의 모든 노드, 즉 A의 전파가 닿지 않는 은닉 노드 C에게도 브로드캐스트된다. 3단계: C는 A를 직접 본 적은 없지만, B가 뿌린 CTS 안에 적힌 'Duration(소요 시간)' 값을 읽어 자신의 메모리 타이머인 NAV(Network Allocation Vector)에 저장한다. 이후 C는 물리적으로 안테나를 켜서 채널을 감시(Physical CS)하지 않고도, NAV 타이머가 0이 될 때까지는 채널이 사용 중이라고 가상으로 확정 짓고 완벽히 침묵한다. 이로써 A의 본 데이터는 C의 간섭 없이 B에게 안전하게 도달한다.

📢 섹션 요약 비유: 양쪽 골짜기 사람이 산 정상으로 메신저(RTS)를 보내면, 산 정상에 있는 사람이 깃발(CTS)을 높이 들어 "지금 왼쪽 마을이 1시간 동안 말할 거야!"라고 선포하여 오른쪽 마을이 1시간(NAV) 동안 입을 다물게 만드는 것과 같습니다.


Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

RTS/CTS 메커니즘은 충돌을 완벽히 방어하지만, 제어 프레임 자체가 점유하는 오버헤드(Overhead) 때문에 득실을 철저히 따져야 한다.

비교 항목기본 CSMA/CA 방식RTS/CTS 적용 방식판단 기준 및 트레이드오프
제어 오버헤드없음 (데이터 + ACK만 교환)높음 (RTS + CTS 추가 교환 SIFS 2회 추가)대역폭 낭비의 형태 차이
충돌 시 손실대용량 본 데이터 전체 파괴짧은 RTS 프레임만 파괴 (피해 최소화)재전송에 소요되는 복구 비용
은닉 노드 방어불가능 (충돌 무방비 노출)완벽한 방어 (NAV 기반 예약)환경의 트래픽 밀집도 및 분포
적합한 데이터수십 바이트의 짧은 데이터 (VoIP)수천 바이트의 대용량 프레임 (파일 전송)패킷 크기에 따른 효율성 교차점

이 도식은 데이터의 크기에 따라 RTS/CTS 도입이 이득인지 손해인지를 비교하는 효율성 매트릭스다.

┌────────────────────────────────────────────────────────┐
│        [데이터 크기에 따른 RTS/CTS 오버헤드 딜레마]        │
├────────────────────────────────────────────────────────┤
│ 1. [작은 패킷 (예: 50 Byte 카카오톡)]                  │
│    기본: [Data 50B] -> [ACK] (매우 빠름)               │
│    RTS적용: [RTS 20B]->[CTS 14B]->[Data 50B]->[ACK]    │
│    => 배보다 배꼽이 더 크다! 대역폭 심각한 낭비 발생.     │
│                                                        │
│ 2. [큰 패킷 (예: 1500 Byte 파일 전송)]                 │
│    기본: [Data 1500B] --(충돌!)--> 전체 파괴/복구 지연 │
│    RTS적용: [RTS]-(충돌)-> 20B만 손해, 1500B는 안전    │
│    => 대용량 데이터 보호를 위한 값싼 보험료 역할!         │
└────────────────────────────────────────────────────────┘

이 대조표는 RTS/CTS가 무조건적으로 좋은 기술이 아님을 명확히 증명한다. 무선 프레임에는 아무리 작은 데이터라도 필수적인 물리 계층 헤더와 SIFS 대기 시간이 따라붙는다. 만약 50바이트짜리 작은 데이터를 보내기 위해 RTS와 CTS를 주고받는다면 채널의 효율성은 급감한다. 반대로 1500바이트짜리 대용량 프레임이 충돌하여 파괴되면, 그 긴 시간을 날려버리고 다시 백오프부터 시작해야 하므로 피해가 막심하다. 이 때문에 실무에서는 패킷이 특정 크기 이상일 때만 RTS/CTS를 발동하도록 임계치(Threshold)를 설정하는 하이브리드 전략을 취한다.

📢 섹션 요약 비유: 우편함에 작은 엽서(작은 패킷)를 넣을 때 굳이 경찰차 에스코트(RTS/CTS)를 붙이면 돈 낭비지만, 1억 원짜리 현금 수송차(대용량 패킷)를 보낼 때는 에스코트를 붙이는 게 훨씬 안전하고 저렴한 보험인 것과 같습니다.


Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 무선 네트워크 운영에서 RTS/CTS는 기본적으로 꺼져 있거나 특정 임계치 이상에서만 작동하도록 설정되며, 관리자의 세밀한 튜닝이 요구된다.

실무 시나리오 및 판단 기준

  1. 사무실 파티션으로 인한 은닉 노드 극대화 환경: 콘크리트 벽이나 파티션이 많은 사무실에서는 물리적으로 거리가 가까워도 전파가 막혀 은닉 노드가 대량으로 양산된다. 관리자가 Ping 테스트나 모니터링을 통해 무선 채널의 혼잡도가 낮음에도 불구하고 재전송률(Retransmission Rate)이 15% 이상으로 치솟는 것을 확인하면, 즉각적으로 AP의 무선 설정에서 'RTS Threshold' 값을 하향 조정(예: 2347바이트 -> 500바이트)하여 적극적인 예약 교환을 유도해야 한다.
  2. VoIP 및 실시간 스트리밍 망에서의 지터(Jitter) 증가: 음성 통화(VoIP) 패킷은 크기가 매우 작지만(수십 바이트), 지연에 극도로 민감하다. 만약 RTS Threshold가 너무 낮게 설정되어 모든 음성 패킷에 RTS/CTS가 붙게 되면, 채널 확보를 위한 제어 프레임 교환 시간이 누적되어 음성 딜레이와 끊김 현상(Jitter)이 폭발한다. 실무자는 트래픽 유형을 분석하여 실시간 패킷이 많은 망에서는 RTS/CTS를 과감히 끄고, 차라리 약간의 충돌을 허용하는 것이 체감 품질(QoE)을 높이는 전략임을 명심해야 한다.

이 판단 트리는 실무 무선망 최적화를 위한 RTS Threshold 튜닝 프로세스를 나타낸다.

[무선 네트워크 체감 속도 저하 및 연결 불안정 접수]
            │
            ▼
    MAC 계층 Frame Retry(재전송) 비율 측정
      ┌─────┴─────┐
   [낮음 (<5%)]  [비정상적 높음 (>15%)]
      │           │
 (RF 환경 양호)   ▼
        원인 분석 (Hidden Node vs 간섭/노이즈)
            ┌─────┴─────┐
        [노이즈]   [장애물/거리로 인한 Hidden Node 의심]
            │           │
      (채널 변경)       ▼
                 [조치] RTS Threshold 파라미터 조정
                   -> 기본 2347 bytes (비활성 상태)
                   -> 1000 bytes 또는 500 bytes로 점진 하향
                   -> Throughput 향상 지표 모니터링 (Loop)

이 흐름의 핵심은 RTS/CTS가 '은닉 노드'라는 특정 질병(장애물/거리 병목)에 대한 표적 치료제라는 점이다. 단순히 외부 전파 간섭(전자레인지, 타 AP 등)이 원인인데 RTS/CTS를 켜면 트래픽만 가중시켜 망을 완전히 붕괴시킨다. 따라서 실무자는 스펙트럼 애널라이저를 통해 노이즈 플로어를 먼저 확인하고, 그것이 깨끗함에도 단말 간 충돌이 잦을 때 비로소 RTS 임계치를 조작하는 정밀한 문제 해결 순서를 밟아야 한다.

📢 섹션 요약 비유: 두통(속도 저하)이 올 때 무작정 강력한 항생제(RTS/CTS)를 먹는 것이 아니라, 열이 나는지(은닉 노드) 체했는지(외부 노이즈) 정확히 진단한 뒤 적정 용량만 처방해야 부작용이 없는 의사의 진단 과정과 같습니다.


Ⅴ. 기대효과 및 결론 (Future & Standard)

RTS/CTS 메커니즘은 보이지 않는 전파 환경의 불확실성을 통제 가능한 소프트웨어 타이머(NAV)로 치환해 낸 무선 네트워크의 걸작이다.

지표RTS/CTS 비활성화 환경RTS/CTS 최적 활성화 환경기대 효과 및 발전 방향
대용량 파일 전송은닉 노드 충돌로 전송 실패율 극심채널 독점 예약으로 안정적 최고 속도영상, 대용량 파일 보호의 핵심
전력 소모 (모바일)충돌 복구 시 대량의 안테나 전력 낭비충돌 전 차단 및 NAV 대기 시 수면(Sleep)배터리 수명 보존에 기여
공간적 재사용성노출 노드(Exposed Node) 문제 발생 우려CTS를 못 받은 단말은 동시 전송 허용 시도안테나 빔포밍(MIMO)을 통한 공간 분할로 진화

이 로드맵은 충돌 방어 기술이 어떻게 1차원적 시간 분할에서 다차원적 공간 분할로 진화했는지를 보여준다.

[초기 무선 802.11b/g] CSMA/CA (충돌 눈치 게임)
       │  * 한계: 장애물 환경에서 은닉 노드로 인한 망 붕괴
       ▼
[발전 무선 802.11n/ac] RTS/CTS + NAV (시간과 공간의 가상 예약)
       │  * 한계: 제어 프레임 오버헤드로 인한 대역폭 낭비 한계
       ▼
[현대 무선 802.11ax/be] OFDMA + BSS Coloring + MU-MIMO
       │  * 혁신: 주파수를 쪼개고 색깔(Color) 태그를 달아, 아예 
          다른 노드의 패킷을 무시하고 여러 명이 '동시' 전송

은닉 노드 문제를 해결하기 위해 고안된 RTS/CTS 교환은 "보이지 않으면 미리 물어보고, 남의 허가를 엿들었으면 침묵한다"는 매우 신사적이고 정교한 분산 알고리즘이다. 하지만 이 방식 역시 결국 한 번에 한 명만 통신해야 한다는 반이중(Half-Duplex)의 한계를 벗어나지는 못했다. 현대의 초연결 Wi-Fi 6/7 기술은 RTS/CTS의 오버헤드를 줄이기 위해, AP가 직접 주파수 자원을 타일처럼 쪼개어 단말들에게 나누어주거나(OFDMA), 공간의 방향성을 제어(MIMO)하여 은닉 노드 자체를 무력화시키는 중앙 집중형 아키텍처로 진화하며 새로운 패러다임을 열어가고 있다.

📢 섹션 요약 비유: 서로 안 보이는 두 기차가 충돌할까 봐 역장에게 무전(RTS)을 쳐서 허가받고 한 대씩 터널을 통과하던 시절에서, 이제는 터널 자체를 여러 개 뚫고(OFDMA) 기차가 각자 전용 차선으로 쌩쌩 달리는 시대로 변해가는 것과 같습니다.


📌 관련 개념 맵 (Knowledge Graph)

  • CSMA/CA | RTS/CTS 메커니즘을 작동시키기 위한 기반이 되는 매체 접근 및 충돌 회피 프레임워크
  • NAV (Network Allocation Vector) | 제어 프레임에 기록된 시간을 바탕으로 동작하는 노드 내부의 가상 전송 대기 타이머
  • Exposed Node Problem | 은닉 노드와 반대로, 충분히 통신할 수 있음에도 남의 통신을 엿듣고 불필요하게 대기하는 현상
  • SIFS (Short IFS) | RTS 수신 후 CTS를 날리거나, Data 수신 후 ACK를 날릴 때 사용하는 가장 짧은 최우선 대기 시간
  • MIMO (Multiple-Input Multiple-Output) | 여러 개의 안테나로 전파의 공간을 분리하여 은닉 노드 제약을 물리적으로 완화하는 기술

👶 어린이를 위한 3줄 비유 설명

  1. 넓은 운동장에서 친구들이 서로 안 보이는 벽 뒤에 숨어있을 때 동시에 공을 던지면 중간에서 공이 부딪히겠죠? (은닉 노드)
  2. 그래서 공을 던지기 전에 가운데 서 있는 선생님한테 "저 던져도 돼요?" (RTS) 하고 먼저 작은 돌맹이를 던져서 물어보는 거예요.
  3. 선생님이 "응, 너만 던져!" (CTS) 하고 허락하면, 나머지 안 보이던 친구들도 그 소리를 듣고 공을 내려놓고 얌전히 기다리는 착한 규칙이랍니다!