오늘의 AI 뉴스

발행 기준: ‘새로 나온 것’과 ‘이제 검증할 수 있는 것’을 구분한다

이 글은 2026년 10월 20일 오전 11시 30분 KST 기준으로 확인할 수 있는 공개 자료를 사용한다. 검색 API는 키가 없어 실패했으므로 OpenAI, Hugging Face, PyTorch 등 공식 목록과 원문을 직접 열어 확인했다. 오늘 다루는 주요 발표 두 건은 미국 기준 10월 19일에 게시됐다. OpenAI는 저자료 프로그래밍 언어의 코딩·마이그레이션 평가를 공개했고, Hugging Face와 PyTorch는 AWS Trainium을 PyTorch의 네이티브 장치로 다루는 TorchNeuron을 설명했다. TorchNeuron 공개 베타는 10월 20일 시작 예정이라고 공식 글에 적혀 있다. 이 시각에 설치 가능 상태를 직접 실행으로 검증한 것은 아니므로 ‘이미 모든 환경에서 사용 가능하다’고 쓰지 않는다.

두 발표는 외형상 서로 다른 시장을 겨냥한다. 하나는 오래된 언어로 쓰인 업무 프로그램을 AI가 얼마나 정확히 만들고 옮기는가, 다른 하나는 모델을 훈련하고 서빙하는 하드웨어를 개발자가 얼마나 자연스럽게 활용하는가다. 그러나 둘 다 같은 질문으로 수렴한다. 인터페이스가 익숙해졌다는 사실과 실제 결과가 보존된다는 사실은 다르다. COBOL을 Python으로 번역해 빌드에 성공했다고 거래 결과가 같아진 것은 아니다. .to('neuron')으로 모델이 올라갔다고 동일한 정확도·비용·꼬리 지연이 보장되는 것도 아니다. 오늘의 분석은 이 간극을 측정하는 방법에 집중한다.

아래의 벤치마크 수치는 발표자들이 정한 시험과 비용 추정 조건에서 나온 결과다. 서로 다른 모델·노력 수준·테스트 집합을 혼합해 범용 순위를 만들지 않는다. 본문의 체크리스트와 예시 데이터 구조, 배포 게이트는 편집자의 실무 설계 제안이며 두 업체가 공식적으로 약속한 기능이 아니다. 특히 금융·인사·의료 같은 상태 변경 업무에서는 공개 벤치마크 점수를 프로덕션 승인으로 전용하지 않는다.

Top News — 10월 19일 공식 발표 두 축

1. OpenAI는 저자료 언어 코딩 능력을 두 종류의 과제로 측정했다. MultiLangBench는 20개 언어로 SQLite와 호환되는 데이터베이스 엔진을 만드는 과제다. 발표 기준 최대 추론 노력에서 GPT‑6 Astra의 평균 테스트 통과율은 87.4%, 비교한 GPT‑5.6 Sol은 26.8%다. COBOL만 보면 10.9%에서 72.1%로 올랐지만, 72.1%는 아직 모든 SQL 동작을 구현했다는 뜻이 아니다. 별도의 COBOL 마이그레이션 과제에서 GPT‑6.1 Sol은 낮은 추론 노력으로 86.6%, 높은 노력으로 97.9% 정확도를 기록했다. 여기서 성공은 숨겨진 테스트의 관측 가능한 출력을 바이트 단위로 동일하게 유지한 경우다. OpenAI 공식 발표 · MultiLangBench 공개 저장소
2. Hugging Face는 TorchNeuron이 PyTorch를 AWS Trainium의 네이티브 경로로 연결한다고 설명했다. 종전의 Optimum Neuron 경유 방식과 달리 neuron 장치, eager 실행, torch.compile, PyTorch의 분산 API를 직접 활용한다. Hugging Face는 상위 100개 텍스트 생성 모델 아키텍처 지원 비율이 Optimum Neuron v0.4.5의 46%에서 TorchNeuron의 89%로 넓어진다고 발표했다. 이는 해당 아키텍처 집합의 ‘기본 지원’ 범위이지 고객의 특정 체크포인트와 양자화·커스텀 연산의 통과율은 아니다. Hugging Face 공식 발표
3. PyTorch 공식 기술 설명은 네이티브화의 범위와 남은 경계를 구체화했다. TorchNeuron은 PyTorch의 PrivateUse1 장치 확장에 기반하고 Trainium2·Trainium3에서 eager, compiled 실행, NKI 사용자 정의 커널, 분산 API, profiler 통합을 다룬다. 공개 베타는 10월 20일, Apache 2.0 오픈소스 저장소 공개도 같은 시점으로 예고됐다. Adaptive eager는 실험적이며 TorchAO·FP8은 이 발표 시점에 private beta라고 명시돼 있다. 모든 최적화가 일반 공개라는 표현은 맞지 않다. PyTorch 공식 기술 글

배경: AI 도입에서 가장 비싼 오류는 ‘겉으로 성공한’ 차이

오래된 프로그램을 현대 언어로 옮길 때 가장 쉬운 성공 지표는 ‘새 코드가 컴파일된다’다. 그러나 사용자가 의존하는 것은 언어가 아니라 행동이다. 입력 한 줄에서 마이너스 금액을 어떻게 표시하는지, 고정 소수점 숫자의 남는 자릿수를 버리는지 반올림하는지, 없는 계정을 조회했을 때 오류 코드와 출력 파일이 무엇인지, 날짜 끝에서 배치를 어떻게 정산하는지가 행동이다. 옛 프로그램의 버그처럼 보이는 현상도 외부 인터페이스가 의존하고 있다면 배포 단계에서는 계약의 일부다. 개선하려면 의도적 정책 변경으로 분리해야 한다.

모델 실행 플랫폼에도 비슷한 일이 생긴다. PyTorch에서 같은 model.forward()를 호출한다고 장치별 연산 지원, 수치 경로, 컴파일 캐시, 병렬 통신, 메모리 배치가 같지 않다. 개발자가 한두 줄만 바꿔 이식할 수 있다는 것은 시작 비용이 낮아진다는 뜻이다. 전체 비용이 낮아지는지는 장기 실행과 팀의 실제 워크로드에서 확인해야 한다. 한 가속기의 우수한 단일 벤치마크를 비용 절감 약속으로 바꾸면 온콜 담당자가 겪을 컴파일 지연과 복구 절차가 빠진다.

이 두 발표를 하나의 호에 함께 싣는 이유는 현대화가 단순한 번역이나 포팅이 아니기 때문이다. 소프트웨어 현대화에는 원래 시스템의 의미를 이해하는 일, 그 의미를 자동 검증으로 포착하는 일, 새 구현의 수치·상태·예외를 비교하는 일, 실행 플랫폼을 재현 가능하게 만드는 일이 한꺼번에 들어간다. AI가 코드를 빠르게 생산하고 새 하드웨어가 기존 프레임워크에 가까워질수록 사람이 해야 할 일은 코드의 양을 세는 것에서 검증 가능한 불변조건을 정의하는 것으로 이동한다.

1. OpenAI 발표에서 실제로 측정한 두 가지 능력

MultiLangBench: 언어별 문법 퀴즈가 아니라 장기 소프트웨어 구축

MultiLangBench는 ‘COBOL 구문을 설명해 보라’는 단답형 시험이 아니다. 모델에 문서와 작업 환경을 주고 특정 언어로 SQLite 3.40.1과 호환되는 엔진을 구현하게 한다. 입력은 초기 데이터베이스 파일과 SQL 쿼리이며, 출력은 쿼리를 처리한 뒤의 데이터베이스 파일이다. 실제 SQLite가 그 파일에 검증 쿼리를 실행한 결과를 기대값과 비교한다. 따라서 프로그램이 그럴듯한 SQL 텍스트를 출력하는 것만으로 통과할 수 없다. 저장 형식, 자료형, 상태 변경, 예외 처리가 모두 결과에 영향을 준다.

공개 저장소는 평가 구성의 세 부분을 명시한다. initial_database는 초기 파일을 만들 SQL, user_query는 후보 구현이 수행해야 할 쿼리, validation_query는 수정된 파일을 진짜 SQLite로 열어 확인하는 쿼리다. 기존 SQLite TCL 테스트 약 5만 1천 개 가운데 약 2만 4천 개를 이 형식으로 변환했다고 설명한다. 전체 실행 비용이 크므로 기본 재현에는 해시 접두어 00, 01, 02에 해당하는 272개 테스트를 권장하고, 고득점 후보를 더 정밀하게 볼 때 전체 테스트를 돌린다면 명시하라고 한다. 272개 부분집합의 점수와 전체 약 2만 4천 개의 점수를 같은 표에 섞으면 안 된다.

저장소는 대상 언어로 작성하지 않았거나 다른 언어를 섞으면 통과율을 0으로 두도록 적었다. 평가 환경에서 이미 설치된 SQLite 라이브러리·실행 파일을 제거하고 인터넷을 막으라는 지침도 있다. 이 조치는 모델이 구현 대신 시스템의 기존 SQLite에 얇은 래퍼를 씌우는 경로를 차단한다. 동시에 이런 통제는 실제 기업 개발 현장과 시험 환경을 구분한다. 실제 현장에서는 기존 라이브러리 재사용이 합리적일 수 있지만, 벤치마크는 그 언어로 구현하는 능력을 재기 위해 그 선택지를 닫는다.

공식 발표는 GPT‑6 Astra가 20개 언어 평균 87.4%로 비교 모델의 26.8%보다 높다고 말한다. 언어별 예시에서 COBOL 72.1%, OCaml 85.8%, Fortran 83.5%, Visual Basic 89.4%가 적혀 있다. 20개 중 19개 언어가 83%를 넘고 COBOL이 72%로 가장 어려웠다. 수치가 인상적이어도 테스트 통과율과 ‘데이터베이스 엔진으로 사용 가능’은 별개다. 남은 테스트가 거래 경계, 손상 복구, 예외 코드, 데이터 타입의 희귀 조합에 집중된다면 작은 비율의 실패가 큰 운영 위험이 될 수 있다. 통과한 사례의 분포를 실제 업무 쿼리의 분포와 대조해야 한다.

비용과 능력의 축은 분리해 읽는다

같은 발표에서 GPT‑6 Luna의 20개 언어 평균 통과율은 40.3%다. 비교한 GPT‑5.6 Sol의 26.8%보다 높고, 발표자가 산정한 샘플당 평균 API 비용은 0.77달러로 비교 모델의 3.48달러보다 약 78% 낮다. 이것을 ‘Luna가 Astra보다 효율적이다’라는 한 문장으로 줄일 수 없다. 통과율 격차가 큰데 업무에서 실패 한 번의 비용이 크다면 저렴한 호출료가 전체 비용을 낮추지 못한다. 반대로 초안 작성과 사람이 반드시 검토하는 낮은 위험 작업이라면 저가 모델이 합리적일 수 있다.

비용 지표를 제품 의사결정에 쓰려면 분모를 맞춰야 한다. API 비용 / 샘플은 구현을 한 번 시도한 평균이다. 사용자가 실제로 원하는 것은 완료된 변경 한 건당 총비용이다. 여기에는 실패한 시도의 재실행, 모델이 만든 코드를 리뷰한 사람의 시간, 테스트 인프라, 보안 검토, 운영 오류 복구가 들어간다. 성공률이 낮은 모델은 값싼 한 번의 시도가 여러 번 누적될 수 있다. 반대로 더 비싼 모델이 첫 시도에 더 자주 맞는다면 완료 작업당 비용은 낮을 수 있다. 발표 데이터만으로 이 계산을 완성할 수 없지만, 구매 결정 전에 무엇을 재야 할지는 분명해진다.

COBOL 마이그레이션: 목표는 새 언어가 아니라 관측 행동의 동일성

두 번째 평가의 과제는 기존 COBOL 프로그램을 C++, Java, Kotlin, Python, Rust 중 하나로 옮기는 것이다. 공식 설명은 숨겨진 테스트에서 관측 가능한 출력이 바이트 단위로 같아야 성공이라고 한다. 이것은 코드를 줄 단위로 번역했는지보다 원래 프로그램의 규칙을 보존했는지를 보는 방식이다. GPT‑6.1 Sol은 낮은 추론 노력에서 86.6% 정확도를 기록했고, 같은 설정의 GPT‑5.6 Sol은 5.4%였다. OpenAI는 이때 GPT‑6.1 Sol의 API 비용이 비교 모델의 61%라고 설명한다. 높은 추론 노력의 GPT‑6.1 Sol은 97.9%로 올라간다.

97.9%는 ‘COBOL 자동 현대화 완료’가 아니다. 평가 집합의 천장에 가까워졌다는 신호일 수 있고, 남은 2.1%가 조직의 가장 민감한 거래에 몰려 있을 수도 있다. 숨겨진 테스트가 포착하지 못한 외부 파일 형식, 특수 문자 인코딩, 배치 스케줄러, 호출 순서, 복구 경로는 별도 검토해야 한다. 공식 글 자체도 실제 프로덕션 적용에는 전문가 검토와 비즈니스 규칙·의존성에 대한 테스트가 필요하다고 적었다. 발표자가 붙인 이 단서를 제외하고 점수만 제품 광고에 가져오면 가장 중요한 경계가 사라진다.

예컨대 고정 소수점 123.456을 두 자리 필드에 넣을 때 원래 프로그램이 남는 자릿수를 버리고 새 코드가 반올림하면 둘 다 실행은 된다. 그러나 결과가 123.45와 123.46으로 갈린다. 작은 오차가 하루 거래 합계, 이자, 퇴직금 계산, 세금 신고에 누적될 수 있다. 실무에서는 이 차이를 ‘정밀도 개선’이라는 이름으로 조용히 넣지 말고, 마이그레이션의 행동 보존 테스트에서 실패로 기록한 뒤 정책 담당자의 명시적 변경 승인에 올려야 한다.

2. 평가를 실제 기업 코드에 옮길 때 빠뜨리기 쉬운 네 가지 경계

첫째, 테스트가 뜻하는 성공의 범위

MultiLangBench의 성공 단위는 개별 검증 쿼리다. COBOL 마이그레이션 평가의 성공 단위는 해당 프로그램이 모든 숨겨진 행동 테스트를 통과했는가다. 수치가 비슷해 보여도 분모가 다르다. 하나는 특정 소프트웨어 구현의 기능 통과율이고 다른 하나는 프로그램별 마이그레이션 완료율이다. 87.4%와 86.6%를 평균내 ‘코딩 성공률 87%’라고 말하면 평가 단위가 사라진다. 보고서에는 과제 수, 테스트 수, 언어, 목표 런타임, 노력 수준, 제한 시간, 비용을 함께 적어야 한다.

기업의 자체 평가도 단위부터 정한다. ‘한 파일을 변환했다’가 아니라 ‘하나의 배치가 전일·당일 데이터를 모두 처리하고 결과 파일과 오류 로그가 동일하다’, ‘같은 고객에 대해 수수료 계산과 예외 플래그가 같다’처럼 업무 단위의 사후 조건을 쓴다. 여러 모듈이 같은 공통 필드를 공유하면 개별 파일 테스트를 모두 통과해도 통합 실행에서 충돌할 수 있다. 따라서 작은 변환 단위의 빠른 피드백과 끝단 업무 시나리오의 느린 검증을 둘 다 둬야 한다.

둘째, 현재 코드에 쓰여 있는 규칙과 조직이 원하는 규칙

레거시 시스템에는 문서화되지 않은 규칙이 많다. 모델이 코드를 요약하면서 ‘이 부분은 이상하니 고쳤다’고 말할 수 있지만, 실제로는 관행적으로 허용된 예외일 수 있다. 반대로 수십 년 묵은 결함을 그대로 보존하는 것도 정책상 부적절할 수 있다. 그래서 프로젝트 초기에 행동 보존 목록과 의도적 변경 목록을 분리한다. 전자는 새 구현이 동일해야 하는 경계이고, 후자는 제품 담당자·법무·운영자가 별도로 승인해야 하는 변경이다. AI에게 두 목표를 하나의 프롬프트로 맡기면 테스트가 어디를 기준으로 실패해야 할지 애매해진다.

구체적으로 원래 출력과 새 출력이 다르면 먼저 차이를 분류한다. unintended_regression은 즉시 수정 대상이다. intended_policy_change는 승인·릴리스 노트 대상이다. legacy_undefined_behavior는 원본이 환경마다 다르게 행동했던 경우로, 새 정책을 정해야 한다. test_oracle_error는 기대값 자체가 잘못된 경우다. 마지막 두 범주까지 무조건 모델에게 ‘정답을 맞히라’고 반복시키면 시스템의 사실 대신 테스트의 우연한 결함을 학습하게 된다.

셋째, 조용히 실패하는 경계값

기존 시스템의 일반 경로를 재현하는 것은 비교적 쉽다. 어려운 것은 0, 음수, 최대 자릿수, 누락 레코드, 중복 레코드, 윤년, 월말, 시간대 변경, 서로 다른 문자 인코딩, 비어 있는 파일, 정렬되지 않은 입력 같은 경계다. 숨겨진 테스트가 있다고 해서 조직 고유의 경계를 모두 대표하지는 않는다. 업무 담당자의 장애 기록과 과거 정산 차이, 수동 보정 로그를 시험 케이스의 입력으로 재구성해야 한다. ‘자주 발생하지 않는다’는 이유로 빼면, 배포 후 드물지만 큰 손실을 만드는 사건만 남는다.

Golden-master 비교에서는 출력 파일의 바이트, 종료 코드, 로그 메시지, 데이터베이스 변경을 각각 본다. 모든 바이트가 같아야 하는 파일과, 순서가 중요하지 않아 정규화할 수 있는 응답을 구분한다. 정규화 규칙을 무심코 넓히면 실제 차이를 숨긴다. 예컨대 줄 끝 문자나 공백은 무시할 수 있어도 금액의 앞자리 0, 부호, 레코드 순서는 다운스트림 파서에서 의미가 있을 수 있다. 정규화 근거를 문서화하고 비교기 자체에 회귀 테스트를 둔다.

넷째, 통과한 코드가 배포 가능한 코드는 아니다

시험 환경의 타임아웃은 공개 저장소 기준 한 테스트당 60초다. 프로덕션 시스템은 평균뿐 아니라 월말 피크, 장애 복구, 감사 재실행의 시간을 맞춰야 한다. 새 코드가 출력은 정확하지만 대용량 파일을 메모리에 전부 올리거나 파일 잠금을 오래 유지하면 배포 불가다. 예외 발생 후 중간 파일 정리, 재시작 가능한 체크포인트, 중복 처리 방지, 운영자에게 남기는 오류 정보도 기능이다. 동작 보존 평가를 통과한 뒤에도 운영 적합성 평가가 필요한 이유다.

3. 기업용 마이그레이션 프로젝트에 적용할 실무 프로토콜

단계 A — 원본을 ‘진실의 원천’으로 캡처한다

첫 작업은 모델 선정이 아니라 기준 상태 고정이다. 원본 소스의 해시, 컴파일러와 플래그, 배치 스케줄, 라이브러리 버전, 입력 파일 스키마, 결과물 포맷, 운영 시점의 설정을 기록한다. 같은 COBOL 소스라도 컴파일러 옵션과 런타임의 숫자 처리, 문자 인코딩에 따라 결과가 다를 수 있다. 기준이 이동하면 새 구현의 차이를 해석할 수 없다. 배포 전에 테스트용 개인정보는 비식별화하고, 실제 거래 데이터가 개발자의 로컬 도구에 무심코 복제되지 않게 접근 경로를 설계한다.

