[논문 리뷰] Compile by Training: Turning Natural-Language Specifications into Local Neural Functions

메타정보
TL;DR
소개 (Introduction)
핵심 기여 (Key Contributions)
관련 연구 / 배경 지식
- Fuzzy function과 Program-as-Weights
- 합성 supervision과 작은 모델의 특화
방법 / 아키텍처 상세
학습 목표 / 손실 함수
- 합성 정답에 대한 조건부 로그우도
학습 데이터와 파이프라인
- Public Finetuned Standard 설정
- Teacher 혼합 실험과 데이터 규모 실험의 조건
실험 결과
결과 분석 / Ablation
한계와 비판적 평가
시사점 / Takeaways
설치 및 사용법
참고 자료
더 읽어보기

메타정보

항목	내용
저자	Yuntian Deng, Pengyu Nie, Stuart Shieber (University of Waterloo · Harvard University)
학회	EMNLP System Demonstrations · 2026 · CC BY 4.0
arXiv 또는 DOI	2609.04199
Code	programasweights/paw-helper · Claudish
데이터	FuzzyBench-Hard · 함수 명세별 teacher 합성 입출력 쌍
리뷰 일자	2026-09-23

TL;DR

자연어로 함수의 동작을 설명하면 teacher가 입출력 예제를 만들고, 고정된 Qwen3-0.6B interpreter의 LoRA adapter를 학습한다. 결과는 adapter·실행 프롬프트·메타데이터를 담은 재사용 가능한 .paw 프로그램이다.
기존 Program-as-Weights의 빠른 compiler가 예측한 adapter와 scaffold에서 출발해 추가 학습한다. FuzzyBench-Hard의 평균 LEM은 22.4%에서 83.6%로 상승한다. 차이는 61.2%p이며, 일반적인 전체 과제 정확도를 뜻하지 않는다.
보고된 컴파일 시간은 3.5초에서 50.9초로 늘어난다. 이는 새 입력 하나의 추론 지연이 아니라 함수를 준비하는 시간이다. 합성 데이터 생성과 학습을 겹치고, 작업 상태를 비동기로 관리한다.
웹사이트 도우미, 자연어 기반 3D 동작 제어, 양방향 문체 변환을 시연한다. 모호한 판단은 neural function이 맡고 검색·분기·출력 구조 검사는 일반 코드와 결합한다.
Teacher 오류, 기준 모델의 실패 사례로 구성된 평가셋, 작은 judge 검증 표본을 함께 고려해야 한다. 로컬 SDK의 실행 입력은 외부 teacher에 보내지 않지만, 최초 명세의 컴파일은 hosted service와 teacher API를 사용한다.

소개 (Introduction)

“오늘 안에 서명해야 하는 메일은 바로 확인하고, 뉴스레터는 나중에 읽는다”는 요구는 사람이 이해하기 어렵지 않다. 하지만 이 동작을 규칙으로 구현하려면 표현의 변형, 문맥, 실제 행동 요청과 단순한 정보 전달의 차이를 계속 다뤄야 한다. 큰 언어모델에 매번 물어보면 구현은 간단해지지만, 같은 종류의 판단을 반복할 때마다 네트워크와 모델 호출 비용이 발생한다. 한편 이 작은 기능 때문에 범용 모델 전체의 능력이 필요한 것은 아닐 수 있다.

Deng et al.의 Compile by Training은 이 반복성을 이용한다. 큰 모델은 함수를 만들 때 예제를 제공하고, 이후 입력은 작은 모델이 처리하게 한다. 개발자는 명세를 작성하고 빌드를 기다린 뒤 결과물을 호출한다. 논문이 학습을 “컴파일”이라고 부르는 이유는 자연어 문장을 기계어로 정확히 번역해서가 아니라, 한 번 준비한 동작을 저장하고 다시 쓸 수 있는 프로그램 형태로 내보내기 때문이다.

이 관점의 흥미로운 점은 개별 fine-tuning 기법보다 소프트웨어의 의존성을 배치하는 방식에 있다. 강력한 teacher를 매 호출의 필수 구성 요소에서 함수 제작 단계의 도구로 옮긴다. 다만 학습된 함수는 여전히 오답을 낼 수 있으며, 새 입력의 처리에도 작은 언어모델 추론이 필요하다. 아래에서는 arXiv v1의 본문과 부록을 바탕으로 실제로 만들어지는 결과물, 평가가 보여 주는 개선의 범위, 서비스와 응용에서 남는 제약을 살펴본다.

핵심 기여 (Key Contributions)

