마케팅

디자인 시스템을 유지하는 힘, 구조가 아닌 유연함!

내가 가진 환경 안에서 디자인 시스템을 구축하는 방법

2025.11.24

구글 검색 선호 매체로 추가

실전 마케팅이 궁금하다고요? <디지털 인사이트>가 마케팅 기업이 발행하는 자체 콘텐츠 가운데 실무에 활용하기 좋은 글만 추려 읽기 좋게 정리했습니다. 원문을 참고하면 더 자세한 내용을 알 수 있어요.

---

---

디자인 시스템 구축은 많은 기업에서 일관성 있는 서비스를 유지하기 위해 당연하게 받아 들여지고 있고, 디자이너들에게는 일종의 필수 관문처럼 여겨지기도 합니다.

저 또한 그렇게 생각하던 시기가 있었는데요, 하지만 이번 글에서 이야기하고자 하는 내용은 디자인 시스템을 구축하는 방법은 아닙니다. 디자인 시스템을 서비스에 맞게 구축할 수 있도록 어떤 방식을 택했는지에 대한 과정과, 직접 디자인 시스템 구축을 하면서 느낀 점에 대해 회고해보고자 합니다.

디자인 시스템은 생각 이상으로 오래 걸린다

디자인 시스템 구축이란 한편으로는 고도의 기획적인 설계 작업이면서, 다른 한편으로는 굉장히 단순한 반복 노동 작업이기도 합니다. 모든 경우의 수를 디자인하기 위해 컴포넌트를 나열하다 보면 그 수는 순식간에 수백 개로 늘어나기 마련입니다. 물론 AI나 피그마 플러그인의 도움을 받을 수 있지만, 근본적인 작업은 수동에 가깝다는 사실을 부정할 수 없습니다.

그래서 더더욱 시간 투자 대비 결과물에 실망할 수도 있습니다. 구축에 오랜 시간을 투자했는데, 막상 눈에 보이는 결과물은 기존에 사용하던 화면과 크게 다르지 않을 수 있거든요. 잘 정리된 UI Kit는 시각적인 임팩트를 줄 수 있지만, 내부적으로 생산성을 즉각적으로 증명하기는 어려운 작업이기도 합니다. 또 실무자 외에는 디자인 시스템으로 인해 향상된 업무 효율을 체감하기 어려울지도 모릅니다.

우리 역시 고작 한 화면에 디자인 시스템을 적용해보기까지 대략 반년이 소요되었습니다. 그 이유는 이미 실천 중인 프로세스를 깨고 새로운 방식을 도입하는 것은 굉장히 어려운 일이기 때문입니다. 또한 디자인 시스템은 디자이너 팀만의 작업이 아닙니다. 개발자와의 소통을 위한 약속을 만들어 나가기 때문에, 커뮤니케이션을 문서화하는 작업이라고 보시는 게 좋을 것 같습니다. 따라서 한 가지의 요소도 어떻게 서로 구분하고 이해할 것인지 약속이 필요한데요. 그 약속을 만들어나가는 과정에서 시행착오도 생기기 마련입니다. 그래서 디자인 시스템을 도입하기 전, 장기적인 작업이 될 것을 염두하고 시작하는 것이 좋습니다.

완전한 디자인 시스템은 없다

자주 반복되는 디자인이라면 시스템을 고도화하여 관리하는 것이 맞습니다. 하지만 서비스를 개선하거나 확장할수록 한정된 디자인 시스템으로는 모든 상황을 통용하기 어렵습니다. 이럴 땐 꼭 그 시스템 안에 갇히기보다는 최소한의 통일점만 갖고 나아가더라도 관리에 충분합니다.

정해진 규칙 내에서 자유롭게 조립이 가능한 형태로 디자인하는 것이 수정이나 새로운 디자인을 추가하는 데 무리가 없었습니다. 특히 제가 작업한 경우에도 복잡하고 많은 라벨링이 필요한 서비스여서 라벨을 조합할 수 있는 최소한의 규칙을 정해두고 다양한 조합을 만들어 나가는 방식이 훨씬 효과적이었습니다. 또한, 프로젝트 성격에 따라 일회성이거나 완전 커스텀 디자인이 필요한 경우도 있습니다. 그럼 그 때마다 디자인 시스템을 복사하여 작업을 할 건가요? 아니면 완전히 새로운 디자인 시스템을 다시 새로 구축할 건가요?

