GPT-5.2 프롬프트 가이드 (OpenAI)

핵심 요약

GPT-5.2는 정확도와 도구 활용, 긴 맥락 처리에 강한 엔터프라이즈용 모델로, 성능을 끌어올리려면 분명한 길이·형식·범위 제약을 프롬프트에 함께 설계하는 것이 중요하다. 특히 말수 조절, 범위 통제, 긴 대화 압축, 도구 호출 전략, 웹 리서치 규칙 등을 명시하면 비용과 지연시간을 관리하면서도 안정적인 품질을 유지할 수 있다.

GPT-5.2가 지향하는 역할과 사용 맥락

GPT-5.2는 단순 대화형 챗봇이라기보다 "복잡한 업무 흐름을 꾸준히 수행하는 에이전트"에 초점을 맞춘 모델이다. 코드 작성, 문서 분석, 금융·규제 관련 작업, 여러 도구를 오가며 진행하는 에이전트 시나리오 등에서 높은 완수율과 안정된 행동을 목표로 설계되었다.

이 모델은 기본적으로 더 정확하고 보수적인 추론을 지향하며, 사용자의 요구와 시스템 프롬프트에 민감하게 반응한다. 따라서 "어떤 톤으로, 얼마나 길게, 어떤 구조로 답해야 하는지"를 구체적으로 말해주면 그에 맞춰 행동하는 경향이 뚜렷하다.

프롬프트를 잘 만든다는 것은 모델에게 "일의 범위, 깊이, 말수, 포맷"을 계약서처럼 명확히 전달하는 것에 가깝다. GPT-5.2는 이런 계약을 잘 지키는 편이므로, 설계를 잘하면 예측 가능하고 평가하기 쉬운 시스템을 만들 수 있다.

GPT-5.2의 핵심 행동 특성 변화

이전 세대(GPT-5, 5.1)와 비교하면 GPT-5.2는 중간 계획과 구조를 더 잘 세우는 편이다. 즉, 답을 내기 전에 자연스럽게 단계나 섹션을 잡는 경향이 강해졌고, 이런 경향은 프롬프트로 더 세밀하게 조절할 수 있다.

또한 불필요한 말은 줄이고 핵심에 집중하는 쪽으로 변화했지만, 여전히 "얼마나 길게 쓸지"는 프롬프트가 좌우한다. 속된 말로 과하게 수다쟁이는 덜 되었지만, 프롬프트가 모호하면 여전히 장황해질 여지가 있다.

도구 호출 측면에서는 조금 더 적극적으로 움직이며, 특히 상호작용 흐름에서 도구 콜 수가 늘어날 수 있다. 이는 정밀한 작업에는 도움이 되지만, 비용과 지연시간 측면에서 부담이 될 수 있어 별도 규칙으로 다듬어 줄 필요가 있다.

마지막으로, 이 모델은 "틀리지 않기 위해 더 신중하게 말하는 성향"이 강화되었다. 애매한 질문에 대해서는 더 보수적으로 추론하고, 적절한 프롬프트를 주면 모호함을 인지하고 가정·한계를 분명하게 밝히는 방향으로 설계되어 있다.

답변 길이와 출력 형식 통제하기

GPT-5.2를 실무에서 쓰려면 가장 먼저 "얼마나 길게, 어떤 구조로 답할지"를 명시하는 것이 좋다. 예를 들어 기본 답변은 몇 문장, 간단한 질문은 몇 문장, 복잡한 작업은 개요 후 항목별 정리처럼 상황별 길이 규칙을 따로 두는 식이다.

이때 핵심은 "범위"가 아니라 "길이와 구조"를 규정하는 것이다. 예를 들어 '긴 작업일수록 개요 한 단락 뒤에 바뀐 점·위치·위험·다음 단계·열린 이슈를 짧게 나눠 써라'처럼 패턴을 정의하면, 에이전트의 출력이 한결 예측 가능해진다.

또한 "사용자 요청을 다시 말하지 말 것, 긴 서사형 문단 대신 짧은 단락과 목록을 쓸 것"처럼 스타일을 분명히 적어주는 것이 좋다. 이런 형식 규칙을 하나의 블록으로 묶어 시스템 프롬프트에 삽입하면, 여러 작업에서 재사용할 수 있는 일종의 스타일 가이드가 된다.

