AI 코딩 규칙은 '어디에 두느냐'에 따라 효과가 달라진다──컨텍스트 구조 관점에서의 고찰

서론

"코딩 규약을 CLAUDE.md에 적어두었는데, AI가 아무렇지도 않게 무시한다"——AI 코딩을 실무에서 사용하고 있는 사람이라면 누구나 한 번쯤 이 벽에 부딪혀 본 적이 있을 것이다.

그리고 많은 이들이 "규칙의 작성 방식이 잘못된 것이리라"라고 생각하며, 표현을 다듬고, 예시를 추가하며, 강조를 늘린다. 그럼에도 효과가 없다.

본고의 주장은 심플하다. 문제는 규칙의 '내용'이 아니라 '위치'에 있는 경우가 많다. 같은 규칙이라도 컨텍스트 윈도우 (Context Window)의 어디에, 어떤 형태로, 어느 타이밍에 배치되느냐에 따라 AI의 준수율은 크게 달라진다.

여기서는 "왜 위치에 따라 효과가 달라지는가"를 컨텍스트 윈도우의 구조, 위치 효과, 로드(Load) 메커니즘이라는 관점에서 정리한다. 어디까지나 공개된 정보와 필자의 실무 경험에 기반한 고찰 및 가설이며, 특정 모델에 대한 정량적 벤치마크가 아님을 미리 밝혀둔다. "규칙을 써도 지켜지지 않는다", "CLAUDE.md가 점점 효과가 없어진다"라고 느끼는 분들을 위한 고찰로서 읽어주신다면 감사하겠다.

5줄 요약 (클릭하여 확장)

TL;DR (5줄 요약)

컨텍스트 윈도우 내의 위치는 "평등"하지 않으며, 앞부분과 뒷부분이 중간보다 효과가 잘 나타난다 (lost in the middle 현상)
규칙은 "지시 (Instruction)"로서 배치하느냐 "자료 (Context)"로서 배치하느냐에 따라 가중치가 달라진다. 시스템 프롬프트 (System Prompt)에 해당하는 위치가 가장 강력하다.
대화가 길어질수록 초반에 배치한 규칙은 최근의 주고받은 대화에 밀려 상대적으로 희석된다
"상주 로드 (CLAUDE.md)"와 "매번 참조 (파일 읽기)"는 AI의 의식에 반영되는 확실성에서 차이가 난다.
결론: 규칙은 적게, 구조화하여, 효과적인 위치에, 필요한 타이밍에 배치한다. 양을 늘린다고 해서 효과가 높아지는 것이 아니다.

1. "규칙을 썼는데 지켜지지 않는" 문제의 정체

먼저 구분해야 할 것은, 준수되지 않는 원인은 크게 세 가지로 나뉜다는 점이다.

원인의 층위	증상	본고의 범위
내용의 문제	규칙이 모호하거나 모순됨	△ (가볍게 언급)
...	...	...

많은 사람은 첫 번째를 의심하며 문장을 다듬지만, 실제로는 두 번째와 세 번째가 작동하지 않는 케이스가 많다. "올바르게 쓰는 것"과 "효과적인 위치에 두는 것"은 별개의 문제다.

여기서 중요한 전제가 하나 있다. LLM은 주어진 컨텍스트 전체를 "일률적으로 동일하게" 읽는 것이 아니다. 토큰 (Token)에는 위치가 있고, 위치에는 가중치의 편향이 존재한다. 이 편향을 이해하면 "왜 같은 규칙이 효과가 있기도 하고 없기도 한지"가 보인다.

2. 컨텍스트 윈도우는 "평등"하지 않다

위치 효과 (lost in the middle)

LLM의 컨텍스트 활용에 관한 연구에서 반복적으로 보고되는 것은, 입력의 앞부분 근처와 뒷부분 근처의 정보는 활용되기 쉬운 반면, 중간에 놓인 정보는 상대적으로 간과되기 쉽다는 경향이다 (이른바 "lost in the middle" 현상).

이는 규칙 배치에 직접적인 영향을 미친다. 긴 컨텍스트의 "한복판"에 중요한 금지 사항을 심어두면, 그것은 구조적으로 가장 무시되기 쉬운 위치에 놓이게 된다.

[컨텍스트 윈도우]
┌───────────────────────────────────────┐
│ 앞부분: 효과가 좋음 (primacy) │ ← 시스템 프롬프트 / 서두의 지시
...

무엇을 의미하는가

반드시 지키게 하고 싶은 규칙은 **앞부분 (시스템 프롬프트에 가깝게) 혹은 최근의 지시 (뒷부분)**에 두는 것이 합리적이다.
방대한 참고 자료 중간에 규칙을 섞는 것은 가장 효과가 떨어지는 배치 방법이 될 수 있다.

