기획 배경
여러 사람들이 SNS에서 애니메이션 캐릭터의 죽음에 대해 슬퍼하고, 이에 공감하는 모습을 자주 볼 수 있었습니다. 하지만 이런 애도는 몇 가지 문제를 안고 있었습니다.
문제 정의
- 공개적인 공간(SNS·현실)이라 원치 않은 스포일러 문제가 있다.
- 공개 장소는 '죽음'이라는 키워드를 다루기에 부적절하다.
그래서 캐릭터의 죽음을 온전히 애도할 수 있는 디지털 애도 커뮤니티 플랫폼을 만들었습니다. UI는 클래식한 Windows 인터페이스로 구성되어, 기존의 정형화된 웹 뷰 아키텍처를 그대로 쓸 수 없었습니다. 그래서 최애의 사인만을 위한 구조를 직접 설계했습니다.
주요 기여
1. Web OS 아키텍처 설계
OS의 큰 요소(화면 렌더링 · 프로세스 관리 · 애플리케이션)를 웹 위에서 재현했습니다.
- 프로세스 관리자와 렌더링 관리자를 분리했습니다.
- 렌더링 관리자가 모든 컴포넌트의 렌더링을 담당합니다.
- 커널(Kernel)이 전체 시스템을 조율합니다.
정형화된 웹뷰 구조를 벗어나 새로운 아키텍처를 구상하고 구현까지 하는 경험은 쉽지 않았지만, 그만큼 구조 설계에 대한 자신감을 얻었습니다.
2. 전체 디자인 & 퍼블리싱
대부분의 화면 디자인을 담당했고, 여러 애플리케이션(추모관·내 컴퓨터·공지사항·절하기·우클릭 메뉴 등)의 퍼블리싱을 직접 맡았습니다.
3. 길잡이 캐릭터 '설이'
처음 방문한 유저를 위해 서비스 곳곳을 안내하는 길잡이 캐릭터 '설이'를 기획·구현했습니다.
4. Unity WebGL 리듬게임
일반적인 4라인 리듬게임에 2가지 기믹 노트를 추가해 Unity 6(WebGL)로 제작하고, iframe + postMessage로 웹에 임베딩했습니다.
트러블슈팅
1. 캐릭터 드래그와 바탕화면 상호작용 충돌
- 문제점 — 캐릭터를 렌더링하는 Matter.js canvas가 바탕화면 전체를 덮어, 바탕화면 클릭 이벤트가 막혔습니다.
- 해결방안 — 캐릭터 canvas가 바탕화면을 덮되, 클릭을 감지해 캐릭터가 아닌 영역이면 이벤트를 아래로 통과시키도록 처리했습니다.
- 성과 — 기존 로직 대부분을 유지한 채 캐릭터 상호작용과 바탕화면 상호작용을 성공적으로 분리했습니다.
- 배운점 — canvas의 z-index 조정은 렌더링 순서의 문제이지 이벤트 흐름의 문제가 아님을 이해하게 됐습니다.
2. WebGL 게임 배포
- 문제점 — 빌드된 리듬게임 파일 크기가 너무 커 프론트엔드에 포함해 배포하기 어려웠습니다.
- 해결방안 — WebGL 빌드를 프론트엔드에 직접 넣지 않고 별도 사이트에 배포한 뒤 iframe으로 불러왔습니다.
- 성과 — 리듬게임이 성공적으로 추가됐고, iframe 로딩에서도 눈에 띄는 성능 저하가 없었습니다.
- 배운점 — 문제 해결의 방향이 항상 기술적 복잡도를 높이는 쪽일 필요는 없다는 것을 배웠습니다.
Result
- 전공동아리(12개 팀, 7개월 개발) 평가에서 금상(1위) 수상
- BEXCO·COEX·수원메쎄 등에서 부스 운영, 방문객 대상 사용자 평가 수집
- 11/8 ~ 12/8 정식 서비스 운영, 누적 트래픽 90만+
