ACES 색상 관리: Academy Color Encoding System

소개

"ACES color"나 "Academy Color Encoding System"을 검색해 보셨다면, 짧은 답은 이렇습니다. ACES는 카메라, 3D 렌더러, 컴포지팅 패키지 등 출처와 관계없이 프로덕션의 모든 이미지에 색상이 무엇을 의미하는지에 대한 하나의 공통 기준을 제공하는 무료 개방형 프레임워크입니다. 영화예술과학아카데미(Academy of Motion Picture Arts and Sciences)가 10년 넘게 개발하고 유지해 왔으며, 2025년 8월 개방형 기술 운영 위원회 아래 Academy Software Foundation(ASWF)으로 이관되었습니다 (Academy 보도자료, 2026년 10월 13일 확인).

이 가이드는 ACES를 쉬운 말로, 그러나 부정확하지 않게 설명합니다. 주요 컬러 스페이스, 입력 및 출력 트랜스폼, ACES 2.0에서 달라진 점, 그리고 OpenColorIO(OCIO)가 3D 소프트웨어 안에서 ACES를 어떻게 전달하는지를 다룹니다. 이어서 대부분의 해설이 건너뛰는 부분, 즉 씬이 내 워크스테이션을 떠나 다른 머신에서 렌더링될 때 색상에 어떤 일이 생기는지와 작업을 제출하기 전에 확인할 체크리스트를 다룹니다. 렌더링 자체가 무엇인지는 렌더링 기본 개념 가이드를 참고하세요.

ACES 한눈에 보기
정식 명칭	Academy Color Encoding System
관리 주체	Academy Software Foundation (2025년 8월부터)
1차 출처에서 확인한 최신 릴리스	ACES 2.0 (2025년 4월 4일)
핵심 컬러 스페이스	ACES2065-1, ACEScg, ACEScct
3D 소프트웨어에서의 전달 수단	OpenColorIO(OCIO) 구성 파일

ACES란 무엇이며 어떤 문제를 해결하는가

Academy는 ACES를 영화 제작의 전 과정에 걸친 색상 관리와 이미지 교환을 위한 오픈 소스 프레임워크로 설명합니다. 구성 요소는 세 종류입니다. 인코딩(컬러 스페이스), 트랜스폼(이미지를 ACES로 옮기고 ACES에서 디스플레이로 옮기는 수학적 변환), 그리고 ACES Metadata File(AMF)과 Transform IDs 같은 사양입니다. ACES2065-1은 SMPTE ST 2065-1:2021로 표준화되어 있으며, ACES 문서에 따르면 수십 개 회사가 자사 도구에 ACES 구성 요소를 적용했습니다 (ACES 문서, 2026년 10월 13일 확인).

문제는 단순합니다. 모든 장치는 픽셀 값이 무엇을 의미하는지에 대해 저마다 다른 기준을 갖고 있습니다. 카메라는 제조사 고유의 인코딩으로 기록하고, 텍스처는 sRGB로 들어오며, 렌더러는 자체 작업 스페이스에서 계산하고, 모니터마다 색 영역(gamut)도 조금씩 다릅니다. 공통 기준이 없으면 같은 숫자가 장소마다 다른 색상을 뜻하게 됩니다. ACES는 일종의 계약 역할을 합니다. 각 소스는 알려진 트랜스폼을 통해 공통 기준으로 한 번 변환되고, 작업은 그 안에서 이루어지며, 결과물은 알려진 트랜스폼을 통해 각 디스플레이로 매핑됩니다. 렌더 결과를 더 좋아 보이게 만드는 필터가 아닙니다. ACES의 가치는 일관성에 있으며, 씬이 머신 사이를 오갈 때 위험해지는 것이 바로 이 일관성입니다.

핵심 컬러 스페이스: ACES2065-1, ACEScg, ACEScct

