오픈AI 공식 프롬프트 가이드: GPT-5를 잘쓰는 3가지 방법

이런 차이는 GPT-5가 “사용자가 명시한 의도(explicit intent)를 파악하는 것”에 뛰어나기에 발생합니다. 조금 더 사람이 바라는 대로 움직인다는 뜻이니까요. 그래서 GPT-5를 잘 쓰려면 명령, 즉, 프롬프트를 잘 만드는 것이 무엇보다 중요합니다. 일반적인 의미를 훌쩍 뛰어 넘어서 말이죠.

오픈AI가 GPT-5를 위해 만든 “공식 프롬프트 가이드”를 다시 GPT-5의 도움을 받아 번역하고 정리했습니다.

GPT 프롬프트 가이드

GPT-5는 오픈AI가 새롭게 선보이는 대표 모델로, 자율적 과제 수행 능력, 코딩, 순수한 지적 능력, 그리고 조정 가능성(steerability)에서 큰 도약을 보여줍니다.

비록 이 모델이 다양한 분야에서 “기본 설정 그대로(out of the box)”도 뛰어난 성능을 발휘하리라 믿지만, 이 안내서는 모델 활용 결과의 품질을 극대화하기 위한 프롬프트 작성 요령을 다루고자 합니다. 이 요령은 모두 오픈AI가 실제 업무에 모델을 훈련하고 적용하면서 얻은 경험에 기반한 것입니다. 가이드에서는 자율적 과제 수행 능력 향상, 지시사항 충실성 확보, 새롭게 추가된 응용프로그램 인터페이스(API) 기능 활용, 그리고 프론트엔드 및 소프트웨어 엔지니어링 코딩 최적화와 같은 주제를 다룹니다. 특히, 인공지능 코드 편집기인 커서(Cursor)가 GPT-5를 활용해 프롬프트 최적화를 시도한 사례에서 얻은 인사이트도 함께 제시합니다.

이러한 모범 사례를 적용하고 표준 도구를 적극적으로 활용했을 때, 뚜렷한 성과 향상을 확인할 수 있었습니다. 이번 안내서와 함께 준비한 프롬프트 최적화 도구가 여러분이 GPT-5를 활용하는 출발점이 되기를 바랍니다. 다만, 언제나 기억해야 할 점은 프롬프트 작성은 모든 경우에 똑같이 통용되는 방식(one-size-fits-all)이 아니라는 것입니다. 이 기초 위에서 직접 실험하고 반복 개선하며, 여러분의 문제에 가장 적합한 해법을 찾아 나가기를 권장합니다.

1. 에이전틱 워크플로우의 예측 가능성 올리기

우선 GPT-5는 개발자들을 염두에 두고 학습시켰습니다. 도구 호출(tool calling), 지시사항 준수, 장기 맥락 이해 능력을 중점적으로 강화해 에이전트형 응용프로그램을 위한 최고의 기초 모델이 되도록 했습니다.

무엇보다 만약 GPT-5를 에이전트형 및 도구 호출 흐름(agentic and tool calling flows)에 도입한다면, Responses API로 업그레이드할 것을 권장합니다. 이 API에서는 도구 호출 사이에 모델의 추론(reasoning)이 유지되므로, 더 효율적이고 지능적인 결과를 얻을 수 있습니다.

에이전트의 적극성(Agentic Eagerness) 제어하기

에이전트 구조(agentic scaffold)는 매우 넓은 제어 스펙트럼을 가질 수 있습니다. 어떤 시스템은 의사결정의 대부분을 기본 모델에 위임하는 반면, 다른 시스템은 강력한 프로그램적 분기(logical branching)를 통해 모델을 엄격히 통제합니다. GPT-5는 이러한 스펙트럼 전반에 걸쳐 작동하도록 학습되었습니다. 즉, 불확실한 상황에서 고차원적 결정을 내리는 것부터, 명확히 정의된 과제를 집중적으로 수행하는 것까지 모두 가능합니다.

여기서는 GPT-5의 에이전트형 적극성을 조율하는 방법, 즉 적극적으로 개입하는 정도와 명시적인 지시를 기다리는 태도 사이의 균형을 어떻게 잡을 수 있는지 다룹니다.

적극성을 줄이는 프롬프트 작성법

기본적으로 GPT-5는 올바른 답변을 도출하기 위해 맥락을 철저하고 종합적으로 수집하려는 성향이 있습니다. 그러나 도구 호출 작업을 줄이고, 최종 답변에 도달하기까지의 지연(latency)을 최소화하고자 불필요한 에이전트의 동작 범위를 줄이고 싶다면 아래와 같은 방법을 활용해 보세요.

추론 강도(reasoning_effort)를 낮은 단계로 전환하세요. 탐색 깊이는 줄어들지만 효율성과 응답 속도는 좋아집니다. 대부분 워크플로우는 중간 혹은 낮은 추론 강도(reasoning_effort) 수준에서도 일관된 결과를 얻을 수 있습니다.
프롬프트로 문제 탐색 방식을 명확히 정의하세요. 모델이 지나치게 많은 아이디어를 탐색하고 추론할 필요를 줄여줍니다.

