프로덕션 앱을 위한 시스템 프롬프트 예시 7가지 (2026 복사-붙여넣기 템플릿)

최고의 시스템 프롬프트 예시는 튜토리얼에서 흔히 볼 수 있는 "당신은 유용한 어시스턴트입니다" 같은 한 줄짜리 문구가 아닙니다. 이들은 새벽 2시에 프로덕션 앱이 엉망이 되는 것을 막아주는 구체적인 지시 블록들입니다. 저희 콘텐츠 파이프라인에서는 10개 이상의 Claude 하위 에이전트를 운영 중이며, 각 에이전트는 Claude Opus 4.8이나 GPT-5에서 버그를 발생시킨 후 여러 차례 재작성된 시스템 프롬프트로 제어됩니다. 이 글에서는 장난감 데모는 건너뜁니다. 대신 실제 프로덕션 스택에서 직접 가져온 두 가지를 포함한, 복사해서 바로 사용할 수 있는 7개의 실제 시스템 프롬프트와 모든 신뢰할 수 있는 프롬프트 아래에 깔려 있는 6단계 구성 요소를 소개합니다.

핵심 요약

• 시스템 프롬프트는 사용자 메시지 이전에 한 번 설정되는 영구적인 지시사항(역할, 제약 조건, 출력 형식, 가드레일)입니다.
• 1,000개의 요청에서 내용이 동일하다면 시스템 프롬프트에 넣고, 요청마다 달라지는 내용은 사용자 턴(user turn)에 넣으십시오.
• 신뢰할 수 있는 프롬프트를 구축하는 6가지 블록: 역할, 컨텍스트, 제약 조건, 출력 형식, 가드레일, 예시.
• 추론 모델(o-series, GPT-5, Claude Opus 4.5 이상)은 공격적인 "무조건 해야 한다(MUST)" 표현보다는 고수준의 목표를 선호합니다.

시스템 프롬프트에는 무엇이 들어가나요? 6가지 구성 요소

시스템 프롬프트는 전체 세션 동안 모델의 역할, 행동, 제약 조건 및 출력 형식을 정의하는 영구적인 지시사항 집합으로, 사용자 메시지 전에 한 번 설정됩니다. 신뢰할 수 있는 프롬프트는 역할, 컨텍스트, 제약 조건, 출력 형식, 가드레일, 그리고 선택적 예시라는 여섯 가지 구성 요소를 공유합니다. 이 순서대로 배치하면 프로덕션 환경에서도 견딜 수 있는 시스템 프롬프트 작성법의 핵심을 얻게 됩니다.

각 블록의 역할은 다음과 같습니다.

역할 블록은見た目보다 훨씬 중요합니다. Anthropic의 문서에는 시스템 프롬프트에서 역할을 설정하면 모델의 행동과 톤이 집중되며, "단 한 문장만으로도 차이"가 난다고 명시되어 있습니다. 가드레일 블록의 경우, 거부 및 안전 규칙에 대한 깊은 고민이 필요하며 이에 대해서는 가드레일 가이드에서 자세히 다루고 있습니다. 또한 Claude를 연동한다면, Anthropic은 모델이 각 유형의 콘텐츠를 혼동하지 않도록 XML 태그(<instructions>, <context>, <input>)를 사용하여 콘텐츠를 분리할 것을 권장합니다.

다음은 이 6가지 블록을 하나의 템플릿으로 연결한, 복사하여 사용할 수 있는 뼈대입니다.

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

6가지 블록은 막연한 느낌을 명확한 사양(spec)으로 바꿉니다. 이는 오직 시스템 프롬프트 레이어에만 해당됩니다. Few-shot, Chain-of-Thought, 프롬프트 체이닝 등 더 광범위한 기법은 프롬프트 엔지니어링 가이드를 참조하시고, 이러한 기법은 시스템 프롬프트 자체에는 포함하지 마십시오. 세션 시스템 프롬프트는 코드베이스 전체를 관리하는 CLAUDE.md와 같은 지속적인 프로젝트 수준 지시사항 파일과도 다릅니다.

프로덕션 시스템 프롬프트 예시 7가지 (복사-붙여넣기 가능)

오늘 바로 system 파라미터나 developer 메시지에 붙여넣을 수 있는 시스템 프롬프트 예시 7가지를 소개합니다. 각각은 실제 업무(에이전트, RAG, 지원, 코딩, JSON, 콘텐츠 QA, 번역)를 대상으로 하며, 주요 블록이 존재하는 이유를 보여줍니다. 마지막 두 가지는 저희 파이프라인에서 실제로 실행 중인 것입니다. Cursor와 Devin 프롬프트가 유출된 저장소들은 수요를 증명하지만, 정작 각 블록이 왜 필요한지 설명하는 주석을 제공하는 곳은 없습니다.

