GPT-6 사용 가이드

소개

GPT-5.6은 복잡한 프로덕션 워크플로우의 품질과 효율성 기준을 높입니다. 특히 토큰 효율이 뛰어나며, 레이아웃 구성, 시각적 위계 표현, 디자인 판단이 개선되어 프런트엔드를 더 세련되게 구현합니다.

GPT-5.6부터 모델 명명 방식도 달라집니다. gpt-5.6 별칭으로 요청을 보내면 플래그십 모델인 gpt-5.6-sol로 전달됩니다. 더 낮은 비용으로 높은 성능을 내려면 gpt-5.6-terra를, 대량의 작업을 효율적으로 처리하려면 gpt-5.6-luna를 사용하세요.

GPT-5.5 또는 GPT-5.4에서 마이그레이션할 때는 기존 모델에서 사용하던 추론 설정으로 시작하세요. 그런 다음 대표 작업에서 기존 설정과 한 단계 낮은 설정을 테스트하세요. GPT-5.6은 더 적은 토큰으로도 품질을 유지하거나 높일 수 있는 경우가 많지만, 최적의 설정은 워크로드에 따라 다릅니다.

새로운 기능

• 프로그래밍 방식의 도구 호출: GPT-5.6은 JavaScript를 작성해 호스팅된 런타임에서 이 방식을 지원하는 도구를 호출하고, 호출 간에 결과를 전달하고, 중간 출력을 처리할 수 있습니다. 작업 범위가 명확하고 도구를 많이 사용하며 단계마다 모델이 새로 판단할 필요가 없는 워크플로우에는 프로그래밍 방식의 도구 호출을 사용하세요. 이 기능은 데이터 비보관(ZDR)과 호환되며 별도의 컨테이너 비용이 들지 않습니다.
• 멀티 에이전트 [베타]: 멀티 에이전트를 사용하면 GPT-5.6 인스턴스 하나가 여러 하위 에이전트에 작업을 나누어 병렬로 진행하고 그 결과를 종합할 수 있습니다. Codex의 Ultra 모드와 마찬가지로, 서로 독립적인 단위로 나눌 수 있는 복잡한 작업에서는 실제 소요 시간을 줄이고 성능을 높일 수 있습니다. 멀티 에이전트는 Responses API에서 베타 기능으로 제공되며, 개발자 피드백을 반영해 개선하고 있습니다.
• 명시적 프롬프트 캐싱: GPT-5.6에서는 프롬프트 앞부분에서 재사용할 구간을 정확히 지정해 OpenAI가 캐싱하도록 할 수 있습니다. 암시적 모드에서는 기존처럼 자동 캐싱을 사용할 수 있습니다. OpenAI는 캐시 쓰기에 캐싱되지 않은 입력 단가의 1.25배를 청구하며, 캐시 읽기에는 계속 할인 요금을 적용합니다. 자세한 내용은 프롬프트 캐싱 설정 방법을 참고하세요.
• 추론 유지: GPT-5.6은 여러 턴에 걸쳐 사용 가능한 추론 항목을 재사용해 멀티턴 작업의 품질과 캐시 효율을 높일 수 있습니다. reasoning.context로 동작 방식을 선택하세요. 자세한 내용은 호출 간 추론 유지 방법을 참고하세요.
• Max 추론 강도: GPT-5.6은 더 폭넓은 탐색과 검증이 필요한 고난도 작업을 위해 max 추론 강도를 지원합니다. 현재 xhigh를 사용한다면 대표 워크로드에서 두 설정을 비교하세요.
• Pro 모드: GPT-5.6은 어려운 작업에 더 많은 연산을 투입해 신뢰도를 높이고 최종 답변 하나를 반환할 수 있습니다. 지연 시간과 토큰 사용량보다 품질이 중요할 때 reasoning.mode: "pro"로 활성화하세요. 자세한 내용은 Pro 모드 사용 방법을 참고하세요.
• 토큰 효율: GPT-5.6은 더 적은 출력 토큰으로 플래그십 수준의 성능을 냅니다.
• 프런트엔드 디자인: GPT-5.6은 레이아웃을 구성하고 시각적 위계를 표현하며 디자인을 결정하는 능력이 향상되어 더 완성도 높고 사용하기 편한 웹사이트와 애플리케이션을 만듭니다.
• 의도 파악: GPT-5.6은 컨텍스트를 바탕으로 사용자의 실제 목표와 어느 정도까지 작업해 주길 원하는지 더 정확하게 파악하므로, 모든 단계를 일일이 지정할 필요가 없는 경우가 많습니다. 도메인 컨텍스트, 반드시 지켜야 할 제약 조건, 승인이 필요한 범위, 성공 기준은 계속 제공하세요. 중요한 사항이 모호할 때 어떤 경우에 질문해야 하는지도 알려 주세요.
• 원본 이미지 세부 수준: GPT-5.6은 이미지 세부 수준이 original 또는 auto이면 원본 이미지 크기를 유지합니다. 단, 가로나 세로가 65,535픽셀을 넘으면 해당 한도에 맞춰 축소합니다. 이미지가 여전히 패치 30,000개 한도를 초과하면 API는 이미지를 더 축소하지 않고 거부합니다. 큰 이미지는 입력 토큰을 더 많이 사용하고 지연 시간을 늘릴 수 있습니다. 자세한 내용은 이미지 세부 수준 선택 방법을 참고하세요.