원본이 실행 가능한 상태라면 대표 입력에 대한 결과를 수집해 golden corpus를 만든다. 성공 사례만 모으지 말고 실패 사례와 정정 처리도 포함한다. 입력과 결과를 사건 단위로 묶어 case_id, 원본 버전, 실행 환경, 날짜, 기대 출력, 허용 가능한 차이, 분류를 남긴다. 운영자가 과거 수동으로 고쳤던 사례에는 원래 프로그램의 출력과 최종 승인된 업무 결과를 따로 보관한다. 둘이 다를 수 있다는 사실을 감추면 새 코드의 ‘정확함’이 무엇인지 모호해진다.

단계 B — 의미를 도메인 불변조건으로 분리한다

모델에게 전체 저장소를 한 번에 번역하게 하기 전에 도메인 담당자와 개발자가 불변조건을 작성한다. 인사 시스템이라면 ‘한 직원의 월별 급여 합계는 항목별 금액의 합과 같다’, ‘퇴사일 이후의 새 근태 기록은 승인 경로 없이 정산되지 않는다’ 같은 규칙이다. 이 규칙은 구현 언어와 독립적이어야 한다. 특정 함수 이름이나 파일 구조에 결합하면 언어만 바뀐 코드를 평가할 수 없다. 불변조건은 정상 경로뿐 아니라 금지된 상태 변경과 개인정보 접근 경계도 포함한다.

불변조건마다 소유자와 근거를 붙인다. 예컨대 법령, 내부 규정, 외부 계약, 오래된 운영 관행을 같은 확실성으로 취급하면 안 된다. 규칙이 문서에 없고 프로그램에서만 관찰됐다면 observed_behavior로 분류하고 검토자를 지정한다. AI는 이 표를 토대로 코드의 가설을 만들 수 있지만, 규칙의 최종 권위를 대신하지 않는다. 특히 규정 변경이 진행 중인 조직에서는 배포 날짜와 규칙 시행일을 분리해야 한다.

단계 C — 작은 변경과 독립된 판정기를 사용한다

모델이 코드를 만들고 스스로 ‘맞다’고 요약한 문장은 검증 증거가 아니다. 모델이 만든 변경을 독립된 실행 하네스에서 원본과 비교한다. 가능하면 입력 생성기와 판정기를 변환 모델의 문맥 밖에서 관리한다. 같은 모델이 테스트도 작성하면 자신이 놓친 규칙을 테스트에서도 놓칠 수 있다. 프로퍼티 기반 입력 생성, 과거 장애 사례, 도메인 담당자가 만든 예외 시나리오를 섞는다. 차이가 나면 전체 프로그램을 다시 생성하기보다 재현 가능한 가장 작은 입력을 추출한다.

개별 수정의 크기도 제한한다. 금액 계산, 인코딩, 파일 I/O, 오류 보고를 한 PR에서 동시에 바꾸면 차이를 좁히기 어렵다. 큰 마이그레이션이라도 어댑터와 핵심 로직을 분리하고, 각 단계에서 원본과 새 구현을 같은 입력에 대해 병행 실행한다. 변경 이유를 설명하는 문서는 자연어 요약만이 아니라 실행 가능한 테스트, 기존 결과와 새 결과의 diff, 예외 처리 표를 포함한다. 승인자가 코드를 전부 읽지 않아도 어떤 행동이 달라질 수 있는지 확인할 수 있어야 한다.

단계 D — 섀도 실행으로 현실의 분포를 확인한다

스테이징에서 모든 준비된 테스트를 통과해도 실사용 입력 분포는 다르다. 읽기 전용 섀도 실행에서는 기존 시스템이 최종 출력을 계속 담당하고 새 구현은 같은 입력을 처리해 결과만 비교한다. 상태 변경 API라면 외부 결제, 이메일, 인사 기록 수정이 이중으로 발생하지 않도록 격리된 사본과 비활성화된 통지 경로가 필요하다. 섀도 결과를 매칭할 때 입력 시각과 원본 시스템의 상태 버전을 연결해야 한다. 두 시스템이 다른 스냅샷을 읽어 생긴 차이를 코드 버그로 오인하지 않기 위해서다.

차이 통계는 단순 불일치율만 보고하지 않는다. 발생 빈도, 금액의 절댓값과 방향, 영향을 받은 고객 수, 규칙 유형, 원인 미분류 비율, 재현 가능성으로 나눈다. ‘99.9% 동일’이라는 지표가 나머지 0.1%의 대규모 급여 정산 오류를 숨길 수 있다. 고위험 사례는 비율이 아니라 건수 0을 출시 기준으로 둘 수도 있다. 무엇을 고위험으로 볼지는 도메인 소유자가 정하고, 모델 점수만으로 바꾸지 않는다.

단계 E — 전환·복구·감사를 한 묶음으로 배포한다

전환은 새 구현을 켜는 한 순간이 아니라 역전 경로를 포함한 절차다. 새 코드가 작성한 레코드를 옛 코드가 다시 읽을 수 있는지, 이중 실행 중 번호 생성이 충돌하지 않는지, 장애 때 어느 시스템이 권위 있는 결과를 보유하는지를 정한다. 일정 기간 동안 양쪽 결과를 비교하되, 단일 쓰기 주체만 외부 효과를 확정하도록 설계한다. 롤백은 코드 버전을 되돌리는 것만으로 끝나지 않는다. 이미 생성된 파일과 통지가 있으면 이를 추적·정정할 절차가 있어야 한다.

감사 기록에는 어떤 모델과 프롬프트가 코드를 만들었는지도 유용하지만, 더 중요한 것은 검증 결과다. 원본 커밋, 새 커밋, 컴파일러와 런타임, 테스트 묶음 버전, 기준 데이터 해시, 검토자, 승인 시각을 함께 보관한다. 다음 달 규정이 바뀌면 과거 승인된 마이그레이션과 새로운 정책 변경을 구분할 수 있어야 한다. 기록을 더 남기는 목적은 ‘AI가 했으니 위험하다’는 낙인이 아니라 다른 코드 변경과 동일한 수준으로 재현하고 책임을 분명히 하기 위함이다.

4. TorchNeuron: PyTorch가 Trainium을 장치로 취급한다는 뜻

이전 경로와 새 경로의 차이

Hugging Face의 설명에 따르면 그동안 Trainium·Inferentia에서 Hugging Face를 사용하는 대표 경로는 optimum-neuron이었다. 이 계층은 PyTorch XLA 기반 torch-neuronx를 감싸면서 lazy tensor, 정적 형태, graph break에 따른 재컴파일 같은 복잡성을 숨기려고 전용 모델링 클래스와 트레이너 코드를 유지했다. 새 TorchNeuron은 neuron을 PyTorch의 장치로 등록하고 eager 실행과 PyTorch의 분산 기본 요소, torch.compile을 직접 노출한다. 따라서 Transformers, Diffusers, Accelerate, PEFT, TRL의 표준 클래스를 이용할 수 있다는 것이 발표의 핵심이다.

이는 기존 Neuron 전용 코드가 즉시 필요 없어진다는 뜻과 다르다. ‘표준 API를 사용한다’는 것은 모델 구현과 교육 자료, 팀의 운영 절차를 다시 쓰는 부담을 낮춘다. 그러나 성능 최적화를 위해 정적 캐시, 패딩, 배치, 컴파일 전략과 커스텀 커널을 여전히 조정해야 할 수 있다. Hugging Face의 텍스트 생성 예시도 device_map=neuron만 보여 주는 데서 끝나지 않고 정적 생성 캐시와 최대 길이, prefill chunk를 설정한다. 경로가 단순해진 부분과 튜닝이 남은 부분을 함께 읽어야 한다.

PyTorch 공식 글은 Trainium을 PrivateUse1 확장 지점으로 등록한다고 설명한다. torch.nn, torch.tensor, torch.autocast, torch.distributed, torch.profiler가 neuron 장치에서 작동하는 것이 목표다. 연구·디버깅 때는 연산을 즉시 실행하는 eager를, 안정된 성능이 중요한 생산 환경에서는 torch.compile(model, backend='neuron') 경로를 쓸 수 있다. eager는 Python 흐름과 breakpoint를 유지하지만 연산별 실행의 비용이 있고, compiled 경로는 그래프 최적화의 이익 대신 컴파일·형태 관리가 필요하다. 같은 장치에서 두 경로를 선택할 수 있게 되는 것은 개발 순환에 의미가 있다.

‘89% 아키텍처 지원’의 정확한 해석

Hugging Face는 텍스트 생성 모델 아키텍처 상위 100개의 기본 지원이 46%에서 89%로 늘었다고 설명한다. 여기서 분모는 Hugging Face의 상위 100개 아키텍처이지 모든 모델 저장소, 체크포인트, 태스크, 양자화 조합이 아니다. 같은 아키텍처라도 사용자가 추가한 커스텀 forward, 비표준 attention, 로더 설정, 디바이스 간 텐서 이동이 있다면 별도 검증이 필요하다. 또 Optimum Neuron v0.4.5와의 비교이므로 다른 버전·다른 조건에서 같은 차이가 난다고 확대하면 안 된다.

실무에서는 ‘지원됨’을 네 단계로 나눠야 한다. 첫째 모델이 로드되는가, 둘째 대표 입력에서 출력이 맞는가, 셋째 실제 길이·배치·동시성에서 안정적인가, 넷째 비용과 복구가 목표에 맞는가다. 첫 단계만 통과한 아키텍처가 네 번째 단계까지 통과했다는 보장은 없다. 지원 표를 검토할 때 모델 카드의 체크포인트 버전과 라이브러리 버전을 고정하고, 한 번의 데모 대신 연속 운영과 오류 경로를 시험해야 한다.

학습·추론·이미지 생성은 같은 기능이 아니다

Hugging Face 글은 Transformers의 텍스트 생성과 SFT 학습, Diffusers의 이미지 파이프라인, Neuron 커널을 각각 예시로 보인다. SFT 예시에서는 SFTTrainer와 DistributedConfig를 사용해 tensor parallelism과 FSDP 크기를 정한다. 예시 구성은 8개 Trainium2 칩, 32개 NeuronCore를 사용했다고 적었다. 이 한 실험이 모든 모델 크기와 데이터셋에서 같은 하드웨어 구성을 요구한다는 뜻은 아니다. 설정을 복사하기 전에 모델 파라미터와 옵티마이저 상태, 시퀀스 길이, 데이터 처리량에 맞춰 메모리·통신 계획을 잡아야 한다.

Diffusers 예시는 이미지 생성의 tensor parallelism을 보여 준다. 그 과정에서 텍스트 인코더는 CPU에 남고 변환기 부분을 Neuron으로 보내는 식의 역할 분리가 나타난다. 이는 ‘파이프라인 전체가 Trainium에서 실행된다’는 단순한 문장보다 실제 배포 계획에 유용한 정보다. CPU 준비 단계나 장치 간 전송이 병목이면 Neuron 커널을 빠르게 해도 종단 지연은 적게 줄어든다. 각 파이프라인의 텍스트 인코더, VAE, 스케줄러, 주 모델, 후처리 위치를 프로파일로 확인해야 한다.

분산 API가 자연스러워져도 통신 비용은 남는다

PyTorch 공식 글은 DDP, FSDP2, SimpleFSDP, tensor parallelism, pipeline parallelism, DTensor와 DeviceMesh 등 표준 분산 API를 설명한다. 장점은 모델 코드가 장치별 특수 분산 프레임워크에 덜 의존한다는 점이다. 그러나 API의 이름이 같다고 네트워크 위상과 집단 통신의 비용까지 같아지는 것은 아니다. Trainium 내부의 collective core와 노드 간 Elastic Fabric Adapter가 어떤 작업에 유리한지는 실제 TP·FSDP 배치, 시퀀스 길이, 마이크로배치 크기에서 측정해야 한다.

큰 모델을 무작정 더 많은 코어로 분할하면 메모리 부족은 해소할 수 있어도 작은 배치에서는 통신 오버헤드가 커질 수 있다. 학습에서는 activation checkpoint와 FSDP 샤딩, gradient accumulation이 메모리와 처리량 사이의 선택지를 바꾼다. 추론에서는 요청 길이 편차와 KV 캐시, tensor parallelism의 all-reduce가 꼬리 지연을 바꾼다. 하드웨어 선택 문서에는 계산 성능뿐 아니라 워크로드의 병렬화 형태를 써야 한다.

5. 베타 시점의 호환성·성능을 읽는 법

정적 형태와 컴파일 캐시

‘eager 지원’이 ‘형태 제한이 모두 사라짐’을 뜻하지 않는다. Hugging Face의 학습 예시는 자동 동적 형태를 비활성화하고 최대 2,048토큰의 wrapped packing, 128토큰 배수 패딩을 사용한다. 같은 형태의 그래프를 재사용하기 위해서다. 텍스트 생성 예시 역시 정적 캐시 사용을 강하게 권장한다. 이는 잘못이라기보다 컴파일 기반 가속기에서 비용을 통제하는 설계다. 현실 입력의 길이가 다양하다면 몇 개의 길이 버킷을 둘지, 긴 요청을 어떻게 처리할지, 컴파일된 그래프가 얼마나 쌓일지 운영 계획에 넣어야 한다.

컴파일 시간은 특히 짧은 수명의 잡에서 중요하다. 첫 배치가 1분 걸리고 이후 배치는 매우 빨라도, 한 번만 실행되는 야간 작업에는 경제성이 없을 수 있다. 반면 같은 모델을 장기간 서빙하면 초기 컴파일은 여러 요청에 분산된다. 따라서 벤치마크를 cold_start, warm_steady_state, shape_change, model_reload로 나눠 보고해야 한다. 평균 추론 속도 한 숫자는 운영자가 실제로 보는 배포 직후 지연을 설명하지 못한다.

연산 지원과 수치 정합성

PyTorch 글은 BF16·FP32·FP16과 정수·불리언 타입, 폭넓은 aten 연산 지원을 설명한다. 그렇더라도 모든 조합과 커스텀 연산을 완전 동일하게 수행한다는 보증은 아니다. 고객 모델의 특정 연산이 CPU로 폴백되는지, 컴파일 중 실패하는지, 구현은 되지만 다른 수치 오차를 보이는지를 구분한다. 학습에서는 첫 스텝의 loss만 비교하지 말고 여러 스텝의 수렴, gradient, optimizer state 저장과 재시작을 봐야 한다. 추론에서는 입력 길이별 출력 품질과 결정론적 설정의 차이를 분석한다.

특히 FP8과 TorchAO의 상태는 발표 시점에 private beta다. 팀이 이미 GPU에서 FP8이나 특정 양자화 경로로 비용을 절감하고 있다면, TorchNeuron의 네이티브 공개 베타와 그 최적화가 동시에 일반 공개라고 가정할 수 없다. BF16 기준으로 먼저 기능·비용을 계산하고, 최적화 기능의 공개 상태와 지원 버전이 확인되면 별도 실험으로 추가한다. 선택 가능한 기능과 앞으로 제공될 기능을 같은 ROI 표에 넣으면 도입 결정이 왜곡된다.

profiler는 빠른 숫자보다 원인을 준다

PyTorch 공식 글은 torch.profiler와 NeuronConfig, Neuron Explorer가 프레임워크 수준 CPU 활동부터 런타임과 장치 이벤트까지 연결하고 소스 라인으로 돌아갈 수 있다고 설명한다. 장치별 툴이 고립돼 있으면 엔지니어는 파이썬 함수와 칩 이벤트를 수동으로 대조해야 한다. 통합 프로파일은 이 비용을 줄일 수 있다. Neuron Explorer의 Parquet 출력은 반복 분석이나 자체 대시보드에도 사용할 수 있다고 적혀 있다. 다만 프로파일 수집 자체에 비용이 있으므로 운영 환경에서는 표본·기간·민감 데이터 취급을 정해야 한다.

프로파일을 볼 때는 연산 시간만 최적화하지 않는다. CPU 토크나이저, 입력 복사, 컴파일, device synchronization, collective 통신, 큐 대기, 모델 로드가 각각 전체 요청에 차지하는 비율을 본다. 특정 커널이 2배 빨라져도 전체 시간의 5%만 차지하면 종단 지연은 크게 변하지 않는다. 반대로 작은 커널이 매 토큰 반복되어 호출 빈도가 높다면 누적 비용이 크다. 소스 라인 연결 기능은 ‘어느 층이 느린지’를 찾는 출발점이지 대체 하드웨어의 우열을 즉시 판정하는 장치가 아니다.

NKI는 탈출구이지 모든 팀의 기본 경로가 아니다

Neuron Kernel Interface는 직접 최적화가 필요한 연산을 위한 저수준 경로다. PyTorch 글은 eager와 compiled 양쪽에서 사용자 정의 연산에 활용할 수 있다고 설명하고, Hugging Face는 관련 커널을 Hub에 공유하는 경로를 소개한다. 공식 글에는 vision transformer용 예시 커널의 최대 2.4배 속도 개선도 등장한다. 이 숫자는 해당 커널·하드웨어·조건의 사례이지 모델 전체 처리량 2.4배가 아니다. 커스텀 커널에는 정합성 테스트, backward 구현, 지원 버전 유지, 팀 내 전문성이 필요하다.

실무 순서는 표준 라이브러리 경로의 성능과 정합성을 먼저 측정하고, 반복해서 나타나는 병목만 NKI로 바꾸는 것이다. 모든 연산을 조기에 수작업 최적화하면 새 모델과 라이브러리가 나올 때 따라가기 어렵다. 커널을 도입하면 해당 연산의 원래 PyTorch 구현을 기준으로 여러 크기와 dtype, 경계 입력을 비교한다. 학습용이라면 forward가 빠른 것만으로 충분하지 않고 역전파와 분산 실행까지 시험해야 한다.

6. 개발자에게 의미: ‘코드 생성’과 ‘모델 실행’ 모두 평가 설계가 제품이다

OpenAI의 공개 평가와 TorchNeuron의 네이티브화는 개발자에게 공통된 기회를 준다. 이전에는 COBOL·Fortran처럼 학습 자료가 적은 언어, 혹은 GPU 외 AI 칩처럼 전용 지식이 많이 필요한 환경이 혁신의 진입 장벽이었다. 코딩 모델이 더 오래 추론하고 장치가 표준 PyTorch API를 받아들이면 초기 실험을 시작할 사람의 범위가 넓어진다. 그렇다고 전문가가 필요 없어지는 것은 아니다. 전문가는 수작업 번역과 장치별 래퍼 작성 대신 어떤 결과를 같다고 볼지, 어디서 차이를 허용할지, 실패를 어떻게 발견하고 복구할지를 설계하는 쪽으로 이동한다.

소규모 팀에는 순서가 중요하다. 먼저 새 기술을 도입하고 평가를 나중에 붙이면 도입 성공을 증명할 원본 지표가 없다. 기존 COBOL 배치의 평균·p95 실행 시간, 실패 입력, 정산 차이, 운영 개입 시간부터 남긴다. GPU 학습이나 서빙 시스템의 비용을 비교하려면 모델 품질, 분당 처리량, p95 지연, 배포 실패 시간, 실제 클라우드 과금 기준을 같은 기간에 측정한다. 그러면 새로운 코딩 모델이나 Trainium이 팀에 주는 이익을 홍보 문구가 아니라 차이표로 볼 수 있다.

인사시스템을 예로 들면, 급여·휴가·근태 규칙은 ‘그럴듯한 코드’를 허용하지 않는다. 과거 데이터의 소급 정정, 입사·퇴사 경계, 지역별 공휴일, 중복 승인, 권한 변경이 맞물린다. 모델은 오래된 계산식을 찾아 새 코드와 테스트 초안을 만드는 데 유용할 수 있다. 그러나 새 구현이 사용자에게 보이는 급여명세서와 내부 원장, 외부 신고 파일을 동일하게 생성하는지 별도 검증해야 한다. 또 개인정보를 포함한 예제 입력을 외부 API로 보내는지, 익명화된 합성 데이터만 쓰는지 데이터 경로를 먼저 확정해야 한다.