*이하 프롬프트 예시의 원문은 모두 영어로 작성되어 있으나 빠른 이해를 돕기 위해 한글로 번역했습니다. 프롬프트 원본은 원문에서 확인할 수 있습니다.

<context_gathering>

목표: 최대한 빠르게 충분한 문맥을 확보한다. 탐색은 병렬로 진행하되, 실행할 수 있는 시점에 도달하면 즉시 중단한다.

방법:

- 먼저 넓게 시작한 뒤, 점차 구체적인 하위 쿼리로 확장한다.
- 병렬적으로 다양한 쿼리를 실행하고, 각 쿼리에서 상위 검색 결과를 확인한다.
- 경로를 중복 제거하고 캐시하여 같은 쿼리를 반복하지 않는다.
- 문맥 확보를 위해 과도하게 검색하지 않는다. 필요한 경우, 한 번의 병렬 배치로 목표 지향적 검색을 실행한다.

조기 중단 기준(Early Stop Criteria):

- 변경할 구체적인 내용을 지목할 수 있을 때.
- 상위 검색 결과가 약 70% 이상 동일한 영역 또는 경로로 수렴할 때.

한 번의 에스컬레이션(Escalate once):

- 신호가 충돌하거나 범위가 불명확한 경우, 한 차례 정제된 병렬 검색을 실행한 후 진행한다.

깊이(Depth):

- 수정할 기호(symbol) 또는 그 계약(contract)에 의존하는 기호까지만 추적한다.
- 반드시 필요한 경우가 아니면 연쇄적인(transitive) 확장은 피한다.

루프(Loop):

- 배치 검색 → 최소 실행 계획 → 작업 완료.
- 검증이 실패하거나 새로운 불명확성이 등장할 때만 재검색한다.
- 더 많은 검색보다는 실행을 우선시한다.

</context_gathering>

만약 최대한 규범적(prescriptive)으로 접근하고 싶다면, 아래 예시처럼 고정된 도구 호출 예산(tool call budget)을 설정할 수도 있습니다. 이 예산은 원하는 탐색 깊이에 따라 자연스럽게 달라질 수 있습니다.

<context_gathering>
- 탐색 깊이: 매우 낮음
- 완전히 정확하지 않을 수 있더라도 가능한 한 빠르게 정답을 제공하는 쪽으로 강하게 편향됨.
- 보통 절대 최대 2회 도구 호출을 의미함.
- 더 많은 조사가 필요하다고 생각되면, 현재까지의 결과와 열린 질문을 사용자에게 알려야 함. 사용자가 확인하면 이후 절차를 진행할 수 있음.
</context_gathering>

핵심적인 문맥 수집 행동을 제한할 때는, 모델이 더 짧은 문맥 수집 단계를 충족하기 쉽게 탈출구(escape hatch)를 명시적으로 제공하는 것이 도움이 됩니다. 일반적으로 이는 “완전히 정확하지 않을 수 있더라도(even if it might not be fully correct)”와 같은 조항의 형태를 띱니다. 위 예시의 두 번째 문항처럼요.

적극성을 높이는 프롬프트 작성법

반대로 모델의 자율성을 장려하고, 도구 호출의 지속성을 강화하며, 확인 질문이나 사용자에게 다시 넘기는 행동을 줄이고 싶을 수도 있습니다. 그럴 때는 추론 강도를 높이고, 아래와 같은 프롬프트를 활용해 지속성과 철저한 과제 수행을 유도하는 것이 좋습니다.

<persistence>
- 당신은 하나의 에이전트입니다. 사용자의 질문이 완전히 해결될 때까지 계속 진행한 후, 그때에만 차례를 종료하고 사용자에게 제어를 넘기십시오.
- 문제 해결이 확실히 완료되었을 때만 차례를 끝내십시오.
- 불확실성을 마주하더라도 절대 중단하거나 사용자에게 되돌리지 마십시오. 가장 합리적인 접근법을 조사하거나 추론하여 계속 진행하십시오.
- 가정(assumption)에 대해 사용자의 확인이나 설명을 요청하지 마십시오. 언제든 사후에 조정할 수 있으므로, 가장 합리적인 가정을 스스로 내리고 그것을 바탕으로 진행하십시오. 다만, 행위를 마친 후에는 그 가정을 사용자 참고용으로 기록해 두십시오.
</persistence>

일반적으로, 에이전트형 과제의 종료 조건(stop condition)을 명확히 규정하고, 안전한 행동과 위험한 행동을 구분하며, 사용자에게 제어를 넘기는 것을 허용하는 시점을 정의해 두는 것이 도움이 됩니다.

예를 들어, 쇼핑 관련 도구 세트에서 결제 및 지불 도구는 사용자 확인을 요구하는 불확실성 임계치(threshold)를 낮게 설정해야 하지만, 검색 도구는 매우 높은 임계치를 가져야 합니다. 마찬가지로 코딩 환경에서는 파일 삭제(delete file) 도구가 grep 검색 도구보다 훨씬 낮은 임계치를 가져야 합니다.

도구 서론(Tool Preambles)

