📑 목차
프로크리에이트의 레이어 최대 개수는 기기 성능이 좋다와 나쁘다 같은 감각이 아니라 iPad의 RAM(메모리) 용량과 캔버스의 총 픽셀 수가 만드는 계산 결과에 가깝습니다. 이 글은 iPad 모델별 RAM 차이가 레이어 제한 수치에 어떻게 반영되는지 그리고 해상도와 DPI와 픽셀 수가 레이어 개수를 줄이거나 늘리는 구조적 이유를 정리합니다. 수익화 작업에서 캔버스 설계가 왜 작업 편의가 아니라 데이터 예산 편성인지 디버깅 관점으로 설명합니다.
레이어 제한 경고는 메모리 예산 초과
저는 처음에 레이어 제한 경고를 보면 iPad가 느려졌거나, 제가 레이어를 너무 많이 써서 생긴 단순한 문제라고 생각했습니다. 그래서 레이어를 합치거나(병합) 캔버스를 다시 만들면서 임시로 넘겼습니다. 그런데 수익화 작업을 하다 보니 상황이 달라졌습니다. 미리캔버스 요소 제작, 이모티콘(특히 360px 같은 소형 규격), 굿즈 인쇄용 고해상도 작업은 모두 수정 가능한 구조가 중요하고 그 구조의 핵심이 레이어입니다. 레이어가 부족하면 비파괴 편집이 무너지고, 수정 비용이 폭발합니다.
결국 저는 레이어 제한을 불편한 기능 제약으로 보는 대신, 기기 RAM이 정해준 메모리 예산 안에서 캔버스 픽셀 수가 레이어 개수를 깎아먹는 구조로 이해하기 시작했습니다. 이 글은 iPad 모델별 RAM 차이가 레이어 한도에 어떤 영향을 주는지 그리고 캔버스 설계(픽셀 수)가 왜 가장 강력한 레이어 조절 레버인지 가능한 한 수학적으로 풀어낸 정리입니다.
RAM과 캔버스 총 픽셀 수는 레이어 제한의 핵심 변수
프로크리에이트의 레이어 최대 개수는 기본적으로 아래 2축으로 움직입니다.
- iPad RAM(메모리) 용량: 사용할 수 있는 작업 메모리의 상한
- 캔버스 총 픽셀 수(가로 ×세로): 레이어 1장이 차지하는 데이터 크기
즉, 같은 iPad라도 캔버스가 커질수록 레이어가 줄고, 같은 캔버스라도 RAM이 큰 모델일수록 레이어가 늘어나는 방향이 됩니다. 여기서 DPI는 자주 오해되는 포인트입니다. DPI는 인쇄 크기와 연결되는 개념이지만 프로크리에이트 내부에서 레이어 제한을 실제로 압박하는 건 픽셀 수입니다. 300 DPI 자체가 레이어를 줄이는 게 아니라 300 DPI로 큰 인쇄 크기를 만들면 픽셀 수가 커지고 그 픽셀 수가 레이어 1장당 메모리 사용량을 키워 레이어가 줄어듭니다. 정리하면 레이어 제한을 건드리는 실무 변수는 결국 픽셀 수입니다.
'메모리 사용량 = 픽셀 × 채널 × 비트 깊이'라는 공식이 레이어 수를 결정
프로크리에이트에서 레이어 제한이 발생하는 가장 근본적인 이유는 단순합니다. 레이어는 이미지 한 장이 아니라 전체 픽셀 배열을 그대로 복제한 메모리 덩어리이기 때문입니다. 개념적으로 레이어 1장의 메모리 사용량은 이런 형태로 설명할 수 있습니다.
- 레이어 1장의 이론적 메모리 사용량 =(가로 픽셀 × 세로 픽셀) × (채널 수 × 비트 깊이)
일반적인 작업 환경에서는 RGBA 구조(Red, Green, Blue, Alpha) 4 채널을 사용합니다.
8bit 기준이라면:
- 1 채널 = 8bit = 1byte
- RGBA = 4byte
- 즉, 픽셀 1개 = 최소 4byte
예를 들어 3000 × 3000px 캔버스를 가정해 보겠습니다.
-3000 × 3000 = 9,000,000픽셀
-9,000,000 × 4byte = 약 36MB (레이어 1장)
이론적으로 레이어 한 장이 약 36MB를 차지합니다. 만약 10장이라면 약 360MB가 됩니다. 여기까지는 단순 계산입니다. 하지만 실제 작업에서는 이보다 훨씬 많은 메모리가 사용됩니다.
1. 왜 실제 레이어 수는 계산보다 적게 나오는가
프로크리에이트는 단순히 픽셀을 저장만 하지 않습니다. 작업을 가능하게 하기 위해 다음 요소들이 동시에 메모리를 점유합니다.
[Undo 히스토리 버퍼]
일반적인 RGBA(색 3 채널 + 알파) 기반에서는 픽셀당 최소 4바이트(8 bit×4 채널)를 기본 단위로 떠올릴 수 있습니다. 하지만 실제 작업에서는 여기서 끝이 아닙니다. 프로크리에이트는 레이어를 단순 보관만 하지 않습니다. 다음 요소들이 레이어 예산을 추가로 갉아먹습니다.
- 히스토리/되돌리기(Undo) 버퍼 - 사용자가 스트로크를 그릴 때마다 이전 상태를 저장합니다. Undo 단계가 많을수록 RAM 점유율이 누적됩니다. 특히 브러시 질감이 무거운 경우, 히스토리 버퍼는 레이어 1~2장에 해당하는 메모리를 추가로 소비하기도 합니다.
- 브러시 연산과 블렌딩 임시 버퍼 - Multiply, Overlay, Gaussian Blur, Liquify 등 필터가 적용되는 순간 임시 렌더링 버퍼가 생성됩니다. 이 임시 버퍼는 화면에 보이지 않지만, 연산 중에는 전체 캔버스 크기만큼 메모리를 추가 점유합니다. 고해상도 작업에서 필터 적용 시 갑자기 버벅거리는 이유가 바로 이것입니다.
- 타임랩스 기록(설정에 따라 부담 증가) - 타임랩스는 단순 영상 녹화가 아니라 작업 단계를 압축 기록하는 별도 데이터 구조입니다. 타임랩스 해상도를 4K로 설정하면 이 데이터가 내부적으로 더 많은 메모리를 요구합니다.
- 색상 프로파일과 내부 색 변환 - P3, sRGB, CMYK 시뮬레이션 등 색상 공간에 따라 내부 계산 방식이 달라집니다. 특히 광색역(P3)은 더 넓은 색 범위를 표현하므로 색 변환 과정에서 연산 비용이 증가합니다.
- iPadOS 시스템 예약 메모리 - RAM 전체가 프로크리에이트에 할당되는 것이 아닙니다. 시스템 프로세스, 백그라운드 앱, GPU 메모리, 디스플레이 버퍼 이 영역을 제외한 남는 RAM이 실제 작업 예산입니다.
그래서 실전에서 레이어 수는 RAM을 픽셀로 나눈 값처럼 딱 떨어지지 않고, 오버헤드(추가 비용) 때문에 더 줄어듭니다.
2. 왜 캔버스를 2배 키우면 레이어가 4분의 1로 줄어드는가
많은 사용자가 체감하는 현상입니다. 캔버스를 조금만 키웠는데 레이어가 절반 이하로 줄어들었다고 하는 이유는 픽셀 수 증가가 제곱 단위로 증가하기 때문입니다.
예시: 2000 × 2000 = 4,000,000픽셀 / 4000 × 4000 = 16,000,000픽셀
가로와 세로를 2배 늘리면 픽셀 수는 4배가 됩니다. 레이어 1장의 비용이 4배가 되므로 동일 RAM에서 유지 가능한 레이어 수는 1/4 수준으로 감소합니다. 이 구조를 이해하지 못하면 고해상도 인쇄용 캔버스를 만들 때마다 왜 이렇게 적지?라는 혼란이 반복됩니다.
3. 수익화 작업에서 이 공식이 중요한 이유
수익형 작업은 다음 특징을 가집니다.
- 비파괴 편집을 유지해야 함
- 수정 요청이 반복됨
- 여러 버전이 필요함
- 클리핑 마스크, 효과 레이어가 많음
즉, 레이어가 곧 수정 가능성이고 자산 구조입니다. RAM 계산 없이 캔버스를 키우면 비파괴 구조를 유지할 레이어 예산이 부족해집니다. 결국 병합 증가, 수정 불가, 재작업 비용 증가로 이어집니다.
앱이 알려주는 레이어 제한을 읽는 방식
사용자들이 가장 많이 찾는 정보는 “내 iPad는 레이어 몇 장 되나요?”입니다. 하지만 이 질문에 인터넷에서 흔히 보이는 숫자를 그대로 박아 넣으면 오히려 위험합니다. 이유는 간단합니다.
- 같은 모델명이라도 세대/칩/램 구성이 다를 수 있다.
- iPadOS 버전, 프로크리에이트 버전, 백그라운드 앱 상태에 따라 가용 메모리가 달라진다.
- 무엇보다 캔버스 크기(픽셀 수)가 달라지면 레이어 수는 즉시 바뀐다.
그래서 저는 모델별 표를 외우는 방식보다 내 작업 목적에 맞는 캔버스를 만들고 앱이 알려주는 레이어 제한을 읽는 방식이 가장 정확하다고 결론 내렸습니다.
1. 실무용 측정 방법(가장 확실한 모델별 비교 방식)
동일한 조건의 캔버스를 만듭니다. (예: 3000 ×3000px / 2048 ×2048px / 360 ×360px 등 작업 목적별)
- 캔버스 정보를 열어 최대 레이어 개수를 확인합니다.
- 같은 캔버스를 다른 iPad에서 열어 레이어 한도를 비교합니다.
- 결과를 작업 유형별 기준표로 저장합니다.
이렇게 하면 모델명 기반 추측이 아니라, 내 워크플로우 기반의 레이어 예산표가 만들어집니다.
2. 모델별 비교를 RAM 구간으로 보기
정확한 수치를 고정해서 말하기 어렵다면, iPad를 RAM 구간으로 나눠 기대치를 잡는 게 현실적입니다.
- 저 RAM 구간(입문형): 고해상도 캔버스에서 레이어가 빨리 줄어듦 → 작업 분할/캔버스 분리 전략 필수
- 중 RAM 구간(작업용): SNS/이모티콘/중형 인쇄 정도까지 균형
- 고 RAM 구간(상위 모델): 큰 픽셀 캔버스에서도 레이어 여유가 상대적으로 큼 → 비파괴 구조 유지가 쉬움
여기서 핵심은 RAM이 높을수록 무조건 좋다가 아니라 내가 쓰는 캔버스 픽셀 수에서 레이어 예산이 얼마나 남는지입니다.
수익화 작업은 가장 좋은 장비보다 가장 안정적인 구조를 필요로 하기 때문입니다.
Q&A
Q. DPI를 낮추면 레이어가 늘어나나요?
A. DPI 자체가 아니라 결과적으로 캔버스 픽셀 수가 줄어들면 레이어가 늘어나는 방향으로 체감했습니다. “픽셀 수가 레이어 비용을 결정한다”가 더 정확했습니다.
Q. 레이어가 부족하면 병합해서 해결하면 되지 않나요?
A. 단순 개인 작업이면 가능하지만, 수익화 작업에서는 수정이 반복되기 때문에 병합은 리스크가 커졌습니다. 레이어는 편의가 아니라 ‘수정 가능성’이었습니다.
Q. 같은 iPad인데 어떤 날은 레이어가 더 적게 느껴지는 이유가 있나요?
A. 백그라운드 앱, iPadOS 상태, 저장공간 부족, 발열 등이 가용 메모리에 영향을 줄 수 있다고 느꼈습니다. “항상 동일한 가용 RAM이 아니다”가 핵심이었습니다.
Q. 레이어 수를 늘리려면 결국 무엇을 먼저 바꿔야 하나요?
A. 저는 캔버스 픽셀 수를 먼저 설계하는 게 가장 영향이 컸습니다. 레이어 예산을 확보한 다음에 브러시/효과/타임랩스 같은 요소를 조절하는 순서가 안정적이었습니다.
나의 생각｜레이어 제한은 데이터 예산표
프로크리에이트의 레이어 제한은 불친절한 제약처럼 보이지만 수익화 관점에서는 오히려 명확한 신호였습니다. 이 캔버스 크기에서 이 기기는 이 정도 데이터만 안정적으로 처리할 수 있다는 예산표를 앱이 먼저 보여주는 셈입니다.
초보자는 종종 캔버스를 크게 잡아두면 안전하다고 생각합니다. 하지만 수익화 작업에서는 크게 시작이 항상 안전하지 않았습니다. 픽셀 수가 커지는 순간 레이어 예산이 줄고, 그 결과 비파괴 구조가 무너져 수정 비용이 커집니다. 저는 이제 캔버스를 만들 때마다, 그림을 그리기 전에 먼저 레이어 예산을 확인합니다. 레이어 예산이 부족하면 캔버스를 조정하거나 작업을 분할하는 쪽이 장기적으로 훨씬 안정적이었습니다.
결론적으로 iPad RAM은 성능이 아니라, 내가 쓸 수 있는 레이어 예산의 상한 입니다. 그리고 그 예산을 가장 크게 흔드는 변수가 캔버스 픽셀 수였습니다. 이 관계를 이해한 이후, 저는 레이어 제한을 운으로 받아들이지 않고 설계로 관리하게 됐습니다. 작업이 자산이 되는 순간, 이런 설계 능력이 결국 생산성과 승인 안정성을 동시에 올려준다고 생각합니다.