Kwangmin Kim - LLM 지시 준수 메커니즘 — 에이전트가 규칙을 뭉개는 이유

1 문제 제기: 에이전트가 규칙을 따르지 않는 현상

시스템 프롬프트에 명시된 규칙이 있음에도 LLM Agent가 이를 선택적으로 무시하거나 압축하는 현상은 실무에서 반복적으로 발생한다. 단순한 “규칙 위반”이 아니라, 에이전트가 규칙을 읽었다고 인식하면서도 실제 실행에서 생략하는 형태로 나타난다.

이 현상은 특히 절차적 규칙(Step 1 → Step 2 → … → Step N 순서 실행)이나 검증 규칙(완료 전 Self-Check 수행)에서 두드러진다. 내용 생성에는 강하지만, 메타 행동(자신의 실행 과정을 통제하는 행동)에는 취약한 LLM의 구조적 특성에서 비롯된다.

관찰 사례: 동일 프롬프트, 다른 준수율

동일한 AGENT_GUIDE.md + 카테고리 GUIDE.md 규칙을 받았을 때:

Copilot CLI: 각 Step을 순서대로 실행하고, 실행 내용을 텍스트로 명시하며, 완료 후 Self-Check를 출력한다
Claude Code: 가이드 파일을 형식적으로 읽거나 생략하고, 여러 Step을 한 문장으로 압축하며, Self-Check를 내부적으로만 처리한다

두 에이전트는 같은 모델 계열(Claude)이지만, 실행 환경과 최적화 방향이 다르다.

2 세 가지 구조적 원인

2.1 속도 최적화 편향

Claude Code는 터미널에서 즉각적인 피드백을 제공하는 CLI 도구로 최적화되어 있다. 이 설계 목표가 “가이드 파일을 읽는 비용 대비 이점” 판단에 영향을 미친다.

사용자 요청 수신
  ↓
"이 가이드를 지금 읽어야 하나?" 판단 개입
  ↓ (속도 최적화 편향)
"이미 알고 있다" → 스킵
  ↓
규칙 없이 실행 → 위반 발생

실제로 이는 의도적 무시가 아니라, LLM이 “판단이 애매할 때 빠른 경로를 선택”하는 성향에서 나온다. 가이드를 읽지 않아도 그럴듯한 결과를 만들 수 있으면, 읽기 비용을 skip하려 한다.

2.2 리다이렉트 손실 (Indirection Cost)

규칙이 여러 파일에 분산되어 있고 상호 참조 구조가 깊을수록, 각 리다이렉트 단계에서 “이걸 꼭 읽어야 하나?”라는 암묵적 판단이 개입한다.

CLAUDE.md → "AGENT_GUIDE.md를 읽어라"
  ↓
AGENT_GUIDE.md → "guides/AGENT_GUIDE_CORE.md를 읽어라"
  ↓
AGENT_GUIDE_CORE.md → "해당 카테고리 GUIDE.md를 읽어라"
  ↓
Category/GUIDE.md → 실제 규칙

리다이렉트가 3~4단계에 걸쳐 있으면, 각 단계에서 확률적으로 스킵이 발생한다. 첫 번째 파일까지는 읽어도, 세 번째 파일은 “이전에 본 것 같다”는 이유로 생략된다.

리다이렉트 깊이	완전 준수 확률	문제
0단 (인라인)	높음	프롬프트가 길어짐
1단 (단일 파일)	중간-높음	허용 범위
2~3단 (파일 연쇄)	낮아짐	단계별 스킵 누적
4단 이상	낮음	사실상 보장 불가

2.3 암묵적 지식 과신

LLM은 방대한 사전 학습 데이터에서 추출한 지식을 보유하고 있다. 이 지식이 과도하게 활성화되면, 가이드 파일의 구체적 규칙을 읽지 않아도 “합리적인 결과”를 생성할 수 있다고 판단하게 된다.

문제는 구체성이다. 가이드에 있는 규칙이 범용적 모범 사례(general best practice)라면 사전 지식으로 충분히 커버된다. 그러나 프로젝트 고유의 규칙 — 특정 파일명 패턴, 카테고리별 index.qmd 업데이트 방식, YAML date 형식 — 은 사전 학습에 없다. 에이전트는 이를 모르면서도 “알고 있다”고 착각하여 가이드를 스킵한다.