작업 범위가 새어 나가는 것을 막는 방법

프론트엔드나 제품 개발 작업에서 자주 발생하는 문제는 "모델이 요구하지 않은 기능이나 화려한 UI를 마음대로 덧붙이는 것"이다. GPT-5.2는 구조적 코드를 잘 쓰는 만큼 이 문제가 더 커질 수 있으므로, 범위를 못 박는 문구를 반드시 포함하는 편이 안전하다.

예를 들어 "요청한 기능만 정확히 구현하고, 새로운 기능이나 컴포넌트는 추가하지 않는다"는 식의 규칙을 만들어 둔다. 여기에 "기존 디자인 시스템을 먼저 파악하고, 색상·토큰·스타일은 시스템에서 정의된 것만 사용한다"라는 제약을 더하면, 스타일 일관성을 유지할 수 있다.

애매한 요구사항에 대해서는 '가장 단순한 해석을 택한다'는 기본 원칙을 함께 적어 두면 좋다. 이렇게 하면 모델이 "혹시 더 멋있게 해볼까?" 하고 임의로 범위를 넓히는 대신, 가장 보수적인 구현을 택하도록 유도할 수 있다.

긴 맥락과 큰 문서에서의 기억력 관리

수만 토큰에 이르는 긴 문서나 장기 대화에서는 사람이든 모델이든 쉽게 맥락을 잃는다. GPT-5.2는 이를 완화하기 위해 "먼저 중요한 구조를 정리하고, 그 위에 답변을 얹는" 패턴과 궁합이 좋다.

길이가 긴 입력이 들어오면 우선 관련 섹션들의 짧은 개요를 내부적으로 잡게 지시하고, 그 다음 사용자의 조건을 명시적으로 다시 적게 하는 것이 좋다. 예를 들어 적용 국가, 기간, 제품 라인 등 핵심 필터를 다시 선언하게 하면, 그 뒤의 추론이 훨씬 덜 흔들린다.

또한 답변할 때는 "어떤 섹션에서 이 내용을 가져왔는지"를 언급하도록 요청하면, 모델 스스로도 위치를 의식하게 되어 오류가 줄어든다. 날짜, 금액, 조항 번호처럼 세부 사항이 중요한 경우에는 해당 부분을 다시 인용하거나 요약하도록 요구해 신뢰도를 높일 수 있다.

모호성·환각 위험 줄이는 프롬프트 설계

질문이 애매하거나 정보가 부족한데도 단정적인 답을 내놓는 행동은 실무에서 가장 위험한 유형에 속한다. 이를 줄이려면 "애매하면 애매하다고 말하고, 경우에 따라 질문이나 가정 목록을 제시하라"는 규칙을 시스템 프롬프트에 명시하는 것이 좋다.

예를 들어 정보가 모자랄 때는 1~3개의 짧은 확인 질문을 던지거나, 가능한 해석들을 나열한 뒤 각각의 가정 위에서 답을 하도록 지시할 수 있다. 외부 사실이 자주 변하는 영역(가격, 정책, 최신 뉴스 등)에 대해서는, 자료가 오래되었을 수 있음을 인정하고 일반적인 수준에서만 이야기하도록 가이드해야 한다.

법률, 금융, 안전처럼 위험도가 높은 답변에서는 "스스로 결과물을 다시 훑어보는 짧은 검증 단계"를 넣는 것이 유용하다. 이때 숨겨진 가정, 출처가 불분명한 수치, '항상, 절대' 같은 과도하게 강한 표현을 찾아 완화하거나 전제를 밝히도록 유도하면, 실제 운영환경에서의 리스크를 크게 줄일 수 있다.

긴 세션을 위한 대화 압축(Compaction) 활용

긴 에이전트 세션에서는 도구 호출과 대화가 계속 쌓이면서 언젠가 컨텍스트 한도가 문제를 일으킨다. GPT-5.2는 이를 위해 이전 대화와 상태를 압축해서 "토큰 수는 줄이되, 의미는 유지하는" 전용 엔드포인트를 제공한다.