사용자가 모니터링하는 에이전트형 진행 과정(agentic trajectory)에서는, 모델이 도구 호출 시 무엇을 하고 있는지와 그 이유를 간헐적으로 업데이트해 주는 것이 훨씬 더 나은 상호작용 경험을 제공합니다. 전개 기간이 길어질수록 이러한 업데이트의 효과는 더욱 커집니다.

이를 위해 GPT-5는 “도구 서론(tool preamble)” 메시지를 통해 명확한 사전 계획과 일관된 진행 상황 업데이트를 제공하도록 학습했습니다.

프롬프트에서 도구 서론의 빈도, 방식, 내용을 조율할 수 있습니다. 모든 도구 호출에 대한 자세한 설명부터 간단한 사전 계획까지, 그 사이 다양한 수준을 선택할 수 있습니다. 다음은 품질이 뛰어난 서론 프롬프트의 예시입니다.

<tool_preambles>
- 도구를 호출하기 전에, 항상 사용자의 목표를 친절하고 명확하며 간결하게 다시 표현하십시오.
- 그 다음, 곧바로 수행할 각 논리적 단계를 체계적으로 설명한 계획을 제시하십시오.
- 파일 편집 등을 실행할 때는 각 단계를 간결하고 순차적으로 설명하며, 진행 상황을 명확히 표시하십시오.
- 마지막으로, 사전 계획과 구분되게 완료된 작업을 요약해 주십시오.
</tool_preambles>

아래는 이러한 프롬프트에 대한 응답으로 모델이 생성할 도구 서론 예시입니다. 이런 서론은 에이전트의 작업이 복잡해질수록 사용자가 과정을 이해하고 따라가는 능력을 크게 향상시킵니다.

"output": [
  {
    "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**날씨 응답 결정**\\n\\n사용자가 요청한 샌프란시스코의 날씨에 대한 답변을 준비해야 합니다. ...."
      }
    ]
  },
  {
    "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "text": "샌프란시스코의 현재 날씨를 확인하기 위해 실시간 날씨 서비스를 조회하겠습니다. 섭씨와 화씨 온도를 모두 제공해, 사용자의 선호에 맞추겠습니다."
      }
    ],
    "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)이지만, 과제의 난이도에 따라 상향 또는 하향 조정하는 것이 좋습니다. 복잡하고 여러 단계에 걸친 과제의 경우, 더 높은 추론 강도를 설정해야 최상의 결과를 얻을 수 있습니다.

또한, 서로 구분할 수 있는 과제를 여러 에이전트 턴(agent turn)에 나누어 수행할 때 성능이 가장 좋아지는 것을 확인했습니다. 즉, 하나의 턴에서는 하나의 과제만 처리하는 것이 바람직합니다.

Responses API를 통한 추론 맥락 재사용

GPT-5를 활용할 때는 Responses API 사용을 강력히 권장합니다. 무엇보다 에이전트의 흐름(agentic flow)이 좋아지고, 비용 절감과 토큰 사용 효율 개선 효과를 얻을 수 있습니다.

실제로, Responses API를 기존의 대화 형식(Chat Completions) 대신 사용할 때 평가 결과가 통계적으로 유의미하게 개선되는 것을 확인했습니다. 예를 들어, 타우-벤치마크의 소매(Tau-Bench Retail) 점수가 73.9%에서 78.2%로 올랐습니다. 핵심은 previous_response_id를 활용해 이전 추론 항목을 후속 요청에 전달하는 것이었습니다. 이렇게 하면 모델이 이전 추론 기록(reasoning trace)을 참조할 수 있어, 연쇄적 사고(CoT, Chain of Thought) 토큰을 절약하고, 매 도구 호출마다 계획을 처음부터 다시 세울 필요가 없어집니다. 결과적으로 지연(latency)과 성능 모두 개선됩니다. 이 기능은 모든 Responses API 사용자, 그리고 ZDR 조직에도 제공됩니다.

2. 기획에서 실행까지, 코딩 성능 극대화하기

GPT-5는 모든 최전선(frontier) 모델 가운데 코딩 능력에서 가장 뛰어난 위치를 차지합니다. 방대한 코드베이스에서 버그를 수정하고, 대규모 변경(diff)을 처리하며, 여러 파일에 걸친 리팩터링이나 새로운 대규모 기능을 구현할 수 있습니다. 또한, 완전히 새로운 애플리케이션을 프론트엔드와 백엔드 전부를 포함하여 처음부터 끝까지 구현하는 데에도 뛰어난 성능을 발휘합니다.

실제 고객들이 코딩 에이전트(coding agent)로 GPT-5를 활용할 때 프로덕션 환경에서 프로그래밍 성능을 높이는 데 효과적이었던 프롬프트 최적화 기법을 소개합니다.

프론트엔드 앱 개발

GPT-5는 엄격한 구현 능력뿐 아니라 기본적인 미적 감각(aesthetic taste) 또한 갖추도록 학습되었습니다. 다양한 웹 개발 프레임워크와 패키지를 활용할 수 있는 능력을 갖추고 있으며, 특히 새로운 애플리케이션을 만들 때는 아래와 같은 프레임워크와 패키지를 활용하면 모델의 프론트엔드 역량을 최대한 이끌어낼 수 있습니다.