명세별 추가 학습을 통한 neural function 생성. 한 번의 가중치 예측으로 끝나는 PAW compiler에 teacher 데이터 합성과 gradient descent를 결합해, 어려운 함수에 더 많은 준비 연산을 투입한다.
동일한 프로그램 형식과 실행 인터페이스. Shared interpreter와 함수별 adapter·scaffold를 유지해 기존 PAW의 저장·버전 관리·조합 방식을 이어 간다.
분 단위 컴파일을 위한 서비스 설계. 데이터 생성과 학습의 중첩, teacher 출력 캐시, GPU 작업 큐, 새로고침 후에도 유지되는 job 상태를 하나의 사용자 흐름으로 연결한다.
정확도 비교와 실제 조합 사례. 의미 기반 평가와 supervision 실험을 제시하고, 분류·답변·검증·구조화된 출력·문체 변환에 학습된 함수를 적용한다.

방법 / 아키텍처 상세

1. 명세·컴파일·로컬 실행의 분리

Figure 1: 명세 입력, 백그라운드 컴파일 진행률, 로컬 SDK의 반복 호출로 이어지는 세 단계. 컴파일 시점의 teacher·GPU 의존성과 실행 시점의 local interpreter.

개발자가 제공하는 것은 text-to-text 함수의 자연어 명세다. 입력에 대해 어떤 출력이 필요한지, 어떤 경우를 제외해야 하는지, 출력 형식이 무엇인지를 설명한다. 시스템의 인터페이스는 명세를 프로그램으로 만드는 Compile과 프로그램을 새 입력에 적용하는 Run으로 나뉜다. 이를 논문의 표기를 따라 쓰면 다음과 같다.

\[\begin{aligned} p_s &= \operatorname{Compile}(s),\\ \hat y &= \operatorname{Run}(p_s,x). \end{aligned}\]

여기서 s는 명세, p는 그 명세를 위한 프로그램, x는 실행 시점에 처음 들어온 입력이다. 이 구분 덕분에 같은 명세의 함수를 여러 입력에 적용할 때 컴파일을 반복하지 않아도 된다. 반대로 동작 요구가 바뀌면 새 프로그램을 준비해야 한다. 결과물이 파일로 남는다는 사실은 배포할 버전을 선택할 수 있게 하지만, 명세의 모든 경우를 정확히 구현했다는 증명이 되지는 않는다.

개인정보 관점에서도 두 시점을 나눠야 한다. 논문에서 컴파일은 PAW service와 teacher API를 사용하는 hosted 과정이다. 따라서 함수 설명은 외부 서비스로 전달된다. 완료된 프로그램을 로컬 SDK로 실행할 때에는 이후 입력을 PAW나 teacher에게 보내지 않는다. 이 주장을 웹 데모를 포함한 모든 배포 방식에 자동으로 확대하면 안 된다. 실제 실행이 어디서 일어나는지는 응용이 선택한 backend에 달려 있다.

2. Teacher의 입출력 예제 생성과 형식 검증

명세 하나만으로는 supervised learning에 필요한 여러 입출력 사례가 생기지 않는다. Compiler는 teacher에게 명세와 생성할 예제 수를 주고, 그 함수가 따라야 할 입력 x와 출력 y의 쌍을 만들게 한다. 부록 D의 요청은 최상위 examples와 문자열 형태의 input, output을 갖는 JSON을 요구한다. 반환 형식이 잘못되거나 필요한 내용이 빠진 batch는 학습에 넘기기 전에 거부한다.

논문의 예시는 arXiv /pdf/ 링크에서 ID를 뽑되 /abs/ 링크는 무시하는 함수다. 두 종류의 주소가 섞인 입력에서 출력은 PDF 주소의 ID만 포함한다. 이런 예제는 긍정 사례뿐 아니라 무엇을 제외해야 하는지까지 명세의 일부임을 보여 준다. 실제 서비스에서는 비용이 낮은 teacher가 대부분의 예제를 만들고 더 큰 teacher가 보완하는 supervision을 제공한다.

여기서 “검증된 예제”의 의미를 좁게 읽어야 한다. JSON이 잘 형성되었고 필드가 존재한다는 검사와, 정답이 명세의 의미에 완벽하게 맞는다는 검사는 다르다. 본문은 자동 형식 검증을 설명하지만 모든 정답을 독립적인 oracle로 다시 보장한다고 말하지 않는다. 잘못된 teacher 예제가 형식 검사를 통과하면 이후 학습이 그 오류를 반복하게 만들 수 있다. 논문의 한계에서도 이 점을 인정한다.

3. Warm start와 run-time scaffold

Figure 2: 위쪽의 teacher 예제 생성·검증·LoRA 학습·프로그램 패키징과 아래쪽의 새 입력 처리. 학습 초기값과 실행 scaffold를 제공하는 warm start.

