Kwangmin Kim - Skill-Based Prompt의 실전 제약: 어텐션 희석과 2-Pass 워크플로우

1 배경: 왜 이 문제를 다루는가

시스템 프롬프트 분해 6단계에서 긴 시스템 프롬프트를 코어 + 스킬 구조로 분해하는 방법론을 다루었다. 이 방법론을 블로그 관리 시스템에 실제 적용한 결과, 스킬 설계의 구조는 잘 작동했으나 콘텐츠 품질 규칙이 체계적으로 무시되는 현상이 관찰되었다. 이 포스트는 그 현상의 원인(어텐션 희석)과 대응 전략을 정리한다.

2 어텐션 희석 (Attention Dilution) 문제

시스템 프롬프트에 규칙을 추가할수록 LLM의 어텐션이 분산되면서, 가중치가 뚜렷한 굵직한 지시만 경쟁에서 살아남고 세부 규칙은 무시되는 현상이다.

2.1 관찰된 증상

블로그 시스템에서 TBD 메모를 정식 포스트로 전환하는 과정에서 다음 패턴이 반복되었다:

형식 규칙(YAML 헤더, 한다 체, 수동 번호 금지)은 잘 따름 — 패턴이 명확하고 기계적이라 가중치가 높다
콘텐츠 품질 규칙(구체적 예시 유지, 섹션 간 연결, 주장-근거-해석)은 자주 무시됨 — 판단이 필요하고 실행 비용이 높아 가중치 경쟁에서 밀린다
원본 TBD에 있던 코드 비유, before/after 대비, 구체적 시나리오가 포스트 전환 시 “~와 동일하다”는 한 줄 요약으로 축소됨

구체적 사례를 보면:

# 원본 TBD (구체적)
구작은 형식+콘텐츠 둘 다 문제이고, 신작 저품질은 콘텐츠만 문제이다.
retrofit-post.md의 Step 1(형식 교정)은 구작에만 필요하고,
Step 3(콘텐츠 보강)은 둘 다에 필요하다.

# 포스트 전환 후 (축소됨)
구작과 신작 저품질은 동일한 구조적 문제를 가진다.

원본의 before/after 대비가 사라지고 추상적 한 줄로 압축되었다. 이것이 어텐션 희석의 전형적 증상이다.

2.2 원인 분석

원인	설명
규칙 수 증가 → 어텐션 희석	규칙이 많을수록 각 규칙에 할당되는 어텐션이 줄어든다. 형식 규칙과 콘텐츠 규칙이 경쟁하면 패턴이 명확한 형식 규칙이 이긴다
LLM 요약 편향	긴 원문을 짧은 포스트로 전환할 때 “핵심 원리 추출 + 구체적 예시 삭제” 방향으로 기울어진다. 학습 데이터에서 “요약 = 추상화”로 패턴이 형성되었기 때문이다
생성 노력 분산	한 세션에서 복수 포스트를 작성하면 각 포스트에 할당되는 생성 노력이 분산된다

세 원인이 동시에 작용하면 결과가 특히 나쁘다. 형식 규칙이 어텐션을 선점하고, LLM의 요약 편향이 구체적 예시를 삭제하며, 복수 포스트 생성으로 각 포스트의 품질이 더 떨어진다.

2.3 이론적 배경: Lost in the Middle과 위치 편향

어텐션 희석은 LLM 연구에서 이미 알려진 현상의 연장선에 있다.

Lost in the Middle (Liu et al., 2023): 긴 컨텍스트를 처리하는 LLM은 시작 부분과 끝 부분의 정보를 잘 활용하지만, 중간 부분의 정보는 놓치는 경향이 있다. 10개의 문서를 컨텍스트에 넣었을 때, 정답이 1번이나 10번 문서에 있으면 잘 찾지만, 5~7번 문서에 있으면 성능이 떨어진다.

이 현상이 시스템 프롬프트 규칙에도 적용된다:

시스템 프롬프트의 규칙 배치:
[시작] ─── 규칙 A, B, C ─── [중간] ─── 규칙 D, E, F ─── [끝] ─── 규칙 G, H
         ↑ 높은 attention              ↑ 낮은 attention           ↑ 높은 attention

블로그 시스템의 관찰 결과를 이 프레임으로 재해석하면:

형식 규칙(YAML 헤더, 한다 체)은 코어 상단에 위치 → 높은 attention → 잘 따름
콘텐츠 품질 규칙은 스킬 파일의 중간 이후에 위치 → 낮은 attention → 자주 무시

