2D 게임용 스프라이트 시트와 PNG 시퀀스: 무엇으로 내보낼까요?

스프라이트 시트와 PNG 시퀀스는 같은 투명 애니메이션을 보존할 수 있지만 서로 다른 작업에 맞게 포장합니다. 실시간 2D 게임에서는 아틀라스가 대상 하드웨어에 맞고 가져오기 도구가 프레임 사각형을 이해한다면 스프라이트 시트와 메타데이터로 시작하세요. 프레임을 개별적으로 검사, 편집, 교체, 보관, 처리해야 한다면 PNG 시퀀스를 보관하거나 내보내세요.

어느 쪽도 항상 메모리를 덜 쓰거나, 모든 엔진에서 더 빠르거나, 모든 기기와 더 잘 호환되지는 않습니다. 차이를 구체적으로 보여주기 위해 같은 공개 AnimGen 애니메이션으로 두 패키지를 비교했습니다. 512 × 512 RGBA 프레임 96개로 구성된 tactician slash 동작이며, 24 FPS에서 4초 동안 재생됩니다.

작업 단계에 맞는 형식 선택하기

안전한 제작 워크플로는 두 형식을 모두 유지하는 경우가 많습니다. 개별 프레임은 검토 가능한 원본으로 보관하고, 하나 이상의 스프라이트 시트는 대상별 런타임 에셋으로 사용합니다.

하나의 애니메이션, 두 개의 실제 패키지

투명 형식 비교에서 사용한 것과 같은 아이소메트릭 tactician slash 시퀀스로 테스트했습니다. 두 패키지 모두 같은 96개 프레임 캔버스를 같은 순서로 담고 있습니다. 시트는 고정된 10 × 10 격자로, 사용 중인 셀 96개와 사용하지 않는 투명 셀 4개가 있습니다. JSON에는 각 512 × 512인 프레임 사각형 96개가 기록되어 있으며 모든 항목은 회전하거나 잘라내지 않은 상태입니다.

사용한 파일을 직접 확인할 수 있습니다.

• 5120 × 5120 스프라이트 시트 PNG 다운로드
• 대응하는 프레임 레이아웃 JSON 열기
• 96프레임 PNG 시퀀스 ZIP 다운로드
• 기계 판독 가능한 측정값과 SHA-256 해시 열기

비교 전에 두 표현을 모두 디코딩했습니다. 96프레임 전체에서 알파 값이 정확히 일치했습니다. 원본 알파가 8보다 큰 픽셀에서는 RGB도 정확히 일치했습니다. 완전히 투명한 RGB 바이트는 합성 이미지에 영향을 주지 않고 패킹 중 정규화될 수 있으므로 제외했습니다.

이 확인은 중요합니다. “같은 애니메이션”은 썸네일만 비슷하다는 뜻이어서는 안 됩니다. 이를 통해 서로 다른 시각적 결과가 아니라 포장 방식을 비교하고 있음을 확인할 수 있습니다.

측정한 다운로드 크기와 파일 수

이 샘플의 다운로드 패키지는 다음과 같습니다.

시퀀스 ZIP에는 PNG 프레임 96개와 README 하나가 있습니다. 압축 전 항목의 합계는 14,550,491바이트입니다. 각 PNG가 이미 압축되어 있어 ZIP으로 줄어든 크기는 약 0.9%에 불과합니다. 이번 한 번의 테스트에서는 시트 패키지가 ZIP보다 54.44% 작았습니다.

모든 스프라이트 시트에 적용되는 압축률은 아닙니다. 투명 영역, 반복 픽셀, 이미지 디테일, 프레임 크기, 격자 배치, PNG 인코더, ZIP 설정에 따라 달라집니다. 밀도 있게 패킹한 시트는 반복되는 빈 영역이나 비슷한 영역을 효율적으로 압축할 수 있지만 다른 애니메이션에서는 다른 결과가 나올 수 있습니다.

ZIP은 풀면 97개 파일이 되지만 네트워크에서는 한 번 다운로드한다는 점도 중요합니다. “파일이 많다”는 것은 압축 해제, 버전 관리, 편집기 작업, 런타임 처리에 영향을 줍니다. 압축 파일로 제공한다면 반드시 HTTP 요청 97번을 뜻하지는 않습니다.

다운로드가 작다고 메모리 사용량도 적은 것은 아닙니다

PNG 파일 크기는 압축된 저장·전송 크기입니다. 렌더러는 보통 픽셀을 디코딩한 뒤 사용하며, 엔진은 플랫폼별 텍스처 압축, 밉맵, 여백 또는 다른 내부 형식을 적용할 수 있습니다.

단순한 RGBA8 기준으로 보면 다음과 같습니다.

• 5120 × 5120 시트는 26,214,400픽셀로, 픽셀당 4바이트일 때 정확히 100 MiB입니다.
• 개별 512 × 512 프레임 96개는 25,165,824픽셀로, 모두 동시에 디코딩하여 메모리에 올리면 정확히 96 MiB입니다.
• 시트에는 사용하지 않는 512 × 512 셀 4개가 있어 4 MiB 차이가 생깁니다.

