GPT-5.6 Sol 프리뷰: 모델 티어가 바꾸는 AI 제품 운영 기준

GPT-5.6 Sol 프리뷰에서 눈에 띄는 부분은 Sol 하나만이 아니다. OpenAI는 GPT-5.6 시리즈를 Sol, Terra, Luna 세 티어로 설명했다. Sol은 플래그십, Terra는 일상 업무용 균형 모델, Luna는 빠르고 저렴한 모델이다. 개발자에게 중요한 질문은 “어느 모델이 가장 똑똑한가”가 아니라 “제품 안에서 어떤 요청을 어느 티어로 보낼 것인가”다.

OpenAI는 발표에서 Terra가 GPT-5.5와 경쟁력 있는 성능을 내면서 비용은 2배 저렴하다고 설명했다. Luna는 가장 낮은 비용 구간에서 강한 성능을 제공한다고 소개됐다. Sol은 코딩, 생명과학, 사이버보안 같은 장기 추론 작업에서 성능을 끌어올리고, 더 긴 reasoning effort와 subagent 기반 ultra mode를 제공하는 방향으로 설명됐다.

이 구조는 AI 제품 운영 방식에 직접적인 영향을 준다. 지금까지 많은 팀은 “기본 모델 하나 + 가끔 고급 모델” 정도로 운영했다. 하지만 티어가 명확해지면 요청 분류, 비용 한도, 캐시, 재시도 정책을 제품 로직의 일부로 설계해야 한다. 모델 선택이 백엔드 아키텍처 문제가 되는 셈이다.

Sol, Terra, Luna를 기능 단위로 나누는 법

모델 티어를 비용순으로만 나누면 실패한다. 싼 모델을 많이 쓰다가 품질이 떨어지고, 비싼 모델을 기본값으로 쓰면 마진이 무너진다. 기준은 요청의 위험도와 되돌리기 비용이다.

Luna에 어울리는 작업은 빠른 초안, 분류, 태깅, 짧은 요약, 검색 쿼리 생성처럼 실패해도 쉽게 재시도할 수 있는 작업이다. 예를 들어 고객 피드백 1,000개를 기능 요청·버그·불만으로 1차 분류하는 일은 Luna급 모델로 시작하고, 애매한 항목만 상위 모델로 올리는 구조가 맞다.

Terra에 어울리는 작업은 일반적인 문서 작성, 고객 응대 초안, 코드 설명, 사내 검색 답변처럼 품질과 비용 균형이 필요한 작업이다. 사용자에게 바로 보이는 결과이지만, 사람이 수정할 수 있거나 위험도가 낮은 영역이다.

Sol에 어울리는 작업은 장기 계획, 복잡한 코드 수정, 보안 분석, 다중 도구 사용, 높은 정확도가 필요한 의사결정 보조다. 실패했을 때 비용이 큰 작업, 여러 단계의 reasoning이 필요한 작업, 도구 호출이 많이 엮인 작업은 Sol로 보내는 편이 낫다.

라우팅 규칙이 없으면 비용 최적화는 불가능하다

AI API 비용을 줄이려면 “모델을 싸게 바꾸자”가 아니라 라우팅 규칙을 만들어야 한다. 실무에서 쓸 수 있는 최소 규칙은 네 단계다.

첫째, 요청을 유형별로 분류한다. 예를 들어 summarize, classify, draft, code_edit, security_review, agent_workflow처럼 나눈다. 둘째, 각 유형에 기본 모델과 승급 조건을 둔다. 셋째, 실패 또는 낮은 신뢰도일 때만 상위 모델로 재시도한다. 넷째, 최종 응답에 사용 모델과 비용 추정치를 로그로 남긴다.

예시는 이렇다.

• classify: Luna 기본, confidence 0.75 미만이면 Terra
• draft: Terra 기본, 법무·보안 키워드가 있으면 Sol
• code_edit: Terra 기본, 파일 5개 이상 변경 또는 테스트 실패 2회 이상이면 Sol
• agent_workflow: Sol 기본, 단순 조회 작업은 Terra로 하위 라우팅
• security_review: Sol 기본, exploit 생성 요청은 정책 레이어에서 차단

