chore(ko): add Korean locale to documentation site (#2173)

2026-08-02 18:43:46 +08:00
parent cfd9c26f09
commit 771ba3f8a7
57 changed files with 6785 additions and 1 deletions
@@ -0,0 +1,263 @@
+---
+title: DevLog @ 2026.03.23
+category: DevLog
+date: 2026-03-23
+excerpt: |
+  AIRI 모바일 성능 개선을 위한 초기 조사
+preview-cover:
+  light: "@assets('/en/blog/DevLog-2026.03.23/assets/cover-light.avif')"
+  dark: "@assets('/en/blog/DevLog-2026.03.23/assets/cover-dark.avif')"
+---
+
+안녕하세요, [@PurCHES5](https://github.com/PurCHES5) 입니다.
+
+최근 AIRI 팀에 합류해 모바일 개발을 맡게 됐습니다. 이 프로젝트와 오픈소스 워크플로 전반에 대한 지식이 아직 얕은 상태에서, 첫 과제는 모바일 빌드 성능을 개선하기 위해 게임 엔진이나 다른 기술적 해법을 통합할 수 있는 가능성을 검토하는 것입니다.
+
+현재 AIRI 모바일 통합의 문제는 주로 성능입니다. 최신 모바일 버전인 [`stage-pocket`](https://github.com/moeru-ai/airi/tree/e952fe779e64494e778e44956eb1caf3338c61a7/apps/stage-pocket) 은 사실상 메인 Vue.js 애플리케이션을 그대로 복사해 Capacitor 로 패키징한 것입니다.
+
+모바일 기기, 특히 iOS 기기와 저사양 하드웨어에서는 Live2D 와 VRM 컴포넌트가 WebView 에 할당된 메모리를 빠르게 소진해 크래시로 이어집니다.
+
+---
+
+## 문제 분석
+
+### 관찰된 현상
+
+- Live2D / VRM 모델 렌더링 시 높은 메모리 사용량
+- iOS 와 저사양 Android 기기에서 잦은 크래시
+- 장시간 구동 후 성능 저하
+
+### 의심되는 원인
+
+- WebView 메모리 누수
+- 모바일 프로세서에서 Three.js 성능 부족
+
+---
+
+## 현재 아키텍처 개요
+
+### 모바일 빌드 스택
+
+| 계층 | 기술 |
+|---|---|
+| 프론트엔드 | Vue.js |
+| 패키징 | Capacitor |
+| 렌더링 | WebGL (Three.js) |
+| 런타임 | 모바일 WebView |
+
+### 렌더링 흐름
+
+```
+Vue UI
+  ↓
+WebView
+  ↓
+Three.js / Live2D / VRM
+  ↓
+Capacitor
+  ↓
+GPU
+```
+
+---
+
+## 모바일의 성능 제약
+
+### WebView 제약
+
+- 네이티브 앱보다 메모리 할당량이 현저히 낮음
+- 가비지 컬렉션 동작을 예측하기 어려움
+- GPU 메모리 압박이 프로세스를 종료시킬 수 있음
+
+### 기기별 제약
+
+- iOS WebView 메모리 상한
+- RAM 이 제한된 저사양 Android 기기
+
+---
+
+## 게임 엔진 통합 탐색
+
+### 후보 엔진
+
+#### 2D
+
+- PixiJS
+- Cocos Creator
+- Unity
+- Godot
+- Bevy
+- Unreal Engine
+
+#### 3D
+
+- Three.js
+- Babylon.js
+- Unity
+- Godot
+- Unreal Engine
+- 직접 작성한 커스텀 3D 엔진
+
+### 통합 전략
+
+| 전략 | 설명 |
+|---|---|
+| 엔진 전면 교체 | WebView 렌더러를 네이티브 엔진으로 완전히 대체 |
+| 하이브리드 WebView | 엔진이 렌더링을, WebView 가 UI 를 담당 |
+| 네이티브 렌더링 모듈 | 엔진이 배경 레이어로 동작하고 그 위에 Vue.js UI 를 겹침 |
+
+### 필요한 기능
+
+- **Live2D**
+- **MMD**
+- VRM
+- Spine2D
+
+---
+
+## Unity 통합 제안
+
+### 렌더링 책임 분담
+
+**Unity 담당:**
+- VRM 렌더링
+- Live2D 렌더링
+- 애니메이션
+- 물리 (필요한 경우)
+
+**Vue / WebView 담당:**
+- UI
+- 설정
+- 네트워크 요청
+
+### 제안하는 하이브리드 아키텍처
+
+```
+Vue UI
+  ↓
+Native Bridge
+  ↓
+Unity Runtime
+  ↓
+Capacitor
+  ↓
+GPU
+```
+
+---
+
+## 프로토타입 빌드
+
+Unity 3D 로 프로토타입 3종을 만들었고, 내보내기 용량을 줄이기 위해 압축을 적용했습니다.
+
+### Unity WebGL 내보내기 설정
+![Unity WebGL Export Settings](/en/blog/DevLog-2026.03.23/assets/Unity-web-export.avif)
+
+### Unity Android 렌더러 설정
+![Unity Android Renderer Export Settings](/en/blog/DevLog-2026.03.23/assets/Unity-android-export.avif)
+
+### 스크린샷
+
+**Android 렌더러 — Live2D:**
+![Android Renderer Live2D prototype](/en/blog/DevLog-2026.03.23/assets/Screenshot-AIRI-Live2D.avif)
+
+**Android 렌더러 — VRM:**
+![Android Renderer VRM prototype](/en/blog/DevLog-2026.03.23/assets/Screenshot-AIRI-VRM.avif)
+
+일관성을 위해 모든 프로토타입 빌드에 동일한 Vue.js 프론트엔드를 적용했습니다. Unity WebGL 내보내기의 경우 [`unity-webgl`](https://github.com/Marinerer/unity-webgl) 을 써서 WebView 의 기존 내용을 Unity WebGL 로 바로 대체했습니다. Unity Android 렌더러의 경우 Three.js 와 VRM 모듈이 들어 있던 기존 뷰를 완전히 제거하고, Unity 가 배경 레이어로 렌더링하며 그 위에 Vue.js UI 를 렌더링합니다.
+
+---
+
+## 벤치마크 결과
+
+모든 측정은 동일 조건에서 Samsung A34 로 수행했습니다. 성능 차이를 더 뚜렷하게 드러내기 위해 의도적으로 저사양 기기를 골랐습니다.
+
+### Live2D 렌더링
+
+| 지표 | Three.js (기준) | Unity WebGL | Unity Android 렌더러 |
+|---|---|---|---|
+| 전체 RAM | **354 MB** | **360 MB** | 663 MB |
+| 그래픽 메모리 | **210 MB** | **202 MB** | 309 MB |
+| CPU 사용률 | 18% | 19% | **7%** |
+| FPS | 무난함 | 무난함 | **매끄러움** |
+
+### VRM 렌더링
+
+| 지표 | 기존 VRM (기준) | Unity WebGL | Unity Android 렌더러 |
+|---|---|---|---|
+| 전체 RAM | 724 MB | **402 MB** | 651 MB |
+| 그래픽 메모리 | 566 MB | **247 MB** | **292 MB** |
+| CPU 사용률 | 11% | 18% | **5%** |
+| FPS | 낮음 | 무난함 | **매끄러움** |
+
+### 참고 스크린샷
+
+**Three.js — Live2D (기준):**
+![Original Three.js Live2D](/en/blog/DevLog-2026.03.23/assets/Live2D-threejs.avif)
+
+**Unity WebGL — Live2D:**
+![Unity WebGL Live2D](/en/blog/DevLog-2026.03.23/assets/Live2D-webgl.avif)
+
+**Unity Android 렌더러 — Live2D:**
+![Unity Android Renderer Live2D](/en/blog/DevLog-2026.03.23/assets/Live2D-android-renderer.avif)
+
+**Three.js — VRM (기준):**
+![Original VRM Module from AIRI](/en/blog/DevLog-2026.03.23/assets/VRM-airi.avif)
+
+**Unity WebGL — VRM:**
+![Unity WebGL VRM](/en/blog/DevLog-2026.03.23/assets/VRM-webgl.avif)
+
+**Unity Android 렌더러 — VRM:**
+![Unity Android Renderer VRM](/en/blog/DevLog-2026.03.23/assets/VRM-android-renderer.avif)
+
+### 핵심 관찰
+
+- **VRM 이 결정적인 병목입니다.** 기준이 되는 Three.js VRM 렌더러는 전체 RAM 724 MB, 그래픽 메모리 566 MB 를 쓰는데, 대부분의 모바일 WebView 가 크래시 없이 버틸 수 있는 수준을 훨씬 넘습니다. Unity WebGL 은 이를 402 MB / 247 MB 로, Android 렌더러는 651 MB / 292 MB 로 낮춥니다.
+- **Unity WebGL 은 VRM 에서 가장 좋은 메모리 프로필을 제공**하며 아키텍처 변경도 최소한입니다. 대신 CPU 사용률이 약간 높습니다.
+- **Unity Android 렌더러는 프레임레이트와 CPU 효율이 가장 좋습니다.** 대신 전체 RAM 사용량이 높은데, Unity 런타임 자체의 오버헤드 때문이라 예상된 결과이며 GPU 작업은 WebView 밖으로 옮겨집니다.
+- **Live2D 성능은 세 방식 모두 비슷합니다.** 기준인 Three.js 구현도 대부분의 Android 기기에서 충분하지만, 전환의 주된 이득은 앞으로 늘어날 콘텐츠를 위한 여유와 저사양 기기에서의 안정성입니다.
+
+---
+
+## 리스크 평가
+
+| 리스크 | 비고 |
+|---|---|
+| 앱/내보내기 용량 증가 | Unity 런타임이 상당한 바이너리 무게를 추가 |
+| 기여자 요건 | Unity / C# 과 셰이더 전문성이 필요 |
+| 크로스 플랫폼 유지보수 | Android 와 iOS Unity 빌드를 병행 유지해야 함 |
+| 브리지 복잡도 | Vue 와 Unity 사이 양방향 통신에 안정적인 API 가 필요 |
+
+---
+
+## 평가 기준
+
+앞으로의 프로토타입과 엔진 결정에는 다음 지표를 일관되게 측정해야 합니다:
+
+- 메모리 사용량 (RAM 및 GPU)
+- 지속 부하에서의 FPS 안정성
+- 시작 / 콜드 런치 시간
+- 빌드 / 설치 용량
+- 배터리 소모
+- 개발 복잡도
+- 장기 유지보수성
+
+---
+
+## 다음 단계
+
+### 1. 브리지 복잡도 평가
+
+[Unity as a Library 통합](https://github.com/Unity-Technologies/uaal-example) 또는 유사한 플러그인을 조사해 양방향 통신(예: 채팅으로 촉발된 표정을 Vue 에서 Unity 로 전달)을 가능하게 합니다.
+
+### 2. iOS 전용 프로토타이핑
+
+iOS 는 WebView 메모리에 관해 가장 제약이 심한 환경이므로, 다음 프로토타입은 Unity 네이티브 레이어가 "Total Safari Memory" 제한을 우회하는지 확인하기 위해 iPhone 에서 검증해야 합니다.
+
+### 3. 빌드 용량 최적화
+
+Unity 의 에셋 관리 시스템을 탐색해 초기 설치 용량을 최소로 유지합니다.
+
+### 4. 커뮤니티 / 기여자 모집
+
+프로젝트가 계속 유지보수 가능하도록, 앞으로의 기여자에게 필요한 역량(Unity/C#, 셰이더 작성)을 정의합니다.