약 3주간의 GPT-5.6-Sol 모델 사용 후기

gpt-5.6-sol 가 출시된지 거의 3주가 다돼가네요.

모델 업데이트가 되면 항상 코딩하는 모델은 주력 모델로 변경해서 사용해보는 편이에요.

그래프에서도 볼 수 있듯이, 7월 9일 출시 직후 기존 gpt-5.5에서 gpt-5.6-sol로 바로 변경했어요.

기존 코딩 모델은 gpt-5.2 부터 gpt-5.5 까지는 항상 high, xhigh 위주로만 사용해왔기 때문에

gpt-5.6-sol 모델도 동일하게 high, xhigh 로 쓰고, max 옵션도 활성화해서 썼어요.

그런데 5.6 은 유독 xhigh 부터 코드가 장황하다는 느낌을 많이 받았어요. 이 이야기는 뒤에서 마저 다루도록 할게요.

프로젝트 규모

먼저, 현재 작업 중인 프로젝트는 Java/Spring 기반의 멀티모듈 프로젝트에요.

라인 수는 cloc 2.10으로 측정했어요. Git에 포함된 파일만 대상으로 했고, 공백과 주석은 제외했어요.

• 전체 프로젝트에는 Java뿐만 아니라 설정, SQL, 스크립트, 문서(.md) 등 cloc이 인식한 파일

• Java 코드만 보면 약 19.7만 줄 정도

• 전체 토큰 수는 Git에서 추적하는 텍스트 파일을 동일한 토크나이저(ticktoken)로 계산한 추정치

• 파일당 평균 토큰 수는 전체 토큰 수를 측정 대상 파일 수로 나눈 값

  • 실제 Codex 작업에서는 필요한 파일만 선택적으로 읽기 때문에 실제 사용 토큰과는 차이가 있어요.

다음으로 reasoning_effrot 를 어떤 작업에 썼는지 간단히 정리해볼게요.

light

기계적인 코드 검색이나 일반 텍스트를 정해진 구조체로 변환하는 작업

light는 Codex 앱에서 직접 사용하지는 않고 API로 사용했는데, 초반에만 잠깐 쓰고 거의 사용하지 않고있어요.

특별한 이유가 있는 건 아니고, light가 적합해 보이는 작업이면 그냥 gpt-5.6-luna나 terra medium을 사용하는 경우가 많았어요.

코드에서 특정 패턴을 찾거나, 여러 텍스트를 JSON 같은 일정한 형식으로 바꾸는 작업은 Sol의 높은 추론이 필요하지 않았어요.

물론 이것도 텍스트의 양에 따라 다를 수 있지만요.

medium

일반적인 기능 추가, 버그 수정, 테스트 작성 같은 대부분 / 주력 코딩 작업

현재 프로젝트에서는 medium을 주력으로 사용하고 있어요.

기능 추가나 버그 수정 대부분은 medium으로 충분해요.

관련 코드를 찾고, 기존 패턴을 파악하고, 구현한 다음 테스트하는 일반적인 흐름은 속도와 결과의 균형이 가장 좋았어요.

작업 범위가 한두 개의 패키지나 컴포넌트 안에서 끝난다면 우선 medium으로 시작해요.

작업 계획 후에 예상보다 분석 범위가 넓다는 게 확인되면 그때 High로 바꾸는 편이에요.

high

모듈 전체의 흐름을 분석한 뒤 코딩하거나 복잡한 E2E 테스트를 작성할 때

high는 단순히 코드가 어려울 때보다, 수정 전에 살펴봐야 할 범위가 넓을 때 사용했어요.

예를 들어 API 모듈의 모든 레이어(Controller, Service, Repository, Domain 등)와 이벤트 처리, 추가적인 인프라 연동까지 함께 확인해야 하는 작업이에요.

다만 살펴볼 범위가 넓더라도 사전에 계획이 충분히 정리돼 있고 실제 작업 복잡도가 높지 않다면 medium으로 처리하기도 해요. 분석과 계획부터 구현까지 한 번에 진행해야 하는 경우(+가끔 귀찮을때)에는 주로 high를 사용했어요.

상태 전이가 여러 단계로 이어지는 복잡한 E2E 테스트 설계도 high를 사용했어요.

테스트 데이터 준비부터 API 호출, 비동기 처리, 최종 상태 검증까지 연결해야 하는 경우에는 medium보다 리팩토링 횟수가 적긴 해요. 근데 가끔 오버엔지니어링 하는 경향이 있어서 medium 을 쓰는 느낌적인 느낌 같은게 올때가 있긴해요.

xhigh

여러 모듈에 걸친 문제를 분석하거나 잠재적인 이슈, 구현 설계 계획을 넓게 확인할 때

체감상 high와 사용하는 영역이 많이 겹치는데, 주로 max 와 함께 계획 문서를 작성할 때 많이 사용해요.

