[arXiv 2607.02512] Program-as-Weights: 퍼지 함수를 가중치로 컴파일하는 프로그래밍 패러다임

Program-as-Weights: A Programming Paradigm for Fuzzy Functions

https://arxiv.org/abs/2607.02512

Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, Yuntian Deng | University of Waterloo, Cornell University, Harvard University | arXiv:2607.02512 | 2026년 7월

---

1. 서론: 자연어로 쓰는 함수가 로컬 가중치가 되는 순간

현업 개발에서 자주 만나는 함수 중에는 규칙 기반 코드로 깨끗하게 쓰기 어려운 것들이 있다. 로그 한 줄이 장애 알림으로 올릴 만큼 중요한지 판정하거나, 조금 깨진 JSON을 문맥에 맞게 복구하거나, 사용자의 검색 의도를 보고 후보 문서를 의미 순서로 재정렬하는 일이 그렇다. 입력과 출력의 형식은 단순하지만, 판단 기준은 자연어 설명과 예시, 예외 조건, 암묵적 업무 맥락에 의존한다. 이 논문은 이런 함수를 fuzzy function이라고 부르고, 자연어 명세를 매번 거대 LLM API에 던지는 현재 관행을 근본적으로 바꾸려 한다.

핵심 아이디어는 함수 명세를 프롬프트 문자열로 보관하는 대신, 한 번의 컴파일 과정을 거쳐 작은 신경망 실행 아티팩트로 저장하는 것이다. 저자들이 제안하는 Program-as-Weights, 줄여서 PAW는 자연어 명세를 읽는 4B급 compiler 모델과 동결된 소형 interpreter 모델을 나눈다. 컴파일러는 명세를 해석해 의사 프로그램과 LoRA 어댑터를 만들고, 인터프리터는 그 어댑터를 붙인 상태로 실제 입력을 처리한다. 이때 큰 모델은 compile-time에만 쓰이고, run-time은 로컬의 작은 모델이 담당한다.

논문의 주장 구조는 꽤 분명하다. LLM을 매번 호출하는 방식은 편하지만, 함수가 제품 안에 들어가는 순간 비용, 재현성, 지연, 개인정보, 오프라인 실행 문제가 계속 남는다. 반대로 완전한 규칙 코드는 디버깅하기 쉽지만, 애초에 사람이 명확한 규칙을 쓰기 어려운 fuzzy task에서는 지나치게 취약하다. PAW는 이 둘 사이에서 자연어 명세를 실행 가능한 weight artifact로 바꾸는 중간 지점을 제안한다. 프로그램이 소스 코드나 프롬프트에만 머물지 않고, LoRA나 KV prefix 같은 연속 파라미터로도 배포될 수 있다는 관점이다.

정량 결과도 이 주장을 뒷받침한다. 기본 구성인 Qwen3 0.6B interpreter와 PAW LoRA는 FuzzyBench 검증 테스트에서 73.78% exact match를 기록한다. 같은 계열의 Qwen3-32B를 직접 prompting한 결과가 68.70%인 점을 고려하면, PAW는 훨씬 작은 실행 모델로 더 높은 점수를 얻는다. 논문은 Qwen3 0.6B의 bf16 메모리를 약 1.2GB, Qwen3-32B를 약 60GB로 설명하며, 배포 관점에서 약 50배의 메모리 차이를 강조한다.

Figure 1: Program-as-Weights의 전체 패러다임. 자연어 함수 명세를 클라우드에서 한 번 컴파일하고, 생성된 neural program을 로컬 interpreter가 실행한다.

Figure 1은 이 논문의 문제의식을 가장 직접적으로 보여준다. 상단 흐름은 자연어 명세가 compiler를 지나 neural program으로 저장되는 compile-time 단계를, 하단 흐름은 그 program을 로컬 interpreter에 붙여 입력을 처리하는 run-time 단계를 구분한다. 중요한 점은 큰 모델을 계속 호출하는 구조에서 벗어나, 함수별 가중치 아티팩트가 캐시되고 배포되는 구조라는 것이다. 이 구분이 이후 비용과 재현성 논의의 기준점이 된다.

요소	논문에서의 의미	리뷰 관점의 해석
Fuzzy function	자연어로 설명하기는 쉽지만 규칙 코드로 정확히 쓰기 어려운 함수	로그 분류, 검색 재랭킹, 형식 복구처럼 제품 코드 안에 들어갈 수 있는 작은 판단 함수에 초점을 둔다.
Compiler	명세와 pseudo-program을 읽고 PEFT weight를 생성하는 4B 모델	큰 모델은 실행기 역할보다 함수 생성 도구 역할에 가까워진다.
Interpreter	생성된 어댑터를 붙여 실제 입력을 처리하는 동결 소형 모델	배포 시 비용과 메모리를 결정하는 주체다.
Neural program	pseudo-program과 LoRA 또는 KV prefix로 구성된 실행 아티팩트	프롬프트 파일, 바이너리, 라이브러리처럼 버전 관리 가능한 새로운 프로그램 단위다.

논문이 흥미로운 이유는 단순히 “작은 모델을 잘 쓰자”가 아니다. 여기서는 작은 모델이 범용적으로 모든 작업을 잘해야 한다는 부담을 지지 않는다. 함수별로 컴파일된 어댑터가 작은 모델의 동작 공간을 좁히고, pseudo-program이 입력 앞에서 언어적 맥락을 제공한다. 따라서 PAW의 실행 단위는 하나의 범용 챗봇 호출과 구분되며, 특정한 spec을 중심으로 고정된 로컬 함수 호출에 가깝다. 이 관점은 LLM을 백엔드 API를 넘어 프로그램 생성기와 런타임으로 분리해 보는 방향을 제시한다.

다만 이 결과를 모든 LLM 호출의 대체재로 읽으면 곤란하다. gpt-oss-20B prompting은 FuzzyBench에서 85.45%로 PAW보다 높고, API 모델인 gpt-5.2와 gpt-5-mini는 각각 96.09%, 91.87%에 도달한다. PAW의 강점은 최고 정확도 자체보다 로컬성, 함수별 배포성, 소형 interpreter의 재사용성이다. 즉 제품 코드 안에서 반복적으로 호출되는 작은 fuzzy function을 대량으로 만들고 관리해야 할 때 설계 공간이 달라진다.

2. 배경 및 관련 연구: 프롬프트, 코드 생성, PEFT 사이의 빈칸

2.1 퍼지 함수가 일반 함수와 다른 지점

일반적인 프로그래밍 함수는 입력 타입, 출력 타입, 조건문, 반복문, 예외 처리 규칙을 코드로 명시한다. 그러나 실제 소프트웨어에는 “이 에러 로그가 사람을 깨울 만큼 긴급한가”, “이 사용자의 질문이 문서 검색인지 설정 변경인지”, “이 자연어 요청에서 필요한 tool parameter가 무엇인가”처럼 경계가 흐린 함수가 많다. 이런 함수는 사람이 자연어로는 꽤 잘 설명하지만, 정규식과 if-else만으로 안정적으로 구현하려면 예외가 계속 늘어난다. 논문은 이 영역을 fuzzy function으로 묶고, 자연어 명세를 실행 가능한 프로그램으로 바꾸는 별도 패러다임이 필요하다고 본다.

기존 LLM 활용 방식은 이 문제를 runtime prompting으로 해결한다. 함수 명세와 입력을 함께 넣고, 모델이 매번 판단하게 하는 것이다. 이 방식은 빠르게 프로토타입을 만들기에는 좋다. 하지만 서비스에 들어가면 입력 한 건마다 외부 API 호출이 발생하고, 모델 버전이 바뀔 때 결과가 달라지며, 사내 로그나 사용자 데이터를 외부로 보내야 할 수도 있다. 또한 작은 함수를 위해 큰 모델을 계속 깨우는 구조라서 지연과 비용이 누적된다. PAW는 이 반복 호출을 compile-once, run-local 구조로 바꾸려는 시도다.

다른 대안은 LLM에게 코드를 생성시키는 것이다. 예를 들어 자연어 명세를 Python 함수로 바꾸고, 그 함수를 로컬에서 실행하면 인터넷 연결이나 모델 호출 없이 처리할 수 있다. 그러나 fuzzy task에서는 코드가 명세의 애매함을 충분히 담지 못하는 경우가 많다. 논문이 비교하는 LM-to-code 계열은 FuzzyBench에서 35.81%에 머물며, 특히 자연어 의미 판단이 필요한 과제에서 약하다. 프로그램을 symbolic code로만 제한하면 fuzzy function의 핵심인 부드러운 의미 판별을 잃기 쉽다는 것이 이 논문의 출발점이다.

2.2 PEFT를 프로그램 표현으로 다시 읽기

