Codex를 사용하다 보면 모델 선택만큼이나 고민되는 것이 바로 추론 레벨이다.
Light, Medium, High, Extra High까지는 이름만 봐도 대충 감이 온다.
"높게 설정할수록 오래 생각하는 거겠지."
그런데 어느 순간 등장하는 것이 Ultra다.
Extra High보다 한 단계 더 높은 것이니 그냥 엄청 오래 생각하는 모드라고 이해하기 쉽지만, 현재 OpenAI가 설명하는 Codex Ultra는 그렇게 단순하지 않다.
결론부터 말하면 다음과 같다.
Codex Ultra는 단순히 Extra High보다 조금 더 오래 추론하는 옵션이 아니다. 최대 수준의 추론을 사용하고, 사용 가능한 환경에서는 추가 에이전트까지 동원할 수 있는 고성능 작업 모드에 가깝다.
따라서 모든 작업을 Ultra로 돌리는 것이 반드시 좋은 전략은 아니다.
이번 글에서는 Codex 추론 레벨인 Light, Medium, High, Extra High, Ultra의 차이와 함께 특히 Codex 울트라 모드가 실제로 어떻게 다른지 알아보자.
Codex의 추론 레벨이란?
먼저 "추론 레벨"이라는 표현부터 이해해야 한다.
Codex에 코딩 작업을 요청하면 모델은 바로 코드를 찍어내는 것이 아니라 문제를 분석하고, 관련 파일을 살펴보고, 구현 방법을 결정하고, 필요하면 테스트까지 수행한다.
이 과정에서 모델이 문제 해결에 얼마나 많은 추론 자원을 사용할 것인지 결정하는 것이 reasoning effort, 즉 추론 수준이다.
쉽게 비유하면 이렇다.
Light
→ 문제를 보고 빠르게 판단
Medium
→ 문제를 한 번 더 검토하고 판단
High
→ 여러 가능성을 비교하며 분석
Extra High
→ 상당히 깊게 조사하고 검증
Ultra
→ 최대 수준으로 분석 + 상황에 따라 다른 에이전트까지 투입
하지만 중요한 점이 있다.
추론 수준을 높인다고 해서 모델 자체가 다른 모델로 변하는 것은 아니다.
예를 들어 GPT-5.6 Sol을 선택한 상태라면 기본적으로 같은 GPT-5.6 Sol을 이용하면서 작업에 투입하는 추론량과 실행 방식이 달라지는 것으로 이해하는 것이 좋다.
Codex 추론 레벨 한눈에 비교
현재 Codex에서 사용할 수 있는 추론 옵션은 모델과 계정 등에 따라 다를 수 있지만 OpenAI의 Codex 요금 관련 공식 문서에는 다음과 같은 단계가 명시되어 있다.
| 추론 레벨 | 특징 | 속도 | 자원 사용 | 추천 작업 |
| Light | 빠른 판단 중심 | 매우 빠름 | 적음 | 단순 수정, 파일 탐색 |
| Medium | 속도와 품질의 균형 | 빠름 | 보통 | 일반적인 개발 |
| High | 복잡한 문제를 더 깊게 분석 | 보통 | 증가 | 디버깅, 기능 구현 |
| Extra High | 매우 깊은 단일 작업 분석 | 느림 | 많음 | 복잡한 버그, 설계, 대규모 수정 |
| Ultra | 최대 추론 + 추가 에이전트 활용 가능 | 가장 느릴 수 있음 | 매우 많을 수 있음 | 대규모 복합 작업 |
여기서 특히 주목해야 할 것은 Extra High와 Ultra의 차이다.
Light에서 Extra High까지는 대체로 "한 에이전트가 얼마나 깊게 생각할 것인가"라는 연속적인 개념으로 이해해도 크게 틀리지 않는다.
하지만 Ultra부터는 이야기가 조금 달라진다.
Light: 간단한 작업은 굳이 오래 고민할 필요가 없다
Light는 빠른 응답과 적은 자원 소비가 중요한 작업에 적합하다.
예를 들어 이런 작업이다.
이 변수 이름 userNm을 userName으로 변경해줘.
또는
이 DTO에 email 필드를 추가해줘.
이런 일을 수행하면서 프로젝트 전체 아키텍처를 탐험하고 데이터 흐름까지 분석할 필요는 없다.
사람으로 치면 책상 위의 연필을 옆으로 10cm 옮겨달라고 했는데 방 구조부터 분석할 필요가 없는 것과 같다.
Light는 다음과 같은 작업에 적합하다.
- 단순 코드 수정
- 이름 변경
- 주석 추가
- 작은 스타일 변경
- 명확한 컴파일 오류 수정
- 파일 위치 탐색
- 간단한 질문
다만 프로젝트 구조를 이해해야 하는 작업에서는 분석이 부족할 가능성이 있다.
Medium: 대부분의 일상적인 개발 작업에 적합
Medium은 Codex를 일반적으로 사용할 때 가장 무난한 선택이다.
속도와 추론 성능 사이의 균형점이라고 생각하면 된다.
예를 들어 다음과 같은 요청이다.
회원 조회 API에 이메일 검색 조건을 추가하고
Repository부터 Controller까지 필요한 코드를 수정해줘.
테스트도 확인해줘.
단순히 코드 몇 줄을 수정하는 수준은 아니지만 그렇다고 프로젝트 전체 구조를 재설계할 정도의 문제도 아니다.
Medium은 일반적으로 다음 작업에 적합하다.
- CRUD 기능 추가
- 기존 API 수정
- 테스트 작성
- 간단한 리팩터링
- 일반적인 프론트엔드 수정
- 비교적 원인이 명확한 버그 수정
무슨 레벨을 사용할지 모르겠다면 Medium에서 시작하는 것도 좋은 방법이다.
High: 여러 파일과 로직을 함께 살펴봐야 할 때
High부터는 조금 더 복잡한 개발 작업에 어울린다.
예를 들어 이런 문제다.
결제 완료 후 간헐적으로 주문 상태가 변경되지 않는 문제가 있다.
관련 코드를 전부 조사하고 원인을 찾아 수정해줘.
이제 단순 코드 생성이 아니라 조사 과정이 필요하다.
Codex는 다음과 같은 내용을 살펴봐야 할 수 있다.
- Controller
- Service
- Repository
- 트랜잭션 범위
- 비동기 처리
- 이벤트 발행
- 외부 API 호출
- 테스트 코드
High에서는 이러한 여러 가능성을 비교하고 잘못된 가설을 버리는 데 더 많은 추론 자원을 사용할 수 있다.
따라서 일반적인 개발에서는 Medium과 High를 가장 자주 사용하게 될 가능성이 높다.
Extra High: 어려운 문제를 제대로 파고들고 싶을 때
Extra High는 상당히 복잡한 문제를 해결할 때 사용하는 단계다.
예를 들어 프로젝트에서 몇 달 동안 묵혀 있던 괴상한 버그를 Codex에게 맡긴다고 생각해보자.
특정 상황에서만 데이터 중복 저장이 발생한다.
전체 호출 흐름과 트랜잭션 구조를 확인하고
가능한 원인을 조사한 뒤
재현 테스트를 만들고
원인을 수정해줘.
이 경우 Codex가 성급하게 첫 번째 가설을 정답이라고 생각하면 곤란하다.
Extra High는 이런 작업에서 여러 가설을 확인하고 관련 코드를 더 폭넓게 살펴보는 데 유리하다.
대표적인 사용 사례는 다음과 같다.
- 복잡한 장애 원인 분석
- 대규모 리팩터링 계획
- 레거시 코드 분석
- 어려운 성능 문제 조사
- 복잡한 데이터베이스 문제
- 시스템 아키텍처 변경
- 어려운 코드 리뷰
- 여러 모듈이 얽힌 기능 개발
그렇다면 이런 생각이 들 수 있다.
"Extra High가 이렇게 좋은데 그냥 항상 Extra High 쓰면 되는 것 아닌가?"
그렇지는 않다.
OpenAI 역시 높은 reasoning effort가 항상 더 좋은 결과를 만든다고 설명하지 않는다.
작업 자체가 단순하거나 종료 조건이 불명확한 경우 오히려 필요 이상으로 조사하거나 지나치게 복잡한 해결책을 만들 수도 있다.
즉 생각을 많이 한다고 모든 문제가 좋아지는 것은 아니다.
라면 끓이는데 식품공학 논문부터 읽을 필요는 없다.
Codex Ultra란 무엇인가?
이제 핵심인 Codex Ultra 모드를 살펴보자.
OpenAI의 현재 공식 설명에서 Ultra에는 두 가지 중요한 특징이 있다.
1. 최대 수준의 추론을 사용한다
GPT-5.6 Sol의 API에는 다음 reasoning effort가 존재한다.
none
low
medium
high
xhigh
max
여기서 max는 말 그대로 가장 어려운 품질 우선 작업을 위해 마련된 최대 reasoning effort다.
OpenAI는 max를 가장 어려운 quality-first 작업에 사용하고, 일반적인 경우에는 xhigh와 비교해서 실제 품질 향상이 있는지 확인할 것을 권장한다.
Codex Ultra 역시 공식적으로 "maximum reasoning"을 사용하는 옵션으로 설명된다.
따라서 Extra High보다 더 많은 추론 자원을 사용할 수 있다.
그런데 여기까지였다면 그냥 "Extra Extra High"라고 불러도 됐을 것이다.
Ultra가 특별한 이유는 다음 특징 때문이다.
2. Ultra는 추가 에이전트를 실행할 수 있다
현재 OpenAI 공식 Codex 요금 설명에는 Ultra에 대해 꽤 중요한 문장이 포함되어 있다.
Ultra는 최대 추론을 사용하며, 적격 사용자에게는 추가 에이전트를 실행할 수 있다.
즉 하나의 Codex가 모든 일을 순서대로 처리하는 대신 작업을 여러 개로 나누어 처리할 수 있다는 의미다.
예를 들어 다음 작업을 생각해보자.
이 Spring Boot 프로젝트를 전체 분석해서
1. 보안 취약점 조사
2. N+1 문제 조사
3. 사용하지 않는 코드 조사
4. 테스트 부족 영역 조사
5. API 구조 문제 조사
를 진행하고 수정 계획을 작성해줘.
일반적인 에이전트 하나가 처리한다면 대략 다음과 같이 진행할 수 있다.
메인 에이전트
↓
보안 조사
↓
DB 조사
↓
코드 조사
↓
테스트 조사
↓
결과 통합
Ultra에서 추가 에이전트가 활용되는 환경이라면 개념적으로 다음과 같은 구조가 가능하다.
메인 에이전트
│
┌─────────────┼─────────────┐
↓ ↓ ↓
보안 조사 DB 조사 테스트 조사
│ │ │
└─────────────┼─────────────┘
↓
결과 통합
OpenAI는 GPT-5.6 API의 Multi-agent 기능을 설명하면서 Codex Ultra와 유사한 방식이라고 명시하고 있다.
따라서 Ultra의 핵심은 단순히 "더 오래 생각한다"에서 끝나는 것이 아니다.
복잡한 문제를 여러 작업으로 분해하고 병렬적으로 탐색하는 오케스트레이션에 가까운 성격까지 가지고 있다.
다만 Ultra를 선택했다고 항상 여러 에이전트가 무조건 생성된다고 이해해서도 안 된다.
공식 표현은 "may run additional agents", 즉 대상 사용자 및 상황에 따라 추가 에이전트를 실행할 수 있다는 것이다.
Ultra가 특히 강력한 작업
Ultra가 제대로 빛나는 것은 작업을 여러 독립적인 영역으로 분리할 수 있을 때다.
예를 들어 대규모 프로젝트 마이그레이션이 있다.
Java 11 + Spring Boot 2 프로젝트를 분석하고
Java 21 + 최신 Spring Boot로 이전하기 위한 작업을 진행해줘.
Deprecated API,
라이브러리 호환성,
Gradle 설정,
테스트,
Spring Security,
JPA 관련 변경 사항까지 모두 확인해줘.
이 문제는 여러 조사 작업을 동시에 수행할 수 있다.
또 다른 예로 프로젝트 전체 품질 점검이 있다.
이 저장소 전체를 분석해서
- 잠재적 버그
- 성능 문제
- 보안 문제
- 구조적 문제
- 테스트 부족
- 중복 코드
를 조사하고 중요도 순으로 개선해줘.
이런 요청은 Ultra와 상당히 잘 맞는다.
반대로 다음 요청에 Ultra를 쓰는 것은 과하다.
버튼 색상을 파란색으로 바꿔줘.
이 일에 에이전트 군단이 출동하면 버튼 하나 바꾸려고 개발팀 전체 회의를 소집하는 것과 비슷하다.
Ultra의 가장 큰 단점: 사용량
Ultra에서 반드시 고려해야 할 것이 토큰과 Codex 사용량이다.
중요한 사실 하나부터 짚고 넘어가자.
Ultra라고 해서 "토큰 하나당 가격" 자체가 별도의 Ultra 가격으로 바뀌는 것은 아니다.
현재 Codex는 기본적으로 사용 모델과 실제 사용한 입력 토큰, 캐시 입력 토큰, 출력 토큰 등을 기준으로 사용량을 계산한다.
하지만 Ultra에서는
최대 reasoning 사용
+
추가 에이전트 실행 가능
+
각 에이전트의 입력/출력
+
최종 결과 통합
이 발생할 수 있다.
따라서 결과적으로 총 토큰 소비량은 상당히 커질 수 있다.
예를 들어 4개의 에이전트가 각각 프로젝트를 분석한다면 네 에이전트 모두 프로젝트 컨텍스트와 작업 결과를 처리해야 할 수 있다.
그래서 Ultra는 사용 한도를 아끼면서 하루 종일 사용하는 기본 모드보다는 정말 어려운 작업에 꺼내 드는 카드에 가깝다.
그리고 "Ultra는 정확히 Extra High의 몇 배를 사용한다" 같은 고정된 공식 배율은 없다.
작업 분해 여부, 실행된 에이전트 수, 저장소 크기, 생성 코드, 테스트 실행, 컨텍스트 크기에 따라 사용량이 크게 달라질 수 있기 때문이다.
Extra High와 Ultra 중 무엇을 써야 할까?
실전에서는 이 기준이 꽤 유용하다.
문제가 하나인데 어렵다면 Extra High
예를 들어 특정 Deadlock의 원인을 찾는 것처럼 하나의 복잡한 문제를 깊게 파고드는 작업이라면 Extra High가 좋은 선택이다.
하나의 문제
+
깊은 분석 필요
=
Extra High
문제가 크고 여러 작업으로 나눌 수 있다면 Ultra
반대로 저장소 전체를 조사하거나 마이그레이션처럼 여러 영역을 동시에 검토해야 한다면 Ultra가 유리해질 수 있다.
큰 문제
+
여러 독립 작업으로 분리 가능
+
최종 결과 통합 필요
=
Ultra
이 차이를 이해하면 Ultra를 훨씬 효율적으로 사용할 수 있다.
Codex 추론 레벨 추천 기준
개인적으로 가장 이해하기 쉬운 기준은 다음과 같다.
Light
"시키는 대로 빠르게 해."
Medium
"평범하게 잘 생각해서 해."
High
"실수하면 곤란하니까 제대로 분석해."
Extra High
"시간이 조금 걸려도 좋으니 원인을 깊게 파고들어."
Ultra
"이건 일이 크다. 최대한 깊게 분석하고 필요하면 팀까지 꾸려서 해결해."
실제 개발에서는 다음처럼 운용하면 효율적이다.
| 작업 | 추천 |
| 변수명 변경 | Light |
| 간단한 API 추가 | Medium |
| 여러 파일을 건드리는 기능 | Medium~High |
| 원인이 애매한 버그 | High |
| 복잡한 장애 분석 | Extra High |
| 대규모 리팩터링 | Extra High~Ultra |
| 프로젝트 전체 감사 | Ultra |
| 프레임워크 대규모 마이그레이션 | Ultra |
| 여러 독립 작업을 한 번에 조사 | Ultra |
추론 레벨을 높이면 무조건 코드 품질도 높아질까?
그렇다고 단정할 수 없다.
OpenAI의 GPT-5 계열 모델 가이드에서도 높은 reasoning effort가 자동으로 더 좋은 결과를 의미하지 않는다고 안내하고 있다.
특히 다음과 같은 상황에서는 오히려 과도하게 생각할 수 있다.
- 요구사항이 모호한 경우
- 작업 종료 조건이 불명확한 경우
- 사용할 수 있는 도구가 지나치게 많은 경우
- 단순한 문제인 경우
예를 들어 "코드를 좀 더 좋게 만들어줘"라는 애매한 요청을 Ultra에 던지면 Codex 입장에서는 대체 어디까지 고쳐야 하는지 알 수 없다.
반대로 다음처럼 성공 조건을 명확히 주는 것이 훨씬 좋다.
UserService의 회원 조회 로직을 리팩터링해줘.
조건:
- 외부 API 인터페이스 변경 금지
- DB 스키마 변경 금지
- 기존 테스트 모두 통과
- N+1 발생 여부 확인
- 새 테스트 추가
- 변경 이유를 마지막에 정리
Ultra라고 해서 프롬프트를 대충 적어도 되는 것은 아니다.
오히려 강력한 에이전트일수록 작업 범위와 성공 조건을 명확하게 지정하는 것이 중요하다.
Codex Ultra와 GPT-5.6 Pro는 같은 것일까?
이것도 혼동하기 쉬운데 같은 개념으로 보면 안 된다.
GPT-5.6 API에는 reasoning effort와 별도로 Pro mode라는 실행 방식이 존재한다.
즉 개념적으로 보면
모델
+
Reasoning Effort
+
실행 방식
은 서로 구분할 필요가 있다.
Codex의 Ultra는 Codex 제품에서 제공되는 추론 및 에이전트 실행 옵션이고, GPT-5.6의 Pro mode는 API에서 더 많은 모델 작업을 수행해 최종 답변의 신뢰도를 높이기 위한 별도의 실행 모드다.
마찬가지로 ChatGPT 모델 선택기에 표시되는 Pro와 Codex Ultra 역시 같은 기능이라고 생각하면 안 된다.
이름이 비슷해서 상당히 헷갈리지만 각각 다른 제품 계층의 옵션이다.
결국 어떤 추론 레벨을 기본으로 사용하면 좋을까?
모든 작업을 Ultra로 설정하는 방식보다는 작업 난이도에 따라 단계적으로 올리는 방식이 가장 합리적이다.
예를 들어 다음과 같다.
일반적인 개발
↓
Medium
조금 복잡하다
↓
High
문제가 어렵다
↓
Extra High
프로젝트 전체를 뒤집어봐야 한다
↓
Ultra
특히 바이브 코딩처럼 Codex에게 기능 개발을 상당 부분 맡기는 경우에도 처음부터 무조건 Ultra를 사용할 필요는 없다.
일반적인 기능 개발은 Medium이나 High로도 충분할 수 있다.
대신 다음과 같은 순간에 Ultra를 활용하면 된다.
- 프로젝트 전체 분석
- 대규모 마이그레이션
- 여러 원인이 얽힌 장애
- 대규모 리팩터링
- 광범위한 코드 품질 검사
- 보안·성능·테스트를 동시에 조사
- 여러 독립적인 조사 작업을 병렬화할 수 있는 경우
한마디로 정리하면 이렇다.
Extra High가 "아주 깊게 생각하는 뛰어난 개발자 한 명"이라면, Ultra는 "최대한 깊게 생각하면서 필요하면 다른 개발자들에게 조사 업무까지 나눠주는 리드 개발자"에 조금 더 가깝다.
그래서 Ultra가 항상 정답인 것은 아니다.
하지만 제대로 맞는 작업에 사용하면 단순한 추론 레벨 하나를 올리는 것 이상의 차이를 만들 수 있다.
참고 자료
- OpenAI Help Center, Codex Rate Card — Ultra는 별도 모델이 아니며 최대 수준의 추론을 사용하고, 대상 사용자에게 추가 에이전트를 실행할 수 있다고 설명한다.
OpenAI Codex Rate Card - OpenAI API, GPT-5.6 Model Guidance — GPT-5.6의 reasoning.effort가 none, low, medium, high, xhigh, max를 지원하며 max를 가장 어려운 품질 우선 작업에 사용하도록 안내한다. 또한 Multi-agent 기능을 Codex Ultra와 유사한 방식으로 설명한다.
OpenAI GPT-5.6 Model Guidance - OpenAI API, GPT-5.6 Sol Model — GPT-5.6 Sol이 none부터 max까지의 reasoning effort를 지원한다는 모델 사양.
GPT-5.6 Sol Model - OpenAI Help Center, ChatGPT Rate Card — Codex에서 제공되는 reasoning level로 Light, Medium, High, Extra High, Ultra를 명시하고 있으며 실제 비용은 모델과 사용 토큰량을 기준으로 계산된다고 설명한다.
OpenAI ChatGPT Rate Card
'IT > AI' 카테고리의 다른 글
| GPT-6 Astra vs GPT-5.6 Sol 비교: 2.5배 비싼데 오히려 토큰을 아낀다? 성능,비용,실사용 후기 총정리 (2) | 2026.09.07 |
|---|---|
| GPT-6 Astra vs Claude Fable 5.1 비교(코딩,성능,가격 등) (4) | 2026.09.05 |
| 클로드코드 주간 한도 50% 상향 이벤트 또 연장됐다(2026년 8월 31일까지) (5) | 2026.08.25 |
| 클로드 오푸스 5(Claude Opus 5) 출시 총정리: 페이블 5,GPT-5.6과 비교 및 실제 개발자 반응 (6) | 2026.07.27 |
| 챗GPT 6 출시 루머 총정리: GPT-5.7과 GPT-6, 정말 8월에 나올까? (1) | 2026.07.27 |