FEC란? 1.6T AI 네트워크가 데이터 오류를 스스로 고치는 방법

AI Network가 800G와 1.6T로 올라가면서 Signal을 완벽하게 깨끗하게 만드는 것은 점점 비효율적이 되고 있습니다. PAM4는 높은 Bandwidth를 제공하지만 Voltage Margin이 작아 Raw BER가 NRZ보다 높아질 수 있고, 224G-class Electrical Lane과 200G-class Optical Lane에서는 작은 Noise와 Jitter도 Error Probability를 높입니다.

이때 Network는 Error가 절대 발생하지 않게 만드는 대신 일정 수준의 Error를 허용하고 Receiver가 스스로 수정하는 방식을 사용합니다.

이 기술이 FEC(Forward Error Correction)입니다.

FEC: Sender가 원본 Data에 추가적인 Error-correction Code를 함께 전송하고 Receiver가 이를 이용해 일부 Bit 또는 Symbol Error를 재전송 없이 직접 복구하는 기술입니다.

쉽게 말하면 Data에 정답을 복원할 수 있는 여분의 힌트를 함께 보내는 것입니다.

AI Network에서 FEC가 중요한 이유는 단순 Reliability뿐 아니라 Retransmission을 줄여 Effective Bandwidth와 Latency를 유지할 수 있기 때문입니다.

FEC를 먼저 한눈에 보면

구분	설명
목적	전송 중 발생한 Error를 Receiver가 직접 수정합니다
방식	Data와 함께 Redundant Code를 전송합니다
장점	Packet Retransmission 없이 일부 Error를 복구할 수 있습니다
비용	Encoding·Decoding Logic, Bandwidth Overhead, Power와 Latency가 추가됩니다
주요 적용	Ethernet, Optical Link, PCIe 6, Storage 등
AI에서 중요한 이유	PAM4 High-speed Link의 Raw BER를 현실적인 System Reliability로 바꾸기 때문입니다

FEC는 단순히 “Error가 나면 고쳐준다”는 기능보다 훨씬 중요합니다. FEC가 있기 때문에 더 공격적인 High-speed Physical Link를 사용할 수 있기 때문입니다.

Error Correction은 어떻게 가능한 걸까요?

Sender가 원본 Data만 보내면 Receiver는 Bit가 틀렸다는 사실을 알아도 원래 값이 무엇이었는지 알 수 없습니다.

그래서 FEC는 원본 Data를 일정 Block으로 묶고 추가 Parity Symbol을 생성합니다.

Receiver는 Data와 Parity 사이의 수학적 관계를 이용해 일부 Symbol이 틀려도 원래 값을 계산해낼 수 있습니다.

대표적인 방식 중 하나가 Reed-Solomon Code입니다.

Reed-Solomon FEC: 여러 Bit를 하나의 Symbol로 묶고 일정 수의 Parity Symbol을 추가해 제한된 수의 Symbol Error를 복구하는 Block Code 방식입니다.

Ethernet High-speed Optical Link에서 오랫동안 사용돼온 FEC도 Reed-Solomon 계열입니다.

RS(544,514)는 무엇을 의미할까요?

High-speed Ethernet 문서에서 자주 보이는 표현이 RS(544,514)입니다.

이는 514개의 Data Symbol을 544개의 Total Symbol로 Encoding하는 Reed-Solomon Code 구조를 의미합니다. 추가된 30개의 Symbol이 Error Correction을 위한 Redundancy입니다.

전통적인 IEEE 802.3 400G Ethernet의 특정 Physical Layer에서는 이 RS(544,514) 계열 FEC가 사용됐고 제한된 수의 Symbol Error를 Correction할 수 있습니다.

다만 중요한 주의점이 있습니다.

1.6T Ethernet 전체가 언제나 동일한 RS(544,514), 동일 Correction Capability를 사용한다고 일반화하면 안 됩니다. Ethernet Generation과 PMD, Lane Architecture에 따라 FEC 구조가 달라질 수 있습니다.

따라서 FEC를 설명할 때 특정 Code를 모든 1.6T Link에 적용되는 Universal Rule처럼 표현해서는 안 됩니다.

