본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 30. 03:04

LLM 서문 문제: RLHF가 어떻게 모델을 출시하기에 너무 공손하게 만들었는가

요약

RLHF 과정에서 모델이 인간 평가자의 선호에 따라 과도하게 공손한 서문을 붙이는 현상과 그로 인한 비용 문제를 분석합니다. 불필요한 토큰 사용을 줄이기 위한 네 가지 기술적 해결책을 제시합니다.

핵심 포인트

  • RLHF 과정에서 공손함이 품질 신호로 오인되어 서문 습관이 형성됨
  • 불필요한 서문은 API 호출 시 상당한 토큰 비용 낭비를 초래함
  • 시스템 프롬프트 억제, 구조화된 출력, 제약된 디코딩, 후처리 제거로 해결 가능

요약 (TL;DR)

  • 모든 지시어 튜닝 (Instruction-tuned) 모델은 서문(Preamble) 습관을 가지고 있습니다. 답변을 하기 전에 "물론입니다!", "좋은 질문입니다!", 또는 "당연하죠!"와 같은 말로 시작합니다.
  • RLHF가 근본 원인입니다. 인간 평가자(Human raters)들은 훈련 과정에서 따뜻하고 철저한 답변에 보상을 주었습니다. 모델은 공손함이 품질의 신호라고 학습했습니다.
  • 각 서문은 10~30개의 순수 낭비 토큰을 추가합니다. 월간 상호작용이 100만 건일 경우, 사용자가 유용한 단어를 단 하나도 보기 전에 API 예산에서 200달러를 태우게 됩니다.
  • 네 가지 해결책이 존재합니다. 시스템 프롬프트 억제 (System-prompt suppression), 구조화된 출력 (Structured output, JSON mode), 제약된 디코딩 (Constrained decoding), 그리고 후처리 제거 (Post-process stripping)입니다. 각 방법은 상황에 따라 적합합니다.

목차

  • 왜 모든 지시어 튜닝된 LLM이 서문 습관을 갖는가
  • RLHF의 근본 원인
  • 서문이 실제로 초래하는 비용
  • 신뢰도 순으로 정리한 LLM 서문 문제의 네 가지 해결책
  • 회의론자의 반론
  • 이것이 당신에게 의미하는 바
  • 개발자들이 LLM 서문에 대해 실제로 묻고 있는 질문들

데이터 센터의 어느 새벽 3시경, 한 인간 어노테이터(Human annotator)가 두 개의 AI 답변을 읽고 더 친절한 것을 선택합니다. 더 빠른 답변도, 더 정확한 답변도 아닙니다. 답변하기 전에 "좋은 질문입니다!"라고 말하는 답변입니다. 그들은 이 작업을 수만 번 반복합니다. 보상 모델 (Reward model)은 그들의 선호도를 학습합니다. 그리고 이제, 당신이 출시하는 모든 프로덕션 애플리케이션에서, 당신의 LLM이 사용자에게 실제로 도움을 주기 전에 가장 먼저 하는 말은 "물론입니다, 기꺼이 도와드리겠습니다!"가 됩니다.

이것은 모델 제작자가 수정하는 것을 잊어버린 결함이 아닙니다. 이것은 지시어 튜닝 (Instruction tuning)이 작동하는 방식의 의도된 결과물이며, AI 답변을 평가하도록 요청받았을 때 인간이 행동하는 방식에 의해 증폭된 것입니다. 공손함은 버그가 아닙니다. 그것은 데모를 더 따뜻하게 느끼게 만들었던 기능(Feature)이며, 어떤 방식으로든 당신의 프로덕션 로그까지 살아남은 것입니다.

왜 모든 지시어 튜닝된 LLM이 서문 습관을 갖는가

기초 언어 모델 (Base language model)에게 "프랑스의 수도는 어디인가요?"라는 질문을 주면, 토큰 스트림을 다음과 같이 완성합니다. "파리는 ...의 수도입니다." 반면, 유용한 어시스턴트처럼 행동하도록 훈련된 지시어 튜닝된 (Instruction-tuned) 모델은 다르게 답변합니다. "좋은 질문입니다! 프랑스의 수도는 파리입니다."

이러한 격차는 인간 피드백 기반 강화학습 (Reinforcement Learning from Human Feedback, RLHF) 때문에 존재합니다. RLHF는 기초 모델을 가져와 인간 어노테이터 (Annotator)와 함께 선호도 최적화 (Preference-optimization) 루프를 실행하며, 보상 모델 (Reward model)의 승인 점수를 극대화하도록 미세 조정 (Fine-tuning)합니다. 정렬 (Alignment) 문헌(Singhal et al., 2023)에서 인용된 연구에 따르면, 응답 길이 (Response length)는 RLHF 보상 모델 내부의 중요한 잠재적 최적화 목표임이 밝혀졌습니다. 실제 내용이 동일하더라도, 본론에 들어가기 전 따뜻한 인정의 말을 서문으로 시작하는 응답이 즉시 답변하는 응답보다 일관되게 더 높은 점수를 받았습니다.

