dark-mode

5 개의 포스트

discord3분 읽기큐레이션 요약

스퀴클, 스타일, 간격: 여러분의 피드백이 모바일 환경 개선에 어떻게 도움이 되고 있는가

Discord는 데스크톱과 모바일의 디자인 경험을 통일하기 위해 모바일 앱의 테마, 형태, 간격과 채팅 입력창을 개선했습니다. 데스크톱의 네 가지 기본 테마를 모바일에 도입하고, 사람은 원형·사물은 스퀘어클이라는 형태 규칙을 적용했습니다. 또한 채팅 바를 정리해 메시지 작성 공간을 넓히고, 자주 쓰는 기능에 더 쉽게 접근할 수 있도록 조정했습니다. ## 데스크톱과 모바일의 테마 통일 - 모바일에서도 데스크톱의 네 가지 기본 테마를 사용할 수 있습니다. - Light - Ash - Dark - Onyx - **Ash**는 기존 Discord의 클래식 다크 테마를 계승하면서 현대적인 접근성 기준에 맞게 대비를 개선했습니다. - **Onyx**는 단순히 어두운 회색이 아니라 완전한 검정색 배경을 사용하는 AMOLED 테마입니다. - OLED 화면에서 검정색 픽셀을 끌 수 있어 배터리 절약에 도움이 될 수 있습니다. - 모바일과 데스크톱에서 동일한 테마로 제공됩니다. - 접근성 설정에서 화면의 대비와 채도를 세부적으로 조절할 수 있습니다. ## 기기 설정에 맞춘 테마 자동 전환 - 사용자가 지정한 Light 테마와 Dark 테마를 기기의 시스템 모드에 맞춰 자동으로 전환할 수 있습니다. - Appearance 설정에서 **“Same as Device Theme”**를 활성화하면 됩니다. - 이 설정은 **Sync Across Devices**보다 우선 적용됩니다. - 모바일뿐 아니라 데스크톱에서도 지원됩니다. - Nitro 사용자는 프로필 테마의 색상에 맞춰 음성·영상 통화 타일의 배경도 변경할 수 있습니다. ## 사람은 원형, 사물은 스퀘어클 - 모바일과 데스크톱 전반에 일관된 형태 규칙이 적용됩니다. - 사용자, 친구, DM의 봇: 원형 - 서버, 앱 등 사물: 모서리가 둥근 사각형인 스퀘어클 - 서버 목록의 아이콘이 스퀘어클 형태로 바뀌어 사람과 서버를 빠르게 구분할 수 있습니다. - 버튼, 입력창, 컨테이너 등 다른 UI 요소의 둥근 모서리도 같은 기준에 맞춰 정리했습니다. - 개인 DM과 그룹 DM은 ‘친구 관계’를 나타내기 때문에 기존처럼 원형을 유지합니다. ## 메시지 입력창과 빠른 작업 메뉴 개편 - 채팅 바가 지나치게 복잡해진 문제를 해결하기 위해 메시지 작성 공간을 넓혔습니다. - 채팅 바 오른쪽에는 다음 기능이 계속 유지됩니다. - 이모지 - 선물 - 음성 메시지 - 자주 사용하는 빠른 작업 - 다음 기능은 **+ 메뉴** 안으로 이동했습니다. - 스레드 - 앱 사용 - **+ 버튼을 길게 누르면** 전체 메뉴를 열지 않고 원하는 작업으로 바로 이동할 수 있습니다. - 스레드나 앱을 자주 사용하는 사용자는 이전보다 한 단계 더 거쳐야 하지만, 길게 누르기 단축 동작으로 기존 접근 속도에 가깝게 사용할 수 있도록 했습니다. ## 플랫폼 간 일관성을 높인 모바일 업데이트 - 이번 업데이트의 목표는 모바일과 데스크톱을 서로 다른 앱처럼 느끼지 않도록 만드는 것입니다. - 동일한 테마 체계, 형태 규칙, UI 간격을 적용해 플랫폼을 바꿔도 익숙한 사용 경험을 제공하려 했습니다. - 변경 사항은 사용자 피드백을 바탕으로 모바일의 시각적 일관성과 사용성을 함께 개선하는 데 초점을 맞췄습니다. 모바일에서 클래식한 분위기를 원한다면 **Ash**, 배터리 효율과 완전한 검정 배경을 원한다면 **Onyx**를 선택하는 것이 적합합니다. 스레드나 앱을 자주 사용한다면 + 버튼 길게 누르기 동작을 익혀 새 채팅 바에 적응하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
discord3분 읽기큐레이션 요약

디스코드 테마를 변경

