LLM에게 규칙을 지키라고 하지 말고, 규칙을 검사하는 코드를 짜라고 시켜라

• 핵심 주장은 간단명료함: LLM은 결정론적(deterministic)이지 않으니까, 매번 일관되게 지켜야 하는 규칙은 LLM한테 맡기지 말고 결정론적 도구(린트, 테스트, 타입 시스템)를 만들어서 빌드 체인에 넣어라. 그리고 그 도구를 LLM한테 짜라고 시켜라
• 수학 쪽에서 먼저 이 문제를 풀었다는 비유가 깔끔함. 테런스 타오(필즈상 수상자)가 2024년 9월에 LLM을 "그럭저럭 무능하지는 않은 대학원생을 지도하는 것 같다"고 표현했는데, 수학 증명에서 LLM이 그럴듯하지만 미묘하게 틀린 논증을 만들어내는 게 위험하다는 거임
• 수학계의 해법: 2026년 1월, LLM(ChatGPT)으로 증명 개요를 만들고 → Aristotle이라는 도구로 논리적 결함을 잡아서 Lean 증명으로 변환하고 → 다시 ChatGPT로 논문 형식으로 작성하는 방식으로, 에르되시(Paul Erdos)가 제시했던 미해결 문제를 최초로 풀었음. LLM이 만들고, 결정론적 시스템이 검증하는 구조

소프트웨어 개발에서의 결정론

• 배포 스크립트를 비유로 씀: 수동 배포보다 스크립트가 좋은 진짜 이유는 시간 절약이 아니라 신뢰성. 스크립트는 매번 똑같은 결과를 내니까
• LLM은 인간과 프로그램 사이 어딘가에 있음. 지치거나 지루해하지는 않지만, 매번 같은 결과를 내지는 못함. 이건 LLM의 근본 작동 방식(다음 토큰의 확률 분포에서 샘플링)에서 비롯되는 거라 프롬프트를 아무리 잘 써도 해결 안 됨
• "한 번만 하면 되는 일"과 "반복적으로 지켜야 하는 일"을 구분하는 게 핵심 프레임워크임:
  • 한 번: 데이터 마이그레이션, 로그인 화면 만들기, 프레젠테이션 차트 생성 → LLM이 해도 됨
  • 반복: SQL 인젝션 방어, 네이밍 컨벤션, 로그에 스택트레이스 포함, 파일 finally 블록에서 닫기 → LLM이 100% 지킬 거라 믿으면 안 됨

해법: 코드로 코드를 검사하라

• 구체적 방법들을 제시함:
  • 타입 시스템 활용: UserString과 SanitizedString 타입을 분리해서 컴파일러가 강제하게 만들기
  • 커스텀 린트: 네이밍 컨벤션이나 레거시 라이브러리 사용 금지를 자동 검사
  • 코드 스캔 유닛 테스트: 승인된 라이브러리만 사용되는지 코드를 스캔
• 이런 도구를 만드는 것 자체가 "한 번만 하면 되는 일"이라 LLM한테 시키기에 딱 좋다는 게 결론. LLM에게 규칙을 따르라고 하지 말고, 규칙을 검사하는 프로그램을 만들라고 시키고, 그걸 빌드 파이프라인에 넣어라
• 저자 본인은 커밋 전에 모든 코드를 한 줄씩 리뷰한다고 하면서도, 모든 사람이 그러지는 않는다는 걸 인정함. 그래서 더더욱 결정론적 검증 도구가 필요하다는 논지