GPT-5.6은 API 없는 내부 툴을 리버스 엔지니어링했는데, Opus 4.8은 그냥 '불가능'이라네요. 이 차이 느끼시는 분 계신가요?
GPT-5.6 sol reverse-engineered an internal tool with no API. Opus 4.8 just said “not possible.” Anyone else noticing this gap?
핵심 요약
GPT 모델은 문제 해결을 위해 탐색하는 반면, Opus는 제약 사항을 이유로 작업을 거부하는 경향에 대한 사용자들의 공감과 토론.
- 모델 간 해결 방식 차이 — GPT는 네트워크 트래픽을 분석해 우회로를 찾지만 Opus는 가이드라인을 이유로 작업을 중단함
- 실무적 제약 사항 — 문서화가 미비한 실제 엔지니어링 환경에서 Opus의 지나친 신중함이 오히려 한계로 작용함
- AI의 리스크 허용도 — 각 모델의 훈련 철학에 따라 문제 해결을 위한 탐색적 접근 방식이 크게 갈림
- 우회 방법 공유 — AI가 작업을 거부할 경우 자신의 사이트라고 속이거나 다른 도구를 사용하는 등의 팁이 공유됨
대신 안 된다고 말하는 대신, GPT-5.6은 파고들기 시작했어. 브라우저의 네트워크 트래픽을 검사하고, 발생하는 요청을 리버스 엔지니어링해서 그에 맞는 접근 방식을 구축했지. 첫 시도에 완벽하진 않았지만, 이전에는 사실상 존재하지 않던 작동 가능한 경로를 찾아냈어.
호기심이 생겨서 Opus 4.8에게 똑같은 작업을 시켜봤어.
결과는 완전히 달랐어. Opus는 즉시 불가능하다고 결론 내리고, 진행하려면 공식 API나 지원되는 통합 기능이 필요하다고 말하더군. 탐색도, 제약 사항을 우회하려는 시도도 없었어. 그냥 딱 잘라 거절한 거지.
이건 내가 한동안 눈여겨본 패턴과 일치해. GPT 모델들은 차단 요소를 조사해야 할 대상으로 취급하는 경향이 있어. 반면 Opus는 그걸 멈추고 '올바른' 방법을 알려줘야 할 이유로 취급하지.
가이드라인이 왜 존재하는지는 이해하고, 많은 상황에서 그게 옳은 선택이라는 것도 알아. 하지만 문서가 불완전하고 공식적으로 지원되는 경로가 없는 복잡한 실무 엔지니어링 작업에서는, 그런 신중함이 실제적인 한계로 변할 수 있어.
다른 사람들도 이런 일을 겪었는지 궁금해. 이게 훈련 철학의 차이일까, 아니면 두 연구소가 현재 리스크 허용도를 그렇게 조정하고 있는 걸까?