LoRA, prefix-tuning, adapter tuning 같은 parameter-efficient fine-tuning은 보통 “작은 추가 파라미터로 모델을 특정 태스크에 적응시키는 방법”으로 설명된다. PAW는 이 도구를 조금 다르게 해석한다. 특정 함수가 요구하는 동작을 작은 파라미터 묶음으로 표현할 수 있다면, 그 묶음은 단순한 학습 부산물을 넘어 함수의 실행 본체가 된다. 즉 LoRA는 모델 압축이나 미세조정 기법을 넘어 프로그램 저장 형식이 된다.

이 해석은 LoRA 원 논문과도 자연스럽게 연결된다. LoRA는 큰 가중치 행렬의 변화량을 저랭크 분해로 표현하며, 사전학습 가중치를 대부분 고정한 채 적은 수의 파라미터만 학습한다. PAW에서는 그 저랭크 변화량이 사전에 학습된 고정 태스크 하나에 묶이지 않고, 자연어 spec마다 동적으로 생성된다. 다시 말해 “한 태스크를 위한 LoRA를 학습한다”에서 “함수 명세를 읽고 LoRA를 컴파일한다”로 이동한다. 이 이동이 논문의 가장 중요한 개념적 점프다.

최근의 workflow compilation 연구와도 차이가 있다. FlowCompile 같은 접근은 LLM workflow graph, reasoning budget, 모델 선택, 병렬화 전략을 compile-time 최적화 대상으로 본다. 반면 PAW는 workflow 바깥의 작은 fuzzy function 하나를 weight-level artifact로 만든다. 둘 다 LLM을 프로그래밍 가능한 substrate로 보는 점은 같지만, 하나는 외부 제어 흐름을 컴파일하고 다른 하나는 내부 파라미터 공간에 함수를 새긴다. 이 차이는 실제 도구 체인 설계에서 꽤 중요하다.

비교 축	runtime prompting	LM-to-code	Program-as-Weights
실행 위치	입력마다 큰 모델 또는 API 호출	생성된 symbolic code를 로컬 실행	컴파일된 어댑터를 로컬 interpreter에 붙여 실행
강점	유연하고 구현이 가장 빠름	재현성과 배포성이 좋음	의미 판단 능력과 로컬 실행성을 동시에 추구
약점	비용, 지연, 개인정보, 버전 변동 문제	fuzzy semantic judgment가 코드 규칙으로 굳어짐	compiler-interpreter 결합과 어댑터 불투명성이 남음
프로그램 표현	프롬프트와 모델 상태	소스 코드	pseudo-program + LoRA 또는 KV prefix

논문이 “program”이라는 단어를 쓰는 것도 이런 이유다. PAW program은 사람이 읽을 수 있는 pseudo-program만으로 구성되지 않는다. 실제 성능은 pseudo-program과 continuous PEFT artifact가 함께 만들며, 이 둘을 분리하면 성능이 떨어진다. 그래서 PAW program은 소스 코드처럼 완전히 해석 가능하지도, 일반 fine-tuned checkpoint처럼 완전히 불투명하지도 않은 중간 형태다. 이 중간성 때문에 배포와 디버깅 모두 새로운 질문을 만든다.

3. 방법론: PAW compiler와 interpreter가 함수를 나눠 맡는 방식

3.1 문제 정의와 프로그램 구성

논문은 fuzzy function을 간단히 $f:X o Y$로 둔다. 사용자는 자연어 명세 $s$를 제공하고, 시스템은 입력 $x$에 대해 목표 출력 $y$와 가까운 결과를 내야 한다. PAW의 형식은 $p= exttt{{Compiler}}(s)$, $\hat{{y}}= exttt{{Interpreter}}(p,x)$로 요약할 수 있다. 여기서 $p$는 하나의 문자열로 끝나지 않고 두 부분으로 나뉜다. 첫째는 사람이 읽을 수 있는 discrete pseudo-program이고, 둘째는 interpreter 내부 모듈에 붙는 continuous PEFT component다.

pseudo-program은 자연어 명세를 더 명확하게 재작성한 설명과 대표 입출력 예시를 포함한다. 논문은 Qwen3-4B-Instruct-2507을 pseudo compiler로 사용하며, 이 모델은 별도로 학습하지 않는다. 역할은 명세의 철자 오류, 애매한 표현, 빠진 조건을 최대한 정리해서 interpreter 앞에 붙일 수 있는 짧은 프로그램 설명으로 바꾸는 것이다. 저자들은 예시 스타일 프롬프트에서 3~6개의 representative input-output pair를 포함하고, 예시 부분을 250 토큰 아래로 제한한다.

continuous component는 주 실험에서 LoRA 어댑터다. LoRA compiler도 Qwen3-4B-Instruct-2507에서 시작하지만, 이쪽은 학습된다. 입력은 원래 spec, pseudo-program, EOS 토큰, 그리고 64개의 learned prefix token으로 구성된다. compiler의 여러 layer에서 prefix 위치 hidden state를 뽑고, mapper가 이를 요약해 interpreter 각 모듈에 들어갈 LoRA basis mixture coefficient를 만든다. 이 구조는 자연어 명세에서 직접 수천만 개의 어댑터 파라미터를 생성하는 weight generator로 볼 수 있다.

Figure 2: Text-to-LoRA PAW 구조. LoRA compiler가 spec과 pseudo-program, learned prefix token을 읽고, mapper가 공유 LoRA basis의 계수를 예측해 interpreter에 주입한다.

Figure 2는 PAW의 실제 학습 구조를 보여준다. 왼쪽은 spec과 pseudo-program을 compiler에 넣어 hidden state를 얻는 단계이고, 가운데 mapper는 그 표현을 LoRA basis의 혼합 계수로 바꾼다. 오른쪽 interpreter는 동결되어 있지만, 함수별 LoRA가 attention과 MLP 모듈에 주입되면서 특정 fuzzy function처럼 행동한다. 따라서 PAW의 학습 대상은 interpreter 전체보다 compiler와 mapper 쪽에 집중된다.

3.2 LoRA mapper와 interpreter 실행

LoRA mapper는 논문이 기대한 것보다 단순한 설계가 가장 잘 작동한다. compiler hidden state를 layer와 prefix position 방향으로 mean-pooling하고, shallow residual MLP trunk를 거친 뒤, module type별 shared basis에 대한 mixing coefficient를 예측한다. 대상 모듈은 attention의 q_proj, k_proj, v_proj, o_proj와 MLP의 gate_proj, up_proj, down_proj다. 기본 설정은 rank 64, module type당 shared basis 64개이며, 함수 하나당 약 38.5M LoRA 파라미터가 interpreter에 주입된다.

실행 단계에서는 interpreter가 완전히 동결되어 있다. 사용자가 어떤 입력을 넣으면, 시스템은 해당 함수의 pseudo-program을 입력 앞에 붙이고, 같은 함수의 LoRA를 target module에 hot-attach한 뒤 autoregressive generation을 수행한다. 이때 interpreter는 특정 spec을 새로 학습하지 않는다. 이미 compile된 neural program을 로드해 사용하는 것이다. 논문은 배포된 Qwen3 0.6B용 Q4_0 LoRA adapter가 약 23MB라고 보고한다. 수백 개의 fuzzy function을 저장해도 범용 30B 모델 하나보다 관리하기 쉬운 크기다.

prefix-tuning 버전도 함께 제시된다. 이 초기 instantiation에서는 compiler hidden state가 interpreter 각 layer의 attention cache에 들어갈 key-value prefix로 변환된다. LoRA 버전과 비교하면 구조는 더 직접적이지만, text FuzzyBench에서는 LoRA가 강하다. Table 1의 제어 비교에서 prompting은 0.098, prefix-tuning은 0.504, Text-to-LoRA rank 18은 0.565, rank 64는 0.657을 기록한다. 논문은 이 결과를 바탕으로 본문 주 실험을 LoRA 중심으로 전개한다.

구성 요소	구체 설정	설계상 역할
Pseudo compiler	Qwen3-4B-Instruct-2507, 별도 학습 없음	자연어 spec을 짧고 일관된 pseudo-program과 예시로 정리한다.
LoRA compiler	Qwen3-4B-Instruct-2507에서 시작, 완전 unfrozen 학습	spec과 pseudo-program에서 함수별 hidden representation을 만든다.
Mapper	mean-pool + residual MLP + shared LoRA basis coefficient	compiler 표현을 interpreter 모듈에 들어갈 LoRA 파라미터로 변환한다.
Interpreter	Qwen3 0.6B 기본, 실험 내내 동결	pseudo-program과 LoRA가 붙은 상태로 실제 입력을 처리한다.
Program artifact	pseudo-program + 약 38.5M LoRA parameter	파일로 저장, 버전 관리, 캐시, 로컬 호출이 가능하다.

