GPT-6 Astra 87.4% 평가와 COBOL 현대화 검증

OpenAI가 10월 19일 공개한 저자원 프로그래밍 언어 평가에서 GPT-6 Astra는 MultiLangBench의 20개 언어 평균 테스트 통과율 87.4%를 기록해 GPT-5.6 Sol의 26.8%를 웃돌았다. 이 성적은 지정된 언어로 SQLite 호환 데이터베이스 엔진을 새로 만드는 과제에서 나온 것으로, 기존 COBOL 시스템을 다른 언어로 옮긴 성공률과는 구별해야 한다.

TokenPost의 10월 20일 보도에 따르면 Astra의 COBOL 통과율은 이전 모델의 10.9%에서 72.1%로, Fortran은 21.4%에서 83.5%로 높아졌으며, 별도 COBOL 변환 평가에서는 GPT-6.1 Sol이 낮은 추론 강도에서 86.6%, 높은 추론 강도에서 97.9%를 기록했다. 이 결과만으로 실무 이전의 성공률을 예측할 수는 없다. 새 코드 작성 능력의 향상은 확인됐지만, 원래 프로그램의 출력과 업무 규칙을 보존하는 일은 각 시스템의 코드와 데이터로 따로 검증해야 한다.

평균보다 낮은 COBOL 성적, Fortran과도 다른 과제

MultiLangBench는 여러 언어에 같은 문제를 주고 모델이 얼마나 작동하는 코드를 만들 수 있는지 측정한다. 이번 결과에서는 Astra가 평가된 모든 언어에서 비교 모델보다 나아졌지만, 언어별 도달 수준은 같지 않았다. 특히 COBOL은 Astra의 전체 평균 아래에 머물렀고, 평가 대상 중 가장 어려운 언어로 남았다. 평균만 보면 놓치기 쉬운 차이가 레거시 언어를 실제로 다루는 조직에는 핵심이다.

전체 평균은 서로 다른 언어로 새 데이터베이스 엔진을 구축한 결과를 한데 묶은 지표다. 특정 언어의 이전 성공률로 해석할 수 없다.
COBOL과 Fortran의 언어별 성적은 같은 새 코드 작성 과제에서 나온다. 두 언어의 점수를 서로 바꾸어 적용하거나 한쪽 성적으로 다른 쪽의 업무 코드를 평가할 수 없다.
COBOL 변환 정확도는 기존 프로그램의 동작을 보존하는 별도 시험이다. 그 수치의 주체는 Astra가 아니라 GPT-6.1 Sol이며, 추론 강도에 따라 성적이 달라진다.

비교 대상인 GPT-5.6 Sol도 동일한 MultiLangBench 과제를 수행했다. 따라서 평균의 차이는 동일한 평가 안에서 새 프로그램을 만드는 능력이 크게 달라졌음을 보여준다. 다만 여기서 작성한 것은 은행의 계정계 프로그램이나 공공기관의 배치 업무가 아니라 공통 사양을 가진 데이터베이스 엔진이다. 언어가 같다는 이유만으로 두 작업의 난도와 실패 유형이 같아지는 것은 아니다.

저자원이라는 표현도 사용량이 적다는 뜻으로만 읽을 수 없다. OpenAI는 Python이나 JavaScript에 비해 학습에 쓸 공개 코드와 문서가 적은 언어를 염두에 두고 이 평가를 설계했다. 오래된 시스템에서는 담당자가 바뀌고 문서가 부족해져 실제 업무 규칙이 코드에만 남아 있을 수 있다. 모델이 언어 문법을 더 잘 다루게 됐다는 발표가 이런 숨은 규칙까지 자동으로 찾아냈다는 뜻은 아니다.

MultiLangBench가 확인한 것은 실행 결과

MultiLangBench에서 생성한 SQLite 호환 엔진의 데이터베이스 결과를 기준 구현과 대조하는 과정

이 평가는 코드의 문법이나 그럴듯한 설명만 채점하지 않는다. 모델이 만든 프로그램은 초기 데이터베이스 파일과 SQL 질의를 입력받아 수정된 데이터베이스 파일을 내놓는다. 기준 SQLite 구현으로 그 결과물을 읽어 예상한 내용이 들어 있는지 확인한다. 언어가 달라도 같은 파일을 공통 인터페이스로 사용하므로 결과를 같은 테스트에 대조할 수 있다.

엔진을 만드는 동안 모델은 상태를 관리하고 오류를 처리하며 새 기능을 추가해야 한다. 뒤에 기능을 붙였을 때 앞서 만든 기능이 깨지면 그 실패도 테스트에 드러난다. 그래서 통과율은 한두 줄짜리 코드의 문법 정확도보다 긴 코딩 작업의 작동 범위를 더 직접적으로 보여준다. 실제 프로그램을 실행해 얻은 결과가 성적의 중심이라는 점에서 단순 코드 완성 평가보다 정보가 많다.

동시에 통과율의 분모는 OpenAI가 구성한 테스트 묶음이다. Think Facility의 평가 정리는 MultiLangBench의 설정과 테스트는 공개되지만 COBOL 변환 테스트는 그 공개 대상에 포함되지 않는다고 설명했다. 공개된 과제는 외부 개발자가 같은 조건으로 모델을 시험할 수 있는 출발점을 제공한다. 그러나 특정 기관의 비공개 업무 코드가 그 테스트에 포함되었다는 의미는 아니다.

