언리얼5로 만든 3D 컨피규레이터 — 터치스크린 매장에 들어간 이야기

한 문장 요약

웹이 아니라 매장 터치스크린에서 돌아가는 3D 컨피규레이터를 언리얼5로 만들었습니다. 고객사가 보유한 3D 모델을 받아, 매장 직원이 손가락으로 색상·재질·조명·카메라 각도를 실시간으로 바꾸며 고객에게 보여줄 수 있게 한 도구입니다.

웹3D를 주로 다루는 우리에게 “왜 굳이 언리얼?”은 가장 먼저 받은 질문이었어요. 이 글은 그 결정의 이유에 대한 기록입니다.

왜 웹이 아니라 언리얼이었나

처음 의뢰가 들어왔을 때 우리도 같은 생각이었습니다. “이거 Three.js로 충분히 되는데?”

그런데 매장 환경을 직접 가보고 나서 마음이 바뀌었습니다.

• 매장은 고정 PC + 큰 터치스크린 환경이었습니다. 노트북도 모바일도 아닙니다. 즉, 폴리곤·텍스처·라이팅 예산이 굉장히 넉넉했습니다.
• 같은 제품을 매일 8시간 이상 풀 화면으로 띄워둡니다. 브라우저보다는 안정성이 보장된 네이티브가 훨씬 안전합니다.
• 무엇보다 — 고객사가 이미 언리얼용 마스터 머티리얼을 가지고 있었습니다. 같은 비주얼을 웹3D로 옮기려면 PBR 텍스처를 다시 굽는 작업이 필요했고, 그건 품질 손실 + 시간 손실 두 개를 동시에 의미했습니다.

도구는 “우리가 잘 쓰는 것”이 아니라 “프로젝트에 맞는 것”으로 골라야 합니다. 이 프로젝트엔 언리얼이 정답이었어요.

작업 범위

세 덩어리로 나뉘었습니다.

1. 윈도우 터치스크린 대응 — 마우스 입력 가정으로 만들어진 언리얼 UI를 손가락에 맞게 다시 잡는 일
2. 언리얼5 개발 — 컨피규레이터 본체, 옵션 UI, 카메라 모션
3. 배경 3D 모델링 + 폴리곤 최적화 — 매장 분위기에 맞는 배경 씬, 그리고 60fps 유지를 위한 폴리 카운트 다이어트

터치스크린이 만든 “안 보이던 문제”

웹이나 데스크톱 컨피규레이터는 마우스를 가정합니다. 호버 상태가 있고, 우클릭 메뉴가 있고, 작은 버튼을 정확히 클릭할 수 있죠. 터치스크린에선 그 가정이 전부 깨집니다.

가장 많이 시간을 쓴 두 가지.

1. 모든 인터랙션 영역을 “손가락 사이즈”로

언리얼 기본 UI 위젯이 데스크톱 기준으로 만들어져 있어, 그대로 두면 매장 직원 손에 안 잡힙니다. 모든 버튼·슬라이더의 hit area를 48px 이상으로 다시 잡았습니다. 시각적인 크기는 그대로 두고 hit area만 키우는 트릭을 많이 썼어요.

2. 호버가 사라진 세상의 옵션 UI

웹 컨피규레이터에서 흔한 “옵션에 마우스 올리면 미리보기” 패턴은 터치에선 못 씁니다. 그래서 옵션을 누르는 순간 — 망설임 없이 — 즉시 적용되도록 구조를 바꿨습니다. 모든 변경은 1탭, 즉시, 되돌릴 수 있게. 이 룰이 UX 전체를 정리해줬습니다.

카메라 모션이 영업 도구가 된다

이 프로젝트에서 클라이언트가 가장 좋아한 기능은 의외로 부위별 카메라 모션이었습니다.

옵션 패널에 “디테일 보기” 버튼을 두고, 누르면 카메라가 그 부위로 부드럽게 이동·줌하면서 라이팅도 거기에 맞춰 살짝 바뀝니다. 매장 직원이 “자, 이 부분을 보세요” 하는 동작이 영상처럼 자동화된 셈입니다.

