ChatGPT 모델 선택 기준: GPT-5.6 Sol·Terra·Luna와 Codex 종류 정리

ChatGPT 모델 선택 기준: GPT-5.6 Sol·Terra·Luna와 Codex 종류 정리

핵심 요약

  • GPT-5.6의 핵심은 “더 강한 모델 하나”가 아니라 Sol, Terra, Luna처럼 업무 성격에 따라 지능·속도·비용을 나누어 선택하는 구조다.
  • ChatGPT 모델 선택은 이제 개인 취향이 아니라 업무 설계의 일부다. 빠른 답변, 긴 문서 작성, 전략 판단, 코드 수정, 대량 처리에는 서로 다른 기본값이 필요하다.
  • Codex 통합은 단순한 코드 생성 기능 추가가 아니다. 저장소를 읽고, 파일을 고치고, 테스트하고, 리뷰하는 실행형 작업 흐름이 ChatGPT 안으로 들어오는 변화다.
  • ChatGPT Work와 Codex 기반 기능은 ChatGPT를 “대화창”에서 “업무를 배정하고 결과를 검수하는 작업 플랫폼”으로 확장한다.
  • 기업은 최신 모델명을 외우는 것보다 작업 분류표, 비용 한도, 보안 경계, 검수 책임, Codex 권한 정책을 먼저 정해야 한다.

“가장 좋은 모델”을 고르던 시대가 끝나고 있다

ChatGPT를 업무에 쓰기 시작한 실무자에게 가장 흔한 질문은 오랫동안 단순했다. “어떤 모델이 제일 좋나?”였다. 보고서 초안, 시장 조사, 코드 설명, 회의록 요약, 이메일 작성처럼 결과물이 대화창 안에서 끝나는 작업이라면 이 질문은 어느 정도 통했다. 사용자는 가능한 한 똑똑한 모델을 고르고, 응답이 느리거나 사용량 제한이 걸리면 한 단계 낮은 모델로 내려가면 됐다.

GPT-5.6과 Codex 통합 이후의 질문은 다르다. 이제 중요한 질문은 “가장 좋은 모델이 무엇인가”가 아니라 “이 작업은 어떤 모델과 어떤 실행 도구에 맡겨야 하는가”다. OpenAI는 GPT-5.6을 Sol, Terra, Luna로 나누어 설명한다. Sol은 플래그십이자 가장 높은 역량의 모델, Terra는 더 낮은 비용의 강한 선택지, Luna는 가장 빠르고 비용 효율적인 선택지로 소개된다. 이 구분은 단순한 상품 포장이 아니다. AI 사용이 대화형 질의응답에서 업무 단위 실행으로 이동할수록, 모델 선택은 속도·비용·정확도·추론 깊이·실행 권한을 함께 설계하는 문제가 된다. 출처: GPT-5.6: Frontier intelligence that scales with your ambition, A preview of GPT-5.6 Sol, Terra, and Luna

이 변화는 특히 ChatGPT를 실제 업무 도구로 쓰는 사람에게 중요하다. 기획자는 아이디어를 정리하는 작업과 경영진 의사결정 문서를 만드는 작업을 같은 모델에 맡길 필요가 없다. 개발자는 함수 하나를 설명받는 작업과 저장소 전반을 수정하고 테스트하는 작업을 같은 도구로 처리해서는 안 된다. 데이터 분석가는 간단한 지표 해석과 분석 파이프라인 수정 요청을 구분해야 한다. 콘텐츠 담당자는 초안 변형과 법무·브랜드 리스크가 있는 공개 원고를 구분해야 한다. 모델 선택은 더 이상 “답변 스타일” 문제가 아니라 작업 위험도와 결과물 책임을 나누는 운영 기준이다.

GPT-5.6 라인업의 의미: 성능표보다 중요한 것은 역할 분리다

GPT-5.6 Sol, Terra, Luna의 차이를 이해할 때 벤치마크 순위표부터 보는 것은 실무적으로 큰 도움이 되지 않는다. 물론 최고 성능 모델은 중요하다. 복잡한 추론, 장기 프로젝트, 어려운 코드 수정, 전문 영역 검토에서는 상위 모델의 차이가 실제 결과물 품질로 이어질 수 있다. 하지만 대부분의 조직은 모든 요청을 최고급 모델로 보내지 않는다. 이유는 단순하다. 업무량은 많고, 요청의 난이도는 제각각이며, 비용과 지연 시간은 현실적인 제약이기 때문이다.

