CPU 벤치마크, 에이전트 도구 실행과 모델 추론을 분리하다
Tom's Hardware는 검증된 프로세서 순위를 공개하기에 앞서 호스트 워크로드를 모델 추론과 분리하는 에이전틱 AI용 첫 CPU 벤치마크를 소개했다. Tom's Hardware CPU 벤치마크는 AI 에이전트가 로컬 리소스를 두고 경쟁할 때 프로세서가 얼마나 많은 작업을 처리할 수 있는지라는 구체적인 질문을 겨냥한다. 이 접근법은 하드웨어 용량 측정과 실제 사용자의 대기 시간 예측을 구분하는 데 유용하다.
AI 에이전트는 모델을 사용해 행동을 선택하고, 도구를 실행하며, 그 결과를 평가하는 소프트웨어다. 이러한 행동은 텍스트 생성 이상의 작업을 만들어 낸다. 모델이 다음에 일어날 일을 결정하는 동안 프로세서는 테스트를 실행하거나, 문서를 검색하거나, 작업을 조율할 수 있다.
핵심적인 긴장은 통제된 측정과 현실적인 실행 사이에 있다. 개인용 컴퓨터 벤치마크인 MLPerf Client에는 이미 모델 실행과 도구를 아우르는 측정 방식의 에이전트 워크로드가 포함돼 있다. 호스트를 분리하면 다른 관점을 얻을 수 있지만, 구매자는 에이전트 벤치마크를 구매 근거로 받아들이기 전에 두 관점을 모두 살펴야 한다.
Tom's Hardware CPU 벤치마크가 실제로 도입한 것
10월 29일 특집에서 분석가 Jake Roach는 모델 상호작용을 기록하고 도구가 로컬에서 실행되는 동안 응답을 재생하는 프로토타입을 설명했다. 이 매체는 설계가 확립됐다고 말하지만, 결과는 여전히 면밀한 검토가 필요하다. 따라서 해당 agentic CPU benchmark는 확정된 프로세서 순위표가 아니라 테스트 접근법을 제시한다.
핵심 변화는 주변 작업을 수행하는 컴퓨터를 살피는 동안 모델의 행동을 일정하게 유지하는 방법이다.
모델의 응답을 생성하는 연산인 추론은 하드웨어 테스트에 또 다른 변동 요인을 더한다. 에이전트는 그 외에는 유사한 실행에서도 서로 다른 행동을 선택할 수 있다. 의사결정과 실행 속도가 모두 달라지면 원인을 파악하기가 더 어려워진다.
기록된 응답은 워크로드 내에서 고정된 경로를 제공한다. 이런 구성에서는 더 짧은 완료 시간을 더욱 일관된 행동 순서에 비추어 해석할 수 있다. 이는 실험을 더 쉽게 검토할 수 있게 하지만, 결과가 나타내는 범위는 좁힌다.
예시로 코딩 작업을 생각해 보자. 에이전트가 프로젝트를 검색하고, 소스 파일을 열고, 편집을 적용한 뒤 테스트를 실행한다. 다음 시도에서 라이브 모델은 다른 검색을 선택하거나 추가 테스트를 요청할 수 있다. 이러한 시도를 비교하면 하드웨어 차이와 수행된 작업의 차이가 함께 섞인다.
통제된 순서는 이러한 모호성을 줄인다. 이 실험은 에이전트가 우연히 똑같이 효율적인 접근법을 선택했는지가 아니라, 서로 다른 시스템이 비교 가능한 작업을 얼마나 효율적으로 실행하는지 물을 수 있다. 목표가 하드웨어 비교일 때 이 구분은 중요하다.
또한 이는 제목이 내세울 수 있는 주장에 한계를 둔다. 라이브 의사결정을 제거한다는 것은 이 측정으로 특정 프로세서에서 모델이 더 잘 추론한다는 사실을 입증할 수 없다는 뜻이다. 더 짧은 재생 시간 역시 실제 운영 에이전트가 더 빨리 작업을 마친다는 것을 의미하지 않는다.
이 뉴스가 주목할 만한 이유는 측정 경계를 명시했기 때문이다. 에이전트 성능은 모델, 프로세서 또는 애플리케이션 중 하나에만 전적으로 속하는 단일 특성이 아니다. 각 계층이 기여하며, 각 계층에는 역할에 맞는 증거가 필요하다.
따라서 유용한 해석은 좁고 구체적이다. 이 프로토타입은 통제된 에이전트 워크로드에서 호스트 용량을 탐색한다. 그 용량이 더 나은 애플리케이션 성능을 예측하는지는 라이브 실행과의 비교가 필요한 별도 질문이다.
향후 결과가 공개되는 곳에서도 이 경계는 분명히 유지돼야 한다. 그렇지 않으면 신중하게 제한된 실험이 지나치게 광범위한 마케팅 주장으로 바뀔 수 있다.
하드웨어 구매자에게는 더 빠른 모델 이상이 필요하다
당장의 압박은 AI 성능 주장을 특정 워크로드와 연결해야 하는 하드웨어 공급업체와 구매자에게 가해진다.
컴퓨터는 질문에 답할 때와 소프트웨어 수정을 실행할 때 같은 작업을 수행하지 않는다. 후자는 로컬 프로그램, 파일, 검증을 포함할 수 있다. 모델만 평가하면 이러한 의존성은 측정 대상에서 벗어난다.
개발자에게 실질적인 문제는 실행 위치다. 원격으로 호스팅되는 모델도 로컬 머신에서의 작업을 지시할 수 있다. 테스트가 로컬에서 실행된다면 원격 서비스를 개선한다고 해서 테스트 단계가 자동으로 짧아지지는 않는다.
반대의 경우도 중요하다. 로컬 작업이 전체 작업 시간에서 차지하는 비중이 작다면 더 빠른 프로세서를 구매해도 체감 경험은 거의 달라지지 않을 수 있다. 유용한 벤치마크는 모든 에이전트 워크플로에 더 높은 호스트 성능이 필요하다고 가정하기보다 이러한 가능성을 드러내야 한다.
이는 프로세서 공급업체에 다른 입증 부담을 만든다. 에이전트에 적합하다는 일반적 주장은 어떤 작업이, 어떤 조건에서, 어떤 애플리케이션 이점과 함께 개선되는지 밝혀야 한다. 용량 측정만으로는 모든 부분에 답할 수 없다.
컴퓨터 제조업체도 관련된 문제에 직면한다. 이들은 목표 사용자층에 맞춰 어느 정도의 프로세서 성능, 메모리, 기타 리소스를 포함할지 결정해야 한다. 벤치마크는 동일한 구성에 또 다른 라벨을 붙이는 대신 이러한 요구를 구분하는 데 도움이 될 때 유용하다.
기업 구매자에게는 동시 작업이 또 다른 차원을 더한다. 동시성이란 여러 작업이 겹치는 기간 동안 활성 상태를 유지하는 것을 뜻한다. 단독으로는 작업을 무리 없이 처리하는 시스템도 동료나 백그라운드 작업이 리소스를 두고 경쟁할 때는 다르게 동작할 수 있다.
처리량, 즉 단위 시간당 완료되는 작업량은 이 차이의 일부를 포착한다. 지연 시간, 즉 개별 작업에 걸리는 시간은 또 다른 측면을 포착한다. 컴퓨터는 전체 작업량을 더 많이 처리하면서도 특정 사용자의 대기 시간을 늘릴 수 있다.
공유 개발 호스트의 예시는 이 차이를 명확히 보여 준다. 여러 에이전트가 별도의 테스트 스위트를 실행하는 동안 개발자들은 대화형 검색을 요청할 수 있다. 완료된 테스트 수를 극대화한다고 해서 검색 응답성이 반드시 유지되는 것은 아니다.
이 때문에 에이전틱 AI 처리량에는 명시된 서비스 요구사항이 필요하다. 허용 가능한 대기 시간의 정의가 없다면 가장 높은 완료율은 사용자에게 과부하로 느껴지는 구성을 보상할 수 있다.
지식 워크플로에서도 시간이 어디에 쓰이는지와 관련한 유사한 질문이 제기된다. searchable knowledge base를 구축하는 팀은 지연을 하드웨어 탓으로 돌리기 전에 문서 처리, 검색, 답변 생성을 구분해야 한다.
이 사례들은 프로토타입에서 측정된 결과가 아니라 구매 관련 질문을 설명한다. 그 가치는 향후 결과가 무엇을 설명해야 하는지 보여 주는 데 있다. 구매자에게는 통제된 점수와 자신들이 실제로 수행하는 작업을 연결하는 증거가 필요하다.
따라서 압박의 핵심은 즉시 프로세서 승자를 선언하는 데 있지 않다. 에이전트 성능 주장이 무엇을 약속하는지 더 명확히 설명하도록 요구하는 데 있다.
추론을 제거하면 호스트 측정은 쉬워진다
프로토타입의 동시성 스윕은 활성 워커 수를 늘리고 완료된 세션을 보고한다. 이는 최고 처리량과 더 느린 세션에 의해 제약되는 운영 지점을 구분한다. 고정된 재생 중에는 기록된 모델 응답이 GPU 추론 지연 없이 도착해, 그러한 속도 조절 없이 호스트에 작업을 제공한다.
추론을 제거하면 분리는 개선되지만, 작업이 프로세서에 도달하는 방식은 바뀐다.
이러한 상충 관계는 설계에서 직접 따라온다. 모델이 응답을 생성하는 데 시간을 쓰는 동안 호스트는 다른 작업을 마칠 기회를 얻을 수 있다. 응답이 즉시 반환되면 다음 행동이 준비되는 시점이 달라진다.
그 결과의 워크로드는 더 느린 라이브 모델이라면 결코 요구하지 않았을 용량을 드러낼 수 있다. 그렇다고 이 측정이 무의미해지는 것은 아니다. 이는 특정한 작업 공급 조건에서의 성능 측정이 된다.
한 가지 비유는 직원용 주문이 이미 준비된 주방을 시험하는 것이다. 이 실험은 주방이 얼마나 많은 음식을 만들 수 있는지 보여 줄 수 있다. 주문과 배달이 추가 지연을 유발할 때 손님이 얼마나 빨리 식사를 받을지는 독립적으로 입증할 수 없다.
에이전트 소프트웨어에서는 행동이 이전 결과에 의존하기 때문에 빠진 속도 조절이 중요하다. 테스트는 그 출력이 다음 의사결정에 활용되기 전에 끝나야 한다. 문서는 에이전트가 그 내용을 사용할 수 있기 전에 처리돼야 한다.
이러한 의사결정을 고정하면 비교에는 도움이 되지만, 타이밍 가정은 여전히 해석이 필요하다. 구매자는 벤치마크가 예상 부하와 닮았는지, 아니면 그 이상의 경계를 의도적으로 스트레스 테스트하는지 물어야 한다.
운영체제는 완료 횟수 이상을 검토해야 하는 또 다른 이유를 제공한다. Linux는 프로세서, 메모리, 입출력 리소스가 제한될 때 발생하는 중단을 추적하는 resource pressure 측정을 문서화한다. 이 문서는 경합을 지연 시간 급증 및 처리량 손실과 연결한다.
이러한 측정은 유용한 진단 맥락을 제공한다. 에이전트 워크로드가 느려진다면, 보조 증거는 프로세서 시간 경쟁과 메모리 또는 스토리지 대기를 구분하는 데 도움이 될 수 있다. 제목 점수만으로는 이를 구분할 수 없다.
이는 프로토타입이 이미 모든 진단 지표를 보고한다는 주장이 아니라 분석적 권고다. 더 넓은 요점은 호스트 용량이 여전히 시스템 특성이라는 것이다. 프로세서는 메모리, 스토리지, 소프트웨어 라이브러리, 운영체제 정책과 함께 작동한다.
따라서 공정한 하드웨어 비교에는 구성 투명성이 필요하다. 그렇지 않으면 독자는 겉보기의 프로세서 우위가 다른 구성 요소나 소프트웨어 설정에 의존하는지 판단할 수 없다.
프로세서 사양에 근거한 설명에도 같은 주의가 필요하다. 코어가 많으면 병렬 작업의 잠재력이 더 크다는 점을 시사하지만, 사양만으로 특정 워크로드가 어떻게 확장되는지는 입증되지 않는다. 측정이 그 간극을 메워야 한다.
Tom's Hardware CPU 벤치마크는 이 문제를 살피는 통제된 렌즈로서 가장 유용하다. 이는 호스트 한계에 관한 질문을 뒷받침할 수 있으며, 라이브 애플리케이션의 타이밍은 보완적인 실험에 맡긴다.
이러한 구분은 리뷰어에게 더 정확한 어휘를 제공한다. 모델이 만드는 지연과 실행 용량을 구분해 논의할 수 있으며, 둘을 구분되지 않은 AI 점수로 평면화하지 않아도 된다.
MLPerf와 에이전트 벤치마크는 서로 다른 질문에 답한다
중요한 비교는 어떤 벤치마크가 다른 것을 대체할 자격이 있는지를 겨루는 것이 아니라, 측정 목표 간의 비교다.
MLCommons는 MLPerf Client가 소프트웨어 엔지니어링과 데이터 분석을 포괄하는 에이전트 테스트를 제공한다고 설명한다. 해당 문서는 모델 추론과 도구 실행을 포함한 전체 작업 시간을 보고하며, 이 단계들 간의 세부 구분도 제공한다.
이 접근법은 완전히 구성된 시스템의 경험을 다룬다. 통제된 호스트 재생은 더 좁은 구성 요소 질문을 다룬다. 두 방법은 주제 면에서 겹치지만, 점수를 서로 대체 가능한 것으로 취급해서는 안 된다.
시스템 테스트는 구성이 더 빨리 끝난다는 사실을 보여줄 수 있지만, 그 이유를 완전히 설명하지는 못할 수 있다. 구성요소 테스트는 한 가지 이점의 원인을 명확히 할 수 있지만, 최종 애플리케이션 이점을 입증하지는 못한다. 함께 사용하면 하드웨어 리뷰를 더 유익하게 만들 수 있다.
MLCommons는 기본, 확장, 실험적 구성요소도 구분한다. 기능이 존재한다고 해서 모든 구성이나 결과가 자동으로 같은 위상을 갖는 것은 아니므로 이러한 라벨은 중요하다. 독자는 특정 워크로드에 부여된 상태를 확인해야 한다.
에이전트 역량 벤치마크는 또 다른 축을 도입한다. SWE-bench는 생성된 패치를 적용하고 리포지토리 테스트를 실행해 소프트웨어 변경 사항을 평가한다. 패치 평가 문서는 일관된 평가를 지원하도록 설계된 컨테이너화된 실행 방식을 설명한다.
따라서 SWE-bench는 유용한 대비를 제공한다. 실행 순서를 완료하는 일은 소프트웨어 문제를 해결하는 일과 다르다. 빠른 시스템도 유효한 결과가 필요하며, 유능한 에이전트도 작업을 실행할 환경이 필요하다.
개발 자동화에 관심 있는 구매자는 한 지표를 다른 지표의 대체물로 간주하지 않아야 한다. 역량과 실행 성능은 상호작용하지만, 어느 하나도 둘 모두를 대신할 수는 없다.
신뢰성은 또 다른 구분을 더한다. 원래의 도구 상호작용 벤치마크인 tau-bench는 도메인 도구와 정책 요구사항을 다루는 에이전트를 평가한다. 저자들은 최종 데이터베이스 상태를 의도한 결과와 비교하고, 반복 시험 전반의 일관성을 살핀다.
이 연구는 이 프로토타입에 대한 직접적인 비판이 아니라 방법론적 주의를 제공한다. 에이전트 서비스는 올바른 작업을 반복적으로 수행해야 한다. 고정된 경로를 재생하는 것만으로는 실제 모델이 그 경로를 안정적으로 선택할 것이라고 독립적으로 입증할 수 없다.
이러한 접근법은 서로 보완적인 유용한 질문들을 만든다. 에이전트가 과제를 해결하는가? 일관되게 해결하는가? 구성된 시스템은 작업을 얼마나 빠르게 실행하며, 어느 구성요소가 이를 제한하는가?
어느 하나를 배제할 필요는 없다. 실수는 이들의 답을 기계가 에이전트 작업에서 단순히 더 빠르다는 보편적 주장으로 압축하는 것이다.
리뷰어에게는 측정값 사이의 불일치를 설명할 기회가 있다. 한 시스템은 호스트 용량에 여유가 있어도 다른 곳에서 제한될 수 있다. 다른 시스템은 통제된 워크로드를 빠르게 마칠 수 있지만, 다른 작업 조합에서는 이점이 거의 없을 수 있다.
측정 경계가 명확하게 유지된다면 이는 해석 가능한 결과다. 서로 다른 테스트를 마치 같은 것을 측정하는 것처럼 제시할 때만 혼란스러워진다.
통제된 재생에도 현실성 검증이 필요하다
Tom's Hardware CPU 벤치마크는 여전히 프로토타입이며, 그 통제된 조건은 면밀한 검토가 필요하다. 해당 매체도 더 폭넓은 플랫폼 범위, 대화형 워크로드, 프레임워크와 관련된 한계를 인정하고 있다.
하드웨어 비교를 위해서는 재현 가능한 실행이 필요하지만, 재현성만으로 워크로드가 실제 운영 환경의 사용 사례를 대표한다는 사실이 입증되지는 않는다.
가장 강력한 회의적 질문은 선택된 경로에 관한 것이다. 기록된 순서는 각 시스템에 비교 가능한 작업을 제공하지만, 그 관련성은 해당 순서가 의도된 애플리케이션을 얼마나 잘 반영하는지에 달려 있다. 일관성은 부적합한 워크로드를 보완할 수 없다.
예시로 문서 작업을 생각해 볼 수 있다. 깨끗한 문서에서 텍스트를 추출하는 작업은 이미지 속 텍스트를 기계가 읽을 수 있는 문자로 변환하는 광학 문자 인식이 필요한 스캔본을 처리하는 작업과 다르다. 어느 사례에 더 비중을 둔 벤치마크인지에 따라 호스트 요구량은 다르게 나타날 수 있다.
같은 원칙은 소프트웨어 작업에도 적용된다. 작은 프로젝트를 검색하는 일과 더 큰 코드베이스를 빌드하는 일은 시스템에 서로 다른 요구를 부과한다. 일반적인 에이전트라는 라벨이 그러한 요구를 동등하게 만들지는 않는다.
따라서 독자는 종합 점수를 해석하기 전에 작업 구성을 살펴봐야 한다. 복합 결과에는 무엇이 결과에 기여하는지 보여줄 만큼 충분한 세부 정보가 필요하다. 그렇지 않으면 워크로드 조합은 보이지 않는 구매 가정이 된다.
정확성에도 같은 수준의 주의가 필요하다. 실제 도구가 예상치 못한 결과를 낸다면, 벤치마크는 유효한 실행과 빠르지만 유효하지 않은 실행을 구분해야 한다. 무효 실행을 설명 없이 제외하는 것 또한 실질적인 문제를 가릴 수 있다.
유용한 보고서는 성공한 측정값과 함께 실패한 실행도 공개할 것이다. 실패가 작업 동작, 구성, 리소스 제한, 또는 테스트 시스템 자체에서 발생했는지 설명해야 한다. 이러한 맥락이 남은 점수가 정상적인 운영을 나타내는지 결정한다.
반복 측정에도 명확한 시작 상태가 필요하다. 이전 작업에서 남은 파일과 기타 데이터는 이후 실행이 수행해야 할 작업을 바꿀 수 있다. 벤치마크는 새 실행, 반복 실행, 또는 명시된 조합 중 무엇을 측정하는지 설명해야 한다.
이는 평가 요건이지, 이 프로토타입이 이를 잘못 처리한다는 증거는 아니다. 그 목적은 독자가 공개된 수치를 하드웨어 선택에 사용하기 전에 무엇을 요구해야 하는지 정립하는 데 있다.
CPU 벤치마크라는 표현에는 또 다른 한계가 있다. 도구 실행은 스토리지와 다른 시스템 리소스에 의존할 수 있다. 이러한 의존성이 점수에 기여한다면, 독자는 모든 차이를 프로세서 탓으로 돌리지 않을 수 있을 만큼 충분한 정보를 얻어야 한다.
마찬가지로 상대적 응답성 임계값에도 맥락이 필요하다. 시스템은 자체 기준선 동작을 유지하면서도 절대적인 측면에서는 다른 시스템보다 더 오래 걸릴 수 있다. 기준선과 부하 상태의 성능 모두 중요하다.
바로 여기서 신중한 보도의 가치가 드러난다. 출처에서 특정 프로세서 제품군이 에이전트 워크로드 전반에서 우위에 있음을 입증하는 검증된 순위는 없다. 방어 가능한 결론은 제안된 방법과 여전히 필요한 증거에 관한 것이다.
재생은 범위, 유효성, 실제 워크로드와의 관계가 보일 때 구매 판단의 근거가 된다. 그 전까지 가장 큰 기여는 어려운 측정 문제를 더 구체적으로 만드는 데 있다.
재현, 실제 비교, 더 폭넓은 워크로드를 지켜보라
다음 이정표는 통제된 호스트 측정값을 독립적으로 이해할 수 있는 애플리케이션 동작과 연결하는 증거여야 한다.
향후 몇 달 동안 주목할 첫 번째 신호는 재현 가능한 워크로드 패키지 또는 그에 상응하는 수준의 방법론 공개다. 독자에게는 작업 정의, 소프트웨어 버전, 구성 세부 사항, 유효성 규칙, 점수 산출 방식에 대한 명확한 설명이 필요하다.
이는 발표된 출시 일정이 아니라 관찰 기준이다. 다른 팀이 동등한 조건에서 해당 동작을 재현할 수 있다면 측정에 대한 신뢰는 강화된다. 결과가 공개되지 않은 선택에 의존한다면 그 유용성은 제한적이다.
재현은 결과의 형태를 이해하는 일도 의미해야 한다. 독립 실행이 서로 다른 하드웨어 조건에서 동일한 수치를 낼 필요는 없다. 일치, 변동 또는 실패를 설명할 수 있을 만큼 충분한 증거를 제공해야 한다.
두 번째 신호는 고정된 재생과 실제 추론 간의 직접 비교다. 이는 모델이 작업 속도를 조절하는 역할을 다시 맡을 때, 측정된 호스트 용량이 완료 시간에 얼마나 영향을 미치는지 보여줄 것이다.
재생에서의 이점이 비교 가능한 실제 워크로드에서도 유지된다면, 해당 애플리케이션에 대한 관련성은 강화된다. 이점이 대부분 사라진다면 재생은 용량 분석에는 계속 유용하지만 업그레이드를 뒷받침하는 근거는 약해진다.
그러한 측정값 간의 차이 자체도 유익한 정보가 된다. 애플리케이션이 다른 곳에서 시간을 소비하고 있거나, 타이밍 변화가 경합을 바꾼다는 점을 보여줄 수 있다. 어느 결과든 구성요소 점수가 모든 것을 예측한다고 가정하는 것보다 더 유용하다.
세 번째 신호는 작업, 프레임워크, 시스템 구성 전반에 걸친 더 폭넓은 범위다. 더 강력한 증거는 결론이 유지되는 영역과 달라지는 영역을 보여줄 것이다. 보편적인 승자보다 워크로드 민감도에 대한 명확한 설명이 더 유익하다.
관련된 변형 전반에서 순위가 비슷하게 유지된다면, 더 넓은 적용 가능성에 대한 신뢰가 높아진다. 순위가 바뀐다면 독자는 실행하려는 작업에 하드웨어 선택을 더 밀접하게 맞출 이유를 얻게 된다.
구매자는 이러한 민감도를 벤치마크의 실패가 아니라 정보로 받아들여야 한다. 에이전트 소프트웨어는 다양한 활동을 포괄하며, 이러한 활동이 같은 시스템을 선호할 필요는 없다.
현재로서는 성능 주장에 붙는 질문을 개선하는 것이 합리적인 대응이다. 무엇이 로컬에서 실행됐는지, 무엇이 고정됐는지, 무효 실행을 어떻게 처리했는지, 그리고 측정 시간에 모델이 포함되는지 물어야 한다.
Tom's Hardware CPU 벤치마크를 구매 가이드로 받아들이기 전에, 자신의 워크플로를 제한하는 단계를 파악하라. 시간이 모델 응답, 문서 처리, 검색, 빌드 또는 검증 중 어디에 쓰이는지 기록하라. 그런 다음 향후 결과를 에이전트라는 라벨이 아니라 그 워크로드와 비교하라. 예상하는 부하에서 성공적인 완료와 대기 시간 모두를 요구하라. 통제된 재생은 유용한 용량을 드러낼 수 있고, 실제 비교는 그 용량이 사용자에게 도달하는지 보여준다. 이러한 측정값이 발전하는 과정에서 증거를 따라가고, 시스템이 반드시 끝내야 할 작업을 중심으로 구매 결정을 내려야 한다. 더 빠른 프로세서는 실제로 어느 단계를 단축할 수 있는가?
