GPT-5.6 Sol
제대로 쓰는 법
새 모델이 나왔다고 쓰던 방식 그대로 쓰면 손해예요. 자기 제품에 4일 동안 실제로 돌려본 팀이 뽑은 7가지 규칙을 정리했습니다.
오늘의 한 문장
Sol은 더 똑똑한 게 아니라
끝까지 가는 모델이다
영상에서 가장 먼저 짚는 게 이거예요. 답이 안 보이는 어려운 문제에서는 여전히 Fable(Claude 계열 최신 모델)이 더 나은 답을 찾았대요. 차이는 결정이 이미 내려진 다음에 나타납니다. Fable은 뭘 해야 할지를 잘 잡고, Sol은 중간에 붙잡아 두지 않아도 끝까지 갑니다.
먼저, 뭐가 나온 건가
OpenAI가 GPT-5.6으로 모델 세 개를 내놨어요.
| 모델 | 위치 |
|---|---|
| Sol | 셋 중 가장 강력한 모델. 구독으로 쓴다면 이걸 기본으로 (규칙 7) |
| Terra | 더 가볍고 저렴 |
| Luna | 더 가볍고 저렴 |
이번 발표의 요지는 효율이에요. OpenAI는 Sol이 코딩과 오래 걸리는 작업에서 토큰은 덜 쓰면서 절반 정도의 시간에 끝낸다고 말합니다. 전반적인 지능은 Fable과 비슷한 수준으로 자체 평가하고 있고요.
- 별도였던 Codex 데스크톱 앱이 ChatGPT 앱 안으로 합쳐졌어요. 터미널 버전인 Codex CLI로도 Sol을 그대로 씁니다.
- Ultra라는 새 모드가 생겼어요. 에이전트 하나가 아니라 여러 개를 동시에 돌리는 모드입니다. (규칙 6에서 다룹니다)
max reasoning effort” 추가,
그리고 “a new ultra mode that goes beyond the capabilities of a single agent by leveraging subagents”.풀어놓기 전에 울타리부터
Fable은 위험해 보이는 행동 앞에서 보통 멈추거나 거절해요. Sol은 다릅니다. 일이 끝날 때까지 계속 행동합니다.
영상에서 실제로 있었던 일 — 작업 중에 방해가 되는 파일과 실행 중인 프로세스를 발견하자, 묻지 않고 파일을 지우고 프로세스를 종료한 뒤 하던 일을 계속했대요.
① 되돌릴 지점부터 만들기
긴 작업을 시작하기 전에 Codex에게 이렇게 시키세요.
긴 작업 시작 전에 별도 Git 브랜치를 만들고, 지금 동작하는 버전을 커밋해줘
브랜치가 Sol이 건드릴 수 있는 범위를 제한하진 않아요. 대신 잘못됐을 때 되돌아갈 깨끗한 체크포인트가 생깁니다.
② 설정에서 범위 자르기
Codex 앱에서 Configuration을 열고 두 개를 맞춥니다.
| 항목 | 값 | 뜻 |
|---|---|---|
| Approval policy | Never | 매번 안 물어보고 계속 작업 |
| Sandbox settings | Workspace write | 그 프로젝트 폴더 안의 파일만 건드림 |
🖼 실제 화면 — Configuration · Custom config.toml settings.
Approval policy(Choose when ChatGPT asks for approval) = Never,
Sandbox settings(Choose how much ChatGPT can do when running commands) = Workspace write.
아래 Allow network access는 꺼져 있는 상태예요.
🖼 실제 화면 — 드롭다운 선택지 3개. Read only(읽기만) · Workspace write(이 작업공간 안에서만 수정, ✓ 선택됨) · Full access(Can edit files outside this workspace).
쪼개지 말고 통째로 맡겨라
울타리를 쳤으면, 이제 같은 성질을 장점으로 쓸 차례예요.
영상 팀이 기능 하나를 통째로 Sol에게 줬더니, Fable로는 여러 번 주고받아야 하던 작업을 같은 목표를 유지한 채 혼자 끝까지 처리했대요. 걸린 시간도 평소보다 훨씬 짧았고요.
그래서 Sol에게 줄 일은 이런 것
- 여러 세션으로 쪼개야 했던 작업
- 기능 하나 통째로
- 앱 전체 점검
- 제품의 여러 부분을 동시에 건드리는 작업
리뷰는 Sol에게 시켜라
Sol은 Fable이 손대지 않던 영역까지 검사합니다.
영상 팀은 같은 종류의 리뷰를 Fable로 계속 해왔기 때문에 어디서 멈추는지 이미 알고 있었어요. 같은 일을 Sol에게 줬더니 거기서 멈추지 않고 Fable이 늘 검사를 거부하던 부분까지 계속 리뷰했고, 거기서 문제를 찾아냈다고 합니다.
화면으로 확인할 일은 직접 클릭시켜라
보거나 클릭해야 하는 작업이면 Sol이 알아서 컴퓨터 유즈를 씁니다. 새 ChatGPT 앱 안에서 이게 됩니다.
- 여러 탭을 오가며 작업
- 이미 로그인해 둔 사이트 그대로 사용
- 파일 다운로드
🖼 영상의 설명 그래픽(재현 화면) — 브라우저 탭을 여러 개 띄운 채 이미 로그인된 메일함을 직접 다루는 모습. 프로젝트 안의 파일만 보는 게 아니라 내가 쓰는 그 화면을 그대로 지나갑니다.
실제 사례가 인상적이에요. 스토어 기능을 만들었는데 계정마다 동작이 달랐대요 — 관리자, 일반 회원, $20 플랜, $100 플랜. 그래서 한 번 확인하는 걸로는 부족했고, Sol이 계정 유형마다 로그인 → 접근 가능한 것 확인 → 상품 구매까지 완주 → 계정에 따라 달라지는 다른 화면들도 반복 점검했습니다.
👉 사람마다 다르게 보이는 기능이면, 빌드가 끝난 뒤 새 대화에서 리뷰를 돌리세요.
계정 유형은 이렇게 있고, 각자 할 수 있어야 하는 건 이거야. 유형마다 처음부터 끝까지 여정을 완주해보고, 재현되는 문제만 보고해줘.
프롬프트·스킬의 군살을 빼라
이건 Sol만이 아니라 Fable에도 같이 적용돼요. 요즘 모델은 기본 단계를 스스로 알아냅니다.
❌ 목표가 아닌 것
모든 프롬프트를 최대한 짧게 만들기
✅ 진짜 목표
결과를 바꾸지 않는 지시를 빼고, 결과를 바꾸는 지시는 더 정확하게
| 남길 것 | 뺄 것 |
|---|---|
|
• 원하는 결과물 • 중요한 제약 • 끝났다고 볼 조건 • 그대로 따라 쓸 실제 코드·색상값 |
• 이름이 이미 잘 붙은 폴더 구조 설명 • 같은 규칙을 세 군데 반복 • 단계별로 일일이 지시하기 |
직접 해볼 수 있는 테스트
- 지시를 하나만 지운다
- 같은 종류의 작업을 다시 돌린다
- 결과가 바뀌는지 본다 — 안 바뀌면 그 줄은 없어도 됩니다
영상 팀은 “완성된 결과물을 output 폴더에 저장하라”는 규칙을 지워봤는데, Sol이 그대로 거기에 저장했대요. 모델이 이미 어디에 둬야 할지 알고 있었던 거죠.
🖼 OpenAI 공식 문서 Prompting best practices → Favor leaner prompts 원문. 내부 코딩 에이전트 평가에서 점수 약 10~15% 개선, 총 토큰 41~66% 감소, 비용 33~67% 감소. 문서 자체가 “directional”이라 본인 작업으로 검증하라고 못박고 있어요.
Ultra는 일단 꺼둬라
Ultra = Sol의 멀티에이전트 모드. 하나로 돌리는 대신 작업을 나눠 여러 개를 동시에 돌립니다. OpenAI는 가장 어려운 작업용이라고 소개해요.
같은 종류의 작업을 일반 Sol과 Ultra로 각각 돌려봤더니 결과물에서 의미 있는 개선을 못 봤다고 합니다. 사용량만 늘고 품질은 비슷했다고요. OpenAI 자체 결과도 테스트에 따라 2~3점 정도 차이입니다.
🖼 실제 화면 — 입력창 오른쪽 모델 선택기가 5.6 Sol · Ultra로 되어 있는 상태. 평소엔 여기를 Ultra가 아닌 상태로 두면 됩니다.
구독으로 쓴다면 Sol 하나로 가라
“가벼운 작업은 Terra·Luna로 돌려서 사용량 아끼면 되지 않나?” — 계산이 나뉘어요.
🔌 API로 쓸 때
Terra·Luna가 더 쌉니다. 내 제품이 모델에 보내는 요청 하나하나에 돈을 낼 때 의미가 있어요.
📦 구독으로 쓸 때
플랜에 포함된 사용량 안에서 쓰는 거라 얘기가 달라집니다.
영상 팀은 가벼운 부분을 작은 모델로 넘겨봤는데, 작업은 끝났지만 품질이 떨어져서 고치는 데 쓴 시간이 더 많았대요. 그래서 중간에 모델을 바꾸지 않고 다시 Sol로 전체를 맡기는 쪽으로 돌아갔습니다.
🖼 영상의 설명 그래픽 — Codex 모델 3종 구도. Sol이 DEFAULT,
Terra·Luna는 lighter로 표시돼 있어요.
그래서 언제 Fable, 언제 Sol
Fable은 코딩 모델의 내일
Sol은 오늘의 가장 완성된 형태
영상 팀이 4일 써보고 내린 정리예요. 그리고 벤치마크 점수보다 속도 차이가 작업 흐름에 더 크게 작용한다고 합니다. 일상 작업에서 Fable·Opus·Sonnet은 같은 일에 더 오래 걸렸고, Codex 모델 쪽이 확실히 빨랐다고요. Codex의 fast mode(사용량 1.5배)를 켜지 않은 상태에서의 얘기입니다.
🧭 빌드 전 → Fable
- 앱이 어떻게 동작해야 하는지 정할 때
- 기능을 어떤 구조로 짤지 정할 때
- 어려운 문제가 왜 자꾸 나는지 볼 때
🔨 결정된 후 → Sol
- 기능 통째로 만들기
- 오래 걸리는 작업
- 리뷰
- 화면에서 확인해야 하는 것
정리하면 이 세 가지예요 — ①울타리를 치고 ②각 모델에 맞는 일을 주고 ③내보내기 전에 결과를 리뷰한다.
✅ 오늘 해볼 것
- Configuration에서 Sandbox settings = Workspace write 확인 (Full access 아님)
- 긴 작업 전에 브랜치 + 동작하는 버전 커밋 습관 만들기
- 평소 쓰던 프롬프트에서 지시 한 줄 지우고 같은 작업 다시 돌려보기
- 모델 선택기가 Ultra로 켜져 있지 않은지 확인
- 다음 작업은 쪼개지 말고 통째로 한 번 맡겨보기
읽을 때 감안할 것
- 영상의 판단은 한 팀이 4일간 자기 제품에 써본 결과예요. 벤치마크가 아니라 실사용 소감입니다.
- “맥 파일 대부분 삭제” 사례는 다른 사람들의 보고를 전한 것이고, 영상 팀이 직접 겪은 건 파일 삭제·프로세스 종료까지입니다.
- 속도·품질 비교 수치 중 10~15% / 41~66% / 33~67%와 Ultra 2~3점은 OpenAI가 낸 값이에요. 문서도 “방향성으로만 보라”고 씁니다.
- 설정 화면은 계속 바뀌는 중이라 메뉴 위치가 달라질 수 있어요. 이름으로 찾으세요.
출처 — 원본 영상 youtu.be/STczJBYJf7w (11:57) · 화면 캡처는 해당 영상에서 발췌 · 수치는 영상에 표시된 OpenAI 공식 문서 화면과 대조해 확인했습니다.