Claude Opus 5의 성능 저하는 모델 문제가 아닐 가능성이 높다.

나도 똑같이 4.8로 돌아갔는데, 프로젝트마다 차이가 좀 있더라

나도 마찬가지 ㅋㅋ

처음 나왔을 땐 진짜 싫었는데, 창의적인 자유를 안 주니까 알아서 다 해결하더라. 지금 "기본 스타일"은 좀 멍청함. 그냥 네 데이터랑 절차를 직접 입력해주면 괜찮음. 가이드라인(harness)이 탄탄할수록 더 잘 돌아감. 모델 자체가 더 말을 잘 듣는 건 아닌데, 이제 똑똑하게 작동하려면 스타일이나 절차를 따로 지정해줘야 함.

이제 모델을 객관적으로 비교하기가 너무 어려워진 것 같음.

사람들 이해가 안 가네. 마치 우리가 서로 다른 제품을 쓰는 것 같음. Opus 5는 괜찮았음. 실수도 더 적고, 프론트엔드 능력도 더 나음. 개인적으로는 Fable보다 더 많이 쓰고 있는데, 프롬프트에 좀 더 신경을 써야 함. Fable 5는 프롬프트가 좀 구려도 대충 넘어갈 수 있는데, Opus 5는 짧고 더 직접적인 프롬프트를 요구함.

ㅇㅇ 내부 시스템 프롬프트(harness) 대부분을 삭제해서 망친 게 맞는 듯.

맞음. 하네스(harness)는 모델만큼이나 중요하다고 볼 수 있지.

Opus 4.6은 규칙을 완전히 안 지키기 시작했고, *훅(hooks)*을 무시하기 시작했으며(!!), 필수적인 시간적 근거 확인(temporal grounding checks)도 안 하고, 지난주 초부터는 미친 듯이 확답을 피하고 있어.

이건 4월부터 구축하고 다듬고 반복해 온 신뢰할 수 있는 워크플로우인데, 지금까지는 거의 완벽했거든.

지난주에 Anthropic이 CC 하네스에 3만 토큰 분량의 내부 시스템 프롬프트를 추가했는데...

잠깐, 4.6 프롬프트도 바꿨다고? 모든 Opus 모델 다?

래퍼(wrapper)에서 성능 저하가 일어난다고 해도, 방어적인 해결책은 세션이 프로젝트를 기억하게 하는 걸 멈추는 거임. 현재 목표, 결정 사항, 미해결 질문, 최신 결과물 같은 작은 프로젝트 브리프를 유지하고, 새 세션마다 그걸 불러와서 업데이트하게 만들어. 그러면 채팅 기록은 버려도 작업 상태는 모델이나 프롬프트 변경에서 살아남을 수 있음.

그게 핵심 차이점임. 브리핑에 암묵적인 패턴을 다 담으려고 하면 안 됨. 에이전트가 그런 패턴을 확인할 수 있는 확실한 근거(대표 모듈, 아키텍처 문서, 테스트, 린트 규칙, 변경 사항을 검증하는 명령어 등)로 안내해야 함. 만약 어떤 패턴이 중요한데 그게 예전 프롬프트의 '직관'에만 의존한다면, 그건 아직 이식 가능한 상태가 아님. CLAUDE.md는 작게 유지하고 인덱스처럼 써야 함. X를 건드리기 전에 이 파일들을 검사하고 체크를 실행하는 식으로.