logo
|
Blog
  • 회사 소개
  • Alarmy
  • DARO
  • Delighthub
딜라이트룸 채용
프로덕트

AI 시대의 디자인 시스템: 적정 밀도는 무엇일까?

디자인 시스템은 무엇이고, 무엇이 아닌가
DelightRoom's avatar
DelightRoom
Mar 11, 2026
AI 시대의 디자인 시스템: 적정 밀도는 무엇일까?
Contents
디자인 시스템은 무엇이고, 무엇이 아닌가디자인 시스템은 ‘일관성’과 ‘판단 비용’의 문제입니다ADS 2.0에서 3.0으로, 무엇이 달라졌나13년 된 서비스에서 기초를 다시 설계하며문제는 UI가 아니라 기준이었습니다더 정교하게가 아니라, 더 명확하게팔레트 — 감이 아니라 구조로 보기갈아엎지 않고, 덮어씌워 검증하기시멘틱 — 협업 도구가 아니라 시스템 언어디자인 시스템은 무엇이고, 무엇이 아닌가적정 밀도라는 질문

디자인 시스템은 무엇이고, 무엇이 아닌가

디자인 시스템은 ‘일관성’과 ‘판단 비용’의 문제입니다

기능이 많아질수록 디자인 시스템은 일관성을 유지하는 일인 동시에, 판단 비용을 관리하는 일이 됩니다.

이번 글은 그 두 가지를 함께 지키기 위해, 시스템이 어떤 판단을 맡고 어떤 판단은 맡지 않을지 ‘적정 밀도’를 다시 정리한 기록입니다.

AI가 초안을 빠르게 만들어줄수록, 팀이 흔들리지 않게 만드는 건 결국 ‘기준’이라는 사실도 함께 확인하게 됐습니다.

이 이야기는 저희 조직의 사례이기도 하지만, 여러 팀이 같은 UI를 함께 만드는 환경이라면 비슷한 형태로 겪게 되는 문제이기도 합니다.

ADS 2.0에서 3.0으로, 무엇이 달라졌나

이번 개편은 “구성 요소를 더 많이 만들기”가 아니라, 기준의 규격을 다시 맞추는 업그레이드였습니다.

변경사항은 크게 세 가지입니다.

Semantic: Emphasis 같은 표현 대신 Foreground처럼, 해석이 아니라 역할이 먼저 보이게 언어를 바꿨습니다.

Typography: 역할 구조는 유지하되, 스케일과 Weight 조합을 제한하고 네이밍을 단순화해 적용 판단을 줄였습니다.

Palette: 들쭉날쭉했던 값을 단계화해, 선택지가 ‘감’이 아니라 ‘구조’로 고정되게 만들었습니다.

이 글은 이 업그레이드 과정에서, 무엇을 시스템이 맡아야 팀이 빨라지고 흔들리지 않는지를 정리한 기록입니다.

13년 된 서비스에서 기초를 다시 설계하며

디자인 시스템을 고쳤다는 이야기를 하기 전에,
왜 이 일이 만만하지 않았는지부터 말하고 싶습니다.

2013년에 출시된 뒤, 13년을 지나온 서비스입니다.
기능은 많아졌고, 팀은 나뉘었으며, 속도는 여전히 중요합니다.

이 상황에서 디자인 시스템을 손본다는 건 비행 중인 비행기의 엔진을 여는 일과 비슷합니다.

게다가 우리는 새로 만드는 게 아니었습니다.
이미 잘 돌아가고 있는 시스템을 다시 들여다보는 일이었습니다.

망가진 걸 고치는 건 명분이 분명합니다.
하지만 잘 돌아가는 걸 고치는 건 조금 다른 종류의 판단을 요구합니다.

문제는 UI가 아니라 기준이었습니다

화면은 멀쩡했습니다. 서비스도 안정적으로 작동했습니다.

문제는 ‘겉으로 보이는 결과’가 아니라, 그 결과를 만들어내는 기준의 규격이었습니다.

ADS 2.0은 얼핏 보면 퍼즐처럼 맞아 돌아가지만, 자세히 보면 조각의 규격이 조금씩 달랐습니다.

그 차이는 당장 화면을 깨뜨리진 않지만, 시간이 지날수록 판단을 느리게 만들었습니다.