프레임워크: Next.js(타입스크립트), React, HTML
스타일링 / UI: Tailwind CSS, shadcn/ui, Radix Themes
아이콘: Material Symbols, Heroicons, Lucide
애니메이션: Motion
폰트: San Serif, Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

제로 투 원(Zero-to-one) 애플리케이션 생성

GPT-5는 애플리케이션을 단번에(one shot) 구축하는 데 탁월합니다. 모델에 대한 초기 실험에서 사용자들은, 아래와 같이 모델이 스스로 만든 평가 기준(excellence rubric)에 따라 반복적으로 실행하도록 요청하는 프롬프트가 GPT-5의 철저한 계획 및 자기 성찰 능력을 활용하여 출력 품질을 향상시킨다는 것을 발견했습니다.

<self_reflection>
- 먼저, 자신이 확신할 때까지 루브릭을 구상하는 데 시간을 쓰십시오.
- 그다음, 세계적 수준의 원샷 웹 애플리케이션을 만드는 데 필요한 모든 요소를 깊이 있게 고민하십시오. 이 지식을 활용해 5~7개의 범주를 가진 루브릭을 만드십시오. 이 루브릭은 반드시 정확히 만들어야 하지만, 사용자에게 공개하지 마십시오. 이는 내부용입니다.
- 마지막으로, 이 루브릭을 활용해 내부적으로 사고하고 반복하며, 주어진 프롬프트에 대한 최상의 해답을 도출하십시오. 만약 응답이 루브릭의 모든 범주에서 최고 기준을 충족하지 못한다면, 다시 시작해야 합니다.
</self_reflection>

코드베이스 설계 기준과 일치시키기

기존 애플리케이션에서 점진적인 변경이나 리팩터링을 수행할 때, 모델이 작성하는 코드는 기존 스타일과 설계 기준을 준수하며 코드베이스에 자연스럽게 “녹아들어야” 합니다. 특별한 프롬프트 없이도 GPT-5는 이미 코드베이스의 참조 문맥을 탐색합니다(예: package.json을 읽어 설치된 패키지 확인). 하지만 프롬프트에 설계 원칙, 디렉터리 구조, 코드베이스의 명시적·암묵적 모범 사례를 요약해 제공하면 이 성능을 더욱 강화할 수 있습니다.

아래는 GPT-5에 적용할 수 있는 코드 편집 규칙 예시입니다. 실제 규칙 내용은 개발자의 설계 철학에 따라 자유롭게 변경할 수 있습니다.

<code_editing_rules>
<guiding_principles>
- 명확성과 재사용성: 모든 컴포넌트와 페이지는 모듈화되어 재사용 가능해야 합니다. 반복되는 UI 패턴은 컴포넌트로 분리해 중복을 피하십시오.
- 일관성: 사용자 인터페이스는 색상 토큰, 타이포그래피, 간격, 컴포넌트 등에서 일관된 디자인 시스템을 따라야 합니다.
- 단순성: 작고 집중된 컴포넌트를 선호하며, 불필요한 복잡성을 피하십시오.
- 데모 지향성: 스트리밍, 멀티턴 대화, 도구 통합 등 기능 시연이 가능하도록 구조를 설계하십시오.
- 시각적 품질: OSS 가이드라인에 명시된 높은 시각적 품질 기준(간격, 여백, 호버 상태 등)을 따르십시오.
</guiding_principles>
<frontend_stack_defaults>
- 프레임워크: Next.js (TypeScript)
- 스타일링: TailwindCSS
- UI 컴포넌트: shadcn/ui
- 아이콘: Lucide
- 상태 관리: Zustand
- 디렉터리 구조:
\\`\\`\\`
/src
 /app
   /api/<route>/route.ts         # API 엔드포인트
   /(pages)                      # 페이지 라우트
 /components/                    # UI 빌딩 블록
 /hooks/                         # 재사용할 수 있는 React hooks
 /lib/                           # 유틸리티 (fetchers, helpers)
 /stores/                        # Zustand stores
 /types/                         # 공유 TypeScript 타입
 /styles/                        # Tailwind 설정
\\`\\`\\`
</frontend_stack_defaults>
<ui_ux_best_practices>
- 시각적 계층: 일관성을 위해 글꼴 크기·굵기는 4~5단계로 제한하십시오. 캡션과 주석에는 `text-xs`를 사용하고, `text-xl`은 히어로 영역이나 주요 제목에만 사용하십시오.
- 색상 사용: 1개의 중립색(예: `zinc`)과 최대 2개의 강조색만 사용하십시오.
- 간격과 레이아웃: 패딩과 마진은 항상 4의 배수로 하여 시각적 리듬을 유지하십시오. 긴 콘텐츠 스트림은 고정 높이 컨테이너와 내부 스크롤을 사용하십시오.
- 상태 처리: 데이터 로딩 시 `skeleton` 플레이스홀더나 `animate-pulse`를 활용하고, 클릭 가능 영역에는 `hover:bg-*`, `hover:shadow-md` 같은 호버 전환 효과를 주십시오.
- 접근성: 적절한 경우 시맨틱 HTML과 ARIA 역할을 사용하십시오. 접근성이 내장된 Radix/shadcn 컴포넌트를 우선 활용하십시오.
</ui_ux_best_practices>
<code_editing_rules>

