Codex 사용량을 소진해도 ChatGPT 일반 Chat의 GPT-6 Pro를 활용할 수 있을까?

숨겨진 Astra를 찾기보다, ChatGPT·GitHub·Codex의 역할을 나눠보자

Codex 사용량이 바닥나면 생각이 많아집니다.

다음 초기화까지 기다릴까. 남은 리셋권을 쓸까. 다른 AI로 작업을 넘길까.

저도 한동안 모델보다 사용량 화면을 더 자주 들여다봤습니다. 작업을 빨리 끝내려고 AI를 쓰는데, 어느 순간 AI를 언제까지 쓸 수 있는지 계산하는 일이 생겼습니다.

그런데 최근 흥미로운 활용법이 공유되고 있습니다.

“Codex에서 Astra를 다 썼다고 끝이 아니다. 일반 ChatGPT에 남아 있는 GPT-6 Pro를 활용할 수 있다.”

여기에 GitHub를 연결하고, 생성한 코드를 로컬 개발환경으로 가져와 검증한 뒤, 외부에서는 스마트폰으로 작업을 이어간다는 이야기까지 붙습니다.

처음 들으면 ‘숨겨진 무제한 코딩 모드’를 발견한 것처럼 느껴집니다.

하지만 공식 문서를 확인해보니, 핵심 아이디어는 맞지만 몇 가지 기능이 한꺼번에 묶여 설명되고 있었습니다.

일반 채팅의 사용량, GitHub 연결 권한, 클라우드 코드 실행, 로컬 빌드, 스마트폰 원격 제어는 각각 구분해야 했습니다.

이번에는 과장된 부분을 걷어내고, 실제로 활용할 만한 방법을 정리해봤습니다.

※ 2026년 9월 26일 공식 문서 확인 기준입니다. 공유된 영상 요약을 공식 자료와 대조해 구성한 글이며, 영상 속 전체 작업을 동일한 환경에서 재현한 성공 후기는 아닙니다.

반응형

1. 별도 사용량은 맞다. 하지만 ‘웹으로 접속하면 공짜’는 아니다

먼저 가장 중요한 부분입니다.

ChatGPT 일반 Chat의 모델 한도와 Work·Codex의 사용량은 구분됩니다. Work와 Codex는 서로 사용량을 공유하지만, 일반 Chat의 GPT-6 Pro는 별도 메시지 한도를 사용합니다.

따라서 Codex 한도를 소진했더라도, 자신의 플랜과 계정에 일반 Chat의 GPT-6 Pro 사용 여유가 남아 있다면 그쪽에서 다른 작업을 진행할 수 있습니다.

다만 기준은 웹이냐 앱이냐가 아니라, 어떤 모드로 작업하느냐입니다.

웹 브라우저에서 접속했어도 Work 작업을 실행하면 Work·Codex 쪽 사용량을 봐야 합니다. ‘브라우저를 켰으니 별도 한도로 동작하겠지’라고 생각하면 안 됩니다.

이 팁의 정확한 의미는 다음에 가깝습니다.

소진한 Codex 한도를 되살리는 것이 아니라, 이미 내 플랜에 제공된 다른 작업 경로를 활용하는 것.

비상 연료가 새로 생긴 것이 아니라, 옆 칸에 남아 있던 연료를 확인하는 느낌입니다.

물론 그 연료로 같은 장비를 똑같이 움직일 수 있는지는 따로 봐야 합니다.

2. ‘Pro + 최고 추론’이라고 모두 Astra는 아니다

모델 선택에서도 확인할 부분이 있습니다.

현재 공식 명칭상 일반 Chat의 GPT-6 Pro는 GPT-6 Astra 기반입니다. 반면 Extra High는 GPT-5.6 Sol의 추론 수준일 수 있습니다. Pro 선택지에도 GPT-5.6 Sol Pro와 GPT-6 Pro가 함께 포함될 수 있으므로 실제 활성 모델을 확인해야 합니다.

따라서 다음 설명은 너무 단순합니다.