AI 모델 실행 쪽에서도 예산 결정은 팀의 실제 데이터로 해야 한다. 같은 8B 모델이라도 텍스트 생성과 임베딩, 배치 요약과 실시간 채팅은 병목이 다르다. 평균 토큰/초가 높은 경로가 승인 화면의 응답 지연에는 불리할 수 있고, 넓은 아키텍처 지원 범위가 우리 모델의 특수 attention을 포함하지 않을 수 있다. TorchNeuron의 장점은 이런 검증을 익숙한 PyTorch 도구로 시작할 수 있다는 데 있다. 검증 과정을 생략할 수 있다는 뜻으로 읽으면 안 된다.

7. 운영 포인트 — 월요일 발표를 화요일 배포 계획으로 바꿀 때

날짜·가용성·성숙도

PyTorch와 Hugging Face의 10월 19일 발표는 10월 20일 공개 베타 시작을 예고했다. KST 오전 11시 30분에 공개 저장소나 패키지가 실제로 내려받아지는지 이 글은 테스트하지 않았다. 베타 안내 문구를 곧바로 사내 표준 플랫폼 확정으로 옮기지 않는다. PoC 계획서에는 확인해야 할 패키지 버전, 지원 인스턴스, 리전, SDK·라이브러리 조합, 모델 아키텍처, 지원 창구를 적는다. 공개 상태를 확인한 뒤에야 재현 가능한 설치 문서를 만든다.

OpenAI 벤치마크 역시 모델이 사용 가능하다는 설명과 특정 기업 코드의 성능 검증을 구분해야 한다. 공개 평가 저장소는 테스트 형식을 확인하고 내부 평가를 설계하는 출발점이다. 공개 점수가 높아도 우리 시스템의 입력 인코딩, 상용 컴파일러 확장, 비표준 SQL은 시험 범위 밖일 수 있다. ‘평균 97.9%’를 우리 전환 프로젝트의 예상 성공률로 적는 순간 근거가 없어진다. 대신 작은 대표 프로그램 묶음을 선정해 파일·모듈·업무 흐름별 차이를 측정한다.

릴리스 게이트를 수치 하나에 맡기지 않는다

코드 마이그레이션 릴리스 게이트는 최소 네 축을 본다. 행동 보존, 성능·확장성, 보안·권한, 복구 가능성이다. 행동 보존에는 중요 금액과 상태 변경의 불일치 건수를, 성능에는 피크 배치 시간과 자원 사용을, 보안에는 데이터 노출 경로와 역할 권한을, 복구에는 장애 시 전환 시간과 재처리 결과를 넣는다. 네 축 중 하나가 심각하게 실패했는데 평균 테스트 통과율이 좋다는 이유로 출시하지 않는다.

새 가속기 도입 게이트도 비슷하다. 품질 정합성, 총비용, 꼬리 지연, 운영 난이도, 공급 가용성을 함께 본다. 총비용에는 칩 사용료뿐 아니라 컴파일 캐시를 만드는 시간, 모델을 새 버전에 맞추는 엔지니어링, 디버깅의 난이도가 포함된다. 모델이 바뀔 때마다 수작업 NKI 커널을 다시 조정해야 한다면 하드웨어 단가의 이익이 줄어든다. 반대로 표준 PyTorch 경로에서 필요한 품질과 처리량이 나오면 네이티브 통합이 운영 비용을 크게 줄일 수 있다. 이는 팀별로 검증할 가설이다.

관측성의 단위를 나눈다

마이그레이션에서는 ‘테스트 실패’ 한 알림만으로 충분하지 않다. 입력 유형, 원본·새 출력의 최소 차이, 영향을 받은 불변조건, 첫 등장 버전, 외부 효과 발생 여부를 함께 기록한다. 플랫폼에서는 요청별 모델 버전, 라이브러리 버전, device, dtype, 시퀀스 길이 버킷, 컴파일 캐시 적중 여부, 재시도, p50·p95·p99를 연결한다. 두 영역 모두 성공처럼 보이는 실패를 찾기 위한 기록이다. 로그가 없는 상태에서 모델만 교체하면 차이의 원인을 모델, 데이터, 하네스, 하드웨어 중 어디에 둘지 알 수 없다.

관측 데이터의 민감도도 관리한다. 레거시 프로그램의 입력에는 주민번호와 급여가, 모델 프로파일에는 사용자 프롬프트나 내부 텐서 형태가 포함될 수 있다. 디버깅을 위해 모든 원문을 무기한 저장할 필요는 없다. 사례 ID와 해시, 최소 재현 입력, 접근 통제된 원문 저장소를 분리하고 필요한 기간을 정한다. 성능 프로파일과 감사 로그가 새로운 개인정보 복제 경로가 되지 않게 해야 한다.

장애 대응에 ‘되돌릴 수 없는 효과’를 먼저 표시한다

코드 번역과 장치 포팅은 로컬 테스트에선 쉽게 되돌릴 수 있다. 그러나 새 시스템이 급여를 지급하거나 고객에게 문서를 발송하고 나면 코드 롤백만으로 세계가 원상복구되지 않는다. 출시 전 runbook에는 어떤 외부 효과가 발생했는지 조회하는 방법, 중복 실행을 막는 키, 정정 통지, 사람 승인 경로가 있어야 한다. 새 가속기의 경우 모델 출력이 불안정하거나 갑자기 비용이 급증할 때 이전 경로로 트래픽을 돌리는 절차를 시험한다. 두 경로의 모델 버전과 결과 차이가 허용 가능한지도 미리 정한다.

8. 오늘의 실행 가능한 검증표

아래 표는 공식 발표를 그대로 옮긴 명령 목록이 아니라 이 글의 실무 제안이다. 공개 벤치마크를 팀의 의사결정으로 변환할 때 누락하기 쉬운 질문을 정리했다.

결정	이번 주에 확보할 증거	아직 주장하면 안 되는 것
레거시 코드 변환 시범	원본 해시, 실행 환경, 대표·경계 입력, 출력 비교기	공개 COBOL 점수가 우리 급여 배치의 성공률이라는 주장
언어별 모델 선택	동일 프로그램 묶음의 완료 건수, 비용, 검토 시간	샘플당 API 비용만으로 전체 프로젝트 원가가 낮다는 주장
Trainium 추론 PoC	목표 체크포인트 로드, 출력 정합성, cold/warm 지연	‘상위 아키텍처 89% 지원’이 모든 체크포인트 지원이라는 주장
Trainium 학습 PoC	여러 스텝의 loss·gradient·체크포인트 복구, 처리량	한 번의 forward 성공이 학습 준비 완료라는 주장
운영 전환	섀도 비교, 불변조건 위반, 롤백·정정 연습	테스트 평균만 높으므로 프로덕션 승인이라는 주장

48시간 안에 할 수 있는 저비용 확인

첫날에는 새 서비스를 구매하거나 전체 저장소를 옮기기보다 표본과 기준선을 준비한다. 가장 대표적인 프로그램 세 개와 가장 위험한 프로그램 두 개를 고른다. 각 프로그램에 입력·출력 포맷, 최근 장애 하나, 경계값 세 가지, 업무 소유자를 붙인다. 원본을 컨테이너나 격리된 빌드 환경에서 재현하고 golden 결과를 만든다. 이 과정이 실패하면 모델을 바꿔도 검증할 기준이 없으므로 여기서 멈추고 원본 시스템을 먼저 문서화한다.

둘째 날에는 한 모델을 사용해 한 프로그램만 변환하고 자동 비교를 돌린다. 실패 케이스는 모델의 자연어 설명이 아니라 원본과 새 코드의 실행 차이로 기록한다. 수정 시도마다 비용과 사람 검토 시간을 남긴다. 같은 날 Trainium PoC를 한다면 공개 베타 패키지와 목표 모델의 정확한 버전을 먼저 고정하고, 기존 GPU 경로와 같은 입력을 사용해 로드·출력·첫 실행·반복 실행을 분리해 잰다. 이 작은 실험이 전체 ROI를 확정하지는 않지만 다음 주의 대규모 시험을 설계할 증거를 준다.

한 달짜리 평가로 확장할 때

작은 표본에서 성공했다고 무작위 프로그램 수를 늘리는 것만으로 충분하지 않다. 시스템의 기능 유형별로 층화한다. 배치 정산, 대화형 조회, 파일 변환, 외부 API 호출, 보안 규칙, 감사 로그를 각각 대표시킨다. 실패 유형이 특정 층에 몰리면 그 층의 케이스를 더 수집한다. 평가가 진행되면서 테스트를 보강할 수는 있지만, 비교한 모델 버전과 시험 버전을 함께 남겨 과거 점수를 새 테스트에 기계적으로 이어 붙이지 않는다.

하드웨어 평가도 목표 워크로드로 층화한다. 짧은 프롬프트의 실시간 질의, 긴 문서 요약, 배치 임베딩, 이미지 생성, 미세조정은 서로 다른 자원 사용을 보인다. 같은 비용표에 묶더라도 어떤 요청에서 이득을 봤고 어디에서 손해를 봤는지 나눠야 한다. 팀이 실제로 쓰지 않는 공개 벤치마크의 최고 처리량보다 서비스의 고객 요청 분포에서 재는 p95 완료 시간이 중요하다.

9. 편집자의 판단: ‘쉬운 시작’은 검증을 더 중요하게 만든다

OpenAI 발표에서 가장 중요한 숫자는 97.9% 하나가 아니다. 저자료 언어에서 장기 코드 작성과 행동 보존을 공개된 방법으로 따로 재겠다는 시도다. 특히 평가 저장소가 테스트 변환 방식과 언어 제한, SQLite 우회 금지, 제한된 기본 표본을 밝힌 점은 숫자의 해석 범위를 분명히 해 준다. 이를 팀이 참고하면 ‘모델이 COBOL을 안다’라는 모호한 주장 대신 ‘이 규칙을 이 입력에서 보존했다’라는 재현 가능한 문장을 만들 수 있다.

TorchNeuron의 중요한 변화 역시 .to('neuron') 한 줄의 상징성만이 아니다. 연구자가 익숙한 PyTorch와 Hugging Face 라이브러리에서 다른 AI 칩을 시험하기 쉬워졌다는 점이다. 접근 문턱이 낮아지면 더 많은 팀이 비교 실험을 할 수 있다. 그러나 베타의 기능 경계, static shape 전략, distributed 통신, 커스텀 커널과 profiler가 그대로 남아 있다. 결론은 특정 칩이 모든 GPU를 대체한다는 선언이 아니라, 우리 워크로드에서 다른 선택지를 공정하게 평가할 수 있는 기반이 넓어졌다는 것이다.

두 흐름을 묶으면 AI 개발자의 새로운 책임이 보인다. 모델은 코드를 빠르게 쓰고 플랫폼은 여러 하드웨어에 같은 프레임워크를 제공한다. 그럴수록 구현의 겉모양이 비슷해져 잘못된 동일성 가정이 늘 수 있다. 성공 기준을 출력 바이트, 상태 전이, 비용 분모, p95 지연, 복구 시간으로 구체화해야 한다. ‘잘 돌아간다’는 말은 파일을 어떻게 비교했고 어느 입력에서 돌렸으며 운영 중 실패를 어떻게 알 수 있는지 답할 때에만 의미가 있다.

부록 A. COBOL 행동 보존을 재현 가능한 시험으로 바꾸는 설계

A-1. 원본 프로그램이 ‘같다’고 판단할 관측면을 먼저 정한다

레거시 전환의 핵심은 원본 코드를 줄 단위로 새 언어에 대응시키는 것이 아니다. 사용자가 관측할 수 있는 면을 목록화하는 것이다. 화면에서 확인하는 결과와 내부 파일에 쓰인 레코드가 다를 수 있고, 호출자에게 반환한 코드와 로그에 남긴 실패 사유가 다를 수 있다. 동일성 판정은 stdout만으로 할 수 없다. 배치 프로그램이라면 입력 파일의 읽기 순서, 출력 파일의 레코드 정렬, 중간 파일 존재 여부, 종료 코드, 표준 오류, 트랜잭션 커밋 결과가 관측면이다. 온라인 서비스라면 API 응답, 데이터베이스 상태, 이벤트 발행, 알림, 감사 기록이 포함된다.

각 관측면에는 엄격도를 부여한다. 금액·계좌·직원 ID·유효일은 정확 일치가 필요할 가능성이 높다. 타임스탬프가 현재 실행 시각을 포함한다면 정해진 허용 범위로 비교할 수 있다. 로그 메시지는 글자 하나까지 동일해야 할 수도 있지만 사람이 읽는 부가 정보일 수도 있다. 이 차이는 담당자가 의도적으로 결정해야 한다. ‘대충 비슷하면 통과’라는 전역 규칙은 사용자가 의존하는 작은 차이를 감춘다. 반대로 모든 출력 바이트의 완전 동일성을 강제하면 무해한 실행 시각 차이가 거짓 실패를 쌓는다. 테스트는 무조건 엄격하거나 느슨한 것이 아니라 필드별 이유가 있는 엄격도를 가져야 한다.

원본을 golden oracle로 삼을 때에도 원본 오류를 사실로 절대화하지 않는다. 원본 시스템이 특정 날짜에 실패했지만 운영자가 수동으로 수정했다면 두 결과를 모두 보존한다. legacy_observed는 기계가 실제 만든 값이고 business_approved는 조직이 최종적으로 인정한 값이다. 새 구현이 어느 쪽을 따라야 하는지는 변경 건별 의사결정이다. 동작 보존 단계에서는 기본적으로 관측값을 재현하고, 버그 수정 단계에서는 승인된 새 값을 따른다. 두 단계를 같은 테스트에 넣으면 모델이 맞아도 실패하고 틀려도 통과하는 혼란이 생긴다.

A-2. 금액과 날짜는 예시가 아니라 타입 계약이다

COBOL의 고정 소수점 표현은 일반적인 부동소수점과 다르다. 새 구현에서 Python float나 JavaScript Number를 편하게 쓰면 입력에 따라 이진 부동소수점의 오차가 생길 수 있다. 그렇다고 임의로 Decimal을 썼다는 사실만으로 같아지지는 않는다. 소수 자릿수, 절사·반올림 모드, 오버플로 처리, 음수의 표현, 중간 계산의 자릿수 제한을 원본과 비교해야 한다. 세 단계 계산에서 각 단계마다 자릿수를 버리는 원본과 마지막에 한 번만 버리는 새 코드는 같은 수식을 사용해도 다른 결과를 낸다.

날짜도 YYYY-MM-DD 문자열로 보이면 간단해 보이지만 세부 규칙은 길다. 2자리 연도의 세기 전환, 휴일 규칙의 적용 지역, 실행 서버의 시간대, 하루의 마감 기준, 윤년, 달력상 없는 날짜, 퇴사일 당일의 포함 여부가 다를 수 있다. 배치가 UTC 자정에 돌다가 KST 기준일을 잘못 잡으면 정산 대상이 바뀐다. 원본 프로그램이 로컬 타임존을 암묵적으로 사용했다면 새 구현은 그 의존성을 명시해야 한다. 마이그레이션 프로젝트에서 날짜 필드마다 ‘저장 형식’, ‘업무 기준일’, ‘표시 시간대’, ‘경계일 처리’를 따로 써야 하는 이유다.

입력 파일의 숫자 필드에서 공백, 앞자리 0, 후행 부호 같은 표현은 파싱 관점에서만 보지 않는다. 다운스트림이 원래 형식에 의존할 수 있다. 금액 12.3과 12.30은 수학적으로 같아도 고정 폭 파일에서는 다른 문자열이다. 새 구현이 더 읽기 좋은 JSON을 출력하는 것은 인터페이스를 개선하는 일이지만, 원래 시스템을 바꾸는 일과 구분해야 한다. 호환 레이어에서 예전 형식을 유지한 뒤 새 계약으로 서서히 전환할 수도 있다. 이때 어느 소비자가 어떤 버전을 읽는지 목록을 만들어야 한다.

A-3. 성공 경로보다 예외 경로가 많은 정보를 준다

일반적으로 모델이 만드는 첫 구현은 행복 경로를 잘 설명한다. 테스트 설계는 오히려 예외 경로를 강화해야 한다. 파일이 없는 경우, 파일은 있지만 0바이트인 경우, 헤더만 있는 경우, 같은 고객의 레코드가 두 번 나오는 경우, 참조 마스터에 ID가 없는 경우를 분리한다. 모두 ‘입력 오류’로 묶으면 원본의 복구 방식이 사라진다. 어떤 오류는 전체 배치를 중지해야 하고, 어떤 오류는 해당 레코드만 보류하며 나머지를 처리해야 한다. 보류 기록이 별도 파일로 나가는지도 검증한다.

입력 순서가 달라졌을 때 결과가 같아야 하는지 역시 업무 규칙이다. 원본이 정렬된 입력을 전제로 했다면 새 코드는 무작위 순서를 처리하면서도 원본과 다르게 작동할 수 있다. 이를 개선으로 받아들일지, 원래 전제를 명시하고 위반 시 실패하도록 할지는 별도 결정이다. 평가에서는 원본과 새 구현을 같은 사전조건 아래 비교하고, 사전조건을 벗어나는 입력은 새 계약 설계의 과제로 분리한다. 테스트의 실패가 개발자에게 무엇을 알려 주는지 분명해야 한다.

인터럽트와 재시작도 예외 경로다. 월말 100만 레코드 중 70만 번째에서 실패했을 때 원본 시스템이 처음부터 다시 돌았는지, 마지막 성공 체크포인트에서 재개했는지, 이미 보낸 통지를 재발송했는지 확인한다. 새 구현이 처리 결과만 같아도 실패 후 재시도에서 두 번 지급하면 사용할 수 없다. 따라서 한 번 실행의 출력 비교와 장애 주입 뒤 복구 테스트를 분리한다. 전자는 기능 정확성, 후자는 운영 정확성이다.

A-4. 테스트 데이터는 개인정보를 제거해도 의미를 보존해야 한다

급여·보험·은행 프로그램을 시험하려면 현실적인 관계와 분포가 필요하다. 그런데 실고객 자료를 외부 모델에 그대로 넣는 것은 위험하다. 모든 값에 임의의 난수를 넣으면 관계가 깨져 필요한 경계가 사라질 수 있다. 대안은 원본 데이터의 분포와 관계를 분석한 뒤 합성 사례를 만드는 것이다. 예를 들어 ‘근속 1년 직전 퇴사’, ‘월말 입사’, ‘다중 직책’, ‘과거 정정’, ‘휴일 중복’처럼 업무 의미를 유지한 가짜 직원 레코드를 만든다. 개인정보 제거와 시험 유효성을 둘 다 목표로 삼는다.

생성한 데이터가 모델 학습·평가에 적합한지 사람이 검토해야 한다. 이름만 바꾼 실제 거래 행은 익명화가 아닐 수 있다. 또 값의 분포를 지나치게 평탄하게 만들면 희귀한 조합을 잃는다. 테스트 카탈로그에는 synthetic, deidentified, public_example을 구분하고 접근 수준을 다르게 둔다. 실데이터가 반드시 필요한 검증은 내부의 승인된 환경에서만 수행하고 외부 API 호출 경로를 차단하거나 적절한 계약·정책을 적용한다. 평가 방식의 설계가 데이터 거버넌스 설계와 연결된다.

A-5. 모델에게 주는 문맥도 버전 관리한다

