Codex 오케스트레이터와 워커 모델 조합, 한도까지 따져 고르는 법

Claude Code에서 익숙해진 역할 분담을 Codex로 옮기면 더 강한 모델을 워커에 두는 편이 나을까. 클코단에서는 Astra High 워커의 결과가 좋았다는 의견과 한 저녁 작업 뒤 표시된 잔여 한도가 3%였다는 경험이 함께 나왔다. 좋은 조합을 찾는 질문은 곧 같은 작업을 얼마나 오래 지속할 수 있느냐는 질문으로 이어진다.

오케스트레이터와 워커는 모델 등급이 아니라 맡은 일로 나뉜다

오케스트레이터는 목표를 쪼개고 작업 범위를 정한 뒤 결과를 확인한다. 워커는 넘겨받은 범위에서 코드를 읽거나 수정하고 검사 결과를 돌려준다. OpenAI의 멀티에이전트 문서는 서로 독립적인 조사와 검토에 하위 에이전트를 쓰고, 짧거나 앞 단계에 의존하는 일은 주 에이전트에 남기라고 설명한다. 하위 에이전트마다 별도 맥락이 생기므로 일을 나누는 것 자체에도 사용량이 든다. (developers.openai.com)

클코단에서 Astra High를 워커로 둔 구성이 잘 맞았다는 평가는 충분히 가능한 경험이다. 어려운 오류의 원인을 추적하거나 여러 파일에 걸친 변경을 맡긴다면 강한 워커가 유리할 수 있다. 다만 그 평가는 해당 작업에서의 사용감이지, Astra를 모든 하위 작업에 배치해야 한다는 검증 결과는 아니다.

Claude Code도 같은 구분을 제공한다. Anthropic 문서에 따르면 하위 에이전트는 별도 모델을 지정하거나 주 대화의 모델을 물려받을 수 있다. 하위 에이전트의 요청 역시 사용량에 더해진다. Claude Code에서 역할을 나눴다는 이유만으로 Codex에서도 동일한 한도 효과를 기대할 수는 없다. (code.claude.com)

Astra High와 Sol Fast는 서로 다른 설정을 가리킨다

‘Astra High’의 High는 추론 강도 설정이다. OpenAI는 추론 강도를 높이면 어려운 문제를 더 깊이 다룰 수 있지만 지연과 토큰 사용도 함께 고려해야 한다고 안내한다. 같은 Astra라도 코드 탐색과 복잡한 설계 판단에 늘 같은 강도를 줄 이유는 없다. (developers.openai.com)

‘Sol Fast’라는 말은 조금 더 조심해서 읽어야 한다. OpenAI의 Fast mode는 처리 속도에 관한 서비스 설정이며 High 같은 추론 강도와는 다른 축이다. API 문서는 Fast mode에 표준 처리보다 높은 토큰당 요금이 붙는다고 명시한다. 방에서 언급된 Sol Fast가 정확히 어떤 제품 화면과 설정을 가리켰는지는 확인되지 않았다. 그날의 한도 감소를 Fast mode 하나의 영향으로 돌릴 수 없는 이유다. (developers.openai.com)

모델 이름도 확인할 필요가 있다. OpenAI는 9월 29일 GPT-6.1 Sol을 공개했고 Codex에서도 사용할 수 있다고 밝혔다. 공식 모델 안내는 Astra를 까다로운 작업에, Sol을 성능과 비용의 균형이 필요한 작업에, Luna를 범위가 분명한 반복 작업에 놓는다. 다만 OpenAI가 제시한 GPT-6.1 Sol의 ‘Astra 대비 5분의 1’은 표준 API 입력·출력 토큰 가격 비교다. 구독자의 남은 사용 한도가 정확히 다섯 배 오래간다는 약속은 아니다. (openai.com)

같은 변경 요청을 세 조합에 나눠 맡겨 보면 차이가 드러난다

