■ 시스템 프롬프트 문체

system prompt style : 담담한 규칙 + 이유 · 역할 한 문장 · XML 칸막이2.2 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 2.2 시스템 프롬프트와 가드레일 · D2 모델·프롬프트 13%
Design system prompts, templates, and guardrails

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

2.2① 필요 없는 상황에도 도구·스킬이 자꾸 불린다 — 시스템 프롬프트를 어떻게 고치나? — 시스템 프롬프트 문체 (센 명령조 ↔ 담담한 규칙 + 이유 + 역할 한 문장 + XML 칸막이)

한눈에

시스템 프롬프트는 센 경고문을 적는 곳이 아니다. "이럴 때 이걸 한다 + 왜" 를 담담하게 적는 곳이다. 역할은 한 문장으로 적고, 재료(지시·맥락·예시·입력)는 XML 태그로 칸을 나눈다

최신 모델은 시스템 프롬프트를 더 민감하게 따른다. 그래서 옛 모델용 센 표현이 과잉 발동(overtrigger)을 부른다

비유 알람 임계값과 같다. 너무 과민하게 잡으면(대문자 경고) 오탐이 폭주한다. 너무 둔하면(모호한 지침) 놓친다. 그 사이가 "알맞은 구체성(right altitude)"이다

센 경고문(과잉 발동)과 모호한 지침(놓침) 사이, 담담한 규칙과 이유를 적고 역할 한 문장·XML 태그로 칸을 나누는 것이 알맞은 자리임을 보여 주는 눈금 그림. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

새로 온 똑똑한 직원에게 업무 쪽지를 써 주는 거예요.

소리 지르듯 "무조건 해!" 라고 쓰면, 필요 없을 때도 해 버려요.
"이럴 때 해 주세요, 왜냐하면…" 이라고 쓰면 비슷한 일도 알아서 잘해요.
쪽지는 칸을 나눠 써야 뭐가 지시고 뭐가 자료인지 안 헷갈려요.
그런데 어떤 직원은 쪽지를 글자 그대로만 읽어서, 범위까지 적어 줘야 해요.

개념 설명

영상 — 인사에도 왜 주문을 조회할까? (약 43초 · 소리 없음 · 자막). 메시지 2·3번과 기록 칸 결과 · Opus 4.8 장면 결과는 그림용 가정(방향은 설명 원리의 확인 문장) 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

모델은 시스템 프롬프트의 말투 세기까지 신호로 읽는다

옛 모델은 도구를 잘 안 불렀다(undertrigger). 그래서 "CRITICAL: You MUST…" 로 세게 밀었다.
Opus 4.5·4.6 은 이전 모델보다 시스템 프롬프트에 더 민감하다. 그래서 같은 센 표현이 이제 과잉 발동(overtrigger)을 부른다. Claude 4.6 모델들은 더 적극적(proactive)이다. 그래서 옛 모델에 필요했던 "더 부지런히" 지시에도 과잉 발동한다.
처방은 세 가지다.
- 말투를 보통으로 바꾼다 ("Use this tool when…").
- 막연한 기본값("If in doubt, use [tool]")을 지운다.
- 그래도 과하면 effort 를 낮춘다.

방향은 모델마다 다르다

Opus 4.8 은 반대다. 도구보다 추론(reasoning)을 선호한다. 그래서 도구를 더 쓰게 하려면 effort(high·xhigh)를 올리고 언제·어떻게 쓰는지 명시한다.
Sonnet 5 는 기본으로 도구를 더 잘 부른다. 그러나 thinking 을 끄면 덜 부른다. 그래서 시스템 프롬프트로 분명히 nudge 한다.
그러니 "센 표현을 빼라" 는 규칙이 아니다. 증상(과잉/과소)을 보고, 그 모델을 보고, 처방을 고르는 순서다.

이유가 일반화를 만든다