원본 코드만 붙여 주고 ‘현대화해 줘’라고 하면 모델은 언어 문법뿐 아니라 업무 의도까지 추정해야 한다. 문서, 입출력 예시, 확인된 불변조건, 금지된 변경, 목표 언어의 런타임, 테스트 명령을 함께 제공하면 결과를 검증하기 쉬워진다. 단, 너무 많은 정책 문서를 한 번에 넣으면 서로 다른 시행일과 지역 규정이 섞일 수 있다. 컨텍스트는 작업 대상에 관련된 버전만 선택하고 문서의 유효 날짜를 표시한다.

프롬프트와 도구 목록, 모델 버전, 추론 노력, 컨텍스트 파일의 커밋을 같은 실험 ID에 연결한다. 한 번 성공한 결과를 다음 달 재현하지 못하면 성능 비교가 어렵다. ‘모델만 변경’과 ‘테스트도 보강’이 동시에 일어나면 점수가 좋아진 원인을 알 수 없다. 기업 환경에서 평가를 연구 논문처럼 완벽히 통제할 필요는 없지만, 최소한 달라진 변수를 기록해야 예산과 위험 결정을 할 수 있다.

부록 B. MultiLangBench 수치를 읽는 세밀한 방법

B-1. 모델 평균과 언어별 최저점을 동시에 본다

20개 언어 평균은 폭넓은 능력의 신호다. 하지만 특정 기업은 20개를 모두 사용하지 않는다. COBOL만 쓰는 팀에게 Astra의 전체 평균 87.4%보다 COBOL 72.1%가 가까운 출발점이다. 반대로 Visual Basic 프로그램을 옮기는 팀은 해당 언어의 결과를 참고하되, 그 언어에서도 자신의 UI·데이터 접근 패턴이 공개 SQLite 구현 과제와 얼마나 닮았는지 따져야 한다. 언어 이름이 같아도 과제 종류가 다르면 실패 모드가 달라진다.

발표에서 GPT‑6 Luna도 모든 언어에서 비교 모델보다 나아졌다고 설명하지만 COBOL 예시는 17.1%다. 이는 같은 언어의 Astra 72.1%와 격차가 크다. 따라서 ‘저렴한 모델을 먼저 써서 안 되면 강한 모델을 부른다’는 라우팅을 생각할 수 있다. 다만 실패를 자동으로 감지할 수 있을 때만 유효하다. 눈에 띄게 실패한 컴파일 오류는 다시 시도하면 되지만, 조용히 잘못된 수수료를 계산한 코드는 약한 모델의 결과가 게이트를 통과해 버릴 수 있다. 라우팅의 전제는 독립된 정확성 판정기다.

B-2. 평가가 배제한 도구를 실제 개발에서는 다시 판단한다

MultiLangBench는 기존 SQLite를 호출해 과제를 우회할 수 없도록 환경을 제약한다. 모델의 구현 능력을 재기 위한 타당한 통제다. 그러나 기업의 실제 개발에서는 검증된 라이브러리 재사용이 새로운 엔진을 직접 구현하는 것보다 안전한 경우가 많다. 공개 평가의 제약을 곧바로 프로덕션 설계의 금지 규칙으로 옮기면 안 된다. 벤치마크가 답하는 질문은 ‘이 모델이 주어진 언어로 복잡한 소프트웨어를 얼마나 만들 수 있는가’이고, 실제 프로젝트의 질문은 ‘어떤 구성으로 업무를 가장 안전하고 경제적으로 완수할 수 있는가’다.

따라서 자체 시험은 두 층을 둘 수 있다. 첫 층은 공개 평가를 최대한 재현해 모델 능력을 비교한다. 둘째 층은 현실적인 도구 접근과 리뷰 프로세스를 허용해 전체 개발 워크플로의 결과를 비교한다. 첫 층에서 점수가 낮은 모델도 기존 테스트와 라이브러리, 엄격한 하네스 아래에서는 유용할 수 있다. 첫 층에서 높은 모델도 사내 방대한 레거시 저장소에서 약할 수 있다. 두 시험을 하나로 대체하지 말아야 한다.

B-3. 비용 추정의 단위를 확장한다

발표의 API 비용 비교는 실험 당시 가격과 호출 조건에 의존한다. 코드 생성 작업에는 읽은 문서, 작업 중의 시행착오, 도구 출력, 테스트 실패 분석이 비용으로 들어간다. 같은 과제를 한번씩 수행한 비용과, 목표 통과율에 도달하기까지 여러 번 시도한 비용은 다르다. 기업 환경에서는 테스트 인프라의 실행 시간과 사람의 승인 시간도 비용이다. 특히 COBOL 전문가가 적다면 그 시간은 희소 자원이다. 빠른 초안을 만들더라도 검토가 오래 걸리는 코드 스타일은 프로젝트 전체를 지연시킨다.

비용 표에는 후보 코드 생성비, 테스트 실행비, 리뷰 시간, 실패 재시도비, 운영 결함 기대비용을 분리한다. 마지막 항목은 정확히 산정하기 어렵지만 0으로 두면 위험한 결정이 된다. 최소한 심각도와 복구 난이도의 범위로 민감도 분석을 한다. 모델 A가 호출당 2달러, 모델 B가 1달러여도 B의 실패가 감사·재정산을 유발한다면 B가 비싸다. 실제 실패 확률을 모르면 작은 파일럿과 섀도 실행으로 범위를 줄여야 한다.

B-4. 통계적 불확실성을 숨기지 않는다

공개 발표의 단일 백분율은 평가 집합에서 관측한 값이다. 재시도마다 변동이 있는 모델이라면 같은 과제를 여러 번 풀어 분산을 확인해야 한다. 20개 언어 평균도 언어별 과제 수와 난도를 알지 못하면 팀의 작업 분포로 바로 가중할 수 없다. 내부 평가에서는 성공률의 점 추정뿐 아니라 케이스 수, 반복 횟수, 통과 기준, 실패 분류를 함께 공개한다. 케이스가 10개인데 9개를 맞힌 결과와 케이스가 1,000개인데 900개를 맞힌 결과는 둘 다 90%지만 신뢰 구간과 실패 유형 분석의 깊이가 다르다.

작은 표본을 고를 때는 쉬운 프로그램만 나열하지 않는다. 입력 길이, 분기 수, 외부 의존성, 계산 민감도, 테스트 가능성으로 층화한다. 그다음 모델별로 같은 표본을 사용한다. 한 모델의 실패 사례만 수정해 재평가한다면 개선의 원인을 구분할 수 있도록 시험 집합 버전을 올린다. 장기적으로는 발견한 장애를 회귀 집합에 편입하되, 이미 그 장애를 보고 수정한 모델과 처음 보는 모델의 점수 비교를 동일한 일반화 시험이라고 부르지 않는다.

부록 C. Trainium 도입 시험을 설계하는 기술 체크포인트

C-1. 모델 로드에서 확인할 것

첫 번째 실험은 라이브러리 설치가 아니라 목표 체크포인트를 로드하는 것이다. 모델 ID, 리비전, 라이선스, 필요한 custom code, 토크나이저, 가중치 형식, dtype을 고정한다. device_map='neuron'으로 동작하는지 확인하되, 로드 중 일부 모듈이 CPU에 남거나 특정 연산이 미지원으로 실패한다면 그 상태를 기록한다. ‘코드가 실행됐다’는 문구보다 실제 모듈별 장치 배치표가 유용하다. 같은 모델 이름이라도 리비전이 바뀌면 모델 구조나 커스텀 구현이 바뀔 수 있다.

첫 추론은 아주 짧은 입력과 긴 입력을 모두 사용한다. 정적 캐시가 필요한 경로에서는 최대 시퀀스 길이와 생성 길이를 명시한다. 기본 예시가 1,024토큰이면 프로덕션의 32,000토큰 문서 요약을 대표하지 않는다. 길이를 키울 때 메모리 요구와 컴파일 그래프 수, 첫 응답 시간이 어떻게 변하는지 측정한다. 배치 크기를 바꾸면 padding 낭비와 처리량이 함께 바뀌므로 단일 요청의 성공으로 동시성을 추정하지 않는다.

C-2. 출력 정합성을 ‘같은 문자’로만 보지 않는다

생성 모델은 확률적이므로 GPU와 Trainium에서 모든 답변 문자열이 같아야 한다고 요구하기 어렵다. 먼저 결정론적 설정에서 로짓 또는 짧은 생성의 차이를 계측하고, 이후 실제 업무 평가에서 답변 품질을 비교한다. 수학·코딩·분류처럼 객관적인 채점이 가능한 작업은 동일한 평가 데이터를 사용한다. 사용자용 대화는 블라인드 사람 평가나 검증된 과제 판정기를 사용하되 평가자의 불확실성도 기록한다. 모델 버전을 고정하지 않고 장치만 바꾼다고 말하면 비교 실험이 아니다.

미세조정에서는 초기·중간·최종 체크포인트를 비교한다. 손실 곡선이 비슷해도 중요한 클래스의 정확도가 낮아질 수 있다. optimizer state를 저장했다가 복구했을 때 학습이 정상적으로 이어지는지, 분산 노드 장애 후 복구가 가능한지, 같은 데이터 순서로 다시 실행했을 때 큰 발산이 없는지 확인한다. 공개 글의 ‘표준 Transformers 체크포인트를 저장한다’는 것은 이식성에 좋은 신호지만, 고객의 전체 파이프라인에서 복구가 검증됐다는 뜻은 아니다.

C-3. 비용을 칩 시간만으로 나누지 않는다

하드웨어 비용 비교에서 흔한 오류는 한 시간 가격을 동일 분모로 두고 계산하는 것이다. 실제로는 성공한 작업 / 총벽시계 시간, p95 완료 시간, 사용한 인스턴스 수, 컴파일·재시작 낭비, 유휴 예약 시간을 본다. 긴 학습 작업은 높은 처리량이 중요하지만, 낮은 트래픽의 서비스는 유휴 비용이 더 큰 변수일 수 있다. 트래픽이 한 시간에 몰리면 스케일 아웃과 그래프 준비 시간이 중요하다. 두 플랫폼의 자동 확장 방식과 최소 인스턴스 유지 비용을 같은 조건으로 놓고 비교한다.

메모리 용량이 달라 배치 크기가 달라질 수 있으므로 장치당 토큰/초만 비교해도 부족하다. 전체 서비스가 처리한 유효 토큰, 실패 재시도, 사용자 요청의 실제 완료율을 측정한다. padding 토큰을 처리량에 포함하면 긴 길이 버킷을 쓰는 시스템의 숫자가 좋아 보일 수 있다. 요청당 유효 토큰과 낭비 토큰을 분리하면 동적 길이의 경제성을 평가할 수 있다. 컴파일 그래프를 공유할 수 있는지, 모델을 여러 버전 띄울 때 메모리가 어떻게 분할되는지도 운영 비용이다.

C-4. 성능 회귀를 어느 층에서 찾을지 정한다

TorchNeuron의 profiler 통합은 분석 경로를 개선할 수 있지만, 계측 목표가 없으면 방대한 이벤트만 쌓인다. 먼저 전체 요청을 토크나이즈, host-to-device, 컴파일, prefill, decode, device-to-host, 후처리로 나눈다. 학습이면 데이터 로딩, forward, backward, optimizer, checkpoint 저장과 통신 시간을 분리한다. 변화가 생긴 층을 찾은 뒤 소스 라인과 장치 이벤트를 확인한다. 모든 릴리스에서 전체 프로파일을 수집하기보다 대표 워크로드와 회귀 조건을 고정해 비교한다.

실험에는 예상 가능한 실패도 주입한다. 지원하지 않는 연산을 호출했을 때 어떤 오류가 뜨는지, 장치 메모리가 부족하면 프로세스가 어떻게 복구되는지, 노드가 사라지면 분산 학습이 어느 단계에서 멈추는지 본다. 에러가 다음 동기화 지점에서 나타날 수 있다는 PyTorch 공식 설명은 디버깅에서 중요하다. 예외가 보고된 파이썬 줄이 반드시 원인이 된 연산의 줄은 아닐 수 있다. 트레이스와 최초 오류 컨텍스트를 함께 보관해 원인을 잘못 지목하지 않는다.

C-5. 베타의 버전 정책을 서비스 정책으로 옮긴다

공개 베타는 새로운 기능을 빠르게 시험할 기회지만 인터페이스와 지원 범위가 변할 수 있다. 라이브러리 의존성을 무제한 최신 버전으로 두지 말고 실험에서 검증한 조합을 잠근다. 모델 아키텍처 지원 폭이 넓더라도 특정 transformers, diffusers, torch, torch-neuronx 조합에서만 확인했을 수 있다. 업그레이드마다 로드·정합성·성능·복구 회귀를 실행한다. 실패하면 즉시 이전 조합으로 돌아갈 수 있게 이미지와 체크포인트를 보존한다.

베타 기능을 고객 서비스에 사용할지 결정할 때에는 해당 기능이 핵심 경로인지 대체 가능한 경로인지 본다. 실험적 adaptive eager나 private beta의 FP8을 핵심 SLA의 유일한 성능 수단으로 삼으면 지원 상태 변화에 취약하다. 안정된 기본 경로에서 서비스 목표를 충족하는지 확인하고, 새로운 최적화는 추가 이익으로 취급한다. 공식 발표의 ‘지원 예정’과 현재 버전의 ‘실측 지원’을 내부 문서에서 다른 색으로 표시하는 것도 혼동을 줄인다.

부록 D. 실제 팀이 마주칠 실패 시나리오 12개

다음 시나리오는 공식 발표의 추가 실험 결과가 아니라 편집자가 두 기술을 평가할 때 쓰도록 구성한 검증 사례다. 공개 점수의 재현을 주장하지 않는다. 의도는 테스트 통과라는 단일 지표 뒤에 숨을 수 있는 차이를 명확한 입력·관측·대응으로 바꾸는 것이다. 각 시나리오에는 적어도 하나의 자동 판정 기준과 실패 시 사람이 확인할 질문을 둔다.

D-1. 소수점의 마지막 한 자리

원본 급여 배치가 시간당 임금을 세 단계로 계산한다고 가정하자. 기본급을 일할 계산한 뒤 수당을 더하고, 마지막에 공제액을 뺀다. 원본은 각 단계에서 소수 둘째 자리 아래를 버리지만 새 언어의 일반적인 통화 라이브러리는 최종 단계에만 반올림할 수 있다. 예제 숫자 하나로는 이 차이를 놓치기 쉽다. 중간 단계에서 경계값을 넘는 입력을 생성하고 세 단계의 값과 최종 지급액을 모두 비교해야 한다. 결과 파일만 같다고 해도 내부 원장이 다른지 확인한다.

차이가 발견되면 단순히 새 코드에 절사 함수를 넣고 종료하지 않는다. 원본 규칙이 실제 정책인지, 오래된 컴파일러의 부작용인지 확인한다. 행동 보존을 목표로 하는 릴리스라면 우선 원본과 같게 만들고, 정책 개선이 필요하다면 별도 변경으로 올린다. 이런 구분 없이 ‘새 구현이 더 정확하다’고 조용히 배포하면 기존 회계 기간과 새로운 기간의 합계가 달라져 사후 감사가 어려워진다.

D-2. 없는 직원과 퇴사한 직원

인사시스템에 직원 ID가 없을 때와 직원은 있지만 퇴사한 상태일 때 원본이 다른 오류 코드를 반환할 수 있다. 모델이 두 경우를 모두 NotFound로 정리하면 코드 구조는 깔끔하지만 업무 의미는 달라진다. 퇴사 직원의 과거 급여 정정은 허용되고 새 근태 입력은 금지될 수 있다. 따라서 사번 조회와 상태 검사를 독립된 테스트로 두고, 과거 기준일을 넘겨 조회할 때 어떤 상태를 기준으로 판단하는지 확인한다.

이 차이는 외부 효과에도 이어진다. 잘못된 오류로 인해 사용자가 권한 없는 재시도를 반복하거나, 자동 처리기가 예외를 무시하고 다음 단계로 넘어갈 수 있다. 응답 코드와 본문, 로그의 분류, 재시도 가능 플래그를 함께 비교한다. 상태값의 의미는 언어가 아니라 도메인 계약이다.

D-3. 파일은 정확한데 레코드 순서가 다르다

새 구현이 레코드를 병렬 처리하며 출력 순서를 바꿨다고 하자. 모든 행의 데이터는 정확하고 집계도 맞다. 이 경우 순서가 의미 없다고 판단해 정규화 비교를 하고 싶어진다. 그러나 다운스트림 시스템이 첫 행을 헤더 다음의 대표 계정으로 읽거나 동일 고객의 레코드가 연속된다고 가정할 수 있다. 입력을 의도적으로 섞은 뒤 원본과 새 파일의 순서, 다운스트림 파서의 결과를 확인한다.

순서가 계약에 포함되지 않았더라도 운영 관행상 의존성이 있다면 바로 제거하지 않는다. 먼저 소비자를 찾아 명시적 버전 전환을 설계한다. 반대로 모든 소비자가 순서 독립성을 보장하고 검증했다면 그 사실을 기록하고 비교기에서 정렬해도 된다. 정규화는 편의가 아니라 증거를 가진 정책이다.

D-4. 오류가 난 날의 재실행

월말 급여 파일을 80% 처리한 뒤 네트워크 오류가 발생한다. 새 구현이 다시 시작되면서 전체 파일을 처음부터 읽고 외부 지급 요청을 중복으로 보낸다면 최종 계산 파일은 맞아도 실제 지급은 틀린다. 시험 환경에서 처리 중간에 프로세스를 종료하고 다시 실행한다. 같은 job_id에 대해 지급 요청이 몇 번 발생했는지, 이전 실행의 상태를 어떻게 조회했는지, 재시작 시점이 어디인지 본다.

멱등 키가 있다면 키가 충돌하지 않고 같은 요청에서 재사용되는지도 확인한다. 오류 응답이 ‘요청이 실패했다’가 아니라 ‘응답을 못 받았다’일 수 있다. 결과가 불명확할 때는 재송신 전에 외부 시스템을 조회하는 절차가 필요하다. AI가 만든 새 코드를 평가할 때 이 경로를 빼면 가장 비싼 실패는 시험 밖에 남는다.

D-5. 다른 문자 인코딩의 같은 이름

레거시 파일이 특정 단일 바이트 인코딩과 고정 폭 필드로 사람 이름을 저장한다고 하자. 새 구현은 UTF-8 문자열 길이를 문자 수로 계산해 필드를 자른다. 화면에는 똑같이 보이더라도 바이트 수가 달라 다음 필드의 시작 위치가 밀릴 수 있다. 이름의 길이 경계, 한글·라틴 문자·기호의 혼합, 빈 값과 전각 문자를 포함한 입력으로 파일의 바이트 오프셋을 검증한다.

이 시험은 사용자 인터페이스의 표시가 맞는지와 별도다. 화면이 맞아도 파일 소비자가 잘못된 직급이나 급여 금액을 읽으면 심각하다. 내부 표현은 현대화하더라도 레거시 인터페이스는 정확한 인코딩 어댑터를 통해 출력하고, 소비자 전환이 완료되기 전에는 형식을 바꾸지 않는다. 출력 바이트를 확인하는 이유가 여기 있다.

D-6. 모델이 기존 SQLite를 호출해 점수를 얻는다

MultiLangBench를 재현하면서 시스템에 설치된 sqlite3 명령이나 라이브러리를 그대로 남겼다면 모델은 엔진을 구현하지 않고 호출할 수 있다. 회사의 제품 개발이라면 검증된 SQLite 사용이 올바른 선택일 수 있지만, 모델 구현 능력 평가에서는 답이 달라진다. 공개 저장소가 모든 SQLite 흔적을 제거하라고 하는 이유는 이 우회 경로 때문이다. 시험 중 생성한 실행 파일의 의존성과 라이브러리 호출을 확인한다.