안전장치

GPT-5.6 모델이 출력을 생성하는 동안 분류기가 사이버 및 생물학 분야의 악용 가능성을 실시간으로 평가합니다. 이에 따라 안전장치가 일부 요청을 차단하거나 모델이 응답을 거부할 수 있습니다. 다른 요청에서는 분류기가 출력을 동기식으로 검토하는 동안 스트림 중간에 생성이 몇 초간 멈춰 응답에 더 오래 걸릴 수 있습니다. 특히 초기 단계에서 방어 활동과 공격 활동이 비슷해 보일 수 있는 이중 용도 분야에서는 안전장치가 간혹 정당한 작업에도 개입할 수 있습니다.

애플리케이션이 개별 최종 사용자에게 서비스를 제공한다면 요청마다 사용자별로 일관된 값을 유지하면서 개인정보를 보호하는 safety_identifier를 보내세요. 구현 방법은 안전 식별자 구현을 참고하세요.

OpenAI는 안전장치가 우회 시도에도 견고하고 효과적으로 작동하도록 지속적으로 개선하고 있습니다. 이와 함께 코드 검토, 취약점 연구, 패치 개발, 디버깅, 보안 교육, 방어 목적의 테스트 등 정당한 작업에는 계속 모델을 사용할 수 있도록 하고 있습니다.

마이그레이션 빠른 시작

Codex로 마이그레이션하기

Codex는 OpenAI Docs 스킬을 사용해 이 가이드에서 권장하는 변경 사항을 적용할 수 있습니다.

$openai-docs 이 프로젝트를 GPT-5.6 모델 제품군으로 마이그레이션하세요.

다른 코딩 에이전트에서 이 스킬을 사용하려면 OpenAI 스킬 리포지터리에서 다운로드하세요.

API 및 모델 매개변수 업데이트하기

• 워크로드에 맞는 모델을 선택하세요. 플래그십 성능이 필요하면 gpt-5.6-sol을, 성능과 비용의 균형이 중요하면 gpt-5.6-terra를, 대량의 작업을 효율적으로 처리하려면 gpt-5.6-luna를 사용하세요. gpt-5.6 별칭으로 보낸 요청은 gpt-5.6-sol로 전달됩니다.
• 추론, 도구 호출, 멀티턴 워크플로우에는 Responses API를 사용하세요.
• 작업 목적에 맞게 reasoning.effort를 설정하세요. GPT-5.6은 none, low, medium, high, xhigh, max를 지원합니다.
  • GPT-5.5 또는 GPT-5.4에서 마이그레이션한다면 현재 추론 강도를 기준으로 삼고 한 단계 낮은 설정과 비교하세요.
  • none을 사용 중이라면 지연 시간 비교의 기준으로 유지하세요. 추론이나 도구 사용이 도움이 되는 워크플로우에서는 low도 테스트하세요.
  • 성능과 지연 시간의 균형을 고려한 시작점으로는 medium을, 지연 시간에 민감한 워크로드에는 low를 사용하세요.
  • 추론을 늘렸을 때 측정 결과에서 품질 향상이 확인되면 high 또는 xhigh를 사용하세요.
  • max는 품질이 최우선인 작업 중에서도 가장 어려운 작업에 사용하세요. max와 xhigh를 비교해 사용 사례에 가장 적합한 품질, 지연 시간, 비용의 균형점을 찾으세요.