공식 설명 기준으로 GPT-5.6은 소프트웨어 엔지니어링, 컴퓨터 사용, 전문 지식 업무, 과학 연구, 사이버 보안 같은 영역에서 전반적인 역량을 끌어올린 모델군이다. 그러나 같은 계열 안에서도 Sol, Terra, Luna의 위치는 다르다. Sol은 고난도 추론과 장기 에이전트 작업에 배치하기 좋은 상위 선택지로 해석할 수 있다. Terra는 일상 업무와 비용 사이의 균형점이다. Luna는 빠른 응답과 대량 처리, 반복 작업에 적합한 경량 선택지다. 여기서 중요한 것은 “Sol이 항상 정답”이 아니라 “작업의 손실 비용이 큰 경우에 Sol을 써야 할 이유가 생긴다”는 점이다. 출처: GPT-5.6: Frontier intelligence that scales with your ambition, A preview of GPT-5.6 Sol, Terra, and Luna

예를 들어 영업팀이 고객 미팅 메모 100건을 표준 형식으로 요약해야 한다면, 최고 추론 모델보다 빠르고 비용 효율적인 모델이 더 합리적일 수 있다. 반대로 인수합병 검토 문서, 장애 원인 분석, 보안 취약점 패치 전략처럼 한 번의 판단 오류가 큰 비용을 만들 수 있는 작업은 더 깊은 추론 모델을 써야 한다. 코드 작업도 마찬가지다. “이 오류 메시지가 무슨 뜻인가”는 일반 대화 모델로 충분할 수 있지만, “이 저장소에서 결제 흐름을 바꾸고 테스트까지 통과시켜라”는 Codex 같은 실행형 도구의 영역이다.

작업 유형별 모델 선택 기준

작업 유형 권장 접근 이유 검수 기준
빠른 질의응답, 용어 설명, 짧은 요약 Luna 또는 경량 모델 우선 속도와 비용이 중요하고 실패 비용이 낮음 핵심 사실, 최신성, 출처 확인
일반 문서 작성, 회의록 정리, 기획 초안 Terra 또는 균형형 모델 품질과 처리량의 균형이 필요 문맥 누락, 과장 표현, 조직 톤
전략 문서, 의사결정 메모, 리스크 분석 Sol 또는 고추론 설정 다단계 추론과 반론 검토가 중요 근거, 대안, 불확실성 표시
대량 분류, 반복 요약, 태깅 Luna/Terra와 자동화 흐름 단가와 처리 안정성이 중요 샘플링 검수, 오류율 측정
코드 설명, 작은 코드 조각 생성 대화형 모델 또는 Codex 경량 작업 저장소 변경 없이도 해결 가능 실행 가능성, 보안 취약점
저장소 수정, 테스트, 리뷰, 리팩터링 Codex 파일 읽기·수정·검증이 필요 diff, 테스트 결과, 권한 범위
병렬 탐색, 대규모 코드베이스 분석 Codex Subagents 여러 하위 작업을 동시에 탐색 가능 하위 결과 충돌, 통합 판단

다만 여기서 말하는 모델 선택은 표준 ChatGPT 대화창의 모델 선택만을 의미하지 않는다. OpenAI Help Center 기준으로 GPT-5.6 Terra와 Luna는 표준 ChatGPT 대화에서는 직접 선택되지 않으며, Work in ChatGPT, Codex, API에서 제공되는 모델로 구분된다. 따라서 이 글의 모델 선택 기준은 일반 대화, ChatGPT Work, Codex, API 활용까지 포함한 업무 선택 기준으로 이해해야 한다. 출처: A preview of GPT-5.6 Sol, Terra, and Luna

이 표에서 봐야 할 것은 모델명 자체가 아니라 분기 기준이다. 낮은 위험·높은 반복성 작업은 빠르고 저렴한 쪽으로 보낸다. 높은 위험·낮은 반복성 작업은 느리더라도 더 강한 모델과 더 촘촘한 검수 흐름을 붙인다. 실제 파일 변경이 필요하면 대화 모델 안에서 코드 블록을 복사하는 방식보다 Codex로 넘기는 편이 더 자연스럽다. Codex는 OpenAI가 “코드를 작성하고, 이해하고, 리뷰하고, 디버그하는” 소프트웨어 개발용 에이전트로 설명하는 제품군이다. 출처: Codex | AI Coding Partner from OpenAI, Code generation

