이유있는 웹기획실무 WHY [2부 실무편-ASIS분석]

프로젝트 초반에 기획자들은 대부분 새로운 프로젝트에 대한 두려움이 앞서기 마련이다. 요구사항을 반영하여 새로운 무언가를 만들어 내야 하는 창작의 고통이랄까? 최고보다는 여러 가지 주어진 환경에서 최적의 결과물을 얻기 위해서는 분석단계가 무엇보다도 중요하다. 이번에는 리뉴얼 프로젝트를 기준으로 하여 AS-IS에 대한 분석의 포인트와 방법에 대해서 이야기해 보고자 한다. 

현실적으로 대부분의 프로젝트에서 분석단계에 아주 적은 일정이 주어지게 마련이다. 심지어 프로젝트를 시작하자마자 화면설계(SB)를 시작하는 경우도 있다. 예산에 맞춰 구축일정을 잡다 보면 반드시 필요한 분석단계가 1순위로 빠져버리는 것이 사실이다. 하지만, 분석에 대한 요령이나 반복적인 학습이 이루어진다면 최소한의 시간으로 AS-IS분석을 통해 인사이트를 얻어 낼 수 있다.

1. 프로젝트 목적 및 배경 분석

일반적으로 RFP를 살펴보면 대부분 사업목적 및 배경이 명시되어 있다. 프로젝트가 만들어진 이유이자 반드시 그 목적을 달성하기 위한 결과물을 만들어야 한다. 그렇기 때문에 목적과 대/내외적인 배경에 대해서 파악하는 것은 기본이며 중요한 과정이다. 사업의 목적은 절대로 변하지 않기 때문이기도 하다.

사업목적과 배경이 분석되지 않고 공유되지 않은 상태에서 많이 벌어지는 일이 전혀 목적에 맞지 않는 결과물로 오픈을 준비할 때이다. 최초에 대표이사는 RFP를 검토하고 사업목적에 맞는 웹사이트를 제안 받아 현업담당자가 수행사와 함께 최고의 결과물을 만들길 기대하고 있지만, 최종 오픈 시점에 완료보고를 받는 자리에서 “이건 누구의 사이트인가요?”라는 멘탈을 강하게 흔드는 피드백을 받은 경험이 있을 것이다. 최초에 보고 받은 대표이사는 사업목적이나 배경에 변함이 없지만, 실제 현업/수행TF는 구축단계에서 다양한 이유로 최초의 방향을 조금씩 틀어가는 경우가 많아지게 된다. 그래서 최초의 사업목적과 배경에 흔들림이 없도록 의사결정의 순간마다 그 목적과 배경에 맞는 의사결정인지에 대한 확인과 점검이 필요하다.

“모든 의사결정사항은 

사업목적을 달성하기 위함이어야 한다.”

프로젝트의 목적은 사실상 ‘매출증대’가 가장 궁극적인 목적이다. 잠재고객확보, 사업영역확장, 브랜드인지도강화는 사업목적을 달성하기 위한 목표가 된다. 영리목적의 서비스를 제공하는 회사로서 매출증대는 당연한 목적이며, 그 목적을 이루기 위해 여러 가지 목표를 세우게 된다. 우리가 말하는 프로젝트가 그 목표 중에 하나가 된다. 즉, 웹사이트 구축이나 모바일 플랫폼 구축 등의 사업목표가 만들어지는 것이다. 물론 사업을 시작하는 목적이 반드시 매출증대만은 아닐 수 있다. 동종업계의 시장 추세에 맞추어 경쟁력을 강화하기 위해서 프로젝트가 시작되거나 새로운 브랜드가 런칭 하면서 온라인 채널을 마련하는 경우도 있다. 다만, 이러한 목적을 달성하기 위한 여러 가지 목표 중에 웹사이트 리뉴얼 등의 온라인 사업이 발생하게 되는 것이다. 

발주사의 이러한 궁극적인 목적과 목표가 설정되면 수행사에게 RFP를 배포하고 해당 목표를 달성하기 위한 다양한 전략이나 실행안들을 제안 받게 되고, 수행사는 주어진 환경과 조건하에서 최고의 전략들을 내세워 구체적인 실행안들을 제안하게 된다. 프로젝트의 탄생 배경에서 소개한 바 있다.

예를 들어, 브랜드인지도 강화, 고객 커뮤니케이션 채널마련, SNS채널을 통한 바이럴 마케팅 채널마련, 대고객서비스 편의성 강화 등의 전략을 가지고 각 전략을 수행하기 위한 실행방안을 마련한다. 

브랜드인지도 강화를 위해 아이덴티티를 고려한 웹사이트 디자인 리뉴얼 

고객 커뮤니케이션 채널을 마련하기 위해 고객센터의 메뉴기능 강화 및 페이스북 팬 페이지 개설 

바이럴 마케팅을 위한 다양한 참여형 이벤트 운영

대고객서비스 편의성 강화를 위해 기능개선 및 사용성 개선 

위의 목적, 목표, 전략, 실행안을 통해서 발주사가 기대할 수 있는 기대효과를 제안한다. 최종적인 기대효과가 프로젝트가 만들어진 목적과 부합한다면 해당 내용과 구축 결과물은 발주사와 수행사가 모두 만족할만한 수준을 얻어 낼 수 있을 것이다.

[2-1 프로젝트 목적 분석]

저자가 왜 사업의 목적, 목표, 전략, 전술의 개념을 강조하는 이유는 ‘프로젝트의 이야기 흐름’을 항상 기억하고 프로젝트의 기획을 해야 하기 때문이다. 구축이든 제안이든 이야기의 흐름 없이는 원하는 결과물을 얻기 힘들고 설령 결과물이 나왔다 해도 본인 스스로의 설득도 되지 않을 것이다.

사업의 목적과 함께 탄생 배경을 생각해야 한다. 사업의 배경은 대/내외적인 사항들을 고려해 볼 수 있다. 내부적인 요인으로는 신규 브랜드 런칭, CI개편으로 인한 브랜드 아이덴티티 변경이나 대표이사의 조직개편으로 인해 서비스의 비전이나 방향성이 변경되어 발생 할 수도 있다. 여러 가지 내부 요인들을 살펴보면 어떠한 컨셉과 전략을 가지고 만들어야 하는지에 대한 인사이트를 얻을 수 있다.

[2-2. PEST 분석]

또한, 대외적인 요인으로는 정치, 경제, 사회문화, 기술측면에서의 어떤 현상이나 변화에 대한 분석을 진행한다. 이를 ‘PEST 분석’이라고 한다. 최근 이슈가 되고 있는 뉴스나 공신력 있는 연구소의 보고서 등을 참고하여 분석결과의 인사이트를 도출한다. 예를 들어, 사용자 환경의 변화, 장차법 시행에 대한 법안대응, 경쟁사의 선행에 따른 시장 경쟁력 확보, 급변하는 모바일 시장에 따른 고객 서비스 대응 등 대외적인 요인으로 인해 이번 사업이 생기게 된 배경을 파악한다.