평가 보고서는 이렇게 두 질문을 분리한다. ‘모델이 해당 언어로 엔진을 구현했는가’와 ‘팀이 표준 라이브러리를 활용해 업무 기능을 빨리 만들었는가’는 모두 가치 있지만 같은 점수표에 넣지 않는다. 벤치마크 결과를 마케팅처럼 사용하려면 그 평가의 금지 조건을 지켜야 하고, 실제 제품 설계는 오히려 재사용 가능한 라이브러리를 적극 검토해야 한다.

D-7. 지원 아키텍처지만 체크포인트가 로드되지 않는다

Hugging Face의 상위 아키텍처 지원 통계에 목표 모델의 계열이 포함됐다고 하자. 그러나 팀이 사용하는 체크포인트는 별도의 원격 코드를 필요로 하거나 새로운 attention 구현을 쓴다. from_pretrained() 단계에서 실패하거나 일부 레이어만 CPU에 남을 수 있다. 지원 표를 본 즉시 비용 견적을 내지 말고 목표 리비전과 정확한 의존성 버전을 고정해 실제 로드를 수행한다.

로드 성공 이후에는 device placement를 출력하고 짧은·긴 입력의 결과를 비교한다. 일부 레이어가 CPU로 폴백되면 단일 입력에서는 성공처럼 보이지만 동시성에서 전송 비용이 급증할 수 있다. 지원 범위는 ‘아키텍처 레벨의 출발점’이고 우리 체크포인트의 운영 적합성은 팀이 측정해야 하는 별도 결과다.

D-8. 공개 베타의 첫 실행이 느리다

TorchNeuron 경로에서 반복 실행의 처리량이 훌륭한데 첫 요청이 모델 로드와 그래프 컴파일 때문에 오래 걸릴 수 있다. 야간 배치라면 큰 문제가 아닐 수 있으나 대화형 HR 승인 화면에서는 사용자가 기다릴 수 없는 지연이다. 워밍된 p50만 보고하지 말고 배포 직후, 스케일 아웃 직후, 새로운 입력 길이 버킷이 처음 들어온 시점의 p95를 따로 측정한다.

워밍 전략은 서버를 항상 켜 두는 비용을 만든다. 여러 모델을 자주 교체하는 팀이라면 각 버전의 컴파일 산출물과 메모리 점유도 더해진다. 따라서 가격표의 인스턴스 시간뿐 아니라 초기화 전략을 포함한 비용으로 비교한다. 짧은 작업과 긴 작업을 다른 경로로 라우팅하는 방식도 검토할 수 있지만, 라우팅이 품질 차이를 만들지 않는지 별도 평가해야 한다.

D-9. 정적 캐시 때문에 드문 긴 요청만 실패한다

실험의 평균 입력 길이는 800토큰이고 설정한 max_cache_len은 1,024다. 일반 요청은 빠르게 처리되지만 분기말 정책 문서처럼 6,000토큰의 입력이 들어오면 예외가 발생하거나 잘린다. 입력 길이의 평균이 아니라 분포의 꼬리를 수집해야 한다. 길이 초과 시 사용자에게 오류를 줄지, 문서를 분할할지, 다른 경로로 보낼지 제품 정책도 필요하다.

분할 요약은 원본 정보를 잃을 수 있으므로 위험한 지시를 자동으로 잘라 처리하지 않는다. 예컨대 직원의 개인별 권한 결정을 긴 문서의 일부만 읽고 하면 안 된다. 긴 입력 라우팅의 테스트에는 내용이 문서의 끝에 있을 때와 중간에 서로 모순된 정책이 있을 때를 포함한다. 하드웨어 성능 최적화가 답변 신뢰성을 낮추지 않도록 한다.

D-10. 학습은 끝났지만 체크포인트가 다른 장치에서 열리지 않는다

Hugging Face의 예시는 trainer.save_model이 표준 Transformers 체크포인트를 쓴다고 설명한다. 실제 팀의 학습 코드는 PEFT 어댑터, 토크나이저 파일, 사용자 정의 config, optimizer state를 추가할 수 있다. 학습 종료 메시지와 저장 파일 존재만으로 이식성을 판단하지 말고 별도 환경에서 모델을 로드해 추론하고, 필요하면 학습을 이어서 실행한다. 모든 필요한 아티팩트의 버전과 해시를 남긴다.

중단 복구는 생산성을 좌우한다. 20시간 학습 뒤 19시간째 노드 장애가 나면 처음부터 다시 해야 하는지에 따라 비용이 크게 다르다. 몇 시간 간격의 체크포인트를 강제로 복구해 loss와 처리량을 비교한다. 저장 형식이 표준이라는 장점과 실제 운영 복구가 검증됐다는 결론은 다른 단계다.

D-11. 커널 하나는 빠른데 서비스는 거의 그대로다

NKI 커널 예시에서 특정 비전 연산이 최대 2.4배 빨라졌다고 하자. 우리 이미지 파이프라인에서는 그 연산이 총 시간의 4%뿐이다. 그 부분을 무한히 빠르게 만들어도 이론상 전체 지연은 약 4% 정도만 줄어든다. 소스 라인과 장치 트레이스를 연결해 병목 비중을 본 뒤 최적화 순서를 정한다. 커널 수치만으로 프로젝트의 ROI를 계산하지 않는다.

반대로 토큰별로 매번 호출되는 작은 연산이라면 개별 실행 시간이 짧아도 전체 기여가 크다. 호출 횟수와 누적 장치 시간, 메모리 이동을 함께 본다. 사용자 정의 커널은 유지 비용이 있으므로 목표 이익과 테스트 범위를 PR에 적는다. 나중에 라이브러리 기본 구현이 개선되면 사용자 정의 경로를 제거할 수 있게 성능 게이트를 자동화한다.

D-12. 하나의 수치가 회귀를 가린다

새 언어 구현의 전체 테스트 통과율이 높아졌지만 퇴사자 정산만 악화될 수 있다. 새 장치의 평균 지연이 좋아졌지만 32,000토큰 문서의 p99가 악화될 수 있다. 두 경우 모두 평균을 하나만 보고 배포하면 특수하지만 중요한 고객군이 피해를 본다. 평가 리포트에 도메인 기능·입력 길이·오류 유형별 표를 함께 둔다. 각 층의 최소 기준과 전체 기준을 동시에 만족해야 출시한다.

이런 층화는 특정 모델이나 칩을 불리하게 만들기 위한 것이 아니다. 어떤 작업에서 강점이 있고 약점이 있는지 알면 더 나은 라우팅과 제품 경계를 정할 수 있다. 완벽한 범용 시스템 하나를 요구하는 대신, 위험이 다른 작업에 서로 다른 경로를 배치하고 사용자에게 결과를 일관되게 제공할 수 있다. 중요한 것은 낮은 성능이 드러난 층을 평균 속에 숨기지 않는 것이다.

부록 E. 승인 회의에 가져갈 비교 문서의 형식

E-1. 첫 페이지는 수치가 아니라 결정 질문이다

기술 도입 회의에서 벤치마크 표를 첫 장에 넣으면 참석자는 숫자의 우열부터 논의한다. 그 전에 ‘무슨 결정을 언제 내려야 하는가’를 한 문장으로 적는다. 예를 들면 ‘이번 분기 급여 배치의 COBOL 3개 프로그램을 읽기 전용 섀도 실행으로 전환할지’ 또는 ‘내년의 문서 요약 추론 서비스에 Trainium 경로를 하나 추가할지’다. 결정 질문이 다르면 시험 대상과 성공 기준도 달라진다. 범용 AI 도입이라는 제목은 책임 소재를 흐린다.

두 번째는 변경하지 않을 조건이다. 급여 불일치 0건, 특정 접근 권한 유지, 감사 출력 보존, 외부 통지의 중복 금지처럼 조직이 양보할 수 없는 조건을 적는다. 새 하드웨어라면 모델 품질 하락 허용 범위, 고객 요청의 p95 최대치, 장애 시 GPU 경로 복귀 시간 등을 적는다. 그다음에 공개 발표 수치를 참고 자료로 놓는다. 공개 수치는 우리 조건에서 통과할지 시험할 우선순위를 정하는 데 도움을 줄 수 있지만, 내부 시험 결과를 대신하지 않는다.

E-2. 표에는 관찰·추정·가정을 구분한다

‘OpenAI 발표에서 GPT‑6.1 Sol의 높은 노력 마이그레이션 정확도 97.9%’는 공개 자료에서 관찰된 수치다. ‘우리 급여 프로그램도 97.9% 맞을 것’은 근거 없는 추정이다. ‘우리 프로그램 20개 중 18개가 golden 테스트를 통과했다’는 내부 관찰이다. 세 문장을 같은 색의 셀에 넣지 않는다. 자료 출처와 날짜, 시험 환경을 각 수치 옆에 적는다. 측정하지 않은 비용이나 가용성은 빈칸으로 두고 담당자와 측정 예정일을 지정한다.

가정은 특히 ROI 계산에 중요하다. 한 달 요청량, 입력 길이, 피크 동시성, 인스턴스 유휴 시간, 엔지니어링 시간의 금액화가 실제와 다르면 비용 결론이 바뀐다. 단일한 ‘절감률 30%’ 대신 입력 가정을 높고 낮게 바꿨을 때 결론이 유지되는지 보여 준다. 불확실성이 큰 변수가 무엇인지 알면 다음 실험에 예산을 집중할 수 있다.

E-3. 실패 사례를 숨기지 않는 문서가 더 유용하다

PoC 보고서는 성공 스크린샷보다 실패의 재현 정보가 더 가치 있다. 코딩 모델이 놓친 입력과 출력 차이, 사람이 수정한 이유, 수정 뒤 새 테스트에서 발견된 회귀를 기록한다. Trainium 시험에서는 로드 실패 체크포인트, 컴파일이 오래 걸린 길이 버킷, CPU 폴백 지점, 분산 장애의 복구 시간을 적는다. 이를 ‘제품이 나쁘다’는 결론으로 바로 연결하지 않는다. 시험 범위를 넓혀 해결 가능한 문제인지, 운영 구조를 바꿔야 하는 문제인지 판단한다.

실패의 소유자도 명시한다. 모델 생성 품질, 테스트 데이터 부족, 레거시 규칙의 모호함, 하네스 오류, 라이브러리 미지원, 설정 실수는 서로 다른 책임 영역이다. 전부 ‘AI가 틀렸다’고 묶으면 해결 경로가 보이지 않는다. 반대로 도구 미지원이나 데이터 미정의를 모델을 더 오래 추론시키는 방식으로 해결하려 해도 비용만 늘어난다.

E-4. 다음 실험의 종료 조건을 미리 정한다

‘좀 더 지켜보자’는 상태가 길어지면 PoC가 상시 운영으로 굳어진다. 다음 시험에서 몇 건의 프로그램, 어떤 모델 버전, 어떤 테스트 묶음, 어느 정도의 예산과 기간을 쓰고 언제 성공 또는 실패로 판정할지 정한다. 예컨대 4주 동안 대표 프로그램 20개를 병행 실행해 고위험 금액 차이 0건, 중요 불변조건 100% 통과, 복구 연습 2회 성공을 기준으로 삼을 수 있다. 수치 자체는 조직에 맞게 정해야 하지만 사전에 선언해야 결과를 보고 기준을 바꾸는 편향을 줄인다.

하드웨어 시험도 목표 처리량과 p95, 모델 품질, 월비용 상한, 운영 복구 시간을 사전에 둔다. 일정 기간 내 패키지가 베타에서 필요한 기능을 제공하지 않으면 실험을 중단하거나 범위를 줄인다. 좋은 기술이더라도 팀의 출시 시점에 맞지 않으면 기다리는 편이 낫다. 명확한 종료 조건은 기술을 포기하기 위한 장치가 아니라 채택할 충분한 증거를 모으기 위한 장치다.

부록 F. 공개 평가를 사내 평가로 옮길 때의 최소 데이터 모델

F-1. 평가 사례의 기본 구조

사내 평가를 스프레드시트 한 장으로 시작할 수는 있다. 그러나 반복 실험을 하려면 한 행에 무엇을 저장할지 명확히 해야 한다. case_id는 사람이 읽기 쉬운 이름과 불변 ID를 함께 가진다. source_revision에는 원본 프로그램의 커밋이나 빌드 해시, runtime_profile에는 컴파일러 옵션과 운영체제, 문자 인코딩이 들어간다. input_ref는 테스트 입력의 위치와 해시, expected_outputs는 비교할 출력면의 목록이다. risk_class는 금액·권한·개인정보처럼 실패의 중요도를 표시한다. owner는 불일치 판단을 맡을 도메인 담당자다.

시험을 실행한 기록은 사례 정의와 분리한다. 같은 사례를 모델 A와 B, 다른 프롬프트, 다른 목표 언어로 여러 번 수행할 수 있기 때문이다. 실행 기록에는 run_id, 모델·노력 수준, 도구·프롬프트 버전, 생성 코드의 커밋, 시작과 종료 시각, 사용 토큰 또는 API 비용, 테스트 결과를 저장한다. 하나의 실행이 여러 출력물을 만들 수 있으므로 파일별 해시와 비교 결과를 자식 항목으로 둔다. 나중에 ‘왜 이 모델을 선택했나’라는 질문을 받았을 때 발표의 평균 대신 우리 실행 기록을 열 수 있어야 한다.

불일치 기록은 단순 pass=false보다 풍부해야 한다. observed_difference, minimal_reproducer, severity, root_cause_status, proposed_disposition, reviewer, decision_date를 둔다. 심각도와 원인은 첫 발견 때 확정되지 않을 수 있으므로 상태 전이를 남긴다. new → reproduced → classified → fixed → verified처럼 단계가 있으면 자동으로 새 후보를 시도할 때 기존 문제를 놓치지 않는다. 아직 분류되지 않은 불일치를 통과 건수에서 빼야 하며, ‘분류 대기’와 ‘문제 없음’을 구분한다.

F-2. 비교기 자체의 설계

파일 비교기는 원본과 새 구현의 출력 경로를 받아 바이트 차이를 보고하는 간단한 프로그램으로 시작한다. 그러나 모든 차이를 바이트 오프셋만으로 제시하면 검토가 느리다. 레코드 스키마가 있다면 직원 ID, 정산일, 항목 코드, 금액 같은 업무 키로 정렬된 diff를 제공한다. 원본 파일이 고정 폭이면 필드 경계대로 잘라 어느 필드가 달랐는지 보여 준다. JSON이라면 키 순서 같은 표현 차이와 숫자·상태 같은 의미 차이를 분리한다.

비교기의 정규화 규칙은 명시적이어야 한다. 일시값의 몇 초 차이를 무시한다면 그 근거와 최대 허용 범위를 코드에 적는다. 파일 끝 개행을 무시한다면 어떤 소비자에게 영향이 없는지 확인한다. 편의상 strip()으로 모든 공백을 없애면 고정 폭 파일의 필드 경계까지 지워져 잘못된 통과를 만들 수 있다. 비교기 변경이 일어나면 과거 실행 결과를 다시 계산할지, 새로운 비교기 버전부터 적용할지 정한다. 평가 도구도 제품 코드와 마찬가지로 변경 관리 대상이다.

F-3. 샘플링은 무작위와 의도적 경계를 함께 사용한다

실제 입력에서 무작위로 1,000건을 뽑으면 흔한 사례의 성능은 알 수 있다. 그러나 전직·복직·소급 급여·중복 승인처럼 희귀한 상태는 하나도 안 들어갈 수 있다. 그래서 무작위 표본과 위험 기반 표본을 따로 모은다. 무작위 표본은 전반적 불일치율과 운영 분포를 추정하고, 위험 표본은 ‘발생 시 큰 피해’가 있는 경계를 검증한다. 두 집합의 성적을 평균내지 않고 별도로 보고한다. 위험 표본은 실제 발생률을 대표하지 않기 때문이다.

합성 입력 생성기는 경계 근처를 촘촘히 훑는 데 유용하다. 근속 364일·365일·366일, 하루의 마지막 분·다음 분, 공제 한도보다 1원 아래·같음·1원 위 같은 삼중점 입력을 만들 수 있다. 무작위 생성에서는 찾기 어려운 off-by-one 오류가 여기서 드러난다. 모델이 생성한 테스트라 해도 도메인 담당자는 이 경계가 실제 규칙과 연결되는지 확인한다. 의미 없는 수치를 대량으로 생성해 통과율만 높이는 것은 검증 깊이를 늘리지 못한다.

F-4. 반복 시도의 의미

한 모델이 같은 프로그램을 한 번은 맞히고 한 번은 틀린다면 ‘능력은 있다’와 ‘업무에 맡길 수 있다’는 다른 결론이 나온다. 반복 시도는 모델의 샘플링 설정과 작업 환경, 허용 시간까지 고정하고 수행한다. 통과율 평균뿐 아니라 5회 모두 통과한 프로그램의 수와, 매번 다른 지점에서 실패한 프로그램의 수를 본다. 매번 통과하지만 코드 구조가 크게 변하면 장기 유지보수 관점에서는 일관성도 평가할 수 있다.

반복을 모든 사례에 무한히 적용할 필요는 없다. 먼저 대표 집합에서 변동을 확인하고, 변동이 큰 사례와 고위험 사례에 반복 예산을 더 쓴다. 시간이 지나 모델 버전이 바뀌면 같은 실행 기록을 다시 만들되 입력·하네스의 해시를 대조한다. 반복 결과를 이전 모델의 다른 테스트 버전과 섞어 보고하면 분산이 모델 때문인지 평가 환경 때문인지 알 수 없다.

F-5. 평가 누출을 피한다

모델이 과거 실패 사례와 정답 코드를 모두 문맥으로 본 뒤 같은 사례를 다시 맞혔다면 그 결과는 회귀 수정 성공이지 새로운 과제에 대한 일반화 성능이 아니다. 이 둘은 모두 중요하지만 이름을 달리한다. 개발용 공개 사례, 회귀용 내부 사례, 최종 판정용 보류 사례를 분리한다. 보류 사례의 존재와 범주는 팀에 알려도 세부 기대값은 실험 과정에서 무분별하게 공개하지 않는다. 나중에 해당 사례를 디버깅에 사용하면 새 보류 사례를 보충한다.

사내 시스템은 코드가 비공개라서 공개 벤치마크의 누출 문제와 다르다고 생각할 수 있다. 그러나 개발자가 한 실험에서 모델에 테스트 로그 전체를 제공하고 다음 실험을 같은 문맥에서 이어 가면 사실상 답을 보여 준다. 실험 기록에 컨텍스트 출처를 남기고, 처음 보는 과제를 평가할 때는 독립 세션과 고정된 도구 권한을 사용한다. 실제 업무에서는 이전 실패의 학습이 좋은 일이지만 평가 보고서에서는 그 차이를 숨기지 않는다.

부록 G. 아키텍처 지원과 운영 지원 사이의 계단

G-1. 1단계: 패키지와 장치 인식

TorchNeuron 공개 베타가 시작됐다고 가정해도 첫 단계는 패키지 설치와 장치 탐지다. 운영체제 이미지, PyTorch 버전, Neuron SDK, 인스턴스 타입, 드라이버가 맞는지 확인한다. torch.device('neuron')이 생성되는 것은 필요 조건이지만 충분 조건은 아니다. 그 장치에 작은 텐서를 올리고 연산·역전파·동기화를 수행한다. 실패 로그를 재현 가능한 이미지와 함께 보관한다. ‘설치 방법이 있다’와 ‘우리 빌드 시스템에서 설치된다’는 별개의 사실이다.

