AI가 코볼을 자바로 옮겼습니다. 30년 묵은 버그까지 그대로요

전 세계 금융권과 정부 시스템에는 아직도 코볼(COBOL)로 짜인 코드가 수십억 줄 남아 있습니다. 문제는 이걸 짠 사람들이 대부분 은퇴했다는 겁니다. 그래서 요즘 “LLM한테 시키면 되지 않나"라는 이야기가 자연스럽게 나옵니다. 그런데 막상 해보니 묘한 일이 벌어집니다. AI가 코드를 옮기면서 원본에 있던 버그까지 아주 성실하게 옮겨왔다는 겁니다.

번역은 성공했는데, 왜 실패인가

먼저 짚고 갈 게 있습니다. 이건 AI가 코드를 못 옮겼다는 이야기가 아닙니다. 오히려 그 반대입니다.

레거시 마이그레이션의 전통적인 성공 기준은 동작 동등성입니다. 같은 입력을 넣으면 같은 출력이 나와야 한다는 거죠. 30년 된 코볼 프로그램과 새로 만든 자바 프로그램이 똑같이 동작하면 성공입니다.

그런데 원본에 버그가 있으면요? 그 버그도 똑같이 재현해야 “동등"입니다. AI는 이 기준을 정확히 맞춥니다. 반올림 처리가 잘못된 계산 로직, 특정 조건에서 발생하는 오버플로, 예외 상황에서 조용히 0을 반환하는 분기. 전부 그대로 자바로 옮겨집니다. 테스트는 통과합니다. 원본과 똑같이 틀리니까요.

왜 이런 일이 벌어지나

LLM은 코드를 “번역"합니다. “이해하고 다시 설계"하는 게 아니라요. 이 차이가 핵심입니다.

사람 개발자가 코볼 코드를 읽다가 이상한 부분을 만나면 어떻게 할까요. 멈춥니다. 그리고 물어보죠. “이거 왜 이렇게 되어 있죠?” 답은 대개 셋 중 하나입니다. 버그이거나, 아무도 모르는 옛날 규정이거나, 특정 고객사 때문에 만든 예외 처리이거나.

LLM은 그 질문을 하지 않습니다. 눈앞의 코드를 목표 언어로 옮기는 게 임무니까요. 게다가 코볼 코드에는 주석이 거의 없고, 있어도 1990년대에 퇴사한 누군가가 남긴 두 줄짜리 메모입니다. 맥락이 없으면 판단할 근거도 없습니다.

더 곤란한 건 따로 있습니다. AI가 옮긴 자바 코드는 겉보기에 아주 깔끔합니다. 현대적인 문법, 적절한 클래스 분리, 읽기 좋은 네이밍. 그래서 코드 리뷰에서 잡히지 않습니다. 코볼 시절엔 “이 부분 뭔가 이상한데"라고 느낄 수 있던 냄새가 번역 과정에서 세련되게 포장돼 사라집니다.

‘버그’와 ‘스펙’을 구분할 수 있는 사람이 없다

진짜 함정은 여기입니다. 원본 코드의 이상한 동작이 버그인지 의도된 스펙인지 판단할 사람이 조직에 남아 있느냐.

금융권에는 유명한 사례가 있습니다. 이자 계산에서 특정 자릿수를 버리는 로직이 있는데 알고 보니 1980년대 규제 요구사항이었던 경우. 반대로 명백한 오류인데 하위 시스템 세 곳이 그 오류를 전제로 만들어져 있어서 고치면 더 큰 문제가 생기는 경우도 있고요.

이 둘을 구분하려면 코드가 아니라 업무 지식이 필요합니다. AI는 코드만 봅니다. 솔직히 말하면 마이그레이션을 발주한 조직도 상당수는 그 업무 지식을 잃어버렸습니다. 애초에 그래서 코볼을 못 걷어내고 있었던 거니까요.

그래서 이런 그림이 나옵니다. 아무도 이해하지 못하는 코볼 코드가, 아무도 이해하지 못하는 자바 코드로 바뀝니다. 언어만 바뀌고 문제는 그대로 남습니다.

그럼 어떻게 해야 하나

이 문제를 아는 팀이 시도하는 방법이 몇 가지 있습니다.

차이를 없애지 말고 기록하기. 마이그레이션 도구가 “이 부분은 의심스럽다"고 표시하게 만드는 방식입니다. AI에게 번역만 시키지 말고 “이상해 보이는 로직 목록"을 별도로 뽑게 하는 거죠. LLM은 코드를 고치는 것보다 이상한 부분을 지적하는 걸 훨씬 잘합니다.

실제 운영 데이터로 대조 실행. 코볼 원본과 자바 결과물에 같은 데이터를 넣고 몇 달간 병렬로 돌리는 방법입니다. 여기서 결과가 갈리는 지점이 나오면 그게 검토 대상입니다. 다만 결과가 같으면 아무것도 못 잡습니다. 앞서 말한 “충실하게 번역된 버그"는 여기서도 안 걸립니다.

번역이 아니라 재작성. 스펙을 문서로 복원한 다음 그 문서를 기준으로 새로 만드는 방식입니다. 가장 확실하지만 가장 비쌉니다. 스펙 복원 자체가 원래 어려운 일이라 결국 원점으로 돌아오고요.

현실적으로는 첫 번째와 두 번째를 섞는 게 대부분입니다. AI에게 번역을 시키되 산출물을 완성품이 아니라 검토용 초안으로 다루는 겁니다.

이건 코볼만의 이야기가 아닙니다

한 걸음 물러나서 보면 이 문제는 언어와 상관없습니다.

파이썬2를 파이썬3로 옮길 때, 앵귤러JS를 리액트로 옮길 때, 온프레미스를 클라우드로 옮길 때. 전부 같은 구조입니다. AI는 지금 있는 것을 잘 옮깁니다. 지금 있는 게 옳은지는 판단하지 않습니다.

마이그레이션의 병목은 이제 “옮기는 작업"이 아닙니다. 그 부분은 AI가 상당히 잘하게 됐습니다. 병목은 무엇을 옮기지 말아야 하는지 결정하는 일로 넘어갔습니다. 이 판단은 코드를 읽어서 나오지 않고요.

마무리

AI 코드 마이그레이션의 성능 지표는 대체로 “원본과 얼마나 똑같이 동작하는가"입니다. 그런데 원본이 틀렸다면 이 지표는 높을수록 나쁩니다.

여러분 조직의 레거시 시스템을 떠올려 보세요. 그 안의 이상한 동작 하나를 짚었을 때 “그건 이래서 그런 겁니다"라고 답해줄 사람이 아직 남아 있나요? 그 답이 “아니오"라면 마이그레이션에서 먼저 손봐야 할 건 도구가 아닙니다.