[지디넷코리아]애플리케이션 시스템을 개발하는 일은 언제나 험난하다. 치열한 경합을 거쳐 수주했더라도 기다리는 것은 시스템 개발이라는 거대한 산이다. 미지의 산을 넘어서 종착점까지 가려면 곳곳에 산재해 있는 고개들을 넘어야 한다. 그 중에서도 프로젝트 초반에 버티고 있는 높은 고개가 바로 요구사항 정의인데 프로젝트 수행에 있어서 최초로 극복해야 할 난관이다. 이를 효과적으로 넘을 수 있어야만 분석, 설계 고개로 향할 수 있다.

요구사항 정의 단계는 생명주기에서 가장 문제가 많은 취약지로 남아 있는 게 현실이다. 최근에 대안 수단으로서 UI 프로토타이핑을 활용하여 효과를 보는 사례가 보고되고 있다. 그래서 UI 활용 현황과 이용 가능한 도구들을 소개하고자 한다.

요구사항을 획득하는 어려움으로부터 자유로운 분석가가 있을까? 이 문제에 대한 방안을 도출한다 하더라도 한두 가지를 개선한다고 해서 획기적으로 나아질 수 없는 것은 여러 가지 요소가 복합되어 있기 때문이다.

그래도 우리가 복합 요인으로 얽히고설킨 문제가 있을 때 위험을 완화시키려면 영향도가 큰 문제 요인부터 한 개씩 해결해 가는 것이 안전한 전략이라는 것을 경험으로 알고 있다. 그것이 UI 프로토타이핑을 선택한 이유이다.

목표 산출물이 초기부터 개방되어 논의된다면 이해 관계자들은 각 화면 별로 자신들과 관련된 부분에서 틀리거나 빠진 것을 고치기 쉬울 것이다. UI 프로토타이핑은 종이와 연필에 의존해서 하는 경우가 아직 주류를 이루지만 파워포인트와 엑셀, 워드 등도 이용하고 있다.

프로토타이핑 전문 도구들도 제품으로서 나오고 있으나 장단점이 있기 때문에 선택이 쉽지 않은 상황이다. 따라서 현황을 정확히 파악해서 자신의 프로젝트에 가장 잘 맞는 방법을 선택할 수 있는 안목을 기를 수 있기를 희망한다.

문제를 해결하려면 요구사항을 알아야 한다

요구사항을 정의하는 방법으로 무엇을 사용하고 있는가? 요구사항 도출의 중요성이 대두되기 시작한 시기를 되돌아본다면 1970년대 초까지 거슬러 올라간다. 당시에는 소위 기능 명세서라는 이름의 문서가 주류를 이루던 시절이었고 요구사항은 문서 곳곳에 숨어있었고 프로그래머들은 숲에서 보물을 찾듯이 고객의 요구를 파악해 가면서 프로그래밍 하던 시절이었다.

그 때 현업에서 일하던 일단의 분석가들이 나서서 새로운 방법들을 탐구하여 제시하기 시작했다. 그 중에서 구조적 분석과 설계 방법이 대단히 각광을 받았다.

Yourdon, DeMarco, Page-Jones 등 개발자들은 산출물로서 구조적 명세서라는 새로운 문서를 소개하면서 이제는 사용자와 함께 DFD를 보면서 상의하면 되니까 고객 요구사항을 어렵게 끌어내던 일은 과거의 일이 되어버렸다고 호언했다. 그러나 인간사 문제가 대체로 그렇듯이 예기치 않은 문제점들이 끊임없이 돌출하기 일쑤였다.

70년대 수준의 문제 규모를 해결하는 데는 성공한 것도 사실이고 그것에 대해서 동의하지 않는 사람은 없었으나 그 DFD가 화려하게 등장한 것에 비하여 관심 밖으로 떠밀리기까지 기간은 오히려 짧았다. 해결해야 할 문제 복잡도가 점점 커지면서 이를 효과적으로 제어하는 능력도 부족했고 대규모 문제를 감당하기에는 어울리지 않는 것으로 판명 났기 때문이다.

