OpenAI, GPT-6 모델 선택·추론 강도·도구 사용 가이드 공개

AI 요약

OpenAI가 GPT-6 모델군을 실제 개발 작업에 적용하는 방법을 소개했습니다. 프로토타입 제작부터 코드 저장소·데이터베이스·외부 API를 아우르는 장시간 작업까지, 모델 선택과 추론 강도 설정, 프롬프트 작성, 운영 준비를 다룹니다. 가이드는 기능 목록만 나열하지 않고 비용과 지연 시간, 작업 성공률을 함께 측정해 업무에 맞는 조합을 찾으라고 권합니다.

작업에 맞는 모델과 추론 강도 선택

가이드는 모델, 추론 강도, 응답 속도를 함께 조정해 성능과 비용의 균형을 맞추라고 안내합니다. 가장 어려운 추론 작업에는 GPT-6 Astra를, 복잡한 코딩·조사·컴퓨터 사용에는 GPT-6.1 Sol을, 송장 필드 추출이나 요청 분류처럼 목표가 분명하고 반복되는 작업에는 GPT-6 Luna를 제안합니다. 모델별 가격도 비교해 선택해야 합니다.

API에서는 작업의 난도에 따라 추론 강도를 설정합니다. 사실 추출이나 작은 수정에는 Low, 기능 계획이나 선택지 비교처럼 판단이 필요한 일에는 Medium, 어려운 디버깅과 심층 분석에는 High를 권합니다. High로도 부족할 때 Extra high 또는 Max를 시험하되, 품질 개선이 추가 시간과 비용을 감당할 만큼 큰지 확인하라고 합니다. Codex에서는 우선 모델 기본값으로 시작한 뒤 간단한 작업은 낮추고 깊은 분석에는 높이는 방식입니다.

응답 시간이 중요한 채팅 앱이나 코딩 도구에서는 API의 Fast 모드를 고려할 수 있습니다. Standard보다 토큰당 비용은 높지만 응답을 더 빠르고 일관되게 제공합니다. Ultrafast는 토큰 생성 속도를 추론 강도와 별도로 높이며 GPT-6 Astra에서 사용할 수 있다고 설명합니다.

프롬프트 캐싱과 운영 준비

운영 전에는 작업에 필요하지 않은 문맥을 줄이되 판단 근거는 남기고, 서로 의존하지 않는 작업은 병렬로 실행해 한 단계의 지연이 다른 작업까지 막지 않도록 해야 합니다. 반복 작업에는 프롬프트 캐싱을 활용합니다. 모델에 따라 캐시된 입력 토큰 비용은 캐시하지 않은 입력보다 최대 95% 낮습니다. 캐시 재사용을 높이려면 안정적인 지침과 참고 자료를 프롬프트 앞부분에 두고, 작업마다 바뀌는 내용은 뒤에 배치하며 도구 정의도 일관되게 유지해야 합니다. 비용을 계산할 때는 캐시 쓰기 비용과 긴 문맥 요금도 포함합니다.

대화가 길어지면 compaction으로 이어서 작업하는 데 필요한 상태를 보존하면서 문맥 크기를 줄일 수 있습니다. 배포 전 대표 작업으로 성공률, 지연 시간, 성공한 작업당 비용을 측정하고, 동작 모니터링과 데이터 제어 방안도 정해야 합니다.

지침을 명확히 하고 장시간 작업을 관리

프롬프트에는 원하는 결과, 대상 독자, 맥락과 제약, 완료 기준을 적어야 합니다. 스킬 설명은 짧고 명확하게 작성하고, 필요한 세부 자료는 필요할 때 불러오도록 구성합니다. AGENTS.md에는 어떤 문서와 테스트가 관련 있는지 적고, 운영 환경에 접근하지 않는 일회용 데이터로 로컬 테스트를 실행하는 등 안전한 반복 작업은 명시적으로 허용하라고 안내합니다.

모델이 독립적으로 결정해도 되는 일과 승인이 필요한 일을 구분하는 것도 중요합니다. 모든 단계에서 허락을 구하라는 포괄적인 규칙 대신 결정 경계를 정하고, 완료 기준에는 변경 구현뿐 아니라 실행, 결과 확인, 실패 수정까지 포함합니다. 요약의 구성은 모델이 선택해도 되지만 프로젝트 범위를 바꾸기 전에는 확인을 요청하는 식으로 권한을 구체화할 수 있습니다.

API에서는 작업 중 지침을 바꾸는 steering, 비동기 도구 호출, 독립 하위 작업 위임을 활용합니다. Responses WebSocket API의 mid-turn steering은 모델이 작업하는 동안 수정 지침을 전달합니다. 이미 실행 중인 도구를 취소하거나 끝난 작업을 되돌리지는 않고, 업데이트를 대기열에 넣습니다. 비동기 도구 호출을 쓰면 애플리케이션이 테스트처럼 오래 걸리는 작업을 실행하는 동안 모델은 독립 작업을 이어갈 수 있습니다. 다만 그 결과에 의존하는 작업은 결과를 받은 뒤 시작해야 합니다. GPT-6.1 Sol은 Responses API에서 멀티 에이전트 작업을 지원하며, 하위 에이전트가 코드베이스의 서로 다른 부분을 조사한 뒤 결과를 합칠 수 있습니다. 이 기능은 베타입니다.