모든 함수는 고정된 Qwen3-0.6B interpreter를 공유한다. 함수마다 달라지는 핵심은 LoRA adapter와 run-time scaffold다. Scaffold는 자유로운 자연어 명세를 구조화된 지시와 예제로 표현하고, 실제 입력이 들어갈 자리를 남겨 둔 프롬프트 템플릿이다. 실행 시 모델이 보는 것은 단순한 입력 문자열만이 아니라 이 템플릿에 입력을 끼운 문맥이다.

빠른 PAW compiler가 초기 adapter와 scaffold를 제공한 뒤, 합성 예제에 대한 학습으로 adapter를 갱신한다. Backbone을 함수마다 새로 학습하거나, 호출할 때마다 teacher를 다시 부르는 구조가 아니다. 또한 모든 과제 정보가 가중치에만 들어 있다고 설명해도 부정확하다. 프로그램은 가중치와 실행 프롬프트를 함께 사용한다.

학습이 끝나면 adapter, scaffold, 원래 명세, interpreter 메타데이터를 프로그램에 묶는다. .paw 파일은 공유 interpreter를 특화하는 결과물이며, 별도의 언어모델 없이 실행되는 일반적인 네이티브 바이너리와는 성격이 다르다. 이 구분은 저장 공간뿐 아니라 배포 호환성을 이해할 때도 필요하다. 같은 함수 파일을 재사용하려면 그것이 기대하는 실행 환경과 interpreter를 함께 고려해야 한다.

4. 합성 데이터와 학습의 중첩 실행

모든 teacher 응답이 올 때까지 기다린 다음 모델을 로드하고 학습하면, GPU는 네트워크 응답을 기다리는 동안 일을 하지 못한다. 논문의 streaming compile 경로는 teacher 요청, 모델 로딩, 학습을 겹친다. 첫 batch에 필요한 예제가 준비되는 즉시 학습을 시작하고, 학습이 데이터 생성 속도를 따라잡았을 때만 대기한다.

Teacher 응답은 요청한 순서대로 도착하지 않을 수 있다. Scheduler는 들어온 예제를 먼저 필요한 batch의 열린 slot에 배치해 기다리는 구간을 줄인다. 본문은 이 과정이 승인된 예제와 정해진 학습 순서를 바꾸지 않는다고 설명한다. 핵심은 늦은 응답 하나 때문에 전체 준비 작업이 직렬로 묶이지 않도록 하는 것이다.

이는 토큰 생성 한 번을 빠르게 만드는 최적화와 다르다. 저자들이 지적하는 지배적인 비용은 개별 학습 step보다 느리고 변동성이 큰 teacher synthesis다. 따라서 GPU가 더 빨라졌을 때 컴파일 시간이 같은 비율로 줄어들 것이라고 기대하기 어렵다. 다만 본문에는 중첩 실행을 끈 조건과 켠 조건의 완전한 비교표가 없으므로, 전체 50.9초 중 이 설계만의 기여를 따로 계산할 수는 없다.

5. Job 상태·공유 큐·출력 캐시

Figure 3: API와 job 저장소, 공유 큐, GPU worker, 프로그램 저장소의 연결. 실선의 요청·결과물 흐름과 점선의 진행 상태·캐시·teacher 통신.

서비스의 API는 각 요청의 영속적인 job 기록을 유지하고, 공유 큐는 대기 작업을 사용 가능한 GPU worker에 배정한다. Worker는 필요한 teacher 출력이 캐시에 있는지 먼저 확인하고 없는 예제만 새로 요청한다. 완료된 프로그램은 공유 저장소에 기록한 뒤 원래 job과 연결한다. 이렇게 하면 웹 요청을 받는 역할과 오래 걸리는 학습을 수행하는 역할을 분리할 수 있다.

사용자 화면도 이 구조에 맞춘다. 컴파일은 화면을 붙잡는 단일 요청 대신 백그라운드 build로 표현된다. 큐 위치와 학습 진행률을 보여 주며, 다른 페이지로 이동하거나 새로고침해도 job은 이어진다. 처리 시간을 줄이는 일과 기다리는 동안 다른 작업을 허용하는 일은 서로 다른 개선이다. 이 논문은 분 단위의 학습을 인터랙티브 제품에 넣기 위해 둘을 함께 다룬다.

학습 목표 / 손실 함수

합성 정답에 대한 조건부 로그우도

명세 s에서 얻은 데이터셋과 학습 목적은 다음과 같다. T는 teacher를 통한 합성 과정, θ는 해당 함수의 adapter 파라미터, r은 입력을 받아 실행 프롬프트를 만드는 scaffold다.

