커스텀 프롬프트 DSL을 사용하여 시스템 프롬프트 토큰을 70% 줄이는 방법

우리가 프롬프트를 잘못된 방식으로 작성해 온 것이라면 어떨까요?

지난 2년 동안 AI 커뮤니티는 더 나은 프롬프트를 작성하는 데 집중해 왔습니다.

우리 모두는 다음과 같은 형태의 프롬프트를 작성해 본 적이 있습니다:

당신은 전문적인 제품 전략가, UX 디자이너, SEO 컨설턴트, 카피라이터, 연구원, 워크플로 아키텍트입니다...

그다음 우리는 다음 항목들을 추가합니다:

• 규칙 (Rules)
• 제약 사항 (Constraints)
• 출력 형식 (Output formats)
• 안전 지침 (Safety instructions)
• 예시 (Examples)
• 예외 사항 (Exceptions)
• 더 많은 규칙 (More rules)

곧 단일 시스템 프롬프트는 **500–5000 토큰 (tokens)**에 달하게 됩니다.

MiniMind AI를 구축하면서, 저는 다른 질문을 던지기 시작했습니다:

왜 우리는 LLM (Large Language Models)에게 긴 영어 에세이를 쓰고 있는 걸까?

AI 시스템을 위해 특별히 설계된 구조화된 명령 언어 (structured instruction language)를 만들면 안 될까요?

다음과 같은 언어 말입니다:

• 컴팩트하고 (compact)
• 기계 친화적이며 (machine-friendly)
• 압축이 가능하고 (can be compressed)
• 자동으로 생성하기 쉬우며 (easy to generate automatically)
• 토큰을 절약하는 (Saves tokens)

그 질문은 결국 다음과 같은 실험으로 이어졌습니다:

• 프롬프트 빌더 (Prompt Builder)
• 프롬프트 옵티마이저 (Prompt Optimizer)
• 프롬프트 아키텍트 스위트 워크플로 (Prompt Architect Suite Workflow)
• CSP v1 (Compressed System Prompt, 압축된 시스템 프롬프트)

기존 프롬프트 압축 연구 (Existing Prompt Compression Research)

프롬프트 압축 (Prompt compression)은 이미 활발한 연구 분야입니다.

Microsoft의 LLMLingua 프로젝트는 성능을 유지하면서도 프롬프트를 상당히 압축할 수 있음을 입증했습니다.

LLMLingua 제품군은 다음과 같은 모델들을 선보였습니다:

• LLMLingua
• LongLLMLingua
• LLMLingua-2

이와 함께 프롬프트 최적화 기술의 생태계도 성장하고 있습니다.

대부분의 프롬프트 압축 연구의 목표는 다음과 같습니다:

의미를 보존하면서 불필요한 토큰을 제거한다.

저의 실험은 약간 다른 것을 탐구했습니다:

장황한 영어 지침을 컴팩트한 AI 판독 가능 DSL (Domain Specific Language, 도메인 특화 언어)로 대체한다.

실험 (The Experiment)

저는 동일한 시스템 프롬프트에 대해 세 가지 버전을 만들었습니다.

과업 (Task):

MiniMind AI를 위한 완전한 SaaS 랜딩 페이지 구조를 생성하라.

버전 A — 전통적인 영어 프롬프트 (Version A — Traditional English Prompt)

당신은 전문적인 AI 제품 디자이너, SaaS 랜딩 페이지 전략가,
UX 카피라이터, SEO 어드바이저, 그리고 전환 최적화 전문가입니다.

...

예상 크기:

~683 tokens

버전 B — 구조화된 프롬프트 (Structured Prompt)

긴 문단 대신 다음과 같이 작성합니다:

ROLE:
  primary: SaaS_Landing_Page_Strategist

...

예상 크기:

~494 tokens

감소율:

~28%

버전 C — CSP v1 (압축된 시스템 프롬프트, Compressed System Prompt)

이것이 가장 흥미로운 부분이었습니다.

CSP:v1

ROLE=SaaSLandingStrategist|UXCopy|SEO
...

예상 크기:

~215 tokens

감소율:

~69%

나의 예상

솔직히 말해서, 저는 버전 C가 실패할 것이라고 예상했습니다.

모델이 압축된 구문 (compressed syntax)을 처리하는 데 어려움을 겪을 것이라고 가정했습니다.

