Structured Prompt Language (SPL): LLM 을 위한 선언적 컨텍스트 관리 언어

1. 문제 정의 (Problem)

대규모 언어 모델 (LLM) 이 소프트웨어 엔지니어링의 핵심이 되면서, **컨텍스트 윈도우 (Context Window)**라는 제한된 자원을 효율적으로 관리하는 것이 새로운 과제로 대두되었습니다. 현재 프롬프트 엔지니어링은 SQL 이 등장하기 전의 데이터베이스 프로그래밍과 유사한 혼란 상태에 있습니다.

주요 문제점은 다음과 같습니다:

• 명령형 (Imperative) 접근의 한계: 개발자가 직접 토큰 수를 계산하고, 프롬프트를 자르고, API 를 호출하는 명령형 코드 (Python 등) 를 작성해야 합니다.
• 예산 관리 부재: 토큰 예산 (Token Budget) 이 명시적으로 할당되지 않아 런타임에서 컨텍스트 오버플로우가 발생하거나 비용이 통제되지 않습니다.
• 가시성 부족: 토큰이 프롬프트의 어떤 부분에 어떻게 할당되는지 확인할 수 있는 표준적인 방법 (EXPLAIN 등) 이 없습니다.
• 비조립성 (Non-composability): 프롬프트가 단조로운 문자열로 구성되어 있어 모듈화나 재사용이 어렵습니다.
• 공급업체 종속성: 특정 LLM API 에 tightly coupled 되어 있어 이식이 어렵습니다.

2. 방법론 (Methodology)

저자는 LLM 을 단순한 텍스트 생성기가 아닌 **"생성형 지식 베이스 (Generative Knowledge Base)"**로 재정의하고, 이를 관리하기 위해 **SQL 에서 영감을 받은 선언적 언어인 SPL (Structured Prompt Language)**을 제안합니다.

핵심 개념

1. 토큰 예산을 제한된 자원으로 모델링: SQL 의 쿼리 최적화기를 차용하여, 컨텍스트 윈도우를 B 토큰으로 제한된 자원으로 보고, 이를 다양한 소스 (시스템 역할, RAG, 메모리, 사용자 입력 등) 에 할당하는 최적화 문제를 정의합니다.
2. SELECT / GENERATE 이원 구조:
   • SELECT: 컨텍스트를 수집하고 압축하는 단계 (RAG, 메모리 조회 등).
   • GENERATE: 수집된 컨텍스트를 바탕으로 새로운 내용을 생성하는 단계.
   • 이 분리를 통해 컨텍스트 수집과 생성을 별도의 리소스 단계로 최적화할 수 있습니다.
3. 명시적 예산 관리: WITH BUDGET, LIMIT, OUTPUT BUDGET 절을 통해 입력 및 출력 토큰 한계를 선언적으로 지정합니다.
4. EXPLAIN 메커니즘: 실행 전 토큰 할당 계획, 예상 비용, 캐시 상태를 보여주는 EXPLAIN 명령어를 도입하여 개발자가 사전에 최적화할 수 있게 합니다.
5. 컴파일러 파이프라인: SPL 엔진은 Lexer, Parser, Semantic Analyzer, Optimizer, Executor 로 구성된 컴파일러 아키텍처를 따릅니다. 최적화기는 예산 초과 시 가장 큰 소스부터 순차적으로 압축 (Truncation) 하는 그리디 알고리즘을 적용합니다.

3. 주요 기여 (Key Contributions)

1) SPL 언어 설계 및 문법

• EBNF 문법: 완전한 형식 문법을 제공하며, 재귀 하강 파서 (Recursive Descent Parser) 를 사용하여 외부 의존성 없이 구현되었습니다.
• CTE (Common Table Expressions): 복잡한 프롬프트를 단순한 블록으로 조립할 수 있는 WITH ... AS 구문을 지원합니다.
• 사용자 정의 함수 (UDF): 프롬프트 처리 패턴을 재사용 가능한 함수로 정의할 수 있습니다.

2) SPL 생태계 및 확장 기능 (5 가지)