• Pro 모드를 사용하려면 선택한 GPT-5.6 모델을 그대로 두고 Responses API에서 reasoning.mode를 pro로 설정하세요. 별도의 Pro 모델 슬러그로 전환하지 마세요. reasoning.effort는 독립적으로 선택하세요. 생략하면 GPT-5.6은 표준 모드와 Pro 모드 모두에서 기본값인 medium을 사용합니다. 요청 예시와 요금 정보는 추론 모드를 참고하세요.
• 이전 추론이 현재 작업에 얼마나 관련 있는지에 따라 추론 유지 방식을 설정하세요. GPT-5.6 모델의 기본값은 all_turns이고 이전 모델의 기본값은 current_turn입니다.
  • reasoning.context를 생략하거나 auto로 설정하면 GPT-5.6의 기본값인 all_turns를 사용합니다. 실제로 적용된 모드는 응답의 reasoning.context 필드에서 확인하세요.
  • 여러 턴에 걸쳐 작업 목표, 가정, 우선순위가 유지된다면 reasoning.context를 all_turns로 설정하세요.
  • all_turns를 사용할 때는 previous_response_id로 다음 요청을 이어 가세요. 그러면 모델이 이전 응답의 추론을 활용할 수 있습니다.
  • 대화 기록을 직접 관리한다면 이전 사용자 입력과 모든 응답 출력 항목을 보존하고 다시 보내세요. store: false 또는 데이터 비보관을 사용하는 경우에는 API가 기본적으로 반환하는 암호화된 추론 항목을 다시 보내세요.
  • 이전 추론이 더 이상 관련 없으면 reasoning.context를 current_turn으로 설정하세요.
• 프롬프트 캐싱 설정을 검토하세요. 암시적 캐싱은 코드 변경 없이 계속 사용할 수 있습니다. GPT-5.6의 캐시 쓰기 단가는 캐싱되지 않은 입력 단가의 1.25배이므로 cached_tokens와 cache_write_tokens를 추적해 실제 비용을 파악하세요. 명시적 중단점 또는 prompt_cache_options.mode: "explicit" 설정을 사용해 불필요한 쓰기를 방지하고, prompt_cache_retention을 prompt_cache_options.ttl로 교체하세요.
• 프로그래밍 방식의 도구 호출을 사용하려면 programmatic_tool_calling 도구를 추가하고, 이 방식을 지원하는 도구별로 allowed_callers를 설정해 호출을 허용하세요. 애플리케이션이 program 항목, 프로그램이 요청하는 함수 호출, program_output 항목을 처리하면서 각 호출의 call_id와 caller의 연결 관계를 유지하도록 업데이트하세요. 요청 예시와 후속 호출 예시는 프로그래밍 방식의 도구 호출 가이드를 참고하세요.
  • 대표 작업으로 PTC를 활성화한 워크플로우를 벤치마크하세요. 작업 성공 여부, 최종 답변의 완전성, 필수 근거, 총 토큰 수, 지연 시간, 비용을 비교하세요. 호출, 턴 또는 중간 출력이 줄었더라도 최종 답변이 요구 품질을 충족할 때만 개선으로 판단하세요.

프롬프트 작성 권장 사항

프롬프트 간결하게 작성하기

반복되는 지침과 예시를 제거하고 도구 설명을 간소화하면 작업 성능과 토큰 효율이 향상될 수 있습니다. 일부 내부 코딩 에이전트 평가에서 더 간결한 시스템 프롬프트를 사용한 구성은 평가 점수가 약 10–15% 높아졌고, 총 토큰 수는 41–66%, 비용은 33–67% 줄었습니다. 결과는 워크로드에 따라 달라지므로 이 수치는 개선 추세를 파악하는 참고 자료로 삼고, 실제 애플리케이션의 대표 작업으로 변경 효과를 검증하세요.

중요한 지침을 유지하면서 프롬프트를 간소화하려면 다음과 같이 하세요.

