AI 데이터센터는 GPU를 한 장씩 사지 않습니다. 가속기가 도착하기 수년 전에 전력 총량을 먼저 확보하고, 그 한도 안에서 유효한 모델 토큰을 얼마나 생산할지 결정합니다. Meta가 2026년에 공개한 논문은 이 과정을 보기 드문 해상도로 기록합니다. 약 30 MW짜리 건물 다섯 동, GB200 GPU 약 8만3천 장, 총 150 MW 규모입니다[1]. 더 큰 1 GW 캠퍼스의 일부지만, 핵심 결론은 간단합니다. GPU 한 장의 벤치마크를 가장 빠르게 만드는 전력 설정이 클러스터 전체 처리량을 가장 높이지는 않습니다.

저자들은 용량 계획, 구축 검증, 실제 운영을 차례로 따라갑니다. 새로운 냉각 장치나 가속기가 주인공은 아닙니다. 같은 시설 한도에서 처리량을 약 14% 높이는 의사결정의 조합이 주제입니다. 낮은 초기 전력으로 GPU를 더 많이 설치해 약 10%를 얻고, 계측으로 여유분을 확인한 뒤 약 2%를 되찾으며, 런타임 제어로 다시 약 2%를 추가합니다. 이 계산은 전력을 구매 단계에서 정해지는 고정 제약이 아니라 운영 중에 배분할 수 있는 클러스터 자원으로 다룹니다.

1,200 W보다 빠른 960 W 클러스터

GB200의 GPU 전력 상한은 1,200 W지만 Meta는 960 W를 기준으로 구축했습니다. 한 장만 보면 손해가 작고, 건물 전체에서는 이득이 크기 때문입니다. 설정을 1,200 W에서 1,000 W로 낮추면 GPU당 성능은 약 5% 줄지만 전력 예산은 16.7% 감소합니다. 900 W에서는 성능이 약 12%, 전력 한도가 25% 줄어듭니다. GPU 한 장이 요구하는 몫이 작을수록 같은 시설에 더 많은 장치를 넣을 수 있으므로, 클러스터 처리량의 최댓값은 장치 성능의 최댓값보다 낮은 전력에서 나옵니다.

논문은 150 MW 안에 700 W H100을 넣는 경우를 기준값으로 삼습니다. GB200을 1,200 W로 계획하면 약 7만4천 장이 들어가며 H100 대비 총 처리량은 1.7배입니다. 960 W에서는 약 8만6천 장을 계획할 수 있고 총 처리량이 1.9배로 오릅니다. GPU마다 조금 느려져도 1,200 W 설계보다 클러스터 전체 작업량은 약 11% 많습니다. 네트워크 스위치의 radix와 실제 배치 조건 때문에 최종 수량은 약 8만3천 장이 됐지만, 이 결론은 바뀌지 않습니다.

여기에는 GPU가 아닌 모든 부하도 들어가야 합니다. 백엔드와 프런트엔드 네트워크가 150 MW의 8~9%를 씁니다. Catalina 연산 pod는 두 랙에 GB200 72장을 넣어 하나의 NVLink 도메인을 만들고, 별도의 공조 보조식 액체 냉각(AALC) 랙 두 개와 짝을 이룹니다. 건물에 시설 냉수가 없기 때문입니다. Grace CPU마다 백엔드용 400 Gb/s ConnectX-7 인터페이스 두 개와 프런트엔드용 200 Gb/s 연결도 붙습니다[2]. 이 경로에 예약한 전력은 GPU에 다시 배정할 수 없습니다.

고정된 150 MW가 8만3천 GPU 클러스터로 바뀌는 과정. a, 약 30 MW짜리 건물 다섯 동이 전체 전력을 구성하고 프런트엔드와 백엔드 네트워크가 8~9%를 씁니다. b, Catalina pod 하나는 두 연산 랙의 GB200 72장과 공조 보조식 액체 냉각 랙 두 개를 묶습니다. c, 같은 시설 한도에서는 960 W 설계가 GPU를 더 많이 수용해 1,200 W 설계보다 총 처리량을 약 11% 높입니다. 이 글을 위해 새로 만든 도판.

용량 계획은 예측이고, 구축 검증은 실측

