GPT-5.6이 나왔다. GPT-5.6 Sol·Terra·Luna, 어떤 작업에 써야 할까

GPT-5.6이 나왔다. 벤치마크 성능표보다 중요한 건 따로 있다

새 모델이 얼마나 똑똑한지보다, 실제 작업에서 몇 번이나 다시 설명해야 하는지가 더 궁금하다.

GPT-5.6가 정식으로 공개됐다. 플래그십 모델인 Sol, 성능과 비용을 절충한 Terra, 저렴하게 쓸 수 있는 Luna까지 세 종류다. 코딩과 과학, 보안 분야의 점수도 올랐고, 여러 에이전트를 동시에 움직이는 ultra 모드도 추가됐다.

발표 자료만 보면 확인할 것이 많다. 그런데 AI 코딩 도구를 실제 업무에 붙여 쓰는 입장에서 궁금한 건 조금 다르다. 요구사항을 한 번에 얼마나 잘 알아듣는지, 수정하다가 멀쩡한 코드를 건드리지는 않는지, 끝났다고 했을 때 테스트까지 제대로 통과했는지. 이런 부분이 좋아졌다면 점수 몇 점이 오른 것보다 훨씬 반갑다.

이번 발표에서 눈에 들어온 건 토큰 효율이었다

GPT-5.6의 메시지는 같은 수준의 결과를 더 적은 토큰으로 만들고, 작업에 따라 모델을 나눠 비용을 낮추겠다는 쪽에 가깝다.

• Sol은 설계나 복잡한 디버깅처럼 판단이 많이 필요한 작업에 어울린다.
• Terra는 일반적인 기능 개발이나 문서 작업처럼 자주 하는 일에 맞춰져 있다.
• Luna는 분류, 형식 변환, 전처리처럼 결과를 바로 확인하기 쉬운 작업에 부담이 적다.

API 가격은 100만 토큰 기준으로 Sol이 입력 5달러, 출력 30달러다. Terra는 2.5달러와 15달러, Luna는 1달러와 6달러다.

가격만 보면 Luna부터 쓰는 게 당연해 보인다. 하지만 모델이 놓친 내용을 사람이 계속 고쳐야 한다면 계산이 달라진다. 토큰 비용은 줄어도 작업 시간은 늘 수 있다. 반대로 중요한 작업에 Sol을 쓰고 수정 횟수를 줄일 수 있다면 비싼 모델이 오히려 나은 선택일 수 있다.

개발자가 체감하는 성능은 다른 곳에서 드러난다

온라인 반응 중에 재미있는 표현이 하나 있었다. 모델 성능을 “Codex에게 욕한 횟수”로 평가했다는 이야기다. GPT-5.5를 쓸 때보다 GPT-5.6 Sol을 쓸 때 그 횟수가 줄었다고 했다.

농담이지만 무슨 뜻인지는 바로 이해된다. AI 코딩을 하다 보면 틀린 답보다 애매하게 맞는 답이 더 피곤할 때가 있다. 요구사항 다섯 개 중 네 개만 처리하거나, 한 곳을 고치면서 다른 곳을 깨뜨리거나, 테스트하지 않은 코드를 완성됐다고 내놓는 경우다.

모델이 좋아졌는지는 결국 다시 설명한 횟수, 되돌린 코드, 직접 고친 시간에서 드러난다.

벤치마크가 필요 없다는 이야기는 아니다. 어떤 작업에서 강한지 빠르게 파악하려면 점수가 필요하다. 다만 내 코드베이스에서 잘하는지는 직접 확인해야 한다. 프로젝트 구조와 사용 언어, 프롬프트 작성 방식이 사람마다 다르기 때문이다.

프롬프트를 짧게 쓰라는 말은 조금 조심해서 들어야 한다

GPT-5.6은 사용자의 의도와 기대 수준을 이전보다 잘 파악한다고 한다. 긴 시스템 프롬프트를 줄였더니 내부 평가 점수는 1015% 좋아지고, 전체 토큰은 4166%, 비용은 33~67% 줄었다는 내용도 공개됐다.

그렇다고 모든 설명을 지우면 안 된다. 프롬프트가 짧아져도 수정 범위, 성공 조건, 승인 없이 하면 안 되는 일은 남겨야 한다. 모델이 알아서 채워도 되는 설명과 사람이 직접 정해야 하는 기준은 다르다.

예를 들어 “짧게 답해줘”라고 쓰는 것보다 “수정한 파일, 변경 이유, 테스트 결과만 알려줘”라고 쓰는 편이 낫다. 답변 길이만 줄이는 게 아니라 무엇을 받아야 하는지 정해 주기 때문이다.

Codex와 Claude Code, 하나만 고를 필요는 없다

새 모델이 나올 때마다 Codex와 Claude Code 중 무엇이 더 좋은지 묻게 된다. 여기에 하나의 정답은 없다. 모델의 코딩 실력만 비교해서 끝나는 문제가 아니기 때문이다.

도구가 안정적으로 동작하는지, 사용량을 얼마나 주는지, 원격으로 작업을 확인할 수 있는지, 긴 세션에서 앞의 맥락을 얼마나 잘 이어가는지도 중요하다. 같은 모델을 써도 프로젝트에 따라 체감이 달라진다.

예산이 허용한다면 둘을 경쟁시키는 방법도 괜찮다. 같은 요구사항으로 설계를 각각 받아 보거나, 한쪽이 작성한 코드를 다른 쪽에 검토하게 하면 각 모델의 장단점이 빨리 드러난다.

새 모델은 같은 작업으로 비교해 보면 된다

GPT-5.6를 써 볼 생각이라면 평소 자주 하는 작업 하나를 정해 두는 게 좋다. 새 기능 하나, 실제 버그 하나, 오래된 코드의 작은 리팩터링 정도면 충분하다.

1. 첫 결과에서 요구사항을 몇 개나 놓쳤는지
2. 수정 지시 뒤에 기존 동작을 깨뜨렸는지
3. 테스트를 직접 실행하고 결과를 확인했는지
4. 사람이 다시 설명하고 고치는 데 몇 분이 들었는지
5. 한 작업을 끝내는 데 실제로 얼마를 썼는지

며칠만 기록해도 Sol을 써야 할 작업과 Terra로 충분한 작업, Luna에 맡겨도 되는 작업이 나뉜다. 모델 이름보다 내 작업에서 나온 기록이 훨씬 믿을 만하다.

GPT-5.6에서 기대하는 건 화려한 답이 아니다

AI 코딩 도구에 바라는 것은 점점 단순해지고 있다. 말을 길게 잘하는 것보다 앞에서 정한 조건을 잊지 않았으면 한다. 수정한 뒤에는 테스트를 돌리고, 문제가 생기면 원인을 찾아 끝까지 고쳤으면 한다.

GPT-5.6가 이런 기본적인 답답함을 줄여 준다면 충분히 좋은 업그레이드다. 성능표는 그다음에 봐도 늦지 않다.

태그: GPT-5.6, Codex, Claude Code, AI 코딩, OpenAI, LLM, 프롬프트, 개발 생산성, AI 에이전트

참고 자료
https://news.hada.io/topic?id=31275
https://openai.com/index/gpt-5-6/