GPT-6 API·Codex 실전, 추론 강도 전환부터 캐싱·장시간 작업까지

# GPT-6 API·Codex 실전, 추론 강도 전환부터 캐싱·장시간 작업까지

GPT-6 API로 기능과 에이전트를 만드는 개발자를 위한 단계별 실무 가이드 (2026년 10월 2일 공식 모델 가이드 기준)

2026년 10월 2일, OpenAI가 'GPT-6 제품군 모델 가이드'를 냈습니다. 프로토타입 구현, 기능 개발과 테스트, 코드 저장소·DB·외부 API를 잇는 여러 단계 워크플로를 GPT-6로 만들 때 필요한 모델 선택, 지시 작성, 장시간 작업 관리, 운영 배포 준비를 한 흐름으로 다룬 문서입니다.

이 글은 그 흐름을 따라가면서, 가이드에 없는 파라미터 이름과 제약은 개발자 문서로 보충합니다. 글을 다 읽고 나면 아래 일곱 가지를 직접 해볼 수 있습니다. 😊

① 모델별 API 제약을 확인하고 gpt-6.1-sol로 안전하게 옮기기
② GPT-6 추론 강도를 고르고, 대화 중에 캐시를 깨지 않고 바꾸기
③ 속도 등급(Fast·Ultrafast)을 쓸지 판단하기
④ 스킬과 AGENTS.md 고쳐 쓰기
⑤ 장시간 작업 다루기(steering·비동기 도구·멀티 에이전트)
⑥ 컴퓨터 사용을 마지막 수단으로 두기
⑦ 배포 전에 GPT-6 프롬프트 캐싱과 측정 지표 점검하기

먼저 핵심 개념 하나만 잡고 가겠습니다. GPT-6 제품군은 세 모델로 나뉩니다. 최고 수준의 지능이 필요한 고난도 추론은 GPT-6 Astra(gpt-6-astra), 복잡한 코딩·리서치·컴퓨터 사용은 GPT-6.1 Sol(gpt-6.1-sol), 범위가 분명한 대량·반복 작업은 GPT-6 Luna(gpt-6-luna)입니다. 세 모델 모두 컨텍스트는 105만 토큰, 최대 출력은 12만 8천 토큰이고, 텍스트와 이미지를 입력받아 텍스트를 출력합니다. 가격과 업무별 선택은 기존 글 「GPT-6 Sol·Luna 출시, 반값 API 업무별 선택법」에서 자세히 다뤘으니, 이 글은 만드는 방법에 집중합니다.

모델별 API 제약부터 확인하고 gpt-6.1-sol로 옮기기

모델마다 허용되는 파라미터가 달라서, 코드를 옮기기 전에 제약표부터 확인해야 합니다. 같은 요청 코드를 그대로 다른 모델에 보내면 막히는 지점이 있습니다.

위 표에서 "문서에 명시 없음"은 지원하지 않는다는 뜻이 아니라, 이 글이 근거로 삼은 자료에 적혀 있지 않다는 뜻입니다. 쓰기 전에 모델 페이지에서 직접 확인해 주세요. 그 밖에 알아 둘 제약이 두 가지 더 있습니다.

첫째, 6.1 Sol은 Chat Completions에서 도구 호출을 하지 않습니다. 도구를 쓰는 에이전트라면 Responses API로 옮겨야 합니다.
둘째, EU 데이터 레지던시에서는 Fast mode를 쓸 수 없습니다.

6.1 Sol로 옮길 때 가장 먼저 볼 한 줄

기존 코드가 reasoning.effort를 none으로 쓰고 있었다면 low 이상으로 바꿔야 합니다. 6.1 Sol은 none과 minimal을 지원하지 않기 때문입니다. 이 한 줄을 놓치면 요청이 거절되므로, 이전 모델에서 옮길 때 가장 먼저 검색해 볼 값입니다.

```
"reasoning": {"effort": "low"}
```

가격 표기도 조심하세요. 6.1 Sol의 캐시된 입력 단가(100만 토큰당 $0.10)는 9월에 나온 GPT-6 Sol 등 다른 모델과 다른 가격입니다. 비용 계산서나 내부 문서에 단가를 적을 때는 반드시 모델 이름을 같이 적고, 이전 모델 가격과 섞지 마세요.

GPT-6 추론 강도 고르고, 대화 중에 캐시 깨지 않고 바꾸기

