배경: 현재 게임의 픽셀아트(카드 뒷면 거미·J/Q/K 캐릭터·무늬·이펙트·마을 동물·건물 등)는 www/game.js 안에 문자 그리드("B.B.......B.B" 식) + 팔레트로 정의돼 있고, 런타임에 canvas로 그려 PNG data URI를 만든다. 이를 "전부 미리 렌더링한 PNG 파일"로 바꾸면 용량이 어떻게 되는지 실측했다.
① 현재 상태 — 텍스트 그리드 규모 전수 스캔
| 항목 | 수치 |
|---|
| game.js 내 픽셀 그리드 행(row) 수 | 1,357줄 |
| 총 픽셀 문자 수 | 10,477자 |
| 원시 소스 바이트(따옴표·콤마 포함) | 약 14.2KB |
| 추정 개별 스프라이트(캐릭터/아이콘/이펙트) 수 | 약 130~140개 |
② 실측 — 대표 스프라이트 7종 렌더링 비교
동일한 그리드+팔레트를 그대로 PIL로 렌더링해 실제 PNG 파일을 만들고 바이트 수를 쟀다(추정이 아닌 실측). 게임이 실제 쓰는 4배 슈퍼샘플(ART_SS=4, html2canvas 캡처 시 흐려짐 방지용)까지 재현.
| 스프라이트 | 크기 | 소스 텍스트 | PNG(원본 1x) | PNG(4x, 최적화) | PNG(4x, 비최적화) |
|---|
| 거미(카드 뒷면) | 13×10 | 160B | 171B | 254B | 283B |
| 왕관(불꽃놀이) | 13×7 | 112B | 109B | 180B | 197B |
| 스페이드 무늬 | 11×11 | 154B | 125B | 189B | 223B |
| 하트(팝 이펙트) | 7×6 | 60B | 130B | 154B | 166B |
| 낙하산 | 13×12 | 192B | 150B | 257B | 284B |
| 왕 카드 캐릭터 | 11×14 | 196B | 197B | 294B | 338B |
| 어지러움 별 | 11×3 | 42B | 93B | 120B | 137B |
| 평균/스프라이트 | 131B | 139B | 207B | 233B |
PNG는 아무리 작아도 파일 헤더·청크 구조 오버헤드(서명+IHDR+IDAT+IEND, 최소 ~60~80바이트)가 고정으로 붙는다. 그래서 작은 스프라이트일수록 텍스트 대비 PNG가 상대적으로 더 손해다(하트: 60B→154B, 2.5배).
③ 전체 규모로 환산 — APK 용량 영향
~3~4KB
현재 방식(텍스트)
APK 압축 후 예상
~25~35KB
PNG 개별 파일 전환 시
APK 예상 증가분
- 현재 방식: 텍스트는 game.js 안에 있고, APK는 ZIP이라 안에 든 텍스트가 DEFLATE로 압축된다. "B.B.......B.B" 같은 반복 패턴은 압축률이 매우 높음(70~85%대 추정) → 14.2KB 원본이 실제 APK에서는 3~4KB 안팎으로 추정.
- PNG 전환 시: 130~140개 스프라이트 × 평균 207B(4x 최적화 기준) ≈ 27~29KB의 PNG 데이터 자체. PNG는 이미 압축된 포맷이라 ZIP이 다시 압축해도 거의 줄지 않는다(추가 이득 사실상 없음).
- 파일 개수 자체의 오버헤드: ZIP은 파일마다 로컬헤더+중앙디렉터리 항목이 별도로 붙는다(파일당 약 50~70바이트). 130~140개 파일이면 이것만으로 6.5~10KB 추가 — 텍스트 방식엔 없는 비용.
- 종합하면 PNG 전환은 이 어셋군만 놓고 봐도 대략 7~10배 더 큰 용량을 차지하게 된다(3~4KB → 25~35KB).
④ 반대급부 — PNG의 장점도 있나?
| 항목 | 텍스트 그리드(현재) | PNG 개별 파일 |
|---|
| 런타임 CPU | 최초 1회 canvas 렌더(스프라이트당 1~수 ms, 이후 캐시) — 스프라이트 130개라도 전체 수백 ms 이내, 체감 안 됨 | 렌더링 불필요, 파일 디코딩만(약간 더 빠를 수 있으나 차이 미미) |
| 수정 용이성 | 문자 하나 바꾸면 끝(에디터로 편집·재생성 가능, 결정론 파이프라인) | 이미지 편집툴 필요, diff로 변경사항 확인 불가(바이너리) |
| git 저장소 크기 | 텍스트라 diff·압축 효율 좋음 | 바이너리라 매 수정마다 저장소 용량 누적(과거 커밋에도 남음) |
| 버전관리 가독성 | PR/커밋에서 그림이 바로 안 보이지만 grid를 읽을 수 있음 | PR에서 미리보기는 되지만 grid 구조는 안 보임 |
| 결정론 원칙(CLAUDE.md) | 이미 이 프로젝트가 확립한 방식과 정합(스펙+생성) | PNG 자체가 "산출물"이라 소스 스펙이 별도로 필요(어차피 grid 스펙은 남아야 함 — 즉 텍스트를 없애는 게 아니라 추가하는 셈) |
중요: PNG로 내보내더라도 그 PNG를 만들려면 원본 그리드 스펙(텍스트)이 어딘가에는 계속 있어야 한다(그래야 재생성 가능 — 이 프로젝트의 결정론 원칙과도 일치). 즉 "텍스트 대신 PNG"가 아니라 사실상 "텍스트 + PNG"가 되어 소스 관리 부담과 용량을 동시에 늘리는 구조다.
종합 결론
현재 텍스트 그리드 방식이 용량 면에서 더 유리 (약 7~10배 차이)
런타임 성능 차이는 체감 불가 수준이고, PNG 전환은 용량 증가+저장소 관리 부담이라는 명확한 손해가 있다.
다만 예외적으로 PNG 전환이 유리한 경우가 있다면: ①색상 수가 매우 많거나 그라디언트가 들어간 복잡한 이미지(텍스트 그리드로 표현 자체가 비효율적인 경우) ②외부에서 그려온 레퍼런스 아트를 그대로 써야 하는 경우 ③프리렌더링으로 런타임 CPU를 완전히 0으로 만들어야 하는 특수 상황(현재 게임엔 해당 없음, 캐시로 이미 해결됨). 현재 게임의 어셋은 대부분 5~10색 이내의 단순 픽셀아트라 이 예외에 해당하지 않는다.
Ssoly Town · Magpies Studio · 실측 기반 비교(추정 아님, PIL 렌더링+PNG 저장으로 직접 측정) · 내부 의사결정 자료 · noindex