OpenAI, 저자원 프로그래밍 언어 코딩 성능 연구 공개 COBOL 이전 평가 포함
- OpenAI가 저자원 프로그래밍 언어 코딩 능력을 다룬 연구 글을 2026년 10월 19일 공개함
- 두 번째 평가는 모델에게 COBOL 프로그램을 C++, Java, Kotlin, Python, Rust 중 하나로 옮기면서 원래 동작을 그대로 유지하도록 요구함
- 평가 기준은 번역된 코드가 원본 프로그램이 하는 일을 보존하는지임
Hacker News 의견들
COBOL이 온라인 뱅킹의 40% 넘게 돌아가고 ATM 거래 95%를 떠받친다는데, 이걸 바이브 코딩으로 갈아엎자는 건 좀 무서운 얘기임.
진짜 어려운 건 만드는 게 아니라 유지보수임. 바이브 코딩한 Rust 코드를 남이 유지하겠다는 사람은 만들겠다는 사람보다 100배 적을 거라 봄.
은퇴하는 COBOL 개발자가 점점 사라지는데, 규제 바뀔 때마다 기존 코드 이해하는 데 LLM이 도움 되면 좋겠음. 바이브 코딩된 은행 인프라는 싫지만 COBOL 다루는 LLM은 원함.
Haskell 빠진 거 아쉽다는 말이 많던데, Clojure는 1년 전에 써봤을 때 결과가 꽤 괜찮았음.
OpenAI 내부 테스트가 SQLite를 바이너리 호환성 유지하면서 처음부터 재구현하는 거라니, de/serializer 짜고 테스트 돌리면서 고치는 루프라 어렵긴 해도 말은 됨. 진짜 미친 건 그걸 프로덕션 데이터에 맡기는 거임.
Lingo도 학습 데이터가 거의 없는 언어인데, Shockwave 리버스 엔지니어링 커뮤니티가 몇 년간 파놓은 자료 덕분에 LLM이 잘 다룬다고 함. Habbo Origins 클라이언트도 그 흐름에서 나왔다는 얘기임.
어셈블리가 목록에 없는 게 아쉬움. 나도 C 스타일 타입 붙은 어셈블러 문법을 만들고 있는데 Claude가 이걸 꽤 잘 짠다고 느낌. Dan Luu 평가에선 LLM이 어셈블리에서 약했다고 나왔는데, 컴파일러가 레지스터 배치를 검증해주면 그 문제가 풀릴 것 같음.
저자원이 결국 학습 데이터가 적다는 뜻인 것 같은데, 일반화 능력 덕인지 데이터를 많이 만들어서 그런 건지 구분이 중요함. 사람도 새 언어 처음 잡으면 관용구는 안 맞고 매뉴얼을 자주 뒤짐.