Optical Circuit Switching 분석｜AI Cluster가 전기식 Spine을 줄이고 Network Topology를 빛으로 재구성하는 방식

AI Network의 대역폭 경쟁은 지금까지 비교적 명확했습니다. 51.2Tbps Switch가 102.4Tbps로 올라가고, 800G가 1.6T로 이동하며, SerDes는 100G/lane에서 200G/lane으로 빨라졌습니다.

Optical Circuit Switch, OCS는 이 흐름과 성격이 다릅니다.

OCS는 기존 Packet Switch를 더 빠르게 만드는 기술이 아닙니다. Network에서 Packet을 처리하는 방법 자체를 바꾸는 것이 아니라, Packet Switch 사이의 물리적인 연결관계를 필요에 따라 다시 구성하는 기술입니다.

일반적인 Ethernet Switch는 들어오는 Packet Header를 읽고 Forwarding Table을 조회한 뒤 어느 Port로 보낼지 매 순간 결정합니다. 반면 OCS는 Packet의 존재를 알 필요가 없습니다. 입력 Fiber에서 들어온 빛을 지정된 출력 Fiber로 물리적으로 연결해 하나의 Optical Circuit을 만들고, 그 Circuit이 유지되는 동안 Data는 Optical Domain에 그대로 머무릅니다.

따라서 OCS 내부에는 대규모 Packet Buffer, Routing Table, 102.4Tbps급 Packet Processing Pipeline이 필요하지 않습니다.

이 차이는 AI Cluster가 커질수록 중요한 경제적 의미를 가질 수 있습니다.

Packet Switch를 한 단계 더 추가하는 대신 Optical Path 자체를 재구성할 수 있다면 일부 Electrical Spine Switch와 OEO 변환을 줄일 수 있기 때문입니다.

Google은 이미 이 Architecture를 실험단계가 아니라 실제 Data Center Network에서 10년 이상 운영해 왔습니다. Google의 Jupiter Network는 OCS와 SDN을 이용해 기존 Clos 중심 구조를 재구성 가능한 Direct-connect 구조로 바꿨고, Google은 이 Architecture가 이전 세대와 비교해 Capex를 30%, 전력을 41% 줄였다고 보고했습니다. 동시에 Network Capacity는 5배 확대됐습니다. 이 수치는 Google Jupiter라는 특정 Architecture의 실제 운영결과이며 모든 OCS Network에 그대로 적용되는 일반적인 절감률로 해석해서는 안 됩니다.

2026년에는 OCS의 투자 의미도 달라지고 있습니다.

Google만 자체적으로 사용하던 특수 Network Architecture에서 벗어나 Lumentum과 Coherent가 상용 AI Data Center용 OCS를 확대하고 있고, Lumentum은 2026 회계연도 말 기준 OCS 주문잔고가 이미 4억 달러를 크게 넘어섰다고 밝혔습니다.

따라서 이제 OCS에서 중요한 질문은 “빛으로 Switch를 만들 수 있는가”가 아닙니다.

AI Network에서 Electrical Packet Switching이 담당하던 Value Pool 가운데 어느 부분을 Optical Switching이 가져갈 수 있는가가 핵심입니다.

OCS는 Optical Packet Switch가 아닙니다

이 차이를 먼저 명확하게 해야 합니다.

일반적인 Ethernet Packet Switch에서는 Packet이 들어오면 Optical Transceiver가 이를 Electrical Signal로 변환합니다. Switch ASIC은 Packet Header를 분석하고 Buffering, Queue Management, Routing, Congestion Control을 수행한 뒤 다시 다른 Port의 Transceiver를 통해 Optical Signal로 내보냅니다.

따라서 한 번의 Packet Switching에는 대략적으로 다음 과정이 포함됩니다.

Optical → Electrical → Packet Processing → Electrical → Optical

이를 OEO, Optical-Electrical-Optical Conversion이라고 합니다.

OCS에서는 이 과정이 없습니다.

빛이 입력 Fiber로 들어오면 Optical Switching Element가 이를 다른 Fiber로 보내고 그대로 빠져나갑니다.

Optical → Optical

입니다.

따라서 OCS는 Packet의 목적지 주소를 읽지도 않고 Packet을 저장하지도 않습니다.

이것이 장점인 동시에 가장 큰 제약입니다.

Packet Switch와 OCS는 완전히 다른 시간축에서 동작합니다

Packet Switch는 Packet 단위로 의사결정을 내려야 합니다.

수백 ns 또는 그보다 짧은 시간 안에 Packet을 분석하고 어느 Port로 보낼지 결정해야 하기 때문에 Switch ASIC에는 대규모 고속 Logic, Buffer Memory와 SerDes가 필요합니다.

OCS는 이렇게 동작하지 않습니다.

먼저 Control Plane이

입력 Port A를 출력 Port B에 연결한다

는 Circuit을 설정합니다.

그 이후에는 Circuit이 변경될 때까지 빛이 같은 경로를 따라갑니다.

따라서 OCS의 Network 제어주기는 Packet Processing보다 훨씬 느립니다.

이 특성 때문에 OCS를 Internet Router나 일반적인 Top-of-Rack Switch처럼 사용할 수 없습니다.

수 µs마다 목적지가 달라지는 작은 Packet Flow를 OCS가 하나씩 추적하는 Architecture는 현실적이지 않습니다.

OCS가 강한 영역은 대규모 Traffic Flow가 일정 시간 유지되는 환경입니다.

그리고 AI Training Cluster가 이 조건과 상당히 잘 맞습니다.

AI Workload는 OCS에 유리한 Traffic Pattern을 가지고 있습니다

대규모 AI Training에서는 수천 개 Accelerator가 하나의 Job을 실행합니다.

어떤 GPU가 어느 GPU와 통신할 것인지가 완전히 무작위로 매 순간 바뀌는 것이 아니라 Parallelism Strategy에 따라 상당한 구조를 가집니다.

Tensor Parallelism에서는 특정 Accelerator Group이 지속적으로 데이터를 주고받고, Pipeline Parallelism에서는 Stage 사이의 Traffic 관계가 존재하며, Data Parallelism에서는 반복적인 Collective Communication이 발생합니다.

Mixture-of-Experts는 All-to-All Traffic을 증가시키지만 이 역시 Training Job의 Placement와 Expert Mapping에 따라 일정한 Communication Structure를 형성합니다.

즉 AI Network는 일반 Web Traffic보다 대형 Flow와 반복적인 통신패턴의 비중이 높습니다.