3.3 학습 목적과 gradient 흐름

학습 목적은 target output의 평균 token negative log-likelihood를 줄이는 것이다. 중요한 점은 interpreter가 동결되어 있어도 gradient가 interpreter의 계산 그래프를 통과해 LoRA 파라미터, mapper, compiler hidden state, compiler weights 쪽으로 흐른다는 것이다. 즉 interpreter는 학습되는 모델 역할 대신 loss를 정의하고 gradient를 전달하는 differentiable execution environment가 된다. 이 설정은 compiler가 “이 spec이면 interpreter 내부에 어떤 작은 변화가 필요할지”를 학습하도록 만든다.

훈련은 상당히 큰 규모다. FuzzyBench의 1,000만 예제를 대상으로 pseudo-program을 먼저 vLLM으로 생성해 spec별로 저장하고, 이후 LoRA compiler와 mapper를 학습한다. 논문은 bf16, learning rate 2e-5, gradient checkpointing, mapper fp32, batch size 16, gradient accumulation 3, effective batch 48, compiler 최대 길이 1280, interpreter 최대 길이 1024를 보고한다. 기본 Qwen3 0.6B 구성은 8×H200 환경에서 3 epoch 학습되며, 3개 GPU 기준 약 72시간이 걸렸다고 서술한다.

이 훈련 방식은 단일 함수를 위해 매번 LoRA를 새로 학습하는 것과 다르다. PAW는 다양한 spec을 본 compiler를 학습해, 새로운 spec이 들어오면 즉시 어댑터를 생성할 수 있게 한다. 따라서 비용 구조는 두 단계로 나뉜다. 한 번은 FuzzyBench 같은 대규모 데이터로 compiler를 학습해야 하지만, 배포 시점에는 새로운 fuzzy function 하나를 컴파일하는 비용만 든다. 이 관점에서 PAW는 “LoRA를 학습하는 서비스”라기보다 LoRA를 생성하는 compiler를 학습하는 방식이다.

3.4 PAW 실행을 알고리즘 단위로 풀어 보기

PAW의 실행을 알고리즘처럼 쓰면 네 단계가 된다. 첫째, 개발자가 자연어 spec을 작성한다. 이 spec은 “긴급 이메일을 즉시 처리, 오늘 안 처리, 보류로 나누라”처럼 사람이 이해하기 쉬운 형태다. 둘째, pseudo compiler가 spec을 다시 쓰고 대표 예시를 붙인다. 이 산출물은 interpreter 앞에 붙을 discrete context가 된다. 셋째, LoRA compiler와 mapper가 같은 spec/pseudo-program에서 function-specific adapter를 만든다. 넷째, 배포 시 interpreter는 pseudo-program과 adapter를 함께 로드한 뒤 실제 입력마다 짧은 출력을 생성한다.

이 네 단계는 일반 prompt engineering과 operational contract가 다르다. prompt engineering에서는 spec이 그대로 runtime 입력의 일부이며, spec을 바꾸면 다음 호출부터 바로 동작이 바뀐다. PAW에서는 spec 변경이 compile artifact 변경으로 이어진다. 따라서 spec diff, compile timestamp, compiler checkpoint, adapter hash, interpreter version을 함께 관리해야 한다. 이 관점에서는 PAW program을 모델 출력보다 build artifact로 보는 편이 자연스럽다. CI에서 binary를 만들고 checksum을 남기는 것처럼, fuzzy function도 compile log와 test log를 가져야 한다.

또한 PAW는 batching 전략도 일반 LLM serving과 다르게 생각하게 만든다. 같은 interpreter를 메모리에 올려 둔 상태에서 서로 다른 LoRA adapter를 hot-swap할 수 있다면, 서비스는 “어떤 모델에 요청을 보낼까”보다 “어떤 program을 어떤 순서로 묶어 실행할까”를 고민한다. adapter 교체 비용, KV cache 재사용 가능성, function별 latency budget, 실패 시 fallback prompting 여부가 운영 변수가 된다. 논문은 이 부분을 깊게 다루지는 않지만, local library 형태의 API를 제시함으로써 이런 runtime scheduler가 필요하다는 단서를 준다.

4. 실험 설정: FuzzyBench와 함수형 평가 프로토콜

4.1 FuzzyBench-10M 구성

논문의 평가 기반은 저자들이 새로 공개한 FuzzyBench다. 데이터는 spec, input, target output의 triples로 구성되며, 총 1,000만 예제를 포함한다. 생성에는 gpt-5.2가 사용된다. 첫 단계에서는 gpt-5.2가 자연어 fuzzy-function spec을 만들고, 두 번째 단계에서는 각 spec에 대해 여러 input-output pair를 생성한다. 논문은 spec 단위로 80/10/10 train/validation/test split을 적용해, 테스트 시에는 학습에서 보지 않은 함수 명세를 평가한다.

검증 테스트셋은 ambiguity를 줄이기 위해 추가 필터링을 거친다. gpt-5.2와 독립적인 strong model인 gpt-5-mini가 같은 target에 동의하는 예제만 남긴다. fuzzy function의 본질상 한 입력에 대해 완전히 유일한 정답이 없을 수 있기 때문이다. 이 필터링은 exact match metric을 쓸 수 있게 해 주지만, 동시에 데이터셋이 synthetic model agreement에 의존한다는 한계도 만든다. 논문은 이 점을 limitations에서 명시적으로 인정한다.

Figure 3: FuzzyBench-10M의 task family 분포. 29개의 thematic version이 7개 고수준 family로 매핑되고, 800개 이상의 sub-category가 포함된다.

Figure 3은 FuzzyBench가 단일 분류 벤치마크를 넘어 여러 fuzzy task family를 누적해 만든 데이터셋임을 보여준다. 초기 버전의 core text/NLP 비중이 크지만, 이후 버전에서 format repair, fuzzy matching, agentic tool use, custom filtering, safety verification 같은 범주가 추가된다. PAW가 특정 데이터셋 요령만 배운 것인지 판단하려면 이 분포와 held-out spec split을 함께 보아야 한다.

FuzzyBench는 29개의 incremental thematic version과 800개 이상의 sub-category를 포함한다. 첫 버전은 2.5M examples와 81,920 specs, 277 base categories에서 시작했고, 최종 버전은 10M examples로 확장된다. 큰 family로는 core text processing/NLP, fuzzy/soft matching, format repair, natural-language commands, agentic/tool use, custom classification/filtering, safety/verification 계열이 들어간다. 논문이 노리는 fuzzy programming의 폭을 보여 주기 위해 데이터셋 자체가 매우 넓게 설계된 셈이다.

항목	설정	의미
데이터 단위	$(s,x,y)$ triples	spec, input, target output을 하나의 함수 호출 예제로 본다.
생성 모델	gpt-5.2	spec 생성과 input-output 생성 모두 강한 모델에 의존한다.
Split	spec 기준 80/10/10	테스트 함수 명세가 학습에 직접 등장하지 않도록 한다.
검증 테스트	gpt-5.2와 gpt-5-mini agreement	exact match 평가의 ambiguity를 줄이는 장치다.
규모	10M examples, 29 versions, 800+ sub-categories	단일 태스크보다 fuzzy-function programming 전체를 겨냥한다.

4.2 평가 지표와 비교군

주 지표는 verified test set의 exact match accuracy다. fuzzy task에서 exact match만 쓰는 것은 다소 엄격하지만, 출력 형식이 짧은 분류나 변환 함수인 경우에는 함수 품질을 직접 비교하기 쉽다. 추가로 논문은 WRENCH/ALCHEmist 설정에서 YouTube, SMS, Yelp, IMDB 같은 텍스트 벤치마크도 함께 보고한다. 여기서는 YouTube, Yelp, IMDB는 accuracy, SMS는 F1을 사용한다.

비교군은 크게 네 갈래다. 첫째, Qwen3 0.6B부터 32B까지의 직접 prompting이다. 둘째, OLMo3-7B와 gpt-oss-20B 같은 다른 로컬 모델 prompting이다. 셋째, gpt-5.2와 gpt-5-mini API baseline이다. 넷째, symbolic code generation 계열인 ALCHEmist와 저자들의 재구현이다. 여기에 같은 Qwen3 0.6B 기반의 full fine-tuning, fixed LoRA, rank별 LoRA baseline을 넣어 PAW의 compiler-generated adaptation이 단순 fine-tuning보다 나은지 확인한다.

