OpenRouter, Claude Sonnet과 Opus를 테스트하다… Haiku가 선택을 더 복잡하게 만든다

OpenRouter는 Haiku 5.5와 함께 Claude Sonnet과 Opus를 테스트한 결과, 코딩 성능이 동률이었다고 발표하며 가장 비싼 옵션을 모든 곳에 써야 한다는 주장에 의문을 제기했다. 10월 30일 공개한 비교 결과는 일상 업무에는 Sonnet 5.5, 대량 작업에는 Haiku 5.5, 실패 비용이 큰 어려운 작업에는 Opus 5.5를 권장한다. 핵심 차이는 범위가 정해진 과제를 통과하는 것과 불확실한 과제 전반에서 판단력을 유지하는 것 사이에 있다.

플랫폼의 Claude 모델 비교에 따르면, 모든 모델이 선정된 코딩 과제를 통과했다. 이 결과는 평판이나 기본 설정만으로 모델을 선택하는 팀에 재고를 요구한다. 동시에 더 어려운 과제가 언제 상위 모델로의 전환을 정당화하는지라는 중요한 질문은 남겨 둔다.

실질적인 답은 모델이 실수한 뒤 어떤 일이 벌어지는지에 달려 있다. 거부된 분류, 부정확한 문서 요약, 결함 있는 아키텍처 결정은 서로 다른 결과를 낳는다. Sonnet은 합리적인 출발점으로 보이며, Haiku와 Opus는 이 범위의 양 끝을 담당한다. 이들을 상호 대체 가능한 모델로 취급하는 것은 증거를 과도하게 확대 해석하는 일이다. 그렇다고 제품 계층을 완전한 구매 가이드로 여기는 것도 핵심을 놓치는 일이다.

Claude Sonnet과 Opus 테스트는 좁은 범위 안에서 동률을 보였다

OpenRouter의 결과는 테스트한 과제에서는 더 저렴한 모델을 지지하지만, 모든 소프트웨어 작업에서 동등한 역량을 입증한 것은 아니다.

플랫폼은 모델이 답변을 생성하는 동안 확인할 수 없었던 비공개 테스트를 포함한 11개의 코딩 문제를 설명했다. 각 모델은 25번의 시도를 모두 통과했다. 별도의 Claude Code 실습도 모든 모델이 성공적으로 마쳤다. OpenRouter는 이 과제들이 작고 명확하게 규정돼 있었다는 점을 명시적으로 인정한다.

이 단서는 독자가 헤드라인 결과를 해석하는 방식을 좌우한다. 명확히 정의된 함수는 모델이 목표로 삼을 수 있는 대상을 제공한다. 테스트 스위트는 외부 검증 수단을 제공한다. 이 두 조건이 함께하면, 열린 형태의 엔지니어링 과제보다 성공 여부를 더 쉽게 판단할 수 있다.

합의된 계산을 구현하는 것과 기업에 실제로 필요한 계산이 무엇인지 결정하는 일의 차이를 생각해 보자. 구현에는 명시적인 입력, 출력, 예외 사례가 있을 수 있다. 반면 비즈니스 결정에는 일관되지 않은 요구사항 해석, 누락된 정보 식별, 원래 요청이 잘못된 방향을 가리킬 때 이를 알아차리는 일이 필요하다.

두 활동 모두 추론을 수반하지만, 시스템에 요구하는 바는 다르다. 구현 테스트를 통과했다는 사실은 첫 번째 활동에 대해 유용한 정보를 제공한다. 특히 아무도 정답을 문서화하지 않은 경우, 두 번째 활동에 대해서는 근거가 더 적다.

이 차이는 소프트웨어 저장소 내부에서도 중요하다. 국소적인 수정은 더 넓은 의존성을 놓친 채 동작을 유지하고 기존 검증을 만족시킬 수 있다. 반대로 기술적으로 인상적인 재설계는 다른 팀이 의존하는 가정을 바꾸기 때문에 실패할 수 있다.

따라서 중요한 질문은 평가가 위임하려는 과제와 닮아 있는지다. 일상적인 코드 생성에는 이 비교가 고무적인 근거를 제공한다. 문서화가 불완전한 낯선 시스템에는 더 많은 문제가 해결되지 않은 채 남는다.