Network Scheduler가 이러한 Traffic Matrix를 알고 있다면 Packet 하나하나의 경로를 최적화하는 대신 Network Topology 자체를 Workload에 맞게 변경할 수 있습니다.

OCS가 등장하는 지점입니다.

OCS는 Routing을 최적화하는 것이 아니라 Topology를 최적화합니다

일반적인 Ethernet Fabric에서는 Physical Topology가 먼저 정해져 있습니다.

Leaf Switch가 Spine Switch에 연결되고 Spine이 다시 여러 Leaf를 연결합니다.

Traffic Engineering은 이 고정된 Physical Topology 안에서 어느 Path를 사용할 것인지 결정합니다.

OCS Architecture에서는 한 단계가 추가됩니다.

Physical Connectivity 자체를 변경할 수 있습니다.

예를 들어 A Cluster와 B Cluster 사이 Traffic이 급증했다면 OCS를 이용해 두 영역 사이 직접 Optical Link를 더 많이 할당할 수 있습니다.

반대로 거의 통신하지 않는 두 영역 사이 Circuit은 줄이고 다른 Workload에 Optical Capacity를 재할당할 수 있습니다.

Google은 이를 Topology Engineering과 Traffic Engineering의 결합으로 설명합니다.

Jupiter에서는 OCS를 이용해 Machine Aggregation Block 사이의 물리적인 연결관계를 동적으로 변경하고 중앙 SDN Controller가 Traffic Pattern에 따라 Topology와 Routing을 함께 최적화했습니다.

이것은 Spectrum-X의 Adaptive Routing이나 UEC의 Multipath와 다른 문제입니다.

Adaptive Routing은 이미 존재하는 여러 Path 가운데 좋은 경로를 선택합니다.

OCS는 Path 자체를 새로 만듭니다.

Clos Network의 구조적인 문제는 모든 연결가능성을 미리 구축해야 한다는 것입니다

전통적인 대규모 Data Center Network에서는 Clos Architecture가 널리 사용됩니다.

Clos의 강점은 어느 Server가 어느 Server와 통신하더라도 충분한 대역폭을 제공할 수 있다는 것입니다.

이를 위해 Leaf와 Spine 사이에 많은 Link를 미리 구축합니다.

문제는 실제 Traffic이 항상 균등하지 않다는 것입니다.

모든 Rack이 다른 모든 Rack과 최대 Bandwidth로 동시에 통신하지 않더라도 Network는 최악의 경우를 감당할 수 있는 Physical Connectivity를 갖춰야 합니다.

결과적으로 일부 Link는 과도하게 사용되고 다른 Link는 놀 수 있습니다.

OCS Architecture의 경제논리는 이 부분에서 시작합니다.

모든 가능한 Traffic Pattern을 Hardware로 미리 Provision하지 않고 필요할 때 Physical Bandwidth를 이동시킨다는 것입니다.

이것이 가능하면 Overprovisioning을 줄일 수 있습니다.

Google Jupiter는 Clos를 완전히 없앤 것이 아니라 Network의 상위 연결방식을 바꿨습니다

OCS를 설명할 때 가장 조심해야 할 부분입니다.

Google이 Packet Switch를 없애고 모든 Network를 OCS로 바꾼 것은 아닙니다.

Jupiter Architecture에서는 Packet Switch들이 여전히 Traffic을 처리합니다.

OCS는 이 Packet Switching Block 사이에서 Physical Optical Connectivity를 재구성하는 역할을 맡습니다.

따라서 OCS는 Packet Switching의 완전한 대체재라기보다 일부 Packet Switching Layer를 제거하거나 단순화할 수 있는 새로운 Interconnection Layer입니다.

Google은 이를 통해 전통적인 Clos 구조를 Machine Aggregation Block 간 Direct-connect 형태로 바꿨습니다.

그 결과 Google의 실제 Production Traffic에서 약 60%는 Source와 Destination Aggregation Block 사이 Direct Path를 사용했고 나머지 Traffic도 평균적으로 하나의 추가 Block만 통과했습니다. 평균 Block-level Path Length는 1.4였습니다.

즉 OCS의 핵심 경제성은 모든 Electrical Switch를 제거하는 것이 아닙니다.

Packet이 통과해야 하는 Electrical Switching Stage를 줄이는 것입니다.

Electrical Spine 하나가 사라지면 BOM에서 무엇이 줄어들까

전통적인 Leaf-Spine Network에서 Leaf와 Spine은 Optical Link로 연결됩니다.

Leaf에서 나온 Data는 Optical Module을 통해 빛으로 변환되고 Spine에 도착하면 다시 Electrical Signal로 변환됩니다.

Spine ASIC이 Packet을 처리한 뒤 다시 Optical Module을 거쳐 다음 Leaf로 전달됩니다.

즉 하나의 중간 Spine Hop에는 Switch ASIC뿐 아니라 양쪽 Optical Interface도 필요합니다.

OCS가 해당 중간단계의 일부를 대체하면 다음 Component가 감소할 가능성이 있습니다.

Spine Switch ASIC, Switch Board, 고속 SerDes, Packet Buffer, Switch용 전력·냉각과 OEO 변환 단계입니다.

대신 새로운 Component가 들어옵니다.

OCS Chassis, Optical Switching Element, Fiber Interface, OCS Control System과 Topology Management Software입니다.

따라서 OCS는 Network BOM에 추가되는 장비라기보다 Network BOM의 구성 자체를 바꾸는 장비입니다.

이것은 Broadcom과 NVIDIA에 잠재적인 Cannibalization Risk를 만듭니다

Broadcom Tomahawk와 NVIDIA Spectrum은 대규모 AI Ethernet의 핵심 Packet Switch ASIC입니다.

AI Cluster가 커질수록 일반적으로 Switch Capacity Demand가 증가합니다.

그러나 OCS가 일부 Spine Layer를 대체할 수 있다면 필요한 Electrical Switch ASIC 수가 기존 Clos Architecture보다 줄어들 가능성이 있습니다.

즉 OCS의 확산은 이론적으로 고성능 Switch ASIC의 TAM 일부를 잠식할 수 있습니다.

다만 이 논리를 과도하게 확대해서는 안 됩니다.

OCS는 Packet을 처리하지 못합니다.

Top-of-Rack, Leaf, Endpoint Aggregation과 Congestion Management는 여전히 Packet Switch가 필요합니다.

GPU·NIC에서 발생한 Traffic을 실제로 Queueing하고 Routing하는 역할도 사라지지 않습니다.

따라서 OCS가 확산되더라도 Broadcom이나 NVIDIA의 Packet Switch가 없어지는 것이 아니라 Fabric의 일부 상위 Switching Stage에서 필요한 ASIC 수가 달라질 가능성으로 보는 것이 더 정확합니다.

