색

팔레트

기본 팔레트는 기능별로 묶은 원시 색 값이다. 그룹마다 가장 어두운 900부터 가장 밝은 50까지 10단계가 있고, 대비 수준과 시각적 위계를 나누는 데 쓴다.

• Primary — 제목, 텍스트, UI 골격에 쓰는 어두운 기준색
• Accent — 상호작용 요소, 링크, 포커스 상태에 쓰는 브랜드 파랑
• Info — 안내성 피드백에 쓰는 부드러운 파랑. 브랜드 accent와 구분한다
• Neutral — 텍스트 위계, 테두리, 표면에 쓰는 회색 스케일
• Green / Yellow / Red — 성공, 경고, 에러 상태에 쓰는 상태 색

info와 accent를 나눈 이유

둘 다 파란색이고, 둘을 나누려면 팔레트 그룹이 하나 더 필요하다. 그래도 나눈 이유가 있다. 송금 화면에서 accent 파랑은 누르면 뭔가 할 수 있다는 뜻이고, info 파랑은 시스템이 알려 주는 내용이라는 뜻이다. 두 색이 같은 색조였을 때 사용자들은 안내 배너를 누르면 뭔가 될 거라 생각하고 눌렀다. 그래서 info를 회청색(600 단계 #3B82B8) 쪽으로 옮겨, 한눈에 다른 역할로 보이게 했다.

상태 색은 일부러 차분하게 둔다

상태 색은 흔히 쓰는 값보다 한두 단계 부드럽다. green-600은 채도 높은 #16A34A 대신 #22915A, red-600은 #DC2626 대신 #BB4A4A다.

송금 앱은 늘 상태를 보여 준다. 대기 중인 거래, 환율 알림, 인증 단계마다 상태 색이 붙는다. 채도를 끝까지 올리면 대시보드 전체가 비상 상황처럼 보인다. 상태 색을 차분하게 두어야 실패한 송금이나 반려된 서류 같은 진짜 에러가 다른 색 칩 열한 개에 묻히지 않고 눈에 띈다.

톤을 낮춘 값은 모두 AA 기준으로 다시 검증했다. 색을 부드럽게 하느라 대비를 희생한 경우는 없다.

일반적인 값에서 벗어난 neutral 두 단계

placeholder 대비는 실제 출시된 디자인 시스템에서 가장 흔한 AA 실패다. 리뷰하는 사람은 필드 용도를 이미 알고 있어서 리뷰에서 잘 드러나지도 않는다. 팔레트 단계에서 고쳐 두면 어떤 컴포넌트도 이 문제를 다시 만들 수 없다.

시맨틱 사용

컴포넌트는 원시 팔레트 값이 아니라 시맨틱 토큰을 참조한다. 이렇게 한 단계를 거치기 때문에 테마를 바꿀 수 있고, 시스템 전체에서 색의 의도가 일관되게 유지된다.

표면 층위

Senco는 표면을 최대 세 단계까지만 쌓는다. 다이얼로그 안 시트 안의 카드에 그때그때 아무 회색이나 쓰지 않도록, 여기서 한 번 정해 둔다.

규칙:

• 1단계는 라이트 모드에서는 그림자로, 다크 모드에서는 밝기로 띄운다. 라이트 모드는 흰색 위에 --ds-shadow-xs를 쓴다. 다크 모드에서는 거의 검은 바탕에 그림자가 보이지 않으므로, #0F172A 위에 더 밝은 #1E293B를 올려 단계를 구분한다.
• 1단계 표면 두 개를 겹치지 않는다. 카드 안에 카드가 필요하다면, 안쪽은 2단계 인셋이나 구분선으로 바꾼다.
• 그림자로 안 되는 일은 테두리가 맡는다. 2단계와 다크 모드에서는 --ds-border로 표면을 나눈다. 다크 모드에서는 높이만으로 부족하고, 고대비 모드에서는 높이로 구분이 아예 안 된다.
• --ds-white는 색이 아니라 시맨틱 토큰이다. 다크 모드에서는 #1E293B가 된다. 정말 흰색이어야 하는 곳에는 #FFFFFF를 직접 쓴다. 실제로 그런 곳은 --ds-on-accent뿐이다.

피드백 색

피드백 상태마다 배경, 테두리, 텍스트, 아이콘 토큰을 한 세트로 써서 신호를 일관되게 준다.

Warning 텍스트만 다른 상태처럼 800이 아니라 900 단계를 쓴다. 대비 때문이 아니라 시각적 무게 때문이다. yellow-800(#854D0E)은 yellow-50 위에서 6.46:1로 AA를 넉넉히 통과한다. 하지만 알림 목록에 쌓아 보면 800의 warning 텍스트가 옆의 success, error 텍스트보다 가벼워 보여서 한 단계 더 진하게 했다.

이 문서의 이전 버전은 800이 4.3:1로 기준 미달이라서 900을 쓴다고 설명했다. 사실이 아니었다. 노랑이 AA를 맞추기 가장 어려운 색조인 건 맞기 때문에 그럴듯해 보였고, 그래서 아무도 확인하지 않고 넘어갔다. 문장만 슬쩍 바꾸지 않고, 정정했다는 사실을 여기 남긴다.

전체 토큰 구조(base → semantic → state → component → platform → bridge)는 Tokens에 있다.

대비 검증

모든 색 조합은 WCAG 2.2 AA 기준(텍스트 4.5:1, UI 컴포넌트 3:1)으로 검증한다. 아래 비율은 모두 스크린샷에서 색을 뽑아 잰 값이 아니라, 실제로 배포되는 토큰 값으로 계산했다.

라이트 모드 (검증됨)

다크 모드 대비 검증은 Themes에 있다.

텍스트 외 대비

기준을 넘어야 하는 건 텍스트만이 아니다. WCAG 2.1 SC 1.4.11은 UI 컴포넌트와 의미를 담은 그래픽에도 3:1을 요구한다.

피드백 테두리 네 개는 알고 있고, 허용한 예외다. SC 1.4.11은 컴포넌트가 있다는 것, 또는 그 상태를 알려 주는 표시가 경계뿐일 때 적용된다. 피드백 알림은 옅은 색 배경, 700 단계 아이콘, 텍스트 라벨로 이미 스스로를 드러내고, 셋 모두 각자의 기준을 통과한다. 400 단계 테두리는 이미 구분되는 표면을 다듬는 역할일 뿐, 표면을 구분하게 해 주는 요소가 아니다. 테두리를 3:1에 맞추려면 600 단계까지 올려야 하는데, 그러면 알림이 옅은 색 상자가 아니라 테두리가 굵은 경고 상자처럼 보이고, 앞에서 정한 차분한 상태 색 원칙이 깨진다. 이 절충을 말없이 안고 가지 않고 기록해 둔다.

기본 상태 입력 테두리의 1.24:1이 두 번째 알고 있고, 허용한 예외다. SC 1.4.11은 경계 말고는 컨트롤이 있다는 걸 알 방법이 없을 때 적용된다. Senco 입력 필드는 항상 위에 라벨이 보이고 48px 높이의 채워진 컨트롤 영역이 있어서, 테두리 없이도 필드를 알아볼 수 있다. 테두리를 gray-400으로 진하게 해 봤더니, 필드가 많은 폼(연락처 주소 폼은 필드가 아홉 개다)이 철창처럼 보였다. 이 예외도 말없이 넘기지 않고 기록한다.

색만으로 신호를 주지 않는다

시스템의 모든 상태는 반드시 색 + 아이콘 + 텍스트 세 가지로 함께 표시한다.

남성 약 12명 중 1명은 색각 이상이 있다. 그중 제2색맹은 이 앱이 쓰는 초록/노랑/빨강 구분을 정확히 무너뜨린다. 시뮬레이션해 보면 green-600과 yellow-600이 거의 같은 탁한 색으로 보인다. 의미를 전하는 건 아이콘과 라벨이고, 색은 거드는 역할이다. Status indicators 참고.

대비 검증 방식

검증은 한 번 하고 끝내는 감사가 아니다. 기본 토큰이 바뀌면 이 표의 조합을 전부 다시 확인한다. 기본 값 하나만 고쳐도 시맨틱 계층을 타고 모든 컴포넌트에 영향이 가기 때문이다. --ds-accent-600을 바꾸면 링크, 포커스 링, Primary 버튼, tip 토큰 행을 한꺼번에 다시 검증해야 한다.

사용 가이드라인

• 컴포넌트에서는 항상 시맨틱 토큰을 쓴다. 기본 팔레트를 직접 참조하지 않는다
• 상태 표시에는 색과 함께 아이콘과 텍스트를 쓴다 (색만 쓰지 않는다)
• 포커스: 테두리 있는 컨트롤은 테두리를 --ds-focus로 바꾸고 20% 후광을 더한다. 테두리 없는 컨트롤은 2px 오프셋을 둔 3px 실선 --ds-focus 외곽선을 쓴다. Tokens 참고
• 비활성 상태도 색만이 아니라 다른 시각적 단서를 함께 쓴다

권장과 금지

가장 중요한 건 제출과 완료를 구분하는 규칙이다. 돈을 다루는 앱에서 초록은 끝났다로 읽히는데, 해외 송금은 제출된 뒤 이틀이 지나서도 실패할 수 있다. 제출은 --ds-info-*, 완료는 --ds-success-*로 표시한다.

어두운 표면 위의 색

카메라 뷰파인더, QR 스캐너처럼 항상 어두운 표면은 테마를 따르지 않는다. 두 모드 모두 #111827을 쓰고, 오버레이에는 밝은 값을 하드코딩한다. 라이트 모드에서 뷰파인더가 뒤집히면 사용자는 익숙한 기준을 잃기만 하고 얻는 건 없다. 시맨틱 테마에서 유일하게 문서화한 예외이고, Tokens에 정리했다.

알려진 공백