오즈코딩스쿨 디자인캠프

오즈코딩스쿨 디자인 캠프 - 다크 모드는 색을 뒤집는 게 아니다 — 토큰이 빛을 본 날 (day19)

송송미미 2026. 6. 25. 00:01

오늘은 하루가 두 토막으로 나뉘었다. 오전은 비교적 가벼웠다. 작업을 대신 해주는 플러그인들을 한 바퀴 둘러봤다. 그리고 오후는 강사님 표현으로 '오늘의 하이라이트', 다크 모드였다. 그런데 막상 해보니 다크 모드는 새로운 무언가라기보다, 그동안 며칠에 걸쳐 쌓아온 시멘틱 컬러와 베리어블 작업이 마침내 보답을 받는 순간이었다.

솔직히 프리미티브 색을 등록하고 시멘틱으로 역할을 나누고 베리어블로 묶을 때는, 이 번거로운 걸 왜 이렇게까지 하나 싶었다. 그런데 오늘 모드 스위치 하나로 화면 전체가 라이트에서 다크로 한 번에 뒤집히는 걸 보고서야, 그 수고가 무엇을 위한 거였는지 이해됐다.

손이 덜 가게 해주는 도구들

오전은 플러그인 투어였다. 공통점은, 손이 많이 가고 반복적인 부분을 대신 처리해준다는 것이었다.

플러그인 · 리소스용도
Progressive Blur 글라스모피즘 풍의 점진적 블러. 배경 위에 깔면 그 위 텍스트 가독성이 좋아진다
Beautiful Shadows 여러 겹의 자연스러운 그림자를 자동 생성. 목업·표지용
html.to.design URL을 넣으면 실제 서비스 화면을 피그마로 변환. 클론·리서치용 (월 10회 무료)
Variables to Frames 등록한 베리어블·디자인 토큰을 표로 자동 문서화
Design Lint 토큰·스타일에 연결되지 않은 하드코딩 색·폰트를 탐색. 마무리 점검용
아이콘 세트 (Phosphor · Material · Feather) 굵기·스타일 조절 가능. Phosphor·Material은 양이 많고, Feather는 둥글둥글 친근한 무드
Color generator 프라이머리 색 하나로 10단계 팔레트를 자동 생성
Storyset (Freepik) 일러스트 검색·삽입. 빈 화면이나 에러 화면에 유용
Dummy content 더미 이름·이메일·가격·문장을 자동 생성 (단, 형식이 미국식이라 주의)
Liquid Glass UI (커뮤니티 리소스) iOS 26의 글라스모피즘 UI를 바로 가져다 쓰는 자료 (플러그인은 아님)

몇 개는 직접 써보며 작게 깨달은 게 있었다. Beautiful Shadows를 써보고 나서야, 우리가 '완성도 높다'고 느끼는 그림자는 대개 한 겹이 아니라 대여섯 겹이 쌓인 결과라는 걸 알았다. 그래서 손으로 일일이 맞추기가 어려웠던 거였다. 마음에 드는 걸 만들면 스타일로 등록해두고 반복해 쓰면 된다. 어제 그림자를 스타일로 등록했던 게 이런 자동 생성과 자연스럽게 이어졌다.

html.to.design은 클론 작업에 쓸 만했다. URL만 넣으면 살아있는 화면을 그대로 가져와서, 폰트·간격·색상·아이콘을 뜯어보기 좋다. 다만 오토 레이아웃 같은 구조까지 완벽하게 잡히진 않으니 참고용으로만 보면 된다. 크롬 확장의 Figma 캡처도 같은 용도인데, 오늘은 계속 막혀서 동작하지 않았다. 클론할 땐 html.to.design을 쓰는 게 안전하겠다.

Design Lint는 일종의 마지막 양심 점검이었다. 급할 때 나도 모르게 토큰 대신 헥스코드를 그냥 입력해버리는 경우가 생기는데, 이 플러그인이 그런 걸 쫙 스캔해서 짚어준다. 마무리 단계에서 한 번 돌려주면 놓친 부분을 잡을 수 있다.

슬롯은 프레임에만 걸린다 (복습)

어제 배운 슬롯을 다시 만져봤는데, 어제는 몰랐다가 오늘에야 또렷해진 두 가지가 있었다.

하나, 슬롯은 프레임 영역에만 지정할 수 있다. 오늘 막혔던 대부분이 여기서 나왔다. 렉탱글이나 엘립스, 또는 그냥 이미지를 슬롯으로 바꾸려고 하면 안 된다. 이미지가 들어갈 자리를 먼저 프레임으로 만들고, 그걸 컴포넌트화한 다음, 슬롯으로 전환해야 한다. 그리고 슬롯 지정은 인스턴스가 아니라 원본에서 해야 한다.

둘, 오늘 새로 배운 클립 콘텐츠(Clip content). 모서리가 둥근 카드를 만들 때, 바깥 프레임에 준 라운드 값이 안쪽 콘텐츠까지 닿지 않아 모서리가 삐져나오는 경우가 있다. 이때 클립 콘텐츠를 켜주면 바깥 라운드가 안쪽 프레임까지 깔끔하게 잘라준다. 원형 이미지는 정사각 프레임에 알값을 9999로 주면 된다.

다크 모드는 색을 뒤집는 게 아니다

오후의 하이라이트는 다크 모드였다. 다크 모드는 배경을 어둡게, 텍스트를 밝게 두는 테마다. 반대로 밝은 배경에 어두운 텍스트가 라이트 모드다. 여기까진 다 아는 이야기인데, 제작자 관점에서 한 가지가 새로웠다.

다크 모드는 색을 그냥 반전시키는 게 아니라, 각 요소에 맞는 어두운 팔레트를 따로 설계하는 것이다.

