이 글의 내용
김희준
김희준

2026년 11월 12일 업데이트

다크 테마에는 읽기 쉬운 텍스트, 구분되는 컨트롤, 화면의 여러 면 사이에서 드러나는 명확한 관계가 필요합니다. 흰 배경을 검은색으로 바꾸는 일은 시작일 뿐입니다. 이 가이드는 색상의 역할을 정하고 라이트·다크 디자인에서 함께 재사용하는 방법을 설명합니다.

Pixso의 공유 디자인 시스템 작업 공간에서 재사용할 컴포넌트와 스타일을 용도에 따라 정리하세요. 여러 화면에 테마를 적용하기 전에 개발자와 이름 및 기대하는 시각적 결과를 합의해 두는 것이 좋습니다.

설계 예시: 일반 텍스트의 대비를 색상 쌍별로 비교합니다. 수치는 색상 값에서 계산한 결과이며 제품 전체의 접근성 평가 결과가 아닙니다.
설계 예시: 일반 텍스트의 대비를 색상 쌍별로 비교합니다. 수치는 색상 값에서 계산한 결과이며 제품 전체의 접근성 평가 결과가 아닙니다.

어두운 배경과 읽기 쉬운 텍스트 조합 선택하기

다크 인터페이스에서는 배경, 카드 등의 표면, 텍스트가 맺는 관계를 의도적으로 설계해야 합니다. 순수한 검정도 배경색의 한 선택지이며 짙은 회색도 사용할 수 있습니다. 콘텐츠, 화면이 사용되는 환경, 표면 사이에 필요한 구분을 고려해 선택하고 실제 전경색과 배경색의 조합을 확인하세요.

다크 테마에 반드시 써야 하는 단 하나의 16진수 색상 값은 없습니다. 널리 쓰이는 짙은 회색에서 시작할 수는 있지만, 많이 사용되는 색이라는 사실만으로 그 위나 옆에 놓이는 모든 색이 잘 읽힌다고 보장할 수는 없습니다.

어두운 배경의 매우 밝은 글씨를 불편하게 느끼는 사람도 있고 선호하는 사람도 있습니다. 특정 색 조합에 보편적인 의학적 효과가 있다고 단정하지 마세요. 읽기 쉬운 텍스트를 제공하고 사용자 선호를 존중하며 실제 이용 환경에서 인터페이스를 평가해야 합니다.

표면과 텍스트에는 소수의 명확한 역할을 정의하세요. 기본 캔버스, 카드, 오버레이는 경계를 알아볼 수 있도록 채우기나 테두리를 다르게 지정해야 할 수 있습니다. 주요 텍스트와 보조 텍스트는 따로 확인하세요. 제목의 대비가 충분하더라도 보조 문구를 너무 흐리게 만들면 읽기 어려워집니다.

브랜드 색상을 역할에 맞게 조정하기

밝은 페이지에서 잘 보이는 브랜드 강조색도 어두운 표면에서는 다른 색상 값이 필요할 수 있습니다. 텍스트 링크, 버튼 배경, 선택된 컨트롤, 장식 도형 등 실제 역할별로 색상을 평가하세요. 쓰임에 따라 주변 색상과 충족해야 할 조건이 달라집니다.

모든 색상의 채도를 일괄적으로 낮추기보다는 확인 과정에서 문제가 드러났을 때 명도나 채도를 조정하세요. 브랜드의 일관성을 알아볼 수 있게 유지하면서도 다크 테마에서 읽기 쉽고 서로 구분되는 값을 선택해야 합니다.

시각적 강조는 특히 유용한 동작과 상태에 집중하세요. 컨트롤뿐 아니라 로고와 일러스트도 확인해야 합니다. 흰 배경이 고정된 에셋에는 다크 테마용 버전이 필요할 수 있지만, 다른 이미지는 그대로 사용할 수 있습니다.

테마 관련 결정을 한곳에 모으기

공유 컴포넌트와 이름이 지정된 색상 스타일을 사용하면 변경 사항을 검토하기 쉽습니다. 대표적인 라이트 화면과 다크 화면을 함께 관리하세요. 그래야 라벨이나 컴포넌트 구조를 바꿀 때 한쪽 버전의 사양만 불명확하게 남는 일을 피할 수 있습니다.

디자인 도구는 시각적 사양을 관리하는 데 도움을 주지만, 애플리케이션에는 별도로 테마 선택 로직과 구현이 필요합니다. 캔버스 미리보기가 잘 보인다는 사실만으로 실제 제품의 모든 상태가 올바르게 전환된다고 판단해서는 안 됩니다.