추론 강도는 일의 난이도에 맞춰 낮게 시작하고, 부족할 때만 올리는 것이 기본 원칙입니다. 쉬운 일은 낮게, 판단이 필요한 일은 중간, 어려운 디버깅과 심층 분석은 높게 둡니다.

Extra High(xhigh)와 Max는 High로 부족할 때 시험해 보는 단계입니다. 늘어난 시간과 비용만큼 결과가 나아질 때만 유지하세요. 나아지지 않는다면 High로 되돌리는 편이 낫습니다.

참고로 단계별로 어떤 작업을 배정하라는 예시 목록은 OpenAI 가이드와 개발자 문서(Reasoning)가 서로 다르게 들고 있습니다. 그래서 특정 예시 목록을 공식 기준이라고 단정할 수 없습니다. 위 원칙을 출발점으로 삼고, 여러분의 대표 작업으로 직접 측정해서 정하세요.

Step 1. 기본 강도를 요청에 지정하기

요청 수준에서 기본값을 정합니다. 6.1 Sol의 기본은 medium입니다.

```
"reasoning": {"effort": "medium"}
```

Step 2. 대화 도중에 강도만 바꾸기

여기서 많이들 실수합니다. 대화가 길어진 뒤 어려운 구간이 나왔다고 요청 수준의 reasoning.effort를 바꾸면, 앞부분이 달라져서 캐시가 깨질 수 있습니다. 대신 다음 사용자 메시지 앞에 configuration_update 항목을 끼워 넣으세요.

```
{"type": "configuration_update", "reasoning": {"effort": "high"}}
```

방법은 다음과 같습니다.

① 요청 수준의 reasoning.effort는 그대로 둡니다
② 다음 사용자 메시지 바로 앞 input 항목에 위 객체를 넣습니다
③ HTTP Responses 요청과 WebSocket response.create 모두 같은 방식입니다

이렇게 하면 원래 프롬프트의 앞부분이 그대로 유지되어 캐시가 깨지지 않습니다. 또 다른 업데이트가 덮어쓰기 전까지는 이후 응답에도 계속 적용됩니다. 다시 낮추고 싶으면 effort를 낮춘 configuration_update를 한 번 더 넣으면 됩니다.

주의할 점이 두 가지 있습니다.

첫째, GPT-6 제품군의 표준 단일 에이전트 모드에서만 동작합니다.
둘째, 바뀌는 것은 추론 강도뿐입니다. 모델이나 도구 같은 다른 설정은 이 방법으로 바꿀 수 없습니다.

속도 등급(Fast·Ultrafast)은 값을 더 낼 이유가 있을 때만

속도 등급은 지연 시간이 제품 가치에 직접 영향을 줄 때만 올리세요. 표준 등급으로 충분한 작업에 비싼 등급을 쓰면 비용만 늘어납니다.

Fast mode

service_tier를 "fast"로 주면 됩니다(예전 이름 "priority"도 같이 동작합니다). 최대 2.5배 빠르고 응답 시간이 고른 편입니다. 대신 토큰 단가는 표준의 2배입니다.

```
"service_tier": "fast"
```

알아 둘 점이 세 가지입니다.

① Astra의 Fast mode에는 지연 시간 SLA가 없습니다
② EU 데이터 레지던시에서는 Fast mode를 쓸 수 없습니다
③ 고객이 화면 앞에서 기다리는 실시간 흐름처럼 응답 시간의 편차가 문제인 곳에 어울립니다

Ultrafast

service_tier를 "ultrafast"로 주면 OpenAI API에서 가장 빠른 등급을 씁니다. 몇 배 빠르다는 수치는 문서마다 표현이 엇갈려서 여기서는 쓰지 않겠습니다. 확인된 조건은 다음과 같습니다.

① GPT-6 Astra에서 모든 API 사용자에게 낮은 속도 제한으로 열려 있습니다. 사용 등급별로 분당 50만(1~3등급)·100만(4등급)·500만(5등급) 토큰이며, 더 높은 한도는 계정팀에 문의합니다
② 가격은 Astra 기준 100만 토큰당 입력 $60·캐시 입력 $6·캐시 쓰기 $75·출력 $300으로, 표준의 6배입니다
③ 6.1 Sol은 Ultrafast 지원 목록에 없습니다
④ 미국 데이터 레지던시와 글로벌 처리만 되고, EU 등 지역 처리 엔드포인트는 안 됩니다
⑤ 도구 호출이 잦은 에이전트라면 WebSocket 연결을 강하게 권합니다

값을 낼 가치가 있는지 판단하는 순서

