EVO-X2 x Qwen3.8-Flash-Next 외전 4: 입력 문서와 로딩 속도의 관계 (실측편) - 로딩 속도가 최대 1.41배 차이 - Insights

지난 외전 3에서는 llama-bench에 랜덤 토큰뿐만 아니라 실문서를 입력할 수 있는 기능을 추가하여, 일본어 문서와 랜덤 토큰으로 PP(Prompt Processing)가 달라지는 것을 검증했습니다.

그 후, 공식(upstream) llama.cpp의 최신 정보를 확인했는데, 제11회에서 검증했던 MoE tile 선택 방식이 구 방식으로 돌아간 것과 그 외에도 신경 쓰이는 업데이트가 몇 가지 있어, 다시 한번 base인 llama.cpp를 교체하여 수정 전 속도를 측정하고, PLE16 변환 테이블 대응 및 QSA union의 고속화를 적용하여 측정하는 등 제11회와 동일한 절차를 반복했습니다.

(이때의 측정 결과는 이번 본론에서 벗어나므로 말미에 어메니티로 첨부합니다.)

지난번 base 교체 후 4일밖에 지나지 않아서, 앞으로 이것을 매번 반복하는 것이 괜찮은지에 대해 생각하고 있는 중이지만, 그것은 나중에 생각하기로 하고, 다음에는 어디부터 착수할까 고민하던 중, 외전 3에서 '직접 만든 고속화에 특별히 유리한 벤치마크로 측정하고 있는 것은 아닌가'라는 의심을 떠올렸습니다.

다음 고속화를 하기 전에 이곳을 정리해 두고 싶다는 생각으로 다시 한번 깊이 빠져들었습니다.

이후, Prompt Processing(입력을 읽어들이는 처리)를 PP, Token Generation(출력 생성)을 TG로 표기합니다. 둘 다 단위는 tok/s이며, 높을수록 빠릅니다.

이번에는 7가지의 입력을 사용하여 Vulkan (QSA union OFF / ON)과 ROCm의 PP 속도를 비교했습니다.

입력 문서가 다르면 PP 속도가 상당히 달라진다. - Vulkan은 컨텍스트 64k에서 최고/최저 차이가 약 1.21배, 128k에서 약 1.41배이며, ROCm은 64k에서 약 1.06배, 128k에서 약 1.04배로 Vulkan보다 차이는 작습니다.

Vulkan은 컨텍스트 64k에서 최고/최저 차이가 '직접 만든 고속화에 특별히 유리한 입력만으로 측정하고 있는 것은 아닌가'라는 의심은 일단 부정할 수 있었습니다.

반면에, 결과의 경향은 상당히 복잡했습니다.

Vulkan(QSA union ON)에서는 영어 기술 문서나 C/C++ 코드가 빨랐습니다.
Vulkan(QSA union OFF)에서는 C/C++ 코드가 가장 빨랐습니다.
ROCm에서는 랜덤 입력이 가장 빨랐으며, Vulkan과는 상당히 다른 순위가 되었습니다.
64k와 128k에서도 순위나 개선율이 바뀌었습니다.

즉, 이번 범위에서는 '이런 문서는 항상 로딩이 빠르다'라고 단순하게 말할 수는 없습니다. 다만, 입력 문서의 차이가 PP 속도에 영향을 미친다는 것 자체는 알게 되었습니다.

소스, Windows 빌드, 검증 스크립트 등은 여기서 공개하고 있습니다.

이번 작업은 r5/upstream-refresh-20261009에서 분기한 전용 브랜치로 진행하고 있습니다.

속도와 관련된 부분만 먼저 올립니다.

항목	내용
PC	GMKtec NucBox EVO-X2
...
이전에 제5회나 외전 1에서 일본어 출력 결과 비교를 했었는데, 문장 평가 기준을 만드는 것은 매우 어렵고, 그에 비하면 속도 측정은 객관적인 숫자가 나오기 때문에 평가가 쉽다고 생각했습니다.

하지만 실제는 그렇지 않았습니다. 입력 내용에 따라 속도가 다르다는 것은 알게 되었지만, 그럼 어떤 입력으로 테스트해야 할지 생각하니 의외로 어렵습니다.

이번에는 일반론은 접어두고, 제가 실제로 로컬 LLM에 입력하여 작업하게 하고 싶은 문서 종류로서

