스프라이트 시트 만들고 사용하는 법

가이드 · 가이드 목록으로

픽셀크래프트 스튜디오 편집팀 · 최종 업데이트: 2026년 8월 · 읽는 데 약 6분

캐릭터 애니메이션을 만들다 보면 프레임이 하나씩 늘어나면서 이미지 파일도 함께 늘어납니다. 프레임마다 파일을 따로 관리하면 엔진에 하나씩 불러와야 하고, 파일 이름이 조금만 어긋나도 애니메이션이 깨집니다. 스프라이트 시트는 이런 프레임들을 한 장의 이미지에 모아두는 방식으로, 대부분의 2D 게임 엔진이 기본적으로 지원하는 표준적인 작업 방식입니다.

왜 낱장 대신 시트로 관리하는가

스프라이트 시트를 쓰면 이미지 파일 하나만 불러오면 되기 때문에 로딩이 단순해지고, 렌더링 시 텍스처를 전환하는 횟수(드로우 콜)도 줄어들어 성능에도 유리합니다. 무엇보다 애니메이션 하나가 통째로 파일 하나에 들어있으므로 버전 관리나 파일 전달이 훨씬 간편합니다. 프레임 수가 2~3개뿐인 간단한 이펙트라면 낱장으로도 충분하지만, 걷기·공격처럼 여러 애니메이션을 가진 캐릭터라면 시트로 관리하는 편이 훨씬 안정적입니다.

그리드 배치 vs 타이트 패킹

스프라이트 시트를 만드는 방법은 크게 두 가지입니다.

패딩(여백)으로 블리딩을 막아라

프레임 사이에 여백 없이 딱 붙여서 배치하면, 화면에 그릴 때 확대·필터링 과정에서 옆 프레임의 픽셀이 살짝 섞여 보이는 블리딩(bleeding) 현상이 생길 수 있습니다. 특히 픽셀 아트처럼 선명한 경계가 중요한 그래픽에서는 이 현상이 눈에 잘 띕니다. 프레임 사이에 최소 1~2픽셀의 투명한 여백(패딩)을 두면 이 문제를 예방할 수 있습니다. 셀 크기를 정할 때부터 실제 캐릭터 크기 + 패딩만큼 여유를 두고 설계하는 것이 좋습니다.

idle walk attack ← 셀 사이 1~2px 여백(패딩)으로 블리딩 방지 →
애니메이션마다 한 행씩 나누고 셀 크기를 통일하면, 엔진에서 "행 = 애니메이션, 열 = 프레임 순서"로 바로 슬라이스할 수 있습니다.

네이밍과 순서 규칙

시트 안에서 애니메이션별로 행(row)을 나누고, 행마다 idle, walk, attack처럼 이름을 붙여 정리해두면 나중에 다시 열어봐도 헷갈리지 않습니다. 개별 프레임을 따로 내보낼 일이 있다면 walk_00, walk_01처럼 두 자리 숫자로 순서를 맞춰두는 것이 좋습니다. 숫자를 한 자리로 두면 walk_10이 walk_1 다음이 아니라 walk_2 앞에 정렬되는 식의 순서 오류가 자주 발생합니다.

엔진에서 잘라 쓰는 방식

대부분의 엔진은 스프라이트 시트를 자동으로 슬라이스하는 기능을 제공합니다. Godot는 SpriteFrames 리소스에서 그리드 크기를 지정해 프레임을 자동으로 나눠주고, Unity는 Sprite Editor의 Grid By Cell Size 옵션으로 동일한 작업을 합니다. Aseprite 같은 픽셀 아트 툴에서 애니메이션을 작업했다면, 시트 이미지와 함께 프레임 좌표가 담긴 JSON을 내보내 엔진에 그대로 가져올 수 있어 수작업으로 좌표를 맞추는 실수를 줄일 수 있습니다.

실전 체크리스트

시트에 들어갈 프레임 크기를 아직 정하지 못했다면 스프라이트 사이즈 정하는 법을 먼저 읽어보세요. 완성한 시트를 원하는 배율로 조절해야 한다면 이미지 크기 변경 도구를 브라우저에서 바로 사용할 수 있습니다.

자주 묻는 질문

스프라이트 시트와 텍스처 아틀라스는 같은 건가요?

거의 같은 뜻으로 쓰입니다. 관례상 "스프라이트 시트"는 애니메이션 프레임을 격자로 나열한 것을, "텍스처 아틀라스"는 크기가 제각각인 이미지를 빈틈없이 모아 좌표 데이터와 함께 쓰는 것을 가리키는 경우가 많습니다.

시트 한 장의 최대 크기는 어느 정도가 안전한가요?

구형 모바일 GPU까지 고려하면 2048x2048, 최신 환경 기준으로는 4096x4096을 한 장 상한으로 잡는 것이 무난합니다. 이를 넘으면 시트를 여러 장으로 나누세요.

프레임을 추가하면 셀 좌표가 다 밀리는데요?

그래서 애니메이션마다 행을 나누고, 각 행 끝에 빈 셀을 몇 개 여유로 두는 방식을 씁니다. Aseprite 등에서 좌표 JSON을 함께 내보내면 프레임을 추가해도 엔진이 메타데이터로 위치를 다시 읽어 수동 수정이 필요 없습니다.