PoC 환경은 노트북의 수동 설치에 의존하지 않는 편이 좋다. 설치 순서를 코드와 이미지 정의로 기록하고 다시 배포해 같은 결과가 나오는지 확인한다. 베타 기능에서는 의존성 해결이 자주 변할 수 있으므로 잠긴 버전 파일과 다운로드한 패키지의 출처를 남긴다. 이런 준비는 성능과 무관해 보이지만, 재현 불가능한 성능 측정은 나중에 다시 검증할 수 없다.

G-2. 2단계: 목표 체크포인트의 기능 통과

장치가 작동하면 목표 모델의 정확한 리비전을 로드한다. 표준 모델을 하나 띄워 성공한 것을 팀의 모델 성공으로 착각하지 않는다. 토크나이저 설정, 원격 코드의 허용 여부, 모델 라이선스, adapter와 quantization 조합, 출력 형식을 확인한다. 추론이라면 실제 서비스의 프롬프트 템플릿과 최대 길이를 넣는다. 학습이라면 필요한 gradient와 optimizer가 해당 장치에서 정상적으로 작동하는지 본다.

기능 통과표에는 ‘완전 통과’, ‘명시적 미지원’, ‘CPU 폴백’, ‘실행은 됐지만 출력 차이 있음’, ‘실행 중 오류’ 등을 나눈다. CPU 폴백을 무조건 실패로 처리할 필요는 없지만 성능과 비용에 미치는 영향을 별도로 측정한다. 공식의 89% 아키텍처 지원 수치는 이 계단의 일부를 가리키는 정보다. 고객의 네 번째 계단, 즉 안정된 운영까지 모두 통과했다는 값이 아니다.

G-3. 3단계: 대표 부하에서의 성능

기능이 맞으면 입력 길이, 배치 크기, 동시성, 모델 버전 수를 축으로 시험한다. 짧은 입력만 사용하면 큰 문서 서비스의 메모리 문제가 보이지 않는다. 단일 요청만 사용하면 분산·큐잉 문제가 보이지 않는다. 무한히 큰 배치만 사용하면 사용자 응답 지연이 보이지 않는다. 대표 부하의 시간대별 분포와 계절 피크를 확인하고, 그에 맞는 시험 범위를 정한다. 서비스에 응답 시간 약속이 있다면 평균이 아니라 꼬리 지연이 핵심이다.

측정 장비 자체도 동일하게 유지한다. GPU 경로는 뜨거운 모델로, Trainium 경로는 콜드 스타트로 측정하면 불공정하다. 반대로 두 경로를 모두 장시간 워밍한 값만 보여 주면 실제 오토스케일 환경을 놓친다. cold와 warm을 각각 같은 조건으로 비교한다. 가격 역시 지역, 예약 방식, 시간대, 인스턴스가 유휴인 시간을 맞춰야 한다.

G-4. 4단계: 장애와 복구

프로덕션 도입을 가르는 마지막 계단은 정상 작동보다 비정상 상태다. 한 장치가 없어졌을 때 요청이 재시도되는지, 분산 학습이 어느 체크포인트에서 다시 시작되는지, 모델 파일이 손상되었을 때 배포가 롤백되는지, 새 라이브러리 버전이 특정 모델에서만 실패하면 어떻게 감지하는지 본다. 관측성에는 장치 오류와 애플리케이션 오류를 연결할 수 있는 ID가 있어야 한다. 그렇지 않으면 사용자 실패가 특정 NeuronCore에서 시작했는지 판단하기 어렵다.

운영자가 GPU 또는 다른 안정 경로로 트래픽을 옮길 수 있는지도 검증한다. 이 전환은 단순 라우팅 스위치가 아닐 수 있다. 모델 버전·토크나이저·수치 경로가 달라 서비스 결과가 달라지면 복구 중 사용자가 다른 답을 받는다. 차이의 허용 범위와 전환 시 세션 상태 처리까지 계획한다. 장애 대응 연습을 하지 않은 고속 경로는 운영 준비 완료라고 부르기 어렵다.

G-5. 5단계: 모델 업데이트의 반복 비용

새 모델 버전이 매달 출시된다면 하드웨어의 가치는 첫 모델의 성능뿐 아니라 새 버전 적응 속도로 결정된다. 네이티브 PyTorch와 표준 Hugging Face 라이브러리 통합은 이 반복 비용을 낮출 가능성이 있다. 그러나 새로운 attention, modality, quantization 방식이 등장할 때에는 지원 지연이나 커스텀 커널 작업이 다시 생길 수 있다. 지난 세 번의 모델 업데이트에 투입한 엔지니어링 시간을 추적하면 플랫폼 선택의 숨은 비용을 볼 수 있다.

팀이 특정 하드웨어에서만 가능한 최적화에 점점 의존하면 이전 경로로 이동하기 어려워질 수 있다. 이를 무조건 나쁘다고 볼 필요는 없다. 이득이 충분하면 전문화가 합리적이다. 다만 모델 코드와 NKI 커널, 일반 PyTorch fallback의 경계를 명확히 두고, 최적화된 코드가 표준 경로에 비해 얼마나 이득을 주는지 정기적으로 재측정한다. 플랫폼의 선택권은 사용하지 않아도 검증 가능한 대체 경로를 보유할 때 가치가 있다.

부록 H. 두 발표를 연결하는 검증 문화

H-1. 둘 다 ‘표준 인터페이스’만으로는 부족하다

MultiLangBench는 같은 데이터베이스 파일을 공통 인터페이스로 사용해 서로 다른 언어의 구현을 비교한다. 이 설계 덕분에 COBOL과 Fortran, Visual Basic의 결과를 한 평가 틀에서 볼 수 있다. 그러나 공통 파일 인터페이스는 구현의 내부가 동일하다는 뜻이 아니다. TorchNeuron도 PyTorch API라는 공통 인터페이스를 통해 Trainium을 사용한다. 그러나 같은 API가 내부 실행 비용과 정밀도를 같게 만들지는 않는다. 표준 인터페이스는 비교의 출발점을 제공하고, 동일성은 테스트로 입증해야 한다.

이 원칙은 일상적인 웹앱 개발에도 적용된다. 동일한 REST 응답 구조를 가진 두 백엔드가 내부 트랜잭션 처리까지 같지는 않다. 동일한 ORM API를 쓰는 두 데이터베이스가 잠금과 격리 수준이 같지는 않다. 인터페이스가 바뀌지 않았다는 사실에 안심하기보다, 그 인터페이스가 표현하지 못한 비기능 요구와 부작용을 별도 표로 관리해야 한다. 오늘의 두 공식 발표는 이 오래된 소프트웨어 공학 문제를 새로운 규모로 보여 준다.

H-2. 공개 평가의 가장 좋은 사용법은 질문 만들기다

공개 점수를 회사 슬라이드에 그대로 붙이는 것보다, 시험 설계에서 질문을 얻는 편이 낫다. MultiLangBench의 데이터베이스 파일 비교를 보면 우리 배치가 만든 결과 파일을 원본과 비교할 수 있는가를 묻게 된다. COBOL 마이그레이션의 바이트 동일성 기준을 보면 어떤 출력은 완전 동일해야 하고 어떤 출력은 정규화할 수 있는가를 묻게 된다. TorchNeuron의 프로파일 통합을 보면 우리 서비스의 지연이 CPU, 컴파일, 장치 실행 중 어디에 있는가를 묻게 된다.

질문이 명확해지면 기술 선택은 덜 이념적이 된다. 특정 모델이나 칩을 좋아한다는 감각 대신, 우리 작업의 정확성·비용·운영 위험을 비교할 수 있다. 결과가 좋으면 채택하고, 나쁘면 사용 범위를 좁히거나 기다린다. 어느 쪽이든 공개 발표를 읽은 일이 실제 팀의 의사결정 품질을 높인다. AI 뉴스의 실무 가치는 신제품 이름을 빨리 외우는 데 있지 않고 이 질문을 더 정확히 만드는 데 있다.

H-3. 검증 가능성은 제품 경험을 개선한다

테스트와 프로파일은 내부 개발자의 도구처럼 보이지만 사용자에게도 영향을 준다. 급여가 맞는 이유를 설명할 수 있는 시스템은 이의 제기를 더 빠르게 처리한다. 성능 회귀를 입력 길이와 장치 경로에 연결할 수 있는 서비스는 일부 사용자에게만 느린 문제를 더 빨리 해결한다. 새로운 언어와 가속기 도입이 고객에게 보이지 않더라도, 그 변화에 대한 검증 체계는 고객이 경험하는 신뢰성과 응답 시간으로 나타난다.

더 빠른 코딩 모델과 더 쉬운 장치 포팅은 개발 속도를 올릴 수 있다. 하지만 승인과 관측이 뒤따르지 않으면 빠른 속도로 오류를 배포할 수도 있다. 따라서 팀의 투자 포트폴리오에는 모델 호출량이나 칩 시간만이 아니라 평가 하네스, 데이터 품질, 비교기, 섀도 실행, rollback 설계가 들어가야 한다. 빠른 생성과 높은 처리량은 검증 가능한 배포와 만나야 비로소 제품의 이익이 된다.

부록 I. 첫 번째 파일럿을 위한 상세 실행 일정

I-1. 준비 주간: 범위를 작게 고정한다

파일럿의 목표를 ‘모든 COBOL 제거’로 잡으면 첫 주부터 성공·실패를 판단할 수 없다. 우선 외부 효과를 발생시키지 않는 조회 또는 정산 계산 프로그램 하나, 외부 시스템과 연동하는 프로그램 하나를 택한다. 두 프로그램의 복잡도가 다르면 모델의 강점과 운영의 위험을 동시에 볼 수 있다. 프로그램의 소스뿐 아니라 호출하는 서브프로그램, 파일 레이아웃, 작업 스케줄, 최근 수정 이력, 운영 담당자를 확인한다. 확인되지 않은 의존성이 많으면 파일럿의 목표를 코드 변환이 아니라 의존성 지도 작성으로 바꿀 수 있다.

데이터 보관 위치와 모델 호출 경로를 준비 단계에서 정한다. 실거래 입력을 외부 API에 보낼 수 없다면 합성 입력과 내부 실행 환경을 만든다. 일부 도메인 규칙이 합성 데이터로 재현되지 않으면 원본 시스템에 대한 로컬 평가 하네스에서만 테스트하고 모델에게는 오류의 일반화된 설명을 전달한다. 이는 정확도를 조금 낮출 수 있지만 보안 경계를 우회하는 것보다 낫다. 실제 평가 가능 범위를 문서에 정직하게 적어야 한다.

하드웨어 PoC도 한 모델과 한 태스크에 집중한다. Hugging Face의 예제에서 로드되는 모델을 먼저 실행해 환경을 확인한 뒤 목표 체크포인트를 별도로 시험한다. 둘을 혼동하면 환경 문제인지 모델 지원 문제인지 알기 어렵다. 팀이 원하는 것이 텍스트 생성인지 이미지 생성인지, 추론인지 SFT 학습인지부터 정한다. 발표에는 여러 경로가 함께 나오지만 내부 파일럿에서 한꺼번에 검증할 필요는 없다.

I-2. 1주차: 기준선의 결함까지 기록한다

원본 프로그램의 대표 입력에 대한 출력만 저장하면 결함이 없는 이상적인 기준처럼 보인다. 실제로는 원본도 모호하거나 불안정할 수 있다. 같은 입력을 두 번 실행해 결과가 변하는지 확인하고, 변한다면 날짜·파일 순서·외부 조회·난수·동시 실행의 영향을 찾는다. 비결정성이 있는 상태에서 새 구현과 한 번만 비교하면 쓸모 없는 차이가 쌓인다. 기준 환경을 고정하거나 허용 가능한 변동의 정확한 원인을 명시해야 한다.

성능 기준선도 같은 시점에 수집한다. 평균 배치 시간뿐 아니라 가장 큰 입력 파일, 피크 기간의 메모리, 오류 발생 때 복구 시간, 운영자 개입 시간을 측정한다. 원본이 이미 성능 목표를 못 맞추고 있다면 새 구현이 원본보다 빠르기만 하면 되는지, 별도 사업 목표를 충족해야 하는지 결정한다. 이전보다 10% 빠르지만 마감 시간에는 여전히 늦는다면 성공이라고 하기 어렵다.

Trainium 비교의 기준 GPU 또는 기존 환경도 정성껏 측정한다. 현재 서비스의 모델 버전, 실제 입력 길이, 배치 전략, 오토스케일, 캐시 상태를 고정한다. GPU 비용의 청구액에는 유휴 인스턴스와 저장소·네트워크가 포함될 수 있다. Trainium의 단순 인스턴스 단가만 비교하지 말고 같은 서비스를 제공하는 데 필요한 전체 환경을 비교해야 한다.

I-3. 2주차: 후보 생성과 실패 원인 분해

코딩 모델에게 원본의 기능 요약, 입출력 계약, 금지된 행동 변경, 목표 언어의 버전을 준 뒤 후보 코드를 만든다. 한 번의 프롬프트로 수천 줄 전체를 만들기보다 경계가 분명한 모듈부터 시작한다. 모델이 구조를 바꾸고 싶어 한다면 왜 그런지, 원본과 어떤 인터페이스를 유지할지 적도록 한다. 코드 스타일보다 golden 테스트와 불변조건의 통과를 우선한다. 실패가 발생하면 원본과 새 구현의 차이를 모델에게 전달하되 개인정보가 없는 최소 재현 입력을 사용한다.

실패는 최소 다섯 범주로 분류한다. 언어 구문·빌드 실패, 실행 시 예외, 데이터·숫자 의미 차이, 외부 의존성 미모델링, 기준 결과의 모호함이다. 첫 두 범주는 모델이나 도구가 비교적 빠르게 수정할 수 있다. 나머지는 업무 담당자와 시스템 지식이 필요할 수 있다. 모든 실패를 ‘프롬프트를 더 길게 쓰면 해결된다’고 가정하지 않는다. 원인을 분리해야 모델을 바꿀지, 문서를 추가할지, 테스트를 보완할지 결정한다.

Trainium 후보에서도 실패 원인을 분리한다. 설치 문제, 미지원 연산, 모델 코드의 장치 가정, compiler shape 문제, 수치 오차, 실제 병목이 CPU에 있는 경우는 처방이 다르다. 특히 모델이 로드되고 한 번 추론했다는 결과로 성능 평가를 바로 시작하지 않는다. CPU 폴백이나 전송 비용이 있는지 먼저 계측한다. 프로파일을 사용할 때는 공식 문서와 같은 버전의 API를 확인하고, 베타 버전의 변화도 기록한다.

I-4. 3주차: 섀도·부하 시험

후보 코드가 준비된 테스트를 통과하면 더 많은 실제 분포의 입력을 섀도 실행한다. 원본만 권위 있는 결과를 외부에 보내고 새 구현은 격리된 환경에서 계산한다. 결과 비교에는 파일 내용과 상태 변경 계획을 포함한다. 섀도 실행이 원본 시스템을 두 번 호출해 외부 효과를 중복시키지 않도록 반드시 읽기·쓰기 경계를 검토한다. 프로그램이 외부 API를 호출한다면 stub이나 기록된 응답을 사용해 같은 조건을 만든다.

하드웨어 시험은 프로덕션과 유사한 요청 믹스를 재생한다. 정상일 때의 부하만 아니라 트래픽이 갑자기 늘 때의 준비 시간, 여러 모델 버전을 함께 띄울 때의 자원 경쟁, 입력 길이 분포가 길어질 때의 실패율을 본다. p50, p95, p99와 작업당 비용을 동시 보고하고 품질 평가도 같은 요청으로 실행한다. 성능만 빨라졌는데 정답률이 떨어지면 서비스의 목표와 맞는지 다시 판단한다.

I-5. 4주차: 검토와 종료 판정

기술 담당자만 성공을 선언하지 않는다. 도메인 담당자는 불일치의 업무 중요도를, 보안 담당자는 데이터 흐름을, 운영 담당자는 복구 절차와 관측성을 검토한다. 이 검토가 매 단계에서 필요할 수 있지만 마지막 주에는 발견한 차이를 기준으로 실제 출시 게이트를 확정한다. 미해결 차이가 한 건이라도 고위험인지, 낮은 위험이라면 보류할 수 있는지 명시한다. 모든 ‘나중에 수정’ 항목에 소유자와 기한을 붙인다.

결정 결과는 셋 중 하나로 적는다. 제한된 범위에서 계속 진행, 추가 검증 후 재결정, 현재 조건에서는 중단이다. ‘대체로 괜찮다’는 문구는 배포 승인과 구분되지 않는다. 중단도 성과일 수 있다. 특정 모델이 특정 COBOL 패턴에 약하거나 베타 버전이 필요한 커널을 지원하지 않는다는 사실을 빨리 알았다면, 더 큰 비용을 쓰기 전에 선택지를 조정할 수 있다.

부록 J. 인사시스템을 예로 든 의미 보존 질문

J-1. 휴가 잔여일의 계산 시점

휴가 잔여일을 계산하는 함수가 있다고 하자. 동일한 직원이라도 신청 시점, 승인 시점, 사용일, 결산일에 따라 잔여일이 달라질 수 있다. 원본 프로그램이 승인된 신청만 차감한다면 새 코드가 제출된 신청까지 차감하면 사용자 화면에서 갑자기 잔여일이 적어 보인다. 반대로 제출 단계에서 임시로 예약하던 시스템을 새 코드가 승인 단계까지 반영하지 않으면 초과 신청을 허용할 수 있다. 평가 입력은 상태 전이의 각 시점과 과거 정정 상황을 포함해야 한다.

표시되는 ‘잔여일’과 실제 신청 가능 일수가 같은 필드인지도 확인한다. 이월 휴가와 법정 휴가가 다른 만료일을 가지면 합계가 같아도 사용 우선순위가 다를 수 있다. 모델이 자료 구조를 단순화하며 두 버킷을 하나로 합치면 다음 달의 결과가 달라진다. 기능 설명 문서가 없다면 원본 코드와 실제 과거 계산을 함께 분석해 버킷 규칙을 추출해야 한다.

J-2. 급여 항목과 반올림 위치

월 급여는 기본급과 각종 수당의 합계처럼 보이지만 개별 항목마다 과세, 공제, 소급 정정 규칙이 다를 수 있다. 원본이 항목별로 절사한 뒤 합치는데 새 구현이 총액에서 한 번 절사하면 합계가 다를 수 있다. 문제를 더 어렵게 만드는 것은 일부 화면이 반올림된 숫자만 보여 주므로 작은 차이가 출력에서 감춰진다는 점이다. 원장 데이터와 신고 파일의 원값을 비교해야 한다.

실무 평가에는 지난 몇 달의 대표 사례뿐 아니라 기본급이 중간에 바뀐 달, 퇴직 직전 달, 소급 지급이 있는 달, 무급휴직 기간을 포함한다. 특정 지역의 원천징수 규칙이 적용되는 직원도 나눠야 한다. 모델이 해당 규정을 외부 지식으로 추정하게 하지 말고 회사의 실제 시행일별 규칙을 입력으로 제공한다. 법과 내부 정책의 해석은 검토자가 최종 판단한다.

J-3. 조직 변경과 권한 변경의 시간 차이

