GPT-6 Sol과 Luna 비용 구조: Codex 팀이 먼저 봐야 할 캐싱·모델 선택 기준

요약: GPT-6 Sol과 Luna는 단순히 “더 싼 모델”로 볼 이슈가 아닙니다. Codex CLI 0.157.0부터 Sol·Luna 지원이 추가됐고, OpenAI 쪽 설명에서는 캐시 입력 토큰 재사용, 에이전트 장기 세션, 코딩 작업 비용 절감이 핵심으로 반복됩니다. 개발팀 입장에서는 새 모델명이 중요한 게 아니라 “어떤 작업을 Astra, Sol, Luna로 나눌 것인가”가 비용을 좌우합니다.

왜 이번 업데이트가 개발자에게 중요한가

코딩 에이전트는 일반 챗봇보다 토큰을 많이 씁니다. 저장소 전체 구조, 최근 diff, 테스트 로그, 에러 스택, 도구 호출 결과가 매 턴 컨텍스트에 붙습니다. 사람이 보기엔 같은 대화처럼 보여도 API 비용은 매번 입력 토큰과 출력 토큰으로 계산됩니다. 그래서 모델 가격이 20~50% 내려가도, 컨텍스트 재사용을 못 하면 실제 청구액은 크게 줄지 않습니다.

이번 GPT-6 Sol·Luna 업데이트에서 봐야 할 포인트는 세 가지입니다. 첫째, Codex CLI가 새 모델 라인을 반영했습니다. OpenAI의 Codex changelog에는 2026년 9월 25일 0.157.0에서 GPT-6 Sol과 Luna가 추가됐고, Bedrock 지원과 구형 모델 마이그레이션 프롬프트도 들어갔다고 적혀 있습니다. 둘째, Releasebot에 반영된 OpenAI 릴리스 노트는 Sol과 Luna가 비용 효율 모델이라는 점을 전면에 둡니다. 셋째, 프롬프트 캐싱 개선이 에이전트 비용 절감의 핵심 기능으로 묶여 있습니다.

즉 “최신 모델이 나왔다”보다 “에이전트 실행 단가를 낮출 수 있는 선택지가 늘었다”가 실무적 해석입니다.

모델 선택은 작업 난이도보다 실패 비용으로 나눠야 한다

많은 팀이 모델을 고를 때 “어려운 일은 최고 모델, 쉬운 일은 싼 모델”처럼 나눕니다. 이 기준은 절반만 맞습니다. 운영 환경에서는 작업 난이도보다 실패 비용이 더 중요합니다.

예를 들어 README 초안 작성, 테스트명 정리, 린트 에러 설명, 작은 리팩터링 제안은 Luna 같은 저비용 모델로 충분할 가능성이 큽니다. 실패해도 사람이 바로 되돌릴 수 있고, 잘못된 출력이 프로덕션에 들어갈 확률도 낮습니다. 반대로 결제 로직 수정, 마이그레이션 SQL 작성, 인증 정책 변경, 대규모 리네이밍은 단순해 보여도 실패 비용이 큽니다. 이때는 Sol 이상, 경우에 따라 Astra급 모델을 쓰고 리뷰 단계를 추가하는 편이 낫습니다.

실무 기준은 다음처럼 두면 좋습니다.

• Luna: 설명, 요약, 초안, 테스트 케이스 후보, 문서 정리.
• Sol: 중간 규모 코드 수정, 버그 원인 추적, 여러 파일을 넘나드는 리팩터링.
• Astra 또는 최고 등급: 보안·결제·권한·데이터 손실 가능성이 있는 변경, 장시간 자율 실행.

여기서 중요한 건 모델을 한 번에 고정하지 않는 것입니다. 에이전트가 이슈를 분석하는 단계에서는 Luna나 Sol로 시작하고, 실제 patch 생성 단계에서 Sol 또는 Astra로 올리는 식의 단계형 라우팅이 비용과 품질을 동시에 잡습니다.

프롬프트 캐싱은 “켜는 기능”이 아니라 “구조를 맞추는 작업”이다

OpenAI 릴리스 노트는 GPT-6에서 캐시 hit rate를 높였고, 캐시된 입력 토큰 read에 큰 할인을 제공한다고 설명합니다. 하지만 캐싱은 문서에 체크박스를 켠다고 자동으로 잘 되는 기능이 아닙니다. 같은 prefix가 반복되어야 캐시가 잡힙니다.

에이전트 프롬프트를 매번 동적으로 섞으면 캐시가 깨집니다. 예를 들어 시스템 지침, 레포 구조, 코딩 규칙, 테스트 명령, 보안 정책의 순서가 호출마다 바뀌면 모델 입장에서는 다른 입력입니다. 반대로 아래처럼 고정 prefix를 유지하면 캐시 효율이 좋아집니다.

