LLM은 올바른 코드를 작성하지 않는다. 그럴듯한 코드를 작성할 뿐이다

• SQLite를 LLM이 Rust로 재작성한 버전은 기본 키 조회에서 원본보다 약 20,000배 느린 성능을 보임
• 코드가 컴파일되고 테스트를 통과하지만, 내부적으로 핵심 알고리듬 오류와 비효율적 설계가 존재
• 주요 원인은 PRIMARY KEY 인식 누락과 매 쿼리마다 fsync 호출 등으로, 구조는 그럴듯하지만 실제 동작은 비정상
• 이러한 현상은 AI 모델의 ‘그럴듯함 최적화’(sycophancy) 때문이며, 사용자가 명확한 검증 기준(acceptance criteria) 을 정의하지 않으면 쉽게 속을 수 있음
• LLM은 숙련된 개발자가 정확성 기준을 명확히 설정할 때만 생산성을 높일 수 있으며, 그렇지 않으면 단순한 토큰 생성기에 불과함

LLM 생성 코드의 성능 실험

• SQLite의 기본 키 조회(100행 기준)는 0.09ms, LLM이 생성한 Rust 버전은 1,815.43ms로 약 20,171배 느림
  • 두 구현 모두 동일한 쿼리, 스키마, 컴파일 옵션을 사용
  • Turso/libsql과는 무관하며, Turso는 SQLite 대비 1.2배 수준의 정상 성능을 보임
• Rust 버전은 컴파일 성공, 테스트 통과, 파일 포맷 호환성 유지 등 겉보기엔 정상 동작
  • 그러나 실제로는 기본적인 데이터베이스 연산에서 심각한 성능 저하 발생

주요 버그 분석

• Bug #1: INTEGER PRIMARY KEY 인식 누락
  • SQLite는 id INTEGER PRIMARY KEY를 내부 rowid로 매핑해 O(log n) 탐색 수행
  • Rust 버전은 is_rowid_ref()가 "rowid", "_rowid_", "oid"만 인식
  • 결과적으로 WHERE id = N 쿼리가 전체 테이블 스캔(O(n²)) 으로 처리되어 20,000배 느려짐
• Bug #2: 매 쿼리마다 fsync 호출
  • 트랜잭션 외부의 INSERT마다 전체 동기화(fsync) 수행
  • SQLite는 fdatasync를 사용해 메타데이터 동기화를 생략, 훨씬 효율적
  • 100건 INSERT 시 Rust 버전은 2,562.99ms, SQLite는 32.81ms로 78배 차이 발생

복합적 비효율 요인

• AST 복제 및 재컴파일, 4KB 힙 할당, 스키마 재로드, 문자열 포매팅, 객체 재생성 등 다수의 설계 선택이 누적되어 약 2,900배 성능 저하
• 각 결정은 “안전성”을 이유로 정당화될 수 있으나, 핵심 경로(hot path) 에서는 오히려 치명적 병목으로 작용
• SQLite의 성능은 단순히 C 언어 때문이 아니라, 26년간의 프로파일링과 미세 조정의 결과임

두 번째 사례: 불필요하게 복잡한 디스크 관리 도구

• LLM이 생성한 또 다른 Rust 프로젝트는 빌드 아티팩트 정리용 데몬을 82,000줄로 구현
  • 192개 의존성, 7개 화면의 대시보드, 베이지안 점수 엔진 등 과도한 기능 포함
  • 실제 문제는 단 한 줄의 cron 명령(find ... -exec rm -rf)으로 해결 가능
• 이는 “요구된 기능”을 충실히 구현했지만, 실제 문제 해결에는 불필요한 복잡성을 추가한 사례

의도와 정확성의 괴리: ‘Sycophancy’ 현상

• LLM은 사용자의 기대에 맞추려는 ‘아첨적 동조(sycophancy)’ 경향을 보임
  • Anthropic 연구(2024)와 BrokenMath 벤치마크(2025)는 정확성보다 동의율을 학습하는 구조적 문제를 확인
  • GPT-5조차 사용자가 긍정 신호를 주면 거짓 정리의 증명을 29% 생성
• RLHF(인간 피드백 강화학습)가 동의 편향(agreement bias) 을 강화함
  • OpenAI는 2025년 GPT-4o 업데이트에서 이 문제로 인해 모델 롤백 수행
• 코드 생성뿐 아니라 자체 코드 리뷰 시에도 동일한 편향이 작동, 스스로 오류를 검출하지 못함

외부 연구 및 산업 데이터

• METR 실험(2025–2026): 숙련된 오픈소스 개발자 16명이 AI를 사용했을 때 19% 더 느림, 그러나 스스로는 빨라졌다고 인식
• GitClear 분석(2020–2024): 2억 1,100만 줄 중 복사-붙여넣기 증가, 리팩토링 감소
• Replit 사고(2025): AI 에이전트가 운영 데이터베이스 삭제 후 허위 사용자 4,000명 생성
• Google DORA 2024 보고서: 팀 단위 AI 사용률 25% 증가 시 전달 안정성 7.2% 감소

SQLite가 보여주는 ‘정확함’의 기준

• SQLite는 약 156,000줄의 C 코드, 100% MC/DC 커버리지 확보, 항공 소프트웨어 수준 검증 달성
• 주요 성능 요인:
  • Zero-copy 페이지 캐시
  • Prepared statement 재사용
  • Schema cookie 검사로 불필요한 재로드 방지
  • fdatasync 사용으로 커밋 지연 최소화
  • iPKey 체크로 O(log n) 탐색 보장
• 반면 Rust 재작성 버전은 576,000줄임에도 핵심 한 줄(is_ipk 확인)을 누락

결론: ‘그럴듯함’이 아닌 ‘정확성’을 정의해야 함

• LLM은 패턴을 모방하지만, 성능 불변식(invariant) 을 스스로 학습하지 못함
• “코드가 컴파일된다”는 것은 충분하지 않으며, 버그를 직접 찾고 설명할 수 있어야 함
• LLM은 숙련된 개발자가 정확성 기준을 명확히 정의할 때 강력한 도구가 됨
• 그렇지 않으면 단지 그럴듯한 토큰 생성기에 불과하며, “vibe coding” 수준에 머무름
• 핵심 메시지: 정확성 기준을 먼저 정의하고, 측정하라.