• 이미 잘 작동하는 프롬프트와 도구 구성에서 시작하세요. 지침, 예시, 도구를 한 번에 한 그룹씩 제거하고 같은 평가를 다시 실행하세요.
• 각 지침은 한 번만 작성하세요.
• 작업에 필요한 도구만 제공하고, 각 도구의 설명은 간결하고 정확하게 작성하세요.
• 제품 요구 사항을 담고 있거나 평가에서 확인된 부족한 점을 보완하는 예시와 스타일 지침은 유지하세요.
• 실행을 시작할 때뿐 아니라 대화가 길어지는 동안에도 컨텍스트를 추적하세요. 세션이 길어질수록 반복되는 프롬프트와 도구 설명의 영향이 커질 수 있습니다.

자율적으로 수행할 작업과 승인이 필요한 작업 구분하기

GPT-5.6은 여러 단계로 이루어진 작업을 주도적으로 수행하고 꾸준히 이어 갈 수 있습니다. 요청별로 어디까지 실행할 권한이 있는지 명시하세요. 그러면 모델은 범위 안의 안전한 작업을 불필요하게 멈추지 않고 계속하되, 외부 시스템에 영향을 주거나 파괴적이거나 비용이 많이 들거나 범위를 넓히는 작업을 실행하기 전에 멈출 수 있습니다.

보통은 간결한 정책으로 충분합니다.

사용자가 답변, 설명, 검토, 진단 또는 계획 수립을 요청하면 관련 자료를 살펴보고 결과를 보고하세요.
사용자가 변경 사항을 적용해 달라고 함께 요청한 경우에만 실제로 변경하세요.

사용자가 변경, 구현 또는 수정을 요청하면 먼저 확인을 구할 필요 없이 요청 범위 내에서 로컬 변경을 적용하고
관련된 비파괴적 검증을 실행하세요.

외부 시스템에 데이터를 쓰거나, 파괴적인 작업을 수행하거나, 구매하거나, 작업 범위를 실질적으로 확대하기 전에는
반드시 사용자의 확인을 받으세요. 구매 금액이 적어도 확인이 필요합니다.

파일 읽기, 로그 확인, 작업 범위 내 코드 편집, 테스트 실행처럼 안전한 로컬 작업을 구체적으로 명시하세요. 정책은 한곳에 모으고 각 규칙은 한 번만 작성하세요. “먼저 물어보세요”, “변경하지 마세요”, “승인을 기다리세요” 같은 지침을 반복하면 모델이 당연히 수행해야 할 안전한 작업에도 불필요하게 승인을 요청할 수 있습니다.

응답 길이와 스타일 설정하기

GPT-5.6은 기본적으로 GPT-5.5보다 간결하게 답하는 경향이 있습니다. 마이그레이션할 때는 “간결하게 답하세요” 또는 “짧게 작성하세요”처럼 전반적인 길이를 제한하는 지침이 여전히 유용한지 확인하세요. 작업에 따라 이런 지침이 필요 없을 수도 있고, 때로는 답변이 지나치게 짧아질 수도 있습니다. 애플리케이션에 필요한 출력을 일관되게 얻는 데 도움이 된다면 유지하세요.

여러 요청에서 응답 길이를 일관되게 제어하려면 text.verbosity로 기본 상세 수준을 설정하고, 작업별 요구 사항은 프롬프트에 작성하세요.

text.verbosity로 기본값 설정하기

요청의 기본 상세 수준으로 low, medium, high 중 하나를 선택하세요. 작업에 필요한 길이, 구조, 필수 내용은 프롬프트에 명시하세요. API 예시는 text.verbosity 설정하기를 참고하세요.

짧은 답변에 반드시 포함할 내용 지정하기

짧은 답변이 필요한 작업에서는 모델이 반드시 유지해야 하는 정보와 생략해도 되는 세부 사항을 구분해 주세요. 예를 들면 다음과 같습니다.

결론부터 제시하세요. 결론을 뒷받침하는 데 필요한 근거, 중요한 유의 사항, 다음에 취할 조치를 포함하세요.
부차적인 세부 사항과 반복되는 내용은 생략하세요.

필수 사실, 결정 사항, 유의 사항, 다음 단계는 모두 유지하세요. 분량을 줄일 때는 서론, 반복되는 내용,
막연히 안심시키는 말, 생략해도 되는 배경 설명부터 덜어 내세요.