\[\begin{aligned} D_s &= \{(x_i,y_i)\}_{i=1}^{n}\sim T(s),\\ \mathcal{L}(\theta_s) &= -\sum_{(x,y)\in D_s}\log p_{\theta_s}(y\mid r_s(x)). \end{aligned}\]

각 예제에서 teacher가 제시한 출력 문자열의 확률을 높이는 supervised objective다. 시퀀스 출력의 로그우도이므로 실제 최적화에서는 정답 토큰들을 예측하도록 학습한다. 논문은 별도의 강화학습 reward나 여러 후보 사이의 preference loss를 핵심으로 도입하지 않는다. 학습 가능한 adapter를 줄인다고 해서 정답 데이터의 품질에 덜 의존하게 되는 것도 아니다.

평가 지표인 LEM은 이 손실 함수와 구별해야 한다. 모델은 teacher가 준 특정 문자열을 학습하지만, 평가에서는 명세상 타당한 다른 표현도 맞는 것으로 인정할 수 있다. 예를 들어 출력 형식이 강제되지 않은 상황에서 같은 항목을 담은 줄 목록과 JSON 배열을 어떻게 다룰지는 judge의 명세 해석에 달려 있다. 학습 목표의 문자열 단위 supervision과 최종 사용 목적의 의미적 동등성 사이에 간격이 존재한다.

학습 데이터와 파이프라인

Public Finetuned Standard 설정

부록 A의 Table 2에 기록된 공개 설정은 다음과 같다. 함수마다 독립적인 합성 데이터를 준비하며, 기반 interpreter는 공유한다.

구성 요소	공개 설정
Interpreter	Quantized local runtime의 Qwen3-0.6B
Teacher	GPT-5.4-mini와 GPT-5.5, 2:1 혼합
데이터	고유 입출력 쌍 2,400개를 6,400개 학습 예제로 확장
Adapter	LoRA rank 64, alpha 16
초기값	Amortized compiler의 hypernetwork initialization
최적화	Batch 48, 100 steps, cosine learning-rate decay
실행 방식	Shuffled batches, 합성과 학습의 중첩

고유 예제 수와 학습용으로 확장된 예제 수는 같은 양이 아니다. 기존 쌍을 반복해 학습 자료를 늘리면 같은 감독 신호를 더 사용할 수 있지만, 새로운 입력 상황이 그만큼 추가되지는 않는다. 따라서 6,400개라는 숫자를 모두 다른 문제 6,400개로 읽으면 데이터 다양성을 과대평가하게 된다.

Batch 48과 100 steps의 곱은 4,800으로, 준비된 학습 예제 수 6,400과 다르다. 표는 데이터 준비 규모와 최적화 설정을 각각 제시하지만, 각 예제가 몇 번 사용되는지까지 설명하지는 않는다. 따라서 이 숫자들만으로 전체 데이터를 몇 epoch 학습했는지 역산하기 어렵다.

Teacher 혼합 실험과 데이터 규모 실험의 조건

부록 C는 두 sweep의 설정을 따로 명시한다. Teacher 혼합 비교는 고유 쌍 3,600개를 반복해 6,400개 학습 세트로 만들고, batch 64, learning rate 0.0002, 100 steps를 고정한다. 반면 데이터 규모 비교는 batch 48, learning rate 0.0002, 100 steps를 사용한다. 두 결과가 같은 Table 1에 있다는 이유만으로 동일 조건의 단일 ablation으로 합칠 수 없다.

이 차이는 3,600쌍 조건의 점수가 한쪽에서는 0.851, 다른 쪽에서는 0.836인 것을 읽을 때 중요하다. 고유 데이터 수 하나만 같다고 나머지 학습 조건까지 동일하지는 않다. 공개 서비스의 기본 recipe, teacher 구성 비교, 데이터 규모 비교를 서로 다른 실험 단위로 유지해야 어떤 변화가 무엇과 비교되었는지 보인다.

실험 결과

FuzzyBench-Hard의 의미 기반 정확도

Figure 4: FuzzyBench-Hard의 평균 LEM. 가로축 0~1 범위에서 Amortized PAW 0.224와 Compile by Training 0.836, 절대 차이 0.612.

FuzzyBench-Hard는 기존 FuzzyBench 중 빠른 PAW compiler가 exact match를 하나도 만들지 못한 명세들로 구성된다. 여기서 중요한 단위는 기준 모델의 실패를 이용해 선택한 명세의 부분집합이라는 점이다. 무작위로 추출한 모든 자연어 함수의 대표 표본이라는 주장은 아니다.

