OPENAI API · GPT-5.6 SOL · LEARNING DOSSIER
프롬프트를 더 길게 만드는 법이 아니라, 결과·제약·증거·완료 기준만 남기고 모델이 효율적인 경로를 고르게 하는 법.
01 · 학습 가이드
학습 가이드 · 핵심 질문
프롬프트는 세세한 작업 순서가 아니라 결과, 성공 기준, 제약, 증거, 멈출 조건을 담는 계약이다. GPT-5.6에는 그 계약 안에서 경로를 고를 여지를 주고, 변경 효과는 같은 대표 평가로 확인한다.
02 · Executive Summary
핵심 요약
이 지침은 GPT-5.6 Sol 및 GPT-5.6 계열로 프롬프트, 도구 설명, 에이전트 지침, 프롬프트 스택을 옮길 때 적용한다. API 세부 기능, 한도, 가격, 제공 기능은 현재의 GPT-5.6 모델 가이드와 함께 확인해야 한다.
이미 작동하는 프롬프트와 도구 집합에서 출발해 지침·예시·도구 묶음을 한 번에 하나씩 제거하고 같은 평가를 다시 돌린다. 같은 규칙의 반복, 행동을 바꾸지 않는 스타일·절차 지시와 예시, 모델이 이미 안정적으로 수행하는 절차, 작업과 무관한 도구 및 설명이 우선 삭제 대상이다.
반드시 보존할 것은 사용자에게 보이는 결과, 성공 기준과 중단 조건, 안전·사업·증거·권한 제약, 문맥에 따라 달라지는 도구 라우팅, 필수 출력 형식과 검증 요건이다. GPT-5 계열은 계약을 세밀하게 따르므로 남은 지침의 모순은 세부 설명 부족보다 더 큰 불안정을 만들 수 있다.
GPT-5.6은 좋은 결과의 조건이 분명하면 검색·도구·추론 경로를 대체로 스스로 고를 수 있다. 예컨대 고객 문제 해결에서는 정책·계정 증거로 자격을 판단하고, 허용된 조치를 응답 전에 끝내며, 완료 조치·고객 메시지·차단 요인을 정해진 필드로 반환하고, 증거가 부족하면 가장 작은 누락 필드만 요청하도록 성공 조건을 적는다.
항상·절대·반드시·오직 같은 절대어는 안전, 필수 필드, 금지 행동처럼 실제 불변인 규칙에만 쓴다. 검색·질문·도구 사용·반복처럼 판단이 필요한 일은 결정 규칙으로 표현한다. 사용자가 명시한 값은 그대로 보존하고, 암묵적 값은 문맥이나 스키마에서 판단할 기준을 주며, 보편 기본값·키워드 매핑·광범위한 의미 지름길은 피한다.
최소한의 유용한 도구 반복을 지향하되 정확성, 필수 증거, 계산, 인용보다 반복 축소를 우선하지 않는다. 매 결과 뒤 핵심 요청에 답할 증거가 충분한지 확인하고, 부족하면 누락 사실을 이름 붙인 뒤 가장 작은 유효 대안을 사용한다.
GPT-5.6은 GPT-5.5보다 기본 응답이 더 짧은 경향이 있어 “간결하게” 같은 포괄 지시는 불필요하거나 지나친 축약을 낳을 수 있다. 필요한 출력이 반복해서 좋아질 때만 유지한다. 요청의 기본 상세도는 text.verbosity 설정 안내에 따라 low·medium·high로 정하고, 작업별 길이·구조·필수 내용은 프롬프트에 별도로 둔다.
성격은 어조, 온기, 직접성, 격식, 유머, 공감, 다듬기 수준을 결정하고, 협업 방식은 질문·가정·주도성·절충 설명·검토·불확실성 처리를 결정한다. 둘 다 짧게 쓰되 목표, 성공 기준, 도구 규칙, 중단 조건을 대신하게 해서는 안 된다.
짧은 답을 원하면 결론·근거·중대한 단서·다음 행동과 필수 사실·결정은 남기고, 도입·반복·상투적 안심·선택적 배경부터 덜어낸다. “친절하게” 같은 추상 라벨 대신 답을 얼마나 직접 말할지, 문제를 언제 인정할지, 안심이나 맺음말이 필요한지를 행동으로 정의한다. 사용자가 문제를 보고하면 다음 단계에 앞서 그 문제를 구체적으로 인정하고, 안심은 관련 있을 때만 쓰며, 상투적 칭찬과 불필요한 맺음말은 생략한다. 언어도 실제 제품 불변 조건이 아니라면 일괄 규칙 대신 기본 출력 언어와 변경 조건을 적는다. 편집·재작성·요약·고객 초안에서는 산출물, 길이, 구조, 장르, 사실 주장을 우선 보존하고, 요청 없이는 새 주장·섹션·홍보조를 보태지 않는다.
GPT-5.6의 주도성과 지속성을 활용하려면 요청이 허용하는 행동 수준을 구분해야 한다. 답변·설명·검토·진단·계획 요청은 자료를 조사해 보고하되 구현으로 넘어가지 않는다. 변경·구축·수정 요청은 범위 안의 로컬 변경과 비파괴 검증을 별도 승인 없이 수행한다. 외부 쓰기, 파괴적 조치, 구매, 실질적인 범위 확대에는 확인을 요구한다.
파일 읽기, 로그 확인, 범위 내 코드 편집, 테스트처럼 안전한 로컬 행동을 명시하고 정책은 한곳에서 각 규칙을 한 번만 말한다. 승인 문구를 되풀이하면 정상적인 안전 작업에도 불필요한 확인이 늘 수 있다. 장기 작업에서는 조사·설계·구현·검토·외부 조율 중 현재 작업 층을 밝혀 모델이 몰래 다음 층으로 넘어가지 않게 한다.
작업 관련 도구만 노출하고 각 설명에는 기능, 사용 시점, 중요한 반환 필드, 오류 동작을 넣는다. 정확성에 선행 조회·검색·검증이 필요하면 최종 상태가 명백해 보여도 생략하지 말라고 명시한다.
서로 독립적인 읽기는 병렬화하고, 앞 결과가 다음 행동을 결정하면 순차 실행하며, 병렬 조회 뒤에는 행동 전에 종합한다. 결과가 비었거나 일부뿐이거나 지나치게 좁으면 “없음”으로 결론 내리기 전 의미 있는 대안을 1–2회 시도한다.
Programmatic Tool Calling(PTC)은 코드가 여러 도구 결과나 큰 중간 산출물을 처리해 훨씬 작은 구조로 반환하는 제한된 워크플로에 적합하다. 필터·조인·정렬·순위화·중복 제거·집계, 유사 레코드의 대량 배치, 반복적 결정론 검증, 큰 구조 결과의 소형 스키마 축약이 대표 사례다. 호출이 많거나 병렬·의존적이라는 이유만으로는 충분하지 않다.
한 번의 호출이면 되거나 중간 결과가 작을 때, 각 결과가 다음 결정을 바꿀 때, 승인이 필요할 때, 인용·원본 산출물을 보존해야 할 때, 호출 사이 의미 판단이 필요할 때는 직접 호출을 택한다. PTC 지침에는 적용 단계, 허용 도구, 출력 스키마, 재시도 한도, 중단 조건, 직접 판단으로의 인계를 구체화한다. 예시 정책은 문서화된 읽기 전용 도구만 써서 필터·중복 제거 후 증거 필드가 있는 소형 스키마를 내고, 일시 오류를 최대 2회 재시도하며, 승인·의미 판단·인용·최종 검증은 직접 호출로 돌리는 것이다.
두 경로를 함께 쓰면 인계 지점을 하나로 고정하고 경로 전환이나 완료 작업 반복을 금한다. program_output과 최종 응답의 message는 별도 출력이므로 둘 다 시험해야 한다. 같은 대표 과제로 직접 호출과 PTC의 정확성·완전성·증거 보존을 먼저 비교한 뒤 토큰, 지연, 비용, 호출, 턴, 재시도를 비교하며, 기존 평가를 통과할 때만 자원 절감을 개선으로 인정한다.
근거 기반 답변은 무엇을 뒷받침해야 하는지, 충분한 증거의 기준, 증거가 없을 때의 행동까지 정의한다. 증거 부재를 곧바로 사실상의 “아니오”로 바꾸면 안 된다. 일반 질의는 짧고 식별력 있는 키워드로 넓게 한 번 검색하고, 핵심을 뒷받침하면 답한다. 필수 사실·담당자·날짜·ID·출처가 빠졌거나, 전수 조사·비교를 요청받았거나, 특정 산출물을 읽어야 하거나, 중요한 주장이 근거 없이 남을 때만 추가 조회한다. 표현 개선·예시 추가·비핵심 세부 보강만을 위해 다시 검색하지 않는다.
연구·종합에서는 실제로 조회한 출처만 인용하고, 인용을 해당 주장에 붙이며, 추론과 직접 근거를 구분하고, 출처 충돌을 드러낸다. 증거가 부족하면 추측 대신 범위를 좁히거나 누락을 보고한다. 창작 초안에서도 출처 기반 사실과 창의적 문구를 분리하고, 더 그럴듯하게 보이게 하려고 이름·지표·날짜·로드맵 상태·고객 성과·제품 기능을 만들지 않는다.
다단계·도구 중심 작업은 첫 호출 전 1–2문장의 사용자용 예고를 보내고, 큰 단계가 바뀌거나 발견이 계획을 바꿀 때만 결과 중심 업데이트를 한다. 각 업데이트는 구체적 성과 하나와 다음 단계를 담고, 일상적인 호출을 중계하지 않는다.
대화 기록을 재생할 때 모델 응답의 phase 값을 유지해야 commentary와 최종 답을 구분할 수 있다. previous_response_id를 쓰면 이전 상태가 자동 보존되지만, 수동 재생 시에는 원래 phase 값을 그대로 둔다. 압축은 매 턴이 아니라 큰 이정표 뒤에 하고, 압축 후에도 프롬프트의 기능을 유지하며 압축 항목은 불투명 상태로 취급한다.
지속된 추론은 목표·가정·우선순위가 여러 턴에 걸쳐 안정적일 때만 유용하다. 이전 추론이 낡았으면 현재 턴의 판단을 쓰며, 지속 추론을 상시 최적화로 취급하지 않는다. 오래된 추론은 토큰과 지연을 늘리고 낡은 경로에 고정시킬 수 있다. 프롬프트 캐시를 위해 재사용 접두부를 안정적으로 유지하고 큰 시스템 프롬프트를 불필요하게 흔들지 않으며, 명시적 캐시 경계는 실제 캐시 동작과 비용을 개선한다고 측정될 때만 둔다.
기존 GPT-5.5 또는 GPT-5.4의 추론 강도를 기준선으로 보존하고, 대표 과제에서 같은 설정과 한 단계 낮은 설정을 시험한다. low는 품질을 유지하는 지연 민감 작업에, medium은 균형 잡힌 시작점에 적합하다. high나 xhigh는 평가가 의미 있는 이득을 보일 때만, max는 가장 어려운 품질 우선 작업에만 쓰며 전역 권장값으로 삼지 않는다.
강도를 높이기 전 프롬프트에 성공 기준, 의존성 규칙, 도구 라우팅, 검증 반복이 빠졌는지 먼저 확인한다.
GPT-5.6은 레이아웃, 시각 위계, 디자인 판단이 강화됐지만 제품 맥락, 기존 디자인 시스템, 중요한 상태와 제약은 여전히 제공해야 한다. 점진적 프런트엔드 변경에서는 기존 토큰·컴포넌트·패턴과 반응형 동작·예상 상태를 보존하고, 요청하지 않은 기능이나 장식은 추가하지 않으며, 완료 전 실제 렌더를 검사한다.
비전·컴퓨터 사용·현지화·OCR처럼 공간 정확도가 중요한 일은 이미지 상세도를 의도적으로 선택한다. 크고 조밀하거나 좌표에 민감한 이미지는 추가 입력 비용과 지연이 정당화될 때 원본 상세도를 사용한다.
모델이 산출물을 검사할 도구를 쓸 수 있게 하고 어떤 검증이 중요한지 명시한다. 코드는 변경 동작의 표적 테스트, 해당 시 타입·린트 검사, 영향 패키지 빌드, 전체 검증이 비싸면 최소 스모크 테스트를 실행한다. 실행할 수 없으면 이유와 차선 검증을 설명한다.
시각 산출물은 렌더한 뒤 레이아웃, 잘림, 간격, 누락, 시각 일관성을 확인하고 요구와 맞을 때까지 고친다. 구현 계획에는 요구사항, 이름이 지정된 리소스·파일, 상태 전이 또는 데이터 흐름, 검증, 실패 동작, 개인정보·보안 고려, 구현에 실질적으로 영향을 주는 미결 질문을 포함한다.
Role: 모델의 기능과 맥락Personality: 어조와 협업 방식Goal: 사용자에게 보일 결과Success criteria: 최종 응답 전에 참이어야 할 조건Constraints: 정책·안전·사업·증거·부작용 제한Tools: 사용할 때와 쓰지 않을 때Output: 섹션·길이·형식·어조Stop rules: 재시도·대안·유보·질문·중단 조건각 섹션은 짧게 유지하고, 행동을 실제로 바꾸는 세부만 추가한다.
작동하는 프롬프트 스택을 한꺼번에 다시 쓰면 변화 원인이 모델, 추론 설정, 프롬프트, 도구 집합, 런타임 중 무엇인지 분리할 수 없다. 회귀가 생기면 소수의 실제 추적 사례에서 실패 유형과 원인으로 보이는 지침·모순을 찾고, 국소적으로 수정한 뒤 같은 사례를 재실행한다.
이 글의 일관된 메시지는 “더 많이 지시하라”가 아니라 결과·불변 제약·증거·완료 기준·검증은 또렷하게 쓰고, 나머지 경로 선택은 모델에 맡긴 뒤 대표 평가로 한 번에 한 변수씩 검증하라는 것이다. 프롬프트, 도구, 추론 강도, 상태 재사용, 캐시, PTC, 시각 상세도는 모두 전역 기본값이 아니라 작업 형태와 측정 결과에 따라 선택해야 하며, 안전·승인·인용·검증 경계만은 짧고 모순 없이 유지한다.
FACT CHECK · 2026-07-16
신뢰도 B — 기술 계약은 강하게 확인되지만 성능 수치의 재현성은 제한적이다. 모델명·별칭, 추론 강도, text.verbosity, PTC, Multi-agent, 대화 상태, 지속 추론, 캐시, 이미지 상세도는 현재 OpenAI 공식 문서에서 교차 확인됐다. 반면 내부 평가의 10–15%·41–66%·33–67% 범위에는 표본·과제·기준선·산식·원자료가 공개되지 않았고, “더 간결하다”거나 “디자인 판단이 더 강하다”는 비교 성능도 공개 방법론 없이 제시된 당사자 보고다.
정합성 한줄평: API·기능 설명과 운영 권고는 공식 문서끼리 일관되지만, 내부 성과 범위와 모델 우위 표현은 독립 검증이 아니라 1차 출처의 방향성 주장으로 읽어야 한다.
아래는 먼저 검증 가능한 제품·API 및 경험적 주장을 판정하고, 이어서 진위 명제가 아닌 규범적 설계 권고를 별도 구획에서 확인한다. 규범 항목의 “✅ 사실”은 그 권고가 현재 공식 문서에 실제로 존재하고 서로 모순되지 않는다는 뜻이며, 모든 워크로드에서 우월하다는 뜻은 아니다.
✅ 사실
GPT-5.6 제품군의 이름과 별칭. 원문의 대상인 gpt-5.6-sol은 GPT-5.6 제품군의 최상위 역량 모델이며, gpt-5.6 별칭은 gpt-5.6-sol로 라우팅된다. 공식 모델 가이드는 함께 gpt-5.6-terra와 gpt-5.6-luna도 명시한다.
⚠️ 불확실
간결한 시스템 프롬프트의 내부 평가 효과. 평가 점수 약 10–15% 향상, 총 토큰 41–66% 감소, 비용 33–67% 감소는 OpenAI가 내부 코딩 에이전트 평가 표본에서 관찰했다고 공식 페이지에 보고한 값이다. 그러나 접근한 문서에는 표본 수, 과제 분포, 비교 프롬프트, 모델·추론 설정, 점수 산식, 가격 가정, 신뢰구간이나 원자료가 없다. 따라서 “OpenAI가 이렇게 보고했다”는 사실은 확인되지만 수치 범위 자체는 독립적으로 검증되거나 일반화되지 않았다.
🟡 부분사실
결과 중심 프롬프트와 계약 충실성. “결과·제약·증거·완료 기준을 주면 GPT-5.6이 효율적인 검색·도구·추론 경로를 고른다”, “GPT-5 계열은 프롬프트 계약을 세밀하게 따르므로 모순이 불안정을 키운다”는 설명은 현재 공식 프롬프팅·모델 가이드의 일관된 제품 지침이다. 다만 이 문서들은 해당 비교의 공개 실험 설계나 효과 크기를 제시하지 않으므로, 보편적으로 입증된 인과 법칙이 아니라 1차 출처의 모델 행동 관찰과 권고로 한정해야 한다.
⚠️ 불확실
GPT-5.6이 GPT-5.5보다 기본적으로 더 간결하다는 비교. 프롬프팅 가이드와 배포 체크리스트가 같은 경향을 명시해 1차 문서 간 정합성은 높다. 그러나 접근한 공식 페이지에는 길이 비교의 데이터셋, 설정, 출력 토큰 분포가 없어 독립적으로 확인할 수 없다. 따라서 “Be concise”가 때로 지나친 축약을 낳을 수 있다는 부분도 워크로드별로 재평가해야 한다.
✅ 사실
text.verbosity 값과 역할. Responses API 요청에서 응답 상세도의 기본값을 low, medium, high 중 하나로 설정할 수 있다. 공식 배포 문서는 낮은 값이 더 짧은 출력과 적은 출력 토큰을, 높은 값이 더 풍부한 설명과 구조를 유도한다고 설명하며, 작업별 필수 내용·길이·구조는 프롬프트에서 별도로 지정하라고 한다.
✅ 사실
GPT-5.6의 reasoning.effort 값. 지원 값은 none, low, medium, high, xhigh, max이며 기본값은 medium이다. 기존 GPT-5.5·GPT-5.4 설정을 기준선으로 유지하고 같은 값과 한 단계 낮은 값을 비교하며, max는 가장 어려운 품질 우선 작업에서만 평가하라는 설명도 최신 공식 문서와 일치한다.
✅ 사실
Programmatic Tool Calling(PTC)의 기능. PTC는 모델이 격리된 V8 런타임에서 JavaScript를 작성·실행해 허용된 도구를 병렬 호출하고, 조건·반복을 사용하며, 큰 중간 결과를 런타임 안에서 처리할 수 있게 한다. 애플리케이션이 programmatic_tool_calling을 추가하고 각 도구의 allowed_callers를 정해야 한다는 최신 계약도 확인된다.
✅ 사실
program_output과 최종 assistant message의 분리. 공식 모델 가이드는 두 항목이 서로 다른 출력이므로 프로그램이 올바른 레코드를 만들었더라도 최종 메시지가 필수 필드·인용·단서를 빠뜨릴 수 있다고 명시한다. 원문의 “둘 다 시험하라”는 검증 대상 구분이 정확하다.
✅ 사실
Multi-agent의 제공 상태와 범위. 원문 본문이 Multi-agent를 직접 다루지는 않지만, 연결된 GPT-5.6 모델 가이드의 기능 맥락을 별도 확인했다. Multi-agent는 모든 GPT-5.6 모델에서 제공되는 Responses API 베타 기능이며, 루트 모델이 병렬 하위 에이전트를 생성·조율하고 결과를 종합한다. 독립적이고 경계가 뚜렷한 작업에는 유리할 수 있지만 토큰 사용을 늘릴 수 있고 순차 의존·공유 가변 상태 작업에는 덜 적합하다는 단서가 공식 문서에 있다.
✅ 사실
assistant phase와 previous_response_id. phase는 중간 commentary와 최종 답변을 구분하는 assistant 메시지 필드다. 수동으로 이력을 재생하면 원래 값을 보존해야 하며, previous_response_id로 연속 응답을 만들면 앞선 응답의 상태를 연결할 수 있다. “이전 assistant 상태가 자동 보존된다”는 원문은 이 연결 방식을 전제로 정확하다.
✅ 사실
압축 항목의 불투명성. 공식 compaction 문서는 압축 항목이 핵심 이전 상태와 추론을 더 적은 토큰으로 다음 실행에 넘기지만 사람이 해석하도록 만들어진 것이 아니라고 설명한다. 원문의 “압축 항목을 불투명 상태로 취급하라”는 기술 설명은 정확하다. 다만 “큰 이정표 뒤에 압축하라”는 시점은 API 요건이 아니라 운영 권고다.
🟡 부분사실
지속 추론(persisted reasoning). reasoning.context의 auto, current_turn, all_turns와, previous_response_id 또는 완전한 이력 재생을 통해 이용 가능한 이전 추론 항목을 이어 쓰는 기능은 공식 문서로 확인된다. 오래된 추론을 제외하면 렌더된 문맥을 줄일 수 있다는 근거도 있다. 다만 “낡은 추론이 지연을 늘리고 오래된 경로에 앵커링한다”는 효과의 크기와 발생률은 공개 측정치가 없어 정성적 위험 경고로 남는다.
✅ 사실
프롬프트 캐시와 안정적인 접두부. 캐시는 동일한 프롬프트 접두부의 정확한 일치를 활용하므로 재사용 구간을 안정적으로 유지하는 것이 적중률에 중요하다. GPT-5.6은 암시적 캐시와 명시적 breakpoint를 모두 지원하고, 명시 모드에서 캐시할 접두부를 지정할 수 있다. 최신 문서는 GPT-5.6의 캐시 쓰기를 미캐시 입력 단가의 1.25배로 과금하고 읽기는 할인한다고도 명시하므로, 원문의 “측정된 비용 이득이 있을 때만 breakpoint를 쓰라”는 단서가 타당하다.
🟡 부분사실
GPT-5.6의 프런트엔드·디자인 능력 향상. 최신 모델 가이드도 GPT-5.6이 레이아웃, 시각 위계, 디자인 판단에서 더 강하다고 명시한다. 그러나 접근한 공식 페이지에는 이 비교를 독립 재현할 벤치마크, 평가자 구성, 기준 모델별 결과가 없다. 따라서 기능 방향에 관한 1차 제품 주장은 확인되지만, 일반적인 우월성은 독립 검증된 사실로 볼 수 없다.
✅ 사실
original 이미지 상세도. GPT-5.6 제품군에서 original은 픽셀 차원이나 패치 예산에 맞춰 입력 이미지를 축소하지 않으며, auto와 상세도 생략도 같은 크기 처리 방식을 쓴다. 큰 이미지는 더 많은 입력 토큰과 지연을 유발할 수 있어, 크고 조밀하거나 좌표에 민감한 작업에서 비용을 감수할 가치가 있을 때 쓰라는 원문의 조건이 공식 vision 문서와 일치한다.
✅ 사실
권고: 프롬프트를 한 번에 한 변수씩 단순화하고 평가한다. 작동하는 기준선에서 반복 규칙, 행동을 바꾸지 않는 예시·절차, 무관한 도구를 한 묶음씩 제거하고 같은 평가를 다시 실행하되, 사용자 결과·성공 기준·중단 조건·안전/사업/증거/권한 제약·문맥 의존 라우팅·출력/검증 요구는 남기라는 방법론이다. 이는 “항상 성능이 오른다”는 명제가 아니라 인과를 분리하기 위한 실험 절차이며, 공식 Evals의 대표 표본 시험 원칙과 맞는다.
✅ 사실
권고: 목적지·결정 규칙·중단 조건을 우선한다. 절차를 모두 고정하기보다 성공 상태를 쓰고, 절대어는 안전·필수 필드·금지 행동 같은 실제 불변 조건에만 사용하며, 검색·질문·반복에는 판단 기준을 준다. 사용자가 명시한 값은 보존하고 암묵적 값에는 문맥·스키마 기준을 제공하며, 정확성·증거·계산·인용보다 도구 반복 최소화를 앞세우지 말라는 내용은 공식 가이드의 규범적 지침이다.
✅ 사실
권고: 성격·협업 방식·길이·보존 규칙을 분리한다. 성격은 어조·온기·격식 등을, 협업 방식은 질문·가정·주도성·불확실성 처리 등을 정하게 하고 둘 다 짧게 유지한다. 짧은 답에서도 결론·근거·중대한 단서·다음 행동을 남기고, 추상적 “친절함” 대신 구체적 문체 행동을 쓰며, 출력 언어의 변경 조건과 편집 시 보존할 산출물·길이·구조·장르·사실 주장을 지정하라는 것은 공식 제품 설계 권고다.
✅ 사실
권고: 자율성·승인·작업 층의 경계를 한곳에 둔다. 답변·설명·검토·진단·계획은 조사와 보고에 머물고, 변경·구축·수정은 범위 내 로컬 변경과 비파괴 검증까지 허용하며, 외부 쓰기·파괴적 조치·구매·실질적 범위 확대에는 확인을 요구하는 예시 정책이다. 안전한 로컬 행동을 명시하고 중복 승인 문구를 피하며, 장기 작업에서는 조사·설계·구현·검토·외부 조율의 현재 층을 구분하라는 것도 같은 규범 묶음이다.
✅ 사실
권고: 관련 도구만 노출하고 의존성에 맞춰 호출한다. 도구 설명에 기능·사용 시점·중요 반환 필드·오류 동작을 넣고, 필수 조회·검색·검증을 선행 조건으로 명시한다. 독립 읽기는 병렬화하고 다음 행동이 앞 결과에 달리면 순차화하며, 병렬 조회 뒤에는 종합하고, 비거나 부분적인 결과에는 결론 전 의미 있는 대안을 1–2회 시도하라는 내용은 작업 라우팅 정책이지 API의 강제 동작은 아니다.
✅ 사실
권고: PTC는 “호출 수”가 아니라 축약 가능한 경계 작업에 쓴다. 필터·조인·정렬·순위·중복 제거·집계, 유사 레코드 배치, 반복적 결정론 검증, 큰 구조 결과의 축약에는 PTC를 고려한다. 한 번의 호출, 작은 중간 출력, 결과마다 다음 판단이 달라지는 작업, 승인, 인용·원본 산출물 보존, 호출 사이 의미 판단에는 직접 호출을 선호한다. 적용 단계·허용 도구·스키마·증거·재시도·중단·인계 조건을 명시하고 두 경로 사이 인계를 하나로 고정하라는 구분이 공식 PTC 문서와 일치한다.
✅ 사실
권고: 근거·인용·검색 예산과 실패 동작을 명시한다. 무엇을 뒷받침할지, 충분한 증거가 무엇인지, 증거가 없을 때 어떻게 좁히거나 유보할지를 프롬프트에 넣고 “근거 없음”을 사실상의 “아니오”로 바꾸지 않는다. 일반 질의는 넓은 검색 1회에서 시작하되 필수 사실·담당자·날짜·ID·출처 누락, 전수·비교 요청, 특정 산출물, 중요 미지원 주장에만 추가 조회한다. 실제 조회한 출처만 주장 가까이에 인용하고 추론·직접 근거·출처 충돌을 구분하며, 창작 초안에 이름·지표·날짜·로드맵·고객 성과·기능을 지어내지 말라는 규범이다.
✅ 사실
권고: 장기 작업의 업데이트·상태·추론·캐시를 선택적으로 관리한다. 첫 도구 호출 전 짧은 예고를 하고 큰 단계나 계획 변경 때만 성과와 다음 단계를 알리며, 일상 호출은 중계하지 않는다. 압축은 매 턴이 아니라 큰 이정표에 맞추고 기능적 프롬프트를 유지한다. 지속 추론은 목표·가정·우선순위가 안정적일 때만, 캐시 breakpoint는 측정된 적중·비용 이득이 있을 때만 쓰며, 추론 강도는 기존 기준선과 한 단계 낮은 값을 먼저 비교하라는 운영 원칙이다.
✅ 사실
권고: 프런트엔드와 산출물은 실제 검증 도구로 확인한다. 점진적 UI 변경에서 기존 디자인 토큰·컴포넌트·패턴·반응형 동작·상태를 보존하고 요청하지 않은 기능·장식을 추가하지 않으며 렌더 결과를 검사한다. 코드는 표적 테스트, 해당 시 타입·린트·빌드, 필요 시 최소 스모크 테스트를 실행하고, 불가능하면 이유와 차선 검사를 밝힌다. 시각 산출물은 레이아웃·잘림·간격·누락·일관성을 보며, 구현 계획에는 요구사항·리소스/파일·상태 전이/데이터 흐름·검증·실패·개인정보/보안·중대한 미결 질문을 넣으라는 품질 절차다.
✅ 사실
권고: 복잡한 프롬프트의 골격과 마이그레이션 순서. Role, Personality, Goal, Success criteria, Constraints, Tools, Output, Stop rules를 짧게 두고 행동을 바꾸는 세부만 추가한다. 마이그레이션은 모델만 바꾸고 추론 강도를 유지한 기준선 평가 → 낡은 scaffolding·반복·무관 도구 제거 → 측정된 회귀를 고치는 최소 지침 → 변경마다 재평가 순서로 진행한다. 회귀는 소수의 실제 trace에서 실패 유형과 모순을 찾아 국소 수정하고 같은 사례를 다시 돌리라는 방법론이다.
03 · 원본 (완역)
아래는 원문의 섹션 순서, 문단, 목록, 예시, 수치, 코드 식별자와 15개 링크 위치를 보존한 한국어 완역입니다. OpenAI의 공식 한국어 번역이 아닙니다.
프롬프트, 도구 설명, 에이전트 지침 또는 프롬프트 스택을 GPT-5.6 Sol이나 GPT-5.6 제품군에 맞게 조정할 때 이 가이드를 활용하세요. API 세부 정보, 한도, 가격, 기능 제공 여부는 최신 GPT-5.6 모델 가이드와 함께 확인하세요.
GPT-5.6은 프롬프트가 결과, 중요한 제약 조건, 이용 가능한 근거, 완료 기준을 정의하되 효율적인 경로는 모델이 선택할 수 있게 여지를 둘 때 가장 잘 작동합니다.
반복되는 지침과 예시를 제거하고 도구 설명을 단순화하면 작업 성능과 토큰 효율이 좋아질 수 있습니다. 내부 코딩 에이전트 평가 실행 표본에서는 더 간결한 시스템 프롬프트를 사용한 구성이 전체 토큰을 41–66%, 비용을 33–67% 줄이는 동시에 평가 점수를 약 10–15% 높였습니다. 결과는 워크로드에 따라 달라지므로, 이 범위는 방향을 보여 주는 수치로 보고 자체 애플리케이션의 대표 작업에서 변경 사항을 검증하세요.
이미 작동하는 프롬프트와 도구 모음에서 시작하세요. 지침, 예시 또는 도구를 한 번에 한 그룹씩 제거한 뒤 같은 평가를 다시 실행합니다.
줄일 항목:
유지할 항목:
남은 지침에 모순이 없는지 검토하세요. GPT-5 계열 모델은 프롬프트의 계약을 면밀하게 따르므로, 서로 충돌하는 규칙은 세부 정보가 부족한 경우보다 더 큰 불안정을 일으킬 수 있습니다.
모든 단계를 지시하기보다 도착점을 설명하세요. 좋은 결과가 어떤 모습인지 프롬프트에 명시하면 GPT-5.6은 대개 효율적인 검색, 도구 또는 추론 경로를 선택할 수 있습니다.
다음 방식을 권장합니다:
고객의 문제를 처음부터 끝까지 해결하세요.
성공의 의미:
- 이용 가능한 정책과 계정 근거를 바탕으로 자격 여부를 판단합니다.
- 답변하기 전에 허용된 조치를 모두 완료합니다.
- completed_actions, customer_message, blockers를 반환합니다.
- 필수 근거가 없다면 누락된 필드 중 가장 작은 것만 요청합니다.불필요한 절대 규칙은 피하세요. ALWAYS(항상), NEVER(절대 금지), must(반드시), only(오직)는 안전 규칙, 필수 필드, 절대로 일어나서는 안 되는 행동처럼 실제로 변하지 않는 조건에만 사용합니다. 검색할 때, 질문할 때, 도구를 사용할 때 또는 반복을 계속할 때처럼 판단이 필요한 사안에는 의사결정 규칙을 제시하는 편이 좋습니다.
사용자가 명시한 값은 그대로 유지하세요. 올바른 값이 암묵적으로 드러나는 경우에는 의사결정 기준을 제공하고 모델이 맥락이나 스키마를 근거로 판단하게 하세요. 보편적인 기본값, 키워드 대응표, 광범위한 의미상의 지름길은 피합니다.
종료 조건을 추가하세요:
유용한 도구 반복 횟수를 가능한 한 줄여 요청을 해결하되, 반복 횟수
최소화를 정확성, 필수 근거, 계산 또는 필수 인용보다 우선하지 마세요.
결과를 받을 때마다 이제 유용한 근거를 바탕으로 핵심 요청에 답할 수
있는지 판단하세요. 가능하다면 답하세요. 필수 근거가 여전히 없다면
누락된 사실을 밝히고 가장 작은 유용한 대체 경로를 사용하세요.GPT-5.6은 기본적으로 GPT-5.5보다 더 간결한 경향이 있습니다. 마이그레이션할 때는 “간결하게 답하세요” 또는 “짧게 작성하세요” 같은 포괄적인 간결성 지침이 여전히 유용한지 확인하세요. 일부 작업에서는 필요하지 않을 수 있고, 때로는 응답을 지나치게 짧게 만들기도 합니다. 애플리케이션에 필요한 출력을 안정적으로 만들어 낸다면 그대로 유지하세요.
요청마다 상세 수준을 더 일관되게 제어하려면 text.verbosity로 기본 상세도를 설정하고, 작업별 요구사항은 프롬프트로 지정하세요. 요청의 기본 상세도는 low, medium, high 중에서 선택합니다. 작업에 맞는 길이, 구조 또는 필수 내용은 프롬프트에 명시하세요. API 예시는 text.verbosity 설정을 참고하세요.
고객을 직접 상대하는 어시스턴트와 협업 제품에서는 개성과 협업 방식을 모두 정의하세요.
둘 다 짧게 유지하세요. 개성은 사용자 경험을, 협업 지침은 작업 수행 방식을 형성해야 합니다. 어느 쪽도 명확한 목표, 성공 기준, 도구 규칙 또는 종료 조건을 대신해서는 안 됩니다.
작업에 더 짧은 답이 필요하다면 모델이 반드시 보존해야 할 정보와 생략할 수 있는 세부 사항을 구분해 주세요. 예를 들면 다음과 같습니다:
결론부터 제시하세요. 결론을 뒷받침하는 데 필요한 근거와 중요한
주의사항, 다음 행동을 포함하세요. 부차적인 세부 사항과 반복은 생략하세요.
필수 사실, 결정, 주의사항, 다음 단계는 모두 유지하세요. 서론, 반복,
일반적인 안심 표현, 선택적인 배경 설명부터 줄이세요.이렇게 하면 모델에 명확한 우선순위가 생깁니다. 먼저 작업 완료에 필요한 내용을 보존한 다음, 가치가 낮은 세부 사항을 제거합니다.
“친근하게” 또는 “공감하며” 같은 포괄적인 표현은 모호할 수 있습니다. 답을 얼마나 직접적으로 말할지, 언제 문제를 인정할지, 안심시키는 말이나 끝인사가 적절한지처럼 제품의 어조를 정의하는 글쓰기 방식을 설명하세요.
답을 직접적으로 말하세요. 사용자가 문제를 보고하면 다음 단계를
제시하기 전에 구체적인 문제를 인정하세요. 관련이 있을 때만 안심시키는
표현을 사용하세요. 일반적인 칭찬과 불필요한 끝인사는 생략하세요.“항상 사용자의 언어로 답하세요” 같은 포괄적인 언어 규칙은 실제 제품 요구사항일 때만 사용하세요. 의도한 출력 언어와 그것을 변경해야 하는 경우를 명시합니다.
편집, 재작성, 요약, 고객 대상 초안에서는 모델이 무엇을 보존해야 하는지 알려 주세요:
요청된 결과물, 길이, 구조, 장르, 사실에 관한 주장을 먼저 보존하세요.
요청받지 않았다면 새로운 주장이나 섹션을 추가하거나 더 홍보적인 어조로
바꾸지 말고, 명확성, 흐름, 정확성을 개선하세요.GPT-5.6은 여러 단계의 작업을 수행할 때 능동적이고 끈기 있게 행동할 수 있습니다. 각 요청이 어느 수준의 행동을 승인하는지 정의하면, 모델이 불필요하게 멈추지 않고 안전한 범위 안의 작업을 계속하는 한편 외부 작업, 파괴적 작업, 비용이 드는 작업 또는 범위를 넓히는 작업에 앞서 멈출 수 있습니다.
일반적으로 다음과 같은 간결한 정책이면 충분합니다:
답변, 설명, 검토, 진단 또는 계획 요청에는 관련 자료를 살펴보고
결과를 보고하세요. 요청에 변경도 포함되어 있지 않다면 구현하지 마세요.
변경, 구축 또는 수정 요청에는 범위 안에서 요청된 로컬 변경을 수행하고,
먼저 묻지 않은 채 관련 비파괴 검증을 실행하세요.
외부 쓰기, 파괴적인 행동, 구매 또는 중대한 범위 확대에는 확인을
요구하세요.파일 읽기, 로그 검사, 범위 안의 코드 편집, 테스트 실행처럼 안전한 로컬 작업을 명시적으로 나열하세요. 정책은 한곳에 두고 각 규칙은 한 번씩만 기술합니다. “먼저 물어보세요”, “변경하지 마세요”, “승인을 기다리세요” 같은 지침을 반복하면 안전하고 예상 가능한 작업에도 불필요한 승인 요청이 생길 수 있습니다.
오래 걸리는 작업에는 현재 수행하는 작업의 층위를 정의하세요. 조사, 설계, 구현, 검토, 외부 조율을 구분하여 모델이 한 층위에서 다른 층위로 알리지 않고 넘어가지 않게 합니다.
작업에 관련된 도구만 제공하세요. 도구 설명에는 도구가 하는 일, 사용 시점, 중요한 반환 필드, 오류 발생 시 동작을 명시해야 합니다.
정확성을 확보하려면 사전 검색이나 조회가 필수인 경우, 그 사실을 명시하세요:
행동하기 전에 필요한 탐색, 조회, 검증 단계를 처리하세요. 의도한
최종 상태가 명확해 보여도 선행 조건을 건너뛰지 마세요.여러 읽기 작업이 서로 독립적이라면 병렬로 처리하세요. 한 결과가 다음 행동을 결정한다면 작업을 순차적으로 진행합니다. 병렬 조회 뒤에는 행동하기 전에 결과를 종합하세요.
도구가 비어 있거나 불완전하거나 의심스러울 정도로 좁은 결과를 반환한다면, 결과가 없다고 결론 내리기 전에 의미 있는 대체 경로를 한두 번 시도하세요.
프로그래밍 방식 도구 호출(Programmatic Tool Calling, PTC)은 코드가 여러 도구 결과나 큰 중간 출력을 처리한 뒤 훨씬 작은 구조화 결과를 반환할 수 있는, 범위가 한정된 워크플로에 가장 적합합니다.
호출이 여러 개이거나, 병렬이거나, 서로 의존한다는 사실만으로 프로그래밍 방식 도구 호출을 정당화할 수는 없습니다.
다음 작업에 사용하세요:
다음 경우에는 직접 도구 호출을 권장합니다:
“프로그래밍 방식 도구 호출을 효율적으로 사용하세요” 같은 일반적인 지침에 의존하지 마세요. 범위가 한정된 단계, 사용할 수 있는 도구, 출력 스키마, 재시도 한도, 종료 조건, 직접적인 모델 판단으로 돌아갈 인계 지점을 명시하세요.
프로그래밍 방식 도구 호출은 범위가 한정된 레코드 축소 단계에만
사용하세요. 문서에 명시된 읽기 전용 도구만 호출하세요. 중간 결과를
필터링하고 중복을 제거한 다음, 근거 필드를 갖춘 필수 소형 스키마만
정확히 출력하세요. 일시적인 실패는 최대 두 번 재시도하세요. 승인,
의미론적 판단, 인용, 최종 검증에는 직접 도구 호출을 사용하세요.두 경로가 모두 필요하다면 명확한 인계 지점을 하나만 정의하고, 모델이 경로를 바꾸거나 완료한 작업을 반복하지 않도록 지시하세요.
program_output 항목과 최종 어시스턴트 message는 서로 다른 출력이므로 둘 다 테스트해야 합니다. 이론적으로는 프로그램이 올바른 레코드를 반환해도 메시지에서 필수 필드, 인용 또는 주의사항이 빠질 수 있습니다.
동일한 대표 작업에서 직접 호출과 프로그래밍 방식 호출을 비교하세요. 최종 응답이 정확하고 완전하며 필수 근거를 포함하는지 확인합니다. 그런 다음 전체 토큰, 지연 시간, 비용, 호출 횟수, 턴 수, 재시도 횟수를 비교하세요. 응답이 기존 평가를 계속 통과하는 경우에만 더 적은 자원 사용을 개선으로 간주합니다.
근거 기반 답변에서는 인용 방식도 프롬프트에 포함해야 합니다. 무엇을 뒷받침해야 하는지, 어느 정도를 충분한 근거로 볼지, 근거가 없을 때 어떻게 행동할지 정의하세요. 근거가 없다는 사실을 곧바로 사실상의 “아니요”로 바꾸어서는 안 됩니다.
일반적인 Q&A에서는 짧고 식별력 있는 키워드를 사용해 넓은 검색을
한 번 수행하세요. 상위 결과에 핵심 요청을 뒷받침할 근거가 충분하다면
그 결과를 바탕으로 답하세요.
필수 사실, 담당자, 날짜, ID 또는 출처가 누락되었거나, 사용자가 전수
조사나 비교를 요청했거나, 특정 결과물을 읽어야 하거나, 그렇지 않으면
중요한 주장이 뒷받침되지 않을 때만 조회를 한 번 더 호출하세요.
표현을 개선하거나, 예시를 추가하거나, 필수적이지 않은 세부 사항을
뒷받침하려는 목적만으로 다시 검색하지 마세요.조사와 종합에서는 다음 원칙을 따르세요:
창작 초안에서는 출처로 뒷받침되는 사실과 창의적인 표현을 구분하세요. 초안을 더 강력하게 들리게 하려고 이름, 지표, 날짜, 로드맵 상태, 고객 성과 또는 제품 기능을 지어내지 마세요.
여러 단계 또는 많은 도구가 필요한 작업에는 첫 도구 호출 전에 사용자에게 보이는 짧은 서두를 제시하도록 프롬프트를 작성하고, 이후에는 주요 단계가 바뀔 때 결과를 중심으로 드물게 업데이트하게 하세요. 모델에 일상적인 도구 호출을 일일이 설명하라고 요구하지 마세요.
여러 단계의 작업에서 도구를 호출하기 전에 첫 단계를 설명하는 한두
문장의 사용자용 업데이트를 보내세요. 작업 중에는 주요 단계가 시작되거나
발견한 내용으로 계획이 바뀔 때만 업데이트하세요. 각 업데이트에는
구체적인 결과 하나와 다음 단계를 명시하세요.기록을 재생할 때는 어시스턴트의 phase 값을 보존하여 모델이 진행 설명과 최종 답변을 구분할 수 있게 하세요. previous_response_id를 사용하면 이전 어시스턴트 상태가 자동으로 보존됩니다. 기록을 수동으로 재생한다면 각 항목의 원래 phase 값을 변경하지 말고 유지하세요.
턴마다 압축하지 말고 주요 이정표가 지난 뒤 압축하세요. 압축 후에도 프롬프트가 기능적으로 일관되게 유지되도록 하고, 압축된 항목은 내부를 다시 해석하지 않는 불투명한 상태로 취급하세요.
목표, 가정, 우선순위가 여러 턴에 걸쳐 안정적으로 유지된다면 저장된 추론이 유용합니다. 이전 추론이 더 이상 관련이 없다면 현재 턴의 행동을 사용하세요. 저장된 추론을 항상 켜 두는 최적화로 여기지 마세요. 오래된 추론은 토큰을 추가하고 지연 시간을 늘리며 모델을 낡은 접근 방식에 고정할 수 있습니다.
프롬프트 캐싱 역시 프롬프트 구성에 영향을 줍니다. 재사용 가능한 접두부는 안정적으로 유지하고, 큰 시스템 프롬프트를 불필요하게 변경하지 마세요. 명시적인 캐시 중단점은 워크로드에서 측정한 캐시 동작과 비용을 개선할 때만 사용하세요.
추론 노력을 바꾸기 전에 현재 추론 노력 설정으로 기준선을 마련하세요.
low를 사용합니다.medium을 사용합니다.high 또는 xhigh를 사용합니다.max를 사용하고, 전체에 적용하도록 권장하지 않습니다.추론 노력을 높이기 전에 프롬프트에 성공 기준, 의존성 규칙, 도구 라우팅 규칙 또는 검증 반복이 빠져 있지 않은지 확인하세요.
GPT-5.6은 레이아웃, 시각적 위계, 디자인 판단 능력이 더 강합니다. 그렇더라도 제품 맥락을 제공하고 기존 디자인 시스템을 보존하며 중요한 상태와 제약 조건을 명시하세요.
점진적인 프런트엔드 변경에서는 다음 원칙을 따르세요:
공간적 정밀도가 중요한 비전, 컴퓨터 사용, 현지화 또는 OCR 작업에서는 이미지 상세도를 의도적으로 선택하세요. 추가 입력 비용과 지연 시간이 정당화되는 경우, 크거나 조밀하거나 좌표에 민감한 이미지에 원본 상세도를 사용하세요.
GPT-5.6이 출력을 검증할 수 있는 도구에 접근하게 하고 어떤 검증이 중요한지 명시하세요.
코딩 작업:
변경한 뒤 이용 가능한 검증 중 가장 관련성이 높은 것을 실행하세요:
- 변경된 동작을 대상으로 하는 테스트
- 해당하는 경우 타입 검사 또는 린트 검사
- 영향을 받는 패키지의 빌드 검사
- 전체 검증 비용이 너무 크다면 최소한의 스모크 테스트
검증을 실행할 수 없다면 그 이유를 설명하고 차선의 점검 방법을
제시하세요.시각 결과물:
완료하기 전에 결과물을 렌더링하세요. 레이아웃, 잘림, 간격,
누락된 내용, 시각적 일관성을 살펴보세요. 렌더링 결과가 요구사항과
일치할 때까지 수정하세요.구현 계획에는 요구사항, 이름이 명시된 리소스나 파일, 상태 전이 또는 데이터 흐름, 검증 점검 항목, 실패 시 동작, 개인정보 보호 또는 보안 고려사항, 구현에 중대한 영향을 주는 미해결 질문을 포함하세요.
복잡한 프롬프트에는 다음 구조를 출발점으로 사용하세요. 각 섹션은 짧게 유지하고 행동을 바꾸는 경우에만 세부 정보를 추가합니다.
Role: [모델의 기능과 맥락]
Personality: [어조와 협업 방식]
Goal: [사용자에게 보이는 결과]
Success criteria: [최종 답변 전에 충족해야 하는 조건]
Constraints: [정책, 안전, 비즈니스, 근거, 부작용 한계]
Tools: [사용할 도구, 사용 시점, 사용하지 말아야 할 도구]
Output: [섹션, 길이, 형식, 어조]
Stop rules: [재시도, 대체 경로, 답변 보류, 질문 또는 종료 시점]기존 애플리케이션을 GPT-5.6으로 옮길 때:
작동하는 프롬프트 스택 전체를 한꺼번에 다시 작성하지 마세요. 그렇게 하면 행동 변화가 모델, 추론 설정, 프롬프트, 도구 모음 또는 런타임 중 어디에서 비롯되었는지 알 수 없습니다.
프롬프트 성능이 퇴보하면 소수의 실제 실행 기록으로 디버깅하세요. 실패 유형을 파악하고, 원인일 가능성이 높은 지침이나 모순을 찾고, 외과적으로 작은 수정을 한 뒤 같은 사례를 다시 실행하세요.
04 · 원본 링크·인용
ACCESSED PRIMARY SOURCES
원문 링크는 완역 본문의 의미상 위치에 그대로 남아 있습니다. 이 목록은 팩트체크에 사용한 1차 출처를 보조적으로 모은 것입니다.
Programmatic Tool Calling
https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling
Frontend prompting
https://developers.openai.com/api/docs/guides/frontend-prompt
05 · 기타
METHOD & LIMITS
API 필드·지원 값·기능 계약은 사실로 검증했습니다. “이 방식이 더 낫다”는 운영 지침은 공식 권고의 존재를 확인했을 뿐, 모든 워크로드의 우월성을 뜻하지 않습니다.
10–15%, 41–66%, 33–67%는 OpenAI 내부 평가의 당사자 보고입니다. 표본·원자료·산식이 공개되지 않아 자체 대표 평가 없이는 일반화할 수 없습니다.
원문의 15개 링크 발생 위치를 완역 안에 보존했습니다. 링크에 포커스를 주거나 마우스를 올리면 대상과 세 줄 요약을 확인할 수 있습니다.
공개 원문 본문을 전체 캡처했으며 로그인·페이월 제한은 없었습니다. 원문 본문에 이미지나 그래프는 없었습니다.
Source: https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6
Captured and checked: 2026-07-16 · Target language: Korean · Partial: no