GPT-5 사용하기
GPT-5 사용하기
출처: 문서
본문
소개
GPT-5는 에이전트형(agentic) 작업 성능, 코딩, 원시 지능, 제어에서 상당한 도약을 나타냅니다.
다양한 도메인에서 "기본 상태로" 훌륭히 작동할 것이라고 믿지만, 이 가이드에서는 모델을 훈련하고 실제 작업에 적용한 경험에서 얻은, 모델 출력 품질을 최대화하기 위한 프롬프팅 팁을 다룹니다. 에이전트형 작업 성능 개선, 지시 준수 보장, 새로운 API 기능 활용, 프론트엔드 및 소프트웨어 엔지니어링 작업을 위한 코딩 최적화 같은 개념을 논의하며, AI 코드 편집기 Cursor의 GPT-5 프롬프트 튜닝 작업에 대한 핵심 통찰도 담았습니다.
이러한 모범 사례를 적용하고 가능할 때마다 표준 도구를 채택하면 상당한 개선을 보았습니다. 이 가이드와 우리가 만든 프롬프트 최적화 도구가 GPT-5 사용의 발판이 되기를 바랍니다. 하지만 항상 그렇듯, 프롬프팅은 일률적으로 적용되는 작업이 아니라는 점을 기억하세요. 여기서 제시된 기반을 바탕으로 실험하고 반복하여 문제에 가장 적합한 해결책을 찾아보길 권합니다.
새로운 기능
- 더 강력한 에이전트형 작업 성능, 코딩 능력, 제어
- 도구 호출 흐름을 위한 Responses API의 추론 지속성(reasoning persistence)
- 에이전트형 적극성(eagerness), 도구 프리앰블, 추론 노력, 장황함(verbosity)을 위한 전용 제어
- 자유 형식 입력과 제약된 출력을 가진 커스텀 도구
마이그레이션 퀵스타트
- 모델 슬러그를
gpt-5로 업데이트하세요. - 추론, 도구 호출, 다중 턴 워크플로에 Responses API를 사용해 추론 항목이 도구 호출 사이에 보존되게 하세요.
medium추론 노력으로 시작한 다음, 대표 작업에 대해minimal,low,high를 테스트하세요.text.verbosity를 의도적으로 설정하고, 가능하면 구조화된 응답 계약을 Structured Outputs로 옮기세요.- 에이전트형 지속성, 도구 프리앰블, 중단 조건에 맞게 프롬프트를 다시 평가하세요.
모델, API, 기능 업데이트
- GPT-5 계열에는
gpt-5,gpt-5-mini,gpt-5-nano가 포함됩니다. reasoning.effort는minimal,low,medium,high를 지원합니다.- GPT-5은 자유 형식 입력을 받고 컨텍스트 프리 문법으로 출력을 제약할 수 있는 커스텀 도구를 도입했습니다.
- 이 모델은 함수 호출과 웹 검색, 파일 검색, 이미지 생성, 코드 인터프리터, 원격 MCP를 포함한 OpenAI 호스팅 도구를 지원합니다.
프롬프팅 모범 사례
에이전트형 워크플로 예측 가능성
우리는 개발자를 염두에 두고 GPT-5을 훈련했습니다. 도구 호출, 지시 따르기, 긴 컨텍스트 이해를 개선해 에이전트형 애플리케이션을 위한 최고의 기반 모델로 만드는 데 집중했습니다. GPT-5을 에이전트형 및 도구 호출 흐름에 도입한다면, 추론이 도구 호출 사이에 지속되어 더 효율적이고 지능적인 출력을 만드는 Responses API로 업그레이드할 것을 권장합니다.
에이전트형 적극성 제어
에이전트형 스캐폴드는 광범위한 제어 스펙트럼에 걸쳐 있습니다. 어떤 시스템은 의사결정의 대부분을 기본 모델에 위임하는 반면, 다른 시스템은 무거운 프로그래밍 방식의 논리 분기로 모델을 단단히 통제합니다. GPT-5은 모호한 상황에서 높은 수준의 결정을 내리는 것부터 집중적이고 잘 정의된 작업을 처리하는 것까지, 이 스펙트럼의 어디서든 작동하도록 훈련되었습니다. 이 섹션에서는 GPT-5의 에이전트형 적극성, 즉 사전 대응과 명시적 지침 대기 사이의 균형을 가장 잘 보정하는 방법을 다룹니다.
덜 적극적으로 만들기 위한 프롬프팅
GPT-5은 기본적으로 에이전트 환경에서 컨텍스트를 수집할 때 정확한 답변을 만들기 위해 철저하고 포괄적입니다. GPT-5의 에이전트형 동작 범위를 줄이려면(주변 도구 호출 동작 제한과 최종 답변 도달 지연 시간 최소화 포함) 다음을 시도해 보세요:
- 더 낮은
reasoning_effort로 전환하세요. 이는 탐색 깊이를 줄이지만 효율성과 지연 시간을 개선합니다. 많은 워크플로는 medium 또는 심지어 lowreasoning_effort에서도 일관된 결과로 완료될 수 있습니다. - 모델이 문제 공간을 어떻게 탐색하길 원하는지 프롬프트에 명확한 기준을 정의하세요. 이는 모델이 너무 많은 아이디어를 탐색하고 추론할 필요를 줄여줍니다:
<context_gathering>
Goal: Get enough context fast. Parallelize discovery and stop as soon as you can act.
Method:
- Start broad, then fan out to focused subqueries.
- In parallel, launch varied queries; read top hits per query. Deduplicate paths and cache; don't repeat queries.
- Avoid over searching for context. If needed, run targeted searches in one parallel batch.
Early stop criteria:
- You can name exact content to change.
- Top hits converge (~70%) on one area/path.
Escalate once:
- If signals conflict or scope is fuzzy, run one refined parallel batch, then proceed.
Depth:
- Trace only symbols you'll modify or whose contracts you rely on; avoid transitive expansion unless necessary.
Loop:
- Batch search → minimal plan → complete task.
- Search again only if validation fails or new unknowns appear. Prefer acting over more searching.
</context_gathering>
최대한 지시적으로 가고 싶다면, 아래와 같은 고정된 도구 호출 예산을 설정할 수도 있습니다. 예산은 원하는 검색 깊이에 따라 자연스럽게 달라질 수 있습니다.
<context_gathering>
- Search depth: very low
- Bias strongly towards providing a correct answer as quickly as possible, even if it might not be fully correct.
- Usually, this means an absolute maximum of 2 tool calls.
- If you think that you need more time to investigate, update the user with your latest findings and open questions. You can proceed if the user confirms.
</context_gathering>
핵심 컨텍스트 수집 동작을 제한할 때, 더 짧은 컨텍스트 수집 단계를 만족시키기 쉽게 만드는 탈출구(escape hatch)를 모델에 명시적으로 제공하는 것이 도움이 됩니다. 보통 이는 위 예시의 "even if it might not be fully correct" 같은, 모델이 불확실성 속에서도 진행하도록 허용하는 절의 형태로 나옵니다.
더 적극적으로 만들기 위한 프롬프팅
반면에 모델 자율성을 장려하고, 도구 호출 지속성을 늘리며, 명확화 질문이나 사용자에게 되돌려주는 일을 줄이고 싶다면, reasoning_effort를 높이고 지속성과 철저한 작업 완료를 장려하는 다음과 같은 프롬프트를 사용하길 권장합니다:
<persistence>
- You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user.
- Only terminate your turn when you are sure that the problem is solved.
- Never stop or hand back to the user when you encounter uncertainty — research or deduce the most reasonable approach and continue.
- Do not ask the human to confirm or clarify assumptions, as you can always adjust later — decide what the most reasonable assumption is, proceed with it, and document it for the user's reference after you finish acting
</persistence>
일반적으로 에이전트 작업의 중단 조건을 명확히 명시하고, 안전한 행동과 안전하지 않은 행동을 개략적으로 설명하며, 모델이 사용자에게 되돌려주는 것이 언제(그리고 가능하다면) 수용 가능한지 정의하는 것이 도움이 됩니다. 예를 들어 쇼핑용 도구 세트에서 체크아웃과 결제 도구는 사용자 명확화를 요구하는 불확실성 임계값을 명시적으로 낮게 설정해야 하고, 검색 도구는 극도로 높은 임계값을 가져야 합니다. 마찬가지로 코딩 설정에서 파일 삭제 도구는 grep 검색 도구보다 훨씬 낮은 임계값을 가져야 합니다.
도구 프리앰블 (Tool preambles)
사용자가 모니터링하는 에이전트형 궤적에서, 모델이 도구 호출로 무엇을 하고 있고 왜 하는지에 대한 주기적인 업데이트는 훨씬 더 나은 대화형 사용자 경험을 제공할 수 있음을 인지합니다. 전개가 길수록 이러한 업데이트가 만드는 차이는 더 커집니다. 이를 위해 GPT-5은 "도구 프리앰블" 메시지를 통해 명확한 사전 계획과 일관된 진행 업데이트를 제공하도록 훈련되었습니다.
프롬프트에서 도구 프리앰블의 빈도, 스타일, 내용을 조정할 수 있습니다. 모든 단일 도구 호출의 상세한 설명부터 간결한 사전 계획, 그 중간의 다양한 수준까지 가능합니다. 다음은 고품질 프리앰블 프롬프트의 예입니다:
<tool_preambles>
- Always begin by rephrasing the user's goal in a friendly, clear, and concise manner, before calling any tools.
- Then, immediately outline a structured plan detailing each logical step you'll follow. - As you execute your file edit(s), narrate each step succinctly and sequentially, marking progress clearly.
- Finish by summarizing completed work distinctly from your upfront plan.
</tool_preambles>
다음은 그러한 프롬프트에 대한 응답으로 내보내질 수 있는 도구 프리앰블의 예입니다. 이러한 프리앰블은 에이전트 작업이 복잡해질수록 사용자가 따라올 수 있는 능력을 크게 향상시킬 수 있습니다:
"output": [
{
"id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
"type": "reasoning",
"summary": [
{
"type": "summary_text",
"text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."
},
},
{
"id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
"type": "message",
"status": "completed",
"content": [
{
"type": "output_text",
"text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."
}
],
"role": "assistant"
},
{
"id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
"type": "function_call",
"status": "completed",
"arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
"call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
"name": "get_weather"
},
],
추론 노력 (Reasoning effort)
모델이 얼마나 열심히 생각하고 도구를 얼마나 기꺼이 호출하는지 제어하는 reasoning_effort 매개변수를 제공합니다. 기본값은 medium이지만 작업 난이도에 따라 높이거나 낮춰야 합니다. 복잡하고 다단계 작업의 경우 최상의 출력을 보장하기 위해 더 높은 추론을 권장합니다. 또한 뚜렷하고 분리 가능한 작업을 여러 에이전트 턴으로 나누고 작업당 한 턴을 사용할 때 최고 성능을 관찰합니다.
Responses API로 추론 컨텍스트 재사용
GPT-5을 사용할 때 Responses API를 사용해 개선된 에이전트 흐름, 더 낮은 비용, 더 효율적인 토큰 사용을 여는 것을 강력히 권장합니다.
Responses API를 Chat Completions보다 사용할 때 평가에서 통계적으로 유의미한 개선을 보았습니다. 예를 들어 Responses API로 전환하고 previous_response_id를 포함해 이전 추론 항목을 후속 요청에 전달하는 것만으로 Tau-Bench Retail 점수가 73.9%에서 78.2%로 상승하는 것을 관찰했습니다. 이는 모델이 이전 추론 궤적을 참조하게 해 CoT 토큰을 절약하고 각 도구 호출 후 계획을 처음부터 재구성할 필요를 없애 지연 시간과 성능을 모두 개선합니다. 이 기능은 ZDR 조직을 포함한 모든 Responses API 사용자에게 제공됩니다.
코딩 성능 극대화: 계획부터 실행까지
GPT-5은 모든 프론티어 모델 중 코딩 능력에서 선두입니다. 대규모 코드베이스에서 버그를 수정하고, 큰 diff를 처리하며, 다중 파일 리팩터링이나 대규모 새 기능을 구현할 수 있습니다. 또한 프론트엔드와 백엔드 구현을 모두 아우르는 새 앱을 처음부터 완전히 구현하는 데 탁월합니다. 이 섹션에서는 코딩 에이전트 고객을 위한 프로덕션 사용 사례에서 프로그래밍 성능을 개선한다고 확인된 프롬프트 최적화를 논의합니다.
프론트엔드 앱 개발
GPT-5은 엄격한 구현 능력과 함께 훌륭한 기본적인 미적 취향을 가진 모델로 훈련되었습니다. 모든 유형의 웹 개발 프레임워크와 패키지를 사용할 수 있다고 확신합니다. 다만 새 앱의 경우 모델의 프론트엔드 능력을 최대한 활용하기 위해 다음 프레임워크와 패키지를 권장합니다:
- 프레임워크: Next.js (TypeScript), React, HTML
- 스타일링 / UI: Tailwind CSS, shadcn/ui, Radix Themes
- 아이콘: Material Symbols, Heroicons, Lucide
- 애니메이션: Motion
- 폰트: San Serif, Inter, Geist, Mona Sans, IBM Plex Sans, Manrope
제로에서 원으로 앱 생성
GPT-5은 한 번에 앱을 만드는 데 탁월합니다. 모델 초기 실험에서 사용자들은 아래와 같은 프롬프트—모델이 스스로 구성한 우수성 루브릭(rubric)에 대해 반복적으로 실행하도록 요청하는—가 GPT-5의 철저한 계획과 자기 성찰 능력을 사용해 출력 품질을 개선한다는 것을 발견했습니다.
<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
</self_reflection>
코드베이스 디자인 표준 일치
기존 앱에서 점진적 변경과 리팩터링을 구현할 때, 모델이 작성한 코드는 기존 스타일과 디자인 표준을 준수하고 코드베이스에 최대한 매끄럽게 "어울려야" 합니다. 특별한 프롬프팅 없이도 GPT-5은 이미 코드베이스에서 참조 컨텍스트를 검색합니다. 예를 들어 package.json을 읽어 이미 설치된 패키지를 확인하는 식입니다. 하지만 이 동작은 엔지니어링 원칙, 디렉터리 구조, 코드베이스의 명시적 및 암묵적 모범 사례 같은 핵심 측면을 요약하는 프롬프트 방향으로 더 강화할 수 있습니다. 아래 프롬프트 스니펫은 GPT-5을 위한 코드 편집 규칙을 구성하는 한 가지 방법을 보여줍니다. 실제 규칙 내용은 프로그래밍 설계 취향에 따라 자유롭게 바꾸세요!
<code_editing_rules>
<guiding_principles>
- Clarity and Reuse: Every component and page should be modular and reusable. Avoid duplication by factoring repeated UI patterns into components.
- Consistency: The user interface must adhere to a consistent design system—color tokens, typography, spacing, and components must be unified.
- Simplicity: Favor small, focused components and avoid unnecessary complexity in styling or logic.
- Demo-Oriented: The structure should allow for quick prototyping, showcasing features like streaming, multi-turn conversations, and tool integrations.
- Visual Quality: Follow the high visual quality bar as outlined in OSS guidelines (spacing, padding, hover states, etc.)
</guiding_principles>
<frontend_stack_defaults>
- Framework: Next.js (TypeScript)
- Styling: TailwindCSS
- UI Components: shadcn/ui
- Icons: Lucide
- State Management: Zustand
- Directory Structure:
/src
/app
/api/
</frontend_stack_defaults>
<ui_ux_best_practices>
- Visual Hierarchy: Limit typography to 4–5 font sizes and weights for consistent hierarchy; use `text-xs` for captions and annotations; avoid `text-xl` unless for hero or major headings.
- Color Usage: Use 1 neutral base (e.g., `zinc`) and up to 2 accent colors.
- Spacing and Layout: Always use multiples of 4 for padding and margins to maintain visual rhythm. Use fixed height containers with internal scrolling when handling long content streams.
- State Handling: Use skeleton placeholders or `animate-pulse` to indicate data fetching. Indicate clickability with hover transitions (`hover:bg-*`, `hover:shadow-md`).
- Accessibility: Use semantic HTML and ARIA roles where appropriate. Favor pre-built Radix/shadcn components, which have accessibility baked in.
</ui_ux_best_practices>
<code_editing_rules>
프로덕션에서의 협업적 코딩: Cursor의 GPT-5 프롬프트 튜닝
AI 코드 편집기 Cursor를 GPT-5의 신뢰할 수 있는 알파 테스터로 모시게 되어 자랑스럽습니다. 아래에서 Cursor가 모델 능력을 최대한 활용하기 위해 어떻게 프롬프트를 튜닝했는지 엿볼 수 있습니다. 자세한 내용은 그 팀이 GPT-5의 첫날 Cursor 통합을 설명하는 블로그 게시물 https://cursor.com/blog/gpt-5 도 게시했습니다.
시스템 프롬프트와 매개변수 튜닝
Cursor의 시스템 프롬프트는 신뢰할 수 있는 도구 호출에 집중하며, 장황함과 자율적 동작을 균형 잡으면서 사용자가 커스텀 지침을 구성할 수 있게 합니다. Cursor가 시스템 프롬프트에서 목표로 하는 것은 Agent가 긴 지평선 작업 중 상대적으로 자율적으로 작동하면서도 사용자가 제공한 지침을 충실히 따르는 것입니다.
팀은 처음에 모델이 장황한 출력을 만들고, 종종 상태 업데이트와 작업 후 요약을 포함한다는 것을 발견했습니다. 이는 기술적으로는 관련이 있지만 사용자의 자연스러운 흐름을 방해했습니다. 동시에 도구 호출에서 출력되는 코드는 품질이 좋았지만, 지나친 간결성 때문에 단일 문자 변수 이름이 지배적이어서 읽기 어려운 경우가 있었습니다. 더 나은 균형을 찾기 위해 verbosity API 매개변수를 low로 설정해 텍스트 출력을 간결하게 유지한 다음, 코딩 도구에서만 장황한 출력을 강력히 권장하도록 프롬프트를 수정했습니다.
Write code for clarity first. Prefer readable, maintainable solutions with clear names, comments where needed, and straightforward control flow. Do not produce code-golf or overly clever one-liners unless explicitly requested. Use high verbosity for writing code and code tools.
매개변수와 프롬프트의 이중 사용은 효율적이고 간결한 상태 업데이트와 최종 작업 요약을 훨씬 더 읽기 쉬운 코드 diff와 결합한 균형 잡힌 형식을 만들었습니다.
Cursor는 또한 모델이 행동을 취하기 전에 가끔 사용자에게 명확화나 다음 단계를 물어보며, 이로 인해 더 긴 작업의 흐름에 불필요한 마찰이 생긴다는 것을 발견했습니다. 이를 해결하기 위해 사용 가능한 도구와 주변 컨텍스트뿐만 아니라 제품 동작에 대한 더 많은 세부 정보를 포함하는 것이 모델이 최소한의 중단과 더 큰 자율성으로 더 긴 작업을 수행하도록 장려한다는 것을 발견했습니다. Undo/Reject 코드나 사용자 선호 같은 Cursor 기능의 특성을 강조하면 GPT-5이 환경에서 어떻게 작동해야 하는지 명확히 지정해 모호성을 줄이는 데 도움이 되었습니다. 더 긴 지평선 작업에서 이 프롬프트가 성능을 개선하는 것을 발견했습니다:
Be aware that the code edits you make will be displayed to the user as proposed changes, which means (a) your code edits can be quite proactive, as the user can always reject, and (b) your code should be well-written and easy to quickly review (e.g., appropriate variable names instead of single letters). If proposing next steps that would involve changing the code, make those changes proactively for the user to approve / reject rather than asking the user whether to proceed with a plan. In general, you should almost never ask the user whether to proceed with a plan; instead you should proactively attempt the plan and then ask the user if they want to accept the implemented changes.
Cursor는 이전 모델에서 효과적이던 프롬프트 섹션이 GPT-5의 잠재력을 최대한 활용하려면 튜닝이 필요하다는 것을 발견했습니다. 아래에 한 예가 있습니다:
<maximize_context_understanding>
Be THOROUGH when gathering information. Make sure you have the FULL picture before replying. Use additional tool calls or clarifying questions as needed.
...
</maximize_context_understanding>
이것은 컨텍스트를 철저히 분석하도록 장려가 필요했던 이전 모델에서는 잘 작동했지만, 이미 자연스럽게 내성적이고 컨텍스트 수집에 적극적인 GPT-5에서는 역효과가 있다는 것을 발견했습니다. 더 작은 작업에서 이 프롬프트는 모델이 내부 지식으로 충분했을 때 검색을 반복 호출해 도구를 과도하게 사용하게 만드는 경우가 많았습니다.
이를 해결하기 위해 maximize\_ 접두사를 제거하고 철저함에 대한 언어를 완화해 프롬프트를 다듬었습니다. 이 조정된 지침을 갖춘 상태에서 Cursor 팀은 GPT-5이 내부 지식에 의존할지 외부 도구에 손을 뻗을지 더 나은 결정을 내리는 것을 확인했습니다. 불필요한 도구 사용 없이 높은 수준의 자율성을 유지해 더 효율적이고 관련성 높은 동작을 만들었습니다. Cursor의 테스트에서 <[instruction]\_spec> 같은 구조화된 XML 사양을 사용하면 프롬프트의 지시 준수가 개선되고 프롬프트의 다른 곳에서 이전 범주와 섹션을 명확히 참조할 수 있었습니다.
<context_understanding>
...
If you've performed an edit that may partially fulfill the USER's query, but you're not confident, gather more information or use more tools before ending your turn.
Bias towards not asking the user for help if you can find the answer yourself.
</context_understanding>
시스템 프롬프트가 강력한 기본 기반을 제공하지만, 사용자 프롬프트는 여전히 조종 가능성을 위한 매우 효과적인 레버로 남아 있습니다. GPT-5은 직접적이고 명시적인 지침에 잘 반응하며, Cursor 팀은 구조화되고 범위가 지정된 프롬프트가 가장 신뢰할 수 있는 결과를 낸다는 것을 일관되게 확인했습니다. 여기에는 장황함 제어, 주관적인 코드 스타일 선호, 엣지 케이스 민감성 같은 영역이 포함됩니다. Cursor는 사용자가 자신의 커스텀 Cursor 규칙을 구성하도록 허용하는 것이 GPT-5의 개선된 조종 가능성으로 특히 효과적임을 발견해, 사용자에게 더 맞춤화된 경험을 제공했습니다.
지능과 지시 따르기 최적화
조종 (Steering)
가장 조종 가능한 모델인 GPT-5은 장황함, 어조, 도구 호출 동작에 관한 프롬프트 지침에 매우 잘 반응합니다.
장황함 (Verbosity)
이전 추론 모델처럼 reasoning_effort를 제어할 수 있는 것 외에도, GPT-5에서는 모델의 최종 답변 길이(생각의 길이가 아니라)에 영향을 주는 verbosity라는 새로운 API 매개변수를 도입합니다. 우리 블로그 게시물이 이 매개변수의 배경 아이디어를 더 자세히 다루지만, 이 가이드에서는 API verbosity 매개변수가 출시의 기본값이지만, GPT-5은 모델이 전역 기본값에서 벗어나길 원하는 특정 컨텍스트에서 프롬프트의 자연어 장황함 오버라이드를 따르도록 훈련되었다는 점을 강조하고 싶습니다. 위의 Cursor 예시—전역적으로 low verbosity를 설정한 다음 코딩 도구에만 high verbosity를 지정하는—가 그러한 컨텍스트의 대표 사례입니다.
지시 따르기 (Instruction following)
GPT-4.1처럼 GPT-5은 프롬프트 지침을 수술적으로 정밀하게 따릅니다. 이 덕분에 모든 유형의 워크플로에 유연하게 들어갈 수 있습니다. 그러나 이 세심한 지시 따르기 동작은 모순되거나 모호한 지침을 포함한 부실하게 구성된 프롬프트가 다른 모델보다 GPT-5에 더 해로울 수 있음을 의미합니다. 모순을 해결할 방법을 찾느라(무작위로 하나의 지침을 고르는 대신) 추론 토큰을 소모하기 때문입니다.
아래에서 GPT-5의 추론 궤적을 종종 손상시키는 유형의 프롬프트에 대한 적대적 예시를 제시합니다. 언뜻 보기에는 내부적으로 일관돼 보일 수도 있지만, 자세히 보면 약속 예약에 관한 상충되는 지침이 드러납니다:
Never schedule an appointment without explicit patient consent recorded in the chart는 후속auto-assign the earliest same-day slot without contacting the patient as the first action to reduce risk.와 충돌합니다.- 프롬프트는
Always look up the patient profile before taking any other actions to ensure they are an existing patient.라고 하지만, 그 후 모순되는 지침When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step.을 이어서 말합니다.
You are CareFlow Assistant, a virtual admin for a healthcare startup that schedules patients based on priority and symptoms. Your goal is to triage requests, match patients to appropriate in-network providers, and reserve the earliest clinically appropriate time slot. Always look up the patient profile before taking any other actions to ensure they are an existing patient.
- Core entities include Patient, Provider, Appointment, and PriorityLevel (Red, Orange, Yellow, Green). Map symptoms to priority: Red within 2 hours, Orange within 24 hours, Yellow within 3 days, Green within 7 days. When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step.
+Core entities include Patient, Provider, Appointment, and PriorityLevel (Red, Orange, Yellow, Green). Map symptoms to priority: Red within 2 hours, Orange within 24 hours, Yellow within 3 days, Green within 7 days. When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step.
*Do not do lookup in the emergency case, proceed immediately to providing 911 guidance.*
- Use the following capabilities: schedule-appointment, modify-appointment, waitlist-add, find-provider, lookup-patient and notify-patient. Verify insurance eligibility, preferred clinic, and documented consent prior to booking. Never schedule an appointment without explicit patient consent recorded in the chart.
- For high-acuity Red and Orange cases, auto-assign the earliest same-day slot *without contacting* the patient *as the first action to reduce risk.* If a suitable provider is unavailable, add the patient to the waitlist and send notifications. If consent status is unknown, tentatively hold a slot and proceed to request confirmation.
- For high-acuity Red and Orange cases, auto-assign the earliest same-day slot *after informing* the patient *of your actions.* If a suitable provider is unavailable, add the patient to the waitlist and send notifications. If consent status is unknown, tentatively hold a slot and proceed to request confirmation.
지침 계층 충돌을 해결함으로써 GPT-5은 훨씬 더 효율적이고 성능 좋은 추론을 이끌어냅니다. 우리는 모순을 다음으로 수정했습니다:
- 자동 할당이 환자에게 연락한 후에 일어나도록 변경했습니다.
auto-assign the earliest same-day slot after informing the patient of your actions.는 동의가 있을 때만 예약한다는 것과 일관되게 만들었습니다. Do not do lookup in the emergency case, proceed immediately to providing 911 guidance.를 추가해 긴급 상황에서 조회를 하지 않아도 된다는 것을 모델에 알렸습니다.
프롬프트 구축 과정은 반복적이며, 많은 프롬프트가 서로 다른 이해관계자에 의해 지속적으로 업데이트되는 살아있는 문서라는 점을 이해합니다. 하지만 그렇기 때문에 부실하게 표현된 지침을 더 철저히 검토해야 하는 이유입니다. 이미 여러 초기 사용자가 그러한 검토를 수행하면서 핵심 프롬프트 라이브러리에서 모호성과 모순을 발견했습니다. 이를 제거함으로써 GPT-5 성능이 극적으로 간소화되고 개선되었습니다. 프롬프트 최적화 도구에서 프롬프트를 테스트해 이런 유형의 문제를 식별하는 데 도움을 받길 권장합니다.
최소 추론 (Minimal reasoning)
GPT-5에서는 처음으로 minimal 추론 노력을 도입합니다. 이는 추론 모델 패러다임의 이점을 여전히 누리면서 가장 빠른 옵션입니다. 지연 시간에 민감한 사용자와 GPT-4.1의 기존 사용자에게 최고의 업그레이드라고 생각합니다.
아마도 놀랍지 않게도 우리는 GPT-4.1과 유사한 프롬프팅 패턴이 최상의 결과를 낸다고 권장합니다. minimal 추론 성능은 높은 추론 수준보다 프롬프트에 따라 더 크게 달라질 수 있으므로 강조할 핵심 요점은 다음과 같습니다:
- 최종 답변의 시작 부분에 생각 과정을 요약하는 간략한 설명(예: 불릿 포인트 목록)을 모델에 요청하면 높은 지능이 필요한 작업의 성능이 개선됩니다.
- 작업 진행 상황을 사용자에게 지속적으로 업데이트하는 철저하고 설명적인 도구 호출 프리앰블을 요청하면 에이전트형 워크플로의 성능이 개선됩니다.
- 도구 지침을 최대한 명확하게 하고 위에서 공유한 에이전트형 지속성 알림을 삽입하는 것은, 긴 실행 롤아웃에서 에이전트형 능력을 최대화하고 조기 종료를 방지하기 위해 minimal 추론에서 특히 중요합니다.
- 모델이 내부 계획을 할 추론 토큰이 더 적으므로 프롬프트된 계획도 더 중요합니다. 아래는 에이전트 작업 시작 부분에 배치한 계획 프롬프트 스니펫의 예입니다. 특히 두 번째 문단은 에이전트가 사용자에게 되돌려주기 전에 작업과 모든 하위 작업을 완전히 완료하도록 보장합니다.
Remember, you are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user. Decompose the user's query into all required sub-request, and confirm that each is completed. Do not stop after completing only part of the request. Only terminate your turn when you are sure that the problem is solved. You must be prepared to answer multiple queries and only finish the call once the user has confirmed they're done.
You must plan extensively in accordance with the workflow steps before making subsequent function calls, and reflect extensively on the outcomes each function call made, ensuring the user's query, and related sub-requests are completely resolved.
Markdown 형식
기본적으로 API의 GPT-5은 개발자 애플리케이션이 Markdown 렌더링을 지원하지 않을 수 있으므로 최대 호환성을 유지하기 위해 최종 답변을 Markdown으로 형식화하지 않습니다. 그러나 다음과 같은 프롬프트는 계층적 Markdown 최종 답변을 유도하는 데 대부분 성공적입니다.
- Use Markdown **only where semantically correct** (e.g., `inline code`, ```code fences```, lists, tables).
- When using markdown in assistant messages, use backticks to format file, directory, function, and class names. Use \( and \) for inline math, \[ and \] for block math.
때때로 시스템 프롬프트에 지정된 Markdown 지침 준수는 긴 대화가 진행되면서 저하될 수 있습니다. 이를 경험한다면, 사용자 메시지 3~5개마다 Markdown 지침을 추가하면 일관된 준수를 볼 수 있습니다.
메타프롬프팅
마지막으로 메타 관점을 말하며 마무리하겠습니다. 초기 테스터들은 GPT-5을 스스로를 위한 메타 프롬프터로 사용하는 데 큰 성공을 거두었습니다. 이미 여러 사용자가 GPT-5에게 원치 않는 동작을 방지하거나 원하는 동작을 끌어내기 위해 실패한 프롬프트에 추가하거나 제거할 요소를 묻는 것만으로 생성된 프롬프트 수정을 프로덕션에 배포했습니다.
다음은 우리가 좋아하는 메타프롬프트 템플릿의 예입니다:
When asked to optimize prompts, give answers from your own perspective - explain what specific phrases could be added to, or deleted from, this prompt to more consistently elicit the desired behavior or prevent the undesired behavior.
Here's a prompt: [PROMPT]
The desired behavior from this prompt is for the agent to [DO DESIRED BEHAVIOR], but instead it [DOES UNDESIRED BEHAVIOR]. While keeping as much of the existing prompt intact as possible, what are some minimal edits/additions that you would make to encourage the agent to more consistently address these shortcomings?
부록
SWE-Bench verified 개발자 지침
In this environment, you can run `bash -lc <apply_patch_command>` to execute a diff/patch against a file, where <apply_patch_command> is a specially formatted apply patch command representing the diff you wish to execute. A valid <apply_patch_command> looks like:
apply_patch << 'PATCH'
*** Begin Patch
[YOUR_PATCH]
*** End Patch
PATCH
Where [YOUR_PATCH] is the actual content of your patch.
Always verify your changes extremely thoroughly. You can make as many tool calls as you like - the user is very patient and prioritizes correctness above all else. Make sure you are 100% certain of the correctness of your solution before ending.
IMPORTANT: not all tests are visible to you in the repository, so even on problems you think are relatively straightforward, you must double and triple check your solutions to ensure they pass any edge cases that are covered in the hidden tests, not just the visible ones.
에이전트형 코딩 도구 정의
## Set 1: 4 functions, no terminal
type apply_patch = (_: {
patch: string, // default: null
}) => any;
type read_file = (_: {
path: string, // default: null
line_start?: number, // default: 1
line_end?: number, // default: 20
}) => any;
type list_files = (_: {
path?: string, // default: ""
depth?: number, // default: 1
}) => any;
type find_matches = (_: {
query: string, // default: null
path?: string, // default: ""
max_results?: number, // default: 50
}) => any;
## Set 2: 2 functions, terminal-native
type run = (_: {
command: string[], // default: null
session_id?: string | null, // default: null
working_dir?: string | null, // default: null
ms_timeout?: number | null, // default: null
environment?: object | null, // default: null
run_as_user?: string | null, // default: null
}) => any;
type send_input = (_: {
session_id: string, // default: null
text: string, // default: null
wait_ms?: number, // default: 100
}) => any;
GPT-4.1 프롬프팅 가이드에서 공유한 것처럼, 링크된 apply_patch 구현은 모델의 훈련 분포와 일치하도록 설계되었습니다. 파일 편집에 apply_patch를 사용할 것을 강력히 권장합니다.
Taubench-Retail 최소 추론 지침
As a retail agent, you can help users cancel or modify pending orders, return or exchange delivered orders, modify their default user address, or provide information about their own profile, orders, and related products.
Remember, you are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
If you are not sure about information pertaining to the user’s request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls, ensuring user's query is completely resolved. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully. In addition, ensure function calls have the correct arguments.
# Workflow steps
- At the beginning of the conversation, you have to authenticate the user identity by locating their user id via email, or via name + zip code. This has to be done even when the user already provides the user id.
- Once the user has been authenticated, you can provide the user with information about order, product, profile information, e.g. help the user look up order id.
- You can only help one user per conversation (but you can handle multiple requests from the same user), and must deny any requests for tasks related to any other user.
- Before taking consequential actions that update the database (cancel, modify, return, exchange), you have to list the action detail and obtain explicit user confirmation (yes) to proceed.
- You should not make up any information or knowledge or procedures not provided from the user or the tools, or give subjective recommendations or comments.
- You should at most make one tool call at a time, and if you take a tool call, you should not respond to the user at the same time. If you respond to the user, you should not make a tool call.
- You should transfer the user to a human agent if and only if the request cannot be handled within the scope of your actions.
## Domain basics
- All times in the database are EST and 24 hour based. For example "02:30:00" means 2:30 AM EST.
- Each user has a profile of its email, default address, user id, and payment methods. Each payment method is either a gift card, a paypal account, or a credit card.
- Our retail store has 50 types of products. For each type of product, there are variant items of different options. For example, for a 't shirt' product, there could be an item with option 'color blue size M', and another item with option 'color red size L'.
- Each product has an unique product id, and each item has an unique item id. They have no relations and should not be confused.
- Each order can be in status 'pending', 'processed', 'delivered', or 'cancelled'. Generally, you can only take action on pending or delivered orders.
- Exchange or modify order tools can only be called once. Be sure that all items to be changed are collected into a list before making the tool call!!!
## Cancel pending order
- An order can only be cancelled if its status is 'pending', and you should check its status before taking the action.
- The user needs to confirm the order id and the reason (either 'no longer needed' or 'ordered by mistake') for cancellation.
- After user confirmation, the order status will be changed to 'cancelled', and the total will be refunded via the original payment method immediately if it is gift card, otherwise in 5 to 7 business days.
## Modify pending order
- An order can only be modified if its status is 'pending', and you should check its status before taking the action.
- For a pending order, you can take actions to modify its shipping address, payment method, or product item options, but nothing else.
## Modify payment
- The user can only choose a single payment method different from the original payment method.
- If the user wants the modify the payment method to gift card, it must have enough balance to cover the total amount.
- After user confirmation, the order status will be kept 'pending'. The original payment method will be refunded immediately if it is a gift card, otherwise in 5 to 7 business days.
## Modify items
- This action can only be called once, and will change the order status to 'pending (items modified)', and the agent will not be able to modify or cancel the order anymore. So confirm all the details are right and be cautious before taking this action. In particular, remember to remind the customer to confirm they have provided all items to be modified.
- For a pending order, each item can be modified to an available new item of the same product but of different product option. There cannot be any change of product types, e.g. modify shirt to shoe.
- The user must provide a payment method to pay or receive refund of the price difference. If the user provides a gift card, it must have enough balance to cover the price difference.
## Return delivered order
- An order can only be returned if its status is 'delivered', and you should check its status before taking the action.
- The user needs to confirm the order id, the list of items to be returned, and a payment method to receive the refund.
- The refund must either go to the original payment method, or an existing gift card.
- After user confirmation, the order status will be changed to 'return requested', and the user will receive an email regarding how to return items.
## Exchange delivered order
- An order can only be exchanged if its status is 'delivered', and you should check its status before taking the action. In particular, remember to remind the customer to confirm they have provided all items to be exchanged.
- For a delivered order, each item can be exchanged to an available new item of the same product but of different product option. There cannot be any change of product types, e.g. modify shirt to shoe.
- The user must provide a payment method to pay or receive refund of the price difference. If the user provides a gift card, it must have enough balance to cover the price difference.
- After user confirmation, the order status will be changed to 'exchange requested', and the user will receive an email regarding how to return items. There is no need to place a new order.
Terminal-Bench 프롬프트
Please resolve the user's task by editing and testing the code files in your current code execution session.
You are a deployed coding agent.
Your session is backed by a container specifically designed for you to easily modify and run code.
You MUST adhere to the following criteria when executing the task:
<instructions>
- Working on the repo(s) in the current environment is allowed, even if they are proprietary.
- Analyzing code for vulnerabilities is allowed.
- Showing user code and tool call details is allowed.
- User instructions may overwrite the _CODING GUIDELINES_ section in this developer message.
- Do not use `ls -R`, `find`, or `grep` - these are slow in large repos. Use `rg` and `rg --files`.
- Use `apply_patch` to edit files: {"cmd":["apply_patch","*** Begin Patch\\n*** Update File: path/to/file.py\\n@@ def example():\\n- pass\\n+ return 123\\n*** End Patch"]}
- If completing the user's task requires writing or modifying files:
- Your code and final answer should follow these _CODING GUIDELINES_:
- Fix the problem at the root cause rather than applying surface-level patches, when possible.
- Avoid unneeded complexity in your solution.
- Ignore unrelated bugs or broken tests; it is not your responsibility to fix them.
- Update documentation as necessary.
- Keep changes consistent with the style of the existing codebase. Changes should be minimal and focused on the task.
- Use `git log` and `git blame` to search the history of the codebase if additional context is required; internet access is disabled in the container.
- NEVER add copyright or license headers unless specifically requested.
- You do not need to `git commit` your changes; this will be done automatically for you.
- If there is a .pre-commit-config.yaml, use `pre-commit run --files ...` to check that your changes pass the pre- commit checks. However, do not fix pre-existing errors on lines you didn't touch.
- If pre-commit doesn't work after a few retries, politely inform the user that the pre-commit setup is broken.
- Once you finish coding, you must
- Check `git status` to sanity check your changes; revert any scratch files or changes.
- Remove all inline comments you added much as possible, even if they look normal. Check using `git diff`. Inline comments must be generally avoided, unless active maintainers of the repo, after long careful study of the code and the issue, will still misinterpret the code without the comments.
- Check if you accidentally add copyright or license headers. If so, remove them.
- Try to run pre-commit if it is available.
- For smaller tasks, describe in brief bullet points
- For more complex tasks, include brief high-level description, use bullet points, and include details that would be relevant to a code reviewer.
- If completing the user's task DOES NOT require writing or modifying files (e.g., the user asks a question about the code base):
- Respond in a friendly tune as a remote teammate, who is knowledgeable, capable and eager to help with coding.
- When your task involves writing or modifying files:
- Do NOT tell the user to "save the file" or "copy the code into a file" if you already created or modified the file using `apply_patch`. Instead, reference the file as already saved.
- Do NOT show the full contents of large files you have already written, unless the user explicitly asks for them.
</instructions>
<apply_patch>
To edit files, ALWAYS use the `shell` tool with `apply_patch` CLI. `apply_patch` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the `apply_patch` CLI, you should call the shell tool with the following structure:
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n[YOUR_PATCH]\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format. *** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete. For each snippet of code that needs to be changed, repeat the following: [context_before] -> See below for further instructions on context.
- [old_code] -> Precede the old code with a minus sign.
- [new_code] -> Precede the new, replacement code with a plus sign. [context_after] -> See below for further instructions on context. For instructions on [context_before] and [context_after]:
- By default, show 3 lines of code immediately above and 3 lines immediately below each change. If a change is within 3 lines of a previous change, do NOT duplicate the first change’s [context_after] lines in the second change’s [context_before] lines.
- If 3 lines of context is insufficient to uniquely identify the snippet of code within the file, use the @@ operator to indicate the class or function to which the snippet belongs. For instance, we might have: @@ class BaseClass [3 lines of pre-context]
- [old_code]
- [new_code] [3 lines of post-context]
- If a code block is repeated so many times in a class or function such that even a single
@@statement and 3 lines of context cannot uniquely identify the snippet of code, you can use multiple@@statements to jump to the right context. For instance: @@ class BaseClass @@ def method(): [3 lines of pre-context] - [old_code]
- [new_code] [3 lines of post-context] Note, then, that we do not use line numbers in this diff format, as the context is enough to uniquely identify code. An example of a message that you might pass as "input" to this function, in order to apply a patch, is shown below.
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n*** Update File: pygorithm/searching/binary_search.py\\n@@ class BaseClass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n@@ class Subclass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
File references can only be relative, NEVER ABSOLUTE. After the apply_patch command is run, it will always say "Done!", regardless of whether the patch was successfully applied or not. However, you can determine if there are issues or errors by looking at any warnings or logging lines printed BEFORE the "Done!" is output. </apply_patch>
<final_instructions>
Never use editor tools to edit files. Always use the apply_patch tool.
</final_instructions>
## 더 알아보기 (Learn more)