“추론을 가장 높게 올리면 숨겨진 Astra가 나온다.”

정확히는 계정에 허용된 모델 목록에서 GPT-6 Pro를 선택했는지 확인해야 합니다. 모델에게 “너 Astra야?”라고 묻는 것보다 화면의 실제 모델명이 더 중요한 기준입니다.

개인 플랜별 한도도 다릅니다.

플랜일반 Chat의 GPT-6 Pro함께 확인할 조건

Pro 100달러	주 50개 메시지	GPT-5.6 Sol Pro와 공유
Pro 200달러	주 200개 메시지	Sol Pro의 별도 일일 한도와 두 모델의 일일 합산 한도도 적용
Plus	일반 Chat에는 포함되지 않음	Work·Codex의 Astra 제공과 구분

이는 확인 시점의 공식 기준입니다. 따라서 ‘주 200회’라는 설명을 모든 Pro 사용자에게 적용할 수는 없습니다.

저처럼 100달러 구간을 기준으로 활용도를 고민하던 사람이라면, 200달러 계정의 시연을 그대로 자신의 사용 가능량으로 받아들이지 않는 편이 좋겠습니다.

숨겨진 사용량을 찾기 전에, 내가 결제한 플랜부터 확인해야 합니다.

3. 주 200회가 ‘200시간짜리 개발 서버’를 뜻하지는 않는다

영상 요약에서 가장 솔깃한 부분은 한 번의 요청으로 긴 코딩 작업을 진행했다는 대목입니다.

잘 정리된 요청 하나로 상당한 분량의 코드나 설계를 받는 것은 충분히 매력적입니다.

하지만 이를 다음처럼 계산하면 곤란합니다.

“주 200회에 한 번마다 한 시간씩이면, 개발 서버 200시간을 받는 셈 아닌가?”

메시지 한도는 정해진 클라우드 실행 시간을 보장하는 상품 설명이 아닙니다.

긴 추론을 수행하는 것, 도구로 코드를 실행하는 것, 자율 에이전트가 프로젝트를 수정하는 것, Unity로 실제 게임을 빌드하는 것은 서로 다른 단계입니다.

ChatGPT에는 데이터 분석 등을 위한 코드 실행 환경이 있지만, 공식 안내에서 설명하는 환경을 곧바로 Unity Editor가 설치된 전용 개발 서버라고 볼 수는 없습니다. 일반 데이터 분석 실행환경의 도구와 네트워크에도 제약이 있습니다.

따라서 결과를 받을 때는 시간을 보는 것보다 다음을 확인하는 편이 낫습니다.

실제로 파일을 만들었는가. 테스트를 실행했는가. 어떤 실행환경에서 확인했는가. 확인하지 못한 것은 무엇인가.

한 시간 동안 생각했다는 사실보다, 실제로 통과한 테스트 하나가 더 유용할 때도 있습니다.

오래 일한 AI가 반드시 일을 끝낸 AI는 아니니까요.

728x90

4. GitHub를 연결하면 자동으로 커밋까지 해줄까?

이번 내용을 확인하면서 가장 먼저 수정해야겠다고 생각한 부분입니다.

ChatGPT의 기본 GitHub 연결은 저장소를 읽고, 검색하고, 분석하기 위한 기능입니다. 이 연결만으로 코드를 수정해 push하거나 PR을 생성할 수 있다고 가정하면 안 됩니다. OpenAI의 GitHub 안내도 이 점을 명시하고 있습니다.

따라서 이런 흐름을 모두에게 가능한 기본 기능처럼 설명하면 부정확합니다.

일반 Chat에서 게임 생성 → 연결한 GitHub에 알아서 커밋 → 다음 도구가 이어서 개발.

별도의 쓰기 지원 도구나 Codex 작업이 개입했다면 가능 범위가 달라질 수 있습니다. 하지만 그 경우에는 어떤 도구가 쓰기를 수행했고, 어느 사용량으로 실행됐는지까지 확인해야 합니다.