상업적 이해관계도 고려할 필요가 있다. OpenRouter는 모델 접근 권한을 판매하며, 이 비교와 함께 평가 서비스를 홍보한다. 이 관계가 측정 결과를 무효로 만들지는 않는다. 다만 재현 가능한 방법과 독립적인 검증의 가치를 특히 높인다.

이 뉴스는 모델 계층에 대해 더 좁고 유용한 도전을 제기한다. 과제에 명확한 결승선이 있을 때는 더 강한 모델에 비용을 지불해도 관찰된 결과가 자동으로 개선되지는 않는다. 구매자는 이제 일괄적인 기본 설정에 의문을 제기할 구체적인 근거를 갖게 됐다.

일상적인 과제가 애플리케이션 작업량의 상당 부분을 차지할수록 이러한 압박은 커진다. 시연에서는 중요하지 않아 보이는 모델 선택이 반복되는 운영 결정이 될 수 있다. 이 비교는 그 결정을 측정된 과제 성능 쪽으로 이끈다.

Sonnet의 중간 위치는 일괄 기본 설정에 압박을 가한다

Sonnet의 가장 강력한 근거는 팀이 어떤 과제에 특별한 처리가 필요한지 알기 전에 실용적인 기준선을 제공한다는 점이다.

Anthropic은 9월 28일 Sonnet 5.5를 출시하며, 범위가 정해진 일상 업무, 버그 수정, 문서 작성에 적합한 모델로 제시했다. Sonnet 성능 평가에서도 지속적인 판단이 필요한 복잡하고 개방형 작업에서는 Opus가 더 강하다고 설명한다.

이러한 포지셔닝은 대체로 OpenRouter의 권고와 맞지만, 그 의미는 신중히 살펴볼 필요가 있다. 기본값은 아직 분류되지 않은 작업을 위한 출발 가정이다. 과제가 예상치 못한 어려움을 드러낼 때는 쉽게 수정할 수 있어야 한다.

엔지니어링 관리자에게는 모델 선택 정책이 압박의 대상이 된다. 모든 요청을 Opus에 배정하려면 조직이 어떤 추가 이점을 얻는지 설명해야 한다. 모든 것을 Haiku에 맡기려면 실패를 어떻게 감지할지 설명해야 한다.

Sonnet은 이 두 의무 사이의 공간을 차지한다. 팀에 더 강한 대안과 더 작은 대안을 모두 측정할 기준선을 제공한다. 이 기준선은 비교에 승인된 결과, 검토 시간, 실수 수정에 드는 노력이 포함될 때 유용해진다.

이슈 설명과 회의 노트에서 업데이트를 작성하는 내부 어시스턴트를 상상해 보자. 대부분의 요청은 단순한 종합 작업일 수 있다. 가끔은 팀 간 상충하는 약속을 조정해야 하는 요청이 있을 수 있다. 단일 모델 정책은 이 차이를 감춘다.

Sonnet을 기본값으로 삼는 것은 Sonnet이 모든 요청을 가장 잘 처리한다는 주장이 아니라 운영상의 선택이 될 것이다. 어시스턴트는 여전히 상충하는 근거를 인식하고 추가 검토를 요청할 방법이 필요하다. 그렇지 않으면 기본값은 검토되지 않은 한계선이 된다.

같은 논리는 코드 검토에도 적용된다. 국소적인 변경 사항을 명시적 규칙과 대조하는 일은 새로운 인증 설계가 보안 가정을 유지하는지 판단하는 일과 다르다. 두 활동을 모두 “코드 검토”라고 부르면 작업량이 실제보다 더 균일해 보인다.

어떤 Claude 모델이 일상 업무 역할에 적합한지 묻는 독자에게는 요청에 붙은 직책보다 과제의 경계가 더 중요하다. 개발자는 일상적인 작업을 제출할 수 있지만, 짧은 관리 질문에는 상당한 판단이 필요할 수 있다.

팀이 이러한 경계를 명시적으로 설명할 때 Claude Sonnet과 Opus 논쟁은 더 실질적인 의미를 갖는다. 모델은 어떤 정보를 받게 되는가? 무엇이 수용 가능한 답변인가? 누가 실패를 알아차리며, 얼마나 빨리 알아차리는가?

