애프터이펙트 렌더 파일이 너무 크거나 업로드 후 색이 깨질 때: ProRes와 H.264 고르는 법

애프터이펙트에서 뽑은 파일이 1분에 몇 GB씩 나오거나, 반대로 작게 뽑아 올렸더니 유튜브에서 그라데이션이 뭉개지고 색이 빠져 보인다면 먼저 한 가지를 확인하세요. 파일 하나에 두 가지 일을 시키고 있지 않은지입니다. 다시 편집하거나 넘길 중간 파일은 ProRes처럼 크고 튼튼하게, 사람들이 볼 배포 파일은 H.264처럼 작게 따로 만드는 것이 기본입니다. 색이 달라 보인다면 설정을 만지기 전에 파일의 값이 바뀐 것인지, 재생하는 쪽이 다르게 보여 주는 것인지부터 가릅니다.

아래 내용은 2026년 9월 기준 최신인 After Effects 26.5의 Adobe 공식 문서를 바탕으로 정리했습니다. 용량 숫자는 코덱의 목표 비트레이트로 계산한 추정치이고, 직접 렌더해 잰 값이 아닙니다.

애프터이펙트 렌더 용량은 코덱과 비트레이트가 정합니다

렌더 파일 크기는 컴프가 얼마나 복잡한지보다 어떤 코덱에 몇 Mbps를 주었는지에 거의 비례합니다. 계산은 간단합니다. 비트레이트(Mbps)에 길이(초)를 곱하고 8로 나누면 대략의 MB가 나옵니다. 15Mbps로 1분이면 15 × 60 ÷ 8, 약 113MB입니다.

Apple이 밝힌 ProRes의 목표 데이터율은 1920×1080, 29.97fps 기준으로 ProRes 422 HQ 약 220Mbps, ProRes 422 약 147Mbps, ProRes 4444 약 330Mbps입니다. 같은 식에 넣으면 ProRes 422 HQ는 1분에 약 1.65GB가 됩니다. 반면 애프터이펙트에 기본으로 들어 있는 H.264 프리셋은 5, 15, 40Mbps이고, 유튜브가 권하는 1080p 30fps 업로드 비트레이트는 8Mbps입니다.

형식	비트레이트 (1080p 29.97)	1분 추정 용량	주 용도
ProRes 4444	약 330Mbps	약 2.5GB	알파 포함 마스터
ProRes 422 HQ	약 220Mbps	약 1.65GB	편집·색보정용 마스터
ProRes 422	약 147Mbps	약 1.1GB	용량을 조금 줄인 마스터
H.264 (AE 프리셋)	5 / 15 / 40Mbps	약 38 / 113 / 300MB	배포, 시사
H.264 (유튜브 권장)	8Mbps (60fps는 12Mbps)	약 60MB	유튜브 1080p 업로드

그러니 “파일이 너무 크다”는 대부분 설정이 잘못됐다는 뜻이 아니라, 중간 파일용 코덱으로 배포 파일을 만들었다는 뜻입니다. Render Queue의 Output Module에서 템플릿 이름만 보고 고르면 어떤 코덱이 걸렸는지 놓치기 쉽습니다. Output Module Settings를 열어 Format과 Format Options에 실제로 무엇이 선택됐는지 한 번 확인하세요. 소리가 없는 컴프라면 Audio Output을 끄는 것도 Adobe가 권하는 용량 절약입니다. 4K라면 ProRes 용량은 대략 네 배로 커지니 저장 공간도 함께 계산해 둡니다.

중간 파일과 배포 파일은 하는 일이 다릅니다

중간 파일은 다음 작업의 재료입니다. Premiere Pro나 DaVinci Resolve로 넘겨 편집하거나 색보정할 파일, 클라이언트에게 넘길 원본, 나중에 다시 꺼낼 보관본이 여기에 해당합니다. ProRes 422 HQ는 10비트 4:2:2로 저장되고, Apple은 여러 번 디코딩과 재인코딩을 거쳐도 눈에 띄는 손실이 없도록 설계했다고 설명합니다. 대신 파일이 큽니다.

배포 파일은 시청자가 재생할 최종본입니다. 유튜브는 업로드 형식으로 MP4 컨테이너, H.264 High 프로필, 4:2:0 크로마 서브샘플링, 가변 비트레이트를 권장합니다. 작고 어디서나 재생되지만, 이 파일을 다시 편집 재료로 쓰면 압축을 한 번 더 거치면서 화질이 깎입니다. 게다가 유튜브 같은 플랫폼은 올린 파일을 다시 인코딩하므로, 업로드 파일은 이미 한 번 압축된 파일이 또 압축되는 구조입니다.

