쉽지만은 않은 사이트 기획

어느 기획이나 처음에는 만들려고 하는 사람의 생각이 필요하다. 아이디어만 공유한다고 해서 무엇을 만들고 싶은지 다 아는 것은 아니다. 개인마다 생각하는 방향이 틀리기에 얼마나 세세하게 생각을 공유하느냐에 따라 기획의 성패가 좌우된다. 지레짐작으로 생각해서는 안된다. 또한 생각을 공유하는 과정에서는 상식이라는 개념을 생각해서도 안된다. 

 

생각을 공유하는 과정에서는 많은 대화가 필요하다. 이를 문서화 하는 것 또한 중요하다. 문서화 하지 않으면 나중에 오해의 요지가 생길 수도 있다. 기획자는 PPT로 단순히 기획서를 작성하는 사람이 아니다. 혼자서 컴퓨터에 앉아 모니터와 눈싸움을 한다고 기획이 나오는 것도 아니다. 또한 내 생각만으로 기획을 하는 것은 결코 아니다. 

 

기획자는 회의를 진행하고 인터뷰를 통해서 상대방의 생각을 끌어내고, 문서화 시킬 수 있는 사람이어야 한다. 

---

인터뷰, 회의를 통해 무엇을 어떻게 만들지 정리된 문서를 요구사항 정의서라고 부른다. 요구사항 정의서는 별도의 양식은 없다. 대부분 엑셀로 작성하며, 요구사항ID, 구분, 요구사항, 설명, 비고 등으로 필요한 항목을 기재하여 작성한다. 프로젝트의 방향을 잡는 중요한 문서로 기준이 되는 문서이다. 기획자는 화면만 잘 기획한다고 잘하는 것이 아니고, 고객(발주사)의 생각과 원하는 것을 정확히 파악하고 정리하는 것이 중요하다. 정리가 안되면 이후 개발 진행도 정리가 안되고, 수 많은 수정과 난관이 기다리고 있다. 이런 프로젝트는 일찌감치 발을 빼는게 정신건강에 이롭다.

---

요구사항 정의서가 완료되었다면 이 문서를 기준으로 화면을 설계, 기획한다. 모든 화면별로 기획이 되어야 한다. 그냥 단순히 게시판이라고 할지라도, 화면설계는 있어야 한다. 화면설계가 되어있지 않은 페이지는 개발 자체가 되지 않는다. 디자이너나 개발자나 화면설계를 기준으로 만들기 때문이다. 기획자가 그냥 텍스트만 있는 화면이라서 화면 설계를 하지 않았다고 하더라도, 없기 때문에 없는 것으로 알고 진행된다. 

 

이런 화면설계 문서를 화면설계서 또는 스토리보드(StoryBoard)라고 부른다. 영화나 광고, 애니메이션등의 스토리보드와 같다. 영화나 애니메이션의 스토리보드(콘티)는 장면별로 카메라 앵글, 대사, 배우의 연기, 음향등을 작성한 문서이다. 스토리보드를 기준으로 촬영이나, 배우, 음향 등이 제작된다. 

 

웹도 마찬가지로 스토리보드에는 화면별로 글자, 버튼, 이미지등의 위치와 버튼을 클릭했을때 액션, 이미지의 슬라이딩, 페이지가 열릴 경우 초기 데이터 등을 기술한다. 앱의 경우에는 화면을 터치하여 스크롤 했을때, 화면을 오래도록 누르고 있을 경우 등에 대해서도 기술해야한다.

 

모든 개발의 기준이 스토리보드를 통해 진행되기 때문에 웹이나 앱의 모든 화면과 액션 등을 빠짐없이 기술해야한다. 기술이 되어 있지 않은 기능은 역시나 개발에서 제외 된다. 다 아는 기능이겠지라고 생각해서는 안된다. 기술되어 있는 내용 그대로 디자인이나 개발이 되기 때문에 나중에 당연한 기능이라서 작성하지 않았다고 해도 변명이 되지 않는다. 

---