평가에는 문자열의 완전 일치 대신 LLM Exact Match, 즉 LEM을 사용한다. 이름에 Exact Match가 있지만 판정 대상은 명세에 따른 의미적 정확성이다. Judge는 명세, 입력, reference output, 모델 출력을 함께 보고 각 결과를 맞음 또는 틀림으로 분류한다. Reference는 허용 가능한 정답의 하나이며, 출력이 문자 단위로 같아야 한다는 요구는 아니다.

이 기준에서 Compile by Training은 0.836, 빠른 Amortized PAW는 0.224다. 백분율로는 83.6%와 22.4%이며 절대 개선은 61.2%p다. 기존 모델이 exact match를 전혀 하지 못한 부분집합에서도 LEM이 0이 아닌 이유가 바로 지표의 차이다. 이 둘을 혼동해 “정확도 0%를 83.6%로 올렸다”고 설명하면 비교 기준을 바꾸게 된다.

반대 방향의 과장도 피해야 한다. 의미 기반 지표라고 해서 형식 오류를 모두 용인하는 것은 아니다. 부록 E는 명세가 JSON 문자열 배열 같은 형식을 명시하면 엄격하게 적용하도록 한다. 값의 오류, 항목의 누락·추가, 요구된 순서의 위반, 부적절한 거부도 오답이다. 형식이 지정되지 않은 경우에만 포장 방식의 차이를 허용한다.

LEM judge의 저자 라벨 일치도

부록 B는 저자가 라벨링한 128개 사례에서 judge를 검증한다. 이 128개는 FuzzyBench-Hard 전체 평가 규모를 뜻하는 숫자가 아니라 채점기 검증 표본이다.

Judge	표본 수	정확도	False positive rate	False negative rate	Cohen’s kappa
GPT-5.5	128	0.977	0.025	0.023	0.946
GPT-5.4-mini	128	0.938	0.050	0.068	0.858

선택된 GPT-5.5는 이 표본에서 더 높은 일치도를 보인다. 다만 97.7%라는 채점기 검증 정확도는 학습된 함수의 정확도가 아니다. 또한 이 결과를 모든 함수 명세와 출력 유형에 대한 완전한 judge 신뢰성으로 확대할 수도 없다. 논문의 주 지표를 해석할 때에는 모델의 오류와 채점기의 오류가 서로 다른 층위에 있다는 점이 필요하다.

Cold compile 시간과 동시 작업 대기

논문은 빠른 compiler의 3.5초와 학습 기반 compiler의 50.9초를 비교한다. 별도의 서비스 측정에서는 teacher 출력 캐시가 없는 동일한 대표 명세를 컴파일했을 때 B300 50.9초, H200 68.2초, RTX GPU 99.2초를 기록했다. RTX의 구체적인 제품명은 제시되지 않으므로 다른 GPU 모델을 임의로 붙일 수 없다.

여기서 cold는 teacher 출력이 캐시에 없다는 조건이다. 모든 런타임 자원과 모델 파일이 완전히 제거된 기계에서의 최초 설치 시간을 뜻한다고 확대 해석하면 안 된다. 수치는 2026년 5월 서비스 출시 시점의 측정이며, 현재 API나 모든 명세에서 동일한 지연이 보장된다는 의미도 아니다.

네 개의 컴파일 작업을 동시에 제출한 부하 시험에서는 모두 완료되었고, 평균 큐 대기는 1.01초였으며 worker 활용이 고르게 나타났다. 이는 비동기 서비스가 여러 작업을 처리할 수 있음을 보여 준다. 하지만 동시 요청이 훨씬 많은 상황의 처리량이나 tail latency를 정량적으로 설명하는 결과는 아니다. 짧은 큐 대기와 한 작업이 완료되기까지의 전체 시간 역시 별개의 값이다.

결과 분석 / Ablation

Teacher 혼합의 품질 이득

Table 1: 개발용 명세의 teacher 혼합·데이터 규모 sweep. 상단 두 행의 teacher 구성 비교와 하단 네 행의 고유 예제 수별 평균 LEM.

고유 쌍 3,600개를 사용하는 혼합 실험에서 GPT-5.4-mini만 만든 데이터는 LEM 0.746이다. 그중 1,200개를 GPT-5.5 데이터로 바꿔 mini 2,400개와 GPT-5.5 1,200개를 섞으면 0.851로 오른다. 동일한 고유 예제 수에서 10.5%p 개선이므로, 단순히 예제 수가 늘어서 좋아졌다는 설명으로는 충분하지 않다.