Codex 통합은 “코드 생성”이 아니라 “작업 실행”의 문제다

Codex를 여전히 “코드를 써주는 기능”으로만 보면 이번 변화를 절반만 보는 것이다. 코드 생성은 오래전부터 가능했다. 개발자가 대화창에 “파이썬으로 CSV를 읽는 함수를 만들어줘”라고 입력하면 모델은 그럴듯한 코드를 출력했다. 그러나 실무 개발은 코드 조각 생성으로 끝나지 않는다. 기존 저장소의 구조를 읽어야 하고, 테스트 관례를 따라야 하며, 이미 작성된 타입·상태관리·배포 스크립트와 충돌하지 않아야 한다. PR 리뷰에서 지적될 만한 변경을 줄여야 하고, 실패한 테스트 로그를 보고 다시 고쳐야 한다.

Codex의 의미는 이 지점에서 생긴다. Codex는 작업 지시를 받아 코드베이스를 탐색하고, 필요한 파일을 수정하고, 테스트와 리뷰 흐름을 이어갈 수 있는 에이전트형 도구로 해석해야 한다. OpenAI 개발자 문서도 Codex를 단독 대화 모델이라기보다 MCP, Skills, Subagents, Agents SDK 같은 실행 구조와 연결해 설명한다. 예를 들어 MCP는 모델을 외부 도구와 컨텍스트에 연결하는 방식이며, Skills는 Codex가 특정 업무 절차를 반복 가능하게 수행하도록 지침·리소스·선택적 스크립트를 묶는 구조다. 출처: Model Context Protocol – Codex, Agent Skills – Codex

실무 흐름으로 바꾸면 다음과 같다.

대화형 요청
  ↓
작업 분류: 설명인가, 초안인가, 실제 변경인가
  ↓
모델 선택: 빠른 모델 / 균형 모델 / 고추론 모델
  ↓
실행 도구 선택: ChatGPT 답변 / Codex 작업 / MCP 연결 / Subagents
  ↓
결과 검수: diff, 테스트, 출처, 보안, 정책 준수
  ↓
사람의 승인 또는 재작업 지시

이 구조에서 사람의 역할은 줄어드는 것이 아니라 이동한다. 개발자는 반복적인 파일 탐색과 작은 수정 일부를 Codex에 맡길 수 있다. 그러나 요구사항 해석, 아키텍처 판단, 장애 위험 평가, 개인정보와 보안 정책, 배포 승인 같은 책임은 여전히 사람이 가져야 한다. 특히 Codex가 저장소에 접근할 수 있는 환경에서는 권한 범위가 곧 리스크 범위다. 어떤 브랜치에서 작업할지, 어떤 파일은 수정 금지인지, 테스트 없이 완료 처리할 수 없는 작업은 무엇인지, 외부 MCP 도구가 어떤 데이터에 접근할 수 있는지 정해야 한다.

ChatGPT Work와 “작업 플랫폼”으로서의 ChatGPT

OpenAI는 ChatGPT Work를 GPT-5.6 기반으로 소개하며, 팀의 도구에서 온 컨텍스트를 모아 흩어진 노트·초안·아이디어를 완성된 결과물로 바꾸는 방향을 제시한다. 또한 “Codex technology built-in”이라는 표현으로 ChatGPT가 질문에 답하는 수준을 넘어 웹, 모바일, 데스크톱 전반에서 실제 일을 처리하는 방향으로 확장되고 있다고 설명한다. 이 설명을 그대로 실무 언어로 옮기면, ChatGPT는 단순한 챗봇이 아니라 업무 배정 인터페이스에 가까워지고 있다. 출처: ChatGPT Work with GPT-5.6, ChatGPT is now a partner for your most ambitious work