Codex에서는 작업 중 생기는 질문에 답하거나 요구사항 변경에 맞춰 진행 방향을 조정할 수 있습니다. 자리를 비울 예정이라면 답변 전에도 계속할 수 있는 작업과 멈춰야 하는 시점을 미리 알려야 합니다. 컴퓨터 사용 기능은 GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna가 API가 없는 웹사이트나 데스크톱 앱과 상호작용하게 합니다. API나 연결된 도구로 직접 처리할 수 있으면 그 방법을 우선하고, 화면을 읽거나 버튼을 누르고 양식을 채워야 할 때 컴퓨터 사용을 선택하라고 안내합니다. 브라우저 제어에는 Playwright, 데스크톱 앱 제어에는 PyAutoGUI를 예로 듭니다.

Reddit 반응

• @u/ElGatoSaez — 저는 모든 작업에서 High를 씁니다.
  • @u/AnonymousTimewaster — 채팅 모드에서는 High를 쓰지만, 6에서는 작업 모드 크레딧이 꽤 빨리 바닥납니다.
  • @u/the_ai_wizard — 저는 이게 유일한 방법이라고 봅니다. 요즘 High가 예전 Medium 수준 같아서 Extra high를 씁니다.
• @u/stangerlpass — 자동 모드가 있어야 하지 않나요? 추론 강도를 뭘로 할지 걱정하고 싶지 않습니다. 선택 가이드를 글로 쓸 수 있다면 모델을 자동으로 선택하도록 만들거나 학습시킬 수도 있을 것 같습니다.
  • @u/space_raffe — 여러 방식으로 시도했지만, 제가 본 반응으로는 결과가 꽤 좋지 않았던 것 같습니다. 직접 선택하는 관행이 시간이 지나며 자리 잡을 수도 있습니다. 앞으로 구독 조건이 더 엄격해진다면 사용량을 최적화하는 법을 익혀야 할 수도 있습니다.
  • @u/JoshSimili — 자동으로 처리하기는 거의 불가능합니다. 역할극에서는 빠른 응답을 원할 수 있지만, 정답이 중요한 복잡한 작업에는 추론 모델이 필요합니다. 자동 라우터가 난도를 제대로 판단하려면 느려질 수 있고, 빠른 사용 상황에서는 난도를 낮게 잡을 수도 있습니다. 사용자가 얼마나 기다릴 수 있는지, 오류 가능성과 사용량 예산을 얼마나 감수할지도 프롬프트만으로 알기 어렵습니다. 그래서 자동 선택이 사용자의 직접 선택만큼 나아질지 모르겠습니다.
• @u/Charizarlslie — Codex로 취미 프로젝트를 만들 때 GPT-6 Luna를 계속 Max로 쓰는데, 5시간이나 주간 한도에 가까워지지 않고 잘 작동합니다. 아주 이상한 문제가 생기거나 수정이 필요하면 Sol로 바꿔 해결 계획을 세우게 한 뒤, 거의 제한 없이 쓸 수 있는 Luna Max로 돌아옵니다.
  • @u/sleafordbods — 앱에 Luna를 써봤는데 코딩을 시작하기도 전에 사용량이 최대치에 도달했습니다.
• @u/anonymuse — 추론 강도를 전부 High로 올리기 전에 skills와 AGENTS.md부터 확인하겠습니다. 지침을 잘 따르는 모델은 나쁜 지침도 더 잘 따를 수 있습니다. “항상 먼저 물어보라”는 규칙은 간단한 작업에서도 허락을 다섯 번씩 구하게 만들 수 있습니다. 기존 지침과 짧고 정돈된 지침을 같은 작업으로 비교해보면 좋겠습니다. 먼저 완료 기준, 승인이 필요한 결정, 관련 있는 검사를 점검하고, 결과 수정에 든 시간까지 포함해 설정을 비교해야 합니다. 새 모델이 나빠졌다는 불만 중 일부는 지침 문제가 더 잘 드러난 결과일 수도 있습니다. 기존 설정과 더 간결한 설정을 비교해본 사람이 있나요?
• @u/Morning_Gecko24 — 여기서 유용한 점은 추론 강도를 모든 작업에서 최대로 두지 않고 예산처럼 다룬다는 겁니다. 추가 추론이 실제로 이득을 주는 시점과 지연 시간만 늘리는 시점을 사람들이 어떻게 판단하는지 궁금합니다.

원문: OpenAI / 번역·요약: Trawling