평가표의 Contained 표기는 self-contained/offline 실행 가능성을 뜻한다. prompting API 모델은 성능이 높지만 contained가 아니다. 로컬 큰 모델 prompting은 contained일 수 있지만 메모리와 지연 비용이 크다. PAW는 compile service를 사용할 수 있지만, 한 번 컴파일된 뒤에는 interpreter와 adapter만으로 실행된다. 이 지점이 표의 정확도 수치만큼 중요하다. 논문은 fuzzy function을 제품 코드 안에 넣는 상황을 염두에 두기 때문이다.

4.3 noise variant와 외부 태스크

저자들은 spec 자체가 항상 깔끔하다고 가정하지 않는다. FuzzyBench에는 typos, grammar errors, ambiguity, formatting drift, all-noise combined, terse phrasing, casual phrasing, paraphrase 같은 noise-perturbed variants가 포함된다. 각 축은 가능한 경우 light, medium, heavy intensity로 나뉜다. 이는 개발자가 실제로 자연어 명세를 쓸 때 발생하는 오탈자, 어색한 문장, 너무 짧은 요청, 비정형 포맷을 반영한다.

또한 논문은 image-conditioned fuzzy functions도 시험한다. 이 경우 text compiler를 Qwen3-VL-4B로 바꾸고, 같은 frozen text interpreter에 PEFT artifact를 주입한다. 흥미로운 점은 작은 text interpreter가 직접 이미지를 보지 않아도, 이미지 정보가 compiler를 통해 adapter에 들어갈 수 있다는 것이다. CoSyn-400K diagram tasks, Im2SMILES, Im2LaTeX, TextVQA 등이 이 평가에 사용된다. 이 결과는 PAW가 단순 텍스트 분류를 넘어 cross-modal function compilation으로 확장될 가능성을 보여 준다.

4.4 exact match 평가가 의미하는 것과 놓치는 것

FuzzyBench의 exact match는 PAW를 함수형 프로그램처럼 평가하기에 잘 맞는다. 출력이 label, 짧은 문자열, schema-constrained answer라면 한 글자 차이도 실제 downstream code에서는 실패가 될 수 있다. 예를 들어 tool parameter extractor가 location field를 조금 다르게 쓰거나, log monitor가 ALERT 대신 설명 문장을 내면 wrapper는 추가 parsing을 해야 한다. 이런 관점에서는 exact match가 지나치게 가혹하기보다, 함수 호출 인터페이스의 안정성을 반영하는 지표가 된다.

반대로 exact match는 fuzzy function의 질적 차이를 충분히 보지 못할 수도 있다. 어떤 output은 target과 표현만 다르고 의미가 같을 수 있으며, 어떤 output은 문자열은 맞지만 reasoning path가 취약할 수 있다. 논문은 agreement filtering으로 ambiguity를 줄였지만, synthetic target이 실제 사용자의 선호와 다를 가능성은 남는다. 따라서 PAW를 특정 조직에 적용하려면 FuzzyBench 점수만 가져오기보다, domain-specific golden set과 human review set을 별도로 만들어야 한다. 특히 안전, 보안, 비용 영향을 주는 함수는 false positive와 false negative의 비용이 다르다.

이 점은 PAW의 compiler training에도 영향을 준다. compiler는 FuzzyBench의 target distribution을 학습한다. 만약 실제 도메인에서 output style, label granularity, edge case가 다르면, compile된 adapter도 그 차이를 바로 흡수하지 못할 수 있다. 논문이 제시한 구조는 강력하지만, 배포 조직은 자체 spec과 예시를 충분히 모아 compiler fine-tuning이나 post-hoc calibration을 고려해야 한다. PAW의 장점은 함수별 adapter가 작다는 점이지만, compiler 자체의 distribution alignment는 여전히 큰 연구 문제다.

또한 Table 2의 여러 benchmark를 하나의 우열 순위로 읽으면 오해가 생긴다. YouTube, SMS, Yelp, IMDB는 전통적인 text classification에 가까워 FuzzyBench와 성격이 다르다. PAW Qwen3 0.6B는 FuzzyBench에서는 Qwen3-32B prompting을 넘지만, SMS F1에서는 80.77로 Qwen3 4B/8B/14B prompting보다 낮다. 따라서 PAW는 모든 분류 태스크에서 작은 모델이 큰 모델을 이긴다는 명제가 아니다. 핵심은 다양한 held-out fuzzy specs를 weight artifact로 빠르게 전환하는 능력이다.

5. 주요 실험 결과: 작은 interpreter가 큰 prompting을 넘는 조건

5.1 FuzzyBench main result

가장 눈에 띄는 결과는 Table 2다. Qwen3 0.6B prompting은 FuzzyBench에서 9.84%에 그친다. 같은 0.6B base를 PAW로 사용하면 73.78%까지 올라간다. 이 차이는 작은 모델 자체가 fuzzy function을 풀 능력이 거의 없더라도, compiler-generated LoRA와 pseudo-program이 붙으면 다른 실행기로 변한다는 점을 보여 준다. Qwen3-32B prompting이 68.70%인 점과 비교하면, PAW Qwen3 0.6B는 훨씬 작은 runtime footprint로 더 높은 FuzzyBench 점수를 낸다.

물론 PAW가 모든 baseline을 이기지는 않는다. gpt-oss-20B prompting은 85.45%이고, API 모델인 gpt-5.2와 gpt-5-mini는 96.09%, 91.87%를 기록한다. 따라서 이 논문의 실용적 메시지는 “PAW가 가장 똑똑하다”가 아니다. 더 정확한 메시지는 반복 호출되는 함수형 fuzzy task에서는, 큰 모델을 매번 실행하는 대신 함수별 weight artifact를 만들어 작은 runtime으로 꽤 높은 정확도를 얻을 수 있다는 것이다. 비용 구조와 배포 구조를 바꾸는 결과다.

모델 / 방법	FuzzyBench	YouTube	SMS F1	Yelp	IMDB	비고
gpt-5.2 API	96.09	95.20	97.06	98.55	95.60	최고 성능이지만 외부 API 의존
gpt-5-mini API	91.87	93.60	91.03	98.13	94.96	강한 API baseline
Qwen3 0.6B prompting	9.84	52.80	0.00	89.55	66.88	소형 모델 직접 prompting의 한계
Qwen3 32B prompting	68.70	93.60	89.04	98.11	94.64	큰 로컬 모델 prompting
gpt-oss-20B prompting	85.45	91.60	89.05	97.42	92.08	PAW보다 정확도는 높지만 runtime이 큼
LM-to-Code reimplementation	35.81	70.46	86.41	50.35	73.92	symbolic code가 fuzzy semantics를 충분히 담지 못함
PAW Qwen3 0.6B	73.78	90.40	80.77	95.82	90.64	23MB adapter, 소형 로컬 실행
PAW GPT-2 124M	54.39	93.60	77.50	93.16	82.12	instruction-tuned가 아닌 작은 base에서도 의미 있는 성능

특히 GPT-2 124M 결과는 개념적으로 흥미롭다. 이 모델은 최신 instruction-tuned 모델이 아닌데도 PAW를 붙이면 FuzzyBench 54.39%를 얻는다. 이는 compiler-generated continuous program이 약한 base의 행동을 상당히 유도할 수 있음을 시사한다. 동시에 Qwen3.5 0.8B가 Qwen3 0.6B보다 항상 낫지 않다는 점도 중요하다. interpreter의 명목 크기보다 tokenizer, architecture, training distribution, compiler와의 결합이 더 중요할 수 있다.

5.2 이미지 조건부 fuzzy function

이미지 조건부 실험은 PAW의 추상화를 더 멀리 밀어붙인다. text interpreter가 이미지를 보지 않아도, vision-language compiler가 이미지와 spec을 읽고 adapter를 만들면, adapter가 이미지 조건을 부분적으로 담을 수 있다. CoSyn-400K의 Circuit, Chemical, Music diagram task에서 PAW LoRA Qwen3.5 0.8B는 각각 0.284, 0.438, 0.573을 기록해 AndesVL 0.6B, Qwen3-VL 2B, Qwen3-VL 4B baseline보다 높다. Im2SMILES에서도 0.285로 VLM baseline을 앞선다.

하지만 모든 이미지 태스크에서 강한 것은 아니다. Im2LaTeX에서는 Qwen3-VL 2B가 0.408, Qwen3-VL 4B가 0.399인 반면, PAW LoRA Qwen3.5 0.8B는 0.204에 머문다. TextVQA에서도 Qwen3-VL 2B가 0.836이고 PAW LoRA Qwen3.5 0.8B는 0.755다. 이 차이는 PAW가 이미지 기반 분류형 또는 짧은 구조 변환에는 강하지만, 긴 markup generation이나 질문응답에서는 아직 정보 손실이 크다는 점을 보여 준다.

