자료가 적은 프로그래밍 언어에서 AI 코딩 능력을 시험하는 두 평가

배경과 문제

COBOL, Fortran, Visual Basic 같은 언어는 Python이나 JavaScript보다 학습에 쓸 코드와 문서가 적다. 그렇지만 금융 거래나 과학 계산 등에서 여전히 쓰인다. OpenAI는 개발자와 기업 고객으로부터 코딩 모델이 이런 언어를 다룰 때 어려움을 겪는다는 피드백을 받았다고 설명한다. 언어가 오래됐다는 사실보다 모델이 배울 자료와 실제 유지보수 수요 사이의 차이가 핵심 문제다.

이런 소프트웨어를 유지보수하거나 현대화하는 일은 여러 이유로 어렵다. 문서가 불완전할 수 있고, 원래 개발자는 회사를 떠났을 수 있으며, 중요한 업무 규칙이 코드 안에만 존재할 수 있다. 버그를 고치든 다른 언어로 옮기든, 시스템이 의존하는 동작을 그대로 보존해야 한다. 이 문제를 해결하려면 모델이 낯선 저장소를 이해하고, 변경을 계획하고, 빌드 도구를 쓰고, 테스트를 실행하고, 실패를 디버깅하는 능력을 갖춰야 한다.

기존 접근의 한계

비교 대상인 GPT-5.6 Sol은 MultiLangBench에서 평균 테스트 통과율 26.8%, 낮은 추론 노력의 COBOL 이식 평가에서 성공률 5.4%를 기록했다. 이 과제에서 성능을 개선할 여지가 컸다는 근거지만, 점수만으로 실패 원인을 문법 이해 부족이나 상태 관리 오류 등으로 나눌 수는 없다. 이 글은 모델의 개선된 학습법을 상세히 설명하는 논문도 아니다.

유용한 코딩 도구인지는 성적과 비용을 함께 보아야 한다. 더 많은 계산을 쓰면 해결하는 기능이 늘 수도 있지만, 그 비용이 업무에서 얻는 이득과 맞아야 하기 때문이다. 이번 평가는 API 비용을 함께 보고하므로 같은 시험에서 모델을 비교할 수 있다. 다만 그 값은 실제 회사 시스템을 전환하는 총비용과 같지 않다.

연구방법을 단계별로

연구진은 두 가지 보완적인 평가를 설계했다. 첫 번째는 MultiLangBench로, 모델이 지정된 언어로 SQLite 호환 데이터베이스 엔진을 처음부터 구현하도록 요구한다. 모델은 코드베이스를 조직하고, 상태를 관리하고, 오류를 처리하고, 기존 기능을 유지하면서 새 기능을 추가해야 한다. 언어 간 비교를 위해 데이터베이스 파일을 공통 인터페이스로 사용한다. 후보 프로그램이 초기 데이터베이스와 SQL 쿼리를 받아 수정된 데이터베이스를 만들면, 참조 SQLite 구현으로 결과 데이터베이스의 내용이 기대와 같은지 확인한다.

공개 README의 대상은 SQLite 3.40.1이다. 원래 TCL 테스트 약 51k개 중 약 24k개를 initial_database, user_query, validation_query 세 부분으로 변환했다. 실행 지침은 비용을 고려해 해시 접두사가 00, 01, 02인 272개를 기본으로 사용하고, 고득점 표본에서 전체 테스트를 쓰면 그 사실을 밝히도록 한다. 모델에게 문서는 주지만 인터넷과 기존 SQLite 구현의 사용은 제한한다. 대상 언어 위반이나 혼합 언어, 크래시, 60초 타임아웃도 실패로 센다.

두 번째 평가는 COBOL 코드베이스 이전이다. 모델이 COBOL 프로그램을 C++, Java, Kotlin, Python, Rust 중 하나로 옮기면서 각 프로그램이 하는 일을 보존해야 한다. 성공적인 이전을 위해서는 프로그램의 비즈니스 로직과 COBOL 특유의 언어 동작을 모두 이해해야 한다. 예를 들어 COBOL의 고정소수점 산술은 명시적으로 반올림을 요청하지 않으면 초과 소수 자릿수를 버린다. 반올림하도록 다시 작성하면 오류 없이 실행되면서도 다른 재무 결과를 낼 수 있다.

COBOL 이식에서는 관찰 가능한 출력의 바이트 단위 동일성을 요구하는 숨겨진 테스트를 쓴다. 해당 프로그램의 모든 테스트가 통과해야 이식 성공으로 센다. 일부 기능만 맞으면 부분 점수를 얻을 수 있는 MultiLangBench와는 성공을 세는 단위가 다르다. 이 숨긴 시험에도 SQLite 평가의 인터넷 제한이나 타임아웃이 동일하게 적용됐다고 원문은 설명하지 않는다.

결과와 숫자의 의미