이 질문들은 Sonnet이 기본값 지위를 내려놓아야 할 시점도 분명히 한다. 더 작은 모델이 비슷한 검토 노력으로 지속적으로 승인된 결과를 낸다면 기준선은 더 낮아져야 한다. 어려운 사례가 반복해서 개입을 요구한다면, 그 사례들은 다른 경로를 거쳐야 한다.

조직 차원의 변화는 작지만 중요하다. 모델 선택은 증거에 뒷받침되는, 수정 가능한 운영 정책이 된다. 조달 과정에서 가장 안전하게 들리는 제품명에 전적으로 의존하지 않게 된다.

Haiku는 위임의 경제성을 바꾸지만 판단의 필요성을 없애지는 않는다

Haiku는 애플리케이션이 범위가 정해진 작업과 그 작업에 의존하는 결정을 분리할 수 있을 때 특히 흥미롭다.

Anthropic은 10월 7일 Haiku 5.5를 출시하며 빈번하고 비용에 민감한 과제를 위한 모델로 설명했다. 명시된 활용 사례에는 요약, 분류, 데이터베이스 쿼리, 그리고 더 큰 과제의 일부를 처리하는 위임형 어시스턴트인 서브에이전트가 포함된다. 이러한 역할은 Haiku 워크로드 가이드에 나타난다.

아키텍처 측면의 의미는 명확하다. 어시스턴트가 정보를 수집하는 데 쓰는 모델과 그 정보의 의미를 결정하는 데 쓰는 모델이 반드시 같을 필요는 없다. 이러한 책임을 분리하면 역량을 실제 작업에 맞출 기회가 생긴다.

고객 피드백을 바탕으로 브리핑을 준비하는 가상의 제품 기획 어시스턴트를 생각해 보자. 한 구성 요소는 요청을 추출하고 이를 뒷받침하는 구절을 첨부할 수 있다. 다른 구성 요소는 서로 모순되는 설명을 조정하고 주목할 만한 사안을 추천할 수 있다. 추출 단계와 추천 단계에는 서로 다른 수준의 추론이 요구된다.

위임된 출력물이 알아보기 쉬운 구조를 갖고 저렴한 검증 방법이 있을 때 더 작은 모델은 매력적이다. 더 큰 결정은 추출된 구절이 정확하고 완전하며 관련성이 있는지에 여전히 좌우된다.

따라서 위임은 일부 책임을 주변 애플리케이션으로 옮긴다. 시스템에는 명확한 과제 경계, 신뢰할 수 있는 출처 참조, 누락된 정보를 처리하는 규칙이 필요하다. 이러한 통제가 없다면 저렴한 단계들의 집합이 값비싼 오해를 낳을 수 있다.

핵심 질문은 애플리케이션이 위임된 작업을 처음부터 다시 수행하지 않고도 검증할 수 있는지다. 인용된 구절을 출처와 대조하는 일은 비교적 직접적이다. 문서 모음 전체에서 어시스턴트가 관련된 모든 모순을 찾아냈는지 확인하는 일은 더 어렵다.

지식 워크플로는 이 지점에서 유용한 비교를 제공한다. 검색 가능한 지식 베이스는 답변의 근거가 되는 자료를 보존하는 데 도움이 된다. 이후 모델 선택은 어떤 어시스턴트가 그 자료를 다루며 어느 정도의 판단을 부여받는지를 결정한다.

Haiku의 역할은 이 전체 연결망을 통해 평가해야 한다. 자연스럽게 읽히는 짧은 요약도 결정을 바꾸는 예외 사항을 빠뜨릴 수 있다. 구조화된 추출은 주장을 잘못된 출처에 연결하면서도 유효해 보일 수 있다.

이것이 출력의 외관보다 후속 승인 여부를 측정해야 하는 이유다. 검토자가 누락된 맥락을 재구성하기 위해 반복해서 문서를 다시 열어야 한다면, 겉보기 효율성은 사람에게 작업을 전가한 셈이다.

반대의 경우도 중요하다. 과제가 좁고 결과를 쉽게 확인할 수 있다면, 모든 곳에 더 강한 모델을 사용하는 것은 자원을 낭비할 수 있다. 제품명만으로 추가 가치를 입증할 수는 없다.

위임 작업에 어떤 Claude 모델이 적합한지 비교하는 팀에게 Haiku는 신뢰할 만한 후보이다. 가장 강력한 근거는 명확한 경계와 측정 가능한 승인 기준에서 나온다. 가장 약한 근거는 작은 과제가 자동으로 더 안전하다는 가정으로 판단을 대체하는 데서 나온다.