일반적으로 사업 배경은 내부적인 요인보다는 변화하는 온라인 서비스의 시장변화에 따른 대외적인 요인으로 인해 발생하는 경우가 많으므로 기획자로서 온라인 서비스에 대한 뉴스와 트랜드에 대한 모니터링은 지속되어야 할 필수 과제이다.

2. 정보구조(Information Architecture) 분석

AS-IS의 시스템 분석은 크게 정보구조(IA), UX/UI설계, 기능에 대한 분석을 진행한다. 먼저 정보구조(IA)에 대한 분석을 위해서는 AS-IS 산출물을 요청하거나 운영팀에서 관리하는 정보구조(IA) 문서를 전달 받아서 검토하는 것이 원칙이나 산출물이 존재하지 않거나 최종 업데이트가 되지 않아 참고할 수 없는 경우가 많다.

먼저 AS-IS의 정보구조(IA)를 왜 분석해야 하는지에 대한 이유를 한번 살펴보자. 한번도 생각해보지 않았을 기획자들이 많을 것으로 보인다. 정보구조(IA)에서 분석해야 할 항목별로 그 이유에 대해서 알아보자.

1) 메뉴구조(Depth)

가장 기본적으로 파악하는 것이 메뉴의 Depth 구조이다. Depth 구조를 파악하면서 현재 메뉴의 그룹핑, 위치, 네이밍의 현황을 분석한다. 확인이 가능한 모든 페이지를 정리하여 페이지수 산정을 통해 TO-BE 개발범위 및 개발일정 수립에 참고하여 반영한다.

정보의 그룹핑은 사용자가 혼선을 일으키지 않도록 되어 있는지, 네이밍은 명확하고 일관성 있게 사용되고 있는지, 사용자가 서비스 이용에 있어 인지하고 있는 UX의 흐름에 맞도록 정보순서가 설계되어 있는지 대한 파악을 통해서 TO-BE에서 그룹핑, 순서, 위치, 네이밍에 대한 개선안을 도출한다.

2) 페이지형식

페이지 형식은 크게 program, html, link 페이지로 구분하고 ‘program’ 페이지는 개발자가 누락하지 않고 소스분석 및 DB를 확인할 수 있도록 한다. 추후에 기능정의 시에 해당 페이지들에 대한 별도 검토를 할 수 있는 리스트로 활용을 해야 한다. ‘html’ 페이지는 해당 페이지에 활용된 원본 이미지나 영상 소스가 있을 경우 소스요청을 하고 TO-BE에 변경되는 내용에 대한 콘텐츠를 추가 요청하여 ‘자료요청목록’을 통해서 관리한다. ‘link’ 페이지의 경우는 별도의 페이지가 존재하지 않으므로 해당 외부링크 URL을 확인하고 변경된 URL에 대해서 확인한다.

요구사항에 따라 TO-BE에서 페이지형식이 변경되는 경우도 발생할 수 있다. 페이지형식이 변경되는 사항에 대해서는 요구사항을 명확히 파악하여 변경 시 문제되는 사항이나 효율적인 운영방안에 부합하는지도 확인이 필요하다. 기존에 html로 운영 중인 페이지를 요구사항에 따라 무조건 기능을 마련하여 관리자페이지를 통해서 관리하도록 만드는 건 좋은 판단이 아니다. 반대의 경우도 마찬가지이다. 해당 페이지의 컨텐츠 업데이트 주기 및 관리 이슈를 파악하여 결정한다.

3) 접근권한

페이지별로 접근할 수 있는 회원등급이 다양한 웹사이트의 경우에는 해당 페이지 접근권한에 대한 변경사항이 있는지에 대해 파악하는 것이 중요하다. 비회원 외 회원전용 페이지인지, 회원 중에도 별도의 인증이나 회원등급에 따라 접근이 제한될 수 있는지, 회원등급 외에 특정한 조건을 갖춘 사용자만 접근이 가능하다면 해당 조건에 대한 파악과 TO-BE에서의 정책과 부합하는지에 대한 확인이 반드시 필요하다. 금융권의 경우처럼 실 거래가 발생하는 웹사이트의 경우에는 특히나 권한에 대한 파악이 매우 중요하다.

접근권한에 따라 구분된 페이지는 TO-BE 정보구조(IA)설계 시 정보 그룹핑이나 위치에 고려를 해야 하고 권한이 없는 고객이 접근 시 처리방안도 화면설계에 고려하여 사용자가 이용에 불편함이 없도록 해야 한다. 회원전용 메뉴가 TO-BE에서는 비회원에게도 서비스 되는 경우에는 간단히 알림 공지나 프로모션을 통해서 비회원의 접근을 유도할 수 있는 방안도 고려 대상이 된다. 구현만 하는 것이 끝이 아니다. 권한정책을 변경한 목적을 다시 한번 생각해봐야 한다.

4) 업데이트주기

앞서 말한 페이지 형식에 대한 요건변경이 발생할 경우 우선 고려해야 하는 것이 해당 페이지에 대한 업데이트 주기를 확인하는 일이다. 예를 들어, AS-IS에 html 페이지로 구현되어 있는 ‘CEO인사말’ 페이지를 TO-BE에서는 관리자페이지에서 업데이트가 가능하도록 CMS(Contents Management System)를 활용하여 program 페이지로 개발을 요구할 경우 업데이트 주기가 얼마나 되며 궁극적으로 program 페이지로 개발을 요청한 이유를 확인해야 한다. 

운영측면을 고려하면 현업담당자는 관리자 기능을 마련하여 편리하게 관리하기를 원하지만, 그에 따른 제약사항이나 구현일정을 고려하였을 경우에 보다 효과적인 방안이 무엇인지를 현업과 수행사간에 협의를 해야만 한다. 업데이트가 연1회 발생하는 ‘CEO인사말’ 페이지를 CMS를 도입해서 만들 이유는 없을 것이다. 요청사항에 대한 근본적인 니즈를 파악해야 한다.

5) 관리자페이지

관리자페이지에 대한 Depth구조, 접근권한 등을 Front 페이지와 같은 방법으로 모두 분석한다. 대형 온라인 서비스의 경우에 슈퍼관리자 외에 메뉴별 관리자가 별도로 관리되는 경우가 많으며, 관리자페이지 별로 운영에 대한 책임 문제가 있으므로 접근권한에 대한 정책이 중요한 쟁점이 될 수 있다. 이러한 경우 슈퍼관리자가 준관리자관리 기능도 병행하여 개발에 반영이 되어야만 한다.

또한, CS운영을 위한 통계기능에 대해서 분석하고 현재의 통계기능의 수준과 TO-BE에서의 통계 기능에 대한 요청 범위를 파악하여 수행기획안에 반영해야만 이후에 추가적인 개발이슈가 발생하지 않을 것이다. ‘Google Analytics’나 ‘네이버 애널리틱스’와 같은 무료서비스를 제안하는 것도 좋지만, 요구사항을 먼저 파악하고 무료서비스가 기능을 충족하는지를 검토하고 통계항목에 대해서도 해당 통계항목의 결과값으로 무엇에 이용하고자 하는지도 파악하여 UI설계에 반영해야 한다.

6) 운영인프라