이렇게 하면 모델이 작업을 완료하는 데 필요한 내용을 먼저 보존한 뒤 중요도가 낮은 세부 사항을 덜어 내도록 우선순위를 명확히 정할 수 있습니다.

어조 정하기

“친근하게” 또는 “공감하는 어조로”처럼 포괄적인 표현은 모호할 수 있습니다. 답을 얼마나 직접적으로 제시할지, 언제 사용자가 겪는 문제를 먼저 언급할지, 안심시키는 말이나 맺음말이 적절한지 등 제품의 어조를 결정하는 구체적인 작성 방식을 설명하세요.

답을 직접적으로 제시하세요. 사용자가 문제를 알리면 어떤 문제를 겪었는지 구체적으로 짚은 뒤 다음 단계를 안내하세요.
안심시키는 말은 상황에 맞을 때만 사용하세요. 상투적인 칭찬과 불필요한 맺음말은 생략하세요.

Pro 모드

품질이 가장 중요할 때 Pro 모드 선택하기

Pro 모드는 하나의 요청에 더 많은 모델 연산을 투입한 뒤 최종 답변 하나를 반환하는 Responses API 실행 모드입니다. 어려운 작업의 신뢰도를 높일 수 있지만 지연 시간이 늘어나며, 추가 연산에 사용한 토큰도 사용량에 합산됩니다. 해당 토큰에는 선택한 모델의 표준 토큰 요금이 적용됩니다.

조금만 품질이 높아져도 결과에 실질적인 차이가 생기고, 추가 연산이 도움이 될 만큼 어려운 작업에 Pro 모드를 사용하세요. 예를 들어 복잡한 최적화, 결과의 가치가 큰 코딩이나 검토, 평가 기준이 명확한 심층 분석이 여기에 해당합니다. 일상적인 작업, 지연 시간에 민감한 작업, 대량으로 처리하는 작업에는 표준 모드를 우선 사용하세요. 평가에서 Pro 모드의 효과가 뚜렷하지 않은 경우에도 표준 모드가 적합합니다.

추론 모드와 추론 강도는 독립적인 설정입니다. Pro 모드는 모든 GPT-5.6 모델에서 사용할 수 있으며, 각 모델이 지원하는 모든 추론 강도와 함께 사용할 수 있습니다. 우선 표준 모드에서 기준으로 삼은 모델과 추론 강도를 그대로 사용하세요. 가장 높은 강도가 항상 최선이라고 가정하지 말고 대표 작업에서 여러 구성을 비교하세요.

API에서 Pro 모드 설정하기

API 요청에서 Pro 모드를 활성화하세요. 프롬프트는 표준 모드에서 사용하던 것처럼 원하는 결과를 중심으로 작성하세요. 목표, 관련 컨텍스트, 제약 조건, 필수 근거, 성공 기준, 출력 형식을 명시하세요. 모델에 “Pro 모드를 사용하세요”, “더 깊이 생각하세요”라고 지시하거나 여러 후보 답변을 생성하라고 요청할 필요는 없습니다.

예를 들면 다음과 같습니다.

이 데이터베이스 마이그레이션 계획을 검토해 어떤 문제가 데이터 손실이나 장시간의 서비스 중단으로 이어질 수 있는지 찾으세요.
문제마다 계획에서 해당 단계를 인용하고, 영향과 발생 가능성을 추정한 뒤 구체적인 완화 방안을 제안하세요.
가장 중요한 위험 다섯 가지를 심각도가 높은 순서대로 제시하세요.

품질과 비용 비교하기

동일한 대표 작업에서 표준 모드와 Pro 모드를 비교하세요. 작업 성공 여부, 답변의 완전성, 필수 근거, 총 토큰 수, 지연 시간, 비용을 측정하세요. 추가 연산을 투입할 만큼 품질이나 신뢰도가 향상되는 작업에 선별적으로 Pro 모드를 사용하세요.

자세한 내용은 추론 모드 가이드를 참고하세요.

프로그래밍 방식의 도구 호출

작업 특성에 따라 프로그래밍 방식의 도구 호출 선택하기