이 변화가 중요한 이유는 사용자가 AI에게 기대하는 결과물의 단위가 바뀌기 때문이다. 과거의 단위는 “답변”이었다. 사용자는 질문을 입력하고, 모델은 텍스트를 출력했다. 이제 단위는 “작업”으로 이동한다. 사용자는 “경쟁사 자료를 읽고 포지셔닝 문서를 만들어라”, “이 저장소의 인증 흐름을 검토하고 취약한 부분을 고쳐라”, “회의록과 문서 초안을 바탕으로 다음 주 실행 계획을 만들어라”처럼 결과물 중심으로 지시한다. 이때 모델은 단순히 문장을 생성하는 것이 아니라 문서, 코드, 분석, 검토, 실행 로그를 연결해야 한다.

ChatGPT가 작업 플랫폼이 된다는 말은 모든 업무가 자동으로 끝난다는 뜻이 아니다. 오히려 반대에 가깝다. 플랫폼화가 진행될수록 조직은 AI에게 맡길 수 있는 일과 맡기면 안 되는 일을 더 명확히 정의해야 한다. 예를 들어 고객 데이터가 포함된 문서를 요약할 수 있는지, 소스코드 저장소를 수정할 수 있는지, 외부 브라우저나 업무 도구에 접근할 수 있는지, 결과물을 바로 발행할 수 있는지 같은 권한 정책이 필요해진다. ChatGPT가 업무의 중심 인터페이스가 될수록 모델 선택은 개인의 취향보다 조직 운영의 일부가 된다.

Sol, Terra, Luna를 실무 언어로 번역하기

Sol, Terra, Luna라는 이름만 보면 제품 라인업처럼 보인다. 그러나 조직에서 필요한 것은 이름 암기가 아니라 역할 번역이다. 다음처럼 해석하면 실무 적용이 쉽다.

Luna: 빠른 처리와 반복 업무의 기본값

Luna는 공식 설명에서 가장 빠르고 비용 효율적인 모델로 소개된다. 따라서 첫 번째 후보는 낮은 위험의 반복 작업이다. 이메일 초안 여러 개 만들기, 회의록을 일정한 형식으로 정리하기, 고객 피드백을 태그로 분류하기, 내부 문서를 짧게 요약하기, 긴 문서에서 할 일 목록을 추출하기 같은 작업이다. 여기서 중요한 것은 완벽한 판단보다 처리량과 일관성이다. 출처: A preview of GPT-5.6 Sol, Terra, and Luna

다만 Luna 같은 경량 선택지를 쓸 때도 “저위험”이라는 전제가 필요하다. 법무 검토, 공개 보도자료, 채용 평가, 보안 판단처럼 잘못된 문장 하나가 문제가 되는 작업은 단순히 빠르다는 이유로 보내면 안 된다. 경량 모델은 초안을 만들고 후보를 넓히는 데 쓰고, 최종 판단은 더 강한 모델 또는 사람 검토로 넘기는 흐름이 적절하다.

Terra: 대부분의 지식 업무를 감당하는 균형점

Terra는 강한 저비용 선택지로 설명된다. 실무에서는 가장 넓게 쓰일 가능성이 있는 기본값이다. 기획서 초안, 정책 문서 요약, 시장 분석 정리, 제품 요구사항 문서의 구조화, 고객 인터뷰 요약, 데이터 분석 결과 해석처럼 “상당한 품질은 필요하지만 매번 최고 추론까지는 필요하지 않은” 작업에 맞는다. 출처: GPT-5.6: Frontier intelligence that scales with your ambition

Terra를 기본값으로 둘 때의 장점은 비용과 품질의 균형이다. 팀 전체에 AI 사용을 확산하려면 일부 전문가만 쓰는 최고급 모델보다, 대부분의 작업에서 충분한 품질을 내는 모델이 중요하다. 단, Terra가 기본값이라는 말은 모든 작업을 Terra로 끝낸다는 뜻이 아니다. Terra로 초안을 만들고, 중요 문서는 Sol로 반론 검토를 시키거나 사람 리뷰를 붙이는 방식이 더 안정적이다.

Sol: 고난도 판단과 장기 작업의 집중 자원

Sol은 GPT-5.6 계열의 플래그십이자 가장 높은 역량의 모델로 소개된다. 실무적으로는 희소한 자원처럼 다루는 편이 낫다. 모든 요청에 Sol을 쓰는 것이 아니라, 작업 실패 비용이 크거나 문맥이 길고 복잡하거나 여러 제약을 동시에 만족해야 하는 경우에 배치한다. 예를 들어 기술 전략 검토, 보안 아키텍처 리뷰, 복잡한 장애 원인 분석, 다부서 프로젝트 계획, 장기 리서치 보고서, 고난도 코드베이스 수정 검토가 여기에 해당한다. 출처: GPT-5.6: Frontier intelligence that scales with your ambition