승인된 테마 값, 컴포넌트 예시, 아직 해결하지 못한 질문을 디자인 옆에 정리하세요. 팀 댓글로 특정 표면이나 상태를 논의하고, 개발 전달 과정에서는 어떤 버전을 구현해야 하는지 명확하게 표시합니다.

설계 예시: 원시 색상 값, 시맨틱 역할, 라이트·다크 화면을 연결합니다. 역할은 유지하면서 테마에 맞게 색상 값을 바꿉니다.
설계 예시: 원시 색상 값, 시맨틱 역할, 라이트·다크 화면을 연결합니다. 역할은 유지하면서 테마에 맞게 색상 값을 바꿉니다.

색상에 용도가 드러나는 이름 붙이기

색상 이름이 목적을 설명하면 관리하기 쉽습니다. 큰 시스템에서는 원시 색상 값, 의미에 따른 역할, 컴포넌트별 역할을 구분할 수 있습니다. 작은 제품이라면 필요하지 않은 3단계 구조를 만들기보다 더 적은 역할로 시작해도 됩니다.

원시 값은 Gray-900이나 Blue-500처럼 사용 가능한 색 자체에 이름을 붙입니다. 이 이름은 팔레트의 색을 설명할 뿐, 페이지 배경에 쓸지 선택된 컨트롤에 쓸지까지 알려 주지는 않습니다.

시맨틱 역할은 페이지 배경, 위로 떠 있는 표면, 주요 텍스트, 보조 텍스트, 중요한 메시지처럼 색이 하는 일을 설명합니다. 각 역할의 의미를 유지하면서 라이트·다크 테마에 각각 적합한 값을 지정할 수 있습니다.

컴포넌트 역할은 포커스된 입력 필드의 테두리처럼 특정 컨트롤에 더 구체적인 결정이 필요할 때 유용합니다. 모든 인스턴스에 별도 토큰을 만드는 대신, 실제 동작을 명확하게 설명하는 데 필요한 곳에 추가하세요.

공유 역할마다 라이트·다크 두 값을 모두 기록하고 해당 Color Styles(색상 스타일)를 대표 프레임에 적용하세요. 이 이름들을 구현 쪽 이름에 어떻게 대응시킬지도 합의해야 합니다. 디자인 파일과 애플리케이션의 저장 형식이 달라도 역할별 대응표를 통해 사양을 전달할 수 있습니다.

값을 바꾼 뒤에는 해당 색을 사용하는 컴포넌트를 검토하세요. 페이지의 라벨을 더 잘 보이게 하는 색이 강조색 버튼 안의 라벨에는 오히려 불리할 수 있습니다. 공유 스타일은 반복 편집을 줄여 주지만 색상 조합을 확인하는 과정까지 없애 주지는 않습니다.

다음 구현 단계는 디자인 토큰으로 테마 전환하기(영문 가이드)입니다. 모드에 따라 값이 달라져도 각 색상이 가진 의미는 일관되게 유지하세요.

설계 예시: 표면 색상과 테두리로 탐색 영역, 모달, 카드를 구분합니다. 그림 속 프로젝트와 수치는 설명용 예시입니다.
설계 예시: 표면 색상과 테두리로 탐색 영역, 모달, 카드를 구분합니다. 그림 속 프로젝트와 수치는 설명용 예시입니다.

표면과 오버레이를 구분하기

다크 인터페이스에서도 깊이와 앞뒤 관계를 이해할 수 있어야 합니다. 라이트 인터페이스에서는 그림자가 오버레이와 아래 페이지를 구분하는 데 도움을 줄 수 있습니다. 다만 그림자는 여러 단서 중 하나이며 모든 오버레이에 필수인 것은 아닙니다.

어두운 배경에서는 그림자가 잘 보이지 않을 수 있습니다. 하나의 짙은 그림자만으로 전체 계층을 표현하려 하지 말고, 채우기·테두리·간격·그림자를 적절하게 조합해 표면을 구분하세요.

기본 배경을 어둡게 두고 카드와 오버레이를 조금 밝게 만드는 방법이 있습니다. 이는 검토할 상대적 관계이지 모든 제품이 따라야 하는 고정된 밝기 단계가 아닙니다. 이미지와 강조색 영역을 포함하여 오버레이 아래에 놓일 수 있는 모든 표면과 비교하세요.

은은한 테두리는 겹쳐진 메뉴의 가장자리를 분명하게 만들 수 있습니다. 실제 합성 색상은 불투명도와 아래 배경에 따라 달라지므로 렌더링된 결과를 평가해야 합니다. 한 가지 예시 카드에서 괜찮아 보인다는 이유만으로 불투명도가 낮은 흰색 테두리를 선택하지 마세요.