High-radix Switch와 OCS는 경쟁하면서 동시에 보완관계가 될 수 있습니다

38번에서 Tomahawk 6의 High Radix가 Fabric Tier를 줄일 수 있다는 점을 살펴봤습니다.

OCS도 비슷한 목적을 가지고 있습니다.

둘 다 Network를 평탄화하고 불필요한 Intermediate Hop을 줄이는 방향입니다.

그러나 방법이 다릅니다.

Tomahawk 6는 한 Packet Switch의 Port 수와 Capacity를 높입니다.

OCS는 여러 Packet Switching Block 사이의 Optical Connectivity를 필요에 따라 다시 구성합니다.

따라서 Hyperscaler는 반드시 둘 가운데 하나만 선택할 필요가 없습니다.

High-radix Leaf/Spine Switch + OCS Interconnection Layer

같은 Hybrid Architecture도 가능합니다.

실제로 Google Jupiter 역시 Packet Switching과 OCS를 함께 사용합니다.

장기적으로 OCS의 가장 현실적인 역할은 Packet Switch 제거가 아니라 Packet Switch Fabric을 더 적은 계층과 더 높은 Utilization으로 운영하게 만드는 것일 가능성이 높습니다.

OCS의 두 번째 경제적 장점은 Data Rate에 상대적으로 독립적이라는 것입니다

Electrical Packet Switch ASIC은 세대교체가 빠릅니다.

12.8T, 25.6T, 51.2T, 102.4T로 Switch Capacity가 증가하면 ASIC과 SerDes를 새로 설계해야 합니다.

OCS는 Data를 해석하지 않습니다.

Fiber를 통해 들어오는 Optical Beam의 방향만 바꿉니다.

따라서 Optical Loss Budget과 Wavelength 범위가 허용한다면 400G Link를 통과시키던 OCS에 800G 또는 1.6T Signal을 전달하더라도 OCS 자체가 Packet Format이나 Ethernet Rate를 이해할 필요가 없습니다.

Lumentum은 자사의 MEMS 기반 OCS가 Protocol과 Modulation Format에 투명하며 O-, C-, L-band에 걸친 Broadband Operation을 지원한다고 설명합니다.

Coherent 역시 같은 이유로 AI Cluster의 Connection Speed가 높아져도 Electrical Switch처럼 OCS 자체를 세대마다 교체할 필요가 줄어들 수 있다고 강조합니다.

이것은 고객에게 매우 매력적인 특성입니다.

하지만 OCS Vendor 입장에서는 반대편도 봐야 합니다.

Data-rate Agnostic이라는 장점은 OCS Vendor에게 Refresh Cycle이 길다는 뜻이기도 합니다

Ethernet Switch ASIC Vendor는 Network Bandwidth가 두 배가 될 때마다 새로운 Silicon Generation을 판매할 기회를 얻습니다.

Optical Module 업체도 400G에서 800G, 1.6T, 3.2T로 이동하면서 Upgrade Cycle이 발생합니다.

OCS는 다릅니다.

같은 Optical Switch가 새로운 Transmission Rate를 그대로 통과시킬 수 있다면 고객이 OCS를 자주 교체할 이유가 줄어듭니다.

즉 고객에게는 높은 투자수익률이지만 Vendor에게는 긴 Replacement Cycle이 될 수 있습니다.

따라서 OCS 시장을 Semiconductor처럼 매 세대 반복되는 Upgrade Revenue로 모델링해서는 안 됩니다.

OCS Revenue는

새로운 AI Cluster 건설, Port 규모 확대, Topology 변경과 신규 고객 채택

에 더 민감할 가능성이 높습니다.

OCS의 세 번째 핵심가치는 전력입니다

Electrical Switch에서는 모든 Data가 SerDes와 Switch Logic을 통과합니다.

102.4Tbps Switch는 수백 개의 고속 SerDes와 대규모 Packet Processing Logic을 계속 동작시켜야 합니다.

OCS에서는 설정된 Path를 빛이 그대로 지나갑니다.

Data Rate가 올라간다고 OCS 내부에 200G 또는 400G SerDes가 추가되는 구조가 아닙니다.

따라서 전달되는 Bandwidth 대비 Switch Fabric 자체의 소비전력이 매우 낮을 수 있습니다.

Google Jupiter의 Production 결과에서 OCS와 Direct-connect Architecture가 전체 Network 전력 절감에 기여한 것도 이 구조와 관련됩니다. Google은 진화된 Jupiter가 이전 Architecture 대비 약 40~41% 낮은 전력을 사용했다고 보고했습니다. 다시 강조하면 이 수치는 OCS 장비 하나의 절감률이 아니라 OCS·SDN·Topology 변화가 결합된 전체 Jupiter Architecture의 결과입니다.

AI Data Center에서는 이 전력절감의 경제적 가치가 과거보다 훨씬 큽니다.

Network에서 절감한 MW를 Compute에 배정할 수 있기 때문입니다.

Google TPU는 OCS가 AI 전용 Supercomputer에서 어떻게 사용되는지 보여줍니다

Google의 OCS 활용은 일반 Data Center Network인 Jupiter에만 국한되지 않습니다.

TPU Architecture에서도 중요한 구성요소입니다.

2026년 Google이 공급 중인 Ironwood TPU에서는 64개의 TPU Chip이 하나의 Cube를 구성하고, Cube 내부는 고속 ICI로 연결됩니다.

여러 Cube를 하나의 Superpod으로 확장할 때 OCS가 등장합니다.

Ironwood의 최대 Superpod은 9,216개의 TPU, 즉 144개의 64-chip Cube로 구성되며 Cube 사이의 연결을 동적으로 재구성 가능한 OCS Network가 담당합니다.

이 Architecture는 OCS가 General-purpose Packet Network보다 고도로 구조화된 Accelerator Fabric에서 특히 강할 수 있다는 것을 보여줍니다.

Ironwood에서 OCS는 성능뿐 아니라 장애복구 장치입니다

AI Supercomputer에서는 Chip 하나가 고장나는 문제보다 Cluster 전체가 정상적으로 Job을 지속할 수 있는지가 중요합니다.

Ironwood Architecture에서는 Cube나 Optical Link에 장애가 발생하면 OCS Fabric Manager가 문제 구간을 우회하도록 Optical Circuit을 다시 구성할 수 있습니다.

Google은 문제가 있는 Cube를 제외하고 정상 Cube만으로 새로운 Optical Circuit을 구성하고 Spare Cube를 투입하는 방식으로 Superpod을 복구할 수 있다고 설명합니다.

