기획자 입장에서 본 디자인 시스템 도입 과정과 현실적인 한계

디자인 시스템은 보통 디자이너, 프론트엔드 개발자가 정리하는 일이라고 생각하기 쉽다.

하지만 나는 기획자로서, 어느 순간부터 디자인 시스템의 필요성을 절실하게 느끼게 되었다.

 

처음부터 거창한 목적이 있었던 것은 아니고, 서비스 내에서 똑같은 기능인데도 버튼이 매번 다른 색을 가진다던가 폰트가 다르다던가 등등의 사례를 보면서 이게 맞나하는 생각이 들었던 게 시작이었다.

---

1. 왜 디자인 시스템이 필요할까?

1) 통일된 UI는 사용자 경험의 기본

내가 디자인 시스템을 도입하고자 한 첫 번째 이유는 통일감 있는 서비스를 만들고 싶었기 때문이다.

같은 '확인' 버튼인데 어떤 페이지에서는 초록색, 어떤 페이지에서는 회색이면 사용자 입장에서는 기능 자체가 다르게 느껴질 수 밖에 없다.

통일되지 않은 디자인 예시. 예시라도 이런식이면 곤란하다

 

이런 작은 UI 요소의 불일치는 결국 전체 서비스의 완성도를 떨어뜨리고 사용자의 혼란을 유발한다.

 

2) 협업 효율을 높이기 위한 필수 구조

디자인 시스템이 없다면, 디자이너 > 기획자 > 프론트엔드 개발자로 이어지는 흐름에서 작은 요소 하나에도 수많은 커뮤니케이션 비용이 발생한다.

• 버튼 radius, 색상, 폰트, 자간, 간격 등
• 매번 지난번엔 이거였는데 이번엔 왜 바꼈죠? 라는 질문 받기 쉽상
• 정해진 기준 없이 매번 '때려 맞추는' 코드

디자인이 통일되지 않을 경우 발생하는 문제

 

결국 기확지인 나는 중간에서 이 모든 갈등과 헷갈림을 받아야 하는 입장이 된다.

실제로는 디자이너가 의도한 UI가 기능 구현만 급급해서 뭉개지는 경우도 많았고, 이는 서비스 퀄리티와 사용자 만족도에도 영항을 줄 수 밖에 없었다.

 

 

2. 내가 디자인시스템 도입을 위해 시도한 방법

디자인 시스템이란 이름을 붙이긴 했지만, 처음에는 아주 작고 단순한 기준부터 정리하기 시작했다.

1) 공통 정의부터 시작

(1) Width 정의

•  PC웹 / 앱 각각의 레이아웃 기준 설정
• auto-layout 적용 영역부터 정리

(2) Foundation : 색상과 폰트 기준 정리

• font-size, font-weight, font-family 등 폰트 기준 정리
• 메인 색상, 보조 색상, 배경 색상 등 변수로 분리

(3) 컴포넌트 단위 정리

• 새롭게 디자인되는 기능부터 컴포넌트화
• 페이지 단위가 아닌 UI 단위로 모듈 구성

 

2) 정리 방식 예시

피그마 프로퍼티 관리 예시 (기획서 작성 시 대충 만든거라 좋은 예시는 아님!)

• 도메인/서비스별로 페이지를 나누고, 컴포넌트와 에셋을 따로 관리
• 동일한 레이아웃 구조는 공통 아나토미로 묶기 > 피그마에서 프로퍼티만 바꿔도 다른 유형으로 사용 가능
• Local Variables로 색상 채계화
  
  • 컬러 팔레트와 실제 용도 분리
  • 경고, 중요, 기본 등 의미별 컬러 그룹 생성
  • 색상 추가 시 용도별 자동 적용 가능하게 구성

이러한 기준은 피그마 기반으로 시작했지만, 프론트엔드 개발자들과도 공유해 코드 적용에도 연동될 수 있도록 정리했다.

 

 

3. 결과는? 반은 성공, 반은 실패

디자인 시스템 도입은 생각보다 훨씬 많은 시간과 합의, 그리고 체력이 필요한 일이다.

 

작은 부분들(폰트, 색상, 버튼 스타일 등)은 정리했지만, 팀 구조상 바쁜 업무로 인해 디자인 시스템을 운영하지는 못했다.

또한 프론트엔드 코드가 이미 고착화되어 있어(레거시 코드,,ㅎ) 전면 적용이 어려운 부분도 많았다.

 

그래도 이 작업을 통해서 얻은 것은 있었다.

- 새로운 기능 개발에는 일부 기준이 적용되기 시작

- 디자인, 개발 모두 일부 컴포넌트 재사용 가능

- 디자이너, 개발자 협업 시 공통 언어가 생김. 기획자의 커뮤니케이션 비용 감소.

 

그리고 느낀 점도 있다.

- 디자인 시스템은 기획자 혼자 정리할 수 있는 일이 아니다. 디자이너와 개발자의 실제 작업 흐름을 반영해야만 한다.

- 컴포넌트 네이밍 하나도 사용하는 당사자들과 사전에 합의된 규칙이 필요하다.

- 팀 규모가 작고 개발 리소스가 부족하다면, 완성된 시스템보다 '가이드라인 정리'부터 시작하는 게 현실적이다.

 

 

4. 도입을 고민 중이라면?

디자인 시스템은 한 번에 확립되는 게 아니라, 계속 만들어가는 것이라고 생각한다.

시간이 부족하고, 명확한 가이드 없이 진행하면 결국 모두가 중간에 포기하게 된다. 그래서 우리 같이 리소스가 부족한 작은 팀에서 도입을 고민 중이라면, 처음에는 작은 룰 하나부터 만들고, 반복 작업을 줄이는 데 집중하는게 현실적이다.

 

시간이 지나면 이것들이 디자인 시스템의 씨앗이 될 것이다.

 

 

5. 참고할 만한 국내 디자인 시스템

해외 사례도 물론 좋지만, 나는 국내 개발 환경에 더 가까운 아래 사이트들 중 일부를 더 많이 참고했다.

• G마켓 디자인 시스템
• KRDS
• SOCAR 프레임
• 라인 디자인 시스템
• 11번가 디자인 시스템

그리고 해외 사례를 참고하고 싶다면, Google Material, Apple HIG를 참고하면 좋다.

 

 

6. 마무리

결국 기획자도 디자인 시스템에 관심을 가져야 한다고 생각한다.

왜냐하면 기획자는 디자인과 개발자 사이에서 가장 자주 중재하는 입장이기 때문이다.

 

디자인 시스템은 툴이 아니라 협업 언어다. 그래서 정리하는 데 드는 수고는 있지만, 결국 서비스의 통일감, 협업 효율, 유지보수성을 모두 높이는 방향으로 돌아온다. 나처럼 작은 팀에서 시작한다면, 디자인 시스템 도입이 부담스럽게 느껴질 수도 있지만, 가이드라인 정리부터라도 시작해보길 추천한다.

 

 

함께 보면 좋은 글

👉🏻 피그마 기획서 작성법 | 궈킨(Gherkin) 문법으로 개발자와 협업하는 방법

 

 

 

기획자 입장에서 본 디자인 시스템 도입 과정과 현실적인 한계