개발자와 협업하기 위한 디자인 시스템

안녕하세요, 게으른 사부작이입니다!

 

오늘은 디자인 시스템 시리즈의 마지막 단계로, 개발자와 협업하기 위한 디자인 시스템에 대해 이야기해보려고 해요. 지금까지 Figma로 스타일과 컴포넌트를 만들어보는 과정을 배웠으니, 이제 그 결과를 개발자와 공유해서 실제 제품으로 구현해볼 차례예요. 저도 처음엔 개발자와 협업하면서 당황했던 경험이 많았는데, 체계적인 가이드를 만들고 나니 훨씬 수월해지더라고요. 그럼 저와 함께 개발자와 원활하게 협업할 수 있는 디자인 시스템을 준비하는 법을 알아볼까요?

 

ChatGPT 생성 이미지

개발자가 '이거 어떻게 코딩해?' 물었을 때 당황했어요

제가 처음 디자인 시스템을 만들고 개발자에게 넘겼을 때의 일이에요. 열심히 Figma에서 버튼과 컬러를 정리해서 공유했는데, 개발자가 "이 버튼 크기가 정확히 몇 픽셀이야? 이 색상 코드는 뭐지? 네이밍은 어떻게 할 거야?" 하고 물어보더라고요. 저는 "어… Figma에서 보면 되지 않나?" 하고 얼버무리다가, 개발자가 "명확한 가이드가 없으면 코딩하기 어렵다"는 피드백을 주더라고요. 그때 정말 당황했어요. 디자이너 입장에서는 "Figma에서 다 보이는데 뭐가 문제지?" 했지만, 개발자 입장에서는 구체적인 가이드가 없으면 작업하기 어렵다는 걸 알게 됐죠. 그 이후로 개발자와 협업할 때 꼭 필요한 가이드를 만들어보는 과정을 배우게 됐어요. 여러분도 개발자와 협업하면서 비슷한 경험 있지 않나요? 오늘은 그 문제를 해결할 수 있는 방법을 공유해볼게요!

명확한 가이드 작성법: 크기 단위와 네이밍

개발자와 협업하려면 명확한 가이드를 만드는 게 핵심이에요. 가이드는 디자이너와 개발자가 같은 언어를 사용할 수 있도록 도와주는 다리 같은 역할을 하죠. 여기서 중요한 두 가지 요소는 크기 단위와 네이밍 규칙이에요. 하나씩 자세히 알아볼게요.

1. 크기 단위 가이드 작성하기

먼저, 크기 단위를 명확히 정의하는 게 중요해요. 디자이너는 보통 Figma에서 픽셀(px) 단위를 사용하지만, 개발자는 프로젝트에 따라 다른 단위를 사용할 수 있거든요. 예를 들어, 웹 개발에서는 rem이나 vw 같은 상대 단위를, 모바일 앱에서는 dp나 pt를 사용할 수 있어요. 이런 단위 차이를 고려해서 가이드를 작성해야 해요.

제가 만든 앱 UI를 예로 들어볼게요. 버튼 크기를 Figma에서 48px x 48px로 설정했어요. 이걸 개발자에게 넘길 때, 단순히 "48px"라고만 쓰는 대신, 단위 변환과 사용 환경을 고려한 가이드를 작성했어요:

• 버튼 크기: 48px x 48px (웹: 3rem x 3rem, 모바일: 48dp x 48dp)
• 간격: 요소 간 간격 16px (웹: 1rem, 모바일: 16dp)
• 폰트 크기: 본문 16px (웹: 1rem, 모바일: 16sp)

이렇게 단위를 명확히 적어놓으니, 개발자가 "이 버튼 크기를 어떻게 적용해야 하지?" 고민할 필요가 없더라고요. 특히 웹과 모바일 환경에 따라 단위가 달라질 수 있다는 점을 미리 알려주니까 협업이 훨씬 수월해졌어요. 저는 처음엔 이런 단위 변환을 몰라서 "그냥 48px로 하면 되지 않나?" 했는데, 개발자가 "상대 단위로 변환해야 반응형 디자인이 가능하다"고 알려줘서 배웠어요. 단위 변환은 rem의 경우 16px = 1rem으로 계산하면 되고, 모바일에서는 px와 dp가 거의 1:1로 대응한다고 생각하면 쉬워요.

2. 네이밍 규칙 정하기: btn-primary 예시

다음으로 중요한 건 네이밍 규칙이에요. 네이밍은 디자이너와 개발자가 같은 이름으로 요소를 부를 수 있게 해주는 약속이에요. 네이밍이 체계적이지 않으면, 디자이너는 "파란 버튼"이라고 부르고, 개발자는 "메인 버튼"이라고 부르면서 혼란이 생길 수 있죠.