설계 예시: 두 테마의 버튼, 입력 필드, 표 행, 알림을 비교합니다. 알림의 성공·정보·경고·오류 유형은 포커스나 비활성과 같은 조작 상태와 구분합니다.
설계 예시: 두 테마의 버튼, 입력 필드, 표 행, 알림을 비교합니다. 알림의 성공·정보·경고·오류 유형은 포커스나 비활성과 같은 조작 상태와 구분합니다.

컴포넌트 상태와 대비 확인하기

버튼, 폼 필드, 표, 대화상자 등 다크 테마에서 사용하는 컴포넌트를 검토하세요. 기본, 호버, 포커스, 누름, 선택됨, 비활성, 오류처럼 각 컴포넌트에 필요한 상태를 확인합니다. 메인 프레임의 배경만 바꿔서는 이러한 조합을 모두 확인할 수 없습니다.

WCAG 2.2 레벨 AA에서는 일반 텍스트에 원칙적으로 최소 4.5:1, 큰 텍스트에 최소 3:1의 대비가 필요하며 해당 성공 기준에 예외도 정의되어 있습니다. W3C의 대비 지침(영문)에서 어떤 조건이 적용되는지 확인한 뒤 실제 색상 조합을 측정하세요.

관련된 전경색·배경색 조합마다 대비 검사 도구를 사용하세요. 기본 버튼만 측정하지 말고 선택, 호버, 포커스, 오류 상태도 포함해야 합니다. 오류는 텍스트와 유용한 안내로 설명하고 색상 이외의 단서로도 상태를 구분하세요. 대비 측정 결과는 접근성 평가의 일부일 뿐, 전체 접근성 요건을 통과했다는 뜻은 아닙니다.

실습 예시: 화면 모드 설정 패널

라이트, 다크, 시스템 설정 따르기 옵션과 짧은 설명, 저장 완료 알림이 있는 설정 패널을 예로 들어 보겠습니다. 이 작은 화면으로 대시보드 전체를 다시 설계하지 않고도 여러 역할을 확인할 수 있습니다.

역할적용 대상두 테마에서 확인할 사항
페이지와 패널 표면캔버스와 설정 카드콘텐츠보다 과하게 눈에 띄지 않으면서 카드의 경계가 분명하다.
주요·보조 텍스트제목, 라벨, 설명 문장설명 문장이 표면에 묻히지 않고 읽기 쉽다.
선택된 옵션현재 선택된 화면 모드색상뿐 아니라 표시나 라벨로도 선택 상태를 알 수 있다.
포커스 표시키보드 포커스가 있는 옵션포커스 상태와 선택 상태를 구분할 수 있다.
결과 피드백저장 완료 또는 실패 알림메시지가 결과를 설명하며 읽기 쉬운 대비를 유지한다.

시스템 설정 따르기가 활성화된 상태에서 다크를 선택하고, 다시 ‘시스템 설정 따르기’를 선택한 뒤 패널을 다시 여는 흐름을 확인하세요. 저장이 실패했다면 저장되지 않은 옵션을 영구 설정인 것처럼 아무 설명 없이 표시해서는 안 됩니다. 선택한 환경설정과 미리보기에 현재 표시되는 화면 모드를 별개로 관리하세요.

다음으로 패널 위에 오버레이를 열어 보세요. 오버레이의 경계, 닫기 동작, 포커스 상태가 여전히 명확해야 합니다. 색상 견본만 모아 놓은 시트로는 드러나지 않는 조합을 확인할 수 있습니다.

개발을 위한 테마 동작 명세 작성하기

제품이 화면 모드를 선택하는 방식을 정하세요. 라이트, 다크, 시스템 설정 따르기는 유용한 선택지입니다. 시스템 옵션은 기기 설정을 따르고, 사용자가 명시적으로 고른 옵션은 기기 설정보다 우선 적용될 수 있습니다. 다음 방문 때와 운영체제 설정이 변경될 때 어떻게 동작할지도 지정하세요.

개발자에게 두 테마의 색상 역할, 선택 동작, 합의한 디자인 버전을 전달하고 관련 Pixso 화면 옆에 이 정보를 정리하세요. 설정 유지, 시스템 환경설정 처리, 실제 컴포넌트의 각 상태는 개발자가 구현해야 합니다.

일반 텍스트, 입력 필드, 선택 항목, 오버레이가 포함된 대표 화면 하나에서 시작하세요. 각 상태가 함께 일관되게 동작하면 같은 역할을 나머지 화면에 확장하고 차트, 일러스트, 삽입된 콘텐츠 등의 예외를 검토합니다.

맨 위로 이동
X에 공유하기
페이스북에 공유하기