이 결과는 저비용 teacher로 양을 확보하고 더 큰 teacher의 supervision으로 보완하는 설계를 지지한다. 그러나 2:1이 모든 과제의 최적 혼합비라는 뜻은 아니다. 표에 제시된 비교만으로 teacher의 정답 품질, 입력 다양성, 어려운 사례의 비중 중 어느 요소가 개선을 만들었는지 분리할 수도 없다. 확인된 것은 해당 조건에서 teacher 구성이 바뀌면 평균 점수도 의미 있게 달라졌다는 사실이다.

고유 데이터 수와 고정된 학습 예산

데이터 규모 sweep의 LEM은 1,440쌍에서 0.821, 2,400쌍에서 0.836, 3,600쌍에서도 0.836, 7,200쌍에서 0.866이다. 관찰된 추세는 대체로 더 다양한 supervision이 도움이 될 수 있음을 보여 주지만, 각 구간에서 개선이 똑같지는 않다. 특히 2,400에서 3,600으로 늘린 결과를 뚜렷한 이득으로 서술해서는 안 된다.

Step 수를 고정한 sweep은 데이터 다양성과 제한된 최적화 예산 사이의 관계를 본다. 모든 데이터 크기에서 충분히 수렴시킨 뒤의 상한을 비교한 실험이라고 설명하기 어렵다. 또한 0.866은 데이터 규모 실험의 가장 큰 조건에서 나온 값이며, 논문의 대표 비교인 0.836을 대체하는 동일 설정의 최종 성능은 아니다.

실무적인 해석은 “더 오래 학습하면 항상 더 좋아진다”보다 좁다. 어떤 사례를 누가 만들어 주느냐와 몇 종류의 사례를 접하느냐가 모두 중요하다. 같은 출력 쌍을 반복해서 사용하는 것과 새로운 입력 분포를 추가하는 것은 서로 다른 선택이며, 함수의 오류를 개선할 때도 이 둘을 따로 진단해야 한다.

Paw-helper의 함수 조합과 일반 코드

Figure 5: (a) 현재 페이지와 질문에 따른 프로그램 트리 및 course·Piazza 답변 결합 경로. (b) 강의 답변과 클릭 가능한 인용을 제공하는 CS486 도우미 화면.

Paw-helper는 논문 시점의 content pack에 30개 프로그램을 담고, 그중 28개를 live routing에 사용한다. 나머지 두 개는 평가와 하위 호환성을 지원한다. 하나의 backend가 저자의 개인 사이트, Waterloo CS486 강의 사이트, NeuralOS, PAW 사이트의 네 문맥을 처리한다. 질문 하나가 28개 함수를 모두 실행하는 구조는 아니다. 현재 사이트·페이지에 맞춰 트리의 일부를 지난다.

과제 변경 사항을 묻는 질문을 예로 들면, 먼저 링크가 필요한지 서술형 답변이 필요한지 분류한다. 강의 페이지에서 답변을 만드는 경로와 Piazza를 BM25로 검색하는 경로를 병렬로 진행하고, 검색 결과를 다루는 함수를 거쳐 마지막 함수가 강의 답변, Piazza 답변, 또는 둘을 합친 결과를 선택한다. 검색과 캐시, 분기 제어는 일반 코드의 역할로 남는다.

이 데모가 보여 주는 것은 하나의 큰 모델이 모든 판단과 제어를 떠맡지 않아도 응용을 구성할 수 있다는 점이다. 다만 함수가 여러 개 연결되면 첫 router의 실수가 뒤의 올바른 answerer까지 잘못된 문맥으로 이끌 수 있다. 논문은 이 조합을 시연하지만, 각 노드의 오류가 end-to-end 성공률에 얼마나 누적되는지를 체계적으로 측정한 사용자 연구까지 제시하지는 않는다.

Avatar DSL과 양방향 문체 변환

Figure 6: (a) 자연어 동작 요청, (b) 생성된 action DSL과 허용 동사·AST 범위 검사, (c) 검증된 동작을 표현하는 브라우저의 3D avatar.

Avatar Director는 자연어 요청을 작은 action DSL로 바꾼다. DSL은 순서, 지속 시간, 반복, 양립 가능한 병렬 동작을 표현하며, 브라우저 코드는 이를 파싱하고 검증한 뒤 캐릭터를 움직인다. 손으로 작성한 44개 검증 명령 중 43개에서 기대한 action 구조를 생성했다. 이 수치는 해당 검증셋에서의 구조적 일치이며, 임의의 사용자 명령 전체에 대한 안전성이나 정확성 보장은 아니다.