규칙 간 가중치 경쟁: 형식 규칙과 콘텐츠 규칙이 모두 컨텍스트에 있을 때, LLM이 제한된 attention 자원을 배분한다. 형식 규칙은 패턴 매칭이 명확하고 실행 비용이 낮아 “이기기 쉬운” 규칙이다. 콘텐츠 규칙은 판단이 필요하고 실행 비용이 높아 “지기 쉬운” 규칙이다.

[가중치 경쟁의 비유]
형식 규칙: "date는 MM/DD/YYYY 형식이다" → 기계적 치환, 비용 낮음 → 항상 이김
콘텐츠 규칙: "주장 뒤에 반사실적 비교를 추가하라" → 창작 필요, 비용 높음 → 자주 짐

이것은 사람에게 동시에 10가지를 시키는 것과 같다.
"이름표 달아라"(쉬움)와 "기획서를 써라"(어려움)를 동시에 주면,
사람도 이름표부터 다 달고 기획서는 대충 쓴다.

2.4 규칙 수와 품질의 관계: 역전점 판단

“규칙을 추가할수록 품질이 올라가다가, 어느 지점에서 역전된다”는 것을 알고 있지만, 그 지점을 어떻게 판단하는가?

역전점의 징후:

징후	의미	대응
새 규칙을 추가했는데 기존에 잘 따르던 규칙의 위반이 증가	어텐션 총량이 포화 상태	새 규칙을 제거하거나 다른 규칙을 빼서 자리를 만든다
같은 규칙인데 어떤 태스크에서는 따르고 어떤 태스크에서는 안 따름	태스크별 컨텍스트 밀도 차이	해당 태스크의 스킬에서 불필요한 규칙을 정리
agent가 규칙을 “인용”하면서도 실제 출력은 위반	규칙을 “알고 있지만” 실행에 반영할 attention이 부족	규칙을 줄이거나 강조 방식 변경

실무 가이드라인:

경험적으로, 하나의 스킬 파일에서 agent가 동시에 준수할 수 있는 규칙 수는 핵심 규칙 5~7개 수준이다. 이것은 인간의 작업 기억 용량(Miller의 7±2)과 유사한 제약이다. 정확한 수치는 모델, 규칙의 복잡도, 태스크의 난이도에 따라 다르지만, 방향은 일관된다: 동시 활성 규칙 수를 한 자릿수로 유지한다.

[좋은 예 — 핵심 규칙만]
## 작성 시 필수 체크 (3개)
1. 원본의 구체적 예시를 축소하지 않는다
2. 섹션 간 연결 고리를 명시한다
3. 주장 뒤에 근거를 붙인다

[나쁜 예 — 규칙 과부하]
## 작성 시 필수 체크 (12개)
1. 원본의 구체적 예시를 축소하지 않는다
2. 섹션 간 연결 고리를 명시한다
3. 주장 뒤에 근거를 붙인다
4. 수식 양쪽에 공백을 넣는다
5. 코드 블록에 언어 태그를 넣는다
6. 인라인 코드는 백틱으로 감싼다
7. 표의 정렬을 맞춘다
...
→ 4~12번은 형식 규칙이다. 이미 코어에 있으므로 여기 반복하면 어텐션만 뺏긴다

3 대응 전략: 규칙을 늘리지 않고 “가중치가 높은 규칙”만 반정규화

3.1 어텐션 희석의 역설

품질을 높이려고 규칙을 추가하면, 규칙 수 증가로 어텐션이 희석되어 오히려 품질이 떨어진다. 따라서 체크리스트를 길게 늘리는 것이 아니라, 가장 빈번하게 위반되는 것만 짧고 강하게 작성 시점에 배치한다.

이것은 소프트웨어의 반정규화(denormalization)와 같은 원리이다. 데이터베이스에서 정규화가 원칙이지만, 읽기 성능을 위해 의도적으로 중복을 허용하는 것처럼, 시스템 프롬프트에서도 규칙의 논리적 위치(audit 스킬)와 별개로 위반 빈도가 높은 규칙만 작성 스킬에 중복 배치한다.

3.2 판단 기준

규칙 성격	배치	이유
위반 빈도 높고 치명적	작성 스킬에 반정규화 (최소 개수만)	작성 시점에 잡아야 효과적
나머지	audit에서 사후 검증	작성 시점에 넣으면 어텐션 희석 가중
전부 반정규화	금지	규칙 과부하 → 어텐션 희석 → 역효과