Discord는 데스크톱과 모바일에서 테마를 바꿔 앱의 색상과 분위기를 개인 취향에 맞게 설정할 수 있도록 지원한다. 모든 사용자는 4가지 기본 테마를 이용할 수 있고, Nitro 회원은 28개의 추가 색상 테마와 최대 5가지 색상을 조합한 사용자 지정 테마를 사용할 수 있다. 또한 Nitro 회원은 테마에 맞춰 앱 아이콘도 변경할 수 있다. ## 데스크톱에서 테마 변경 - **사용자 설정 > 외관(Appearance)**으로 이동한다. - “Themes” 영역에서 다음 카테고리를 확인할 수 있다. - **Default Themes**: 모든 사용자 이용 가능 - **Color Themes**: Nitro 회원 전용 - 테마를 선택하면 즉시 앱에 적용된다. - **Preview Themes** 버튼을 사용하면 Nitro 전용 테마도 구독 여부와 관계없이 미리 볼 수 있다. ## 모바일에서 테마 변경 - 모바일 앱의 **You 탭 > 오른쪽 위 설정 아이콘 > Appearance > Theme** 순서로 이동한다. - 화면을 좌우로 넘겨 원하는 테마를 선택한다. - 기본적으로 데스크톱과 모바일의 테마가 동기화된다. - 기기별로 다른 테마를 사용하려면 모바일 Appearance 설정에서 **Sync Across Clients**를 끄면 된다. ## 모든 사용자가 이용할 수 있는 기본 테마 - 기본 테마는 총 4가지다. - Light - Ash - Dark - Onyx - **Sync with computer/device**를 활성화하면 컴퓨터나 휴대폰의 밝은 모드·어두운 모드 설정에 맞춰 Light와 Dark 테마가 자동 전환된다. - Light 테마에서는 **Dark Sidebar** 옵션을 사용할 수 있다. - 서버 목록, DM, 채널 목록은 어두운 색상으로 표시된다. - 대화 영역은 밝은 색상으로 유지된다. ## Nitro 전용 색상 테마 - Nitro 회원은 기본 테마 외에 **28개의 추가 색상 테마**를 이용할 수 있다. - 예시: - Chroma Glow - Citrus Sherbert - Midnight Blurple - Retro Raincloud - 해당 테마는 Appearance 설정의 **Color Themes** 카테고리에서 선택한다. ## Nitro 사용자 지정 테마 - 기본 제공 테마가 마음에 들지 않는 Nitro 회원은 직접 색상 테마를 만들 수 있다. - 하나의 사용자 지정 테마에 **최대 5가지 색상**을 조합할 수 있다. - 현재 모바일 앱에서는 사용자 지정 테마를 직접 만들 수 없다. - 데스크톱에서 만든 사용자 지정 테마는 모바일에도 동기화되어 사용할 수 있다. ## Nitro 전용 앱 아이콘 변경 - Themes 설정 아래의 **In-App Icon** 메뉴에서 앱 아이콘을 바꿀 수 있다. - vaporwave, 우주, 게임 등 다양한 스타일을 포함해 약 **23가지 아이콘**이 제공된다. - 데스크톱에서는 앱 왼쪽 위 아이콘이 변경되고, 모바일에서는 기기 홈 화면의 앱 아이콘이 변경된다. - 아이콘 설정은 기기별로 적용되므로 데스크톱과 휴대폰에 서로 다른 아이콘을 설정할 수 있다. ## 실용적인 활용 방법 - 여러 기기에서 같은 분위기를 유지하려면 테마 동기화를 켜고, 기기별 개성을 원하면 동기화를 끄는 것이 좋다. - 밝은 화면과 어두운 화면을 자주 오간다면 기기 테마와 자동 동기화하는 기능이 편리하다. - Nitro 회원은 기본 테마, 28개 색상 테마, 사용자 지정 색상, 앱 아이콘을 조합해 Discord의 전체적인 시각적 스타일을 세밀하게 꾸밀 수 있다.

원문 읽기(새 탭에서 열림)
toss원문

달리는 기차 바퀴 칠하기: 7년만의 컬러 시스템 업데이트 (새 탭에서 열림)