방법	Circuit	Chemical	Music	Im2SMILES	Im2LaTeX	TextVQA
AndesVL 0.6B	0.183	0.214	0.448	0.000	0.435	0.718
Qwen3-VL 2B	0.186	0.258	0.470	0.016	0.408	0.836
Qwen3-VL 4B	0.196	0.221	0.450	0.044	0.399	0.822
PAW prefix Qwen3 0.6B	0.241	0.365	0.525	0.175	0.391	0.612
PAW LoRA Qwen3 0.6B	0.274	0.414	0.552	0.203	0.181	0.721
PAW LoRA Qwen3.5 0.8B	0.284	0.438	0.573	0.285	0.204	0.755

5.3 개발자 인터페이스와 local invocation

논문은 PAW를 연구 결과로만 두지 않고 개발자 API와 UI를 함께 제시한다. 기본 흐름은 paw.compile(spec, slug=...)로 자연어 명세를 컴파일하고, paw.function(id_or_path)로 로컬 함수를 로드해 호출하는 방식이다. 첫 다운로드 이후 실행에는 외부 API가 필요하지 않으며, 같은 interpreter가 여러 program을 hot-swap한다. 이 부분은 PAW가 단순한 benchmark trick을 넘어 실제 라이브러리 형태를 목표로 한다는 점을 보여 준다.

Figure 4: PAW 웹 UI의 compile 단계. 사용자가 자연어로 fuzzy function을 지정하면, 서비스가 해당 명세를 neural program으로 컴파일한다.

Figure 4는 PAW가 개발자 도구로 보이도록 설계된 방식을 보여준다. 사용자는 Python 코드나 학습 스크립트를 직접 다루기보다 자연어 명세를 입력하고, 시스템은 그 명세를 컴파일 가능한 함수 정의로 해석한다. 논문 관점에서 이 UI는 성능 결과만큼 중요하다. PAW가 추구하는 대상은 모델 연구자가 수작업으로 만드는 adapter에 머물지 않고, 일반 개발자가 함수 단위로 생성해 저장하는 program artifact이기 때문이다. 그래서 UI는 연구용 데모보다 함수 빌더에 가깝다.

Figure 5: PAW 웹 UI의 test 단계. 컴파일된 program에 테스트 입력을 넣고, 실제 출력이 명세와 맞는지 상호작용적으로 확인한다.

Figure 5는 컴파일된 함수가 곧바로 검증 루프에 들어가는 모습을 담고 있다. fuzzy function은 정답 경계가 흐리기 때문에, 단순히 “컴파일 성공”만으로 충분하지 않다. 개발자는 대표 입력을 넣어 출력 label이나 변환 결과가 기대와 맞는지 확인해야 한다. 이 단계는 전통적인 unit test와 비슷하지만, 테스트 대상이 symbolic code와 달리 pseudo-program과 LoRA가 결합된 neural program이라는 점에서 다르다.

Figure 6: PAW 웹 UI의 Python 실행 단계. 컴파일된 program을 로컬 코드에서 불러와 일반 함수처럼 호출하는 사용 흐름을 보여준다.

Figure 6은 PAW가 최종적으로 노리는 배포 장면이다. 컴파일된 program은 웹 UI 안에 머물지 않고, Python 코드에서 로드되어 일반 함수처럼 호출된다. 이때 developer experience의 핵심은 모델 호출이 함수 호출처럼 보인다는 점이다. spec은 compile-time에만 필요하고, run-time 코드에서는 작은 interpreter와 adapter가 조합되어 입력을 처리한다. 제품 코드 관점에서는 LLM API wrapper보다 더 라이브러리적인 형태다.

5.4 case study가 보여 주는 함수 단위 조립 방식

논문 후반의 case study는 PAW의 쓰임새를 benchmark 바깥으로 옮긴다. 첫 번째 예시는 event-driven log monitoring이다. 터미널이나 학습 로그를 계속 보면서 어떤 줄이 사람에게 알려야 할 이벤트인지 판단하는 함수다. 단순 timeout이나 문자열 포함 규칙만 쓰면 checkpoint 저장, traceback, 훈련 완료, dependency warning을 일관되게 구분하기 어렵다. PAW 함수는 emitted line을 보고 ALERT 또는 QUIET를 반환하고, 별도의 stall timer가 “새 출력이 오랫동안 없다”는 상황을 처리한다. 여기서 PAW는 전체 모니터링 시스템 전체를 맡기보다 의미 판정 subroutine으로 들어간다.

두 번째 예시는 intent-based site navigation이다. 사용자의 자연어 질문을 보고 현재 페이지가 playground, hub, browser, docs, settings, none 중 어디에 가까운지 분류한다. 논문은 여기서 하나의 거대한 agent를 만들지 않고, page classifier, question-type classifier, yes/no answerer, how/what answerer, answer validator 같은 여러 PAW 함수를 조합한다. 이 구성은 PAW가 복잡한 reasoning chain을 하나의 adapter에 모두 넣기보다, 짧고 검증 가능한 fuzzy function을 여러 개 붙이는 방향에 잘 맞음을 보여 준다.

세 번째 예시는 semantic search reranking이다. 키워드 검색이 먼저 상위 10~20개 후보를 가져오고, PAW reranker가 각 후보를 exact_match, highly_relevant, somewhat_relevant, not_relevant로 분류한다. 이 설계는 retrieval-augmented 시스템에서 자주 나오는 문제와 연결된다. embedding similarity나 keyword score는 후보를 넓게 찾는 데 좋지만, 사용자의 미묘한 의도와 업무 맥락에 맞는 최종 순위를 항상 잘 주지는 않는다. PAW reranker는 큰 LLM 재랭킹 API를 매번 호출하지 않고, 로컬에서 작고 반복적인 의미 판정을 수행하는 대안으로 제시된다.

네 번째 예시는 tool-calling pipeline이다. 논문은 ToolCall-15 설정에서 needs-tool 판정, tool-router, impossible-check, second-tool 판단, location/ticker/units/search query/person/translate parameter extractor 등 10개의 PAW function을 사용한다. 날짜와 시간 파싱은 정규식으로 처리하고, OpenAI tool_calls JSON은 Python 코드가 결정적으로 조립한다. 결과는 93%로 보고되며, 실패한 한 사례도 PAW function 자체보다 proxy loop-prevention logic 문제로 분석된다. 이 예시는 neural fuzzy 판단과 deterministic glue code를 섞는 방식이 실용적임을 보여 준다.

마지막 Alien-Taboo 예시는 PAW program library의 성격을 잘 드러낸다. 사용자는 금지어를 쓰지 않고 secret word를 설명하고, PAW 함수는 그 단어를 추측한다. 언어별로 다른 PAW program을 hot-load하지만, 같은 Qwen3 0.6B interpreter가 서버에서 실행된다. 단어장은 gpt-5.4 계열으로 만든 후보, simulated playthrough, Zipf commonness, manual pass를 거쳐 정제된다. 이 사례는 PAW가 단순 분류기보다 더 상호작용적인 애플리케이션에도 들어갈 수 있음을 보여 주지만, 여전히 각 turn은 하나의 짧은 함수 호출로 구성된다.

Case study	PAW function의 역할	시스템 설계상 의미
Event-driven log monitoring	ALERT / QUIET 의미 판정	timeout, tailing, notification 같은 deterministic control과 결합된다.
Site navigation	page type, question type, answer validation 분류	여러 작은 fuzzy subroutine을 조립해 agent-like workflow를 만든다.
Semantic reranking	후보 문서 relevance bucket 분류	embedding 검색 뒤의 비싼 LLM reranker를 로컬 함수로 대체할 수 있다.
Tool calling	tool 필요성, 라우팅, parameter extraction	neural 판단과 deterministic JSON assembly를 분리한다.
Alien-Taboo	언어별 secret word 추측	하나의 interpreter가 여러 game-specific adapter를 교체 실행한다.

이 case study들을 종합하면 PAW의 적합한 위치가 보인다. PAW는 모든 것을 처리하는 end-to-end agent보다, 사람이 이미 시스템 구조를 알고 있고 그 안의 특정 의미 판정만 반복적으로 필요한 곳에 잘 맞는다. log monitor에서는 알림 판정, site navigation에서는 페이지/질문 분류, tool calling에서는 파라미터 추출이 그런 위치다. 이 범위를 지키면 PAW program은 작고 테스트 가능하며, 실패해도 deterministic wrapper가 다시 제한을 걸 수 있다. 반대로 전체 계획 수립과 장기 상태 관리를 하나의 PAW adapter에 넣으려 하면 현재 논문이 검증한 범위를 넘어선다.

6. 추가 분석 및 Ablation Study: 왜 compiler-generated LoRA가 필요한가