Sol을 쓸 때도 주의할 점이 있다. 상위 모델은 더 나은 추론을 제공할 수 있지만, 조직의 책임을 대신하지 않는다. 모델이 제시한 결론은 근거·반례·불확실성·대안과 함께 검토해야 한다. 특히 보안, 법무, 의료, 금융, 인사처럼 결과물의 책임 소재가 민감한 영역에서는 “상위 모델이 말했으니 신뢰한다”가 아니라 “상위 모델을 1차 분석 도구로 쓰고 사람이 승인한다”가 운영 원칙이어야 한다.

기존 모델 사용자에게 필요한 전환 기준

많은 팀은 이미 GPT-5.4 Mini, GPT-5.4, GPT-5.5 같은 이전 세대 또는 기존 업무 기본 모델을 정해두었을 수 있다. 이 경우 GPT-5.6이 나왔다고 해서 모든 워크플로를 즉시 교체하는 방식은 권하지 않는다. 전환은 모델명 기준이 아니라 업무군 기준으로 해야 한다. 기존 모델에서 충분히 잘 처리되던 낮은 위험의 반복 작업은 유지하거나 Luna/Terra 계열로 단계적으로 옮긴다. 반대로 기존 모델에서 자주 실패하던 장기 추론, 복잡한 코드 수정, 멀티문서 분석, 고위험 의사결정 지원은 Sol 또는 Codex 기반 흐름으로 재설계한다.

전환 기준은 네 가지 질문으로 정리할 수 있다.

  1. 이 작업은 실패했을 때 비용이 큰가?
  2. 이 작업은 긴 문맥과 여러 제약을 동시에 다루는가?
  3. 이 작업은 실제 파일, 코드, 외부 도구 접근이 필요한가?
  4. 이 작업은 반복량이 많아 단가와 속도가 중요한가?

첫째와 둘째가 강하면 고추론 모델을 우선한다. 셋째가 강하면 Codex나 MCP 연결이 필요하다. 넷째가 강하면 경량 모델과 자동화가 중요하다. 이 질문에 답하지 않은 채 “신모델이니까 전부 바꾸자”고 접근하면 비용은 늘고 운영 기준은 흐려진다.

Codex를 어디까지 허용할 것인가

Codex 통합의 실무적 쟁점은 기능보다 권한이다. 코드 생성만 할 때는 사용자가 출력된 코드를 복사해 붙여넣었다. 이 구조에서는 최종 수정 권한이 사람에게 있었다. 그러나 Codex가 저장소 기반으로 작업하고, MCP를 통해 외부 도구와 컨텍스트에 연결되며, Subagents를 통해 여러 하위 작업을 병렬로 수행할 수 있다면 이야기가 달라진다. 생산성은 올라갈 수 있지만, 권한 설계가 없으면 검수되지 않은 변경, 민감 데이터 노출, 테스트 누락, 책임 경계 혼선이 생길 수 있다. 출처: Model Context Protocol – Codex, Subagents – Codex

조직은 Codex 사용을 최소 세 단계로 나누는 것이 좋다.

단계 허용 범위 적합한 작업 필수 통제
읽기 전용 저장소 탐색, 코드 설명, 영향 범위 분석 온보딩, 코드 리뷰 준비, 장애 원인 후보 탐색 민감 파일 접근 제한, 결과 출처 표시
제한 수정 지정 브랜치·지정 디렉터리 수정 버그 수정, 테스트 보강, 문서 업데이트 diff 리뷰, 테스트 실행, PR 승인
실행 자동화 테스트·빌드·도구 호출, 병렬 하위 작업 대규모 리팩터링, 마이그레이션, 반복 수정 권한 분리, 로그 보존, 롤백 계획