처음 테스트할 때는 오히려 조금 수동적인 경로가 명확합니다.

ChatGPT 일반 Chat
요구사항 분석·코드 생성
        ↓
사용자
파일 검토·저장·테스트
        ↓
사용자
Git 커밋·GitHub 반영
        ↓
로컬 Codex
필요한 부분만 검토·수정

여기서 GitHub는 모델의 기억력을 마법처럼 연결하는 장치가 아닙니다.

여러 도구가 같은 코드와 작업 상태를 확인할 수 있도록 결과물을 남기는 장소입니다.

초보적인 방식처럼 보일 수도 있습니다. 하지만 어느 단계에서 무엇을 했는지 확인하기에는 훨씬 좋습니다.

자동으로 연결되는 것보다, 연결된 줄 알았는데 아무것도 저장되지 않은 상황을 피하는 것이 먼저입니다.

5. 저장소 주소보다 중요한 것은 ‘어디까지 끝났는지’다

“여기 GitHub 주소야. 이어서 해줘.”

이렇게만 넘기면 다음 담당자가 다시 많은 것을 확인해야 합니다.

어느 브랜치를 봐야 하는지, 최신 변경이 원격에 반영됐는지, 테스트는 실제로 통과했는지, 무엇을 구현하지 않았는지까지 알아야 하기 때문입니다.

저라면 코드와 함께 짧은 인수인계 문서를 남기겠습니다.

# AI_HANDOFF

## 기준 코드
- 저장소:
- 브랜치:
- 기준 코드 커밋 SHA:

## 완료한 것
- 차량 이동 로직 작성
- 체크포인트 순서 처리

## 실제 검증한 것
- Node 테스트 12개 통과

## 아직 검증하지 않은 것
- 모바일 화면
- Unity 프로젝트 변환
- Windows 실행 파일

## 다음 작업
- 입력·재시작 경계값 검토

## 변경하지 말 것
- 테스트를 삭제하거나 기준을 낮추지 않는다.
- 새 패키지와 외부 통신을 임의로 추가하지 않는다.

이 문서는 특정 모델 전용이 아닙니다.

ChatGPT가 작성한 코드를 Codex가 받아도 되고, 나중에 Claude나 사람이 이어받아도 됩니다.

이런 방식의 장점은 사용량 절약보다 오래갈 수 있다고 생각합니다.

대화창을 옮길 때마다 프로젝트를 처음부터 다시 설명하는 일을 줄일 수 있기 때문입니다.

단, 문서에 “테스트 완료”라고 쓰는 것만으로 검증이 끝난 것은 아닙니다. 실제 실행 로그와 코드 상태가 맞는지는 직접 확인해야 합니다.

6. Unity 게임은 ‘코드 생성’과 ‘완성’ 사이에 몇 단계가 더 있다

영상의 Unity 레이싱 게임 사례는 흥미롭습니다.

다만 초보자가 따라 할 수 있는 설명으로 만들려면 완료 기준을 나눠야 합니다.

C# 파일을 생성한 상태와, 게임이 정상적으로 빌드된 상태는 다릅니다.

제가 나누는 단계는 다음과 같습니다.

단계확인할 내용

코드 생성	필요한 C#과 설명이 실제 파일로 존재하는가
프로젝트 확인	맞는 Unity 버전에서 컴파일되는가
플레이 확인	입력·카메라·충돌·랩 계산이 동작하는가
빌드 확인	Windows Player 빌드가 실제로 성공했는가
전달 확인	압축을 새 폴더에 풀어 실행해도 동작하는가

Unity는 명령행에서 Editor 메서드를 실행해 빌드를 자동화할 수 있고, BuildPipeline.BuildPlayer는 빌드 결과 보고서를 반환합니다. 다만 이를 사용하려면 해당 프로젝트를 빌드할 수 있는 Editor와 실행환경이 먼저 준비돼 있어야 합니다.

그래서 처음에는 웹 Chat에 프로젝트 전체를 무조건 맡기기보다, 정확한 Unity 버전과 현재 프로젝트 조건을 제공하고, 코드 생성 범위를 작게 잡는 방식을 제안합니다.