6.1 LoRA mapper 설계 ablation

논문의 ablation에서 흥미로운 결과는 더 복잡한 mapper가 항상 좋지 않다는 점이다. 기본 mapper는 compiler hidden state를 mean-pool하고, single residual MLP로 shared LoRA basis의 coefficient를 예측한다. 직관적으로는 layer별, position별 정보를 더 세밀하게 보존하는 구조가 좋을 것 같지만, Table 4에서는 default rank 64, basis 64 설정이 0.6223으로 가장 높다. per-position aggregation은 0.5598, per-position + per-layer basis는 0.5559로 떨어진다.

저자들은 이 결과에 대해 명확한 이론적 설명을 제시하지 않는다. 오히려 future work를 위해 보고한다고 말한다. 이 정직한 서술은 중요하다. PAW의 compiler는 자연어 명세를 weight로 바꾸는 복잡한 함수이므로, 더 큰 표현력이 항상 더 나은 generalization으로 이어진다는 보장이 없다. shared basis와 mean-pooling은 불필요한 자유도를 줄이고, spec-level function identity를 더 안정적인 저차원 표현으로 압축했을 가능성이 있다.

Ablation	점수	해석
Default mapper: mean-pool, residual MLP, shared bases	0.6223	가장 단순한 기본 구조가 최상위 결과를 낸다.
Per-position aggregation	0.5598	prefix position별 정보를 세밀하게 살리는 설계가 오히려 약하다.
Per-position + per-layer bases	0.5559	표현력 증가가 overfitting 또는 최적화 난점으로 이어질 수 있다.
Per-layer bases only	0.6028	default보다 낮지만 position별 구조보다는 낫다.
LoRA + prefix-tuning both pathways	0.6033	두 PEFT 경로를 섞어도 자동으로 이득이 생기지 않는다.

6.2 compiler 없는 baseline과의 비교

Table 5는 PAW가 단순히 “LoRA라서 좋은 것”인지 확인한다. 같은 base와 비슷한 예산에서 fixed LoRA rank 18은 0.4236, rank 64는 0.5210, rank 128은 0.5159다. full fine-tuning은 0.5840이다. 반면 PAW Qwen3 0.6B는 0.7378이다. 이 차이는 함수별 명세를 읽어 adapter를 생성하는 compiler가 핵심임을 보여 준다. 하나의 고정 LoRA나 full fine-tune은 수많은 fuzzy function을 한 모델 상태 안에 평균적으로 담아야 하지만, PAW는 spec마다 다른 program을 만든다.

이 지점은 일반 fine-tuning과의 관점 차이를 만든다. fine-tuning은 모델을 “더 많은 fuzzy task를 아는 범용 실행기”로 만든다. PAW는 범용 실행기를 크게 고치기보다, 각 fuzzy function을 위한 작은 실행 패치를 만든다. 따라서 PAW의 성능은 interpreter의 사전 지식, compiler의 spec 이해, mapper의 weight 생성 능력, pseudo-program의 언어적 scaffolding이 함께 만든다. 하나만 떼어 보아서는 논문 결과를 설명하기 어렵다.

6.3 robustness와 pseudo-program의 역할

spec noise 실험은 실제 개발 환경과 직접 연결된다. clean 조건에서 epoch-2 Qwen3 0.6B PAW는 0.6692를 얻고, heavy typos에서는 0.6621로 0.7%p만 떨어진다. grammar noise는 오히려 0.6731로 약간 높고, ambiguity는 0.6511, formatting은 0.6526, all-noise는 0.6326이다. combined heavy noise에서도 하락폭은 3.7%p 수준이다. 자연어 명세가 조금 지저분해도 compiler가 상당 부분 흡수한다는 결과다.

Table 7은 pseudo-program이 이 robustness에 기여함을 보여 준다. pseudo-program default는 clean 0.6443, heavy typos 0.6108을 기록한다. raw spec만 쓰면 clean 0.6285, heavy typos 0.5662다. clean에서는 약 1.6점 차이지만, heavy typos에서는 약 4.5점으로 벌어진다. pseudo compiler가 단순한 설명 장식을 넘어 noisy spec을 interpreter와 LoRA compiler가 쓰기 좋은 형태로 정제한다는 증거다.

조건	성능	clean 대비 변화	의미
Clean	0.6692	기준	명세가 깔끔한 기본 조건
Heavy typos	0.6621	-0.7%p	철자 오류에 비교적 강함
Heavy ambiguity	0.6511	-1.8%p	의미 경계가 흐릴수록 손실이 커짐
Heavy formatting	0.6526	-1.7%p	비정형 포맷에도 큰 붕괴는 없음
All-noise heavy	0.6326	-3.7%p	여러 noise가 겹쳐도 기능이 완전히 무너지지 않음
Pseudo default vs raw spec under typos	0.6108 vs 0.5662	+4.5%p	pseudo compiler의 denoising 효과가 커짐

6.4 quantization과 로컬 배포

로컬 실행을 주장하려면 정확도와 함께 모델 크기와 속도를 봐야 한다. 논문은 Qwen3 0.6B interpreter와 LoRA adapter를 GGUF/llama.cpp 계열로 quantize한 결과를 보고한다. PyTorch bf16 base는 약 1515MB이고 accuracy는 0.6580이다. Q8_0 base + Q4_0 LoRA는 805MB + 23MB에서 0.6567, Q6_K base + Q4_0 LoRA는 623MB + 23MB에서 0.6575를 기록한다. Q4_K_M base + Q4_0 LoRA는 총 약 507MB 수준에서 0.6453이다.

저자들은 Q6_K + Q4_0 조합이 bf16과 사실상 구분하기 어려운 수준이라고 본다. MacBook M3에서 Q5_K_M base + Q4_0 adapter는 약 31.6 tokens/s, cold load 0.48초로 보고된다. 이 수치는 PAW가 서버 없는 로컬 유틸리티 함수로 쓰일 수 있음을 뒷받침한다. 물론 실제 제품에서는 batching, adapter hot-swap, concurrent calls, memory residency 같은 운영 문제가 추가되지만, 단일 함수 실행의 feasibility는 충분히 보여 준다.

형식	Base 크기	LoRA 크기	정확도	해석
PyTorch bf16	1515MB	-	0.6580	비교 기준
fp16 base + fp32 LoRA	1509MB	162MB	0.6594	정확도는 유지되지만 adapter가 큼
Q8_0 base + Q4_0 LoRA	805MB	23MB	0.6567	크기를 크게 줄이고 정확도 유지
Q6_K base + Q4_0 LoRA	623MB	23MB	0.6575	논문이 강하게 추천할 만한 균형점
Q4_K_M base + Q4_0 LoRA	484MB	23MB	0.6453	총 507MB 근처에서 약 1.3점 손실

6.5 실패 양상과 PEFT 선택 문제

image-conditioned 결과는 PEFT 선택이 task-dependent임을 잘 보여 준다. LoRA는 CoSyn diagram classification과 Im2SMILES에서 강하지만, Im2LaTeX처럼 긴 구조 문자열을 생성하는 과제에서는 prefix-tuning이 상대적으로 더 나은 경우가 있다. 이는 정보가 model weight delta로 들어가는 방식과 attention cache로 들어가는 방식이 생성 길이와 구조 보존에 다르게 작용할 수 있음을 시사한다. 현재 논문은 이 차이에 대한 원리를 확정하지 않고, 결과 중심으로 보고한다.

실패 양상을 더 자세히 보면 PAW의 좋은 사용 범위가 드러난다. 짧은 label, 제한된 output schema, 일정한 입력 형식, 반복 호출되는 의미 판정에는 강하다. 반대로 길고 자유로운 generation, 외부 지식이 필요한 질문응답, 다단계 추론, input마다 새로운 근거를 찾아야 하는 task에서는 큰 VLM이나 LLM prompting이 더 낫다. PAW program은 함수의 behavior prior를 저장하지만, 매 입력마다 풍부한 reasoning budget을 새로 쓰는 구조는 아니다. 이 차이를 이해해야 실제 시스템에서 baseline 선택을 잘 할 수 있다.

compiler scaling 표가 inconclusive로 남은 점도 중요하다. Qwen3 4B unfrozen compiler가 Qwen3.5 0.8B interpreter 설정에서 0.6455를 기록하지만, Qwen3 14B unfrozen은 0.6257이고, Qwen3 32B frozen은 0.6174다. 큰 compiler가 항상 더 좋은 adapter를 만든다고 말할 수 없다. compiler가 hidden representation을 어떻게 노출하고, mapper가 그 representation을 interpreter weight space로 얼마나 잘 옮기는지가 더 중요할 수 있다. 이는 단순한 scaling law보다 compiler-interpreter co-design이 필요하다는 신호다.