즉 OCS는 단순 Bandwidth Optimization Device가 아닙니다.

Physical Topology 자체를 변경할 수 있기 때문에 Cluster-level Fault Domain을 Software에서 재구성할 수 있는 Infrastructure입니다.

AI Cluster 규모가 커질수록 이 가치가 증가합니다.

10만 개 Accelerator가 있다면 Hardware Failure 자체를 완전히 없애는 것은 불가능합니다.

Architecture가 장애를 전제로 설계되어야 합니다.

OCS는 물리적인 Network를 Software-defined Resource로 바꿉니다

기존 Data Center에서 Fiber 연결은 상당히 정적인 Infrastructure였습니다.

Rack을 설치하고 Fiber를 연결하면 Physical Topology는 쉽게 바뀌지 않습니다.

OCS가 들어가면 상황이 달라집니다.

Fiber는 그대로 두고 Optical Path만 Software로 변경할 수 있습니다.

즉 CPU를 Virtual Machine으로 나누고 Storage를 Pooling하듯이 Network Topology 자체를 재구성 가능한 Resource로 만들 수 있습니다.

Google Jupiter가 OCS를 SDN과 함께 사용한 이유입니다.

OCS Hardware만 설치한다고 자동으로 효율적인 Network가 만들어지는 것이 아닙니다.

Traffic Demand를 예측하고 어떤 Circuit을 연결해야 할지 계산하며 Packet Routing과 동시에 조정하는 Control Software가 필요합니다.

따라서 OCS의 경쟁력은 Optical Hardware만의 경쟁이 아닙니다.

OCS가 어려운 진짜 이유는 Control Plane입니다

Packet Switch는 Physical Topology가 고정되어 있기 때문에 Routing Software는 그 Topology 위에서 Path를 계산하면 됩니다.

OCS에서는 Topology 자체가 변수입니다.

Controller는 동시에 두 문제를 풀어야 합니다.

첫째, 어떤 Physical Optical Circuit을 구성할지 결정해야 합니다.

둘째, 만들어진 Topology 위에서 Packet Traffic을 어떻게 보낼지 결정해야 합니다.

Topology를 바꾸는 동안 Traffic을 다른 Path로 우회해야 할 수도 있습니다.

또 새로운 Circuit을 만들어도 Traffic Demand가 곧 바뀐다면 재구성 비용만 증가할 수 있습니다.

따라서 OCS에서는 Topology Engineering Algorithm의 품질이 Hardware Utilization을 결정합니다.

Google이 OCS만 개발한 것이 아니라 중앙 SDN Control과 Automated Network Operations를 함께 구축한 이유입니다.

Traffic Prediction이 틀리면 OCS의 장점이 줄어듭니다

OCS는 특정 Source와 Destination 사이 Physical Capacity를 직접 연결합니다.

따라서 Traffic Demand가 어느 정도 지속돼야 Circuit을 만드는 의미가 있습니다.

갑자기 Traffic Pattern이 바뀌면 새 Circuit을 구성해야 합니다.

일반적인 Cloud Front-end Traffic처럼 짧고 불규칙한 Flow가 매우 많다면 고정된 Packet Fabric이 더 효율적일 수 있습니다.

반면 대형 AI Job처럼 수초·수분·수시간 동안 동일한 Accelerator Group이 지속적으로 통신한다면 OCS의 재구성 시간이 상대적으로 중요하지 않습니다.

이것이 OCS Adoption을 판단할 때 매우 중요한 변수입니다.

Traffic의 크기보다 Traffic의 시간적 안정성이 더 중요할 수 있습니다.

OCS에는 Packet Buffer가 없습니다

Packet Switch에서는 여러 입력이 동시에 하나의 출력으로 몰리면 Buffer에 Packet을 저장할 수 있습니다.

OCS는 그렇게 할 수 없습니다.

입력 Fiber와 출력 Fiber 사이 Circuit을 연결할 뿐입니다.

따라서 여러 Source가 동시에 동일 Destination으로 보내고 싶다고 해서 OCS가 Packet을 Queueing하며 공유 Port를 시간분할해줄 수 없습니다.

이 문제는 Packet Switch나 End Host, Scheduler가 해결해야 합니다.

즉 OCS는 Congestion Control의 대체재가 아닙니다.

Spectrum-X의 Adaptive Routing, UEC Transport, RDMA Congestion Control 같은 기술도 여전히 필요합니다.

OCS는 Congestion이 발생하는 Physical Capacity 배치를 바꿀 수 있을 뿐 Packet-level Congestion 자체를 처리하지 않습니다.

그래서 OCS와 AI NIC는 서로 대체관계가 아닙니다

AI NIC는 RDMA, Packet Scheduling, Retransmission, Multipathing과 Congestion Control을 수행합니다.

OCS는 Optical Circuit만 변경합니다.

따라서 OCS Architecture에서도 ConnectX, Thor Ultra 같은 AI NIC의 역할은 유지됩니다.

오히려 Topology가 동적으로 변하면 NIC와 Network Controller가 현재 어떤 Path가 존재하는지 더 정확하게 인식해야 할 수도 있습니다.

장기적으로 OCS가 확대된다면 Network Topology Controller와 NIC Telemetry 사이의 통합이 새로운 Software Layer가 될 가능성이 있습니다.

OCS의 Hardware 핵심은 무엇일까

현재 상용 OCS에는 여러 Optical Switching Technology가 경쟁하고 있습니다.

대표적인 방식 가운데 하나가 MEMS입니다.

MEMS OCS에서는 매우 작은 Mirror Array의 각도를 조절해 입력 Fiber에서 나온 빛을 특정 출력 Fiber 방향으로 반사합니다.

Lumentum의 R300은 이러한 MEMS Technology를 이용하는 300×300 Port OCS입니다. R64는 64×64 Port 구성을 제공합니다.

MEMS의 핵심 장점은 Optical Signal이 복잡한 Waveguide Network를 여러 번 통과하지 않고 Mirror를 통해 공간상에서 이동하기 때문에 낮은 Insertion Loss와 높은 Port Scale을 확보하기 유리하다는 점입니다.

Lumentum은 자사 MEMS OCS의 대표적인 Insertion Loss가 증폭 없이 1.5dB 미만이며 Protocol과 Modulation Format에 독립적으로 동작한다고 설명합니다.

Google Palomar 역시 MEMS OCS입니다

Google이 Jupiter에서 자체 개발한 Palomar OCS 역시 MEMS를 사용합니다.

