3D 제품 모델 파일 크기: 휴대폰이 실제로 불러오는 무게

3D 제품 모델 파일 크기가 5MB를 넘으면, 구매자가 휴대폰으로 여는 제품 페이지에는 이미 너무 무겁습니다. 중급 안드로이드 기기와 평범한 모바일 회선에서 버티는 무게는 2MB 안팎입니다. 이유는 취향이 아니라 산수입니다. 5Mbps에서는 1MB마다 1.6초를 기다린 뒤에야 뷰어가 첫 프레임을 그릴 수 있습니다.

이 숫자를 받아들이면 논의의 성격이 달라집니다. 대부분의 공급업체는 3D 모델을 마케팅 자산으로 보고 파일 크기를 3D 스튜디오의 문제로 넘깁니다. 구매자에게는 페이지를 열자마자 가장 먼저 내려받는 파일일 뿐입니다. 아래는 무게 예산표, 바이트가 실제로 사라지는 네 곳, 그리고 견적 메일에 3D 링크를 붙이기 전에 실행할 여섯 가지 점검입니다.

3D 제품 모델 파일 크기 표: 휴대폰이 가장 먼저 내려받는 것

다운로드 시간은 파일 크기 × 8 ÷ 회선 속도입니다. 렌더링도, 회전도, 첫 프레임도 이 식에 없습니다. 아래 표는 회선이 안정적이라고 가정하고 TLS 핸드셰이크와 왕복 지연은 계산하지 않았습니다. 실제 휴대폰은 표보다 느립니다.

모델 크기	10 Mbps	5 Mbps	1.6 Mbps	기다리는 동안 구매자가 하는 일
2 MB	1.6초	3.2초	10초	모델을 돌려 보고 사양 한 줄을 읽음
5 MB	4초	8초	25초	스크롤해서 지나가거나 정지 이미지를 누름
10 MB	8초	16초	50초	페이지가 고장 났다고 판단
20 MB	16초	32초	100초	탭을 닫음
50 MB	40초	80초	250초	모델을 아예 보지 못함

50MB 행을 다시 보십시오. 사무실의 좋은 회선에서도 13초, 창고나 전시장, 호텔의 약한 모바일 회선에서는 4분이 넘습니다. 이 정도 크기의 모델은 홍보 자산이 아니라 구매자가 동의하지 않은 파일 전송입니다.

3D 제품 모델은 구매자가 제품 전체를 다 내려받기 전까지 제품의 어떤 부분도 볼 수 없는 유일한 상품 자산입니다. 사진은 위쪽부터 점진적으로 표시되고, 동영상은 몇 초만 버퍼링하면 재생이 시작됩니다. GLB는 시작되지 않습니다.

모델 전체가 먼저 도착해야 하는 이유

glTF 2.0 명세는 이 형식이 스트리밍 형식이 아니라고 분명히 밝힙니다. 바이너리 데이터 자체는 스트리밍이 가능하지만, glTF는 스트리밍 구조를 정의하지 않습니다. 따라서 뷰어는 자산을 불러오고, 해석한 뒤, 렌더링합니다. 제품처럼 보이는 중간 상태는 없습니다.

컨테이너 선택도 여기에 영향을 줍니다. GLB는 JSON 장면 설명과 바이너리 버퍼를 한 파일로 묶고 base64 팽창도 없어서 요청 한 번으로 효율적이지만, 구매자는 패키지 전체를 기다립니다. .gltf와 .bin, 개별 텍스처로 나누면 뷰어가 조각을 따로 가져와 더 일찍 시작할 수 있지만 요청이 늘고 실패 지점도 늘어납니다. 단일 SKU 제품 카드에는 GLB 하나가 보통 정답이고, 60개 SKU 시리즈에서는 공통 자산을 분리한 쪽이 총 용량이 더 작은 경우가 많습니다.

