27. 시스템 프롬프트 설계

시스템 프롬프트란

지금까지의 프롬프트가 이번 한 번의 지시였다면, 시스템 프롬프트는 대화 전체·여러 작업에 걸쳐 지속되는 설정입니다. 역할, 지켜야 할 규칙, 톤, 출력 기본값 등을 한 번 정해두면 매 메시지에 반복하지 않아도 적용됩니다. 챗 앱의 "커스텀 인스트럭션", "프로젝트 설정", API의 시스템 메시지가 모두 여기 해당합니다.

📌 핵심: 시스템 프롬프트는 "이 대화/이 봇이 항상 어떻게 행동해야 하는가"를 정합니다. 매번 바뀌는 작업 내용은 일반 프롬프트에, 변하지 않는 행동 원칙은 시스템 프롬프트에 두는 것이 기본 분업입니다.

가장 중요한 원칙 — 딱 맞는 "고도"

시스템 프롬프트 설계의 핵심 난점을, 한 제공자는 고도(altitude) 비유로 설명합니다. 너무 낮게(시시콜콜하게) 날면 융통성이 없어지고, 너무 높게(막연하게) 날면 방향이 안 잡힙니다. 둘 다 실패 모드입니다.

flowchart TB
    high["너무 높음 (막연)<br/>'도움이 되게 잘 행동해'<br/>→ 방향이 없음"] 
    sweet["딱 맞는 고도<br/>명확한 원칙 + 판단 여지<br/>→ 일관되되 유연"]
    low["너무 낮음 (시시콜콜)<br/>모든 경우를 if-then으로 나열<br/>→ 깨지기 쉽고 융통성 없음"]

    high -.->|내려라| sweet
    low -.->|올려라| sweet

    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class high,low bad
    class sweet good

너무 낮은 경우 (시시콜콜)

모든 상황을 규칙으로 못박으려는 시도입니다. "고객이 X라고 하면 Y로, Z라고 하면 W로..."를 끝없이 나열하면, 예상 못 한 상황에서 무너지고, 규칙끼리 충돌하며, 유지보수가 악몽이 됩니다. 한 제공자는 이렇게 하드코딩된 복잡한 로직이 깨지기 쉽고 유지가 어렵다고 경고합니다.

너무 높은 경우 (막연)

반대로 "전문적이고 도움이 되게 행동하라" 수준이면, 모델이 구체적 상황에서 어떻게 해야 할지 방향을 못 잡습니다(5장 모호함 문제가 시스템 레벨에서 반복).

딱 맞는 고도

명확한 원칙과 휴리스틱을 주되, 구체적 판단은 모델의 추론에 맡기는 수준입니다. "왜"를 설명하는 원칙은, 일일이 나열한 규칙보다 새로운 상황에 잘 일반화됩니다.

너무 낮음 ❌
"환불 문의면 정책 링크를 보내고, 단 14일 지났으면 거절하되,
VIP면 예외로 승인하고, 단 금액이 10만원 넘으면 상급자에게...
(끝없는 분기)"

딱 맞음 ✅
"너는 고객의 문제 해결을 우선하는 CS 담당자다.
환불은 <환불정책>을 근거로 판단하되, 정책이 모호한 경계 사례는
고객에게 유리하게 해석하고 '상급자 확인 후 안내' 경로를 제시한다.
정책 밖 사안은 단정하지 말고 담당자 연결로 안내한다."

아래는 원칙(문제 해결 우선)과 판단 기준(정책 근거, 경계는 고객 유리), 실패 경로(확인 후 안내)를 주되, 모든 경우를 나열하지 않습니다. 새로운 상황에도 원칙으로 대응할 수 있습니다.

시스템 프롬프트의 구성 요소

작업에 따라 다르지만, 자주 들어가는 블록들:

💡 팁: 11장의 구조화를 시스템 프롬프트에도 적용하세요. 위 블록들을 구분자(태그·제목)로 나누면, 길어져도 모델이 각 부분을 명확히 인식합니다. 단, 14장의 중간 소실을 떠올려 가장 중요한 원칙은 앞쪽에 두세요.

길이의 함정