AS-IS 정보구조를 파악하는데 왠 운영인프라 분석이냐고 물을 수 있지만 정보구조를 분석하다 보면 현재 운영되는 운영인력들에 대한 업무스킬과 대응능력 및 운영 프로세스에 대해서도 파악하는 것이 TO-BE 개선안을 반영하는데 중요한 요소로 작용될 수 있다. 트랜드라고 해서 무조건 기술반영을 고려 할 것이 아니라 이후에 운영이 가능한지에 대한 확인을 현업PM과 공유할 필요는 있다.

예를 들어, 요즘 트랜드가 플래시를 사용하지 않고 스크립트로 동적인 비주얼을 개발했을 경우 운영인력에 스크립트를 관리하고 인수인계가 가능한 인력이 없다면 개발에 있어 고려를 해볼 필요가 있다. 대안으로 스크립트를 사용하지 않고 개발하거나 운영인프라의 충원 등을 현업과 협의하는 것이 선행되어야 한다. 이러한 사항들은 추후에 발생할 수 있는 이슈에 대해 사전에 대응하는 방법이다. 실제 이러한 이슈로 인해서 개발이 완료된 것을 변경한 사례들이 있다.

정보구조(IA)에 대한 분석 항목별로 주요 분석내용에 대해서 알아봤다면 이제 AS-IS 정보구조(IA) 문서는 어떻게 작성하면 좋을지에 대해서 알아보자. 원칙은 TO-BE 정보구조(IA) 문서로 활용이 이어지도록 감안하여 작성을 해야 한다. 간단히 말하면 AS-IS 정보구조(IA)를 기준으로 메뉴순서변경, 추가/삭제, 메뉴명변경을 업데이트 하면 TO-BE 정보구조(IA)문서가 되는 것이다.

[2-3. AS-IS 정보구조(IA) 예시]

저자가 정보구조(IA) 작성을 중요하게 생각하는 이유는 IA문서 안에서 웹사이트의 전체적인 모습을 그려볼 수 있기 때문이다. 정보구조(IA)를 읽는 방법을 익히는 것이 중요하다. 실제로 저자는 프로젝트 내내 IA문서로 프로젝트의 전반적인 사항을 관리한다. [2-3]의 정보구조(IA) 예시를 설명해 보자.

『넥슨 웹사이트는 현재 5개의 1Depth 메뉴로 구성되어 있으며, 총 17페이지로 만들어져 있다. 온라인게임 메뉴는 리스트(list)페이지만 존재하며, 주단위로 온라인게임에 대한 리스트가 업데이트가 되고 각 온라인게임 개별 홈페이지 링크를 제공한다.

모바일게임 메뉴는 온라인게임과 유사한 리스트페이지를 제공하고 주단위로 업데이트가 진행되며, 게임별 상세(detail)가 홈(default)과 게임챗의 페이지로 tab UI로 구성되어 있다. 게임챗 페이지는 게임별로 로그인 사용자만 작성이 가능한 댓글기능의 페이지로 구성된다. 게임별 동영상이 포함되어 있으므로 동영상파일에 대한 확인이 필요하다.

이벤트 메뉴는 진행중인 이벤트, 종료된 이벤트, 당첨자 발표 3개의 메뉴로 구성되어 있으며, 각각 리스트(list)페이지와 상세(detail)페이지로 구성되어 있다. 진행중인 이벤트와 종료된 이벤트는 비회원도 접근이 가능하나, 이벤트 별로 추가 개발되는 이벤트 참여페이지로의 이동을 위해서는 로그인이 필요하다. 당첨자 발표는 로그인을 해야만 접근이 가능하며, 추가적으로 이벤트에 참여여부를 확인하여 상세페이지로의 접근이 가능하다.

넥슨플레이 메뉴는 홈과 서비스소개라는 html 페이지로 구성되어 있으며 총 6페이지의 분량이다. 브랜드별 로고이미지를 포함하고 있어 원본이미지 수급이 필요하다. 회원만 접근이 가능한 고객지원 메뉴가 있다. 
넥슨캐시는 http://cash.nexon.com으로 외부링크 처리되며, 새 창으로 이동하도록 되어 있다.』

기획자 마다 정보구조(IA)를 작성하는 기준은 다를 수 있다. 그 역시 작성에 이유나 목적이 다를 뿐이며, 저자가 말하는 AS-IS 정보구조(IA) 분석을 위해 작성되는 항목이나 작성법을 소개했다. 서비스의 기능이나 구현범위가 크지 않은 프로젝트에서의 수준을 소개했을 뿐 실제 대형 프로젝트의 경우에 AS-IS 정보구조(IA)문서는 이보다 훨씬 다양한 정보를 담아 낼 수 있다. 이후에 정보구조(IA) 문서만으로도 각 페이지별 화면에 대한 구성을 파악할 수 있다. 정보구조(IA)에 대한 작성법은 TO-BE 설계 단계에서 다시 한번 이야기 하도록 한다.

3. UX/UI설계 분석

UX(User Experience-사용자경험)와 UI(User Interface-사용자매개체)에 대한 저자의 개념정리는 설계단계에서 다시 이야기를 하도록 하겠다. 먼저 UX/UI의 분석을 위해서는 아래의 5가지 관점에서 장단점을 분석하여 인사이트를 정리하고, 개선안에 대한 벤치마킹을 계획하여 인사이트를 도출한다.

5가지의 분석관점에 대해서 상세히 살펴보자.

[2-4. UX/UI 분석관점]

1) 사용성(Usability)

UX와 접근성 확보에 기반한 UI설계와 디자인이 적절한지에 대한 분석이다. 사용하는 UI에 대한 설계와 디자인은 다양한 결과물로 구현이 가능하다. 해당 기능의 속성이나 사용자가 사용하는 목적 등을 고려하여 적절한 UI를 선택하고 그에 맞는 디자인을 반영해야 사용자가 불편함 없이 사용이 가능하며 기능상의 오류도 범하지 않게 된다.

예를 들어, 체크박스(Check box)와 라디오버튼(Radio button)은 UX상 그 기능이 다르다. 다중선택의 경우 체크박스를 단일선택의 경우는 라디오버튼을 사용해야만 한다. 단일/다중 선택에 대한 별도의 안내 없이도 일반 사용자는 해당 UI만 보고도 본인이 선택해야 할 행동을 인지하고 결정하게 된다. 

물론 단일선택의 경우에 콤보박스(Combo box)를 사용해도 무방하지만, 선택항목의 개수와 사용자의 인지도를 고려하여 UI를 설계해야 한다. 남자와 여자 둘 중 단일선택의 경우와 달리 1일~30일까지 중 하나의 일자를 선택해야 하는 경우에는 라디오버튼 보다는 콤보박스의 UI가 사용성이 더 뛰어나다고 판단한다. 반대로 남/여 둘 중에 하나를 선택하는 경우라면 콤보박스보다는 라디오버튼이 더 직관적이고 사용성이 좋다고 판단한다. 

