GPT-5.6 Sol 공개: 개발자가 먼저 봐야 할 모델 라인업 변화

OpenAI가 GPT-5.6 계열을 제한 프리뷰로 공개했다. 이름만 바뀐 모델 발표로 보면 놓치는 부분이 많다. 이번 발표의 핵심은 Sol, Terra, Luna라는 세 단계 라인업, 더 긴 reasoning effort, subagent 기반 ultra mode, 그리고 사이버·바이오 같은 고위험 영역을 전제로 한 단계적 배포 방식이다.

개발자 입장에서 중요한 질문은 단순하다. “지금 당장 기존 GPT-5.5 워크로드를 갈아타야 하나?” 답은 아직 아니다. 제한 프리뷰 단계라 접근 가능한 조직이 좁고, 실제 API 안정성·지연시간·비용 데이터가 충분히 쌓이지 않았다. 다만 앞으로 모델 선택 기준이 더 복잡해질 가능성은 높다. 기존처럼 “가장 똑똑한 모델 하나”를 고르는 방식보다, 작업별로 Sol·Terra·Luna를 나누는 운영 설계가 필요해진다.

왜 이번 발표가 중요한가

GPT-5.6은 단일 모델이 아니라 용도별 티어로 공개됐다. Sol은 플래그십, Terra는 일상 업무용 균형 모델, Luna는 빠르고 저렴한 모델이다. OpenAI 설명에 따르면 Terra는 GPT-5.5에 가까운 성능을 더 낮은 가격에 제공하고, Luna는 가장 낮은 비용대에서 강한 성능을 목표로 한다.

이 구조는 실제 제품 운영에 바로 영향을 준다. 예를 들어 코드 리뷰, 긴 문서 분석, 에이전트 계획 수립은 Sol 후보가 된다. 고객센터 요약, 내부 문서 검색 답변, 간단한 분류는 Terra나 Luna가 더 맞을 수 있다. 한 모델로 모든 요청을 처리하면 구현은 편하지만, 비용과 지연시간이 빠르게 비효율화된다.

또 하나의 변화는 “reasoning effort”가 더 세분화된다는 점이다. GPT-5.6 Sol에는 더 깊게 생각하는 max reasoning effort가 추가되고, ultra mode는 단일 에이전트를 넘어 subagent를 활용하는 방향으로 소개됐다. 복잡한 작업을 여러 하위 작업으로 나누는 패턴이 모델 레벨에서 더 자연스러워지는 셈이다.

모델 라인업을 제품에 매핑하는 방법

새 모델이 나오면 가장 흔한 실수는 기존 모델명을 검색해서 그대로 치환하는 것이다. 그러나 GPT-5.6 계열은 그렇게 접근하면 위험하다. 제품 기능을 먼저 작업 유형으로 분류해야 한다.

권장 분류는 네 가지다.

• 단순 응답: FAQ, 짧은 요약, 라벨링, 형식 변환
• 중간 추론: 고객 문의 triage, 문서 기반 답변, 코드 설명
• 장기 작업: 리팩터링 계획, 복잡한 SQL 작성, 여러 파일 검토
• 고위험 작업: 보안, 바이오, 법률, 금융, 계정 권한과 연결된 작업

단순 응답은 Luna 후보로 시작하고, 실패율이 높을 때 Terra로 올린다. 중간 추론은 Terra를 기본값으로 두고, 정확도 기준을 통과하지 못하는 케이스만 Sol로 승격한다. 장기 작업은 Sol을 검토하되, subtask 분해와 중간 검증을 반드시 넣는다. 고위험 작업은 모델 성능보다 정책·로깅·승인 플로우가 먼저다.

이런 라우팅을 구현하려면 요청마다 task_type, risk_level, expected_latency, max_cost 같은 메타데이터를 남기는 것이 좋다. 처음부터 완벽한 라우터를 만들 필요는 없다. 2주 정도 운영 로그를 쌓고, 실패한 요청만 상위 모델로 재처리하는 shadow evaluation부터 시작하면 된다.

가격과 캐싱에서 확인해야 할 숫자

공개된 가격은 100만 토큰 기준으로 Sol이 입력 $5, 출력 $30, Terra가 입력 $2.50, 출력 $15, Luna가 입력 $1, 출력 $6이다. 출력 토큰 단가가 입력보다 훨씬 비싸기 때문에, 긴 답변을 무제한 허용하는 UI는 비용을 빠르게 키운다.