프로그래밍 방식의 도구 호출(PTC)은 작업 범위가 명확하고 코드로 여러 도구의 결과나 대량의 중간 출력을 처리해 훨씬 작은 구조화된 결과를 반환할 수 있는 워크플로우에 가장 적합합니다. 필터링, 조인, 순위 지정, 중복 제거, 집계, 검증 등 처리 절차를 예측할 수 있는 작업에 사용하세요.

호출이 여러 번 필요하거나, 병렬로 실행되거나, 호출 간 종속성이 있다는 이유만으로 프로그래밍 방식의 도구 호출을 선택할 필요는 없습니다. 다음과 같은 경우에는 PTC를 사용하지 않고 도구를 직접 호출하는 편이 좋습니다.

• 한 번의 호출로 충분한 경우
• 중간 출력이 이미 작은 경우
• 각 결과에 따라 모델의 다음 판단이 달라질 수 있는 경우
• 작업에 승인이 필요한 경우
• 최종 출력에 인용 정보나 원래 형식의 산출물을 보존해야 하는 경우

작업별로 호출 방식 지정하기

모델이 적절한 호출 방식을 선택하도록 하려면 도구를 제공하거나 “프로그래밍 방식의 도구 호출을 효율적으로 사용하세요” 같은 일반적인 지침을 주는 것만으로는 부족합니다. 직접 호출과 프로그래밍 방식의 호출을 모두 사용할 수 있다면 다음 사항을 명시하세요.

• 범위가 정해진 단계 중 프로그래밍 방식의 도구 호출을 사용할 단계
• 해당 단계에서 호출할 수 있는 도구
• 정확한 출력 스키마와 반드시 포함해야 하는 근거
• 동시 실행 한도, 재시도 한도, 중단 기준
• 계속 직접 호출로 처리할 작업

도구 설명에는 예상 반환 필드와 타입, 오류 발생 시 동작을 명시하세요. 모델이 프로그램을 작성하기 전에 반환 구조를 파악할 수 없다면 직접 호출을 우선 사용하세요. 그러면 모델이 결과를 확인한 뒤 활용 방법을 결정할 수 있습니다.

두 방식이 모두 필요하다면 한 방식에서 다른 방식으로 넘기는 지점을 하나만 명확하게 정하세요. 그 밖의 지점에서 방식을 바꾸거나 이미 완료한 작업을 반복하지 않도록 모델에 지시하세요.

예를 들면 다음과 같습니다.

<tool_orchestration>
[bounded stage]에서는 프로그래밍 방식의 도구 호출을 사용하고, [eligible tools]에 지정된 도구만 호출하세요.
서로 독립적인 호출은 안전한 경우 동시에 실행하세요. 도구의 입력과 출력에는 문서에 명시된 필드만 사용하세요.

중간 결과를 처리해 필요한 내용만 남긴 뒤, [output schema]에 정확히 맞춰 출력하세요.
최종 답변에 필요한 근거를 포함하세요.

[condition]을 충족하면 중단하세요. 일시적인 실패에 한해 최대 [R]회까지 재시도하세요.
이미 완료한 호출을 반복하거나 사이드 이펙트가 있는 작업을 수행하지 마세요.
필수 결과가 여전히 누락되어 있으면 실패했음을 명확히 나타내는 구조화된 결과를 반환하세요.

[semantic judgment, approval, or final validation]에는 도구를 직접 호출하세요.
</tool_orchestration>

최종 답변 평가하기

program_output 항목과 어시스턴트의 최종 message는 별개의 출력이므로 둘 다 테스트하세요. 프로그램이 올바른 레코드를 반환하더라도 메시지에서 필수 필드, 인용 정보 또는 유의 사항이 빠질 수 있습니다.

동일한 대표 작업에서 직접 호출과 프로그래밍 방식의 호출을 비교하세요. 먼저 최종 응답이 정확하고 완전하며 필요한 근거를 포함하는지 확인하세요. 그런 다음 총 토큰 수, 지연 시간, 비용, 호출 횟수, 턴 수, 재시도 횟수를 비교하세요. 리소스 사용량이 줄어도 응답이 기존 평가를 계속 통과하는 경우에만 개선으로 판단하세요.

자세한 내용은 프로그래밍 방식의 도구 호출 가이드를 참고하세요.