Google의 Palomar는 136×136 Non-blocking Connectivity를 제공하며 136개 입력과 출력 사이 임의의 1:1 연결을 구성할 수 있습니다.

Google 연구자료에서는 Palomar가 전체 18,496개의 가능한 Cross-connection에서 통상 2dB 미만 수준의 Insertion Loss를 보였다고 설명합니다.

Palomar가 중요한 이유는 사양보다 대규모 실제 운영경험입니다.

Google은 OCS를 단순 Proof-of-concept로 운영한 것이 아니라 Jupiter Data Center와 TPU Supercomputer에 지속적으로 사용해 왔습니다.

따라서 MEMS OCS는 적어도 대규모 Hyperscale Deployment가 가능한 Architecture라는 점은 이미 검증된 셈입니다.

Coherent는 MEMS와 다른 Digital Liquid Crystal 방식을 선택했습니다

현재 상용 OCS 시장에서 흥미로운 경쟁구도 중 하나입니다.

Coherent의 OCS는 MEMS Mirror 대신 Digital Liquid Crystal Technology를 사용합니다.

Coherent는 현재 64×64부터 320×320, 512×512까지 OCS Configuration을 제시하고 있습니다.

회사가 강조하는 차별점은 기계적으로 움직이는 Mirror가 없다는 것입니다.

Coherent는 자사의 Digital Liquid Crystal Platform이 10V 미만의 낮은 구동전압을 사용하고, 과거 Wavelength Selective Switch에서 16만 대 이상 출하된 Technology를 기반으로 한다고 설명합니다. 이러한 신뢰성 비교는 Coherent 자체의 Vendor Positioning이라는 점을 감안해야 합니다.

반대로 Lumentum은 자사의 MEMS Platform이 Telecom Network에서 누적 1조 시간 이상의 Mirror 동작경험을 가지고 있다는 점을 강조합니다.

따라서 현재 OCS에서는 단순하게

MEMS는 신뢰성이 낮고 Liquid Crystal이 우수하다

또는 그 반대로 결론 내리기 어렵습니다.

실제 경쟁은 Port Scale, Insertion Loss, 재구성 특성, 신뢰성, 제조원가와 고객의 장기 Field Data에서 결정될 가능성이 높습니다.

OCS의 Port 수는 Packet Switch의 Port 수와 같은 의미가 아닙니다

300×300 OCS라고 하면 Ethernet Switch의 300 Port와 비슷해 보일 수 있습니다.

그러나 OCS Port는 Packet Processing Port가 아니라 광경로를 연결하는 Fiber Port입니다.

하나의 Fiber에 WDM으로 여러 Wavelength Channel이 들어간다면 OCS는 내부 Data Format을 알지 못한 채 전체 Optical Signal을 그대로 다른 Port로 보낼 수 있습니다.

따라서 OCS가 실제로 처리하는 Aggregate Bandwidth는 단순

Port 수 × 특정 Ethernet Rate

로 고정되지 않습니다.

같은 OCS의 Fiber 위에서 광전송 기술이 발전하면 System Bandwidth가 증가할 수 있습니다.

이 Data-rate Transparency가 OCS의 가장 중요한 경제적 특성 가운데 하나입니다.

그런데 OCS를 하나 더 넣으면 Optical Loss가 추가됩니다

빛이 OCS를 그냥 통과한다고 해서 Loss가 0인 것은 아닙니다.

Mirror, Lens, Fiber Coupling, Connector 등을 통과하면서 Insertion Loss가 발생합니다.

따라서 기존 Point-to-point Optical Link에 OCS가 추가되면 Transceiver의 Optical Power Budget도 더 엄격해질 수 있습니다.

이 때문에 Optical Transceiver 공급망 역시 OCS Architecture에 맞춰 변화하고 있습니다.

Coherent는 OCS를 통과한 상태에서도 2km·6km Link를 유지할 수 있도록 400G·800G OCS용 Transceiver를 별도로 개발했고, 1.6T 제품으로 확장하는 Roadmap도 제시했습니다.

즉 OCS는 Optical Module을 없애는 Technology가 아닙니다.

오히려 OCS를 포함한 Link Budget을 만족시키는 새로운 Optical Interface가 필요할 수 있습니다.

이것이 OCS와 CPO를 경쟁기술로 보면 안 되는 이유입니다

CPO와 OCS 모두 Optical Technology이기 때문에 비슷한 것으로 보일 수 있지만 해결하는 문제가 완전히 다릅니다.

CPO는 Switch ASIC에서 Optical Engine까지의 Electrical Distance를 줄입니다.

목표는 SerDes Power와 Signal Integrity 문제를 해결하는 것입니다.

OCS는 이미 Optical Signal이 된 이후 어느 Fiber와 어느 Fiber를 연결할 것인지 결정합니다.

따라서 미래 Architecture에서는 두 기술을 동시에 사용할 수 있습니다.

예를 들어 CPO Switch에서 나온 Optical Signal이 OCS를 통과해 다른 Compute Block이나 Switch로 직접 연결되는 구조입니다.

이 경우 Data Path는

Switch ASIC → CPO Optical Engine → OCS → Optical Engine → Destination

이 될 수 있습니다.

중간 OCS에서는 OEO 변환이 필요하지 않습니다.

CPO가 Electrical-to-Optical 변환 위치를 바꾼다면 OCS는 Optical Domain 자체에서 Network Topology를 바꾸는 기술입니다.

Lumentum은 OCS에서 현재 가장 직접적인 상장기업 Exposure 가운데 하나입니다

2026년 들어 OCS가 투자 관점에서 특히 중요해진 이유가 여기에 있습니다.

Lumentum은 R300과 R64라는 상용 OCS 제품군을 운영하고 있습니다. R300은 최대 300×300 Port를 제공하고 R64는 GPU Interconnect와 Data Center 연결을 겨냥한 64×64 Platform입니다. 두 제품 모두 SONiC 기반 Control과 gNMI Management를 지원합니다.

더 중요한 것은 기술 Roadmap이 실제 주문으로 이동했다는 점입니다.

Lumentum은 2026 회계연도 4분기 실적발표에서 OCS 주문잔고가 이미 4억 달러를 크게 넘어섰으며 급증하는 고객수요에 대응해 생산을 확대하고 있다고 밝혔습니다.

FY2026 Lumentum 전체 매출은 약 30억1,400만 달러였습니다. 따라서 4억 달러 이상의 OCS 주문잔고는 회사 규모와 비교해 무시하기 어려운 수준입니다. 다만 주문잔고는 아직 매출로 인식된 금액이 아니며 인도일정과 고객집중도도 확인해야 합니다.