왜 FEC가 있으면 더 높은 BER를 허용할 수 있을까요?

FEC가 없다면 Receiver가 Error를 거의 만들지 않는 매우 깨끗한 Physical Channel이 필요합니다.

이를 위해 더 강한 Signal, 더 짧은 Cable, 더 많은 Equalization과 더 비싼 Component가 필요할 수 있습니다.

FEC가 있으면 Channel에서 일정 수준의 Raw Error가 발생해도 Decoder가 수정할 수 있습니다.

즉 System Designer는 Physical Layer Margin 일부를 FEC에 맡기고 더 높은 Speed를 사용할 수 있습니다.

이 때문에 FEC를 Coding Gain의 관점에서 설명하기도 합니다.

Coding Gain: Error Correction Code를 사용함으로써 동일한 최종 BER를 더 낮은 Signal Quality에서도 달성할 수 있게 되는 효과입니다.

하지만 FEC는 공짜가 아닙니다

Parity를 추가하기 때문에 실제 Data 외의 Bit가 함께 전송됩니다. 즉 Bandwidth Overhead가 있습니다.

Encoder와 Decoder Logic도 필요합니다.

특히 Decoder는 Error 위치를 찾고 값을 복구해야 하기 때문에 Latency와 Power를 사용합니다.

따라서 FEC를 무조건 강하게 만들면 좋은 것이 아닙니다.

AI Network에서는 매우 낮은 Latency가 중요하기 때문에 필요한 Reliability를 만족하면서 가장 낮은 Latency와 Power를 갖는 FEC가 중요합니다.

이것이 Ethernet과 PCIe가 각각 자신의 Workload에 맞는 Coding 구조를 사용하는 이유입니다.

PCIe 6의 FEC는 Ethernet FEC와 동일하지 않습니다

PCIe 6.0도 PAM4로 전환하면서 FEC를 도입했습니다.

하지만 PCIe는 CPU, GPU, NIC, CXL Memory 같은 Device 사이에서 매우 낮은 Latency를 요구합니다.

그래서 PCI-SIG는 PCIe 6.0에 Lightweight FEC와 Strong CRC, Link-level Retry를 결합했습니다.

PCI-SIG는 64GT/s PAM4에서 이전 NRZ 세대보다 Raw BER가 크게 높아질 수 있기 때문에 FEC와 CRC가 필요하며, 이를 위해 256-byte FLIT Mode를 도입했다고 설명합니다.

즉 PCIe의 목표는 매우 강한 FEC 하나로 모든 Error를 수정하는 것이 아니라 짧은 FEC Latency와 강한 Error Detection, 빠른 Retry를 조합해 전체 Reliability를 확보하는 것입니다.

이 차이는 매우 중요합니다.

왜 PCIe 6에서는 FLIT Mode까지 필요했을까요?

FEC는 일반적으로 고정된 크기의 Data Block을 처리하기 쉽습니다.

기존 PCIe Packet은 크기가 다양했습니다.

그래서 PCIe 6.0은 Data를 256-byte FLIT라는 고정 단위로 묶어 전송합니다.

FLIT(Flow Control Unit): PCIe 6.0에서 FEC와 CRC를 효율적으로 적용하기 위해 도입된 256-byte 고정 Data Transfer Unit입니다.

PCI-SIG는 64GT/s PAM4에서 FLIT Mode가 필수이며 한 번 Link가 FLIT Mode로 Train되면 LinkUp 상태에서 계속 해당 Mode를 유지한다고 설명합니다.

즉 Physical Layer의 PAM4 전환이 Data Link Architecture까지 바꿨습니다.

Ethernet에서는 왜 FEC가 더 오래 사용됐을까요?

Optical Communication은 Fiber, Laser, Modulator와 Receiver를 통과하면서 Noise와 Distortion이 발생합니다.

Data Rate가 올라갈수록 Receiver Sensitivity Margin이 작아지고 Optical Budget도 어려워집니다.

그래서 Ethernet Optical Link는 이미 여러 Generation에서 FEC를 사용해왔습니다.