그 후 데이터 기반으로 문제 해결을 시도하면서 ERD를 사용자에게 가르쳐 보려는 시도가 한 때 유행했다. 그 후 객체지향 방법에 희망을 걸어 보기도 했다. 하지만, 그것은 프로그래밍 생산성 향상에는 크게 도움을 주었으나 요구사항 획득에 도움 주는 문제에서는 나아진 것이 없었다.

그 동안 두드러지게 발전된 분야로 품질과 생산성을 높을 수 있는 프레임워크 기술들이 보편화 된 것은 확실한 수확이었다. 사용자들이 PC기반으로 사무 환경이 바뀌어 오피스 도구를 실제 업무에 활용하면서 소프트웨어를 보는 눈높이가 올라가다 보니 웬만큼 만들어서는 만족할 수 없게 되었다. 그리고 인터넷 이용이 늘어나고 새로운 서비스를 접하면서 사용자가 개발팀에 바라는 기대치도 그 만큼 높아만 갔다.

그런데 높아진 기대치에 부응하여 개발팀이 만족스럽게 내놓을 수 있는 무기는 오랫동안 나타나지 않았다. Jacobson 덕분에 사용자와 개발자 간 연결 고리를 만들 수 있는 유스케이스 보급이 일반화되면서 새로운 희망이 솟을 수 있게 된 것은 얼마나 다행인가!

프로토타이핑에서 효과를 보려면 사용자 언어 사용이 필수
앞에서 모델링 도구 역사를 좀 지루하다 싶을 정도로 기술한 것은 개발자용 도구를 고객 측 사용자에게 억지로 맞추려 해서는 성공할 수 없다는 사실을 역사에서 배우자는 의도였다. 소위 만능 해결 도구를 드디어 찾았다고 판단되면 업무에 적용해 보고, 잘못된 것이었다는 것을 인지하면 포기하고 다른 대안을 찾아 나서게 마련이다.

그런 후에 다시 두 번째 대안으로 교체해서 시도해 보고, 또 다시 시행착오 하고… 문제의 본질을 알기까지 오랜 세월이 걸릴 수밖에 없었다.

결국 해답은 단순한 원리에 있었으니 사용자가 평소 사용하는 언어와 평소 활용하는 그림으로 나타내어 의사소통하는 것이 유일한 대안이라는 결론에 이르고 있다. ‘목마른 놈이 우물 파라’는 속담도 있지만 누가 목마른가를 알면 어느 쪽에서 학습해야 하는지가 저절로 결정된다.

사용자인 고객들은 도메인 지식을 습득하고, 의사소통을 하며 보고하고, 교육할 때 그들의 언어로 하게 마련이다. 그리고 그들도 자신들의 업무로 인해 나름대로 바쁘기 때문에 개발자들의 언어를 배울 틈을 내기란 어렵다.

그런 현실을 이해한다면 어느 쪽에서 배워서 대화해야 하는지는 자명해진다. 모델링 하려면 UML을 배울 수밖에 없고, 데이터를 저장하려면 SQL을 배워야한다. 또 프로그래밍하려면 자바를 배워야 했듯이 사용자와 대화하려면 분석가는 그들의 언어를 배워야 하는 것은 당연한 일 아닌가?

사용자들은 자신들의 언어를 잘 알아들을수록 그들은 개발자들을 더욱 가깝게 대해준다. 소위 공통언어를 사용하는 족속들끼리의 연대 의식이다.

그러면 사용자들은 어떤 언어를 사용하는가? 고객들은 도메인에 속한 전문 용어들을 써서 자연어 문법으로 도메인 내용을 설명한다. 물론 그림은 말 이전에 인류의 공통 언어이고 사용자도 예외는 아니다.

대신 그림 속에 들어가는 콘텐츠가 도메인마다 다를 뿐이다. 고객이 사용할 화면에서 도메인에 속한 엔티티와 속성들, 그리고 도메인 프로세스가 들어있는 그림 조각들이 도메인 이해 관계자들의 언어이다.

그리고 화면이 이동하는 것을 동적으로 나타낸 문서나 화면을 이동하는 동작을 시연할 수 있다면 그것도 사용자 언어에 속한다. 화면이 중요한 이유는 ‘그림 한 장이 백 마디 말보다 낫다’라는 말에서 보듯이 그림은 문장에 비해서 월등히 효과가 높기 때문이다. 그리고 동적 시뮬레이션으로 대화할 수 있다면 가치는 더 높아진다.