PNG 시퀀스가 언제나 96 MiB를 사용한다는 뜻은 아닙니다. 도구는 한 번에 한 프레임만 로드하거나, 일부를 스트리밍하거나, 디코딩 이미지를 버리거나, 빌드 중 시퀀스를 다시 패킹할 수 있습니다. 반대로 엔진이 가져온 모든 프레임을 메모리에 유지할 수도 있습니다. 압축 다운로드 크기를 GPU 메모리로 간주하지 말고 대상 빌드를 측정하세요.

단일 아틀라스는 여러 스프라이트가 같은 텍스처를 참조하므로 배칭을 쉽게 할 수 있지만 드로 콜 하나를 보장하지는 않습니다. 머티리얼, 블렌드 상태, 정렬, 셰이더, 렌더러 규칙, 기타 상태 변경도 영향을 줍니다.

최대 텍스처 크기 확인하기

측정한 시트는 5120 × 5120입니다. 다운로드 가능한 PNG로는 문제가 없지만, 폭넓은 모바일·WebGL 호환성을 위해 흔히 사용하는 보수적인 4096 × 4096 기준을 넘습니다.

원문에서 참고한 Godot 텍스처 크기 지침은 폭넓은 플랫폼 호환성을 위해 4096 × 4096보다 큰 텍스처를 피하도록 권장하며 모바일 GPU는 보통 이 크기로 제한된다고 설명합니다. MDN WebGL 권장사항도 4096을 널리 사용할 수 있는 기준으로 다루지만 데스크톱은 훨씬 큰 텍스처를 지원할 수 있다고 경고합니다.

이 수치는 호환성 기준이지 모든 환경의 상한선이 아닙니다. Unity는 SystemInfo.maxTextureSize로 대상 하드웨어의 제한을 제공하며, WebGL에서는 활성 컨텍스트에 조회할 수 있습니다.

const maxTextureSize = gl.getParameter(gl.MAX_TEXTURE_SIZE);

이 96프레임 샘플에서 512 × 512 셀을 유지하며 4096 이하로 나누면 다음과 같이 만들 수 있습니다.

• 64프레임을 담는 4096 × 4096 크기의 8 × 8 시트 하나
• 32프레임을 담는 4096 × 2048 크기의 8 × 4 시트 하나

이때 메타데이터는 각 프레임이 어느 텍스처에 있는지 식별해야 합니다. 5120픽셀 아틀라스의 크기만 줄이고 기존 512픽셀 사각형 좌표를 그대로 사용하면 안 됩니다. 셀 크기가 바뀌어 좌표가 맞지 않게 됩니다. 더 작은 프레임 캔버스로 내보내거나, 더 적은 프레임을 선택하거나, 대상에 맞는 레이아웃을 적용하는 엔진 팩을 사용하는 것도 가능합니다.

메타데이터가 제공하는 것

스프라이트 시트 이미지 하나만으로는 재생 방법을 알 수 없습니다. 최소한 프레임 사각형과 순서가 필요합니다. 게임에 따라 재생 시간, 애니메이션 이름, 반복 동작, 원본 캔버스, 피벗, 오프셋, 텍스처 파일 이름도 필요할 수 있습니다.

여기서 사용한 공개 JSON은 다음을 제공합니다.

• frame_0000.png부터 frame_0095.png까지의 키
• 각 프레임의 x, y, w, h 사각형
• 원본 및 sprite-source 크기
• 프레임마다 42ms의 정수 재생 시간
• 프레임 0–95를 포함하는 tactician_slash 태그
• 시트 크기와 RGBA8888 형식

42ms는 24 FPS를 정수로 근사한 값입니다. 정확한 타임라인 동기화가 중요하다면 반올림한 프레임당 정수가 긴 시퀀스에서도 수학적으로 정확하다고 가정하지 말고 내보내기 매니페스트의 기준 FPS나 재생 시간 정보를 사용하세요.

PNG ZIP에는 의미 있는 파일 이름과 24 FPS, 고정 캔버스 정렬, 권장 하단 중앙 피벗을 기록한 README가 있습니다. PNG 파일 자체에는 애니메이션 순서, FPS, 반복 동작, 게임플레이 상태가 포함되지 않습니다. 이런 부가 정보를 시퀀스와 함께 보관하세요.

따라서 “스프라이트 시트와 PNG 시퀀스”의 선택은 이미지 형식뿐 아니라 메타데이터의 선택이기도 합니다.

스프라이트 시트와 텍스처 아틀라스는 관련 있지만 항상 같지는 않습니다

두 용어는 흔히 혼용되지만 다음과 같이 구분하면 유용합니다.

• 스프라이트 시트는 보통 애니메이션 프레임을 예측 가능한 띠 또는 격자에 배치합니다.
• 텍스처 아틀라스는 관계없는 스프라이트를 모으고, 투명 여백을 잘라내고, 영역을 회전하고, 불규칙한 사각형을 패킹해 공간을 절약할 수 있습니다.