이런 사정은 성능 리포트의 이미지 항목에 나타나지 않아 놓치기 쉽습니다. 제품 페이지의 LCP 요소는 보통 대표 이미지나 텍스트 블록이고 WebGL 캔버스가 아닙니다. 구글의 기준은 75백분위에서 LCP 2.5초 이하입니다. 뷰어 스크립트와 모델 다운로드가 대표 이미지와 대역폭을 다투면 페이지는 이 기준을 놓치는데, 3D 팀은 "모델은 정상적으로 렌더링된다"고 보고합니다.

페이지의 나머지는 이미 얼마나 무거운가

Web Almanac이 인용한 2024년 HTTP Archive 데이터에 따르면 데스크톱 페이지 중앙값은 2,312KB, 모바일 페이지는 2,037KB입니다. 모바일에서는 이미지만 중앙값의 약 900KB를 차지합니다.

모델을 옆에 놓고 비교해 보십시오.

자산	일반적인 무게	모바일 페이지 중앙값(2,037KB) 대비
모바일 페이지 전체	약 2MB	1배
2MB GLB	2MB	페이지 두 배
5MB GLB	5MB	페이지 전체의 2.5배
20MB GLB	20MB	페이지 전체의 10배

예산은 이렇게 정합니다. 3D 뷰는 갤러리, 사양표, 리뷰, 추적 스크립트, 테마가 함께 있는 페이지의 한 요소일 뿐입니다. 모델 하나가 페이지 중앙값보다 크면 모델이 곧 페이지가 되고, 구매자는 초 단위로 비용을 치릅니다.

날씨, 전시장 와이파이, 기기도 이 문제를 키웁니다. 3년 된 중급 기기는 파일을 승인할 때 쓰던 노트북보다 4096픽셀 텍스처를 훨씬 느리게 처리합니다. 스튜디오 모니터가 아니라 휴대폰에서 확인하십시오.

바이트는 어디로 사라지고, 어떤 압축이 어디를 고치는가

3D 제품 모델 파일 크기는 세 곳에 집중됩니다. 보통 많은 순서로 텍스처, 지오메트리, 그 외(애니메이션, 카메라, 불필요한 노드)입니다. 의외로 지오메트리가 주범이 아닌 경우가 많습니다. 사진에서 만든 모델에 4096 × 4096 PNG 텍스처 하나를 붙이면 감싸는 메시보다 무거워질 수 있습니다.

부분	무엇이 키우는가	실제로 줄이는 방법
텍스처	4096px PNG, 쓰지 않는 노멀·러프니스 맵, 내장 색상 프로파일	뷰어가 표시하는 크기에 맞춘 작은 이미지, JPEG 또는 KTX2, 재질이 쓰지 않는 맵 삭제
지오메트리	스캔·세분화로 수백만 폴리곤이 된 메시, 중복 부품	보이는 디테일까지 감면, 반복 부품 인스턴싱, Draco 지오메트리 압축
그 외	아무도 재생하지 않는 애니메이션, 숨은 노드, 카메라, 조명	뷰어에 필요 없는 것 삭제. 제품 턴테이블에는 카메라 한 대면 충분

압축의 중심에는 Khronos가 승인한 두 확장이 있고, 각각 다른 문제를 풉니다. KHR_draco_mesh_compression은 원시 정점 데이터 대신 압축된 지오메트리를 전송합니다. KHR_texture_basisu는 KTX2와 Basis Universal 슈퍼압축으로 텍스처를 저장해 전송량과 GPU 메모리를 함께 줄입니다.

둘 다 확장이며 glTF 기본 기능이 아닙니다. 뷰어가 지원해야 하고, 비압축 폴백이 없으면 extensionsRequired에 선언해야 합니다. 보내기 전에 구매자가 실제로 쓸 뷰어에서 파일을 열어 보십시오. 제품 카드, 자사 웹사이트, 마켓플레이스의 3D 슬롯입니다. Blender에서 열린다는 사실은 휴대폰 브라우저에서 문제없다는 증거가 아닙니다.

3D 제품 뷰 링크를 보내기 전 여섯 가지 점검