시스템 프롬프트는 매 요청에 항상 포함되므로, 길수록 매번 토큰·비용을 먹고 attention을 차지합니다(3부). "혹시 몰라" 규칙을 계속 추가하다 보면 비대해지고, 중요한 원칙이 묻힙니다(중간 소실).

⚠️ 흔한 실수·미신: "시스템 프롬프트에 가능한 모든 규칙을 넣어두면 안전하다"는 틀렸습니다. 4부에서 본 모든 컨텍스트 함정이 그대로 적용됩니다 — 길수록 신호가 희석되고, 규칙이 충돌하며, 유지가 어려워집니다. 시스템 프롬프트야말로 "고신호 최소집합"(13장)이 중요한 곳입니다.

🔧 개발자 노트: 시스템 프롬프트는 보통 프롬프트의 가장 앞·정적인 부분이라 캐싱에 유리합니다(6부). 자주 바뀌지 않게 설계하고, 변동 부분(사용자별 데이터 등)은 뒤쪽 메시지로 분리하면 캐싱 이점과 깨끗한 구조를 함께 얻습니다. 또 시스템 프롬프트는 평가(23장) 대상으로 삼아, 규칙을 바꿀 때마다 회귀 테스트하세요 — 한 규칙 추가가 다른 동작을 망가뜨리는 일이 흔합니다. 모델 이전 시에도 시스템 프롬프트가 새 모델에서 같게 동작하는지 반드시 재검증합니다(9장의 교훈).

시스템 vs 일반 프롬프트 — 무엇을 어디에

시스템 프롬프트 (지속)         일반 프롬프트 (매번)
─────────────────          ─────────────────
- 역할·정체성                 - 이번 작업 내용
- 변하지 않는 원칙·톤          - 이번 입력 자료
- 출력 기본값                 - 이번만의 특수 요청
- 안전·경계                   - 구체적 질문

🧪 직접 검증법: 시스템 프롬프트가 너무 시시콜콜한지 보려면, 예상 못 한 입력을 던져보세요. 규칙에 없는 상황에서 모델이 합리적으로 대응하면 고도가 적절한 것이고, 우왕좌왕하거나 엉뚱하게 굴면 원칙이 부족하거나 규칙에 과의존하는 것입니다.

이 장에서 배운 것

• 시스템 프롬프트는 대화·여러 작업에 걸쳐 지속되는 설정으로, 변하지 않는 행동 원칙을 담는다. 변하는 작업 내용은 일반 프롬프트에 둔다.
• 핵심 원칙은 "딱 맞는 고도"다. 시시콜콜한 규칙 나열은 깨지기 쉽고, 막연한 지시는 방향이 없다. 원칙+판단 여지가 새 상황에 잘 일반화된다.
• 자주 쓰는 구성 블록: 역할·핵심원칙·톤·출력기본값·경계·실패처리·자료/도구 규칙. 구조화하고 중요한 것을 앞에 둔다.
• 매 요청에 포함되므로 길이가 곧 비용·희석이다. 시스템 프롬프트야말로 고신호 최소집합이 중요하다.
• 시스템 프롬프트는 캐싱에 유리하고, 평가·모델 이전 시 반드시 회귀 검증 대상이다.

✍️ 확인 문제

1. "시스템 프롬프트에 모든 예외 상황을 if-then 규칙으로 다 적어두면 봇이 완벽해진다"는 접근의 문제를, "고도" 비유로 설명해보세요.

1. 다음 항목을 시스템 프롬프트와 일반 프롬프트 중 어디에 둘지 분류해보세요.
   • (a) "항상 존댓말을 쓴다"
   • (b) "이 이메일을 요약해줘"
   • (c) "근거 없는 사실은 지어내지 않는다"
   • (d) "이번엔 특별히 캐주얼한 톤으로"

1. (실습) 사내 IT 헬프데스크 봇의 시스템 프롬프트를, "딱 맞는 고도"로 설계해보세요. 구성 블록을 활용하되, 시시콜콜한 규칙 나열을 피하고 원칙 중심으로 작성하세요.

다음 → 28. 멀티턴과 에이전트 맥락의 프롬프트
이전 ← 26. 검색·도구와 결합하기 · 목차