일본어 기술 문서
영어 기술 문서
C/C++ 소스 코드

의 3종류, 그리고 문서 종류에 따른 차이가 궁금해서

일본어 문학
영어 문학

의 2종류를 추가하여, 지금까지 사용하던 일본어 논문의 반복 문서와 llama-bench 본래의 랜덤 토큰 입력을 총 7가지 비교하기로 했습니다.

처음에는 공개 벤치마크에서 데이터를 가져올까 생각했지만, 저의 현재 로컬 LLM 용도로는 외부에 내보낼 수 없는 문서를 읽어 요약하거나 질문에 답하게 하는 것이 주력이고, 어려운 추론은 그렇게 필요하지 않습니다.

그래서 간단히 문서 전체를 읽게 하는 것으로 했습니다. 이번 테스트 데이터는 평소 사용하던 일본어 논문 외에는 지시문도 추가하지 않았습니다.

문서는 '일반 공개되어 누구나 접근할 수 있음'과 '1개 문서로 64 토큰 이상'이라는 조건으로 다음 것들을 선택했습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

분류	사용한 데이터	제작 방법・개요	전체 파일 token 수
일본어・기술	기계학습 입문	github 리포지토리에서 md 형식의 본문을 자체 스크립트로 통합	65,007
...
데이터가 완성되었으므로 바로 속도 측정을 해보았다. 이번에는 출력 내용을 보지 않기 때문에 warm-up이나 반복을 쉽게 할 수 있도록 llama-bench만 사용했다.

우선 Vulkan 버전을 가지고, 제11회에서 넣었던 QSA union 고속화 ON/OFF를 비교해 보았다.

제11회에서 넣었던 MoE tile 선택 구 방식은 이번에 교체한 upstream에서는 이미 대응되어 있었기 때문에, 이번에는 추가 이식이나 수동 설정은 하지 않았다.

64k의 경우, 실 문서 6종류 모두 원 파일의 시작부터 61,789 토큰을 읽게 했다. 랜덤 데이터는 llama-bench 표준 생성 토큰을 사용한다.

아래 수치에 붙은 **(1), (2)…**는 각 표의 각 수치 열에서 큰 순서대로의 순위이다. 예를 들어 272.362 (7)는 해당 열에서 7종류 중 7위를 의미한다.

ON 개선율이나 union 평균도 마찬가지로 큰 값부터 1위를 붙였기 때문에, **union 평균 1위는 'KV가 가장 많음'**을 의미하며, '가장 빠름'을 의미하는 것은 아니다.

입력	OFF tok/s	ON tok/s	ON 개선율
일본어・기술	299.235 (5)	366.032 (4)	+22.32% (2)
영어・기술	312.423 (2)	378.992 (1)	+21.31% (3)
C/C++ 코드	329.275 (1)	377.754 (2)	+14.72% (6)
일본어・문학	285.479 (6)	344.105 (5)	+20.54% (5)
영어・문학	304.394 (4)	368.631 (3)	+21.10% (4)
...	+5.09% (7)

평소에 사용하던 일본어 논문 반복 문서는 QSA union ON/OFF의 개선율이 가장 높았지만, 일본어 기술 문서, 영어 기술 문서도 비교적 높기 때문에 반복 때문인지는 알 수 없다.

속도의 순위를 보면,

QSA union OFF만으로 비교했을 때, 가장 빠른 것은 C/C++ 코드, 가장 느린 것은 일본어 논문 반복이다.
QSA union ON만으로 비교했을 때, 가장 빠른 것은 영어 기술 문서, 가장 느린 것은 랜덤이다.

QSA union ON/OFF의 개선율과, QSA union ON 시의 속도 순위와, QSA union OFF 시의 속도 순위가 모두 같지는 않다.

64k에서 최고/최저의 차이는,

QSA union OFF: 329.275 / 272.362 ≒ 1.21배
QSA union ON: 378.992 / 324.074 ≒ 1.17배

로, QSA union ON 쪽이 입력 간의 차이가 조금 줄어든다.

QSA union의 통계 진단 기능을 ON으로 설정하고, unique union과 padded union의 평균도 측정해 보았다. 이것은 속도 비교용이 아니라 내부 동작을 보기 위한 진단 값이다.

QSA union에 대한 설명과 통계 진단 기능의 구현에 대해서는 외전 3에 적었으므로, 여기서는 설명을 생략한다.

입력	Unique union 평균	Padded union 평균
일본어・기술	14,471.06 (5)	14,596.95 (5)
...	11,964.69 (7)
일본어・문학	19,225.61 (2)	19,352.74 (2)
영어・문학	15,424.84 (4)	15,552.09 (4)
일본어・반복	17,406.27 (3)	17,532.78 (3)
랜덤	24,562.67 (1)	24,688.34 (1)

64k의 unique union 평균(가로축)과 QSA union ON에서의 속도 개선율(세로축)

graph02_64k_unique_union_vs_gain_scatter.png

그래프 중 약어는 JA Tech=일본어 기술, EN Tech=영어 기술, JA Lit=일본어 문학, EN Lit=영어 문학, JA Repeat=일본어 반복, C/C++=C/C++ 소스코드, Random=랜덤

Unique union 평균과 QSA union ON에 의한 속도 개선율이 상관관계가 있는가 싶었는데, 그렇지 않았다. 랜덤 데이터만 극단적인 이상치처럼 보인다.

C/C++ 코드: unique union은 가장 작지만, 개선율은 **+14.72%**로 6위
일본어・반복문: unique union은 그보다 크지만, 개선율은 **+25.88%**로 1위
랜덤: unique union이 가장 커서, 개선율은 **+5.09%**로 최하위

다음으로 128k에서도 측정해 보았다. 일본어 기술 문서만은 원본 문서가 짧아서 128k에 부족했기 때문에 테스트에서 제외했다. 실제 문서는 맨 앞 126,253 토큰을 사용하고 있기 때문에, 64k와의 비교에는 KV 길이의 변화뿐 아니라 추가된 입력 내용의 차이도 포함된다.

입력	128k OFF tok/s	128k ON tok/s	ON 개선율
일본어・기술	— (대상 제외)	—	—
...	346.600 (1)	+46.78% (6)
일본어・문학	168.064 (6)	294.020 (5)	+74.95% (1)
영어・문학	204.938 (3)	335.141 (3)	+63.53% (3)
일본어・반복문	183.660 (4)	310.682 (4)	+69.16% (2)
랜덤	170.615 (5)	261.673 (6)	+53.37% (5)

64k에서는 개선율이 +5~~26%였던 것에 비해, 128k에서는 **+47~~75%**로 급격히 커졌다.

128k의 최고/최저 차이는,

QSA union OFF: 236.129 / 168.064 $allingdotseq$ 1.41배 - QSA union ON: 346.600 / 261.673 $allingdotseq$ 1.32배

로, 64k보다 상당히 크다.

특히 QSA union OFF에서는 C/C++ 최고 속도와 최저 속도의 일본어 문학 간 차이가 **약 40.5%**나 난다.

128k의 통계 데이터는 특징의 차이가 명확한 3가지 종류만 가져와 보았다.

입력	128k Unique union 가중 평균
일본어・기술	— (미측정)
...
128k, 16k 폭의 KV 구간별 unique union 가중 평균 가로축은 각 KV 구간의 중점

graph05_128k_unique_union_kv_bin_trend.png

128k에서도 순서는 코드 < 문학 < 랜덤을 유지했다.

이번 128k 진단 데이터를 KV 구간별로 살펴보면, 코드의 unique union 평균은 32–48k 구간의 12,487에서 48–64k 구간의 10,941까지 감소했다. 128k까지 계속 줄어들까 싶었지만, 실제로는 그 이후 다시 증가하고 있었다. 즉, '코드는 후반으로 갈수록 점점 작아진다' 같은 단순한 이야기는 아니었다.

64k와 128k에서 ON 개선율, OFF 시 속도, ON 시 속도의 순위가 뒤섞여서 점차 혼란스럽다. 대략적으로 보면 이번 데이터에서는

문서 종류로 보면
소스 코드 > 기술 문서 > 문학 - 언어별로 보면
프로그래밍 언어 > 영어 > 일본어

라는 경향이 있는 것 같다.

영어와 일본어는 같은 내용의 번역이 아니기 때문에 엄밀한 비교는 아니다.

이번에 사용된 영어 기술 문서와 일본어 기술 문서는 둘 다 정보 처리 분야의 것이지만, 본문 중에 수식이나 소스 코드 예시가 섞여 있다. 반면, 일본어 논문 반복문은 자연어 처리 분야의 것으로, 수식이나 소스 코드는 거의 나오지 않는다.

따라서, 일본어 논문 반복문과 일본어 기술 문서 간의 차이 원인이 반복 여부인지, 수식이나 소스 코드 비율인지, 아니면 그 외 내용상의 차이인지는 아직 잘 알 수 없다.

하지만 지금까지의 측정 결과로써, 처음에 걱정했던 '직접 만든 고속화가 특별히 유리한 벤치마크에서 측정하고 있는 것이 아닌가'라는 의심은 일단 부정할 수 있었다고 생각한다.

위의 결과가 Vulkan 특유의 것인지, ROCm에서도 같은 경향인지 궁금해서 ROCm으로도 측정하여 Vulkan과 비교해 보았다. 이쪽 Vulkan 란은 ROCm 대조용으로 다시 측정한 수치를 사용했기 때문에, 전 절의 Vulkan 최초 측정표와 일부 값이 약간 다르다.

입력	Vulkan OFF	Vulkan ON	ROCm
일본어・기술	299.24 (5)	366.03 (4)	397.65 (5)
영어・기술	312.42 (2)	378.99 (1)	398.78 (4)
C/C++	329.47 (1)	378.01 (2)	394.67 (6)
일본어・문학	285.48 (6)	344.11 (5)	404.03 (3)
영어・문학	304.39 (4)	368.63 (3)	405.36 (2)
...
64k Vulkan QSA union ON, OFF, ROCm의 입력별 PP 속도 비교표

graph03_pp_compare_64k_vulkan_rocm_checked.png

그래프 중 약어는 JA Tech=일본어 기술, EN Tech=영어 기술, JA Lit=일본어 문학, EN Lit=영어 문학, JA Repeat=일본어 반복, C/C++=C/C++ 소스코드, Random=랜덤

ROCm의 경우 Vulkan만큼 입력 차이에 따른 PP 차이가 크지 않다. 게다가 순위가 상당히 다르다.

Vulkan QSA union OFF에서는 C/C++ 코드가, Vulkan QSA union ON에서는 영어 기술 문서가, ROCm에서는 랜덤이 가장 빨랐다.

64k의 최고/최저 차이는,

Vulkan QSA union OFF:
약 1.21배 - Vulkan QSA union ON:
약 1.17배 - ROCm: 415.82 / 394.03 $allingdotseq$
약 1.06배

속도 자체는, 64k에서는 ROCm이 전체 7개 입력에서 Vulkan 양 모드보다 빨랐다.

입력	Vulkan OFF	Vulkan ON	ROCm
일본어・기술	—(대상 제외)	—	—
...	346.60 (1)	296.08 (6)
일본어・문학	168.06 (6)	294.02 (5)	301.54 (3)
영어・문학	204.94 (3)	335.14 (3)	302.22 (2)
일본어・반복	183.66 (4)	310.68 (4)	296.27 (5)
랜덤	170.62 (5)	261.67 (6)	308.22 (1)

128k Vulkan QSA union ON, OFF, ROCm의 입력별 PP 속도 비교표

graph04_pp_compare_128k_vulkan_rocm_checked.png

ROCm 128k의 최고/최저 차이는, 308.22 / 296.08 $allingdotseq$ 약 1.04배.

Vulkan OFF의 약 1.41배, Vulkan ON의 약 1.32배와 비교하면 상당히 차이가 작다.

그리고, Vulkan에서는 느렸던 랜덤이 가장 빠르고, 소스 코드가 가장 느리며, 기술 문서보다 문학 쪽이 빠르다는 Vulkan과는 정반대의 결과가 나타났다.

속도 자체는, 128k에서는 6개 입력 중 4곳에서 Vulkan QSA union ON이 ROCm보다 빨랐다.

이 부분을 보면, 입력 의존성은 '모델과 입력'만으로 결정되는 것이 아니라 백엔드 구현체와도 상당히 관련되어 있는 것 같다.

이후에 Vulkan의 QSA union OFF, 즉 upstream 그대로에 가까운 상태에서, 입력에 따른 차이가 매우 크고 C/C++ 코드가 가장 빠르며 일본어 문학이 가장 느리고, 랜덤은 가장 빠르지도 가장 느리지도 않다는 점이 궁금해서 깊게 파고들게 되는데, 내용이 길어져서 그 이야기는 다음 검증 편으로 미루겠다.

7가지 종류의 문서로 PP 속도를 비교해 본 결과, Vulkan의 QSA union OFF, QSA union ON, ROCm 모두 경향이 달라서 '이런 문서는 로딩이 빠르다'라고 단순하게 말할 수 없다는 것을 알게 되었다.

하지만, 입력 문서에 따라 로딩 속도가 다르다는 것은 확실하며, 특히 Vulkan에서 그 경향이 크다.

최근에는 하드웨어 구성에 따라 모델이나 설정을 자동으로 조정해 주는 추론 엔진이 유행하고 있는데, 하드웨어 구성뿐만 아니라 입력 문서의 유형이나 샘플을 전달하면 그것에 맞춰 백엔드나 설정을 자동 조정해 주는 것이 있으면 편리할 것 같다.

이번에는 '직접 만든 속도 향상에 특별히 유리한 벤치마크로 측정하는 것은 아닌가'라는 의심은 부정할 수 있었다. 지난번과 달리, 당초의 목적은 달성했다 (웃음)

다음으로 이어서 검증편을 진행하며, 특히 Vulkan QSA union OFF에서 나타난 입력 차이에 초점을 맞춰 GPU 프로파일러나 진단 로그까지 사용하여 원인을 깊이 파헤칠 예정입니다. ROCm 측의 입력 차이가 작은 이유는 계속해서 별도의 조사 과제로 남게 됩니다.

본문 초반에 작성했던 '업스트림(upstream)을 교체하고 다시 측정'한 결과를 적어두겠습니다. 이는 7가지 종류의 입력을 비교한 표와는 다른 측정으로, 평소 사용하던 일본어 논문 반복 문서를 llama-cli로 읽게 한 결과입니다.

① 업스트림 교체 직후 (Unsloth Original 모델, MTP OFF)

Context	Vulkan PP	Vulkan TG	ROCm PP	ROCm TG
64k	269.24	25.31	390.73	21.18
...

각 셀을 1회 측정했습니다. 이 측정을 하기 전에 Windows를 26H2로 업데이트했기 때문에, 지난번 교체했을 때의 업스트림 측정 결과와의 차이를 모두 업스트림 변경에 돌릴 수는 없지만, 지난번 교체 시점(제11회)의 업스트림 그대로의 측정 결과와 비교했을 때 PP와 TG 모두 조금씩 빨라지고 있습니다.

② PLE16 변환 모델 적용 후 (64k)

Backend	Original PP	PLE16 PP	Original TG	PLE16 TG
Vulkan	269.30	270.65	25.42	25.90
ROCm	389.78	389.01	21.18	21.15

Original과 PLE16의 로딩 및 추론에 성공했으며, 적용 전과 비교했을 때 PP와 TG 모두 큰 차이는 없었습니다.

③ QSA union 도입 후 (Vulkan만)

모델	Context	QSA union OFF PP	ON PP	ON PP 개선율	TG OFF / ON
Original	64k	270.74	341.94	+26.30%	25.58 / 25.89
...

업스트림을 교체한 후에도, QSA union은 계속해서 속도 향상에 효과적임이 밝혀졌습니다.

이는 지금까지 측정에 사용해 온 데이터와 기본적으로 동일합니다.

건효사(乾孝司)・오쿠무라 마나부(奥村学) 「텍스트를 대상으로 한 평가 정보 분석에 관한 연구 동향」 (『자연어 처리』 Vol.13, No.3, 2006년, pp.201–241)

이 논문의 언어 처리 학회 논문지 LaTeX 코퍼스에 수록된 LaTeX 소스에서 제3장의 일부를 9,406자 및 14,874자로 잘라내고, 2가지 종류의 블록을 반복하여 필요한 길이의 일본어 문서를 만들었으며, 앞뒤에 지시문을 추가했습니다.

지금까지 llama-cli로 측정할 때는 64k용(d7), 128k용(d15), 256k용(d31)의 입력 파일을 사용했지만, 이번 7가지 비교에서는 256k용 nlp-survey-ch3-d31-b1.txt로 통일했으며, 다른 문서와 마찬가지로 앞에서부터 필요한 토큰 수를 잘라냈습니다.

따라서, 이번 64k와 128k 측정에서는 끝부분의 지시문은 로드되지 않았습니다.

출처: 아오조라 문고 『吾輩は猫である』
가공: 다운로드한 텍스트 파일이 문자 코드가 SJIS였기 때문에 UTF-8로 변환함
출처: Project Gutenberg #1184, The Count of Monte Cristo(몽테 크리스토 백작) - 가공: 다운로드한 텍스트를 그대로 사용
출처: 심층 학습 입문
가공: github 리포지토리에서 소스 zip 파일을 다운로드 및 압축 해제하고, 목차 데이터를 참고하여 각 장의 markdown 파일을 통합하는 python 스크립트를 직접 제작하여 1개 파일로 통합함
출처: Dive into Deep Learning 영어판 v1.0.3
가공: github 리포지토리에서 소스 zip 파일을 다운로드 및 압축 해제하고, 목차 데이터를 참고하여 각 장의 markdown 파일을 통합하는 python 스크립트를 직접 제작하여 1개 파일로 통합함
출처: ggml-org/llama.cpp
가공: 이번 베이스에 사용된 de7fa0a3c6a2e1b4cd9f22eb8d6bf5b12dbdb63b 소스에서, 직접 제작한 스크립트로 추론 관련 코드를 추출하여 1개 파일로 통합함
llama-bench 표준의 랜덤 토큰 입력을 사용합니다. 실제 문서 파일은 없습니다.

64k에 해당하는, PP(Prompt Processing)만 측정하는 예시입니다. -f는 입력 파일을 지정하고, -p가 처리할 토큰 수를 의미합니다. 다음 예시는 64k 입력에 필요한 길이만큼의 소스 파일을 사용합니다.

.\\\llama-bench.exe \
-m "(메인 모델 경로)" \
-f "(충분히 긴 실제 문서 파일 경로)" \
...

랜덤 입력을 측정할 때는 -f와 --prompt-slice를 제외합니다. 128k의 경우 -c 131072 -p 126253으로 변경합니다.

이것은 제가 수정한 것이므로, 공식 llama-bench에 같은 옵션이 있다는 의미는 아닙니다. 수정된 소스는 github 리포지토리에 있습니다.

Device: NucBox EVO-X2
CPU / APU: AMD Ryzen AI MAX+ 395 with Radeon 8060S
CPU clock displayed by Windows: 3.00 GHz
Installed memory: 128GB
UMA Frame Buffer: 96GB
Windows CPU 측에서 보이는 RAM: 약 32GB
GPU: AMD Radeon 8060S Graphics
GPU arch:
gfx1151
OS: Windows 11 Pro
Version: 26H2 (r5 측정 시)
OS Build: 26300.9550
Update: KB5121794 (2026-10-08, r5 측정 전)
Windows Feature Experience Pack: 측정 자료에서 미확인
Upstream repository: ggml-org/llama.cpp
r4 upstream pin: de7fa0a3c6a2e1b4cd9f22eb8d6bf5b12dbdb63b

Vulkan:

Compiler: LLVM / Clang 20.1.8
Vulkan SDK: 1.4.357.0

ROCm:

ROCm: 10.0.0 / TheRock
Compiler: AMD Clang 23.0.0
Host toolchain: Visual Studio 2022 Build Tools / MSVC 14.44
GPU target:
gfx1151
Repository:
unsloth/Qwen3.8-Flash-Next-GGUF
URL: https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF
Quantization:
UD-IQ3_XXS
File size reported by llama.cpp: 76.32 GiB
BPW: 3.71
Model params: 176.94B

상기 모델을 LaurentZuijdwijk의 Strix Halo 전용 fork 내에 있는 gguf-py exttt{gguf} exttt{scripts} exttt{gguf_split_ple_heads.py}로 변환한 PLE16 모델을 사용했습니다.

EVO-X2 x Qwen3.8-Flash-Next 외전 4: 입력 문서와 로딩 속도의 관계 (실측편) - 로딩 속도가 최대 1.41배 차이

요약

핵심 포인트

댓글