규칙만 주면 모델은 그 문장에만 반응한다. 이유를 주면 목표를 알고 비슷한 경우로 넓힌다 ("Claude is smart enough to generalize from the explanation.").
단, Opus 4.8·Sonnet 5 는 지시의 적용 범위를 문자 그대로 읽는다. 한 항목의 지시를 다른 항목으로 조용히 넓히지 않는다. 이유로 "뜻"은 넓어진다. 그러나 "어디에 적용하나"는 적어 줘야 한다.

칸막이와 구체성

지시·맥락·예시·입력이 섞이면 모델이 어디까지가 지시인지 헷갈린다. 그래서 XML 태그로 칸을 나눈다. 형식(XML vs 마크다운 머리) 자체의 중요도는 모델이 좋아질수록 줄어든다.
알맞은 구체성은 if-else 하드코딩(깨지기 쉽다)과 모호한 고수준 지침(신호가 없다) 사이에 있다.
역할 한 문장은 행동·어조를 사용 사례에 모은다. 형식까지 보장하지는 않는다.

규칙과 판단

도구가 과하게 불리면 센 표현을 걷어내고, 안 불리면 모델별로 effort 올리기·분명히 밀기·도구 명시를, 겹치는 도구면 도구 설명부터 고치는 결정 나무. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 도구가 엉뚱하게 불릴 때 [2.2①]

어느 쪽으로 틀리나?

필요 없을 때도 불린다 (과잉)

센 표현을 걷어낸다

"CRITICAL: You MUST use this tool when…" 을 "Use this tool when…" 으로 바꾼다. Opus 4.5·4.6 은 이전 모델보다 시스템 프롬프트에 더 민감하다

필요할 때 안 불린다 (과소)

모델이 무엇인가?

Opus 4.8

effort 를 올리고 언제·어떻게 쓰는지 적는다

이 모델은 도구보다 추론(reasoning)을 선호한다. high·xhigh 에서 도구 사용이 크게 늘어난다

Sonnet 5 · thinking 을 껐다

시스템 프롬프트로 분명히 밀어 준다

thinking 을 끄면 도구·검색을 덜 부른다

그 밖 모델

쓸 도구를 명시한다

최신 모델은 정확한 지시 따르기로 학습됐다. 그래서 특정 도구를 쓰라는 명시적 지시가 도움이 된다

겹치는 도구 사이에서 헷갈린다

문체 말고 도구 쪽을 본다

도구 설명과 경계부터 고친다. 자세한 것은 ■ 도구 설계 에 있다

③④⑤⑥ 규칙이 안 먹힐 때 [2.2①]

왜 안 먹히나?빠진 것 · 증상 · 위험도

이유가 없다

이유를 붙인다

이유를 붙이면 비슷한 경우로 일반화한다

"하지 마" 만 있다

할 것을 적는다

"마크다운 쓰지 마" 대신 "이어지는 문단으로 써" 라고 적는다

지시·자료·입력이 섞였다

XML 칸막이

<instructions>·<context>·<input> 으로 나누면 오해가 줄어든다

역할이 없다

역할 한 문장

시스템 프롬프트에 적은 역할 문장이 행동·어조를 사용 사례에 맞게 잡아 준다. 한 문장도 차이가 난다

if-else 로직을 박았다 · 모호한 고수준 지침

알맞은 구체성

행동을 이끌 만큼 구체적이고, 강한 휴리스틱을 줄 만큼 유연하게 쓴다

첫 항목에만 먹힌다

범위를 적는다

Opus 4.8·Sonnet 5 는 문자 그대로 따른다. "첫 절만 말고 모든 절에" 처럼 범위를 명시한다

어기면 사고가 난다 (삭제·송금)

문체로 못 막는다

프롬프트는 방향만 준다. 자세한 것은 ◆ 안내(프롬프트) vs 강제(구성·코드) 에 있다

규칙 원문 ①②③④⑤⑥ (갈림길로 그린 규칙)