프로덕션 환경에서의 협업 코딩: 커서(Cursor)의 GPT-5 프롬프트 튜닝

AI 코드 편집기 커서(Cursor)는 GPT-5의 신뢰할 수 있는 알파 테스터였습니다. 커서가 GPT-5의 성능을 최대한 이끌어내기 위해 프롬프트를 어떻게 조정했는지 그 일부를 소개합니다.

*자세한 내용은 커서 팀이 공개한 블로그 글에서 확인할 수 있습니다: 커서 블로그

시스템 프롬프트와 매개변수 튜닝

커서 팀은 초기 단계에서 모델이 장황한 출력을 생성한다는 것을 발견했습니다. 출력에는 상태 업데이트와 작업 후 요약이 자주 포함되었는데, 이는 기술적으로는 관련성이 있었지만 사용자의 자연스러운 흐름을 방해했습니다. 그와 함께, 도구 호출에서 생성된 코드는 높은 품질을 보였으나, 지나치게 간결하여 읽기 어렵고 단일 문자 변수명이 주로 쓰였습니다.

더 나은 균형을 찾고자 그들은 텍스트 출력을 간결하게 유지하기 위해 verbosity API 매개변수를 낮음으로 설정했고, 프롬프트를 수정하여 코딩 도구 내 출력에서는 장황하게 작성하도록 강하게 유도했습니다.

코드를 작성할 때는 명확성을 최우선으로 하십시오. 명확한 이름, 필요한 경우 주석, 직관적인 제어 흐름을 사용하여 읽기 쉽고 유지보수 가능한 해법을 선호하십시오. 명시적으로 요청되지 않는 한 코드 골프나 지나치게 영리한 한 줄 코드는 작성하지 마십시오. 코드를 작성할 때와 코드 도구에서는 높은 장황도를 사용하십시오.

이처럼 매개변수와 프롬프트를 이중으로 활용해 효율적이고 간결한 상태 업데이트, 최종 작업 요약과 훨씬 더 가독성 높은 코드 변경을 결합한 균형 잡힌 형식을 만들어낼 수 있습니다.

커서는 또한 모델이 가끔씩 실행에 앞서 사용자에게 확인이나 다음 단계를 묻는 경우가 있었는데, 이는 장기 작업의 흐름에서 불필요한 마찰을 일으켰습니다. 이를 해결하기 위해, 그들은 사용할 수 있는 도구와 주변 문맥뿐 아니라 제품 동작에 대한 더 많은 세부 정보를 포함하면, 모델이 최소한의 중단으로 더 긴 작업을 수행하고 더 큰 자율성을 발휘할 수 있다는 것을 발견했습니다. 특히 Undo/Reject 코드와 사용자 선호와 같은 커서 기능의 세부 사항을 강조하는 것은 GPT-5가 자신의 환경에서 어떻게 행동해야 하는지를 명확히 지정함으로써 모호성을 줄이는 데 도움이 되었습니다.

아래의 프롬프트는 장기 작업의 성능을 올려주는 방식의 프롬프트입니다.

작성한 코드 수정은 사용자에게 제안된 변경으로 표시됩니다. 이는 (a) 사용자가 언제든 거부할 수 있으므로 코드 수정은 적극적으로 해도 무방하며, (b) 코드는 잘 작성되어야 하고 빠르게 검토할 수 있어야 한다는 것을 의미합니다(예: 단일 문자 대신 적절한 변수 이름 사용). 코드 변경을 수반하는 다음 단계를 제안할 때는, 계획을 진행할지 사용자에게 묻는 대신 그러한 변경을 적극적으로 수행하여 사용자가 승인하거나 거부할 수 있도록 하십시오. 일반적으로, 계획을 진행할지 여부를 사용자에게 묻는 일은 거의 없어야 합니다. 대신 계획을 적극적으로 시도한 후 구현된 변경을 사용자에게 승인할지 여부를 요청해야 합니다.

한편 커서는 이전 모델에서 효과적이었던 프롬프트의 일부가 GPT-5에서는 조정이 필요하다는 것을 발견했습니다. 아래는 이전 모델에서 적합했던 프롬프트 예시입니다.

<maximize_context_understanding>
정보를 수집할 때는 철저하게 하십시오. 응답하기 전에 전체 상황을 완전히 파악했는지 확인하십시오. 필요할 경우 추가적인 도구 호출(tool calls)이나 확인 질문을 사용하십시오.
...
</maximize_context_understanding>

이 접근은 맥락을 철저히 분석하도록 장려할 필요가 있던 이전 모델에서는 잘 작동했지만, 이미 자연스럽게 자기 성찰적이고 맥락을 적극적으로 수집하는 GPT-5에는 역효과를 냈습니다. 규모가 작은 작업에서는 내부 지식만으로 충분한데도 이 프롬프트가 모델이 검색 도구를 반복적으로 호출하도록 유도하는 경우가 자주 있었습니다.