1. 시스템 규칙과 팀 코딩 컨벤션.
2. 레포 설명과 주요 디렉터리 구조.
3. 작업 수행 정책: 읽기, 수정, 테스트, 보고 순서.
4. 현재 이슈 설명.
5. 최신 로그, diff, 사용자 추가 지시.

앞쪽 13은 거의 바꾸지 않고, 뒤쪽 45만 바꾸는 방식입니다. explicit breakpoint를 지원하는 환경이라면 “여기까지는 재사용되는 prefix”를 분명히 나누는 편이 좋습니다. 캐시가 맞으면 같은 저장소에서 여러 이슈를 처리할 때 입력 토큰 비용이 눈에 띄게 줄어듭니다.

Codex CLI 업데이트에서 같이 봐야 할 운영 변화

Codex changelog에는 모델 추가 외에도 실무에 영향을 주는 변경이 같이 있습니다. fullscreen transcript 기본 활성화, background server 자동 시작, remote session과 local background-server session에서 /import 사용, proxy routing 수정, 파일 업로드 transient failure retry, 네트워크 restriction을 redirect와 WebSocket까지 확장한 내용입니다.

이건 “모델 업데이트”가 아니라 “에이전트 런타임을 오래 돌리는 방향”으로 제품이 움직이고 있다는 신호입니다. 장시간 세션에서는 모델 성능보다 주변 런타임 안정성이 더 자주 발목을 잡습니다. 업로드 timeout, proxy, redirect, WebSocket 제한, tmux scrollback 같은 작은 문제가 실제 업무에서는 중단 원인이 됩니다.

따라서 팀에서 Codex를 쓰고 있다면 모델명만 바꾸지 말고 다음 항목을 같이 점검해야 합니다.

• CLI 버전과 npm 패키지 버전이 팀원마다 다른지.
• proxy 또는 사내 네트워크에서 realtime 연결이 끊기는지.
• background server가 자동으로 뜰 때 기존 세션 정책과 충돌하지 않는지.
• 파일 업로드가 큰 로그나 스크린샷에서 timeout 나는지.
• 네트워크 restriction이 redirect 이후에도 유지되는지.

모델 성능이 좋아져도 이 레이어가 불안정하면 개발자는 “AI가 또 멈췄다”고 느낍니다.

비용 측정은 토큰 단가가 아니라 작업 단가로 해야 한다

새 모델 가격표만 보고 월 비용을 예측하면 대부분 빗나갑니다. 코딩 에이전트 비용은 “한 요청당 얼마”보다 “작업 하나를 완료하는 데 몇 번 호출했고, 몇 번 실패했고, 사람이 얼마나 개입했는가”로 봐야 합니다.

권장 지표는 네 가지입니다.

• task_cost: 이슈 1개를 닫는 데 든 총 API 비용.
• retry_count: 모델 출력 오류, 테스트 실패, 도구 실패로 재시도한 횟수.
• human_review_minutes: 사람이 확인하고 고친 시간.
• merge_success_rate: 생성된 변경이 리뷰 후 실제 머지된 비율.

Sol이 토큰당 더 비싸더라도 Luna보다 재시도가 적으면 작업 단가는 더 낮을 수 있습니다. 반대로 단순 문서 작업에 Sol을 쓰면 품질 차이는 작고 비용만 늘 수 있습니다. 새 모델 도입 테스트는 “같은 이슈 20개를 Luna, Sol, 기존 모델로 나눠 처리”하는 방식이 가장 현실적입니다.

오늘 적용할 체크리스트

• Codex CLI를 팀 표준 버전으로 맞추고 0.157.0 이후 변경점을 공유합니다.
• 작업을 low-risk, medium-risk, high-risk로 나누고 모델 라우팅 표를 만듭니다.
• 시스템 프롬프트와 레포 컨텍스트를 고정 prefix로 분리합니다.
• 캐시 hit rate, task_cost, retry_count를 로그로 남깁니다.
• 보안·결제·권한 변경은 저비용 모델 단독 실행을 금지합니다.
• 모델 비교는 토큰 단가가 아니라 “이슈 1개 완료 비용”으로 평가합니다.
• 첫 주에는 자동 머지보다 draft PR 생성까지만 허용해 실패 패턴을 모읍니다.

이번 업데이트의 결론은 단순합니다. GPT-6 Sol과 Luna는 비용을 줄일 수 있지만, 캐싱 구조와 작업 라우팅이 없으면 효과가 반감됩니다. 모델을 바꾸기 전에 에이전트 입력 구조, 위험도 분류, 작업 단가 측정부터 정리하는 팀이 실제 비용을 줄입니다.