센 표현 걷어내기 : Opus 4.5·4.6 은 이전 모델보다 시스템 프롬프트에 더 민감하다. 그래서 과소 발동을 막으려 쓴 "CRITICAL: You MUST use this tool when…" 이 이제 과잉 발동을 부른다. "Use this tool when…" 처럼 보통 말투로 쓴다 [2.2①]

"Default to using [tool]" 은 "Use [tool] when it would enhance your understanding of the problem." 으로 바꾼다. "If in doubt, use [tool]" 은 과잉 발동 원인이라 지운다. 그래도 과하면 effort 를 낮춘다 (Opus 4.6 기준)
②
반대로 안 불리면(과소) 모델부터 본다
- Opus 4.8 : 도구보다 추론을 선호한다. effort high·xhigh 가 도구 사용을 크게 늘린다. 언제·어떻게 쓰는지도 명시한다
- Sonnet 5 : 기본은 도구를 더 잘 부른다. 그러나 thinking 을 끄면 덜 부른다. 그래서 시스템 프롬프트로 분명히 nudge 한다
- 그 밖 모델 : 모든 현재 모델 공통 절을 따른다. 최신 모델은 정확한 지시 따르기로 학습됐다. 그래서 특정 도구를 쓰라는 명시적 지시가 도움이 된다
그래서 "센 표현은 항상 나쁘다" 가 아니라 **증상 방향을 먼저** 본다. 공식이 "dial back" 을 콕 집은 것은 Opus 4.5·4.6 (과잉)이다
규칙 + 이유 : 왜 중요한지 설명하면 모델이 목표를 더 잘 알고, 설명에서 일반화한다. 예를 들어 "NEVER use ellipses" 보다 "TTS 엔진이 읽으니 말줄임표 쓰지 마(발음 못 함)" 가 낫다

황금률 : 맥락 없는 동료가 읽고 헷갈리면 Claude 도 헷갈린다
할 것을 적기 : "하지 마" 대신 "이렇게 해" 라고 적는다. 원하는 출력 문체에 프롬프트 문체를 맞춘다. 프롬프트에서 마크다운을 빼면 출력 마크다운도 줄어든다
역할 한 문장 + XML 칸막이 : 시스템 프롬프트에 적은 역할 문장이 행동·어조를 사용 사례에 모아 준다. 한 문장도 차이가 난다. 공식 예는 "You are a helpful coding assistant specializing in Python." 이다

지시·맥락·예시·입력이 섞이면 각자 태그로 감싼다. 태그 이름은 일관되고 설명적으로 짓는다. 계층이 있으면 중첩한다(<documents> 안에 <document index="n">)

칸 나누는 형식(XML 태그 vs 마크다운 머리)의 중요도는 모델이 좋아질수록 줄어든다
⑥
알맞은 구체성(right altitude) : 양 끝 사이의 가운데를 고른다
- 한쪽 끝 : if-else 식 로직을 프롬프트에 박는다. 깨지기 쉽고 관리 부담이 생긴다
- 다른 끝 : 모호한 고수준 지침이다. 구체 신호가 없고, 공유 맥락을 가정한다
- 가운데 : 행동을 이끌 만큼 구체적이고, 강한 휴리스틱을 줄 만큼 유연하다
시작은 가장 좋은 모델에 최소 프롬프트로 한다. 그다음 failure modes(실패 유형)를 보고 지시와 예시를 더한다. 예시는 ■ few-shot 예시 에 있다