이것이 현재 Lumentum OCS에서 가장 중요한 투자지표입니다.

기술 발표가 아니라 Backlog가 Revenue로 얼마나 빠르게 전환되는가입니다.

Lumentum에서 OCS는 기존 Optical Component 사업과 수익구조가 다릅니다

Lumentum의 전통적인 Data Center Exposure는 EML, CW Laser와 Optical Transceiver 같은 Component 중심이었습니다.

OCS는 System입니다.

실제로 Lumentum은 FY2026 매출을 Components와 Systems로 구분하고 있으며 System 매출은 약 10억800만 달러로 전년의 약 5억2,900만 달러에서 크게 증가했습니다. 다만 이 System Revenue 전체가 OCS는 아닙니다.

OCS가 본격적으로 확대되면 Lumentum의 사업구조에서 의미 있는 변화가 생길 수 있습니다.

Component Supplier에서 AI Network System Supplier로 Value Chain이 올라가기 때문입니다.

그 대신 System 사업에서는 Software, Customer Qualification, Field Support와 Supply Chain Complexity도 함께 증가합니다.

Coherent도 이미 OCS 매출을 시작했습니다

Coherent는 2024년 300×300 Digital Liquid Crystal OCS를 공개했고 2025 회계연도에 OCS Platform에서 첫 매출을 기록했습니다. 당시 회사는 OCS가 2030년까지 자체 Data Center Addressable Market을 20억 달러 이상 확대할 것으로 추정했습니다. 이는 Coherent 자체 시장 전망이라는 점은 구분해서 볼 필요가 있습니다.

2026년 Coherent의 제품군은 64×64부터 320×320까지 확대됐고 512×512 Configuration도 제시되고 있습니다. 회사의 FY2026 10-K에서도 OCS를 AI·ML 및 Hyperscale Data Center용 핵심 개발영역으로 별도 분류하고 있습니다.

다만 현재 Coherent는 OCS 매출을 별도로 공개하지 않습니다.

따라서 Lumentum의 4억 달러 이상 주문잔고와 Coherent의 OCS Revenue를 직접 비교할 수는 없습니다.

Coherent에서 확인해야 할 것은 OCS 전체 매출이 아니라 고객 수, Port Configuration Mix와 Data Center 사업 내 OCS 매출비중이 실제로 확대되는지입니다.

Lumentum과 Coherent의 경쟁은 MEMS 대 Liquid Crystal로 끝나지 않습니다

OCS 고객이 평가할 항목은 매우 많습니다.

평가항목	중요성
Port 규모	한 OCS가 연결할 수 있는 Endpoint 수
Insertion Loss	Optical Link Budget 결정
재구성 특성	Topology 변경 가능속도
신뢰성	대형 Training Job 중단 위험
Wavelength 범위	여러 Optical Standard 지원
양방향성	Fiber 효율
Control Software	SDN 통합
Serviceability	장애복구·유지보수
제조원가	대규모 Deployment 경제성
생산능력	Hyperscaler Volume 공급 여부

즉 Optical Device 성능만으로 시장점유율이 결정되지 않습니다.

특히 AI Infrastructure에서는 수천 대를 안정적으로 생산하고 운영할 수 있는 Manufacturing Scale과 Software Integration이 더 중요해질 수 있습니다.

OCS가 성공하면 Optical Port 수요에는 어떤 영향을 줄까

여기에는 서로 반대되는 두 효과가 존재합니다.

OCS가 Electrical Spine Layer를 제거하면 해당 Spine Switch에 연결되던 일부 Optical Module Pair도 줄어들 수 있습니다.

이는 Optical Unit Demand에 부정적인 효과입니다.

반면 OCS Architecture 자체는 Packet Switching Block 사이에 광연결을 광범위하게 사용하며 Circuit을 유연하게 구성하려면 충분한 Fiber Connectivity가 필요합니다.

또 OCS의 Link Budget을 맞추기 위한 고성능 Transceiver 수요가 발생할 수도 있습니다.

따라서

OCS 확산 = 광모듈 증가

라고 단순화하거나

OCS 확산 = 광모듈 감소

라고 단순화하는 것 모두 위험합니다.

실제 결과는 제거되는 Electrical Hop 수와 새로 구축되는 Direct Optical Circuit 수에 따라 결정됩니다.

OCS의 가장 강력한 경제적 장점은 Stranded Bandwidth를 줄이는 것입니다

네트워크에는 설치돼 있지만 사용되지 않는 Bandwidth가 존재할 수 있습니다.

Fixed Clos Architecture에서는 Traffic Pattern이 바뀌어도 Physical Link 수는 그대로입니다.

어떤 영역은 혼잡하고 다른 영역의 Link는 낮은 Utilization으로 운영될 수 있습니다.

OCS는 사용되지 않는 Physical Connectivity를 다른 Traffic Pair에 재배치할 수 있습니다.

즉 새로운 Switch나 Fiber를 추가하지 않고 기존 Physical Resource의 Utilization을 높일 수 있습니다.

Google Jupiter의 Capex 절감도 단순 OCS Hardware가 Packet Switch보다 싸기 때문만은 아닙니다.

Heterogeneous Capacity를 단계적으로 추가하고 Traffic Demand에 따라 Topology를 조정할 수 있었기 때문입니다.

이것이 OCS의 가장 중요한 Network Economics일 수 있습니다.

Network Upgrade 방식도 달라질 수 있습니다

Fixed Fabric에서는 새로운 Switch Generation을 설치하면 기존 Network의 일부를 한꺼번에 교체해야 하는 문제가 발생할 수 있습니다.

OCS를 사용하면 서로 다른 Speed Generation의 Packet Switching Block을 같은 Fabric 안에 연결하고 필요한 Bandwidth를 재배치하는 방식이 가능합니다.

Google은 Jupiter의 OCS Architecture가 Heterogeneous Technology를 이용한 Incremental Network Build와 Zero-downtime Upgrade를 가능하게 했다고 설명합니다.

AI Network처럼 Upgrade Cycle이 빠른 시장에서는 중요한 장점입니다.

800G Network가 완전히 감가상각되기 전에 1.6T가 도입되고 이후 3.2T가 등장한다면 모든 Fabric을 동시에 교체하는 것은 자본효율이 낮습니다.

OCS는 세대가 다른 Network Block을 연결하는 Optical Patch Fabric의 Software-defined Version처럼 활용될 수 있습니다.

하지만 OCS가 모든 AI Network의 정답은 아닙니다

OCS 투자논리에서 반드시 반대편을 봐야 합니다.

첫 번째 문제는 Traffic Dynamism입니다.

