프롬프트 길이와 구조 설계

1 개요

실무를 하다보면 프롬프트 길이에 대한 질문이 자주 나온다. “시스템 프롬프트는 얼마나 길어야 하나요?”라는 질문에 대한 답은 “상황에 따라 다르다”이지만, 일반적인 가이드라인과 고려해야 할 요소들을 정리해보자.

2 핵심 결론

프롬프트 길이에 정답은 없다. 길이 자체보다 구조와 밀도가 중요하다. 같은 500줄이라도 비구조화된 텍스트 나열과 시맨틱 XML 태그로 구조화된 프롬프트는 LLM의 이해도에서 큰 차이가 난다.

3 길이별 가이드라인

구분	토큰 수	대략적 줄 수	용도
짧은 프롬프트	~500	~50줄	단순 분류, 요약, 번역
중간 프롬프트	500~2,000	50~200줄	대부분의 업무용 챗봇, RAG
긴 프롬프트	2,000~5,000	200~400줄	복잡한 도메인 전문가, few-shot 포함
매우 긴 프롬프트	5,000+	400줄 이상	멀티 에이전트, 코드 생성, 복잡한 워크플로

4 길어도 되는 경우

4.1 Few-shot 예시가 많을 때

예시가 많을수록 LLM 성능이 올라가는 것은 실증된 사실이다. 도메인 특화 작업에서 3~5개의 few-shot 예시는 프롬프트를 길게 만들지만, 그만큼 답변 정확도를 높인다.

4.2 도메인 규칙이 복잡할 때

데이터 표준화처럼 4계층 사전 체계(단어/도메인/용어/코드)를 다루는 경우, 각 사전의 구성 항목과 구분 규칙, 결정 트리 등을 모두 포함하면 350줄 이상이 자연스럽다.

4.3 분기 로직이 다양할 때

질문 유형별로 다른 처리가 필요한 경우 (범위 외 질문, 표준화 수행 요청, 원칙 안내 등) 각 분기에 대한 지시가 필요하므로 길어질 수밖에 없다.

5 길면 생기는 실제 문제

5.1 1. Lost in the Middle

LLM은 프롬프트의 앞부분과 뒷부분에 더 주의를 기울이고, 중간에 있는 지시를 놓치는 경향이 있다. 이 현상은 모델 크기와 무관하게 발생한다.

중요

대응 전략: 가장 중요한 규칙은 프롬프트의 앞쪽이나 뒤쪽에 배치한다. 시맨틱 XML 태그(<boundaries>, <fix-...> 등)로 구조화하면 LLM이 섹션 경계를 인식하여 중간 내용도 잘 참조한다.

5.2 2. 지시 충돌

길어질수록 서로 모순되는 규칙이 들어갈 확률이 올라간다.

# 충돌 예시
"추상적 답변 금지" vs "150토큰 이내로 요약"
"문서에 없는 내용 포함 금지" vs "PCR 분야 실무 사례 제공"

힌트

대응 전략: 우선순위를 명시한다. “(모든 규칙보다 최우선)”, “(매우 중요)” 같은 표현이나 결정 테이블로 규칙 간 우선순위를 정한다.

5.3 3. 비용

프롬프트 토큰은 매 호출마다 과금된다. Input 토큰 비용을 무시할 수 없다.

프롬프트 크기	일 호출 수	월 input 토큰	GPT-4.1 기준 월 비용 (추정)
1,000 토큰	1,000회	30M	~$60
5,000 토큰	1,000회	150M	~$300
5,000 토큰	10,000회	1.5B	~$3,000

노트

Prompt Caching을 지원하는 모델(Claude, GPT)을 사용하면 반복되는 시스템 프롬프트 부분의 비용을 크게 줄일 수 있다.

5.4 4. 디버깅 난이도

프롬프트가 길수록 어떤 지시가 답변 품질에 영향을 주는지 추적하기 어려워진다. 특정 답변 오류가 발생했을 때, 350줄 중 어느 부분이 원인인지 특정하려면 체계적인 ablation이 필요하다.

