LLM을 매번 부르지 않고, 작은 함수로 남기는 상상

제일 먼저 든 생각

업무 자동화를 만들다 보면 이상한 함수들이 생긴다. “중요한 로그만 알려줘”, “이 검색 결과가 내 의도와 맞는지 판단해줘”, “깨진 JSON을 고쳐줘”, “이 요청에는 어떤 도구를 불러야 하는지 골라줘” 같은 함수들이다. 규칙으로 쓰기엔 너무 애매하지만, 큰 LLM API를 매번 부르기엔 비용·속도·재현성이 부담스럽다.

이 논문은 그 중간 지대를 겨냥한다. 자연어로 적은 애매한 함수(fuzzy function)를 큰 모델이 한 번 읽고, 작은 로컬 실행물로 컴파일한다. 이후 호출은 매번 거대 모델을 부르지 않고, 작은 인터프리터와 함수별 LoRA 어댑터가 처리한다. 저자들은 이 방식을 Program-as-Weights(PAW)라고 부른다.

PAW는 큰 모델을 매 요청의 문제 해결자로 쓰는 대신, 애매한 업무 함수를 한 번 컴파일해 로컬에서 반복 실행하는 방향을 제안한다.

큰 모델은 문제 해결자에서 도구 제작자로 이동한다

논문의 문제의식은 선명하다. 현실의 많은 프로그래밍 과제는 명확한 규칙으로 닫히지 않는다. 로그 중요도 판별, 의도 기반 검색 재정렬, 자연어 명령 분류, 형식 오류 복구처럼 사람은 대략 알지만 코드로 완전히 적기 어려운 일이 많다. 지금은 이런 일을 LLM API 호출로 처리하는 경우가 많다.

저자들은 이 접근이 편리하지만 비용, 취약성, 재현성, 오프라인 실행성 측면에서 문제가 있다고 본다. 그래서 큰 모델을 매번 호출되는 해결사가 아니라, 함수를 만드는 컴파일러로 바꾸자고 제안한다.

“PAW는 파운데이션 모델을 입력마다 호출되는 문제 해결자가 아니라 도구 제작자로 다시 놓는다.”

“PAW reframes the foundation model from a per-input problem solver into a tool builder.”

이 문장이 실무적으로 걸렸다. 에이전트 자동화에서 비용이 커지는 이유는 많은 단계가 “작은 판단”인데도 매번 큰 모델을 부르기 때문이다. 라우팅, 필터링, 검증, 재랭킹, 경고 판별 같은 단계는 한 번 설계하면 반복 호출된다. 이런 단계를 독립적인 작은 함수로 빼낼 수 있다면, 전체 워크플로의 비용 구조가 달라진다.

컴파일 한 번, 실행은 로컬에서

논문이 제안하는 구조는 세 단계다. 개발자가 자연어로 함수 사양을 쓴다. 신경망 컴파일러가 그 사양을 작은 신경망 프로그램으로 바꾼다. 고정된 경량 인터프리터가 그 프로그램을 로컬에서 실행한다. 구체 구현에서는 4B Qwen3 계열 컴파일러가 pseudo-program과 LoRA를 만들고, 0.6B Qwen3 인터프리터가 실행한다.

초록의 수치는 이 방향의 가능성을 보여준다. 0.6B Qwen3 인터프리터가 PAW 프로그램을 실행했을 때 Qwen3-32B 직접 프롬프팅과 비슷하거나 더 나은 성능을 냈고, 추론 메모리는 약 1/50 수준이었다고 보고한다. MacBook M3에서는 양자화된 구성으로 초당 약 30토큰 속도를 냈다. 논문 본문에서는 Q6_K base + Q4_0 LoRA가 bf16과 거의 구분되지 않는 정확도를 보였고, 함수별 어댑터는 약 23MB 규모로 제시된다.

“컴파일된 프로그램은 캐시하고, 버전 관리하고, 오프라인에서 라이브러리 함수처럼 호출할 수 있는 하나의 파일이다.”

“The compiled program is a single file that can be cached, version-controlled, and called offline like any other library function.”

여기서 중요한 것은 “작은 모델이 큰 모델을 이겼다”는 식의 단순 결론이 아니다. 특정 fuzzy function을 반복 실행하는 상황에서는, 함수 사양을 명확히 하고 한 번 컴파일한 뒤 같은 런타임에서 재사용하는 구조가 실용적일 수 있다는 점이다.

원문 첫 페이지. PAW는 자연어 사양 → 신경망 프로그램 → 로컬 실행이라는 컴파일러-인터프리터 구도를 제안한다.

Deciflow 자동화에 붙여본다면

Slot 3, Deciflow 실무 와일드카드로 보면 이 논문은 에이전트 설계의 비용 절감 아이디어라기보다 워크플로 분해법에 가깝다. 모든 단계를 하나의 거대한 프롬프트로 묶는 대신, 반복되는 판단을 작은 함수로 이름 붙이는 것이다.

예를 들어 이런 함수들이 후보가 된다.

• 터미널 로그에서 사용자가 봐야 할 줄만 ALERT/QUIET로 분류하기
• 검색 결과 20개를 질문 의도에 맞게 exact/high/some/not relevant로 재랭킹하기
• 사용자의 요청이 도구 호출이 필요한지 먼저 판별하기
• 보고서 초안에서 개인정보나 공개 위험 문장을 찾아내기
• 교육평가 답안에서 루브릭 기준 누락 여부를 1차 표시하기

PAW가 당장 모든 업무에 적용 가능한 성숙한 제품이라는 뜻은 아니다. 하지만 “이 판단은 매번 큰 LLM을 부를 만큼 복잡한가, 아니면 독립 함수로 굳힐 수 있는가”라는 질문은 지금의 RAG·에이전트 설계에도 바로 쓸 수 있다.

조심해서 읽을 점

이 논문은 새로운 프로그래밍 패러다임을 제안하는 연구라 기대와 한계가 함께 있다. 논문이 보여준 수치는 특정 벤치마크와 구현 조건에서의 결과다. 수치 계산, 문자 위치 추적, 복잡한 JSON 구성 같은 실패 모드도 본문에서 언급된다. 따라서 “모든 LLM 호출을 작은 LoRA로 대체할 수 있다”고 읽으면 과하다.

다만 방향은 흥미롭다. 업무 자동화의 다음 질문은 “어떤 모델을 쓸까”에서 “어떤 판단을 함수로 고정할까”로 이동할 수 있다. 내일 작은 실험을 한다면, 기존 에이전트 프롬프트 하나를 열어 반복되는 판단 3개를 함수 이름으로 뽑아볼 것이다. 큰 모델을 더 잘 부르는 법보다, 큰 모델을 덜 자주 부르게 만드는 구조가 더 오래 남을 수 있다.

원문 정보

• 제목: Program-as-Weights: A Programming Paradigm for Fuzzy Functions
• 저자: Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, Yuntian Deng
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2607.02512v1
• PDF: https://arxiv.org/pdf/2607.02512

원문 논문: Program-as-Weights: A Programming Paradigm for Fuzzy Functions