결정론적 vs 확률론적 코드 생성: Bun의 Vibe-Coded Rust 변환이 경고 신호를 보내는 이유

Noah Hall이 The Tech Enabler에 기고한 글에서 결정론적 코드 생성과 확률론적 코드 생성 사이에 명확한 선을 긋습니다. 그는 Bun이 최근에 백만 줄 규모의 코드베이스를 Zig에서 Rust로 vibe-coded 변환한 사례를 경고 사례로 사용합니다. 그의 핵심 주장은 결정론적 시스템은 일관되고 검토 가능한 결과를 제공하지만, LLM은 불확실성을 도입하여 대규모 코드 리뷰를 불가능하게 만든다는 것입니다.

결정론적 코드 생성

Hall은 검증된 결정론적 도구들을 언급합니다: Python의 2to3(Python 2→3 마이그레이션), 그리고 Elm, PureScript, TypeScript와 같은 언어용 트랜스파일러는 항상 동일한 JavaScript를 생성합니다. 그가 만든 언어 Derw는 JavaScript, TypeScript 또는 영어를 출력하고; Tegan은 JavaScript 또는 Go를 출력하며; Mojie는 JavaScript, Python 또는 영어를 대상으로 합니다. 모두 AST-to-AST 변환에 기반하며, 동일한 입력이 주어지면 항상 동일한 출력을 얻습니다. 일관성이 중요합니다: "버그가 일관적이면 고칠 수 있습니다. 버그가 일관적이지 않으면 수정이 기하급수적으로 어려워집니다."

확률론적 코드 생성

LLM은 실행마다 출력이 달라집니다. 때로는 A, 때로는 B를 생성합니다. Hall은 3년 전에 neuro-lingo를 패러디로 만들었습니다: 인간은 함수 시그니처와 주석만 작성하고, LLM이 컴파일할 때마다 구현을 새로 생성합니다. 예시:

function add(a: number, b: number): number {
  // 두 숫자를 더합니다
}
function main() {
  // 콘솔에 "Hello World"를 출력합니다
  // add(2, 3)의 결과를 출력합니다
}

"neuro-lingo를 컴파일할 때마다 코드가 LLM에 의해 새로 생성됩니다. 매번 조금씩 다릅니다. 때로는 버그를 유발하고, 때로는 깔끔하고 단순하며, 때로는 혼란스럽습니다." Hall은 완전히 AI 기반의 코드 흐름이 바로 이렇게 작동하지만, 인간이 책임져야 할 프로덕션에 배포되고 있다고 주장합니다.

"테스트가 있다"는 오류

테스트만으로는 품질을 보장할 수 없습니다. Hall은 SQLite가 가장 많이 테스트된 코드베이스라고 언급합니다: C 코드 155.8 KSLOC 대비 테스트 코드 92,053.1 KSLOC (590배). 100% 브랜치 커버리지, 수백만 개의 테스트 케이스, 광범위한 테스트 환경에도 불구하고 SQLite는 여전히 인간 검토에 의존합니다. "인간이 9일 동안 100만 줄의 변경사항을 검토하는 것은 불가능합니다. Bun은 마스터에 병합된 코드를 검토하지 않았습니다."

Hall은 결정론적 코드 생성도 여전히 검증이 필요하며, 확률론적 생성은 코드 줄 수에 비례하여 위험을 증가시킨다고 결론짓습니다. 원본 기사는 각 예시를 더 자세히 다룹니다.