WebGL : 개념 정리 및 PC/모바일 개발과의 차이점

참고 자

 

웹 - Unity 매뉴얼

 

1. 서론

어릴 적 웹 브라우저에서 별도의 설치 없이 바로 실행되는 플래시 게임을 종종 했다.

 

최근 itch.io 같은 인디 게임 플랫폼이나 기술 데모를 보며 웹 기술의 발전을 느꼈다.

 

이제는 유니티(Unity)로 만든 고퀄리티 3D 게임도 웹에서 구동된다.

 

평소 게임 클라이언트 개발자를 지망하며 유니티를 다뤄왔지만, '웹(Web)'이라는 환경은 모바일이나 PC와는 완전히 다른 생태계다.

 

이번 기회에 WebGL에 대해 대략적으로 무엇인지, 유니티 개발자가 웹 빌드를 할 때 알아야 할 기술적 차이점은 무엇인지 정리해 보려고 한다.

 

2. WebGL이란?

WebGL (Web Graphics Library)은 웹 브라우저가 컴퓨터의 그래픽 카드(GPU)를 사용하여 그래픽을 렌더링 할 수 있게 해주는 자바스크립트(JavaScript) API다.

 

별도의 플러그인 설치 없이 웹 표준 기술만으로 3D 그래픽을 구현할 수 있다.

 

기술적으로 WebGL은 OpenGL ES 2.0을 기반으로 설계되었다.

 

▶ OpenGL ES란?

OpenGL ES (Embedded Systems)는 PC보다 성능이 제한적인 스마트폰, 태블릿 같은 임베디드 장치를 위한 그래픽 표준 API다.

• WebGL 1.0 ≒ OpenGL ES 2.0 (구형 모바일 기기 수준)
• WebGL 2.0 ≒ OpenGL ES 3.0 (최신 모바일 기기 수준)

즉, "WebGL로 개발한다"는 것은 기술적으로 "모바일 사양에 맞춰 개발한다"와 매우 유사하다.

 

3. HTML5와 Canvas, 렌더링 원리

WebGL의 동작을 이해하려면 HTML5의 <canvas> 태그를 알아야 한다.

• HTML5 <canvas> : 웹 페이지 상에서 그래픽을 그릴 수 있는 영역(Element)이다.
• WebGL : 이 캔버스 영역에 GPU 가속을 받아 고속으로 그래픽을 그려내는 역할을 한다.

정리하자면 브라우저가 HTML5 캔버스 영역을 할당하면, WebGL API가 GPU에 명령을 내려 그 영역 안에 픽셀을 렌더링 하는 구조다.

 

하지만 다행히도 유니티 개발자가 직접 <canvas> 태그를 제어하거나 날것의 WebGL API를 코딩할 일은 거의 없다.

 

유니티 엔진이 빌드 과정에서 C# 로직을 WebGL 규격에 맞게 자동으로 변환하고 연결해 주기 때문이다.

 

따라서 우리는 '내 게임이 브라우저의 캔버스 위에서 그려진다'는 전체적인 구조만 이해하고, 실제 개발은 익숙한 C# 환경에서 진행하면 된다.

 

4. Unity WebGL 빌드 원리 (WebAssembly와 런타임)

C#으로 작성된 유니티 프로젝트가 자바스크립트 기반의 웹에서 실행되는 원리는 다음과 같다.

 

유니티 WebGL 빌드는 IL2CPP와 Emscripten을 거쳐 WebAssembly (Wasm) 파일을 생성한다.

 

IL2CPP가 C#을 C++로 바꾸면, Emscripten이라는 툴체인이 그 C++ 코드를 받아서 최종적으로 웹 브라우저용 바이너리인 WebAssembly로 빌드해 줍니다.

1. WebAssembly (Wasm) : C/C++ 같은 언어를 웹에서 네이티브에 가까운 속도로 실행하기 위해 만든 바이너리 포맷(0과 1로 된 기계어 형태)이다. 텍스트인 자바스크립트보다 해석 및 실행 속도가 월등히 빠르다.
2. 동작 원리 (AOT) :
   • 유니티의 C# 로직은 빌드 시점에 이미 AOT(Ahead Of Time) 방식으로 Wasm으로 컴파일된다. 런타임에 코드를 변환하는 JIT(Just In Time) 방식이 아니다.
   • 런타임 호출의 의미 : Wasm은 연산(CPU)은 빠르지만, 직접 GPU에 접근할 권한이 없다. 따라서 화면을 그려야 할 때(DrawCall), Wasm(유니티 엔진)은 브라우저의 Javascript/WebGL API(브릿지)를 호출한다.
   • 이 과정에서 Wasm과 JS 사이의 통신 비용(오버헤드)이 발생하므로 최적화가 중요하다.

 

5. 모바일 개발 vs WebGL 개발의 기술적 차이

유니티 에디터나 PC 빌드에서는 문제없던 기능들이 WebGL에서는 제한되는 경우가 많다.

① 스레딩 (Threading) 제약

• App : 멀티 스레드 생성을 통한 병렬 처리가 자유롭다.
• WebGL : 자바스크립트 환경은 기본적으로 싱글 스레드(Single Thread)다.
  • 유니티의 System.Threading 같은 기능이 제한적으로 작동하거나, 사용 시 브라우저 응답 없음 현상을 유발할 수 있다.
  • 최근 Web Workers를 이용한 멀티 스레딩 지원이 생겼으나, SharedArrayBuffer 등 서버 보안 설정이 까다롭다.
  • 따라서 WebGL 개발 시에는 멀티 스레드 의존도를 낮추고 코루틴(Coroutines)을 적극 활용하는 것이 안전하다.

② 네트워크 (Networking) 제약

• App : 소켓(Socket)을 열어 TCP나 UDP 통신을 자유롭게 사용한다.
• WebGL : 브라우저 보안 정책상 RAW TCP/UDP 소켓을 직접 사용할 수 없다.
  • 대안 : WebSockets을 사용해야 한다.
  • WebSockets : HTTP 프로토콜로 연결을 맺은 뒤, 연결을 유지하며 양방향 데이터를 주고받는 통신 기술이다.
  • 네트워크 엔진을 사용할 경우 전송 프로토콜을 WebSockets으로 변경해야 한다.

③ 파일 시스템 (File System) 제약

• App : System.IO를 통해 로컬 디스크에 파일 입출력이 가능하다.
• WebGL : 보안상 웹사이트가 사용자의 로컬 하드디스크에 직접 접근할 수 없다.
  • IndexedDB : 대신 브라우저는 IndexedDB라는 내장 NoSQL 데이터베이스를 제공한다.
    • 유니티는 내부적으로 이 공간을 가상의 파일 시스템으로 매핑하여 사용한다. PlayerPrefs나 파일 저장 API를 호출하면 실제로는 IndexedDB에 데이터가 저장되는 방식이다.

④ 메모리 (Memory) 관리

• WebGL은 브라우저가 탭 하나에 할당하는 메모리 한도가 명확하다.
• 유니티 WebGL 힙(Heap)은 실행 시점에 연속된 메모리 블록을 요구한다. 따라서 기기의 램 용량이 충분하더라도, 메모리 단편화(Fragmentation)가 심하면 할당에 실패하여 OOM(Out of Memory) 오류가 발생할 수 있다.