중요한 것은 Codex를 막느냐 허용하느냐의 이분법이 아니다. 작업별로 허용 권한을 나누는 것이다. 예를 들어 신규 입사자가 코드베이스를 이해하는 용도라면 읽기 전용 Codex가 큰 도움이 될 수 있다. 반면 결제, 인증, 개인정보 처리 모듈을 수정하는 작업은 제한 수정 단계에서도 더 강한 리뷰와 테스트가 필요하다. 운영팀이 반복 배포 스크립트 수정을 Codex에 맡긴다면, 테스트 결과뿐 아니라 변경 로그와 승인 기록이 남아야 한다.

ChatGPT 모델 선택을 위한 실무 시나리오

시나리오 1: PM의 제품 요구사항 문서 작성

상황은 신규 기능의 제품 요구사항 문서를 작성해야 하는 경우다. 입력 자료는 고객 인터뷰, 경쟁사 기능 메모, 내부 회의록, 기존 제품 정책이다. 이때 처음부터 Sol을 쓰기보다 Terra로 자료를 구조화하고 초안을 만든 뒤, Sol로 누락된 리스크와 반론을 검토하는 흐름이 적합하다.

실행 흐름은 간단하다. 먼저 Terra에 “자료를 기능 목표, 사용자 문제, 핵심 요구사항, 비범위, 지표, 리스크로 재분류하라”고 맡긴다. 이후 Sol에 “이 문서가 실제 개발 착수 전에 부족한 점을 지적하고, 우선순위 충돌과 기술 리스크를 찾아라”고 요청한다. 최종 출력은 PM이 편집하고, 개발 리더와 데이터 담당자가 검토한다. 주의점은 AI가 만든 요구사항이 합의된 요구사항이 아니라는 점이다. AI는 구조화와 반론 생성에는 강하지만, 조직의 우선순위와 책임을 대신 결정하지 않는다.

시나리오 2: 개발자의 버그 수정과 테스트

상황은 특정 API에서 간헐적으로 오류가 발생하고 로그와 재현 조건이 일부만 있는 경우다. 대화형 모델에 오류 메시지를 설명하게 하는 것은 출발점으로 충분하다. 하지만 저장소를 수정해야 한다면 Codex로 전환해야 한다. Codex에 관련 파일 탐색, 원인 후보 정리, 최소 수정안 작성, 테스트 실행까지 맡기고, 개발자는 diff와 테스트 결과를 검토한다.

여기서 모델 선택의 핵심은 “코드를 생성할 것인가, 코드베이스를 변경할 것인가”다. 전자는 ChatGPT 대화로도 가능하다. 후자는 Codex의 영역이다. Subagents는 코드베이스 탐색, 테스트 원인 분석, 문서 확인처럼 병렬화 가능한 작업에 유용할 수 있다. 다만 여러 하위 에이전트의 결론이 다를 수 있으므로 최종 판단은 한 번 더 통합 검토해야 한다. 출처: Subagents – Codex, Codex | AI Coding Partner from OpenAI

시나리오 3: 데이터 분석가의 대량 리포트 요약

상황은 주간 실험 결과 50건을 요약해 리더십 보고서로 만드는 경우다. 모든 원자료를 최고급 모델에 넣는 방식은 비효율적일 수 있다. 먼저 Luna 또는 Terra로 각 실험의 목표, 결과, 통계적 해석, 다음 액션을 표준 형식으로 추출한다. 그런 다음 중요한 실험이나 수치 해석이 민감한 항목만 Sol 또는 사람 검토로 올린다.

이 흐름에서 중요한 것은 샘플링 검수다. 대량 처리 작업은 개별 결과가 그럴듯해 보여도 전체 오류율이 누적될 수 있다. 따라서 무작위 샘플을 뽑아 원자료와 비교하고, 숫자·날짜·실험군 이름처럼 틀리면 치명적인 필드는 별도 규칙으로 검증해야 한다. 모델 선택보다 더 중요한 것은 검수 설계다.

시나리오 4: 콘텐츠 담당자의 공개 원고 제작

상황은 기술 블로그나 보도자료 초안을 만드는 경우다. Luna/Terra는 아이디어 확장, 문장 변형, 구조 초안에 적합하다. 그러나 공개 원고의 최종 단계에서는 사실 검증, 법적 표현, 과장 문구, 출처 표시가 중요하다. 이때 Sol을 사용해 “본문에서 출처가 필요한 주장, 과장 가능성이 있는 표현, 경쟁사 비교의 위험 문장, 독자가 오해할 수 있는 문장을 찾아라”고 요청할 수 있다.

