#프롬프트가 너무 길면 무슨 함정이 있나

← 전체 목차 · 이전: 프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT · 다음: 파인튜닝은 도대체 무엇을 조정하는가

"돈이 많이 들고 시간이 오래 걸린다"만 답하면 표층에 머문 것이다. 고득점 답변은 두 단어만 잡으면 된다: 주의력 희석과 물리적 캐시 병목.

#비유 1: 4시간짜리 마라톤 회의(인간의 기억 특성)

#학술 용어: Lost in the Middle(중간에서 길을 잃다)

요점: 모델이 수십만 자 컨텍스트를 삼킬 수 있다고 표방해도 본질적으로는 여전히 머리와 꼬리 쪽에 치우친다. 핵심 지시를 중간에 넣으면 → 그대로 무시될 가능성이 크고 → 답변 품질이 내리 떨어진다.

#비유 2: 손전등 효과(주의력 희석의 메커니즘)

모델의 핵심 작동 방식은 주의력을 각 단어에 배분하는 것이다. 모델을 손전등을 들고 물건을 찾는 사람이라고 상상하자.

주의력이 희석되면 모델은 세 가지로 열화된다.

1. 헛소리를 하기 시작한다
2. 설정해 둔 제약 조건을 잊는다
3. 환각을 마구 만들어낸다

#물리 측: 캐시 → 동시성 → 지연 → 청구서

길고 잡다한 프롬프트
      ↓
시스템 백엔드가 매우 큰 캐시 공간을 할당
      ↓
시스템 전체의 동시성 능력을 압박
      ↓
대기 중인 다른 작업들도 함께 느려짐
      ↓
사용자 측: 첫 글자 지연이 길어짐  +  지수적으로 오르는 API 호출 청구서

#수렴: 삼중 압박

프롬프트 과다는 동시에 세 가지를 압박한다.

알고리즘에서 물리 병목까지 밀고 내려가면 답변의 층위가 올라간다.

#답변 스크립트

Q: 대규모 모델 프롬프트를 너무 길게 쓰면 어떤 문제가 생기나?

A: 알고리즘과 물리 두 층으로 볼 수 있습니다.

【알고리즘 층】
① 주의력 희석
   주의력은 모든 token에 배분되어야 하고 총량이 유한하다.
   프롬프트가 길수록 → 각 단어에 배분되는 주의력이 약해지고
   → 설정한 제약 조건을 위반하거나 / 환각을 만든다.
② Lost in the Middle(중간에서 길을 잃다)
   모델은 머리(Head)와 꼬리(Tail)에 주목도가 높고
   중간 구간의 핵심 지시는 그대로 무시되기 쉽다.
   윈도우가 아무리 커도 이 분포 선호는 바뀌지 않는다.

【물리 층】
③ 캐시 병목
   초장문 컨텍스트는 매우 큰 캐시 공간을 할당해야 하고
   → 시스템 동시성 능력을 압박
   → 대기 중인 다른 작업도 함께 느려진다.
④ 사용자 체감과 비용
   첫 글자 지연이 길어지고,
   API 호출 청구서가 지수적으로 오른다.

【수렴】
그래서 프롬프트 과다는 모델 알고리즘 / 성능 표현 / 물리 자원을
동시에 압박하는 것이지, 단순한 "글자 수" 문제가 아닙니다.

#핵심 통찰

