유니티 색이 이상할 때 먼저 볼 3곳: Color Space, sRGB, 톤매핑

블렌더나 서브스턴스 페인터에서는 선명하던 색이 유니티에 들어오자 칙칙하거나 허옇게 물 빠져 보인다면, 머티리얼 값을 만지기 전에 색 설정 세 곳부터 확인하세요. 프로젝트의 Color Space, 텍스처마다 붙는 sRGB 체크, 카메라에 걸린 톤매핑입니다. 셋 중 하나만 어긋나도 같은 텍스처가 전혀 다른 색으로 보입니다.

Base Color를 더 진하게 칠해서 다시 내보내 봐도, 이번엔 블렌더 쪽이 지나치게 진해집니다. 문제는 색 자체가 아니라 숫자를 읽고 계산하고 화면에 옮기는 과정에 있기 때문입니다. 그런데 이 세 곳을 다 맞췄는데도 블렌더 화면과 똑같지 않은 경우가 있습니다. 그때 남은 차이가 무엇인지는 글 뒷부분에서 닫겠습니다.

유니티 색이 이상할 때, 증상으로 먼저 가르기

세 곳은 하는 일이 다릅니다. sRGB 체크는 텍스처 숫자를 어떻게 읽을지, Color Space는 빛을 어떤 숫자로 계산할지, 톤매핑은 계산 결과를 모니터에 어떻게 옮길지를 정합니다. 그래서 어긋난 곳에 따라 증상의 범위가 다릅니다. 텍스처 한 장만 이상하면 sRGB, 씬 전체의 음영이 이상하면 Color Space, 화면 전체의 대비와 채도가 이상하면 톤매핑 쪽입니다.

보이는 증상	먼저 볼 곳
특정 텍스처만 허옇고 파스텔처럼 물 빠졌다	그 텍스처의 sRGB 체크(꺼져 있음)
광택이 블렌더보다 흐리고 표면이 거칠다	스무스니스를 RGB 채널로 읽는 맵의 sRGB 체크(켜져 있음)
씬 전체에서 빛이 닿는 범위가 좁고 그림자 쪽이 급하게 어두워지며, 조명을 올리면 금방 하얗게 뜬다	Project Settings의 Color Space(Gamma)
화면 전체가 한 톤 가라앉고 채도가 빠졌다, 또는 대비가 과하고 색조가 바뀌었다	Volume의 Tonemapping(Neutral·ACES)
작은 팔레트 텍스처의 색이 아예 다른 색으로 번졌다	색 설정이 아니라 텍스처 압축(Compression)

에셋이 분홍색으로 보이거나, 텍스처 없이 회색 덩어리로 들어왔다면 이 글의 세 곳과는 다른 문제입니다. 분홍색은 셰이더와 렌더 파이프라인이 맞지 않을 때, 회색은 머티리얼에 텍스처가 연결되지 않았을 때 나타납니다. 이 글은 텍스처가 제대로 붙어 있는데 색감만 다를 때를 다룹니다.

1. Color Space: 유니티가 빛을 계산하는 방식 (1/3)

블렌더의 Cycles와 EEVEE, 서브스턴스 페인터의 뷰포트는 모두 빛의 양에 비례하는 선형(Linear) 숫자로 조명을 계산합니다. 유니티는 이 방식을 프로젝트마다 고를 수 있게 남겨 두었습니다. 위치는 Edit > Project Settings > Player > Other Settings > Rendering의 Color Space이고, 값은 Linear와 Gamma 둘 중 하나입니다(Unity 6 매뉴얼 기준). 블렌더·서브스턴스와 결과를 맞추려면 Linear여야 합니다.

Gamma에서는 이미 감마가 걸린 텍스처 값을 그대로 조명 계산에 넣습니다. 유니티 매뉴얼은 이 경우 빛의 세기가 커질수록 표면이 비선형으로 밝아져 여러 곳이 지나치게 밝아지고, 모델과 씬이 물 빠진 느낌이 날 수 있다고 설명합니다. 거리와 각도에 따른 빛의 감쇠도 달라져서, 매뉴얼 표현으로는 Linear에서 빛의 반경이 더 넓어 보입니다. 위 렌더의 세 번째 줄에서 빛을 덜 받는 면이 급하게 어두워지는 것이 Gamma 쪽 모습입니다. 왜 계산은 선형이어야 하는지는 Linear Workflow가 필요한 이유에서 따로 다뤘습니다.

Gamma로 오래 작업한 프로젝트를 Linear로 바꾸면 조명 세기와 반투명 블렌딩처럼 Gamma 화면에 맞춰 잡아 둔 결과가 함께 달라집니다. 바꾸기 전에 버전 관리에 커밋해 두고, 바꾼 뒤에는 조명부터 다시 봅니다. 반대로 원래 Linear인 프로젝트라면 이 칸은 통과하고 다음 단계로 갑니다.

2. sRGB (Color Texture): 텍스처 숫자를 읽는 방식 (2/3)