사람이 한눈에 정보를 인지하고 받아들이는 수가 보통 6~7개라고 한다. 선택사항의 수에 따라 UI설계를 하는데 기준이 될 수 있는 사항이다. 메인페이지에 자주 있는 ‘서비스 바로가기’의 수도 10개, 20개의 바로가기를 제공한다면 사용자는 한번에 인지할 수 있는 정보량을 넘어서 원하는 메뉴를 찾는 행동을 하게 된다. 서비스 바로가기 UI를 제공하는 의미가 반감되는 설계이다. 사용성에 준한 UI를 판단할 때 사용자의 마우스 이동 동선이나 클릭 수를 기준하여 판단해도 좋다.

[2-5. 체크박스와 라디오버튼]

최적의 UI를 설계하는 것도 중요하지만, 그에 맞는 UI디자인을 반영하는 것도 매우 중요하다. 일부 웹디자이너의 경우 미적 요소만을 고집하여 가독성을 해치는 디자인을 하는 경우들이 종종 있지만, 아무리 미관상의 뛰어난 디자인이라고 해도 사용하는데 문제가 있다면 이쁘게 보일지 모르지만 사용자는 사용을 하지 않는다.

2) 가독성(Readability)

사용성에서 설명한대로 UI디자인에 대해 이야기할 때 가장 중요한 관점이 가독성이다. 가독성은 말 그대로 ‘읽을 수 있느냐’에 대한 정도이다. 사용자는 텍스트 글자를 읽어 정보를 전달받는 것과 마찬가지로 디자인의 모양이나 색상을 통해서도 같은 정보를 전달 받아 행동한다. 그러므로 설계된 UI의 모양이나 색상, 폰트와 스타일을 결정할 때 사용자가 정보를 읽어 들이는데 문제가 없어야 하며 더 중요한 것은 정확히 읽어야 한다.

물론, 사용자들 마다 인지하고 읽고 판단하는데 차이가 있다. 그래서 가독성을 고민할 때 우리는 해당 서비스의 주 타겟층에 대한 분석내용을 고려하여 판단해야 한다. 타겟의 연령대, 온라인 서비스의 활용 능력, 사용하는 디바이스, 해당 서비스에 대한 이해와 학습 정도 등을 고려하여 가독성 있는 디자인을 위한 최적의 방안을 찾아 내야 한다. 주 타겟층이 60대 이상의 고령자들인데 미관상의 이유만으로 네이밍을 모두 영문으로 표기하고, 명도대비를 고려하지 않고 색상을 결정한다면 사용자는 디자이너가 의도한 미관상의 아름다움을 보기도 전에 사용을 멈추게 될 것이다.

디자이너가 이러한 인사이트를 고려하여 가독성 있는 UI디자인을 할 수 있도록 기획자는 사전에 파악된 분석내용에 대해서 반드시 공유하여 디자이너가 최적화된 가이드를 만들 수 있도록 협업해야 한다. UI를 설계하는 과정에서 UI설계를 진행한 기획의도를 중점적으로 설명해야 한다는 것이다. 대부분의 기획자가 디자이너에게 전달해야 할 중요한 사항들을 잊은 채 화면에 대한 그림만 전달하는 경우가 많지만, 그로 인해서 가독성이 부족한 디자인 결과물에 대한 책임도 기획자에게 없지 않다고 본다. 

3) 명확성(Clarity)

그룹핑 된 메뉴의 상위메뉴명을 결정하거나, 카피 문구를 통해서 브랜드에 대한 속성을 전달하거나, 액션 버튼명을 결정하거나, 정보전달을 위해 부가적인 비주얼 이미지를 선택할 때 우리는 전달하고자 하는 내용을 사용자가 혼선을 일으키지 않도록 명확하게 표현할 수 있는 설계와 디자인을 선택해야만 한다. 5가지의 인사이트 관점에서 가장 놓치기 쉬운 부분이기도 하고 가장 부족함 없이 반영되는 부분이기도 하다.

우리가 웹사이트에 표현하는 텍스트, 이미지, UI 등 모든 요소는 사용자와 커뮤니케이션을 하기 위한 표현들이다. 명확하지 않고 불분명한 메뉴명으로 정보구조가 설계되어 있다면 사용자가 기대하는 서비스에 찾아 들어가는데 있어 사용자는 혼선을 일으키게 마련이다. 정보구조의 설계에서부터 UI디자인에 이르기까지 모든 사항에 대해 명확히 표현해야 하며 이를 위해서는 일관성 있는 화면설계와 디자인을 위해서라도 반드시 가이드를 마련하여 구축해야만 한다. 디자인가이드와 커뮤니케이션가이드에 대한 이야기는 설계단계에서 다시 설명하겠다.

“사용자가 기획자와 똑같은 생각으로 

서비스를 이용한다고 절대 생각하지 마라.”

4) 일관성(Consistency)

‘비밀번호’, ‘패스워드’, ‘password’, ‘PW’ 기획자가 4가지를 똑같은 의미로 사용을 한다고 해서 사용자도 그렇게 받아 들일 거라고 생각하지 마라. 사용자는 아쉽게도 의도한대로만 절대 행동하지 않는다. 일관성은 단순하게 가이드라고만 생각할 문제는 아니다. 디자인 및 커뮤니케이션의 가이드 적용뿐 아니라 인터렉션에 대한 설계나 아이덴티티에 대한 표현에 있어서도 브랜드 커뮤니케이션에 일관성 있도록 적용을 해야 한다. ‘과연 고객에게 일관성 있게 브랜드에 대해 이야기 하고 있는가?’ 온/오프라인 서비스 채널(웹사이트/매장)에서 사용자에게 브랜드에 대해 일관성 있게 이야기하는 것도 ‘브랜딩(Branding)’의 하나이다. 사용자와 하나의 언어로 커뮤니케이션 해야만 한다.

5) 확장성(Expandability)

모든 UI가 그렇지는 않지만 일반적인 UI들은 확장성을 고려하여 설계 및 디자인이 되어야 한다. 최근에는 HTML5의 등장과 함께 크로스브라이징(Cross Browsing-상호호환성)이 일반화 되었고 하나의 소스로 웹과 모바일에 최적화 될 수 있는 반응형 웹(Responsive Web)까지 나오면서 운영인력에 대한 리소스 관리가 이슈가 되는 운영사에서 니즈가 강한 성향을 보이고 있다. 반응형 웹이 아니더라도 네비게이션을 비롯한 일부 UI들은 추가/삭제에 대한 확장성을 고려하여 UI를 설계하고 디자인하고 퍼블리싱과 프로그래밍까지 다양한 경우의 수로 고려를 해야만 한다. 

최근에는 세로 드롭다운(Drop-down)형 메가메뉴(Mega menu) GNB의 UI형태를 많이 가져가 메뉴에 대한 추가 확장성 고려 및 확장된 영역을 마케팅영역으로 활용까지 다양한 활용방안이 고려되어 구현되고 있다. 불과 몇 년 전만 해도 화면의 콘텐츠 영역을 가린다는 이유로 가로형 GNB가 대부분 이였지만, 잦은 사용자의 마우스이탈이나 확장성을 고려하기 어려운 UI로 판단되면서 이제 거의 찾아보기 힘든 UI형태가 되었다. 최신 웹기술의 발달과 더불어 UI의 트랜드는 늘 변화한다. 지금의 환경과 기술에 최적화되어 사용성과 확장성을 고려할 수 있는 UI설계와 디자인을 고민해야 한다. 

