연초까지 자주 나오고 계속 언급되던 회사들의 AI 모델 경쟁이 조금 둔화된 느낌입니다.
피로감을 말하는 유저들도 많고, 사실 어떤 모델을 쓰더라도 어느 정도 저점이 보장된 느낌도 크고요. 물론 제미나이는 갈 길이 멀어 보입니다. 대체 Gemini Pro 3.5(또는 4.0)는 언제 나오는 거죠,,, 4.0 아르곤 전격발표 두근두근
한 6월쯤부터 둔해졌던 모델 경쟁이 GPT 5.6 Sol부터 다시 대두되는 것 같은데, 그것까지도 사실 그렇게 와닿지는 않더라고요. 제 주변 사용자들이 하나같이 5.6 Sol은 토큰이 말 그대로 녹아내린다고 했습니다. 토큰이 그렇게 녹아내리면 그냥 고비용이니까 고성능이네, 싶은 거라 크게 와닿지 않았습니다.
제 체감상 Claude Opus 5.5부터는 다시 Claude가 1황이 아닌가 싶습니다. 고성능인데 가성비까지 챙기는 느낌이거든요. Opus 5.5가 Opus 5.0에 비해 간만에 장점만 존재하는 버전업이라는 생각이 들 정도로 쾌적합니다.
일단 저는 Pro 이용자라서 최근 Fable을 사용한 적이 없습니다. 잠깐 무료로 풀렸을 때 Fable은 정말 신나고 즐겁게 사용했었는데, 이후에는 Opus 5.0과 Sonnet 5.0을 병행하면서 썼습니다.
근데 Opus 5.5 이후 2주 동안은 대부분의 작업을 Opus 5.5로만 하고 있습니다. 말 그대로 추론 속도와 사용량 소모가 눈에 보일 정도로 적습니다. 퀄리티는 Opus 5.0에 비해서 와닿게 다른 점은 모르겠고 사실 그 정도의 일을 요구하지도 않습니다만, 속도와 토큰 소모는 눈에 띄게 개선되었습니다.
Sonnet 5.5가 마음에 와닿지 않았던 것도 이 이유에서였습니다. 보통 엔트리 모델의 신규 버전은 플래그십 모델의 이전 버전과 비교가 되곤 하는데, 그러다 보니 Opus 5.0과 비교하게 되고 그러면 “굳이?” 싶은 거죠. 제 체감상 완전한 상위호환인 Opus 5.5가 있는데도.. 굳이? 하는 생각이었습니다.
그러다 이번에 Sonnet 5.5를 제대로 써볼 기회가 생겼습니다. 마침 운영 중인 서비스에서 어느 날 오전부터 트래픽이 갑자기 몰리는 일이 있어서, 로그를 조사시키는 작업으로 Opus 5.5와 Sonnet 5.5를 비교해봤습니다. 원인을 모르는 상태라 누가 더 정답에 가까운지보다는 조사하는 과정을 보는 쪽이었습니다.
프롬프트는 똑같이 했고, 둘 다 1차 답변에 이어서 쓴 세션이라 환경도 같았습니다. 물론 딱 1회입니다.
결과는 나쁘지 않았습니다. Opus는 7일 동안 한 번도 없던 경로를 찾아냈는데 Sonnet은 거기까지 가지 못했습니다. 이건 확실히 Opus 쪽이 더 쓸모 있었네요. 다만 횟수를 늘리다 보면 Sonnet도 이런 경로를 확인할 수 있지 않을까 싶긴 합니다.
속도와 사용량은 놀라웠습니다. Opus는 29분에 5시간 사용량의 17%를, Sonnet은 22분에 14% 정도를 썼습니다. 정수 % 단위라 오차는 있겠지만, 같은 작업에서 시간도 사용량도 줄었습니다. Opus 5.5가 이미 엄청나게 절약된다고 생각했는데 그보다도 효율이 좋았습니다. 엔트리 모델이니 당연한 결과일 수도 있겠지만요.
작업 도중에 현상을 설명해달라는 요청은 오히려 Sonnet이 더 철저하게 수행하더라고요. Opus는 조사가 다 끝난 뒤에 한 번에 정리해줬는데, Sonnet은 단계마다 지금 무엇을 확인했고 어떤 값이 나왔는지 중간중간 알려줬습니다.
신뢰도나 완성도를 검증하기엔 한참 부족한 테스트입니다. 막연히 Opus가 더 높지 않을까 하는 마음도 여전히 있고요.
하지만 Sonnet 5.0을 쓰면서 큰 문제를 못 느꼈던 입장에서는, Sonnet 5.5도 당연히 쓸 것 같습니다. 그러니 앞서 말한 “굳이?”라는 생각은 바뀌었습니다.
그러고 보니 이 테스트를 도운 모델도 Sonnet 5.5였습니다. 프롬프트를 만들고 결과를 같이 보는 일을 맡겼는데, 대화나 작업 계획을 어떻게 짜는지 보고 싶었고 Opus 5.5는 10일이라도 더 써봤으니 Sonnet 5.5를 실사용으로 체감해보려는 의도였습니다.
그런데 결과를 채점하던 중에 “저도 Sonnet이라 평가가 기울 수 있습니다”라는 말이 먼저 나왔습니다. 자기 선호 편향이라는 게 있고, 실제로 기울었는지는 스스로 확인할 수 없다는 설명까지 덧붙여서 솔직하게 말해주더라고요. 흥미로웠습니다.
인터넷 후기를 보면 “계획은 Opus에게, 작업은 Sonnet에게”라는 말이 많은데 어떤 느낌인지는 알 것 같습니다.
Sonnet의 작업은 약간 공평함에 치중되어 있는데, 이게 실제 작업에 유리한 느낌은 아니었거든요. 이론으로만 작업을 배운 실무 경험 없는 엘리트 코스의 우당탕탕 첫 현장실습 느낌이랄까요.
10월 7일 추가
오늘(10월 7일) 공식 가이드 두 편을 읽고 알게 된 것을 이어서 적습니다.
Opus 가이드의 첫 번째 권장은 긴 작업을 한 번에 맡기라는 것입니다. 메시지 하나에 전체 작업과 완료 기준을 적고, 언제 멈추고 물어봐야 하는지까지 알려준 뒤 맡겨두라고 합니다.
Sonnet 가이드는 반대로 명확한 스펙과 결과를 확인할 수단이 있는 작업에 Sonnet이 잘 맞고, 판단이 필요한 복잡한 작업은 Opus를 고르라고 합니다.
Sonnet이 작성한 지시 프롬프트라서 그런지 Sonnet에게 더 맞는 프롬프트였습니다. 계획을 할 때 계획 에이전트에게 작업을 할 모델을 명시해주는 것도 방법이 될 수 있겠다 싶었습니다.
같은 현상을 조사시킨다고 하면 Sonnet에게는 이런 느낌으로 맡기게 됩니다. 순서와 조회 축, 보고 방식을 사람이 정해주는 쪽입니다. 현상과 평시 구간, 조회만 하라는 공통 정보는 두 프롬프트 앞에 똑같이 넣는다고 보시면 됩니다.
같은 현상을 아래 순서대로 조사해 주세요. 한 단계가 끝나면 다음 단계로 넘어가세요.
1단계 기준선: [평시 구간]의 30분 단위 건수를 툴팁 값으로 읽어 표로 만드세요.
2단계 시작 시각: 증가가 시작된 시각 전후를 1분 단위로 조회해 분당 건수 표를 만드세요.
3단계 분해: 증가 전과 증가 후를 호스트, 경로, 상태코드, 클라이언트 IP, User-Agent 다섯 축으로 각각 Top 10 비교 표를 만드세요.
4단계 샘플: 증가가 큰 패턴 2개의 로그 상세를 각각 3건씩 열어 요청 형태를 그대로 적으세요.
진행 방식
- 각 단계 시작 전에 무엇을 조회할지 한 줄, 끝난 뒤 확인한 수치를 한두 줄로 알려 주세요.
- 수치는 툴팁·표 값만 쓰고, 읽지 못한 값은 "미확인"으로 적으세요.
- 못 한 단계는 마지막에 표로 정리해 주세요.Opus에게는 이런 느낌입니다. 방법은 맡기고 목표와 완료 기준, 멈출 조건만 줍니다.
목표: 이 증가의 원인을 "근거가 붙은 설명"으로 좁혀 주세요. 조사 방법과 순서는 알아서 정하세요.
완료 기준 (모두 충족하면 끝입니다)
- 증가가 평시 대비 얼마나 비정상인지 수치로 판단했습니다.
- 증가분의 대부분을 만든 요청의 특성을 설명했거나, 설명하지 못한 비율을 명시했습니다.
- 가설 중 배제된 것과 남은 것이 근거와 함께 구분되어 있습니다.
멈추는 경우: 로그인 만료나 권한 문제처럼 제가 없으면 진행할 수 없을 때만 멈추고 물어보세요. 그 밖에는 묻지 말고 끝까지 진행하세요.
제가 드린 평시 기준이 데이터와 맞지 않아 보이면 그 사실을 먼저 알려 주세요.
보고: 끝난 뒤 한 번에, "제게 필요한 것 / 확인한 것 / 확인하지 못한 것" 세 제목으로 정리해 주세요.제가 썼던 프롬프트는 앞쪽에 가까웠습니다.
중간 보고도 다시 생각하게 됩니다. 문서에는 Sonnet 5.5가 도구를 호출하는 사이사이 짧은 진행 메모를 쓰도록 되어 있다고 나옵니다. 위에서 “Sonnet이 더 철저하게 수행했다”고 쓴 부분이 이 설계에서 나온 차이인지, 확장 프로그램이 그 메모를 보여주는 방식 때문인지는 확인하지 못했습니다. Opus 문서에도 작업 중 상황을 알려준다는 말은 있어서 Sonnet만의 특징이라고 단정하기는 어렵습니다.
effort는 둘 다 높음으로 맞춰서 돌렸습니다. 같은 높음이 두 모델에서 같은 양의 사고를 뜻하는지는 문서에서 확인하지 못했습니다.
그러니 위의 “속도와 사용량은 놀라웠다”와 “더 철저했다”는 프롬프트의 영향을 분리하지 못한 1회 결과로 읽어야 합니다. 모델 두 개에 프롬프트 두 종류를 모두 돌려서 네 조합을 만들면 모델 때문인지 프롬프트 때문인지 구분될 것 같습니다.