따라서 후속 연구는 “어떤 PEFT가 어떤 fuzzy function family에 맞는가”를 체계적으로 분류해야 한다. label classification, short normalization, structured extraction, long markup generation, multilingual guessing, image-to-symbol translation은 서로 다른 inductive bias를 요구한다. 하나의 PAW compiler가 모든 유형에 같은 방식으로 LoRA를 뿌리는 것보다, task family별로 LoRA, prefix, adapter composition, mixture-of-adapters를 선택하는 meta-compiler가 필요할 수 있다. 이 방향은 논문 결과가 남긴 가장 실질적인 ablation 질문이다.

7. 한계점 및 향후 연구 방향: 가중치 프로그램을 믿고 고칠 수 있는가

7.1 compiler-interpreter 결합 문제

첫 번째 한계는 compiler와 interpreter의 결합이다. PAW compiler는 특정 interpreter family와 함께 학습된다. Qwen3 0.6B에 맞춘 compiler를 그대로 Qwen3.5 0.8B나 GPT-2 124M에 붙일 수 없다. 논문은 interpreter를 바꾸려면 compiler를 다시 학습해야 한다고 본다. 이는 라이브러리 배포 관점에서 중요한 제약이다. 일반 소스 코드는 Python 버전이나 OS 차이는 있어도 대체로 같은 의미를 유지하지만, PAW program은 interpreter architecture와 tokenizer, module naming, hidden dimension에 강하게 묶인다.

이 결합은 장기 유지보수 문제를 만든다. 어떤 조직이 수천 개의 PAW program을 만들었다고 가정하면, interpreter를 업그레이드할 때 모든 program을 재컴파일하거나 새 compiler를 훈련해야 할 수 있다. 모델 공급망이 바뀌거나 quantization backend가 달라질 때도 호환성 검증이 필요하다. 따라서 PAW가 실사용으로 가려면 adapter ABI, interpreter compatibility matrix, regression test suite 같은 공학적 층이 함께 필요하다.

7.2 불투명한 continuous program

두 번째 한계는 해석 가능성이다. pseudo-program은 사람이 읽을 수 있지만, 실제 성능의 상당 부분은 LoRA 파라미터에 들어 있다. 이 continuous component는 사실상 neural binary다. 어떤 규칙을 왜 학습했는지, 특정 예외를 어떻게 처리하는지, 안전하지 않은 shortcut이 들어갔는지 직접 읽기 어렵다. 제품 코드에서 fuzzy function이 중요한 의사결정에 쓰인다면, 테스트 케이스만으로 충분한지 문제가 남는다.

이 문제는 일반 fine-tuning의 불투명성과 닮았지만, 함수형 배포라는 점 때문에 더 날카롭다. PAW program은 개발자가 “이 함수는 이런 일을 한다”고 이름 붙이고 코드 안에 넣는 단위다. 따라서 함수 문서, 테스트, 버전 diff, rollback, provenance가 필요하다. 앞으로는 adapter delta를 분석해 어떤 token pattern이나 feature direction이 활성화되는지 보는 도구, pseudo-program과 LoRA component의 불일치를 찾는 검증기, adversarial spec perturbation에 대한 stress test가 중요해질 것이다.

7.3 synthetic data와 single-step 평가

세 번째 한계는 FuzzyBench의 synthetic nature다. 1,000만 예제라는 규모는 강점이지만, spec과 target이 gpt-5.2 계열에서 생성되고 agreement filtering도 gpt-5-mini와의 일치에 의존한다. 이 설계는 다양한 fuzzy function을 빠르게 만들 수 있지만, 실제 기업 로그, 고객 지원 라벨, 보안 이벤트, 의료/법률 문서 분류 같은 도메인에서 같은 성능이 유지되는지는 별도 검증이 필요하다. 모델 생성 데이터의 스타일을 compiler가 학습했을 가능성도 배제할 수 없다.

또 하나는 single-step 평가다. 모든 주요 평가는 하나의 입력을 받아 하나의 출력을 내는 함수 호출로 구성된다. 논문 case study는 여러 PAW function을 사람이 조합해 tool-calling pipeline이나 site navigation pipeline을 만들 수 있음을 보여 주지만, 학습된 program 자체가 장기 상태, multi-turn memory, error recovery, tool feedback을 다루는지는 검증하지 않는다. 실제 agent workflow 안에서 PAW가 쓰이려면 single fuzzy function을 넘어 composed fuzzy program의 안정성까지 봐야 한다.

7.4 배포 관점의 안전장치

PAW를 실제 서비스에 넣는다면 최소한 세 가지 안전장치가 필요해 보인다. 첫째, compile-time 검증이다. spec이 지나치게 넓거나 출력 형식이 불명확하면 compiler가 그럴듯한 adapter를 만들 수는 있지만, 그 함수가 제품 요구를 만족한다고 보기 어렵다. 따라서 spec linter, output schema checker, representative example coverage checker가 compile pipeline 앞단에 있어야 한다. 둘째, run-time guardrail이다. PAW 출력이 허용된 label set 또는 JSON schema를 벗어나면 deterministic code가 거부하거나 fallback해야 한다.

셋째, post-deployment monitoring이다. fuzzy function은 시간이 지나며 데이터 분포가 바뀌면 조용히 성능이 내려갈 수 있다. 로그 알림 함수는 새로운 framework의 warning pattern을 놓칠 수 있고, search reranker는 새 제품 이름이나 내부 약어를 잘못 분류할 수 있다. 이런 drift를 잡으려면 PAW output과 사람 수정, downstream action 결과, false positive/false negative 샘플을 다시 수집해야 한다. 그리고 이 샘플은 다음 compiler 또는 program 재컴파일의 regression set이 되어야 한다.

이 안전장치 관점에서 보면 PAW는 LLM을 없애는 기술이라기보다 LLM 호출의 위치를 옮기는 기술이다. 사용자는 run-time에서 큰 LLM API를 덜 부르지만, compile-time compiler, test generation, regression evaluation, monitoring analysis에는 여전히 강한 모델과 사람이 필요할 수 있다. 장점은 이 비용이 입력마다 반복되지 않고 함수 lifecycle 단계에 집중된다는 점이다. 따라서 PAW의 경제성은 호출량이 많고 함수 정의가 비교적 안정적인 환경에서 가장 커진다.

8. 내 해석: 프로그램 저장 위치가 prompt에서 weight로 이동할 때 생기는 질문

나는 이 논문을 LoRA의 응용 논문이라기보다, 프로그램이 어디에 저장되는가를 묻는 논문으로 읽었다. 이전에 리뷰한 LoRA 축은 다운스트림 적응을 저랭크 weight delta로 표현한다는 점이 핵심이었다. FlowCompile이나 structured LLM workflow compilation 계열은 LLM 호출 그래프와 reasoning budget을 외부 workflow로 컴파일한다. Corpus2Skill, SkillCAT, Agent Skills 계열은 지식을 문서와 skill tree, topology로 저장한다. Program-as-Weights는 이 흐름에서 다른 좌표에 있다. 함수의 의미를 prompt/context나 workflow graph 바깥에 두지 않고, interpreter가 읽는 weight artifact 안에 직접 넣는다.

가장 걸리는 약점은 검증 가능성이다. 논문은 exact match, noise robustness, ablation, quantization을 꽤 촘촘히 보여 주지만, 실제 개발자가 PAW program을 코드베이스에 넣었을 때 무엇을 diff로 리뷰해야 하는지는 아직 답이 약하다. pseudo-program은 사람이 볼 수 있지만, LoRA component가 예외 케이스를 어떻게 처리하는지는 테스트 입력을 많이 넣어 보는 수밖에 없다. 특히 보안 필터, 개인정보 제거, 운영 알림처럼 false negative 비용이 큰 함수라면, 23MB짜리 adapter가 작은 라이브러리처럼 보인다는 사실만으로 신뢰하기 어렵다.

내가 이 연구를 확장한다면 먼저 PAW program provenance와 regression harness를 붙여볼 것 같다. 자연어 spec, pseudo-program, compiler checkpoint, interpreter checkpoint, LoRA quantization format, 대표 test suite, adversarial perturbation set을 하나의 manifest로 묶고, program이 업데이트될 때마다 behavior diff를 자동으로 남기는 방식이다. 이는 기존 skill artifact나 workflow compilation과 연결될 수 있다. 외부 skill 문서는 사람이 읽을 수 있는 control plane이 되고, PAW adapter는 특정 fuzzy subroutine의 data plane이 되는 구조다.