1. Text2SPL: 자연어 (다국어 지원) 를 SPL 스크립트로 변환하는 인터페이스.
2. Mixture-of-Models (MoM) 라우팅: USING MODEL auto를 통해 태스크 유형 (코드, 수학, 언어 등) 을 감지하여 실행 시점에 전문 모델로 자동 라우팅합니다.
3. Logical Chunking (선언적 Map-Reduce): 긴 문서를 CTE 를 통해 여러 청크로 분할하여 병렬 처리한 후 결과를 통합합니다. 이는 어텐션 비용을 $O(N^2)$에서 $O(N^2/k)$로 줄여줍니다.
4. SPL-flow: 3 단계 공급업체 폴백 전략 (Ollama → OpenRouter → 자기 치유 재시도) 을 가진 견고한 에이전트 오케스트레이션 레이어.
5. BENCHMARK: 여러 모델을 병렬로 실행하여 성능, 비용, 지연 시간을 비교하고 자동으로 최적 모델을 선택하여 저장하는 기능.

3) 구현 및 오픈소스

• spl-llm (SPL 엔진) 과 spl-flow (오케스트레이션) 라는 두 가지 파이썬 패키지를 제공하며, VS Code 확장 프로그램도 함께 배포됩니다.

4. 실험 결과 (Results)

• 개발자 경험 (Developer Experience): 5 가지 벤치마크 태스크에서 명령형 Python 코드 대비 평균 65% 의 코드 줄 수 (LoC) 감소를 달성했습니다. 또한, 모든 수동 토큰 계산 작업을 제거했습니다.
• 토큰 예산 최적화: 예산이 부족할 때 최적화기가 자동으로 가장 큰 컨텍스트 소스부터 압축하여 예산을 준수하며, 이 과정이 EXPLAIN을 통해 투명하게 표시됩니다.
• 비용 예측: 실행 전 다양한 LLM 모델 (GPT-4, Claude, Llama 등) 에 대한 예상 비용을 산출하여, 최대 68 배의 비용 차이를 사전에 인지하고 모델을 선택할 수 있게 합니다.
• Logical Chunking 효율성: 긴 문서를 $k$개의 청크로 나누어 병렬 처리할 때, 어텐션 계산 비용을 $k$배 줄일 수 있음을 실험적으로 입증했습니다. 동일한 스크립트로 클라우드 (병렬) 와 로컬 GPU (순차) 환경 모두에서 실행 가능함을 보였습니다.

5. 의의 및 결론 (Significance)

이 논문은 LLM 애플리케이션 개발 패러다임을 명령형 프롬프트 엔지니어링에서 선언적 쿼리 엔지니어링으로 전환하는 중요한 이정표입니다.

• SQL 의 성공 원리 적용: 선언적 명세, 자동 최적화, 조립성, 이식성, 투명성 (EXPLAIN) 을 LLM 컨텍스트 관리에 적용하여 개발자의 인지 부하를 줄이고 시스템의 효율성을 극대화합니다.
• 자원 중심 사고: 프롬프트의 '내용' 최적화 (DSPy 등) 와 별개로, '컨텍스트 예산'이라는 자원을 어떻게 할당할지에 초점을 맞춥니다.
• 아키텍처적 통찰: 거대한 컨텍스트 윈도우를 늘리는 대신, 선언적 청킹과 전문 모델 라우팅 (MoM) 을 통해 더 작고 효율적인 모델들로 복잡한 태스크를 해결하는 새로운 확장 경로 ($O(N^2/k)$ 효율성) 를 제시합니다.
• 접근성: 기존 SQL 개발자들에게 친숙한 문법을 제공하여 AI 엔지니어링 진입 장벽을 낮추고, 데이터 엔지니어와 분석가들이 GenAI 영역으로 자연스럽게 확장할 수 있는 다리를 제공합니다.

결론적으로 SPL 은 LLM 애플리케이션의 복잡성을 추상화하고, 비용과 성능을 통제 가능한 수준으로 관리할 수 있는 구조화된 프레임워크를 제시합니다.