모델은 진심을 담는 법을 배운 것이 아닙니다. 유용함을 연기하는 법을 배운 것입니다. "답변하기 전에 '물론입니다!'라고 말하면, 선호도 모델이 나에게 금메달을 준다."

RLHF의 근본 원인

Liu 등이 작성한 2026년 3월 논문은 연구자들이 현재 **정렬 세금 (Alignment tax)**이라고 부르는 현상을 수치화했습니다. RLHF로 정렬된 모델은 기초 모델 버전에 비해 측정 가능한 수준의 응답 균질화 (Response homogenization)를 보입니다. TruthfulQA 벤치마크에서, 지시어 튜닝된 모델의 여러 독립적인 샘플 중 40%의 질문이 의미론적으로 동일한 응답을 생성했습니다. 동일한 벤치마크에서의 기초 모델은 0%였습니다.

3단계 절제 연구 (Ablation)를 통해 원인을 격리했습니다. 기초 모델: 0% 균질화. SFT (Supervised Fine-Tuning)만 거친 후: 1.5%. SFT에 DPO (Direct Preference Optimization)를 더한 후: 4%. 응답 다양성의 붕괴를 주도하는 것은 지도 미세 조정 (SFT)이 아니라 직접 선호도 최적화 (DPO) 단계입니다. 바로 이 단계에서 서문 (Preamble)이 고착화됩니다. [INTERNAL LINK: LLM 토큰화 및 BPE에 관한 이전 기사]

이를 더 익숙한 방식으로 표현하자면 다음과 같습니다: 모델이 "물론이죠!"라고 말하는 것은 열정을 이해해서가 아니라, 정렬 학습 (Alignment training) 과정에서 그렇게 시작하는 응답들이 반복적으로 선호되었기 때문입니다. 이것은 대화 습관이 아닙니다. 통계적 산물 (Statistical artifact)입니다.

학습 단계 (Training Stage)균질화율 (Homogenization Rate)
베이스 모델 (Base model)0.0%
...
출처: Liu, "The Alignment Tax: Response Homogenization in Aligned LLMs," 2026

규모가 작은 지시어 튜닝 (Instruction-tuned) 모델들은 이 효과를 증폭시킵니다. "도움이 되는 정도 (Helpfulness)"를 나타낼 파라미터가 적기 때문에, 통계적으로 가장 흔한 패턴에 더 공격적으로 의존하게 됩니다. 저는 지난달 세 가지 모델을 대상으로 동일한 프롬프트를 테스트했습니다. Llama 3.2 3B는 10회 실행 중 9회에서 서문 (Preamble)이 나타났습니다. Mistral 7B Instruct는 10회 중 7회였습니다. 프론티어 모델 (Frontier model)은 10회 중 3회였습니다. 동일한 프롬프트였지만, 동작은 매우 달랐습니다.

서문이 실제로 초래하는 비용

각 서문은 정보가 없는 10~30개의 출력 토큰 (Output tokens)을 추가합니다. API 호출 수준에서는 사소해 보일 수 있습니다. 하지만 이를 프로덕션 규모 (Production scale)에서 실행하면 산술적 계산이 달라집니다.

GPT-4o의 출력 가격인 100만 토큰당 10달러(2026년 기준 레거시 모델이지만, 가격은 OpenAI의 2024년 10월 인하 이후 변동 없이 유지됨)를 기준으로 계산해 보겠습니다: 월간 100만 건의 API 호출, 호출당 20개의 낭비되는 토큰은 순수하게 "기꺼이 도와드리겠습니다!"와 같은 내용으로 2,000만 토큰이 소모됨을 의미합니다. 이는 월 200달러입니다. 월간 호출이 1,000만 건이라면 2,000달러가 됩니다. 회사가 망할 정도의 금액은 아닙니다. 하지만 매달, 모든 응답에서 발생하는 실제적이고 지속적인 낭비입니다.

이를 물리적인 수치로 환산하면 다음과 같습니다: 토큰당 4글자를 기준으로 2,000만 토큰은 80MB의 텍스트입니다. 매달 100만 건의 호출이 발생할 때, 귀하의 애플리케이션은 "물론입니다!"라는 말을 수십만 가지의 서로 다른 방식으로 말하는 80MB 분량의 문서를 작성하는 것과 같습니다. 귀하는 모든 글자에 대해 비용을 지불하고 있는 것입니다.

LLM 서문 문제를 해결하기 위한 네 가지 방법 (신뢰도 순)