이런 파일이 필요할 때	고를 형식	확인할 것
편집·색보정 프로그램으로 넘길 원본	ProRes 422 HQ	QuickTime 형식, Format Options의 코덱
자막·로고처럼 배경이 투명해야 할 때	ProRes 4444 또는 PNG 시퀀스	Channels를 RGB + Alpha로
렌더가 길어 중간에 멈출 수 있을 때	이미지 시퀀스(PNG, TIFF 등)	멈춰도 끝난 프레임은 남음
유튜브·SNS 업로드, 클라이언트 시사	H.264 MP4	해상도·프레임레이트에 맞는 비트레이트

알파가 필요하다면 H.264는 처음부터 후보가 아닙니다. Apple ProRes 가운데 알파 채널을 지원하는 것은 ProRes 4444 계열뿐이므로, ProRes 422 HQ로 뽑으면 투명 배경이 사라집니다. Output Module Settings에서 Channels를 RGB + Alpha로 바꾸는 것도 잊지 마세요. Windows에서도 ProRes 내보내기는 2018년 말 업데이트부터 지원됩니다.

Render Queue와 미디어 인코더(Media Encoder), 언제 무엇을 쓰나

예전에는 “애프터이펙트에서는 MP4가 안 나오니 Media Encoder로 보내라”가 정답이었지만, 지금은 Render Queue에서 H.264를 바로 뽑을 수 있습니다. Output Module Settings의 Format에서 H.264를 고르고 Format Options에서 비트레이트를 조정합니다. Adobe 문서에 따르면 새로 설치했거나 Output Module 환경설정을 초기화한 경우 기본 템플릿이 H.264 – Match Render Settings – 15 Mbps이고, 하드웨어와 소프트웨어 인코딩을 모두 지원합니다.

이럴 때	보낼 곳
ProRes·이미지 시퀀스 같은 중간 파일	Render Queue
알파 채널(RGB + Alpha)이 필요할 때	Render Queue
한 번 렌더로 마스터와 업로드본을 함께 뽑을 때	Render Queue (Output Module 여러 개)
인코딩하는 동안 AE에서 계속 작업할 때	Media Encoder
여러 배포 규격을 프리셋으로 한꺼번에 뽑을 때	Media Encoder
Output Module에 없는 형식·세부 옵션이 필요할 때	Media Encoder
두 경로의 색·밝기가 다르게 나올 때	Render Queue로 ProRes 마스터 → Media Encoder에서 H.264

Output Module 두 개로 마스터와 업로드본을 한 번에

Render Queue에서 특히 유용한 기능은 한 렌더 항목에 Output Module을 여러 개 붙이는 것입니다. Output To 왼쪽의 + 버튼으로 모듈을 하나 더 추가하면, 컴프를 한 번만 렌더하면서 ProRes 마스터와 H.264 업로드본을 동시에 만들 수 있습니다. 렌더를 두 번 돌릴 필요가 없습니다.

Media Encoder로 보낼 때 알아 둘 점

Composition > Add to Adobe Media Encoder Queue로 보내면 인코딩은 Media Encoder가 맡고, 그동안 애프터이펙트에서 다른 작업을 이어갈 수 있습니다. Adobe는 애프터이펙트 안에 들어 있는 인코딩 설정 창이 독립 실행형 Media Encoder의 기능을 전부 제공하지는 않는다고 밝히고 있으니, 원하는 형식이나 세부 옵션이 Output Module에 없다면 Media Encoder로 보냅니다.

한 가지 알아 둘 점이 있습니다. 애프터이펙트는 Media Encoder에 프레임을 Dynamic Link로 넘기고, Dynamic Link는 들어오는 프레임을 Rec.709로 가정합니다. 그래서 같은 컴프라도 Render Queue로 뽑은 파일과 Media Encoder로 뽑은 파일의 밝기와 색이 다르다는 보고가 사용자 커뮤니티에 꾸준히 올라옵니다. 두 경로의 결과가 다르다면 Render Queue로 ProRes 마스터를 한 번 뽑고, 그 파일을 Media Encoder에 불러와 H.264로 인코딩하세요. 렌더는 한 번, 인코딩은 필요한 만큼 하게 되고 비교 기준도 하나로 고정됩니다.

업로드 후 화질이 뭉개질 때: 비트레이트와 그라데이션

유튜브에 올린 영상이 뭉개진다면 먼저 업로드 파일의 비트레이트가 해상도와 프레임레이트에 맞는지 봅니다. 유튜브 권장값은 SDR 기준 1080p 8Mbps(48~60fps는 12Mbps), 1440p 16Mbps(24Mbps), 4K 35~45Mbps(53~68Mbps)입니다. 1080p라면 애프터이펙트의 15Mbps 프리셋으로 충분하지만, 4K를 15Mbps로 뽑으면 권장값에 한참 못 미칩니다. 4K 30fps는 40Mbps 프리셋, 4K 60fps는 그보다 높게 직접 설정합니다.

