Opus 5와 GPT 5.6이 과도하게 엔지니어링하고 이해하기 어려운 이유
Why opus 5 and gpt 5.6 over engineer and are incomprehensible
핵심 요약
최신 모델들이 테스트 커버리지 최적화로 인해 단순한 문제도 과도하게 복잡하게 만드는 현상에 대한 분석.
- 과도한 엔지니어링 — 모델이 단순한 문제에도 불필요하게 방대한 테이블과 테스트 코드를 생성함
- 학습의 부작용 — RL 학습 과정에서 테스트 커버리지와 장기 과제 수행을 우선시하도록 최적화됨
- 파시모니의 결여 — 간결함(parsimony)은 정량화하기 어려워 RLAIF 설정에서 우선순위가 밀림
- 대응 전략 — 모델의 노력(effort) 설정을 낮추거나, 제약 조건을 강화하는 프레임워크 사용 권장
Opus 5와 GPT 5.6은 매우 지능적이며 이전 버전에서는 찾지 못했을 버그를 확실히 찾아낼 능력이 있습니다. 하지만 이들은 단순한 문제를 과도하게 생각하고 과도하게 엔지니어링하는 경향도 있습니다. 예를 들어, 간단한 일반 파싱 규칙을 만드는 대신, 수백 개의 테스트가 작성된 거대한 룩업 테이블을 만들어낼 수 있습니다. 결국 같은 기능을 수행하지만, 더 느리고, 룩업 테이블에 없는 엣지 케이스는 어떻게 처리할지 등 견고함은 오히려 떨어질 수 있습니다. 또한 코드를 너무 많이 생성하고 테스트도 과도하게 만들며, 결과물을 내놓는 데 더 많은 시간이 걸립니다.
이는 모델들이 완전성(테스트 커버리지)과 장기 과제 수행을 최적화하도록 RL 학습되었음을 시사합니다. (부작용으로 모델이 불필요한 엣지 케이스를 최적화하느라 몇 시간씩 돌아갈 수 있는데, 이는 작업 시간은 늘리지만 자동화된 분류기 입장에서는 좋아 보입니다.) 저는 이것이 모델이 과도하게 일반화하려다 실패하면서 원래의 범위에서 점진적으로 벗어나는 원인이 된다고 생각합니다. 모델은 간결함을 유지하는 대신 엣지 케이스를 찾으려 하기 때문입니다. 이로 인해 사용자에게는 보이지 않는 가정이 만들어지고, 그 가정에 기반한 출력물은 이해하기 어렵게 됩니다.
요약: 모델들은 파시모니(간결함)를 희생하면서 테스트 커버리지의 완전성, 견고함, 장기 과제 수행을 보상하는 자동화된 분류기를 통해 사후 학습되었습니다. 파시모니는 정량화하고 분류하기가 훨씬 어렵기 때문에 RLAIF 설정에서는 손해를 보게 됩니다.
그렇다면 이 모델들을 사용하는 가장 좋은 방법은 무엇일까요? 이렇게 훈련된 경향을 어떻게 관리할 수 있을까요?
한 가지 분명한 해결책은 더 잘 튜닝될 때까지 사용하지 않거나, 아니면 단순히 적대적 검토자로 사용하는 것입니다. 또 다른 옵션은 모델을 제약하기 위해 당신의 하네스를 (과도하게?) 엔지니어링하는 것입니다.
