GPT-5.2 Prompting Guide 요약: 프로덕션 에이전트 성능을 올리는 프롬프트 패턴

GPT-5.2는 “똑똑해진 모델”이라기보다, 프로덕션에서 평가 가능하고 일관되게 동작하도록 더 дисцип린(규율)이 강화된 모델에 가깝습니다.

이 글은 원문을 길게 옮기지 않고, 실제 운영에서 체감되는 포인트(출력 길이/형식, 스코프 통제, 장문 컨텍스트, 불확실성, compaction, reasoning_effort 마이그레이션)를 “바로 가져다 쓰는” 형태로 정리합니다.

핵심 메시지: GPT-5.2는 “기본값”도 좋지만, 명시적 제약(verbosity/format/scope/reasoning)을 주는 순간 성능이 안정적으로 올라갑니다.

1) GPT-5.2에서 달라진 행동 특성

구조화가 더 “자연스럽게” 나옵니다(계획/중간 구조를 잡는 습관이 강해짐).
기본적으로 더 간결하지만, 프롬프트에 따라 길이 민감도가 큽니다(원하는 길이를 수치로 고정하는 게 유리).
지시사항 준수와 포맷 일관성이 개선됐습니다(기업형 워크플로우에 유리).
도구 호출은 상호작용 흐름에서 더 “많이” 할 수 있습니다(툴 효율 규칙을 추가하면 줄일 수 있음).
애매하면 보수적으로 근거를 찾는 경향이 강합니다(불확실성 처리 블록이 특히 잘 먹힘).

2) 프롬프트 패턴 5종 세트(실전에서 제일 많이 쓰는 것)

(1) Verbosity와 출력 모양을 “숫자”로 잠그기

에이전트는 답이 맞아도 길이가 흔들리면 운영 품질이 떨어집니다. 그래서 “문장 수/불릿 수/섹션 수”로 제한을 박는 게 가장 싸고 강력합니다.

운영 팁: “기본 답변은 3–6문장 또는 불릿 5개 이하”처럼 클램프를 두면 비용/지연/일관성이 같이 좋아집니다.

복잡한 작업은 “짧은 개요 1문단 + (What changed / Where / Risks / Next steps / Open questions)” 같은 템플릿을 고정해두면 리뷰가 쉬워집니다.

(2) 스코프 드리프트(과잉 구현) 방지: “정확히 그리고 오직” 규칙

프론트엔드/UX/에이전트 자동화에서 가장 흔한 사고는 “요구하지 않은 기능”을 붙이다가 검토 범위가 폭발하는 것입니다. GPT-5.2는 구조화가 좋아진 만큼, 방심하면 더 많이 만들어낼 수 있습니다.

“요청한 것만 구현”을 금지어 수준으로 반복해 넣기
디자인 토큰/기존 시스템이 있으면 그 범위 안에서만 색/스타일 사용
애매하면 “가장 단순한 유효 해석”을 선택하도록 명시

(3) 장문 컨텍스트(긴 문서/스레드)에서 “길 잃는” 문제 줄이기

입력이 길어질수록 모델은 “전반적 요약”은 잘하지만, 특정 조항/날짜/임계값 같은 디테일에서 미끄러지기 쉽습니다. 이때는 먼저 관련 섹션을 재고정(re-grounding)시키는 패턴이 효과적입니다.

추천 패턴: 먼저 “요청과 관련된 섹션만” 짧게 개요로 잡고, 답변에서는 “문서의 어떤 섹션에서 나온 주장인지”를 앵커링합니다.

디테일 의존 답변(날짜/조항/수치)은 인용 또는 정확한 패러프레이즈를 요구하면 누락이 줄어듭니다.

(4) 애매함/환각 리스크 줄이기: “질문 or 가정” 분기

운영에서 위험한 건 틀린 답 자체보다 “확신에 찬 틀림”입니다. 애매하면 1–3개의 정밀 질문을 하거나, 2–3개의 해석을 가정으로 분리해 제시하도록 규칙을 넣으세요.

최근 변경 가능성이 있으면 일반론으로 답하고, 최신성 한계를 명시
확실하지 않은 수치/라인/참조는 만들지 말기(“모르면 모른다”를 시스템화)
법/금융/컴플라이언스는 최종 제출 전 “가정/근거 없는 수치/과한 단정” 자체 점검 규칙 추가