순서대로 실행하십시오. 처음 두 개가 대부분의 손실을 막고, 나머지 네 개가 고객 문의로 돌아오는 실패를 막습니다.

파일이 웹용으로 내보낸 단일 .glb이며, 텍스처가 흩어진 .blend·.step·.obj가 아님
이 .glb가 구매자의 실제 회선에 맞는 무게 예산 안에 있음
정지 이미지가 먼저 로드되고, 구매자가 누르거나 스크롤해 도달한 뒤에 뷰어가 시작됨
한 손가락으로 회전, 핀치로 확대되며 모델이 튀거나 경계를 넘어가지 않음
실루엣, 부품 수, 철물이 제품 및 치수 도면과 여전히 일치함
WebGL을 못 쓰거나 사내 정책으로 막힌 구매자도 사진과 사양표를 볼 수 있음

점검 1: 웹 내보내기 파일이지 작업 파일이 아니다

.blend나 .step은 제작 문서입니다. 히스토리, 카메라, 재질을 담고 있고 어느 직원 노트북 폴더의 텍스처를 참조하기도 합니다. 웹 컨테이너는 GLB이며, 장면에는 제품 하나, 카메라 하나, 뷰어가 읽을 수 있는 재질만 들어가야 합니다. 내보내기 대화상자가 "모디파이어 적용", "숨은 객체 포함"을 물으면 전자는 예, 후자는 아니오입니다.

모델의 원본 사진도 똑같이 중요합니다. 각도와 조명이 다른 사진을 섞어 만든 모델은 구매자가 돌리는 순간 이음매가 드러납니다. 사진 세트가 엇갈리면 제품 페이지가 무너지는 것과 같은 이치입니다. 사진 세트가 아직 준비되지 않았다면 내보내기 전에 3D 제품 뷰에 필요한 사진부터 확인하십시오.

점검 2: 무게는 구매자의 회선에 맞춘다

내보낸 파일을 열어 MB 단위의 3D 제품 모델 파일 크기를 읽고 위 표와 비교하십시오. 반드시 내보낸 파일을 보고, 원본 프로젝트는 보지 않습니다. 40MB 작업 파일이 3MB로 나올 수 있고, 3MB 작업 파일이 텍스처를 묶어 30MB가 될 수도 있습니다.

예산을 넘으면 가장 큰 부분부터 고칩니다. 4096픽셀 PNG 네 장을 1024픽셀 JPEG 한두 장으로 바꾸는 편이 지오메트리를 건드리는 것보다 효과가 큰 경우가 많습니다. Draco와 KTX2는 그다음입니다. 합리적인 자산을 작게 만드는 도구이며, 터무니없이 무거운 자산을 허용 범위로 바꿔 주는 도구가 아닙니다.

점검 3: 첫 프레임은 포스터 이미지, 빈 캔버스가 아니다

뷰어를 지연 로드하고 구매자가 조작할 때까지 정지 이미지(가능하면 모델 초기 각도와 같은 구도)를 보여 주십시오. 3D 캔버스가 핵심 경로에서 빠지고 페이지에는 진짜 LCP 후보가 생깁니다.

다음으로 자주 실패하는 지점은 상호작용입니다. 구글의 Interaction to Next Paint 기준은 75백분위에서 200밀리초 이하가 양호, 500밀리초 초과가 나쁨입니다. 무거운 모델에 물리 엔진과 그림자 패스가 더해지면 페이지 로딩이 빨라도 중급 기기에서는 탭 후 회전이 이 선을 넘습니다.

점검 4: 엄지 하나로 돌아간다

한 손으로 휴대폰을 들고 엄지로 모델을 돌려 보십시오. 손가락 두 개가 필요하거나, 손을 떼면 모델이 저절로 흘러가거나, 확대할 때 회전 중심이 어긋나면 구매자는 제품이 아니라 뷰어와 싸우게 됩니다.

