LLM이 편집한 코드가 얼마나 잘 살아남는지 테스트하기 위해 프로그래밍 언어를 만들었습니다

프로그래밍 언어가 LLM의 코드 편집을 위해 설계될 수 있을까요? 저는 Almide라는 정적 타입 (statically typed) 프로그래밍 언어를 만들었습니다. 동기는 단순히 또 다른 범용 언어를 만드는 것이 아니었습니다. 저는 특정한 질문을 탐구하고 싶었습니다: 만약 LLM이 기존 코드를 수정한다면, 그러한 편집이 프로그램을 망가뜨릴 가능성이 낮도록 프로그래밍 언어를 설계할 수 있을까? AI와 프로그래밍에 관한 대부분의 논의는 코드 생성 (code generation)에 집중되어 있습니다: 모델이 처음부터 함수를 작성할 수 있는지, 벤치마크 문제를 해결할 수 있는지, 또는 프롬프트로부터 구현을 생성할 수 있는지에 대해서 말이죠. 하지만 일상적인 소프트웨어 작업에서 많은 코딩은 그린필드 (greenfield, 신규 개발) 생성이 아닙니다. 그것은 수정입니다: 파라미터 추가, 데이터 구조 변경, 파서 업데이트, 엣지 케이스 (edge case) 수정, API 리팩토링, 기존 동작 유지, 테스트가 여전히 통과되도록 하는 것 등 말입니다. 이것이 저를 제가 '수정 생존율 (modification survival rate)'이라고 부르는 지표로 이끌었습니다.

수정 생존율 (Modification survival rate)
아이디어는 간단합니다: LLM이 기존 프로그램을 수정한 후, 그 결과물이 여전히 컴파일되고 기존 테스트를 통과하는가? 이는 결과물이 "맞아 보이는지"를 묻는 것보다 의도적으로 더 엄격합니다. 수정된 프로그램이 실제 코드가 통과해야 하는 기본적인 검사들을 견뎌낼 수 있는지를 묻는 것입니다. Almide를 위해 저는 30개의 코드 수정 작업이 포함된 작은 벤치마크를 구축했습니다. 현재 벤치마크 결과는 다음과 같습니다:

• Claude Sonnet 4.6은 30/30개의 Almide 작업을 통과합니다.
• 동일한 작업 세트를 Rust에서 실행하면 약 58%를 기록합니다.
  이것은 "Almide가 Rust보다 낫다"는 뜻이 아닙니다. Rust는 훨씬 더 성숙하며, 훨씬 더 큰 생태계를 가지고 있고, 더 넓고 어려운 문제들을 해결하고 있습니다. 제가 Rust를 비교 지점으로 사용하는 이유는 Rust가 강력한 컴파일 타임 보장 (compile-time guarantees)을 가진 진지한 정적 타입 시스템 언어이기 때문입니다. 제가 탐구하려는 질문은 더 좁습니다: 언어 설계 선택이 LLM이 생성한 편집 사항이 계속 컴파일되고 테스트를 통과하는 빈도에 측정 가능한 영향을 미칠 수 있는가?

Almide란 무엇인가
Almide는 Rust로 구현된 정적 타입 (statically typed) 언어입니다.

현재 다음과 같은 기능들을 갖추고 있습니다:

• 양방향 타입 추론 (bidirectional type inference)
• 완전성 검사를 포함한 패턴 매칭 (pattern matching with exhaustiveness checking)
• 자동 에러 전파를 위한 이펙트 함수 (effect functions for automatic error propagation)
• 파이프라인 연산자 (pipeline operator) 및 UFCS 스타일 호출
• 버전 관리 패키지를 포함한 모듈 시스템 (module system with versioned packages)
• 네이티브 Rust 코드 생성
• 직접적인 WebAssembly (WASM) 코드 생성
• 컴파일러 자체가 WASM으로 실행되는 브라우저 플레이그라운드 (browser playground)

