구글은 정말로 머터리얼 디자인 시스템을 적용하나요?
Salmon Inspiration은 듀오톤 멤버들이 성장을 위해 수행하는 다양한 활동들을 담은 콘텐츠입니다. 듀오톤에서 제공 및 지원하는 세미나에 참석한 후기나, 개인적으로 공부한 내용들을 작성합니다. 이번에는 구글 재팬에서 안태완, 이정영 디자이너가 듀오톤을 방문하셨습니다.
안태완
구글 search ux 총괄 리더
이정영
시니어 비주얼 디자이너
(전)네이버, 라인 인터랙션 디자이너
두 분은 모두 구글 앱을 제작하고 계십니다. 태완님은 현재 Search파트를 리드하고 계시며, 이전에는 구글 News를 담당하셨습니다. 정영님은 구글 앱, 그 중에서도 iOS를 담당하고 계십니다.
구글은 전 세계에 지사를 갖고 있지만, 모두가 강력한 글로벌 가이드라인을 따르며 중앙 집중화된 디자인을 하고 있다고 해요. 이러한 관점에서, 살몬들이 디자인 시스템이라는 키워드를 중점으로 질문을 준비하여 세미나가 진행되었습니다.
질의응답 중 흥미로웠던 몇 가지를 소개합니다.
Q. 구글은 정말로 머터리얼 디자인 시스템을 적용하나요?
정영: 구글 내에는 다양한 디자인 시스템이 있어요. 코어가 머터리얼일 뿐이죠.
예를 들면, 컬러나 아이콘은 머터리얼을 중심으로 사용해요. 특히 아이콘은 강력하게 따르는 편이죠. 워낙 잘 되어있으니까. 개발자에게 해당 아이콘의 url만 전달하면 쉽게 빠르게 적용할 수 있거든요.
반면 컬러는 조금씩 예외를 만들어가면서 적용해요. 머터리얼에서 100, 200, 300으로 나눠놓는다면, 예를 들어 서치 같은 중요도가 높은 부서에서에서 공식 문서에는 빠져있는 150과 같이 다른 컬러를 사용하는 경우가 있어요. 또, 머터리얼은 안드로이드 기반이다 보니 iOS의 경우 비교적 느슨한 경우도 많죠.
태완 : 머터리얼도 모든 상황에 완벽하게 들어맞을 수는 없어요. 절대적인 규칙이 아니라는 거죠. 머터리얼 확장형의 이름이 머터리얼2가 아니라 머터리얼 Theme인 이유가 있어요.
머터리얼 팀에서 초기 시스템을 구축한 후에, 각 조직과 긴밀하게 협업을 해요. 그러는 과정에서 디자인 패턴을 모으고 시스템화한 것이 구글 머터리얼입니다.
구글 안에서도 머터리얼은 기본 가이드, 즉 ‘최소한의’ 정의라고 생각한다고 보시면 돼요. 예를 들면 구글 앱이나 서치 안에서도 별도의 시스템을 갖고 있어요. 머터리얼과 부딪히거나 포함되어 있지 않은 내용은 머터리얼 팀과 조율해나가죠. 그러다보면 서치 팀의 디자인 시스템이 머터리얼에 반영될 때도 있고요.
Q. 디자인하실 때 사용성과 심미성, 이 둘 사이를 어떻게 조율하시나요?
정영 : 구글로 이직한 후 제가 한국에서 디자인했던 예전 제품들을 다시 보니, 심미적인 부분 때문에 대비를 약하게 쓴 부분들이 보이더라구요. 하지만 선명하게 사용했을 때 심미성이 떨어져 보이는 것은, 디자이너들에게만 해당하는 경우가 많아요.
구글 디자인은 시스템화가 잘 되어있어서 웹 접근성을 잘 통과해요. 무조건적으로 통과해야 하는 기준임을 내부적으로 공감하기 때문에, 전사가 접근성 리뷰를 기준으로 디자인을 진행하는 편이죠.
디자이너가 생각하는 아름다움 때문에 웹 접근성을 포기한다면, 그건 우리의 시선일 뿐, 사용성에 좋지 않은 영향을 끼칠 수 있다는 것을 고려하며 디자인하고 있어요.
Q. 디자인 시스템을 여러 직군이 함께 사용하는데, 직군 간 커뮤니케이션에서 어려운 점은 없었나요?
태완: 글쎄요. 엔지니어들의 시스템에 대한 이해도가 굉장히 높아서 커뮤니케이션 미스에 대한 이슈가 낮은 편이에요.
정영 : 머터리얼은 여러분이 열람하시는 스탠다드 사이트가 있고, 내부용이 따로 있어요. 내부용은 외부용에 비해 아주아주 상세하게, 거의 모든 변수를 고려한 수준으로 정의되어있죠. 또 그 소스 하나로 모든 사람이 협업을 하기 때문에, 딱히 커뮤니케이션에 미스가 생길 일은 없어요.
Q. 마이크로 인터랙션을 제작할 때의 프로세스는 어떻게 되나요?
정영: 입사하자마자 충격을 받았던 게 있어요. 개발자한테 제가 만든 프로토타입 보여줬더니, “이렇게까지 만들어 줄 필요 없어. 레퍼런스 비디오만 주면 내가 만들어 줄게.” 라고 하더라고요. 너무 충격적이었죠.
서로가 최고의 인재라는 상호 신뢰가 강력하게 있고, 각자 실력에 대한 자부심이 대단하기 때문에, 서로 ‘못하겠다’는 말을 하지 않아요. 그래서 불필요한 프로세스가 확 줄어들죠.
레퍼런스 비디오만 주는 것로도 가능한 경우가 많았기 때문에, 프로토 타입이 필요하더라도 프레이머까지 사용하지 않고, 프로토파이로도 충분했어요.
Q. 디자인시스템에 대한 핵심성과지표(KPI)를 따로 측정하나요?
정영: 구글에서는 이런 질문을 받을 일이 없었어요. 산출물 기준으로 디자인 시스템을 만드는 플로우이니까요.
반면 라인에서 디자인 시스템을 디자인 할 때, 많이 들었던 질문이었죠. 디자인 시스템 자체가 가치를 만들어야하는 상황에 처해있었기 때문에 그런 질문을 많이 받았어요.
라인의 경우 굳이 개발 단축, 리소스 단축같은 말을 만들긴 했지만… 제품이 자리 잡고 디자인 시스템을 런칭했을 때 효용이 잘 드러난다면, 저런 질문은 필요 없을 것 같아요. 제품 자체가 가치를 만들어내는 게 중요하지, 시스템이 제품과 분리되어 가치를 내야 하는 상황을 만드는 건 좋지 않다고 생각해요. 시스템을 처음 만드는 상황에서 나오는 과도기적 고민 아닐까요.
태완: 시스템을 따로 놓고, 시스템만 중점으로 이야기 하진 않아요. 프로덕트 내의 여러 파트가 제 역할을 하고 있는지에 관심을 가지는 편이고요. 그 역할이 잘 수행되고 있을 때 시스템이 제 몫을 했다고 봐요.
Q. 업무 시 라이브러리 관리, 히스토리 아카이빙은 어떻게 진행하나요?
태완: 기본적으로 구글러들은 새로운 툴에 개방적이에요. 이미 3~4개월 전부터, 전사가 피그마로 이전했죠. 히스토리 아카이빙도 피그마로 하고 있고요.
정영: 한국에서는 업무 보고라는 문화가 있잖아요. 불필요한 절차처럼 보일 수도 있지만, 이게 좋은 점이 전사적으로 서로가 뭘 하는지 알 수 있다는 거거든요.
구글에선 업무 보고는 없지만, 구글 슬라이드를 협업 용으로 쓰고 있더라고요. 슬라이드에 업무 히스토리를 쌓는 거죠. 어떤 프로젝트의 히스토리가 한 문서에 처음부터 끝까지 작성되어있어요.
작업에 대한 코멘트나, 언제 누가 이 작업을 했는지, 삭제된 안건은 X표시를 달아두고, 그에 해당하는 히스토리가 기록되어있고… 뒤늦게 합류한 멤버도 이 문서만 보면 빠르게 파악할 수 있어서, 너무 좋더라고요.
듀오톤은 멤버들의 성장을 위해 오늘처럼 다양한 디자인 분야의 연사를 초대해 영감을 얻는 세미나를 개최합니다. 다음에는 어떤 분이 방문하시게 될까요? 다음 세미나도 기대해주세요.
작성자: 김강령, 김경은, 윤지수, 이창훈, 김다솜
듀오톤 공식 웹사이트: https://duotone.io/