3. 규칙은 "지시"인가 "자료"인가

같은 문자열이라도 LLM에게 "이것은 따라야 할 지시다"라고 해석되는 배치 방식과, "이것은 참고 정보다"라고 해석되는 배치 방식이 있다.

시스템 프롬프트에 해당하는 위치가 가장 강력하다

많은 채팅형 LLM은 메시지에 system / user / assistant와 같은 역할 (Role)을 가진다. 일반적으로 system 역할에 배치된 지시는 대화를 통해 지속적으로 효과가 나타나도록 설계 및 학습되어 있다.

❌ 약한 배치 방식 (자료로서 끼워 넣기)

다음은 프로젝트 정보입니다.
... (긴 배경 설명) ...
그런데 코드는 TypeScript로 작성해 주세요.
...

✅ 강한 배치 방식 (지시로서 명시)

[system 相当의 위치]
당신은 이 프로젝트의 코드를 작성하는 어시스턴트입니다.
다음 제약 사항을 항상 준수하십시오:
...

도구에 따라 이 「role(역할)에 대한 할당」은 내부적으로 수행된다. 예를 들어 CLAUDE.md나 .cursorrules의 내용은, 도구가 시스템 프롬프트(System Prompt)에 상당하는 위치에 주입하도록 설계되어 있는 경우가 많다 (구현 상세는 도구 및 버전에 따라 다르다). 따라서 "어느 파일에 쓰는가"는 사실 "어떤 role에 실리는가"를 간접적으로 결정한다.

"자료 속의 규칙"이 약한 이유

RAG (Retrieval-Augmented Generation)를 통해 가져온 문서나, 대화 중에 붙여넣은 긴 코드 안에 규칙을 작성하더라도, 그것은 AI에게 "참조해야 할 정보의 일부"일 뿐 "따라야 할 제약"으로서 명시되지 않는다. 지시와 자료의 경계가 모호하면, 규칙은 자료로 격하된다.

4. 규칙에는 "신선도"가 있다

CLAUDE.md에 규칙을 확실히 작성했음에도 불구하고, 대화가 길어지면 점점 지켜지지 않는다 —— 이런 경험은 흔히 있다. 이것 또한 배치(정확히는 "시간적 배치")의 문제다.

거리가 멀어지면 희석된다

대화가 진행될수록, 초반에 배치한 규칙과 "지금 바로 생성하려는 토큰" 사이의 거리는 멀어진다. 최근의 상호작용(최신성(Recency)이 작용하는 끝부분)에는 새로운 코드나 지시가 쌓이게 되며, 상대적으로 규칙의 존재감은 희석된다.

턴 1: [규칙] ← 여기서 제시
턴 2~20: 구현 논의, 코드, 에러 대응 …
턴 21: "그럼 다음 함수를 작성해줘"
...

대책: 규칙을 "재주입"하기

상주 로드형 (CLAUDE.md / .cursorrules): 이 방식의 강점은 도구가 매 턴마다 맨 앞에 재주입해 준다는 점에 있다. 이는 신선도 문제에 대한 구조적인 대책이 된다.
반대로 "처음에 한 번만 붙여넣은 규칙"은 긴 대화 속에서 확실히 희석된다. 중요한 규칙은 매 단계(節目)에서 짧게 재게시하거나, 상주 로드 메커니즘에 싣는 것이 유효하다.

5. "양"을 늘린다고 해서 더 잘 듣는 것은 아니다

이 부분은 직관과 반대되는 지점이다. 규칙은 많으면 많을수록 잘 지켜지는 것이 아니다. 오히려 역효과를 낼 때가 있다.

신호 대 노이즈 비 (Signal-to-Noise Ratio)

100줄의 지시서 안에 정말 중요한 금지 사항이 3개 묻혀 있다고 가정하자. AI는 그 3개와 나머지 97줄의 "있으면 좋은 정도의 지시"를 가중치 차이 없이 받아들인다. 결과적으로 최우선 규칙이 묻혀버린다.

양이 늘어나면, 앞서 언급한 "중간에 묻히는" 위치 효과(Position Effect)의 리스크도 높아진다.
서로 가볍게 모순되는 지시가 늘어나, AI가 무엇을 우선해야 할지 판단하는 데 혼란을 겪는다.

대책: 우선순위를 구조로 나타내기

"모두 중요하다"는 "어느 것도 중요하지 않다"와 같다. 지키게 하고 싶은 순서대로 나열하고, 양을 압축하라. 필자의 실무 감각으로도, 지시서는 "길고 자세하게"보다 "짧고 우선순위가 있는" 편이 준수율이 안정적으로 유지되기 쉽다.