4. 기능 분석

저자는 AS-IS에 구현된 기능 분석을 정보구조(IA)를 파악할 때 병행하여 목록을 정리한다. 실제 정보구조(IA)를 분석하기 위해서는 모든 페이지를 파악해야만 페이지 내 포함되어 있는 팝업페이지까지 분석이 가능하다. 기능 분석은 사용자가 직접 사용하는 기능과 관리자페이지를 통해서 제공되는 기능으로 구분하여 목록을 작성하고 직접 사용하면서 파악이 가능한 기능에 대한 간단한 기능정의를 작성한다. 이 문서가 요구사항정의 후 작성되는 기능정의서(Function Chart) 초안으로 활용한다.

기능정의서의 초안이라는 입장에서 상세한 기능정의나 환경에 의한 제약사항을 명시하기에는 부족한 단계이므로 현재의 기능에 대한 가시적인 내용을 정리하여 전체적으로 구현해야 할 기능에 대해서 파악하는데 목적을 두고 진행해야 한다. 기능 분석은 기획자 단독으로 진행하는 것보다는 프로그래머와 업무협의를 통해서 함께 진행하는 것이 효과적이다. 일반적인 웹사이트에 존재하는 기능을 예를 들어 살펴보자.

회원기능: 회원가입, 로그인, 아이디/비밀번호찾기, 회원정보수정/삭제, 회원탈퇴, 회원검색

게시판기능: 작성, 수정/삭제, 게시물이동, 공지설정, html편집기, 댓글, 스크랩, 공유, 보기설정

통합검색기능: 연관검색어, 테마검색, 검색순위, 검색상세설정, 통합검색결과

통계기능: 방문자, 페이지뷰, 다운로드, 스크랩, 회원, 게시물, 검색, 이벤트 통계

일반적인 웹사이트에 구현되는 기능으로 회원기능, 게시판기능, 통합검색기능, 통계기능을 보면 위의 예시처럼 1차적인 기능 분석이 가능하다. 하지만 1차적인 기능 분석의 내용만으로는 실제 기능정의서 작성에 있어 구현에 누락이 많이 발생하게 된다. TO-BE의 개선 요구사항을 파악 후에 실제 구현 단계에서는 필요한 기능을 제공하기 위해 연관된 부가기능까지 상세한 기능정의가 필요하다.

‘회원가입’ 기능만을 위해서도 부가적으로 발생할 수 있는 기능이 가입중복확인, 실명확인, 약관관리, 우편번호검색 기능이 필요하다. 여기에 회원가입 시에 사용자로부터 입력 받아야 할 정보에 따라서 추가적인 입력정보관리 기능이 발생하게 된다. 통계기능은 해당 요구사항에 따라서 프로그램 개발 시 로그데이터를 저장하기 위해 페이지마다 처리해야 할 업무와 로그데이터를 관리자가 원하는 시점으로 통계결과를 보여주기 위한 업무가 발생하게 된다.

그러므로 AS-IS의 기능 분석을 통해서 TO-BE에 반드시 유지해야 할 기능, 개선해야 할 기능, 제거해야 할 기능, 추가되어야 할 기능으로 구분하여 기능정의서, 화면설계서에 반영될 수 있도록 인사이트를 정리해야 한다.

관리자페이지에 존재하는 기능도 마찬가지의 이유와 목적을 가지고 기능에 대한 구분을 진행하고 이미 파악된 환경이나 조건에 제약사항이 발생할 경우에는 기능 구현에 따른 이슈를 제기하여 의사결정을 진행할 수 있도록 해야 한다. 기능정의서 역시 프로젝트 진행 중에 요건의 추가/변경에 따라 이슈가 자주 발생하게 되기 때문에 기능정의와 의사결정 사항에 대해서는 현업TF와 프로그래밍 개발팀에게 명확하게 전달되고 미스커뮤니케이션이 발생하지 않도록 각별히 주의해야 한다.

5. 타겟 분석

정보구조(IA), UX/UI설계, 기능 분석은 수행TF가 객관적으로 전문가 입장에서 판단하여 분석해도 인사이트에 큰 차이가 없는 경우가 많고 실제 에이전시의 전문 기획자들의 인사이트가 가장 정확하다. 하지만 프로젝트의 목적이나 배경과 마찬가지로 본 웹사이트의 타겟에 관련된 분석은 반드시 현업TF와 함께 분석하고 지속적인 인사이트 내용에 대해 공유와 피드백이 필요하다. 일반적인 기준에서 타겟을 설정하고 니즈를 분석하여 정리된 인사이트가 전체적으로 웹사이트의 방향을 잘못 가져갈 수도 있기 때문이다. 그만큼 서비스의 타겟을 설정하고 니즈를 파악하는 문제는 중요한 과정 중에 하나이다.

기초편에 언급했듯이 타겟분석을 위한 타겟설정은 현업TF에 요청하여 설정된 세부 타겟의 그룹군을 기준하여 분석을 시작하는 것이 올바른 방법이다. 타겟 분석에 있어서 저자는 3가지 질문을 가지고 시작하여 인사이트를 정리한다.

1) 누구를 위한 서비스인가? (WHO)

어떠한 속성을 가진 사용자를 주타겟으로 서비스를 준비할 것이며, 서브타겟은 어떠한 속성을 가진 사용자를 대상으로 부가 서비스를 준비할 것인가? 타겟의 연령, 성별, 지역, 학력, 직업 등 다양한 사용자층의 속성을 기준으로 준비하는 온라인 서비스 구축에 영향력이 있는 속성만을 결정해 주타겟과 서브타겟의 속성을 결정한다.

예를 들어, 전 세계적으로 유명한 조립식 블록완구 브랜드 레고(LEGO)의 웹사이트로 제품소개 및 쇼핑몰까지 연동하여 운영이 되고 있는 웹사이트를 리뉴얼 하는 프로젝트이다. 제품이 아동 블록완구를 판매한다고 해서 타겟을 6세~10세의 남성아동으로 설정하여 웹사이트를 개발해서는 안될 말이다. 실제 완구를 받고 사용하는 타겟층은 그러하지만 웹사이트를 방문하여 매출을 발생 시키는 타겟층은 그렇지 않다. 6세~10세의 아동을 둔 부모나 부모의 형제로 20대 후반~40대 초반의 소득이 안정적인 직장인을 주타겟으로 설정해야 할 것이다. 서브타겟으로는 레고 수집을 취미로 가진 성인 사용자로 설정하면 될 것이다. 극단적인 예라고 생각할지 모르지만, 실제 그렇게 타겟을 설정하는 경우가 적지 않다.

[2-6. 레고(www.lego.com)]

2) 사용자는 무슨 이유로 방문하는가? (WHY)

