자연어 명세를 작은 로컬 함수로 바꾸는 방법, Compile by Training 논문이 보여준 가능성 | DAKER 커뮤니티

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

한 줄 답: 반복되는 텍스트 처리 규칙을 매번 큰 모델 API에 보내는 방식은 익숙하지만, 비용과 지연 시간, 외부 의존성도 함께 따라옵니다 관련 일정 예: ; 2026년 9월 3일 17:59.

데이콘·DAKER 커뮤니티 기준으로 정리한 안내입니다.

반복되는 텍스트 처리 규칙을 매번 큰 모델 API에 보내는 방식은 익숙하지만, 비용과 지연 시간, 외부 의존성도 함께 따라옵니다. 특히 제품 안에서 오래 유지해야 하는 규칙이라면, 실시간 호출보다 다른 구조가 더 나을 수 있습니다.

이번 논문은 이 문제를 컴파일 관점에서 다시 봅니다. 자연어로 적은 규칙을 한 번 학습해 두고, 이후에는 작은 로컬 함수처럼 재사용하자는 제안입니다. 텍스트 변환을 서비스 내부의 실행 단위로 다루고 싶은 팀이라면 지금 읽어볼 만합니다.

원문: 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

무엇을 제안하나

논문은 자연어 명세를 재사용 가능한 neural function으로 바꾸는 compile by training을 제안합니다. 대상은 논문 표현대로 recurring text functions입니다. 사람이 말로 설명하기는 쉽지만, 규칙 코드로 만들기는 번거로운 텍스트 함수들을 작은 모델 구성요소로 굳히는 접근입니다.

예를 들면 입력 문장을 내부 표기법으로 바꾸거나, 고객 메모에서 특정 패턴만 추출하거나, 애매한 표현을 조직 기준에 맞게 정규화하는 작업이 여기에 가깝습니다. 이런 작업은 지금도 큰 모델 API 호출로 처리하는 경우가 많지만, 요청이 들어올 때마다 원격 모델을 부르면 비용과 지연 시간이 계속 누적됩니다.

반복되는 자연어 규칙을 매번 원격 호출로 처리하지 않고, 제품 안에서 관리되는 작은 실행 단위로 바꾸려는 시도입니다.

Compile by Training은 어떻게 동작하나

구조는 비교적 분명합니다. 사용자는 먼저 자연어 명세를 작성합니다. 컴파일 시점에는 teacher model이 그 명세에 맞는 과제별 예시를 만들고, 그 예시를 바탕으로 compact interpreter용 small adapter를 학습합니다.

이 과정을 마치면 실행 단계에서는 teacher model 없이 결과 함수를 사용할 수 있다고 설명합니다. 논문은 이 결과물을 저장하고, versioning하고, composition할 수 있는 함수처럼 다룰 수 있다고 말합니다.

컴파일 시에는 teacher model이 필요하지만, 실행 시에는 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가 든다고 밝힙니다. 즉 실시간 호출을 줄이는 대신, 앞단에서 학습 시간을 지불하는 구조입니다.

FuzzyBench-Hard에서 semantic accuracy 83.6%를 보고하지만, compile-time cost는 roughly a minute 수준이라고 밝힙니다.

빌더가 주목할 지점

이 논문이 흥미로운 이유는 모델 호출을 꼭 챗봇이나 에이전트 흐름으로만 보지 않아도 된다는 점입니다. 반복되는 텍스트 변환은 서비스 내부 함수처럼 다뤄질 수 있고, 함수 이름과 입력 예시, 실패 예시, 버전, 배포 위치를 정해 운영할 수 있습니다.

특히 데이터 정제, 고객 지원 문구 정규화, 내부 태그 부여처럼 같은 기준을 오래 유지해야 하는 작업에 잘 맞습니다. 낮은 지연 시간, 예측 가능한 비용, 외부 장애 완화가 중요한 경우에는 실시간 추론과 사전 컴파일을 나누는 기준이 될 수 있습니다.

만능 해법으로 읽으면 안 되는 이유

다만 이 논문을 범용 코드 생성기나 전체 업무 절차 자동화로 읽는 것은 맞지 않습니다. 논문이 겨냥하는 대상은 recurring text functions입니다. 복잡한 reasoning, 외부 도구 호출, 사용자별 정책 판단이 섞인 흐름 전체를 대신하기보다는, 자연어로 정의하기 쉬운 특정 텍스트 함수를 작은 로컬 구성요소로 만드는 방향에 가깝습니다.

또한 컴파일 시 teacher model이 만든 예시의 품질이 중요합니다. 명세가 애매하면 컴파일된 함수도 애매한 기준을 학습할 수 있습니다.

이 접근은 어려운 업무 절차 전체보다, 반복되는 특정 텍스트 함수를 굳히는 데 더 가깝습니다.

어떤 작업부터 실험해볼 만한가

적용 후보를 고를 때는 입력 형식이 어느 정도 반복되는지, 결과가 사람이 바로 검토할 수 있는 짧은 출력인지, 실패했을 때 되돌리기 쉬운지를 먼저 보는 것이 좋습니다. 이런 조건을 만족하면 compile by training식 접근을 시험해볼 여지가 있습니다.

반대로 긴 reasoning이 필요하거나 외부 도구 호출이 핵심이거나 사용자별 정책 판단이 자주 섞이면, 작은 로컬 함수보다 기존 에이전트 흐름을 유지하는 편이 더 적절할 수 있습니다.

도입 전에 함께 봐야 할 운영 요소

이 접근을 실제 제품에 붙이려면 검증과 데이터 관리도 함수 단위로 생각해야 합니다. 성공 예시만 모으기보다 반례, 비슷하지만 다른 입력, 금지 출력, 빈 입력, 긴 입력을 함께 넣어 regression set을 만드는 편이 좋습니다. 명세가 바뀌면 새 버전을 따로 기록해야 운영 중 기준 변화를 추적할 수 있습니다.

teacher model이 만든 예시는 학습 데이터가 되므로, 어떤 명세에서 어떤 예시가 만들어졌는지, 사람이 수정한 예시가 무엇인지, 배포된 adapter가 어느 데이터 묶음에서 나왔는지를 남겨두는 것이 중요합니다. 작은 모델이라고 해서 운영 기록까지 작아지는 것은 아닙니다.

비용 비교도 호출 단가만으로는 부족합니다. 컴파일 시간, 샘플 생성 비용, 재학습 빈도, 로컬 서빙 비용, 실패 검수 시간을 함께 봐야 합니다. 자주 바뀌는 규칙은 다시 컴파일해야 하므로 이득이 줄어들고, 오래 유지되는 규칙은 앞단 비용을 나눠 가질 수 있어 이득이 커질 수 있습니다.

정리

이 논문은 반복되는 자연어 판단을 매번 호출하는 대신, 제품 안에서 관리되는 작은 실행 단위로 바꿀 수 있는지 묻습니다. 자연어 명세를 함수처럼 저장하고, 버전으로 관리하고, 조합 가능한 구성요소로 다루려는 발상이라는 점에서 실무적인 시사점이 분명합니다.

특히 반복량이 많고 기준이 오래 유지되는 텍스트 변환이라면, 실시간 API 호출만이 유일한 선택지는 아닐 수 있습니다.

출처