스페이스	프라이머리	인코딩	주요 용도
ACES2065-1	AP0	선형	기본 ACES 인코딩(SMPTE ST 2065-1)
ACEScg	AP1	선형, 16비트 또는 32비트 부동소수점	CG 렌더링 및 컴포지팅
ACEScct	AP1	준로그, 0.0078125 미만은 선형 toe 구간	컬러 그레이딩, 소프트웨어 내부용

출처: ACES2065-1, ACEScg, ACEScct 페이지, 2026년 10월 13일 확인.

ACEScg는 선형이며 씬 리퍼러드(scene-referred) 방식입니다. 값이 상대 노출을 직접 나타냅니다. 음수 값도 유효하므로 가능하면 유지해야 하고, 1.0보다 훨씬 큰 값도 정상이므로 의도적인 색보정 단계가 아니라면 클램프하지 않아야 합니다.
ACEScg는 CG 계산 방식 때문에 존재합니다. 문서에 따르면 CGI 계산은 RGB를 반사율처럼 취급하는 경우가 많은데, 이 방식은 매우 넓은 AP0 프라이머리와 잘 맞지 않습니다. ACEScg는 더 작은 AP1 프라이머리(red 0.713, 0.293, green 0.165, 0.830, blue 0.128, 0.044)와 동일한 화이트 포인트(CIE xy 0.32168, 0.33767)를 사용합니다. 두 스페이스 사이의 변환은 고정된 행렬입니다.
ACEScct는 렌더링용 스페이스가 아닙니다. 문서는 이를 소프트웨어나 하드웨어 내부에서만 쓰이는 임시(transient) 스페이스라고 설명합니다. 렌더러는 ACEScg에서 작업하고, 그레이딩 도구는 ACEScct로 전환할 수 있습니다.

실무 원칙은 이렇습니다. 렌더링과 컴포지팅은 ACEScg에서 진행하고, ACES2065-1은 스튜디오가 요청할 때 사용하는 교환용 형식으로 취급합니다.

입력 트랜스폼과 출력 트랜스폼: 파이프의 양 끝

외부 세계와 ACEScg 작업 스페이스 사이에는 두 종류의 트랜스폼이 있습니다.

**입력 트랜스폼(Input transform)**은 소스를 작업 스페이스로 변환합니다. 텍스처에는 저장된 방식에 맞는 트랜스폼이 필요하며, 컬러 이미지는 대개 sRGB입니다. 3D 소프트웨어에서는 각 이미지 노드의 입력 컬러 스페이스(input color space) 필드가 이에 해당합니다.
**출력 트랜스폼(Output transform)**은 씬 리니어(scene-linear) ACES 데이터를 디스플레이용으로 준비하며, 이 과정에서 톤 매핑과 색 영역 매핑을 적용합니다 (About rendering, 2026년 10월 13일 확인). 3D 소프트웨어에서는 뷰포트와 렌더 창의 뷰 트랜스폼(view transform) 또는 디스플레이(display) 설정이 이에 해당합니다.

렌더팜 렌더링에서 가장 중요한 점은 뷰 트랜스폼은 이미지를 보기 위한 것이라는 사실입니다. 이미지 자체는 씬 리니어 상태로 유지되어야 합니다.

ACES 파이프라인: 텍스처와 카메라 영상은 입력 트랜스폼을 거쳐 렌더링용 ACEScg로 들어가고, 선형 EXR로 저장된 뒤 출력 트랜스폼이 이미지를 디스플레이로 매핑합니다

ACES 2.0에서 달라진 점

프로젝트 변경 이력(changelog)은 ACES 2.0의 릴리스 날짜를 2025년 4월 4일로 기록하고 있습니다 (aces-core CHANGELOG, 2026년 10월 13일 확인). ACES 문서는 이번 릴리스의 중심에 재설계된 렌더링 트랜스폼 모음이 있다고 설명합니다 (About ACES 2, 2026년 10월 13일 확인).

새로운 출력 트랜스폼은 ACES 1.x보다 톤 스케일이 덜 공격적이고, 미드톤 대비가 줄었으며, 하이라이트 롤오프가 더 부드럽습니다.
색 영역 매핑이 더 견고해져 클리핑 아티팩트가 줄었습니다.
특수한 디스플레이를 위한 파라미터, 디스플레이 프리셋, 최적화된 역변환(inverse transform)이 더 직관적입니다.

