2026년 7월 9일 공개된 GPT-5.6은 Sol, Terra, Luna 세 가지로 나뉩니다. 셋 다 컨텍스트 창 1,050,000토큰, 최대 출력 128,000토큰으로 동일하고 지식 컷오프도 2026년 2월 16일로 같습니다. 이름만 보면 상·중·하 등급 같지만 실제 차이는 그렇게 단순하지 않습니다.
7월 30일 가격 인하 이후 Sol과 Luna의 입력 단가 차이는 25배까지 벌어졌습니다. 그런데 주요 벤치마크 격차는 대부분 2~3점에 그칩니다. 이 어긋난 조합이 어떤 모델을 기본값으로 둘지를 결정합니다.
스펙 표는 셋이 똑같고, 가격만 25배 벌어집니다
OpenAI API 문서 기준으로 세 모델의 컨텍스트 창은 모두 1,050,000토큰, 최대 입력은 922,000토큰, 최대 출력은 128,000토큰입니다. 지원 엔드포인트도 Chat Completions, Responses, Batch로 동일합니다. 추론 강도 옵션 역시 none부터 max까지 여섯 단계로 같습니다.
갈리는 건 가격입니다. 100만 토큰 기준 입력·출력 단가는 Sol이 5달러와 30달러, Terra가 2달러와 12달러, Luna가 0.2달러와 1.2달러입니다. 캐시된 입력은 세 모델 모두 정가의 10% 수준으로 떨어집니다.
| 항목 | Sol | Terra | Luna |
|---|---|---|---|
| 입력 / 출력 (100만 토큰) | $5 / $30 | $2 / $12 | $0.2 / $1.2 |
| Terminal-Bench 2.1 | 88.8% | 87.4% | 84.7% |
| SWE-Bench Pro | 64.6% | 63.4% | 62.7% |
| MRCR v2 (256K~512K) | 91.5% | 89.6% | 41.3% |
컨텍스트 창은 같은데 긴 입력에서 Luna만 무너집니다
세 모델의 컨텍스트 창 숫자가 같다는 점 때문에 오해가 생기기 쉽습니다. 실제로 넣은 내용을 되찾아오는 능력은 전혀 다릅니다. 256K~512K 구간을 측정하는 MRCR v2에서 Sol은 91.5%, Terra는 89.6%인 반면 Luna는 41.3%입니다.
50점 차이는 등급 차이가 아니라 용도 차이입니다. Luna에 20만 토큰짜리 계약서 묶음을 넣고 특정 조항을 찾아달라고 하면 절반 넘게 놓친다는 뜻입니다. 반대로 Terra는 Sol과 2점 차이라 장문 처리에서 굳이 Sol을 쓸 이유가 크지 않습니다.
Luna의 100만 토큰 컨텍스트는 담을 수 있다는 뜻이지, 찾아낼 수 있다는 뜻이 아닙니다.
벤치마크 격차는 생각보다 훨씬 좁습니다
Terminal-Bench 2.1은 Sol 88.8%, Terra 87.4%, Luna 84.7%입니다. SWE-Bench Pro는 64.6%, 63.4%, 62.7%로 1점 안쪽씩 벌어집니다. 장시간 전문 업무를 재는 Agents' Last Exam도 52.7%, 50.4%, 50.3%입니다.
Terra와 Luna 사이가 0.1점인 항목이 있다는 건 이 벤치마크가 세 모델을 잘 변별하지 못한다는 뜻이기도 합니다. 그래서 벤치마크만으로 등급을 나누면 가격 25배 차이가 정당화되지 않습니다.
비교 기준으로 이전 세대인 GPT-5.5는 Terminal-Bench 85.6%, SWE-Bench Pro 59.4%였습니다. Luna조차 GPT-5.5보다 코드 이슈 해결에서 앞선다는 계산이 나옵니다.
코딩만 놓고 보면 Sol이 1위가 아닙니다
SWE-Bench Pro에서 Sol은 64.6%인데, Anthropic의 Claude Fable 5는 80%로 보고됐습니다. 15점 넘게 차이 납니다. 저장소 단위 코드 수정이 주 업무라면 GPT-5.6 안에서 고민할 문제가 아닙니다.
반대로 터미널 명령과 도구 호출을 엮는 에이전트 작업에서는 결과가 뒤집힙니다. Artificial Analysis의 Coding Agent Index에서 Sol은 80점으로 선두이고 Terra 77.4점, Luna 74.6점입니다. 같은 '코딩'이라도 무엇을 재느냐에 따라 순위가 바뀝니다.
따라서 모델을 고르기 전에 자기 작업이 코드 패치 생성인지, 터미널 워크플로 실행인지부터 구분해야 합니다. 서비스 비교 관점에서 이 구분이 벤치마크 점수보다 먼저입니다.
272K 토큰을 넘기는 순간 요금표가 바뀝니다
세 모델 모두 입력이 272,000토큰을 넘으면 해당 요청 전체에 입력 2배, 출력 1.5배 요율이 붙습니다. 초과분만이 아니라 요청 전체가 대상이라는 점이 중요합니다.
Terra로 30만 토큰을 넣으면 입력 단가가 100만 토큰당 2달러가 아니라 4달러로 계산됩니다. 271K와 273K 사이에서 비용이 두 배로 뛴다는 뜻입니다. 넘길 것 같으면 청킹으로 두 번 나눠 호출하는 편이 대체로 쌉니다.
속도가 급하면 모델이 아니라 모드를 바꿔야 합니다
세 모델의 초당 출력 토큰이나 첫 토큰 응답 시간은 공식 문서에 공개되어 있지 않습니다. Luna가 가장 빠르다는 서술만 있을 뿐 수치는 확인되지 않았습니다. 그래서 속도를 이유로 Luna를 고르는 판단은 지금 근거가 약합니다.
수치가 있는 건 모드 쪽입니다. 7월 30일 함께 공개된 Fast 모드는 Sol 전용으로 표준 대비 최대 2.5배 속도를 내고 토큰 단가는 2배입니다. 지능은 그대로이고, 기존 priority 서비스 티어 요청은 자동으로 Fast 모드를 씁니다.
더 극단적인 선택지로 Cerebras 인프라에서 도는 Sol Ultrafast가 초당 최대 750토큰을 낸다고 발표됐습니다. 다만 현재 일부 고객 대상 제한 프리뷰이고 가격은 공개되지 않았습니다.
보안과 컴퓨터 사용에서만 Sol이 확실히 벌어집니다
대부분 항목에서 2~3점이던 격차가 특정 영역에서는 크게 벌어집니다. ExploitBench는 Sol 73.5%, Terra 52.9%, Luna 33.2%입니다. SEC-Bench Pro도 71.2%, 57.7%, 48.9%로 20점 넘게 차이 납니다.
화면을 직접 조작하는 OSWorld 2.0은 62.6%, 50.2%, 45.6%이고, BrowseComp는 90.4%, 87.5%, 83.3%입니다. 게놈 워크플로를 재는 GeneBench Pro는 28.7%, 23.3%, 10.8%로 절대 점수가 낮습니다.
정리하면 Sol에 웃돈을 낼 근거는 일반 추론이 아니라 보안 분석, 컴퓨터 조작, 도메인 특화 워크플로에 있습니다. 이 세 가지가 아니라면 Sol 선택은 대체로 과지출입니다.
7월 30일 인하가 선택 기준을 한 번 뒤집었습니다
출시 3주 만인 7월 30일, OpenAI는 Luna 단가를 100만 토큰당 1달러/6달러에서 0.2달러/1.2달러로 80% 내렸습니다. Terra는 2.5달러/15달러에서 2달러/12달러로 20% 내렸고 Sol은 그대로입니다.
전 라인 인하로 보도된 곳이 많지만 Sol은 포함되지 않았습니다. 이 인하로 Sol 대비 Luna의 입력 단가 배수는 5배에서 25배로 커졌습니다.
결과적으로 분류·태깅·요약처럼 짧은 입력을 대량 처리하는 파이프라인은 Luna로 옮길 근거가 생겼습니다. 단, 앞서 본 MRCR 41.3%는 인하와 무관하게 그대로입니다.
이런 경우에는 세 모델 모두 답이 아닙니다
GPT-5.6 계열은 지원 범위 자체가 좁습니다. 세 모델 공통으로 아래 기능이 빠져 있어서, 기존 파이프라인을 통째로 옮기려다 막히는 경우가 많습니다.
- Realtime API 미지원 — 음성 실시간 대화 구성 불가
- 파인튜닝 미지원 — 도메인 튜닝 대신 프롬프트·캐싱으로 대응해야 함
- 임베딩·이미지 생성·오디오·모더레이션 엔드포인트 미지원
- 출력은 텍스트 전용 (입력은 텍스트와 이미지)
지식 컷오프가 2026년 2월 16일이라는 점도 걸립니다. 그 이후 사건이나 라이브러리 변경은 웹 검색 도구나 문서 주입으로 채워야 합니다. AI 도구를 조합할 때 이 경계를 먼저 확인하는 편이 안전합니다.
결론: Terra를 기본값에 두고 위아래로 예외를 만드세요
Terra는 대부분 벤치마크에서 Sol과 2~3점 차이인데 단가는 60% 저렴하고, 장문 회수율은 89.6%로 Sol에 근접합니다. 특별한 이유가 없다면 기본값은 Terra입니다. 여기서 두 방향으로만 예외를 두면 됩니다.
위로는 보안 분석, 컴퓨터 조작, 장기 에이전트 작업일 때 Sol로 올립니다. 아래로는 입력이 짧고 건수가 많은 분류·추출 작업일 때 Luna로 내리되, 긴 문서는 절대 넘기지 않습니다. 이 기준을 코드에 라우팅 규칙으로 박아두는 방식은 Codeforest에서 다루는 운영 자동화와도 맞물립니다.