가장자리도 확인하십시오. 윗면, 바닥, 뒷면입니다. 회전을 ±45도에서 막는 뷰어는 구매자가 가장 보고 싶은 면, 즉 촬영 스튜디오가 절대 찍지 않는 면을 숨깁니다.

점검 5: 형태가 여전히 제품과 일치한다

모델을 실물과 치수 도면에 대고 돌려 보십시오. 실루엣, 철물, 이음매, 판재 모서리 두께를 봅니다. 이어서 구매자가 확인할 부분, 즉 경첩, 발, 손잡이, 몰딩 단면을 봅니다.

사진을 3D로 바꾸는 것은 프레젠테이션 단계이지 측정 단계가 아닙니다. 모델은 곡선을 부드럽게 다듬을 수 있지만, 손잡이를 새로 만들거나 이음매를 지우거나 도면에 적힌 비율을 바꿔서는 안 됩니다. 모델과 도면이 어긋나면 도면이 우선이며 모델을 다시 만듭니다.

여기서 두 산출물이 서로 정직해야 합니다. 회전하는 모델은 형태와 부품이 만나는 방식을 보여 주고, 측정 치수를 넣은 도면은 숫자를 보여 줍니다. 측정한 치수를 사진에 고정하고 같은 소스에서 회전 모델을 만드는 소프트웨어라면 두 뷰가 어긋나지 않습니다. 치수는 주석 위에 남아 구매자가 읽을 수 있고, 렌더링 안에 묻혀 아무도 측정할 수 없는 상태가 되지 않습니다.

점검 6: 볼 수 없는 구매자에게도 대안이 있다

기업 노트북은 WebGL을 막고, 일부 브라우저는 기본으로 꺼 두며, 오래된 기기는 큰 텍스처에서 메모리가 부족해집니다. 어느 경우든 구매자는 정지 이미지, 사양표, 문의 버튼에 도달할 수 있어야 합니다.

폴백은 계획이 아니라 페이지에 적으십시오. WebGL을 쓸 수 없을 때 빙글빙글 도는 회색 상자를 보여 주는 것은 뷰어가 없는 것보다 나쁩니다. 구매자는 제품 페이지가 고장 났다고 믿게 됩니다.

3D 뷰가 증명할 수 있는 것과 없는 것

3D 제품 뷰는 프레젠테이션 자산입니다. 형태, 비율, 부품 간 관계를 전달하며 측정 기록이 아닙니다. 화면에서 보이는 크기는 카메라, 화각, 구매자 화면에 따라 달라지므로 구매자가 치수를 읽을 수 없고, 공급업체도 읽을 수 있다고 암시해서는 안 됩니다.

이 문장은 페이지에 직접 쓰는 것이 좋습니다. "치수는 실측값, 3D 뷰는 형태만 표현"이라고 적으면 이 과정에서 가장 비싼 오해를 막을 수 있습니다. 구매자가 모델을 치수가 들어간 도면으로 믿고 그것에 맞춰 주문하는 사고입니다.

구매자의 질문	답하는 것	답하지 못하는 것
"폭이 정확히 1200mm인가요?"	사진에 치수를 넣은 사양 도면	아무리 정교한 3D 렌더링도 불가
"뒷면은 어떻게 생겼나요?"	3D 뷰 또는 뒷면 사진 세트	앞면만 있는 갤러리
"우리 집 문을 통과하나요?"	문 폭과 최소 포장 치수	화면에서 마음대로 확대되는 모델
"다리는 어떻게 고정하나요?"	분해 도면 또는 다리를 분리한 3D 뷰	잘 찍은 연출 컷 한 장

3D가 그 무게를 감당할 가치가 없을 때

3D가 모든 구매자 질문의 기본 답은 아닙니다. 모든 형식을 한 페이지에 올리면 맞는 하나만 올리는 것보다 느립니다. 다음 판단 기준을 쓰십시오.