1. 먼저 표준 등급에서 지연 시간을 재 봅니다

2. 사용자가 기다리는 구간이 병목인지 확인합니다

3. 병목이면 Fast를 먼저 시험합니다(단가 2배)

4. Fast로도 부족하고 Astra가 꼭 필요한 구간에만 Ultrafast(단가 6배)를 시험합니다

야간 배치처럼 기다려도 되는 작업에는 속도 등급이 필요 없습니다. 오히려 Batch나 Flex를 쓰면 표준의 50% 단가로 처리할 수 있습니다.

스킬 설명과 AGENTS.md를 GPT-6 기준으로 고쳐 쓰기

예전에 도움이 되던 촘촘한 지시가 이제는 결과를 방해할 수 있으니, 스킬과 AGENTS.md를 새 기준으로 다듬어야 합니다. OpenAI 개발자 블로그(2026년 9월 11일)에 따르면, 모델이 미묘한 뜻과 모호함을 훨씬 잘 이해하게 되면서 지나치게 구체적인 지시가 오히려 방해가 될 수 있습니다.

이 섹션의 조언은 GPT-6 Astra 기준으로 쓰인 글에서 나온 것입니다. 지시문 자체를 쓰는 기본(결과·대상·맥락·완료 기준)은 기존 글 「챗GPT 앱에서 GPT-6 쓰는 법」에서 다뤘으니, 여기서는 파일을 어떻게 고치는지에 집중합니다. 또 저장소 스킬은 다른 모델을 쓰는 동료의 에이전트도 읽습니다. Sol이나 Luna에 도움이 되던 지시가 Astra에는 과한 제약이 될 수 있으니, 팀에서 쓰는 모델이 섞여 있다면 함께 점검하세요.

Step 1. 스킬 설명은 "언제 쓰는지"가 분명하게, 최대한 짧게

공식 예시를 그대로 옮깁니다.

나쁜 예:
```
Postgres 스키마 마이그레이션 생성·검증. DB·쿼리·모델·영속성 작업 시 사용
```

좋은 예:
```
Postgres 스키마 마이그레이션을 추가·변경하거나 그 적용(rollout)을 검토할 때 사용
```

나쁜 예는 "DB·쿼리·모델·영속성"처럼 범위가 넓어서, DB에 조금만 닿는 작업에도 스킬을 불러오게 만듭니다. 좋은 예는 호출 시점이 분명합니다. 스킬이 많아지면 Codex가 설명을 줄여서 넣기 때문에, 설명이 길고 흐릿할수록 고르기가 더 어려워집니다.

Step 2. 여러 흐름을 가진 스킬은 루트 문서를 안내판으로

한 스킬 안에 흐름이 여러 개라면, 루트 문서는 작은 안내판 역할만 하게 두세요. 세부 문서와 스크립트는 필요할 때만 읽도록 가리키기만 하면 됩니다. 처음부터 모든 내용을 한 문서에 몰아넣으면 매번 맥락이 늘어납니다.

Step 3. AGENTS.md는 "항상"을 "상황별"로

공식 가이드의 예를 수정 전·후로 보겠습니다.

수정 전:
```
매 수정 전에 architecture.md, database.md, deployment.md를 읽어라.
```

수정 후:
```
서비스 경계는 architecture.md, 스키마 변경은 database.md, 배포 준비 때는 deployment.md를 본다.
```

수정 전 문장은 아주 작은 수정에도 문서 세 개를 읽게 만듭니다. 수정 후는 상황에 맞는 문서만 가리킵니다.

Step 4. "항상 테스트하라"를 지우고, 안전한 흐름은 명시적으로 허락하기

Astra는 스스로 테스트를 돌립니다. 그래서 예전의 "항상 테스트하라" 지시는 불필요한 테스트를 부를 수 있습니다. 대신 안전한 일상 흐름을 분명히 허락하세요. 공식 예는 이렇습니다.

```
운영 환경 접근이 없는 일회용 데이터로 도는 로컬 테스트는 단계마다 승인받지 말고 실행한다.
요청한 변경 때문에 생긴 실패를 고친 뒤 다시 돌린다.
```

Step 5. 결정 범위와 완료 기준을 적기

스스로 할 수 있는 행동과 승인이 필요한 행동을 나눠 적으세요. 일괄적인 "항상 물어보기" 규칙은 분명한 기준으로 바꿉니다. 다른 모델을 막으려고 넣었던 강한 금지 문구도 점검 대상입니다. Astra는 그런 문구를 지나치게 무겁게 받아서, 계속해도 되는 일에서 멈출 수 있습니다.