특히 브라우저에서 동작하는 범위를 정확히 읽어야 한다. Figure 6이 명시하는 것은 DSL 해석과 3D rendering이다. 웹 데모에서 neural inference까지 전부 브라우저 안에서 실행된다고 이 그림만으로 주장할 수는 없다. 사용자가 자유롭게 표현하는 부분을 모델에 맡기면서 실행 가능한 행동 범위를 코드로 제한한다는 설계가 핵심이다.

또 다른 응용인 Claudish는 특정 AI 문체를 흉내 내는 방향과 평이한 영어로 되돌리는 방향을 별도 명세로 작성하고, 각각 하나의 adapter를 학습한다. 두 방향 모두 의미 보존이 요구되지만, 같은 가중치를 단순히 역으로 사용하는 것은 아니다. 논문은 2026년 8월 22일부터 9월 2일까지 웹 데모에서 성공적으로 처리된 번역 요청 100,747건을 보고한다. 이는 사용량과 처리 성공의 기록이지, 100,747건 모두의 의미 보존을 사람이 검증했다는 지표가 아니다.

한계와 비판적 평가

명세의 모호성·teacher 오류·분포 이동

저자가 명시한 첫 번째 한계는 합성 supervision이 teacher의 오류를 물려받을 수 있다는 점이다. 여기에 리뷰어 관점에서 더해 볼 문제는 명세가 애초에 모호할 때다. Teacher가 일관된 해석으로 예제를 만들면 작은 모델은 그 해석을 잘 배우더라도 사용자가 의도한 동작과 어긋날 수 있다. 학습 loss가 내려갔다는 사실만으로 이 간격을 발견하기 어렵다.

배포 후 입력 분포가 달라지는 문제도 남는다. 정해진 강의 문맥이나 스타일 변환에서 작동한 함수가 새로운 도메인 표현을 같은 수준으로 처리할지는 별도로 확인해야 한다. 프로그램이 파일로 고정된다는 장점은 실행 중 자동으로 새 지식에 맞춰진다는 뜻이 아니다. 명세 변경과 재컴파일, 회귀 검증의 운영 절차는 실제 응용이 준비해야 할 부분이다.

평가 부분집합과 baseline의 범위

FuzzyBench-Hard는 빠른 PAW가 어려워한 명세에 초점을 맞추므로, 이 compiler의 약점을 추가 연산으로 얼마나 보완하는지 보기에는 적절하다. 그러나 부분집합의 선택 과정 자체가 비교 대상의 실패와 연결된다. 전체 FuzzyBench나 실제 서비스의 입력 분포에서도 61.2%p 개선이 유지된다고 결론 내릴 수 없다.

또한 이 논문의 핵심 비교만으로는 작은 interpreter에 명세를 직접 prompting한 경우, warm start 없이 같은 데이터로 학습한 경우, teacher를 매 입력에 직접 호출한 경우의 상대적인 효율을 모두 알 수 없다. 결과는 추가 합성·학습 경로 전체의 유효성을 보여 주지만, 초기 adapter가 얼마나 기여했는지나 end-to-end 비용의 최선 선택까지 분리하지는 않는다.

Judge 의존성과 반복 사용의 경제성

GPT-5.5 judge를 128개 저자 라벨로 점검한 것은 근거 없이 자동 채점을 사용하는 것보다 낫다. 그렇더라도 함수 유형별 채점 오류나 teacher와 judge가 공유하는 판단 성향을 배제하는 증거는 아니다. 여기서는 이를 실제로 발생한 편향이라고 단정하기보다, 독립적인 검증으로 더 확인할 여지가 있는 평가상의 제약으로 보는 것이 맞다.

비용 측면에서는 컴파일 시간이 제시되지만 teacher 호출의 금액, 대표 기기별 함수 실행 지연, 동일 품질 조건의 원격 추론 비용을 함께 묶은 분석이 부족하다. 따라서 몇 번 호출하면 컴파일 비용을 회수하는지 특정 숫자로 계산할 근거가 없다. 반복 사용이 많을수록 준비 비용을 나눌 수 있다는 구조적 장점과, 실제 총비용 절감이 입증되었다는 주장은 구분해야 한다.

결정적 제어와 의미적 정확성의 간격

출력의 타입과 DSL 문법을 검사하면 허용되지 않은 구조를 막을 수 있지만, 허용된 구조가 사용자의 의도에 맞는지는 별도 문제다. 예를 들어 순서가 있는 동작 요청에서 허용된 동사를 잘못된 순서로 생성하면 parser를 통과하더라도 과제는 실패한다. Paw-helper의 답변 validator 또한 하나의 학습된 함수라면 절대적인 정답 oracle로 취급할 수 없다.