제가 사용한 네이밍 규칙을 예로 들어볼게요. 버튼 컴포넌트를 만들 때, 다음과 같이 이름을 정했어요:

• Primary 버튼: btn-primary (주요 행동, 파랑 #007BFF)
• Secondary 버튼: btn-secondary (보조 행동, 회색 #D3D3D3)
• Warning 버튼: btn-warning (경고 행동, 빨강 #FF0000)

네이밍 규칙을 정할 때 몇 가지 원칙을 세웠어요:

• 형식: 요소 타입(btn, input, icon) + 역할(primary, secondary, warning)으로 구성.
• 소문자 사용: 대문자 섞으면 혼란스러우니까 모두 소문자로 통일.
• 간결성: 너무 길지 않게, 직관적으로 이해할 수 있도록.

예를 들어, "파란 버튼" 대신 btn-primary라는 이름을 쓰니까 개발자가 바로 이해하고 코드에 반영하더라고요. 개발자 입장에서도 btn-primary라는 이름이 CSS 클래스 이름으로 바로 사용할 수 있어서 편리하다고 하더라고요. 저는 처음엔 "blue-button" 같은 식으로 네이밍을 했었는데, "blue"는 색상에만 초점이 맞춰져 있어서 "이 버튼이 어떤 역할을 하는 거지?"라는 혼란이 생겼어요. 그래서 역할 중심으로 네이밍을 바꾸니까 훨씬 명확해졌어요.

실무 적용 사례: 가이드로 협업 효율 높이기

명확한 가이드를 작성하고 나니 협업이 정말 쉬워졌어요. 제가 참여했던 쇼핑 앱 프로젝트에서 가이드를 적용해본 사례를 공유해볼게요. Figma 파일에 "가이드"라는 아트보드를 따로 만들어서 크기 단위와 네이밍 규칙을 정리했어요:

• 컬러: color-primary: #007BFF, color-secondary: #D3D3D3, color-warning: #FF0000
• 버튼: btn-primary (48px x 48px, 3rem), btn-secondary, btn-warning
• 간격: spacing-medium: 16px (1rem)

이 가이드를 개발자에게 공유하고, Figma의 "Inspect" 탭에서 값을 바로 확인할 수 있도록 안내했어요. 개발자가 "이 버튼의 색상 코드는 뭐지?" 하고 물어볼 때, "가이드 아트보드에서 color-primary로 확인해줘!"라고 하니까 바로 이해하더라고요. 또, 네이밍 규칙 덕분에 개발자가 CSS 클래스 이름을 btn-primary로 바로 적용해서 코드 작업이 빨라졌어요. 이런 작은 변화가 협업 효율을 정말 많이 높여주더라고요.

실무 팁: 소통과 피드백

개발자와 협업할 때 몇 가지 실무 팁을 더 드릴게요. 먼저, 소통이 중요해요. 가이드를 만들었다고 끝나는 게 아니라, 개발자와 가이드를 함께 검토하면서 "이 네이밍 괜찮아요?" "단위 이렇게 쓰는 게 편한가요?" 하고 의견을 물어보세요. 저는 처음엔 가이드만 넘기고 끝났는데, 개발자가 "이 간격 단위가 애매하다"고 피드백을 줘서 수정한 적이 있어요. 이런 피드백이 가이드를 더 탄탄하게 만들어주더라고요.

또, Figma 플러그인 중 "Design Tokens" 플러그인을 활용하면 디자인 시스템 값을 JSON 파일로 내보내서 개발자와 공유할 수 있어요. 저는 이 플러그인을 사용하면서 개발자와의 데이터 공유가 훨씬 편해졌어요.

협업이 쉬워졌으니, 문서화도 해볼게요!

개발자와 협업하기 위한 디자인 시스템을 준비하면서, 명확한 가이드의 중요성을 정말 많이 느꼈어요. 크기 단위와 네이밍 규칙을 체계적으로 정리하니까 디자이너와 개발자가 같은 언어로 소통할 수 있었죠. 협업이 훨씬 쉬워진 걸 보니, 이제 디자인 시스템을 더 오래 유지하고 관리할 수 있는 방법도 고민해봐야겠더라고요. 다음 포스트에서는 디자인 시스템을 체계적으로 문서화하는 방법을 알아볼게요. 여러분은 개발자와 협업하면서 어떤 가이드를 만들어보셨나요? 저는 네이밍 규칙 덕분에 혼선이 줄어서 정말 좋았어요. 댓글로 여러분의 경험도 공유해주세요!