자동차 한 대, 단순한 트랙, 순서대로 통과할 체크포인트, 재시작 기능 정도입니다.

외부 에셋, 멀티플레이, 로그인, 결제까지 붙이기 시작하면 ‘한도 활용 테스트’가 어느새 게임 개발 프로젝트가 됩니다.

또 Windows 빌드 결과는 .exe 하나만 전달해서 끝나는 것이 아닙니다. 데이터 폴더와 런타임 파일 등을 포함한 빌드 출력물 전체가 필요합니다.

AI가 “완료했습니다”라고 말한 시점보다, 새 폴더에서 실행해본 시점이 더 믿을 만한 완료 지점입니다.

7. 모바일로 이어가는 것은 가능하지만, 사용량까지 사라지지는 않는다

제공된 요약에는 Telegram과 로컬 Mac의 Codex CLI를 연결하는 ‘SonarBot·소널봇’이 등장합니다.

다만 이번 확인에서는 그 이름에 해당하는 정확한 공식 저장소와 배포판을 특정하지 못했습니다.

그래서 이름이 비슷한 프로젝트를 임의로 골라 설치법을 만들지는 않았습니다.

대신 현재 OpenAI가 제공하는 공식 Remote 연결을 실습 대안으로 넣었습니다.

공식 문서상 Windows·Mac의 데스크톱 환경을 iOS·Android에서 원격으로 이어갈 수 있습니다. 같은 계정과 워크스페이스, 필요한 인증을 준비하고, 데스크톱의 연결 설정에서 페어링을 시작하는 방식입니다.

여기서도 역할을 나눠 이해해야 합니다.

스마트폰
지시·확인
    ↓
연결된 내 PC
Codex와 로컬 개발 도구 실행

스마트폰이 Unity를 대신 빌드하는 것이 아닙니다.

연결된 PC가 작업을 수행하므로 호스트가 켜져 있고 온라인 상태여야 합니다. 원격에서 조작해도 기존 세션의 권한과 실행 조건을 따릅니다.

그리고 로컬 Codex를 다시 호출하면 Codex 사용량도 다시 발생합니다.

ChatGPT 로그인으로 실행하는 Codex와 API 키 인증은 과금 경로가 다릅니다. 원격 지시라는 이유로 이 구분이 없어지지는 않습니다.

따라서 다음 기대는 조정해야 합니다.

“Codex 한도가 0%여도 Telegram으로 보내면 계속 개발되겠지?”

그렇지 않습니다.

Chat에 남은 허용량으로 코드를 더 받을 수는 있어도, 마무리 단계에서 Codex를 쓰려면 그쪽 사용 조건이 충족돼야 합니다.

반면 사람이 로컬 테스트나 Unity 빌드 명령을 직접 실행하는 단계에는, 별도로 모델을 호출하지 않는 한 AI 추론이 필요하지 않습니다.

원격 제어는 이동의 제약을 줄이는 도구이지, 사용량을 없애는 도구는 아닙니다.

8. 처음에는 Unity보다 작은 과제로 사용 경로부터 검증하자

영상처럼 큰 결과물부터 만들고 싶은 마음은 이해합니다.

하지만 이번에 확인하려는 것이 ‘내 계정의 별도 Chat 한도를 활용할 수 있는가’라면, 처음부터 Unity 설치와 모바일 봇 연동까지 한꺼번에 할 필요는 없습니다.

어디에서 문제가 생겼는지 구분하기 어려워지기 때문입니다.

그래서 별도 실습 가이드의 첫 과제는 외부 라이브러리가 없는 작은 레이싱 로직으로 구성했습니다.

AI에게 두 함수를 구현하게 하고, 미리 준비된 테스트로 결과를 확인합니다.

첫 테스트는 실패하는 것이 정상입니다. 함수가 아직 구현되지 않았기 때문입니다.