Meta는 전력 운영을 세 시간대로 나눕니다. 계획은 차세대 가속기가 나오기 6~12개월 전에 시작하며, 이때는 실측값 대신 모델을 씁니다. 장비를 설치한 뒤에는 랙과 시설 계측을 맞춰 가정을 검증합니다. 실제 운영에서는 짧게 나타나는 여유 전력을 차단기와 작업에 위험을 주지 않는 범위에서 활용합니다.

구축 단계에서는 명판 전력의 단순 합계가 충분하지 않은 이유가 드러났습니다. 랙 전원공급장치의 텔레메트리는 상위 원격 전력 패널(RPP)의 계측값보다 계속 높았습니다. Meta는 두 값을 보정하고, 최댓값보다 70백분위 집계가 공유 부하를 더 잘 나타낸다고 판단했습니다. 8만3천 장에 보수적인 오차가 반복되면 실제 작업에 쓸 수 있는 수 MW가 그대로 묶입니다.

전력 배전 구조는 건물 총량이 남아 있어도 국소 한도를 만듭니다. 전력은 주배전반(MSB), RPP, 랙 순서로 흐르며 가장 여유가 적은 요소가 다음 1 W의 사용 가능 여부를 정합니다. 실제로 MSB의 13%는 남은 용량이 50 kW 미만이었습니다. MSB의 평균 여유는 약 160 kW, 해당 배전반 아래 GPU당 약 100 W였지만 RPP에는 GPU당 두 배가 넘는 여유가 있었습니다. 따라서 캠퍼스 총량이 충분해 보여도 불균형 때문에 계획 용량의 5~10%가 쓰이지 못할 수 있습니다.

그래도 실측 결과는 GPU 설정을 960 W에서 1,020 W로 올릴 근거가 됐습니다. 설치 수량을 바꾸지 않고 예상 성능을 2~3% 되찾는 조치입니다. 순서가 중요합니다. 처음에는 낮은 전력 한도로 물리적 수량을 확보하고, 구축 후 감사에서 안전하다고 확인한 여유만 연산에 다시 배정합니다.

전력 파형을 먼저 펴고, 남은 봉우리를 낮추는 방식

대규모 동기식 작업의 소비전력은 일정하지 않습니다. 연산 구간에는 수많은 GPU의 부하가 함께 오르고, 통신 구간에는 함께 내립니다. 평균이 한도 아래여도 클러스터 전체가 동시에 전환하면 짧은 시간에 큰 전력 변동이 발생합니다. 차단기는 짧은 과부하를 견디지만, 논문이 제시한 동작 범위는 약 1.2배에서 45초 또는 2배에서 30초 수준입니다. 긴 평균값을 본 뒤 반응하는 제어기로는 이 시간대를 지킬 수 없습니다.

이 문제는 건물 안에서 끝나지 않을 수 있습니다. Llama 3 보고서는 GPU 2만4천 장이 동기화된 연산 구간에 들어가거나 빠질 때 소비전력이 수십 MW 단위로 변할 수 있다고 설명했고, SemiAnalysis는 같은 부하 형태를 데이터센터 내부가 아니라 전력망 연결 문제까지 확장해 분석했습니다[5][6]. 따라서 무효 연산을 이용한 평탄화 비용은 낭비라는 이유만으로 판단할 수 없습니다. 제어하지 않은 전력 변화 때문에 상위 계통에 남겨야 할 안전 여유와 함께 비교해야 합니다.

Meta는 두 메커니즘을 함께 씁니다. Power Smoother는 통신 구간의 골에 레지스터만 쓰는 텐서 코어 명령을 채웁니다. HBM이나 L2를 건드리지 않으며 실제 모델 계산에도 기여하지 않지만, 전력이 급격히 떨어졌다가 다시 솟는 현상을 줄입니다. 적응형 후퇴 제어가 사용 가능한 한도를 지키며, 애플리케이션 성능 손실은 3% 미만입니다. 소량의 무효 연산을 허용해 더 큰 시설 안전 여유를 줄이는 선택입니다.

Dimmer는 남은 봉우리를 처리합니다. 장치 계측이 적용 한도의 97%를 넘으면 7초 평균을 사용해 GPU 상한을 점진적으로 조절합니다. 이때 작업 단위 조정이 필수입니다. GPU 한 장만 늦추면 분산 학습의 지연 작업자가 되고, 나머지 GPU는 전력을 쓰면서 기다립니다. Dimmer는 스케줄러와 작업 정보를 이용해 같은 작업의 랭크를 함께 조절합니다. 상시 비워 두던 단기 여유를 안전하게 쓰면서 클러스터 처리량을 약 2% 더 높입니다.