Playground: https://almide.github.io/playground/
Benchmark: https://almide.github.io/almide-dojo/

LLM 편집에 언어 설계가 중요한 이유
LLM은 그럴듯한 코드를 생성하는 데 매우 능숙합니다. 문제는 그럴듯한 코드가 항상 유효한(valid) 코드는 아니라는 점입니다. 모델이 기존 프로그램을 편집할 때, 다음과 같은 여러 가지 작은 방식들로 실패할 수 있습니다:

• 하나의 호출 지점(call site)은 변경했지만 다른 곳은 변경하지 않음
• 잘못된 변체(variant)를 반환함
• 에러 케이스를 누락함
• 소유권(ownership) 또는 가변성(mutation) 규칙을 위반함
• 국소적으로는 올바르게 보이지만 더 이상 주변 프로그램과 일치하지 않는 코드를 생성함
• 컴파일은 되지만 테스트를 통과하지 못하는 편집을 수행함

이러한 실패 중 일부는 모델의 문제입니다. 하지만 일부는 언어 설계의 문제일 수도 있습니다. 언어는 프로그램 구조를 더 쉽게 추론할 수 있게 하고, 일반적인 변경 사항을 국소적(local)으로 만들며, 유효하지 않은 상태를 더 쉽게 거부하고, 의도된 수정을 가리키는 진단(diagnostics)을 제공함으로써 편집이 더 잘 살아남을 수 있도록(survivable) 만들 수 있습니다. 이것이 Almide가 탐구하고 있는 설계 영역입니다.

벤치마크
이 벤치마크는 처음부터 생성하는 방식이 아니라 코드 수정(code modification) 작업에 중점을 두어 구축되었습니다. 각 작업은 모델에게 기존 프로그램을 제공하고 코드를 수정하도록 요청합니다. 그 후 출력 결과는 컴파일과 테스트를 통해 확인됩니다. 점수는 코드가 우아한지, 관용적인지(idiomatic), 또는 사람이 선호하는지에 기반하지 않습니다. 첫 번째 질문은 단지 이것입니다: "편집이 살아남았는가?"

30개의 작업이 적다는 것은 알고 있습니다. 이 벤치마크가 아직 무엇인가를 결정적으로 증명한다고 생각하지는 않습니다. 하지만 초기 결과가 충분히 흥미롭기 때문에, 벤치마크를 공개하고 프로그래밍 언어, 컴파일러, 테스트, 그리고 AI 지원 프로그래밍(AI-assisted programming) 분야에서 일하는 사람들의 피드백을 받고 싶습니다.

피드백을 받고 싶은 부분

저는 특히 벤치마크 방법론 (benchmark methodology)에 대한 피드백에 관심이 많습니다. 예를 들어 다음과 같은 질문들입니다: 어떤 종류의 수정 작업 (modification tasks)이 포함되어야 할까요? 작업 난이도는 어떻게 분류해야 할까요? 언어가 벤치마크에 과적합 (overfitting)되는 것을 어떻게 방지할 수 있을까요? 벤치마크에 다중 파일 편집 (multi-file edits)을 포함해야 할까요? 더 큰 라이브러리나 실제 애플리케이션을 포함해야 할까요? 여러 언어 간에 어떻게 공정하게 비교할 수 있을까요? "컴파일 및 테스트 통과"만으로 충분할까요, 아니면 또 다른 단계의 의미론적 검사 (semantic checking)가 필요할까요?

또한 언어 설계 (language-design)에 대한 피드백에도 관심이 있습니다. 만약 LLM 지원 수정 (LLM-assisted modification)이 일반적인 프로그래밍 워크플로 (programming workflow)가 된다면, 언어는 무엇을 최적화해야 할까요? 단순히 인간이 처음부터 코드를 작성하는 것뿐만 아니라, 인간과 기계가 기존 코드를 함께 반복적으로 변경하는 상황을 위해서 말입니다. 이것이 바로 Almide가 탐구하고자 하는 질문입니다.