설정된 사용자는 우리가 만들 온라인 서비스에 무슨 이유로 찾아오는가? 무엇을 할 목적으로 방문하는가? 사용자가 왜 찾아오는지에 대한 이유와 목적을 모른다면 어떻게 만들어야 할지에 대한 답도 사실은 설득력이 부족할 수 밖에 없다. 이러한 사용자의 방문목적을 충분히 안다고 생각하거나 PV(Page View)통계에만 의존하여 잘못된 판단을 하는 경우가 있다. 사용자의 방문목적을 명확하게 파악하고, 그 방문목적을 쉽고 빠르게 달성하기 위해서 최적의 결과물을 만들어야 한다. 이는 통합테스트 시나리오 작성에도 기준이 되어야 하며, 사용자 매뉴얼을 만드는 목차로도 반영이 되어야 한다.

[2-7]은 온라인 주식거래가 가능한 대신증권 웹사이트이다. 대신증권 웹사이트 방문하는 사용자는 왜 방문하겠는가? 우선 코어타겟(Core Target)은 대신증권의 계좌를 보유하고 있으면서 서비스상품(주식/펀드, 채권, 보험 등)을 이용하는 계좌고객일 것이다. 그 중에서도 온라인 주식거래를 하기 위한 사용자가 1순위 코어타겟이 될 것이다. 현재는 모바일 주식거래(MTS)도 많은 성장을 보였지만 우리나라 온라인 주식거래 웹사이트를 이용하는 사용자 행동패턴을 보면 직장에서 업무 중에 가용한 시간을 이용하여 쉽고 빠른 주식거래를 실시간으로 하기 위해 증권사 웹사이트 WTS(Web Trading System)에 방문한다.

코어타겟의 방문 목적달성을 위해서 메인페이지의 UX/UI설계와 노출 콘텐츠를 구성하여 쉽고 빠르게 원하는 페이지에 접근하도록 사용성을 개선하고 간편이체/빠른주문 등의 부가적인 서비스를 마련하여 서비스 만족도를 향상 시키고 있다. 사용자의 방문목적을 분석하는 것은 사용자의 행동 시나리오를 통해서 파악하거나 로그분석을 통해서 인사이트에 접근하는 것이 가장 효과적이다.

[2-7. 대신증권,2013 (www.daishin.co.kr)]

3) 사용자에게 무엇을 주고자 하는가? (WHAT)

이 질문에 대한 대답을 가시적으로 보이는 결과물에 대해서만 논해서는 부족함이 있다. 질문을 좀 바꾸어 말하면 ‘사용자가 어떠한 경험을 하길 원하는가?’로 표현할 수 있겠다. 단순히 사용자의 요청에 대한 피드백을 말하는 것이 아니라 브랜드를 경험하고, 브랜드 아이덴티티를 인지하고, 상품에 대한 간접경험을 통해 ‘어떻게 기억되고 타인에게 어떻게 전달 되야 할지’를 고민해야 한다. 그에 따라 우리는 UX/UI설계와 디자인을 하고 커뮤니케이션 가이드에 따라 사용자와 지속적인 커뮤니케이션을 통해 주고자 하는 메시지를 전달해야 한다.. 예를 들어, 최근 트랜드가 되고 있는 스크립트 기술로 새로운 인터렉션을 구현한다고 해도 그로 인해 사용자에게 전달할 내용이 없다면 아무 소용이 없는 일 아닌가?

기획, 디자인, 퍼블리싱, 프로그래밍이 모두 브랜드를 전달하기 위한 하나의 컨셉으로 설계되고 디자인되어야 한다. 그것이 어쩌면 온라인 서비스를 만드는 궁극적인 구축 전략이며 목표가 될 수 있겠다.

삼성전자에서 갤럭시노트가 처음 소개되었을 때 제품의 가장 큰 이슈가 ‘S펜’이였다. 당연히 모든 광고매체를 통해서 S펜의 기능과 우수성을 홍보했다. 그때 갤럭시노트 웹사이트에 눈에 띄었던 것이 S펜으로 디자인된 마우스포인터이다. 사용자는 웹사이트를 이용하는 내내 S펜을 움직여 사이트를 경험함으로써 갤럭시노트의 S펜을 간접경험 할 수 있었다.

자, 위의 3가지 질문을 통해 먼저 타겟을 설정해 보자. 타겟은 일반적으로 코어타겟(Core target)과 서브타겟(Sub target)으로 나누어 설정한다. 서비스의 성격에 따라 하나 이상의 타겟층을 코어타겟으로 설정할 수도 있다. 그리고 AS-IS의 코어타겟과 TO-BE의 코어타겟이 같다는 전제는 위험한 설정이다. 서두에 말한 프로젝트의 목적과 배경을 기준으로 이번 개편의 목적에 따라 AS-IS의 서브타겟이 코어타겟이 될 수도 아니면 고려되지 않았던 새로운 타겟층이 코어타겟이 될 수도 있다. 예를 들어 한번 살펴보자.

『본 프로젝트는 혁신적으로 개선된 ‘M3 현대카드 이용고객의 온라인 서비스 만족도를 개선’(목적1)하고 ‘M3 현대카드의 차별화된 서비스를 소개하여 이용고객을 증대’(목적2)시키기 위해 현대카드 웹사이트를 리뉴얼 하고자 한다.』

위의 프로젝트 개요에 따라 M3 현대카드 이용고객을 위한 ‘차별화된 대고객서비스의 사용성 개선’(목표1)과 제품홍보를 통해서 보다 많은 ‘M3 현대카드 고객을 확보’(목표2)하기 위하여 리뉴얼 프로젝트를 수행한다. 여기서 먼저 신용카드 사용자를 중심으로 유저케이스(User case)를 정리해 보자.

[2-8. 타겟설정]

M3 현대카드의 보유여부와 타사카드의 보유여부를 크게 나누어서 일반적인 카드사용 및 보유패턴을 고려 했을 경우 총 7가지의 유저케이스를 정리할 수 있다. 이 중에서 이번 웹사이트 리뉴얼은 ‘M3 현대카드 이용고객의 온라인 서비스 만족도 개선’이 그 1차 목적이므로, M3 현대카드를 보유하고 있는 CASE1~CASE3까지를 코어타겟으로 설정하고, 2차 목적에 기준하여 M3 현대카드를 보유하지 않은 잠재고객에게 서비스 장점을 경험하도록 하여 M3 현대카드로의 이용전환을 기대할 수 있도록 CASE4~CASE7을 서브타겟으로 설정할 수 있다.

위의 예시를 보면 코어타겟에게는 UX/UI 및 사용성 개선이 주요 전략으로 온라인 서비스 만족도를 향상 시키고, 서브타겟에게는 기존 현대카드나 타사 신용카드와의 차별화된 서비스 비교가 가능한 콘텐츠 정보를 제공 함으로써 공격적이 마케팅 전략으로 M3 현대카드 이용전환의 계기를 마련할 수 있도록 해야 할 것이다.

위와 같이 M3 현대카드 이용고객을 코어타겟으로 설정했다면, 통계자료와 웹사이트 사용자의 로그분석을 통해서 구체적인 타겟 속성 및 행동패턴을 분석하여 TO-BE 개선을 위한 인사이트를 도출해야 한다. 코어타겟으로 설정된 M3 현대카드 이용고객의 연령분포, 성별, 지역분포, 학력분포, 직업 등 웹사이트 사용에 있어 영향을 줄 수 있는 타겟 속성을 정리한다. 그리고 정리된 속성별로 공개된 연구자료나 설문자료들을 검색하여 개선방향을 설정하는데 활용할 수 있도록 인사이트로 정리한다. 연령/성별 소비성향, 성별 색채선호도, 직업별 온라인사용시간분포 등의 통계자료를 분석하여 화면기획 및 디자인에 대한 가이드에 반영 한다.