세 단계의 처리량 개선. 계획 단계에서는 960 W를 선택해 설치 밀도를 높이고 1,200 W 계획보다 클러스터 처리량을 약 10% 늘립니다. 구축 검증에서는 랙 계측을 시설 계측기와 보정하고 국소 병목을 찾아 1,020 W로 올려 약 2%를 더합니다. 실행 중에는 Power Smoother가 통신 구간의 전력 하강을 줄이고 Dimmer가 7초 단위로 작업의 전력 상한을 함께 조절해 약 2%를 추가합니다. 이 글을 위해 새로 만든 도판.

운영자가 가져갈 것

다른 시설이 복제해야 할 것은 960 W라는 숫자가 아닙니다. 이 값은 특정 가속기, 작업 구성, 네트워크, 건물에 속합니다. 복제할 대상은 최적화의 경계입니다. 목표가 장치 성능이면 가장 높은 안정 전력 설정이 답입니다. 시설 한도 안에서 완료한 클러스터 작업량이 목표라면 GPU 수량, 비연산 부하, 배전 계층, 작업의 동기성, 국소 불균형까지 함께 계산해야 합니다.

이 경계는 텔레메트리의 역할도 바꿉니다. 랙 센서, RPP 계측기, MSB 한도는 같은 자원 그래프의 서로 다른 구간을 나타냅니다. 어느 한 값만 절대값으로 쓰면 과부하 위험을 만들거나 용량을 묶습니다. 약 14%의 개선은 시간대를 연결해 얻은 결과입니다. 먼저 보수적으로 예측하고, 구축 후 측정하며, 확인한 여유만 작업 단위 제어로 사용합니다.

물론 1.9배라는 비교는 Meta의 작업 특성과 특정 세대 전환을 전제로 합니다. 지연시간에 민감한 추론 서비스는 마지막 수십 W의 가치를 다르게 평가할 수 있습니다. Power Smoother도 평탄한 전력 파형을 얻기 위해 에너지를 더 쓰므로 전력 요금, 냉각, 차단기 구조에 따라 득실이 달라집니다. 다만 100MW 규모에서는 전력을 클러스터 외부의 고정 조건으로만 볼 수 없습니다. 설비 계획과 계측, 스케줄링을 함께 최적화해야 실제 처리량이 결정됩니다.

다음 100 MW를 위한 구축 검증 모델

이 논문은 몇 W로 설정했는지를 외우기보다 구축 검증 모델로 옮겨 쓸 때 가치가 큽니다. 먼저 네 장의 원장을 분리해야 합니다. 첫째 원장에는 건물별로 계약한 시설 전력을 기록합니다. 둘째 원장에서는 전력 변환, 냉각, 네트워크, 제어 설비가 쓰는 전력을 뺍니다. 셋째 원장은 남은 전력이 주배전반, RPP, 랙 전원 경로를 따라 실제 어디에 도달하는지 보여 줍니다. 넷째 원장은 여러 GPU 상한에서 공급 가능한 랙 전력이 얼마만큼의 작업 처리량으로 바뀌는지 계산합니다. 최종 용량을 정하기 전에 이 원장들을 합치면 어느 구간이 제약인지 보이지 않습니다.

150 MW 사례에서 네트워크가 8~9%를 쓴다면 첫 학습 스텝을 실행하기 전에 12~13.5 MW가 이미 배정됩니다. GPU 텔레메트리에는 나타나지 않는 냉각과 변환 손실도 시설 용량을 씁니다. 남은 값을 960 W로 나누는 계산은 맞지 않습니다. GB200 연산 모듈에는 CPU, 메모리, 내부 패브릭, 전력 공급 회로가 함께 있기 때문입니다. 한 MSB는 거의 찼고 다른 MSB에는 여유가 많은데 건물별 전력을 균등하게 나누는 계산도 틀립니다. 실제 나눗셈의 분모는 측정값과 배전 위치를 반영한, 배치 가능한 pod의 전력이어야 합니다.

이 차이를 이해하면 전력량계에는 여유가 있는데 새 랙을 켤 곳은 없다는 상황을 설명할 수 있습니다. 전력량계는 전체 합계를 보여 주고, 한계에 가까운 MSB는 전력을 사용할 수 있는 주소를 보여 줍니다. 용량은 수량과 위치가 함께 있어야 실제 자원이 됩니다. 따라서 구축 검증 보고서에는 캠퍼스 전체 여유율 하나가 아니라 배전 노드별 여유 분포를 제시해야 합니다. 그 분포의 하위 꼬리가 계획한 랙 중 실제로 켤 수 있는 수량을 정합니다.

