Go to Editor

FAQ — Spine JSON 최적화 및 물리 베이킹 (Spine 3.7–4.2)

re-polish는 게임 팀이 예측 가능한 품질로 Spine JSON 내보내기를 최적화하도록 도와줍니다. 이 FAQ는 파일 크기 줄이기, 커브 정리, Spine 4.2의 물리 베이킹에 대한 실용적인 질문을 다룹니다.

마지막 업데이트: 2026-04-18

크기와 성능

시각적 품질을 잃지 않고 Spine JSON 크기를 줄이려면?

중복 키를 제거하고, 오차 허용 범위로 커브를 간소화하며, 릴리즈 내보내기 전에 미사용 엔티티를 제거합니다.

Spine JSON이 .skel보다 큰 이유는?

JSON은 사람이 읽을 수 있는 형식으로 상세한 텍스트 구조를 저장합니다. 장점은 검사, diff, 파이프라인 자동화가 더 쉽다는 것입니다.

Spine 프로젝트에서 JSON 크기를 가장 많이 늘리는 부분은?

밀집한 키 분포, 복잡한 커브 데이터, 과대한 bone/slot 구조가 주요 요인입니다.

JSON 축소가 게임 로딩 성능을 향상시키나요?

네. 작은 페이로드는 더 빠른 전송, 더 짧은 파싱 시간, 더 낮은 메모리 압력을 의미합니다.

커브와 키

자동 키 정리는 안전한가요?

안전성은 임계값과 트랙 유형에 달려 있습니다. 일반 변환은 안전하지만 VFX와 스타일라이즈드 모션은 보수적 설정이 필요합니다.

공격적인 커브 간소화를 피해야 할 때는?

미세한 움직임, 수작업 스타일 디테일, 오디오나 게임플레이 트리거와의 엄격한 동기화 시.

“베이크된 키를 커브로 정리”란 무슨 뜻인가요?

베이킹 후 애니메이션에 노이즈가 있는 키가 포함될 수 있습니다. 정리는 더 부드럽고 컴팩트한 커브를 재구성합니다.

최적화가 애니메이션 스타일을 망가뜨리지 않았는지 확인하려면?

컨트롤 클립에서 전후를 비교하세요: 빠른 회전, 극단적 포즈, 루프 이음새, VFX 세그먼트.

물리 베이킹 (Spine 4.2)

Spine 4.2에서 물리를 베이크하는 이유는?

베이킹은 시뮬레이션 출력을 결정론적 키로 변환하여 재생 예측성을 높이고 루프를 안정시킵니다.

물리 베이킹 후 파일 크기가 급증할 수 있는 이유는?

베이킹은 매우 밀집한 키 시퀀스를 생성합니다. 컴팩트한 크기를 복구하려면 두 번째 패스가 필요합니다.

베이크된 물리를 이전 런타임에서 사용할 수 있나요?

대부분의 경우 예, JSON에 런타임 특정 물리 데이터 없이 표준 애니메이션 키가 포함되어 있다면 가능합니다.

물리 베이킹 후 루프 이음새를 부드럽게 하려면?

시작/끝 포즈를 맞추고 이음새 주변의 전환 창을 제어합니다. 베이크 후 스무딩이 스파이크 제거에 도움이 됩니다.

이전 Spine 버전(3.7–4.1)을 사용하는 프로젝트에 물리를 추가할 수 있나요?

네. 업그레이드 → 베이크 → 다운그레이드 파이프라인을 사용하세요: Set Spine Version 노드가 JSON을 4.2로 업그레이드하고, Add Physics Constraints 노드가 선택한 본에 물리를 추가하고, Bake Physics 노드가 시뮬레이션을 표준 키프레임으로 변환하며, 마지막 Set Spine Version 패스가 대상 버전으로 다운그레이드합니다. 결과는 물리 의존성이 없는 일반 애니메이션 파일로, 이전 런타임과 호환됩니다. 프로젝트가 이전 런타임에서 실행되더라도 Spine 4.2 물리를 빠른 모션 제작 도구로 활용할 수 있습니다.

파이프라인

자동 최적화가 수동 정리보다 나은가요?

수동 정리는 최대한의 제어력을 제공하지만 확장성이 떨어집니다. 자동화는 일관성과 속도를 제공합니다.

최적화의 유용성을 증명하는 지표는?

JSON 크기, 파싱 시간, 로드 시 피크 메모리, 컨트롤 클립에서의 시각적 diff를 추적합니다.

프로젝트 전체 최적화

하나의 JSON만이 아니라 Spine 프로젝트 전체를 어떻게 최적화하나요?

전체 프로젝트 워크플로우에서는 Project Input, Project Viewer, Deduplicator를 함께 사용하세요. 이 pipeline은 프로젝트 전체를 불러오고, 병목을 빠르게 찾고, 중복 asset을 제거하는 데 도움이 됩니다.

프로젝트 최적화에 Project Input을 써야 하는 이유는 무엇인가요?

Project Input은 단일 파일 대신 전체 프로젝트 폴더나 아카이브를 그래프에 불러옵니다. 그래서 이후 node들이 JSON, atlas 데이터, 텍스처, 프로젝트 구조에 배치 처리하기 좋은 하나의 컨텍스트에서 접근할 수 있습니다.

Project Viewer의 장점은 무엇인가요?

Project Viewer는 변경 전에 프로젝트를 살펴보고 가장 무거운 JSON 파일, atlas 페이지, 텍스처 asset을 찾아줍니다. 덕분에 추측이 아니라 실제 병목에 최적화 작업을 집중하기 쉬워집니다.

프로젝트 workflow에서 Deduplicator는 무엇을 개선하나요?

Deduplicator는 프로젝트 전반에서 동일하거나 거의 동일한 스프라이트를 찾아 하나의 기준 버전을 남기고 참조를 그 버전으로 다시 연결합니다. 이렇게 하면 atlas 중복 콘텐츠가 줄고 asset 낭비가 낮아지며, 이후 export나 repack 단계도 단순해집니다.

왜 Static Bake가 iGaming pipeline에 유용한가요?

Static Bake는 선택한 애니메이션 프레임을 생성된 PNG 스프라이트와 정적 심볼로 바꿉니다. reels, UI 요소, 프로모 장면에 쓰일 안정적이고 예측 가능하며 runtime 부담이 낮은 asset이 필요한 iGaming pipeline에서 특히 유용합니다.

이 pipeline은 프로덕션 팀에 무엇을 제공하나요?

파일을 하나씩 처리하는 대신 전체 프로젝트를 불러오고, 분석하고, 정리하는 반복 가능한 workflow를 팀에 제공합니다. 시간은 절약되고, 무겁거나 중복된 asset을 놓칠 가능성은 줄어들며, 릴리스 준비도 더 예측 가능해집니다.

제한 및 품질 관리

최적화 시 주요 품질 위험은?

스타일 중요 트랙에서의 과도한 압축. 보수적 기본값을 유지하고 대상 QA 검사를 실행하세요.