Blog·인사이트

WebGL이란? — 우리가 5년 이상 매달려 온 기술

···6분 읽기
요약

LG ThinQ WebGL 엔진, 두코 디지털 카탈로그, 빌드심플리 BIM 뷰어, 한국앤컴퍼니 자동차 배터리 쇼룸 등 프로덕트 메이커가 5년 이상 운영해 온 WebGL을 시리즈의 출발점으로 정리합니다. 추상적 소개 대신 실제로 부딪힌 문제와 그 답을 위주로 풉니다.

WebGL — 우리가 5년 이상 매달리고 있는 기술

프로덕트 메이커는 LG전자의 LG ThinQ WebGL 엔진을 비롯해 다수의 WebGL 프로젝트를 설계·개발해 왔습니다. 가전·자동차·제조·건축 영역에서 웹 3D를 실제 운영 단계까지 끌고 가는 작업을 5년 이상 해 오고 있습니다.

이 글은 WebGL 시리즈의 첫 글로, WebGL이 무엇인지 정리하면서 동시에 저희가 이 기술로 무엇을 만들어왔는지 함께 적습니다. WebGL을 "다양한 분야에서 활용된다" 식으로 추상적으로 소개하는 글은 인터넷에 이미 많기 때문에, 여기서는 실제로 우리가 부딪힌 문제와 그 답을 위주로 풉니다.

WebGL이란

WebGL(Web Graphics Library)은 웹 브라우저에서 GPU를 직접 활용해 3D 그래픽을 렌더링하는 표준 API입니다. OpenGL ES 2.0(WebGL 1.0)과 OpenGL ES 3.0(WebGL 2.0)을 기반으로 설계됐으며, 별도의 플러그인이나 앱 설치 없이 HTML <canvas> 요소 위에서 동작합니다. 2025년 기준 전 세계 데스크톱·모바일 브라우저의 97% 이상이 WebGL 1.0을, 90% 이상이 WebGL 2.0을 지원합니다.

중요한 점은 WebGL 위에서 동작하는 모든 3D는 "URL 하나로 접근 가능한" 상태가 된다는 것입니다. 앱 마켓 심사도, OS별 빌드도, 별도 설치도 없습니다. 검색 엔진이 페이지를 읽고, OG 이미지와 메타데이터가 그대로 작동하고, 링크 공유로 그 자리에서 3D 콘텐츠가 열립니다.

Three.js — 사실상 표준 라이브러리

WebGL을 직접 다루면 셰이더(GLSL) 코드와 행렬 연산을 한 줄씩 작성해야 합니다. 큐브 하나 띄우는 데도 100줄에 가까운 보일러플레이트가 필요한 수준이라, 실무에서는 거의 모두 추상화 라이브러리를 사용합니다.

그 중 Three.js가 사실상 표준입니다. GitHub 스타 100,000개 이상으로 웹 3D 라이브러리 중 가장 큰 생태계를 보유하고 있고, 거의 모든 메이저 WebGL 결과물이 Three.js 위에서 돌아갑니다. Babylon.js·PlayCanvas 같은 대안이 있지만, 라이브러리 생태계·튜토리얼 자료·서드파티 도구의 풍부함은 Three.js가 압도적입니다. 프로덕트 메이커도 대부분의 WebGL 프로젝트의 기본 스택을 Three.js 위에 둡니다.

우리가 WebGL로 만들어온 것들

같은 WebGL 기술이라도 어떤 환경에서, 어떤 제약 아래 만들었느냐에 따라 노하우가 완전히 갈립니다. 저희가 그동안 운영한 주요 사례는 다음과 같습니다.

LG ThinQ WebGL 엔진 — 전국 아파트 도면을 연동해 실내 공간을 3D로 시뮬레이션하고, 그 공간에 가구를 배치하고 가전을 직접 제어할 수 있는 엔진입니다. 도면이 없는 집은 사용자가 벽체를 직접 생성·편집해 자신의 공간을 만들 수 있도록 설계했습니다.

두코 디지털 카탈로그 — 화장품 용기 제조사의 다양한 SKU(펌프·에어리스·튜브·캡 등)를 CAD(STP) 파일에서 웹 3D 모델로 변환해 카탈로그로 노출하는 작업입니다. 거래처가 링크 하나로 제품을 직접 돌려보고, 자사 브랜드 로고와 컬러, 재질을 실시간으로 변경해 보는 시뮬레이터까지 한 화면에서 사용할 수 있습니다.