토스 디자인 시스템(TDS)은 서비스의 글로벌 확장과 다양한 플랫폼 대응을 위해 7년 만에 컬러 시스템을 전면 개편했습니다. 인지적으로 균일한 색공간인 OKLCH를 도입하여 시각적 일관성과 접근성을 확보하고, 디자이너가 직접 제어하는 자동화된 토큰 관리 체계를 구축했습니다. 이번 개편을 통해 TDS는 단순한 디자인 가이드를 넘어, 비즈니스 성장을 뒷받침하는 확장 가능한 기술 인프라로 진화했습니다. ### 기존 컬러 시스템의 한계와 부채 - **명도 불일치**: 동일한 명도 단계(예: 100)임에도 색상(Grey, Blue, Red 등)에 따라 실제 느껴지는 밝기가 달라 UI가 얼룩덜룩해 보이는 문제가 있었습니다. - **모드 간 이격**: 라이트모드와 다크모드의 명도 기준이 달라 다크모드에서 특정 색이 너무 튀거나 가독성이 떨어지는 현상이 발생했습니다. - **관리 체계의 파편화**: 웹, iOS, 안드로이드, 디자인 에디터 등 각 플랫폼에서 컬러를 개별 관리하면서 싱글 소스 오브 트루스(SSOT)가 무너지고 커뮤니케이션 비용이 증가했습니다. ### OKLCH 색공간을 통한 인지적 균일함 확보 - **지각적 평등성**: 수치상 명도와 인간이 느끼는 밝기가 다른 HSL 모델 대신, 인지적으로 균일한 OKLCH 및 HSLuv 색공간을 활용해 모든 색상의 명도를 통일했습니다. - **접근성 자동화**: 정의된 명도 체계를 바탕으로, 외부 브랜드 컬러를 입력하더라도 TDS 기준에 맞는 배경-텍스트 대비를 자동으로 추출하는 로직을 구현했습니다. - **디바이스 최적화**: RGB 환경에서 표현하기 어려운 OKLCH 색상을 위해 채도(Chroma)를 클램핑(Clamp)하여 색조와 명도를 유지하면서도 기기 호환성을 높였습니다. ### 심미성과 접근성을 위한 시각 보정 - **Dark Yellow 문제 해결**: 수치적으로만 맞춘 노란색은 탁해 보이거나 너무 진해 보일 수 있어, 노란색 계열에 한해 별도의 명도 진행 단계를 적용하는 시각 보정을 거쳤습니다. - **다크모드 시인성 강화**: 인간의 눈이 어두운 배경에서 대비를 더 낮게 인식하는 특성을 고려하여, 최신 명도대비 메트릭인 APCA를 참고해 다크모드의 대비를 더 강하게 설계했습니다. - **시맨틱 토큰 정비**: 색상의 값(Primitive)이 아닌 사용 의도(Semantic)에 집중한 토큰 체계를 정립하여 디자인 결정 시간을 단축하고 일관성을 보장했습니다. ### 디자이너 중심의 토큰 자동화 시스템 - **통합 파이프라인**: Figma 플러그인(Token Studio)과 GitHub를 연동하여 디자이너가 컬러를 수정하고 커밋하면 모든 플랫폼의 코드가 자동으로 생성되도록 구축했습니다. - **실험적 환경**: 개발자의 수동 작업 없이도 디자이너가 직접 토큰을 변경하고 빠르게 실험할 수 있는 환경을 만들어 디자인 시스템의 운영 효율을 극대화했습니다. 성공적인 디자인 시스템 개편을 위해서는 단순한 심미적 수정을 넘어, 데이터 기반의 색공간 설계와 엔지니어링 관점의 자동화가 필수적입니다. 특히 비즈니스가 확장되는 시점이라면 컬러 시스템을 개별 컴포넌트가 아닌, 모든 플랫폼을 관통하는 하나의 '코드'이자 '인프라'로 접근하는 태도가 필요합니다.

figma4분 읽기큐레이션 요약

피그마 패턴 라이브