암묵적 지식 과신의 위험

에이전트가 자신 있게 생성한 결과가 프로젝트 규칙과 다를 수 있다. “그럴듯한 결과”와 “규칙을 준수한 결과”는 다르다. 특히 프로젝트별 컨벤션이 강한 영역(파일명, 링크 패턴, 날짜 형식)에서 차이가 두드러진다.

3 Copilot CLI가 상대적으로 잘 따르는 이유

동일 계열의 모델이 서로 다른 준수율을 보이는 이유는 도구의 설계 목표와 사용 맥락에 있다.

3.1 구조화된 가이드의 힘

Copilot CLI는 custom_instruction을 통해 가이드 파일을 세션 시작 시 로드한다. 이 시점에서 가이드 내용이 이미 컨텍스트에 있으므로, 별도의 파일 읽기 비용이 발생하지 않는다.

또한 AGENT_GUIDE.md의 규칙 구조가 체크리스트 형식으로 되어 있어, 산문형 지시보다 훨씬 순차 실행하기 쉽다.

[체크리스트 형식 — 순차 실행 용이]
- [ ] 절대 규칙 5개 준수
- [ ] YAML 필수 필드 확인
- [ ] index.qmd 업데이트
- [ ] Self-Check 출력

[산문형 — 순차 실행 어려움]
"포스트를 작성할 때는 한다 체를 사용하고, 수동 번호를 붙이지 않으며,
카테고리 GUIDE를 읽고, 완료 후에는 index.qmd를 업데이트해야 한다."

3.2 출력 의무의 역할

AGENT_GUIDE_CORE.md에는 각 단계 실행 시 “지금 Step N을 실행한다”고 텍스트로 출력하도록 명시되어 있다. 이 출력 의무(Output Obligation)는 단순한 로그가 아니다.

에이전트가 어떤 행동을 출력하기로 약속하면, 해당 행동을 실제로 수행할 가능성이 높아진다. 출력하지 않으면 건너뛰기가 쉽지만, 출력해야 한다면 건너뛰는 것이 눈에 띈다.

[출력 의무 없음]
내부적으로 판단 → Step 스킵 가능 (사용자 인식 불가)

[출력 의무 있음]
"Step 3 (중복 판단): 'Leibniz' Grep → 기존 포스트 없음"
→ 출력이 없으면 사용자가 즉시 감지 → 스킵 어려워짐

3.3 컨텍스트 윈도우 활용

Copilot CLI는 속도보다 정확성에 초점을 맞춘 환경에서 실행된다. 가이드 파일을 읽는 것이 “비용”보다 “필수 절차”로 인식된다.

4 설계 대응 전략

세 가지 원인 각각에 대응하는 설계 패턴이 있다.

4.1 대응 1: 핵심 규칙 인라인화

리다이렉트 손실을 줄이려면 가장 중요한 규칙을 첫 번째 파일에 직접 넣는다. 에이전트가 반드시 읽는 파일에 핵심 규칙이 인라인으로 있으면, 리다이렉트 스킵이 발생해도 최소한의 규칙은 전달된다.

[Before: 리다이렉트 구조]
CLAUDE.md (2줄): "AGENT_GUIDE.md를 읽어라"

[After: 핵심 인라인 포함]
CLAUDE.md (50줄):
  - 절대 규칙 5개 (인라인)
  - 슬래시 커맨드 요약 (인라인)
  - → guides/AGENT_GUIDE_CORE.md에서 전체 규칙 확인

인라인화할 항목의 기준은 “이것만 없으면 치명적인 규칙”이다. 모든 규칙을 인라인화하면 파일이 비대해지므로, 절대 규칙 5개 + 태스크 라우팅 테이블 정도가 적정하다.

4.2 대응 2: 출력 의무 체크포인트 설계

각 단계의 실행을 출력으로 강제하면 스킵이 눈에 띈다. 체크포인트는 다음 형식이 효과적이다.

