첫 접속에 50MB가 들던 웹 빌드 줄이기

전송량과 화면 비용을 따로 줄였습니다

LAST37N의 초기 웹 빌드는 첫 접속에 필요한 네 파일이 약 50MB였습니다. 고DPI 화면에서는 캔버스 내부 픽셀도 불필요하게 커지고 있었습니다. 다운로드와 렌더링은 서로 다른 비용이므로, 이번에는 릴리스 압축과 내부 해상도 제한을 각각 적용하고 수치를 따로 기록했습니다.

Unity 6000.0.83f1의 압축 Disabled·Development 빌드를 gzip·Release로 바꿨습니다. 기존 빌드는 보존하고 별도 출력과 포트에서 확인한 파일만 기본 로컬 웹에 반영했습니다. 새 파일이 생겼다는 사실만으로 현재 서비스가 바뀌었다고 판단하지 않았습니다.

압축 파일과 응답 헤더를 함께 맞췄습니다

브라우저가 압축을 직접 해제하도록 서버에서 gzip 헤더와 wasm MIME을 제공합니다. 실제 wasm 응답의 Content-Encoding: gzip, Content-Type: application/wasm과 압축 길이 7,220,833바이트를 확인했습니다. 아래 도표는 빌드부터 전송 검증까지의 절차를 정리한 것입니다.

flowchart LR
 A["gzip Release 빌드"] --> B["응답 헤더 설정"]
 B --> C["새 컨텍스트와 캐시 비활성"]
 C --> D["실제 전송량과 기능 확인"]
 D --> E["기본 로컬 웹에 적용"]

초기 네 파일은 50,532,559바이트에서 10,398,823바이트로 줄었습니다. 감소율은 79.42%입니다. 파일은 loader·data·framework·wasm을 기준으로 합산했으며 지도와 실시간 통신까지 포함한 총 네트워크 비용으로 설명하지 않습니다.

고DPI 화면의 내부 픽셀 수를 제한했습니다

DPR 2, CSS 1440×900 조건에서 내부 캔버스는 2880×1800이었습니다. 자동 배율을 1로 제한해 1440×900으로 낮췄고, 렌더링 픽셀 수는 5,184,000에서 1,296,000으로 75% 줄었습니다. 전송량 감소와 픽셀 감소를 합쳐 하나의 성능 개선율로 만들지는 않았습니다.

실제 최종 로컬 서버에서도 도시 로딩과 1440×900 캔버스, 전송량을 다시 확인했습니다. 캐시를 끈 새 브라우저 컨텍스트에서 측정했기 때문에 이전 파일이 남아 전송량이 작게 보이는 상황을 피했습니다. 다만 픽셀 수가 줄었다고 FPS가 같은 비율로 늘었다고 판단할 수는 없습니다.

용량 예산과 기능 회귀를 함께 뒀습니다

HTML이 참조하는 네 파일 합계가 12MiB를 넘으면 빌드 후 검사가 실패하도록 했습니다. 이 상한은 당시 임시 예산 설정입니다. 실제 수색과 식수 사용, 배낭, 상점 구매·판매, 의무병 치료도 별도 QA 데이터베이스에서 확인했습니다. 압축 때문에 용량만 줄고 게임이 열리지 않는 결과를 막기 위한 검사입니다.

로컬 냉시작은 5.45초와 5.33초였지만 단일 실행이므로 유의한 속도 개선으로 해석하지 않았습니다. 인터넷 다운로드 지연이나 저사양·모바일 성능, 다수 캐릭터의 FPS도 이 결과로 증명하지 않습니다. 당시 초기 청크의 개별 건물·도로 렌더러에는 배칭과 LOD가 아직 적용되지 않았습니다. 이번에는 전송과 고DPI 예산을 먼저 정리하고, 다음 렌더 최적화의 기준점을 남겼습니다.

작업 근거

• 개발 기록 원문