Traffic Pattern이 너무 빠르게 바뀌면 Physical Topology를 계속 변경하는 것이 효율적이지 않습니다.

두 번째는 Circuit Contention입니다.

하나의 출력 Port에 여러 입력이 동시에 직접 연결될 수는 없기 때문에 Scheduling과 Packet Layer가 필요합니다.

세 번째는 Control Complexity입니다.

Topology와 Routing을 동시에 최적화해야 합니다.

네 번째는 Optical Loss Budget입니다.

OCS가 추가될수록 Link에 새로운 Loss가 생깁니다.

다섯 번째는 Port Scale입니다.

Packet Switch ASIC의 Radix와 OCS의 Optical Port Scale이 서로 다른 속도로 발전할 수 있습니다.

여섯 번째는 고객의 Network Software 역량입니다.

Google처럼 자체 SDN과 Workload Scheduler를 모두 개발할 수 있는 Hyperscaler와 일반 Enterprise 고객의 Adoption 난도는 전혀 다릅니다.

가장 큰 진입장벽은 OCS Hardware보다 Hyperscaler의 Software Architecture일 수 있습니다

OCS Box를 구매하는 것은 어렵지 않을 수 있습니다.

어려운 것은 그 Box를 Network 안에서 유용하게 만드는 것입니다.

어떤 GPU Job을 어느 Rack에 배치할지,

어떤 Rack 사이 Bandwidth가 필요할지,

어느 Optical Circuit을 만들지,

Circuit을 바꿀 때 기존 Flow를 어디로 이동시킬지,

Failure가 발생하면 어떤 Topology로 복구할지

를 하나의 Control System에서 관리해야 합니다.

이 때문에 OCS는 일반적인 Ethernet Switch보다 고객의 Software Co-design 요구가 높습니다.

Google의 성공사례가 모든 Cloud Operator에게 그대로 복제될 것이라고 가정해서는 안 되는 이유입니다.

Counter Thesis 1: 102.4T·204.8T Switch가 충분히 싸지면 OCS의 경제성이 줄어들 수 있습니다

Switch ASIC의 단위 Bandwidth당 가격과 전력이 계속 빠르게 낮아진다면 복잡한 Optical Topology Engineering을 도입하는 것보다 기존 Clos Fabric을 더 크게 구축하는 것이 단순하고 저렴할 수 있습니다.

High-radix Switch 역시 Fabric Tier를 줄입니다.

따라서 OCS의 경제성은 절대적인 것이 아니라

Electrical Switching Cost와 Optical Switching Cost 사이의 상대적인 변화

에 의해 결정됩니다.

Tomahawk 6 이후 Switch Silicon의 전력효율이 빠르게 개선되는지 계속 확인해야 합니다.

Counter Thesis 2: 고객 자체 OCS가 상용 Vendor 시장을 제한할 수 있습니다

Google은 OCS의 대표적인 대규모 사용자지만 동시에 자체 Palomar OCS를 개발했습니다.

Hyperscaler는 Network Architecture가 경쟁력에 직접 영향을 준다고 판단하면 Custom Silicon처럼 Optical Switching Hardware도 자체 개발할 수 있습니다.

이 경우 OCS 시장 자체는 커져도 Lumentum이나 Coherent가 확보하는 Merchant Market은 예상보다 작을 수 있습니다.

따라서 Google의 성공사례를 곧바로 OCS Vendor의 TAM으로 연결해서는 안 됩니다.

Technology Adoption과 Merchant Revenue Pool은 별개의 문제입니다.

Counter Thesis 3: OCS의 긴 수명은 신규 설치 후 매출성장률을 낮출 수 있습니다

Data-rate Agnostic은 고객에게 강력한 장점입니다.

그러나 OCS가 800G에서 1.6T, 다시 3.2T까지 그대로 사용될 수 있다면 새로운 Speed Generation이 등장할 때마다 Replacement Demand가 발생하지 않습니다.

초기 설치시장은 강하게 성장하더라도 시장이 성숙한 이후에는 Revenue Growth가 신규 AI Campus 건설에 더 의존할 가능성이 있습니다.

Semiconductor Upgrade Cycle과 다른 Valuation Framework가 필요한 이유입니다.

Counter Thesis 4: OCS가 Packet Switching을 대체한다는 표현 자체가 과장일 수 있습니다

Vendor Marketing에서는 OCS가 기존 Electrical Packet Switch를 대체한다고 표현하는 경우가 있습니다.

실제로는 역할이 다릅니다.

OCS는 Packet Buffering, Routing, Congestion Control을 수행하지 못합니다.

따라서 대부분의 실제 Architecture에서는 Packet Switch를 유지하면서 특정 Spine·Interconnection Layer를 Optical Circuit으로 전환하는 방식이 더 현실적입니다.

OCS TAM을 기존 전체 Data Center Switch 시장과 동일한 규모로 놓는 것은 과도한 가정일 수 있습니다.

현재 투자 관점에서는 Lumentum의 OCS가 가장 흥미로운 이유

현재 공개된 정보 가운데 가장 분명한 상업화 신호는 Lumentum의 주문잔고입니다.

Lumentum은 FY2026 말 기준 OCS Backlog가 4억 달러를 크게 넘어섰다고 밝히며 CPO와 함께 아직 사업 초기단계라고 설명했습니다.

이 숫자에서 확인되는 것은 OCS가 단순 연구주제에서 벗어났다는 사실입니다.

하지만 다음 확인이 더 중요합니다.

주문잔고가 실제 매출로 얼마나 빠르게 전환되는지,

고객이 한두 Hyperscaler에 집중되어 있는지,

R300과 R64 가운데 어떤 제품이 주력인지,

OCS System Gross Margin이 기존 Component 사업보다 높은지,

그리고 기존 Optical Transceiver·Laser 매출과 함께 판매되는 비율이 얼마나 되는지입니다.

이 숫자들이 나와야 OCS가 Lumentum의 구조적인 이익성장 Driver인지 판단할 수 있습니다.

Coherent에서는 OCS 자체보다 Photonics Portfolio와의 결합을 봐야 합니다

Coherent는 Liquid Crystal OCS뿐 아니라 Optical Transceiver, EML, Silicon Photonics와 Laser를 함께 공급합니다.

OCS를 채택하는 고객이 OCS에 최적화된 Transceiver까지 Coherent에서 구매한다면 하나의 AI Network Architecture에서 회사가 확보하는 Content가 증가할 수 있습니다.

Coherent는 이미 OCS 통과시 추가되는 Optical Loss를 고려한 별도 Transceiver 제품을 개발했습니다.