1. 자율 에이전트

역할을 좁게 정의하고, 도구 사용 규칙을 명시하며, 무한 루프에 빠지지 않도록 중단 조건을 제공해야 합니다.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

작동 원리: 좁은 역할과 명시적인 중단 조건은 작업을 완료하는 에이전트와 루프에서 토큰만 소모하는 에이전트의 차이를 만듭니다. 이는 우수한 에이전트 시스템 프롬프트 모범 사례의 핵심입니다.

2. RAG / 검색 기반 Q&A

검색(Retrieval)의 핵심은 모델이 자체 메모리에 의존해 답변하는 것을 막는 것입니다. 단 하나의 규칙으로 이를 해결할 수 있습니다.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

작동 원리: "컨텍스트에서만 추출"이라는 규칙과 인용 형식은 RAG 시스템 프롬프트에서 환각(Hallucination)을 방지하는 가장 비용 효율적인 가드레일입니다.

3. 고객 지원 봇

톤(Tone), 에스컬레이션 경로, 그리고 엄격한 금액 규칙은 지원 봇이 불가능한 약속을 하지 않도록 하면서도 도움이 되게 유지합니다.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

작동 원리: 환불 가드레일과 에스컬레이션 대체 방안은 지원 봇이 프로덕션에서 퇴출되는 두 가지 주요 실패 모드를 차단합니다.

4. 코딩 어시스턴트

출력 형식과 버전을 제한하고, 편집 전에 설명하도록 만듭니다.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

작동 원리: "전체 파일이 아닌 diff"와 버전 상한선은 어시스턴트가 귀하의 스택 범위 내에서 작동하도록 유지합니다. 코딩 에이전트를 위한 프롬프트 설계는 별도의 가이드가 필요할 만큼 깊으므로, 이 예시는 간결하게 유지했습니다.

5. 구조화된 데이터 / JSON 추출

스키마를 출력 형식 블록에 넣고 산문(prose)을 금지하십시오. 이것이 신뢰할 수 있는 구조화된 출력을 위한 패턴입니다.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

작동 원리: 설명된 형식보다 리터럴 스키마와 "유효한 JSON만"이라는 규칙이 항상 더 효과적입니다. 프롬프트 이상의 강제 패턴(JSON 스키마 검증, 도구 기반 추출)에 대해서는 구조화된 출력 가이드를 참조하십시오.

6. 콘텐츠 QA / 검증기 에이전트 (저희 프로덕션 파이프라인에서 사용)

이것은 저희 스택에서 실행됩니다. 저희 검증기의 시스템 프롬프트는 부정적 제약 조건의 예시입니다. 모델에게 무엇을 쓰지 말아야 하는지 정확히 지시한 후, 스크립트로 규칙을 문자 그대로 확인합니다.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

작동 원리: 열거된 금지 목록과 grep 명령어는 "유행어 피하기"처럼 모호한 지시와는 달리强制执行 가능합니다. 모델은 분위기(vibe)와는 논쟁할 수 있지만, 0이 아닌 종료 코드(non-zero exit code)와는 논쟁할 수 없습니다.

7. 번역 에이전트 (저희 프로덕션 파이프라인에서 사용)

이것도 저희 것입니다. 번역기의 프롬프트는 출력 형식 및 완전성 계약과 모델이 자신의 출력에 대해 자체적으로 수행하는 자체 점검(self-check)을 포함합니다.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

작동 원리: 완전성 계약과 구체적인 잘못된 출력 예시는 모호한 "정확하게 번역하라"는 지시가 놓치기 쉬운 잠재적 실패(silent failures)를 잡아냅니다.

프로덕션에서 시스템 프롬프트를 운영하며 배운 점

저희 파이프라인에서 발생한 세 가지 시스템 프롬프트 버그는 어떤 문서 페이지보다 많은 교훈을 주었습니다. 이 세 가지 모두 듣기엔 괜찮았지만 구체적이거나 검증 가능하지 않았던 지시사항에서 비롯되었습니다. 다음은 저희 16개 이상의 Claude 하위 에이전트에서 발생한 문제와 그때마다 효과를 본 정확한 수정 사항입니다. 패턴은 항상 동일했습니다. 부드러운 규칙은 무시되지만, 구체적이고 외부에서 검증되는 규칙은 준수됩니다.

