시스템 프롬프트를 모델에 내재화한다: MS의 OPCD 프레임워크가 LLM 배포를 바꾸는 방법

시스템 프롬프트라는 숨은 비용

LLM 기반 서비스를 운영하는 기업이라면 시스템 프롬프트의 존재를 잘 알고 있을 것이다. 안전 정책, 응답 톤, 도메인 지식, 포맷 규칙 등을 담은 이 긴 지시문은 매 요청마다 모델에 함께 전송된다. 문제는 이것이 공짜가 아니라는 점이었다.

기업 수준의 시스템 프롬프트는 수천 토큰에 달하는 경우가 흔했다. 토큰 수가 늘어나면 두 가지 비용이 동시에 증가한다. 첫째, 추론 지연(latency)이다. Transformer 아키텍처에서 어텐션 연산은 시퀀스 길이의 제곱에 비례하므로, 프롬프트가 길어질수록 첫 토큰까지의 대기 시간이 눈에 띄게 늘어난다. 둘째, 비용이다. 대부분의 API 과금은 입력 토큰 수에 비례하기 때문에, 동일한 시스템 프롬프트를 하루 수백만 번 반복 전송하면 그 자체가 상당한 청구서가 된다.

LLM 서빙의 구조를 다룬 이전 글에서 살펴본 것처럼, 프리필(prefill) 단계의 연산량은 입력 토큰 수에 직접적으로 좌우된다. 시스템 프롬프트는 이 프리필 비용의 고정 오버헤드였던 셈이다.

그렇다면 이 반복되는 지시를 모델 가중치 자체에 “구워 넣을” 수는 없을까? 마이크로소프트 리서치가 2025년 2월에 공개한 OPCD(On-Policy Context Distillation) 프레임워크는 바로 이 질문에 대한 답이었다¹.

컨텍스트 증류의 기본 아이디어

OPCD를 이해하려면 먼저 컨텍스트 증류(context distillation)라는 개념을 알아야 한다. 원리는 교사-학생 패러다임에 기반한다.

1. 교사 모델: 긴 시스템 프롬프트를 포함한 전체 컨텍스트를 받고, 그에 맞는 고품질 응답을 생성한다.
2. 학생 모델: 시스템 프롬프트 없이 사용자 질문만 받는다. 교사의 응답을 관찰하며 동일한 행동을 재현하도록 학습한다.

학습이 완료되면 학생 모델은 시스템 프롬프트 없이도 교사와 유사한 응답을 생성할 수 있다. 프롬프트에 담겨 있던 정보가 모델 파라미터에 내재화된 것이다.

이 아이디어 자체는 새로운 것이 아니었다. 그러나 기존 컨텍스트 증류에는 두 가지 근본적인 한계가 있었다.

기존 방식의 두 가지 결함

오프-폴리시 학습과 노출 편향

기존 컨텍스트 증류는 오프-폴리시(off-policy) 방식으로 작동했다. 학습 데이터는 훈련 전에 미리 수집된 고정 데이터셋이었다. 학생 모델은 교사가 생성한 “정답” 시퀀스만 보며 학습했는데, 이것이 노출 편향(exposure bias) 문제를 일으켰다.

학습 중에는 항상 정답 토큰이 주어졌지만, 실제 배포 환경에서는 자기가 생성한 토큰을 기반으로 다음 토큰을 예측해야 한다. 한 번이라도 잘못된 토큰을 생성하면 이후 시퀀스가 연쇄적으로 무너질 수 있었다. 논문의 공저자인 Tianzhu Ye는 이를 “운전 영상만 보여주고 실제 운전을 시키는 것”에 비유했다².

순방향 KL 발산의 문제

두 번째 문제는 학습 목표 함수에 있었다. 기존 방식은 순방향 KL 발산(forward KL divergence)을 최소화했다. 이 지표는 학생이 교사의 전체 분포를 “덮으려” 하는 모드 커버링(mode-covering) 행동을 유도했다.

학생 모델은 교사보다 작거나 컨텍스트 없이 작동하므로, 교사의 복잡한 분포를 완벽히 재현할 용량이 부족했다. 그럼에도 모든 가능성을 포괄하려 하면 예측 분포가 지나치게 넓어지고, 이는 환각(hallucination)과 일반화 실패로 이어졌다.

OPCD의 핵심 설계: 온-폴리시 + 역방향 KL

OPCD는 이 두 가지 문제를 동시에 해결했다.

온-폴리시 학습

OPCD에서 학생 모델은 미리 준비된 데이터셋이 아니라 자신이 직접 생성한 응답으로부터 학습한다. 구체적인 흐름은 다음과 같았다.

