283. DQDB (Distributed Queue Dual Bus)

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

본질: DQDB는 LAN/WAN과 2계층 장비에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: DQDB를 이해하면 스위칭 효율과 브로드캐스트 범위 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

개념: 최대 50km 반경(도시 크기)의 노드들을 150Mbps 이상의 고속으로 연결하는 MAN 규격 프로토콜. 슬롯(Slot) 단위로 데이터를 잘라서 전송한다.
필요성:
- LAN(근거리 망)은 거리가 너무 짧았고, WAN(광역 망)인 X.25 전용선은 너무 느리고 비쌌다. "서울시 전체, 부산시 전체에 있는 대학과 관공서를 하나로 묶어주는 적당한 거리(50km)의 고속 광통신망을 만들자!"라는 도시권 망(MAN)의 수요가 생겼다.
- FDDI(이중 링)를 쓰자니 수십 km짜리 링을 완벽히 둥글게 공사하는 게 너무 빡셌다. "그냥 곧게 쭉 뻗은 선 2개(Dual Bus)를 쫙 깔고 양방향 통신을 시키자!"라는 버스 토폴로지 기반의 DQDB가 탄생했다.
💡 비유: 이더넷이 "건물 내 복도", X.25가 **"도시 간 고속도로"**라면, DQDB는 서울시 내부의 주요 구청과 대학교들만을 뺑뺑 돌며 짐을 실어 나르는 **"수도권 광역 순환 급행 버스(MAN)"**를 만들기 위한 도로 설계도였습니다.

[FDDI]
    │
    ▼
[DQDB]
    │
    └──▶ [PON / AON]

📢 섹션 요약 비유: ** DQDB는 양방향 통행이 불가능해 툭하면 사고가 나던 1차선 좁은 버스(Bus) 망에, 서로 반대 방향으로 질주하는 **"상행선/하행선 두 개의 거대한 컨베이어 벨트(Dual Bus)"**를 깔아 도시 전체의 택배를 해결하려 했던 물류 시스템입니다.

Ⅱ. 아키텍처 및 핵심 원리

1. 토폴로지: 끊어진 링 (Dual Bus)

DQDB는 물리적으로 버스 A와 버스 B, 두 개의 단방향 광케이블로 이루어진다.

Bus A (상행선): 왼쪽 끝(헤드)에서 오른쪽으로 끊임없이 빈 상자(슬롯)를 만들어 뿜어낸다.
Bus B (하행선): 오른쪽 끝에서 왼쪽으로 빈 상자를 만들어 뿜어낸다.
모든 스위치(노드)는 이 두 선에 동시에 걸쳐 있다. 만약 노드 2가 자기보다 오른쪽에 있는 노드 4에게 데이터를 보내려면 Bus A를 타고, 왼쪽에 있는 노드 1에게 보내려면 Bus B를 타면 된다. 방향이 명확하여 충돌(Collision)이 0%다.

2. 기가 막힌 예약 시스템: 분산 큐(Distributed Queue) 알고리즘

토큰 링처럼 토큰이 올 때까지 멍하니 기다릴 필요가 없다. 만약 노드 3이 오른쪽 노드 5에게 데이터를 보내려 한다고 치자 (Bus A 사용).

노드 3은 무작정 Bus A의 빈 상자에 물건을 싣지 않는다. 내 오른쪽(노드 4, 5) 애들이 먼저 싣겠다고 예약해 둔 물건이 있을 수 있기 때문이다.
그래서 노드 3은 반대쪽으로 흘러가는 Bus B에다가 "나 상행선(Bus A)에 짐 하나 실을 거다!"라고 예약증(Request Bit=1)을 써서 던진다.
내 왼쪽에 있는 노드 1, 2는 Bus B를 타고 오는 예약증을 읽고, "아, 오른쪽에 있는 3번 녀석이 짐 실을 게 있구나! 그럼 내가 뿜어내는 상행선(Bus A) 빈 상자 중 하나는 3번을 위해 쓰지 말고 통과시켜 줘야겠다!"라고 속으로 카운트(Queue 카운터)를 올린다.
노드 1, 2가 양보해서 흘려보내 준 빈 상자가 노드 3에 도착하면, 그때 노드 3이 짐을 싣는다.

 ┌─────────────────────────────────────────────────────────────┐
 │               DQDB 분산 큐 (상행선 짐 싣기 예약 과정)           │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [노드 1]        [노드 2]        [노드 3]        [노드 4]       │
 │                                    │ 나 짐 실을래! (오른쪽으로)  │
 │                                    ▼                        │
 │  ======================= Bus A (상행선 빈 상자 뿜뿜) =====▶    │
 │                                    │                        │
 │  ◀======== Bus B (하행선, 여기에 "예약증" 던짐) ===========    │
 │     ▲               ▲             │                        │
 │     │ (예약증 확인)   │ (예약증 확인) ┘                        │
 │   "아! 밑에 애가 짐 싣는다네. 빈 상자 하나 안 건드리고 패스해줄게!"     │
 │                                                             │
 │   * 핵심: 통제하는 중앙 서버 없이, 양방향으로 예약증을 날려 서로       │
 │     양보하는 '분산(Distributed)' 대기열(Queue) 시스템.          │
 └─────────────────────────────────────────────────────────────┘

