brunch

매거진 Agile

라이킷 35 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이상현 Nov 09. 2018

디자이너와 개발자의 협력에 관하여

디자인 시스템으로 소통하기

*예전에 썼던 글들을 브런치로 옮기다 보니 작성 시점이 맞지 않습니다. 양해부탁드립니다.

토요일에 GDG(Google Developer Group Seoul)에서 주최하는 ‘디자이너와 개발자의 협력’과 관련된 세미나 (https://www.meetup.com/ko-KR/GDG-Seoul/events/252856793/)에 다녀왔습니다.

세미나 내용들은 누군가가 정리해서 공유할 테니 나중에 구글링 해보시면 좋을 것 같고, 전 우리가 같이 생각해보면 좋을 것들에 대해서만 나눠 보려 합니다.

Design System에 대하여

디자인 시스템이란?

:디자인 시스템이란 게 있습니다. 발표자이신 상용님(위메프 시니어 디자이너)이 Design System = UI Kit X Dev라고 표현하셨는데 적절한 거 같습니다. 과거 스타일 가이드나 코드 가이드라인보다 훨씬 더 상위 개념이고, 표준화된 디자인 작업을 위한 큰 가이드라인과 비슷합니다.

왜 중요한가

잘 합의된 디자인 시스템은 커뮤니케이션 비용을 엄청나게 낮출 수 있습니다.

디자인 시스템은 기본적으로 정의된 것들을 재사용하는 것을 원칙으로 합니다. UI 패턴 등에 대해 기획/디자이너/개발에서 모두 동일한 언어(네이밍이라 해도 좋고)를 사용하게 되고, 해당 언어에 맵핑되는 UI 등이 명확하기 때문에 혼돈이 생길 여지가 적습니다. 즉, 매우 초기단계부터 완성 단계의 산출물이 상상 가능하죠.

일관성 있는 사용자 경험을 제공할 수 있습니다.

스타일 가이드가 없다고 생각해 보면, 페이지 별로 서로 다른 버튼의 컬러, 라운드 각도, 폰트 사이즈, 등등등 많은 것이 다르게 디자인 될 겁니다. 이건 작업하는 단계에서도 재고가 크지만, 사용자 입장에서 동일 task를 수행하는데 계속 무언가가 달라지니 학습 비용이 높아지고, 결국 사용성이 매우 떨어집니다.

위메프(상용님)에서 현재 디자인 시스템을 정립하고 있는데, UI 패턴이 50가지 이상이라고 합니다. 아마 더 후진 곳에서는 UI 패턴이 100개가 될 거고, 잘 정립된 곳은 패턴이 더 적을 것이라고 생각합니다.

재사용성이 매우 높아집니다

스케치의 심볼을 생각하면, 이미 잘 정의된 UI Kit이 있다면 이를 어떻게 조립할지만 생각하면 됩니다. 당연히 재사용성이 높아지고, 유지보수도 쉬워집니다.

어떻게 만드나

개발자와의 협업

디자인 시스템은 더 효율적으로 프로덕트를 만들기 위한 행위입니다. 개발팀 도움이 없거나, 합의되지 못한다면 의미없는 문서가 됩니다.

스케치 활용하기

스케치의 심볼 기능을 잘 이용하면 됩니다. 단, 모든 경우의 수를 심볼화하면 복잡해집니다. 리팩토링에서 말하는 삼진아웃제를 응용해서, 3번 이상 중복 사용될 경우엔 심볼화 한다 같은 원칙이 필요합니다.

도큐먼트로 정리합니다.

- 전체 UI 패턴을 뽑아 정리합니다

- 리스트를 작성하고 위계구조등을 정의합니다

- 네이밍 규칙을 정의합니다

위메프는 이렇답니다

* 벡터화 : 초기 PSD 등을 모두 스케치로 옮겼답니다.

* 심볼제작/구조화 : 자주사용되는 패턴에 대해서 심볼화 하는 작업

* 시스템화 : 실제 시스템으로 배포 되는 겁니다

* 경량화 : 전체 사용되는 UI 패턴이 최소화 될 수 있도록 개선합니다.

* 스타일 : 스타일 등을 개선합니다.

* 위 단계에서 시스템화에서 스타일은 무한 반복됩니다.

단점은 없나?

스타일보다 효율이나 건설적인 사고만 우선 되는 거 아닌가?

- 디자인 시스템이 정립되면 해당 시스템 안에서만 사고가 권장됩니다.

- Atomic Design은 정의된 원자들(레고 블럭) 가지고만 사고하게 됩니다.

이렇게 생각의 틀을 가두는 게 디자이너의 창의성과 창발을 막는다는 데 동의합니다. 다만, 저는 개인적으로 디자이너가 px단위로 뭔가를 만지고 수정하는 행위, 버튼의 위치를 고민하는 행위 보다 훨씬 더 가치있는 것을 고민해야 한다고 생각합니다. 예를 들어 전체 브랜딩과 관련된 것, 사용자 경험을 위한 전체적인 디자인 전략, 패턴의 수를 줄이거나 기존 패턴의 리팩토링 등등요.

시간이 오래 걸립니다

상용님이 말하길 디자인 시스템을 구축하는 건 농사짓는 거와 같다고 합니다. 어쩌면 1년 이상이 걸릴 수도 있고요. 매 순간 개선 포인트가 발생할 겁니다. 디자인 시스템만 관리하는 별도의 디자이너가 없는 환경이 많죠.

어떻게 적용하나?

디자인 시스템에 대해 디자이너와 개발자, 기획자 모두 같이 얘기 나눠 보면 좋겠습니다. 디자인 시스템이 주는 장점이 명확하기 때문에 이런 장점을 어떻게 얻을 수 있을 것인지 같이 논의해보면 좋죠. 디자인 시스템을 구축할지 말지가 아니라, 어떻게 하면 장점을 취할 수 있을지에 대해서만요.

첫 번째 세션과 세 번째 세션인 ‘김상용 디자이너의 디자인 시스템 구축에 대한 생각과 고민’과 ‘AB180 개발자와 디자이너의 Git과 Atomic으로 개선해본 협업 프로세스’를 묶어서 정리 겸 생각해볼 만한 내용을 정리했습니다.

협업에 대하여

레이니스트 황성현 CTO님이 발표한 ‘협업의 비밀’은 제가 익히 알고 있는 영역이고 몇년째 관심 갖고 공부하는 영역인데요. 가장 중요한 주제라고 생각하지만, 개인이 느끼고 필요해서 공부하기 전까지는 잘 와닿지 않는 주제일 겁니다. 워낙 추상적인 영역이고, 서로의 생각도 다르고, 합의도 잘 안 되는 영역이다 보니 논쟁이 잦은 주제입니다.

세션에서 다뤄진 내용 중 저도 고민하는 영역에 대해서만 짧게 공유드립니다.

분업과 협업의 차이, 분업은 협업이 아님

분업과 협업의 차이를 이해 할 필요가 있습니다. 분업이 잘 되면 협업이 잘 되는 건가요?

전 예전에 워드커닝햄(Agile의 큰 축인 XP-eXtreme Programming의 대가 중 한 명)이 썻던 글을 보고 엄청 큰 충격을 받았습니다. 망치로 머리를 강타 당한 느낌이었어요. 12개의 할 일과, 12명의 작업자가 있을 때 대부분의 관리자는 일과 사람을 1:1로 나눠서 배분하죠. 워드는 12명에게 3개의 일만 먼저 줘서 협력해서 일하게끔 하고, 다음 3개의 일을 제공하는 식을 해야 한다고 얘기 합니다. 이 얘기가 시사하는 바가 굉장히 많다고 생각합니다.

협업 근육

* 애자일하는 분들 사이에선 협업 근육이란 표현을 꽤나 자주 사용합니다.

* 근육이란 메타포를 생각해보면요,

* 절대 시간이 지난다고 저절로 생기지 않습니다.

* 생겼다고 해도 노력하지 않으면 없어집니다.

* 근육 만드는 게 원래 어렵습니다. 그리고 노력한 만큼 생기지 않습니다.

* 잘못된 습관은 오히려 몸에 해가 됩니다.

* 같이 오래 일한다고 저절로 생기지 않고, 생겼다고 하더라도 일이 바뀌거나 사람이 바뀌면 고생하기 마련입니다.

이상입니다.

아래는 발표 슬라이들이니 관심있는 분들은 한번씩 살펴보시면 좋겠네요.

이상용 디자이너, 위메프

디자인 시스템 구축에 대한 생각과 고민