정답은 없습니다. 핵심은, 환경과 목적에 맞는 유연한 적용이 필요합니다.

디자인 시스템을 구축하기로 한 이유

일관되지 않은 디자인으로 인한 충돌이라던가, 모두가 알고 있는 빈번한 문제점이지만 사실 내부에선 디자인 측면의 문제만으로는 변화로 움직이지 못했습니다. 일관성 없는 디자인으로 인한 충돌이나 그에 따라 발생하는 비효율은 사용자나 개발자 입장에선 잘 작동하기만 하면 크게 문제 삼지 않았거든요. 하지만 새로운 서비스가 추가될수록, 필요에 의해 그때그때 덧붙여진 디자인은 전체적인 흐름을 더욱 복잡하게 만들었고, 내용을 추가할 때마다 반복되는 업데이트 작업을 피할 수 없었습니다.

내부에서 필요성을 느끼지 못한 것은, 이미 그 리소스에 익숙한 실무자들이 있었기에 시간에 쫒기는 업무 속에서 숙련자가 빨리 처리를 하는 편이 디자인 시스템을 구축하는 시간보다 더 효율적일 수 밖에 없었기 때문이었습니다. 그럼에도 불구하고 변화를 결심하게 된 가장 큰 계기는 바로 바뀐 개발 환경이었습니다. React로 개발 환경이 변경되면서 퍼블리싱 업무 영역이 모호해지자, 디자인 통일에 대한 문제가 수면 위로 떠오르게 된 거죠.

저는 이 시점에서 고민했습니다. 디자인 시스템을 어떤 목적을 가지고 구축할 것인가? 내부에서 디자인 시스템을 구축하기 원하는 가장 중요한 목적을 파악해야 했습니다. 제가 꼽은 가장 두드러지는 목표는 React 환경에 맞춘 ‘유연한’ 디자인 구성을 제공하는 것이었습니다. 저는 아래와 같은 최소한의 목표를 세워 점진적으로 시스템을 구축해 나가기로 했습니다.

내가 가진 환경 안에서 디자인 시스템 구축하기

1. 매 서비스마다 중복 작업 줄이기

기존에는 CSS 충돌로 인해 !important를 무리하게 부여하며 구축하는 작업이 많았고, 그만큼 일회성 CSS가 넘쳤습니다. 이 상황에서 React로 구현하기는 엉킨 이어폰 줄 풀기 같은 일이 되어버렸습니다. React 라이브러리에 css 파일을 덧씌우며 억지로 제어하는 건 이젠 정말 시간 낭비였습니다. 그래서 중복 작업을 최소화하고 비효율적인 시간 낭비를 줄이고자 디자인 시스템 설계를 결정했습니다.

예시로, 이전에도 아이덴티티 컬러는 이미 정해진 바가 있었지만, variation은 그때그때 opacity로 표현하며 추가했습니다. 한 번 쓰고 잊혀지거나 육안으로 유사한 색상이 여러 개 존재하는 등의 문제가 허다하여 불필요한 css가 점점 쌓이고 있었던 것이죠. 이를 방지하기 위해서 이번 업데이트 때 파운데이션을 활용하여, 각 메인 컬러마다 light-dark, normal-hover-active 규칙을 부여하며 규칙적인 컬러 팔레트를 늘려나갔습니다.

이렇게 구축하였을 때는 색을 변경하더라도 경우에 맞게 선택이 가능하며, 컬러를 사용한 이유를 즉시 이해하기 편리해집니다.

2. 점진적인 고도화

이미 많은 기능을 포함한 서비스였기에, 모든 디자인 작업을 마친 후 한 번에 적용하기에는 기약이 없을 것이라고 판단했습니다. 따라서 기존 서비스에 하나씩 적용하기 위해 필요한 컴포넌트를 개발하여 붙여나가는 방식을 선택했습니다.