저자들은 보장된 정확성이 필요한 응용에서 출력 검증이나 결정적 제어 경로를 유지하라고 명시한다. 응용 증거의 초점도 함수 조합과 구조화된 실행에 있으며, 체계적인 사용자 연구는 후속 과제로 남긴다. 따라서 이 연구의 성과는 신경망으로 일반 프로그램의 보장을 대체한 데 있기보다, 검증 가능한 코드와 결합할 수 있는 작은 학습 요소를 손쉽게 만드는 데 있다.

시사점 / Takeaways

큰 모델을 호출하는 시점을 설계할 수 있다. 반복되는 좁은 판단에서는 매 입력의 추론뿐 아니라 함수를 준비하는 build 단계에 계산을 배정하는 선택지가 생긴다.
프로그램의 구성은 가중치만이 아니다. Adapter, 실행 scaffold, interpreter 메타데이터가 함께 동작을 결정하므로 이들을 한 결과물로 관리하는 방식이 중요하다.
합성 데이터의 양과 품질을 따로 봐야 한다. Teacher 혼합의 10.5%p 이득과 데이터 규모에 따른 비균일한 개선은 supervision 설계를 독립적인 최적화 대상으로 만든다.
83.6%를 평가 정의와 함께 기억해야 한다. 기준 모델의 실패 명세를 모은 부분집합에서 얻은 LEM이며, 전체 과제의 문자열 정확도나 실행 보장이 아니다.
Neural function과 일반 코드의 역할 분담이 실용성의 중심이다. 모호한 의미 판단을 학습하더라도 검색, 타입 검사, 실행 범위와 실패 경로는 명시적으로 유지할 수 있다.

설치 및 사용법

공개 Claudish 저장소의 README와 translate.py는 다음 SDK 사용 방식을 제공한다. 아래는 이미 컴파일된 프로그램을 불러오는 예제이며, 새 함수 학습을 재현하는 코드는 아니다. 설치 및 API 형태를 공개 소스와 대조했으며, 이 리뷰에서 모델 다운로드와 실제 추론 성능을 다시 측정하지는 않았다.

pip install programasweights --extra-index-url https://pypi.programasweights.com/simple/

import programasweights as paw

to_claudish = paw.function("ca9d5165b6c8e6615529")
to_english = paw.function("e469f61ccab2699fbd51")

text = to_claudish("Only owners can merge.")
print(text)
print(to_english(text))

저장소 설명에 따르면 프로그램은 한 번 내려받은 뒤 로컬에서 실행한다. 생성은 EOS에서 끝나므로 예제는 max_tokens를 지정하지 않는다. 원문을 두 방향으로 통과시켰다고 완벽한 round trip이 보장되는 것은 아니다. 두 프로그램은 의미 보존을 목표로 별도로 학습되었으며, 중요한 사실이나 조건이 유지되는지는 사용 목적에 맞게 확인해야 한다.

새로운 함수는 PAW playground에서 명세를 작성하고 Finetuned Standard로 컴파일하는 흐름을 사용할 수 있다. 웹사이트 도우미 코드는 별도의 paw-helper 저장소에 공개되어 있다. 이 저장소는 local SDK와 remote inference 경로를 구분하므로, “PAW를 사용한다”는 이유만으로 모든 응용 입력이 로컬에 남는다고 가정해서는 안 된다.

참고 자료

Compile by Training 원문: Deng, Nie, Shieber의 arXiv v1. 본 리뷰의 실험 수치와 그림은 이 버전을 기준으로 설명.
PAW playground: 공개 Finetuned Standard compiler 데모.
Paw-helper 코드 · Claudish 코드와 명세: 논문 응용의 공개 구현.
그림·표 출처: Deng et al., Figures 1~6 및 Table 1. 원문 라이선스 CC BY 4.0. 원문 그림에 한국어 설명 캡션 추가.

더 읽어보기

Program-as-Weights: A Programming Paradigm for Fuzzy Functions (Zhang et al., 2026): 자연어 명세에서 adapter를 예측하는 빠른 compiler와 공유 interpreter의 기반 연구.
Prompt2Model: Generating Deployable Models from Natural Language Instructions (Viswanathan et al., 2023): 과제 설명에서 데이터 준비와 fine-tuning을 거쳐 배포 모델을 만드는 선행 시스템.
LoRA: Low-Rank Adaptation of Large Language Models (Hu et al., ICLR 2022): 기반 모델을 고정하고 작은 저랭크 업데이트로 동작을 특화하는 방법.
Self-Instruct: Aligning Language Models with Self-Generated Instructions (Wang et al., ACL 2023): 모델이 생성한 instruction 데이터를 supervision으로 사용하는 접근.