GPT-5.6 Sol과 Luna 중 뭘 기본 코딩 모델로 쓸까? 8가지 설정으로 테스트해 봄

*현재 표준 API 요금을 기준으로 입력, 캐시된 입력, 출력 총합을 추산한 값임. 실제 Codex 구독 사용량이나 주간 제한 소모량과는 다름. 텔레메트리에 캐시 쓰기 토큰 정보가 없어서 캐시 쓰기 비용은 제외함.

보고된 출력 총합에는 (단순 사용자 프롬프트뿐만 아니라) 추론 토큰도 포함되어 있어서, 비용 계산할 때 추론 토큰 세부 사항은 따로 더하지 않았음.

입력 수치는 각 Codex 호출에 대해 제공업체가 보고한 총합임.

정성적 검토

GPT-5.6 Sol XHigh를 써서 정확성, 실현 가능성, 최소 구성, 증명 및 복잡도, 구현 품질을 1차로 검토해 봤다.

Spark를 17/20점으로 매기고 나머지는 전부 20/20점 줬음. Spark가 쓴 equal-prefix 체크 방식이 재귀를 쓰는데, 입력 길이가 길어지면 재귀 깊이가 깊어져서 문제에서 제시한 20만 자 제한 조건에서 좀 불안정할 수 있다는 게 주된 지적임.

물론 이 검토 결과나 점수가 절대적인 진리는 아님. 전체 검토 내용이랑 구현물 다 올려놨으니까 직접 보고 판단해 봐.

개인적인 결론

이번 테스트만 놓고 보면 Sol Low가 생성 시간 대비 토큰 효율이 제일 좋았음. 구현도 깔끔하게 통과했고, 비교적 직관적이고 완성도도 높았음.

API 가격 기준으로 보면 Luna XHigh도 이런 제한적인 작업에는 꽤 괜찮아 보임. Sol XHigh랑 거의 비슷한 시간에 끝났는데, 추산된 API 비용은 훨씬 저렴했거든.

그렇다고 이게 무조건 최고의 코딩 모델이라는 건 아님. 이번 작업은 저장소 이해도, 재시도 횟수, 검토 오버헤드, 모호한 요구 사항 처리, 아니면 신뢰할 만한 결과가 나올 때까지 몇 번이나 대화를 주고받아야 하는지 같은 건 측정하지 않았으니까.

한계점

• 설정당 작업 하나, 병렬로 딱 한 번씩만 돌림

• 공개된 문제(2024년 11월 첫 등장)라 학습 데이터에 포함됐을 가능성 있음

• Terra 설정은 테스트 안 함

• 실제 저장소 환경 같은 현실적인 맥락 없음

• LLM 리뷰어가 작성한 정성적 비교

• API 비용 추산은 실제 구독 사용량과 다름

• 캐시 쓰기 토큰 수치 확인 불가

설정들을 병렬로 실행하고 프롬프트, 출력, 로그, 텔레메트리까지 싹 다 보존하려고 내가 직접 만드는 오픈소스 워크플로우 러너인 Crewplane을 사용함.

워크플로우 원본, 프롬프트, 8개 출력물 전체, 텔레메트리, 제공업체 로그, 전체 비교 자료:

https://github.com/crewplaneai/crewplane-lab/tree/master/leetcode-3348-gpt-8-agents

LeetCode 문제 하나가 일상적인 코딩 업무를 완벽하게 대변할 수 없다는 건 나도 잘 알아. 특히 위에서 언급한 한계점들을 생각하면 더더욱 그렇지. 어차피 이게 무슨 결정적인 벤치마크나 모델 순위를 매기려는 의도는 아니었어. 그냥 내가 궁금해서 해본 빠르고 통제된 테스트일 뿐이야. 솔직히 Sol Low랑 Medium이 생각보다 너무 잘 버텨서 놀랐다.

실제 리포지토리에서 둘 다 써본 형들은 어때? 다들 어떤 서브 에이전트를 쓰거나 코딩할 때 기본으로 뭘 써?

Ohmypi를 메인으로 쓰는데 모델이 안 바뀌는 문제가 좀 있었음. 조언자 기능은 좋음. 난 Codex가 싫음. 어제 깨달은 건데 내 LLM 문제의 50%는 나 때문이었음. LLM이 이해할 수 있게 용어나 맥락을 제대로 전달하지 못했던 거임. UI나 시각적인 면에서 Sol이 아직 헤매는 것도 이 때문이고. 점점 나아지는 중.

일반 코딩용으로 GPT 5.5 대신 추천할 만한 거 있어? 결과물은 만족하는데, 작업마다 모델 안 바꾸고 할당량 아낄 수 있는 최적의 모델을 찾고 싶어서.

8번의 실행 모두 정확히 1번의 최상위 턴을 사용했어.