LLM Wiki

OpenAI GPT-5.6 Sol 프롬프트 가이드 — 결과·성공 기준·중단 조건 중심 설계

Properties2
descriptionGPT-5.6 Sol은 절차를 길게 지시하기보다 목표·성공 기준·제약·근거·중단 조건을 명확히 정의한 프롬프트에서 잘 작동한다.
tagsai-models, ai-coding, prompt-engineering, agent-harness, optimization

15 min read

개요

OpenAI의 GPT-5.6 Sol 프롬프트 가이드는 모델에게 모든 절차를 세세하게 지시하기보다 최종 결과, 성공 기준, 중요한 제약, 사용할 근거와 도구, 완료·중단 조건을 명확히 정의하라고 권장한다. 모델이 효율적인 경로를 선택할 여지를 남기되, 안전·권한·검증·출력 형식처럼 실제 결과를 바꾸는 계약은 분명하게 유지하는 접근이다.

이 가이드는 gpt-5.5에서 GPT-5.6으로 마이그레이션하거나, moc-ai-coding에 속한 코딩 에이전트와 moc-ai-agents-harness 기반 하네스를 최적화할 때 참고할 수 있다.

핵심 주장

가이드는 반복 지시와 불필요한 예시·도구 설명을 줄이면 성능과 비용을 함께 개선할 수 있다고 설명한다. OpenAI의 내부 코딩 에이전트 eval 표본에서는 프롬프트를 간소화한 설정이 다음과 같은 방향성 있는 변화를 보였다.

  • 평가 점수 약 10~15% 개선
  • 전체 토큰 약 41~66% 감소
  • 비용 약 33~67% 감소

이는 특정 내부 워크로드의 결과이며 모든 애플리케이션에 그대로 일반화할 수 없다. 실제 대표 task와 기존 eval을 고정한 뒤, 지시를 하나씩 제거하면서 품질·토큰·지연·비용을 함께 측정해야 한다.

프롬프트를 먼저 단순화하기

줄일 것

  • 같은 규칙을 여러 번 반복하는 문장
  • 모델의 행동을 바꾸지 않는 스타일·프로세스 지시
  • 결과에 영향을 주지 않는 예시
  • 모델이 이미 안정적으로 수행하는 절차 설명
  • 현재 작업과 무관한 도구와 긴 도구 설명

남길 것

  • 사용자가 보게 될 최종 결과
  • 성공 기준과 종료 조건
  • 안전·비즈니스·근거·권한 제약
  • 상황에 따라 달라지는 도구 라우팅 규칙
  • 필수 출력 형식과 검증 조건

GPT-5 계열은 프롬프트 계약을 밀접하게 따르므로, 누락보다 서로 충돌하는 규칙이 더 큰 불안정성을 만들 수 있다. 따라서 길이를 줄이는 것만이 아니라 남은 지시 사이의 모순도 점검해야 한다.

결과 우선 프롬프트와 중단 조건

모든 행동 순서를 강제하기보다 목적지를 정의한다.

고객 문제를 끝까지 해결하라.
 
성공 기준:
- 정책과 계정 근거로 자격을 판단한다
- 허용된 조치를 완료한다
- completed_actions, customer_message, blockers를 반환한다
- 필수 근거가 없으면 가장 작은 누락 필드만 질문한다

불필요한 ALWAYS, NEVER, must, only는 줄이고, 실제 불변 조건에만 사용한다. 검색·질문·도구 사용·반복 여부처럼 판단이 필요한 영역은 절대 규칙 대신 decision rule로 표현한다.

또한 다음과 같은 중단 조건을 둔다.

  • 가능한 적은 유효한 도구 루프로 처리한다.
  • 루프 횟수보다 정확성·필수 근거·계산·인용을 우선한다.
  • 각 결과를 받은 뒤 핵심 요청에 답할 수 있는지 판단한다.
  • 필수 근거가 부족하면 누락된 사실을 밝히고 가장 작은 유효 fallback을 사용한다.
  • 단순히 표현을 개선하거나 부가 예시를 추가하기 위해 검색을 반복하지 않는다.

성격·협업 방식·응답 길이

