GPT-6 Astra, 설정부터 다시 봐야 한다

결과물 자랑보다 먼저 볼 게 있습니다. 전역 지침은 그대로 둬도 되는지, 추론은 무조건 높여야 하는지, 긴 작업의 문맥은 어떻게 유지할지입니다. 공개 이틀째 기준으로 공식 문서와 초기 사용자 반응을 맞춰봤습니다.

새 모델인데 프롬프트를 더 길게 써야 할까?

오히려 먼저 할 일은 기존 지침을 더하는 게 아니라 점검하는 것에 가깝습니다.

OpenAI의 Astra 모델 가이드는 이전 모델보다 일반적인 지시 이행 능력이 좋아졌지만, 그만큼 skill이나 AGENTS.md 같은 파일 안의 지시에도 더 민감하다고 설명합니다. 애매하거나 서로 충돌하는 규칙이 있으면 모델이 일찍 멈추거나 엉뚱한 방향으로 갈 수 있어, 접근 가능한 지침 파일을 감사하라고 아예 권고하고 있어요.

GPT-4·5 시절에 모델을 붙잡아 두려고 덧붙인 문장이 많다면 Astra에서는 한 번 정리할 이유가 생겼습니다.

그렇다고 짧은 프롬프트가 무조건 정답이라는 뜻은 아닙니다. Astra는 긴 지시도 더 잘 따릅니다. 핵심은 길이가 아니라 우선순위가 분명하고 서로 모순되지 않는가입니다.

제가 먼저 손볼 건 전역 지침입니다

예전 모델 때문에 넣은 보정 문구가 겹쳐 있다면 줄여볼 만합니다. 예를 들어 “항상 먼저 질문해라”와 “질문하지 말고 끝까지 수행해라”가 같이 있거나, 전역 지침과 프로젝트의 AGENTS.md가 서로 다른 완료 조건을 요구하는 식입니다.

공식 가이드도 사용자 지시와 skill의 우선순위를 명확히 하고, 모델이 권한 확인 때문에 계속 멈춘다면 어떤 skill과 어떤 문장이 원인이었는지 드러내도록 지시하는 방법을 제안합니다.

반대로 “Astra 전용 만능 시스템 프롬프트”를 길게 붙여야 한다는 근거는 찾기 어렵습니다. OpenAI가 제시하는 보정도 문제가 생긴 행동에 맞춰 자율 실행, 문체, 테스트 범위처럼 필요한 부분을 좁게 조절하는 방식입니다.

추론 레벨, 무조건 High나 Max는 아닙니다

API의 GPT-6 Astra는 low, medium, high, xhigh, max 다섯 단계를 지원합니다. 이전의 none은 지원하지 않습니다.

여기서 중요한 건 OpenAI의 마이그레이션 권고입니다. 기존에 none이나 minimal을 썼다면 우선 low에서 비교하고, 그렇지 않았다면 기존에 실제로 쓰던 reasoning effort를 유지한 채 비교하라고 합니다. 처음부터 전부 Max로 올리라는 권고가 아닙니다.

실제로 공개 직후 Reddit의 Codex 사용자 중에는 Sol에서 High를 쓰다가 Astra에서는 Medium을 쓰는데도 빠르고 이전 모델이 놓친 버그를 찾았다는 사례가 있습니다. 반대로 Very High에서 아주 단순한 질문 하나가 사용량을 크게 소모했다는 게시물도 올라왔습니다.

둘 다 개인 사례입니다. “Medium이 정답”이라는 증거가 아니라, 높은 추론을 기본값처럼 고정할 이유도 아직 없다는 참고 자료로 보는 게 맞습니다.

API라면 더 좋은 방법도 생겼습니다

Astra의 Responses API에는 대화 중 reasoning effort를 바꾸는 configuration_update가 추가됐습니다.

평소에는 낮거나 중간 수준으로 진행하다가 어려운 구간에서만 추론을 높이고, 다시 평범한 후속 작업에서는 내릴 수 있습니다. 이때 원래 프롬프트 앞부분을 다시 쓰지 않아도 돼 prompt cache를 유지할 수 있다는 게 포인트입니다.

그래서 API를 직접 쓰는 서비스라면 “모든 요청 High”보다 난이도에 따라 reasoning을 바꾸는 구조가 더 흥미로운 최적화 지점입니다.

Codex 장기 작업은 이 옵션을 볼 만합니다

이번에 가장 실용적으로 보이는 변화 중 하나는 Codex의 새로운 문맥 보존 방식입니다.