그래서 다크 모드를 지원한다는 건, 디자인 시스템 안에 라이트 테마와 다크 테마 두 벌을 갖춰둔다는 뜻이었다. 그리고 이걸 가능하게 하는 게 바로 시멘틱 컬러와 베리어블이다. 예를 들어 '배경'이라는 시멘틱 토큰 하나가 라이트 모드에서는 흰색을, 다크 모드에서는 어두운 색을 가리키도록 설정해두면, 색을 하나하나 찍어 바꾸지 않아도 바깥에서 모드 하나만 바꾸는 것으로 전체 색이 한 번에 스위칭된다.

바로 이 지점에서 그동안의 작업이 보답을 받았다. day14에서 토큰 구조를 쌓고, 며칠에 걸쳐 시멘틱 컬러와 베리어블을 등록한 게 다 이 한 번의 전환을 위한 준비였던 셈이다. 방법 자체는 어렵지 않았다. 베리어블에 컬렉션을 하나 만들고, 거기에 모드를 하나 더 추가해 라이트와 다크로 나눈 다음, 각 색마다 라이트 값과 다크 값을 짝지어 등록하면 된다. 적용은 프레임의 어피어런스(또는 섹션)에서 모드를 골라주면 끝이다.

적용하는 층위는 두 가지였다. 섹션 자체에 걸면 기기에서 다크 모드를 켰을 때처럼 그 안의 모든 게 어두워지고, 프레임에 걸면 앱 안에서 직접 전환하는 형태가 된다. 둘을 동시에 걸면 충돌할 수 있어서, 프레임으로 제어하고 싶을 땐 섹션 쪽을 'Auto'로 둬야 했다.

흥미로웠던 건 다크 모드가 무조건 좋은 게 아니라는 대목이었다. 흔히 다크 모드가 눈의 피로를 줄여준다고들 하는데, 최근에는 그게 늘 그런 건 아니라는 이야기도 나온다고 한다. 사용 환경, 화면 밝기, 글자 크기, 대비, 개인의 시력에 따라 달라져서 어떤 모드가 더 편하다고 단정할 수 없다는 것이다.

이 대목에서 간호하던 때가 떠올랐다. 임상에서는 "이게 무조건 몸에 더 좋다" 같은 단정을 그대로 믿지 않도록 배운다. 어떤 처치가 도움이 되는지는 환자와 상황에 따라 다르고, 근거를 따져봐야 한다. "다크 모드가 눈에 더 좋다"는 말도 결국 같은 모양의 주장이었다. 그래서 답은 무조건 다크가 아니라, 서비스의 성격에 맞는 기본 테마를 고르는 거였다.

서비스의 성격과 주된 사용 맥락에 따라 적합한 기본 테마를 정해야 한다.

실제로 유튜브·넷플릭스·스포티파이처럼 영상이나 음악, 콘텐츠를 보여주는 서비스는 다크 모드를 기본으로 둔다. 배경이 어두워지면 콘텐츠가 더 돋보이기 때문이다. 반대로 뉴스나 문서, 블로그처럼 읽는 게 주된 행위인 서비스는 텍스트 가독성이 우선이라 라이트 모드를 기본으로 쓴다. 그래서 오늘 실습에서도 토스 화면은 기본을 라이트 모드로 잡고, 다크는 전환되도록 세팅했다.

다만 베리어블 연결이 은근히 까다로웠다. 색이 제대로 안 바뀌거나, 섹션과 프레임의 모드가 꼬이는 일이 잦아서, 끊었다 다시 연결하기를 여러 번 반복했다. 개념은 명쾌한데 손은 자꾸 미끄러지는, 어제오늘 반복되는 그 감각이었다.

단축키와 꿀팁 정리

오늘 나온 단축키와 작업 팁을 모아둔다.

단축키 · 기능설명
Cmd+K 플러그인 검색·실행 (하단 툴바에서도 가능)
Option+Cmd+K 컴포넌트 만들기
Shift+S 섹션 만들기
Clip content 카드 외곽의 라운드를 안쪽 프레임까지 적용
알값 9999 정사각 프레임을 원형으로
Option(Alt) + 요소 위에 호버 요소 간 간격·사이즈 값 확인

그밖에 기억해둘 것들. 슬롯은 프레임에만 걸리니 이미지·도형은 먼저 프레임으로 바꾼다. 다크 모드는 색을 직접 칠하지 말고 시멘틱 토큰으로 전환되게 만든다. 더미 텍스트가 필요할 땐 GPT나 한글 더미 플러그인을 쓰고, 영문이면 Lorem Ipsum으로 채운다.

정리하며

오늘 가장 크게 남은 건, 미뤄두고 쌓아온 작업이 한순간에 빛을 본다는 감각이었다. 시멘틱 컬러와 베리어블을 등록할 때만 해도 당장 눈에 보이는 결과가 없어 막연했는데, 다크 모드 스위치 하나로 화면 전체가 뒤집히는 걸 보니 그제야 그 토대가 무엇을 떠받치고 있었는지 보였다. 보이지 않는 곳을 단단히 해두면, 정작 필요한 순간엔 손이 거의 안 가는 일이 된다.

그리고 다크 모드가 무조건 좋은 게 아니라는 이야기도 오래 남았다. 정답을 하나로 못 박기보다 상황에 맞게 고르는 태도가, 결국 사람을 위한 설계의 기본이라는 생각이 들었다.

오후의 다크 모드 실습은 솔직히 진이 빠졌다. 베리어블이 자꾸 꼬여서 같은 작업을 몇 번이고 다시 했고, 다들 지쳐서 수업도 조금 일찍 마쳤다. 그래도 개념만큼은 확실히 손에 들어왔다.