UI3 개편은 Figma 내부 디자인 시스템이 오랜 성장 과정에서 파편화되었다는 문제를 드러냈고, 이를 해결하기 위해 Figma Pattern Library(FPL)를 처음부터 다시 구축하게 만들었습니다. 디자이너와 엔지니어가 페어 프로그래밍에 가까운 방식으로 협업해 디자인 의도와 코드 구현을 연결하고, 변수·REST API·테마 모드를 기반으로 일관되고 접근성 높은 제품 개발의 기반을 마련했습니다. FPL은 단순한 컴포넌트 모음이 아니라 조직 전체의 공통 언어이자 UI3를 확장하기 위한 단일 진실 공급원으로 설계되었습니다. ## UI3가 드러낸 내부 디자인 시스템의 문제 - Figma는 다른 팀의 디자인 시스템 구축을 돕는 제품을 만들고 있었지만, 내부 시스템은 오랜 기간의 급속한 성장과 제품 확장으로 분리되어 있었습니다. - 동일해야 할 컴포넌트가 서로 조금씩 달랐고, 연결이 끊긴 컴포넌트 인스턴스가 누적되었습니다. - UI3를 모든 Figma 제품에 적용하려면 새로운 화면 디자인만으로는 부족했습니다. - 여러 팀이 일관되고 효율적으로 작업할 수 있는 견고한 기반 시스템이 필요했습니다. ## 디자이너와 엔지니어의 페어 협업 - Wayne Sun과 Tom Williams는 디자이너와 엔지니어로 구성된 5명의 소규모 팀을 만들었습니다. - 개발에서 한 사람이 코드를 작성하고 다른 사람이 실시간 검토하는 페어 프로그래밍처럼, 디자이너와 엔지니어가 긴밀하게 짝을 이루어 작업했습니다. - 디자이너는 시각적·사용자 경험 의도를 전달하고, 엔지니어는 이를 실제 컴포넌트와 토큰 시스템으로 구현했습니다. - 이 방식은 디자인 파일과 제품 코드 사이의 간극을 줄이고, 양쪽이 공유할 수 있는 시스템 언어를 만드는 데 목적이 있었습니다. - 그 결과 새로운 내부 디자인 시스템인 Figma Pattern Library(FPL)가 탄생했습니다. ## 스타일과 스프레드시트에서 변수 중심 구조로 전환 - 기존 시스템은 Figma의 변수 기능이 등장하기 전에 만들어졌습니다. - 디자이너는 Figma 스타일을 사용했지만, 엔지니어는 별도의 Google Sheets에서 색상 토큰을 관리했습니다. - 스프레드시트가 제품 변경 사항을 즉시 반영하지 못하면서 디자인 파일과 실제 코드의 색상이 달라지는 문제가 발생했습니다. - 팀은 Figma 변수와 REST API를 활용해 디자인과 코드가 자동으로 동기화될 수 있는 구조를 만들었습니다. - 타이포그래피 변수를 새로 만들고, 기존 타이포그래피 스타일이 이 변수들을 별칭으로 참조하도록 구성했습니다. - 색상 스타일은 중앙 관리가 가능한 색상 변수로 마이그레이션했습니다. - 색상 변수에 CSS 정의도 추가해 Dev Mode의 검사 패널에서 개발자가 올바른 변수명과 코드 표현을 확인할 수 있게 했습니다. ## Primitive와 Semantic 변수로 색상 체계 정리 - 색상은 밝기와 어두움이 체계적으로 이어지는 **color ramp**를 기반으로 구성했습니다. - 기본 색상 단위인 **Primitive 변수**는 색상 계열별로 정리하고, 100부터 1000까지 단계적으로 구분했습니다. - 실제 UI 용도를 나타내는 **Semantic 변수**는 Primitive 변수를 별칭으로 참조합니다. - 예를 들어 특정 색상값을 직접 사용하는 대신 배경, 텍스트, 테두리 같은 의미 기반 변수로 연결할 수 있습니다. - Semantic 변수는 다음과 같은 테마와 제품별 모드를 지원하도록 설계되었습니다. - 라이트 모드와 다크 모드 - Figma Design - FigJam - Slides - Dev Mode - 이 구조 덕분에 하나의 공통 컴포넌트가 제품이나 테마에 따라 색상만 자연스럽게 바꿀 수 있습니다. - Primitive 변수의 값을 수정하면 이를 참조하는 Semantic 변수와 컴포넌트에 변경 사항을 일괄 적용할 수 있습니다. ## FPL의 역할 - FPL은 UI3의 시각적 스타일을 정의하는 동시에, 이를 실제 제품에 일관되게 구현하기 위한 기술적 기반입니다. - 디자인과 엔지니어링을 분리된 단계로 처리하지 않고, 초기 설계부터 함께 검증하는 협업 모델을 채택했습니다. - 변수와 모드 기반의 구조는 여러 제품과 테마를 지원하면서도 공통된 사용자 경험을 유지하도록 돕습니다. - 중앙화된 토큰과 컴포넌트는 중복 구현과 미세한 시각적 차이를 줄이고, 향후 변경 사항을 더 빠르게 확산시킬 수 있습니다. FPL 사례는 디자인 시스템을 단순한 UI 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

다크 모드 밝히