사용자 언어를 잘 활용하는 분야가 있는가?
필자는 개발자들이 벤치마킹 할 수 있는 사용자기반의 산출물로써 누구에게나 추천하는 문서가 있는데 바로 자동차 운전 설명서와 핸드폰 사용 설명서이다. 사용자가 읽고 이해할 수 있도록 사용자 입장에서 기술된 문서로서 이보다 더 잘 만든 것은 아직 못 보았기 때문이다.

핸드폰 기능이 하루가 다르게 다양해지고 있는데 새로운 기능들을 활용하려면 사용 설명서 대로 따라 해 보면서 습득할 수 있도록 작성되어야 한다.

그 설명서들도 초기에는 지금과 다르게 읽고 이해하기가 어려운 때가 있었지만 요새는 어느 회사 설명서를 보아도 알기 쉽게 되어있다. 설명서를 잘 만들 수 있는 것은 문서 작성자들이 여러 산출물을 비교하면서 좋은 점들을 받아들이면서 개선을 거듭한 덕택일 것이다.

어떤 일이든지 개방 환경으로 전환 하면 발전이 가속 된다는 것을 두 가지 사용 설명서는 증명하고 있는 것이다. 그럼 설명서들이 다른 설명서와 다른 점은 무엇일까? 핸드폰의 복잡하게 얽혀 있는 기능들을 분해해서 한 가지씩 설명하되 책장을 넘기지 않고 알 수 있도록 한 페이지로 설명하거나 길어도 두 페이지를 넘지 않는다.

그래도 각 설명마다 사용자가 알고 싶은 내용이 충분히 들어 있다. 더 알고 싶으면 해당되는 페이지에 가면 다시 독립 항목이면서 자체로 완전히 의미 있는 작은 지식이 활용될 준비를 하고 있다. 그런데 주의할 점은 무조건 작게 나눈다고 해서 좋은 건 아니란 사실이다.

서비스 단위로 나누어야 하고 서비스를 처음부터 끝까지 설명해야 하는데 이 두 가지 규칙이 지켜질 때에야 비로소 분해 설명을 하는 가치가 있다. 한 서비스를 두 동강 내어 별도로 설명한다면 분해해서 얻는 이익보다 분리되었기 때문에 잃는 정보 손실이 더 클 테니 차라리 분리하지 않는 편이 나을 것이다.

왜 그렇게 작성하는 것이 좋은가? 바로 유스케이스 원리로 설명할 수 있다. 이들 설명서는 유스케이스 기술서로 작성된 것이다. 그 설명서를 작성한 사람들이 유스케이스를 학습하고 나서 작성했는지 아니면 고객들에게 최선의 서비스를 제공하는 방향으로 설명서를 작성하다 보니 현재처럼 진화되었는지 필자로서는 알 수 없으나 결과는 같다.

사용자 설명서가 알고 보니 유스케이스!
이제 자연스럽게 유스케이스 설명으로 넘어왔다. 이바 야콥슨의 회고록에 따르면 그가 유스케이스를 개발하게 된 것도 당시 개발자로써 복잡한 요구사항 문제를 효과적으로 풀어낼 방법을 찾다가 자연스럽게 나온 것임을 알 수 있다. 전화 교환기를 개발할 때 수많은 문제가 발생해서 복잡하게 얽혀 있었는데, 어떤 방식으로든 정리해야 했다.

그래서 유스케이스라는 방법을 고안해 냈고 그렇게 해결한 결과가 좋았고… 그 때부터는 같은 방법을 써서 요구사항 획득을 효과적으로 진행할 수 있었고 결과적으로 에릭슨 교환기의 품질을 보장해 주는 원동력이 되었다.

그렇게 탄생된 유스케이스 방법이 훌륭하지만 추가로 그림 요소와 동적인 요소를 도입하면 더 큰 효과를 낼 수 있다. 이것에 대해서는 다음 섹션 이후에 자세히 분석한다.