400G와 800G, 1.6T로 올라가면서 FEC는 더 중요한 Design Component가 됐습니다.

즉 현대 Optical Network의 Bandwidth Roadmap은 SerDes Speed와 Optical Component뿐 아니라 FEC Coding Capability가 함께 만들어낸 결과입니다.

FEC Threshold를 넘으면 어떤 일이 생길까요?

FEC는 무한한 Error를 고칠 수 없습니다.

Correction Capability를 넘는 Error가 한 Codeword에 몰리면 Decoder가 복구하지 못합니다.

이때 Uncorrectable Codeword가 발생하고 상위 Layer에서 Packet Drop이나 Retry가 필요할 수 있습니다.

따라서 Link Margin을 볼 때는 단순 평균 Pre-FEC BER뿐 아니라 Error Distribution이 중요합니다.

Random Error와 Burst Error는 FEC에 미치는 영향이 다를 수 있습니다.

이것이 Interleaving과 Error Distribution Control이 중요한 이유입니다.

Burst Error는 왜 어려울까요?

Random Error가 멀리 떨어져 발생하면 여러 Codeword에 분산될 수 있습니다.

하지만 Noise Event나 Crosstalk 때문에 Error가 특정 짧은 구간에 몰리면 하나의 Codeword가 Correction Limit를 넘을 수 있습니다.

Burst Error: 짧은 시간이나 연속된 Symbol 구간에 Error가 집중적으로 발생하는 현상입니다.

High-speed Link에서는 Connector Resonance, Power Noise, Optical Impairment 같은 원인이 Burst Error를 만들 수 있습니다.

따라서 FEC Validation에서는 평균 BER 숫자만 보는 것보다 실제 Error Pattern까지 확인할 필요가 있습니다.

FEC가 강하면 Link Reach를 늘릴 수 있을까요?

일정 부분 가능합니다.

더 강한 FEC는 낮은 Signal-to-noise Ratio에서도 Post-FEC BER Requirement를 만족할 수 있게 해줍니다.

이는 Optical Reach나 Channel Margin을 늘릴 수 있습니다.

하지만 Decoder Complexity와 Latency, Power가 증가합니다.

따라서 장거리 Telecom Network와 Short-reach AI Interconnect가 같은 FEC를 사용하는 것은 합리적이지 않을 수 있습니다.

AI Network는 매우 큰 Bandwidth를 짧은 거리에서 낮은 Latency로 사용하므로 Short-reach에 최적화된 Coding Trade-off가 중요합니다.

FEC와 LPO는 긴밀하게 연결됩니다

LPO는 Module 내부의 Full Retimer DSP를 줄여 Power와 Latency를 낮추려는 Architecture입니다.

그만큼 Host SerDes와 Optical Component의 Signal Margin에 더 많이 의존합니다.

이때 FEC가 최종 Reliability를 지탱하는 중요한 안전망이 됩니다.

하지만 Pre-FEC BER가 Correction Threshold에 너무 가까우면 Temperature나 Manufacturing Variation만으로도 Link Reliability가 불안정해질 수 있습니다.

따라서 LPO의 실제 성공여부는 FEC Margin을 충분히 확보하면서 DSP Power를 줄일 수 있는가에 달려 있습니다.

FEC와 CPO도 연결됩니다

CPO는 Switch ASIC과 Optical Engine 사이 Electrical Channel을 짧게 만들어 Signal Integrity를 개선할 수 있습니다.

Electrical Side BER Margin이 좋아지면 Link Power를 줄일 여지가 생길 수 있습니다.

하지만 Optical Link 자체의 Error Correction은 여전히 필요합니다.

또 Optical Engine이 Package 가까이 들어갈수록 Fleet-level FEC Telemetry를 이용한 Predictive Maintenance가 중요해질 수 있습니다.

CPO의 Serviceability를 개선하려면 고장난 Optical Path를 완전히 실패하기 전에 찾아야 하기 때문입니다.

FEC Counter는 데이터센터 운영에 중요한 Telemetry입니다

Network Device는 단순히 Link Up/Down만 보고하지 않습니다.