가령 작은 서비스의 로그인 오류를 고친다고 하자. 입력은 재현 절차, 관련 저장소, 기대 동작, 기존 테스트 명령이다. 오케스트레이터에게는 “원인을 조사할 범위와 완료 조건을 정하고, 구현과 검증을 구분하라”고 맡길 수 있다. 워커에게는 “지정한 파일에서 오류를 수정하고 테스트를 실행한 뒤, 바뀐 파일과 실패한 검사를 보고하라”고 전달한다. 산출물은 그럴듯한 설명이 아니라 코드 변경, 검사 결과, 남은 문제다.

비교할 때는 작업 입력과 완료 기준을 고정한다. 한 번은 Sol이 처음부터 끝까지 맡고, 다른 번에는 Sol이 조정하고 Astra High가 어려운 원인 분석만 맡게 한다. 마지막에는 Astra가 조정하되 명확한 수정은 Sol이나 Luna에 넘긴다. 각 시도에서 통과한 테스트, 사람이 다시 고친 부분, 걸린 시간과 표시된 사용량을 함께 기록해야 한다. 모델만 바꾸고 작업 범위까지 달라지면 조합의 효과를 읽기 어렵다.

OpenAI 문서도 독립적인 작업에만 위임하고 같은 파일을 고치는 에이전트들은 변경을 조율하라고 권한다. 워커에게 저장소 전체를 막연히 탐색시키는 대신 조사할 질문과 돌려받을 결과를 좁히는 까닭이다. 써본 사람들 사이에선 작은 일까지 나눴다가 검토와 재작업이 늘었다는 불만도 있고, 범위가 명확한 일을 가벼운 모델에 넘겨 도움이 됐다는 반응도 있다. 어느 쪽이 재현되는지는 작업의 모양에 달려 있다. (developers.openai.com)

잔여 3%는 모델 한 개의 소비율을 뜻하지 않는다

한 저녁 뒤 잔여 한도가 3%였다는 사례는 사용자의 체감으로서 중요하다. 그러나 작업 시작 전 잔량, 실행 횟수, 각 에이전트의 모델과 추론 강도가 없으면 소비 원인을 분리할 수 없다. OpenAI 도움말은 사용량이 모델뿐 아니라 작업 길이, 맥락, 속도 설정, 도구 사용에 따라 달라진다고 설명한다. 사용 한도가 공유되는 요금제라면 다른 대상의 사용도 함께 확인해야 한다. (help.openai.com)

확인 경로는 있다. Codex CLI에서는 /status를 입력하고 제품의 사용량 화면에서는 어느 한도가 소진됐는지와 재설정 시점을 확인할 수 있다. Claude Code의 사용량 정보도 함께 확인할 수 있다. 서로 다른 화면의 백분율만 나란히 놓기보다 평소 맡기는 변경 요청 몇 건을 끝낼 수 있었는지 비교하는 편이 실용적이다. (help.openai.com)

강한 워커가 값어치를 하는 경계는 재작업에서 정해진다

개인 개발자나 작은 팀에는 작업마다 계획·구현·검토를 모두 별도 에이전트에 맡길 여유가 없다. 오류 원인이 불명확하고 여러 선택지가 얽힌 구간에서는 Astra High 워커가 시간을 아낄 수 있다. 반면 수정할 위치와 통과할 검사가 이미 정해졌다면 강한 워커의 추가 판단이 결과를 바꾸지 않을 수도 있다. OpenAI 역시 동일한 입력으로 모델과 추론 설정을 시험해 필요한 품질을 충족하는 가벼운 구성을 찾으라고 권한다. (developers.openai.com)

클코단의 두 경험은 모순되지 않는다. 잘 풀린 작업과 빠르게 줄어든 한도는 같은 저녁에 일어날 수 있다. 오케스트레이터와 워커 조합을 평가할 때는 가장 강한 모델을 어디에 넣었는지와 재작업, 추가 사용량을 함께 봐야 한다.