2019. 2. 8. 07:50ㆍpxd talks
어느덧 pxd에도 2019년 새해가 밝았습니다. 2019년의 첫 pxd talk에서는 우종희 주임이 UI 팀과 GUI 팀의 효율적인 협업 프로세스에 대해 강연을 해주었습니다. UI와 GUI의 업무는 물과 기름처럼 명확하게 구분 지을 수 있는 영역이 아니기 때문에 밀접한 협업이 필요한데요. 이 과정에서 생기는 비효율을 개선할 수 있는 효과적인 방법에 대해 자세히 들을 수 있었습니다.
들어가며
We're not designing pages, we're designing systems of components.
- Stephen Hay
네덜란드의 디자이너이자 'Responsive Design Workflow'의 저자 Stephen Hay는 위와 같이 말하였습니다. 효과적인 협업에는 시스템적으로 접근하는 마인드 셋이 기반이 되어야 한다는 협업 프로세스의 방향성을 잘 표현한 문장인 것 같습니다.
협업 프로세스는 한가지 특효약으로 개선이 이루어지는 것이 아니며, 이는 비단 UI와 GUI 팀의 협업에만 국한되는 이야기도 아닐 것입니다. 강연은 커뮤니케이션 방식을 개선하는 것과 더불어 적절한 도구 활용으로 제품의 퀄리티를 높이면서 작업 시간을 단축시키는 업무 프로세스를 제안하는 방식으로 진행되었습니다. 강연에서 언급된 구체적으로 개선할 수 있는 단계는 총 4단계로, 하나씩 자세히 살펴보고자 합니다.
협업 프로세스 개선을 위한 4단계
pxd의 업무환경은 프로젝트에 따라 달라지기 때문에 하나의 업무 프로세스를 모든 프로젝트에 적용하기는 어렵습니다. 따라서 위 A~D 단계 중 프로젝트 상황에 따라 유연하게 적용해야 합니다. 4단계 중 A 단계는 필수적이고, D 단계로 갈수록 선택적이라고 볼 수 있으며, 아래의 단계가 선행되어야 다음 단계를 진행할 수 있습니다. 이를테면 C 단계를 적용하기 위해서는 A, B 단계를 선행해야 하는 개념입니다.
A - 시스템적 컴포넌트 정의
좋은 협업은 서로 다른 역할의 구성원들 간의 원활한 커뮤니케이션을 바탕으로 합니다. 커뮤니케이션이 원활하다면 그만큼 비효율을 줄일 수 있고, 그 성과가 고스란히 결과물로 나타날 것입니다.
업무에서 UI-GUI 간의 커뮤니케이션은 주로 화면과 컴포넌트를 중심으로 이루어집니다. 그런데 이 컴포넌트의 구분과 이름, 기준 등은 팀원들 각자가 조금씩 다르게 정의하고 이해하고 있는 경우가 많습니다. 따라서 팀원들의 컴포넌트 이해도를 맞추고 정리하여 프로젝트에서 사용할 컴포넌트 기준을 정리하는 과정이 필요합니다. 이때 스케치를 사용하는 경우라면, 정리한 기준을 발전시켜 스케치 심볼 네이밍 컨벤션(규칙)을 만들어 디자인 시스템, 라이브러리를 만드는데 사용할 수 있습니다.
초반에 이 과정을 거치는 것 또한 시간과 노력이 들어가겠지만, 공통의 룰을 바탕으로 협업한다면 컴포넌트 단위의 더 정교한 커뮤니케이션을 할 수 있게 되고, 일관성 있는 제품을 설계하는데 큰 도움이 됩니다.
B - 목적에 맞는 도구 사용
A 단계에서 컴포넌트를 정의했다면, 이를 효율적으로 활용할 수 있는 도구를 선택해야 합니다. 도구는 각자의 쓰임새가 있기 때문에 목적에 맞는 도구를 사용해야 효율성을 높일 수 있겠죠. 기존에 주로 사용하던 파워포인트나 키노트는 본래 문서 작성용으로 만들어진 도구로, 문서를 작성하는 데는 효과적이지만 화면을 그리기에는 불편한 점이 많습니다. 포토샵의 경우 본래 이미지 편집에 사용하는 범용적인 도구이다 보니 간단한 작업에도 많은 리소스를 사용하거나 아예 작업이 불가능한 경우가 생깁니다. 이처럼 의도에 맞지 않게 프로그램을 사용하게 되면, 그 과정에서 불편함이 생기게 되는 것이죠. 특히, 컴포넌트를 중심으로 디자인을 할 때 파워포인트, 포토샵과 같은 도구는 한계가 더욱 분명해집니다.
그런데 최근, 컴포넌트 중심의 작업 방식을 효율적으로 지원해주고 UI 화면을 쉽게 공유할 수 있도록 하는 프로그램들이 많이 서비스되고 있습니다.
위의 To-be에 언급된 도구들을 유기적으로 잘 활용하면, 커뮤니케이션을 위한 문서를 줄일 수 있을 뿐만 아니라 더 짧은 시간 동안 일관성 있는 UI를 설계하는데 도움이 됩니다.
pxd에서 시험적으로 사용하고 있는 Abstract을 간략히 소개 드리면, Abstract은 Sketch 파일의 버전 관리 도구로 디자이너의 git이라고도 불립니다. 개발자들이 git을 사용하여 코드의 버전을 관리하고, github을 통해서 협업하는 것과 마찬가지로 Abstract을 이용하여 협업하면 버전 관리를 쉽고 용이하게 할 수 있습니다. 이를 적극적으로 사용한다면 라이브러리를 쉽게 구축할 수 있으며, 커뮤니케이션 또한 한곳에서 이루어져 커뮤니케이션을 위한 리소스를 많이 절약할 수 있습니다.
C - UI 팀, GUI 팀의 공동 관리 라이브러리
라이브러리는 하나의 소스로 여러 사람이 작업을 할 수 있도록 하는 기능입니다. 라이브러리를 사용하지 않을 경우, 작업하는 사람 각자가 같은 컴포넌트를 여러 번 제작하게 되어 효율성이 떨어집니다. 더군다나 프로젝트의 규모가 크고 인원이 많은 경우에는 통일성을 맞추기도 어려워집니다. 하지만 라이브러리를 사용하면 필요한 서비스에 컴포넌트를 한 번씩만 제작하기 때문에 작업시간을 대폭 단축시킬 수 있고, 같은 인터랙션의 컴포넌트를 하나로 사용하기 때문에 제품 전반에 일관성을 유지하기 쉬워집니다.
덧붙여, UI 팀과 GUI 팀이 공동으로 라이브러리를 관리하게 되면 유지 보수 시 작업 리소스를 대폭 단축시킬 수 있고, 팀 내의 커뮤니케이션이 더 원활해질 수 있습니다. 또한, 공동 라이브러리를 잘 제작하면 다음 단계인 D 단계도 쉽게 진행할 수 있습니다.
D - UI/GUI 문서 통합 관리(커뮤니케이션 기준 통일)
기존에는 UI 설계문서(기획서)와 GUI 가이드라인 및 시안 문서를 팀별로 따로 발행하고 관리했습니다. 이런 방식으로 진행하는 것이 프로젝트 관리 측면에서 역할과 책임 범위가 분명하여 좋은 점은 있습니다. 하지만 프로젝트와 제품을 기준으로 봤을 때에는 이중 작업이 발생하거나, 커뮤니케이션 오류가 생길 가능성이 있습니다.
통합 문서로 진행하는 것이 불가능한 프로젝트가 있지만, 가능하다면 분명한 장점이 있습니다.
1. 버전 관리가 쉽다.
두 개 이상의 문서를 발행하는 경우, UI 설계 문서와 GUI 문서의 싱크가 틀어지는 경우가 있는데, 이를 맞추기 위해 각 팀이 문서를 비교해보는 과정을 거치기도 합니다. 통합하여 관리하면 기준이 되는 단일 문서의 버전만 관리하면 되기 때문에 버전 관리가 용이해집니다.
2. 커뮤니케이션 미스가 줄어든다.
커뮤니케이션은 문서를 발행하는 가장 중요한 이유 중 하나입니다. UI 설계 문서와 GUI 디자인의 레이아웃 등이 일치하지 않기 때문에 개발자와 연락하는 경우가 종종 발생합니다. 때로는 작은 차이로 컴포넌트가 달라지는 경우도 있어 GUI 가이드 전달 이후 다시 개발해야 하는 경우도 생깁니다. 통합 문서를 사용하면 이러한 문제를 제거할 수 있습니다.
3. 마이너한 수정을 용이하게 할 수 있다.
기존 방식에서는 레이블의 문구가 바뀌는 정도의 작은 수정 사항이 있는 경우에도 최소 두 명이 작업을 진행해야 합니다. 통합하여 관리하는 경우, 컴포넌트가 변경되지 않는 간단한 수정사항은 한 명이 작업할 수 있습니다.
아마 이 글을 여기까지 읽어내려오면서 드는 생각이 있었을 겁니다.
이게 정말 가능하다고?
물론 앞에서 언급한 모든 단계를 현업에 바로 적용하는 것은 현실적으로 한계가 있습니다. 따라서 프로젝트의 규모나 클라이언트의 요구 사항 등 여러 상황에 맞게 유동적으로 활용하는 것이 가장 효과적입니다. 이를테면 A 단계부터 시작해서 적용 가능한 단계까지 진행을 하는 것이죠.
마무리
이번 강연 내용을 바탕으로 협업하는 과정을 개선함에 있어 지향해야 할 부분을 함께 고민해볼 수 있었던 시간이었습니다. 아무래도 개개인이 모여 팀을 구성하다 보니 협업 과정에서 발생하는 문제는 분야를 막론하고 골칫거리이자 개선의 대상이 되는데요. 강연에서 소개된 기존 사례와 툴 활용법을 통해 보다 더 구체적으로 개선 방안을 이해하고 적용해 볼 수 있을 듯합니다.