스토리보드는 대부분 PPT로 작성되며, PDF로 작성하기도 한다. 기획자의 취향에 맞게 작성된다. 다만, 양식은 존재하지만, 기업체마다 다르다. 특히나 대기업 프로젝트의 경우 해당 기업의 스토리보드 양식이 있기때문에 양식에 맞추어 작성한다. 양식이 다르다고 해도, 기본적으로 상단은 화면 개요(아이디, 작성자, 작성일, 화면이름 등)을 기입하고 왼쪽 화면은 설계된 화면, 오른쪽은 화면에 대한 설명을 작성한다.

 

경험이 많은 기획자, 개발을 아는 기획자 경우에는 추가적으로 기능 흐름에 대한 대략적인 플로우차트도 작성하는 경우가 있다. 플로우 차트까지 있으면 개발자들이 좀 더 쉽게 개발을 할 수 있다. 플로우차트라고 해서 개발에 사용되는 세세하고, 복잡한 것보다는 전체 흐름 관점에서 작성한다.  

 

스토리보드에는 각 화면 설계와 플로우차트 그리고 메시지 리스트를 기록한다. 메시지는 경고(Alert) 메시지, sms문자 메시지, 카카오 알림톡 메시지와 같은 문구도 작성해야한다. 문구 하나 하나를 허투루 생각해서는 안된다. 단어 하나 틀렸다고 고객에게 클레임이 들어오는 경우도 있다. 또한 성의 또는 예의 없는 문구는 사이트의 질을 떨어뜨린다. 사이트의 컨셉에 맞게 문구도 다르게 표현된다. 사이트는 아기자기하게 귀여운데, 문구는 중년처럼 무거운 메시지를 발산하면 컨셉자체가 흔들린다. 반대로 중후하고 무거운 사이트인데, 아기자기한 메시지가 노출되면 일본 만화에서 가끔씩 나오는 세일러복 입은 중년 아저씨같은 느낌이 든다.

---

요구사항 정의서와 이를 기준으로 화면와 전체 흐름을 작성하는 스토리보드까지 완성되었다고 기획이 끝나는 것은 아니다. 

 

기획은 사이트의 처음과 끝을 책임지는 업무이다.

 

스토리보드를 기준으로 개발이 완료되면 테스트할 수 있는 문서가 필요하다. 이것을 테스트 시나리오(Test Scenario)라고 부른다. 테스트 시니리오는 화면별로 어떻게 테스트를 해야하는지와 결과가 어떻게 나와야 하는지에 대한 가이드이다. 테스트 시나리오를 개발자나 PM, PL이 작성하게 되면 안되어 있는 기능을 은근슬쩍 뺄 수도 있고, 전체 흐름을 알지만, 세세한 부분은 기획자 만큼 모르기 때문에 놓칠 수도 있다. 

 

테스트 시나리오가 없으면, QA 테스트 인력들이 어떻게 테스트를 해야하는지 헤맬 수 있다. 또는  무작위로 테스트 하고 자신이 생각하는대로 오류라고 던질 수도 있다. 이렇게 되면 개발자와 테스트 인력간 다툼과 스트레스 지수가 올라가는 일은 자명하다. 

 

테스트 시나리오는 사이트를 사용하는 가이드 역할을 한다. 예상하는대로 테스트 시나리오를 작성하는 일이 제일 귀잖다. 스토리보드에서도 화면에서 버튼이나 문구, UX등을 생각하면서 이리저리 옮기고 지우고 추가하는 일은 재미있지만, 화면 요소에 대한 설명 문구를 작성하는 일은 제일 귀찮은 작업이다. 뭔가 단순 노동같은 업무라 지루하고, 재미없고, 귀찮은 일이다. 대부분은 아니지만, 신입 기획자에게 할당하는 경우도 있다. 개인적인 생각으로는 신입 기획자가 경험이 많은 기획자가 작성한 스토리보드 화면을 보고 설명 문구를 달고, 테스트 시나리오를 작성하는 업무를 하다보면 오히려 좀 더 빨리 기획에 눈을 뜰 수 있지 않을까 생각한다.

 