완료 기준도 중요합니다. Astra는 첫 구현 뒤에 검토를 받으러 일찍 돌아올 수 있습니다. 그러니 구현, 실행, 결과 확인, 실패 수정까지를 '완료'로 정의해 주세요. 반대로 "첫 구현 뒤 검토를 위해 멈춰라"라고 쓰면 멈춤 지점이 앞당겨집니다. 응답 형태도 정해 두면 좋습니다. 바뀐 것, 확인한 것, 남은 주의점을 담은 짧은 인계 요약이 한 예입니다.

Step 6. 저장소 구조와 MCP 서버 정리

① 큰 프로젝트는 AGENTS.md를 저장소 안에 나눠 두어, 매번 들어가는 맥락을 줄입니다
② 쓰지 않는 MCP 서버는 끕니다. 서버마다 맥락이 늘어나 사용량을 더 쓰기 때문입니다

장시간 작업 다루기: steering·비동기 도구·멀티 에이전트·Codex 확인 질문

장시간 작업은 "시작하고 기다리기"가 아니라 중간에 방향을 돌리고, 오래 걸리는 도구를 병행하고, 필요하면 나눠 맡기는 방식으로 운영합니다. API 쪽 세 가지와 Codex 쪽 한 가지를 차례로 보겠습니다.

① 작업 방향 조정 (Responses API steering)

실행 중인 응답에 중간 지시를 보내는 기능입니다. Responses API WebSocket에서 동작합니다.

1. 응답을 만든 뒤 `response.created` 이벤트를 받습니다

2. 같은 연결로 `response.steer`를 보냅니다. 포함하는 필드는 type, previous_response_id, input뿐입니다

3. 서버에서 `response.steer.accepted`가 오면 대기열에 들어갔다는 뜻이지 반영이 끝났다는 뜻이 아닙니다

4. 반영된 응답은 서버가 자동으로 이어서 만듭니다. 이때 response.create를 다시 보내지 마세요

예외가 하나 있습니다. 도구 결과나 승인이 필요한 상황이면 `response.steer.pending`이 옵니다. 이때는 도구 결과를 담아 response.create를 보냅니다. 이미 받아들여진 steer는 다시 보내지 않습니다.

한계도 분명히 알아 두세요. steering은 이미 보낸 출력을 고치지 않고, 끝난 작업을 되돌리지 않으며, 이미 시작된 도구를 취소하지 않습니다. 그리고 GPT-6 제품군만 지원합니다(GPT-5.6 이하는 불가). 전체 이벤트 흐름 예제는 공식 steering 문서를 참고하세요.

② 비동기 도구 호출

함수나 커스텀 도구 정의에 `async: true`를 주면, 앱이 테스트처럼 오래 걸리는 도구를 돌리는 동안 모델이 독립적인 일을 계속 진행합니다. GPT-6 Astra 이후 모델에서 지원합니다.

```
"async": true
```

지킬 규칙은 세 가지입니다.

① 도구 실행은 여전히 앱의 몫입니다. 모델이 대신 실행해 주지 않습니다
② 결과는 원래의 call_id로 돌려줍니다
③ 그 결과에 기대는 일은 결과가 도착한 뒤에 시작해야 합니다

테스트를 돌리는 동안 문서를 정리하게 하는 것처럼, 서로 의존하지 않는 일이 있을 때 효과가 큽니다.

③ 멀티 에이전트 (베타)

GPT-6.1 Sol에서 베타로 쓸 수 있습니다. `multi_agent.enabled`를 켜고, 요청 헤더에 `OpenAI-Beta: responses_multi_agent=v1`을 붙입니다. 독립적인 하위 작업을 하위 에이전트에 맡기고 결과를 종합하는 방식입니다.

다만 토큰을 더 씁니다. 그리고 단계가 순서대로 이어지는 일이나 같은 자원을 함께 고치는 일에는 맞지 않습니다. 서로 독립적인 조사 여러 건을 동시에 맡기는 식으로 쓰세요.

④ Codex: 작업 중 확인 질문에 답하는 요령

Astra를 쓰는 Codex는 작업 도중 확인 질문을 할 수 있습니다. 이때 다음 순서로 응답하세요.

1. 다음 단계에 영향을 주는 질문에 먼저 답합니다

2. 결정하는 동안 계속해도 되는 독립 작업이 있으면 알려 줍니다