Corrected Codeword Count, Uncorrectable Codeword Count, Pre-FEC BER Estimate 같은 정보를 제공할 수 있습니다.

이 데이터를 시간에 따라 보면 특정 Link의 Margin이 서서히 악화되는지 확인할 수 있습니다.

예를 들어 Optical Module Laser가 Aging되거나 Connector가 오염되면 Corrected Error가 점차 증가할 수 있습니다.

Application에는 아직 Error가 보이지 않지만 운영팀은 이를 조기에 감지할 수 있습니다.

즉 FEC는 Error Correction 기능이면서 Network Health Sensor 역할도 합니다.

AI Cluster에서 이 Telemetry가 중요한 이유

GPU 수만 개가 연결된 Cluster에서는 모든 Link를 사람이 직접 점검할 수 없습니다.

일부 Link의 FEC Error가 증가하면 Training Job의 Tail Latency가 불규칙하게 악화될 수 있습니다.

이런 문제는 GPU Software Bug처럼 보일 수도 있습니다.

따라서 NIC와 Switch, Optical Module의 FEC Telemetry를 Fleet-level로 분석해 이상 Link를 자동으로 찾는 Software가 중요해집니다.

Network Semiconductor 업체들이 Hardware뿐 아니라 Telemetry Platform까지 제공하려는 이유입니다.

Marvell은 RELIANT 같은 Interconnect Telemetry Platform을 통해 Optics, DSP, Switch, PCIe Retimer, NIC의 Link Health를 통합적으로 분석하는 방향을 추진하고 있습니다.

FEC는 Switch ASIC에도 Silicon Area를 사용합니다

100Tbps급 Switch는 엄청난 수의 High-speed Port를 동시에 처리합니다.

각 Port의 FEC Encoder와 Decoder도 매우 높은 Throughput을 처리해야 합니다.

따라서 FEC Logic의 Area와 Power Efficiency가 Switch Silicon 경쟁력에 영향을 줄 수 있습니다.

1.6T Port 수가 증가할수록 FEC 처리량도 증가합니다.

즉 FEC는 Protocol Specification의 작은 기능이 아니라 Switch ASIC Power Budget에 실제 영향을 주는 Hardware Block입니다.

Optical DSP에서도 FEC는 중요한 차별화 요소입니다

Retimed Optical Module에서는 DSP가 Equalization, Gearbox와 함께 FEC 관련 Processing을 담당할 수 있습니다.

DSP Power를 줄이면서 충분한 Coding Gain을 유지하는 것이 중요합니다.

Broadcom과 Marvell 같은 Optical DSP 업체가 800G·1.6T Generation에서 Process Node와 DSP Architecture를 개선하는 이유도 전체 Module Power를 줄이기 위해서입니다.

LPO는 이 DSP를 줄이는 방향이고 Full Retimed Module은 강한 DSP를 유지하는 방향입니다.

결국 FEC Architecture도 Optics Product Mix와 연결됩니다.

FEC가 강해지면 더 느려질까요?

일반적으로 더 복잡한 Coding은 더 많은 Logic과 Processing Step을 요구할 수 있습니다.

하지만 실제 Latency는 Architecture와 Implementation에 따라 다릅니다.

AI Network에서는 몇 ns에서 수십 ns의 추가 Latency도 대규모 Collective Communication에 누적될 수 있습니다.

따라서 Vendor들은 Coding Gain뿐 아니라 Decoder Latency를 중요한 Design Target으로 봅니다.

특히 PCIe와 CXL은 Memory·Device Access Latency에 민감하기 때문에 Lightweight FEC를 사용합니다.

즉 Network와 Memory Interconnect에서 FEC Strength와 Latency Requirement가 서로 다릅니다.

투자 관점에서는 FEC 자체보다 FEC가 필요하게 만드는 고속화가 중요합니다

FEC Algorithm은 표준화돼 있는 경우가 많습니다.

따라서 “FEC 시장”이라는 단독 Theme보다 고속 PAM4 Link가 확대되면서 어떤 Silicon Content가 증가하는지 보는 것이 정확합니다.