빌드심플리 모듈러 배치 시뮬레이터 — 모듈러 건축 회사 케이씨MMC를 위해 구축한 웹 시스템입니다. 고객이 보유한 필지 위에 콘크리트 모듈러 건물을 배치 시뮬레이션하고, 정북일조 검토와 견적까지 한 화면에서 볼 수 있습니다.

한국앤컴퍼니 디지털 카탈로그 — 자동차 배터리 라인업을 웹 3D 쇼룸으로 구축. 한국앤컴퍼니(주)의 협력사로 등록되어 진행한 프로젝트입니다.

이 외에도 현대 아이오닉6 인터랙티브 콘텐츠, 휴니트 슈퍼노바(CES 혁신상) 등 자동차·제조·가전 영역의 WebGL 프로젝트를 운영해 왔습니다.

WebGL이 잘 맞는 영역

저희가 실제로 도입을 권하는 영역은 명확합니다. 첫째, 제품의 형상·재질이 곧 영업 자산인 곳입니다. 가구·가전·자동차·주얼리·시계처럼 "직접 돌려보고 싶다"는 욕구가 매출 직결인 카테고리에서는 사진보다 3D가 항상 더 강합니다.

둘째, 옵션·커스터마이징이 핵심인 곳입니다. 두코의 화장품 용기 시뮬레이터처럼 캡·몸체·재질·라벨을 실시간으로 조합해 보여주는 화면은 사진 카탈로그로는 만들 수 없습니다.

셋째, 공간감·내부 구조 시연이 필요한 곳입니다. 빌드심플리에서의 사용자 필지위에서 동작하는 콘크리트모듈러 3D 뷰어, 의료 기기 분해도, 산업 장비 단면 같은 케이스가 여기 들어갑니다.

넷째, 글로벌·다플랫폼 송출이 필요한 곳입니다. iOS·Android·웹·스마트 TV 환경을 모두 커버해야 한다면 네이티브 3D 빌드를 따로 만드는 대신 WebGL 위에서 한 코드베이스로 해결하는 쪽이 거의 항상 빠르고 가볍습니다.

WebGL이 잘 맞지 않는 영역

반대로 단가가 낮고 옵션이 적은 일용품, 촬영만으로 충분한 패션 아이템, 텍스트·표·이미지 중심의 정보 콘텐츠에는 WebGL 도입 비용이 효과를 압도합니다. 또 모바일 게임처럼 높은 프레임과 풍부한 셰이더 효과가 필수인 영역은 여전히 Unity·Unreal의 영역입니다. WebGL은 "충분한 수준의 시각적 품질을 모든 디바이스에서 한 번에 전달하는" 데 강한 기술이지, 모든 3D의 답이 아닙니다.

한계와 실전에서 부딪힌 것들

WebGL 프로젝트에서 가장 자주 죽는 지점은 세 곳입니다.

저사양·구형 디바이스의 DrawCall 한계 — 데스크톱에서 잘 돌던 모델이 모바일·구형 단말에서 프레임이 떨어지는 가장 흔한 이유입니다. 멀티 디바이스 환경의 프로젝트라면 거의 모두 부딪히는 지점입니다.

GPU 드라이버·OS별 렌더링 차이 — 같은 셰이더가 Android의 Mali·Adreno·Apple의 Metal·여러 임베디드 환경의 그래픽 스택에서 미묘하게 다르게 그려집니다. 다기기 QA가 필수입니다.

초기 로딩 — 모델 파일·텍스처·셰이더가 한꺼번에 깔리는 구조라 그대로 두면 첫 진입에 수십 MB가 빠지고, 모바일 사용자의 절반이 그 자리에서 이탈합니다. Draco/Basis Universal 압축과 프로그레시브 로딩이 사실상 의무입니다.

이 세 가지에 대한 실전 대응법은 시리즈 안에서 한 편씩 따로 다룹니다.

이어지는 글들

이 글이 시리즈의 출발점입니다. 이후 글에서 다음 주제를 차례대로 풀 예정입니다.

  1. DrawCall 최적화 — WebGL 성능 최적화의 첫 번째 관문
  2. WebGL E-Commerce — 3D 뷰어가 구매 전환율에 미치는 영향
  3. CAD → Web 3D 변환과 디지털 카탈로그 — STP 파일을 웹 3D 카탈로그로 옮기는 방법
  4. 대기업이 소규모 스튜디오에 WebGL을 의뢰하는 이유 — 규모가 아니라 전문성의 문제

