Azure가 네트워크 서비스를 확장하면서 부딪힌 제약은 스위치 대역폭만이 아니었습니다. 가상 네트워크와 NAT 게이트웨이, 로드 밸런서는 패킷을 전달하는 것에 더해 연결별 정책과 상태를 관리해야 합니다. 이를 전용 장치로 옮기면 고객이 사용할 CPU는 늘어나지만, 기존 데이터센터에 그 장치를 설치할 자리가 없으면 확장은 다시 멈춥니다.
Microsoft가 NSDI 2026에서 발표한 SONiC DASH SmartSwitch는 이 문제를 하드웨어 배치와 소프트웨어 정의를 함께 바꾸는 방식으로 다룹니다[1]. 별도 장비에 두었던 DPU(Data Processing Unit)를 원래 필요한 스위치 안에 넣고, 하드웨어가 효율적으로 실행할 수 있도록 서비스 처리 규칙의 자유도를 제한합니다. 중요한 것은 DPU를 몇 개 더 넣었는지가 아니라, 어떤 서비스를 어떤 단위로 설치하고 운영할 수 있게 됐는지입니다.
이 기술은 GPU 간 집단 통신이나 새로운 스케일업 인터커넥트가 아닙니다. AI 인프라에서는 고객별 네트워크 격리, 추론 서비스의 접속점, 스토리지로 향하는 사설 연결처럼 가속기 주변의 서비스망에 해당합니다. 따라서 논문의 처리량을 그대로 학습용 올리듀스 성능으로 읽어서는 안 됩니다.
별도 DPU 풀이 남긴 설치 부담
네트워크 처리를 고객 서버 밖으로 분리하면 필요한 곳에서 공용 자원을 나눠 쓸 수 있습니다. 모든 서버에 같은 오프로딩 장치를 달 필요가 없고, 호스트 CPU를 네트워크 처리에 쓰는 부담도 줄어듭니다. 다만 공용 풀을 어디에 설치하는지는 별개의 문제입니다. 논리적으로 자원을 공유할 수 있다고 해서 물리적인 증설도 쉬워지는 것은 아닙니다.
Azure의 이전 설계인 Sirius는 DPU를 담는 서버와 이를 데이터센터에 연결하는 추가 스위치를 필요로 했습니다. 기존 컴퓨트 열에는 이미 서버와 네트워크 장비가 들어가 있어 새 랙을 놓을 공간이 충분하지 않았습니다. 통로 쪽에 장비를 추가하면 공기 흐름과 작업자의 접근에 영향을 주고, 기존 서버 랙을 빼면 고객에게 제공할 컴퓨트 용량이 줄어듭니다. 패킷 처리량만 비교해서는 드러나지 않는 비용입니다.
SmartSwitch는 논문에서 MoR(Middle of Rack) 역할을 맡는 T1 계층에 들어갑니다. 패킷 전달을 위한 스위치와 상태 처리용 DPU가 하나의 섀시에서 전력, 냉각과 연결 설비를 공유하므로 보조 장비를 줄일 수 있습니다. 그렇다고 DPU의 소비전력이나 교체 작업이 사라지는 것은 아닙니다. 기존에 설치해야 했던 장비에 기능을 통합하면서 추가로 필요한 자원을 줄이는 설계입니다.
임의의 규칙 대신 고정된 단계와 설정값
소프트웨어 가상 스위치는 다양한 조건과 동작을 자유롭게 조합할 수 있습니다. 서비스 개발에는 편리하지만, 규칙마다 검색 필드와 처리 방식이 달라지면 하드웨어의 메모리 구성과 실행 시간을 예측하기 어렵습니다. 흔한 연결의 빠른 경로만 오프로딩하고 복잡한 신규 연결 처리를 CPU에 남겨 두면, 연결이 자주 생기는 서비스에서는 그 CPU가 다시 병목이 됩니다.
DASH는 처리 단계의 수와 연결 순서, 테이블의 키 구조, 허용 동작을 미리 정합니다. 운영자는 이 범위 안에서 테이블 내용을 채우거나 지원하는 속성을 설정합니다. 검색 키의 일부 필드를 사용하지 않도록 설정하는 것과, 정확히 일치하는 값을 찾던 테이블에 새로운 검색 방식을 요구하는 것은 다릅니다. 전자는 준비된 하드웨어 기능의 설정이고, 후자는 구현 자체의 변경에 가깝습니다.
논문에 제시된 파이프라인은 13개 단계로 구성됩니다. 이는 모든 네트워크 기능을 담을 수 있다는 주장이 아니라, 클라우드에서 반복적으로 사용하는 기능을 제한된 기본 연산으로 표현하겠다는 선택입니다. 가상 네트워크의 주소 매핑과 게이트웨이의 주소 변환은 정책이 다르지만, 고객의 처리 문맥을 찾고 연결 상태를 확인한 뒤 필요한 변환을 적용한다는 공통점이 있습니다.
따라서 ‘고정’과 ‘변경 불가’를 같은 뜻으로 읽을 필요는 없습니다. 기존 단계의 설정으로 표현할 수 있는 서비스 변경은 제어 소프트웨어가 처리합니다. 반면 새로운 검색 의미나 지원하지 않는 동작이 필요하면 명세와 구현을 함께 바꿔야 합니다. 도입할 때는 현재 기능 목록뿐 아니라 향후 서비스가 어느 쪽의 변경을 요구할지도 확인해야 합니다.
연결 상태와 상태 변경을 함께 두는 이유
SmartSwitch에서 NPU는 신경망 가속기가 아니라 Network Processing Unit, 즉 네트워크 처리 칩을 뜻합니다. NPU는 높은 대역폭으로 언더레이 패킷을 전달하고, DPU는 DASH에 정의된 상태 기반 서비스를 실행합니다. NPU와 DPU를 모두 비슷한 패킷 가속기로 보면, 저장할 상태의 양과 상태를 바꾸는 속도가 서로 다른 설계 조건이라는 점을 놓치게 됩니다.
이미 알려진 연결의 패킷은 DPU에서 상태를 검색하고 기록된 동작을 적용하면 됩니다. 반면 처음 들어온 연결은 정책을 판정하고 새 상태를 만든 뒤에야 후속 패킷이 빠른 경로를 이용할 수 있습니다. 평가한 구현에서는 DPU CPU의 소프트웨어가 상태 삽입에 참여하고, 기존 연결의 패킷은 DPU의 처리 하드웨어가 담당합니다. 두 경로를 같은 DPU에 두면 상태를 만드는 쪽과 읽는 쪽을 별도 장치 사이에서 조정하는 부담을 줄일 수 있습니다.
고객 VM의 패킷은 캡슐화와 가상 인터페이스 식별 정보를 통해 해당 서비스를 맡은 DPU로 전달됩니다. VM이 연결 상태의 물리적 저장 위치를 알 필요는 없지만, 운영 시스템은 어느 DPU에 서비스를 배치할지 정해야 합니다. 전체 풀에 여유가 있어도 특정 고객이나 특정 DPU에 부하가 몰리면 그 여유를 자동으로 사용할 수 있는 것은 아닙니다. 배치와 이동 정책이 처리량만큼 중요해지는 이유입니다.
대역폭·연결률·상태 용량의 별도 해석
시험에 사용한 Cisco 플랫폼에는 12.8 Tbps 스위치 칩과 200 Gbps DPU 여덟 개가 들어갑니다. DPU는 교체 가능한 모듈 네 개에 나뉘며, 외부 네트워크 포트의 합산 용량은 11.2 Tbps, DPU 내부 연결은 1.6 Tbps입니다. 서로 다른 경로의 용량이므로 12.8 Tbps 전체를 상태 기반 서비스의 처리량으로 표시하면 안 됩니다.
큰 패킷을 처리한 실험에서 DPU 여덟 개의 처리량은 1.53 Tbps였습니다. 작은 패킷에서는 초당 약 3억 9,100만 패킷이라는 다른 제한이 나타납니다. 같은 비트 수를 보내더라도 패킷이 짧으면 검색과 패킷별 처리를 더 자주 수행해야 합니다. 대용량 전송이 전체 바이트의 대부분을 차지하는 환경에서도 짧은 RPC나 제어 트래픽을 별도로 시험해야 하는 이유입니다.
신규 연결 처리율은 배경 연결 상태가 없는 조건에서 초당 1,922만 개, 각 DPU가 배경 상태 3,200만 개를 보관한 조건에서는 초당 1,682만 개였습니다. 후자는 섀시 전체로 2억 5,600만 개의 상태를 유지한 경우입니다. 신규 연결 처리율을 비교할 때 이미 저장된 연결이 얼마나 있었는지 확인하지 않으면, 실제 운영에서 기대할 수 있는 값을 과대평가하기 쉽습니다.
확장 실험에서는 트래픽을 DPU에 균등하게 분배했습니다. 이 조건은 하드웨어 자원을 늘렸을 때의 확장성을 보여 주지만, 일부 고객에게 부하가 몰리는 상황까지 보장하지는 않습니다. 운영 중에는 전체 트래픽을 DPU 수로 나눈 평균보다 가장 바쁜 DPU와 가상 인터페이스를 먼저 봐야 합니다. DPU 하나에서 측정한 평균 패킷 지연 역시 애플리케이션의 높은 백분위 지연이나 응답시간 보장이 아닙니다.
전체 소비전력과 추가 소비전력의 차이
기존 데이터센터에 새 장비를 넣을 수 있는지 판단하려면 추가로 필요한 전력과 공간을 알아야 합니다. 반면 완성된 두 시스템의 효율을 비교하려면 각각의 전체 소비전력과 처리량이 필요합니다. 두 값 모두 유용하지만, 비교 도중 기준을 바꾸면 통합 설계의 효과를 실제보다 크게 보이게 만들 수 있습니다.
SmartSwitch의 최대 패킷 부하 조건에서 측정한 전체 소비전력은 1,040.83 W입니다. 일반 T1 스위치가 있던 구성을 기준으로 추가되는 소비전력은 448.72 W입니다. 섀시의 전체 높이도 2U이지만 추가로 차지하는 공간은 1U입니다. 작은 쪽의 숫자는 기존 장비를 대체한 효과를 반영하며, 장비 자체가 448.72 W만 쓰거나 높이가 1U라는 뜻이 아닙니다.
Sirius와의 비교는 이중화된 전체 장비 중 절반을 기준으로 정규화했습니다. 전력 효율 1.81배와 랙 공간 효율 2.68배는 각각 소비전력과 랙 공간당 패킷 처리량을 비교한 결과입니다. 이를 데이터센터 전체 전력이 같은 비율로 줄어든다거나 건물의 사용 가능 면적이 같은 비율로 늘어난다는 의미로 확대해서는 안 됩니다. 실제 구매 사양에는 서비스에 필요한 이중화와 유지보수 여유 용량을 다시 포함해야 합니다.
이 설계에서 얻을 수 있는 이점은 불필요한 보조 장비를 줄이고 기존 설치 방식에 맞춘다는 데 있습니다. 그 효과는 출발점에 따라 달라집니다. 서비스 장비를 놓을 공간이 충분한 신축 시설과 이미 빈자리가 없는 컴퓨트 열은 같은 트래픽을 처리하더라도 다른 선택을 할 수 있습니다.
P4로 맞추는 동작, 여전히 따로 검증할 성능
공개 API가 있다고 해서 두 공급자의 장치가 같은 서비스를 구현한다고 단정할 수는 없습니다. 패킷을 바꾸는 순서나 상태 갱신의 의미가 조금만 달라도 고객이 보는 결과가 달라집니다. DASH는 기대하는 동작을 P4 코드로 표현하고 이를 실행 가능한 기준 구현으로 사용합니다. 자연어 설명만으로 맞추기 어려운 부분을 테스트할 수 있게 만든 것입니다.
공급자는 같은 동작을 구현하되 내부적으로 다른 하드웨어 수단을 사용할 수 있습니다. 따라서 이 P4 모델을 모든 DPU에서 수정 없이 실행되는 공통 바이너리로 이해하면 안 됩니다. 실제 장비가 나오기 전에는 소프트웨어 모델을 대상으로 기능 시험을 만들고, 장비가 준비되면 같은 제어 인터페이스를 통해 그 시험을 적용하는 방식입니다.
이 접근은 공급자를 바꿀 때 서비스 자체를 다시 만드는 부담을 줄입니다. 그러나 기능이 같다는 사실이 테이블 용량, 연결 생성 속도, 장애 동작과 진단 기능까지 같다는 의미는 아닙니다. 장치별 성능 시험과 운영 검증은 남습니다. 공급자 중립 인터페이스가 유용하려면 구현별 한계를 감추기보다 명확하게 드러내야 합니다.
업데이트와 복구 중에도 남아야 하는 용량
스위치와 서비스를 한 섀시에 통합하면 업데이트 시 영향도 함께 커질 수 있습니다. 전체 장비를 재부팅하면 패킷 전달과 서비스 풀이 동시에 영향을 받습니다. 논문은 DPU를 순서대로 업데이트해 전체 서비스를 한꺼번에 중단하는 대신 사용 가능한 처리 용량을 일시적으로 줄이는 운영 방식을 설명합니다.
이 방식이 유효하려면 모듈 일부가 빠져도 피크 수요를 처리할 여유가 있어야 합니다. 벤치마크의 최대 처리량을 전부 판매한 뒤 업데이트는 무중단으로 끝날 것이라고 기대할 수는 없습니다. 상태를 옮기고 동기화하는 작업의 부담까지 포함해 유지보수 중의 최대 수요를 감당하는지 확인해야 합니다. 필요한 여유분은 DPU의 총개수만이 아니라 장애와 정비 절차에 따라 결정됩니다.
연결 상태의 동기화도 실제 네트워크 대역폭을 사용합니다. Azure는 T1 SmartSwitch 사이의 대량 상태 동기화에 T0 경로를 사용하며, 이는 상위 계층의 혼잡 가능성과 같은 장애 영역에 속하는 장비들의 동시 장애 위험을 비교한 선택입니다. 다른 데이터센터가 그대로 따라야 하는 계층 배치 규칙은 아닙니다. 자체 토폴로지의 초과 구독률과 장애 범위로 다시 판단해야 합니다.
상태가 빠르게 바뀌면 진단 방식도 달라져야 합니다. 큰 테이블을 전부 덤프하는 동안 연결이 생성되고 사라지면, 수집을 마친 결과가 이미 과거 상태일 수 있습니다. 논문은 필요한 연결만 골라 조회하고 패킷이 각 단계에서 어떤 항목과 일치했는지 추적하는 기능을 설명합니다. 고객에게는 단순한 시간 초과로 보이는 문제가 잘못된 정책이나 누락된 상태에서 시작했는지 구분하기 위한 기능입니다.
AI 서비스망에서의 도입 기준
AI 인프라 팀은 어떤 트래픽이 이 서비스를 통과하는지부터 확인해야 합니다. 대규모 학습 통신, 사설 접속점을 지나는 스토리지 접근, 외부 추론 요청과 에이전트 내부 RPC가 모두 같은 경로와 상태를 필요로 하지는 않습니다. 설치된 GPU 수가 많다는 이유만으로 상태 처리용 DPU 풀의 효과가 커진다고 볼 수 없습니다.
그다음에는 유지되는 연결과 새로 생기는 연결을 구분해야 합니다. 소수의 큰 전송을 오래 유지하는 작업과 추론 작업자가 한꺼번에 늘면서 짧은 연결을 만드는 상황은 서로 다른 자원을 압박합니다. 고객별 부하가 치우친 조건에서 비트 처리량, 패킷 처리율, 상태 점유량과 신규 연결률을 함께 측정하고, 정비 대상 모듈을 제외한 상태와 동기화 작업이 진행되는 상태에서도 반복해야 합니다.
마지막으로 서비스 동작이 하드웨어에 고정할 만큼 안정됐는지 판단해야 합니다. 공통 기능이 반복되고 여러 공급자가 같은 동작 명세를 구현할 수 있다면 DASH 방식의 이점이 큽니다. 반대로 애플리케이션별 패킷 처리가 빠르게 바뀐다면 소프트웨어의 자유도를 남기는 편이 유리할 수 있습니다. 모든 기능을 하드웨어로 옮기는 것이 아니라, 충분히 정리된 기능을 골라 가속하는 선택입니다.
SONiC DASH는 이 소프트웨어 선택을 실제로 설치 가능한 장비 구성과 연결했다는 점에서 의미가 있습니다. 처리량 시험은 서비스 경로의 능력을 보여 주고, 운영 경험은 그 능력을 고객에게 제공할 수 있는 용량으로 만드는 조건을 설명합니다. 구매와 도입 기준에는 포트와 DPU 수뿐 아니라 정비 중 남는 용량, 상태를 관측하는 기능과 검증된 서비스 동작까지 들어가야 합니다.
출처와 저작권 안내
이 글은 NSDI 2026 최종 논문[1]을 바탕으로 작성한 독립적인 편집 다이제스트입니다. 원문 저자의 소속은 Microsoft, Microsoft Research Asia와 홍콩중문대학교입니다. 실측값은 원문의 시험·운영 조건에 한정해 인용했으며 도입 기준과 시스템 수준의 해석은 Silicon & Systems의 분석입니다. 원문의 문장·표·도판을 옮기지 않고 본문과 설명 도판을 새로 작성했습니다. 원 논문의 저작권은 해당 권리자에게 있으며(© 2026), 프로시딩 발행 기관은 USENIX Association입니다.