직원이 A부서에서 B부서로 이동하면 조직도, 결재선, 예산 코드, 보고서 접근 권한이 동시에 바뀌지 않을 수 있다. 원본 시스템이 실제로는 날짜별로 서로 다른 기준을 사용했다면 새 구현이 하나의 ‘현재 부서’ 필드로 합치는 순간 과거 보고서나 승인 경로가 달라질 수 있다. 평가에는 변경일 전후의 신청과 조회, 승인자가 이동 직후 결재할 수 있는지, 과거 기록을 볼 수 있는지 포함한다.

권한은 특히 출력 비교만으로 충분하지 않다. 권한이 없는 사용자가 호출했을 때 데이터가 반환되지 않는지, 감사 기록이 남는지, 다른 부서의 직원 ID를 추측해 조회할 수 없는지 확인한다. 코딩 모델이 만든 새 API가 기존 화면에서는 정확하게 보이더라도 서버측 접근 제어를 누락했다면 실패다. 기능의 의미에는 누구에게 결과를 보여 주는지도 포함된다.

J-4. 중복 승인과 동시 수정

휴가 신청을 두 명의 관리자가 거의 동시에 승인할 수 있다. 원본 시스템이 잠금이나 버전 번호로 한 번만 차감한다면 새 구현은 같은 의미를 유지해야 한다. 단일 스레드 테스트에서는 둘 다 맞아 보일 수 있다. 동시에 두 요청을 보내 잔여일이 두 번 줄지 않는지 확인한다. 한 요청이 성공하고 다른 요청이 충돌을 받았다면 사용자에게 어떤 메시지가 가는지도 본다.

이 오류는 AI가 특정 함수의 로직을 정확히 옮겨도 트랜잭션 경계가 달라질 때 발생한다. 새 언어의 ORM 기본 동작이나 데이터베이스 격리 수준이 원본과 다를 수 있다. 코드 리뷰에서는 함수 내부뿐 아니라 저장소 레이어와 재시도 정책을 확인한다. 충돌을 자동으로 재시도하면 동일한 승인 의도가 두 번 반영될 위험이 있으므로 멱등 키와 현재 상태 검사도 필요하다.

J-5. 소급 정정의 출처

과거 근태 기록을 나중에 고치면 이미 지급한 급여와 다음 달 정산에 차이가 생긴다. 원본 시스템이 정정을 새 거래로 기록하는지, 과거 행을 덮어쓰는지, 감사 이벤트를 별도 남기는지 확인한다. 새 구현이 최종 잔액만 맞추고 정정 이력을 버리면 감사와 분쟁 대응이 어려워진다. 같은 직원·같은 금액이어도 ‘처음부터 그랬다’와 ‘나중에 고쳤다’는 업무 의미가 다르다.

평가 케이스에는 원래 신청, 승인, 정정 요청, 재승인, 급여 조정의 시간 순서를 넣는다. 최종 출력만 비교하지 않고 각 시점의 상태와 이벤트를 비교한다. AI가 생성한 구현을 평가할 때 이렇게 시계열의 의미를 측정하면 단일 입력·단일 출력 시험이 놓친 차이를 찾을 수 있다. 사용자에게 어떤 정정 안내가 전달되는지도 외부 효과에 포함한다.

J-6. 개인정보 삭제와 감사의 긴장

직원이 개인정보 삭제를 요청했을 때 일부 자료는 지워야 하고 일부 법정 기록은 제한적으로 보존해야 할 수 있다. 원본의 자료 수명 정책이 코드와 수동 절차에 흩어져 있다면 새 시스템은 이를 명확히 모델링해야 한다. 모든 데이터를 즉시 삭제하는 것도, 전부 남기는 것도 올바른 답이 아닐 수 있다. 데이터 범주별 보존 근거와 접근 권한을 먼저 정하고 구현을 시험한다.

모델 생성 과정에서 사용한 테스트 데이터와 로그도 삭제 범위에 포함될 수 있다. 원본 데이터베이스만 정리하고 코딩 에이전트의 작업 기록에 민감한 입력이 남으면 요구를 충족하지 못한다. 평가 인프라를 설계할 때부터 원본·합성·비식별 데이터를 구분하고, 디버깅 로그의 보존 정책을 적어야 한다. 모델이 코드를 옮겼다는 이유로 기존의 개인정보 책임이 사라지지 않는다.

부록 K. 벤치마크를 읽을 때 흔한 10가지 오해

K-1. ‘평균 테스트 통과율’은 프로그램별 성공률이 아니다

MultiLangBench의 87.4%는 20개 언어에 걸친 평균 테스트 통과율이다. 우리 프로그램 100개 중 87개를 별도 검토 없이 배포해도 된다는 뜻이 아니다. 하나의 구현에서 여러 검증 쿼리가 통과하는 비율과 다수 프로그램의 완전 마이그레이션 비율은 서로 다른 분모를 쓴다. 보고서가 백분율을 인용할 때는 무엇을 한 단위로 셌는지 같은 문장에 적어야 한다. 그래야 경영진이 숫자의 인상을 업무 위험으로 잘못 환산하지 않는다.

K-2. ‘숨겨진 테스트 전부 통과’는 알려지지 않은 모든 입력의 정답이 아니다

COBOL 마이그레이션 평가에서 숨겨진 테스트를 모두 통과한 프로그램은 그 평가 기준에서는 성공이다. 그러나 실제 소프트웨어의 입력 공간은 훨씬 넓다. 테스트가 누락한 시스템 의존성이나 희귀 오류는 여전히 남을 수 있다. 숨겨진 테스트는 모델이 공개된 정답 사례에 맞춰 코드를 과적합하지 못하게 하는 중요한 장치지만, 모든 가능성을 증명하는 형식 검증은 아니다. 프로덕션의 추가 테스트와 리뷰가 필요한 이유를 발표도 인정한다.

K-3. ‘높은 추론 노력 97.9%’는 항상 쓸 설정이 아니다

높은 추론 노력에서 정확도가 올라가도 작업당 시간과 비용이 달라질 수 있다. 모든 파일에 그 설정을 적용하기보다 위험과 난도에 따라 라우팅할 수 있다. 그러나 약한 경로의 실패를 잡는 판정기가 없다면 라우팅은 비용 절감 대신 숨은 오류를 만들 수 있다. 따라서 먼저 고위험 코드와 판정이 어려운 코드에는 강한 설정을 쓰고, 낮은 위험과 쉽게 자동 채점 가능한 변환에만 저렴한 경로를 시험한다. 비용 정책은 검증 정책 뒤에 와야 한다.

K-4. ‘낮은 API 비용’은 낮은 전체 소유 비용이 아니다

모델의 요청 가격은 개발 프로젝트 총비용의 일부다. 코드 리뷰와 테스트를 더 많이 유발하는 경로는 API가 싸도 전체 비용이 높을 수 있다. 장애를 늦게 발견하면 정산 재처리와 고객 응대까지 발생한다. 비용 계산을 하기 전에 성공한 업무 한 건의 정의를 확정해야 한다. 테스트를 통과한 초안인지, 검토와 보안 승인까지 끝난 PR인지, 고객에게 배포돼 일정 기간 문제 없이 운영된 기능인지에 따라 비용 분모가 달라진다.

K-5. ‘네이티브 PyTorch’는 모든 코드를 무수정 실행한다는 뜻이 아니다

TorchNeuron은 표준 인터페이스를 넓히지만 새 device backend다. 특수 연산과 비표준 확장, 동적 형태, 특정 dtype의 지원 상태는 확인해야 한다. 기본 예시의 .to('neuron')이 간결한 것은 좋은 개발 경험의 신호다. 그러나 모델이 실제로 쓰는 모든 경로와 프로덕션 지표가 그 한 줄로 검증됐다는 결론은 아니다. 목표 체크포인트와 작업을 실행해 장치 배치와 정합성을 봐야 한다.

K-6. ‘89% 지원’은 우리 모델의 89%가 동작한다는 뜻이 아니다

공식 수치는 상위 100개 텍스트 생성 아키텍처 가운데 기본 지원하는 비율이다. 우리 조직이 상위 아키텍처만 쓰는지, 특정 체크포인트가 추가 코드를 쓰는지, 임베딩·이미지 모델이 같은 범위에 포함되는지는 별도 질문이다. 지원 표는 시험할 후보를 빠르게 찾는 자료지 배포 보증서가 아니다. 정확한 모델 리비전·태스크·정밀도를 적은 자체 통과표가 필요하다.

K-7. ‘eager 지원’은 컴파일 전략이 필요 없다는 뜻이 아니다

eager는 연구와 디버깅의 진입 장벽을 낮춘다. 생산 환경의 처리량에서는 compiled 경로가 유리할 수 있고, Hugging Face 예시처럼 정적 캐시와 길이 버킷, 자동 동적 형태 비활성화가 필요할 수 있다. 기능 검증에는 eager를 사용하고 성능 평가에는 compiled 경로를 추가하는 식으로 목적을 분리한다. 두 방식이 제공하는 장점이 다른데 하나의 시험 수치로 뭉치면 운영 판단을 잘못할 수 있다.

K-8. ‘공개 베타’는 장기 지원 약속과 다르다

10월 20일 공개 베타 예고는 기술을 직접 시험할 시점이 왔다는 뜻이다. 안정성, 버전 호환, 지원 기간은 별도의 문서와 실제 운영 결과로 확인해야 한다. adaptive eager는 실험적이고 FP8 관련 일부 최적화는 private beta로 구분돼 있다. 미래 릴리스의 기능을 현재 구매 결정의 확정된 편익으로 계산하지 않는다. 제품 일정이 촉박하다면 보수적 경로를 유지하면서 검증할 시간을 확보한다.

K-9. ‘커널 2.4배’는 서비스 2.4배가 아니다

특정 커널의 속도 이익은 전체 요청에 그 커널이 차지하는 비중만큼만 영향을 준다. 장치 실행 외의 네트워크, 데이터 준비, CPU 후처리, 컴파일, 동기화가 지연의 상당 부분이면 커널 최적화의 체감 효과는 작다. 반대로 그 커널이 반복해서 호출되면 큰 효과가 있을 수도 있다. profiler로 호출 횟수와 누적 시간을 보고 병목에 맞춘 최적화를 한다. 예시 수치를 그대로 재무 계획에 넣지 않는다.

K-10. ‘같은 프레임워크’는 같은 운영 조직이란 뜻이 아니다

기존 PyTorch 도구를 쓸 수 있다는 것은 학습 비용을 낮추지만, 장애 대응과 비용 관리에는 새로운 지식이 필요하다. Trainium의 장치 오류, 분산 통신, 컴파일 그래프, 패키지 조합, NKI 커널은 GPU 경로와 다를 수 있다. 운영 담당자가 프로파일을 열어 원인을 찾고 이전 경로로 되돌릴 수 있어야 한다. 설치가 쉬운 기술과 운영하기 쉬운 기술은 겹치지만 동일하지 않다.

부록 L. 의사결정에 사용할 간단한 계산 틀

L-1. 작업당 비용의 분모를 정한다

모델 A의 호출비가 낮더라도 결과가 자주 틀려 두 번째 호출과 사람 검토를 필요로 하면 완료 비용이 커진다. 내부 평가에서 첫 시도 통과 비율, 최종 승인까지 평균 시도 횟수, 각 시도의 API 비용, 테스트 실행 시간, 검토자 시간을 기록한다. 이를 합해 승인된 프로그램 한 개당 비용을 비교한다. 아직 프로덕션 장애의 기대비용을 모른다면 위험 범위를 따로 적고 0이라고 가정하지 않는다.

마찬가지로 플랫폼 비용의 분모는 유효한 요청 완료 수다. 장치 시간당 가격과 처리량을 곱할 때는 실패·재시도·워밍·유휴·컴파일 시간을 포함한다. 길이 버킷에 패딩이 많으면 장치가 처리한 토큰 수는 많아도 고객에게 유용한 토큰은 적을 수 있다. 제품은 유효한 요청의 품질과 응답 시간을 사는 것이지 원시 연산량을 사는 것이 아니다.

L-2. ‘한 번 성공’과 ‘계속 성공’의 비용 차이

어떤 코드 변환이 다섯 번 중 한 번만 완전 통과한다면 여러 후보를 생성해 자동 테스트로 고를 수 있다. 단, 후보의 실패가 테스트에서 반드시 드러나야 한다. 한 번 성공한 후보를 사람이 검토해 안정적으로 보존할 수 있다면 변동성이 개발 초안 단계에서는 허용될 수 있다. 그러나 모델이 매주 새 코드를 직접 프로덕션에 반영하는 구조라면 반복 성공률이 중요하다. 성공 정의가 개발 지원인지 자율 배포인지에 따라 비용과 위험 계산을 분리한다.

플랫폼도 비슷하다. 한 번의 벤치마크에서 높은 처리량을 보인 경로와 월간 배포·스케일링·장애를 거치며 안정적인 경로는 다르다. 짧은 PoC의 최고값과 장기 운영의 p95, 에러율, 복구 시간을 함께 보고 이익을 계산한다. 평균 이익이 작더라도 특정 중요한 작업의 꼬리 지연이 크게 개선되면 채택 가치가 있을 수 있다. 반대로 평균이 크게 개선돼도 규정상 중요한 요청의 오류가 늘면 사용할 수 없다.

L-3. 위험에 따른 다른 승인선

레거시 코드 중 내부 통계 화면을 만드는 작업과 실제 급여 지급 파일을 만드는 작업의 승인선을 같게 둘 필요는 없다. 통계 화면은 허용 오차와 빠른 rollback을 둘 수 있다. 지급 파일은 금액·대상·시점의 완전 일치와 이중 실행 방지가 필요하다. 모델과 평가 예산을 위험에 따라 다르게 배치한다. 승인선이 높은 작업은 사람이 더 많이 개입한다는 의미만이 아니라 자동으로 확인할 불변조건을 더 정교하게 만든다는 뜻이다.

Trainium 경로에서도 내부 연구 배치와 고객 대상 실시간 서비스의 승인선은 다르다. 연구 배치는 베타 기능을 빨리 시험하면서 오류를 수동으로 분석할 수 있다. 실시간 서비스는 고객 지연과 가용성 계약이 있으므로 대체 경로와 온콜 절차가 중요하다. 기술이 같은데 적용 영역이 다르면 의사결정이 달라질 수 있다. ‘전사 도입’ 또는 ‘전면 금지’보다 작업별 적용 지도가 실용적이다.

부록 M. 책임자별로 달라지는 읽는 법

M-1. CTO 또는 제품 책임자에게

오늘의 발표를 예산 계획에 반영한다면 ‘AI가 레거시를 해결한다’와 ‘Trainium이 GPU보다 싸다’라는 큰 문장부터 쓰지 않는다. 어떤 프로그램을 어느 범위에서 옮길지, 어떤 모델 작업을 어느 장치에서 돌릴지를 구체적으로 정한다. 기대 효과는 개발 완료 시간, 장애 감소, 비용, 공급자 선택권처럼 측정 가능한 목표로 표현한다. 그 목표에 도달하는 과정에서 누가 원본 규칙을 승인하고 누가 배포 중지를 결정할지까지 예산에 포함한다. 검증 인력을 제외한 AI 예산은 실제 배포 단계에서 막힐 수 있다.

레거시 프로그램을 없애는 일의 어려움은 보통 구문 변환 속도가 아니다. 업무 담당자가 떠났고, 데이터 계약이 낡았으며, 실패의 비용이 커서 새 코드에 서명하기 어렵다는 점이다. 모델 능력 향상은 초안 작성과 탐색의 시간을 줄일 수 있다. 그러나 서명할 근거를 만드는 비교기, 테스트 자료, 운영 절차에 투자하지 않으면 생산성 향상이 출시로 연결되지 않는다. 파일럿의 KPI를 생성 코드 줄 수가 아니라 검증된 업무 경로 수로 두는 편이 좋다.

하드웨어는 클라우드 단가 표만 보지 않는다. 네이티브 PyTorch 경로는 공급자 선택권과 연구자의 실험 속도를 높일 가능성이 있다. 하지만 팀의 주요 체크포인트가 아직 미지원이거나 필요한 FP8 경로가 private beta라면 당장 비용 이익을 실현할 수 없다. 계약과 조직의 마이그레이션 비용까지 포함한 선택지를 비교한다. 하나의 공급자에 전부 옮기기보다 작업군별 선택권을 확보하는 단계적 전략도 가능하다.

M-2. 개발 리더에게

팀의 구현 표준을 ‘AI가 만든 코드는 반드시 사람이 본다’에서 멈추지 않는다. 사람이 무엇을 봐야 하는지 지원하는 산출물을 만든다. 원본과 새 코드의 구조적 차이, golden 테스트 결과, 실패의 최소 재현 입력, 불변조건 통과표, 권한 변경표가 있으면 검토가 빨라진다. 모든 개발자에게 COBOL과 새 언어, 급여 도메인을 동시에 완벽히 알도록 요구하기보다 역할을 분리한다. 원본 전문가가 규칙을 설명하고, 새 언어 담당자가 구현을 검토하고, 도메인 담당자가 위험을 승인하는 흐름을 만든다.

모델의 코딩 성능을 평가할 때 한 번의 멋진 데모보다 동일한 사례 집합을 정기적으로 돌린 기록이 유용하다. 모델 업데이트가 있을 때마다 소수 표본을 다시 돌리고, 실패 패턴이 개선되는지 또는 다른 곳으로 이동하는지 본다. API 비용과 모델 응답 시간만 기록하면 코드 리뷰 시간을 놓친다. 모델이 더 나은 코드를 만들면서 테스트 작성까지 돕는다면 전체 PR 완료 시간이 줄 수 있고, 반대로 스타일이 자주 바뀌면 리뷰가 더 길어질 수 있다. 측정의 최종 단위는 팀의 완료된 변경이다.

Trainium을 검토한다면 엔지니어 한 명이 예제 노트북을 실행하는 PoC로 끝내지 않는다. 서비스 소유자가 실제 요청을 재생하고, 데이터 엔지니어가 모델 입력 파이프라인을 확인하고, 온콜 담당자가 장애 연습을 한다. torch.profiler 통합이 공개됐다는 것은 기존 도구와 연결된 성능 조사가 가능해진다는 신호다. 그러나 팀이 어떤 지표를 볼지 정하지 않으면 도구가 있어도 운영되지 않는다. 모델·런타임·장치 지표를 동일한 요청 ID에 연결하는 관측 계획을 세운다.

M-3. 품질 엔지니어에게

기능 테스트만 늘리는 것은 충분하지 않다. 서로 다른 모델의 출력을 같은 독립 하네스로 검증하고, 테스트 데이터의 출처와 대표성을 관리한다. 테스트가 원본 프로그램의 실수를 고착시키는지, 실제 업무 정책을 반영하는지도 주기적으로 확인한다. 모델이 높은 점수를 얻기 위해 테스트 집합의 공백을 파고드는지 탐지하려면 신규 보류 사례와 과거 장애 회귀 사례를 나눠야 한다. 변경된 테스트 기준은 점수 시계열에 표시한다.

하드웨어 품질 시험에서는 수치 차이를 0 아니면 1로 단순화하지 않는다. 정밀도와 연산 순서의 차이로 로짓이 조금 달라도 실제 사용자 과제 결과가 같을 수 있다. 반대로 출력 문자열이 대부분 같아도 드문 입력에서 치명적인 차이가 생길 수 있다. 수치 단계의 오차, 모델 과제의 정답, 제품 업무의 결과를 세 층으로 보고한다. 이 세 층을 분리하면 어느 단계에서 이득과 손실이 생겼는지 찾기 쉽다.

M-4. 보안·개인정보 책임자에게

