디자이너가 코딩까지 알아야 해요?
D2C라니, 거 말이 너무 심한 거 아니오
결론
디자이너는 코딩을 몰라도 되지만, 코딩을 모르는 디자이너가 만든 결과물은 실제와 다를 수 있음.
그런데 나도 잘 모른다. 코딩..
https://www.tiktok.com/@verticalinstitute/video/73116541024238830162살짜리 앱을 전면 개편하게 되었다. 나는 개편하는 시점에 투입되었다. 그렇기 때문에 지난 2년간의 히스토리를 충분히 알지 못한다. 게다가 개발언어가 바뀌게 되면서 모든 화면을 새로 구현하게 되었고 그 과정에서 2024년과 2025년의 디자인시스템이 엉키며 V1의 디자인부채를 대대적으로 청산해야 하는 숙제가 주어졌다.
타이포그래피, 컬러팔레트, 아이콘 에셋이 대표적으로 문제가 되었다. 이들을 V2라는 이름으로 새로 묶어 개발자와 토큰명을 통일해야 했다. 그렇다면 내가 피그마에서 작업한 결과물에서 개발자는 어떤 내용을 눈여겨보는 거며, 어떤 부분을 신경 써야 서로가 두세 번 일하는 사태를 미연에 방지할 수 있을까?
피그마의 데브모드는 유료플랜부터 제공되기 때문에 오늘은 pixso의 데브모드를 통해 몇 가지를 살펴볼까 한다.
Text Style
왜 통일해야 필요하죠?
텍스트는 여러 가지 속성으로 이루어져 있다. typeface(=font), size, wieght, row height, letter spacing 등 다양한 요소들로 구성되어있다. text style은 이와같은 여러 가지 속성값을 하나로 묶어준다. 다양한 속성값을 하나로 묶어 body/small 혹은 label/small과 같은 text style로 묶는 식인 것이다.
따라서 같은 14pt의 텍스트일지라도 body로 쓰이느냐 lable로 쓰이느냐에 따라 text style을 별도로 지정해줘야 한다. 2줄 이상 사용할 일이 없는 label의 줄간보다 여러 줄로 표기될 때를 고려해야 하는 body의 줄간격이 더 여유 있어야 하기 때문이다.
이때, 같은 폰트사이즈이더라도 body와 label의 텍스트 스타일을 별개로 지정하면 반복작업을 줄일 수 있다. 이렇게 지정한 텍스트 스타일은 데브모드에서 다음과 같은 형태로 확인할 수 있다.
(좌) 스타일을 지정한 상태 / (우) 스타일을 지정하지 않은 상태이렇게 되면 개발자가 폰트 사이즈, 줄간격, 자간 등을 일일이 체크하지 않아도 text style만 보고도 작업할 수 있어 훨씬 효율적인 업무가 가능하다.
D2C
Design to Code
사실 처음 D2C라는 단어를 듣고 발작했다. 디자이너보고 코딩까지 하라는 의미의 신조어인가 싶어서, 다행히 그건 아니었고, Pixso에서 베타로 시범 중인 기능이었다. 스크린을 선택한 뒤, 데브모드의 D2C 탭에서 code kit을 다운로드할 수 있는 기능이다. 필요한 개발언어를 선택해서 코드 패키지 파일을 다운로드할 수 있다. 그런데 코드뿐만 아니라, 이미지 에셋 파일도 export 할 수 있도록 챙겨준다.
다운로드한 code kit의 압축을 풀면 아래와 같은 구조의 폴더와 파일들이 생성된다. figma 파일 Import도 가능하니, 피그마에서 작업한 파일을 과금 없이 코드파일로 출력하려면 pixso에서 figma 파일을 불러와 추출해 보는 것도...(읍읍)...
개발자와 디자이너 간의
생산성 향상을 위해
디자이너는 코딩을 몰라도 되지만, 코딩을 모르는 디자이너가 만든 결과물은 실제와 다를 수 있다. 그렇다면, 디자인과 결과물의 일관성을 높이려면 어떻게 해야 할까?
pixso의 D2C(design to code) 기능을 사용하면 개발자가 일일이 디자인 요소를 보면서 코드를 옮기지 않아도 된다. 레이어구조, 네이밍 규칙, 스타일 등을 실제로 동작하는 프로덕션 수준의 코드 스니펫으로 변환해 주기 때문이다. 이는 디자이너와 개발자 간의 불필요한 수정작업을 줄이고 빠른 속도로 더 높은 품질의 제품을 배포하는데 도움이 된다.
다운로드한 코드패키지는 구조가 명확하여 개발자가 쉽게 수정, 유지관리 및 확장할 수 있다. 제공되는 대표적인 개발 언어는 다음과 같다
HTML / CSS
• 의미 있는 HTML 태그 구조를 자동 생성합니다. (지저분하고 정리되지 않은 코드가 아님)
• 반응형 레이아웃(Flex/Grid)을 지원하며, 디자인에서 직접 CSS 스타일을 추출해 간격, 색상, 폰트가 완벽히 일치합니다.
• 정적 웹 프로토타입을 빠르게 구축하는 데 유용하며, 프런트엔드 팀은 처음부터 시작하지 않고도 디자인을 빠르게 테스트하고 미리 보기 할 수 있습니다.
Flutter
• Flutter의 엄격한 표준을 따르는 위젯 구조 코드를 출력해 중첩 레이아웃이나 속성명을 추측할 필요가 없습니다.
• 주요 디자인 속성(중첩 레이아웃, 색상, 텍스트 스타일, 이미지)을 Flutter 호환 코드로 변환합니다.
• 모바일 UI를 빠르게 제작하거나 크로스 플랫폼 앱 개발에 이상적이며, 디자인 목업을 실제 Flutter 인터페이스로 전환하는 시간을 단축합니다.
ArkUI (OpenHarmony 개발)
• OpenHarmony의 공식 언어인 ArkTS 기반의 HarmonyOS 인터페이스 코드를 생성합니다.
• 컴포넌트 기반 변환을 지원하여 깊은 전문 지식 없이도 네이티브 HarmonyOS 앱 인터페이스를 구축할 수 있습니다.
• ArkUI 개발 진입 장벽을 낮추어, HarmonyOS에 익숙하지 않은 팀도 디자인에서 구현까지의 사이클을 빠르게 진행할 수 있습니다.
특히 네이밍 규칙의 경우, 꼭 개발자와 사전에 협의하여 통일하는 게 좋다. 이름을 적을 때는 공백(space bar)보다는 대시(-)로 구분하는 케밥스타일이 편하던지, 슬래시(/)는 피그마가 자체적으로 위계로 인식하기 때문에 적절하지 못하다던지. 미리 약속하지 않으면 나중에 어마어마한 후폭풍이 되어 돌아오기 때문이다.
*본 원고는 pixso로부터 소정의 원고료를 지원받아 작성되었습니다.
끝.
