37편 · 약 18분

GPT-5.6 Sol·Terra·Luna: 세대와 능력 계층을 분리한 모델 패밀리와 Programmatic Tool Calling

왜 지금 봐야 하나

OpenAI는 2026년 7월 9일 GPT-5.6을 공개했다. 이번 릴리스가 단순한 모델 업데이트와 다른 이유는 두 가지다.

첫째, 이름 체계 자체가 바뀌었다. GPT-4o, GPT-4o mini처럼 한 모델 안에 경량 변종을 묶던 방식을 버리고, 세대 번호 × 능력 계층이라는 2차원 네임스페이스를 도입했다. Sol, Terra, Luna라는 세 계층은 각자 독립적인 학습·배포 주기를 가지면서 동시에 같은 베이스 학습 런에서 증류된다.

둘째, Programmatic Tool Calling이 Responses API의 정식 표면으로 올라왔다. 모델이 JavaScript를 직접 생성해 도구를 연속으로 호출하고 중간 결과를 처리하는 호스티드 런타임 경로가 생겼다. 이는 "모델이 한 번 답변할 때마다 사람이 orchestration을 넣는" 기존 루프를 특정 워크플로에서는 완전히 대체한다.

두 가지 모두 모델을 선택하고 API를 설계하는 방식에 직접 영향을 준다.

핵심 사양 한눈에 보기

항목	Sol	Terra	Luna
API 모델 ID	`gpt-5.6-sol`	`gpt-5.6-terra`	`gpt-5.6-luna`
`gpt-5.6` alias	Sol을 가리킴	—	—
입력 가격 (1M 토큰)	$5	$2.50	$1
출력 가격 (1M 토큰)	$30	$15	$6
컨텍스트 윈도	1.05M 토큰	1.05M 토큰	1.05M 토큰
최대 출력 토큰	128,000	128,000	128,000
지식 컷오프	2026-02-16	2026-02-16	2026-02-16
포지셔닝	복잡한 추론·코딩·장기 에이전트	일상 작업 균형	고처리량·저비용

세 모델이 동일한 컨텍스트 윈도와 출력 한계를 공유한다는 점이 중요하다. 능력 차이는 추론 깊이와 복잡한 다단계 작업의 품질에서 나타나고, context budget 자체는 같다.

GPT-5.6 세대 번호와 능력 계층 구조

GPT-5.6 모델 패밀리: 세대 번호와 능력 계층의 분리

1. 세대 번호와 능력 계층을 분리한 이유

기존 gpt-4o / gpt-4o mini 방식의 문제는 어느 것이 더 최신인지, mini와 full이 어떻게 다른지를 사용자가 직접 추론해야 했다는 것이다. GPT-5.5에서 GPT-5.5 Turbo가 나오고, 다음 달 GPT-5.5 mini가 나오면 이미 혼란이 시작된다.

5.6부터의 새 규칙은 단순하다.

숫자 = 세대: 5.6은 5.5보다 나중에 나온 베이스 훈련을 뜻한다.
이름 = 능력 계층: Sol은 항상 플래그십, Terra는 항상 균형, Luna는 항상 경량·고속이다.

Sol → 태양(최대 에너지), Terra → 지구(실용적 균형), Luna → 달(작고 빠름). 직관적인 이름이지만, 운영자 입장에서 더 중요한 것은 계층의 의미가 세대를 넘어 이어진다는 보장이다.

alias 정책과 호출 안정성

gpt-5.6은 현재 gpt-5.6-sol을 가리킨다. 이 alias는 새로운 세대가 출시되면 gpt-5.7-sol로 전환되지 않고, GPT-5.6 패밀리 안에서 Sol의 최신 버전을 계속 가리킨다. 즉,

최신 플래그십이 항상 필요한 앱 → gpt-5.6 또는 gpt-5.6-sol 사용
같은 Terra 계층에서 모델이 업데이트돼도 괜찮은 앱 → gpt-5.6-terra 사용
재현 가능성과 회귀 방지가 중요한 앱 → timestamp가 붙은 버전 고정 ID 사용 (OpenAI 릴리스 노트 권장)

이 정책은 이전 버전에서 mini-turbo-preview 같은 이름들이 언제 deprecated되는지 불확실했던 문제를 해소한다.