이는 앞서 언급했던 기존의 필요에 의해 그때그때 디자인을 붙여 넣는 방식과 다를 바 없어 보일 수 있지만, 핵심은 최소한의 규칙 내에서 확장성에 유의하며 디자인을 만들어 나가는 것입니다.

1. 초기 단계: 기본적인 설정인 타이포그래피, 간격 및 레이아웃, 브레이크 포인트와 같은 최소한의 규정을 우선적으로 설계했습니다. (예: spacing은 4px의 배수인 4px, 8px, 16px, 24px, 32px 등으로 규정하고 padding, margin, gap 값을 설정해 나아감)
2. 규칙 정리: 모달, 카드, 테이블 등 규칙이 필요한 핵심 컴포넌트의 가이드라인을 정리했습니다.
3. 반복되는 작업을 컴포넌트화: 반복적으로 사용되는 UI 패턴을 정리하고 컴포넌트화했습니다.
4. 라이브러리 작업: 컴포넌트를 라이브러리로 활용 가능하게 끔 정리했습니다.

이러한 점진적인 방식을 택한 것은, 서비스에 새로운 살을 붙일수록 새로운 디자인이 필연적으로 필요해지기 때문이며, 시스템이 유연하게 확장될 여지를 남겨두기 위함이었습니다.

3. 토큰 활용하기

? 관련 포스트 참고: Figma와 React로 자동화된 디자인 시스템 구축하기

토큰 스튜디오를 선택한 이유: 유지보수성과 확장성의 극대화

이러한 프로세스가 가능하게끔 도와준 것은 바로 토큰 스튜디오였습니다. 효율성을 찾는 과정에서, 협업 개발자와 논의 끝에 디자인 변경 사항이 GitHub에 연동되어 자동으로 반영되는 방식을 채택하였습니다. 토큰 스튜디오로 디자인 시스템과 코드의 동기화를 통해, 반복 작업을 줄이고 작업의 정확도를 극대화 시킬 수 있었습니다. 언제 업데이트를 하였는지 로그만 남겨둔다면 개발자의 도움 없이도 디자이너가 스스로 업데이트가 가능하였고, 개발자 역시 효율적인 프로세스를 통해 무리 없이 수정된 디자인으로 개발에 바로 적용하였습니다. 또한 컴포넌트 재사용성을 증가시켜 토큰 기반의 일관된 디자인을 보장할 수 있었습니다.

유연한 디자인 시스템을 향한 고민

디자인 시스템의 토대를 세우고 실제 프로젝트에 적용하는 과정에서 많은 시행착오가 있었습니다. 모두가 함께 지켜야 할 원칙을 만들고, 그 약속을 바꾸거나 업데이트한다는 것은 생각보다 훨씬 어렵고 섬세한 일이었습니다.

처음에는 완벽한 디자인 시스템을 만드는 것이 목표였습니다. 모든 컴포넌트를 일관되게 정의하고, 재사용 가능한 구조를 갖추는 것에 집중했죠. 하지만 실제로 시스템을 운영하고 유지하다 보니, 완벽함보다 유연함이 더 중요한 가치라는 걸 점점 실감하게 되었습니다.

특히 React 기반 환경에서는 변화가 잦고, 다양한 라이브러리와의 호환이 필수적입니다. 이런 환경에서는 단단히 닫힌 구조보다, 확장성과 수정 여지를 남긴 유연한 시스템이 훨씬 실용적이었습니다. 새로운 요구사항이 생기거나 디자인이 바뀔 때도, 기존 구조를 무너뜨리지 않고 자연스럽게 이어갈 수 있었죠.

물론, 상황에 따라 완벽하게 갖춰진 디자인 시스템이 필요한 경우도 있습니다. 그 선택은 디자이너의 몫이고, 반드시 짚고 넘어가야 할 것은 왜 디자인 시스템을 구축하려 하는가입니다. 시스템은 그 자체로 목적이 아니라, 디자이너와 개발자, 그리고 제품을 더 효율적으로 연결하기 위한 수단이기 때문입니다.

디자인 시스템은 한 번 완성되는 것이 아니라, 팀의 상황과 제품의 방향에 따라 끊임없이 진화해야 하는 살아 있는 구조입니다.

• 에디터이민호 (treewords@ditoday.com)