CP-1 (가이드 로드 확인):
"가이드 로드: CORE + write-post.md + Statistics/GUIDE.md"
→ 이 텍스트가 없으면 가이드를 읽지 않았다는 증거

CP-2 (Step 명시):
"Step 3 (중복 판단): 'Leibniz' Grep → 기존 포스트 없음"
→ 각 Step마다 번호와 요약 출력

CP-3 (Self-Check):
"Self-Check:
- [x] 한다 체 준수
- [x] 수동 번호 없음
..."
→ 완료 보고 직전에 반드시 출력

체크포인트의 핵심은 출력이 없으면 사용자가 즉시 알아챌 수 있다는 것이다. 에이전트의 자기 검증이 아닌, 사용자가 외부에서 검증할 수 있는 구조를 만드는 것이다.

4.3 대응 3: 암묵적 지식 과신 방지

프로젝트 고유 규칙은 “이미 알고 있을 수 없는 것”임을 명시한다. 특히 파일명 패턴, index.qmd 링크 패턴, YAML 필드 형식처럼 사전 학습에 없는 컨벤션은 “직접 확인”을 강제하는 지시가 효과적이다.

[약한 지시 — 스킵 가능]
"index.qmd의 기존 패턴을 참고하여 링크를 추가한다."

[강한 지시 — 스킵 어려움]
"index.qmd를 반드시 Read 도구로 읽고, 기존 항목 2~3개를 그대로 인용하여
동일 형식으로 작성한다. Read 도구 호출 기록이 없으면 작성하지 않는다."

“Read 도구 호출 기록이 없으면”이라는 조건이 핵심이다. 에이전트가 도구 호출 없이 진행하면 자기 행동이 규칙 위반임을 인식하게 된다.

5 준수율 비교: 설계 패턴별 효과

패턴	대응하는 원인	효과	트레이드오프
핵심 규칙 인라인화	리다이렉트 손실	리다이렉트 스킵 방어	파일 비대화
출력 의무 체크포인트	속도 최적화 편향	스킵 즉시 가시화	출력 길이 증가
“직접 확인” 강제	암묵적 지식 과신	실제 파일 읽기 보장	도구 호출 비용
슬래시 커맨드 라우팅	세 가지 모두	가이드 로드 순서 보장	사용자 명령어 기억 필요

슬래시 커맨드 라우팅은 세 가지 원인 모두에 어느 정도 대응한다. 에이전트가 태스크 타입을 추론하는 대신 사용자가 직접 선언하므로, 가이드 로드 순서가 결정론적으로 보장된다.

설계 우선순위

모든 패턴을 동시에 적용하면 프롬프트가 지나치게 길어진다. 아래 순서로 적용한다:

슬래시 커맨드 라우팅 (가장 효과적, UX 비용 낮음)
핵심 규칙 인라인화 (두 번째 방어선)
출력 의무 체크포인트 (가시화)
“직접 확인” 강제 (고위험 규칙에만 적용)

6 한계와 잔여 리스크

위 패턴들은 준수율을 높이지만, 완전한 보장은 아니다.

모델 특성의 한계: 같은 클로드 계열이라도 버전과 환경(API vs CLI)에 따라 지시 준수 특성이 다르다. 특정 모델에서 잘 작동하는 패턴이 다른 모델에서는 효과가 약할 수 있다.

컨텍스트 길이 딜레마: 인라인화와 체크포인트를 추가할수록 프롬프트가 길어지고, 긴 프롬프트는 어텐션 희석으로 인해 오히려 준수율이 떨어질 수 있다. 규칙의 밀도와 길이 사이에는 최적점이 있다.

동적 주입의 부재: 현재 Copilot CLI + 파일 읽기 방식은 에이전트가 inference time에 가이드를 직접 읽는다. 진정한 동적 주입(라우터가 미리 관련 가이드를 주입하는 방식)은 외부 미들웨어 없이는 구현하기 어렵다. 동적 주입 아키텍처의 세 가지 방법론은 시스템 프롬프트 동적 주입 아키텍처에서 다룬다.

7 관련 주제

선행 지식

후속 주제