GPT-6 아스트라, 솔보다 빠른데 사용 한도는 왜 빨리 닳나

아스트라로 작업을 마치는 시간은 줄어도 하루 동안 처리할 수 있는 일은 오히려 줄어들까. 클코단에서는 리팩터링 속도를 반기는 평가와 사용 한도를 걱정하는 경험담이 함께 나왔다. GPT-6 Astra의 공식 사용 조건과 브라우저 작업 방식을 살펴보면 솔에서 갈아탈 판단 기준이 구체화된다.

솔보다 빠르다는 평가는 어디까지 확인됐나

클코단에서는 코드 구조를 고치는 일을 적은 왕복으로 끝냈다는 초기 평가가 있었다. GPT-5.6 Sol보다 방향을 되짚는 과정이 줄었다고 느낀 이용자도 있었다. 반면 산출물을 충분히 검토한 뒤 판단해야 한다는 신중한 의견도 나왔다.

여기서 아스트라는 OpenAI의 GPT-6 Astra다. OpenAI 모델 가이드는 코드·브라우저·업무용 소프트웨어를 오가는 복잡한 작업에 강점을 둔다. Claude Code 이용자에게는 기존 작업을 맡길 비교 대상이지만 해당 경험을 Claude Code 자체의 업데이트로 읽어서는 안 된다. OpenAI는 일부 평가에서 이전 모델보다 출력 토큰을 적게 쓰면서 더 좋은 결과를 냈다고 설명한다. 토큰 단가가 높아도 작업당 추정 API 비용은 낮아졌다는 설명도 붙였다. 다만 제조사의 평가 결과가 개별 저장소의 수정 품질이나 구독 한도 절감을 보장하지는 않는다.

답변이 빨리 끝났다는 경험과, 검토를 통과한 수정이 빨리 나왔다는 평가는 다르다.

리팩터링의 비교 단위는 최종 코드와 기존 동작이어야 한다. 같은 출발점에서 같은 변경을 맡기고 테스트 결과와 사람이 다시 손본 시간을 함께 기록해야 한다. 방의 호평은 이런 비교를 해볼 이유이며 솔보다 항상 우수하다는 증거는 아직 아니다.

5시간 한도는 5시간 연속 작업권이 아니다

사용량에 관한 방의 경험은 편차가 컸다. 5시간 단위 한도를 불과 십여 분 만에 다 썼다는 사례부터, 몇 시간 사용했다는 사례까지 있었다. 서로 다른 계정과 작업의 경험이므로 평균 소진 시간으로 계산할 수는 없다.

OpenAI 요금 문서는 한도를 고정된 메시지 개수로 설명하지 않는다. 모델, 작업 규모, 누적 문맥, 추론, 도구 사용, 검색과 캐시가 모두 사용량에 영향을 준다. 짧은 요청 하나도 큰 저장소를 읽고 여러 도구를 실행하면 많은 자원을 쓸 수 있다.

공식 문서가 제시하는 Pro 5x의 5시간당 로컬 메시지 추정치는 아스트라 25~225회, 솔 50~500회다. 보장 횟수가 아니며 실제 잔여량과 초기화 시점은 사용량 화면에서 확인하도록 안내한다. 주간 한도가 함께 적용될 수도 있다.

크레딧 단가도 차이가 난다. 현재 OpenAI 요금표에서 입력 100만 토큰은 아스트라 250크레딧, 솔 125크레딧이다. 출력은 각각 1,250크레딧과 750크레딧이며 아스트라 Fast 모드는 Standard 대비 2.5배를 적용한다. 이 수치는 구독 크레딧 요금이고 API 달러 요금과 구분해야 한다. 빠른 응답을 얻으려고 속도 설정까지 높이면 한도 소진도 빨라질 수 있다. 작업당 토큰이 감소했다는 공식 설명과, 잔여량이 빠르게 줄었다는 경험담은 동시에 성립할 수 있다.

리팩터링과 화면 검증을 한 작업으로 맡기는 법

개인 개발자에게 중요한 변화는 수정과 확인을 얼마나 적은 개입으로 연결하느냐다. 아스트라를 비교할 때도 저장소 전체를 막연히 개선해 달라고 요청하기보다, 완료 조건이 분명한 작업을 넣는 편이 결과를 판단하기 쉽다.