3. DQDB의 몰락

이 천재적인 예약 시스템은, 데이터를 53바이트(헤더 5+페이로드 48) 단위의 슬롯으로 잘라 보낸다. (어디서 많이 보지 않았는가? 바로 ATM 셀 규격과 100% 동일하다). DQDB 위원회는 B-ISDN(ATM)과의 호환성을 위해 이 규격을 맞췄지만, 정작 통신사들은 "어차피 ATM 셀 규격 쓸 거면, 뭐하러 복잡하게 버스망 예약 시스템을 까냐? 그냥 처음부터 끝까지 ATM 스위치로 다 깔아버리자!"라며 망을 넘어가 버렸고, DQDB는 상용화 직전에 사장되었다.

📢 섹션 요약 비유: ** DQDB의 분산 큐는 회전초밥집에서 **"나 연어초밥 먹을 거니까 주방장(상류)님! 내 앞사람들이 다 먹어 치우지 못하게 연어초밥 하나만 따로 빼서 흘려보내 주세요!"**라고 반대편 레일로 쪽지를 날리는 극강의 민주적 컨베이어 벨트 시스템이었습니다.

Ⅲ. 비교 및 연결

DQDB를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. FDDI가 기반 조건을 만든다면, DQDB는 그 위에서 핵심 메커니즘을 구현하고, PON / AON는 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 스위칭 효율과 브로드캐스트 범위에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	FDDI의 기반 정리	DQDB의 핵심 동작	PON / AON의 확장 적용
자원 관점	기본 조건 확보	스위칭 효율 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: DQDB는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 DQDB를 단독 개념으로 외우기보다 어떤 병목을 줄이기 위한 선택인지 먼저 따져야 한다. 특히 FDDI 수준의 기본 대책으로 충분한지, 아니면 DQDB가 제공하는 메커니즘이 실제로 필요한지 구분해야 한다. 이후 확장 단계에서는 PON / AON와 같은 후속 기술, 자동화 체계, 표준 호환성까지 함께 검토해야 한다.

실무 체크리스트

현재 문제의 핵심이 스위칭 효율 부족인지, 브로드캐스트 범위 악화인지 먼저 분리한다.
DQDB가 추가하는 복잡도와 운영 이득이 균형을 이루는지 확인한다.
도입 후에는 인접 기술인 PON / AON와의 연계 방식을 함께 검증한다.

안티패턴

DQDB의 장점만 보고 트래픽 패턴이나 운영 비용을 무시한 채 과도 도입하는 설계
FDDI와의 경계를 정리하지 않아 중복 투자나 정책 충돌을 만드는 설계
📢 섹션 요약 비유: DQDB를 실제로 쓰는 판단은 도구 상자를 고르는 일과 비슷하다. 좋아 보이는 도구보다 지금 문제에 맞는 도구가 중요하다.

Ⅴ. 기대효과 및 결론

DQDB는 LAN/WAN과 2계층 장비를 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 스위칭 효율 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 PON / AON, 지능형 캠퍼스 패브릭, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 지능형 캠퍼스 패브릭 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

📢 섹션 요약 비유: DQDB는 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념	연결 포인트
FDDI	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
MAC 주소 (Media Access Control Address)	2계층 전달 대상을 식별하는 기본 주소다.
스위치 (Switch)	프레임을 적절한 포트로 전달하는 핵심 장비다.
PON / AON	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: FDDI]
    │
    ▼
[현재 개념: DQDB]
    │
    ├──▶ [확장 A: PON / AON]
    └──▶ [확장 B: 지능형 캠퍼스 패브릭]

DQDB는 FDDI에서 출발해 현재 메커니즘을 정교화하고, 이후 PON / AON와 지능형 캠퍼스 패브릭 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

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

학교 우편함에 이름표가 붙어 있어야 편지가 엉뚱한 곳에 가지 않아요.
이 개념은 어느 교실로 보내야 할지 알아보는 분류 규칙과 같아요.
그래서 같은 건물 안에서도 편지가 더 빠르고 질서 있게 움직여요.