텔레메트리도 같은 계층으로 다뤄야 합니다. 장치가 보고하는 전력은 빠른 제어에 유용하고, RPP와 MSB 계측은 보호와 정산에 더 적합합니다. 센서마다 샘플링 구간, 보정 오차, 측정하는 물리 경계가 다릅니다. 장치의 1초 미만 피크는 시설 평균에서 사라질 수 있고, 랙 센서의 작은 편향은 계획 전체에서 수 MW로 누적될 수 있습니다. 운영자는 원시 측정값을 보존하고 타임스탬프를 맞춘 뒤 계층 사이의 변환 모델을 명시적으로 만들어야 합니다. 보정 계수 하나만 적용하면 작업부하, 온도, 이용률이 바뀌어도 오차가 일정하다고 가정하게 됩니다.

Meta가 사용한 70백분위도 모든 데이터센터에 그대로 적용할 상수가 아닙니다. 독립적인 최댓값을 더하는 방식보다 신중하게 고른 통계값이 공유 전력 경계를 더 잘 나타낼 수 있다는 증거입니다. 작업 구성, 전원공급장치, 계측 구간이 다르면 다른 백분위가 필요할 수 있습니다. 과거 시운전 데이터에서 통계값을 정하고, 별도의 고부하 기간에 다시 검증해야 합니다. 보정에 사용한 실행에서만 잘 맞는 값은 안전한 여유 전력으로 쓸 수 없습니다.

에너지, 전력, 변화율을 구분하는 기준

대시보드 하나에 자주 섞이는 값이 세 가지입니다. 에너지는 일정 기간의 요금을 정합니다. 전력은 급전 경로나 냉각 설비가 부하를 지속해서 감당할 수 있는지 정합니다. 전력 변화율은 동기화된 부하 전환을 전기 설비와 전력망 연결부가 따라갈 수 있는지 정합니다. Power Smoother는 에너지를 늘리면서 변화율을 낮출 수 있고, Dimmer는 연산 처리량을 잠시 낮춰 피크를 줄입니다. 둘을 모두 전력 최적화라고만 부르면 무엇을 비용으로 지불했는지 알 수 없습니다.

평가 실험도 달라야 합니다. 전력 상한을 평가할 때에는 완료한 모델 작업량, 에너지, 실행 시간을 함께 측정합니다. 평탄화는 실제 제한이 걸리는 전기 경계에서 상승·하강 변화율의 분포를 봐야 합니다. 보호 제어기는 평균 반응이 아니라 반응 지연의 꼬리와 최대 초과량을 시험해야 합니다. 한 시간 평균으로 효율이 좋아 보여도 짧은 동기 전환에서 차단기를 동작시키면 안전한 제어가 아닙니다.

Power Smoother는 평탄한 부하의 가치가 추가 에너지와 애플리케이션 간섭보다 클 때에만 타당합니다. 이 가치는 상시 남겨 두는 여유의 축소, 전력회사가 요구하는 변화율의 완화, 냉각 운전의 안정화에서 나올 수 있습니다. 비교는 실제 한도를 만드는 전기 경계에서 해야 합니다. MSB나 캠퍼스 파형을 바꾸지 못하는 GPU 수준 평탄화는 시설 이점 없이 비용만 만듭니다.

Dimmer는 다른 검증이 필요합니다. 분산 작업에서는 불균등한 출력 제한의 비용이 커집니다. 한 작업자만 2% 늦춰도 계속 가장 느린 랭크가 되면 작업 전체 손실은 2%보다 클 수 있습니다. 따라서 제어 단위는 동기화 범위를 따라야 합니다. 텐서 병렬이나 파이프라인 병렬 작업에서는 할당 장비의 일부일 수 있고, 강하게 동기화된 데이터 병렬 작업에서는 전체 작업일 수 있습니다. 스케줄러 메타데이터는 편의 기능이 아니라 함께 움직여야 할 GPU의 범위를 정하는 입력입니다.

여유 전력에는 유효 기간이 있는 구조