1. 학생 모델이 시스템 프롬프트 없이 질문을 받고 응답을 생성한다.
2. 교사 모델은 전체 시스템 프롬프트를 포함한 컨텍스트를 보유한 채, 학생의 각 생성 단계에서 토큰 분포를 평가한다.
3. 학생의 토큰 분포와 교사의 토큰 분포 간 차이를 기반으로 학생의 파라미터를 업데이트한다.

이 방식의 핵심은 학생이 자신의 실수를 직접 경험하고 교정한다는 점이었다. 오프-폴리시 방식처럼 정답만 보는 것이 아니라, 자신이 틀릴 수 있는 상황에서 교사의 피드백을 받으며 학습했다.

역방향 KL 발산

OPCD는 순방향 KL 대신 역방향 KL 발산(reverse KL divergence)을 최소화했다. 역방향 KL은 모드 시킹(mode-seeking) 행동을 유도한다. 학생 분포에서 확률이 높은 영역에 집중하되, 교사가 높은 확률을 부여했더라도 학생이 낮게 평가한 토큰은 억제한다.

Ye의 설명에 따르면 “역방향 KL을 최소화하면 학생의 고확률 영역에 집중하는 모드 시킹 행동이 촉진된다. 학생이 가능성이 낮다고 판단하는 토큰은, 교사가 높은 확률을 부여했더라도 억제된다”².

이 조합의 효과는 명확했다. 학생 모델은 자신의 능력 범위 내에서 가장 정확한 응답에 집중하게 되었고, 무리하게 교사의 전체 분포를 모방하려다 환각을 일으키는 문제가 크게 줄었다.

벤치마크 결과: 수치로 본 효과

OPCD 논문은 두 가지 실험 시나리오에서 결과를 보고했다¹.

경험적 지식 증류

첫 번째 실험에서는 모델이 수학 문제를 풀면서 축적한 해결 전략을 파라미터에 내재화할 수 있는지 검증했다.

특히 17억 파라미터의 소형 모델에서 6.3%→38.3%로 약 6배의 성능 향상을 보인 점이 주목할 만했다.

시스템 프롬프트 증류

두 번째이자 본 글의 핵심 주제인 시스템 프롬프트 내재화 실험에서는, 안전 정책과 의료 도메인 프롬프트를 모델에 구워 넣는 시나리오를 테스트했다.

30억 파라미터 모델에서 안전 분류 정확도가 30.7%에서 83.1%로 뛴 것은, 시스템 프롬프트 없이도 프롬프트가 있을 때에 근접하는 성능을 달성했음을 의미했다.

범용 성능 유지

파인튜닝의 고질적 문제인 치명적 망각(catastrophic forgetting) 측면에서도 OPCD는 양호한 결과를 보였다. 안전 규칙을 내재화한 모델이 관련 없는 의료 QA 태스크에서도 기존 오프-폴리시 방식 대비 약 4%p 높은 성능을 유지했다. 특화와 범용 성능을 동시에 확보한 것이다.

기존 프롬프트 압축 기법과의 비교

시스템 프롬프트의 비용 문제를 해결하려는 시도는 OPCD가 처음이 아니었다. 대표적인 기존 접근법과 비교하면 OPCD의 위치가 더 명확해진다.

LLMLingua: 토큰 수준 압축

마이크로소프트가 2023년에 공개한 LLMLingua는 소형 언어 모델(GPT-2, LLaMA-7B 등)을 활용해 프롬프트에서 중요도가 낮은 토큰을 제거하는 방식이었다³. 최대 20배 압축을 달성하면서도 성능 저하를 최소화했다는 점에서 주목받았다. 후속 연구인 LongLLMLingua(ACL 2024)는 긴 컨텍스트 시나리오에서의 압축을 더욱 개선했다.

그러나 LLMLingua 계열은 추론 시점에서 매번 압축을 수행해야 한다는 한계가 있었다. 압축 자체에도 연산이 필요했고, 원본 프롬프트는 여전히 어딘가에 존재해야 했다. 압축된 프롬프트의 토큰 수도 0이 아니었다.

소프트 프롬프트와 프롬프트 튜닝

프롬프트 튜닝(prompt tuning)은 학습 가능한 연속 벡터(소프트 프롬프트)를 입력 앞에 붙여 모델 행동을 조정하는 기법이었다. 이산적 토큰 대신 연속 공간에서 최적화하므로 훨씬 적은 수의 파라미터로 유사한 효과를 낼 수 있었다. 그러나 소프트 프롬프트도 추론 시마다 입력에 추가해야 하며, 해석 가능성이 떨어진다는 단점이 있었다.

OPCD의 차별점