Color Space가 Linear여도 텍스처 한 장 한 장이 어떻게 읽히는지는 따로 정해야 합니다. 프로젝트 창에서 텍스처를 선택하면 Inspector의 Texture Import Settings에 sRGB (Color Texture) 체크가 있습니다. 유니티 문서는 이 칸을 텍스처가 감마 공간에 저장됐는지를 나타내는 값으로 설명하고, 알베도처럼 색을 담은 텍스처는 켜고 정확한 숫자가 필요한 텍스처는 끄라고 안내합니다.

이 칸이 틀리면 숫자가 한 방향으로 밀립니다. 색 텍스처에서 sRGB가 꺼지면, 화면에서 중간 회색으로 보이던 128이 선형 값 0.5로 읽혀 화면에는 188 근처로 밝게 나옵니다. 어두운 색일수록 더 많이 들떠서 텍스처 전체가 허옇게 물 빠집니다. 위 렌더의 두 번째 줄이 이 상태입니다. 128과 0.214, 188이라는 숫자가 어디서 나오는지는 sRGB와 Linear 글의 변환표에 정리해 두었습니다.

반대 실수도 칙칙함을 만듭니다. 러프니스, 메탈릭, 스무스니스, AO처럼 숫자 자체가 의미인 맵에 sRGB가 켜져 있으면 0.5가 약 0.214로 줄어 읽힙니다. AO는 틈이 더 진해지고, 셰이더 그래프처럼 스무스니스를 RGB 채널로 읽는 경우에는 스무스니스가 반 이하로 줄어 하이라이트가 퍼지고 표면이 거칠어 보입니다. 다만 URP Lit 기본값처럼 메탈릭 맵의 알파 채널에 든 스무스니스는 sRGB 변환을 받지 않습니다. 노멀 맵은 Texture Type을 Normal map으로 바꾸면 되고, sRGB로 읽혔을 때 무엇이 망가지는지는 Normal Map을 sRGB로 불러오면 망가지는 이유에서 다뤘습니다.

서브스턴스·블렌더에서 내보낸 맵	유니티 Texture Type	sRGB (Color Texture)
Base Color, Albedo, Emission	Default	켬
Metallic, Roughness, Smoothness, AO, Height	Default	끔
메탈릭·스무스니스 등을 한 장에 묶은 맵(HDRP의 Mask Map 등)	Default	끔
Normal	Normal map	(Normal map 타입이 처리)

하나 조심할 점이 있습니다. 유니티 문서에 따르면 Texture Import Settings 아래의 미리보기 창은 Linear 프로젝트에서도 감마 방식으로 텍스처를 보여 줍니다. 그래서 체크를 바꾼 결과는 미리보기가 아니라 씬에 놓인 모델에서 확인해야 합니다.

여기까지 맞췄는데 텍스처 한 장이 아니라 화면 전체가 여전히 한 톤 가라앉아 있다면, 텍스처를 읽는 쪽이 아니라 화면에 옮기는 쪽을 볼 차례입니다.

3. 톤매핑: 계산된 빛을 화면에 옮기는 방식 (3/3)

선형으로 계산한 빛은 1.0을 넘을 수 있지만 모니터는 0에서 1까지만 보여 줍니다. 이 넓은 범위를 화면에 접어 넣는 곡선이 톤매핑입니다. URP에서는 카메라 Inspector의 Post Processing 체크가 켜져 있고, 씬의 Volume 프로필에 Tonemapping이 들어 있을 때만 곡선이 적용됩니다. 둘 중 하나라도 빠지면 톤매핑은 없는 것과 같습니다.

URP의 Tonemapping Mode는 세 가지입니다. None은 곡선을 걸지 않습니다. Neutral은 색조와 채도는 최대한 건드리지 않고 범위만 다시 매핑합니다. ACES는 Neutral보다 대비가 강하고 실제 색조와 채도까지 바꿉니다. HDRP에는 여기에 직접 곡선을 잡는 Custom과 LUT를 넣는 External이 더 있습니다. 내장 렌더 파이프라인은 Post Processing 패키지(v2)의 Color Grading에서 같은 설정을 찾습니다.

위 비교에서 None은 공이 가장 진하지만 주황 공의 반사광이 노랗게 잘렸습니다. Neutral은 밝은 쪽을 눌러 담기 때문에 화면 전체가 한 톤 가라앉고 채도가 빠져 보입니다. 유니티의 Neutral 수식에 넣어 보면 선형 값 1.0이 약 0.63으로 내려가고, 중간 회색 0.18은 거의 그대로 남습니다. 하얀 벽과 밝은 색이 칙칙해 보이는 이유가 이 숫자에 있습니다. ACES는 위 비교에서 그림자가 더 깊어지고 노랑·주황의 색조가 옅게 바뀌었습니다.