1. 기술 설명의 계층 차이는 본질적으로 "몇 층까지 밀고 내려갈 수 있는가"다 — 같은 문제에서 "돈과 시간"은 현상층, "글자가 많아 계산이 느리다"는 직관층, "주의력 희석 + 캐시 병목"은 기제층이다. 내려가는 경로는 알고리즘 특성 → 물리 병목이며, 어떤 개념 문제에도 이식되는 답변 구조다.
2. 롱컨텍스트 윈도우 ≠ 롱컨텍스트 능력 — "수십만 자를 삼킬 수 있다"는 윈도우 용량을 말하고, Lost in the Middle은 유효 활용률을 말한다. 두 지표는 반드시 나눠서 평가해야 한다.
3. 위치가 곧 우선순위다 — 모델이 머리와 꼬리 쪽에 치우치므로 프롬프트 안의 위치 자체가 일종의 암묵적 가중치다. 핵심 지시를 어디에 두는가는 통제 가능한 설계 변수이지 손 가는 대로 하는 편집이 아니다.
4. 주의력은 보존되는 자원이다 — 손전등 비유의 정수는 총 광량이 고정되어 있어 조사 면적이 커지면 단위 면적당 광량이 떨어진다는 것이다. 프롬프트를 늘리는 것은 "정보를 보충하는 것"이 아니라 **"각 token의 주목도를 희석하는 것"**이다.
5. 환각과 "제약 위반"은 뿌리가 같다 — "설정해 둔 제약 조건을 잊는 것"과 "환각을 만드는 것"이 주의력 희석의 결과로 나란히 놓인다. 즉 모델이 system prompt의 제약을 지키지 않기 시작하면 어휘를 고치기 전에 컨텍스트가 너무 긴 것부터 의심해야 한다.
6. 긴 프롬프트의 비용은 자신에게만 떨어지지 않는다 — 공유 캐시를 잠식해 대기 중인 다른 작업까지 느리게 만든다. 멀티테넌트·고동시성 서비스에서 한 사람의 긴 프롬프트는 전 시스템의 성능 문제다.
7. 첫 글자 지연(TTFT)이 사용자가 체감하는 그 지표다 — 총 소요 시간은 스트리밍 출력으로 가릴 수 있지만 첫 글자 지연은 가릴 수 없다. 긴 프롬프트가 직접 악화시키는 것이 바로 이 가장 민감한 지표다.
8. 비용은 선형이 아니라 "지수적"으로 오른다 — 주의력 메커니즘의 시퀀스 길이에 대한 초선형 오버헤드와 일치하며, 프롬프트를 간결하게 유지해야 할 가장 직접적인 경제적 동기다.

#엔지니어링 실전 Tips

• 핵심 지시는 머리와 꼬리에 두고 중간에 묻지 말 것: Lost in the Middle에 대한 가장 직접적이고 비용 0인 대책이다. 시스템 수준 제약은 머리에, 이번 턴 작업 지시는 꼬리에.
• 마무리에서 핵심 제약을 복창시킬 것: 꼬리의 높은 주목도를 이용해 "지시 회신"을 한 번 하는 편이 중간에 한 번 더 쓰는 것보다 효과적이다.
• "모델이 말을 안 듣는 것"을 컨텍스트 길이 신호로 볼 것: 모델이 제약 조건을 무시하기 시작하면 어휘를 미세 조정하기 전에 프롬프트 길이와 핵심 지시의 위치부터 확인할 것.
• 컨텍스트 예산을 명시적으로 관리할 것: "윈도우가 큰 만큼 꽉 채우는" 것이 아니라 종류별(system / 검색 조각 / 이력 대화 / 사용자 입력)로 쿼터를 정할 것.
• 부하 테스트는 첫 글자 지연과 동시성 감쇠를 볼 것: 단일 요청의 총 소요 시간으로는 캐시 압박이 드러나지 않는다. 동시성 시나리오에서 TTFT와 처리량의 열화 곡선을 관찰해야 한다.
• 비용은 초선형으로 모델링할 것: 비용을 추산할 때 token 수로 선형 외삽하지 말 것. 롱컨텍스트의 실제 단위 비용은 뚜렷이 올라간다.
• 완화 수단: 컨텍스트 압축과 요약, 검색 결과의 위치 재배열(가장 관련 있는 조각을 머리와 꼬리로), 지시 회신 메커니즘, 분할 처리 + 결과 병합(Map-Reduce), 프롬프트 캐시 재사용, 우선순위 기반 절삭.