도구가 더 강해졌는데 쓰기가 더 어려워졌다는 반응이 나올 때, 두 가지 설명이 가능합니다. 도구가 잘못 만들어진 경우, 혹은 도구가 이전과 다른 것을 사용자에게 요구하는 경우입니다. 이 구분이 중요한 이유는 대응 방식이 완전히 달라지기 때문입니다.

앤트로픽이 Opus 5를 공개한 직후, 개발자와 실무자들이 모이는 Hacker News에 한 글이 올라왔습니다. 벤치마크에서 앞선 모델이 왜 쓰기는 더 불편한가. 685포인트, 631개 댓글이 달린 이 논의에서 흥미로운 건 반응이 두 갈래로 나뉘었다는 점입니다. 한쪽은 "예전 모델이 더 편했다"고 했고, 다른 쪽은 "그게 더 강한 모델이 해야 하는 올바른 행동"이라고 맞섰습니다.

두 집단이 같은 도구를 쓰면서 왜 반대 경험을 했는지를 따라가면 다른 질문이 나옵니다.

이전 모델이 편했던 방식입니다

"마케팅 이메일 작성해줘"라고 입력하면 이전 모델은 바로 뭔가를 내놓았습니다. 제품이 무엇인지, 독자가 누구인지, 어떤 톤이어야 하는지 — 이 정보를 제공하지 않아도 됐습니다. 모델이 스스로 빈칸을 채웠습니다.

이걸 능력이라고 읽기 쉽지만, 다르게 보면 모델이 사용자의 의도를 추정해서 진행한 것입니다. 결과가 그럴듯하면 추정이 맞은 것처럼 보였고, 틀려도 "AI가 이 정도"라는 기대 수준에서 넘어갔습니다. 사용자 쪽에서는 모호한 지시를 내려도 쓸 만한 결과가 나오는 경험이 반복됐습니다.

더 강한 모델이 드러냅니다

더 강한 모델은 이 빈칸 채우기를 다르게 처리합니다. 맥락이 부족하면 질문을 요청하거나, 여러 해석 가능성을 나란히 제시하거나, 어떤 방향을 원하는지 먼저 확인합니다. 예전에는 "일단 결과부터"였던 흐름이 끊기는 것처럼 느껴집니다.

이 마찰을 제품 디자인 관점에서 보면 다른 의미가 나옵니다. 사용자가 도구를 쓰다가 막히는 지점은 결함이기도 하지만, 동시에 그 사용자가 도구에 무엇을 기대하는지 가장 정확하게 드러내기도 합니다. 정보를 적게 주고도 원하는 결과를 받으려는 습관 — 이게 이전 모델에서는 통했지만 더 강한 모델에서는 통하지 않는 것이죠.

프롬프트 품질과 결과 품질의 연결이 이전보다 직접적이 됐습니다. 이전 모델은 사용자가 제공하지 않은 정보를 모델이 채워주는 완충재가 있었는데, 그 완충재가 줄어든 것입니다. 이 불편함을 이 관점에서 보면, 도구의 문제라기보다 작업 방식의 문제에 가깝습니다.

기대값이 올라가면 실패도 더 크게 느껴집니다

여기에 또 다른 원인이 섞여 있습니다. 더 강한 모델에 대한 기대치 자체가 높아집니다. 이전 모델이 실수했을 때는 "역시 AI는 이 정도"라는 선에서 받아들였습니다. 더 강한 모델이 같은 실수를 하면 "이게 왜?"라는 반응이 나옵니다.

서비스 품질 연구에서 관찰된 패턴과 비슷합니다. 기대치가 높아진 상태에서 같은 수준의 실수가 발생하면 만족도가 오히려 낮아집니다. 실제 실수 빈도가 줄어도 체감 만족이 따라오르지 않을 수 있기 때문입니다. Opus 5의 불편함 일부는 Opus 5가 충분히 강하다는 인식이 역설적으로 만들어낸 결과일 수 있습니다.

벤치마크가 측정하지 않는 작업들입니다

벤치마크는 정답이 있는 문제를 측정합니다. 코딩 과제, 수학 풀이, 사실 확인. 이 영역에서는 성능 향상이 체감으로 이어집니다. 실수가 줄고, 긴 맥락을 더 일관되게 처리하고, 복잡한 추론도 따라갑니다.

그러나 실무에서 AI를 쓰는 많은 상황은 정답이 없습니다. 기획 방향을 어떻게 잡을지, 이 문장이 더 자연스러운지, 이 제안이 설득력이 있는지. 이런 작업에서 더 강한 모델은 단정을 피하고 가능성을 나열하고 판단을 사용자에게 돌리는 경향이 있습니다. 이전 모델이 "이게 맞을 것 같습니다"라고 빠르게 답했다면, 더 강한 모델은 "이런 방향도 있고 저런 방향도 있는데 어느 쪽인가요"라고 물을 수 있습니다.

실제로는 더 정직한 대응입니다. 그러나 빠른 답을 기대하던 습관과 부딪힙니다.

모델을 고르기 전에 작업 유형을 먼저 정합니다

Hacker News 논의가 두 갈래로 갈린 이유가 여기에 있을 가능성이 높습니다. 서로 다른 작업에 같은 도구를 쓰면서, 서로 다른 경험을 각자의 모델 평가로 일반화했을 수 있습니다.

빠른 초안이 필요하거나 아이디어를 흩뿌려볼 때는 가벼운 모델이 효율적입니다. 코드 리뷰, 긴 문서의 논리 점검, 수치 분석처럼 정확도가 결과를 결정하는 작업에는 강한 모델이 맞습니다. 이 구분 없이 강한 모델로 전환하면 작업마다 예상과 다른 반응을 받고, 이전 모델로 돌아가면서 "결국 AI는 이 정도"라는 결론을 내리게 됩니다.

모델 선택 기준에 벤치마크 점수를 넣는 것은 합리적입니다. 그보다 먼저 정리할 질문이 있다면, 이 작업에서 모호함을 어느 정도 허용할 수 있는가입니다. 빠른 방향성이 중요한 작업이면 가벼운 모델이 실용적이고, 오류 하나가 결과를 바꾸는 작업이면 강한 모델의 신중함이 실제 비용을 낮춥니다. 이 질문을 먼저 정리하면 모델 선택과 프롬프트 방식이 함께 좁혀집니다.