차이가 드러나는 방식은 단순했습니다.

  • 같은 회색인데 화면마다 느낌이 달랐고
  • 같은 강조인데 톤이 달랐고
  • 그래서 매번 “이게 맞나?”를 다시 확인해야 했습니다

기준이 명확하지 않으면 판단은 계속 사람에게 돌아옵니다. 사람이 반복해서 판단해야 하면 속도는 조금씩 느려집니다.

그때 깨달았습니다.

기능이 많아질수록 디자인 시스템은 미학의 문제가 아니라, 반복되는 결정을 줄이고 기준을 고정하는 문제가 된다는 것을요.

더 정교하게가 아니라, 더 명확하게

이번 작업의 방향은 의외로 단순했습니다.

더 많은 규칙을 만드는 대신, 반복적으로 고민되는 지점만 시스템이 맡게 만드는 것입니다.

그 외의 영역은 억지로 묶지 않는 것입니다.

여기서 말하는 적정 밀도는, 시스템이 반복되는 판단을 대신해주는 정도와 그로 인해 생기는 유지 비용 사이의 균형입니다.

AI가 반복 작업을 덜어줄수록, 사람의 판단은 오히려 ‘예외와 기준’ 쪽으로 더 모이게 됩니다.

팔레트 — 감이 아니라 구조로 보기

가장 먼저 본 건 팔레트였습니다.
색 자체에 큰 혼란은 없었습니다. 이미 잘 쓰이고 있었고, 디자이너들도 익숙했습니다.

하지만 Gray Scale을 자세히 보면 50, 100 대신 97, 95처럼 세분화된 값들이 많았습니다.

Gray Scale만 따로 봐도 단계가 21개나 됐습니다. 즉, 회색을 고를 때마다 ‘정답 후보’가 21개라는 뜻이었습니다.

바로 화면이 깨지거나 큰 사고가 나진 않습니다.

다만 새로운 화면을 만들 때마다 “이 중 어디를 써야 하지?”라는 작은 판단이 반복됐습니다. 그래서 핵심은 색을 “더 촘촘하게”가 아니라 더 선택하기 쉽게 만드는 것이었습니다.

감으로 고치지 않기로 했습니다. 데이터를 보기로 했습니다.

팔레트 값을 CSV로 추출한 뒤, 참고한 공개 팔레트(shadcn)와 비교

1. ADS 2.0 팔레트 값을 CSV로 추출하고

2. 참고한 공개 팔레트(예: shadcn)와 비교한 뒤

3. ΔRGB + 3×ΔL 기준으로 가장 근접한 단계를 매핑하고

4. 매핑 컬러 데이터를 다시 추출해 Figma Make로 시각화하고, 실제 화면 기준으로 검수했습니다.

팔레트 값을 CSV로 추출한 뒤, 참고한 공개 팔레트(shadcn)와 비교
Figma Make를 활용해 기존 팔레트와 매핑 예정 컬러를 비교 검수

Figma Make를 활용해 기존 팔레트와 매핑 예정 컬러를 시각화

이 과정에서 AI를 적극적으로 활용했습니다.
수치 비교와 시트 정리는 분명히 빨랐습니다.

하지만 곧 알게 됐습니다.

AI가 생각하는 기계적인 ‘매핑’과, 실제 UI에서 의도와 맥락을 반영해 사용된 단계 사이에는 생각보다 큰 간극이 있다는 것을요.

색 계산은 정확했습니다.
문제는 “이 2.0 토큰을 3.0의 어떤 항목에 붙일지”였습니다.

토큰 네이밍을 충분히 반영하지 못하거나, 가장 근접한 HEX를 기준으로 엉뚱한 항목에 연결되는 경우가 반복됐습니다.

그래서 CSV를 한 번 뽑고 끝내지 않았습니다.

추출 → 매핑 → 검토 → 수정 → 다시 추출.

이 과정을 거의 10번 가까이 반복했습니다.

AI가 해준 건 빠른 초안이었습니다.

최종적으로 “이 매핑 결과가 맞는가”를 판단하는 일은 여전히 사람의 몫이었습니다.

갈아엎지 않고, 덮어씌워 검증하기

새 팔레트를 정의한 뒤에도 우리는 2.0을 바로 지우지 않았습니다.

대신 3.0 값을 2.0 팔레트 변수(Variables)에 매핑해 덮어씌웠습니다.

이미 운영 중인 화면 위에서 어떤 변화가 발생하는지 확인하기 위해서였습니다.