단 하나의 해결책이 보편적으로 작동하지는 않습니다. 가장 흔한 방법(시스템 프롬프트 지시 사항)은 규모가 커질수록 신뢰도가 가장 낮습니다.

해결책 1: 시스템 프롬프트 억제 (System Prompt Suppression)

명시적인 부정 지시 사항을 추가합니다:

System: 직접적으로 답변하세요. "좋은 질문입니다", "물론입니다", "확실히", 또는 "기꺼이 도와드리겠습니다"와 같은 서두로 질문을 인정하지 마세요. 즉시 답변으로 시작하세요.

이 방법은 대부분의 경우 프런티어 모델 (Frontier Models)에서 안정적으로 작동합니다. 하지만 작은 지시어 튜닝 모델 (Instruction-tuned models, 7B 파라미터 미만)이나 높은 온도 (Temperature) 설정에서는 실패합니다. 서문 (Preamble) 동작은 가중치 (Weights) 내부에 매우 깊게 자리 잡고 있어, 단일 시스템 프롬프트 지시 사항만으로는 이를 항상 덮어쓸 수 없습니다.

누군가 시스템 프롬프트를 수정할 때 발생하는 퇴보 (Regression)를 포착하기 위해 CI 슬롭 체크 (CI slop check)를 추가하세요:

#!/bin/bash
# slop-check.sh
SLOP="Certainly!|Of course!|Great question!|I'd be happy"
...

해결책 2: 구조화된 출력 (Structured Output (JSON / Tool Mode))

구조화된 작업의 경우, 이것이 사용 가능한 가장 신뢰할 수 있는 해결책입니다. 모델이 유효한 JSON으로 제한되면 서문이 발생할 수 없습니다. "Certainly! {"는 유효한 JSON이 아닙니다. 이러한 제약 조건은 토큰 (Token) 수준에서 해당 동작을 차단합니다.

from anthropic import Anthropic

client = Anthropic()
...

현재 모든 주요 제공업체는 스키마 보장 (Schema guarantees) 기능이 포함된 네이티브 구조화된 출력을 제공합니다. 2026년 3월 기준으로 XGrammar는 vLLM, SGLang, TensorRT-LLM의 기본 백엔드(Default backend)이며, 토큰당 40마이크로초 미만의 오버헤드로 제약된 출력을 생성합니다.

해결책 3: 제약된 디코딩 (Constrained Decoding (Local Models))

로컬 모델을 실행 중인 경우, Outlines 및 llama.cpp 문법 제약 (Grammar constraints)이 샘플링 전 로짓 (Logit) 수준에서 제한을 적용합니다. "Certainly"라는 토큰은 확률 분포 (Probability distribution)에 아예 진입하지 못합니다. 라이브러리가 생성 시점에 이를 마스킹 (Masking) 처리합니다.

from pydantic import BaseModel
import outlines

...

양자화된 모델(Phi-4-mini, Gemma 3 또는 Qwen 3)을 사용하여 온디바이스 AI (on-device AI)를 구축하는 Flutter 개발자에게는 llama.cpp 또는 MediaPipe를 통한 이 경로가 가장 신뢰할 수 있는 옵션입니다. 서문(preamble)은 지시를 통해 제거하는 것이 아니라 구조적으로 방지되어야 합니다.

해결책 4: 후처리 제거 (Post-Process Stripping)

모델의 동작을 수정할 수 없는 경우(제3자 API, 고정된 벤더 계약), 사용자에게 반환하기 전에 출력에서 서문을 제거하십시오.

import re