WebGL은 "신기한 기술"이 아니라 이미 매일 운영되고 있는 기술입니다. 시리즈 전체에서 우리가 어떻게 운영하는지를 함께 적어 두겠습니다.


WebGL,3D,웹개발,Three.js,브라우저
다른 포스팅
Blog·인사이트

WebGL이란? — 우리가 5년 이상 매달려 온 기술

···6분 읽기

WebGL — 우리가 5년 이상 매달리고 있는 기술

프로덕트 메이커는 LG전자의 LG ThinQ WebGL 엔진을 비롯해 다수의 WebGL 프로젝트를 설계·개발해 왔습니다. 가전·자동차·제조·건축 영역에서 웹 3D를 실제 운영 단계까지 끌고 가는 작업을 5년 이상 해 오고 있습니다.

이 글은 WebGL 시리즈의 첫 글로, WebGL이 무엇인지 정리하면서 동시에 저희가 이 기술로 무엇을 만들어왔는지 함께 적습니다. WebGL을 "다양한 분야에서 활용된다" 식으로 추상적으로 소개하는 글은 인터넷에 이미 많기 때문에, 여기서는 실제로 우리가 부딪힌 문제와 그 답을 위주로 풉니다.

WebGL이란

WebGL(Web Graphics Library)은 웹 브라우저에서 GPU를 직접 활용해 3D 그래픽을 렌더링하는 표준 API입니다. OpenGL ES 2.0(WebGL 1.0)과 OpenGL ES 3.0(WebGL 2.0)을 기반으로 설계됐으며, 별도의 플러그인이나 앱 설치 없이 HTML <canvas> 요소 위에서 동작합니다. 2025년 기준 전 세계 데스크톱·모바일 브라우저의 97% 이상이 WebGL 1.0을, 90% 이상이 WebGL 2.0을 지원합니다.

중요한 점은 WebGL 위에서 동작하는 모든 3D는 "URL 하나로 접근 가능한" 상태가 된다는 것입니다. 앱 마켓 심사도, OS별 빌드도, 별도 설치도 없습니다. 검색 엔진이 페이지를 읽고, OG 이미지와 메타데이터가 그대로 작동하고, 링크 공유로 그 자리에서 3D 콘텐츠가 열립니다.

Three.js — 사실상 표준 라이브러리

WebGL을 직접 다루면 셰이더(GLSL) 코드와 행렬 연산을 한 줄씩 작성해야 합니다. 큐브 하나 띄우는 데도 100줄에 가까운 보일러플레이트가 필요한 수준이라, 실무에서는 거의 모두 추상화 라이브러리를 사용합니다.

그 중 Three.js가 사실상 표준입니다. GitHub 스타 100,000개 이상으로 웹 3D 라이브러리 중 가장 큰 생태계를 보유하고 있고, 거의 모든 메이저 WebGL 결과물이 Three.js 위에서 돌아갑니다. Babylon.js·PlayCanvas 같은 대안이 있지만, 라이브러리 생태계·튜토리얼 자료·서드파티 도구의 풍부함은 Three.js가 압도적입니다. 프로덕트 메이커도 대부분의 WebGL 프로젝트의 기본 스택을 Three.js 위에 둡니다.

우리가 WebGL로 만들어온 것들

같은 WebGL 기술이라도 어떤 환경에서, 어떤 제약 아래 만들었느냐에 따라 노하우가 완전히 갈립니다. 저희가 그동안 운영한 주요 사례는 다음과 같습니다.

LG ThinQ WebGL 엔진 — 전국 아파트 도면을 연동해 실내 공간을 3D로 시뮬레이션하고, 그 공간에 가구를 배치하고 가전을 직접 제어할 수 있는 엔진입니다. 도면이 없는 집은 사용자가 벽체를 직접 생성·편집해 자신의 공간을 만들 수 있도록 설계했습니다.

두코 디지털 카탈로그 — 화장품 용기 제조사의 다양한 SKU(펌프·에어리스·튜브·캡 등)를 CAD(STP) 파일에서 웹 3D 모델로 변환해 카탈로그로 노출하는 작업입니다. 거래처가 링크 하나로 제품을 직접 돌려보고, 자사 브랜드 로고와 컬러, 재질을 실시간으로 변경해 보는 시뮬레이터까지 한 화면에서 사용할 수 있습니다.

빌드심플리 모듈러 배치 시뮬레이터 — 모듈러 건축 회사 케이씨MMC를 위해 구축한 웹 시스템입니다. 고객이 보유한 필지 위에 콘크리트 모듈러 건물을 배치 시뮬레이션하고, 정북일조 검토와 견적까지 한 화면에서 볼 수 있습니다.