국내 외 IT동향이나 트랜드 분석자료를 검색하거나 다양한 현황에 대한 통계자료를 검색할 수 있는 웹사이트를 공유한다. 이 외에도 삼성경제연구소(www.seri.org), LG경제연구원(www.lgeri.com), KT경제연구소 디지에코(www.digieco.org) 등 IT를 비롯한 경제 전반적인 연구결과들을 검색할 수 있는 기업별 자체 연구소에서도 자료를 참고할 수 있다.

IT STAT: 국내 정보화 통계자료 제공(www.itstat.go.kr) 

ITU(국제전기통신연합), ICT-eye(정보통신통계): 국제 정보화 통계자료 제공(www.itu.int)

OECD(경제협력개발기구): OECD 국가 관련 통계자료 제공(www.oecd.org/statistics)

KOSIS(국가통계포털): 국가별 현황 통계자료 제공(www.kosis.kr)

ITFIND(IT지식포털): IT동향 및 연구보고서 자료 제공(www.itfind.or.kr)

KISA ISIS(인터넷통계 정보검색 시스템): 인터넷자원, 이용현황 통계자료 제공(isis.kisa.or.kr)

StatCounter Global Stats(스탯카운터): 국제 웹 이용현황 통계자료 제공(gs.statcounter.com)

Rankey(랭키): 웹사이트 분석평가 서비스, 웹사이트 접속순위 자료 제공(www.rankey.com)

이제 타겟에 대한 설정이 완료되었다. 타겟 속성을 파악했고 속성별로 객관적인 통계자료를 통해서 행동성향을 파악했다. 그렇다면 AS-IS 웹사이트를 실제 사용하는 사용자들에 대한 니즈와 행동패턴을 분석해 보자. 사용자들의 니즈파악은 주로 CS(Customer Satisfaction)채널로 접수된 사용자의 문의사항이나 요구사항을 통해서 인사이트를 얻을 수 있다. 이용에 불편한 사항, 지속적인 사용자오류가 접수된 사항, 추가적인 기능요구사항 등을 분석하여 TO-BE에서 UX/UI나 기능개선의 인사이트로 활용하고, 사용자가 숙지해야 할 정책에 대한 안내나 필수활용 가이드에 대해서는 별도의 이용가이드를 배포하거나 자주찾는질문(FAQ)에 콘텐츠를 강화하여 개선방향을 설정한다.

이러한 사용자 니즈파악의 방법도 있지만 사용자의 온라인 설문조사나, 오프라인 매장에서의 이벤트를 통한 설문조사를 하거나, 인터뷰를 진행하여 사용자의 니즈를 파악하는 능동적인 방법도 있을 수 있다. 설문조사는 설문대상을 고려하여 많지 않은 문항수(10~15개 내외)를 선정하고 단답형으로 답할 수 있는 질문을 만드는 것이 관건이다. 설문조사를 비롯하여 모든 분석과정이 그렇지만 인사이트로 활용할 수 없는 분석과정은 전혀 필요 없는 업무임을 늘 인지하고 있어야 한다.

설문조사의 경우 사용자를 위한 설문조사도 진행에 유용하지만, 현업 서비스담당자나 CS담당자 등 웹사이트와 사용자간에 직접적인 운영업무를 맡고 있는 현업 내부 사용자에게도 설문조사를 진행한다면 니즈파악에 좀 더 객관적인 접근이 가능할 것이다. 아무래도 수행사 보다는 현장에서 사용자와 직접 소통하는 담당자들에게 실질적인 니즈파악에 더 근접한 인사이트를 얻을 수 있을 것이다.

설문조사를 너무 어렵게 생각하지 않았으면 한다. 설문조사를 현업/수행TF의 제한된 인력들이 분석한 니즈 파악의 인사이트 결과가 실제로 그러한지에 대한 확인의 과정으로 생각하면 쉽게 준비가 가능할지 모르겠다. 

회원가입에 큰 문제가 있다고 인사이트를 정리했다. 가입과정도 복잡하고, 입력항목이 많고, 사용자는 이 정보를 왜 입력해야 하는지를 모르기에 거부감이 있어 회원가입을 망설인다. 그렇다면 TF가 판단한 위의 문제점에 대해서 사용자도 정말 그렇게 생각하고 있는지를 조사하는 과정이라고 접근해 보자.

설문조사에 대한 과정이 사전에 협의된 요구사항이 아니더라도 기획자가 보다 정확한 사용자의 니즈파악과 인사이트를 정리하기 위해서 필요하다고 판단되거나 TF의 분석결과에 대한 신뢰도가 부족하다면 간단한 설문조사 문항을 만들어 진행하는 것이 권한다. 무엇보다 수행TF에서의 적극적인 분석과정 액션들이 현업TF에게는 신뢰감을 쌓아줄 수 있고, 의외의 결과를 얻어내는 일이 종종 있다.

[2-9. 설문조사 예시]

마지막 타겟분석 과정은 사용자 로그 데이터 분석이다. AS-IS에 통계기능이 없다면 분석이 어렵겠지만, 최근에는 무료 통계 솔루션이나 ASP(Application Service Providing)를 통해서 제공되는 막강한 통계서비스들이 있기 때문에 많이 활용되고 있다. 구체적인 사용자 로그 데이터가 없다고 하더라도 최소한 UV(Unique Visitors-순 방문자수)와 PV(Page View-페이지뷰)정도는 AS-IS에도 구현되어 있는 경우가 대부분이다. 순 방문자수 대비 페이지뷰가 현저히 적다면 이에 대한 분석을 통해 원인과 대안마련이 되어야 한다. 순방문자수가 1000인데 전체 페이지뷰가 1000이라면 모든 1000명의 방문자는 메인페이지만 보고 이탈하는 경우라고 판단하면 된다.

예를 들어, 쇼핑몰을 운영하는데 하루에 1000명의 방문자가 있고, 상품상세 페이지뷰가 3000이며 장바구니 페이지뷰가 2000이라고 가정할 때 평균 1인당 3개의 상품을 보고 그 중에 2개는 장바구니에 담아 두는 행동패턴을 볼 수 있다. 그렇다면 결제는 얼마나 이루어질까? 하루에 결제되는 수를 확인해보니 100개에 불과하다. 이는 사용자가 장바구니에 담아두고 결국 결제는 진행하지 않는 사용자가 대부분이라는 인사이트를 얻을 수 있다. 그럼 과연 사용자는 장바구니에 담아만 두고 실제 결제는 다른 쇼핑몰에서 하는 것일까? 결제페이지를 구분하여 자세히 살펴보니 결제입력 페이지는 1500의 페이지뷰를 발생하고 있다. 그러나 결제완료 페이지는 고작 100의 페이지뷰만 발생되는 것이 확인됐다. 이것으로 사용자는 실제 결제를 행하지만, 결제입력 페이지에서 ‘페이지이탈’이 엄청나게 발생하고 있으므로 결제입력 페이지에 대한 문제점을 파악하고 긴급 개선을 해야만 한다.