URP 템플릿의 샘플 씬처럼 처음부터 Volume이 깔린 씬도 있고, 에셋스토어에서 받은 유니티 에셋의 데모 씬도 자기 Volume을 함께 들고 올 수 있습니다. 색이 갑자기 달라졌다면 Hierarchy에서 Volume 컴포넌트가 붙은 오브젝트부터 찾아보세요. Volume의 Tonemapping 체크를 잠시 끄고 화면이 블렌더 쪽으로 돌아오는지 보면, 톤매핑이 원인인지 바로 갈립니다.

세 곳을 다 맞춰도 블렌더와 다르다면: 보는 화면이 다릅니다

이제 처음의 질문으로 돌아갑니다. Linear도 맞고, sRGB도 맵마다 맞고, 톤매핑도 확인했는데 블렌더 화면과 여전히 다릅니다. 이 경우는 유니티가 틀린 것이 아닙니다.

블렌더와 유니티는 같은 숫자를 서로 다른 화면 변환으로 보여 주고 있습니다.

블렌더 4.0 이후 새 파일은 View Transform이 AgX로 시작합니다. AgX는 밝은 빛을 부드럽게 눌러 담는 대신 대비와 채도를 낮게 보여 주는 변환이고, 블렌더 AgX·Filmic·Standard 글에서 자세히 비교했습니다. 유니티 URP의 Tonemapping 목록에는 AgX가 없습니다. 서브스턴스 페인터는 또 다릅니다. Display Settings > Camera settings의 Tone mapping 기본값이 Linear라 1.0을 넘는 값을 그냥 자르고, ACES로 바꿀 수 있습니다. 세 프로그램이 각자 다른 화면을 기본으로 보여 주는 셈입니다.

그래서 맞추는 일은 색을 고치는 일이 아니라 기준 화면을 하나로 정하는 일입니다. 최종 결과가 유니티에서 보이므로 기준은 유니티로 잡고, 나머지 둘을 거기에 맞춥니다.

유니티 Tonemapping	블렌더 View Transform	서브스턴스 페인터 Tone mapping
None	Standard	Linear (기본값)
ACES	ACES 1.3 (5.0 이상, 가까운 짝)	ACES (가까운 짝)
Neutral	정확한 짝 없음	정확한 짝 없음

ACES 짝은 같은 계열의 곡선일 뿐 구현이 같지는 않으니, 나란히 놓았을 때 조금 남는 차이는 정상입니다. 블렌더 View Transform은 비교할 때만 바꾸고, 블렌더 렌더 자체가 결과물인 작업이라면 원래 설정으로 되돌립니다.

블렌더·서브스턴스와 유니티 결과를 맞추는 순서

1. 유니티 Color Space를 Linear로 확인합니다. Edit > Project Settings > Player > Other Settings > Rendering.
2. 텍스처마다 sRGB를 맞춥니다. 색 맵은 켜고, 숫자 맵은 끄고, 노멀은 Normal map 타입으로 둡니다.
3. 텍스처가 맞게 들어왔는지 조명 없이 봅니다. URP의 Unlit 셰이더 머티리얼에 Base Map만 꽂고 카메라의 Post Processing을 끈 화면에서 보면, 이미지 뷰어로 연 원본과 같은 색이어야 합니다. 여기서 다르면 아직 sRGB 단계 문제입니다.
4. 유니티 톤매핑 모드를 정합니다. None, Neutral, ACES 중 게임의 최종 화면으로 쓸 것을 고릅니다.
5. 서브스턴스와 블렌더의 화면을 그 모드에 맞춥니다. 위 짝 표대로 페인터의 Tone mapping과 블렌더의 View Transform을 바꿉니다.
6. 조명을 비슷하게 맞춘 뒤 비교합니다. 같은 HDRI를 쓰거나, 흰색 디렉셔널 라이트 하나처럼 단순한 조명에서 봅니다. 이 단계 뒤에 남는 차이는 색 설정이 아니라 렌더러와 조명의 차이입니다.

색을 숫자로 옮길 때도 함정이 있습니다. 블렌더 컬러 피커의 RGB 칸은 Linear로 표시될 수 있지만, Hex 칸은 항상 sRGB로 감마 보정된 값입니다. Linear 프로젝트의 유니티는 머티리얼 색을 감마 값으로 받아 내부에서 선형으로 바꾸므로, 블렌더의 Linear RGB 숫자를 그대로 옮겨 적으면 색이 어둡게 들어옵니다. 색을 옮길 때는 Hex 값을 복사합니다.

한 줄 정리

유니티 색이 칙칙하거나 물 빠져 보이면, 텍스처 한 장의 문제인지 화면 전체의 문제인지부터 가르고 Color Space, sRGB, 톤매핑 순서로 확인합니다. 그래도 블렌더와 다르면 기준 화면을 유니티로 정하고 블렌더의 View Transform과 서브스턴스의 Tone mapping을 거기에 맞춥니다.

유니티 색이 칙칙하면, 머티리얼보다 색 설정 세 곳부터.