# 지키는 순서 (위로 갈수록 절대적)
1. [MUST] any 타입 금지 · 타입 안전성 최우선
2. [MUST] 외부 입력은 반드시 유효성 검사(Validation) 수행
...

6. 구조화하여 "효과를 내기"

지난 글에서는 "AI에 대한 컨텍스트는 XML 라이크(XML-like)한 태그로 구조화하면 해석이 안정되기 쉽다"고 썼는데, 이는 규칙 배치에도 그대로 적용된다.

규칙의 "범위"를 명시하기

3절에서 지시와 자료의 경계가 모호하면 규칙이 자료로 격하된다고 언급했다. 태그로 감싸는 것은 그 경계를 명시하는 가장 간단한 방법이다.

❌ 경계가 모호함

TypeScript를 사용해서, any는 피하고, 그리고 외부 입력은 유효성 검사하고,
이 프로젝트는 Next.js 15로…

✅ 범위와 우선순위를 명시

<rules>
<rule priority="must">코드는 TypeScript로만 작성. any 타입 금지</rule>
<rule priority="must">외부 입력은 반드시 유효성 검사를 수행할 것</rule>
...
</rules>

<rules>와 <context>를 분리함으로써, "어디까지가 따라야 할 제약이고 어디서부터가 참고 정보인지"를 한눈에 확정할 수 있다. priority 속성을 통해 가중치의 차이도 명시할 수 있다. 이는 "위치"가 아니라 "구조"로 효과를 보강하는 접근 방식이다.

7. 실전: 어디에 무엇을 둘 것인가

지금까지의 정리를 배치 장소별 지침으로 요약한다.

배치 장소	작동 방식	적합한 규칙
시스템 프롬프트 (System Prompt) / CLAUDE.md / `.cursorrules`	최상단·상주·매 턴 재주입. 가장 강력함	반드시 지켜야 하는 MUST 계열 (타입 안정성, 금지 사항, 출력 형식)
최근 사용자 지시 (末尾, 끝부분)	최신성 (Recency) 효과. 해당 시점에 강력함	해당 태스크 고유의 일시적인 제약 사항
참조 파일 (수시로 읽기)	읽었을 때만 작동. 확실성은 중간	상세한 규약집·너무 커서 상주시키기 어려운 지식
...

배치 원칙 (4가지)

적게 (Less) — MUST를 압축한다. 신호 대 잡음비 (Signal-to-Noise Ratio)를 높인다.
구조화하여 (Structured) — <rules> 태그 등으로 범위와 우선순위를 명시한다.
효과적인 위치에 (Effective Position) — 최상단(상주) 또는 최신 위치에 둔다. 중간에 묻어두지 않는다.
필요한 타이밍에 (Timely) — 긴 대화에서는 전환점에서 재게시하거나, 상주 로드(Resident Load)에 포함시킨다.

요약

"규칙을 썼는데도 지켜지지 않을 때", 우리는 흔히 문장 표현을 의심한다. 하지만 많은 경우, 효과가 없는 것은 내용이 아니라 배치 때문이다.

컨텍스트 윈도우 (Context Window)는 균질한 공간이 아니라, 위치·역할·거리에 따라 정보의 가중치가 변한다. 그렇기에 같은 규칙이라도 "최상단에·지시로서·짧고·구조화하여 배치"하면 지켜지기 쉽고, "자료 중간에·장문과 섞어서·단 한 번만 배치"하면 지켜지기 어렵다.

표현을 다듬기 전에, 먼저 배치를 의심하는 것이 문제 해결의 지름길이 된다.

AI를 위한 규칙 설계는 "무엇을 쓸 것인가"만큼이나 "어디에·어떻게·언제 둘 것인가"가 중요하다.

본고의 원칙(적게·구조화하여·효과적인 위치에·필요한 타이밍에)을 일상적인 개발 흐름으로 시스템화하고 싶다면, 필자가 개인 개발 중인 OSS AI Dev OS가 참고가 될 수도 있다. 다만 본고의 지침은 특정 도구에 국한되지 않으며, CLAUDE.md나 .cursorrules, 혹은 순수 프롬프트(Raw Prompt)에서도 동일하게 응용할 수 있다.

참고

Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023) — 긴 컨텍스트에서의 위치 효과를 보고한 대표적인 논문
Prompting best practices — Anthropic Docs — XML 태그 구조화 및 System Role 사용법을 포함한 공식 프롬프트 엔지니어링 가이드
Prompt caching — Anthropic Docs — 최상단에 고정된 접두사(Prefix)를 캐싱하는 메커니즘
Prompt Engineering — OpenAI Docs — 타 모델에서의 지시 설계 참고 자료