이름과 값이 같이 있으면 이름을 믿는다
추천색 표에는 navy, crimson 같은 그럴듯한 이름이 있었고, 아무도 값을 보지 않았습니다. 색만 바꾸지 않고, 계절 설명을 숫자 규칙으로 옮겨 모든 색을 검사하게 했습니다.
Clad는 질문 두 개와 사진 한 장으로 퍼스널컬러 결과 카드를 만드는 서비스입니다. 카드의 중심에는 계절마다 어울리는 색 여덟 개와 피할 색 네 개가 있습니다. 사람들이 결과에서 가장 오래 들여다보는 부분이고, 옷을 사거나 립을 고를 때 실제로 다시 꺼내 보는 부분입니다.
얼마 전 이 색을 전부 다시 골랐습니다. 몇 개가 틀려서만은 아니었습니다. 표를 들여다보니 색마다 붙은 이름이 그 아래의 값을 아무도 보지 않게 만들고 있었습니다. 이 글은 색 자체보다 그 구조에 관한 이야기입니다.
그럴듯한 이름 아래의 값
계절별 추천색은 웹 기본 색표의 값이었습니다. navy, crimson, steelblue처럼 브라우저가 이름만으로 알아듣는 색들입니다. 이름은 그럴듯했습니다. 표를 읽는 사람도, 검토하는 사람도 «겨울에 네이비, 맞지» 하고 넘어갔습니다. 그런데 그 값들은 실제 옷이나 화장품에서는 드문 색이었습니다. 겨울 쿨톤의 추천 여덟 색은 전부 그런 값이었습니다.
더 곤란한 것은 설명과의 어긋남이었습니다. 겨울에 대한 설명은 «선명하거나 무채색»이라고 말하면서, 추천색에는 탁한 청회색이 들어 있었습니다. 문장을 읽은 사람은 선명한 색을 기대하는데, 화면은 흐린 색을 보여 주고 있었습니다. 둘 다 같은 결과 카드 안에 있었습니다.
이것이 오래 남은 이유는 단순합니다. 표에 이름과 값이 나란히 있으면 사람은 이름을 읽습니다. 값은 숫자 몇 자리라서 읽어도 머릿속에 색이 떠오르지 않습니다. 그래서 검토는 이름을 상대로 이루어지고, 값은 한 번도 검토받지 않은 채 배포됩니다.
숨겨진 것은 없었습니다. 값은 처음부터 파일 안에, 이름 바로 옆에 있었고 누구든 열어 볼 수 있었습니다. 그래서 이 패턴은 이름을 붙여 둘 가치가 있습니다. 문제는 정보가 없었던 것이 아니라, 읽히는 단어 옆에 읽히지 않는 숫자가 놓였을 때 주의가 어디로 가느냐였습니다.
같은 이름, 다른 값
색값이 한 곳에만 있지 않았다는 것도 드러났습니다. 같은 이름의 색을 두 표가 각자 들고 있었고, 값이 서로 달랐습니다. 겨울의 피할 색 «베이지»는 한쪽 표에서는 베이지였는데, 화면에서는 거의 흰색으로 보였습니다.
이름이 같으니 누구도 둘이 다르다고 의심하지 않았습니다. 이름이 두 표를 같은 것처럼 보이게 붙여 두는 사이, 그 아래에서 값은 각자 갈라져 있었습니다. 지금 만들고 있는 앱 쪽에도 팔레트가 따로 있었습니다. 같은 이름 하나가 세 군데에서 세 가지 값을 가리킬 수 있는 구조였습니다.
색을 바꾸는 것으로는 부족했다
가장 쉬운 해결은 색을 더 나은 값으로 바꾸는 것이었습니다. 실제로 바꾸기도 했습니다. 이제 추천색과 피할 색은 모두 실제로 파는 옷감 염색이나 립의 색입니다. 하지만 바꾸기만 하면 같은 일이 다시 일어난다고 봤습니다. 다음에 누군가 색을 하나 더할 때도, 그 색은 여전히 이름으로 검토될 테니까요.
그래서 두 가지를 함께 했습니다. 먼저 각 계절의 설명문이 말하는 세 가지, 따뜻함과 밝기와 선명함을 숫자 규칙으로 옮겼습니다. 모든 추천색은 그 규칙을 통과해야 하고, 통과하지 못하면 검사가 실패합니다. 겨울에 탁한 청회색을 넣으면 이제 사람이 아니라 검사가 먼저 막습니다. 다음으로 색값이 한 표에서만 나오게 했습니다. 앱이 따로 들고 있던 팔레트도 같은 값으로 합쳤습니다.
둘은 같이 해야 의미가 있었습니다. 한 표를 상대로 규칙을 검사해도 화면이 다른 표에서 색을 가져오면, 검사는 아무도 보지 않는 값에 대해 통과합니다. 규칙은 값이 설명의 약속을 지키게 하고, 표를 하나로 두는 것은 검사받은 값이 곧 보이는 값이 되게 합니다. 어느 하나만 하면 이름이 숨을 틈이 남습니다.
어느 쪽을 기준으로 삼을지도 정해야 했습니다. 설명과 색이 어긋날 때 설명을 색에 맞춰 고칠 수도 있었습니다. 하지만 그 설명문은 진단 모델이 읽는 문장입니다. 문장을 고치면 판정이 흔들립니다. 그래서 설명은 그대로 두고 색이 설명을 따르게 했습니다. 기준은 하나여야 하고, 그 하나는 더 많은 것이 기대고 있는 쪽이어야 했습니다.
이름은 검사받지 않는다
이 일에서 남은 것은 색에 대한 교훈이라기보다 데이터에 대한 교훈입니다. 이름과 값이 같이 있는 데이터는 어디에나 있습니다. 설정 키와 실제 값, 상품명과 가격, 라벨과 수치. 그 모든 자리에서 사람은 이름을 믿고 값을 건너뜁니다. 이름이 그럴듯할수록 더 그렇습니다.
그래서 이름이 말하는 것을 값이 지키는지, 사람이 아니라 무언가가 확인하도록 묶어 두려고 합니다. 설명과 데이터가 서로를 검사하지 않으면, 값은 그럴듯한 이름 아래에서 조용히 틀린 채로 남습니다. 그리고 그 값을 처음 제대로 보는 사람은 대개 화면 앞의 사용자입니다.