이 문제를 해결하려고 그들은 maximize_ 접두사를 제거하고 철저함에 관한 기준을 완화하며 프롬프트를 정제했습니다. 이렇게 지침을 조정한 커서 팀은 GPT-5가 내부 지식을 활용할지, 외부 도구를 사용할지에 대한 더 나은 결정을 내리는 것을 확인했습니다. 이는 곧 불필요한 도구 사용 없이 높은 자율성을 유지하면서 더 효율적이고 관련성 있는 행동으로 이어졌습니다.

특히 테스트에서 <[instruction]_spec>과 같은 구조화된 XML 사양을 사용하는 것이 지침 준수율을 향상시켰고, 그들의 프롬프트 내에서 이전 범주와 섹션을 명확히 참조할 수 있게 했습니다.

<context_understanding>
...
사용자의 요청을 부분적으로 충족시킬 수 있는 편집을 수행했지만 확신이 없다면, 차례를 끝내기 전에 더 많은 정보를 수집하거나 도구를 사용하십시오.
스스로 답을 찾을 수 있다면, 사용자에게 도움을 요청하기보다는 직접 해결하려는 쪽으로 기울이십시오.
</context_understanding>

한편 시스템 프롬프트가 강력한 기본 기반을 제공하지만, 사용자 프롬프트는 여전히 조정을 위한 매우 효과적인 수단으로 남아 있습니다. GPT-5는 직접적이고 명확한 지시에 잘 반응하기에, 커서 팀은 구조화되고 범위가 정해진 프롬프트가 가장 신뢰할 만한 결과를 낸다는 것을 일관되게 확인했습니다. 여기에는 장황함 제어, 주관적인 코드 스타일의 선호, 특수 사례에 대한 민감성 같은 영역이 포함됩니다.

즉, 사용자에게 자신만의 커서 규칙을 구성할 기능을 제공하는 것이 GPT-5를 활용하는 데 특히 효과적이었으며, 사용자들에게 더 맞춤화된 경험을 제공했다는 뜻입니다.

3. 지능과 지시 준수 최적화

조정(Steering)

GPT-5는 지금까지 나온 모델 중 가장 조정할 여지가 큰 모델로, 장황함(verbosity), 어조(tone), 도구 호출 행동(tool calling behavior)에 관한 프롬프트 지시에 매우 민감하게 반응합니다.

장황함(Verbosity)

무엇보다 GPT-5에서는 새로운 API 매개변수인 verbosity를 도입했습니다. 이 매개변수는 모델의 사고 과정(thinking)의 길이가 아니라 최종 답변의 길이에 영향을 미칩니다.

이 안내서에서 특히 강조하고 싶은 점이 있습니다. API verbosity 매개변수는 기본적으로 전역 설정이지만, GPT-5는 특정 맥락에서 전역 기본값을 벗어나도록 유도하는 자연어 기반 프롬프트 지시에도 반응하도록 학습되었다는 점입니다. 예를 들어, 커서 사례처럼 전역적으로는 verbosity를 낮게 설정하고, 코딩 도구에 대해서만 높은 verbosity를 지정한 것이 대표적인 활용 예입니다.

지시 준수(Instruction following)

GPT-4.1과 마찬가지로, GPT-5는 프롬프트로 내린 지시를 외과적 정밀성(surgical precision) 수준으로 따릅니다. 이는 모든 유형의 워크플로우에 유연하게 적용될 수 있지만, GPT-5가 지시에 매우 신중하게 따르는 특성이 있기 때문에 모순되거나 모호한 지시가 포함된 잘못 작성된 프롬프트는 다른 모델보다 더 큰 문제를 일으킬 수 있습니다. GPT-5는 무작위로 하나를 선택하지 않고, 지시 간의 모순을 조정할 방법을 찾으려고 추론 토큰(reasoning tokens)을 소모하기 때문입니다.

아래는 GPT-5의 추론 흔적(reasoning traces)을 종종 손상시키는 대립적(adversarial) 프롬프트의 예시입니다.