OPCD는 이들과 근본적으로 다른 접근을 취했다. 프롬프트를 “줄이는” 것이 아니라 완전히 제거한다. 시스템 프롬프트의 정보가 모델 가중치에 직접 내재화되므로, 추론 시점에 추가 입력이 전혀 필요하지 않았다. 모델 압축 기술을 다룬 글에서 양자화나 프루닝이 모델 크기를 줄이는 것이라면, OPCD는 입력 크기를 줄이는 — 정확히는 없애는 — 기법이었다.

실전 도입 조건과 제약

OPCD의 도입 장벽은 상대적으로 낮았다. 논문에 따르면, 기존 RLVR(Reinforcement Learning from Verifiable Rewards) 파이프라인을 운영하는 팀이라면 큰 아키텍처 변경 없이 적용할 수 있었다. 구현은 오픈소스 RLVR 코드베이스인 verl 위에 구축되었으며, 마이크로소프트는 내부 리뷰 후 코드를 공개할 계획이라고 밝혔다².

하드웨어 요구사항은 A100 GPU 8장 정도로, 대규모 사전학습에 비하면 현실적인 수준이었다. 데이터 요구사항도 가벼웠다. 경험적 지식 증류에는 약 30개의 시드 예제만으로 충분했고, 시스템 프롬프트 증류에는 기존에 사용하던 최적화된 프롬프트와 표준 태스크 데이터셋이면 되었다.

그러나 OPCD가 만능은 아니었다. Ye는 “필요한 정보가 매우 동적이거나, 자주 업데이트되는 대규모 외부 데이터베이스와 관련된 경우에는 RAG가 더 적합하다”고 언급했다². OPCD는 본질적으로 정적이고 반복적인 지시를 내재화하는 데 최적화되어 있었다. 시스템 프롬프트, 안전 정책, 도메인 규칙처럼 변하지 않는 정보가 이상적인 대상이었다.

LLM 서빙 파이프라인에서의 위치

OPCD를 vLLM 같은 서빙 엔진과 함께 배포한다고 가정하면, 효과는 두 가지 경로로 나타난다.

프리필 단계 단축: 시스템 프롬프트가 사라지면 입력 시퀀스 길이가 그만큼 줄어든다. 2,000토큰의 시스템 프롬프트를 사용하던 서비스라면, 매 요청마다 2,000토큰분의 프리필 연산이 절감된다. KV 캐시 메모리 사용량도 비례하여 감소한다.

처리량 증가: 입력이 짧아지면 동일한 GPU 메모리에 더 많은 요청을 배치(batch)할 수 있다. 연속 배칭(continuous batching) 환경에서 이는 곧 처리량 향상으로 이어진다.

수천 토큰의 시스템 프롬프트가 하루 수백만 쿼리에 반복 전송되는 대규모 서비스에서, 이 절감 효과는 인프라 비용의 유의미한 감소로 이어질 수 있었다.

자기 개선 모델을 향한 발판

OPCD의 장기적 의미는 단순한 비용 절감을 넘어섰다. 경험적 지식 증류 실험이 보여준 것처럼, 모델이 자신의 성공 경험에서 규칙을 추출하고 이를 파라미터에 내재화할 수 있다면, 이는 자기 개선(self-improvement) 루프의 가능성을 시사했다.

배포된 모델이 운영 중 축적한 성공 패턴을 정리하고, OPCD를 통해 다음 버전에 내재화하는 사이클이 반복된다면, 모델은 점진적으로 특정 도메인에 최적화될 수 있다. 물론 이 비전이 실현되려면 자동화된 경험 추출, 품질 검증, 안전한 업데이트 파이프라인 등 해결해야 할 과제가 남아 있었다.

정리

OPCD는 “시스템 프롬프트를 매번 보내는 대신 모델에 구워 넣자”는 단순한 아이디어를, 온-폴리시 학습과 역방향 KL 발산이라는 기술적 혁신으로 실현한 프레임워크였다. 기존 컨텍스트 증류의 노출 편향과 환각 문제를 해결하면서, 30억 파라미터 모델에서 안전 분류 정확도를 30.7%에서 83.1%로 끌어올린 결과는 인상적이었다.

프롬프트 압축이 “줄이는” 접근이었다면, OPCD는 “없애는” 접근이었다. LLM 기반 서비스를 대규모로 운영하는 기업에게, 매 요청마다 수천 토큰의 고정 비용을 제거할 수 있다는 것은 실질적인 게임체인저였다. 마이크로소프트가 코드를 공개하면, 이 기술이 얼마나 빠르게 프로덕션 파이프라인에 스며들지 지켜볼 만하다.