오늘날 유스케이스는 요구사항을 수집 할 수 있는 가장 중요한 도구로 인식되고 있지만 개발자들이 작성한 유스케이스 문서를 검토할 때마다 느끼는 것은 유스케이스 가치를 왜 이렇게도 알아주지 않는가 하는 점이다.

그러다 보니 유스케이스 역할과 책임도 턱 없이 축소되어 겨우 몇 페이지에 극히 인색하게 설명을 해서 지금 보고 있는 것이 유스케이스인가 아니면 유스케이스 요약인가 하는 착각을 일으킬 정도이다.

독자 중에 자신이 분석가라고 생각하는 분이 있다면 스스로에게 자문해 보아야 한다. ‘내가 유스케이스를 제대로 대접하면서 사용하고 있는가’, ‘유스케이스를 사용하지 않는 분이 혹시 이런 생각은 하지나 않을까’, ‘나는 유스케이스를 사용하지도 않으니 그 놈을 홀대한 일도 없었는가’. 그러나 사실과 다를 수도 있다.

당신이 문제 설명서를 작성할 때 비즈니스 프로세스 단위로 나누고 그 각각에 의미 있는 활동을 부여했는지 음미한다면 분명히 유스케이스 사고를 하고 있다고 봐야 한다.

참고로 분석가와 개발자를 구분하는 기준은 문제 기술서 문장을 금과옥조로 여기고 그것에 의존해서 일을 진행하는지 아니면 문제 설명서 문맥 속에 숨겨진 본질을 찾는 노력을 하는 지로 구별한다.

언어는 사용할 때만 가치가 발휘된다
사용자가 잘 알고 있는 언어로 의사소통해야 한다는 것을 인식만 하고 부단히 교류하는 활동을 하지 않는다면 아무것도 변하는 것은 없다.

겨우 몇 번만 소극적으로 교류하고 요구사항을 획득한 척 하더라도 결과적으로 얻는 것이 없기는 마찬가지다. 서로 통할 수 있는 공통어가 생겼으니 이제부터는 부단히 대화를 해서 서로 동의한 것을 공통어로 기록해 가야 한다.

꼭 필요한 것은 사용자와 개발팀이 자신의 생각을 서로 공유하고 그 기반에서 부단한 교류를 해야만 요구사항을 만족할 만하게 획득할 수 있다는 점이다.

요구사항을 획득하는 방법으로서 유스케이스를 활용하는 것이 우선 주류가 되어야 하지만, 그것을 제대로 작성하려면 동적으로 시뮬레이션 되는 비주얼 화면의 도움을 받음으로써 더 속도를 내어 주요 요구사항에 대해서는 조기 완료시킬 수 있다.

요구사항을 구체적으로 획득하자

결국 사용자는 화면을 보면서 일을 하므로 내부 논리 보다는 UI에 관심이 집중될 수밖에 없다. 이것이 바로 UI 프로토타입을 매개체로 하여 사용자의 관심을 끌어들이면 효과를 보는 이유이고, 프로토타이핑을 하는 목적이다.

고객이 개발팀과 인터뷰하는 것만으로는 답답한 생각이 많이 든다. 내가 말한 것이 화면에서 어떻게 나타날 것인가?

지금까지 이해한 것을 화면으로 요약해 주면 한 단계아래 세부사항을 논할 수 있을 텐데…. 개발팀이 말로만 할 게 아니라 파악한 내용을 보여준다면 교정해줄 수 있을 텐데…. 개발팀들은 사용자 입장에서 무엇이 필요할 것인가를 생각해 본다면 그들을 더 잘 이해할 수 있게 된다.

UI 프로토타이핑으로 위험을 줄일 수도 있는가? 이 질문에 대한 답은 ‘이해 관계자들 간 상이한 관점을 서로 알 수 있고, 대화를 효과적으로 진행하여 일정지연을 감소시킬 수 있기 때문에 도움이 된다’이다.

프로토타이핑 이점

개발자와 사용자 간 인식 차이를 식별하는데 이용하고 고객 서비스 중 누락된 부분을 발견하기 쉽다. 또 직접 유사 화면을 대하기 때문에 사용하기 불편하고 혼란을 주는 부분을 식별, 개선하고 요구사항에서 불완전한 내용과 일관성이 미흡한 부분이 있으면 식별하기도 좋다.

특히 완성은 덜 되었더라도 작동하는 시스템이 있다면 타당성과 유용성을 초기에 확인할 수 있고 품질이 보장된 시스템의 명세서 기초로서 인정받을 수도 있다.

UI 프로토타이핑은 어떻게 사용되는가?
초기에 작성된 프로토타이핑은 참조용이나 청사진으로 이용할 수 있으므로 여기서 출발하여 시스템 초기 버전을 제시하여 개발자들이 기준으로 사용할 수 있다. 시스템을 구축하고 난 후가 아니라 초기에 시스템 특성을 파악하고, 사용자 요구사항을 검증하여 위험을 줄일 수 있기 때문이다. 개발팀에서 만들기 쉽고 사용자 측에 넘겨 시험하기도 쉽다.

멀티 쓰레딩이나 네트워크 프로그램에서 위험 가능성을 인지했다면 미리 생각한 것이 맞는지 확인해 본 후에 코딩을 시작해야 시행착오를 줄 일 수 있다.

다른 산업분야에서는 프로토타이핑을 어떻게 활용하는가?
건축이나 토목과 같은 정적인 설계에서뿐만 아니라 선박 건조 시에도 모형을 만들어 시험하는 것은 물론이고 자동차의 신 모델을 출시할 때는 필수적으로 컨셉트 카(concept car)를 미리 만들어 충분히 시험을 해 본 후에야 양산 플랜트를 구축하고 있다.

자동차 산업에서 필수로 쓰이는 컨셉카는 무엇에 활용하는가? 고객들에게 신차의 개념과 스타일, 기술을 보여주면서 새롭고 파격적인 설계에 대한 고객 반응을 살펴보면서 고객으로부터 사용 용이성 측면에서 자료를 수집할 수 있는데 바로 모형이 있기 때문에 가능한 일이다.

UI프로토타이핑 접근법에는 무엇이 있는가?
대표 접근법으로는 진화용(Evolutionary) 프로토타이핑과 시안용(Throw-Away) 프로토타이핑 그리고 진화용을 보완한 점진적 방법이 있다. 전자는 일부 구현된 시스템을 사용자에게 제공하고, 요구사항이 명확해지면 수정하고 추가해가는 반면에 후자는 요구사항 분석과 확인 목적으로 활용한 후 버린다. 두 가지 접근법은 특징은 <표 1> 에 나타냈다.

<표 1> 진화용 프로토타이핑과 시안용 프로토타이핑 비교

점진적 개발법

진화용 프로토타입의 장점과 함께 대규모 개발에서 필요한 통제를 결합할 필요가 있다. 그렇게 하면 수시 변경에서 오는 문제점을 피할 수 있기 때문이다.

정상적인 소프트웨어 프로세스를 따르므로 관리가 잘 될 수 있으나 문제점으로는 소프트웨어 아키텍처를 먼저 구축한 후 요구사항이 완료되므로 아키텍처 제약으로 인해 요구사항이 제한 받을 수 있다는 점을 꼽을 수 있다.

GUI 프로토타이핑은 어느 방법을 따를 것인가? 개발자들이 자신의 관점에서 UI를 만들어 사용자에 전달했을 때 한 번에 그대로 받아들이는 경우가 있는가? 사용자와 의사소통을 원활히 하려면 사용자의 언어를 매개체로 써야 할 뿐 아니라 사용자가 쉽게 참여할 길을 열어 주어야 한다.

그런 의미에서 진화용 프로토타입을 사용하여 초기 인터페이스를 만든 후에 사용자가 평가해서 만족할 때까지 수정하면 효과를 높일 수 있을 것이고, 그 과정에서 개선안이 떠오른다면 전면 재구축할 수도 있다.

프로토타이핑 도구들

프로토타이핑에 필요한 도구들은 화면 설계를 어느 정도 정밀하게 나타낼 수 있는가에 따라 화면 충실도라고 하는데, 충실도가 낮은 도구들로서는 PowerPoint, Visio, hotoshop/Fireworks, Denium, Paper 등이 있다. 한편 충실도가 높은 도구들은 iRise, Axure, Serena Composer, Lucid Spec, Caretta, VB, HTML (WYSIWYG) 등이 있다.

이들 중 몇 가지 도구에 대해서 UI를 소개하기로 한다. 각 도구들에 대한 자세한 기능에 대해서는 해당 도구를 홍보하고 있는 사이트와 사용자 커뮤니티에 들어가서 참조할 수 있다.

페이퍼를 이용한 프로토타이핑
페이퍼 프로토타이핑에 대해서 Carolyn Snyder는 “UI를 정의하고 정제하는 가장 빠르고 쉬운 방법”이라고 요약했다. UI 프로토타이핑 도구로 가장 많이 사용되는 도구는 아마도 페이퍼 프로토타이핑(Paper Prototyping)일 것이다. 이와 관련된 자세한 기술은 페이퍼 프로토타이핑 홈페이지(www.paperprototyping.com)에서 확인할 수 있다.

페이퍼 프로토타이핑의 장점은 많다. 일단 비용이 저렴하고, 팀 회의 중에 대화하면서 생성이 가능하며 설계가 완료되지 않았기 때문에 변경될 수 있다는 암시를 줄 수 있는 덕분에 고객이 과다한 기대를 하지 않아서 좋다.

한편 단점도 있는데, 테스트하기에 부적당하고 상호 관계가 많은 경우에는 나타내기가 복잡해지며, 여러 사람들에게 나누어 주거나 공유하기가 어렵다는 점들이다.

<화면 1> 페이퍼를 이용한 프로토타이핑

Denium을 이용한 프로토타이핑
Denium과 관련된 자세한 기능은 dub.washington.edu/projects/denim/에서 확인할 수 있다.

Denium의 장점으로는 페이퍼에 비해 상호 교류를 더 잘 할 수 있고, 출력을 HTML로 출력해서 배포할 수 있다는 점이다. 또, 버튼과 체크박스, 드롭다운을 구비하고 있으며 무료로 다운로드 받을 수 있다는 점도 특징이다.

단점으로는 타블렛 PC에서 펜 마우스로 설계하기에는 좋지만 보통의 마우스를 사용할 경우 지루한 작업이 될 수 있다는 점과 학습 곡선이 오래 걸린다는 점 등을 들 수 있다.

<화면 2> Denium을 이용한 프로토타이핑

EA 도구를 이용한 프로토타이핑
시스템 개발에서 사용하는 CASE를 사용하여 애플리케이션 모델링을 하므로 만일 CASE가 프로토타이핑 기능을 제공한다면 효과적일 것이다. 따라서 분석 설계용 CASE를 조사한 결과 엔터프라이즈 아키텍트(Enterprise Architect)에서 UI 프로토타이핑 기능을 제공하고 있다.

<화면 3>은 EA CASE에서 제공하는 대로 화면 설계와 코멘트로 설명을 보충한 결과를 보여주고 있다. 그러나 EA에서 시뮬레이션 기능을 제공하지 않는다는 점은 좀 아쉽다.

<화면 3> EA를 이용한 UI 프로토타이핑

프로토타이핑 전용 도구를 이용하기

전용 도구에는 프로토타이핑 하는데 필요한 장치들을 구비하고 있다. 덕분에 프로토타입을 손쉽게 그릴 수 있으므로 UI를 만드는 속도가 빠르다. 코드 한 줄 안 쓰고도 사용 편의성 문제를 쉽게 확인할 수 있다. 특별 look & feel 이라도 쉽게 만들 수 있다. 요구사항이 명백해지고 상호 교류를 할 수 있으므로 비용이 많이 드는 반복 개발을 감소시킬 수 있다.

UI와 요구사항이 더 긴밀하게 연결된다. 자동 UI 명세서 문서를 생성한다. 소프트웨어 생명주기 문서화 작업에서 요구사항 문서로도 활용된다는 점들도 장점이다. 그럼 프로토타이핑 전용 도구를 사용하는 몇 가지 예에 대해 알아보자.

Caretta를 이용한 프로토타이핑
클라이언트에서 할 일이 많은 경우 프로토타이핑에 적당하다. 그리고 자신만의 템플릿을 만들어 놓고 재사용하기 좋다. 마법사 기능이 많은 덕분에 마우스 드래그만으로 편리하게 프로토타이핑을 할 수 있다.

물론 불편한 점도 있다. 웹 환경 클라이언트 프로토타이핑을 지원하지 않고, 상호 교류가 한 페이지에서만 이루어지므로 화면을 많이 만들면 좁아터진 곳에서 옹색하게 작업해야 한다.

Caretta 외에도 다음 세 가지 도구들이 저마다의 장점과 단점을 지닌 채 활용되고 있다.

<화면 4> Caretta를 이용한 UI 프로토타입

●Lucid Spec(http://www.elegancetech.com/LS.aspx)
장점으로는 명세서를 작성할 수 있고, 행동 설명을 붙일 수 있다. 단점은 시뮬레이션이 되긴 하나 Lucid 에서 만든 파일만 작동하고, 인터페이스가 다른 도구들에 비해서 눈에 잘 들어오지 않는다.

<화면 5> Lucid를 이용한 UI프로토타이핑

●Serena Composer(http://www.serena.com/Products/composer/home.asp)
장점으로는 시뮬레이션이 가능, 워크플로와 프로젝트 관리 기능 보유, 명세서 작성 기능 있음. 단점으로는 학습 곡선이 길고, UI프로토타이핑이 워크플로에 너무 밀착되어 있고, 프로토타입 외에 기능 과다로 복잡하다.

●Axure(www.axure.com)
장점으로는 사용하기에 좋고, 명세서 작성 기능이 탁월, 템플릿 재사용, 워크플로를 선택적으로 연결 가능하다. 단점으로는 웹에 치중되고, 과다한 파일 생성, 그리고 배포할 때 매끄럽지 않음.

●iRise Studio(www.irise.com)
장점으로는 가장 강력한 기능이 있는 프로토타이핑 도구, 고급스런 프로토타입과 명세서 생산 가능함. 스프레드시트로 출력 가능, 스크린 간에 변수 전달 기능 있음. 단점으로는 가격이 비싸고, 웹 기반이며, 상당 기간 훈련이 필요하다.

PPT를 이용한 UI 프로토타이핑
파워포인트를 이용하여 동적인 UI 프로토타이핑을 하는 방법을 소개한 사례들이 매우 매력적으로 보고되고 있다. 마이크로소프트(이하 MS)에서 UI 개발 당당 매니저로 일하고 있는 Jensen Harris는 An Office User Interface Blog에서 자신들이 MS 도구들을 개발할 때 사용하는 UI 프로토타입과 시뮬레이션 방법을 소개하고 있다.

UI 프로토타이핑 도구로써 PPT를 쓰면 좋은 점이 많은데 시스템 개발에 앞서 ISP를 선행으로 실시했다면 그 결과 산출된 공식적인 산출물들이 대부분 PPT로 되어있어서 정보를 활용하기 편하다는 점이 가장 큰 장점이다.

파워포인트는 누구나 익숙해져 있기 때문에 다른 사람의 도움 없이도 스스로 설계할 수 있다는 점 또한 강점이다. PPT로 만든 자료는 흔히 페이퍼 프로토타입과 비교되는데 페이퍼 보다는 실제에 더 가깝게 그릴 수 있고 수정하기도 편하고 보존도 용이하다.

그러나 이전까지는 동적인 시뮬레이션을 해 볼 수 없었기 때문에 개발자로써는 힘들게 그린 자료를 들고 가서 화면 링크 관계(interaction)를 일일이 설명해야만 했다. 또, 듣고 있는 사용자로써는 흐름만 대충 이해할 뿐이어서 가치 있는 피드백을 제공하기 어려웠다.

그러다 보니 요구사항 도출과 식별이 늦어지고 시스템 개발 일정에 차질은 물론, 세밀한 기능들은 빠진 채 분석, 설계 단계로 진행할 위험이 있었다.

프로토타입에 동적 기능이 부여되면 상호 작용하는 감을 느낄 수 있다. 또한 전자 파일이기 때문에 손으로 그린 문서보다는 쉽게 수정할 수 있다. 그리고 사용 용이성을 검증해 보는 평가자는 마우스를 사용할 수 있으므로 자연스러움도 느껴볼 수 있다.

사용자들에게 페이퍼 프로토타입이 잘 먹혀들지 않는 이유는 무엇일까? 고객들에게 페이퍼를 모니터라고 생각하고 연필은 마우스라고 가정해 주면 좋겠다고 요청했을 때 마지못해 시늉은 내겠지만 내심으로 불편하기 때문이라고 Jenson Harris는 예리하게 지적하고 있다.

Maureen Kelly는 프로토타이핑 도구들이 많이 있음에도 PPT를 고집하는 이유를 세 가지로 제시하고 있다.

우선, 신속성이다. 한 번 만들어 보고 마음에 안 들면 즉시 고쳐볼 수 있기 때문이다(그 모든 것을 분 단위 시간 내로).

둘째로는 정밀도 부족을 꼽는다. 예쁘게 그려지지 않는다는 점을 오히려 장점으로 보는 것이다. 덕분에 상위 수준 설계 이슈에 대해서만 집중할 수 있을 뿐만 아니라 예쁜 그림은 원래 만들어 지지도 않기 때문에 시도조차 할 수 없어서 자신도 모르게 필요 이상의 정교한 작업에 몰입하는 것을 막을 수 있다는 얘기다.

추가 장점으로서는 설명을 바로 여백에 넣을 수 있는데 이것은 HTML이나 플래시로 프로토타입을 만들 때에 겪었던 아쉬움이 해결되는 순간이다.

셋째로는 누구나 가지고 있는 도구라서 좋다는 것이다. 팀원 모두가 가지고 있을 뿐 아니라 사용자도 가지고 있기 때문에 만나지 않고도 이메일로 보내기만 하면 스스로 실행해 보고 의견을 제시할 수 있다.

Kelly가 제안하는 파워포인트 프로토타이핑 절차와 기능이 매우 정제되어 있으니 직접 실천해 보길 바란다. 여기서는 PPT로 가능한 주요 기능만 기술한다. 자세히 알려면 참고 자료에 상세 절차가 자세히 기술되어 있으므로 내용대로 따라 하면 된다. 다음은 PPT에서 가능한 시뮬레이션 기능들을 열거한 것이다.

(1) Hyperlinking Text
(2) Creating Buttons and Hyperlinked Images
(3) Simulating Back Button
(4) Creating Mouseover Effects
(5) Use slide masters for persistent navigation
(6) Disable standard slideshow controls

주의사항

UI 프로토타입이 성공하려면 화면 설계 기간을 WBS에 등록하고 정식 프로세스 자격을 주어야 한다. 그리고 산출물을 공식 산출물로 등록하고 이와 동등한 문서를 대체시켜 주어야만 개발팀이 환영하면서 UI 프로토타입 문서를 중요하게 여겨 유지할 것이다.

사용자 중에는 프로토타입이란 사실을 망각하고 처음부터 UI 세부 사항에 과다하게 집착할 수가 있다. 그럴 경우에는 설명을 충분히 해서 프로토타입은 특정한 부분만을 검증하기 위해 작성된 것이란 사실을 알려주고 일정을 알려 주는 방법으로 오해를 불식시켜 주어야한다.

모든 일들은 긍정적인 면과 부정적인 면이 함께 공존한다. 그런 의미에서 프로토타이핑도 예외는 아닐 것이다. 독자들 중에 혹시나 UI프로토타이핑에 대해 부정적 선입견이 있었다면 필자의 글을 읽으면서 생각을 바꾸는 계기가 되었으면 하는 바람이다. 그리고 돈 안 드는 일이니까 당장 들어가서 시연해 보기 바란다(봐야 믿을 수 있으니까).

그리고 이왕이면 10개 화면 정도로 시도해 보면 좋겠다. 그러고 나서 팀원들과 그 내용을 공유하고 나서 신중히 생각해 보자. 우리 조직에 이 방법을 도입할 것인지에 대해서. @


참고자료
1. Brian Phelps, Rapid High Fidelity Prototyping Tools, Pfizer Inc.
2. Maureen Kelly, "Interactive Prototypes with PowerPoint", Sep. 2007, www.boxesandarrows.com/view/interactive
3. Jensen Harris, "Prototyping with PowerPoint", An Office User Interface Blog

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.