또 다른 후속 방향은 PAW와 context-space optimization의 결합이다. Reflective Context Learning류의 접근은 prompt, memory, playbook을 최적화 대상으로 본다. PAW는 parameter space를 프로그램 표면으로 삼는다. 둘을 나누기보다, 어떤 부분은 readable context로 남기고 어떤 부분은 weight로 컴파일할지 결정하는 compiler가 필요해 보인다. 예컨대 정책 설명, 안전 경계, 감사용 rationale은 pseudo-program 또는 skill 문서에 남기고, 반복되는 미세한 분류 기준만 LoRA로 보내는 식이다. 이렇게 해야 weight program의 성능과 문서 프로그램의 검토 가능성을 동시에 얻을 수 있다.

Figure 7: 컴파일된 PAW program library. 서로 다른 자연어 명세가 별도의 pseudo-program과 LoRA artifact로 저장되고, 하나의 interpreter가 이들을 교체해 실행한다.

Figure 7은 PAW를 단일 모델 실험을 넘어 program library로 보는 장면을 제공한다. message urgency, JSON repair, PII removal 같은 서로 다른 명세가 별도 program으로 저장되고, 같은 interpreter가 필요할 때 adapter를 바꿔 단일 함수를 실행한다. 이 구조에서는 모델 배포보다 함수 카탈로그 관리가 중요해진다. 어떤 program이 어떤 spec과 checkpoint에서 생성됐는지 추적하는 provenance가 성능만큼 필요하다.

운영 관점에서 또 하나 볼 점은 adapter catalog의 lifecycle이다. 하나의 서비스가 이메일 triage, log alert, search reranking, tool routing, schema repair처럼 여러 PAW program을 갖게 되면, 각 program은 별도의 테스트 세트와 권한 범위를 가져야 한다. 예를 들어 개인정보 제거 함수와 검색 재랭킹 함수가 같은 interpreter를 공유하더라도, 입력 로그 보존 정책과 실패 시 fallback은 완전히 다를 수 있다. 따라서 PAW runtime은 단순 모델 서버보다 function registry, access control, audit log, rollback policy를 함께 가진 작은 플랫폼에 가까워질 가능성이 높다.

이 플랫폼화는 논문의 코드 예시와도 맞닿아 있다. paw.compile과 paw.function은 사용성을 단순하게 보이게 만들지만, 내부에는 compiler service, artifact store, quantized interpreter, adapter loader, local cache가 숨어 있다. 논문이 제시한 수치는 이런 계층이 충분히 작게 구현될 수 있음을 보여 주지만, 제품 환경에서는 monitoring과 governance가 같은 비중으로 따라와야 한다. PAW의 진짜 가치는 함수 하나를 잘 만드는 데서 끝나지 않고, 많은 fuzzy function을 반복 가능하게 관리하는 데서 커진다.

9. 결론: LLM을 호출하는 함수에서 컴파일하는 함수로

Program-as-Weights는 자연어로 쓰기 쉬운 fuzzy function을 로컬에서 실행 가능한 neural program으로 바꾸는 패러다임을 제안한다. 논문의 기술적 구성은 pseudo-program과 LoRA adapter의 결합이며, 핵심 실험은 Qwen3 0.6B interpreter가 Qwen3-32B prompting보다 높은 FuzzyBench 점수를 내는 장면이다. 이 결과는 작은 모델 자체의 능력을 과장하기보다, 함수별로 생성된 weight artifact가 작은 모델을 특정 행동 공간으로 강하게 유도할 수 있음을 보여 준다.

논문의 장점은 문제 정의가 실용적이라는 데 있다. 많은 조직은 모든 판단 함수를 거대 LLM API로 처리하고 싶지 않다. 비용, 지연, 개인정보, 네트워크 의존성, 모델 버전 변동이 계속 부담이 된다. 반대로 완전한 규칙 코드는 의미 판단을 감당하지 못한다. PAW는 이 사이에서 compile-time big model과 run-time small interpreter를 분리한다. 이 분리는 fuzzy function이 충분히 반복 호출되고, 출력 공간이 비교적 제한적이며, 테스트 세트를 만들 수 있는 상황에서 특히 설득력 있다.

동시에 PAW는 새로운 운영 질문을 만든다. 가중치로 저장된 program은 어떻게 리뷰하고, 어떻게 감사하고, 어떻게 버전 관리할 것인가. interpreter 업그레이드 때 program 호환성은 어떻게 보장할 것인가. synthetic benchmark에서 좋은 함수가 실제 회사 데이터에서도 같은 경계 감각을 보일 것인가. 이런 질문은 논문의 한계이자 후속 연구의 핵심이다. PAW가 넓게 쓰이려면 compiler 성능만큼이나 program governance가 중요해진다.

Figure 8: 부록의 prefix-tuning compile 구조. natural language description과 예시를 읽어 interpreter attention cache에 넣을 KV prefix를 생성한다.

Figure 8은 LoRA 이전 또는 보조 instantiation인 prefix-tuning 흐름을 보여준다. compiler가 함수 설명과 예시를 읽고, interpreter 각 layer의 attention cache에 주입될 key-value prefix를 만든다. 이 구조는 PAW의 일반 추상화가 특정 PEFT 기법에 묶이지 않는다는 점을 보여 준다. 다만 본문 결과에서는 text fuzzy task 기준으로 LoRA가 prefix보다 강하게 나타나며, 이미지의 긴 markup 생성에서는 prefix가 더 나은 경우도 보고된다.

Figure 9: 부록의 prefix-tuning interpret 구조. 생성된 KV prefix가 frozen interpreter의 attention 경로에 들어가고, 입력은 해당 prefix와 함께 처리된다.

Figure 9는 prefix-tuning program이 실제 interpreter 안에서 작동하는 모습을 보여준다. LoRA가 weight matrix의 저랭크 변화를 주입한다면, prefix-tuning은 attention context에 추가 key-value state를 제공한다. 두 방식 모두 discrete code와 다른 continuous artifact로 함수를 표현하지만, 정보가 들어가는 위치가 다르다. 이 비교는 PAW를 하나의 구현을 넘어 “함수를 PEFT artifact로 컴파일하는 계열”로 이해하게 만든다.

결국 이 논문은 “LLM을 함수처럼 호출한다”는 익숙한 표현을 한 단계 바꾼다. PAW에서 함수는 LLM 호출 그 자체보다, LLM이 만들어 낸 작고 배포 가능한 program artifact다. 이 artifact는 pseudo-program처럼 읽히는 부분과 LoRA처럼 실행되는 부분으로 나뉜다. 그 조합이 충분히 안정적이라면, 앞으로의 애플리케이션은 prompt 템플릿 모음만이 아니라 compiled fuzzy function library를 함께 갖게 될 수 있다. PAW는 그 방향을 수치와 시스템 구현으로 처음 꽤 구체적으로 보여 준 논문이다.

이 때문에 PAW의 성패는 모델 정확도, artifact 관리, 테스트 문화가 함께 맞물릴 때 판단해야 한다.

특히 반복 호출량이 큰 내부 도구에서는 이 세 축의 균형이 곧 비용 절감과 품질 보증의 기준이 된다.

10. 요약 정리

• Program-as-Weights는 자연어로 명세한 fuzzy function을 pseudo-program과 LoRA adapter로 구성된 neural program으로 컴파일한다.
• 큰 compiler 모델은 compile-time에만 쓰이고, 실행 시에는 동결된 소형 interpreter가 함수별 adapter를 붙여 로컬에서 입력을 처리한다.
• Qwen3 0.6B 기반 PAW는 FuzzyBench에서 73.78% exact match를 기록해 Qwen3-32B prompting의 68.70%를 넘지만, gpt-oss-20B나 API 모델보다 항상 높지는 않다.
• FuzzyBench는 1,000만 개 spec-input-output 예제로 구성되며, spec 기준 split과 model agreement filtering으로 exact match 평가를 가능하게 한다.
• LoRA mapper ablation에서는 mean-pool, residual MLP, shared basis를 쓰는 단순한 default 구조가 더 복잡한 per-position/per-layer 구조보다 강했다.
• pseudo-program은 명세를 읽기 좋게 만드는 장식을 넘어, 특히 오탈자와 format noise가 있는 spec에서 성능을 지키는 denoising 장치로 작동한다.
• Quantization 결과는 Qwen3 0.6B interpreter와 23MB Q4_0 LoRA adapter가 MacBook급 로컬 환경에서도 실행 가능한 크기와 속도에 접근함을 보여 준다.
• 가장 큰 한계는 compiler-interpreter 결합, continuous program의 불투명성, synthetic benchmark 의존, single-step 평가에 있다.
• 이 논문은 LoRA를 단순 fine-tuning 기법에서 프로그램 저장 형식으로 확장해 읽게 만들며, prompt/workflow/skill compilation과 다른 weight-level programming 축을 제시한다.