당신이 COBOL 프로그램을 모델에게 건네고 Java 작성을 요청했다고 가정해 봅시다. Java는 컴파일됩니다. 당신이 작성한 테스트도 통과합니다. 그러다 한 배치 실행에서 고객에게 메인프레임보다 1센트가 더 지급되는데, 그 이유는 기존 코드는 세 번째 소수점 자리까지 처리했지만 새 코드는 반올림했기 때문입니다.
그 1센트가 OpenAI가 COBOL, Fortran 및 Visual Basic 언어의 코딩에 대해 10월 19일 게시된 글에서 제시한 기준점입니다. COBOL 마이그레이션 평가에서는 모든 숨겨진 테스트가 원본과 동일한 관찰 가능한 출력을 바이트 단위로 생성할 때만 마이그레이션으로 인정합니다. 이 평가에서 OpenAI는 GPT-6.1 Sol이 낮은 추론 노력(low reasoning effort)을 투입하여 86.6%의 작업을 통과했으며, 같은 설정에서의 GPT-5.6 Sol은 5.4%를 기록했다고 보고했습니다 (OpenAI, TokenPost). 높은 노력(high effort)을 투입했을 때는 97.9%에 도달했습니다.
이 수치들은 모두 OpenAI가 자체적으로 수행한 평가에서 나온 큰 숫자이며, 마이그레이션 테스트는 공개되지 않았습니다. 두 가지 평가 중 오직 하나만 다시 실행해 볼 수 있습니다.
OpenAI가 발표한 내용
이 글은 새로운 제품이 아니라 기능 업데이트입니다. Runtime Wire는 이를 같은 방식으로 설명하고 있으며, OpenAI 자체 문구에 따르면 팀이 사용하는 언어의 코딩 작업에서
- MultiLangBench (구축 중). 모델이 20개 언어 중 하나로 SQLite 호환 데이터베이스 엔진을 처음부터 작성합니다 (OpenAI).
- COBOL 마이그레이션. 모델이 COBOL 프로그램을 C++, Java, Kotlin, Python 또는 Rust로 변환하며, 숨겨진 테스트가 관찰 가능한 출력물에 대해 바이트 단위의 일치 여부를 확인합니다 (OpenAI).
OpenAI는 이 작업을 금융 시스템, 카드 및 ATM 거래에서 COBOL이 차지하는 비중과 기상 예측 및 원자력 안전 분석에 사용되는 Fortran의 용도를 언급하며 언어 중심으로 설명합니다 (OpenAI).
모델별 수치
최대 추론 노력(maximum reasoning effort)을 투입한 MultiLangBench에서, OpenAI는 20개 언어에 걸친 평균 테스트 통과율을 다음과 같이 보고합니다 (OpenAI; GPT-5.6 Sol 및 Astra의 평균과 COBOL 셀은 TokenPost에서도 확인할 수 있습니다):
| 언어 | GPT-5.6 Sol | GPT-6 Luna | GPT-6 Astra |
|---|
| 평균 (20개 언어) | 26.8% | 40.3% | 87.4% |
| ... | | | |
COBOL은 Astra가 가장 낮은 점수를 기록한 언어로, 72.1%입니다 (OpenAI). Luna는 저렴한 옵션으로, OpenAI는 GPT-5.6 Sol 대비 샘플당 $0.77로 추정하며, Astra보다 훨씬 낮은 점수를 보였습니다.
가격이 중요한 이유는 두 개의 주요 모델 간의 가격 차이가 크기 때문입니다. GPT-6.1 Sol은 입력 토큰당 2달러, 출력 토큰당 10달러로 책정되어 있으며, GPT-6 Astra는 각각 10달러와 50달러입니다. 마이그레이션 평가의 경우, OpenAI에 따르면 GPT-6.1 Sol은 GPT-5.6 Sol의 예상 API 비용의 61% 수준으로 작동했습니다 (OpenAI). TokenPost는 이 수치가 평가(eval)만을 다루며, 실제 프로덕션 시스템을 이전하는 비용은 포함하지 않는다고 언급했습니다.
절반은 직접 실행할 수 있습니다
MultiLangBench는 Apache-2.0 라이선스 하에 GitHub에서 이용 가능합니다. README에는 모델이 요청된 언어로 SQLite 3.40.1을 구현해야 하며, 이때 SQLite 문서를 참조해야 한다고 명시되어 있습니다. 테스트 케이스는 SQLite의 TCL 스위트에서 변환되었으며, 전체 약 51k개 중 24k개에 해당합니다. 각 테스트는 초기 데이터베이스, 사용자 질의(user query), 그리고 검증 질의(validation query)로 구성됩니다.
OpenAI와 비교하여 여러분의 수치를 산출하기 전에 README에서 알아두면 좋은 몇 가지 규칙이 있습니다:
- 이름이
00, 01 또는 02로 시작하는 272개 테스트만 사용하십시오. 높은 점수를 받은 샘플에 대한 추가적인 정밀도가 필요할 경우 전체 스위트를 사용할 수 있지만, 반드시 그렇게 명시해야 합니다.
- 먼저 환경에서 SQLite의 흔적을 모두 제거하고 인터넷 접속 없이 실행하십시오.
- 각 테스트는 60초의 시간 제한이 있으며, 잘못된 언어로 작성된 솔루션은 점수 0점을 받습니다.
점수는 API 비용과 테스트 통과율이라는 두 쌍으로 이루어져 있으므로, 낮은 점수를 가진 모델이라도 비용이 저렴하다면 예산 측면에서 무조건 나쁘다고 할 수 없습니다 (MultiLangBench).
마이그레이션 평가(migration eval)는 재실행할 수 없는 절반입니다. Runtime Wire에서는 이를 "OpenAI가 설계한 숨겨진 테스트"라고 부르며, GitHub 리포지토리에는 SQLite 빌드 작업만 포함되어 있습니다. 따라서 86.6%는 OpenAI가 자체적으로 설정한 숨겨진 테스트를 기준으로 측정한 수치입니다. 또한 OpenAI는 마이그레이션 결과물이 프로덕션에 배포되기 전에 여전히 전문가의 검토와 비즈니스 규칙 및 시스템 종속성에 대한 테스트가 필요하다고 밝히고 있습니다 (OpenAI).
패리티 체크(parity check)를 직접 구축하기
OpenAI의 방법에서 재사용할 수 있는 것은 통과 규칙입니다. 즉, 결과물이 정확히 일치할 때만 마이그레이션으로 간주됩니다. 모델을 신뢰하기 전에 자체 코드에 이 검사를 구현할 수 있습니다.
실제 입력값을 수집하고, 기존 빌드와 마이그레이션된 프로그램 각각에 대해 실행한 다음, 바이트 단위로 비교합니다:
import subprocess
import sys
from pathlib import Path
...
이는 종료 코드(exit codes)와 표준 출력(stdout)을 원시 바이트(raw bytes)로 비교하므로, 후행 공백(trailing spaces), 줄 바꿈 문자(line endings), 패딩된 숫자까지 모두 계산됩니다. 만약 배치 작업이 파일을 출력하는 경우라면, 그 파일들도 같은 방식으로 비교해야 합니다.
마이그레이션을 망가뜨리는 경우는 조용한 경우가 많습니다. OpenAI의 예시는 COBOL의 고정 소수점 산술(fixed-point arithmetic)인데, 반올림을 요청하지 않으면 추가적인 소수 자릿수를 잘라내는(truncates) 특성이 있습니다 (OpenAI). Python에서는 decimal 모듈을 사용하여 어떤 동작 방식을 원하는지 지정할 수 있습니다:
from decimal import Decimal, ROUND_DOWN, ROUND_HALF_UP
amount = Decimal("2") / Decimal("3")
...
3분의 2는 소수점 이하를 반올림하여 0.67이 됩니다. float와 round()를 사용하는 마이그레이션된 프로그램은 반올림 경로를 따르며, 단순히 '충분히 가까움'만 확인하는 모든 테스트를 통과하게 합니다. cases/ 폴더에 이러한 값들과 더불어 빈 레코드 및 최대 필드 너비 같은 값을 채워 넣으세요. TokenPost 역시 같은 점을 지적합니다: 반올림 방식이나 누락된 레코드를 처리하는 방식의 변경만으로도 대체 코드가 작동하는 것처럼 보여도 결과가 바뀔 수 있습니다.
마이그레이션을 작업(task)으로 실행하기
COBOL 포팅은 오랜 시간 걸리는 에이전트 작업입니다. 프로그램을 읽고, 새로운 것을 작성하고, 패리티 스크립트를 실행하고, 차이점(diffs)을 수정하고, 다시 실행하는 과정을 반복합니다. 레거시 트리가 손상되지 않도록 별도의 브랜치를 할당해 주는 것이 좋습니다.
저는 Hermes IDE를 구축했으니 이 점을 염두에 두세요. Hermes는 Claude Code, Codex 및 기타 커맨드라인 에이전트들을 나란히 실행하며, 각각 자체 터미널과 작업 공간(worktree)에서 작동합니다(README). ⌘N을 누르면 해당 hermes/<name> 브랜치에 작업을 시작하고, 이 작업이 에이전트의 첫 번째 프롬프트가 됩니다. 이를 통해 동일한 마이그레이션 티켓을 두 개의 에이전트에게 전달하여 두 브랜치 모두에 대해 패리티 스크립트를 실행할 수 있습니다. 저는 아직 OpenAI 모델을 COBOL 마이그레이션에 직접 적용해 본 적은 없습니다.
Two real agent sessions side by side in Hermes IDE: Codex on orders-types and Claude Code on orders-api, each in its own hermes/ worktree, with the sessions sidebar on the left
Hermes IDE 2.3.4: Codex와 Claude Code가 각각 자체 hermes/ 작업 공간에서 나란히 작동하며, 상태, 컨텍스트 사용량, 비용 및 브랜치가 사이드바에 표시됩니다.
Hermes는 다운로드할 수 있으며, BSL 1.1 하에 소스 코드를 공개하고 있습니다. macOS, Windows, Linux에서 실행 가능합니다. OpenAI, Anthropic 또는 기타 에이전트 공급업체와는 관련이 없습니다.
OpenAI만 이런 것이 아닙니다: TokenPost는 IBM의 COBOL-to-Java 도구와 비교 테스트를, 그리고 Anthropic이 Claude Code로 COBOL을 마이그레이션하는 공개된 접근 방식을 언급합니다. 어떤 에이전트를 선택하든, 패리티 스크립트(parity script)가 해당 포팅 여부를 결정합니다.
이번 주에 할 일
COBOL, Fortran 또는 Visual Basic 코드를 소유하고 있다면, 세 가지 단계는 비용이 거의 들지 않습니다:
- 모델이 코드에 접근하기 전에 실제 프로덕션 입력으로 패리티 하네스(parity harness)와
cases/ 폴더를 구축합니다.
- OpenAI의 수치 대신 자신만의 수치를 원한다면, 관심 있는 언어에 대해 MultiLangBench의 272개 테스트 서브셋을 실행합니다.
- GPT-6.1 Sol through the API로 작고 잘 테스트된 프로그램을 시도해보고, 몇 개의 케이스가 바이트 단위로 동일하게 돌아오는지 계산합니다.
패리티 하네스가 깨끗한 결과를 보여준다면, 오늘 모델에게 마이그레이션하도록 맡기고 싶은 레거시 코드가 있습니까? 댓글로 알려주세요.
유용했다면
이러한 마이그레이션은 에이전트 루프(agent loop)입니다: 작성하고, 검사를 실행하며, 차이점(diff)을 읽고, 다시 시도하며, 하네스가 녹색 신호가 될 때까지 중지합니다. AI Agents Pocket Guide는 도구 호출부터 에이전트가 너무 일찍 승리를 선언하는 것을 막는 가드레일(guardrails)에 이르기까지, 그 루프 뒤의 패턴들을 다룹니다. 동일한 티켓에 두 개의 에이전트를 실행하고 싶다면, Hermes IDE가 무료이며 제가 구축했습니다.
AI Agents Pocket Guide: Patterns for Building Autonomous Systems with LLMs