압축은 대화 전체를 사람이 읽을 수 있는 요약으로 바꾸는 것이 아니라, 모델이 나중에 계속 추론할 수 있도록 정보를 암호화·축약하는 과정에 가깝다. 따라서 압축 결과를 분석하거나 조작하려 하지 말고, 이후 요청에 그대로 포함시켜 맥락을 이어가는 용도로만 사용하는 것이 원칙이다.

실무에서는 컨텍스트 한계에 닿기 직전에 미리 압축하는 것이 좋고, 특히 도구를 많이 쓴 구간이나 큰 작업이 끝난 시점에 한 번씩 정리하는 패턴이 유용하다. 압축 뒤에 프롬프트 구조를 바꾸면 모델 행동이 달라질 수 있으므로, 최대한 이전과 동일한 시스템·사용자 프롬프트를 유지하는 것이 안정적인 운영에 도움이 된다.

에이전트의 중간 보고와 도구 사용 전략

GPT-5.2는 여러 단계를 스스로 설계하고 도구를 오가며 작업하는 능력이 강화되었다. 이때 사람 입장에서는 "어디까지 진행됐는지, 무엇이 바뀌었는지"만 알고 싶지, 모든 내부 생각과 도구 호출 로그를 보고 싶은 것은 아니다.

따라서 "새로운 큰 단계에 들어갈 때나 계획이 바뀔 때만 짧게 상황을 보고하라"는 규칙을 두면 좋다. 각 보고에는 최소 하나의 구체적 결과(무엇을 찾았는지, 무엇을 확인했는지, 무엇을 수정했는지)를 포함하게 하면, 진척 상황을 효율적으로 파악할 수 있다.

도구 사용에 대해서는, 최신 정보나 사용자 고유 데이터가 필요할 때는 모델 자신의 지식보다 도구를 우선 사용하도록 명시하는 것이 좋다. 여러 파일 읽기, 여러 레코드 조회처럼 서로 독립된 읽기 작업은 가능한 병렬로 실행하도록 유도하면 지연시간을 줄일 수 있다.

특히 쓰기·업데이트 도구 호출 이후에는 "어디가, 어떻게 바뀌었는지, 이후 검증은 했는지"를 짧게 다시 말하게 하면, 변경 이력을 추적하고 오류를 찾기 쉬워진다. 이렇게 도구 사용 규칙과 중간 보고 규칙을 함께 설계해 두면, 에이전트가 "조용히 일을 잘하는 어시스턴트"에 가까워진다.

구조화 추출·문서 작업에 특화된 설계

GPT-5.2는 PDF, 오피스 문서, 이메일, 표 등에서 구조화된 정보를 뽑아내는 작업에서 특히 강점을 보인다. 다만 이 능력을 최대한 활용하려면 "어떤 JSON 구조로 내보낼지"를 미리 정해 주는 것이 거의 필수에 가깝다.

스키마를 설계할 때는 필수 필드와 선택 필드를 구분하고, 문서에 없는 정보는 추측하지 말고 null로 두도록 명시하는 것이 좋다. 또한 리턴 직전에 원본을 한 번 더 훑어 누락된 값이 없는지 스스로 점검하게 하면, 추출 완성도가 눈에 띄게 올라간다.

여러 문서나 여러 표에서 동시에 뽑아야 한다면, 문서별로 따로 결과를 만들고 파일명이나 문서 제목 같은 안정적인 식별자를 함께 기록하게 해야 한다. 이를 통해 나중에 어느 값이 어느 문서에서 왔는지를 쉽게 추적할 수 있고, 검증 및 디버깅 과정이 단순해진다.

GPT-5.2로의 마이그레이션 전략

기존에 GPT-4o, 4.1, 5, 5.1을 쓰고 있다면, GPT-5.2로 옮길 때 가장 중요한 것은 "모델만 바꾸고 나머지는 그대로 두는 것"이다. 초기에는 프롬프트를 손대지 말고 모델과 reasoning_effort 설정만 바꿔, 변화의 원인이 모델인지 프롬프트인지 분리해서 볼 수 있게 해야 한다.