금지 어휘 버그. 몇 주 동안 모델은 우리가 아무리 부드럽게 요청해도 초안에 leverage와 robust라는 단어를 계속 포함시켰습니다. "유행어 피하기"라는 부드러운 지시는 아무 효과가 없었습니다. 해결책은 예시 #6이었습니다. 프롬프트 내에 열거된 금지 목록을 포함하고, 일치하는 항목이 있을 때 0이 아닌 코드로 종료되는 grep 스크립트를 추가했으며, 추가로 1,000단어당 최대 3개의 em-dash 제한을 두었습니다. 교훈: 모호한 제약 조건은 무시되지만, 열거되고 외부에서 검증되는 제약 조건은 준수됩니다.

발음 구별 부호(Diacritics) 버그. 저희 번역기는 터키어, 프랑스어, 스페인어 번역 시 ASCII 문자를 조용히 출력했습니다. karşılaştırma가 karsilastirma로 변환되었고, 원어민 독자가 지적하기 전까지 아무도 알아차리지 못했습니다. 해결책은 프롬프트에 원어민 문자 테이블을 포함하고, 명시적인 잘못된 출력 예시를 제공하며, 실행 후 grep 검사를 수행하는 것이었습니다(원어민 문자가 0개이면 재번역). 교훈: 규칙뿐만 아니라 실패의 구체적인 예시를 모델에 제공하십시오.

안정적 ID 버그. 이는 비용이 많이 드는 버그였습니다. 재번역 때마다 로컬라이즈된 슬러그를 다시 생성하는 시스템 프롬프트 때문에 게시자는 게시물당 두 번째 라이브 문서를 생성하게 되었습니다. 우리는 2026-06-13에 54개의 중복 라이브 문서를 배포했고, 2026-07-05까지 삭제하지 않아 3주 동안 링크 자산(link equity)이 분산되고 중복 콘텐츠 플래그가 발생했습니다. 해결책: 신원을 명시적으로 고정하고 기존 ID를 그대로 재사용하는 것입니다. 결정론적이지 않게 자체 식별자를 재생성하는 시스템 프롬프트는 중복을 유발합니다; 저희는 ID를 고정하기 전에 54개의 라이브 문서를 생성했습니다.

가장 흔한 시스템 프롬프트 실수는 무엇인가요?

가장 흔한 시스템 프롬프트 실수는 장문의 텍스트 지시, 상충되는 규칙, 부정적 표현만 사용, 요청별 컨텍스트를 정적 프롬프트에 덤프하기, 대체 방안(fallback) 생략 등입니다. 2026년 모델에서는 새로운 실수가 하나 추가되었습니다: 공격적인 대문자와 "무조건 해야 한다(MUST)" 표현이 이제 Claude Opus 4.5+에서 과도하게 트리거됩니다.

빠른 수정 목록은 다음과 같습니다.

• 장문의 텍스트. 수정: 6가지 블록으로 분할하고 안정적인 콘텐츠를 앞에 배치하십시오.
• 상충되는 지시. 수정: 한 줄에 하나의 규칙; 배포 전에 충돌을 해결하십시오.
• 부정적 표현만 사용. 수정: 피해야 할 것뿐만 아니라 해야 할 일을 명시하십시오.
• 대문자와 "MUST" 과용. Anthropic의 최신 모델에서는 역효과를 냅니다. 그들의 문서에는 이제 "중요: 이 도구를 반드시 사용하십시오(CRITICAL: You MUST use this tool)"라고 작성하던 곳에 "필요할 때 이 도구를 사용하십시오"와 같은 일반적인 표현을 사용할 수 있다고 명시되어 있습니다. 2025년의 조언이 이제는 실수가 된 것입니다.
• 정적 프롬프트에 동적 컨텍스트 포함. 요청별 데이터는 사용자 턴에 유지하십시오. 무엇이 어디에 속하는지는 별도의 규율이며, 이는 컨텍스트 엔지니어링 가이드에서 다루고 있습니다.
• 대체 방안 없음. 항상 거부 반응과 에스컬레이션 경로를 정의하십시오.
• 길이와 비용 무시. 긴 프롬프트는 모든 호출에서 지연 시간과 토큰 비용을 증가시킵니다. 가치가 있는 내용만 남기고 줄이십시오.

명확한 지시의 기본 사항에 대해서는 OpenAI의 모범 사례 기사가 여전히 훌륭한 체크리스트입니다.

시스템 프롬프트를 어떻게 테스트하고 반복 개선하나요?

시스템 프롬프트는 코드처럼 테스트하십시오. 예상 출력이 포함된 작은 골든 세트(golden set) 입력을 구축하고, 변경 사항이 있을 때마다 모델의 응답을 이에 대해 검증(assert)하십시오. 동일한 입력으로 두 가지 프롬프트 버전을 A/B 테스트하고 더 많은 검사를 통과한 버전을 유지하십시오. 눈으로 확인하는 것보다 어설션(assertion)이 항상 더 낫습니다.