색상차가 큰 구간을 우선 점검했고, 시각적으로 어색해 보이는 화면은 다시 조정했습니다.

이번 작업은 리셋이 아니라 마이그레이션에 가까웠습니다.

새 체계를 선언하기 전에, 기존 시스템 위에서 충분히 흔들어봤습니다.

결과적으로 선택지는 줄었고, 팀 간 합의는 더 빨라졌습니다.

시멘틱 — 협업 도구가 아니라 시스템 언어

ADS 2.0에도 시멘틱 토큰(의미 기반 토큰)은 존재했습니다.

하지만 목적은 주로 디자인 협업을 위한 것이었습니다.

예를 들어 Emphasis / High, Medium, Low 같은 구조는 강조 정도는 설명하지만, 역할까지는 드러내지 않습니다.

사람은 이해할 수 있습니다. 하지만 시스템은 감이 없습니다.

그래서 우리는 Emphasis 대신 Foreground라는 개념을 도입했습니다.

Foreground는 텍스트만 의미하지 않습니다.

배경 위에 올라오는 모든 요소를 하나의 역할로 묶습니다.

이 변화는 협업을 편하게 만들기 위한 선택이라기보다, 해석의 여지를 줄이기 위한 결정에 가깝습니다.

디자인 시스템은 무엇이고, 무엇이 아닌가

가끔 개발자들과 이야기하다 보면 이런 말을 듣습니다.

“디자인 시스템이 없어서 개발하기 어렵다.”

이 질문을 들으면 ‘디자인 시스템’은 무엇일까, 다시 생각하게 됩니다.

대화를 이어가 보면, 그때 개발자가 말하는 ‘디자인 시스템’은 토큰이나 컴포넌트보다 *화면을 그리기 위한 정의(정책과 우선순위)*에 가까운 경우가 많았습니다.

특정 화면을 구현하려고 할 때 무엇을 어떤 우선순위로 보여줘야 하는지, 어떤 상태와 예외를 고려해야 하는지 기준이 정리되어 있지 않을 때가 많아 결국 “이 화면을 어떻게 구성해야 하지?”에서 멈추는 순간이 반복됐습니다.

디자인 시스템은 기획을 대신하지 않습니다.

정책을 대신하지도 않습니다.

결정을 대신 내려주지도 않습니다.

다만 이미 내려진 결정을 일관되게 반복할 수 있게 도와줄 뿐입니다.

그리고 AI가 기획의 일부를 점점 더 보조하게 될수록, ‘무엇을 만들 것인가’ 못지않게 그 결정을 어떤 기준으로 일관되게 구현할 것인가가 중요해집니다.

이번 개편에서 우리가 특히 집중한 것도, 상태와 예외까지 포함해 일관성을 유지할 수 있는 명확한 가이드라인을 만드는 일이었습니다.

적정 밀도라는 질문

기능이 많아질수록 디자인 시스템은 일관성을 유지하는 일인 동시에, 판단 비용을 관리하는 일이 됩니다.

이번 작업을 통해 우리는 시스템이 무엇을 맡고 무엇을 맡지 않을지의 경계를 더 또렷하게 그렸습니다.

다음 단계는 색과 토큰을 넘어서, 상태와 예외(정책)를 어디까지 시스템이 맡을지 기준을 확장하는 일입니다.

적정 밀도라는 건 정답이라기보다 균형에 가깝습니다.

우리는 이번에 그 균형을 조금 더 선명하게 만든 셈입니다.

AI 시대일수록, 더 많은 결과물을 만드는 것보다 ‘결정의 기준’을 또렷하게 만드는 일이 먼저입니다.

⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌

→ 딜라이트룸 채용 공고 살펴보기 ⏰

Share article
Contents
디자인 시스템은 무엇이고, 무엇이 아닌가디자인 시스템은 ‘일관성’과 ‘판단 비용’의 문제입니다ADS 2.0에서 3.0으로, 무엇이 달라졌나13년 된 서비스에서 기초를 다시 설계하며문제는 UI가 아니라 기준이었습니다더 정교하게가 아니라, 더 명확하게팔레트 — 감이 아니라 구조로 보기갈아엎지 않고, 덮어씌워 검증하기시멘틱 — 협업 도구가 아니라 시스템 언어디자인 시스템은 무엇이고, 무엇이 아닌가적정 밀도라는 질문

Delightroom

RSS·Powered by Inblog