(5) 툴 콜(도구 호출)과 병렬화: “언제 툴을 쓰는지”를 먼저 정의

GPT-5.2는 도구 기반 흐름에서 신뢰도가 좋아졌지만, 가끔 “읽기 툴을 너무 자주” 쓰기도 합니다. 해결은 간단합니다. 툴을 쓰는 조건과, 병렬로 읽을 대상을 먼저 규칙으로 못 박으면 됩니다.

실전 규칙: “최신/사용자 전용 데이터, 특정 ID/URL/문서명 참조”는 무조건 툴 우선으로 처리합니다.

쓰기(변경) 툴 호출 뒤에는 “무엇이/어디가/검증은 했는지” 3가지를 짧게 재진술하게 하면 사고가 크게 줄어듭니다.

3) Compaction: 긴 워크플로우를 “컨텍스트 한도 밖”으로 밀어붙이는 방법

툴 콜이 많은 에이전트는 대화가 길어지면서 컨텍스트가 빨리 차고, 그 순간부터 품질이 흔들립니다. 이때 compaction은 이전 대화를 “손실을 관리하며 압축”해서 이어달릴 수 있게 해주는 전략입니다.

언제 쓰나: 멀티스텝 도구 흐름, 긴 대화 유지가 필요한 세션, 컨텍스트 한도 임박 시점
운영 요령: “매 턴”이 아니라, 큰 마일스톤 이후에만 압축(너무 자주 하면 흐름이 흔들릴 수 있음)
주의: 압축 결과는 불투명(opaque)하므로 내부를 파싱/의존하지 말고 “이어가기” 목적으로만 사용

4) 마이그레이션 체크리스트: GPT-5.2로 옮길 때 가장 안전한 순서

모델 교체와 프롬프트 수정을 동시에 하면, 좋아졌는지 나빠졌는지 원인을 못 찾습니다. 가이드는 “하나씩 바꾸기”를 강하게 권합니다.

모델만 교체하고 프롬프트는 그대로 두기(기능 동일성 유지)
reasoning_effort를 명시적으로 핀(pin) 고정(기본 thinking에 끌려가 비용/지연이 변하는 걸 방지)
기존 eval로 베이스라인 측정 후, 회귀가 있을 때만 프롬프트를 미세 조정
변경 후에는 다시 eval, 그리고 한 번에 한 가지만 조정

기억할 포인트: GPT-5는 기본 reasoning이 ( \text{medium} ), GPT-5.1/5.2는 기본이 ( \text{none} ) 쪽이라 체감이 달라질 수 있습니다. 그래서 “이전과 같은 latency/깊이 프로파일”을 원하면 reasoning_effort를 반드시 명시하는 게 안전합니다.

5) (복붙용) 프롬프트에 바로 넣는 미니 블록

아래는 “길이/스코프/불확실성” 3개만 묶은 최소 블록입니다. 실제로는 팀 표준 프롬프트에 고정해두고, 작업별로 수치만 바꾸는 방식이 관리가 쉽습니다.

<output_verbosity_spec>
- 기본: 3–6문장 또는 불릿 5개 이하
- 단답형: 2문장 이하(결론 + 이유)
- 복잡 작업: 1문단 개요 + What changed/Where/Risks/Next steps/Open questions(각 1줄)
</output_verbosity_spec>

<design_and_scope_constraints>
- 사용자가 요청한 것만, 정확히 구현
- 추가 기능/스타일/UX embellishment 금지
- 애매하면 가장 단순한 유효 해석 선택
</design_and_scope_constraints>

<uncertainty_and_ambiguity>
- 애매하면: (1) 1–3개 확인 질문 또는 (2) 2–3개 해석 + 가정 분리
- 확실하지 않은 수치/근거/참조는 생성 금지
</uncertainty_and_ambiguity>

6) 한 줄 인사이트: “좋은 프롬프트”의 기준이 바뀌었다

GPT-5.2에서는 “멋진 지시문”보다, 평가 가능한 형식(길이/섹션/스키마)과 안전장치(스코프/불확실성/툴 규칙)를 갖춘 프롬프트가 장기적으로 더 높은 성능을 냅니다.

GPT-5.2 프롬프팅 가이드