기존에는 context window가 차면 compaction으로 이전 작업을 요약했습니다. 긴 디버깅이나 대규모 리팩터링에서는 “왜 이 방법이 실패했는지”, “앞에서 어떤 테스트가 깨졌는지” 같은 세부 정보가 압축 과정에서 빠질 수 있었죠.

Astra는 Codex에서 context window를 넘겨 노트를 유지하고, 이전 context window를 다시 검색할 수 있는 실험 기능을 제공합니다. OpenAI는 config.toml에서 켤 수 있고 향후 몇 주 안에 Astra의 기본값으로 만들 예정이라고 밝혔습니다.

몇 시간짜리 리팩터링·디버깅 세션을 자주 한다면, 이번 설정 중에서는 이 기능이 가장 먼저 시험해볼 만해 보입니다.

1M 문맥이 생겼다고 아무거나 다 넣는 건 아닙니다

API 모델 페이지 기준 Astra의 context window는 1,050,000 토큰입니다. OpenAI가 공개한 장문맥 평가에서도 512K~1M 구간 성능이 이전 Sol보다 크게 좋아졌습니다.

하지만 입력이 272K 토큰을 넘으면 해당 요청 전체의 입력·캐시 요율이 2배, 출력 요율이 1.5배가 됩니다. “문맥이 넓으니 저장소 전체를 매번 밀어 넣자”는 식은 비용 측면에서 별개 문제예요.

오히려 필요한 컨텍스트를 찾게 하고, 장기 작업에서는 새 문맥 보존 기능을 활용하는 쪽을 먼저 검토할 만합니다.

가격이 비싸니 Low만 써야 한다? 이것도 단순합니다

Astra API 가격은 100만 토큰당 입력 10달러, 출력 50달러입니다. 숫자만 보면 부담스럽습니다.

그런데 OpenAI의 Terminal-Bench 4.0 평가에서는 Astra가 Sol보다 높은 점수를 내면서도 작업당 추정 API 비용은 약 9% 낮았습니다. GPQA Diamond의 낮은 비용 설정에서도 Sol 최고 점수를 넘어가면서 추정 비용이 약 37% 낮았다고 설명합니다.

즉 토큰 단가는 비싸지만 일을 끝내는 데 필요한 토큰과 반복 횟수가 줄면 총비용은 달라질 수 있습니다. 실제 서비스에서는 토큰 단가보다 성공한 작업 1건의 총비용을 비교하는 편이 낫습니다.

ChatGPT, Codex, API 설정을 섞으면 안 됩니다

SNS 팁을 볼 때 가장 먼저 구분할 부분입니다. configuration_update나 272K 이후 API 요율은 API 이야기이고, config.toml의 새 문맥 보존은 Codex 이야기입니다. 일반 ChatGPT 설정처럼 소개하면 틀립니다.

Astra 자체도 9월 3일 공개됐고, 9월 5일 현재 제한된 조직부터 순차 배포 중입니다. Plus·Pro·Business·Enterprise와 API의 더 넓은 제공은 며칠에 걸쳐 진행되는 단계라, 지금 올라오는 “최적 설정”은 장기간 검증된 사용법이라기보다 초기 체감담이 많습니다.

지금 바꿀 것과 굳이 안 바꿀 것

그래서

Astra가 나왔다고 사용법을 전부 갈아엎을 필요는 없어 보입니다. 오히려 반대입니다. 예전 모델을 보정하려고 쌓아둔 규칙을 걷어내고, 필요한 지침만 명확하게 남기는 것부터 해볼 만합니다.

추론도 무조건 최대로 두기보다 실제 작업 난도에 맞춰 올리고 내리는 편이 공식 권고와 더 가깝습니다. Codex에서 긴 작업을 자주 한다면 새 문맥 보존 기능은 직접 비교해볼 가치가 있고요.

아직 공개 이틀째입니다. SNS의 “이 설정이 정답”이라는 말은 조금 더 지켜봐야 합니다. 앞으로 실제 사용 데이터가 쌓이면 Medium과 High의 사용량·완료율, 장기 문맥 보존 전후의 재작업 차이가 더 중요한 비교 기준이 될 것 같습니다.

출처: OpenAI GPT-6 Astra 공식 발표·Model guidance·GPT-6 Astra API 모델 페이지·Release notes. 초기 사용자 반응은 2026.09.05 Reddit r/codex·r/ChatGPT 공개 게시물 일부를 참고했으며 전체 사용자 반응으로 일반화하지 않았습니다.