자연어 규칙을 작은 로컬 함수로 컴파일합니다 | DAKER 커뮤니티

자연어 규칙을 작은 로컬 함수로 컴파일합니다 썸네일
자연어 규칙을 작은 로컬 함수로 컴파일합니다

원문: https://arxiv.org/abs/2609.04199

논문: Compile by Training: Turning Natural-Language Specifications into Local Neural Functions

저자: Yuntian Deng, Pengyu Nie, Stuart Shieber

제출: 2026년 9월 3일 17:59:49 UTC

비고: EMNLP 2026 System Demonstrations

확인한 사실

빌더가 볼 지점

오늘 고른 첫 번째 논문은 자연어로 적은 반복 작업 규칙을 매번 큰 원격 모델에 보내지 않고, 작은 로컬 함수처럼 재사용하려는 시도입니다. 논문 제목은 Compile by Training: Turning Natural-Language Specifications into Local Neural Functions입니다. 저자는 Yuntian Deng, Pengyu Nie, Stuart Shieber입니다. arXiv 제출 이력은 2026년 9월 3일 17:59:49 UTC의 v1입니다. 코멘트에는 EMNLP 2026 System Demonstrations가 적혀 있습니다.

핵심 문제는 단순합니다. 제품 안에는 사람이 말로 설명하기는 쉽지만 규칙 코드로 구현하기는 까다로운 텍스트 함수가 많습니다. 예를 들면 입력 문장을 내부 표기법으로 바꾸거나, 고객 메모에서 특정 패턴만 추출하거나, 애매한 표현을 조직의 기준에 맞게 정규화하는 작업입니다. 지금은 이런 작업을 큰 모델 API 호출로 처리하는 경우가 많습니다. 그러나 입력이 들어올 때마다 원격 모델을 부르면 비용, 지연 시간, 외부 제공자 의존성이 계속 붙습니다.

논문이 제안하는 방향은 이 반복 호출을 컴파일 문제로 다시 보는 것입니다. 사용자는 자연어 명세를 씁니다. 컴파일 시점에는 teacher model이 그 명세에 맞는 과제별 예시를 만들고, 그 예시로 compact interpreter에 붙는 small adapter를 학습합니다. 컴파일이 끝난 뒤에는 teacher model 없이 결과 함수를 실행합니다. 논문은 이 결과물을 저장하고, 버전으로 관리하고, 일반 소프트웨어처럼 조합할 수 있다고 설명합니다.

숫자로 확인할 수 있는 결과도 있습니다. 논문은 FuzzyBench-Hard라는 부분집합에서 semantic accuracy 83.6%를 보고합니다. 이 부분집합은 Program-as-Weights fast compiler가 exact match를 만들지 못한 과제라고 설명됩니다. 대신 비용도 분명히 밝힙니다. fast compiler가 seconds 단위로 끝나는 쪽이라면 compile by training은 roughly a minute 수준의 compile-time cost가 듭니다. 즉 즉석 호출을 줄이려면 앞단에서 학습 시간을 지불해야 한다는 구조입니다.

빌더에게 중요한 점은 모델 호출을 모두 에이전트나 챗봇으로만 보지 않아도 된다는 점입니다. 반복되는 텍스트 변환은 서비스 내부 함수처럼 다뤄질 수 있습니다. 함수 이름, 입력 예시, 실패 예시, 버전, 배포 위치를 정해 두면 운영자는 매 요청을 프롬프트로 다시 설명하지 않아도 됩니다. 특히 데이터 정제, 고객 지원 문구 정규화, 내부 태그 부여처럼 같은 기준을 오래 써야 하는 작업에 맞습니다.

다만 이 논문은 만능 코드 생성기가 나온 이야기로 읽으면 안 됩니다. 논문이 말하는 대상은 recurring text functions입니다. 어려운 업무 절차 전체를 대신 수행한다기보다, 자연어로 정의하기 쉬운 특정 텍스트 함수를 작은 모델 구성요소로 굳히는 방향입니다. 또한 컴파일 시 teacher model이 만든 예시에 품질이 걸립니다. 명세가 애매하면 컴파일된 함수도 애매한 기준을 학습할 수 있습니다.

