토폴로지 그림만으로 네트워크를 배포할 수는 없습니다. 의도한 링크 하나를 양쪽 포트의 일치하는 설정으로 바꿔야 합니다. 주소 블록은 장비, 루프백, 인터커넥트와 서비스 프리픽스로 나눠야 하며 BGP 피어 그룹, 경로 필터와 커뮤니티는 장비 역할을 반영해야 합니다. 규모가 커지면 이 변환을 수작업 문서로 관리할 수 없습니다.
Meta의 Matryoshka는 이 과정을 컴파일로 다룹니다. 상위 모델에 네트워크 역할, 연결과 정책을 표현하고, 시스템이 구체적인 자원을 할당해 스위치 설정을 생성합니다. 배포 전에는 불변 조건을 검증하고 단계적으로 적용합니다. Meta는 6년 넘게 Matryoshka를 운영하면서 18종, 약 900개의 데이터센터 네트워크와 10만 GPU AI 슈퍼클러스터 설계에 사용했다고 보고합니다[1].
모델을 기준 정보로 사용하는 방식
Matryoshka는 스위치마다 예외를 나열하지 않고 장비 역할로 표현합니다. 호환되는 역할의 포트를 링크로 연결하고, 역할 쌍에 맞는 템플릿이 인터페이스와 BGP 동작을 만듭니다. 프리픽스는 용도별로 할당해 장비 제어 주소와 실제 트래픽 주소를 분리합니다. 라우팅 정책은 명시적인 입력으로 유지하며 같은 역할의 장비에 일관되게 적용합니다.
AI 네트워크는 가속기 세대가 바뀔 때 서버 밀도, 레일 수와 스위치 계층까지 달라질 수 있습니다. 수천 개 설정을 직접 고치면 아키텍처 변경과 반복 작업이 섞입니다. 모델을 수정하면 Matryoshka가 장비별 설정을 다시 생성하고 어떤 출력이 바뀌었는지 비교할 수 있습니다.
검증도 컴파일러 안에 있어야 할 이유
설정 생성만 자동화하면 잘못된 입력도 빠르게 복제됩니다. Matryoshka는 배포 전에 모델과 출력을 검증합니다. 논문은 연결, 주소 할당, 설정 구조와 배포 상태를 검사한다고 설명합니다. 단계적 적용은 장애 범위를 제한하고 나머지 패브릭에 같은 변경을 넣기 전에 피드백을 제공합니다.
소프트웨어 빌드 과정과 비교하면 입력은 검토 가능한 의도이고 출력은 결정론적인 결과물이며 배포 전에 검사가 실행됩니다. 다만 스위치 설정은 실제 전달 시스템을 즉시 바꾸므로 일반 소프트웨어보다 위험 범위가 큽니다. 라우팅 정책 하나가 잘못되면 많은 랙에 영향을 줄 수 있습니다. 따라서 롤백, 점진적 배포와 관측 기능도 컴파일러 계약의 일부입니다.
10만 GPU에서 설계 속도가 성능이 되는 과정
Meta는 10만 개가 넘는 GPU 슈퍼클러스터를 배포할 때 Matryoshka를 사용했습니다. 이 논문이 강조하는 이점은 링크 속도 증가가 아니라 토폴로지와 설정을 빠르게 반복할 수 있다는 점입니다. 이 규모에서는 아키텍처 결정을 안전하게 동작하는 네트워크로 바꾸는 시간 자체가 인프라 성능입니다.
약 900개 네트워크에 적용한 기록도 중요합니다. 설정 시스템은 하나의 신규 설계에서는 깔끔해 보이지만 세대가 다른 장비와 기존 예외를 함께 다룰 때 한계가 드러납니다. 18종의 네트워크와 6년 운영은 Matryoshka가 균일한 신규 패브릭뿐 아니라 이전, 부분 배포와 운영 예외를 다뤘음을 뜻합니다.
의도 기반 시스템이 전문가 판단을 없애는 것은 아닙니다. 엔지니어는 여전히 토폴로지, 라우팅 정책, 용량과 배포 조건을 정합니다. Matryoshka는 그 결정을 명시적이고 재현 가능하게 만듭니다. 잘못된 의도는 많은 잘못된 설정을 만들 수 있으므로 리뷰 품질과 검증 범위가 새로운 통제 지점이 됩니다.
설정도 패브릭 아키텍처
AI 패브릭 논의에서는 하드웨어 토폴로지와 운영을 따로 다루곤 합니다. 그러나 안전하게 변환, 검증하고 변경할 수 없는 토폴로지는 운영 가능한 아키텍처가 아닙니다. 반대로 모델 기반 과정은 반복 세부 사항을 자동화해 더 복잡한 설계도 관리할 수 있게 합니다.
결국 패브릭의 확장성은 추상화 품질에도 달려 있습니다. 스위치 포트 수와 광 링크 거리는 무엇을 연결할 수 있는지 결정합니다. 설계 시스템은 그 가능성을 얼마나 빨리 신뢰할 수 있는 네트워크로 만들고 이후 얼마나 안전하게 바꿀 수 있는지를 결정합니다. 10만 GPU에서는 두 항목이 모두 용량 계획입니다.
네트워크 설계의 여러 표현 계층
물리 연결, 논리 주소와 라우팅 정책은 서로 다른 질문에 답합니다. 물리 계층은 포트와 광섬유의 존재를, 논리 계층은 서브넷, 루프백과 역할을 정합니다. 정책은 어떤 경로를 내보내고 선호하거나 거부할지를 표현합니다. 운영 조직이 이 계층을 서로 다른 도구에 저장하면 최종 장치 설정은 스크립트와 사람이 비공식적으로 결합하게 됩니다.
Matryoshka는 이 결합을 컴파일 문제로 다룹니다. 상위 설계 모델이 의도를 표현하고 시스템이 구체적인 스위치 설정으로 낮춥니다. 링크 역할은 주소 할당을 제한하고, 주소 체계는 정책을 제한하며, 선택한 스위치 플랫폼은 문법과 지원 기능을 제한합니다. 설정 문장이 파싱된다는 사실은 마지막 조건일 뿐 정확성의 정의가 아닙니다.
재사용 가능한 작은 구성 요소를 포드, 클러스터와 데이터센터로 중첩하고 매개변수를 사용하면 모든 설정을 복사하지 않고 크기가 다른 설계에 적용할 수 있습니다. 그러나 허용 범위가 명시된 매개변수만 안전합니다. 포트 수, 링크 속도 또는 스위치 세대가 바뀌면 기존 템플릿 안의 숨은 가정이 깨질 수 있습니다.
의도에 필요한 자료형과 불변 조건
“중복 경로를 제공한다” 같은 의도는 직접 컴파일하기에 너무 넓습니다. 장치, 포트, 링크, 프리픽스, 역할과 정책을 자료형으로 표현하고 배포 전에 검사할 불변 조건을 정해야 합니다. 주소 중복 금지, 양쪽 포트 호환, 경로 광고 범위와 독립 업링크 수 등이 그 예입니다. 설계 원칙을 기계가 확인할 수 있는 조건으로 바꾸는 과정입니다.
자료형은 이기종 장치의 차이도 포함합니다. 두 스위치가 비슷한 라우팅 기능을 제공해도 한계와 명령 문법은 다를 수 있습니다. 공통 모델은 필요한 의미를 표현하고 플랫폼별 후단은 지원되는 명령을 선택하거나 설계를 거부해야 합니다. 지원하지 않는 기능을 조용히 빼면 완전해 보이지만 원래 의도를 위반한 설정이 생깁니다.
검증은 여러 층에서 수행해야 합니다. 정적 검사는 잘못되거나 충돌하는 입력을 찾고, 컴파일 검사는 모든 의도가 대상 구조로 매핑되는지 확인합니다. 장치 구성을 합친 뒤에는 도달성, 격리와 경로 중복을 분석할 수 있습니다. 마지막으로 단계적 배포가 실제 하드웨어 상태를 관찰합니다. 논리적으로 맞는 계획도 케이블, 펌웨어나 재고 정보 오류로 실패할 수 있으므로 한 검사가 다른 검사를 대신하지 않습니다.
설정 생성과 변경 관리
새 데이터센터는 깨끗한 모델에서 만들 수 있지만 운영망은 부분적으로 바뀝니다. 패브릭 평면 추가, 스위치 교체와 주소 체계 변경은 최종 설정이 옳아도 전환 중 위험한 상태를 만들 수 있습니다. 의존 순서를 지키고 영향 범위를 제한하는 실행 계획이 필요합니다.
소수 장치의 시험 적용으로 넓은 배포 전에 근거를 얻을 수 있습니다. 각 단계 뒤에 세션, 경로와 도달성이 예상대로인지 원격 측정으로 확인해야 합니다. 불변 조건이 깨지면 일부 배포가 만든 상태까지 고려해 되돌려야 하며 텍스트 파일 하나만 복원해서는 부족합니다. 전환 상태를 관리하지 못하는 설정 컴파일러는 가장 어려운 운영 단계를 모델 밖에 남깁니다.
6년 동안 18종, 약 900개 데이터센터에 사용했다는 기록은 Matryoshka가 최초 구축뿐 아니라 반복적인 변화를 다룬다는 근거입니다[1]. GPU 10만 개 클러스터는 큰 포트 수, 여러 네트워크 계층과 빠른 용량 증가가 결합된 사례입니다. 그렇다고 하나의 템플릿이 18종을 그대로 설명한다는 뜻은 아닙니다. 공통 구성과 검증 논리를 재사용하면서 차이를 명시적으로 남기는 구조로 보는 것이 타당합니다.
모델은 운영 권한의 경계가 되는 과정
중앙 의도는 일관성을 높이지만 권한도 집중시킵니다. 공유 구성 요소 하나의 오류가 많은 장치 설정에 퍼질 수 있습니다. 따라서 모델 저장소에는 운영 서비스 코드와 같은 검토, 시험, 소유권과 버전 관리가 필요합니다. 변경을 합치기 전에 어떤 데이터센터와 장치 종류에 영향을 줄 수 있는지 계산해야 합니다.
입력을 버전으로 남기면 결과를 재현할 수 있습니다. 장애 조사자는 장치 설정을 만든 모델, 재고, 컴파일러와 플랫폼 후단을 다시 구성할 수 있어야 합니다. 이 의존성 중 하나라도 이력 없이 바뀌면 규칙이 존재하는 이유를 출력 파일만으로 설명할 수 없습니다. 긴급 수동 변경을 허용할 때는 출처 기록이 더 중요합니다.
수동 수정은 설정 차이를 만듭니다. 장애 대응 중 필요할 수 있지만 변경을 의도 모델에 반영하거나 검토 뒤 의도적으로 덮어써야 합니다. 차이를 감지하지 않고 생성 파일만 권위로 삼으면 올바른 긴급 수정이 사라질 수 있습니다. 장치 상태만 권위로 삼으면 일관되지 않은 정책이 남습니다. 이 조정 절차를 명확히 하는 것이 운영 가치의 핵심입니다.
AI 클러스터에서는 한 설계 오류의 비용이 큰 이유
AI 학습 패브릭은 긴밀하게 동기화된 작업을 운반합니다. 한 레일의 경로 또는 배선 오류는 일반 도달성이 남아 있어도 모든 랭크를 느리게 할 수 있습니다. 검증은 A에서 B로 도달하는지만 보지 않고 용량과 대칭성까지 확인해야 합니다. 집합 통신 계획이 기대하는 위치에는 동일 비용 경로가 있어야 하고, 장애 범위도 작업 배치의 가정과 맞아야 합니다.
주소와 정책 상태의 규모도 중요합니다. 대형 클러스터는 인터페이스와 경로 항목을 늘리고 여러 세대의 스위치가 공존하면서 이질성도 커집니다. 컴파일러는 상태를 일관되게 할당할 수 있지만 하드웨어 한계를 없애지는 못합니다. 표 용량, 포트 분할, 큐 구성과 지원 원격 측정의 자원 계산이 필요합니다. 의미가 맞아도 한 플랫폼의 표 크기를 넘는 설계는 배포할 수 없습니다.
빠른 확장에서는 재고 정보의 정확성이 핵심 의존성입니다. 포트 식별자와 케이블 기록이 오래되면 컴파일러가 잘못된 토폴로지를 완벽하게 검증할 수 있습니다. 의도한 링크를 이웃 검색과 광 진단 결과에 대조하는 피드백 기반 검증이 필요합니다. 차이가 있으면 해당 단계를 격리하거나 중단한 뒤 정책을 확장해야 합니다.
다른 운영자가 가져갈 수 있는 범위
일반 방법은 이전할 수 있습니다. 네트워크 의도를 자료형이 있는 모델로 표현하고, 플랫폼 후단으로 컴파일하며, 불변 조건을 확인하고 단계적으로 배포하는 절차입니다. 정확한 모델은 그대로 옮길 수 없습니다. Meta의 장치 역할, 토폴로지 종류, 주소 관례와 장애 절차는 자사 장비와 조직을 반영합니다. 다른 운영자는 내부 스키마가 아니라 설계 규율을 가져가야 합니다.
도입 비용도 큽니다. 컴파일러에는 신뢰할 수 있는 재고 정보와 설정, 검증 및 배포 시스템의 연동이 필요합니다. 템플릿만 만들고 수동 예외를 추적하지 않는 부분 도입은 관리 기준을 줄이지 못한 채 하나 더 늘릴 수 있습니다. 반복되는 네트워크 종류가 많아 검증과 재사용의 이익이 플랫폼 구축 비용을 상쇄하는 환경에 적합합니다.
Matryoshka의 핵심 결과는 기술과 조직에 걸쳐 있습니다. 아키텍처를 스위치 상태로 바꾸는 과정을 검토하고 시험할 수 있는 산출물로 만들었고 6년 동안 적용했습니다. GPU 10만 개 설계는 규모의 상단을, 네트워크 18종은 통제된 변형의 중요성을 보여 줍니다. 의도한 토폴로지가 실제로 존재하는지를 결정하므로 AI 인프라에서 컴파일러도 패브릭의 일부입니다.
출처와 저작권 안내
이 글은 공개 접근이 가능한 NSDI 2026 논문과 USENIX 공식 발표 페이지를 바탕으로 Silicon & Systems가 독립적으로 작성한 편집 요약입니다. 아키텍처, 운영 기록과 한계를 우리 표현으로 다시 설명했으며 원문의 문장, 표와 도판을 옮기지 않았습니다. 본문 도판은 이 글을 위해 새로 제작했습니다. USENIX는 NSDI 논문의 저작권을 저자가 보유한다고 명시하며, 해당 논문은 (c) 저자 2026입니다.