Layer	FEC와 연결되는 Value
Switch ASIC	Multi-port FEC Encoder·Decoder Logic
Optical DSP	High-speed Equalization·Coding·Telemetry
NIC	Ethernet FEC와 Error Monitoring
PCIe/CXL	Lightweight FEC·CRC·Retry Logic
Test	Pre/Post-FEC BER와 Error Injection Validation
Operation Software	FEC Counter 기반 Predictive Maintenance

즉 FEC는 AI Connectivity가 단순 Speed 경쟁에서 Reliability Engineering 경쟁으로 이동하고 있다는 증거입니다.

앞으로 볼 것은 1.6T에서 FEC Power 비중입니다

Port Speed가 계속 올라가면 FEC Logic도 더 많은 Data를 처리합니다.

Switch와 Optical Module의 Power Budget 안에서 FEC가 차지하는 비중이 커질 수 있습니다.

따라서 더 효율적인 Decoder Architecture와 Process Node가 중요합니다.

1.6T·3.2T 세대로 이동할수록 FEC 성능뿐 아니라 Energy per corrected bit도 경쟁요소가 될 수 있습니다.

두 번째는 FEC Telemetry 표준화입니다

Multi-vendor AI Network에서는 서로 다른 Switch와 NIC, Optical Module의 Error Counter를 통합해서 해석해야 합니다.

Telemetry Format이 표준화될수록 Hyperscaler가 Network Health를 자동화하기 쉬워집니다.

이는 Open Ethernet과 UEC Ecosystem에서도 중요한 운영요소가 됩니다.

세 번째는 FEC와 Retransmission의 균형입니다

모든 Error를 FEC로 수정하려고 하면 Decoder가 너무 무거워질 수 있습니다.

반대로 FEC를 너무 약하게 하면 Retry와 Retransmission이 증가합니다.

차세대 AI Transport에서는 Physical FEC와 Packet-level Selective Retransmission을 함께 최적화하는 방향이 중요해질 수 있습니다.

즉 Reliability를 하나의 Layer에서 해결하지 않고 PHY Coding과 Transport Recovery를 함께 설계하게 됩니다.

핵심 정리

질문	답
FEC란?	Data에 Redundant Code를 추가해 Receiver가 일부 Error를 재전송 없이 수정하는 기술입니다
왜 필요한가요?	PAM4 High-speed Link에서 일정 Raw BER를 허용하면서 최종 Reliability를 유지하기 위해서입니다
Reed-Solomon FEC란?	Symbol 단위 Parity를 이용해 제한된 Symbol Error를 복구하는 Block Code입니다
모든 1.6T가 같은 FEC를 쓰나요?	아닙니다. Ethernet Generation과 PMD Architecture에 따라 FEC 구조가 달라질 수 있습니다
PCIe 6에도 FEC가 있나요?	있습니다. 낮은 Latency를 위해 Lightweight FEC, Strong CRC와 Retry를 결합합니다
단점은?	Bandwidth Overhead, Silicon Area, Power와 Latency가 추가됩니다
투자포인트는?	1.6T·PCIe 6 고속화에 따른 FEC Logic, Optical DSP, Telemetry와 Test Complexity 증가입니다

FEC는 High-speed Network의 실패를 보완하는 기술이 아니라 High-speed Network를 가능하게 만드는 전제조건에 가깝습니다.

PAM4를 사용하면 더 적은 Lane으로 더 높은 Bandwidth를 만들 수 있지만 Raw BER는 관리하기 어려워집니다. FEC는 그 Error를 일정 범위 안에서 직접 수정해 System이 안정적으로 동작하도록 만듭니다.

이 덕분에 Industry는 Physical Channel을 비현실적으로 완벽하게 만들지 않고도 800G와 1.6T, PCIe 6 같은 속도를 현실적인 Cost와 Power로 구현할 수 있습니다.

하지만 FEC에도 한계가 있습니다. Channel이 너무 길거나 손실이 너무 크면 Error가 Correction Capability를 넘어섭니다. 결국 Signal을 중간에서 다시 깨끗하게 만들어야 합니다.

그 역할을 하는 Semiconductor가 바로 Retimer입니다.