TECH NOTE · DESKTOP AI PET
데스크톱 펫 캐릭터 애니메이션으로 Live2D와 Spine을 빼고 스프라이트 시트를 고른 이유를, 무료 배포 앱의 런타임 라이선스 조건 중심으로 정리했습니다.
무료로 배포할 앱이라 런타임 라이선스부터 봤다
데스크톱 펫 캐릭터를 어떤 방식으로 움직일지 정할 때, 후보는 셋이었다. Live2D, Spine, 그리고 스프라이트 시트. 결론부터 적으면 스프라이트 시트를 골랐고, 결정적인 이유는 그림 품질이 아니라 런타임 라이선스였다.
만들려던 게 무료로 배포하는 앱이었다. 여기서 조건이 하나 붙는다. 내가 라이선스를 사는 것으로 끝나는 게 아니라, 받아 쓰는 사람에게도 조건이 붙는지를 봐야 한다.
Spine이 걸린 지점
Spine은 2D 스켈레탈 애니메이션 도구로 널리 쓰인다. 그림 품질과 작업 효율만 보면 매력적이다.
그런데 런타임이 오픈소스가 아니다. 라이선스 파일에 각 사용자가 Spine Editor 라이선스를 보유해야 한다는 조항이 있다. 무료로 배포하는 앱에 이걸 넣으면, 앱을 받은 사람이 라이선스를 사야 하는 구조가 될 수 있다.
내가 에디터를 정식으로 구매해도 이 조항은 남는다. 그래서 뺐다.
Live2D가 걸린 지점
Live2D는 세 가지가 겹쳤다.
- Cubism Core가 상용 라이선스다
- 당시 Godot 연동(GDCubism)이 0.9.x대라 성숙도가 낮았다
- 캐릭터 리깅 자체의 제작 난이도가 높다
라이선스만 문제였다면 조건을 따져볼 수 있었는데, 미성숙한 연동과 높은 제작 비용이 함께 왔다. 혼자 만드는 프로젝트에서 셋을 동시에 감당할 이유가 없었다.
DragonBones는 2순위로만 남겼다
오픈 스켈레탈 도구인 DragonBones도 후보였다. 라이선스 쪽 문제는 덜하다.
다만 엔진 런타임의 성숙도를 검증하지 못했다. 채택했다가 나중에 런타임에서 막히면 그때 다시 갈아타야 한다. 그래서 2순위 후보로만 적어두고 진행하지 않았다.
정리하면 이렇게 갈렸다
| 후보 | 걸린 지점 | 판단 |
|---|---|---|
| Live2D / GDCubism | Cubism Core 상용 라이선스, 연동 미성숙, 제작 난이도 | 제외 |
| Spine | 런타임이 오픈소스 아님. 사용자에게도 에디터 라이선스 요구 | 제외 |
| DragonBones | 라이선스는 무난하나 런타임 성숙도 미검증 | 보류 |
| 스프라이트 시트 | 외부 런타임 의존이 없음 | 채택 |
스프라이트 시트를 고른 이유를 뒤집어 말하면, 고를 이유가 없어서 남은 것에 가깝다. 라이선스가 완전히 자유롭고, 엔진 기본 기능만으로 재생되며, 그림을 만드는 진입 장벽이 낮다. 원조 시메지가 그렇게 만들어졌다는 점도 결이 맞았다.
대신 포기한 것이 있다
스프라이트 시트는 프레임을 미리 다 만들어 둬야 한다. 뼈대를 움직여 자세를 만드는 방식이 아니라서, 표정이나 동작을 하나 추가하려면 그 프레임들을 새로 그려야 한다.
립싱크가 대표적이다. Live2D였으면 입 모양을 파라미터로 조절했을 텐데, 스프라이트에서는 입 모양 프레임을 따로 만들어 음성에 맞춰 바꾸는 방식이 된다. 부드러움은 떨어지고 만들 그림은 늘어난다.
이건 감수한 비용이다. 다만 이 프로젝트에서는 AI로 캐릭터 이미지를 생성하고 있어서, “프레임을 많이 만들어야 한다”는 부담이 손으로 그리던 시절보다는 덜하다. 그 부분이 판단에 영향을 줬다.
화면 거리에 따라 프레임셋을 나눴다
한 가지 더 정한 게 있다. 캐릭터가 화면 가까이 있을 때와 멀리 있을 때 쓰는 프레임을 나눴다.
| 상황 | 프레임셋 |
|---|---|
| 근경 — 대화하거나 표정을 보여줄 때 | 큰 표정 프레임셋 |
| 원경 — 창 주변을 돌아다닐 때 | 작은 액션 프레임셋 |
멀리 있을 때는 표정이 어차피 안 보인다. 그때까지 큰 프레임을 쓰면 용량만 늘어난다. 반대로 가까이 왔을 때 작은 프레임을 늘려 쓰면 뭉개진다.
전환 자체는 크기가 충분히 작아지는 지점에서만 일어나게 했다. 그 시점에는 이미 디테일이 보이지 않아서 프레임셋이 바뀌어도 눈에 띄지 않는다.
같이 나오는 질문
유료 앱이었으면 다른 선택을 했을까
Spine 쪽은 다시 검토했을 것이다. 걸린 게 기술이 아니라 배포 조건이었기 때문이다. 앱을 파는 구조라면 사용자에게 라이선스가 전가되는 문제를 다르게 볼 여지가 있다.
스프라이트 시트는 용량이 크지 않나
프레임 수만큼 그림이 늘어나니 스켈레탈보다 큰 게 맞다. 다만 이 프로젝트에서는 캐릭터 팩을 앱 번들 밖에 두고 사용자 폴더에 설치하는 구조라, 앱 크기와는 분리돼 있다.
라이선스는 어디까지 확인해야 하나
배포 형태를 정하고 나서 보는 게 순서다. 무료 배포인지, 유료인지, 사내용인지에 따라 같은 라이선스도 결론이 달라진다. 이 프로젝트는 무료 배포가 먼저 정해져 있어서 그 기준으로 걸렀다.
다음에 볼 건 그 프레임들을 실제로 어떻게 만들었는지다. 프레임을 많이 그려야 하는 방식을 골랐으니, 그 부분을 어떻게 감당했는지가 이어지는 이야기다.