이 구분은 권고를 현실에 맞게 유지한다. Haiku는 애플리케이션 개발자가 활용할 수 있는 선택지를 넓힌다. 그렇다고 각 구성 요소가 무엇을 달성해야 하는지 정의할 책임까지 없애지는 않는다.

Opus는 방지하는 실패를 통해 자신의 자리를 증명해야 한다

Opus를 선택하는 근거는 모든 짧은 벤치마크에서 이길 것이라는 기대가 아니라, 어려운 작업과 피할 수 있는 재작업에 있다.

Anthropic은 9월 22일 Opus 5.5를 출시하며 까다로운 코딩 및 전문 업무를 위한 모델로 제시했다. Opus 역량 평가는 벤치마크 격차가 실제 환경의 차이를 보여 주는 지표로서 점점 덜 신뢰할 만해졌다고 경고한다. 이는 보편적인 보장이 아니라 여전히 개발사의 평가다.

이러한 틀은 범위가 정해진 코딩 동률이 구매 결정을 끝내지 못하는 이유를 설명하는 데 도움이 된다. 더 강한 모델의 가치는 과제에 명확한 사양이 없을 때 드러날 수 있다. 초기 실수가 이후 작업의 방향을 바꿀 때도 마찬가지다.

낯선 서비스와 불완전한 문서를 포함하는 가상의 마이그레이션을 상상해 보자. 어시스턴트는 기존 동작을 파악하고, 의존성을 식별하며, 호환성을 유지하고, 해결되지 않은 가정을 설명해야 한다. 성공적인 패치는 과제의 일부일 뿐이다.

그럴듯한 해결책에 빠르게 도달하는 모델도 잘못된 해석을 전제로 삼으면 오히려 더 많은 작업을 만들 수 있다. 그러면 검토자는 그 추론을 재구성하고, 잘못된 가정을 찾아내며, 관련 변경 사항을 되돌려야 한다.

중요한 척도는 승인된 결과에 이르는 전체 경로다. 여기에는 모델의 작업, 인간의 감독, 검증, 수정이 포함된다. 요청 단위 비교만으로는 이러한 결과를 모두 포착할 수 없다.

이는 Opus가 특정 마이그레이션에서 더 잘 수행할 것임을 입증하지는 않는다. 다만 이를 사용할 근거를 정당화하려면 어떤 종류의 증거가 필요한지를 보여 준다. 구매자는 대표적인 까다로운 과제에서 중대한 실수가 더 적은지, 불확실성이 더 명확한지, 또는 개입이 더 적은지를 살펴봐야 한다.

작업 길이만으로는 완전한 대체 지표가 되기 어렵다. 긴 문서에도 질문이 명확한 반복적 내용이 포함될 수 있다. 짧은 요청에는 권한, 보안 또는 양립할 수 없는 비즈니스 요구사항에 관한 어려운 결정이 숨어 있을 수 있다.

더 강력한 신호는 모호성과 결과의 중대성이 결합된 경우다. 어시스턴트가 무엇이 중요한지 스스로 찾아내야 하는가? 잘못된 가정이 확산될 수 있는가? 결과물이 다른 작업에 영향을 미치기 전에 검토자가 문제를 신뢰성 있게 발견할 수 있는가?

이러한 조건이 적용되는 경우에는 더 높은 역량을 배정하는 것이 합리적일 수 있다. 다만 그 배정 역시 조직 자체의 작업에서 얻은 증거가 필요하다. 프리미엄 모델이 평가에서 영구적으로 면제되어서는 안 된다.

모델 선택으로 달성할 수 있는 범위에도 한계가 있다. 더 강력한 어시스턴트라도 누락된 승인을 제공하거나, 검토되지 않은 프로덕션 변경을 허용 가능한 것으로 만들 수는 없다. 역량, 권한, 검증은 여전히 별개의 요구사항이다.

Claude Sonnet과 Opus를 비교할 때, 이는 “쉬운 작업 대 어려운 작업”보다 더 정확한 경계선을 만든다. Sonnet은 일반적인 기준선 역할을 할 수 있다. Opus는 작업이 최종 결과에 중요한 약점을 반복적으로 드러낼 때 예외로서의 가치를 얻는다.

