현대 컴퓨팅 환경에서 I/O 인터페이스의 병목은 더 이상 프로세서 속도가 아닌, 주변기기와의 통신 대역폭과 프로토콜 오버헤드에서 발생합니다. 과거 병렬 포트(Parallel Port)나 직렬 포트(Serial Port)가 가지던 물리적 공간 점유와 IRQ(Interrupt Request) 충돌 문제는 범용 직렬 버스(USB)의 등장으로 해결되었으나, 대역폭 증가에 따른 신호 무결성(Signal Integrity) 유지와 복잡한 네이밍 스키마는 엔지니어들에게 새로운 기술적 부채로 다가오고 있습니다. 본 글에서는 USB 표준이 단순한 속도 향상을 넘어, 어떤 방식으로 인코딩 효율을 높이고 전력 전송(Power Delivery)을 협상하는지 아키텍처 관점에서 분석합니다.
1. 호스트 중심 아키텍처와 폴링 메커니즘
USB의 초기 설계 철학은 '저비용 주변기기'와 '호스트 주도권'에 있습니다. FireWire(IEEE 1394)가 P2P(Peer-to-Peer) 통신을 지원하여 주변기기 간 직접 데이터 전송이 가능했던 것과 달리, USB는 철저한 **마스터-슬레이브(Master-Slave)** 구조를 따릅니다. 호스트 컨트롤러(Host Controller)가 버스의 모든 트랜잭션을 스케줄링하고 시작해야 하며, 디바이스는 호스트의 요청(Token Packet)이 있을 때만 데이터를 전송할 수 있습니다.
이러한 폴링(Polling) 방식은 디바이스의 회로 복잡도를 낮추는 데 기여했지만, CPU 오버헤드를 유발하는 단점이 있었습니다. 초기 USB 1.1에서는 이러한 오버헤드가 무시할 수준이었으나, 고속 전송이 필요한 현대 환경에서는 DMA(Direct Memory Access)와 xHCI(eXtensible Host Controller Interface) 스펙을 통해 CPU 개입을 최소화하는 방향으로 진화했습니다.
USB 디스크립터 구조와 식별
호스트가 디바이스를 인식하는 과정은 디스크립터(Descriptor)를 읽어오는 것에서 시작됩니다. 리눅스 커널 관점에서 USB 디바이스가 연결되었을 때의 구조체 정의를 살펴보면 계층 구조를 명확히 이해할 수 있습니다.
/* Linux Kernel: include/uapi/linux/usb/ch9.h */
/* USB Device Descriptor */
struct usb_device_descriptor {
__u8 bLength;
__u8 bDescriptorType; /* USB_DT_DEVICE */
__le16 bcdUSB; /* USB Spec Release Number */
__u8 bDeviceClass;
__u8 bDeviceSubClass;
__u8 bDeviceProtocol;
__u8 bMaxPacketSize0;
__le16 idVendor; /* Vendor ID (VID) */
__le16 idProduct; /* Product ID (PID) */
__le16 bcdDevice;
__u8 iManufacturer;
__u8 iProduct;
__u8 iSerialNumber;
__u8 bNumConfigurations;
} __attribute__ ((packed));
위 코드에서 idVendor와 idProduct는 드라이버 매칭의 핵심 키가 됩니다. __attribute__ ((packed))는 패딩 없이 바이트 정렬을 강제하여 프로토콜 헤더와 메모리 레이아웃을 일치시키기 위한 필수적인 지시어입니다.
2. 물리 계층(PHY)의 진화와 인코딩 오버헤드
USB 규격이 업데이트될 때마다 마케팅 용어(Full Speed, High Speed, SuperSpeed) 뒤에는 물리 계층의 전송 방식 변화와 인코딩 오버헤드(Encoding Overhead)라는 트레이드오프가 존재합니다. 엔지니어는 '대역폭(Bandwidth)'과 실제 '처리량(Throughput)'의 차이를 이해해야 합니다.
NRZI와 Bit Stuffing (USB 2.0 이하)
USB 2.0까지는 D+와 D- 라인을 이용한 차동 신호(Differential Signaling)와 NRZI(Non Return to Zero Invert) 인코딩을 사용했습니다. NRZI는 데이터가 0일 때 신호를 반전시키고, 1일 때 유지합니다. 하지만 1이 연속되면 신호 변화가 없어 클럭 동기화(Clock Recovery)를 잃을 수 있습니다. 이를 방지하기 위해 6개의 연속된 1 뒤에 강제로 0을 삽입하는 **비트 스터핑(Bit Stuffing)**이 발생하며, 이는 약 0.8%의 대역폭 손실을 유발합니다.
8b/10b 및 128b/132b 인코딩 (USB 3.x 이상)
USB 3.0(Gen 1)부터는 별도의 TX/RX 라인을 사용하는 전이중(Full-Duplex) 통신으로 전환되었습니다. 5Gbps 대역폭을 달성하기 위해 8비트 데이터를 10비트 심볼로 변환하는 **8b/10b 인코딩**을 사용합니다. 이는 DC 밸런싱을 맞추기 위함이지만, 20%의 오버헤드를 발생시킵니다. 즉, 물리적 속도는 5Gbps이나 실제 데이터 전송률은 4Gbps(500MB/s)가 한계입니다.
USB 3.1(Gen 2) 및 USB4에서는 효율성을 높이기 위해 **128b/132b 인코딩**을 도입하여 오버헤드를 약 3% 수준으로 획기적으로 줄였습니다.
| 버전 | 마케팅 명칭 | 물리 대역폭 | 인코딩 방식 | 오버헤드 | 실효 대역폭 (Approx.) |
|---|---|---|---|---|---|
| USB 2.0 | High Speed | 480 Mbps | NRZI + Bit Stuffing | Variable | ~420 Mbps |
| USB 3.2 Gen 1 | SuperSpeed | 5 Gbps | 8b/10b | 20% | 4 Gbps (500 MB/s) |
| USB 3.2 Gen 2 | SuperSpeed+ | 10 Gbps | 128b/132b | ~3% | 9.7 Gbps (1.21 GB/s) |
| USB4 | USB4 40Gbps | 40 Gbps | 128b/132b | ~3% | 38.8 Gbps |
3. Type-C와 Power Delivery(PD) 협상 로직
USB Type-C는 단순한 커넥터 형상 변경이 아닙니다. 핵심은 24핀 구조 내에 포함된 **CC(Configuration Channel)** 핀에 있습니다. 기존 USB가 전압(VBUS)을 무조건 공급했다면, Type-C와 PD는 기기 간의 **협상(Negotiation)**을 통해 전력의 방향(Source/Sink)과 데이터 역할(DFP/UFP)을 결정합니다.
CC 핀의 역할과 저항값 감지
Source(전력 공급자)와 Sink(전력 수신자)는 CC 라인의 저항 값(Pull-up Rp, Pull-down Rd)을 감지하여 연결 상태를 확인합니다. 이 과정이 완료되기 전까지 VBUS에는 전력이 공급되지 않습니다(Cold Socket). 이는 안전을 위한 중요한 메커니즘입니다.
def check_connection_state(cc_voltage):
# 전압 레벨에 따른 전류 용량 판별 (Source 측)
if cc_voltage > 2.04: # vRa range
return "Audio Accessory"
elif cc_voltage > 1.31: # vRd-3.0 range
return "Connected: 3.0A Capability"
elif cc_voltage > 0.66: # vRd-1.5 range
return "Connected: 1.5A Capability"
elif cc_voltage > 0.20: # vRd-USB range
return "Connected: Default USB Power"
else:
return "Detached"
위의 의사 코드(Pseudo-code)는 Source 입장에서 CC 핀의 전압 분배를 측정하여 Sink 디바이스가 요청하는 전류량을 파악하는 로직을 단순화한 것입니다. PD 통신은 이 CC 라인을 통해 BMC(Biphase Mark Coding) 방식으로 패킷을 주고받으며, 최대 240W(48V/5A, EPR 모드)까지 전압과 전류 프로필을 동적으로 변경합니다.
4. USB4와 터널링 아키텍처
USB4는 Intel의 Thunderbolt 3 프로토콜을 기반으로 만들어졌으며, 핵심은 **터널링(Tunneling)**입니다. USB4는 단순히 USB 패킷만 나르는 것이 아니라, PCIe, DisplayPort, USB 3.x 패킷을 캡슐화하여 단일 물리 링크로 전송합니다. 이는 시스템 버스(PCIe)를 외부로 확장하는 개념이므로 보안 취약점(DMA Attack 등)에 대한 대비가 필요하며, IOMMU(Input-Output Memory Management Unit) 활성화가 필수적입니다.
USB4 라우터는 내부적으로 가상 스위치 역할을 하며, 각 프로토콜에 대역폭을 동적으로 할당합니다. 예를 들어 모니터가 연결되면 DisplayPort 스트림에 우선순위를 부여하고, 남은 대역폭을 데이터 전송에 할당하는 방식입니다.
결론: 복잡성 비용과 호환성 관리
USB 표준은 '범용성(Universal)'이라는 목표를 달성하기 위해 내부적으로 막대한 복잡성을 수용하는 방향으로 발전했습니다. 초기 폴링 방식의 단순함에서 시작하여, 이제는 다중 프로토콜 터널링과 고전력 협상까지 수행하는 거대한 플랫폼이 되었습니다. 개발자와 시스템 엔지니어에게 이는 단순한 케이블 연결이 아닌, PHY 계층의 신호 무결성, PD 컨트롤러의 펌웨어 상태, 그리고 호스트 컨트롤러 드라이버의 호환성까지 고려해야 함을 의미합니다. 올바른 USB 시스템 설계를 위해서는 단순 스펙 시트의 숫자가 아닌, 이러한 프로토콜 스택 전반에 대한 이해가 선행되어야 합니다.
Post a Comment