Codex CLI에서는 `/model`로 사용 가능한 모델과 추론 강도를 고른다. 데스크톱 앱에서는 입력창 아래 선택기를 사용한다. OpenAI는 기본 추론 강도에서 시작하고 더 깊은 분석이 필요할 때 높이도록 안내한다. 예를 들어 입력으로 수정할 모듈, 유지할 외부 동작, 기존 테스트 실행법을 제공한다. 함수 분리만 수행하고 관련 테스트 결과와 변경 이유를 돌려달라는 식으로 산출물을 정한다. 이는 방의 특정 사례를 복원한 절차가 아니라, 공식 모델 가이드의 범위·제약·검증 지침을 적용한 요청 예시다.

화면 문제까지 있다면 데스크톱 앱의 내장 브라우저를 연결할 수 있다. OpenAI Browser 문서의 순서는 개발 서버 실행, 로컬 페이지 열기, 화면과 코드 변경 비교다. 이어 문제가 있는 요소에 주석을 남기고 그 부분을 고치도록 요청한다. 가령 로컬 설정 페이지 주소와 버튼이 넘치는 조건을 입력한다. `@Browser`로 페이지를 열어 문제를 재현하고 수정 후 같은 화면을 다시 확인하도록 요청한다. 받을 결과는 코드 변경과 해당 화면에서 확인한 동작이며 단순한 완료 보고만으로 검증을 대신하지 않는다.

내장 브라우저는 Codex CLI와 IDE 확장에는 제공되지 않는다. CLI에서 아스트라를 선택했다고 데스크톱 앱의 브라우저 기능까지 생기는 것은 아니다. 이 차이를 놓치면 모델의 능력과 실행 도구의 차이를 섞어 평가하게 된다.

맥과 윈도의 차이는 모델 목록만으로 설명되지 않는다

클코단에는 macOS에서 선택 가능한 아스트라가 Windows에서는 아직 나타나지 않았다는 경험도 있었다. 다만 이 사례만으로 Windows 미지원이나 특정 OS 우선 배포를 단정할 수는 없다. OpenAI는 제공 여부가 배포 단계, 로그인 방식, 클라이언트에 따라 달라진다고 명시한다.

공식 모델 목록에는 아스트라의 데스크톱 앱·CLI·IDE 확장 지원이 표시돼 있다. 반면 Codex cloud는 지원 대상으로 표시돼 있지 않다. 같은 계정이라도 어느 제품 화면을 사용하는지부터 구분해야 하는 이유다.

화면을 직접 조작하는 Computer Use에도 별도 조건이 있다. OpenAI 문서에 따르면 지원 지역의 macOS와 Windows에서 사용할 수 있으며 Computer Use 플러그인을 설치하고 활성화한다. macOS에서는 화면 기록과 손쉬운 사용 권한을 허용해야 한다. Windows에서는 대상 앱이 활성 데스크톱에 보여야 하며 작업 중 포인터와 키보드를 에이전트가 사용한다. Windows에서는 같은 세션에서 다른 일을 하는 백그라운드 조작을 지원하지 않는다. 소규모 팀이 화면 검증을 맡길 때는 실행 시간뿐 아니라 작업용 PC를 함께 쓸 수 있는지도 비용에 들어간다.

아스트라의 실익은 재작업을 얼마나 줄이느냐에 달렸다

도구를 잘 다룬다는 첫인상은 유용하지만 어떤 작업을 줄였는지까지 확인해야 구매 판단에 쓸 수 있다. 리팩터링이라면 동작을 보존했는지, 화면 수정이라면 같은 재현 절차에서 문제가 사라졌는지가 기준이다. 요청 횟수가 줄어도 검토와 재수정이 늘면 절약한 시간은 작아진다.

OpenAI의 아스트라 프롬프팅 가이드에도 이 판단에 필요한 단서가 있다. 작은 코드 작업에서 필요 이상으로 폭넓게 테스트할 수 있어 변경에 맞는 검증 범위를 지정하라고 안내한다. 스킬과 `AGENTS.md`의 지시에 민감할 수 있으므로, 불명확하거나 충돌하는 지침도 점검 대상으로 꼽는다.

1인 사업자에게는 어려운 수정 하나를 끝내는 가치와 반복 작업을 많이 처리하는 가치가 다르다. 아스트라를 투입해 사람의 디버깅 시간이 크게 줄어든다면 높은 단가를 감수할 근거가 생긴다. 단순 수정까지 같은 설정으로 처리하면 그 이득이 남는지는 별도의 문제다.

현재 확인된 정보만으로 아스트라가 하루 생산량까지 늘린다고 단정할 수는 없다. 솔에서 전환할 근거는 응답 속도의 첫인상보다, 같은 예산 안에서 검토까지 끝낸 작업이 얼마나 늘었느냐에 있다.