Figma의 다크 모드는 색상만 어둡게 바꾸는 단순한 프런트엔드 작업이 아니라, 제품 전반의 UI 상태와 접근성, 향후 테마 확장성을 함께 해결해야 하는 시스템 구축 프로젝트였다. Figma는 사용자 요청에 대응하는 동시에 시각적 접근성을 높이고, 새로운 기능이 처음부터 다크 모드를 지원하도록 만드는 것을 목표로 했다. 이를 위해 전체 UI를 조사하고 여러 팀의 공통 컴포넌트를 체계적으로 refactoring하는 방식을 택했다. ## 다크 모드가 필요했던 이유 - 다크 모드는 Figma 사용자들이 가장 많이 요청한 기능 중 하나였다. - 야간 작업 시 밝은 화면으로 인한 불편을 줄일 수 있었다. - 시각 장애나 특정 시각적 질환이 있는 사용자에게 다크 모드가 더 읽기 쉬울 수 있었다. - 색상 대비는 WCAG 접근성 지침의 핵심 요소이므로, 다크 모드는 Figma의 “디자인을 모두에게 accessible하게 만든다”는 목표와도 연결됐다. - 일반적으로는 라이트 모드가 시각적 수행 능력에 유리하지만, 백내장 등 특정 질환이 있는 사람은 다크 모드에서 더 나은 성능을 보일 수 있다. ## 단순한 색상 교체가 아니었던 이유 - 처음에는 모든 밝은 색을 어두운 색으로 바꾸면 된다고 생각했지만, 실제로는 UI의 상태와 맥락을 함께 고려해야 했다. - 다크 모드 전환 시 다음 요소를 결정해야 했다. - 밝은 편집기 패널을 어둡게 바꾸고 아이콘과 텍스트를 밝게 할지 - 라이트 모드에서도 이미 어두운 툴바와 메뉴를 그대로 유지할지 - 캔버스 배경처럼 사용자가 만든 콘텐츠까지 테마에 따라 변경할지 - C++ 렌더링 엔진이 그리는 투명도 격자 등의 색상도 변경할지 - Figma 전체가 아니라 편집기 등 특정 영역만 지원할지에 대한 제품 범위 결정도 필요했다. ## 전체 UI 감사와 범위 설정 - 개발에 앞서 각 팀원이 Figma 앱의 UI 표면을 조사하고, 다크 모드로 재구성하기 어려운 부분을 파악했다. - 프로젝트 시작 당시 Figma에는 10개의 제품 엔지니어링 팀이 있었고, 각 팀이 모달, 패널, 툴바 등 주요 UI 영역을 담당했다. - 하나의 UI 요소도 여러 상태와 복잡한 예외 상황을 포함할 수 있었다. - 특정 조건에서만 나타나는 상태 - 여러 뷰와 화면 - 숨겨진 서브모달과 드롭다운 - 따라서 표면적으로 보이는 화면뿐 아니라 모든 상태와 엣지 케이스까지 다크 모드 범위에 포함해야 했다. ## 확장 가능한 테마 시스템의 목표 - 목표는 현재 다크 모드만 구현하는 것이 아니었다. - 두 가지 장기 목표를 세웠다. - 개발자가 새로운 기능을 다크 모드 지원과 함께 바로 만들 수 있도록 하기 - 향후 Figma와 FigJam에 새로운 테마를 쉽게 추가할 수 있도록 하기 - 공통 UI 컴포넌트는 다크 모드를 지원해야 하지만, 다크 모드가 적용되지 않는 화면에서는 기존 동작과 외관을 유지해야 했다. - 구현 과정에서 기존 기능을 깨뜨리지 않는 회귀 방지(regression-proof) 구조가 중요했다. - 새로운 엔지니어의 온보딩과 향후 예측하지 못한 요구사항 대응까지 고려해, 적용과 유지보수가 쉬운 방식이 필요했다. ## 프로젝트 규모가 만든 엔지니어링 과제 - Figma의 UI가 여러 팀에 분산되어 있어 소수의 엔지니어만으로 전체를 처리하기 어려웠다. - 각 팀이 소유한 컴포넌트와 화면을 공통 원칙에 맞게 바꿔야 했다. - 단순히 색상 값을 교체하는 것이 아니라, 컴포넌트가 어떤 표면과 상태에서 사용되는지까지 체계적으로 분리해야 했다. - 이 경험은 개별 기능을 추가하는 방식보다, 제품 전체에서 재사용할 수 있는 디자인·엔지니어링 시스템을 구축하는 접근이 필요하다는 점을 보여준다. 다크 모드처럼 겉보기에는 간단한 기능도 실제로는 UI 상태, 접근성, 팀 간 소유권, 공통 컴포넌트, 향후 확장성을 함께 설계해야 한다. 유사한 기능을 구현할 때는 특정 화면의 색상부터 바꾸기보다 전체 범위를 먼저 감사하고, 테마 토큰과 공통 컴포넌트를 중심으로 회귀를 방지할 수 있는 구조를 마련하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)