이 기준은 구매자가 단지 안심하기 위해 비용을 지불하지 않도록 보호하기도 한다. 질문은 Opus가 결과를 바꾸는지, 혹은 그 주변의 작업을 줄이는지가 된다. 둘 다 아니라면 제품 계층에서의 위치는 실질적인 정당성이 거의 없다.

코딩 동점은 신뢰성과 통합에 관한 질문을 남긴다

작은 평가는 기회를 드러낼 수 있지만, 이를 도입하는 데 따르는 전체 위험을 측정하지는 못한다.

OpenRouter의 비교는 실질적인 구매 질문을 던진다는 점에서 주목할 가치가 있다. 다만 그 결론은 특정 과제 모음, 설정, 성공 기준에 여전히 의존한다. 그 모음에서 프로덕션 정책으로 나아가려면 추가 증거가 필요하다.

한 가지 한계는 범위와 관련된다. 평가는 함수가 정의된 사례를 처리하는지 테스트할 수 있지만, 유지보수성과 향후 호환성은 대체로 측정되지 않은 채 남을 수 있다. 이용 가능한 모든 검사를 통과했다고 해서 모든 중요한 요구사항이 반영되었다는 뜻은 아니다.

또 다른 한계는 반복 조건과 관련된다. 범위가 제한된 과제를 다시 실행하면 해당 과제에서의 일관성에 관한 정보를 얻을 수 있다. 하지만 더 폭넓은 낯선 문제를 테스트하는 일을 대체하지는 못한다.

겉으로 보이는 차이가 작을 때 이러한 구분은 중요해진다. 근소한 우위는 선택된 작업, 실행 환경 또는 모델 설정을 반영할 수 있다. 구매자는 작은 점수 차이를 영구적인 순위로 바꾸는 일을 경계해야 한다.

주변 소프트웨어도 중요하다. 애플리케이션이 응답을 잘못 처리하거나, 유용한 맥락을 잃거나, 도구 결과를 잘못 해석하는 동안에도 모델 자체는 잘 수행할 수 있다. 운영 신뢰성은 전체 시스템의 특성이다.

OpenRouter의 별도 벤치마크 측정은 모델, 제공업체, 검색 엔진, 도구 예산을 구분한다. 이러한 구분은 구매자에게 실질적인 문제를 부각한다. 모델을 바꾸는 일이 실행의 다른 부분을 바꾸는 일과 동시에 일어날 수 있기 때문이다.

예를 들어, 애플리케이션은 모델을 전환하면서 지침도 바꿀 수 있다. 승인된 결과가 개선되더라도 조직은 그 개선을 즉시 모델만의 공으로 돌릴 수 없다. 새 지침이 차이의 일부를 설명할 수 있다.

공급업체의 주장을 비교할 때도 같은 주의가 필요하다. Anthropic은 자사 전체 제품군의 가치를 설명하는 데 이해관계가 있다. OpenRouter는 모델 비교와 라우팅을 유용하게 만드는 데 이해관계가 있다. 두 관점 모두 증거를 제공하지만, 어느 쪽도 독립적인 테스트를 대체하지는 않는다.

회의적인 해석이 두 회사를 모두 일축해야 한다는 뜻은 아니다. 이는 측정 결과와 그 결과를 바탕으로 한 권고를 분리해야 한다는 뜻이다. 보고된 코딩 동점은 설명된 설정 안에서의 측정 결과다. 제안된 기본 정책은 더 폭넓은 판단이다.

가장 강력한 내부 검토는 집계 점수만이 아니라 불일치를 살펴볼 것이다. Haiku는 어디에서 Sonnet이 거부하는 답변을 내놓는가? Opus는 어디에서 누락된 가정을 찾아내는가? 어떤 불일치가 실제로 검토자의 결정을 바꾸는가?

그러한 사례는 구분되지 않은 성공률보다 더 많은 것을 보여 준다. 더 강력한 모델이 유용한 판단을 제공하는지, 아니면 단지 다른 답변을 작성하는지를 보여 준다.

따라서 해결되지 않은 문제는 실질적이다. 조직은 작업을 여러 모델에 분배하면서도 승인된 결과를 유지할 수 있는가? OpenRouter는 조사할 이유를 제공한다. 그러나 모든 저장소, 문서 모음 또는 고객 상호작용에 적용되는 보편적 답을 제공하지는 않는다.