CG에는 무엇이 달라집니까? 우리가 확인한 페이지들은 변경이 파이프라인의 디스플레이 쪽 끝에 있다고 설명하며, ACEScg 인코딩 자체가 바뀌었다는 서술은 찾지 못했습니다. 실제로는 같은 씬 리니어 EXR이라도 ACES 1.x 출력 트랜스폼으로 보느냐 ACES 2.0 출력 트랜스폼으로 보느냐에 따라 화면에서 다르게 보일 수 있습니다. 워크스테이션에서는 한쪽으로 미리 보고 렌더팜 노드는 다른 쪽을 사용한다면, 같은 데이터의 서로 다른 룩을 비교하는 셈입니다.

버전 표기에 대한 참고 사항입니다. OpenColorIO 문서는 현재 OCIO 2.6 이상용 내장 구성을 aces-v2.1 라벨로 나열하며, OCIO 2.6.0은 2026년 10월 1일에 공개되었습니다 (OCIO Studio config 및 OCIO releases, 2026년 10월 13일 확인). 반면 우리가 확인한 ACES 자료에는 2.1 항목이 나와 있지 않으므로, 1차 ACES 출처에서 확인할 수 있었던 마지막 릴리스는 2.0으로 취급합니다. 버전을 추정하지 말고 사용 중인 구성 이름에 적힌 버전 문자열을 직접 확인하세요.

OpenColorIO가 소프트웨어 안에서 ACES를 전달하는 방식

ACES는 색상 계산을 정의하고, OpenColorIO는 애플리케이션이 이를 사용하는 방법입니다. OCIO는 Academy Software Foundation 프로젝트이며, 영화 제작을 겨냥한 완전한 색상 관리 솔루션으로 소개됩니다 (OpenColorIO 문서, 2026년 10월 13일 확인). 구성(configuration) 파일은 사용할 수 있는 컬러 스페이스, 애플리케이션이 의존하는 롤(예: 렌더링 스페이스), 디스플레이와 뷰를 정의합니다. 대부분의 애플리케이션은 환경설정에서 구성을 선택할 수 있으며, OCIO 환경 변수로 사용할 구성 파일의 경로를 지정할 수도 있습니다 (Using OCIO, 2026년 10월 13일 확인).

OCIO는 경로 대신 이름으로 참조하는 **내장 구성(built-in config)**도 제공합니다. CG 구성은 일반적인 DCC 앱을 위한 경량 세트이며, 예를 들어 ocio://cg-config-v4.0.0_aces-v2.0_ocio-v2.5가 있습니다. Studio 구성은 ACES 컬러 스페이스, 디스플레이, 뷰의 전체 세트를 담고 있으며, 예를 들어 ocio://studio-config-v4.0.0_aces-v2.0_ocio-v2.5가 있습니다. 이름은 구성 유형, 구성 버전, ACES 버전, 최소 OCIO 버전 순으로 읽습니다. 내장되어 있으므로 외부 LUT 파일이 필요하지 않습니다 (CG config 및 Studio config 페이지, 2026년 10월 13일 확인).

애플리케이션마다 설정 방식이 다릅니다. 각 벤더의 공식 문서가 설명하는 내용은 다음과 같습니다(모든 페이지는 2026년 10월 13일 확인).