이건 컨피규레이터가 아니라 영업 시연 도구에 더 가깝습니다. 우리가 처음 그렸던 그림보다 훨씬 가치가 컸어요.

폴리곤 최적화 — 60fps은 협상 불가

매장 PC가 강력하다고 해도, 8시간 풀 부하 60fps은 만만한 목표가 아닙니다. 그래서 다음을 적용했습니다.

• HLOD + Nanite 부분 적용 — 배경의 디테일은 살리되 GPU 부하는 줄이기
• 머티리얼 인스턴스화 — 옵션 색상은 동적 머티리얼 인스턴스로 처리. 새 머티리얼을 매번 컴파일하지 않음
• 라이트 베이크 + 동적 라이트 1개 — 키 라이트 하나만 동적, 나머지는 베이크
• 씬 단순화 — 화면에 안 들어오는 배경 디테일은 과감하게 제거. “보이는 것만 만든다” 룰

가장 효과가 컸던 건 머티리얼 인스턴스였습니다. 옵션 변경 시 prefer-shader-compile 끊김이 사라지면서 인터랙션이 “기계 같은” 매끄러움을 갖게 됐어요.

우리가 배운 것

환경이 도구를 결정한다

웹 vs 네이티브, Three.js vs 언리얼 — 이런 비교는 추상적으로 하면 답이 안 나옵니다. “어디서 돌아가는가, 누가 쓰는가, 몇 시간 켜져 있는가” 를 보면 답이 나옵니다.

터치스크린은 “큰 모바일”이 아니다

매장 터치스크린은 모바일도 데스크톱도 아닌 세 번째 환경입니다. 사람이 서서, 옆에 다른 사람이 보고, 오류가 나면 즉시 티가 납니다. 이 환경은 단순함과 안정성으로 설계해야 합니다.

영업 도구로서의 컨피규레이터

“고객 셀프 컨피규레이터” 와 “영업 직원이 들고 시연하는 컨피규레이터” 는 만들어야 하는 도구가 다릅니다. 후자에선 카메라 모션, 디테일 줌, 라이팅 변화 같은 “스토리텔링 기능” 이 핵심입니다.

자주 받는 질문

언리얼 vs Three.js, 어떻게 결정하나요? 세 가지로 봅니다. (1) 매장/키오스크/박람회 같은 고정 환경인가? — 언리얼 / (2) 누구나 링크 한 줄로 들어와야 하는가? — Three.js / (3) 비주얼 품질이 협상 불가인가? — 언리얼.

기존 언리얼 자산을 그대로 쓸 수 있나요? 대부분 가능합니다. 마스터 머티리얼, 라이팅 셋업, 환경 라이브러리가 있으면 수개월 분량의 작업이 생략됩니다. 가져오기 전에 사용 라이선스만 확인하면 됩니다.

유지보수는 어떻게 하나요? 언리얼 프로젝트는 빌드 후 단일 실행 파일 + 데이터 폴더로 배포합니다. 옵션 추가/제거는 데이터 폴더 교체로 처리할 수 있도록 데이터 드리븐 구조로 짜는 게 정석입니다.

도입까지 얼마나 걸리나요? 3D 자산이 정리돼 있으면 812주, 모델링부터 같이 해야 하면 1216주 정도가 일반적입니다.

---

매장 키오스크나 박람회 부스, 혹은 영업 시연용 도구로 3D 컨피규레이터를 검토 중이시라면 프로젝트 문의 로 사용 환경(고정 PC인지, 어떤 화면인지, 몇 시간 풀 부하인지)을 알려주세요. 보통 첫 통화에서 “언리얼인가 웹인가” 부터 같이 정리해드립니다.

Hammergrid Lab은 언리얼·Three.js·WebGPU 기반 3D 제품 도구를 만드는 크리에이티브 개발 스튜디오입니다.