GPT-5.6 Sol은 GPT-5.5보다 기본적으로 더 간결한 경향이 있으므로, 기존의 광범위한 Be concise 지시가 여전히 필요한지 확인해야 한다. 기본 상세도는 API의 text.verbosity로 설정하고, 프롬프트에는 작업별 길이·구조·필수 내용을 적는 방식을 권장한다.

성격(personality)과 협업 방식(collaboration style)은 분리한다.

  • 성격 — 말투, 온도감, 직접성, 격식, 유머, 공감, 완성도
  • 협업 방식 — 질문 시점, 가정 허용 범위, 주도성, trade-off 설명, 검증, 불확실성 처리

짧은 답변이 필요할 때는 무조건 줄이라고 하지 말고, 보존해야 할 정보의 우선순위를 지정한다.

결론부터 말한다. 결론을 뒷받침하는 근거와 중요한 주의사항,
다음 행동을 포함한다. 도입부·반복·일반적인 안심 표현·부가 배경은 줄인다.

자율성과 승인 경계

GPT-5.6 Sol은 다단계 작업에서 적극적이고 지속적으로 행동할 수 있으므로, 허용된 자율성의 범위를 한 곳에서 정의한다.

답변·설명·검토·진단·계획 요청:
관련 자료를 확인하고 결과를 보고한다. 구현 변경은 하지 않는다.
 
변경·빌드·수정 요청:
범위 내 로컬 변경을 수행하고 비파괴 검증을 실행한다.
 
외부 쓰기·삭제·구매·비용 발생·범위 확장은 확인을 요구한다.

읽기, 파일 검사, 범위 내 편집, 테스트 같은 안전한 로컬 행동은 명시적으로 허용할 수 있다. 반대로 외부 시스템 변경, 파괴적 작업, 구매, 비용이 드는 작업은 승인 경계 밖에 둔다. 연구·설계·구현·리뷰·외부 조정을 서로 다른 작업 층으로 구분하면 모델이 조용히 다음 단계로 넘어가는 것을 막을 수 있다.

도구 라우팅과 Programmatic Tool Calling

작업과 관련된 도구만 노출하고, 각 도구의 용도·사용 시점·반환 필드·오류 동작을 설명한다. prerequisite lookup이나 검증이 필요한 작업은 최종 상태가 명확해 보여도 해당 단계를 건너뛰지 않도록 한다.

독립적인 조회는 병렬화하고, 한 결과가 다음 행동을 결정하면 순차적으로 처리한다. 빈 결과·부분 결과·비정상적으로 좁은 결과가 나오면 의미 있는 fallback을 한두 번 시도한다.

Programmatic Tool Calling(PTC)은 다음처럼 데이터 축약 경계가 분명한 경우에 적합하다.

  • 필터링·정렬·순위화·조인·중복 제거
  • 여러 레코드의 배치 처리
  • 반복적인 결정론적 검증
  • 큰 구조화 결과를 작은 schema로 축약

단순히 여러 도구를 병렬 호출한다는 이유만으로 PTC를 사용할 필요는 없다. PTC를 쓸 때는 허용된 도구, 출력 schema, retry 횟수, stop condition과 direct model judgment로 돌아오는 handoff를 명시해야 한다.

근거·검색·인용

근거 기반 답변에서는 무엇을 인용해야 하는지, 어느 정도의 증거가 충분한지, 증거가 없을 때 어떻게 행동할지를 프롬프트에 포함한다.

  • 검색된 출처만 인용한다.
  • 인용은 해당 주장을 직접 뒷받침하는 위치에 붙인다.
  • 직접 확인된 사실과 추론을 구분한다.
  • 출처 간 충돌을 표시한다.
  • 근거가 부족하면 추측하지 말고 답변 범위를 줄이거나 누락 근거를 밝힌다.
  • 증거 부재를 곧바로 사실의 부재로 해석하지 않는다.

장기 작업과 상태