애플리케이션	문서 내용	출처
Blender 5.2	내장 구성에 ACEScg 작업 스페이스, ACES 2.0 뷰 트랜스폼, ACES2065-1 또는 ACEScg로 EXR 저장 기능이 포함되어 있으며, 공식 ACES 구성은 `OCIO` 변수로 지정할 수 있음	매뉴얼
Maya 2022	ACEScg가 기본 렌더링 스페이스이고, 기본 뷰는 sRGB용 ACES 출력 트랜스폼이며, `OCIO`가 설정되어 있으면 구성 경로는 읽기 전용	Arnold for Maya, 환경설정
Cinema 4D (2026 SDK 매뉴얼)	OCIO 모드에서는 ACEScg 렌더 스페이스, sRGB 디스플레이, ACES 1.0 SDR 비디오 뷰를 사용하며, 각 문서가 자신의 OCIO 상태와 구성 경로를 저장하고, 레거시 모드도 있음	Maxon 개발자 매뉴얼
Redshift	ACES가 기본 렌더링 스페이스이며, `OCIO` 구성이 설정되어 있으면 이를 사용하고 없으면 함께 제공되는 ACES 구성을 사용	Redshift 문서

기본값은 애플리케이션과 버전에 따라 다르며, 색상을 좌우하는 설정 중 일부는 씬 파일 밖의 환경 변수나 내 디스크의 경로에 있습니다. 문제는 바로 여기서 시작됩니다. 2026년 Cinema 4D 주기에 대해서는 기능 요약을 참고하세요.

씬이 워크스테이션을 떠날 때 색상이 어긋나는 지점

내 컴퓨터에서 색상 관리는 눈에 보이지 않는 요소들이 받치고 있습니다. 환경 변수, 환경설정 파일, 1년 전에 만들어 둔 폴더의 구성 파일 같은 것들입니다. 렌더 노드에는 씬이나 렌더팜이 제공하지 않는 한 이런 것이 없습니다. 풀 매니지드 렌더팜(render farm)에서는 프로젝트를 업로드하고 머신에 로그인하지 않은 채 프레임을 받기 때문에, 데스크톱에서처럼 노드에 변수를 몰래 설정할 수 없습니다. 먼저 확인해 볼 만한 실패는 네 가지입니다.

1. 구성(OCIO config)이 다르거나 없는 경우. OCIO 변수는 씬 파일이 아니라 그것을 설정한 머신의 환경에 존재하며, Cinema 4D 문서는 구성의 경로를 저장합니다. 내 워크스테이션의 드라이브를 가리키는 경로는 씬을 여는 머신이 같은 파일을 읽을 수 있을 때만 의미가 있습니다. 읽을 수 없으면 애플리케이션이 알 수 없는 컬러 스페이스를 보고하거나 다른 구성으로 대체할 수 있고, 그 결과는 승인한 이미지와 더 이상 일치하지 않습니다. 서로 다른 ACES 버전을 가진 구성도 같은 문제를 더 눈에 띄지 않는 형태로 일으킵니다.

2. 텍스처의 입력 컬러 스페이스 태그가 잘못된 경우. JPEG, PNG 같은 컬러 텍스처는 sRGB로, 선형 HDR 이미지는 씬 리니어로, 데이터 맵(노멀, 러프니스, 마스크)은 raw 또는 non-color로 읽어야 합니다. Autodesk의 Arnold for Maya 페이지가 바로 이 구분을 권장하며, Redshift 문서는 자동 변환이 틀릴 수 있다고 경고하므로 각 에셋을 확인해야 합니다. 잘못된 태그는 스스로 드러나지 않습니다. 색상이 바랜 듯하거나 너무 어둡게 보이거나, 러프니스 맵 하나가 조용히 머티리얼을 바꿔 놓기도 합니다. 렌더팜은 씬에 적힌 대로 프레임마다 그대로 렌더링합니다.

3. 뷰 트랜스폼이 출력에 구워진(baked) 경우. Maya 문서에 따르면 Apply Output Transform to Renderer를 켜지 않는 한 OCIO 뷰는 렌더링된 이미지 파일에 적용되지 않습니다. 프레임에 디스플레이 트랜스폼이 구워져 있는데 컴포지터가 또 하나를 적용하면 이미지가 두 번 변환되어 대비가 뭉개지고 하이라이트가 클리핑되며, 되돌리기도 어렵습니다.