다음 신호는 권고가 적용되는 범위를 보여줘야 한다

일상적인 품질이 유지되고, 어려운 과제에서의 이점이 측정 가능해지며, 더 작은 모델의 비용 절감 효과가 전체 워크플로에서도 유지된다면 이 권고는 더욱 강해진다.

향후 몇 달 동안 주목할 첫 번째 신호는 더 길고 덜 구체적인 과제에 대한 독립적인 테스트다. 유용한 보고서는 원래 요청, 관련 제약조건, 인간의 개입, 최종 승인 결정을 보여 줄 것이다. 성공적인 시연과 함께 실패한 시도도 확인할 수 있게 해야 한다.

그러한 조건에서 Opus가 중대한 오류를 꾸준히 줄인다면, 제한적으로 배정되는 역할에 대한 근거가 강화된다. Sonnet이 비슷한 수준의 감독으로 이를 따라잡는다면, 더 폭넓게 Sonnet을 기본값으로 삼아야 한다는 주장이 강해진다.

이 신호가 중요한 이유는 이야기에서 해결되지 않은 부분이 지속적인 판단과 관련되기 때문이다. 짧은 연습 문제를 더 추가하면 범위는 넓어지겠지만, OpenRouter가 남긴 질문에 직접 답하지는 못한다.

두 번째 신호는 제한된 작업을 Haiku에 맡기는 팀의 프로덕션 증거다. 중요한 결과에는 승인된 답변, 에스컬레이션, 검토자 수정, 그리고 후속 의사결정이 정확하게 유지되는지가 포함된다. 모델의 기여는 그 결과물이 더 큰 프로세스에 들어간 뒤에도 확인 가능해야 한다.

Haiku가 그러한 결과를 유지한다면, 가끔의 백그라운드 작업을 넘어 이를 사용할 근거가 강화된다. 검토자가 반복적으로 누락을 수정하거나 근거를 재구성해야 한다면, 권고에는 더 좁은 경계가 필요하다.

지식 근로자는 원본 자료와 결정을 AI 지식 베이스에 보존함으로써 이 증거를 더 쉽게 검토할 수 있다. 목적은 연속성이다. 검토자는 무엇이 답변을 뒷받침했는지와 예외가 왜 발생했는지를 확인해야 한다.

세 번째 신호는 모델 선택이 전체 애플리케이션 전반에서 신뢰성 있게 유지되는지 여부다. 팀은 실행 동작, 비용 산정, 위임된 결과의 처리 방식에서 발생하는 변화를 주시해야 한다. 통합 문제가 실제로 무슨 일이 일어났는지를 흐린다면, 유리한 모델 비교도 실질적 가치를 잃는다.

그러한 운영 세부사항이 예측 가능해지면 작업 기반 선택을 더 쉽게 유지할 수 있다. 일관되지 않은 상태로 남는다면 팀은 요청을 분배하는 이점과 추가 복잡성을 비교해야 한다.

이 신호들은 함께 권고의 가장 약한 지점을 테스트한다. 범위가 제한된 연습 문제 밖의 작업, 위임된 결과물의 품질, 그리고 이를 연결하는 시스템의 신뢰성을 살핀다. 어느 것도 전체 Claude 제품군에서 영구적인 승자를 선언할 필요는 없다.

Claude Sonnet과 Opus를 다시 검토하는 사람이라면, 팀이 이미 승인하거나 거부한 작업부터 시작하라. 일반적인 요청과 검토 시간을 소모한 난감한 사례를 포함하라. 답변을 비교하기 전에 원래 증거를 보존하고, 승인 기준을 정의하며, 모델이 어디에서 의견이 갈리는지 살펴보라. 그런 다음 Haiku가 숨겨진 작업을 검토자에게 넘기지 않고 제한된 부분을 맡을 수 있는지 고려하라. 추가 판단이 관찰 가능한 이점을 낳는 곳에는 Opus를 유지하고, 증거가 바뀌면 그 결정을 수정하라. 유용한 결과는 팀이 설명하고, 검토하고, 개선할 수 있는 모델 정책이다. 승인된 결과에 이르는 전체 경로를 계산했을 때, 어떤 과제가 여전히 더 강력한 모델을 정당화하는가?