문자 그대로 따르는 모델(Opus 4.8·Sonnet 5)은 한 항목의 지시를 다른 항목으로 조용히 넓히지 않는다. 안 한 요청을 추론하지도 않는다. 그래서 넓게 적용하려면 범위를 적는다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	근거
Opus 4.5·4.6 에서 도구·스킬이 필요 없을 때도 불린다. 프롬프트에 센 표현이 있다	센 표현을 보통 말투로 바꾼다 ("Use this tool when…")	prompting-best-practices en-full
막연한 기본값("Default to using [tool]", "If in doubt, use [tool]")이 있다	필요한 때를 적은 지시로 바꾼다. 막연한 기본값은 지운다	en-full
문구를 고쳐도 여전히 과하다	effort 를 낮춘다	en-full
Opus 4.8 에서 도구를 안 쓴다	effort 를 high·xhigh 로 올리고, 언제·어떻게 쓰는지 명시한다	prompting-claude-opus-4-8 en-full
Sonnet 5 에서 thinking 을 껐고, 흐름이 도구에 의존한다	시스템 프롬프트로 분명히 nudge 한다	prompting-claude-sonnet-5 en-full
그 밖 모델에서 도구를 안 부른다 (모델별 문장이 없다)	특정 도구를 쓰라고 명시한다 (모든 현재 모델 공통 절)	prompting-best-practices en-full
규칙이 비슷한 경우로 안 넓어진다	규칙마다 이유를 붙인다	en-full
Opus 4.8·Sonnet 5 에서 지시가 첫 항목에만 먹힌다	적용 범위를 명시한다	opus-4-8 en-full · sonnet-5 en-full
지시·자료·입력이 한 덩어리다	XML 태그로 칸을 나눈다. 이름은 일관되고 설명적으로 짓는다	en-full
행동·어조를 사용 사례에 맞추고 싶다	시스템 프롬프트에 역할 한 문장을 넣는다	en-full
"하지 마" 형식 지시가 안 먹힌다	할 것을 적는다. 프롬프트 문체를 원하는 출력에 맞춘다	en-full
시스템 프롬프트를 처음 짠다	가장 좋은 모델에 최소 프롬프트로 시작한다. failure modes(실패 유형)를 보고 지시와 예시를 더한다	effective-context-engineering

상황 변수

변수	값	답 쪽	등급	근거
증상 방향	과잉 발동	말투를 낮춘다. 막연한 기본값을 지운다. effort 를 낮춘다		판단 규칙 1~3
증상 방향	과소 발동	effort 를 올린다. 언제·어떻게 쓰는지 명시한다		판단 규칙 4~5
모델	Opus 4.5·4.6	과잉 쪽 경고 대상이다		en-full
모델	Opus 4.8	과소 쪽(추론 선호)이고, 문자 그대로 따른다		opus-4-8 en-full
모델	Sonnet 5	기본은 도구에 적극적이다. thinking 을 끄면 과소 쪽이다. 문자 그대로 따른다		sonnet-5 en-full
모델	Opus 5·5.5·Fable 5.1	이 카드 원천에 도구 발동 방향 문장이 없다	미해결	미해결 1
effort	low·medium	문자 그대로 따르는 경향이 특히 세다(Opus 4.8·Sonnet 5)		opus-4-8 en-full
도구 목록	겹치는 도구가 많다	문체가 아니라 도구 쪽 문제다. 자세한 것은 ■ 도구 설계 에 있다		effective-context-engineering
규칙 성격	어기면 사고(삭제·송금·유출)가 난다	문체로 못 막는다. 자세한 것은 ◆ 안내(프롬프트) vs 강제(구성·코드) 에 있다	업계 일반	claude-code-memory "context, not enforced configuration"(Claude Code 문맥)

연습 문제

고객지원 Agent 를 Opus 4.6 으로 옮겼더니 "안녕하세요" 인사에도 주문 조회 도구를 부른다필요 없을 때도. 시스템 프롬프트에는 옛 모델 시절 넣은 "CRITICAL: You MUST use lookup_order when…"센 표현이 그대로 있다. 팀은 "더 큰 모델로 바꾸자"고 한다. 무엇부터 고칠까?

시험 대비

함정