4. 선형 EXR 대신 디스플레이 리퍼러드 8비트로 출력한 경우. OpenEXR은 고동적범위(HDR) 씬 리니어 이미지 데이터를 표현하도록 설계되었습니다 (OpenEXR, 2026년 10월 13일 확인). 8비트 PNG나 JPEG는 디스플레이용으로 준비된 값을 담고 있어 ACEScg가 기대하는 1.0 초과 값을 담을 수 없습니다. 따라서 실제 작업을 8비트로 렌더링하면 하이라이트 디테일과 재보정 여지를 잃게 됩니다. 멀티 레이어 EXR 파일의 구조는 EXR 및 Cryptomatte 가이드에서 다룹니다.

워크스테이션과 렌더팜 사이에서 색상이 어긋나는 네 가지 경우: 구성 불일치, 잘못된 입력 스페이스, 구워진 뷰 트랜스폼, 8비트 출력

일관된 색상을 위한 제출 전 체크리스트

일곱 가지 항목을 확인하는 데는 몇 분이면 충분하며, 800번째 프레임에서 불일치를 발견하는 것보다 훨씬 적은 비용이 듭니다.

구성을 기록해 두세요. 씬이 내장 ocio:// 이름을 사용하는지 파일 경로를 사용하는지 적어 두고, 이름에서 ACES 버전을 읽고, 워크스테이션의 OCIO 변수가 구성을 제공하는지 확인합니다. 이 변수는 씬과 함께 이동하지 않습니다.
프로젝트 안에서 작업 스페이스를 설정하세요. 기본값에 의존하지 말고 렌더 스페이스를 명시적으로 선택합니다(대부분의 CG 파이프라인에서는 ACEScg). Cinema 4D에서는 문서가 레거시 모드일 수 있다는 점을 기억하세요.
모든 텍스처의 태그를 확인하세요. 컬러 이미지는 sRGB, 선형 HDR은 씬 리니어, 데이터 맵은 raw로 지정합니다. 몇 개의 머티리얼은 샘플로 점검합니다.
뷰 트랜스폼은 보기 용도로만 사용하세요. 파이프라인에서 필요하지 않다면 출력에 디스플레이 트랜스폼이 구워지지 않았는지 확인합니다.
실제 작업은 씬 리니어 EXR로 출력하세요. 8비트 형식은 미리보기에만 사용하고, 컴포지터를 위해 EXR의 컬러 스페이스를 기록해 둡니다.
프로젝트를 빠짐없이 패키징하세요. 프로젝트 폴더를 압축하지 않은 상태로, 씬 파일과 참조된 모든 에셋이 제자리에 있도록 업로드합니다. 커스텀 또는 스튜디오 구성을 사용한다면 미리 렌더팜에 알려 주세요.
프레임 하나를 테스트로 렌더링하세요. 워크스테이션 렌더와 렌더팜 렌더를 같은 뷰어에서 같은 뷰 트랜스폼으로 열고, 눈으로 보는 것은 물론 컬러 피커로 몇몇 픽셀 값도 비교합니다. 샘플링이나 디노이징으로 인한 작은 차이는 정상이지만, 색조가 눈에 띄게 바뀌는 것은 정상이 아닙니다.

일곱 단계 제출 전 색상 체크리스트: 구성, 작업 스페이스, 텍스처 태그, 뷰 트랜스폼, EXR 출력, 패키징한 프로젝트, 테스트 프레임

풀 매니지드 렌더팜에서 프레임 하나 테스트하기

Super Renders Farm은 풀 매니지드 클라우드 렌더팜이므로, 머신에 로그인하거나 소프트웨어를 설치하거나 라이선스를 직접 관리할 필요가 없습니다. 편리하지만, 그만큼 체크리스트가 중요한 이유이기도 합니다. 워크스테이션이 자체 환경에서 얻던 모든 것을 씬과 업로드하는 파일이 가지고 가야 하기 때문입니다.

