기술 요약: 생성적 컴파일 (Generative Compilation)

문제 정의

대규모 언어 모델(LLM)은 코드 생성의 표준 도구가 되었으나, 이들이 생성하는 코드는 특히 Rust와 같이 풍부한 정적 의미론을 가진 언어에서 종종 오류가 발생하기 쉽다. Rust의 소유권 및 대여(ownership and borrowing) 규칙은 강력한 메모리 안전성을 보장하지만, 이러한 엄격한 컴파일 타임 규칙은 유효한 코드 생성을 어렵게 만든다.

이러한 격차를 해결하기 위한 기존 전략들은 다음과 같은 상당한 한계를 지닌다:

1. 사후 생성 컴파일러 피드백 (Post-Generation Compiler Feedback): 표준적인 접근 방식은 전체 프로그램이 생성될 때까지 기다린 후, 컴파일러를 실행하고 진단 결과를 모델에 다시 전달한다. 이는 "지연된 피드백" 루프를 유발한다. 생성 초기에 발생한 오류는 눈덩이처럼 불어나, 모델이 수정을 받기 전까지 유효하지 않은 가정 위에 무의미한 토큰을 낭비하게 만든다. 또한, 파일 전체에 걸친 누적된 진단 결과는 모델이 근본 원인에 집중하는 것을 방해할 수 있다.
2. 제약된 디코딩 (Constrained Decoding): 이 방식은 토큰 샘플링 중에 개입하여 유효한 프로그램을 만들 수 없는 토큰을 거부한다. 이는 모델의 분포에 대한 화이트박스(white-box) 접근 권한을 요구하며(프런티어 블랙박스 API 사용을 제한함), 컴파일러의 의미론적 분석(예: Rust의 borrow checker 재구현)을 언어별로 비용스럽게 재구현해야 한다. 표현력이 풍부한 언어의 경우 이는 흔히 비현실적이다.

방법론: 생성적 컴파일

저자들은 오프더셸프(off-the-shelf) 컴파일러가 생성 도중에 부분 프로그램을 검사할 수 있게 하여, 모델의 샘플링 과정을 수정하지 않고도 컴파일러 스타일의 진단을 제공하는 프레임워크인 **생성적 컴파일(Generative Compilation)**을 소개한다.

핵심 개념: 실러 (The Sealor)

중심적인 기술적 장치는 **실러(sealor)**로, 이는 부분 프로그램(코드의 접두사)을 표준 컴파일러가 진단할 수 있는 완전하고 잘 형성된 프로그램으로 변환하는 가볍고 주로 구문 유도적인 변환 $S$이다.

• 메커니즘: 실러는 누락된 구문 구조를 채우고, 잘 타입화된 플레이스홀더(예: 값에 대한 holeval(), 발산하는 제어 흐름에 대한 holediv())를 삽착하여 부분 프로그램을 닫는다.
• 피드백 루프: 봉인된(sealed) 프로그램은 기존 컴파일러(예: rustc)로 전달된다. 만약 컴파일러가 봉인된 프로그램을 거부하면, 생성된 진단 결과는 원래의 부분 프로그램 소스 범위(span)로 매핑되어 LLM에 전달된다. LLM은 이 집중된 피드백을 바탕으로 코드를 수정한다.
• 설계 목표: 실러는 다음 두 가지 속성을 충족하도록 설계되었다:
  • 완전성 (Completeness): 유효한 완성을 허용하는 부분 프로그램을 거부해서는 안 된다(모델을 혼란스럽게 하는 거짓 양성을 방지함).
  • 건전성 (Soundness, 선택적): 실제 막다른 길(dead end)인 부분 프로그램은 거부해야 한다. 표현력이 풍부한 의미론에 대해 전역적 건전성은 결정 불가능하지만, 저자들은 특정 클래스의 프로그램(예: 문장 경계)에 대해 건전성을 목표로 하여 오류를 조기에 포착한다.

정형화 및 구현

1. 페더웨이트 러스트 (Featherweight Rust, FR): 저자들은 먼저 Rust의 소유권과 대여를 포착하는 압축된 계산법인 FR 상에서 이 접근 방식을 정형화한다. 그들은 구문 유도형 실러($S_{FR}$)를 정의하고, 그 완전성과 선택적 건전성에 대한 증명을 제시한다. 이 모든 개발 과정과 증명은 Lean을 통해 기계화되었다.
2. 실제 Rust (Real Rust): 이 방법론은 실제 Rust($S_{RS}$)로 확장된다. 실러는 Rust 특유의 구문, 제어 흐름, 그리고 미래 의존적 오류(예: 나중에 정의될 이름의 미해결 문제)를 처리한다.
   • 플레이스홀더: holediv()(panic!)를 사용하여 발산하는 브랜치를 닫음으로써 borrow-check 오류를 트리거하지 않도록 하며, holeval()(일반 함수 호출)을 사용하여 특정 타입 제약을 부과하지 않고 값을 제공한다.
   • 오류 억제: 완전성을 유지하기 위해, 코드가 불완전하여 발생하지만 향후 생성에 의해 해결될 수 있는 특정 컴파일러 오류(예: "missing trait items")를 억제한다.
   • 투영 (Projection): 봉인된 프로그램으로부터의 진단은 원래의 부분 프로그램 소스 범위로 투영되어, LLM이 관련성 높은 피드백을 받을 수 있도록 한다.