“전부 반정규화 금지”가 핵심이다. 감사 항목이 7개(A~G)라면, 작성 스킬에는 위반 빈도 1, 2위인 2개만 사전 체크리스트로 넣는다:

원본의 구체적 예시를 추상적 한 줄로 축소하지 마라
섹션 간 연결 고리를 생략하지 마라

나머지 5개는 작성 후 감사 단계에서 검증한다.

3.3 규칙 배치 전략: 위치와 형식이 가중치를 결정한다

같은 규칙이라도 어디에, 어떻게 쓰느냐에 따라 agent가 따를 확률이 달라진다. Lost in the Middle 현상과 가중치 경쟁을 고려한 배치 전략이다.

위치 전략:

[스킬 파일 내 규칙 배치 — 가중치가 높은 순]
1. 파일 최상단 (## 이 스킬의 핵심 규칙)  ← 가장 높은 attention
2. 해당 Step 바로 앞               ← 실행 시점에 가까워 효과적
3. 파일 최하단 (## 주의사항)          ← 시작 다음으로 높은 attention
4. 파일 중간                       ← 가장 낮은 attention — 여기에 중요 규칙을 두면 안 된다

형식 전략:

형식	효과	적합한 규칙
굵은 글씨 + 부정형 (“~하지 마라”)	높음 — 금지는 허용보다 강하다	치명적 위반 방지 (삭제 금지, 축소 금지)
번호 목록 (1. 2. 3.)	중간 — 순서와 완결성을 암시	절차적 규칙 (Step별 체크리스트)
WRONG/CORRECT 예시 쌍	높음 — 패턴 매칭 가능	형식 규칙, 스타일 규칙
산문형 설명	낮음 — 읽히지만 실행에 반영 안 됨	배경 설명, 동기 (실행 규칙에는 부적합)

“가중치 예산” 사고법:

하나의 스킬에 할당할 수 있는 어텐션 총량을 고정된 예산으로 생각한다. 규칙을 추가할 때마다 예산에서 차감된다.

[어텐션 예산 = 100이라고 가정]
핵심 콘텐츠 규칙 3개 × 20 = 60  (구체적, 판단 필요, 비용 높음)
형식 규칙 2개 × 5 = 10         (기계적, 이미 코어에 있음)
절차 규칙 3개 × 10 = 30        (Step 순서)
합계: 100 → 예산 내

여기에 "형식 규칙 5개를 추가"하면:
형식 규칙 7개 × 5 = 35         (+25)
→ 합계 125 → 예산 초과
→ 콘텐츠 규칙의 실질 가중치가 줄어든다

이 비유의 핵심: 형식 규칙은 단가가 낮지만 수가 많으면 총량이 커서 콘텐츠 규칙의 자리를 잠식한다. 코어에 이미 있는 형식 규칙을 스킬에 반복하지 않는 것이 콘텐츠 규칙의 가중치를 보호하는 가장 효과적인 방법이다.

4 2-Pass 워크플로우: 1차 생성 + 2차 보강을 전제한 운영

어텐션 희석이 존재하는 한, agent의 1회 생성으로 완벽한 포스트를 기대하는 것은 비현실적이다. 대신 1차 생성 + 2차 보강을 전제한 워크플로우가 현실적이다.

TBD → convert-tbd로 포스트 생성 (1차: 구조 + 기본 콘텐츠)
    ↓
audit에서 품질 검증 (감사 항목 A~J)
    ↓
부족하면 → retrofit-post Step 3(콘텐츠 보강)으로 2차 보강
    ↓
완성

이것은 SW에서 “코드 작성 → 리뷰 → 수정”이 한 사이클에 안 끝나고 2~3 라운드 도는 것과 같다. 완벽한 1회 생성을 기대하는 것은 코드 리뷰 없이 커밋하겠다는 것과 같은 발상이다.

4.1 왜 2-Pass가 1-Pass보다 나은가

핵심은 각 Pass에서 경쟁하는 규칙 수가 줄어든다는 것이다.

[1-Pass — 모든 규칙이 동시에 경쟁]
형식 규칙 (5개) + 구조 규칙 (3개) + 콘텐츠 규칙 (5개) = 13개 동시 경쟁
→ 콘텐츠 규칙이 밀려서 품질 저하

[2-Pass — 규칙을 시간적으로 분리]
1차 Pass: 구조 + 기본 콘텐츠 (형식 규칙 5개 + 구조 규칙 3개 = 8개)
2차 Pass: 콘텐츠 보강만 (콘텐츠 규칙 5개만)
→ 각 Pass에서 경쟁 규칙 수가 적어 어텐션 밀도 증가

2-Pass의 본질은 어텐션 경쟁의 시간적 분리이다. 시스템 프롬프트 유형 분류와 혼합 설계에서 다룬 계층적 라우팅이 공간적 분리(스킬 파일을 나눠서 동시 로드량을 줄임)라면, 2-Pass는 시간적 분리(한 세션에서 할 일을 나눠서 동시 경쟁 규칙 수를 줄임)이다.

4.2 각 Pass의 역할 분담

	1차 Pass (생성)	2차 Pass (보강)
목표	구조가 올바른 포스트 생성	콘텐츠 품질 향상
사용 스킬	convert-tbd 또는 write-post	retrofit-post Step 3
활성 규칙	YAML, 한다 체, 섹션 구조, index 업데이트	구체적 예시 보존, 섹션 연결, 주장-근거-해석
품질 기대	형식 100%, 콘텐츠 60~70%	콘텐츠 90%+
실패 모드	형식 위반 (드묾)	보강 부족 (audit에서 재검증)

1차와 2차의 입출력 관계:

1차 입력: TBD 메모 (비정형, 구체적 예시 포함)
1차 출력: .qmd 파일 (형식 OK, 콘텐츠 기본)
         ↓
2차 입력: 1차 출력 + 원본 TBD (원본의 구체적 예시를 참조 가능)
2차 출력: .qmd 파일 (형식 OK, 콘텐츠 보강)

2차 Pass의 핵심은 원본 TBD를 다시 참조할 수 있다는 것이다. 1차에서 축소된 예시를 2차에서 원본과 대조하여 복원할 수 있다. 1차에서 “~와 동일하다”로 축소된 부분을 2차에서 원본의 before/after 대비를 보고 복원하는 식이다.

4.3 2-Pass vs N-Pass

2-Pass를 넘어 3-Pass, 4-Pass로 늘리면 더 좋은가? 대부분의 경우 아니다.

[수익 체감]
1-Pass → 2-Pass: 큰 개선 (형식과 콘텐츠의 경쟁 해소)
2-Pass → 3-Pass: 작은 개선 (세부 품질 향상)
3-Pass → 4-Pass: 거의 무의미 (2차 보강으로 이미 잡힌 문제)

+ Pass마다 컨텍스트 전환 비용 발생
+ Pass마다 사용자 개입 또는 자동화 오버헤드 증가

경험적으로, 생성(1차) + 보강(2차) + 검증(audit)의 3단계가 비용 대비 품질의 최적점이다. 이것은 SW에서 “코드 작성 → 코드 리뷰 → 수정”의 3단계가 가장 일반적인 것과 같다. 4차, 5차 리뷰가 있는 조직도 있지만, 대부분의 버그는 1차 리뷰에서 잡힌다.

4.4 retrofit-post의 이중 역할

retrofit-post 스킬은 사실 두 가지 문제를 동시에 해결한다:

원래 목적: skill-based 체계 도입 이전의 구작 포스트를 현행 규칙에 맞게 교정
숨겨진 목적: agent가 새로 작성했지만 어텐션 희석으로 품질이 떨어진 포스트를 보강

이 두 가지는 구조적으로 같은 문제이다:

구작 포스트:    사람이 규칙 없이 썼다         → 형식 위반 + 콘텐츠 빈약
신작 저품질:    agent가 규칙은 있지만 못 따랐다 → 형식 OK + 콘텐츠 빈약

구작은 형식+콘텐츠 둘 다 문제이고, 신작 저품질은 콘텐츠만 문제이다. retrofit-post의 Step 1(형식 교정)은 구작에만 필요하고, Step 3(콘텐츠 보강)은 둘 다에 필요하다. 하나의 스킬이 두 유형의 입력에 모두 작동하는 것은, 문제의 본질이 같기 때문이다.

5 시스템 프롬프트 설계에 대한 메타 시사점

이 관찰은 Skill-Based Prompt 방법론 자체에 대한 메타 피드백이다:

직관	사실
스킬을 잘 설계하면 agent의 행동을 제어할 수 있다	맞다, 하지만 100%는 아니다
규칙이 많아질수록 제어력이 올라간다	틀리다, 어느 지점부터 역전된다
최적 규칙 수가 존재한다	맞다, 그리고 그 수는 생각보다 적다

시스템 프롬프트 설계는 “무엇을 넣을까”보다 “무엇을 뺄까”가 더 중요한 설계이다. 이것이 코드와의 결정적 차이이다.

코드:     기능을 추가해도 기존 기능이 희석되지 않는다
프롬프트:  규칙을 추가하면 기존 규칙의 효과가 희석된다

코드에서는 모듈을 추가해도 기존 모듈이 느려지지 않는다(의존성 없는 한). 프롬프트에서는 규칙을 추가하면 기존 규칙에 할당되는 어텐션이 줄어든다. 코드는 격리가 가능하지만, 프롬프트 규칙은 하나의 어텐션 풀을 공유한다.

따라서 프롬프트 설계의 최적화 방향은:

코드: 필요한 기능을 추가한다 (더하기 최적화)
프롬프트: 불필요한 규칙을 제거한다 (빼기 최적화)

5.1 “빼기 최적화”의 실행 방법

“불필요한 규칙을 제거한다”는 원칙은 명확하지만, 어떤 규칙이 불필요한지 판단하는 것이 어렵다. 제거 후보를 식별하는 구체적 방법이다.

제거 후보 식별 기준:

질문	Yes일 때 조치
이 규칙은 코어에 이미 있고, 이 스킬에서 반복하고 있는가?	스킬에서 제거 (코어에 위임)
이 규칙은 agent가 규칙 없이도 이미 잘 따르는가?	제거 (LLM의 기본 능력에 위임)
이 규칙은 audit에서 사후 검증할 수 있는가?	스킬에서 제거, audit으로 이동
이 규칙은 최근 3회 이상 위반된 적이 없는가?	제거 검토 (효과 없는 규칙일 수 있음)

제거의 안전장치 — audit이 있으면 스킬에서 뺄 수 있다:

2-Pass 워크플로우에서 audit 단계가 있으므로, 스킬에서 규칙을 빼도 audit에서 잡을 수 있다. 이것이 2-Pass의 숨겨진 이점이다. audit이 있기 때문에 스킬을 가볍게 유지할 수 있고, 스킬이 가벼우므로 핵심 규칙의 어텐션이 높아진다.

[1-Pass 시스템에서의 딜레마]
스킬에서 규칙을 빼면 → 위반 시 잡을 수 없다 → 빼기 어렵다
→ 규칙이 계속 쌓인다 → 어텐션 희석 → 품질 저하

[2-Pass 시스템에서의 해결]
스킬에서 규칙을 빼도 → audit에서 잡을 수 있다 → 안심하고 뺄 수 있다
→ 스킬의 규칙이 적다 → 어텐션 밀도 높음 → 품질 향상

6 종합: 어텐션 희석 대응의 3가지 축

이 포스트에서 다룬 대응 전략을 3가지 축으로 정리한다.

축	전략	이전 포스트와의 관계
공간적 분리	스킬을 파일로 나눠 동시 로드량을 줄인다	시스템 프롬프트 분해 6단계의 핵심
시간적 분리	2-Pass로 규칙 경쟁을 시간축에서 분리한다	이 포스트의 2-Pass 워크플로우
가중치 분리	반정규화로 중요 규칙의 어텐션 가중치를 보호한다	프롬프트 설계와 SW 설계의 반정규화 판단 기준

세 축은 독립적으로 적용할 수 있지만, 함께 적용하면 효과가 곱해진다. 스킬 분해(공간)로 동시 로드 규칙을 줄이고, 2-Pass(시간)로 생성과 검증을 분리하고, 반정규화(가중치)로 핵심 규칙의 우선순위를 보장한다.

7 관련 주제

선행 지식

시스템 프롬프트 분해 6단계 — 공간적 분리(스킬 분해)의 방법론. 본 포스트는 분해만으로 해결되지 않는 문제를 다룬다
시스템 프롬프트 유형 분류와 혼합 설계 — 계층적 라우팅의 컨텍스트 밀도 분석이 어텐션 희석의 정량적 배경
프롬프트 설계와 SW 설계의 구조적 대응 — 반정규화 판단 기준. 본 포스트의 “가중치 분리” 축의 이론적 근거

후속 주제

코드베이스 분석 Agent의 스킬 설계 — 어텐션 희석을 고려한 실전 스킬 설계 사례

관련 포스트

스킬 패턴의 실전 적용: 블로그 지식 관리 시스템 — 이 포스트의 관찰이 발생한 실제 시스템
Claude Code의 Long Context 대응 전략 — 컨텍스트 윈도우 관리의 실무적 접근