최소한의 평가(eval) 루프는 다음과 같습니다.

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

예시 #6의 grep은 실행할 수 있는 가장 저렴한 어설션입니다. 비용이 들지 않으며 피로도 느끼지 않습니다. 프롬프트 라이브러리가 몇 개를 넘어 성장하면, 파일 간 복사-붙여넣기 대신 실제 프롬프트 관리 도구를 사용하여 프롬프트를 버전 관리하고 테스트하십시오. 규모와 상관없이 핵심은 동일합니다. 프로덕션 프롬프트를 변경할 때는 그것이 더 나아졌는지 나빠졌는지 알려주는 검증 절차를 결코 건너뛰지 마십시오.

시스템 프롬프트 vs 사용자 프롬프트 vs 개발자 메시지

시스템 프롬프트는 고정된 행동을 설정합니다. 사용자 프롬프트는 요청별 작업을 전달합니다. 개발자 메시지는 OpenAI의 추론 모델에서 사용되는 역할로, 명령 계층에서 사용자 메시지보다 우선순위가 높은 앱 수준 지시사항을 포함합니다. Anthropic은 role: "system" 메시지 대신 최상위 system 파라미터를 사용합니다. 다음은 경쟁사들이 종종 놓치는 세 가지 구분입니다.

OpenAI는 순위 지정에 대해 명시적입니다. "개발자 메시지는 애플리케이션 개발자가 제공하는 지시사항으로, 사용자 메시지보다 우선순위가 높습니다". 따라서 사용자가 앱 규칙을 덮어쓰려고 시도하더라도 개발자 메시지가 명령 계층에서 승리합니다.

추론 모델에는 다른 시스템 프롬프트가 필요한가요? (2026)

네. OpenAI의 o-series, GPT-5, Claude Opus 4.5+와 같은 추론 모델은 단계별 스크립트보다는 고수준의 목표를 원합니다. OpenAI는 추론 모델을 세부 사항을 신뢰할 수 있는 선임 동료에 비유하는 반면, GPT 모델은 명시적인 지시가 필요한 주니어 직원처럼 행동한다고 설명합니다.

이 프레임은 프롬프트 작성 방식을 변화시킵니다. 추론 모델의 경우 목표와 제약 조건을 명시하고 "세부 사항은 그들이 처리하도록 신뢰"하십시오. GPT 모델의 경우 단계를 상세히 설명하십시오. 추론 모델을 과도하게 구체화하면 종종 더 나은 결과가 아닌 더 나쁜 결과를 초래합니다.

Claude 측면에도 2026년의 변화가 있습니다. Opus 4.5+는 시스템 프롬프트에 더 민감하게 반응하므로, CRITICAL:과 MUST를 쌓아 올리던 옛 습관은 이제 과도하게 트리거됩니다. 이러한 언어를 일반적인 표현으로 완화하십시오. 비용 관련 주의 사항: 프롬프트 캐싱이 작동하여 반복 호출 시 지연 시간을 줄일 수 있도록 안정적이고 재사용되는 콘텐츠를 프롬프트의 시작 부분에 배치하십시오. 또한 추론 모델이 단계별 작업을 수행하는 경우, Chain-of-Thought 프롬프팅은 자체 가이드가 있는 별도의 주제이므로 여기서는 다시 다루지 않겠습니다.

Techsy의 접근 방식

Techsy에서는 B2B 클라이언트를 위한 에이전트 시스템을 구축하며, 위에서 소개한 검증기 및 번역기 프롬프트는 해당 프로덕션 스택에서 실행됩니다. 우리는 모든 시스템 프롬프트를 코드처럼 취급합니다. 버전을 관리하고, 골든 세트로 테스트하며, 희망이 아닌 스크립트로 필수 규칙을 강제합니다. LLM 기능을 데모에서 프로덕션으로 이동하면서 AI 통합 작업에 도움이 필요하시다면 무료 상담을 신청하세요.

저자 소개

Mert Batur Gurbuz는 Techsy.io의 공동 창립자로, 팀은 B2B 클라이언트를 위해 AI 에이전트, 자동화 시스템 및 음성/SDR 파이프라인을 배포합니다. 그는 버밍엄 대학교에서 공부하며 Techsy 팀이 프로덕션에서 실제로 사용하는 LLM 툴링 스택에 대해 글을 씁니다.

공동 창립자, Techsy.io, 버밍엄 대학교 · LinkedIn

자주 묻는 질문

시스템 프롬프트란 무엇인가요?

