# 아트
> 데이터는 완비인데 시각 자산이 0이었습니다. 그리고 가독성을 고치려고 건 게이트가 가독성을 더 나쁘게 만들었습니다.
- 수치: ΔY 0.22
- 상태: wip
- 사람이 보는 화면: https://aitryed.com/ko/built/moon-studio/wuxia/art/
- 반대 언어: https://aitryed.com/en/built/moon-studio/wuxia/art/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt
---
**데이터는 다 갖춰져 있는데 «그림이 0장»이었습니다. 그리고 보기 좋게 만들려고 건 장치가 오히려 더 나쁘게 만들었습니다.**
## 상황부터
초식 44개, 신물 26개. **데이터는 완비**였습니다. 이름도 있고 수치도 있고 관계도 있습니다.
**그림이 0장이었습니다.**
이게 혼자 만들 때의 실제 모습입니다. **코드와 데이터는 꽤 빨리 차는데, 그림은 안 찹니다.**
## 규칙 하나 — 「명도가 먼저, 색은 나중」
색을 고를 때 보통 **색상**부터 봅니다. 「이 계열은 파랑, 저 계열은 빨강」처럼요.
그런데 화면에서 실제로 중요한 건 **밝고 어두움**입니다. 사람 눈이 **밝기 차이로 물체를 구분**하기 때문입니다.
색만 다르고 **밝기가 비슷하면 안 갈립니다.** 특히 화면이 복잡할 때요.
그래서 **밝기를 먼저 정하고 색을 나중에** 올립니다.
## 그리고 여기서 값을 치렀습니다 — 「고치려고 건 장치가 더 나쁘게 만들었습니다」
이 글에서 제일 중요한 대목입니다.
가독성이 나빠서 **자동 검사를 하나 걸었습니다.** 「색 대비가 기준 이하면 경고」 같은 것이었습니다.
그럴듯합니다. 그런데 **결과가 더 나빠졌습니다.**
이유는 이렇습니다. 그 검사는 「두 색의 대비」를 재는데, 제가 고치려던 문제는 「화면 전체에서 구분이 되나」였습니다.
**재는 것과 고치려는 것이 달랐습니다.**
그래서 검사를 통과시키려고 색을 조정하다 보니, **개별 대비는 좋아지는데 전체 화면은 더 지저분**해졌습니다. 다들 강해지니까 **아무것도 튀지 않게** 됐습니다.
> **대신 재는 지표(프록시)를 잡을 때, 그 지표가 진짜 문제와 같은 방향인지 먼저 확인해야 합니다.** 아니면 지표를 좋게 만들수록 문제가 나빠집니다.
## 그리고 「색을 배정했는데 왜 안 달라 보이나」
같은 문제의 다른 얼굴입니다.
계열마다 색을 배정했는데 **화면에서 안 달라 보였습니다.**
원인이 **밝기가 다 비슷했던 것**이었습니다. 색은 넷인데 **밝기는 사실상 하나**였습니다.
이건 **색 목록만 봐서는 안 보입니다.** 목록에서는 넷이 확실히 다릅니다. **화면에 올려야** 보입니다.
## 그래서 「체계가 색을 배정합니다」
사람이 하나씩 고르지 않고, **규칙이 배정**하게 바꿨습니다.
| | 사람이 고르면 | 체계가 배정하면 |
|---|---|---|
| 하나씩 볼 때 | 예쁨 | 예쁨 |
| **전체를 볼 때** | **비슷한 게 섞임** | **골고루 벌어짐** |
| 새로 추가할 때 | **또 고민** | **자동으로 자리 잡음** |
세 번째가 특히 큽니다. 계열이 늘어날 때마다 **「어떤 색을 줄까」를 다시 고민**하지 않아도 됩니다.
## 선언과 실제를 대조합니다
마지막 장치입니다. **「이렇게 하기로 했다」와 「실제로 그런가」를 기계가 대조**합니다.
규칙을 정해 놓고 **지켜지는지는 안 보는** 경우가 대부분입니다. 그리고 안 지켜져도 **아무 일도 안 일어납니다** — 조금씩 어긋나다가 나중에 「어? 이거 왜 이래」가 됩니다.
## 아직 못 한 것
**여전히 그림은 부족합니다.** 위의 것들은 전부 **「어떻게 만들 것인가」에 대한 정리**이지, **만든 것 자체는 아직 적습니다.**
혼자 만들 때 이 칸이 제일 느리게 찹니다. 그리고 **그 사실을 인정하고 「무엇을 안 만들지」를 정하는 게** 다음 할 일입니다.
## 여기부터는 자세한 기록입니다
이 프로젝트의 상태를 한 줄로 말하면 이렇다. **44초식·26신물·30NPC 데이터는 완비인데, 대응하는 시각 자산이 0인 상태가 오래 갔다.**
기획 문서에 "아트 톤" 한 줄을 적는 것과 그 톤이 3D 월드에 닿는 것은 완전히 다른 일이다.
## 명도가 먼저, 색은 나중
가장 자주 틀리는 순서다. **캐릭터 가독성은 색상이 아니라 명도 서열이 만든다.**
화면을 세 층으로 나눈다 — 플레이어(밝음) / 배경·바닥(중간) / 적(어두움). **어느 두 층도 명도가 겹치면 안 된다.**
실측 하한은 캐릭터와 바닥의 명도차 **0.22**다. 0.15 아래로 내려가면 실루엣이 배경에 묻힌다.
이 프로젝트를 재봤더니 **보스와 바닥의 명도차가 0.009**였다. 사실상 같은 명도고, 하필 그 장이 보스전이었다.
검증은 간단하다. **채도를 0%로 놓고 렌더한 스크린샷에서 층이 갈리면 통과.** 색을 빼도 읽혀야 한다. 그리고 한 포즈만 보면 안 된다 — 대기·공격·이동·피격·승리 다섯 포즈를, 히어로샷·게임플레이·인식한계 세 거리에서 본다.
## 프록시 지표가 진짜 문제를 악화시켰다
여기가 이 부문에서 제일 값비싼 교훈이다.
"적이 배경에 묻힌다"를 고치려고 **씬 전체 밝기 하한**을 테스트로 걸었다. 화면 평균 밝기가 일정 값 이상이어야 통과하게.
그 하한을 통과하려면 바닥을 밝게 올려야 했다. 그런데 바닥이 밝아지자 **캐릭터 명도 대역으로 들어왔고**, 보스와 바닥의 차이가 **0.039에서 0.009로 오히려 나빠졌다.**
게이트는 초록불이었다. 그동안 진짜 문제는 악화되고 있었다.
**가독성 게이트는 반드시 "캐릭터와 배경의 차이"를 직접 재야 한다.** 대신 재기 쉬운 걸 재면, 그 지표를 통과시키는 방향으로 손대다가 원래 문제를 키운다. 이건 아트 이야기가 아니라 **측정 이야기**다.
## 색을 배정했는데 왜 안 달라 보이나
열 개 스테이지에 색상이 이미 잘 배정돼 있었다. 13°부터 270°까지 넓게. 그런데 **전부 같은 회색으로 읽혔다.**
원인은 색상 미배정이 아니라 **채도**였다. 지각 채도 평균이 0.023. 인접한 아홉 쌍 중 다섯 쌍이 색차 0.02 미만 — 사람 눈으로 구분 불가였다. 채도를 2.4배 올리자 그 다섯 쌍이 전부 해소됐다.
**"색을 배정했는데 왜 안 달라 보이지"의 답은 대개 채도다.**
그리고 색 차이를 잴 때 **RGB 유클리드 거리를 쓰면 안 된다.** 명도에 지배돼서 색 차이를 못 잰다. 명도를 뺀 색상·채도 평면에서 재야 한다.
같은 이유로 진영 색을 "같은 급"으로 보이게 하려면 색상만 돌려서는 안 된다. 채도와 명도를 고정하고 색상만 바꾸면 노랑·시안이 빨강·파랑보다 훨씬 밝아 보인다. **진영 간 채도까지 맞춰야** 한다.
## 체계가 색을 배정한다
**아티스트가 스테이지마다 색을 고르면 반드시 한쪽으로 몰린다.** 체계가 배정하면 자동으로 흩어진다.
무협은 이걸 공짜로 얻는다 — **오행이 이미 세계관 안에 있다.** 원소를 스테이지에 1:1로 고정 배정하고, 각 스테이지의 지배색과 형태 언어를 거기서 도출하면 된다.
채도도 총량이 아니라 배분으로 관리한다. 배경과 바닥은 중저채도, **고채도 픽셀은 화면의 5% 이하**, 그리고 그 5%의 소유자를 미리 목록으로 못박는다. 소유자를 안 정하면 아무나 채도를 쓰고 결국 다 같이 칙칙해진다.
## 선언과 실제를 대조한다
문서에는 "3D 셀룩"이라고 적혀 있었다. 실제로 열어 보니 **바닥·벽·잡졸·정예 머티리얼이 전부 표준 PBR**이었고, 툰 셰이더는 캐릭터 일부에만 붙어 있었다.
**화면에서 가장 넓은 면적과 가장 많은 개체가 셀 셰이더를 안 타고 있었다.**
그래서 아트 톤 점검은 문서를 읽는 게 아니라 **머티리얼이 어느 셰이더를 쓰는지 세는 것**부터 한다. 이건 [검증](/ko/built/moon-studio/wuxia/qa/index.md)에서 반복해서 나오는 이야기와 같다 — 적혀 있는 것과 돌고 있는 것은 다르다.
로우폴리에 표준 PBR을 얹으면 최악의 조합이 된다. 로우폴리는 **양식화된 셰이딩이 있어야 의도로 읽히고**, 없으면 그냥 싸구려로 읽힌다.
## 아직 못 한 것
방법론과 실측은 생겼다. 못 한 건 다른 쪽이다.
혼자 만들면 병목이 코드가 아니다. 코드는 [AI가 쓴다](/ko/about/). 병목은 **캐릭터 하나, 애니메이션 한 벌**이고, 초식이 28개면 모션도 그만큼 필요하다.
그래서 생성 도구를 볼 때 관심사는 "이 도구 좋다"가 아니라 **어디까지 자동으로 나오고 어디부터 사람이 필요한가**다. 그리고 그 답을 내려면 도구만 봐서는 안 된다 — 도구 소개만 모으면 결론이 항상 "되긴 된다"로 끝난다. 그래서 **외주 견적을 같이 본다.** 값을 모르면 판단이 아니라 희망이 된다.
**그 한계선을 아직 실측한 적이 없다.** 지금 모여 있는 건 도구들이 스스로 주장하는 성능뿐이다. 이 사이트에서 반복하는 말 — 대상의 주장은 근거가 아니다 — 을 정작 여기에는 아직 적용 못 했다.