한국앤컴퍼니 디지털 카탈로그 — 자동차 배터리 라인업을 웹 3D 쇼룸으로 구축. 한국앤컴퍼니(주)의 협력사로 등록되어 진행한 프로젝트입니다.

이 외에도 현대 아이오닉6 인터랙티브 콘텐츠, 휴니트 슈퍼노바(CES 혁신상) 등 자동차·제조·가전 영역의 WebGL 프로젝트를 운영해 왔습니다.

WebGL이 잘 맞는 영역

저희가 실제로 도입을 권하는 영역은 명확합니다. 첫째, 제품의 형상·재질이 곧 영업 자산인 곳입니다. 가구·가전·자동차·주얼리·시계처럼 "직접 돌려보고 싶다"는 욕구가 매출 직결인 카테고리에서는 사진보다 3D가 항상 더 강합니다.

둘째, 옵션·커스터마이징이 핵심인 곳입니다. 두코의 화장품 용기 시뮬레이터처럼 캡·몸체·재질·라벨을 실시간으로 조합해 보여주는 화면은 사진 카탈로그로는 만들 수 없습니다.

셋째, 공간감·내부 구조 시연이 필요한 곳입니다. 빌드심플리에서의 사용자 필지위에서 동작하는 콘크리트모듈러 3D 뷰어, 의료 기기 분해도, 산업 장비 단면 같은 케이스가 여기 들어갑니다.

넷째, 글로벌·다플랫폼 송출이 필요한 곳입니다. iOS·Android·웹·스마트 TV 환경을 모두 커버해야 한다면 네이티브 3D 빌드를 따로 만드는 대신 WebGL 위에서 한 코드베이스로 해결하는 쪽이 거의 항상 빠르고 가볍습니다.

WebGL이 잘 맞지 않는 영역

반대로 단가가 낮고 옵션이 적은 일용품, 촬영만으로 충분한 패션 아이템, 텍스트·표·이미지 중심의 정보 콘텐츠에는 WebGL 도입 비용이 효과를 압도합니다. 또 모바일 게임처럼 높은 프레임과 풍부한 셰이더 효과가 필수인 영역은 여전히 Unity·Unreal의 영역입니다. WebGL은 "충분한 수준의 시각적 품질을 모든 디바이스에서 한 번에 전달하는" 데 강한 기술이지, 모든 3D의 답이 아닙니다.

한계와 실전에서 부딪힌 것들

WebGL 프로젝트에서 가장 자주 죽는 지점은 세 곳입니다.

저사양·구형 디바이스의 DrawCall 한계 — 데스크톱에서 잘 돌던 모델이 모바일·구형 단말에서 프레임이 떨어지는 가장 흔한 이유입니다. 멀티 디바이스 환경의 프로젝트라면 거의 모두 부딪히는 지점입니다.

GPU 드라이버·OS별 렌더링 차이 — 같은 셰이더가 Android의 Mali·Adreno·Apple의 Metal·여러 임베디드 환경의 그래픽 스택에서 미묘하게 다르게 그려집니다. 다기기 QA가 필수입니다.

초기 로딩 — 모델 파일·텍스처·셰이더가 한꺼번에 깔리는 구조라 그대로 두면 첫 진입에 수십 MB가 빠지고, 모바일 사용자의 절반이 그 자리에서 이탈합니다. Draco/Basis Universal 압축과 프로그레시브 로딩이 사실상 의무입니다.

이 세 가지에 대한 실전 대응법은 시리즈 안에서 한 편씩 따로 다룹니다.

이어지는 글들

이 글이 시리즈의 출발점입니다. 이후 글에서 다음 주제를 차례대로 풀 예정입니다.

  1. DrawCall 최적화 — WebGL 성능 최적화의 첫 번째 관문
  2. WebGL E-Commerce — 3D 뷰어가 구매 전환율에 미치는 영향
  3. CAD → Web 3D 변환과 디지털 카탈로그 — STP 파일을 웹 3D 카탈로그로 옮기는 방법
  4. 대기업이 소규모 스튜디오에 WebGL을 의뢰하는 이유 — 규모가 아니라 전문성의 문제

WebGL은 "신기한 기술"이 아니라 이미 매일 운영되고 있는 기술입니다. 시리즈 전체에서 우리가 어떻게 운영하는지를 함께 적어 두겠습니다.


WebGL,3D,웹개발,Three.js,브라우저
다른 포스팅
WebGL프로젝트 상담