힌트

대응 전략: 프롬프트를 시맨틱 섹션으로 나누고, 섹션 단위로 ON/OFF하며 A/B 테스트를 수행한다. XML 태그로 구조화되어 있으면 특정 태그를 제거하는 것만으로 ablation이 가능하다.

6 구조화가 길이보다 중요한 이유

같은 내용이라도 구조화 방식에 따라 LLM의 준수율이 달라진다.

6.1 비구조화된 프롬프트 (v1 패턴)

template: |
  ## 역할
  당신은 전문가이다.

  ## 답변 구조 (매우 중요)
  * 서론 부분
  * 본문 부분 (중요)
  * 결론 부분

  ## 답변 가이드
  * 한국어 답변 원칙
  * 표준화 요청 질문 처리 가이드

  ## 사전 유형 구분 규칙 (매우 중요)
  ...350줄의 평문 나열...

6.2 구조화된 프롬프트 (v2 패턴)

template: |
  <role>전문가 역할 정의</role>

  <boundaries>
  CAN: ...
  CANNOT: ...
  </boundaries>

  <question-routing>
  | 조건 | 행동 |
  |------|------|
  | 범위 외 | 안내 후 종료 |
  | 수행 요청 | 경고 + 가이드 |
  </question-routing>

  <fix-domain-selection>
  WRONG: "번호"라는 단어로 도메인 결정
  CORRECT: 데이터의 실제 목적으로 판단
  </fix-domain-selection>

6.3 구조화의 효과

측면	비구조화	구조화
Lost in the Middle	중간 규칙 놓침	XML 태그가 경계 역할
지시 충돌 감지	전문을 읽어야 발견	섹션별로 독립 검증 가능
A/B 테스트	전체 교체만 가능	태그 단위 ON/OFF
디버깅	350줄 전체 추적	특정 태그만 분석
유지보수	수정 시 부작용 예측 어려움	섹션 간 의존성 명확

7 수확 체감 지점

7.1 Few-shot 예시 수

예시 수	효과
0개 (zero-shot)	기본
1~2개	큰 성능 향상
3~5개	최적 구간 (수확 체감 시작)
6개 이상	미미한 추가 향상, 비용만 증가

7.2 프롬프트 길이

토큰 수	판단 기준
~2,000	대부분의 태스크에 충분
2,000~5,000	복잡한 도메인에서 정당화 가능
5,000 이상	Progressive Disclosure(스킬 분리)를 검토할 시점

경고

5,000토큰을 넘기면 단일 프롬프트 대신 스킬 분리 또는 멀티 프롬프트 체인을 고려해야 한다. 질문 유형을 먼저 분류하고, 해당 유형에 맞는 짧은 프롬프트를 동적으로 로딩하는 방식이 비용과 성능 모두에서 유리하다.

8 실무 체크리스트

프롬프트 길이를 결정할 때 확인할 항목이다.

• 모든 규칙이 실제로 답변 품질에 기여하는가? (불필요한 규칙 제거)
• 중복되는 지시가 있는가? (동일한 규칙이 여러 곳에 반복)
• 서로 충돌하는 규칙이 있는가? (우선순위 명시)
• 가장 중요한 규칙이 프롬프트 앞/뒤에 배치되어 있는가?
• 시맨틱 태그로 구조화되어 있는가?
• few-shot 예시가 3~5개 범위인가?
• 5,000토큰을 넘기면 스킬 분리를 검토했는가?
• A/B 테스트로 각 섹션의 기여도를 검증할 계획이 있는가?

9 요약

원칙	설명
길이는 도메인 복잡도에 비례	단순 분류는 짧게, 4계층 사전 체계는 길게
구조 > 길이	XML 태그 구조화가 단순 길이 축소보다 효과적
5,000토큰이 분기점	이를 넘기면 스킬 분리 또는 프롬프트 체인 검토
A/B 테스트가 최종 판단 기준	이론보다 실측이 확실