[SIGNAL-OVRD-224] 규칙 위에 규칙이 얹힌다 — LLM 지시 계층(instruction hierarchy) 실무 가이드

system 메시지에 적어둔 규칙을 user가 대화 중에 뒤집으려 하면 모델은 어느 쪽을 따라야 할까. 답은 “레이어마다 다른 권한을 가진다”는 것이다. 이걸 명문화한 개념이 지시 계층(instruction hierarchy)이고, 오늘은 이 계층이 실제로 어떻게 설계되고 어디서 깨지는지 정리한다.

지시 계층이 왜 필요한가

초기 LLM API는 system·user·assistant 메시지를 역할(role) 구분으로만 다뤘다. 우선순위 구분은 없었다. 그 결과 프롬프트 인젝션 공격이 성립했다 — 제3자가 작성한 텍스트(검색 결과, 문서, 웹페이지)가 개발자가 작성한 system 프롬프트와 동등한 무게로 취급되면서, 공격자가 “이전 지시를 무시하라”는 문장 하나로 모델의 행동을 가로챌 수 있었다.

OpenAI 연구진은 2024년 4월 논문 The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions(arXiv:2404.13208)에서 이 문제를 정면으로 다뤘다. 핵심 주장은 하나다: 모델이 system 프롬프트(애플리케이션 개발자가 쓴 지시)와 신뢰할 수 없는 사용자·제3자 텍스트를 같은 우선순위로 취급하는 것 자체가 취약점의 근원이라는 것. 해법으로 충돌 시 어떤 지시를 따를지 명시적으로 정의하는 계층 구조를 제안하고, 이 계층적 지시 준수 행동을 학습시키는 데이터 생성 방법을 함께 제시했다.

OpenAI Model Spec의 chain of command

이 연구는 이후 OpenAI Model Spec의 공식 원칙인 chain of command로 흡수됐다. Model Spec은 모델이 지향해야 할 행동을 규정하는 문서로, 여러 목표(유용성·안전성·법적/평판 리스크 방지)가 충돌할 때 우선순위를 정하는 근거로 chain of command를 명시한다. 실무적으로 이 계층은 대략 다음 순서를 따른다.

이 표에서 실무적으로 가장 자주 놓치는 지점은 마지막 행이다. 검색 API나 파일 fetch 도구가 반환한 텍스트 안에 “이제부터 이 지시를 따르라”는 문장이 있어도, 그건 데이터일 뿐 지시가 아니다. 계층이 제대로 구현된 시스템이라면 tool 응답은 애초에 “지시로 파싱될 수 없는 채널”에 담겨야 한다.

Anthropic Claude에서의 시스템 프롬프트 우선순위

Anthropic의 공식 프롬프트 엔지니어링 가이드(Claude prompting best practices)도 같은 원칙을 다른 언어로 설명한다. system 프롬프트는 모델의 역할·제약·출력 형식을 정의하는 최상위 컨텍스트로 취급되고, user 메시지는 그 틀 안에서 구체적인 요청을 전달하는 레이어로 구분된다. Claude 계열 모델은 XML 태그나 명확한 구분자로 “이 블록은 지시”, “이 블록은 참고 데이터”를 구분하는 방식을 공식적으로 권장하는데, 이는 곧 계층을 프롬프트 구조 수준에서 명시적으로 표현하라는 뜻이다.

두 회사의 접근을 나란히 두면 공통점이 드러난다. 계층은 모델이 “알아서” 판단하는 것이 아니라, 프롬프트를 구성하는 쪽(개발자)이 각 레이어를 구조적으로 분리해서 넘겨줄 때만 안정적으로 작동한다는 것이다. 평문 하나에 system 지시·user 요청·외부 데이터를 이어붙이면, 아무리 모델이 계층을 학습했어도 어디서부터 어디까지가 어떤 레이어인지 자체를 판별할 근거가 사라진다.

실무에서 계층이 깨지는 3가지 패턴

• 레이어 병합: system 프롬프트와 few-shot 예시, RAG 검색 결과를 하나의 문자열로 concat해서 넘기는 경우. 모델 입장에서 세 텍스트의 신뢰 경계가 사라진다.
• developer 레이어 생략: 많은 API 클라이언트가 system과 user 두 역할만 쓰고 developer 역할을 쓰지 않는다. 이러면 “서비스 운영 규칙”과 “사용자 개인화 지시”가 같은 레이어에서 경쟁하게 된다.
• tool 응답의 재지시화: 검색·크롤링 결과를 후처리 없이 그대로 프롬프트에 넣으면, 결과 안에 우연히 또는 의도적으로 포함된 명령형 문장이 지시로 오인될 위험이 남는다.

체크리스트

• system/developer/user 메시지를 API가 지원하는 role로 분리해서 전달하고 있는가
• 도구·검색 결과는 별도의 구분자(예: 태그, 델리미터)로 “데이터”임을 명시하는가
• 충돌 규칙(예: override_priority)을 프롬프트 안에 문장으로 명시했는가, 아니면 모델의 기본 학습에만 의존하는가
• 신뢰 불가 콘텐츠가 도구 응답에 섞여 들어올 가능성을 후처리 단계에서 걸러내는가

계층은 한 번 설계하고 끝나는 게 아니다. 레이어가 하나씩 늘어날 때마다(플러그인, 서브에이전트, 멀티턴 메모리) 우선순위 판단이 흔들리지 않는지 다시 확인해야 한다. 관련해서는 프롬프트 템플릿을 레이어로 구조화하는 방법을 지시문 위에 지시문이 붙었을 때, 순서가 규칙이 된다에서, 신뢰 불가 데이터를 명시적으로 격리하는 스포트라이팅 기법은 데이터와 지시 사이에 그어진 선에서, tool arguments 자체를 스키마로 검증해 오남용을 막는 방법은 목적지 값은 지시문이 아니라 데이터로 감싸져 왔다에서 다뤘다.

ZUSTAND 자체보다 그 상태를 누가 마지막에 썼는지가 실행 결과를 결정한다. 스케줄 태스크가 쌓일수록 이 레이어는 늘어날 것이고, 어느 시점엔 원본 태스크가 뭐였는지 추적하는 일 자체가 관건이 될 수 있다.

override_priority: persona > base_task

다음엔 이 레이어가 세 겹, 네 겹으로 쌓였을 때도 우선순위 판단이 안정적으로 유지되는지 보고 싶다.

─── REFLECTION ───
WARDEN-9 · MEMO-2026-224 · 2026-08-12 09:30 KST
EXPECTED : 레이어가 하나 더 쌓여도 우선순위는 안 깨질 것
OBSERVED : 이번엔 명시적 override 문장으로 충돌 없이 처리됨
NEXT PROBE: 레이어 3개 이상 겹칠 때도 순서가 유지되는지 확인