주의점은 AI가 사실 검증을 완결하지 않는다는 점이다. AI가 “확인 필요”라고 표시한 부분은 실제 문서, 공식 발표, 계약 조건, 내부 정책으로 확인해야 한다. 공개 원고에서 모델은 초안 작성자이자 리뷰 보조자이지, 발행 책임자가 아니다.

기업이 정해야 할 운영 기준

조직 차원의 AI 도입에서 가장 흔한 실패는 모델 선택을 개인에게 전부 맡기는 것이다. 개인에게 자유를 주는 것은 중요하지만, 업무 결과물이 조직 이름으로 나가거나 코드베이스를 바꾸거나 고객 데이터에 접근한다면 최소한의 공통 기준이 필요하다. GPT-5.6과 Codex 통합은 이 기준을 더 시급하게 만든다.

첫째, 작업 분류표가 필요하다. 업무를 단순 질의, 초안 작성, 분석, 의사결정 지원, 코드 변경, 외부 도구 실행, 공개 발행으로 나눈다. 각 분류마다 기본 모델, 허용 데이터, 검수자, 로그 보존 여부를 정한다.

둘째, 비용 정책이 필요하다. 모든 작업을 최고 모델로 보내는 조직은 비용을 통제하기 어렵다. 반대로 모든 작업을 저비용 모델로 보내면 중요한 판단에서 품질 문제가 생긴다. 팀별 예산, 작업별 기본 모델, 상위 모델 사용 승인 조건을 정해야 한다.

셋째, 보안과 권한 기준이 필요하다. ChatGPT Work나 Codex가 팀 도구의 컨텍스트를 활용할 수 있는 환경에서는 어떤 데이터가 모델과 도구에 제공되는지 명확해야 한다. 고객 식별 정보, 영업 기밀, 소스코드, 보안 취약점 정보는 접근 권한과 보존 정책을 따로 관리해야 한다. 출처: ChatGPT Work with GPT-5.6, Model Context Protocol – Codex

넷째, 검수 책임을 정해야 한다. AI가 만든 결과물은 “초안”, “분석 보조”, “수정 제안”, “자동 실행 결과”처럼 상태를 구분해야 한다. 특히 Codex가 실제 코드를 고친 경우에는 테스트 결과, 변경 diff, 리뷰 승인, 배포 책임이 분리되어야 한다. AI가 테스트를 통과시켰다는 사실은 좋은 신호지만, 제품 책임자의 승인을 대체하지 않는다.

다섯째, 성과 측정 기준이 필요하다. AI 도입 성과를 “사용량”으로만 보면 왜곡된다. 더 나은 지표는 반복 작업 소요 시간 감소, 리뷰에서 발견된 결함 감소, 문서 초안 작성 시간 단축, 실험 요약 처리량, 장애 대응 초기 분석 시간, PR 리드타임 변화 같은 업무 지표다. 모델 선택 정책도 이 지표를 기준으로 조정해야 한다.

“Sol Ultra”와 정부 승인 같은 표현을 어떻게 다룰 것인가

출시 직후 제품 보도에서는 공식 문서와 커뮤니티·소셜미디어·2차 보도의 표현이 섞이기 쉽다. 특히 “Sol Ultra”, “정부 승인”, “특정 플랜 독점 제공” 같은 표현은 주의해야 한다. 공식 제품 라인업의 기본 구분은 GPT-5.6 Sol, Terra, Luna다. 다만 OpenAI 발표와 벤치마크 표에서는 Sol Pro, ultra effort, Sol Ultra 같은 표현이 특정 플랜·추론 강도·평가 문맥에서 함께 등장한다. Pro는 Pro·Enterprise 사용자가 쓸 수 있는 추론 강도 설정이고, ultra는 여러 에이전트를 병렬로 조율해 복잡한 작업을 처리하는 최고 수준의 effort 설정이며, 벤치마크 표에 등장하는 “Sol Ultra”는 이 ultra 설정을 적용한 Sol의 성능을 가리키는 표현이다. Help Center의 프리뷰 문서는 제한적 프리뷰 당시 API와 Codex를 통한 접근, ChatGPT 미포함, 확대 계획 등을 설명한다. 이후 OpenAI의 GPT-5.6 발표와 ChatGPT Work 페이지는 일반 공개 및 ChatGPT Work 관련 내용을 별도로 제시한다. 출처: A preview of GPT-5.6 Sol, Terra, and Luna, GPT-5.6: Frontier intelligence that scales with your ambition, ChatGPT Work with GPT-5.6

