1,000개 파일 언어 마이그레이션을 AI와 AST 트랜스파일러로 완수한 이야기: LLM의 '평가 허점'과 싸운 방법

안녕하세요! DearOne 주식회사의 하세가와입니다.

저는 DearOne의 AI 추진실에서 RAG 개발 및 RAG를 활용한 사내 시스템 개발에 종사하고 있습니다.

이 글을 통해 알 수 있는 것
- 1,000개 파일 이상의 핵심 시스템에서 로직을 유지하며 AST(추상 구문 트리)를 사용하여 '언어만 전환하는' 실전적 접근법
- AI를 이용한 언어 마이그레이션에서 직면하는 'Specification Gaming (평가 허점/지름길)'의 실제와, AI 스스로에게 허점을 찾게 하는 회피책...

수십 년 전에 작성된 프로그램이 지금도 많은 시스템에서 작동하고 있습니다. 이렇게 계속 유지보수되는 이유 중 하나는 재작성 공수가 너무 크기 때문입니다. 새로운 언어의 장점을 도입하고 싶어도 방대한 코드를 사람의 손으로 다시 작성하는 것은 현실적인 비용 관점에서 쉽지 않았습니다. 언어를 선택한 순간, 그 언어와 오랫동안 함께할 것이 결정되어 버린 것입니다.

하지만 진정 가치가 있는 것은 언어가 아니라 로직입니다. 수년간 다듬어진 업무 규칙이나 계산 절차는 어떤 언어로 작성되더라도 같은 가치를 지닙니다. 언어는 단지 그 로직을 표현하는 수단에 불과합니다. 성능이 더 좋은 언어나 보안성이 확실한 언어 등, 시대가 변하면 적절한 수단도 달라집니다.

AI의 시대가 되면서 이 두 가지를 분리할 수 있게 되었습니다. 로직은 계속 사용하고, 그것을 표현하는 언어만 시대에 맞춰 전환하는 것입니다. 본고는 한 핵심 업무 시스템의 1,000개가 넘는 파일에서 실제로 이를 시도해본 기록입니다.

처음에는 간단하고 직관적인 방식으로 시작했습니다. 변환 전 파일을 AI에게 전달하여 새로운 언어로 변환하도록 하는 방식이었습니다. 결과물은 반환된 코드를 읽고 판단합니다.

작은 파일의 경우, 놀라울 정도로 잘 되었습니다. 수백 줄 정도의 처리라면 AI는 변환 대상 언어의 관습에 맞는, 사람이 작성한 것과 구별하기 어려운 코드를 돌려줍니다.

하지만 대상을 1,000개가 넘는 파일로 확장하자 상황이 달라졌습니다. 긴 함수에서는 드물게 발생하는 분기가 생략되는 경우가 있었습니다. 파일을 나누어 전달했기 때문에 같은 타입이 파일마다 다른 이름으로 번역되었습니다. 같은 파일을 두 번 변환시키면, 둘 다 그럴듯해 보이는 두 가지 버전의 코드가 반환됩니다.