측정으로 확인한 여유도 영구적인 용량이 아닙니다. 외기 온도가 바뀌면 냉각 전력이 달라지고, 펌웨어가 바뀌면 장치의 동작이 달라집니다. 새 모델 구조는 연산과 통신 시간의 비율을 바꾸며, 네트워크 토폴로지가 바뀌면 GPU 밖의 부하가 달라집니다. 모든 여유 전력 값에는 근거가 된 측정, 유효한 운전 조건, 재검증 시점을 함께 기록해야 합니다. 한 세대의 작업에 승인한 상한을 다른 세대의 기본값으로 쓰기 전에 다시 확인해야 합니다.

이렇게 보면 구축 검증은 한 번 끝나는 행사가 아니라 계속되는 정산 절차입니다. 제어 표에는 시설 노드, 안전한 연속 한도, 단기 과부하 곡선, 보정한 측정 불확실성, 현재 승인한 부하, 남은 여유를 기록할 수 있습니다. 스케줄러는 용량을 세 종류로 나눕니다. 장시간 공급할 수 있는 전력, 잠깐 쓸 수 있는 피크 허용량, 아직 검증하지 않은 이론상 여유입니다. 장시간 작업의 입장 결정에는 첫째만 사용하고, 둘째는 조정된 런타임 가속에 쓰며, 셋째는 측정으로 확인할 때까지 사용할 수 없는 값으로 둬야 합니다.

장애 정책도 같은 표에 들어가야 합니다. 계측 스트림이 끊기면 마지막 여유가 계속된다고 가정하지 말고 보수적인 상한으로 돌아가야 합니다. 전력 명령이 분산 작업의 일부에만 도달했다면 함께 변경을 마치거나 원래 값으로 복구해야 합니다. 캠퍼스 총량은 안전하지만 한 MSB가 한도에 가까우면 이후 작업은 다른 전력 경로에 배치해야 합니다. 시설 제어를 구축이 끝난 뒤 장치 관리 서비스에 덧붙일 수 없는 이유입니다.

마지막으로 처리량 개선과 함께 불확실성을 보고해야 합니다. 약 14%라는 원장에는 계획 비교, 시운전 조정, 런타임 실측처럼 근거 수준이 다른 이득이 들어 있습니다. 다음 구축에서도 이 항목을 분리해야 합니다. 구매 모델은 몇 장을 넣을 수 있는지 예상하고, 구축 검증은 몇 장을 안전하게 켤 수 있는지 입증하며, 운영 텔레메트리는 승인한 장비가 실제로 끝낸 작업량을 보여 줍니다. 이 주장을 분리하면 계산상 최댓값을 지속 가능한 서비스 용량으로 제시하는 오류를 막을 수 있습니다.

실행 순서는 분명합니다. 시설 경계를 확보하고, 여러 장치 상한을 모델링하며, 비연산 부하를 별도로 배정하고, 전력을 실제 위치까지 전달할 수 있도록 배전 구조를 설계합니다. 그다음 텔레메트리 계층을 보정하고 안전한 연속 설정을 검증한 뒤 작업의 동기화 범위를 제어기에 제공합니다. 이 절차를 마친 뒤에만 순간 여유를 사용해야 합니다. 소프트웨어가 물리 한도를 피하는 것이 아니라 이미 구매한 한도 가운데 실제로 공급 가능한 몫을 늘리는 방식입니다.

공급 가능한 전력당 처리량이 실제 가속기 지표

이 논문은 가속기 전력을 소프트웨어가 다루는 자원으로 바꿉니다. 배선과 냉각 설비를 보호하려면 명판 전력이 필요하지만 시설의 유효 산출량을 예측하기에는 부족합니다. 주파수가 전력보다 천천히 떨어지는 구간에서는 상한을 낮춰 클러스터의 MW당 처리량을 높일 수 있습니다. 반대로 상한을 잘못 고르면 동기화된 작업 시간이 길어져 절감한 전력을 모두 잃습니다. 필요한 곡선은 각 전력 상한에서 실제 공급 가능한 MW당 승인 토큰이나 학습 스텝이며, 가장 느린 장비의 꼬리 동작도 포함해야 합니다.

구매 비교도 달라집니다. 열 설계 전력(TDP)이 다른 가속기를 칩당 FLOPS나 랙당 와트만으로 평가할 수 없습니다. 전력 변환 손실, 냉각, 작업부하 이용률, 통신 대기, 모델 오차와 순간 변동에 대비해 남긴 여유를 시설 경계까지 계산해야 합니다. 명목 효율이 높은 장비라도 순간 전력이 큰 여유를 요구하거나 소프트웨어가 효율 구간을 유지하지 못하면 캠퍼스 전체 산출량은 낮을 수 있습니다.