따라서 Coherent의 OCS 투자논리는 Box 판매만의 문제가 아닙니다.

OCS가 회사의 기존 Optical Component와 Module 사업의 Attach Rate를 높이는 Platform 역할을 하는지가 더 중요한 문제입니다.

Broadcom과 NVIDIA에서는 OCS Adoption을 Risk이자 새로운 Optical Opportunity로 봐야 합니다

OCS가 Electrical Spine ASIC 수를 줄이면 Broadcom과 NVIDIA의 Switch Silicon에는 부정적인 영향을 줄 수 있습니다.

반면 OCS까지 Data가 도달하려면 Optical Interface가 필요합니다.

CPO와 1.6T·3.2T Optics가 확대되면 Broadcom의 Silicon Photonics·Optical DSP·Laser에는 또 다른 기회가 생길 수 있습니다.

NVIDIA 역시 Spectrum-X Photonics를 통해 Electrical-to-Optical Conversion을 Switch 가까이 이동시키고 있습니다.

따라서 OCS가 커지는 환경에서는 Networking Revenue Pool이 사라지는 것이 아니라 Packet Processing Silicon에서 Optical Connectivity 쪽으로 일부 이동할 가능성이 있습니다.

Broadcom처럼 양쪽 Portfolio를 모두 가진 업체에서는 Cannibalization과 Content Capture를 동시에 분석해야 합니다.

투자자가 OCS에서 실제로 추적해야 할 지표

첫 번째는 상용 OCS 주문잔고와 매출 전환입니다. 현재 가장 구체적인 지표는 Lumentum의 4억 달러 이상 주문잔고입니다.

두 번째는 고객 수와 고객집중도입니다. 단일 Hyperscaler Architecture인지 Multi-customer Standard로 확산되는지가 시장 크기를 결정합니다.

세 번째는 OCS Port 규모입니다. 64×64, 300×300을 넘어 512×512 이상으로 얼마나 안정적으로 확장되는지 중요합니다.

네 번째는 Insertion Loss입니다. Loss가 높아지면 Transceiver Power와 Reach에 직접 영향을 줍니다.

다섯 번째는 Topology 재구성 Software입니다. OCS Hardware보다 실제 Cluster 효율을 결정할 수 있습니다.

여섯 번째는 전기식 Spine 제거 비율입니다. 실제 Switch ASIC TAM Cannibalization을 판단하는 핵심입니다.

일곱 번째는 OCS당 Optical Attach입니다. OCS 확산이 Transceiver와 Laser Revenue를 얼마나 추가하는지 확인해야 합니다.

여덟 번째는 신규 AI Cluster 가운데 OCS 채택비율입니다.

아홉 번째는 OCS의 교체주기입니다. Data-rate Agnostic Architecture가 Vendor의 반복매출에 어떤 영향을 주는지 중요합니다.

열 번째는 Hyperscaler 자체개발 비중입니다. Merchant OCS Vendor의 실제 TAM을 결정합니다.

OCS에서 가장 중요한 산업 변화는 Network Topology가 Hardware에서 Software로 이동한다는 것입니다

지금까지 Network Software는 주어진 Physical Infrastructure를 어떻게 사용할지 결정했습니다.

OCS에서는 Software가 Physical Infrastructure의 연결관계까지 변경합니다.

이 차이는 생각보다 큽니다.

GPU Scheduler가 Compute Placement를 결정하고,

Network Controller가 Traffic Demand를 예측하고,

OCS Controller가 Optical Circuit을 만들며,

Packet Switch와 NIC가 만들어진 Topology 위에서 실제 Traffic을 전달하게 됩니다.

결국 AI Cluster Scheduling과 Network Topology가 하나의 Optimization Problem으로 수렴합니다.

이것은 AI Infrastructure에서 Network가 단순 Packet Transport Layer에서 Compute Scheduling의 일부로 이동하고 있다는 의미입니다.

AI Infrastructure에서 OCS가 위치하는 Layer

OCS는 AI Infrastructure의 Reconfigurable Network Fabric Layer에 위치합니다.

Packet Switch보다 아래의 단순 Physical Component도 아니고 일반 Optical Transceiver와도 다릅니다.

Physical Connectivity를 Software에서 재구성하면서 Packet Network의 Topology 자체를 변경합니다.

Upstream에서는 MEMS, Liquid Crystal, Precision Optics, Fiber Array와 Optical Manufacturing이 필요합니다.

Downstream에서는 800G·1.6T·3.2T Transceiver, CPO, Packet Switch와 AI NIC가 연결됩니다.

System Layer에서는 SDN, Workload Scheduler와 Topology Engineering Software가 필요합니다.

그리고 최종 Demand는 수천~수십만 개 GPU·TPU·XPU를 하나의 Training Domain으로 묶으려는 Hyperscaler에서 발생합니다.

Google의 Jupiter와 Ironwood가 중요한 이유는 OCS가 이론적 Architecture가 아니라는 점을 이미 증명했기 때문입니다. Jupiter에서는 OCS가 10년 이상 Production Network Evolution의 핵심 요소로 사용됐고, 현재 Ironwood에서는 최대 9,216 TPU를 하나의 Superpod으로 연결하는 재구성 가능한 Fabric의 핵심 역할을 맡고 있습니다.

2026년에 새롭게 확인되는 것은 이 Architecture가 Google 내부에서만 머물지 않고 있다는 점입니다.

Lumentum은 OCS 주문잔고가 4억 달러를 넘어섰고 Coherent 역시 이미 Liquid Crystal OCS에서 매출을 시작했습니다.

따라서 이제 OCS의 핵심 투자질문은 기술 가능성이 아닙니다.

Google에서 검증된 재구성형 Optical Fabric이 얼마나 많은 AI Cluster Architecture로 확산되는가.

그 과정에서 전기식 Spine Switch가 실제로 얼마나 줄어드는가.

줄어드는 Packet Switching Value보다 OCS·Optical Module·Laser·Control Software에서 새로 생기는 Value가 더 큰가.

그리고 그 새로운 Revenue Pool을 Lumentum·Coherent 같은 Merchant OCS 업체가 가져가는가, 아니면 Hyperscaler가 자체 Hardware로 내부화하는가.

이 질문의 답에 따라 OCS는 단순한 Optical Component 시장으로 끝날 수도 있고, AI 데이터센터의 Network Architecture 자체를 재편하는 새로운 Infrastructure Layer가 될 수도 있습니다.

OCS의 가장 중요한 특징은 Packet을 더 빠르게 처리한다는 것이 아닙니다.

Packet이 이동해야 할 물리적인 길 자체를 바꾼다는 것입니다.