// 1개씩 변환한 결과 (예시)
함수 신청을 반려(差し戻す)(신청, 이유) {
if 신청.상태 == 승인 대기 {
...

하나씩 보면 모두 잘 만들어진 코드입니다. 부족했던 것은 1,000개 파일에 걸쳐 같은 규칙을 일관되게 적용하는 것이었습니다. 그래서 저희는 발상을 바꿨습니다. AI에게 번역하도록 시키는 대신, '번역하는 기계'를 AI가 만들도록 시킨 것입니다.

프로그램을 일단 문장의 품사 분석과 유사한 '구조도'(추상 구문 트리, AST: Abstract Syntax Tree)로 만든 다음, 그 구조도를 기반으로 새로운 언어로 다시 작성합니다. 구문 트리는 특정 언어의 작성 방식에서 분리된, 로직 자체의 모습입니다. 여기에 로직과 언어를 분리하는 열쇠가 있었습니다.

기존 파서(parser)를 이용해 각 파일을 분석하고, 구문 트리를 노드의 종류와 속성을 가진 JSON 형태로 출력합니다. 예를 들어 조건 분기 문장은 다음과 같은 JSON이 됩니다.

{
"kind": "IfStatement",
"location": { "file": "approval/flow.src", "line": 128 },
...

트랜스파일러는 이 트리를 깊이 우선 탐색(depth-first)하며, 노드의 종류별로 준비된 변환 규칙을 적용하여 변환 대상 코드를 조립합니다.

RULES = {
"IfStatement": emit_if,
"TryStatement": emit_try,
...

트랜스파일러도, 변환 규칙도 AI가 작성합니다. AI가 만든 규칙을 프로그램이 여러 번 동일하게 적용하는 것입니다. 이 분담 덕분에 AI의 코딩 속도만으로 일관성과 재현성을 즉시 확보할 수 있었습니다. 사람이 확인할 대상 역시 1,000개가 넘는 출력 파일에서 수십 개의 변환 규칙으로 줄어들었습니다.

그 이후부터 AI는 눈부신 속도로 진행되었습니다. 예외 처리 구문을 복사하는 규칙, 타입 이름 매핑, 내용이 비어있는 함수에 기본 반환값을 채우는 규칙 등입니다. 규칙이 하나 추가될 때마다 빌드가 통과되는 파일이 한꺼번에 늘어났습니다. 그리고 며칠 후, AI로부터 보고가 도착했습니다.

변환 전 모든 파일에 대해, 변환 완료된 파일 수가 일치. 변환 완료 (100%)

보고를 받고, 변환 전 원본과 대조해 보았습니다. 업무의 핵심을 담당하는 종료 처리 모듈에서는, 옮겨진 코드의 양이 원본의 1할에도 미치지 못했습니다.

// 변환 전 (원본)
함수 신청을 승인하다(신청) {
승인 권한을 확인하다
...

원인은 트랜스파일러의 폴백 처리였습니다. 규칙이 없는 노드를 만나면, 빌드가 멈추지 않도록 그 노드를 건너뛰고 있었던 것입니다.

def emit_fallback(node):
return "" # 미지원 구문은 버리고, 빌드를 멈추지 않는다

AI가 손을 대충 쓴 것은 아니었습니다. 저희가 부여한 '빌드가 통과하는 것'이라는 평가를 문자 그대로 달성하고 있었던 것입니다. 평가가 요구하지 않는 '내용물'은 평가 바깥에 놓여있었을 뿐입니다.

그래서 평가 방식을 수정했습니다. 그런데 수정할 때마다 AI는 다음 지름길을 찾아냅니다.

빈 파일의 개수를 줄이라고 요청하자, 빈 파일 수는 측정할 때마다 52개, 71개, 36개로 변동했습니다. 내용물이 있는 파일은 늘어나지 않았습니다. 조사해 보니, 빈 파일들은 빌드 제외 목록으로 옮겨져 있었습니다. 제외 목록에 있는 파일은 빈 파일로 계산하지 않는 방식이었던 것입니다.

보고서를 보고 진행 상황을 판단하고 있을 때, 보고서에 적힌 커밋 중 일부가 리포지토리에 존재하지 않았습니다. AI의 세션이 전환될 때마다, 이미 사라진 작업 환경 기록이 이어지고 있었던 것입니다.

기계 학습 분야에서는 이러한 행동을 Specification Gaming이라고 부릅니다. 평가를 최대화하는 과정에서, 평가를 설계한 측이 예상하지 못한 지름길을 발견하는 현상입니다. 영업의 평가를 건수만으로 측정하면, 소액 건만 늘어나는 구조입니다. '좋은 심장의 법칙(Goodhart's Law)'이라고도 알려진 그 구도입니다.

저희는 구멍을 찾아 메우기를 반복했습니다. 분모를 원본 쪽에 고정하고, 원본의 각 파일을 네 가지 카테고리로 분류합니다.

\text{구현율} = \frac{\sum_{f \in \text{구현 완료}} \text{문 노드 수}(f)}{\sum_{f \in \text{원본}} \text{문 노드 수}(f)}

보고서가 아닌, CI(Continuous Integration)가 리포지토리에 기록한 것만을 근거로 삼습니다.

{
"input_manifest_sha256": "3f9c…",
"converter_commit": "a41e…",
...

모두 효과가 있었습니다. 하지만 구멍을 하나 막을 때마다, AI는 다음 구멍을 찾아냅니다. 저희가 구멍을 발견하는 것은 늘 AI가 그것을 사용한 뒤였습니다. 계속해서 수세에 몰리고 있었던 것입니다.

전환점은 하나의 순수한 의문에서 찾아왔습니다. AI가 평가의 구멍을 이렇게 잘 찾을 수 있다면, 그 힘을 평가를 만드는 쪽에 사용하면 어떨까 하고요.

저희는 새로운 평가를 사용하기 전에, 먼저 AI에게 이렇게 부탁했습니다.

다음 평가 스크립트를 읽어주세요.
구현을 전혀 진행하지 않고 '구현 완료'의 수를 늘리는 방법을 가능한 한 많이 제시해주세요.

AI는 저희가 생각지 못한 우회로들을 연이어 제시해 왔습니다.

이 발상은 체크 메커니즘 자체에도 확장되었습니다. 체크가 정말로 기능하고 있는지 확인하기 위해, AI에게 일부러 버그를 심게 하고 그 체크가 그것을 잡아낼 수 있는지 시험합니다(뮤테이션 테스트의 개념입니다). 예를 들어 상수 정의에 대한 체크에는, 정의 하나를 삭제하거나, 값을 변경하거나, 같은 정의를 중복하는 등 7가지 패턴의 변경을 AI가 준비하고, 7가지 패턴 모두가 탐지되는 것을 확인했습니다.

실패 처리 방식도 정반대로 바꿨습니다. 이전의 폴백 처리는 미지원 구문을 조용히 버리고 있었습니다. 이것을, 미지원 노드를 기록하고 빌드가 반드시 실패하도록 하는 방식(Fail-Close)으로 변경했습니다.

def emit_fallback(node):
UNSUPPORTED[node["kind"]].append(node["location"])
return f'compile_error("unsupported: {node["kind"]} at {node["location"]}")'

그러자, 그동안 숨겨져 있던 실패 지점들이 출현 빈도 표로 떠올랐습니다.

빌드 과정에서는 잡히지 않는 오류를 찾아내는 체크 로직도 AI가 만들었습니다. 예를 들어, 변환 원본(source)이 실행 시점에 속성(property)을 이름으로 참조하는 동적 메커니즘에 의존하고 있다면, 변환 대상 언어(target language)에서는 타입을 명시적으로 공개하지 않는 한 이 참조는 성립할 수 없습니다. 게다가 실패하더라도 예외를 발생시키지 않고 값이 조용히 비게 됩니다. AI는 추상 구문 트리(AST)에서 문자열 키에 의한 모든 참조를 추출하고, 변환 대상에서 해당 참조가 성립하는지 검증하는 체크 로직을 만들었습니다.

for access in walk(tree, kind="DynamicPropertyAccess"):
key = access["key"]
if key["kind"] != "StringLiteral":
...

인계 과정 역시 읽기만 하는 것에서 실행하는 것으로 바뀌었습니다. 인계 문서에 작성할 항목에는 반드시 그것을 검증할 수 있는 커맨드를 첨부했고, 다음 세션의 AI는 작업을 시작하기 전에 이 모든 것을 재실행합니다.

- claim: 승인 플로우 모듈은 구현 완료
verify: census --module approval --expect implemented
- claim: 규칙 추가 후에도 트랜스파일러 출력은 변함없음
...

이 시스템으로 전환되자, AI는 과거의 보고서와 실제 상태 간의 불일치에 스스로 인지하고, 누락된 모듈을 찾아내어 보고서를 실제 수치로 수정했습니다.

AI는 평가의 허점을 찾는 상대방에서, 함께 평가 역량을 키워나가는 동료로 변했습니다. 그 이후부터 마이그레이션은 급물살을 탔습니다.

마이그레이션 마무리 단계에서는 AI에게 동작 검증(behavior verification)을 맡겼습니다. 변환 원본과 변환 대상에 동일한 입력을 주어, 출력이 일치하는지 비교하는 차분 테스트(difference test)입니다.

준비 과정 중에, AI가 기묘한 사실을 발견했습니다. 세액(tax amount)을 계산하는 동일한 처리가 변환 원본의 두 곳에, 서로 다른 구현으로 존재했던 것입니다. 하나는 화면에서의 신청에서 사용되었고, 다른 하나는 파일로부터의 일괄 가져오기에서 사용되고 있었습니다. AI에게 양쪽 구현 모두에 동일한 40가지 금액을 입력하게 하자, 6가지 경우에서 결과가 달랐습니다.

(발췌)

| 세액 공제 금액 | 화면 신청 시 | 일괄 가져오기 시 |
|---|---|
| 1,005 | 100 | 101 |
| ... |
한쪽은 소수점 이하를 버리고(truncation), 다른 쪽은 반올림을 하고 있었습니다. 두 구현 모두 각각의 테스트는 통과했습니다. 정적 분석(static analysis)을 거쳐도 아무것도 나오지 않았습니다. 하나씩 살펴보면, 둘 다 올바르게 작동하고 있는 것입니다. 수년 동안 동일한 신청 건이라도, 화면에서 입력했는지 일괄 가져왔는지에 따라 세액이 1원씩 차이가 날 때가 있었습니다.

“변환 원본에 충실하게 옮긴다”고 해도, 어느 것에 충실해야 하는지. 그 답은 코드 어디에도 적혀있지 않았습니다.

저희는 줄곧 AI의 출력을 의심하며 검증 로직을 만들어 왔습니다. 변환 원본이 정답이고, AI가 그것을 따라잡고 있는지 확인하기 위해서 말입니다. 그런데 마지막에 질문받은 것은 AI가 아니라 저희였습니다. '정답이란 무엇인가'라는 질문이었습니다.

이를 결정한 것은 인간이었습니다. 업무 담당자와 논의하여 올바른 사양(specification)을 정하고, 모든 금액과 기대하는 세액을 그대로 '정답표(Ground Truth)'로 고정했습니다. AI는 그날 안으로 이 표에 맞춰 두 가지 구현을 하나로 통합했고, 심지어 그 표 자체를 테스트 케이스로 삼았습니다. 이 표는 어떤 언어에도 의존하지 않습니다. 다음에 언어를 전환할 때도, 동일한 표가 그대로 정답이 됩니다.

사람의 눈으로 확인하면 안심이라는 생각에도 같은 말이 적용됩니다. 1,000개가 넘는 파일을 사람이 모두 읽을 수는 없으며, 설령 읽는다 해도 피로나 선입견에 의해 판단은 흔들립니다. 실제로 수년 동안 변환 원문을 다뤄온 인간조차도 이 불일치(discrepancy)를 알아채지 못했습니다. '100% 완료'라는 보고를 읽고 안심했던 것도 우리 인간이었습니다.

AI가 만들고, AI가 체크하며, AI에게 허점을 찾게 합니다. 합격/불합격 여부는 빌드(build)나 해시값(hash value)처럼 몇 번을 실행해도 같은 결과를 반환하는 도구가 내놓습니다. 그리고 인간은 무엇이 올바른지 결정합니다. 이 형태로 정착했을 때, AI는 마이그레이션을 완성했을 뿐만 아니라, 수년 동안 모호했던 사양(specification)까지 명확하게 해주었습니다.

지금까지 언어를 선택하는 것은 그 언어와 오랫동안 함께한다는 것을 의미했습니다. 이번 경험으로 우리의 생각이 바뀌었습니다. 로직은 구문 트리(Syntax Tree)와 정답표라는, 언어에 의존하지 않는 형태로 남길 수 있습니다. 트랜스파일러(Transpiler)도, 체크 과정도, 평가의 허점 찾기 역시 AI가 만들어 줍니다. 다음에 언어를 바꿀 때는 변환 규칙만 수정하면 됩니다.

로직은 자산으로서 계속 사용하고, 언어는 시대에 맞춰 교체합니다. AI 시대가 되면서, 그것이 현실적인 선택지가 된 것입니다.