운영 루프에는 전력 예측 오차의 예산이 남아 있어야 합니다. 배포 전에는 최대값 하나가 아니라 신뢰 구간이 필요합니다. 시운전 뒤에는 랙과 작업부하 텔레메트리로 그 범위를 갱신합니다. 실행 중에는 남은 여유를 가장 많은 유효 작업을 만드는 전력 상한과 배치에 나눕니다. 150MW 시스템의 의미는 시설과 연산이 별개의 결정이 아니라는 데 있습니다. 설비 계획이 안전 범위를 정하고, 측정이 쓰지 않은 여유를 찾으며, 스케줄링이 그 여유를 모델 진척으로 바꿉니다. 전력이 부족한 시장에서는 건물 경계에 도달하지 못하는 칩 효율 1%보다 이 운영 루프가 더 많은 판매 가능 AI 용량을 만들 수 있습니다.

전력 한도는 스케줄러까지 전달돼야 할 이유

전력 제약이 있는 스케줄러는 GPU 수뿐 아니라 시간 구간별로 사용할 수 있는 용량을 알아야 합니다. 전력망 인입, 변전과 버스웨이, 랙, 냉각, 짧은 순간 여유는 서로 다른 한계입니다. 하나의 사이트 MW로 합치면 장비를 놀리거나 전체 한도 전에 국소 설비가 먼저 제한될 수 있습니다.

밀리초와 초 단위 변화는 장치 제어가, 수 분의 지속 부하는 랙과 열 제어가, 더 긴 부족은 작업 배치와 수용 제어가 맡아야 합니다. 학습 단계, 추론 배치, 체크포인트, 통신의 전력 패턴을 작업 정보와 연결하면 서로 보완적인 부하를 함께 배치할 수 있습니다.

출력 제한에 필요한 성능 분모

GPU 최대 전력을 낮추면 같은 사이트 한도에서 더 많은 장치를 켤 수 있지만 작업 시간이 늘어 총에너지가 증가할 수도 있습니다. 목표 시간과 품질을 유지한 상태에서 공급 가능한 MW당 완료 작업을 비교해야 합니다. 작업마다 전력 곡선이 다르므로 두 설정만 보지 말고 성능이 급격히 꺾이는 지점까지 측정해야 합니다.

냉각 장치나 전력 모듈이 빠질 때 다른 장비가 부하를 받으므로 장애 여유도 계산에 포함해야 합니다. 정상 상태의 효율만 높인 계획은 유지보수 때 더 많은 작업을 중단할 수 있습니다.

150 MW가 모두 판매 가능한 연산은 아닌 이유

인입 전력은 변환, 냉각, 네트워크, 스토리지, 호스트 CPU, 이중화, 운영 여유를 거쳐 GPU에 도달합니다. 날씨와 설비 상태, 순간 부하에 따라 실제 값도 달라집니다. 커미셔닝에서는 랙과 행, 장애 조건을 단계적으로 시험하고 전력망부터 장치까지 계측값을 맞춘 뒤, 수천 개 가속기가 같은 단계로 바뀌는 동기식 부하를 재현해야 합니다.

GPU 8만3천 장의 사례가 보여 주는 결론은 런타임 전력 제어가 클러스터 아키텍처라는 점입니다. 용량 계획만으로 유효 연산을 보장할 수 없고 출력 제한만으로 용량을 만들 수도 없습니다. 예측, 구축 검증, 계측, 스케줄링, 장치 제어가 같은 전력 경로 모델을 공유해야 사이트가 검증한 범위 안에서 모델 작업을 계속 완료할 수 있습니다.

출처와 저작권 안내

이 글은 Silicon & Systems가 작성한 편집 요약입니다. 아래 논문의 주장과 결과를 우리 표현으로 다시 썼습니다. 논문의 문장, 표, 도판은 옮기지 않았으며, 본문의 두 도판은 보고된 수치를 바탕으로 이 글을 위해 새로 만들었습니다. 원문은 Creative Commons Attribution 4.0 International 라이선스로 공개돼 있습니다. 저작권 (c) 2026 원저자. 원문과 라이선스는 arXiv 서지 페이지에서 확인할 수 있습니다.