그다음 일반 Chat에서 생성한 코드를 저장하고, 같은 테스트를 다시 실행합니다.

이 방식이면 확인할 것이 명확합니다.

실제로 어떤 모델을 사용했는지, 코드가 사양을 지켰는지, 테스트를 약하게 바꾸지 않았는지, 다른 사용량에 변화가 있었는지를 단계별로 볼 수 있습니다.

간단한 첫 요청은 이런 형태입니다.

첨부한 사양서와 소스, 테스트 파일을 먼저 읽어줘.

목표:
- 사양에 따라 지정된 함수 두 개만 구현한다.
- 입력 검증과 경계값 처리를 포함한다.

제한:
- 테스트 파일을 변경하지 않는다.
- 새 패키지나 외부 통신을 추가하지 않는다.
- 관련 없는 기능을 구현하지 않는다.
- 실제 실행하지 못한 테스트는 미검증이라고 표시한다.

출력:
- 수정한 파일의 완전한 내용
- 핵심 변경 이유
- 다음 담당자에게 전달할 짧은 인수인계

작업을 충분히 설명하되, 메시지 한 번을 아끼겠다고 목표가 다른 열 가지 일을 몰아넣지는 않을 생각입니다.

요청을 하나로 묶는 것과, 실패 원인을 알 수 없을 정도로 크게 만드는 것은 다릅니다.

9. ‘게이지가 그대로’라고 곧바로 무제한을 선언하지 말자

한 번 요청한 뒤 Codex 게이지가 그대로라면 신기할 수 있습니다.

하지만 비교할 때는 다른 요인을 함께 봐야 합니다.

같은 시간에 백그라운드 작업이 실행 중이었는지, 자연 초기화가 끼어들었는지, 사용량 표시가 즉시 반영되는지, 중간에 Work나 Codex 작업으로 넘어갔는지 등이 달라질 수 있습니다.

저라면 작은 과제를 진행하면서 다음 정도를 기록하겠습니다.

시작 전 플랜·모델·모드, Chat의 한도 표시, Work·Codex 사용량, 실행한 작업과 결과.

그리고 Chat 코드 생성 단계와 로컬 Codex 검토 단계를 나눠 기록합니다.

Codex가 따로 소비한 양까지 합친 뒤 “Chat에서도 Codex 게이지가 줄었다”고 해석하거나, 반대로 Chat에 요청했다는 이유로 모든 후속 작업이 별도 한도라고 생각하면 비교가 꼬입니다.

여기에서 중요한 것은 ‘절대로 차감되지 않는다’를 증명하는 실험이 아닙니다.

내 계정에서 어떤 작업을 어느 경로로 맡길 수 있는지 확인하는 것입니다.

실습 가이드에도 그래서 사용률뿐 아니라 사용됨·남음, 작업 모드, 다른 실행 여부를 함께 적도록 했습니다.

숫자를 많이 모으는 것보다, 무엇을 비교하는지 분명히 하는 편이 먼저입니다.

10. 내게는 ‘추가 결제’보다 ‘역할 분담’이라는 점이 좋았다

저는 API 종량제 비용을 계속 계산하면서 개발하는 방식이 잘 맞지 않습니다.

코드를 한 번 더 읽게 해도 되는지, 프롬프트를 길게 쓰면 얼마나 들지, 실패한 시도에 얼마를 썼는지까지 신경 쓰면 작업에 집중하기 어려울 것 같기 때문입니다.

그래서 이번 방식에서 가장 흥미로운 부분도 ‘더 많은 토큰’ 자체는 아닙니다.

이미 결제한 도구 안에서, 맡길 수 있는 역할을 다시 나눠본다는 점입니다.

저라면 일반 Chat에는 요구사항 정리, 복잡한 설계 판단, 파일 단위 코드 생성과 리뷰를 맡겨볼 수 있겠습니다.

GitHub에는 결과물과 결정 사항을 남깁니다.

로컬에서는 테스트와 빌드를 확인하고, Codex는 실제 실행환경을 보면서 고쳐야 하는 부분에 집중시킵니다.