시스템은 LLM과 병렬로 동작하는 동시 모듈로서 작동하며, 부분 코드를 실러/컴파일러로 스트리밍하고, 거부 시 생성을 재시작하며, 블랙박스 모델을 지원하기 위해 평문(plain text)으로만 통신한다.

주요 기여

1. 생성적 컴파일 프레임워크: 표준 컴플러가 생성 중에 부분 프로그램을 검사할 수 있게 하여, 사후 생성 피드백과 제약된 디코딩 사이의 간극을 메우는 새로운 프레임워크.
2. 실러 이론 (Sealor Theory): 실러의 정의와, 그들의 완전성 및 건전성 속성이 유도된 생성적 컴파일러로 격상됨을 보여주는 정식 증명.
3. 기계화된 FR 구현: Featherweight Rust를 위한 구문 유도형 실러의 완전 기계화된 구현(원래의 FR 정형화에 대한 수정 포함).
4. Rust를 위한 최초의 부분 프로그램 검사기: 의미론적 추론을 rustc에 위임하면서 구문, 제어 흐름 및 플레이스홀더를 처리하는 실제 Rust를 위한 실용적 구현.
5. 경험적 평가: 레포지토리 수준의 Rust 작업(C-to-Rust 변환 및 API 적응)에 대해 7개의 프런티어 블랙박스 및 오픈 웨이트 모델을 대상으로 광범 fact적인 평가 수행.

결과

평가는 생성적 컴파일(GC)이 표준 사후 생성 컴파일러 피드백(PC) 및 가공되지 않은 LLM 생성보다 우수함을 입증한다:

• 컴파일러 오류 감소: GC는 컴파일되지 않는 출력 비율을 크게 줄인다. 예를 들어, UpdatedAPI 작업에서 GC는 Claude Opus 4.8의 컴파일 에러를 0.0%로 줄였으며(PC의 6.7% 대비), GPT-5의 경우 3.3%로 줄였다(PC의 13.3% 대비).
• 기능적 정확성 향 향상: GC는 14개의 모델-데이터셋 구성 중 11개에서 가장 높은 기능적 정확도를 달-성했다.
• 조기 오류 탐지: GC는 오류에 훨씬 더 가까운 곳에서 오류를 탐지한다. 오류 보고의 중앙값 지연 시간은 오류의 주요 범위(span)로부터 단 3줄이었으며, 이는 함수 수준 체크(14줄)나 사후 생성 피드백(89줄)과 비교된다.
• 집중된 진단: 생성 중 복구 불가능한 첫 번째 오류에서 중단함으로써, GC는 더 작고 표적화된 오류 보고서(평균 5.5개 진단 vs PC의 13.8개)를 생성하여 오류 연쇄 현상을 방지한다.
• 런타임 효율성: 온더플라이(on-the-fly) 검사 오버헤드에도 불구하고, GC는 많은 피드백 라운드가 필요한 모델의 경우 긴 비컴파일 가능 파일을 생성하는 것을 피함으로써 전체 런타임을 단축했다.

의의 및 주장

본 논문은 생성적 컴파일이 컴파일러를 단순한 사후 점검 도구가 아닌, 생성 중에 활성화되는 프로그래밍의 "일급 시민(first-class citizen)"으로 만드는 단계라고 주장한다.

• 실용성: 제약된 디코딩과 달리, 이는 블랙박스 모델과 함께 작동하며 기존 컴파일러 인프라를 재사용하므로 방대한 의미론적 재구현이 필요하지 않다.
• 효과성: 조기에 집중된 피드백을 제공하여 "눈덩이 효과"를 방지하고, 결과적으로 더 높은 품질의 코드와 빠른 수렴을 이끌어낸다.
• 범용성: 이 개념은 LLM뿐만 아니라 자연어 프롬프트에 의해 제어 가능한 모든 코드 생성 방식에 적용 가능하다.

저자들은 오류 메시지의 정형화에 대해서는 겸허한 태도를 유지하며, 실러의 아티팩트를 경험적으로 억제하고 있으나, 진단이 원래의 부분 프로그램 내의 실제 결함과 일치함을 공식적으로 증명하는 것은 향데 과제로 남겨두었다고 언급했다. 또한, 언어 명세로부터 실러를 자동 구축하는 것을 향후 연구 방향으로 열어두었다.