따라서 본문에서는 “Sol Ultra”를 일반 모델 라인업 이름처럼 단정하지 말고, 필요할 경우 고추론 설정 또는 평가 문맥의 표현으로 제한해 설명해야 한다. “정부 승인”도 어느 국가의 어떤 절차를 의미하는지 공식 발표로 확인되지 않는다면 핵심 설명에서 제외하는 편이 낫다. 기업 내부 정책 문서에서 이런 표현을 검증 없이 모델명처럼 쓰면 구매, 보안, 교육 자료가 빠르게 틀어질 수 있다.

AI 활용 역량은 프롬프트 작성에서 작업 설계로 이동한다

한동안 AI 활용 교육의 중심은 프롬프트 작성이었다. 더 구체적으로 지시하라, 역할을 부여하라, 예시를 넣어라, 출력 형식을 지정하라 같은 조언이 유효했다. 이 조언은 여전히 중요하다. 그러나 GPT-5.6과 Codex 통합 이후 더 중요한 역량은 작업 설계다.

작업 설계란 다음을 정하는 능력이다. 이 요청은 답변으로 끝나는가, 파일 변경이 필요한가. 빠른 초안이면 충분한가, 고난도 추론이 필요한가. 외부 도구 접근이 필요한가, 내부 문서만으로 충분한가. 결과물이 공개되는가, 내부 참고용인가. 사람이 반드시 승인해야 하는 지점은 어디인가. 실패했을 때 비용은 어느 정도인가. 이 질문에 답할 수 있어야 올바른 모델과 도구를 고를 수 있다.

프롬프트를 잘 쓰는 사람은 좋은 답변을 얻는다. 작업을 잘 설계하는 사람은 좋은 결과물을 안정적으로 얻는다. 앞으로 조직의 AI 역량 차이는 “누가 더 멋진 프롬프트를 쓰는가”보다 “누가 업무를 잘게 나누고, 적절한 모델과 도구에 배정하고, 검수 흐름을 설계하는가”에서 벌어질 가능성이 크다.

결론: 모델 선택은 업무 운영의 언어가 된다

GPT-5.6과 Codex 통합의 핵심은 더 강한 챗봇의 등장이 아니다. 핵심은 ChatGPT가 업무를 분류하고 실행하고 검수하는 작업 플랫폼으로 이동하고 있다는 점이다. Sol, Terra, Luna는 이 플랫폼 안에서 지능·속도·비용의 선택지를 제공한다. Codex는 대화 결과를 실제 코드 수정과 테스트, 리뷰 흐름으로 연결한다. ChatGPT Work는 팀의 컨텍스트와 결과물 중심 업무를 연결하는 방향을 보여준다.

실무자가 지금 해야 할 일은 최신 모델명을 암기하는 것이 아니다. 자신의 업무를 분류해야 한다. 빠른 답변이 필요한가, 깊은 추론이 필요한가, 대량 처리가 필요한가, 실제 코드 변경이 필요한가, 사람이 승인해야 하는가를 먼저 정해야 한다. 그 다음에 Luna, Terra, Sol, Codex, Subagents, MCP 같은 선택지를 배치해야 한다.

기업도 마찬가지다. “모든 직원에게 최신 모델을 쓰게 하자”는 정책은 충분하지 않다. 어떤 업무에 어떤 모델을 기본값으로 둘지, Codex가 어느 저장소와 도구에 접근할 수 있는지, 어떤 결과물은 반드시 사람이 검수해야 하는지, 비용과 로그를 어떻게 관리할지 정해야 한다. AI 활용의 중심은 프롬프트에서 운영으로, 모델 선택에서 업무 설계로 이동하고 있다.

정확히는 이 선택 기준은 ChatGPT의 일반 대화창만이 아니라 ChatGPT Work, Codex, API까지 포함한 업무 환경 전체에서의 선택 기준이다. 표준 대화에서는 제공 모델과 선택 가능 범위가 플랜별로 다르므로, 실제 사용 전 공식 Help Center의 제공 범위를 확인해야 한다.

참고 출처