프레임레이트도 확인합니다. 유튜브는 원래 프레임레이트 그대로 인코딩해 올리라고 권합니다. Render Settings의 Frame Rate가 컴프와 다르게 잡혀 있으면 움직임이 끊기거나 프레임이 섞여 보일 수 있습니다.

비트레이트를 충분히 줬는데도 하늘이나 비네팅 같은 부드러운 그라데이션에 계단이 생긴다면 비트레이트보다 8비트 배포 형식의 한계일 가능성이 큽니다. 유튜브 권장 형식은 4:2:0이고, 플랫폼이 다시 압축하면서 미세한 톤 차이가 뭉개집니다. 이 경우 비트레이트를 더 올리기보다 인코딩 전에 약한 노이즈나 그레인을 얹어 계단을 흩뜨리는 편이 효과적입니다. 원인과 처리 순서는 밴딩이 생기는 4가지 지점에, 8비트와 16비트의 차이는 8bit·16bit·32bit 차이에 정리했습니다.

업로드 후 색이 빠져 보일 때: 파일이 바뀐 걸까, 보는 쪽이 다른 걸까

애프터이펙트에서는 진하던 색이 업로드하거나 다른 재생기로 열었더니 물빠진 듯 밝아 보이는 경우가 흔합니다. 여기서 바로 프로젝트 색 설정을 바꾸면 원인을 놓치기 쉽습니다. 먼저 두 경우를 가릅니다. 렌더한 EXR을 불러온 순간부터 색이 다르다면 내보내기가 아니라 입력 해석 문제이니 애프터이펙트 EXR 색 맞추기를 먼저 보세요.

렌더한 파일을 애프터이펙트로 다시 불러와 원본 컴프와 같은 프레임을 띄웁니다. Info 패널을 열고 어두운 부분, 중간 톤, 밝은 부분 몇 곳에 마우스를 올려 RGB 값을 비교합니다. H.264는 4:2:0 8비트로 압축되므로 한두 단계 차이는 정상입니다. 어두운 부분이 눈에 띄게 올라가 있는 식으로 값이 크게 다르면, 파일 자체가 바뀐 것입니다. 이때는 내보내기 경로를 의심합니다. Media Encoder로 보낸 파일과 Render Queue에서 뽑은 파일을 같은 방법으로 비교해 보고, 프로젝트에서 색 관리를 켰다면 Output Module Settings의 Color 탭에 어떤 출력 프로파일이 걸려 있는지 확인합니다.

값이 거의 같은데 재생기에서만 다르게 보인다면 파일은 멀쩡하고 보여 주는 쪽의 해석이 다른 것입니다. 모니터와 웹이 주로 쓰는 sRGB와 영상 규격인 Rec.709는 원색은 같지만 밝기 곡선을 다루는 방식이 달라, 같은 값도 재생 환경에 따라 조금 다르게 보일 수 있습니다. 두 규격의 차이는 Rec.709와 sRGB는 같은 걸까?에서 설명했습니다. 유튜브는 색 공간 정보가 비어 있으면 BT.709로 가정하고, 풀 레인지 영상은 리미티드 레인지로 변환한다고 밝히고 있습니다.

확인은 실제 시청 환경에서 합니다. 5~10초짜리 테스트 구간을 같은 설정으로 뽑아 일부 공개로 올리고, PC 브라우저와 휴대폰에서 원본 컴프와 비교하세요. 한 재생기에서만 다르게 보인다면 그 재생기의 문제이고, 모든 곳에서 같은 방향으로 틀어진다면 파일이나 프로젝트 설정 쪽을 다시 봅니다.

내보내기 전 점검 순서

• 역할 정하기: 이 파일이 다시 쓸 마스터인지, 올릴 배포본인지 먼저 정합니다. 둘 다 필요하면 Output Module을 두 개 붙입니다.
• 실제 코덱 확인: Output Module Settings에서 Format과 Format Options를 열어 봅니다. 템플릿 이름만 믿지 않습니다.
• 알파: 투명 배경이 필요하면 ProRes 4444나 PNG 시퀀스, Channels는 RGB + Alpha로 둡니다.
• 비트레이트: 1080p는 15Mbps 프리셋, 4K는 40Mbps 이상. 60fps라면 한 단계 높게 잡습니다.
• 프레임레이트와 오디오: Render Settings의 Frame Rate를 컴프와 맞추고, 소리가 없으면 Audio Output을 끕니다.
• 테스트 업로드: 긴 영상은 짧은 구간을 먼저 올려 화질과 색을 확인한 뒤 전체를 뽑습니다.

마스터는 크게 한 번, 배포본은 목적에 맞게 작게. 이 두 파일을 나눠 두면 용량 문제와 재인코딩 손실을 함께 줄일 수 있고, 업로드 뒤 문제가 생겨도 마스터에서 다시 인코딩하면 되므로 긴 렌더를 처음부터 다시 돌리지 않아도 됩니다.