경량 LLM 프롬프트 컴파일러 아이디어 분석

ChatGPT와 논의한 아이디어: 매우 작은 LLM을 파인튜닝해서, LLM에서 좋은 답을 얻을 수 있는 프롬프트만을 전문적으로 생성하게 하는 것.

핵심 포지셔닝

"좋은 프롬프트를 쓰는 모델"이 아니라 "사용자의 거친 요청을 target LLM이 실행할 수 있는 구조화된 명세로 컴파일하는 전용 모델"로 정의하는 것이 실용적이다.

예를 들어 사용자가 "이 자료 요약해줘"라고 하면 다음과 같이 변환하는 것:

• 목표: 의사결정용 요약
• 대상 독자: 임원
• 출력 형식: 핵심 결론 5개, 리스크, 다음 액션
• 금지: 원문에 없는 수치 추정 금지
• 불확실성 처리: 근거가 약한 항목은 "확인 필요"로 표시

아이디어의 가치 — 조건부 있음

가치가 높은 상황

• 짧고 애매한 입력이 들어오지만 실제 업무는 반복적일 때
• 고객지원, 리서치, 보고서, 코드리뷰 등 출력 포맷이 정해져 있는 작업
• 같은 target LLM을 계속 쓰고 그 모델의 "잘 먹히는 프롬프트 패턴"을 학습시킬 때
• 프롬프트 길이 축소를 통한 비용/지연 절감
• 로컬·온디바이스·프라이버시 환경에서 프롬프트 전처리 필요

가치가 낮은 상황

• 범용적으로 "모든 질문에 더 좋은 프롬프트"를 만드는 경우 — 최신 큰 모델은 불완전한 요청도 잘 추론하므로 추가 가치가 작음

비즈니스 포지셔닝: "프롬프트 생성기"보다 도메인별 task router + prompt compiler + evaluator loop로 포지셔닝하는 것이 낫다.

모델 크기 — 현실적인 하한

추천 전략: 처음부터 0.5B로 시작하지 말고 3B~4B에서 목표 품질을 만든 뒤 → 1.5B → 0.6B 순으로 distillation (지식 증류, 큰 모델의 능력을 작은 모델에 옮기는 과정). 너무 작은 모델부터 가면 "아이디어가 안 되는지 vs 모델이 너무 작은지" 구분이 불가능하다.

한국어 포함 시: Qwen 계열, Gemma 계열 등 다국어 평가 필수.

생각하지 못한 핵심 포인트

1. 평가 루프가 가장 중요

"좋은 프롬프트"는 절대적인 게 아니다. 특정 target LLM, 특정 task, 특정 metric에서 좋은 프롬프트가 있을 뿐이다.

• 단순 "나쁜 질문 → 좋은 프롬프트" 데이터는 약함
• 필요한 데이터 구조: 사용자 원문 → 목표 task → target LLM → 후보 프롬프트 N개 → 각 후보의 답변 → 평가/선호도 → 최종 선택 프롬프트 + 선택 근거

작은 모델이 "그럴듯한 프롬프트 문체"가 아니라 실제로 target LLM 성능을 올리는 패턴을 배우게 해야 한다.

2. 단일 호출이 아닌 다중 후보 + 평가

작은 모델이 한 번에 완벽한 프롬프트를 내는 것은 어렵다. 3~5개 후보를 만들고 간단한 평가기로 고르면 품질이 크게 올라간다.

이 접근을 APE (Auto Prompt Engineering), PromptBreeder, PromptAgent 등이 모두 사용하며 "생성 → 평가 → 선택/개선" 루프를 돈다.

3. 프롬프트 과최적화 위험

task에 따라 프롬프트 최적화 효과가 크게 다르다. 어떤 task는 출력 랜덤성이나 문제 자체의 난이도가 더 큰 요인이다.

4. 보안 — 프롬프트 인젝션 증폭

작은 모델이 사용자 입력을 "권위 있는 시스템 지시처럼 보이는 문장"으로 재작성하면, 악의적인 지시가 증폭될 수 있다. OWASP(웹 애플리케이션 보안 조직)가 주요 LLM 위험 중 하나로 꼽는 문제.

5. 추천 아키텍처

User request
  → Small Prompt Compiler (의도 추출, 누락 감지, task 선택, 스키마 선택, 제약 추가)
  → Candidate prompts 3~5개
  → Evaluator / heuristic / small judge
  → Best prompt → Target LLM → Answer
  → Feedback logging → 주기적 SFT/DPO/RL 업데이트

중간 출력은 자연어가 아닌 JSON 구조로 하는 것이 좋다:

{
  "task_type": "document_summary",
  "user_goal": "의사결정용 요약",
  "audience": "executive",
  "constraints": ["원문에 없는 수치 추정 금지"],
  "output_format": ["핵심 결론", "근거", "리스크", "다음 액션"],
  "target_model_prompt": "..."
}

이렇게 하면 환각(hallucination, 모델이 사실을 만들어내는 현상)을 줄이고 테스트와 디버깅이 쉬워진다.

6. 파인튜닝 전략

1. 사람 만든 고품질 template 50~200개 준비
2. 실제/synthetic(인공적으로 만든) 요청 5천~5만 개 생성
3. 큰 LLM으로 후보 프롬프트 다수 생성
4. 각 후보를 target LLM에 넣어 실제 답변 품질 평가
5. 최고 후보 → SFT 데이터, 후보 간 순위 → DPO/ORPO 데이터
6. 3B~4B에서 성공 → 1.5B, 0.6B로 distill
7. 초기 데이터 적으면 규칙 기반 template + few-shot + reranker가 더 안정적

7. 성공 지표

• Raw prompt 대비 target LLM 답변 품질 상승 (핵심)
• 재시도 횟수 감소 (비용 절감)
• format compliance (제품 안정성)
• 누락 정보 질문률 (무리한 가정 방지)
• hallucinated constraint 비율 (작은 모델이 임의 조건을 추가하는지)
• prompt injection 전파율 (보안)
• target model 변경 시 성능 유지 (이식성)

최종 판단

작은 LLM에게 "좋은 프롬프트를 써라"가 아니라 "사용자 의도를 target LLM이 잘 실행할 수 있는 검증 가능한 작업 명세로 변환하라"고 학습시키는 것이 핵심 설계 원칙이다.

관련 노트

• Qwen3.6-27B 로 Claude 대체 실험 — 로컬 모델 활용 사례
• [[제주 방언 번역 모델 (88M)]] — 작은 모델의 가능성 사례
• Lathe — LLM으로 새로운 도메인 배우기 — LLM 도구 설계 철학
• MiMo — 1조 파라미터 모델에서 초당 1000 토큰 — 속도 vs 정확성 논쟁