중요한 건 라우팅 결과를 감으로 보지 않는 것이다. 요청 유형별 평균 입력 토큰, 출력 토큰, 재시도율, 사용자 수정률을 남겨야 한다. 비용은 토큰 단가만으로 결정되지 않는다. 긴 프롬프트, 과도한 컨텍스트, 실패 후 재시도, 불필요한 도구 호출이 합쳐져 실제 청구액을 만든다.

reasoning effort와 ultra mode를 제품에 넣는 기준

GPT-5.6 Sol 발표에는 더 깊게 생각하는 max reasoning effort와 subagent를 활용하는 ultra mode가 등장한다. 이 기능은 매력적이지만 기본값으로 켜면 위험하다. 시간이 길어지고, 비용이 늘고, 사용자가 기다려야 한다.

따라서 reasoning effort는 사용자 플랜, 요청 중요도, 예상 비용에 따라 다르게 적용해야 한다. 무료 사용자에게 모든 요청을 high effort로 처리하면 서비스가 지속되지 않는다. 반대로 엔터프라이즈 고객의 보안 리뷰나 대규모 마이그레이션에는 높은 effort를 쓰는 것이 합리적이다.

ultra mode도 마찬가지다. subagent 병렬화는 복잡한 작업을 빠르게 풀 수 있지만, 각 subagent가 서로 다른 가정을 하면 결과 병합이 어려워진다. 제품에 넣을 때는 subagent별 역할, 산출물 형식, 충돌 해결 규칙을 미리 정해야 한다. “알아서 나눠서 해줘”보다 “보안, 성능, UX 세 관점으로 나눠 검토하고 마지막에 충돌점을 표로 정리해줘”가 훨씬 안정적이다.

안전장치가 운영 기능이 되는 이유

OpenAI는 GPT-5.6 Sol에 대해 사이버 요청, 고위험 활동, 반복적 악용에 대한 보호를 강화했다고 설명했다. 실시간 misuse classifier, 계정 단위 리뷰, 차등 접근 같은 레이어도 언급됐다.

제품 개발팀은 이를 단순한 공급사 정책으로 보면 안 된다. 모델 공급사의 안전장치가 개입하면 응답이 지연되거나 거절될 수 있다. 즉, 이것도 사용자 경험의 일부다.

예를 들어 개발자 도구에서 보안 분석 기능을 제공한다면, 사용자가 합법적인 취약점 점검을 요청했는데 모델이 거절할 수 있다. 이때 제품은 “다시 시도하세요”가 아니라 허용되는 입력 예시, 필요한 증빙, 대체 워크플로우를 제공해야 한다. 공급사 정책 변화에 따라 기능 품질이 흔들리지 않게 fallback 모델 또는 사람 승인 루트도 필요하다.

바로 적용할 운영 체크리스트

• 요청 유형별 기본 모델을 정했는가
• 상위 모델로 승급하는 조건을 로그 기반으로 정의했는가
• reasoning effort를 사용자 플랜과 작업 위험도에 연결했는가
• subagent 사용 시 역할, 산출물, 병합 규칙을 정했는가
• 모델별 토큰 사용량, 재시도율, 지연 시간을 대시보드로 보고 있는가
• 안전장치로 응답이 거절될 때 사용자에게 설명과 대안을 제공하는가
• 고위험 작업은 모델 라우팅 전에 정책 레이어에서 먼저 걸러내는가

GPT-5.6 Sol 프리뷰의 핵심은 플래그십 모델 경쟁만이 아니다. AI 제품이 성숙할수록 모델은 하나의 엔진이 아니라 여러 티어의 운영 자원이 된다. 좋은 제품은 가장 강한 모델을 많이 쓰는 제품이 아니라, 요청의 위험도와 가치에 맞춰 모델을 정확히 배치하는 제품이다.