제가 예상했던 결과는 다음과 같습니다:

• 섹션 누락
• 품질 저하
• 지시 사항 이행 능력 저하

하지만 제 생각이 틀렸습니다.

결과

Gemini는 다음 항목들을 성공적으로 생성했습니다:

• 히어로 섹션 (Hero section)
• 문제 섹션 (Problem section)
• 솔루션 섹션 (Solution section)
• 기능 (Features)
• 이점 (Benefits)
• 사용 사례 (Use cases)
• FAQ
• SEO 메타데이터 (SEO metadata)

또한 다음 사항들을 정확하게 이해했습니다:

• 인간 참여형 워크플로우 (Human-in-the-loop workflows)
• 웹 검색 (Web research)
• 구조화된 출력 (Structured outputs)
• PDF 내보내기 (PDF exports)
• JSON 내보내기 (JSON exports)
• Markdown 내보내기 (Markdown exports)

이 모든 것이 약 70% 더 작은 프롬프트로부터 나왔습니다.

출력이 완전히 동일하지는 않았습니다.

일부 뉘앙스는 손실되었습니다.

하지만 품질은 놀라울 정도로 높게 유지되었습니다.

왜 이것이 작동했을까?

최신 LLM (Large Language Models)은 다음과 같은 방대한 양의 데이터를 통해 학습됩니다:

• JSON
• YAML
• XML
• 소스 코드 (Source code)
• API 명세서 (API specifications)
• 설정 파일 (Configuration files)
• GitHub 저장소 (GitHub repositories)

다음과 같은 구조는:

RULES=[
 no_fake_claims,
 seo_friendly,
...

모델이 여러 문단의 산문 (prose)을 읽는 것보다 실제로 해석하기 더 쉬울 수 있습니다.

모델은 단순히 언어를 읽는 것이 아닙니다.

제약 조건 (constraints)에 대한 내부 표현 (internal representation)을 구축하는 것입니다.

진짜 통찰 (The Real Insight)

저는 이제 흥미로운 아이디어가 다음과 같다고 생각하지 않습니다:

프롬프트 압축 (Prompt Compression)

그보다 더 흥미로운 아이디어는 이것이라고 생각합니다:

프롬프트 DSL (Prompt DSL)

AI 지시를 위한 도메인 특화 언어 (domain-specific language)입니다.

다음과 같이 쓰는 대신:

당신은 전문적인 경쟁사 조사 어시스턴트입니다.
웹 검색을 사용하세요.
항상 출처를 인용하세요.
...

우리는 다음과 같이 작성할 수 있습니다:

ROLE=CompetitorResearch

TOOLS=[
...

프롬프트 DSL vs 전통적인 영어

지표 (Metric)	영어 (English)	DSL
인간 친화도 (Human Friendly)	매우 우수 (Excellent)	좋음 (Good)
...

MiniMind AI에 구축하기

이 실험은 결과적으로 MiniMind AI 내부의 세 가지 제품이 되었습니다.

1. 프롬프트 빌더 (Prompt Builder)

프롬프트 빌더 (Prompt Builder)는 가공되지 않은 요구사항을 전문적인 프롬프트로 변환합니다.

예시:

입력 (Input):

웹 검색과 출처 인용 기능이 있는
경쟁사 조사 에이전트를 구축해줘.

출력 (Output):

전문적인 시스템 프롬프트 (Professional System Prompt)
전문적인 에이전트 프롬프트 (Professional Agent Prompt)
전문적인 워크플로우 프롬프트 (Professional Workflow Prompt)

구조, 가드레일 (Guardrails), 출력 계약 (Output contracts), 형식 요구사항 (Formatting requirements) 및 지침 (Instructions)을 수동으로 작성하는 대신, 이 도구는 이를 자동으로 생성합니다.

직접 체험해 보세요:

MiniMind AI Prompt Builder

2. 프롬프트 옵티마이저 (Prompt Optimizer)

프롬프트 옵티마이저 (Prompt Optimizer)는 기존 프롬프트를 가져와 다음과 같은 구조화된 형식으로 압축합니다:

• CSP v1
• JSON
• YAML
• XML
• Markdown
• 최적화된 영어 (Optimized English)

목표는 단순히 토큰 (Token)을 줄이는 것이 아닙니다.

목표는 동작 (Behavior)을 보존하면서 토큰을 줄이는 것입니다.

예를 들어, 제 테스트 중 하나는 다음과 같은 결과를 생성했습니다:

원본 예상 토큰 (Original Estimated Tokens): 567
최적화된 예상 토큰 (Optimized Estimated Tokens): 323

...

옵티마이저는 또한 다음 항목들을 생성합니다:

제거 또는 병합된 항목 (Removed or Merged Items)

• 중복된 지침 (Duplicate instructions)
• 반복되는 형식 요구사항 (Repeated formatting requirements)
• 대화형 미사여구 (Conversational filler)
• 불필요한 역할 설명 (Redundant role descriptions)

보존된 핵심 규칙 (Preserved Critical Rules)

• 가드레일 (Guardrails)
• 출력 계약 (Output contracts)
• 도구 권한 (Tool permissions)
• 보안 제약 사항 (Security constraints)
• 부정 규칙 (Negative rules)
• 인용 요구사항 (Citation requirements)

이는 _무엇이 변경되었는지_에 대한 가시성을 제공하기 때문에 압축 그 자체만큼이나 가치 있는 것으로 나타났습니다.

직접 체험해 보세요:

MiniMind AI Prompt Optimizer

3. 프롬프트 아키텍트 스위트 워크플로우 (Prompt Architect Suite Workflow)

프롬프트 빌더 (Prompt Builder)와 프롬프트 옵티마이저 (Prompt Optimizer)가 존재하게 된 후, 다음 논리적인 단계는 이들을 하나의 완전한 워크플로우 (Workflow)로 결합하는 것이었습니다.

프롬프트를 수동으로 생성하는 대신, 이 워크플로우는 사용자가 전체 프롬프트 엔지니어링 (Prompt-engineering) 과정을 거칠 수 있도록 안내합니다.

Raw Requirement (원시 요구사항)
        ↓
Prompt Builder (프롬프트 빌더)
...

직접 시도해 보기:

MiniMind AI Prompt architect suite

워크플로우 결과물

이 워크플로우는 단순히 프롬프트를 생성하는 것에 그치지 않습니다.

완전한 핸드오프 패키지 (Handoff package)를 생성합니다.

실행 요약 (Executive Handoff Summary)

다음 내용을 설명하는 간결한 개요입니다:

• 무엇이 생성되었는가
• 무엇이 최적화되었는가
• 무엇이 보존되었는가
• 무엇이 변경되었는가

원본 프롬프트 (Original Prompt)

사용자의 원시 요구사항 (Raw requirement)으로부터 생성된 전문적인 프롬프트입니다.

최적화된 프롬프트 (Optimized Prompt)

압축된 CSP v1 버전입니다.

예시:

CSP:v1

ROLE=CompetitorResearch
...

압축 보고서 (Compression Report)

예시:

Original Tokens (원본 토큰): 567
Optimized Tokens (최적화된 토큰): 323

...

보존 분석 (Preservation Analysis)

워크플로우는 다음 항목들을 자동으로 식별합니다:

보존됨 (Preserved)

• 보안 요구사항 (Security requirements)
• 가드레일 (Guardrails)
• 출력 형식 (Output formats)
• 승인 요구사항 (Approval requirements)
• 인용 (Citations)
• 제약 사항 (Constraints)

제거 또는 병합됨 (Removed or Merged)

• 중복된 문구 (Duplicate wording)
• 반복된 지침 (Repeated instructions)
• 불필요한 예시 (Redundant examples)
• 대화형 미사여구 (Conversational filler)

내보낼 수 있는 결과물 (Exportable Deliverables)

최종 패키지는 다음과 같은 형식으로 내보낼 수 있습니다:

• PDF
• JSON
• Markdown

이를 통해 프롬프트를 다음과 같이 활용할 수 있습니다:

• 버전 관리 (Versioned)
• 검토 (Reviewed)
• 공유 (Shared)
• 재사용 (Reused)
• 감사 (Audited)

팀과 프로젝트 전반에 걸쳐 활용이 가능합니다.

품질 평가에 관한 참고 사항

한 가지 중요한 참고 사항이 있습니다.

이 실험에서의 품질 비교는 비공식적이었습니다.

저는 출력을 수동으로 비교하였으며, 최적화된 프롬프트가 원본의 동작, 구조 및 제약 사항을 보존하는 것처럼 보이는지를 평가했습니다.

대규모 데이터셋이나 표준화된 작업 세트(Task suites)를 통한 엄격한 벤치마크 기반 평가를 수행한 것은 아닙니다.

저를 놀라게 한 것은 압축이 작동한다는 사실이 아니었습니다.

저를 놀라게 한 것은 눈에 띄는 품질 저하가 나타나기 전까지 얼마나 많은 압축이 가능했는가 하는 점이었습니다.

여러 테스트에서 40~70%까지 줄어든 프롬프트들도 여전히 원본 버전과 놀라울 정도로 유사한 출력을 생성했습니다.

이것이 프롬프트 DSL (Domain Specific Language)이 보편적으로 더 낫다는 증거는 아닙니다.

하지만 CSP v1과 같은 구조화된 지시 언어(structured instruction languages)가 더 탐구할 가치가 있다는 점을 확신시키기에는 충분했습니다.

품질 평가 방법

이 실험에서의 품질 평가는 비공식적이었습니다.

저는 영어 프롬프트와 압축된 CSP v1 버전에서 생성된 출력을 수동으로 비교하였으며, 주요 요구사항, 구조, 제약 조건 및 출력 섹션이 보존되었는지 평가했습니다.

벤치마크 기반의 평가나 대규모 작업 테스트를 수행하지는 않았습니다.

저를 놀라게 한 것은 압축이 작동한다는 사실이 아니라, 눈에 띄는 품질 저하가 나타나기 전까지 얼마나 많은 압축이 가능한가 하는 점이었습니다.

이것이 에이전트(Agents)에게 중요한 이유

챗봇은 단일 시스템 프롬프트를 사용할 수 있습니다.

하지만 에이전트 시스템은 다음과 같은 것들을 사용할 수 있습니다:

• 플래너 프롬프트 (Planner Prompt)
• 리서치 프롬프트 (Research Prompt)
• 리뷰어 프롬프트 (Reviewer Prompt)
• 라이터 프롬프트 (Writer Prompt)
• 평가자 프롬프트 (Evaluator Prompt)

만약 각 프롬프트가 1,000개의 토큰을 포함한다면:

5 agents × 1000 tokens
=
5000 prompt tokens

이 프롬프트들을 60% 줄인다면,

절감 효과는 상당해집니다.

특히 대규모 에이전트 시스템과 워크플로우 플랫폼의 경우 더욱 그렇습니다.

CSP v1 (Compressed System Prompt)

제가 현재 가장 선호하는 형식은 다음과 같습니다:

CSP v1

예시:

CSP:v1

ROLE=CompetitorResearch
...

단순합니다.

읽기 쉽습니다.

압축 가능합니다.

기계 친화적(Machine-friendly)입니다.

더 큰 질문

우리는 다음과 같이 변화해 왔습니다:

기계어 (Machine Code)
↓
프로그래밍 언어 (Programming Languages)

그 이유는 인간이 기계 명령어를 직접 작성해서는 안 되기 때문입니다.

아마도 프롬프팅도 유사한 경로를 따를지 모릅니다.

어쩌면 미래의 개발자들은 거대한 영어 시스템 프롬프트를 작성하지 않을 수도 있습니다.

어쩌면 그들은 다음과 같이 작성할 것입니다:

ROLE=
GOAL=
RULES=
...

그리고 컴파일러와 최적화 도구가 나머지를 처리하도록 맡길 것입니다.

제가 CSP v1이 미래라고 주장하는 것은 아닙니다.

하지만 Prompt Builder, Prompt Optimizer, 그리고 Prompt Architect Suite를 구축한 후 한 가지 사실이 분명해졌습니다:

현대의 LLM (Large Language Models)은 제가 예상했던 것보다 훨씬 더 구조화된 명령 언어 (structured instruction languages)를 잘 이해합니다.

그리고 이는 매우 흥미로운 가능성들을 열어줍니다.

여러분은 어떻게 생각하시나요?

여러분은 다음 중 무엇을 유지하고 싶으신가요?

• 3,000 토큰 분량의 영어 시스템 프롬프트 (system prompt)

또는

• 버전 관리, 압축, 생성 및 자동 최적화가 가능한 구조화된 DSL (Domain Specific Language)?

다른 분들도 프롬프트 DSL (prompt DSLs)이나 프롬프트 컴파일러 (prompt compilers)를 실험해 본 적이 있는지 궁금합니다.