구매자의 진짜 질문	더 가볍고 충분한 자산	3D를 쓰는 조건
"옆에서 보면 어떤가요?"	360도 사진 시퀀스 또는 네 각도 사진 세트	프레임을 넘기는 대신 자유롭게 돌려야 할 때
"얼마나 큰가요?"	사진에 치수를 넣은 사양 도면	절대 아님. 3D로는 답할 수 없음
"어떻게 분해되나요?"	번호가 붙은 분해 도면	조립 순서 자체가 판매 포인트일 때
"마감이 맞나요?"	같은 조명에서 찍은 매크로 사진	절대 아님. 텍스처는 색상 증거가 아님

"어떤 형식을 보낼까"만 문제라면 실제 선택은 3D 뷰와 사진 시퀀스 사이이고, 3D와 아무것도 보내지 않기 사이가 아닙니다. 판단 기준은 파일 무게, 상호작용, 구매자가 필요한 조작 자유도입니다. 3D 제품 뷰어와 360도 사진 비교에서 이 구분을 더 자세히 다룹니다.

3D가 자리를 얻을 가치가 있다면 보이는 곳에 두십시오. 측정 치수 옆에서 함께 열리는 3D 제품 뷰를 구매자가 사내로 전달하는 제품 카드에 넣는 편이, 카탈로그 세 번 클릭 뒤에 숨은 뷰어보다 훨씬 유용합니다.

자주 묻는 질문

웹사이트의 3D 제품 모델은 얼마나 커야 하나요?

5MB 이하, 구매자가 휴대폰으로 열 가능성이 높다면 2MB 이하입니다. 상한은 취향이 아니라 산수에서 나옵니다. 5Mbps에서 5MB 모델은 첫 프레임까지 8초가 걸리고, 뷰어 자바스크립트 실행 시간은 아직 포함되지 않았습니다. 원본 프로젝트가 아니라 내보낸 GLB로 확인하십시오.

3D 모델이 제품 페이지를 느리게 만드나요?

그렇습니다. 보통 두 곳에서 느려집니다. 다운로드가 대표 이미지와 대역폭을 다투어 Largest Contentful Paint를 구글의 2.5초 양호 기준 밖으로 밀어냅니다. 이어서 뷰어 자바스크립트가 메인 스레드를 차지해 상호작용 지연을 INP 200밀리초 기준선으로 밀어냅니다. 플레이스홀더가 아니라 모델을 실제로 올린 상태에서 PageSpeed Insights로 측정하십시오.

GLB와 glTF의 차이는 무엇인가요?

GLB는 바이너리 컨테이너이고 glTF는 형식입니다. .gltf는 JSON이며 별도의 .bin과 이미지 파일을 가리킵니다. .glb는 JSON과 바이너리 버퍼를 한 파일에 담고 base64를 쓰지 않아 요청 한 번으로 끝나며 동등한 JSON 내장 방식보다 조금 작습니다. 둘 다 glTF 2.0이고 규격을 지킨 뷰어에서 로드됩니다.

형태를 망가뜨리지 않고 3D 모델 파일 크기를 줄일 수 있나요?

가능합니다. 세 단계입니다. 재질이 쓰지 않는 텍스처를 지우고, 뷰어가 실제로 표시할 수 있는 디테일까지 지오메트리를 줄이고, 지오메트리에 Draco, 텍스처에 KTX2/Basis를 적용합니다. 각 단계 뒤에 실루엣과 부품 수를 다시 확인하십시오. 가장 저렴한 개선은 거의 항상 텍스처이고, 가장 비싼 실수는 곡면을 너무 깎아 도면과 윤곽이 맞지 않게 되는 것입니다.

구매자가 3D 뷰에서 제품 치수를 잴 수 있나요?

아니요. 3D 뷰는 형태와 비율을 보여 줄 뿐 치수를 보증할 수 없습니다. 보이는 크기는 카메라, 화각, 화면에 따라 달라집니다. 숫자가 필요한 구매자는 치수를 넣은 사양 도면이나 치수 도면을 봐야 합니다. 치수는 제품에 붙이는 것이지 렌더링에서 추론하는 것이 아닙니다.