다단계·도구 중심 작업에서는 첫 도구 호출 전에 한두 문장의 사용자 표시 preamble을 보내고, 이후에는 주요 단계가 바뀔 때만 결과 중심으로 업데이트한다. 일상적인 도구 호출을 모두 중계하듯 설명하지 않는다.

  • 주요 milestone 뒤에 context를 compact한다.
  • 이전 응답을 재생할 때 assistant phase 값을 유지한다.
  • 장기 상태의 목표·가정·우선순위가 바뀌었으면 오래된 reasoning을 그대로 재사용하지 않는다.
  • 재사용 가능한 prompt prefix를 안정적으로 유지해 prompt caching을 방해하지 않는다.

Reasoning effort

현재 reasoning effort를 baseline으로 삼고, 대표 task에서 같은 수준과 한 단계 낮은 수준을 비교한다.

  • low — latency가 중요하고 품질이 유지될 때
  • medium — 균형 잡힌 기본값
  • high·xhigh — eval에서 의미 있는 품질 향상이 확인될 때
  • max — 가장 어려운 품질 우선 작업에 한정

Reasoning을 올리기 전에 성공 기준, 의존성 규칙, 도구 라우팅, 검증 루프가 프롬프트에 빠져 있지 않은지 먼저 확인한다.

프론트엔드·시각 작업

GPT-5.6 Sol은 레이아웃·시각적 위계·디자인 판단이 강화되었지만, 기존 디자인 토큰·컴포넌트·반응형 동작을 보존하도록 명시해야 한다.

증분 UI 변경에서는 다음을 지킨다.

  • 기존 디자인 시스템과 컴포넌트 패턴을 먼저 검사한다.
  • 요청하지 않은 장식이나 추가 기능을 넣지 않는다.
  • 반응형 동작과 상태를 보존한다.
  • 최종 전에 렌더링하고 clipping·spacing·누락 콘텐츠·일관성을 확인한다.

완료 전 검증

코딩 작업에서는 변경 범위에 맞는 검증 도구를 제공하고, 무엇을 확인해야 하는지 프롬프트에 적는다.

  • 변경 동작에 대한 targeted test
  • 해당하는 경우 type check·lint
  • 영향받은 패키지의 build
  • 전체 검증이 비싸면 최소 smoke test

검증을 실행할 수 없다면 이유와 차선의 확인 방법을 보고한다. 시각 산출물은 렌더링 후 레이아웃·clipping·spacing·누락 콘텐츠를 검사하고 요구사항에 맞을 때까지 수정한다.

권장 구조와 마이그레이션 순서

복잡한 프롬프트의 시작점으로 다음 순서를 사용한다.

Role
Personality
Goal
Success criteria
Constraints
Tools
Output
Stop rules

GPT-5.6으로 마이그레이션할 때는 한 번에 프롬프트를 다시 쓰지 않는다.

  1. 모델을 바꾸되 기존 reasoning effort를 유지한다.
  2. 프롬프트 변경 전에 대표 eval을 실행한다.
  3. 낡은 scaffolding·반복 지시·무관한 도구를 제거한다.
  4. 측정된 regression을 고치는 최소한의 지시만 추가한다.
  5. 매번 같은 eval을 다시 실행한다.

프롬프트가 regression을 일으키면 실제 trace를 작은 세트로 추려 실패 양상을 확인하고, 원인이 되는 지시나 모순을 surgical edit한 뒤 같은 케이스를 반복 검증한다.

실전 적용 메모

이 가이드는 긴 시스템 프롬프트를 계속 추가하는 방식보다, 얇은 Planner·Builder·Verifier 계약을 만들고 각 단계의 성공·권한·검증·중단 조건을 분리하는 방향과 잘 맞는다. 특히 도구를 많이 붙인 에이전트에서는 다음 순서가 유효하다.

  1. 현재 prompt·tool set의 representative eval을 고정한다.
  2. 반복 지시와 실제 사용되지 않는 도구를 제거한다.
  3. 결과·성공 기준·stop rule을 먼저 복원한다.
  4. reasoning effort를 한 단계 낮춰 품질·지연·비용을 비교한다.
  5. validation loop와 evidence requirements가 유지되는지 확인한다.

OpenAI의 수치 자체는 내부 eval 표본에 대한 주장이지 독립 재현 결과가 아니다. 따라서 이 문서의 방향은 채택하되, 사용자 workload에서 token·latency·cost·quality를 함께 측정해 판단해야 한다.

백링크