안녕하세요. 조금만 기다리면 기다리던 5월 연휴입니다.
얼마전에 디자인 시스템과 Token, JSON에 연관된 글을 읽었는데요.
디자인 시스템에 대한 다양한 아티클을 읽으며,
"디자인 시스템은 왜 필요하며, 개발적으로 어떤점이 이득인가"에 대해
더욱 더 명확하게 기록하고 싶었습니다.
오늘 글은.. 제 경험이 굉장히 많이 담겨있기 때문에 좀 깁니다 ^^;;
(스압 ㅁㄹㅈㅅ)
👩🏻🎨 디자인 시스템은 어떻게 파생됐을까요?
저는 UI라는 개념을 2018년쯤부터 딥하게 배우기 시작했는데요.
그 당시에는 '디자인 시스템'이라는 단어보다는 '스타일 가이드'라는 표현을 더 많이 썼던 것 같습니다.
또한, 과거에는 디자이너와 프론트엔드 사이에 '퍼블리셔'라는 전문 역할이 있었죠.
퍼블리셔 분들이 JSON, CSS, 마크업과 관련된 영역을 책임졌던 기억이 있습니다.
하지만 현대에 와서는, 프로덕트 디자이너가 이 역할까지 아우르게 되었습니다.
단순히 화면을 꾸미는 것만이 아니라,
- 방대한 컴포넌트를 시스템화할 수 있는지
- 그 시스템을 재사용할 수 있는지
이 능력이 디자이너의 중요한 자질로 평가되고 있습니다.
[그렇다면, 디자인 시스템이 필요한 상황은?]
- 스타트업이 성장해서 신규 팀원이 많이 투입되는 경우
- 다수의 디자이너가 공통 규칙 없이 일하는 팀
- 빠르게 다양한 A/B 테스트를 돌려야 하는 환경
디자인 시스템이 발생하게 된 계기는, 이렇게 여러가지 계기가 있는데요.
여태까지 제가 경험한 것중 가장 많은 사례는 바로 첫번째인 것 같습니다.
사실 작은 규모의 회사나, 스타트업에서는 이 프로덕트가 얼마나 성장할 수 있을지 모르기 때문에 디자인 시스템이 없거나,
혹은 있어도 아주 작은 규모로 존재하게 됩니다.
특히 이렇게 디자인 시스템이 없는 곳에서는,
어김없이 '하드코딩'이라는 단어가 등장하게 됩니다.
예를 들어, "#000000" 이라는 검정색을 'primary_black'으로 변수화하지 않았다면,
개발자는 모든 코드를 뒤져서 "#000000"을 수작업으로 수정해야 합니다.
컬러 하나 바꾸자고 수십, 수백 군데를 수정해야 하는 일이 생기는 거죠.
🤔 그렇다면 하드코딩이 뭔데?
하드코딩이란,
코드 안에 값(예: 폰트, 컬러, 크기 등)을 직접 박아 넣는 것을 말합니다.
📦 폰트 변경이 필요할 때 발생하는 하드코딩 문제
예를 들어, 처음 프로젝트 시작할 때 디자이너가 "Roboto" 폰트를 기본으로 제안했다고 해요.
개발자는 아무런 시스템 설계 없이, 그냥 코드마다 직접 폰트를 지정합니다.
body { font-family: 'Roboto', sans-serif; } h1 { font-family: 'Roboto', sans-serif; font-weight: 700; } .button { font-family: 'Roboto', sans-serif; }
그러다가, 어느 날 디자이너가 요청합니다.
🧑🏻🔧 "저희 브랜드 리뉴얼해서 기본 폰트를 'Pretendard'로 바꿔야 해요!"
근데 개발팀에서는 이렇게 말합니다:
❌ "이거 바꾸려면 페이지 전체 다 뜯어야 해요... 시간이 너무 많이 걸려요."
왜?
폰트를 하드코딩했기 때문이에요.
수십, 수백 군데 폰트 코드가 다 따로따로 박혀 있어서,
일일이 찾아가면서 고쳐야 합니다.
(그리고 실제로는 빠뜨리는 곳이 꼭 생겨요… 결국 QA 폭탄🥲)
🙆🏻♂️만약, 디자인 시스템이 있었다면?
처음부터 폰트를 이렇게 정의했겠죠.
:root { --font-family-base: 'Roboto', sans-serif; }
그리고 실제 코드에서는 이렇게 정의를 내립니다.
body { font-family: var(--font-family-base); } h1 { font-family: var(--font-family-base); font-weight: 700; } .button { font-family: var(--font-family-base); }
➡️ 이렇게 했으면,
변경할 때는 --font-family-base 값만 수정하면 끝! 🎯
만약 폰트를 Roboto에서 Pretendard로 바꾸고 싶다?
--font-family-base: 'Pretendard', sans-serif;
👉 단 1줄로 전체 폰트 변경 완료. 아주 간단하죠?
☠️ 그래서, 명확하지 않은 디자인 시스템은 하드코딩을 발생시킨다.
여러 프로젝트를 해본 디자이너라면, 분명 앞의 경험을 해본적이 99.999% 있으셨을거라고 봅니다.
예를 들면 이런 경우인거죠.
디자인 시스템이 없는데, (당연히 하드코딩했겠죠?)
클라이언트가 300개의 화면에 대해 동일한 버튼의 UI를 바꾸고 싶다합니다. -> 🤦🏻♀️ 이거 대략 난감인거죠..
그래서, 결국 모든 UI는 개발과 정말 밀접하게 관련이 있다는 말을 하고 싶습니다.
- 화면에 배치한 수많은 UI -> 개발에서 API 명세서의 기준이 됨
- 컴포넌트 명칭 -> 코드에서의 "변수명"
이렇게 우리가 만드는 수많은 UI와, 명칭은 개발에서 가장 중요한 기준의 첫 시초에 해당합니다.
그래서 명확하지 않은 UI 기능과, 컴포넌트 명칭이 많아질수록 개발단계에서는 지레짐작하고 개발하기 때문에
결국 하드코딩(노가다코딩)과 수많은 QA,QC를 야기시킵니다. (윗물이 맑아야,,아랫물도 맑다..)
사용성을 고려한 UX/UI도 정말 중요합니다만,
나무가 아닌 숲을 보기 위해서는
- 사용자에게 더 빠른 업데이트를 제공하기 위해,
- 그리고 프로덕트의 유지보수를 위해,
- 팀원들간의 커뮤니케이션을 위해
스스로 just 디자이너가 아닌 "시스템 아키텍처"라고 생각하는 것이 디자이너가 한단계 성장하는 발판이라고 생각이 듭니다. :)
(사실 디자이너를 국문으로 풀면 설계자이기도 해요.)
💬 그래서 다음편은..
이 디자인 시스템을 어떻게 전달해야 개발팀과 잘 커뮤니케이션 할 수 있을지,
디자인 시스템과 - Token - JSON에 대한 개념과 디자인 시스템을 잘 전달하는 방법, 그리고 피그마에서는 왜 디자인 시스템과 관련된 기능을 넣었는지에 대한 유래를 모두 기재해보려합니다!
IT업계는 정말 빨리 바뀌지만, 그렇다고 알짜배기만 배운다고 해서 실무를 잘할 수 있다는 생각은 금물인 것 같습니다.
항상 동료들과 하는 토픽 중 제일 메인은, 결국에는 돌고 돌아 디자인의 개념, 그리고 CS의 개념에 대해 알아야 왜 현재 이런 프로세스가 나왔는지 알 수 있다는 부분인데요.
이러한 부분들을 천천히 탑재해간다면, 어느 순간 기획,디자인,개발을 어울러서 혼자 창업할 수 있지 않을까요? (하하)
자, 그럼 다음편으로 찾아오겠습니다. 읽어주셔서 감사합니다!