시스템 프롬프트는 사용자 메시지 이전에 한 번 설정되는 영구적인 지시사항 집합으로, 전체 세션 동안 모델의 역할, 행동, 제약 조건 및 출력 형식을 정의합니다. 이는 고정된 "행동 방식" 레이어이며, 사용자의 요청별 메시지가 매 턴마다 변경되는 동안 동일하게 유지됩니다.

시스템 프롬프트와 사용자 프롬프트의 차이점은 무엇인가요?

시스템 프롬프트는 모든 요청에서 동일한 고정된 "행동 방식"이고, 사용자 프롬프트는 요청별 "수행 작업"입니다. 간단한 경험 법칙: 1,000개의 요청에서 내용이 동일하다면 시스템 프롬프트에 넣고, 호출마다 변경되는 내용은 사용자 턴에 넣으십시오.

개발자 메시지와 시스템 프롬프트의 차이점은 무엇인가요?

OpenAI의 추론 모델(o-series, GPT-5)은 system 메시지 대신 developer 메시지를 받습니다. 이는 명령 계층에서 사용자 메시지보다 우선순위가 높은 앱 수준 지시사항을 전달하므로, 사용자가 규칙을 덮어쓰려고 시도할 때 개발자 메시지가 승리합니다. Anthropic은 역할 기반 메시지 대신 단일 최상위 system 파라미터를 유지합니다.

시스템 프롬프트는 얼마나 길어야 하나요?

역할, 제약 조건, 출력 형식 및 가드레일을 커버할 수 있는 최소한의 길이여야 합니다. 지나치게 긴 프롬프트는 모든 호출에서 토큰 비용과 지연 시간을 증가시키며 Claude Opus 4.5+에서 추가 추론을 과도하게 트리거할 수 있습니다. 안정적인 프롬프트가 길어야 한다면, 프롬프트 캐싱이 비용을 상쇄할 수 있도록 재사용되는 콘텐츠를 앞에 배치하십시오.

시스템 프롬프트는 ChatGPT/GPT와 Claude에서 동일하게 작동하나요?

개념은 동일하지만 메커니즘은 다릅니다. OpenAI는 메시지 배열 내에서 system 또는 developer 역할을 사용하는 반면, Anthropic은 별도의 최상위 system 파라미터를 사용하며 지시사항, 컨텍스트 및 예시를 분리하기 위해 XML 태그를 선호합니다. 지시사항은 공급자 간에 이전될 수 있지만, 배선(wiring) 및 형식 규칙은 그렇지 않습니다.

대화 중간에 시스템 프롬프트를 변경할 수 있나요?

API를 통해 모든 호출에서 전체 메시지 페이로드를 다시 보내므로 기술적으로는 턴 사이에 시스템 프롬프트를 교체할 수 있습니다. 하지만 대화 중간에 변경하면 연속성이 깨지고 모델이 자체 규칙에 대해 혼란스러워할 수 있습니다. 한 번 설정하거나, distinct task-specific 프롬프트로 의도적으로 교체하는 것을 선호하십시오.

시스템 프롬프트에 XML 태그와 마크다운 중 무엇을 사용해야 하나요?

Anthropic은 Claude가 지시사항, 컨텍스트 및 예시를 혼동하지 않도록 분리하기 위해 XML 태그를 권장합니다. OpenAI 모델은 마크다운과 일반 제목을 잘 처리합니다. 두 공급자 모두에 한 스타일을 강요하기보다 공급자의 규칙에 맞추고, 선택한 스타일을 단일 프롬프트 내에서 일관되게 유지하십시오.

추론 모델에는 다른 시스템 프롬프트가 필요한가요?

네. 추론 모델은 단계별 미세 관리가 아닌, 선임 동료에게 브리핑하듯 고수준의 목표를 원합니다. Claude Opus 4.5+와 같은 최신 모델을 과도하게 트리거하는 공격적인 대문자와 "무조건 해야 한다(MUST)" 언어를 제거하고, 목표와 가드레일을 명시한 후 모델이 도달 경로를 계획하도록 맡기십시오.

좋은 시스템 프롬프트의 구성 요소는 무엇인가요?

6가지 블록: 역할, 컨텍스트, 제약 조건, 출력 형식, 가드레일 또는 대체 방안, 그리고 선택적으로 몇 가지 예시. 역할과 제약 조건이 대부분의 작업을 수행하며, 출력 형식 블록은 응답을 파싱 가능하게 만들고, 가드레일은 경계 상황에서의 동작을 정의합니다. 예시는 목표 품질을 언어로 설명하기 어려울 때만 추가하는 것이 가치 있습니다.