3. 자리를 비울 때는 "무엇은 계속하고, 어디서 답을 기다리며 멈출지"를 미리 말합니다

4. 요구 사항이 바뀌면 "무엇을 바꾸고 무엇을 유지할지"를 함께 알려 방향을 돌립니다

컴퓨터 사용은 API나 연결된 도구로 안 될 때만

화면을 눈으로 보고 클릭하는 방식은 가장 마지막에 고르세요. Astra, 6.1 Sol, Luna 세 모델 모두 웹사이트와 데스크톱 앱을 직접 조작할 수 있지만, 단계마다 가장 단순하고 믿을 만한 방법을 고르는 것이 원칙입니다.

판단 순서는 이렇습니다.

1. API나 연결된 도구로 되는 일인가? 그렇다면 그것을 씁니다

2. 안 된다면, 그때 화면을 읽고 버튼을 누르고 양식을 채우는 컴퓨터 사용을 씁니다

자체 앱에 컴퓨터 사용을 넣을 때는, 브라우저 조작은 Playwright 코드를, 데스크톱 조작은 PyAutoGUI 코드를 실행하는 도구를 모델에 쥐여 주는 방식입니다. 이때도 한 작업 안에서 단계마다 방법을 고르면 됩니다. 예를 들어 데이터 조회는 연결된 도구로 하고, 연동 API가 없는 관리자 화면에서 값을 입력하는 단계만 컴퓨터 사용으로 처리하는 식입니다.

배포 전 점검: 캐싱 배치, allowed_tools, 압축, 병렬화, 측정

운영 배포 전에는 캐시가 실제로 맞는지, 비용 추산에 빠진 항목이 없는지, 대표 작업으로 측정했는지를 확인하세요.

캐싱 배치 원칙

반복 작업은 프롬프트 캐싱으로 공통 맥락을 재사용합니다. 캐시된 입력은 모델에 따라 최대 95% 저렴합니다. 캐시는 30분 안에 다시 쓰는 공유 앞부분에 적용됩니다. 배치 원칙은 다음과 같습니다.

① 고정 지시와 참고 자료를 바뀌는 작업 내용보다 앞에 둡니다
② 도구 정의, 스키마, 순서를 일정하게 유지합니다
③ 명시적 캐시 중단점으로 캐시할 범위를 정합니다

도구가 바뀔 때, 지시가 바뀔 때

도구 목록이 달라져야 할 때 정의를 지워 버리면 앞부분이 달라져서 캐시가 깨집니다. 이렇게 하세요.

① 정의는 그대로 두고 `allowed_tools`로 호출 가능한 도구만 좁힙니다
② 도구를 아예 못 쓰게 하려면 `tool_choice`를 none으로 둡니다
③ 지시를 바꿀 때는 기존 지시를 고치지 말고, 맥락 끝에 새 개발자 메시지를 붙입니다

캐시 미스 진단

캐싱 대시보드와 진단 도구로 캐시 미스를 찾을 수 있습니다. `prompt_cache_diagnostics`에는 `tools_changed`처럼 미스 원인을 나타내는 표시가 들어옵니다. 캐시율이 기대보다 낮으면 먼저 이 진단부터 보세요.

비용 추산 시 빼먹기 쉬운 두 가지

비용을 추산할 때 캐시 쓰기 비용과 긴 컨텍스트 요금을 꼭 넣으세요.

① 캐시 쓰기는 미캐시 입력가의 1.25배입니다
② 입력이 27만 2천 토큰을 넘으면 요청 전체에 입력·캐시 단가 2배, 출력 단가 1.5배가 붙습니다. 일부 구간이 아니라 요청 전체에 적용됩니다

압축과 병렬화

긴 대화는 컨텍스트 압축(compaction)으로 줄입니다. 독립적인 작업은 동시에 돌려서, 느린 단계 하나가 전체를 붙잡지 않게 하세요.

측정 지표 3가지

배포 전에 대표 작업으로 다음 세 가지를 재세요.

① 작업 성공률
② 지연 시간
③ 성공한 작업당 비용

실패한 시도의 비용까지 성공한 작업 몇 건으로 나눠 보는 것이 포인트입니다. 추론 강도, 속도 등급, 모델 선택을 바꿀 때마다 이 세 숫자로 비교하면 판단이 쉬워집니다. 마지막으로 모니터링과 데이터 제어 설정, API 배포 체크리스트까지 확인하고 나가세요.

자주 하는 실수

