핵심 요약
GPT-5.4는 긴 작업과 멀티스텝 에이전트 흐름에서 강하지만, "출력 계약·도구 규칙·완료 기준·검증"을 명시할수록 더 안정적으로 끝까지 완수합니다.
추가로, 과도한 추론 설정을 올리기 전에 프롬프트 구조(완전성/검증/도구 지속성)를 먼저 강화하는 것이 비용 대비 효과가 큽니다.
GPT-5.4를 잘 쓰는 관점: "성능"보다 "계약"이 먼저
GPT-5.4는 장문에서의 톤 유지, 여러 단계의 작업 지속, 근거 기반 종합에 강합니다.
하지만 이 장점은 자동으로 발현되기보다 "무엇을 어떤 형태로 내야 하는지(출력 계약)"와 "어떤 조건에서 끝난 것으로 보는지(완료 기준)"를 명확히 줄 때 가장 크게 드러납니다.
한마디로, GPT-5.4는 똑똑해서가 아니라 "규칙을 주면 그 규칙을 오래 기억하고 지키는 쪽"이라서 성능이 체감됩니다.
강점과 취약 지점: 어디서 '명시적 프롬프트'가 필요한가
강점은 크게 세 갈래입니다. 첫째, 긴 답변에서도 말투와 성격이 덜 흔들립니다.
둘째, 에이전트형 작업에서 중간에 포기하지 않고 재시도하며 루프를 닫는 경향이 강합니다.
셋째, 긴 문서나 여러 도구 결과를 엮어 "근거 많은 요약"을 만드는 데 유리합니다.
반대로 명시적 지시가 특히 도움이 되는 구간도 반복적으로 나타납니다. 세션 초반처럼 맥락이 얕을 때는 도구 선택(라우팅)이 흔들릴 수 있고, 선행 조건이 있는 작업은 "먼저 해야 할 것"을 건너뛰기 쉽습니다.
또한 리서치에서 출처 수집·인용을 규율하지 않으면 형식이 흐트러지거나 근거 경계가 약해질 수 있고, 되돌릴 수 없는 행동(삭제/결제/배포)은 실행 전 검증·허가가 필요합니다.
출력 계약으로 '짧고 구조적인 답'을 강제하기
토큰 효율과 안정성을 동시에 올리는 핵심은 "얼마나 말할지"를 기분이 아니라 규칙으로 정하는 것입니다. Responses API의 verbosity 같은 파라미터가 있어도, 프롬프트 안에서 출력 형태를 계약처럼 못 박으면 효과가 더 확실합니다.
예를 들어 "요청한 섹션만, 지정한 순서대로, 지정 포맷만(JSON/SQL/Markdown 등)"을 선언하면, 모델이 중간 설명을 덧붙이며 형식을 깨는 일을 줄일 수 있습니다.
실무에서는 이게 견적서처럼 작동합니다. "결과물은 이 양식으로 납품"이라고 써두면, 중간 사담이나 과잉 친절이 줄고 파싱 실패도 감소합니다.
<output_contract>
- Return exactly the sections requested, in the requested order.
- If a format is required (JSON, Markdown, SQL, XML), output only that format.
</output_contract>대화 중 요구가 바뀔 때: 범위·우선순위·지속 규칙을 문장으로 박아두기
사용자는 중간에 "형식 바꿔줘", "이번엔 계획만", "위험만 말해"처럼 방향을 자주 꺾습니다. 이때 모델이 헤매지 않게 하려면, '언제 진행하고 언제 물어볼지'와 '새 지시가 기존 지시를 어떻게 덮는지'를 미리 규정해야 합니다.
특히 좋은 방식은 "되돌릴 수 있고 저위험이면 묻지 말고 진행, 외부 영향/비가역/민감정보 필요면 허락 요청" 같은 기본 정책을 두는 것입니다.
또한 지시 우선순위를 "최신 사용자 지시가 기존 스타일 규칙을 덮되, 안전·정직·프라이버시는 예외 없이 유지"처럼 선명하게 적어두면, 갑자기 톤을 바꾸거나 작업 범위를 바꿀 때도 일관성이 살아납니다.
도구 사용을 끝까지 밀고 가게 만드는 규칙: 지속성·의존성·병렬화
에이전트 실패의 흔한 패턴은 "정답이 뻔해 보여서" 조회·검증 같은 선행 단계를 생략하는 것입니다. 이를 막으려면 도구 사용을 '선택'이 아니라 '필요조건'으로 만들어야 합니다.
핵심은 세 가지입니다. 첫째, 정확도/근거/완성도를 유의미하게 올리면 도구를 쓰도록 강제하고, 결과가 비었거나 애매하면 다른 전략으로 재시도하도록 씁니다.
둘째, 어떤 행동을 하기 전에 "선행 조회가 필요한지"를 점검하도록 의존성 체크를 둡니다. "최종 상태가 obvious"여도 선행 단계를 건너뛰지 못하게 하는 안전장치입니다.
셋째, 서로 독립인 조회는 병렬로 돌려 시간을 줄이고, 의존성이 있는 단계는 순차로 묶어 사고를 줄입니다. 즉 "속도는 병렬, 정확성은 순차"라는 원칙을 프롬프트로 고정합니다.
장기·대량 작업 완주 장치: 완전성 계약과 빈 결과 복구
긴 배치 작업에서 모델이 중간에 "대충 끝낸 것처럼" 마무리하는 문제는, 완료 정의가 흐리기 때문에 생깁니다. 그래서 "요청 항목 전부를 처리했거나, 못 했으면 [blocked]로 표시" 같은 완전성 계약이 필요합니다.
또한 검색/조회가 비어 있을 때 즉시 "없다"고 결론내리지 않도록, 최소 1~2번의 대체 전략(다른 쿼리, 넓은 필터, 선행 조회, 다른 소스)을 시도하게 만들면 리서치 품질이 올라갑니다.
이 두 블록은 "긴 작업을 끝까지 가져가는 체력"을 프롬프트로 보강하는 장치입니다.
고위험 작업 전 필수: 검증 루프와 '컨텍스트 없으면 추측 금지'
완료 직전에 간단한 검증 루프를 넣으면 요구사항 누락, 근거 없는 단정, 형식 드리프트를 잡아낼 수 있습니다.
검증은 보통 네 갈래로 충분합니다. 요구사항 충족(정확히 다 했나), 근거(주장에 출처가 있나), 형식(스키마/스타일을 지켰나), 그리고 외부 영향(되돌릴 수 없으면 허락을 받았나)입니다.
여기에 "필요한 정보가 없으면 추측하지 말고, 가능하면 조회 도구를 쓰고, 불가하면 최소 질문만"이라는 게이팅 규칙을 붙이면, 그럴듯한 상상을 사실처럼 말하는 사고를 줄일 수 있습니다.
리서치·인용 품질 고정: 출처 경계와 인용 형식을 '잠그기'
리서치에서 가장 중요한 건 "어디까지가 근거이고 어디부터가 상상인지"의 경계입니다. 이를 위해 "이번 워크플로에서 실제로 가져온 소스만 인용"을 규칙으로 걸고, URL/ID/인용구를 지어내지 못하게 금지해야 합니다.
또한 인용은 문서 끝에 몰아서 붙이면 주장-근거 연결이 약해집니다. "해당 주장 바로 옆에 인용을 붙여라"처럼 연결 규칙을 명시하면, 증거 기반 합성이 더 단단해집니다.
리서치 모드는 3단계(질문 쪼개기→각 질문 검색+2차 단서→모순 조정 후 인용 포함 결과 작성)로 강제하면, 검색을 한 번 하고 끝내는 습관을 줄일 수 있습니다.
구조화 출력(예: JSON/SQL)과 비전 작업(이미지 detail)의 실무 규칙
파서가 읽어야 하는 결과물은 "형식 외 텍스트 금지"가 가장 중요합니다. 괄호/대괄호 균형 점검, 테이블/필드 발명 금지, 스키마가 없으면 질문하거나 에러 오브젝트 반환 같은 규칙을 넣으면 운영 사고가 줄어듭니다.
비전·컴퓨터 사용 흐름에서는 이미지 detail을 자동에 맡기지 말고 작업 목적에 맞게 고릅니다. 정밀 판독은 high, 큰 화면·OCR·좌표 정확도가 중요하면 original, 비용/속도가 우선이면 low처럼 결정 기준을 프롬프트나 통합부에서 고정하는 편이 안전합니다.
런타임 통합 포인트: phase, Compaction, 성격(페르소나) 분리
도구가 많이 끼거나 오래 걸리는 에이전트는 "지금은 작업 중 코멘터리인지, 최종 답인지"를 런타임이 구분해줘야 오작동이 줄어듭니다. Responses API의 phase는 이런 혼동(서두/코멘터리를 최종 답으로 오인)을 줄이기 위한 신호이므로, 장기 작업에서는 명시적으로 쓰고 재생(replay) 시에도 보존하는 편이 유리합니다.
긴 세션은 Compaction으로 맥락을 압축해 유지하되, 압축 결과를 '불투명한 상태'로 취급하고, 압축 전후 프롬프트 기능을 동일하게 유지하는 것이 핵심입니다.
또 고객-facing 글쓰기에서는 "세션 전체 성격(지속)"과 "이번 응답의 글쓰기 제약(일회성)"을 분리하면 제어가 쉬워집니다. 예를 들어 페르소나는 유지하되, 이번엔 "이메일, 산문만, 150단어 이하"처럼 아티팩트 제약을 별도로 거는 방식입니다.
추론 노력(reasoning_effort) 튜닝과 마이그레이션 순서
추론 노력은 만능 스위치가 아니라 마지막 미세조정 노브로 다루는 게 좋습니다. 많은 경우 <completeness_contract>, <verification_loop>, <tool_persistence_rules> 같은 프롬프트 장치가 비용 대비 효과가 더 큽니다.
권장 감각은 이렇습니다. 빠른 실행/추출/분류/짧은 변환은 none이나 low에서 시작하고, 장문 종합·다문서 검토·모순 조정·전략 글쓰기는 medium 이상을 고려합니다. xhigh는 기본값으로 두기보다, 평가(evals)에서 확실히 이득이 보일 때만 쓰는 쪽이 안전합니다.
마이그레이션은 "한 번에 하나만 바꾸기"가 핵심입니다. 모델만 먼저 바꾸고 추론 노력은 고정한 뒤 평가를 돌리고, 그 다음에 프롬프트 블록을 추가하거나 추론 노브를 한 단계씩 올리는 순서를 추천합니다.
인사이트
GPT-5.4 활용의 요령은 "더 생각하게 만들기"보다 "덜 흔들리게 만들기"입니다.
출력 계약(형식), 도구 규칙(조회·의존성), 완료 기준(전부 처리/[blocked]), 검증 루프(요구·근거·형식·허가)까지 네 가지를 먼저 고정하고, 그래도 부족할 때만 reasoning_effort를 올리면 비용과 품질을 동시에 잡기 쉽습니다.
출처 및 참고 : Prompt guidance for GPT-5.4 | OpenAI API
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.