특히 에이전트형 기능은 출력 토큰이 늘어나기 쉽다. 계획, 도구 호출 설명, 중간 상태, 최종 보고까지 모두 출력에 잡힌다. 따라서 개발 단계에서 max_output_tokens를 넉넉하게 열어두더라도, 프로덕션에서는 기능별 상한을 분리해야 한다.

GPT-5.6부터는 prompt caching도 더 명시적인 운영 대상으로 바뀐다. 발표에 따르면 explicit cache breakpoints와 30분 최소 cache life가 지원된다. 캐시 write는 uncached input rate의 1.25배로 과금되고, cache read는 기존처럼 cached input 90% 할인을 받는다.

이 말은 “자주 반복되는 긴 시스템 프롬프트나 정책 문서”가 있는 제품에서 비용 구조가 달라진다는 뜻이다. 예를 들어 80k 토큰짜리 제품 정책 문서를 매 요청마다 붙이는 RAG 시스템이라면, 캐시 경계 설정 하나로 비용 차이가 커질 수 있다. 반대로 매 요청마다 프롬프트 앞부분이 바뀌는 구조라면 캐시 적중률이 낮아진다.

안전 장치가 제품 UX에 미치는 영향

이번 발표에서 OpenAI는 사이버와 바이오 영역의 safeguards를 많이 강조했다. 실시간 classifier, generation 중단 후 상위 reasoning model 검토, account-level review, 차등 접근 같은 구조가 언급됐다. 이 내용은 정책 문서처럼 보이지만 실제 제품 UX와 연결된다.

개발자에게 필요한 대응은 세 가지다.

첫째, 사용자가 차단을 만났을 때 단순히 “요청 실패”로 보여주지 말아야 한다. 보안 코드 리뷰처럼 합법적인 dual-use 작업에서도 safeguard가 개입할 수 있다. 이때 사용자가 무엇을 바꿔야 하는지 모르면 이탈한다.

둘째, 재시도 로직은 무작정 반복하면 안 된다. 같은 입력을 반복 전송하면 계정 단위 risk signal에 악영향을 줄 수 있다. 대신 요청을 더 방어적 목적 중심으로 재구성하거나, 사람이 확인하는 플로우로 넘겨야 한다.

셋째, 로그에 refusal reason, task_type, user role, attached context를 남겨야 한다. 나중에 false positive를 줄이거나 공급사 지원팀과 논의하려면 근거가 필요하다.

도입 전 실험 설계

GPT-5.6을 바로 프로덕션 기본 모델로 바꾸기보다, 평가 세트를 먼저 만드는 것이 안전하다. 최소 50개, 가능하면 200개 이상의 실제 사용자 요청을 모아야 한다. 단순 성공 여부가 아니라 다음 기준으로 채점한다.

• 정답 정확도: 기존 모델 대비 개선이 있는가
• 비용: 요청당 총 토큰 비용이 얼마나 늘거나 줄었는가
• 지연시간: p50, p95 응답 시간이 제품 UX 기준을 넘지 않는가
• 안정성: 같은 입력에 대한 출력 변동성이 허용 가능한가
• 정책 개입: 정상 요청이 불필요하게 차단되는 비율은 얼마인가

특히 Sol과 Terra의 비교가 중요하다. Sol이 더 강하더라도 실제 제품 지표에서 Terra와 차이가 작다면 기본값은 Terra가 맞다. Sol은 실패 재처리, 관리자 도구, 고가치 워크플로우에 제한적으로 쓰는 편이 비용 효율적이다.

실행 체크리스트

• 기존 AI 기능을 단순 응답, 중간 추론, 장기 작업, 고위험 작업으로 분류한다.
• GPT-5.6 Sol, Terra, Luna 후보 라우팅 표를 만든다.
• 50개 이상의 실제 요청으로 baseline 평가 세트를 만든다.
• 출력 토큰 상한과 요약 길이 정책을 기능별로 분리한다.
• 반복 프롬프트가 긴 기능은 cache breakpoint 후보를 표시한다.
• safeguard 차단 로그를 실패 로그와 따로 저장한다.
• 제한 프리뷰 단계에서는 프로덕션 전환보다 shadow evaluation을 먼저 한다.

출처: OpenAI의 GPT-5.6 Sol 프리뷰 발표와 OpenAI API changelog 기준.