MultiLangBench에서 최대 추론 노력 조건의 GPT-6 Astra는 20개 언어 평균 테스트 통과율 87.4%를 기록했다. 이는 GPT-5.6 Sol의 26.8%보다 60.6%포인트 높은 수치다. 개선은 테스트한 모든 언어에서 나타났다. COBOL은 10.9%에서 72.1%로, OCaml은 25.6%에서 85.8%로, Fortran은 21.4%에서 83.5%로, Visual Basic은 27.5%에서 89.4%로 올랐다. Astra는 20개 언어 중 19개에서 83%를 넘었고, COBOL이 72%로 가장 어려웠다.

GPT-6 Luna는 최대 추론 노력에서 평균 테스트 통과율 40.3%를 기록했다. 같은 GPT-5.6 Sol 기준과 비교해 COBOL은 10.9%에서 17.1%, OCaml은 25.6%에서 34.1%, Fortran은 21.4%에서 31.4%, Visual Basic은 27.5%에서 41.6%로 올랐다. 샘플당 추정 평균 API 비용은 0.77달러로 Sol의 3.48달러보다 약 78% 낮았다. Astra보다 통과율은 낮고 이전 Sol보다는 높다는 비교이며, 토큰 단가나 실행 속도 개선 수치가 아니다.

COBOL 이전 평가에서 GPT-6.1 Sol은 낮은 추론 노력에서 86.6% 정확도를 기록했다. 같은 설정에서 GPT-5.6 Sol은 5.4%에 그쳤고, 비용은 GPT-6.1 Sol이 61%로 39% 저렴했다. 더 높은 추론 노력에서는 정확도가 97.9%에 도달해 평가가 거의 포화 상태에 이르렀다. 다만 높은 노력 조건의 정확한 명칭, 그 조건의 비용, 표본 수는 원문에서 확인할 수 없다.

구체적인 예시

원문은 COBOL 고정소수점 계산에서 명시적으로 반올림을 요청하지 않으면 초과 자릿수를 버리는 동작을 예로 든다. 이해를 돕는 가상 예시로, 정확한 십진수 금액 10.006을 소수 둘째 자리까지만 남긴다고 생각해 보자. 절삭하면 10.00, 가장 가까운 값으로 반올림하면 10.01이 된다. 실제 평가 문제나 고객 사례가 아니라 차이를 보여 주는 예시다. 컴파일과 실행이 성공해도 금액 처리 규칙이 달라지면 기존 업무 동작을 보존한 것이 아니다.

MultiLangBench는 후보 프로그램이 출력한 답만 믿는 대신 수정된 데이터베이스 파일을 넘겨받는다. 실제 SQLite 3.40.1이 그 파일에 검증 쿼리를 실행해 기대 출력 문자열과 대조한다. 이렇게 검사하는 쪽과 모델이 만드는 구현을 분리하면 서로 다른 프로그래밍 언어에 같은 판정 기준을 적용할 수 있다. 어느 언어를 썼는지 확인하는 절차도 별도로 필요하다.

한계와 오해하기 쉬운 점

테스트 통과율은 프로그램 전체의 완전한 정확성이나 실제 서비스의 결함 제거율을 보장하지 않는다. COBOL 이식의 모든 테스트 통과도 준비된 숨긴 시험에서 동작이 같았다는 뜻이며, 모든 입력이나 의존성에서 같다는 증명은 아니다. OpenAI 자체 평가를 모든 저자원 언어나 대규모 실제 저장소에 일반화할 수는 없다.

공개 지침의 272개 기본 시험과 약 24k개 전체 시험은 구분해야 한다. 블로그 성적 각각에 어느 범위를 썼는지, 반복 횟수와 분산, 소요 시간은 본문만으로 확인할 수 없다. COBOL 숨긴 문제 전체와 표본 수도 확보하지 못했다. 독립 재현을 수행한 결과가 아니라 공식 본문 서술과 공개 README를 대조한 설명이다.

원문은 직접 요청에서 접근이 제한되어 웹 읽기로 기사 서술을 확보했다. 동적 차트의 모든 언어 수치를 따로 복원한 것은 아니므로, 여기서는 본문에 적힌 수치만 사용했다. 저장소 문서의 날짜나 커밋 시각을 글의 최초 게시일로 대신하지 않았고, 이 글과 함께 새 논문 PDF가 공개됐다고 표시하지도 않았다.

실제로 어떻게 활용할까

개발자는 공개 MultiLangBench 문서로 시험이 어떤 동작을 검사하는지 먼저 살펴볼 수 있다. 그런 다음 자신의 언어와 작업에 필요한 기능이 평가 범위에 포함되는지 비교하는 데 활용할 수 있다. 블로그는 언어별 결과 공개를 안내하지만, 이번 해설에서 모든 결과의 원시 표나 실행 기록까지 확보한 것은 아니다.

오래된 프로그램을 옮기는 팀에는 기존 동작을 관찰 가능한 테스트로 남기는 관점이 유용하다. 단순히 새 언어로 다시 쓰거나 컴파일에 성공하는 데서 끝내지 않고, 업무 규칙과 시스템 의존성이 유지되는지 확인해야 한다는 뜻이다. 실제 도입에는 전문가 검토와 시스템에 맞춘 시험이 필요하다는 원문의 조건을 그대로 적용해야 한다.