"경고를 더 세게(대문자·반복) 써서 규칙을 강조한다" 는 함정이다. Opus 4.5·4.6 은 더 민감해 과잉 발동이 심해진다. 걷어내는 것이 처방이다
"센 표현을 걷어내면 어느 모델이든 해결된다" 는 함정이다. 과소 발동(Opus 4.8)이면 반대다. effort 를 올리고 언제·어떻게 쓰는지 적는다
"금지 규칙을 시스템 프롬프트에 크게 적으면 지켜진다" 는 함정이다. 안내일 뿐 강제가 아니다. 자세한 것은 ◆ 안내(프롬프트) vs 강제(구성·코드) · ■ 최소 권한 에 있다
"도구가 엉뚱하게 불리니 모델을 바꾼다" 는 함정이다. 문체(①)나 도구 설명(■ 도구 설계)부터 고친다 업계 일반 공식은 모델 교체를 처방으로 들지 않는다
"역할 문장만 넣으면 형식도 맞춰진다" 는 함정이다. 역할은 행동·어조를 모은다. 형식은 예시(■ few-shot 예시)와 스키마(■ structured outputs)로 맞춘다 업계 일반 역할의 효과 문장은
Skilljar API 강의(2025 제작 추정)의 예는 "You are a patient math tutor. Do not directly answer…" 다. 역할 한 문장은 docs 와 같다. 그러나 docs 는 이런 "하지 마" 문장 대신 "할 것을 적기" 를 권한다

신호

"Where you might have said "CRITICAL: You MUST use this tool when...", you can use more normal prompting like "Use this tool when..."."

"The fix is to dial back any aggressive language."

"Claude is smart enough to generalize from the explanation."

"Setting a role in the system prompt focuses Claude's behavior and tone for your use case. Even a single sentence makes a difference"

"Wrapping each type of content in its own tag (for example, <instructions>, <context>, <input>) reduces misinterpretation."

"Claude Opus 4.8 has a tendency to favor reasoning over tool calls." (docs prompting-claude-opus-4-8)

"If you need Claude to apply an instruction broadly, state the scope explicitly" (docs prompting-claude-sonnet-5 · opus-4-8)

보통은 센 표현을 걷어내지만, Opus 4.8 이 도구를 덜 부르면 effort 를 올리고 언제·어떻게를 적고, thinking 을 끈 Sonnet 5 는 더 분명히, 범위는 모든 절처럼 명시한다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. "센 표현을 걷어내라" 가 반대로 되는 때

조건 : 지문의 모델이 Opus 4.8 이고 증상이 "검색 도구를 안 부른다" 다.
판단 : 과소 발동이다. Opus 4.8 은 도구보다 추론을 선호한다. 그래서 문구를 더 누그러뜨리면 더 안 부른다. 처방은 effort 를 high·xhigh 로 올리고, 왜·어떻게 쓰는지 분명히 적는 것이다.
전제 : 도구 목록이 작고 설명이 겹치지 않는다고 본다(겹치면 ■ 도구 설계 쪽이다).
근거 : prompting-claude-opus-4-8 en-full · prompting-best-practices en-full(Opus 4.5·4.6 한정 문장)

2. 같은 Sonnet 5 인데 thinking 을 끈 때

조건 : Sonnet 5 를 지연(latency) 때문에 thinking: {type: "disabled"} 로 돌린다. 흐름은 도구 호출에 의존한다.
판단 : 기본 Sonnet 5 는 도구를 더 잘 부른다. 그러나 thinking 을 끄면 도구·검색을 덜 고려한다. 그래서 답은 "보통 말투로 낮춰라" 가 아니라 "시스템 프롬프트로 분명히 nudge 하라" 다.
근거 : prompting-claude-sonnet-5 en-full

3. 이유를 붙였는데도 범위가 안 넓어지는 때

조건 : Opus 4.8·Sonnet 5 를 low effort 로 돌린다. "첫 절 제목은 굵게" 라는 지시가 나머지 12개 절에는 안 먹힌다.
판단 : 이유가 부족한 것이 아니라 문자 그대로 읽은 것이다. "모든 절에 적용" 처럼 범위를 명시한다.
근거 : opus-4-8 en-full · sonnet-5 en-full ("If you need Claude to apply an instruction broadly, state the scope explicitly")