코딩 용도로는 초반에 쓰다가 최근에는 거의 안 쓰고 있어요.

gpt-5.6-sol의 xhigh 부터는 구현 과정에서 세부적인 부분까지 상당히 깊게 파고들고 오버엔지니어링하는 경우가 굉장히 많아요.

단순한 API나 비즈니스 로직을 추가해달라고 요청하는 경우

• 모듈 전체의 구조를 다시 살펴보고, 모듈 수준 또는 시스템 수준의 문제로 범위를 확장해서 구현

• 아직 발생하지 않은 잠재적인 문제까지 방어하기 위해 검증 로직이나 안전장치를 추가

• 여러 계층의 추상화를 만들기 시작

  • 필요 이상의 인터페이스와 추상화가 추가

  • 간단하게 끝낼 수 있는 로직이 여러 단계로 나뉘면서 코드의 흐름을 따라가기 어려워져요

음.. 그래서 예외적인 상황이나 잠재적인 이슈에는 견고(?)하다고 할 수 있는데, 요청보다 구현 범위가 커지면서 계획이 틀어지는 경우가 생겼죠.

(구현된 범위를 리뷰하는 스킬도 만들어서 썼었는데, 지금은 AGENTS.md 문서 그래프에 읽히도록 해놨어요)

지금은 코딩에 계속 사용하기보다는, 구현 계획 문서를 정리하는 용도로 더 자주 사용하고 있어요.

max

프론트엔드, 백엔드, 인프라까지 여러 프로젝트(Repository)를 탐색해서 계획 문서를 작성할 때

max도 실제 코딩보다는 프로젝트 수준의 분석과 계획 문서 작성에 주로 사용했어요. (xhigh 와 동일하게 오버엔지니어링 이슈가 많았거든요.)

하나의 기능을 구현하기 위해 프론트엔드 저장소, 백엔드 API, 배포 설정이나 인프라까지 함께 살펴봐야 하는 경우가 있어요.

이럴 때 각 프로젝트에서 변경해야 할 부분과 작업 순서, 검증 방법을 계획 문서로 정리하도록 했어요.

계획이 충분히 정리된 이후의 실제 구현은 다시 medium이나 high로 진행하는 경우가 많았어요.

Ultra

처음 출시됐을 때 동작 방식과 체감 성능을 확인하기 위해 몇 번 사용

Ultra는 처음 나왔을 때 몇 번 사용한 이후로는 거의 사용하지 않았어요.

제가 하는 작업에는 Ultra 는 성능 향상보다 그냥 토큰 먹는 괴물이었죠.

이전에 정리해놓은 문서도 있어요. GPT-5.6-Sol Ultra 모드는 어떻게 동작할까?

아무튼 이번 Codex cli 0.145.0 버전에 multi_agent_v2 가 stable 버전으로 지정됐는데, 기본은 비활성화라 활성화를 시켜줘야해요.

codex features enable multi_agent_v2

몇가지 더 추가 설정을 해줘야 쓸만할텐데, 이건 아래 릴리즈 노트에 있는걸 Codex에게 보고 설정해달라고 하는게 가장 편해요.

• 서브에이전트별 모델과 추론 수준, 동시 실행 수를 설정할 수 있도록 개선하고, 역할 복원과 에이전트 탐색 기능을 보강해 선택적으로 활성화하는 멀티에이전트 V2의 안정성을 높였습니다. (#33550, #33631, #33657, #33841, #34383)

그래서 한동안은 Ultra를 선택하지 않았는데, 이번에 패치도 됐으니 여러 작업을 동시에 분석하거나 자동 위임하는 subagent가 꼭 필요하면 다시 사용해볼 생각이에요.

정리

현재 사용 방식은

• light: API에서 기계적인 코드 검색이나 텍스트 구조화에 잠깐 사용했지만, 지금은 luna나 terra medium으로 대체

• medium: 대부분의 기능 추가, 버그 수정, 테스트 작성을 처리하는 주력 코딩 설정

• high: 모듈 전체 분석과 구현을 한 번에 진행하거나 복잡한 E2E 테스트를 설계할 때 사용

• xhigh: 여러 모듈의 잠재적인 문제와 구현 방향을 넓게 분석해 계획 문서를 작성할 때 사용

• max: 프론트엔드, 백엔드, 인프라 등 여러 저장소를 함께 탐색해 프로젝트 수준의 계획을 세울 때 사용

• ultra: 평소에는 거의 사용하지 않지만, 여러 작업의 병렬 분석이나 자동 위임이 꼭 필요할 때 사용 고려

약 23만 줄 규모의 현재 Java/Spring 프로젝트에서는 medium만으로도 대부분의 코딩이 가능하고

high 이상은 코드를 더 잘 작성하게 하는 용도라기보다, 더 넓은 범위를 놓치지 않고 살펴보게 하는 용도로 사용하고 있어요. 끗.