커스텀 OCIO 설정에 대해 공개된 구성별 호환성 목록은 없습니다. 파이프라인이 스튜디오 고유의 구성에 의존한다면 업로드하기 전에 24/7 라이브 채팅 또는 supportcenter@superrendersfarm.com으로 지원팀에 문의하고, 구성 파일과 프레임 하나짜리 테스트를 함께 보내 주세요. 업로드 규칙 하나를 짚어 둡니다. 렌더팜은 압축 파일(.zip, .rar, .7z, .tar, .tar.gz)을 풀지 않으므로, 압축 파일 안에 있는 것은 렌더링되지 않습니다.

테스트 프레임은 작은 작업입니다. 신규 계정에는 $25 상당의 무료 Render Credits가 제공되며, 사용량이 청구되는 방식은 요금 페이지에서 설명합니다. Cinema 4D와 Redshift 씬의 작업 제출 방법은 Cinema 4D 클라우드 렌더팜 페이지에 설명되어 있으며, Redshift, Maya, Blender 페이지에서 각 애플리케이션을 다룹니다.

FAQ

Q: ACES는 무엇의 약자인가요? A: ACES는 Academy Color Encoding System의 약자로, 영화예술과학아카데미가 만들고 2025년 8월부터 Academy Software Foundation이 관리하는 색상 관리 및 이미지 교환용 개방형 프레임워크입니다.

Q: ACES2065-1과 ACEScg의 차이는 무엇인가요? A: 둘 다 선형이며 화이트 포인트를 공유합니다. ACES2065-1은 넓은 AP0 프라이머리를 사용하는 SMPTE ST 2065-1 정의의 기본 인코딩입니다. ACEScg는 더 작은 AP1 프라이머리를 사용하며 CG 렌더링과 컴포지팅을 위한 작업 스페이스입니다.

Q: 렌더팜을 쓰려면 ACES가 꼭 필요한가요? A: 아닙니다. 단순한 선형 sRGB 파이프라인을 포함해 일관된 색상 파이프라인이라면 무엇이든 가능합니다. 중요한 것은 작업에 관여하는 모든 머신에서 씬, 텍스처, 출력 설정이 명시적이고 동일하다는 점입니다. ACES가 널리 쓰이는 이유는 문서화된 공통 표준이기 때문입니다.

Q: ACES 2.0에서는 무엇이 달라졌나요? A: 핵심 변화는 더 부드러운 톤 스케일과 더 견고한 색 영역 매핑을 갖춘, 재설계된 렌더링 및 출력 트랜스폼 모음입니다. 프로젝트 변경 이력에는 릴리스 날짜가 2025년 4월 4일로 기록되어 있습니다. 우리가 확인한 문서는 새로운 ACEScg 인코딩이 아니라 파이프라인의 디스플레이 쪽 끝의 변경을 설명합니다.

Q: 렌더팜에서 렌더링한 결과가 워크스테이션과 다르게 보이는 이유는 무엇인가요? A: 흔한 원인은 OCIO 구성이 다르거나 없는 경우, 텍스처의 입력 컬러 스페이스 태그가 잘못된 경우, 뷰 트랜스폼이 출력에 구워진 경우, 8비트 출력 형식을 사용한 경우입니다. 이 순서대로 확인한 다음, 프레임 하나를 테스트로 렌더링해 같은 뷰어에서 워크스테이션 렌더와 비교하세요.

Q: EXR과 PNG 중 어느 쪽으로 렌더링해야 하나요? A: 실제 작업은 씬 리니어 EXR로 렌더링하고, 디스플레이 트랜스폼은 확인과 최종 납품용으로 남겨 두세요. PNG나 JPEG는 미리보기에만 사용하는 것이 좋습니다. 8비트 파일은 디스플레이용으로 준비된 값을 담고 있어 1.0을 넘는 값을 표현할 수 없기 때문입니다.

Q: Super Renders Farm은 커스텀 OCIO 구성을 지원하나요? A: 커스텀 구성에 대해 공개된 호환성 목록은 없습니다. 파이프라인에서 커스텀 구성을 사용한다면 업로드하기 전에 24/7 라이브 채팅 또는 이메일로 지원팀에 문의하고, 워크스테이션 렌더와 비교할 수 있도록 프레임 하나짜리 테스트를 함께 보내 주세요.