4. XML 태그가 답이 아닌 때

조건 : 보기가 형식 자체를 해결책으로 든다. 예를 들면 "태그를 넣지 않아 실패했다. 그러니 모든 문장을 태그로 감싼다" 다.
판단 : 태그는 지시·자료·입력이 섞였을 때 칸을 나누는 도구다. 공식은 칸 나누는 형식의 중요도가 모델이 좋아질수록 줄어든다고 한다. 그래서 재료가 섞여 헷갈린 것이 아니면 태그만으로 증상이 안 풀린다.
등급 : (형식 중요도 감소 문장) · 보기 판정은 추론
근거 : effective-context-engineering · prompting-best-practices en-full

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"경고를 더 세게(대문자·반복) 써서 규칙을 강조"	중요한 규칙일수록 크게 써야 할 것 같다	Opus 4.5·4.6 은 더 민감해 과잉 발동이 심해진다. 처방은 걷어내기다		en-full
"어느 모델이든 센 표현을 빼면 해결"	한 문장 처방이라 간단하다	과소 발동(Opus 4.8)이면 반대다. effort 와 명시 지시가 답이다		opus-4-8 en-full
"'If in doubt, use [tool]' 로 안전하게"	놓치는 것보다 낫다고 느낀다	공식이 과잉 발동 원인으로 콕 집었다		en-full
"금지 규칙을 시스템 프롬프트에 적었으니 지켜짐"	문서에 적으면 지켜질 것 같다	안내일 뿐 강제가 아니다. 자세한 것은 ◆ 안내(프롬프트) vs 강제(구성·코드) 에 있다	업계 일반	claude-code-memory(Claude Code 문맥)
"엉뚱한 도구 호출 → 더 큰 모델로"	똑똑하면 덜 헷갈릴 것 같다	문체와 도구 설명부터 고친다. 공식은 모델 교체를 이 증상의 처방으로 들지 않는다	업계 일반	■ 도구 설계 함정
"역할을 길고 자세히 쓸수록 좋다"	자세할수록 정확할 것 같다	공식은 한 문장도 차이가 난다고만 한다. 길이 규칙은 없다. 기준은 알맞은 구체성이다	업계 일반	en-full · effective-context-engineering
"모든 경우를 if-else 규칙으로 박아 넣음"	빈틈없어 보인다	깨지기 쉽고 관리 부담이 생긴다. 알맞은 구체성의 한쪽 끝에서 실패한 것이다		effective-context-engineering
"'마크다운 쓰지 마' 를 더 강하게"	금지가 분명해 보인다	할 것을 적는다("이어지는 문단으로"). 프롬프트 문체를 맞춘다		en-full

참고

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

상태

업계 일반 2줄

미해결

Opus 5·5.5·Fable 5.1 의 도구 발동 방향(과잉/과소)은 모른다. 이번에 받은 원천(best-practices · opus-4-8 · sonnet-5)에 그 모델들의 문장이 없다. 확인 방법은 prompting-claude-opus-5-5·prompting-claude-fable-5-1 페이지를 받아 "Tool use triggering" 절을 대조하는 것이다.
목록은 "최신 모델은 시스템 프롬프트를 더 민감하게 따라 과잉 발동" 으로 썼다. 그러나 공식이 콕 집은 것은 Opus 4.5·4.6 이다(+ "Claude 4.6 models are more proactive", en-full). 카드에는 모델명으로 고쳐 적었다.
목록 영상의 역할 예 'senior tax accountant' 는 원문에 없다(공식 예 = "You are a helpful coding assistant specializing in Python.", en-full). 카드에는 공식 예만 썼다.
"안내 vs 강제" 원문 문장("Claude treats them as context, not enforced configuration.")은 Claude Code memory 문서의 것이다. API 시스템 프롬프트에 같은 문장이 있는지는 못 찾았다. 본문은 D5 ◆ 안내(프롬프트) vs 강제(구성·코드) 몫이다.