레거시 마이그레이션의 테스트 자료와 코드에는 민감한 규칙과 실제 개인 자료가 있을 수 있다. 외부 모델에 전달되는 파일, 로그, 스택 트레이스, 실패 재현 입력을 목록으로 만든다. 가명처리된 데이터라도 드문 조합이 특정 개인을 식별할 수 있는지 살핀다. 모델 제공자와의 계약, 저장 기간, 지역, 접근 권한을 확인하고 조직 정책에 맞는 경로를 결정한다. 코딩 모델이 생산성을 올린다는 이유로 기존의 데이터 분류 규칙을 건너뛰지 않는다.

Trainium 운영에서는 모델 입력과 프로파일 로그가 어디에 남는지 확인한다. Neuron Explorer의 상세 이벤트와 Parquet 출력이 성능 조사에 유용해도, 요청의 내용이나 사내 모델 구조가 분석 저장소에 무기한 남으면 새로운 노출면이 된다. 추적 데이터의 보존 기간과 접근 권한, 삭제 절차를 업무 데이터와 연계한다. 하드웨어 선택은 데이터 처리 지역과 네트워크 경로에도 영향을 줄 수 있으므로 리전 가용성과 법적 요구를 함께 검토한다.

M-5. 운영자에게

새 코드와 새 장치 모두 장애가 나면 마지막으로 운영자가 복구한다. 운영 문서에는 정상 설치 명령보다 이상 상태의 분기표가 중요하다. 결과 파일 불일치, 모델 로드 실패, 컴파일 지연, 메모리 부족, 분산 통신 실패, 비용 급증 각각에서 먼저 볼 지표와 되돌릴 경로를 적는다. 이전 구현을 남겨 놓는다면 어느 버전의 데이터까지 다시 읽을 수 있는지 확인한다. 복구가 어려운 외부 효과를 분리해 승인 단계에 둔다.

운영 문서는 정적 체크리스트가 아니라 실제 연습으로 검증한다. 파일럿 중 한 번은 의도적으로 잘못된 입력을 넣고 중단·정정 과정을 수행한다. 하드웨어 PoC에서는 의도적으로 긴 입력과 갑작스러운 요청 증가를 넣고 경보와 대체 경로를 확인한다. 이런 시험이 실패했다면 개발자가 속도를 더 올리기 전에 복구 도구를 먼저 고쳐야 한다. 신속한 배포는 신속한 복구가 가능할 때 지속 가능하다.

부록 N. 다음 발표를 읽기 위한 관찰 목록

OpenAI 쪽에서 이후 확인할 것은 평가의 확장과 재현성이다. MultiLangBench의 언어별 상세 결과, 어떤 SQL 기능에서 실패가 집중되는지, 비용 측정의 정확한 환경, 모델별 추론 노력에 따른 성공 분포가 중요하다. COBOL 마이그레이션은 변환 대상 프로그램의 유형과 길이, 숨겨진 테스트의 경계, 사람 전문가의 검토 기준이 더 공개되면 실무 해석이 쉬워진다. 이번 글은 현재 공개된 범위만 사용했고 누락된 세부 조건을 추측해 채우지 않았다.

TorchNeuron 쪽에서 확인할 것은 공개 베타 패키지의 실제 가용성과 문서의 버전 일치다. AWS Neuron 문서와 PyTorch 글, Hugging Face 예시가 같은 소프트웨어 조합을 전제하는지 확인해야 한다. 상위 아키텍처 지원 비율이 향후 모델 확장에 따라 어떻게 변하는지, 동적 형태와 컴파일 캐시의 실무 제약이 얼마나 완화되는지, TorchAO·FP8의 공개 범위가 언제 바뀌는지도 추적할 만하다. 공개 베타가 시작된 뒤 실측 데이터를 얻으면 오늘의 예고를 실제 검증으로 갱신할 수 있다.

또 하나의 관찰 대상은 서드파티 생태계다. 네이티브 PyTorch 경로가 생겨도 평가·모니터링·모델 서빙 라이브러리가 이를 얼마나 빨리 받아들이는지에 따라 팀의 실제 개발 경험이 달라진다. PyTorch 글은 vLLM Neuron과 vLLM Omni Neuron 같은 서빙 플러그인을 설명한다. 우리 팀이 사용하는 버전과 기능이 호환되는지는 직접 확인해야 한다. 표준 API의 확산이 라이브러리 생태계의 지원으로 이어질 때 플랫폼 이익이 커진다.

코딩 모델의 평가 생태계도 같은 원리다. 공개 평가 저장소가 생겼다고 회사가 자동으로 신뢰할 수 있는 마이그레이션을 얻게 되지는 않는다. 도메인별 테스트 자료, 차이를 검토할 전문가, 출력 비교기가 준비돼야 한다. 이후 발표에서 점수가 더 올라가면 가장 먼저 볼 것은 ‘우리 기준에서 남아 있는 실패가 줄었는가’다. 숫자가 커진 이유가 새로운 평가 집합의 쉬운 문제 때문인지, 실제 어려운 경계의 개선 때문인지 확인해야 한다.

두 발표의 장기 의미를 한 문장으로 정리하면 이렇다. AI는 코드를 만들고 실행 플랫폼은 그 코드를 더 다양한 장치에 올리는 일을 쉽게 하고 있다. 그 결과를 업무적으로 동일하고 운영상 안전하다고 증명하는 일은 여전히 별도의 전문 영역이다. 오늘의 뉴스가 유용한 이유는 바로 그 검증 영역을 구체적인 시험과 운영 질문으로 바꾸게 해 주기 때문이다.

부록 O. 파일럿 팀이 처음 물어야 할 질문과 짧은 답

O-1. “모델 점수가 97.9%면 사람 검토를 2.1%에만 하면 되나요?”

아니다. 그 수치는 공식 COBOL 마이그레이션 평가의 해당 설정에서 관측된 정확도다. 우리 코드의 어느 2.1%가 실패할지 미리 알려 주지 않는다. 더욱이 평가의 프로그램과 조직의 프로그램은 다르다. 사람 검토를 무작정 모든 줄에 동일한 깊이로 적용할 필요는 없지만, 금액·권한·외부 효과를 다루는 경로와 자동 시험이 포착하지 못하는 업무 규칙에는 집중해야 한다. 자동 비교와 위험 기반 리뷰를 결합하면 검토 시간을 더 효율적으로 쓸 수 있다.

검토 범위를 줄이려면 먼저 테스트가 결함을 실제로 잡는지 증명한다. 과거 장애를 주입하고 실패하는지, 숫자 절사 규칙을 일부러 바꿨을 때 경고하는지, 외부 상태를 한 번 더 수정했을 때 금지된 부작용으로 분류하는지 확인한다. 테스트가 약한 상태에서 모델 점수만 높다고 리뷰를 줄이면 검증되지 않은 위험을 사람에게 넘기는 것이다.

O-2. “프로그램을 통째로 변환하는 편이 빠르지 않나요?”

한 번의 생성으로 전체 코드를 얻는 것은 빠르다. 그러나 차이가 났을 때 원인을 찾고 수정하는 시간까지 보면 반드시 빠르지 않다. 명확한 입출력 경계가 있는 모듈부터 변환하고 각 단계에서 golden 비교를 돌리면 오류를 좁히기 쉽다. 다만 파일을 너무 작게 쪼개면 원본의 전역 상태와 호출 순서를 잃는다. 작업 단위는 문맥을 이해할 만큼 넓고 차이를 검증할 만큼 좁아야 한다. 프로그램의 복잡도에 따라 이 경계를 정한다.

전체 변환 초안은 아키텍처를 파악하는 데 유용할 수 있다. 그러나 배포 승인 단위는 업무 효과와 연결된 테스트 가능한 경로로 나눈다. 예를 들어 직원별 정산 계산, 파일 포맷 변환, 지급 요청 생성은 서로 다른 위험을 가진다. 초안의 생성 단위와 출시의 승인 단위를 같게 만들 필요는 없다.

O-3. “Trainium에서 코드가 한 줄만 바뀌면 테스트도 줄일 수 있나요?”

아니다. 소스 코드의 변경량은 실행 환경의 변화량을 뜻하지 않는다. .to('neuron') 한 줄이 장치 연산, 메모리 배치, 컴파일 경로, 수치 정밀도, 분산 통신을 바꿀 수 있다. 적어도 목표 모델의 로드, 대표 입력의 출력 품질, 짧고 긴 입력의 지연, 장애 복구를 확인한다. 코드가 간단해진 것은 좋은 개발 경험이다. 그러나 간단한 API가 의미하는 것은 실험 시작의 비용이 낮아졌다는 것이지 실험이 생략된다는 것이 아니다.

테스트 수준은 서비스 위험에 맞춰 조절할 수 있다. 연구용 실험에서는 짧은 스모크 테스트와 profiler가 충분할 수 있다. 고객 대상 서비스에서는 품질 회귀와 p95 지연, 고장 시 대체 경로가 필요하다. 공개 베타를 어떤 목적에 쓰느냐가 시험의 깊이를 결정한다.

O-4. “89% 지원인데 우리 모델이 안 되면 발표가 잘못된 건가요?”

그럴 필요는 없다. 공식 수치의 분모는 상위 100개 텍스트 생성 모델 아키텍처이고 비교 대상은 Optimum Neuron v0.4.5다. 팀의 특정 체크포인트가 커스텀 연산, 새로운 아키텍처 리비전, 별도 양자화 방식을 쓴다면 그 범위에 속하지 않을 수 있다. 우선 해당 모델이 수치의 범위에 들어가는지 확인하고, 정확한 버전에서 재현 가능한 오류를 만든다. 그 뒤 지원 문서와 이슈를 확인해 해결 가능한 설정 문제인지 기능 공백인지 판단한다.

반대로 모델이 로드됐다고 발표의 89%와 같은 성능 수준을 얻은 것도 아니다. 지원 비율은 성능 비율이 아니다. 로드·정합성·성능·복구라는 계단을 각각 통과해야 고객의 모델 지원이라고 부를 수 있다.

O-5. “GPU와 Trainium 중 어느 쪽이 더 싸다고 결론 내릴 수 있나요?”

오늘 확인한 공식 자료만으로 우리 팀의 비용 우위를 결론 낼 수 없다. 모델 아키텍처, 요청 길이, 배치, 동시성, 지역, 구매 방식, 유휴 시간과 엔지니어링 비용이 필요하다. PyTorch 글의 고객 인용에 다른 업체의 특정 워크로드 비용 이익이 있어도 그 조건을 우리 서비스에 일반화하지 않는다. 같은 모델과 품질 기준을 만족시키며 실제 요청을 완료하는 데 얼마가 드는지를 두 경로에서 측정한다.

비용 실험은 같은 기간에 해야 한다. 한쪽에는 새 모델 버전을, 다른 쪽에는 오래된 버전을 쓰면 장치의 차이가 아니라 모델의 차이를 보게 된다. 한쪽만 미리 컴파일하고 다른 쪽은 첫 실행을 재면 초기화 조건이 다르다. 공정한 비교는 비용만이 아니라 품질과 지연의 동일한 목표를 만족하는 구성을 찾는 과정이다.

O-6. “지금 바로 프로덕션 전환을 시작해야 하나요?”

발표가 새로운 선택지를 열었다는 이유만으로 전면 전환 일정을 잡을 필요는 없다. 반대로 완벽한 일반 공개를 기다리며 아무것도 확인하지 않는 것도 기회를 놓칠 수 있다. 레거시 쪽에서는 원본의 테스트 가능성과 가장 위험한 불일치부터 확인한다. Trainium 쪽에서는 공개 베타의 실제 패키지 상태를 확인하고 목표 체크포인트를 한 개 실행한다. 작은 실험의 결과가 다음 투자의 근거가 된다.

프로덕션 전환은 발견된 결함을 모두 ‘수정 예정’으로 적어 두고 진행하는 행사가 아니다. 업무 소유자가 검증 기준을 승인하고, 운영자가 실패를 관측하고 되돌릴 수 있으며, 사용자에게 영향을 주는 차이가 분류됐을 때 시작한다. 그 시점까지는 격리된 평가와 섀도 실행에서 학습한다. 두 공식 발표의 장점은 그 평가를 더 잘할 도구와 모델이 늘었다는 데 있다.

부록 P. 독자가 직접 재확인할 때의 순서

먼저 OpenAI 공식 글에서 두 평가를 분리해 읽는다. MultiLangBench의 20개 언어 평균과 COBOL 마이그레이션의 프로그램별 성공률은 같은 종류의 수치가 아니다. 공개 저장소에서는 입력·수정된 데이터베이스 파일·검증 쿼리의 관계, 전체 변환 테스트와 권장 기본 부분집합의 차이, SQLite 우회 금지 조건을 확인할 수 있다. 벤치마크를 사내에서 재현한다면 시험의 제약을 그대로 썼는지 문서화한다. 일부 제약을 완화했다면 더 현실적인 개발 시험일 수 있지만 원래 점수와 직접 비교해선 안 된다.

다음으로 Hugging Face 글과 PyTorch 글을 나란히 읽는다. Hugging Face는 개발자가 실제로 쓰는 라이브러리에서 무엇이 달라지는지 보여 주고, PyTorch는 장치 등록과 eager·compiled 경로, 분산 API, 프로파일링의 기술 경계를 설명한다. 두 글 모두 10월 20일 공개 베타를 예고하지만, 오늘의 기사에서 해당 패키지의 실제 실행까지 증명한 것은 아니다. 팀이 설치를 시작할 때에는 그 시점에 제공되는 최신 공식 문서와 패키지 버전을 확인해야 한다.

읽는 순서의 마지막은 자신들의 시스템이다. 원본 배치의 예외 파일, 운영자가 수동 보정한 기록, 현재 GPU 서비스의 요청 길이 분포는 공개 글보다 우리 결정을 더 직접적으로 좌우한다. 공개 발표는 무엇을 시험할지 알려 주지만, 어떤 차이를 허용할지는 조직의 업무와 사용자가 결정한다. 그래서 뉴스에 실린 큰 수치를 프로젝트 승인선으로 바로 바꾸지 않고, 작은 재현 실험의 가설로 바꾼다.

특히 매일 발표가 쏟아지는 AI 분야에서는 발표 날짜와 기능 상태를 함께 적는 습관이 중요하다. 어제의 발표가 오늘의 공개 베타를 예고하는 경우, 예고와 실제 사용 가능 상태를 분리한다. ‘지원한다’는 문장도 아키텍처가 로드되는지, 특정 모델이 정확한 출력을 내는지, SLA를 만족하는지에 따라 층위가 다르다. 이러한 구분은 신중한 표현을 위한 장식이 아니라 개발 계획의 순서를 정확히 만드는 도구다.

이번 호의 두 뉴스는 코드와 칩을 둘러싼 장벽을 낮춘다는 공통점을 가진다. 하지만 장벽이 낮아질수록 검증되지 않은 변경도 쉽게 만들어진다. 저자료 언어의 모델 성능 향상은 레거시 프로젝트를 다시 시작할 근거가 되고, 네이티브 PyTorch 지원은 새로운 가속기를 시험할 실용적 계기가 된다. 그다음 단계는 조직의 입력과 출력, 장애와 비용을 기준으로 직접 측정하고 기록하는 일이다. 숫자를 다시 계산할 수 있고 실패를 다시 재현할 수 있을 때, 기술 뉴스는 비로소 배포 가능한 의사결정으로 바뀐다.

오늘의 최종 체크: 무엇을 아직 모르는가

우리는 공개 발표에서 제시된 모델 점수와 기능 목록을 확인했지만, 이 글의 독자가 운영하는 특정 COBOL 저장소에서 같은 정확도가 나오는지는 모른다. 저장소가 어떤 컴파일러 확장과 외부 파일 계약을 사용하는지, 문서화되지 않은 규칙이 얼마나 있는지, 사업상 허용할 수 없는 오류가 무엇인지에 대한 데이터가 없기 때문이다. 이 공백은 추정으로 메울 수 없다. 원본의 실행 결과를 수집하고 도메인 담당자와 경계 입력을 정한 뒤 후보 모델을 평가해야 한다.

Trainium에서도 특정 팀의 모델이 TorchNeuron 공개 베타에서 실제로 로드되는지, 어떤 연산이 CPU에 남는지, 입력 길이에 따른 컴파일 비용이 얼마인지, GPU 경로와 비교한 전체 서비스 비용이 어떻게 되는지는 모른다. 공식 글의 지원 범위는 실험의 우선순위를 잡는 데 도움을 준다. 그러나 구매·배포 결정에 필요한 수치는 대상 모델과 목표 인스턴스에서 직접 측정해야 한다. 베타의 기능 상태도 오늘 이후 바뀔 수 있으므로 설치 시점의 공식 문서와 버전을 다시 확인한다.

이처럼 모르는 것을 목록화하면 계획이 더 선명해진다. 레거시 팀의 첫 산출물은 golden corpus와 차이 분류표, 플랫폼 팀의 첫 산출물은 버전이 고정된 로드·정합성·지연 결과다. 둘 다 거창한 전면 도입 선언보다 작지만 검토 가능하다. 하나의 성공 숫자 뒤에 남아 있는 실패 모드를 보이게 하는 것이 이번 호가 제안하는 공통 실행 원칙이다.

다음 번 내부 검토 회의에서는 각 주장 옆에 출처, 확인 날짜, 자체 측정 여부를 붙이는 편이 좋다. 발표자가 측정한 값은 외부 관찰, 팀이 동일한 환경에서 재현한 값은 내부 관찰, 아직 시험하지 않은 기대치는 가설로 표시한다. 가설의 책임자와 검증 기한을 적으면 과장된 숫자가 예산 문서에서 사실처럼 굳어지는 것을 막을 수 있다. 반대로 실제로 재현된 이점은 명확히 채택 근거로 삼을 수 있다. 개발 현장의 판단은 기술에 대한 낙관이나 회의가 아니라 관측한 결과와 남아 있는 위험의 균형에서 나와야 한다.

장기적으로는 이 기록을 다음 모델과 다음 장치의 비교 기준으로 재사용한다. 오늘의 시험이 잘 설계되면 내년의 새로운 코딩 모델에도 같은 레거시 사례를 적용할 수 있고, 다음 가속기에도 같은 부하와 품질 게이트를 적용할 수 있다. 그래서 평가 하네스의 가치는 이번 발표를 검증하는 데 그치지 않는다. 앞으로의 기술 선택을 더 빠르고 더 공정하게 만드는 조직의 자산이 된다.

공식 소스 링크와 확인 범위

• OpenAI: Advancing coding in low-resource programming languages — 2026년 10월 19일 발표. MultiLangBench와 COBOL 마이그레이션 결과, 비용 비교, 프로덕션 적용의 단서.
• OpenAI: MultiLangBench 공개 저장소 — SQLite 3.40.1 기반 시험 형식, 약 2만 4천 변환 테스트, 기본 272개 부분집합, 언어·인터넷·SQLite 우회 제한.
• Hugging Face: TorchNeuron 공식 소개 — 2026년 10월 19일 목록 확인. Transformers·Diffusers·TRL 예시, 상위 아키텍처 지원 범위, 10월 20일 공개 베타 예고.
• PyTorch: Introducing TorchNeuron — 2026년 10월 19일 갱신. PrivateUse1, eager·compile, 분산 API, NKI, profiler, 베타와 private beta의 구분.
• AWS Neuron: PyTorch 개발 문서 — 구현 및 지원 범위를 확인할 공식 문서 진입점.
• OpenAI 공식 뉴스 목록 · Hugging Face 공식 블로그 목록 — 발행 시점의 발표 날짜 확인.
• Google 개발자 블로그 · Anthropic 공식 뉴스 목록 · GitHub 개발자 뉴스 — 확인한 공식 목록. 이 글의 두 주요 발표의 수치 근거로 사용하지 않았다.