이 차이는 점수를 해석할 때 중요하다. SQLite와 호환되는 엔진을 만드는 과정에는 파일 상태와 질의 처리 같은 복잡한 문제가 있지만, 기존 조직의 프로그램에는 그 조직만의 입력 형식과 다른 프로그램과의 연결이 있다. 공개 과제의 테스트를 모두 통과해도 그런 연결에서 어떤 값이 오가는지는 별도로 드러나지 않는다. 따라서 평균 통과율은 모델의 언어별 코딩 능력을 비교하는 근거이고, 운영 중인 시스템의 변경 승인 기준은 아니다.

COBOL 변환은 GPT-6.1 Sol의 동작 보존 시험

COBOL 프로그램과 변환된 프로그램의 계산 결과에서 소수 자릿수 차이가 동작 일치를 깨뜨리는 사례

COBOL 현대화에 더 직접적인 실험은 기존 프로그램을 C++, Java, Kotlin, Python 또는 Rust로 옮기는 별도 평가다. 여기서는 변환된 프로그램이 정상 실행되는 것만으로 합격하지 않는다. 숨겨진 테스트의 모든 입력에서 관찰 가능한 출력이 원본과 바이트 단위로 같아야 성공으로 센다. 기능은 비슷해 보여도 숫자 한 자리나 출력 형식이 바뀌면 동작 보존에 실패한 것이다.

그 평가에서 낮은 추론 강도의 GPT-6.1 Sol은 이전 모델보다 높은 정확도를 기록했고, 같은 조건의 추정 API 비용도 낮았다. 높은 추론 강도에서 나온 최고 정확도는 다른 조건의 결과다. 낮은 설정의 비용과 높은 설정의 정확도를 하나의 실행 조건처럼 결합하면 비용 대비 성능을 과장하게 된다. Astra의 데이터베이스 엔진 작성 성적을 이 변환 시험의 정확도나 비용으로 옮겨 적는 것도 잘못된 비교다.

COBOL의 고정소수점 계산은 왜 출력 일치가 필요한지를 잘 보여준다. 명시적인 반올림 지시가 없으면 남는 소수 자릿수를 버리는데, 변환본이 이를 반올림으로 처리하면 오류 없이 실행되면서도 금액이 달라질 수 있다. 누락된 레코드를 처리하는 순서나 기본값도 원본의 업무 결과에 영향을 준다. 이런 차이는 코드가 보기 좋게 정리되었는지와 별개로 거래 결과를 바꿀 수 있다.

숨겨진 테스트는 평가 과정에서 공개되지 않은 입력으로 변환본을 시험하지만, 운영 시스템의 모든 상황을 대신하지는 못한다. 합격률은 평가에 포함된 프로그램과 입력에 대한 결과다. 여러 프로그램이 파일을 주고받는 흐름, 오래된 외부 인터페이스, 문서화되지 않은 예외 규칙이 실제 이전 범위에 들어가면 다시 같은 동작을 보이는지 살펴봐야 한다. 전문가 검토와 업무 규칙에 맞춘 테스트가 필요한 이유가 여기에 있다.

한국 금융·공공 시스템에 남는 세 가지 판단축

한국에서 COBOL이나 Fortran으로 운영하는 금융·공공 시스템을 검토한다면 먼저 어떤 작업을 평가할지 분명히 해야 한다. 새 코드를 작성하는 일에는 해당 언어의 MultiLangBench 결과가 참고가 되지만, 기존 프로그램을 이전하는 일에는 원본과 변환본의 동작 일치가 더 직접적인 지표다. 새 기능의 구현 능력과 낡은 업무 규칙의 보존 능력은 서로 보완하지만 같은 성적표에 올릴 수 없다.

다음은 추론 강도와 비용이다. 변환 시험에서 더 높은 정확도를 얻은 설정은 더 많은 추론을 쓰는 조건이므로, 낮은 설정의 비용 수치와 한데 묶어 예산을 잡을 수 없다. 공개된 비용 비교는 평가 과제를 처리하는 추정 API 사용량에 관한 것이다. 생성된 코드를 읽고, 테스트 실패 원인을 찾고, 수정한 뒤 다시 시험하는 사람의 시간까지 합친 운영 이전 비용은 그 수치에 들어 있지 않다.

마지막은 비공개 실무 코드의 회귀 테스트다. 같은 입력을 원본과 변환본에 넣어 출력 값뿐 아니라 숫자 자릿수, 누락 레코드 처리, 예외 경로, 파일 형식을 대조해야 한다. 프로그램이 외부 시스템에서 값을 받거나 다른 프로그램으로 결과를 넘긴다면 그 경계도 시험에 포함된다. 이는 모델의 일반적인 언어 이해도를 재는 일이 아니라 해당 조직의 업무 결과가 유지되는지를 확인하는 절차다.

특히 금융 거래처럼 작은 계산 차이가 누적될 수 있는 영역에서는 정상 종료 여부만으로 변경을 승인하기 어렵다. 배치 작업이라면 중간 파일과 재실행 상황, 온라인 처리라면 요청과 응답의 경계까지 실제 업무 조건을 반영해야 한다. 이런 항목은 발표된 평가에 모두 들어 있다고 가정할 수 없으며, 각 기관이 보유한 코드와 테스트 자료에 따라 범위가 달라진다. 모델의 높은 공개 성적은 시험할 후보를 좁혀 주지만, 운영 승인에 필요한 증거는 해당 시스템에서 만들어진다.

이번 발표로 외부가 같은 조건에서 재시험할 수 있는 새 코드 작성 평가가 열렸다. 다음 관건은 한국의 실제 레거시 코드에서 원본과 변환본을 나란히 실행했을 때 얼마나 많은 업무 규칙이 그대로 유지되고, 오류를 고치는 데 얼마나 많은 검토가 드는지다. 그 데이터가 쌓여야 모델 성능의 개선을 특정 시스템의 안전한 이전 범위와 비용으로 연결할 수 있다.

함께 읽기: