brunch

매거진 사용자 인터페이스를 생각하다

라이킷 60 댓글 8

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Weak Tie Mar 24. 2016

UI 디자인 툴을 만들었던 경험담

글을 시작하면서

현재 UI디자인 또는 기획하는 업무를 담당하는 대부분의 사람들은 파워포인트를 사용하고 있을 것으로 예상된다. 그것은 꽤 오래 전부터 진행된 습관으로, 더욱 강력한 툴인 Microsoft VISIO를 쓰기에는 기획자나 UI디자이너의 개발이해도가 많이 부족한 것이 현실이다. 여기에 신속하게 프로토타입까지 만들어내야 하는 시대의 흐름 속에, 기획자와 UI디자너이들은 멘붕을 경험하게 되었던 것이 현재 모습이다.

이러한 시대의 흐름에 발맞춰 UI를 디자인하고 그것을 즉시 프로토타입으로 테스트 해 보는 툴들이 속속들이 나타나고 있다. 속속들이 나타났다기 보다는 오래 전부터 지속되어 오다가 최근에 들어서야 UI/UX의 입지가 높아지면서 수요가 폭발한 것이라 생각하면 쉽다. 대표적인 툴로는 AxureRP, Balsamiq Mock-Up, Fluid UI, Design Studio 등이 있다. 최근 Facebook에서 Paper 앱을 출시하면서 사용된, 그들 스스로 만든 "Origami(종이접기)" 라는 툴이 화두가 되면서 다시금 주목 받고 있다.

<FluidUI: 개인적으로 가장 잘 만들어진 프로토타이핑 툴이지만 Windows에서는 되지 않는다는 함정>

<Origami: Facebook에서 Paper 앱을 만들 때 사용한 툴. Windows에서 동작하지 않는다 ㅠㅠ>

기획자나 UI디자이너들은 언제나 환영할 일이다. 자신들이 할 수 없는 영역의 무엇인가를 툴에서 '손쉽게(?)' 제공해 주며, 의도한대로 제품이나 서비스를 출시할 수 있다는 것은 너무나도 행복한 일이니까 말이다.

그렇다면 단계를 조금 더 거슬러 올라가보자.

과연 누군가 만들어 놓은 툴을 그냥 공부하고 이용만 하면 되는 것일까?

그러한 툴은 왜 만들어지고, 누가 만들고 어떻게 탄생하는 것일까?

이번 칼럼은 위와 같은 질문에 대한 경험담으로, 실무를 담당하는 분들과 공유하고자 한다.

이상적인 에덴동산을 꿈꾸다

기업을 운영하는 대부분의 사람들이 꿈꾸는 방향은 역시 최대의 수익성이다. 이 '수익성'이라는 단어 속에는 순수한 자재의 원가를 절감하는 노력 뿐만 아니라 '최대 효율의 프로세스를 통한 원가절감'도 포함되어 있다. 시발점은 바로 여기에 있다.

일반적으로 '하드웨어를 제외한' 멀티미디어 제품이나 서비스를 개발하는 프로세스는 '기획 - UI디자인 - GUI디자인 - 소프트웨어 개발 - 평가(QA/QC) - 출시' 의 과정을 거치게 된다. 폭포수 방법론 또는 애자일 방법론 같은 내용을 반영하더라도 어느 시점에 평가 및 재설계를 하느냐의 차이일 뿐 큰 틀에서의 흐름은 같다.

이미지 출처: http://www.frankendesign.com/wordpress/689/the-design-process-trap/

하지만 현실에서는 항상 다음과 같은 질문을 하게 된다.

- 왜 대체 기획한대로 제품이 나오지 않을까?

- 왜 대체 UI디자인을 한 대로 GUI디자인이 나오지 않을까?

- 왜 대체 GUI디자인을 한 대로 소프트웨어가 개발되지 않을까?

결론적인 해답은, 이전 단계에서 다음 단계로 넘어가는 시점의 커뮤니케이션오류 또는 휴먼오류이다. 이 부분은 언제나 기업의 의사결정권자에게 보고되고, 오류를 최소화하는 방안을 강구하도록 요구되어진다. 이제 고민이 시작되는 것이다.

결국 "모든 프로세스를 아우를 수 있는 시스템을 구축"해야 하는 결론에 다다르게 된다.

상상해보면 그것은 에덴동산이고 무릉도원이며 다음과 같은 프로세스가 기본적인 생각의 틀이다.

1) (기획은 제외하고) UI디자인이 된 와이어프레임이 입력되고 GUI디자이너에게 이관된다.

2-1) 디자인된 UI에 그래픽과 폰트가 입혀지고 소프트웨어 개발자에게 이관된다.

2-2) 입력된 데이터를 기반으로 간편한 코딩을 통해 프로토타입을 산출한다.

3) 소프트웨어 개발자는 입력된 모든 데이터를 빌드하고 'To-Do'부분에 백엔드 프로그램을 진행한다.

4) UI가 디자인된 모습 그대로 소프트웨어가 개발된다. (짜잔!!)

자 이제 에덴동산과 무릉도원을 만들어내기 위한 모든 준비가 끝났다. '어떻게 할 것인지?' 고민해보자.

누군가가 만들어놓은 것 말고 직접 만들기

7년 전 "모든 프로세스를 아우를 수 있는 시스템”을 만들어야 하는 미션이 주어지고, 그 당시 신입사원이었던 필자의 입장에서는 많은 고민과 검토를 해야 할 수 밖에 없었다. 그 당시에도 유사한 목적으로 출시된 솔루션들은 어느 정도 있었고 그 중 몇 개를 검토했었으나 다음과 같은 문제가 있었다.

- 수요가 그다지 많지 않아 가격이 비싸다

- 회사의 프로세스에 맞지 않아 사용에 한계가 있다

- 필요로 하는 문서가 출력되지 않는다

- UI가 좋지 않아 디자이너들이 도저히 사용할 수 없다

이러한 결과들로 인해, 결론은 ‘솔루션을 직접 만들기’로 진행되게 되었다.

(개인적인 생각으로는 NAVER도 Design Studio를 자체적으로 만든 이유가 상기 내용과 같지 않았을까 한다)

EB Guide Studio : 자동차 업계에서 많이 검토되는 툴인데...비주얼 디자이너에겐 넘사벽이고 비싸다

요구사항을 찾고 분석하기

‘솔루션’ 이라고 해 봤자 결과론적으로는 특정 ‘툴’을 만들어야 하는 것이다. 이 툴은 “UI디자이너 – 비주얼 디자이너 – 소프트웨어 개발자”를 물 흐르듯 자연스럽게 연결시켜줘야 하는 툴로써, 다르게 해석하면 너무나도 다른 3직군의 요구사항을 모두 만족시켜야 하는 난제였다(What the hell!!). UI디자이너 1명(나), 비주얼 디자이너 1명, 소프트웨어 개발자 2명으로 TFT가 구성되고 각자의 요구사항을 나열하기 시작했다.

요구사항은 간단하게 정리하자면 다음과 같았다.

- UI디자이너는 화면에 오브젝트별 와이어 프레임을 배치하고 각각의 속성을 정의할 수 있어야 한다.

- 화면에 그래픽 리소스를 속성별로 배치해야 한다. 이는 이미지일 수도 있고 버튼일 수도 있다.

- 글로벌 제품 대응을 위해 다국어를 지원 및 확인 가능해야 한다. (개인적으로 이게 가장 획기적이다)

- 회사에서 필요로 하는 문서가 자동으로 산출되어야 한다. (리소스 속성 및 좌표 같은 것)

- 오브젝트 및 화면 별로 인터랙션 속성을 정의할 수 있어야 하며 이를 스크립트 코딩할 수 있어야 한다.

- 입력된 그래픽 리소스는 별도 가공 없이 그대로 전달되고, 이를 빌드하면 소프트웨어 개발자는 To-Do부분의 코딩을 진행해야 한다.

사실 이 과정은 어렵고 험난했으며 특히나 세부적인 협의는 괴로울 만큼 상당히 오랜 기간이 소요되었다. 이 부분에 대한 일화만으로도 상당히 많은 지문을 채울 수 있으나, 이 부분은 다음 기회로 넘기기로 하자.

요구사항을 정리하는 것은 분명 큰 일이다. 문제는 그 다음으로 요구사항을 시각화해서 ‘툴을 만들 수 있게’ 구성을 해야 했다. 하지만 TFT의 구성 인원을 다시금 살펴보자면... 이러한 요구사항을 시각화해야 하는 역할은 내 몫이었다.

벤치마킹하기

존재하지 않던 툴을 만드는 것은 백지에 그림을 새로 그리는 것과 동일하다. 사실 이런 상황에서 밑그림을 그리기 위한 최선의 방법은 역시 벤치마킹일 수 밖에 없다. 정말 다행인 것은 나 자신이 사용할 줄 아는 툴과 프로그램 언어의 개수가 상당히 많고 그것들은 다음과 같았다. (툴을 ‘사용할 줄만 아는 것’ 과 ‘잘 사용하는 것’과 ‘창의적 결과물을 만들어내는 것’은 전혀 다른 개념의 이야기로 여기서는 ‘사용할 줄만 아는 것’을 의미한다)

[그래픽 툴 (영상편집 툴 포함, 버전 생략)]

- Microsoft PowerPoint (이 정도는 누구나 다)

- Adobe Photoshop (이 분야의 사람이면 누구나 다)

- Adobe Illustrator (비주얼 디자이너라면 누구나 다)

- Adobe Dreamweaver (난이도가 올라갑니다)

- Adobe Flash

- Adobe After-Effect

- Adobe Premiere

- Corel Painter

- Autodesk 3D Studio Max

- Autodest Maya

- Pixologic Z-Brush

- Visual Studio

[프로그램 언어 (버전 생략)]

- C (C, MFC, DirectX, OpenGL)

- C++

- Java

- Java Script

- Flash Action Script

- ASP

- PHP

이렇게 다양한 툴과 언어를 사용할 줄 안다는 것은 이 프로젝트에서 정말 감사할 일이었다.

먼저 목적성에 가장 부합했던 툴은 무엇보다도 ‘Dreamweaver’와 ‘Flash’이다. 정확히 말하자면 Dreamweaver는 그래픽 툴이라고 하기 보다는 ‘퍼블리싱 툴’ 이라는 개념이 맞고 Flash는 ‘프로토타입+퍼블리싱’ 툴 이라는 개념이 가장 적절하다. 어쨌던 기본 개념은 이 두 가지 툴에서 시작해야 했다.

Dreamweaver : 웹 퍼블리싱 툴 중에는 단연 최강이 아닐까?

Flash : 한때 인터랙티브 웹의 최강자. 지금도 프로토타입용으로는 단연 최고다

그 다음 중요한 것은 UI디자이너와 비주얼 디자이너, 개발자의 시각에서 바라봐야 하는 것이었다.

- UI디자이너들은 대부분 PowerPoint(PPT)에 익숙하다. 오브젝트의 배치 방식 및 인터랙션의 개념은 PPT와 유사해야 한다.

- 비주얼 디자이너들은 대부분 Photoshop에 익숙하다. 따라서 툴은 최대한 Photoshop과 유사한 UI로 구성되어야 하며 인터랙션 역시 Photoshop와 유사해야 한다.

Photoshop: 디자이너들이 가장 사랑하면서 저주하는 그 놈

- 소프트웨어 개발자는 비주얼 스튜디오에 익숙하다. 따라서 툴은 최대한 비주얼 스튜디오와 유사한 UI로 구성되어야 한다고 생각했으나, 실제로 그들이 필요한 것은 헤더 및 클래스 정의, 파라미터 및 포인터 추적이 용이한 ‘소스코드의 하이어라키 구조화’였다.

결국 마지막 ‘소프트웨어 개발자’의 영역은 도저히 내가 할 수있는 영역이 아니기 때문에, TFT 멤버 중 개발 담당자분께 의존하고 툴의 UI를 디자인하기 시작했다.

메뉴구조 짜기

메뉴구조라 하면 "IA(Information Architecture)"와 동일하다고 생각하면 된다. 일반적으로 엑셀로 단계별로 정의하게 되는데, 문제는 일정이었다. 즉시 개발에 착수할 수 있도록 기획서가 빠르게 나와야 하는 난관으로... 결국, 기획서를 작성하면서 바로 메뉴구조를 짜기 시작했다. 사실 기억을 더듬자면 어떻게 이렇게까지 할 수 있었는지 스스로가 잘 하고 싶은 마음에 미쳤던 것이 아닌가 싶다.

메뉴구조 짜기1 : 이런 것부터 정의를 시작해야 했다

메뉴구조 짜기 2 : 그냥 엑셀로 만들 걸....하고 후회하고 있다

화면UI구성하기

앞서 말한 바와 같이 툴은 결국 UI디자이너와 비주얼 디자이너가 사용하게 된다. 결국 한참을 고민하다가 다음과 같이 화면을 구성하게 되었다. (처음 보면 그냥 포토샵이다)

툴 시작 시 초기 화면 기획 : 물론 결과적으로 나온 툴은 이렇게 안 생겼다 ㅠㅠ

그래픽 툴에 대한 사용에 익숙한 분들이라면 각각의 구성요소가 무엇을 의미하는지 대략 알 수 있을 것이다. 아래는 각 구성요소에 대한 세부적인 정의를 진행했던 기획서이다.

UI 정의서 : 막 이런거도 정의하고 그랬다

동작 정의하기

다음은 실제 각각의 기능을 실행했을 때의 동작에 대한 정의를 해야 한다. 뭐 하나 쉬운 것은 없었지만 이 부분만큼은 정말 힘들었던 것으로 기억된다. 스스로 사용하면서 자연스럽게 사용하던 모든 기능들을 문서로 정의해서 실제 툴을 개발하시는 분께 전달해야 한다. 파워포인트의 오브젝트 입력 방법, 포토샵의 레이어 위치 조정 및 그룹 생성, 플래시의 애니메이션 적용 방법, 드림위버의 오브젝트 속성값 입력 방법 등을 총 동원해서 정의를 해야 했다.

동작 정의서1 : 이걸 만들기 위해 너무나도 당연하게 사용하던 기존 툴을 다시 세부적으로 분석해야 했다

동작 정의서2 : 너무나도 당연한 것 같지만 모르는 사람이 많았던 폰트 및 좌표

이상향은 도달했는가?

이미 7년전에 진행한 프로젝트이며, 1년 정도 지난 뒤에 툴은 어떠한 형태를 갖추게 되었다. 여느 툴이 그러다시피 1.0 버전은 완성도가 현격히 떨어지는 경향이 있으며 기획자나 UI디자이너의 의도대로 나오지 않는다. 그에 따라 1.0 버전이 아닌 Beta 버전으로 사용하는 경우가 많다. 허나 이 툴의 경우는 부득이한 상황에 의해 즉시 실제 양산 프로젝트에 적용해야 했고 엄청난 수정을 거치게 되었다.

이 툴은 현재도 사용하고 있지만 아쉽게도 버전업을 할 기회가 없었다...

만일 좀 더 많은 지원이 꾸준히 있었다면 지금쯤이면 4.0 버전 정도로 업데이트되어 (그럴리 없겠지만) 시중에 고가에 판매해도 될 정도의 툴로써 성장했을지도 모른다.

이상향...이라고 하기엔 거창할지 모르지만 “UI디자인 -> 비주얼 디자인 -> 소프트웨어 개발”로 연결되는 프로세스는 결국 성립되었다. 그리고 최소한 화면에 배치된 디자인 리소스를 소프트웨어 개발자가 다시금 입력하는 이중작업은 없어졌고, 유지보수는 수월해졌다. 그러나 그것이 이상향일까...

결론부터 말하자면 이상향에는 결국 도달하지 못했다. 그리고 이상향은 어디에도 존재하지 않으며 어떠한 방법을 써도 해결되지 않는다. 이것은 진실이며 모두가 이해해야 할 본질이다.

문제는 툴이 아니다. 프로세스와 사람이다.

이 툴을 기획, 디자인, 개발하는 것은 당연히 힘들고 어려운 일이었지만 어쨌든 개발이 되었고 실제 적용되었다. 문제는 실제 사용 중에 일어났다. 다음은 이 프로젝트를 적용함에 있어 겪은 어려움이다

- 새로운 시스템이 부여되면 기존 프로세스를 탈피하는데 많은 고통이 따른다.

어느 조직이나 고유의 프로세스가 있고, 그것은 오랜 시간 동안 시행착오와 함께 다듬어져 현재의 형태를 유지하게 되었을 것이다. 이에 대하여 새로운 시스템이 부여되면 기존 프로세스를 유지해 온 조직은 관성을 버려야 한다. 이 과정에서 많은 반대의견이 있게 되는데 그 중심에는 ‘오랜 시간 기존의 프로세스를 유지해 온 사람들’이 있다. (반대가 나쁘다는 것은 아니다. 위험 부담을 줄이는 것이 더 나은 결정일 수 있다)

새로운 것에 대한 반대의견이 일단 발생하면 장점보다는 단점들이 눈에 보이게 되고 이러한 부정적인 시각들은 프로젝트에도 부정적인 영향을 미침과 동시에 툴 자체에 대한 불신이 커진다.

- 프로토타이핑과 퍼블리싱은 비주얼 디자이너에게 넘기 힘든 벽이다.

최근 비주얼 디자이너에게는 인터랙션 디자인의 영역까지 습득해야 하는 어려움이 있다. 이러한 인터랙션 디자인은 프로토타이핑을 포함하게 되는데 이를 위해서는 기본적인 코딩을 배워야 한다. 지금도 마찬가지겠지만 비주얼 디자이너가 코딩을 배운다는 것은 여간 어려운 일이 아니며, 아얘 진입도 못하는 분도 있다.

또한 툴에 입력된 그래픽 리소스가 소프트웨어 개발에서 유효하게 사용되기 위해서는 입력 하면서 버튼, 이미지 등의 속성값이 완벽하게 입력되어야 하는 등의 ‘무결성’이 보장되어야 한다. 소프트웨어를 개발한 경험이 없고서야 무결성 데이터의 입력을 비주얼 디자이너가 수행하기엔 분명 무리가 있다.

- 역할에 대한 명확한 정의가 필요하다.

앞서 설명한 내용과 같이 툴을 잘못 사용하게 되면 비주얼 디자이너가 감당해야 하는 영역이 너무 넓어진다. 이는 각 기업별 조직 구성 및 역할을 통해 정의되는 부분으로 이러한 프로세스가 완성되기 위해서는 툴 사용을 위한 별도 조직이 필요하다. 이는 프론트엔드 개발 조직이 될 수도 있고, 디자인 영역의 인터랙션 디자인 조직이 될 수도 있다.

즉, 조직이 세팅되지 않은 상태에서 툴의 적용은 업무를 가중시키고, 시스템의 오류를 야기시킨다.

- 조직이 엄청나게 유기적으로 움직여야 한다.

어떠한 툴을 사용해서 시스템을 만들어낸다는 것은, 시스템이 툴에 의존된다는 것을 의미한다. 이것은 툴의 운영이 매끄럽다면 엄청난 개발 시간의 단축과 비약적인 업무 효율성 상승을 꾀할 수 있다는 것과 같은 의미이며, 이를 위해서는 조직간 전달되는 데이터의 무결성이 보장되어야 한다.

‘무결성’은 레이아웃 디자인, UI배치, 오브젝트 속성 정의, 그래픽 리소스 입력, 오브젝트 이벤트 정의, 오브젝트 이름 등을 모두 포함하고 있으며 UI디자이너-비주얼디자이너-소프트웨어 개발자간 서로의 작업 방식을 공유하고 상대방의 작업 방식에 맞추어 데이터를 입력해 줘야 한다.

말이 쉽지, 실제로는 어려운 일이고 결국 모든 것은 리더의 운영능력과 담당자간의 커뮤니케이션에 달려 있다.

(여기에서 '리더'는 디자인과 개발 영역을 모두 아우를 수 있는 사람을 지칭한다)

모든 문제점은 프로세스와 사람으로 귀속된다

마무리 하면서

기획자 또는 UI디자이너 분들은 많은 프로토타이핑 툴을 접하고 있다. 그것은 기획서에 포함할 이미지로 활용하기에도 좋고, 실제 UI시나리오를 설계하기에도 좋다. 이에 따라 새로운 툴이 나오거나 버전업이 되면 스터디를 하고 사용해 보기도 한다.

하지만 누군가가 만들어 놓은 것을 사용하는 것이 아닌 나 자신이 사용하기 적합한 툴을 직접 만들어 본다는 생각을 하면 어떨까? 이것은 단지 툴의 문제가 아닌 "생각의 틀을 깨는 방법"일 수 있다.

웨어러블이 화두가 되면서 모두가 웨어러블을 활용한 아이디어를 도출하고 서비스 디자인을 한다. 이에 대해 ‘웨어러블이 동작되는 원리 또는 원천기술’에 대하여 생각의 깊이를 더 깊게 내려가보는 것을 어떨까? (사실 이전에 Bluetooth LE에 대한 칼럼을 쓴 이유가 여기에 있다)

이러한 접근법은 스스로의 사고력을 깊게 만들어 주며, 현상이 아닌 원리를 활용한 더 나은 서비스를 디자인 하는 시작점이 될 수 있다. 나아가서는 나 스스로가 느꼈던 ‘모든 것은 사람과 프로세스의 문제’라는 조직적이고 인문학적인 접근이 가능할 수도 있겠다.