요약
Opus 5.5에는 완료 기준과 함께 일을 통째로 맡기고 "신중히 생각하라"는 지시는 빼는 것이 좋습니다.
claude.dev 블로그에 애디 오스마니가 올린 사용 가이드입니다. Opus 5.5는 오래 혼자 일하고 답하기 전에 늘 생각하는 모델이어서, 요청하고 이끌고 확인하는 방식도 달라져야 한다고 설명합니다.
왜 중요한가
- 예전 모델에 맞춰 넣던 "단계별로 생각하라" 같은 문구가 이제는 응답만 늦출 수 있습니다.
- Opus 5보다 여러 단계를 거치는 작업에서 가장 크게 나아졌다고 합니다.
- 사람의 역할은 단계마다 지시하는 일에서 완료 기준과 멈출 지점을 정하고 결과를 검토하는 일로 옮겨 갑니다.
핵심 내용
- 작업 전체를 한 메시지에 담고, 무엇이 끝난 상태인지 분명히 적으라고 했습니다.
- Claude Code의 CLAUDE.md(프로젝트 지침 파일)에 데이터 삭제나 강제 푸시 전에는 멈추고 묻도록 적어 두라고 권했습니다.
- 긴 작업은 TASKS.md 같은 파일에 체크리스트를 두면 컨텍스트 압축(오래된 대화를 요약해 줄이는 과정) 뒤에도 진행 상황이 남습니다.
- 큰 감사나 마이그레이션은 서브에이전트(일을 나눠 맡는 하위 에이전트)에 나누고, 각 결과의 근거를 다시 확인하게 하라고 했습니다.
- 결과를 볼 때는 요약에서 사용자에게 필요한 것부터 읽고, 사람이 검토하기 전에 병합을 막을 문제만 모델에게 먼저 짚게 하라고 했습니다.
HN 반응
- CI 개선을 맡겨 9시간 만에 실행 시간을 10분에서 4분으로 줄였다는 경험담에, 그런 최적화는 유지보수가 힘든 땜질이 되기 쉽다는 반론이 붙었습니다.
- 벤치마크로는 Opus 5.5가 Fable보다 앞서지만, 계획과 리뷰는 Fable에, 실행은 Opus에 맡긴다는 이용자가 많았습니다.
정말 좋은 모델입니다. 며칠 전에 Opus에게 CI를 전반적으로 빠르게 만들라는 큼직한 지시를 줬습니다. 과금되는 분(minutes)과 실제 걸리는 시간 둘 다 신경 쓴다고 말해 뒀고요. CI 전체를 분석해서 계획을 세우고, 그 계획을 Fable 서브에이전트에게 검토받은 다음, 위험은 낮고 효과는 큰 변경에 집중하라고 했습니다.
9시간 뒤에 머지할 준비가 된 PR이 12개 나왔고, 결과적으로 CI 시간은 약 10분에서 약 4분으로 줄었고 과금 분은 60% 정도 줄었습니다. 제가 들인 시간은 한 시간도 안 됩니다.
그런데 코드 품질은 괜찮았나요, 아니면 엉망이었나요?
저희 회사에서도 사람들이 CI를 개선하라고 비슷한 요청을 했는데, 결과는 CI가 빨라진 대신 임시방편 땜질투성이였거든요. 워크플로 YAML 파일마다 거대한 인라인 bash 스크립트가 들어가서 사실상 유지보수도 리뷰도 불가능한 난장판이 됐습니다. 이런 최적화를 몇 번만 거치면 CI 전체가 덕트 테이프로 만든 루브 골드버그 장치가 됩니다.
늘 문제가 되는 부분이죠. 중간급 엔지니어라면 누구든 CI 설정을 보면 비효율적인 부분을 몇 군데 쉽게 찾아내고 해결할 수 있습니다. 하지만 그걸 해결하려면 그 프로젝트에서만 통하는 특정한 조정을 넣어야 하고, 그런 조정은 다른 곳으로 일반화되지 않거나 추가 유지보수가 필요하다는 것도 압니다. 게다가 그 내용을 아는 사람은 이제 자기 한 명뿐이고요. CI 시간 6분 줄이는 일이 그만한 대가를 치를 가치가 있는 경우는 드뭅니다.
이번 주에 이상한 일이 생길 때마다 원인은 VSCode의 모델 선택이 "auto"로 되돌아가 있어서였고, 다른 모델이 나름대로 최선을 다하고 있었던 겁니다. 방금 5.5로 설정해 뒀어요. 제 용도에서는 Fable도 오히려 못하게 느껴집니다.
앤트로픽 스스로도 거의 모든 벤치마크에서 Fable을 5.5보다 낮게 평가합니다.
지금 "Fable은 대체 왜 있는 거죠?"라는 질문은 아주 아주 합당해요.
모델을 하나의 선형 축 위에서, 혹은 모든 벤치마크를 합친 다축 기저 집합으로 분류하는 실수를 하고 계시네요. 그건 사실이 아닙니다. 모델마다 잘하는 것과 할 수 있는 것, 문제에 접근하는 방식이 고유한데, 벤치마크에는 그런 면이 드러나지 않습니다. Fable은 검토를 더 잘합니다. 잘 설명하기는 어렵지만 사실입니다. 저는 Fable이 꼼꼼하게(가끔은 너무 꼼꼼하게) 검토하고, 정보를 빽빽하지만 질서 있게 제시한다고 믿습니다. 그 결과물은 예전에 보안 업체에서 코드 리뷰를 받으면 얻던 것과 맞먹습니다. Opus에게 작업을 시키고 Fable에게 (계획과 구현을) 검토시키는 조합이 좋습니다.
저는 Fable이 세부 사항을 다 채우지 않고 작업을 구상하는 식의 상위 수준 계획에 더 낫다고 봅니다. Opus는 그런 걸 썩 잘하지 못하는 것 같은데, 다른 모델들도 마찬가지이긴 하고요.
저도 같은 생각입니다. Fable은 주고받으면서 계획을 다듬는 데 더 낫고, Opus 5.5는 (확실히 더 저렴하기도 하고) 군더더기 없이 실행하는 데 더 낫습니다.
제 경험과도 똑같습니다.
Fable은 고정된 모델이 아니라 모델의 한 부류예요. Opus 5.5보다 더 나은 Fable 5.5도 나올 겁니다.
그래도 Claude Opus 5.1은 나온 적이 없잖아요. Fable은 5에서 5.1로 갔고 Opus는 5에서 5.5로 갔는데요.
아마 Fable 5.1이 Fable 5를 처음으로 다시 튜닝한(더 나은 표현이 있을까요?) 버전이고, Opus 5.5가 Opus 5를 처음으로 다시 튜닝한 버전일 텐데, 어쩌다 보니 Opus 쪽이 더 잘 나온 걸까요?
Opus 5.5는 아마 6 모델을 증류한 버전일 겁니다.
6이 있다면 서비스하고 있지 않겠어요? 대부분의 사용자에게는 너무 비싸더라도, 관심 가질 대기업은 분명 있을 텐데요.
아니요, 그렇게 생각하지 않습니다. 오픈AI에는 특정 벤치마크에서 GPT 6보다 5배쯤 낫다는 비공개 모델이 있는데, 출시하지 않고 출시 계획도 없습니다. AI 기업들이 최고 모델은 자기들이 쓰고, 나머지 사람들에게는 더 작고 싼 증류 모델을 내놓을 가능성이 점점 커지고 있어요. AI 기업들이 여러 분야로 수직 통합하고 있는 만큼 더 그렇습니다.
대형 AI 기업의 목표가 돈 받고 모델을 서비스하는 거라고 전제하고 계시네요. 그게 목표가 아닙니다. 그들에게는 최고 모델을 공유하지 않을 이유가 아주 많습니다.
저는 Fable이 더 박식하고 똑똑하고 학식이 깊은 쪽이고, Opus는 숙련된 기술자라고 봅니다.
벤치마크는 앞의 면모를 측정하지 못합니다.
앤트로픽은 모델 등급마다 출시 시점이 크게 달라서, 모든 용도에 압도적으로 가장 좋은 모델이 늘 하나씩 생기는 것 같습니다. Haiku 4.5는 나온 지 거의 1년이 됐고요. Sonnet은 괜찮지만 Opus보다 실질적으로 나은 점이 있는지는 모르겠습니다. Fable이 나오고 나서야 Fable과 Opus 중에서 고를 수 있게 됐는데, 5.5가 나온 지금은 Fable을 쓸 이유가 없습니다.
차라리 Fable을 내놓을 게 아니라 Opus 5로 냈어야 하고, 그다음 Opus 출시작은 Sonnet이라고 부르고, 그다음 Sonnet 출시작은 Haiku라고 불렀어야 한다고 생각합니다. 그 가격 구조를 감당할 수 있었을지는 모르겠지만, 앤트로픽은 토큰 가격 면에서 늘 가장 경쟁력이 떨어지는 쪽이었죠.
Fable은 새 API 가격표와 함께 나왔고 구독에도 별도 사용량이 주어졌어요.
말씀하신 대로 했다면 앤트로픽이 추가 비용을 엄청나게 떠안거나, 아니면 전반적으로 가격을 올리겠다는 신호를 시장에 보내는 셈이 됐을 겁니다.
게다가 Fable과 Opus는 특기가 달라서, 서로 다른 모델로 내놓는 게 정말 맞습니다.
Opus 5.5가 대단하고 Claude Max 사용량도 효율적으로 쓴다는 데 동의합니다. Opus 5에서 나오던 형편없는 글솜씨에 비하면 엄청난 도약이에요. 저는 주로 소통 문제 때문에 오케스트레이션 워크플로에 Fable을 쓰는 쪽으로 옮겼습니다. (Opus 5도 능력은 충분했던 것 같은데 수수께끼처럼 말해서 금방 신뢰를 잃었어요.) 5.5는 이제 방향을 덜 잡아줘도 되고 소통도 잘합니다. 그래서 같은 CC 세션을 지난 한 주 내내 돌렸습니다. (물론 글에 나온 대로 영속적인 계획 같은 걸 두고 컴팩션하면서요.) 이 세션이 제가 직접 만든 에이전트 오케스트레이션의 PM 역할을 맡아 다른 코딩 에이전트들(antigravity, codex, pi 등)을 굴리면서 괜찮은 결정을 내리고, 추천 사항도 대체로 좋습니다.
훌륭하긴 한데, 목표만이 아니라 자기가 무엇을 하는지는 여전히 알아야 합니다. 저는 몇 년 전에 플랫폼을 맨땅에서 만들었고, 지금은 기능을 더 넣고 디자인도 더 다듬어서 다시 만드는 중입니다. 아주 세세한 부분까지 무엇을 해야 하는지 정확히 알고 있죠. 첫 프롬프트에 아키텍처와 모든 것이 어떻게 동작해야 하는지를 아주 자세히 적었고, Xhigh로 한 시간 작업한 뒤에 제가 요청한 청사진 산출물이 나왔습니다. 그 뒤 사흘 동안 모든 걸 하나하나 읽으며 메모를 적었는데, 부가 가치 없이 시스템만 지나치게 복잡하게 만들어 놨더군요. 게다가 아키텍처 설계 일부는 보안 위험이 될 수도 있어 보였고요. 그래서 며칠 뒤에 제 메모를 먹였더니 이번에는 4시간에 1M 토큰이 들었습니다! 이후 또 며칠 동안 검토하고 메모를 적었는데, 원하는 모습에 더 가까워지긴 했지만 여전히 아키텍처 오류가 있었습니다. 세 번째 실행은 한 시간쯤 걸렸고, 마침내 제대로 된 모습이 나왔어요. 핵심이 아닌 부분에는 아직 메모할 것이 더 있지만요. 그래서 목표와 대략적인 상위 수준만 정해 주면 품질 좋은 결과가 나오는 단계에는 아직 와 있지 않다고 생각합니다.
한 가지 더 말씀드리면, 이게 잘 되는 건 목표가 명확하고 측정 가능하기 때문이라고 봅니다.
Opus 5.5로 힐 클라이밍(hill-climbing) 작업도 해 봤는데, 이쪽은 방향을 훨씬 더 많이 잡아줘야 했습니다. 왜냐면 ... 평가(eval)가 어렵거든요.
9시간이요?!
네. 서브에이전트를 여러 개 띄워서 온갖 것을 벤치마크하는 서로 다른 실험을 돌렸고, 과거 실행의 CI 로그도 검토했습니다. 결국 무엇을 어떻게 캐시하는지, 여러 코드 품질 검사, 테스트 러너 속도 개선 등 많은 부분이 바뀌었어요.
비용은 감히 묻지 못하겠네요. 저는 한 번 1시간 16분 돌아간 작업으로 60달러를 태운 적이 있어서요.
저는 월 100달러 구독을 쓰고 있고, 이 세션은 토큰 환산 비용으로 약 500달러가 들었습니다.
(전부 Opus 5.5로 돌린 건 아닙니다. Fable 5.1을 조언자로, Sonnet 5.5를 기계적인 변경에 쓰는 식으로 구성해 두었습니다.)
제발 가격이 빨리 내려갔으면 좋겠네요. 보조금이 끊기면 이런 워크플로는 이미 부자가 아닌 사람은 감당할 수 없게 될 테니까요.
2028년에 어마어마한 양의 컴퓨트 생산 설비가 가동돼요. 컴퓨트는 상품(commodity)입니다. 오래 비싼 채로 남아 있지는 않을 거예요.
장난감 같은 CI가 아니라면, 과금 분이 60% 줄면 500달러는 금방 회수합니다. GitHub는 터무니없이 비싸거든요.
표준
actions_linux의 비용이 분당 $0.006이니까, 500달러를 들여 실행당 6분을 아끼면 손익분기점은 약 1만 4천 번 실행입니다. 하지만 더 큰 머신을 쓰거나 병렬 작업을 돌린다면 절감액은 더 빨리 쌓이죠. 제 생각에는 피드백 루프가 짧아지는 실제 소요 시간 절감이 더 큰 이득일 수 있는데, 가치를 따지기는 더 어렵습니다.보조금은 Misanthropic과 ClosedAI가 사용자 돈을 짜내려고 심어 놓은 거짓말이고, 오히려 반대인 것처럼 생각하게 만드는 겁니다.
추론은 수익성이 아주 높은 사업이에요. 자원도 전문성도 훨씬 부족한 제3자 업체조차 그렇습니다.