위의 예시에서 설명한 것처럼 통계를 위한 로그 데이터를 쌓는 것만이 중요한 것이 아니다. 빅데이터가 굉장한 화두로 떠오르는 시점에서 데이터를 통해서 인사이트 뿐만 아니라 가치(Value)까지도 얻어 낼 수 있는 역량을 키워나가야 한다. 톰크루즈 주연의 영화 ‘마이너리티 리포트(2002)’에서 배경으로 나오는 것처럼 2054년에는 인간의 범죄가 일어날 것을 시스템이 예측하여 사전에 범죄를 예방할 수 있다는 내용이다. 지금의 빅데이터 성장속도라면 충분히 가능하지 않을까? 영화를 떠나서 좀 더 가치 있는 방향으로 기술이 발전했으면 한다.

가장 많이 사용하고 있는 무료 통계 서비스로는 구글 애널리틱스(www.google.co.kr/analytics)로 유료 서비스에 버금가는 다양한 통계 데이터 분석이 가능하다. 최근에는 네이버 애널리틱스(analytics.naver.com)도 다양한 통계 데이터 분석 기능을 제공하면서 국내 사용자에게 좋은 호응을 얻고 있다. 

무료 서비스는 제약사항이나 한계가 있으므로 통계기능에 대한 요구사항을 명확히 파악하여 활용가능여부를 명확히 판단하여 도입여부에 대한 의사결정을 받아야만 한다. 프로젝트 개발 말미에 통계기능에 대한 이슈가 발생하면 기대이상의 리스크를 만나게 될 것이다.

6. 인프라 환경 분석

인프라 환경은 시스템 하드웨어와 같은 물리적 인프라와 수행/운영TF의 업무능력과 스킬 보유현황 등의 논리적 인프라를 포함하여, AS-IS에서의 온/오프라인의 비즈니스 로직과 운영 프로세스, 수행TF가 적절한 수행장소에서 업무에 집중할 수 있도록 파견장소에 대한 업무환경 파악까지를 의미한다. 그래서 인프라 환경분석은 전반적으로 수행PM이 진행하여 기획팀에서 분석된 인사이트 중 인프라 환경에 제약사항이 될만한 요소는 별도 체크하여 대안이 마련될 수 있도록 한다.

인프라 환경에 대한 분석 내용은 크게 3가지로 정리해 보고자 한다.

1) 시스템 환경

개발언어(language), 프레임워크(framework), 데이터베이스서버(database server), 웹서버(web server), WAS(web application server)의 기본적인 물리적 구조도와 각 소프트웨어의 버전 등을 확인하여 AS-IS의 상황과 TO-BE에서 개선될 사항을 파악한다. 시스템 환경 분석은 개발PL과 현업 전산담당자와 함께 진행해야 하며, 기술적인 업무협조 사항에 대한 조율이 원활히 이루질 수 있도록 서로간의 R&R을 함께 정리하는 것도 중요한 사항이다.

이외에도 금융권처럼 기간계 시스템(Legacy로 불림)이 존재한다면 웹서비스와 인터페이스(Interface) 방법에 대한 확인이 필요하며 보안정책 및 사용중인 솔루션과 외부 API에 대한 정보를 파악한다. 언급된 개발관련 용어들은 별도의 설명을 하지 않겠다. 모르는 용어가 있으면 반드시 본인이 이해가 가능범위까지 검색을 통해서 정보를 인지할 수 있도록 한다. 사전적인 의미를 파악하고 프로그램 개발자에게 직접 설명을 듣길 권한다.

2) 수행/운영TFT

수행TF와 현업담당자의 인력구성에 대한 조직도 작성은 위에서 언급한 바가 있다. 의사결정을 위한 프로세스와 대략의 소유예상 일정과 의사결정과정에서 리스크가 발생할 요인에 대한 파악, 컨소시엄의 형태로 프로젝트 수행TF가 구성되었다면 R&R(Role&Responsibility)정의 뿐만 아니라, 현업담당자와 협업해야 하는 부분에 대해서도 R&R을 정리해야 한다. 

실제 프로젝트 수행 중에 미스커뮤니케이션이 많이 발생하는 부분이 현업담당자와 협업과정에서 R&R정리가 되지 않아 서로의 과업범위로 인지하고 업무진행을 하다가 누락하는 경우이다. 수행/현업TF는 효율적인 프로젝트 관리를 위해서 그리고 업무를 진행하는 본인을 위해서라도 명확히 정리를 하고 진행해야만 한다. 그리고 이후에 수행/현업TF 간에 커뮤니케이션 채널은 어떻게 유지해야 하며 공유의 대상과 범위에 대한 협의도 되어야 한다.

이러한 수행과정에 대한 환경분석도 중요하지만 놓치지 말아야 할 것이 운영에 관련된 파악이다. 운영업무 프로세스, 운영인력구성 및 업무스킬은 사전에 파악을 해두는 것이 좋다. TO-BE의 웹사이트를 운영함에 있어 현재의 운영 프로세스에서 문제가 없을지나 운영관리 이슈가 다소 발생할 여지가 있다면 현재 인력으로 충분히 가능할지에 대한 의견을 현업PM에게 전달하여 사전에 리스크가 될만한 사항에 대해서 공유해야 한다. 만들기만 한다고 다 되는 것이 아니다.

“리스크를 가장 줄이는 것도 커뮤니케이션이지만, 

가장 큰 리스크가 발생하는 것도 커뮤니케이션이다.”

3) 업무 환경

보통 파견지로 이동하여 현업TF와 함께 프로젝트를 수행하는 경우가 많으므로, 수행PM과 영업팀에서는 파견지 이동 전에 수행TF의 업무장소에 대한 환경파악이 필요하다.

수행TF와 현업TF의 자리배치현황부터 네트워크 준비상황, 개인/공용 업무장비현황, 프로젝트 보안정책현황, 출퇴근 시간 및 규제사항, 인트라넷 계정정보 등 본사를 떠나 외부 파견장소에서 현업TF와 함께 하는 업무환경은 아무리 편한 사이가 된다고 해도 심리적으로 불편하기 마련이다. 업무환경에 대한 개선책 마련은 수행TF들이 최적의 환경에서 프로젝트에 집중할 수 있도록 환경을 마련하자는데 의미가 있으므로 수행PM의 적극적인 노력이 필요할 것이다.

일부 PM들은 이러한 저자의 생각이 불필요한 행동이라고 피드백을 하는 경우도 있다. PM은 프로젝트를 관리하는 사람이다. 프로젝트에는 계획/분석/설계/개발/검수의 과정과 산출물만 있는 것이 아니다. 그 이전에 그것들을 만드는 수행TF와 협업하는 현업TF가 있다. HR(Human Resource)관리야 말로 수행PM과 PL이 놓치지 말고 수행해야만 한다. 프로젝트 도중에 TF인력 이탈이야 말로 제일 큰 리스크 중에 하나일 것이다.