Opus 5.5가 너프됐다는 느낌은 전혀 안 드는데

요즘 여기 올라오는 글들 보면 Opus 성능 너프 먹었다는 얘기가 많던데, 난 정반대 경험을 해서 한번 적어본다.

난 작은 마케팅 에이전시 운영 중인데, 지금 고객사 하나 리조트 관리 시스템을 만들고 있거든. AI 에이전트가 손님들 문의 응대하고, CRM에서 텔레마케터들이 리드랑 통화 데이터 처리하는 꽤 규모 있는 프로젝트야. 처음엔 Fable 쓰다가 중간에 Opus 5.5를 도입해서 빌드랑 코드 리뷰를 맡겼거든? 근데 얘가 Fable이 놓친 버그들을 잡아내더라. 그냥 "변수 이름 바꿔라" 수준이 아니라, 실제 손님들이 썼으면 바로 터졌을 법한 진짜 문제들을 찾아냄. 솔직히 이 정도일 줄은 몰랐다. 그 뒤로 Fable은 쳐다도 안 봄.

작업 속도도 훨씬 빠름. 예상했던 것보다 훨씬 앞서나가고 있는데, 우리 고객사가 서비스 오픈하면 매달 돈을 주는 구조라 이게 진짜 중요하거든. 그리고 사용 제한도 솔직히 혜자임. 매일 최소 12시간씩 돌리는데, Max 20x 기준으로 주간 제한의 88%밖에 안 썼고 리셋까지 아직 몇 시간 남았으니까.

만약 너네가 쓰면서 성능 구려졌다고 느낀다면, CLAUDE.md 파일부터 확인해 봐. 내 거 보니까 옛날 모델용으로 작성된 잡다한 내용이 엄청 많더라고. 싹 다 정리해서 200줄 미만으로 줄였는데, 아래 규칙들이 진짜 도움 많이 됐다:

모든 규칙 아래에는 왜 이 규칙이 필요한지 '이유'를 한 줄씩 적어둠. 왜 그런지 알면 훨씬 말을 잘 듣고, 나중에 어떤 규칙이 쓸모없는지 판단하기도 쉬움.

• 같은 걸 두 번 지적하게 되면 그날 바로 규칙으로 박아버림. 만약 이미 비슷한 규칙이 있으면 새로 추가하지 말고 기존 걸 수정해. 안 그러면 규칙끼리 서로 충돌해서 난리 남.

• 코드를 짠 에이전트가 직접 리뷰하게 하지 말고, 무조건 다른 에이전트한테 리뷰 시킴. 그리고 리뷰 결과는 그냥 제안일 뿐, 무조건 다 고쳐야 하는 리스트가 아님. 우리 앱 규모에서 진짜 중요한 수정인지 먼저 판단하게 함. 이거 도입하기 전엔 사소한 앱 하나 가지고 리뷰 두 번 돌렸더니 수정 계획이 14개나 튀어나오더라.

• 테스트 코드를 믿기 전에, 일부러 버그를 심어서 테스트가 제대로 실패하는지 확인해. 우리도 테스트 6개나 통과했는데 알고 보니 버그 6개 다 살아있던 적 있었음.

• 토큰 50만 개 정도 쌓이면 핸드오프 노트 작성하고 세션 새로 파. 그 이상 넘어가면 확실히 멍청해짐.

• git 명령어 써서 작업물 날아갈 수 있는 상황이면 무조건 커밋부터 해. 이거 막는 훅(hook) 추가하기 전에 작업물 4번 넘게 날려먹음.

난 불만 하나도 없다.