힘들게 테스트 시나리오까지 작성을 완료하고 털어버리고, 프로젝트에서 철수 한다면 속 시원하겠지만, 실제 테스트시에 변경 사항이 나올 수도 있고, QA 테스트 인력이 이해를 못할 수도 있기 때문에 테스트시에는 테스트된 문서에 대응해야한다. 명백한 오류이면 개발자를 추긍하고, 테스트가 잘 못 됐다면, 테스트 인력을 가이드해야한다. 한마디로, 프로젝트가 끝날때까지는 어디도 못 간다는 의미이다. 간혹, 테스트 시나리오까지 작성하고 미리 QA 테스트 인력에게 교육 후 철수하는 경우도 있지만, 지금까지 테스트가 원활히 진행된 적은 없었다. 

---

테스트 시나리오를 작성하고, 교육하고, 대응했다면 이걸로 끝나면 얼마나 좋을까마는 한가지 더 남은게 있다. 테스트 시나리오는 각 화면에 대한 테스트 가이드와 결과가 기재되어있다. 실제 고객들이 사이트를 이용하면서 화면 하나 하나만 보는 것이 아니다. 요즘은 한 페이지 사이트가 대세이긴 하지만, 기존 다수의 페이지에서 한 페이지의 스크롤 방식으로 기본적으로 페이지 단위가 스크롤 단위로 전환됐을 뿐이다. 

 

고객은 화면 페이지 하나 하나에 별로 관심이 없다. 그런데 테스트 시나리오는 페이지 하나 하나에 큰 의미를 둔다. 서로간에 괴리가 있다. 물론 고객이 페이지 하나 하나에 관심이 없더라도, 문구가 틀리거나 오류가 발생하면 바로 알아차린다. 고객은 사이트 흐름에 더 관심을 가진다. 원하는 페이지로 바로 갈 수 있어야 하고, 페이지로 넘어 갔을때 기대했던 결과가 나와야 한다. 또는 기대하지 않았던 더 나은 결과가 나올 수도 있고, 새로운 경험을 체험할 수도 있다. 

 

이런 흐름에 대한 기대와 더 좋은 체험을 생각하고 기획하는 분야가 UX(User Experience) 분야이다. 

 

아주 좋은 UX까지는 아니더라도, 고객이 기대한 결과는 제대로 나와야 한다. 이것 또한 테스트시에 고객이 어떻게 행동하느냐에 따라 거기에 대한 결과를 미리 예상하고 오류를 잡아낼 수 있는 가이드가 있어야 한다. 이런 가이드를 테스트 케이스(Test Case)라고 한다. 또한 최초 요구사항에 맞게 여러가지 다양한 조건에 대한 결과도 테스트 케이스에 포함된다.

 

테스트 케이스는 흐름에 대한 테스트 가이드이다. 고객이 어떠한 행동을 할지 모르기 때문에 생각할 수 있는 모든 케이스를 생각하고, 해당 케이스가 발생했을 때 어떤 결과 화면이 나와야 하는지 작성하고 테스트해야한다. 

 

일반 단순한 페이지까지 테스트 케이스를 만들 필요는 없지만, 중요한 기능에 대해서는 반드시 있어야 한다. 고객은 착하게 가이드대로 하지 않기 때문이다. 고객은 가이드를 모른다. 그냥 버튼이 있으면 클릭하는 거고, 순서는 생각하지도 않는다. 순서나 가이드를 강요하는 사이트는 고객에게 책임을 전가시키는 나쁜 사이트다. 순서대로 하지 않아도 고객이 원하는 결과를 얻을 수 있는 사이트가 좋은 사이트이다. 이런 좋은 사이트가 되기 위해서는 테스트 케이스가 많아야 하고, 많은 테스트를 해야한다. 

 

기획은 단순히 초반에 기획만 하고 사라지는 업무가 아니다.
아이의 탄생 과정을 책임지는 부모와 같은 위치이다.

---