“이 버튼, Hover 상태에서 컬러 값이 어떻게 되나요?”
“모바일 환경에서 이 영역의 좌우 패딩 값도 유지되나요?”
디자이너의 작업물이 실제 제품으로 구현되는 과정에서 발생하는 수많은 질문은 단순한 궁금증이 아니라, '구현을 위한 명확한 정의'가 부족할 때 발생하는 커뮤니케이션 비용입니다. 프로덕트 디자이너는 단순히 심미적인 화면을 그리는 것을 넘어, 논리적으로 납득할 수 있는 설계도를 전달해야 합니다. 이번 글에서는 개발자의 불필요한 고민을 줄이고, 제품의 일관성을 보장하는 디자인 시스템 기반의 협업 방식을 다룹니다.
협업 관점에서 디자인 시스템을 만들어야 하는 이유
디자인 시스템, 디자인을 일관성 있게 유지하기 위해서 만드는 것도 있지만 더 크고 중요한 이유로 만듭니다. 개발 프로세스 내에서 디자인 시스템은 단순한 가이드를 넘어, 제품의 생산성을 결정짓는 인프라입니다. 구체적으로 디자인 시스템이 협업의 질을 어떻게 바꾸는지 세 가지 관점에서 살펴보겠습니다.
1. 공통 언어를 통한 커뮤니케이션 비용을 최소화합니다
디자이너가 "이 버튼은 우리 브랜드의 메인 컬러로 해주세요" 라고 말할 때, 개발자는 코드에서 #3A82F7을 찾아야 할지, blue_600을 사용해야 할지 고민하게 됩니다.
디자인 시스템은 이러한 추상적인 표현을 ‘디자인 토큰’이라는 공통의 언어로 정의합니다. 명확하게 정의된 언어는 불필요한 확인 과정을 생략하고, 비즈니스 로직을 구현하는 더 본질적인 대화에 집중하게 만듭니다.
2. 컴포넌트의 모듈화를 통한 개발 속도 및 재사용성을 높입니다
디자인 시스템이 없는 환경에서 개발자는 매 페이지마다 중복되는 UI를 매번 새로 코딩하거나, 과거의 코드를 찾아 복사해야 합니다. 이는 코드의 파편화를 초래하고 유지 보수를 어렵게 만듭니다.
잘 설계된 디자인 시스템은 UI를 독립적인 컴포넌트 단위의 모듈로 분리합니다. 개발자는 마치 레고 블록을 조립하듯 미리 검증된 컴포넌트를 조합하여 화면을 구성할 수 있습니다. 이는 초기 구현 속도를 비약적으로 높일 뿐만 아니라, 특정 UI의 변경이 필요할 때 시스템의 소스 코드 한 곳만 수정하면 프로덕트 전체에 반영되는 강력한 운영 효율성을 제공합니다.
3. 여러 케이스에 대한 예측 가능성을 제공 합니다.
개발 과정에서 가장 병목이 발생하는 지점은 정의되지 않은 상태를 만났을 때입니다. "데이터가 없을 때는 어떤 화면을 보여주나요?", "텍스트가 길어져서 영역을 넘어가면 어떻게 처리하나요?" 같은 질문들입니다.
디자인 시스템은 단순히 예쁜 화면을 보여주는 것이 아니라, 각 요소가 가질 수 있는 모든 state와 제약 조건 및 세부적 로직을 미리 규정합니다. 개발자는 디자인 시스템을 통해 발생 가능한 예외 케이스를 사전에 예측할 수 있고 이는 곧 구현의 정확도와 프로덕트의 안정성으로 이어집니다.
디자인 시스템, 만들어두는 것으로 충분할까?
플래드에서는 컬러 → 타이포그래피 → 아이콘 → basic 컴포넌트 → complex 컴포넌트 (플래드 내부에서는 basic 컴포넌트가 3개 이상 조합된 더 큰 단위의 컴포넌트로 정의) 위 순서대로 디자인 시스템을 구축하는 작업을 진행하였습니다.
그러나 단순히 여러 case에 대한 컴포넌트를 stickersheet로 만드는 것 만으로는 디자인 시스템의 목적을 달성하기 어렵습니다. 진정한 디자인 시스템은 디자인과 개발 사이의 간극을 메우는 설명서이자 언어가 되어야 하기 때문입니다.
실무에서 개발자와 디자이너 사이의 간극을 메울 수 있도록 아래 4가지의 방식을 적용시키며 작업했습니다.
1. 타이포그래피 정리 시 자간과 행간을 퍼센테이지로 설정하지 않기
피그마에서는 자간과 행간을을 퍼센테이지(%)로 입력하는 것이 기본값처럼 느껴질 수 있지만, 이를 그대로 가이드에 옮기는 것은 개발자에게 숙제를 던져주는 것과 같습니다. 수치상의 모호함을 없애기 위해 자간은 반드시 px 또는 em 단위로 정의해야 합니다.
웹 표준인 CSS에서 letter-spacing 속성은 px, em, rem 같은 길이 단위만 인식합니다. 만약 디자이너가 "자간 2%"라고 가이드를 주면, 개발자는 매번 코드 작성 시 폰트 사이즈 * 0.02를 계산기로 두드려 수치를 변환해야 합니다. 이는 불필요한 공수를 발생시킬 뿐만 아니라, 폰트 사이즈가 바뀔 때마다 계산을 반복하게 만드는 비효율의 원인이 됩니다.
2. 컴포넌트의 맥락을 정의하는 간결한 가이드 작성하기
아무리 공통된 이름을 사용하더라도, 디자이너와 개발자가 해당 컴포넌트를 바라보는 관점은 다를 수 있습니다. 이를 방지하기 위해 각 컴포넌트의 핵심 역할과 사용 방법을 한두 줄의 텍스트로 명시하는 것이 좋습니다.
위와 같은 방식으로 ‘당연히 알고 있는 정의’ 라고 하더라도 컴포넌트가 사용될 때, 컴포넌트와 등장하는 현상을 정의하는 가이드를 작성했습니다.
3. 변수(State, Color, Style)의 시각적 명세화
피그마의 컴포넌트 기능을 통해 변수를 설정하는 것에서 그치지 않고, 개발자가 인스펙터 창을 일일이 확인하지 않아도 한눈에 모든 변수를 파악할 수 있도록 정리해야 합니다.
컴포넌트를 우선 작업한 후 컴포넌트 옆 혹은 위에 해당 컴포넌트에 적용된 변수들을 명시적으로 작성합니다.
변수는 한번에 4~5개씩 적용되는 경우도 있기 때문에 일렬로 정리하는 것보다는 위 사진처럼 컴포넌트를 일종의 격자 형태로 x축과 y축에 따라 변수를 다르게 주어 정리하면 한 눈에 보기 더 편합니다. 이로써 개발자는 컴포넌트의 전체 스키마를 빠르게 파악할 수 있게 됩니다.
4. 레이아웃의 시각화와 조립 샘플 제공하기
단순히 수치로 패딩 값을 설정해두는 작업을 끝내는 것보다, 영역 간의 간격과 정렬 기준을 직관적으로 시각화하여 보여주는 것이 훨씬 효과적일 것입니다. 개발자가 피그마 개발자 모드를 켜서 마우스를 올리는 수고를 덜어줄 수 있을 정도로 가이드 자체가 직관적이면 좋을 것이라 생각했습니다.
여기에 더해, 개별 컴포넌트 단위의 가이드를 넘어 실제 화면에서 어떻게 조립될지 보여주는 샘플을 함께 배치했습니다.
이러한 디테일이 가져오는 3가지 결정적 효과
1. 컨텍스트 스위칭의 최소화와 생산성 향상
개발자가 가장 몰입해야 하는 순간은 코드로 로직을 구현할 때입니다. 하지만 디자인 시안의 수치를 확인하기 위해 매번 개발자 모드를 켜고, 레이어를 클릭하고, 숨겨진 변수를 찾는 과정은 개발자의 흐름을 끊는 컨텍스트 스위칭 비용을 발생시킵니다.
가이드와 변수가 시각적으로 명세화 되어 있으면, 개발자는 시선을 옮기는 것 만으로 정보를 즉시 습득할 수 있습니다. 이러한 작업은 개발자의 불필요한 단순 반복 작업을 줄여주며, 결과적으로 전체적인 개발 속도를 비약적으로 높이는 결과로 이어집니다.
2. 설계 파트너로서의 상호 신뢰 구축
개발자가 디자이너를 신뢰하는 순간은 단순히 시안이 예쁠 때가 아니라, 디자이너가 구현 과정의 고충을 깊이 이해하고 있다고 느낄 때라고 생각합니다. 컴포넌트의 사용 목적을 명시하고 변수를 체계적으로 정리하는 노력은, 디자이너가 시스템을 함께 설계했다는 증거가 됩니다.
그럼에도 불구하고,
아무리 촘촘하게 디자인 시스템을 구축하고 가이드를 상세히 작성하더라도, 개발자와의 미스 커뮤니케이션을 0%로 만드는 것은 불가능에 가깝습니다. 실제 프론트엔드 구현 단계에 진입하면, 디자인 단계에서는 미처 발견하지 못했던 예외 케이스나 기술적 제약 사항이 수면 위로 드러나기 마련이고 이런 상황에서는 질문이 오갈 수 밖에 없습니다.
이때에는 개발자와 머리를 맞대고 의사결정을 내리는 소통을 적극적으로 하는 것이 중요합니다. 문제가 발견된 즉시 소통하고, 협의된 내용을 디자인 시스템에 곧바로 업데이트하며 관리한다면 어느새 충분히 견고한 디자인 시스템이 만들어질 것이라 생각합니다.
마치며
이번 글에서는 디자이너로서 개발자와 ‘잘’ 협업하기 위해 이쁨 받기 위해 디자인 시스템 구축 단계에서 어떤 작업을 진행하면 좋을지 다뤄보았습니다. 디자인 시스템을 정교하게 구축하는 일은 단순히 시각적인 가이드를 만드는 작업이 아닙니다. 그것은 개발자의 언어를 이해하고, 구현의 문턱을 낮추며, 팀 전체가 본질적인 비즈니스 로직에 몰입할 수 있도록 단단한 기반을 닦는 일입니다.
우리가 타이포그래피의 단위를 고민하고, 변수를 시각화하며, 조립 샘플을 제공하는 모든 수고로움은 결국 동료의 시간을 아껴주기 위한 배려에서 시작됩니다. 그리고 이러한 배려가 쌓여 디자이너의 의도가 코드로 완벽하게 치환될 때, 비로소 프로덕트는 한 차원 높은 완성도를 갖게 됩니다.
기억해야 할 점은 디자인 시스템은 한 번의 배포로 끝나는 결과물이 아니라, 제품의 성장과 함께 끊임없이 진화해야 하는 살아있는 서비스라는 사실입니다. 시스템의 빈틈이 발견되는 것을 두려워하지 마세요. 그 공백은 개발자와의 긴밀한 대화를 통해 채워질 것이며, 그 과정에서 디자인 시스템은 더욱 견고해질 것입니다.
처음부터 완벽한 디자인 시스템은 없습니다. 결국 ‘이쁨 받는 디자이너’의 핵심은 빠른 소통과 적용입니다.