옮기고 나서 막히는 대부분은 아래 다섯 가지 중 하나입니다.

① none을 그대로 둔 채 6.1 Sol로 교체: 6.1 Sol은 none과 minimal을 지원하지 않으니 low 이상으로 바꾸세요
② 대화 중 요청 수준의 effort를 직접 변경: 캐시가 깨질 수 있으니 configuration_update를 쓰세요
③ steer.accepted를 반영 완료로 착각: 대기열에 들어간 것뿐입니다. 반영은 서버가 자동으로 이어 만듭니다
④ 도구가 바뀔 때 정의를 삭제: allowed_tools로 좁히거나 tool_choice를 none으로 두세요
⑤ 모델 가격을 섞어서 문서에 기록: 6.1 Sol의 캐시 입력 단가($0.10)는 이전 모델 가격과 다릅니다. 모델 이름을 같이 적으세요

제대로 옮겨졌는지 확인하는 체크리스트

아래 항목을 위에서부터 확인하면, 글에서 다룬 모든 단계가 반영됐는지 점검할 수 있습니다.

① 코드에 reasoning.effort none·minimal이 남아 있지 않다(6.1 Sol 기준)
② 도구 호출은 Responses API에서 하고 있다
③ 대화 중 추론 강도 변경은 configuration_update로 하고, 변경 후에도 캐시 적중이 유지된다
④ 속도 등급은 지연 시간 측정 결과를 근거로 골랐고, 데이터 레지던시 조건(EU 등)과 충돌하지 않는다
⑤ 스킬 설명이 "언제 쓰는지"를 분명히 말하고 짧다
⑥ AGENTS.md가 상황별 안내로 바뀌었고, 안전한 로컬 테스트 허용과 완료 기준이 적혀 있다
⑦ 쓰지 않는 MCP 서버를 껐다
⑧ steering을 쓴다면 steer.accepted와 steer.pending 처리 분기가 구현돼 있다
⑨ 비동기 도구는 call_id로 결과를 돌려주고, 결과에 의존하는 일은 결과 도착 후에 시작한다
⑩ 비용 추산에 캐시 쓰기 1.25배와 27만 2천 토큰 초과 요금이 들어 있다
⑪ 작업 성공률·지연 시간·성공한 작업당 비용을 대표 작업으로 측정했다

자주 묻는 질문

Q. GPT-5.5를 쓰고 있는데 영향이 있나요?
GPT-5.5는 2026년 10월 14일 ChatGPT·Work·Codex에서 종료됩니다. OpenAI API는 이번 종료의 영향을 받지 않습니다. 다만 Codex나 ChatGPT에서 GPT-5.5로 작업하고 계셨다면 날짜 전에 다른 모델로 옮겨 두세요.

Q. 6.1 Sol에서 Ultrafast를 쓸 수 있나요?
현재 6.1 Sol은 Ultrafast 지원 목록에 없습니다. Ultrafast는 GPT-6 Astra에서 쓸 수 있고, 더 빠른 응답이 필요하면 6.1 Sol에서는 Fast mode를 검토하세요.

Q. 스킬·AGENTS.md 조언을 Sol이나 Luna 환경에도 그대로 적용해도 되나요?
이 조언은 GPT-6 Astra 기준 글에서 나온 것입니다. 저장소 스킬은 다른 모델을 쓰는 동료의 에이전트도 읽으므로, Sol과 Luna에 도움이 되던 지시가 Astra에는 과한 제약이 될 수 있다는 점은 확인된 사실입니다. 반대로 Astra용으로 줄인 지시가 다른 모델에서 충분한지는 직접 시험해 보세요.

오늘 바로 해볼 세 가지

처음부터 모든 것을 바꾸려고 하면 어디서 문제가 생겼는지 알기 어렵습니다. 그러니 순서를 정해서 하나씩 해보세요. 😊

① 코드에서 reasoning.effort none을 검색해 6.1 Sol에 맞게 바꿉니다
② AGENTS.md의 "항상 ~하라" 문장 하나를 상황별 안내로 고쳐 봅니다
③ 대표 작업 하나로 작업 성공률·지연 시간·성공한 작업당 비용을 재 봅니다

그 세 숫자가 이후 모든 선택(강도, 속도 등급, 모델)의 기준선이 됩니다. 이 글에서 파라미터 이름 위주로 다룬 부분의 전체 코드 예제는 OpenAI 개발자 문서의 steering, async tool calling, prompt caching, Reasoning 가이드에서 확인하실 수 있습니다.