이 테스트는 규칙적인 스프라이트 시트를 사용합니다. 프레임을 잘라내거나 회전하지 않아 각 프레임이 같은 512 × 512 캔버스를 유지합니다. 일부 투명 픽셀 공간을 낭비하지만 프레임 간 정렬과 하단 중앙 피벗을 간단하게 유지할 수 있습니다.

더 조밀한 아틀라스는 빈 공간을 줄일 수 있지만 가져오기 도구가 원본 크기 오프셋, 트리밍, 회전, 여백, 가장자리 확장을 올바르게 처리해야 합니다. 이를 무시하면 캐릭터가 튀거나, 옆 셀을 샘플링하거나, 눈에 띄는 이음새가 생길 수 있습니다. 스크린샷에서 가장 작아 보이는 구조가 아니라 실제 가져오기 도구가 정확하게 재현할 수 있는 가장 효율적인 구조를 고르세요.

스프라이트 시트가 더 적합한 경우

다음 경우에는 스프라이트 시트+JSON 또는 엔진 팩을 선택하세요.

• 프레임을 실시간 2D 런타임에서 사용합니다.
• 아틀라스가 검증한 텍스처 제한 안에 들어옵니다.
• 가져오기 도구가 제공된 사각형과 타이밍을 이해합니다.
• 애니메이션 프레임을 보통 함께 로드하고 사용합니다.
• 텍스처 공유가 엔진의 배칭·에셋 관리 전략에 도움이 됩니다.
• 실수로 파일을 분리하거나 순서를 바꾸기 어려운 패키지를 원합니다.

Godot을 사용한다면 별도의 Godot 4 가져오기 실측 사례에서 작은 셀, SpriteFrames 리소스, 타이밍, 피벗, 실제 재생을 포함한 런타임용 패키지를 검증했습니다. 그 패키지는 프레임 크기가 96 × 96으로 다르므로 위 크기 표에 의도적으로 포함하지 않았습니다.

PNG 시퀀스가 더 적합한 경우

다음 경우에는 PNG 시퀀스를 선택하세요.

• 아티스트가 개별 프레임을 수정하거나 교체해야 합니다.
• 합성 도구, 인코더, 자체 파이프라인이 번호가 있는 이미지를 요구합니다.
• WebM, ProRes, 시트, 엔진 패키지를 나중에 만들 무손실 원본을 원합니다.
• 전체 애니메이션이 안전한 텍스처 크기를 초과합니다.
• 런타임에서 현재 장면에 필요한 프레임이나 동작만 로드할 수 있습니다.
• 결함이 원본 픽셀, 패킹, 가져오기, 필터링, 재생 중 어디에서 생겼는지 진단합니다.

프레임 하나만 바뀌면 개별 파일이 소스 관리에서 비교하기도 쉽습니다. 반면 이름, 타이밍, 캔버스, 피벗을 이미지와 계속 동기화해야 하며, 일부 엔진은 가져올 때 어차피 다시 패킹합니다.

영상 편집과 웹 제공은 판단 기준이 다릅니다. WebM Alpha, ProRes 4444, PNG 시퀀스 비교는 같은 원본 애니메이션으로 이런 제공 형식을 테스트합니다.

실용적인 내보내기 워크플로

게임 프로젝트에서는 다음과 같은 워크플로가 유연합니다.

1. 패키징 전에 필요한 애니메이션 구간을 선택하고 검토합니다.
2. 검사 또는 제작 원본으로 개별 PNG 프레임을 내보냅니다.
3. 알파, 고정 캔버스 정렬, 프레임 순서, FPS, 피벗을 확인합니다.
4. 대상 플랫폼의 최대 텍스처 크기와 출력 해상도를 정합니다.
5. 대상에 맞춰 시트 하나, 여러 시트 또는 엔진 전용 패키지로 패킹합니다.
6. 작은 장면에 가져와 타이밍, 필터링, 가장자리, 피벗, 반복 연결부를 확인합니다.
7. 프레임 시퀀스, JSON, 매니페스트, 검증한 런타임 패키지를 서로 구분해 보관합니다.

AnimGen의 스프라이트 시트 제작 도구는 생성된 동작이나 지원되는 영상에서 시작해 필요한 구간과 프레임 수를 선택하고, PNG 프레임, JSON이 포함된 스프라이트 시트, 엔진 팩으로 내보낼 수 있습니다. 출력 형식 참고 문서는 정확한 결과물을 나열합니다. 무료·유료 형식 이용 권한은 현재 요금 및 내보내기 이용 조건을 기준으로 확인하세요.

사람이나 도구에 개별 프레임이 필요하면 PNG 시퀀스를 사용하세요. 검증한 런타임이 공유 텍스처와 신뢰할 수 있는 메타데이터의 이점을 얻는다면 스프라이트 시트를 사용하세요. 같은 제작 과정의 서로 다른 단계에 유용하다면 둘 다 보관하세요.