물론 이것이 항상 더 저렴하거나 빠르다는 보장은 없습니다.

파일을 옮기고, 내용을 검토하고, 작업 상태를 정리하는 시간이 추가됩니다. 작은 수정 하나라면 익숙한 Codex 세션에서 바로 끝내는 편이 더 편할 수 있습니다.

그래서 이 방법을 주력 도구를 완전히 대체하는 비밀 무기보다는, Codex 한도가 부족하거나 설계와 구현을 나누고 싶을 때 선택할 수 있는 보조 작업 흐름으로 보는 편이 좋겠습니다.

사용량 5%를 아끼려고 인수인계에 두 시간을 쓰면, 제 시간이 더 비쌉니다.

11. ‘더 오래 돌리는 법’보다 ‘어디까지 맡길지 정하는 법’

이런 팁을 보면 언제나 조금 유혹을 받습니다.

한 번의 요청으로 더 오래 일하게 할 수 있다면 좋겠고, 남겨둔 한도가 있다면 알뜰하게 쓰고 싶습니다.

하지만 최대 실행시간을 채우는 것 자체가 목표가 되면 방향이 바뀝니다.

프로젝트에 필요한 일을 끝내려고 AI를 쓰는 것이 아니라, AI를 오래 쓰려고 프로젝트를 키우게 됩니다.

이번에도 저는 반대로 접근하려 합니다.

작은 기능 하나를 끝내봅니다.

다음 담당자가 이어받을 수 있도록 결과를 남깁니다.

검증하지 못한 부분을 정확하게 구분합니다.

그 경로가 편하고 유용하다고 느껴지면 더 큰 프로젝트로 확장합니다.

새로운 사용법을 익히는 것보다, 그 사용법으로 무엇을 마무리했는지가 중요하니까요.

결론: 숨겨진 무제한 Astra보다, 안 나눠 쓴 역할이 있었다

이번 팁에는 활용할 만한 핵심이 있습니다.

Codex에서 사용량이 끝났다고 해서, 내 계정에서 가능한 모든 AI 작업이 동시에 끝난 것은 아닐 수 있습니다. 일반 Chat과 Work·Codex의 이용 체계를 구분하면 다른 방식으로 작업을 이어갈 여지가 있습니다.

다만 다음 기대는 구분해야 합니다.

일반 Chat의 사용 여유가 있다는 것과, 그곳에 무제한 자율 개발 서버가 있다는 것은 다릅니다.

GitHub를 읽을 수 있다는 것과 직접 커밋할 수 있다는 것도 다릅니다.

코드를 생성했다는 것과 실제 Unity 게임을 빌드했다는 것도 다릅니다.

스마트폰에서 지시할 수 있다는 것과, 연결된 PC나 Codex 한도가 필요 없다는 것도 다릅니다.

그 차이를 알고 구성하면 충분히 흥미로운 작업 방식이 됩니다.

저는 이번 내용을 이렇게 받아들이려고 합니다.

Chat에서 생각과 초안을 만들고, GitHub에 결과를 남기고, 로컬에서 실행해 확인한다. Codex는 정말 필요한 검증과 수정에 사용한다.

모든 일을 한 도구에 맡기는 편리함도 좋지만, 역할을 나눠두면 한쪽의 사용량이 부족할 때 다른 길을 선택하기도 쉬워집니다.

그렇다고 새로운 연결을 만들기 위해 또 결제부터 할 필요는 없습니다.

현재 계정에서 작은 과제로 확인해보고, 실제로 편해지는지 판단하면 됩니다.

‘숨겨진 꿀통을 찾았다’는 제목도 솔깃합니다.

하지만 제게 더 오래 도움이 될 팁은 아마 이쪽일 것 같습니다.

숨겨진 토큰을 찾는 것보다, 이미 가진 도구에 일을 잘 나눠주는 것.

이번에는 사용량을 끝까지 녹이는 대신, 작업 하나를 끝까지 마무리하는 실험을 해보려고 합니다.