당신은 CareFlow Assistant이며, 헬스케어 스타트업을 위한 가상 행정 도우미입니다. 당신의 목표는 환자의 우선순위와 증상에 따라 요청을 분류(triage)하고, 적절한 네트워크 내 제공자에게 연결하며, 가장 빠른 임상적으로 적합한 시간대를 예약하는 것입니다. 항상 환자 프로필을 조회하여 기존 환자인지 확인한 후 다른 행동을 하십시오.
- 핵심 엔티티에는 환자(Patient), 제공자(Provider), 예약(Appointment), 우선순위 수준(PriorityLevel: Red, Orange, Yellow, Green)이 포함됩니다. 증상을 우선순위에 매핑하십시오: Red는 2시간 이내, Orange는 24시간 이내, Yellow는 3일 이내, Green은 7일 이내. 증상이 높은 긴급성을 나타낼 경우, EMERGENCY로 격상시키고 스케줄링 단계 전에 즉시 환자에게 911에 연락하도록 안내하십시오.
+핵심 엔티티에는 환자(Patient), 제공자(Provider), 예약(Appointment), 우선순위 수준(PriorityLevel: Red, Orange, Yellow, Green)이 포함됩니다. 증상을 우선순위에 매핑하십시오: Red는 2시간 이내, Orange는 24시간 이내, Yellow는 3일 이내, Green은 7일 이내. 증상이 높은 긴급성을 나타낼 경우, EMERGENCY로 격상시키고 스케줄링 단계 전에 즉시 환자에게 911에 연락하도록 안내하십시오.
*응급 상황에서는 조회를 하지 말고, 즉시 911 안내를 하십시오.*
- 다음 기능을 사용하십시오: schedule-appointment, modify-appointment, waitlist-add, find-provider, lookup-patient, notify-patient. 예약 전에 보험 적격성, 선호 클리닉, 문서화된 동의를 확인하십시오. 환자의 명시적 동의가 차트에 기록되지 않은 경우 절대로 예약을 잡지 마십시오.
- 높은 중증도(Red, Orange) 케이스의 경우, 위험을 줄이기 위해 환자에게 연락하지 않고 동일 일자 내 가장 빠른 슬롯을 *자동 배정*하십시오. 적절한 제공자가 없는 경우, 환자를 대기자 명단에 추가하고 알림을 보내십시오. 동의 상태가 불분명하다면, 임시로 슬롯을 보류한 후 확인을 요청하십시오.
- 높은 중증도(Red, Orange) 케이스의 경우, 환자에게 당신의 조치를 알린 후 동일 일자 내 가장 빠른 슬롯을 *자동 배정*하십시오. 적절한 제공자가 없는 경우, 환자를 대기자 명단에 추가하고 알림을 보내십시오. 동의 상태가 불분명하다면, 임시로 슬롯을 보류한 후 확인을 요청하십시오.

처음 보면 일관성을 가진 것처럼 보일 수 있지만, 자세히 보면 예약 스케줄링 지시에 모순이 있음을 알 수 있습니다.

“환자의 동의가 차트에 명확히 기록되지 않으면 예약을 잡지 말라”는 지시와 “위험을 줄이기 위해 환자에게 연락하지 않고 동일 일자 내 가장 빠른 슬롯을 자동 배정하라”는 지시가 충돌합니다.
“항상 환자 프로필을 조회해 기존 환자인지 확인한 후 다른 행동을 하라”고 말하면서 “응급일 경우, 스케줄링 전에 응급으로 분류해 911에 즉시 연락하도록 안내하라”는 모순된 지시를 포함합니다.

이러한 지시 계층의 충돌을 해결하면 GPT-5는 훨씬 더 효율적이고 성능 높은 추론을 이끌어냅니다. 아래와 같은 방식이면 모순을 해소할 수 있습니다.

자동 배정을 “환자에게 알린 후” 수행하도록 변경해 “동의가 있을 때만 예약”이라는 지시와 일치시킵니다.
“응급 상황에서는 조회를 하지 말고 즉시 911 안내를 하라”는 규칙을 추가해, 예외 상황에서 환자 조회를 건너뛰어도 괜찮음을 모델이 알도록 했습니다.

프롬프트 작성은 본질적으로 반복적(iterative)인 과정이며, 대부분 프롬프트는 여러 이해관계자에 의해 끊임없이 업데이트되는 살아있는 문서(living documents)입니다. 그렇기 때문에 부실하게 작성된 지시를 철저히 검토하는 것이 더욱 중요합니다.

실제로 초기 사용자 중 다수가 프롬프트 라이브러리를 검토하는 과정에서 애매모호하거나 모순된 지시를 발견했고, 이를 제거함으로써 GPT-5의 성능이 크게 개선되고 작업 흐름이 간소화되었습니다.

최소한의 추론

GPT-5에서는 처음으로 최소 추론 강도(minimal reasoning effort)를 도입했습니다. 이는 추론 모델 패러다임의 장점을 유지하면서도 가장 빠른 옵션으로 지연(latency)에 민감한 사용자나 기존 GPT-4.1 사용자에게 가장 적합한 업그레이드라고 할 수 있습니다.

이때 최적의 결과를 위해서는 GPT-4.1에서와 유사한 프롬프트 패턴을 권장합니다. 최소 추론에서는 높은 추론 단계보다 프롬프트에 따라 성능 변동이 훨씬 크기 때문에, 다음과 같은 핵심 포인트를 강조하는 것이 중요합니다.

최종 답변 시작 부분에서 모델이 자신의 사고 과정을 요약하는 간단한 설명(예: 글머리표 목록 형태)을 제시하도록 유도하면, 높은 지능이 요구되는 과제에서 성능이 향상됩니다.
과제 진행 상황을 꾸준히 사용자에게 업데이트하도록, 철저한 설명 중심의 도구 서론(tool-calling preamble)을 요청하면, 에이전트형 워크플로우에서 성능이 개선됩니다.
도구 지시사항을 가능한 명확하게(disambiguation) 하고, 앞서 설명한 에이전트형 지속성(agentic persistence) 리마인더를 삽입하는 것은 최소 추론 환경에서 특히 중요합니다. 이는 장기 실행 과정에서 에이전트 능력을 최대화하고 조기 종료를 방지합니다.
모델이 내부적으로 사용할 수 있는 추론 토큰이 적기 때문에, 프롬프트 기반 계획(prompted planning)이 더욱 중요해집니다.

