한 개발자가 ChatGPT에서 긴 조사와 문서 정리를 반복한 뒤 Codex로 복잡한 코드 검토를 시작하려 할 때, 두 작업은 더 이상 완전히 별개의 사용 한도 안에 있지 않을 수 있다. OpenAI는 12월부터 Plus, Pro, Business 요금제에서 ChatGPT와 Codex의 사용 허용량을 공유하는 방향으로 전환한다고 안내했다.
이 변화는 “Codex 좌석을 몇 개 더 살 것인가”라는 질문을 없애지는 않는다. 다만 같은 계정에서 ChatGPT와 Codex를 함께 쓰는 사람이라면, 어떤 화면에서 작업했는지보다 어떤 요청에 제한된 사용량을 쓸지 더 중요해진다. 조직 계약이나 워크스페이스가 구성원 사이의 사용량을 어떻게 적용하는지는 제공된 안내만으로 단정할 수 없으므로, 팀 전체가 하나의 토큰 풀을 공유한다고 전제해서는 안 된다.
개인별 한도 구조라면 한 사람의 조사 업무와 코딩 업무가 경쟁한다. 조직 계약에서 별도 공유 구조나 관리 정책을 적용한다면, 그때는 여러 사용자의 업무 우선순위까지 운영 대상으로 삼게 된다. 어느 경우든 제품의 통합 한도를 팀별 예산 기능으로 오해하지 않는 것이 출발점이다.
바뀌는 것은 ChatGPT와 Codex 사이의 사용량 경계다
통합 사용량 전환의 핵심은 ChatGPT와 Codex가 각각 독립된 사용량을 소진하는 방식이 아니라, 선택한 모델과 요청의 성격에 따라 같은 허용량을 함께 쓴다는 점이다. 토큰은 모델이 입력과 출력을 처리하는 단위다. 더 고급 모델을 선택하거나 작업이 복잡해질수록 사용량 소모가 커질 수 있다.
따라서 긴 코드베이스를 읽고 여러 파일의 수정 방향을 검토하는 Codex 작업과, 긴 자료를 비교·정리하는 ChatGPT 작업은 사용 시간만으로 비교하기 어렵다. 짧은 질문을 여러 번 보냈는지, 한 번에 큰 작업을 맡겼는지도 사용량 관리에서는 같은 의미가 아니다.
반대로 모든 ChatGPT 활동이 통합 사용량을 줄이는 것은 아니다. 안내에 따르면 즉시 대화는 이 사용량에서 차감되지 않는다. 조직이 사용 정책을 만들 때 짧은 확인 질문까지 일괄 제한하면, 정작 제한해야 할 복잡한 에이전트 작업이나 외부 앱 사용 경로를 놓칠 수 있다.
사용자는 설정의 사용량 화면에서 통합 잔여 사용량과 재설정 시점을 확인할 수 있다. 이 정보는 개인이 다음 작업을 미룰지, 더 높은 요금제나 크레딧 사용을 검토할지 판단하는 기준이 된다. 조직 관리자는 이 화면이 팀 전체 사용량을 집계하거나 부서별 사용량을 배정한다는 뜻으로 해석하지 말아야 한다.
아직 확인되지 않은 운영 기능을 정책의 전제로 두지 말아야 한다
제공된 안내는 ChatGPT와 Codex 사용량이 공유된다고 설명하지만, Business 워크스페이스 구성원 전체가 하나의 토큰 풀을 공동으로 쓰는지, 관리자가 직무별 토큰을 예약할 수 있는지, 팀별로 별도 사용량을 배분할 수 있는지는 설명하지 않는다.
그래서 “팀의 공용 예산”은 제품 기능명이 아니라 내부 운영 원칙으로만 써야 한다. 예를 들어 조직은 다음을 정할 수 있다.
- 회사 계정으로 외부 앱의 AI 요청에 ChatGPT 플랜 사용을 허용할지
- 크레딧 구매와 사용을 누가 승인할지
- 운영상 중요한 업무에서 어떤 모델과 도구를 우선 검토할지
- 사용량이 부족할 때 어떤 업무를 사람의 수동 절차로 전환할지
이 원칙은 사용량을 기술적으로 분리하거나 예약해 주지 않는다. 다만 한도 소진 뒤에 누가 어떤 결정을 해야 하는지 미리 정해 둔다. 특히 조직 계약의 실제 한도 구조, 계정별 적용 범위, 관리자 설정 가능 항목은 계약 조건과 워크스페이스 설정에서 따로 확인해야 한다.
업무를 세 부류로 나누면 모델 선택이 쉬워진다
통합 사용량 환경에서 가장 높은 성능의 모델을 모든 업무의 기본값으로 정하면, 중요한 순간에 선택지가 줄어든다. 반대로 모든 요청을 낮은 비용의 모델로 밀어 넣으면 코드 변경이나 장애 판단처럼 재작업 비용이 큰 업무에서 시간을 잃을 수 있다.
모델과 도구를 배정할 때는 업무 이름보다 실패했을 때의 영향을 먼저 본다. 다음 구분은 제품 기능이 아니라 내부 운영 기준의 예시다.
중단하거나 잘못 처리했을 때 운영 영향이 큰 업무
배포 직전 변경 검토, 보안 관련 수정의 이해, 장애 상황에서 원인 가설을 정리하는 작업이 여기에 들어갈 수 있다. 결과를 그대로 실행한다는 뜻은 아니다. 사람이 최종 판단하고 승인해야 하는 업무이지만, 검토 범위와 대응 속도에 영향을 줄 수 있으므로 모델 선택을 신중히 다룬다.
Codex의 자동 검토 기능은 일부 적격 작업에서 승인 대기 없이 검토를 진행하도록 돕지만, 워크스페이스 제한을 없애거나 모든 승인 절차를 대체하지는 않는다. 사용량 정책과 코드 변경 권한은 따로 설계해야 한다.
반복되지만 대체 경로가 분명한 업무
테스트 코드 초안, 변경 이력 요약, 기술 문서의 첫 구조, 코드 리뷰 질문 목록은 사람이 보완하거나 작업 범위를 줄이기 비교적 쉬운 편이다. 이런 업무에는 전체 저장소 분석을 기본 요청으로 두기보다 대상 모듈, 확인할 변경점, 원하는 산출물 형식을 먼저 적도록 정할 만하다.
이 방식이 일정한 토큰 절감률을 보장하는 것은 아니다. 다만 요청의 범위를 정하지 않은 채 복잡한 작업을 반복하는 일을 줄인다. 모델 품질을 낮추기 전에 작업 지시를 좁히는 편이 나은 경우도 있다.
미뤄도 업무 흐름이 멈추지 않는 업무
개인 학습, 문체 변환, 이미 읽은 문서의 재요약, 회의 전 아이디어 확장은 유용하지만 긴급 업무와 같은 우선순위를 가질 필요는 없다. 조직이 자체적으로 잔여 사용량 기준을 정했다면, 이 단계의 업무는 짧은 요청이나 즉시 대화 중심으로 전환하도록 안내할 수 있다.
여기서 목적은 개인 사용을 감시하는 일이 아니다. 한도에 가까워졌을 때 어떤 종류의 작업부터 축소하거나 미룰지 합의하는 데 있다.
외부 앱의 주간 제한은 예산 배정이 아니라 소비 상한이다
참여 앱이나 사이트에 ChatGPT 계정으로 로그인한 뒤 플랜 사용을 허용하면, 그 앱의 적격 AI 요청도 포함된 ChatGPT Work 및 Codex 사용량에 반영될 수 있다. Go, Plus, Pro 사용자는 지원되는 상용 앱과 사이트에서 이런 선택을 할 수 있으며, 앱별 주간 사용 제한도 설정할 수 있다.
이 제한은 유용하지만 별도 예산이 아니다. 특정 앱이 전체 주간 사용량 가운데 사용할 수 있는 비율을 막는 상한일 뿐, 그 앱을 위해 사용량을 따로 확보하지 않으며 전체 한도도 늘리지 않는다.
따라서 외부 앱 연결을 검토할 때는 “이 도구가 편리한가”만 묻지 말고 다음을 확인하는 편이 좋다.
- 이 앱의 AI 요청이 개인 또는 조직의 ChatGPT 플랜 사용량을 써야 하는가.
- 앱이 사용하는 요청이 Codex 작업과 같은 사용량에 영향을 줄 수 있는가.
- 앱별 주간 상한을 어느 수준으로 둘 것인가.
- 전체 한도에 도달한 뒤 앱이 크레딧을 쓰도록 허용할 것인가.
- 앱 구독료와 ChatGPT 플랜 사용량, 크레딧 비용을 누가 구분해 검토할 것인가.
앱이 별도의 구독료나 인프라 비용을 청구할 수도 있다. ChatGPT 플랜 사용을 허용했다는 사실만으로 그 앱의 비용 구조가 하나로 합쳐지는 것은 아니다.
사용량 보고서보다 먼저 볼 것은 소진 당시의 작업이다
통합 사용량이 부족해졌을 때 개인별 사용량 순위만 보면, 누가 많이 썼는지는 알 수 있어도 그 사용이 불필요했는지는 판단하기 어렵다. 긴 코드 검토가 중요한 배포 결정을 도왔는지, 조사 작업이 반복 요약에 그쳤는지는 토큰 양만으로 구분되지 않는다.
운영 초기에는 다음 질문을 기록해 보는 편이 낫다.
- 사용량 부족이 발생했을 때 진행 중이던 작업은 무엇이었는가.
- 그 작업은 더 짧은 요청, 다른 모델, 수동 검토로 이어갈 수 있었는가.
- 외부 앱 연결이 사용량 소진 시점에 영향을 주었는가.
- 재설정까지 기다리는 것과 크레딧 사용 중 무엇이 내부 승인 기준에 맞았는가.
- 해당 계정 또는 워크스페이스의 한도 구조를 계약 문서와 설정 화면에서 확인했는가.
이 기록은 정교한 원가 배부 체계를 만드는 자료가 아니라 다음 운영 주기에 우선순위를 조정하는 근거다. 통합 한도 정책의 목표도 모든 사람이 같은 양을 쓰게 만드는 데 있지 않다. 한도가 부족한 상황에서 어떤 작업을 먼저 줄이고, 어떤 작업에는 추가 승인이나 비용을 허용할지 분명히 정하는 데 있다.
다음 운영 회의에서는 좌석 수 논의와 함께 계정별 한도 구조를 먼저 확인하고, 이어서 “이 사용량이 부족해졌을 때 우리 조직이 가장 늦게 미뤄야 하는 작업은 무엇인가”를 정해 보자. 그 답이 있어야 모델 선택, 외부 앱 제한, 크레딧 승인 기준도 일관되게 정할 수 있다.
