VFX 스튜디오에서 일하다 보면 “OCIO 설정 확인해봤어요?”라는 말을 정말 자주 듣게 됩니다. **OpenColorIO(OCIO)**는 Maya, Nuke, Houdini처럼 서로 다른 프로그램에서도 색이 똑같이 보이게 만들어주는 색관리 시스템인데, 오늘은 이 OCIO가 정확히 무엇이고 어떻게 작동하는지 차근차근 풀어보겠습니다.
OCIO는 어디서 왔을까 – 탄생 배경과 오픈소스 이야기
OCIO는 원래 소니 픽처스 이미지웍스(Sony Pictures Imageworks)라는 VFX 스튜디오가 자기들 내부 파이프라인 문제를 풀기 위해 만든 도구였습니다. 문제는 간단했어요. 애니메이터는 Maya에서 작업하고, 컴포지터는 Nuke에서 작업하는데, 같은 이미지인데도 프로그램마다 화면에 보이는 색이 미묘하게 달랐던 거죠. 마치 같은 사진을 인화소마다 다른 조명 아래에서 보는 것과 비슷한 상황이었습니다.
이 문제를 해결하려고 이미지웍스는 “색 처리 규칙을 프로그램 안에 각각 넣지 말고, 하나의 설정 파일로 빼서 모든 프로그램이 그 파일을 참조하게 하자”는 아이디어로 OCIO를 개발했습니다. 이후 2015년경 오픈소스로 공개되었고, 지금은 리눅스 재단 산하의 **ASWF(Academy Software Foundation)**라는 단체가 관리하고 있어요. ASWF는 OCIO 외에도 USD, OpenEXR 같은 VFX 업계 핵심 오픈소스 프로젝트들을 함께 관리하는 곳으로, 특정 회사가 아니라 업계 전체가 공동으로 유지보수하는 구조라서 신뢰도가 높습니다.
OCIO가 실제로 하는 일 🎨
한마디로 정리하면, OCIO는 “이 색공간에서 저 색공간으로 어떻게 변환할지”에 대한 규칙집을 하나의 파일로 통일해주는 시스템입니다. 마치 여러 나라 사람이 모인 회의에서 동시통역사 한 명이 모두의 말을 같은 언어로 옮겨주는 것과 비슷해요. 통역사가 없으면 각자 자기 나라 말로 떠들다가 오해가 생기듯, OCIO가 없으면 각 프로그램이 자기 방식대로 색을 해석해서 결과물이 서로 어긋나게 됩니다.
구체적으로 OCIO는 이런 일을 담당합니다.
- 이미지를 불러올 때 어떤 색공간으로 인식할지 지정 (예: sRGB, ACEScg, Raw)
- 모니터에 뿌려줄 때 어떻게 변환할지 지정 (Display/View 트랜스폼)
- 작업 중간에 특정한 ‘룩’을 얹어서 미리보기를 만들 수 있게 지원
- 파일 이름 규칙만으로 자동으로 색공간을 추론
이 모든 규칙이 담긴 파일이 바로 config.ocio이고, 이 파일 하나만 여러 프로그램에 공유하면 어떤 소프트웨어에서 열어도 같은 색으로 보이게 되는 거예요.
config.ocio 파일 구조 살펴보기
config.ocio는 YAML 형식의 텍스트 파일이에요. 처음 열어보면 복잡해 보이지만, 핵심 구성 요소는 다섯 가지 정도로 나눌 수 있습니다.
| 구성 요소 | 역할 | 쉬운 비유 |
|---|---|---|
| roles | 프로그램이 특정 상황에서 기본으로 쓸 색공간 지정 (예: scene_linear, color_picking) | 회사에서 부서별 대표 담당자 지정 |
| colorspaces | 사용 가능한 색공간 목록과 각각의 변환 방식 정의 | 사전에 등록된 언어 목록 |
| displays / views | 모니터 종류별로 어떤 변환을 적용해 보여줄지 정의 | TV 종류에 맞는 화면 모드 설정 |
| looks | 특정 무드나 스타일을 입히는 추가 변환(선택적) | 사진 필터 프리셋 |
| file_rules | 파일명 패턴으로 색공간을 자동 판별하는 규칙 | 확장자만 보고 프로그램을 자동 실행하는 것 |
간단한 구조 예시는 이런 식입니다.
yaml
ocio_profile_version: 2
roles:
scene_linear: aces_interchange
color_picking: sRGB
default: sRGB
displays:
sRGB:
- !<View> {name: Standard, colorspace: sRGB}
colorspaces:
- !<ColorSpace>
name: sRGB
family: display
...실무에서는 이 파일을 직접 처음부터 쓰는 경우는 드물고, ACES 공식 config나 스튜디오에서 커스터마이징한 config를 가져다 씁니다.
OCIO 환경변수($OCIO) 설정하는 법
프로그램이 어떤 config.ocio 파일을 참조할지 알려주려면 $OCIO라는 환경변수를 지정해주면 됩니다. 이 환경변수 하나만 잡아주면 Maya든 Nuke든 Houdini든 같은 파일을 보게 되는 거죠.
리눅스나 macOS에서는 터미널에서 이렇게 설정합니다.
bash
export OCIO="/studio/pipeline/ocio/aces_1.3/config.ocio"윈도우에서는 시스템 환경 변수에 OCIO 키를 추가하고 값으로 config 파일 경로를 넣어주면 됩니다. 스튜디오 환경이라면 보통 렌더팜이나 각 워크스테이션의 환경설정 스크립트에서 자동으로 이 값을 세팅해두기 때문에, 아티스트가 직접 만질 일은 많지 않아요. 다만 개인 작업이나 프리랜서 환경에서는 이 설정을 빠뜨려서 색이 이상하게 보이는 경우가 종종 있으니 기억해두면 좋습니다.
OCIO v1과 v2, 무엇이 달라졌나
OCIO는 버전 1에서 버전 2로 넘어오면서 꽤 큰 변화를 겪었습니다. 실무에 영향을 주는 주요 차이는 다음과 같아요.
- GPU 처리 지원 강화: v2는 GPU 상에서 색 변환을 더 효율적으로 처리할 수 있도록 설계되어, Nuke나 실시간 뷰포트에서 반응 속도가 개선되었습니다.
- 빌트인 트랜스폼(Built-in Transforms): v2부터는 ACES 관련 변환 같은 표준 트랜스폼이 OCIO 라이브러리 안에 내장되어, 외부 룩업테이블(LUT) 파일 없이도 표준 변환을 바로 쓸 수 있게 되었습니다.
- 성능 개선: 캐싱과 최적화 로직이 개선되어 대규모 씬에서도 색 변환 연산 부담이 줄었습니다.
- 문법과 구조 변경: config 파일 문법이 일부 달라져서, v1용 config를 v2 프로그램에서 그대로 못 쓰는 경우가 있습니다(반대도 마찬가지예요).
즉, 단순히 숫자만 올라간 게 아니라 내부 동작 방식 자체가 상당히 개선된 버전이라고 보면 됩니다. 다만 정확히 어떤 프로그램이 몇 버전부터 v2를 기본으로 채택했는지는 소프트웨어별로 다르고 계속 업데이트되는 부분이라, 작업 전에 사용 중인 프로그램의 공식 문서로 현재 지원 버전을 확인하는 습관을 들이는 게 안전합니다.
어떤 프로그램들이 OCIO를 지원할까
OCIO는 이제 VFX·애니메이션 업계에서 사실상 표준처럼 자리 잡았습니다. 대표적으로 아래 프로그램들이 OCIO 색관리를 지원해요.
- Maya (컬러 매니지먼트 프리퍼런스에서 OCIO config 연동)
- Nuke (파운드리 제품군 전반에서 깊게 통합)
- Houdini
- Blender
- Substance Painter/Designer 계열
- DaVinci Resolve (컬러그레이딩 단계에서 활용)
프로그램마다 UI에서 색공간을 지정하는 메뉴 이름이나 위치는 조금씩 다르지만, 내부적으로 결국 같은 config.ocio 파일을 참조한다는 원리는 동일합니다.
스튜디오에서 config를 반드시 공유해야 하는 이유
한 프로젝트에 참여하는 아티스트들이 각자 다른 config.ocio를 쓰면 어떻게 될까요? 예를 들어 라이팅 아티스트는 config A를 쓰고 컴포지터는 config B를 쓴다면, 같은 EXR 파일을 열어도 두 사람 눈에 보이는 색이 완전히 달라질 수 있습니다. 이건 마치 같은 악보를 서로 다른 조율을 한 피아노로 연주하는 것과 같아서, 아무리 연주를 잘해도 결과물이 어긋날 수밖에 없어요.
그래서 스튜디오들은 프로젝트를 시작할 때 표준 config.ocio 파일을 하나 정해서 모든 부서, 모든 워크스테이션, 렌더팜에 동일하게 배포합니다. 보통 이 파일은 버전 관리 시스템(Git 등)으로 관리되고, 파이프라인 담당 부서(TD)가 프로젝트 요구사항에 맞춰 커스터마이징한 뒤 배포하는 경우가 많습니다.
자주 나는 오류 – config 버전 불일치 문제
실무에서 가장 흔하게 마주치는 문제는 config 버전이 서로 다를 때 색공간 이름이 달라지는 현상입니다. 예를 들어 어떤 config에서는 작업용 색공간 이름이 ACEScg인데, 다른(혹은 이전) config에서는 ACES - ACEScg처럼 표기가 다르거나, 아예 이름 자체가 다르게 정의된 경우가 있어요. 이럴 때 파일을 다른 config 환경에서 열면 “해당 색공간을 찾을 수 없습니다” 같은 오류가 뜨거나, 최악의 경우 오류 없이 조용히 엉뚱한 색공간으로 대체되어 렌더링되는 일도 생깁니다.
이런 문제를 예방하려면 아래를 습관화하는 게 좋습니다.
- 프로젝트 시작 시 config.ocio 파일 경로와 버전을 팀 전체에 공지하기
$OCIO환경변수가 올바른 경로를 가리키는지 작업 시작 전 확인하기- 외부 협업사와 파일을 주고받을 때는 config 파일도 함께 전달하기
- 렌더 메타데이터에 사용된 색공간 이름을 남겨서 나중에 추적 가능하게 하기
작은 습관이지만, 이걸 놓치면 며칠 걸려 렌더링한 결과물을 색공간 이름 하나 때문에 통째로 다시 뽑아야 하는 상황이 생길 수 있어요.
마무리
OCIO는 결국 “색을 어떻게 해석하고 보여줄지”에 대한 약속을 하나의 파일로 만들어, 서로 다른 프로그램들이 같은 언어로 대화하게 해주는 도구입니다. config.ocio의 구조(roles, colorspaces, displays/views, looks, file_rules)를 이해하고 $OCIO 환경변수 설정법만 알아둬도, 앞으로 색이 이상하게 나올 때 어디서부터 확인해야 할지 감이 잡힐 거예요.
자주 묻는 질문(FAQ)
Q1. OCIO와 ACES는 같은 건가요? 아니요, 서로 다른 개념입니다. ACES는 색공간과 색 변환에 대한 업계 표준 규격이고, OCIO는 그런 색 변환 규칙을 프로그램에서 실제로 적용할 수 있게 해주는 소프트웨어 도구예요. 흔히 OCIO config 안에 ACES 규격이 구현되어 있는 형태로 함께 쓰입니다.
Q2. config.ocio 파일은 어디서 구할 수 있나요? ACES 공식 저장소에서 배포하는 기본 config를 받아서 쓸 수도 있고, 소속 스튜디오에서 자체적으로 커스터마이징한 파일을 받아서 쓰는 경우가 대부분입니다. 개인 작업이라면 사용하는 프로그램에 기본 내장된 config를 그대로 써도 무방한 경우가 많아요.
Q3. $OCIO 환경변수를 설정하지 않으면 어떻게 되나요? 프로그램마다 다르지만, 보통 해당 소프트웨어에 내장된 기본 config를 대신 사용하게 됩니다. 문제는 이 기본값이 스튜디오의 표준 config와 다를 수 있다는 점이라, 협업 프로젝트에서는 반드시 환경변수를 명시적으로 지정해주는 게 안전합니다.