2. Programmatic Tool Calling: 모델이 도구 호출 코드를 직접 작성한다

GPT-5.6의 가장 큰 API 변화는 Programmatic Tool Calling이 Responses API의 공식 표면이 됐다는 것이다.

기존 방식과 무엇이 다른가

기존 tool use 흐름:

모델 응답 → tool_calls 추출 → 앱이 도구 실행 → 결과 다시 모델로 전달 → 반복

Programmatic Tool Calling:

모델이 JavaScript를 작성 → 호스티드 런타임이 도구를 직접 실행 → 중간 결과를 모델 없이 처리 → 최종 결과만 반환

핵심 차이는 중간 단계마다 모델의 추론 토큰을 소모하지 않는다는 것이다. 예를 들어 100개의 DB 레코드를 필터링하고 상위 5개를 랭킹하는 작업에서, 기존 방식은 각 필터 단계마다 모델 호출이 발생하지만, Programmatic Tool Calling은 모델이 처음에 전체 JavaScript 로직을 한 번 생성하면 런타임이 나머지를 실행한다.

어떤 작업에 맞는가

공식 문서가 명시한 적합한 작업 유형:

적합한 작업	적합하지 않은 작업
필터링, 조인, 랭킹	각 단계마다 새 정보로 판단이 필요한 작업
중복 제거, 집계, 검증	중간 결과에 따라 다음 도구를 바꿔야 하는 작업
사전 정의된 절차적 파이프라인	불확실성이 높고 유연한 계획이 필요한 작업
동일 로직을 여러 레코드에 반복 적용	Human-in-the-loop가 필요한 승인 흐름

"모델의 새로운 판단이 중간에 필요한가"가 핵심 판단 기준이다. 필요 없다면 Programmatic Tool Calling이 낫고, 필요하다면 기존 tool use 루프가 맞다.

API 구조

response = client.responses.create(
    model="gpt-5.6-terra",
    tools=[
        {"type": "programmatic_tool_calling"},  # 런타임 활성화
        {
            "type": "function",
            "name": "search_records",
            "allowed_callers": ["programmatic"]  # 프로그래매틱 호출 허용
        },
        {
            "type": "function",
            "name": "rank_results",
            "allowed_callers": ["programmatic"]
        }
    ],
    input=[{"role": "user", "content": "고객 ID 123~456 중 최근 7일 내 구매 있는 상위 5명을 찾아줘"}]
)

응답 구조:

program 아이템: 모델이 생성한 JavaScript 코드
program-issued 함수 호출: 런타임이 직접 실행
program_output 아이템: 최종 처리 결과

각 호출에는 call_id와 caller가 붙는다. 이 값을 보존해서 응답을 올바르게 연결해야 한다. 무시하면 multi-call 시나리오에서 결과 매핑이 깨진다.

Programmatic Tool Calling 동작 흐름

기존 Tool Use 루프

1. 모델 호출 → tool_calls 반환

↓ 앱이 실행

2. 도구 결과를 messages에 추가

↓ 다시 모델 호출

3. 모델이 결과 해석 → 다음 tool_call

↓ 반복 (N회)

4. 최종 응답

⚠ 각 중간 단계마다 모델 추론 비용 발생

→

Programmatic Tool Calling

1. 모델 호출 → program 아이템 반환
(JavaScript 로직 포함)

↓ 호스티드 런타임이 직접 실행

2. 런타임이 allowed_callers 도구 호출
(모델 개입 없음)

↓ 중간 결과 처리

3. 필터링·랭킹·집계 등 절차적 처리
(call_id로 결과 연결)

↓ 완료

4. program_output 반환

✓ 중간 단계에 모델 추론 비용 없음

GPT-5.6 Programmatic Tool Calling: 기존 tool use 루프와의 차이

3. Responses API가 중심 표면이 됐다

GPT-5.6과 함께 OpenAI는 새 기능의 진입점을 Responses API로 명확히 전환했다. Chat Completions API는 여전히 지원되지만, Programmatic Tool Calling, 멀티에이전트 구성, 지속적 추론 상태(persisted reasoning)는 모두 Responses API에서만 동작한다.

이전 코드와의 호환성

Chat Completions에서 Responses API로 전환할 때 핵심 차이:

항목	Chat Completions	Responses API
요청 필드	`messages`	`input`
응답 구조	`choices[0].message`	`output` 아이템 목록
도구 호출 결과	`tool` role message	`function_call_output` 아이템
스트리밍	SSE delta	SSE 이벤트 스트림
상태 유지	앱이 직접 messages 관리	`previous_response_id`로 서버 측 유지

기존 Chat Completions 코드를 그대로 두고 GPT-5.6을 쓰는 것은 가능하다. 하지만 Programmatic Tool Calling, 지속적 컨텍스트, 향후 추가될 멀티에이전트 기능을 쓰려면 Responses API 전환이 필요하다.

4. 운영자가 바로 받는 영향

모델 선택 결정 트리

문제의 복잡도와 비용이 모두 중요하다
    ├── 복잡한 다단계 추론, 고품질 코딩, 장기 계획 → Sol ($5/$30)
    ├── 대부분의 프로덕션 작업, GPT-5.5 수준 품질로 충분 → Terra ($2.50/$15)
    └── 분류, 필터, 간단한 QA, 고처리량 파이프라인 → Luna ($1/$6)

가격은 같아도 컨텍스트를 많이 쓰는지가 비용을 좌우한다. 1.05M 토큰 윈도를 실제로 채우는 작업이라면, 어떤 계층을 선택하든 컨텍스트 비용이 가장 크다.

Programmatic Tool Calling 도입 판단 기준

다음 조건이 모두 해당하면 도입 가치가 있다:

동일한 도구 호출 패턴이 여러 레코드에 반복 적용된다.
중간 결과마다 모델의 새 판단이 필요하지 않다.
기존 방식에서 중간 tool use 라운드트립이 비용이나 지연의 병목이다.

다음 조건 중 하나라도 해당하면 기존 방식이 낫다:

다음 도구를 무엇을 쓸지 중간 결과에 따라 결정해야 한다.
Human approval 흐름이 포함된다.
외부 상태에 따라 다음 행동이 달라지는 불확실한 시나리오다.

호출 비용 예상

Terra 기준으로 간단한 계산:

시스템 프롬프트 2K + 사용자 입력 500 + 컨텍스트 없음 → ~3K 입력 토큰
→ 비용: $0.0075 / 호출
월 100만 호출 → ~$7,500

Sol은 Terra의 2배, Luna는 Terra의 40% 수준이다. Luna로 충당 가능한 작업을 Sol로 돌리면 2.5배 차이가 난다.

5. 이 릴리스에서 특히 조심할 한계

Programmatic Tool Calling은 allowed_callers 설정을 꼭 봐야 한다. 도구를 등록만 하고 allowed_callers: ["programmatic"]을 빠뜨리면 런타임이 그 도구를 실행하지 못한다. 에러 메시지가 모호할 수 있어 디버깅이 어렵다.
call_id / caller 무시는 운영 위험이다. multi-call 시나리오에서 이 값을 보존하지 않으면 결과 매핑이 틀릴 수 있다. 단일 호출 테스트에서는 문제가 안 보여 지나치기 쉽다.
alias(gpt-5.6)는 Sol을 가리키고, 나중에 Sol이 내부적으로 갱신되면 응답이 달라질 수 있다. 회귀 테스트 기준을 alias가 아닌 고정 ID 기반으로 만들어 두는 것이 안전하다.
세 모델 모두 1.05M 토큰 윈도를 공유하지만, 긴 컨텍스트에서의 품질은 Sol이 다르다. 64K+ 이상의 긴 컨텍스트에서 Terra나 Luna가 정보를 얼마나 잘 통합하는지는 별도 검증이 필요하다.
지식 컷오프는 2026년 2월 16일이다. 그 이후의 사건이나 릴리스에 대한 답변은 할루시네이션 위험이 있다.

결국 GPT-5.6의 핵심은 "더 강한 모델이 나왔다"보다, 모델 패밀리를 어떻게 고정하고 어떤 API 표면으로 다룰지 설계를 다시 해야 한다는 데 있다. alias 정책, Responses API 전환, Programmatic Tool Calling 적용 경계 — 이 세 가지가 이 릴리스에서 운영자가 실제로 결정해야 할 사항이다.