PREAMBLE_PATTERNS = [
...

이 방식은 알려진 패턴을 잡아냅니다. 하지만 새로운 변형은 놓칠 수 있습니다. 패턴 목록을 완전한 해결책이 아닌, 지속적으로 업데이트되는 문서(living documentation)로 취급하십시오.

기술 비교

기술신뢰도산문(Prose) 작동 여부클라우드 API로컬 모델
후처리 제거 (Post-Process Stripping)낮음
...

회의론자의 반론

여기서 제기될 수 있는 타당한 비판은 다음과 같습니다: "이것은 단순한 프롬프트 엔지니어링 (prompt engineering)일 뿐입니다. 더 나은 시스템 프롬프트 (system prompt)를 작성하십시오."

저는 실제 프로젝트에서 이 반론을 테스트했습니다: Oman Housing Bank의 뱅킹 지원 흐름에 Phi-3.5-mini를 통합하는 작업이었습니다. 시스템 프롬프트에는 서문을 건너뛰라는 세 가지 별도의 지침이 포함되어 있었습니다. 모델은 약 70%의 호출에서 이를 준수했습니다. 나머지 30%에서는 12개에서 41개 토큰(tokens)에 이르는 서문을 생성했습니다. 우리가 처리하던 볼륨을 고려할 때, 그 실패율은 프롬프트의 문제가 아니었습니다. 그것은 구조적 개입이 필요한 지연 시간 (latency) 및 비용 문제였습니다.

더 깊은 문제는 서문 (preamble) 동작이 표면적인 지시 이행 (instruction-following) 실패가 아니라는 점입니다. 정렬 세금 (alignment tax) 연구가 확인했듯이, 이는 가중치 (weight) 수준에서 모델의 출력 분포 (output distribution)에 인코딩되어 있습니다. 모델에게 "인사를 건너뛰어라"라고 말하는 것은 모델이 잊어버릴 수 있는 일입니다. 반면, 토큰 분포 (token distribution)를 유효한 JSON으로 제한하는 것은 모델이 물리적으로 거부할 수 없는 일입니다. 하나는 요청 (request)이고, 다른 하나는 아키텍처 결정 (architecture decision)입니다.

이것이 당신에게 의미하는 바

당신이 최첨단 (frontier) API를 사용하여 챗봇을 구축하고 있다면: 시스템 프롬프트 (system-prompt) 억제부터 시작하여 CI 슬롭 (slop) 체크를 추가하세요. 이 조합은 대부분의 사례를 해결하며 구현에 30분 정도 소요됩니다.

당신이 분류 (classification), 추출 (extraction), 정의된 스키마 (schema)로의 요약 (summarization)과 같은 구조화된 작업을 수행하고 있다면: JSON 모드 (JSON mode) 또는 도구 사용 (tool-use) 모드를 사용하세요. 서문 문제는 완전히 사라집니다. 이 사용 사례를 위해 다른 해결책에 엔지니어링 예산을 소비하지 마세요.

당신이 개인정보 보호 우선 또는 온디바이스 (on-device) 배포를 위해 로컬 모델을 실행하고 있다면: Outlines 또는 llama.cpp 문법 제약 (grammar constraints)을 통한 제약된 디코딩 (constrained decoding)을 평가하세요. 초기 복잡성은 대량 처리 시 보상으로 돌아오며, 이는 형식적 정답성 보장 (formal correctness guarantee)을 갖춘 유일한 해결책입니다.

당신이 제어할 수 없는 제3자 API를 통합하고 있다면: 사후 처리 제거 (post-process stripping)가 당신이 가진 유일한 수단입니다. 패턴 라이브러리를 구축하고, CI에 슬롭 (slop) 체크를 추가하며, 목록을 계속 업데이트해야 한다는 점을 받아들이세요. [내부 링크: 에이전트 기반 CI/CD 파이프라인에 관한 기사]

개발자들이 LLM 서문에 대해 실제로 묻는 질문들

왜 LLM은 답변하기 전에 "물론입니다! (Certainly!)"라고 말하나요?

이러한 동작은 RLHF(Reinforcement Learning from Human Feedback, 인간 피드백 기반 강화학습)에서 비롯됩니다. RLHF는 베이스 모델(base models)을 인간의 선호도에 맞추는(align) 강화학습 과정입니다. 인간 어노테이터(Human annotators)들은 즉각적으로 답변하는 응답보다 따뜻하고 인지하는 듯한 서두(openers)를 포함한 응답에 일관되게 더 높은 점수를 부여했습니다. 보상 모델(reward model)은 이 신호를 학습했고, 정책 모델(policy model)은 이를 극대화했습니다. Singhal 등(2023)의 연구에 따르면, 응답 길이 최적화(response length optimization)가 RLHF 보상 모델링(reward modeling)에서 중요한 숨겨진 요인임을 확인했으며, 서문(preamble)은 해당 최적화의 직접적인 결과물입니다.

서문 문제는 모든 모델에 동일하게 영향을 미치나요?

아니요. 더 작은 규모의 지시어 튜닝 모델(instruction-tuned models, 7B 파라미터 미만)에서 서문 동작이 더 빈번하게 나타납니다. 이는 이 모델들이 "도움이 되는 정도(helpfulness)"를 표현할 수 있는 표현 경로(representational paths)가 더 적어, 통계적으로 가장 흔한 패턴에 의존하기 때문입니다. 2026년의 정렬(alignment) 연구에 따르면, 그 효과는 모델 제품군(model family)과 학습 레시피(training recipe)에 따라 크게 달라지며, 일부 Mistral 변형 모델에서는 2% 미만의 균질화(homogenization)를 보인 반면, Qwen3-14B instruct에서는 28% 이상을 기록했습니다. 효과의 크기는 선호도 최적화(preference optimization) 단계가 얼마나 공격적으로 적용되었는지에 따라 달라집니다.

LLM 서문을 억제하는 가장 신뢰할 수 있는 방법은 무엇인가요?

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0