이때 reasoning_effort는 이전 모델의 성격을 그대로 따라가는 것이 기본 전략이다. 예를 들어 4o나 4.1에서 빠른 응답을 쓰고 있었다면 GPT-5.2에서는 effort를 none으로 두고, GPT-5나 5.1을 쓰던 경우에는 기존 effort 값을 그대로 옮기는 식이다.

그 후 자체 평가 도구나 테스트 세트를 돌려 성능 변화를 확인한 뒤, 문제가 있으면 두 가지 방법 중 하나를 선택해 점진적으로 개선한다. 하나는 reasoning_effort를 한 단계 올려 더 깊은 추론을 허용하는 것이고, 다른 하나는 프롬프트의 길이·형식·범위·스키마 제약을 조금씩 다듬는 것이다.

각 변경 후에는 반드시 다시 평가를 돌려 "어떤 수정이 어떤 결과를 낳았는지"를 확인해야 한다. 이렇게 모델 변경, effort 조정, 프롬프트 변경을 한 번에 한 가지씩만 적용하면, 예측 가능한 품질 관리가 가능해진다.

웹 리서치 에이전트 설계의 모범 패턴

GPT-5.2는 웹 검색과 정보 종합에 강하지만, 아무 말 없이 쓰면 웹을 안 쓰거나, 근거 없이 단정적인 답을 내놓을 수도 있다. 따라서 "언제든 애매하거나 최신성이 중요한 주제는 반드시 웹을 검색하라"는 규칙을 강하게 못 박는 것이 좋다.

리서치 에이전트의 기본 임무는 "회의적인 독자도 납득할 수 있을 만큼 근거를 갖춘 답을 내는 것"이다. 이를 위해 항상 여러 검색 쿼리를 병렬로 사용하고, 서로 다른 출처를 교차 확인하며, 각 주장 뒤에 출처를 명시하도록 시스템 프롬프트에서 요구할 수 있다.

답변은 마크다운 형식으로 구조화하고, 어려운 용어나 약어는 그 자리에서 풀어 설명하게 하면 읽기 편한 리포트가 된다. 또한 사용자가 짧게 해달라고 명시하지 않는 한, 질문에 직접적으로 답한 이후에도 "배경, 원리, 실무적인 시사점"까지 덧붙이는 것을 기본값으로 설정하면, 한 번의 리서치로 얻는 정보량이 크게 늘어난다.

모호한 질문에 대해서는 굳이 되묻지 말고, 가장 가능성 높은 해석을 먼저 밝힌 뒤 그 해석을 기준으로 충분히 긴 답을 제공하도록 설계하는 것이 좋다. 동시에 다른 plausible한 해석이 있다면 그 경우도 따로 다뤄, 사용자가 자신의 의도와 가장 가까운 부분을 골라 활용할 수 있게 해준다.

인사이트

GPT-5.2는 "좋은 프롬프트를 잘 지키는" 모델이다. 그만큼 프롬프트를 대충 쓰면 모델의 잠재력을 반만 쓰는 셈이 되고, 반대로 길이·범위·형식·도구 사용 규칙을 체계적으로 설계하면 안정적이고 강력한 에이전트를 비교적 쉽게 만들 수 있다.

실무에서 바로 적용해볼 만한 팁은 다음과 같이 정리할 수 있다. 첫째, 모든 에이전트에 공통으로 쓸 "출력 길이·형식 규칙"과 "모호성·불확실성 처리 규칙"을 시스템 프롬프트 블록으로 만들어 두고 재사용하라. 둘째, 각 도메인(프론트엔드, 데이터 분석, 리서치 등)마다 "범위 통제"와 "도구 사용 원칙"을 별도 블록으로 정의해 두면 유지보수가 쉬워진다. 셋째, 컨텍스트가 길어지는 워크플로에서는 compaction을 적절한 시점에 사용하고, 모델 교체 시에는 reasoning_effort와 프롬프트 변경을 분리해 평가하라.

결국 GPT-5.2를 잘 쓰는 핵심은 "모델을 더 똑똑하게 만들려 하기보다, 모델이 지킬 규칙을 더 명확하게 쓰는 것"에 있다. 이 관점을 유지하면, 같은 모델로도 훨씬 더 신뢰할 수 있고 운영하기 쉬운 시스템을 설계할 수 있다.

출처 및 참고 : GPT-5.2 Prompting Guide