아래는 저희가 에이전트형 과제의 시작 부분에 배치한 샘플 계획 프롬프트입니다. 특히 두 번째 단락은 에이전트가 사용자에게 제어를 반환하기 전에 과제와 모든 하위 과제를 완전히 수행하도록 보장합니다.

당신은 에이전트(agent)임을 명심하십시오 - 사용자의 질의가 완전히 해결될 때까지 계속 진행한 뒤에만 차례를 끝내고 사용자에게 제어를 반환하십시오. 사용자의 질의를 필요한 모든 하위 요청(sub-request)으로 분해하고, 각각이 완료되었는지 확인하십시오. 요청의 일부만 완료한 상태에서 멈추지 마십시오. 문제가 해결되었음을 확신할 때에만 차례를 종료하십시오. 여러 개의 질의에 응답할 준비가 되어 있어야 하며, 사용자가 완료되었다고 확인한 뒤에만 호출(call)을 끝내십시오.
이후의 함수 호출(function call)을 수행하기 전에 작업 흐름(workflow) 단계에 따라 충분히 계획해야 하며, 각 함수 호출이 만들어낸 결과를 면밀히 되돌아보아 사용자의 질의와 관련 하위 요청들이 완전히 해결되었는지 확인해야 합니다.

마크다운(Markdown) 서식

기본적으로 GPT-5는 API에서 최종 답변을 마크다운으로 서식화하지 않습니다. 이는 마크다운 렌더링을 지원하지 않는 애플리케이션에서도 최대한의 호환성을 보장하기 위함입니다.

마크다운 형식의 최종 답변을 성공적으로 유도하려면 아래와 같은 프롬프트를 사용하면 좋습니다.

마크다운은 의미적으로 올바른 경우에만 사용하십시오. (예: 인라인 코드, 코드 블록, 목록, 표 등)
어시스턴트 메시지에서 마크다운을 사용할 때는 파일, 디렉터리, 함수, 클래스 이름을 백틱(`)으로 감싸십시오. 수학 수식은 인라인에는 \( and \), 블록 수식에는 \[ and \]을 사용하십시오.

가끔은 시스템 프롬프트에 지정된 마크다운 지침 준수가 긴 대화가 이어지는 동안 약화될 수 있습니다. 이러한 경우, 3~5개의 사용자 메시지마다 마크다운 지침을 덧붙이면 일관된 준수를 유지하는 데 도움이 된다는 것을 확인했습니다.

메타프롬프트(Metaprompting)

마지막으로 메타 차원의 내용을 덧붙이자면, 초기 테스터들은 GPT-5를 자기 자신을 위한 메타프롬프터(meta-prompter)로 활용하여 큰 성과를 거두었습니다. 이미 여러 사용자가 원하는 행동을 이끌어내지 못한 프롬프트에 대해, GPT-5에게 어떤 요소를 추가하면 원하는 행동을 더 잘 유도할 수 있는지, 또는 어떤 요소를 제거하면 원치 않는 행동을 방지할 수 있는지를 직접 묻는 방식으로 수정된 프롬프트를 배포한 사례가 있는 것입니다.

다음은 유용하다고 생각한 메타프롬프트 템플릿의 예시입니다.

프롬프트 최적화를 요청받으면, 당신의 관점에서 답하십시오 — 이 프롬프트에 어떤 특정 구절을 추가하거나 삭제해야 원하는 행동을 더 일관되게 유도하거나 원치 않는 행동을 방지할 수 있는지 설명하십시오.  

다음은 프롬프트입니다: [PROMPT]  

이 프롬프트에서 기대하는 행동은 에이전트가 [원하는 행동을 수행]하는 것입니다. 그러나 실제로는 [원치 않는 행동을 수행]하고 있습니다.  
기존 프롬프트를 최대한 유지하면서, 이러한 문제를 더 일관되게 해결하도록 유도하기 위해 최소한의 수정/추가를 한다면 어떤 것들이 있을까요?

마치며

여기까지, 오픈AI의 공식 프롬프트 가이드를 정리하면 이렇습니다.

GPT-5를 효과적으로 활용하려면 모델의 성격을 이해하고 상황에 맞는 프롬프트 설계가 중요합니다.
에이전트 워크플로우에서는 도구 사용과 작업 흐름을 자연스럽게 이어주는 지침이 도움이 됩니다.
개발 환경에서는 코드 편집 규칙을 잘 잡아두면 더 읽기 쉽고 유지보수하기 좋은 결과물을 얻을 수 있습니다.
지시 준수, 추론 강도, 마크다운, 메타프롬프트 등을 적절히 활용하면 GPT-5의 성능과 안정성을 한층 높일 수 있습니다.

점점 성능을 키워가는 AI 모델은, 또 그만큼 AI를 쓰는 사용자의 성장을 요구하고 있습니다. GPT-5에 불평하며 “아무렇게나 막 써도 알아서 잘 답해주는 AI”를 기다리기 보다 더 나은 프롬프트를 만들어 보는 것은 어떨까요? 그 사이에도 누군가는 열심히 프롬프트를 만들어 원하는 답을 더 잘 얻어갈 테니까요.

<원문>

GPT-5 prompting guide