Program-as-Weights(2607.02512) 논문을 읽으며 내 파이프라인의 결정 하나가 떠올랐다. link_corrector.py 같은 스크립트에서 “이 링크가 깨진 건지” 판단하는 로직을 짤 때마다 나는 두 선택지 사이에서 고민한다 — 규칙(정규식·휴리스틱)으로 짤 것인가, LLM 호출로 위임할 것인가. 이 논문은 세 번째 선택지를 제시한다: 규칙으로 짜기엔 애매하고(fuzzy) LLM 호출로는 비싸고 비결정적인 로직을, “학습된 가중치를 가진 함수”로 컴파일해버리는 것이다.
이건 하네스 엔지니어링이 놓치고 있던 축이다. 20260605-harness-engineering은 LLM 주위에 검증·관측 레이어를 두르는 것에 집중하는데, Program-as-Weights는 애초에 LLM 호출 자체를 없애고 그 자리에 지역적으로 실행되는 파라미터화된 함수를 심는다. 하네스가 “LLM을 통제하는 레이어”라면, 이건 “LLM을 함수로 응고시키는” 접근이다.
내 판단 기준이 바뀐다. 로직이 fuzzy하다고 곧장 LLM 호출로 가지 않고, “이걸 한 번 학습해서 가중치로 굳힐 수 있는가”를 먼저 물어야 한다. 매 실행마다 API를 왕복하는 건 재현성과 비용 양쪽에서 이미 지고 시작하는 선택이다.
근거
규칙 기반으로 구현하기 어려운 프로그래밍 태스크(로그 필터링, JSON 수리, 의도 기반 검색)를 LLM API에 외주화하는 대신, “fuzzy function”으로 컴파일하는 새로운 프로그래밍 패러다임 제안.
연결된 생각
- 20260605-harness-engineering — 대조: 통제 레이어를 두르는 접근 vs LLM 호출 자체를 없애는 접근
- 20260707-program-as-weights-fuzzy-function — 이 통찰의 개념적 근거