오늘 적용하려면 먼저 반복 API 호출 목록을 적어 보십시오. 그중 사람에게 다시 설명하지 않아도 되는 텍스트 변환을 하나 고르십시오. 입력, 기대 출력, 실패하면 안 되는 예외, 사람이 검수할 샘플 수를 정하십시오. 그 다음에는 큰 모델 호출 비용과 지연 시간을 현재 기준으로 재십시오. 논문이 말한 로컬 함수 접근은 호출량이 적은 기능보다 반복량이 많은 기능에서 먼저 의미가 생깁니다.

검증도 함수 단위로 해야 합니다. 성공 예시만 모으면 운영 중에 기준이 흔들립니다. 반례, 비슷하지만 다른 입력, 금지 출력, 빈 입력, 길이가 긴 입력을 함께 넣어야 합니다. 일반 코드 함수처럼 regression set을 만들고, 명세가 바뀔 때는 새 버전을 따로 기록하십시오. 이렇게 해야 로컬화가 비용 절감으로 끝나지 않고 품질 관리 방식으로 이어집니다.

제품팀 관점에서는 이 접근이 워크플로 설계도 바꿉니다. 지금까지는 '이 기능에 모델 API를 붙인다'가 기본 문장이었습니다. 이 논문을 읽고 나면 '이 반복 판단은 컴파일해서 제품 내부 함수로 둘 수 있는가'라는 질문을 먼저 할 수 있습니다. 즉 실시간 추론과 사전 컴파일을 나누는 기준이 생깁니다. 낮은 지연 시간, 예측 가능한 비용, 외부 장애 완화가 중요한 경우에는 이 구분이 바로 설계 변수가 됩니다.

적용 후보를 고를 때는 세 가지를 보십시오. 첫째, 입력 형식이 어느 정도 반복됩니까. 둘째, 결과가 사람이 바로 검토할 수 있는 짧은 출력입니까. 셋째, 실패했을 때 되돌리기 쉽습니까. 이 세 조건을 만족하면 compile by training식 접근을 실험하기 좋습니다. 반대로 긴 reasoning, 외부 도구 호출, 사용자별 정책 판단이 섞이면 작은 로컬 함수보다 기존 에이전트 흐름을 유지하는 편이 낫습니다.

데이터 관리도 따로 정해야 합니다. teacher model이 만든 예시는 학습 데이터가 됩니다. 어떤 명세에서 어떤 예시가 만들어졌는지, 사람이 고친 예시가 무엇인지, 배포된 adapter가 어느 데이터 묶음에서 나왔는지를 남기십시오. 그래야 나중에 출력 기준이 바뀌었을 때 원인을 추적할 수 있습니다. 작은 모델이라고 해서 운영 기록이 작아져도 되는 것은 아닙니다.

마지막으로 비용 비교는 호출 단가만 보면 부족합니다. 컴파일 시간, 샘플 생성 비용, 재학습 빈도, 로컬 서빙 비용, 실패 검수 시간을 함께 보십시오. 자주 바뀌는 규칙은 매번 다시 컴파일해야 하므로 이득이 줄어듭니다. 안정적으로 오래 쓰는 규칙은 앞단 비용을 나눠 가질 수 있어 이득이 커집니다.

도입 결정을 내릴 때는 기존 코드 함수와 같은 승인 절차를 두십시오. 누가 명세를 바꿀 수 있는지, 누가 예시를 승인하는지, 어떤 테스트를 통과해야 배포되는지 정해야 합니다. 모델 기반 함수라도 제품에서는 함수입니다. 이름, 소유자, version, rollback 절차가 없으면 운영자는 나중에 같은 출력을 재현하기 어렵습니다.

작은 실험의 종료 조건도 정해 보십시오. 같은 명세로 100개 샘플을 돌려 사람이 고친 비율이 얼마 이하일 때만 다음 단계로 갑니다. 실패가 특정 입력 유형에 몰리면 모델 교체보다 명세 보강이 먼저입니다. 성공 기준을 미리 적어야 기술 데모와 제품 도입을 구분할 수 있습니다.

한 줄 요약은 이것입니다. 반복되는 자연어 판단을 매번 호출하지 말고, 제품 안에서 관리되는 작은 실행 단위로 굳힐 수 있는지 검토하십시오. 오늘은 후보 업무 하나만 고르고, 기존 호출 로그와 실패 샘플부터 모으십시오.

원문은 아래 arXiv 링크에서 확인할 수 있습니다.