[창업이야기] 12. 티저페이지, 테스트
티저 페이지
2010년 12월, 기능 구현이 거의 다 끝나고 테스트 단계로 접어들 무렵 우리는 마케팅에 대해 생각하기 시작했다. 기획과 개발, 디자인을 넘어 마케팅까지 모두 경험해 볼 수 있다는 것은 스타트업에서 일하는 것의 장점 중 하나이다. 어떤 사람에게는 이런 점이 단점일 수도 있지만, 다양한 것에 관심이 있는 나에게 이 점은 장점이었다. 우리 회사는 그때까지 출시된 제품이 하나도 없는 이름 없는 회사였기 때문에 사람들의 관심을 유도할 만한 신선한 방법을 찾아야 했다. 어떻게 마케팅을 할까 고민하다 팀 내에서 “티저 페이지를 하나 만들면 어떨까?”라는 이야기가 나왔다. 그 즉시 디자인의 마술사 션이 초안을 만들었고, 그 안에 대화 내용은 렌스가 채워 넣었다. 이후 팀원의 의견을 수렴하여 세세한 부분을 수정해 최종적으로 티저 페이지를 완성했다.
[티저 페이지 내용]
남자 1 : 이것 봐! 우리가 해냈어!
(첫 번째 해석 가능한 뜻)
남자 2 : 훌륭해! 이제 더 이상 아이패드에서 블로깅을 방해 없이 사용할 수 있을 거야!
남자 1 : 아니, 그럴지도? (이 대답은 말이 안 된다. 그러므로 두 번째 뜻으로 해석해야 함.)
(두 번째 해석 가능한 뜻)
남자 2 : 훌륭해! 이제 더 이상 아이패드에서 블로깅할때 드래그는 안 할 거야!
남자 1 : 아니, 그럴지도?
이 티저 페이지는 Blogsy의 핵심 기능(드래그&드롭을 사용해 미디어 콘텐츠를 포스트에 쉽게 첨부할 수 있는 점)에 대한 힌트가 내포되어 있었고, 중의적인 뜻이 있는 Drag(끌어내다, 방해하다)라는 단어를 사용해 수수께끼 같은 문장을 만들어 사람들이 호기심을 갖도록 유도했다. 이 앱에 호기심이 있는 사용자는 자신의 이메일 주소를 등록함으로써 나중에 앱이 출시되었을 때 그 소식을 알 수 있도록 했다. Blogsy의 트위터와 페이스북 계정으로 퍼뜨린 이 티저 페이지에 제법 많은 사람이 관심을 표현했고, 우리도 그 관심 덕분에 예상보다 훨씬 길었던 마무리 과정을 힘내서 진행할 수 있었다. 우리는 이 티저 페이지를 Blogsy의 출시가 2개월 정도 남았다고 판단했던 시점에 사람들에게 공개했다. 그 이유는 사람들이 이 티저 페이지를 보고 난 후 호기심이 유지될 만한 기간이 최대 2개월이라고 생각했기 때문에다. 하지만 실제로 Blogsy의 출시는 티저 페이지가 공개된 시점으로부터 4개월 후에야 가능했다.
테스트
2011년 3월, 션과 나는 비록 생각보다 시간이 더 걸리긴 했지만, 각자 맡은 부분의 구현을 모두 끝냈다. 그 당시 데이브는 자신이 맡은 부분의 구현을 다 끝내지 못한 상황이었는데, 나와 션이 기능 구현을 끝내고 나니 데이브는 자신이 맡은 부분 때문에 전체적인 프로젝트 일정이 지연되는 것을 피하고자 더욱 분발해서 일했다. 그래서 데이브 쪽 일이 이전 보다 활발하게 진행되기 시작했는데, 데이브가 맡은 코드가 완성되지 않아 처리할 수 없었던 데이브 코드에 의존적이었던 부분을 션이 맡아서 데이브와 함께 일을 했다. 그동안 나는 테스트를 하기로 했다. 전에 이야기했듯이 나는 코드를 그렇게 잘 작성하지는 못하지만 그래도 지루해 보이는 것을 인내하면서 관찰하는 일은 잘한다. 하지만 그런 성향을 갖고 있는 나에게도 테스트는 지루하고 재미없는 일이었다.
테스트를 해야 하는데, 어떻게 해야 하는지 정보가 하나도 없었다. 상용 프로그램 개발 자체가 그때가 처음이라 테스트도 처음이었다. 인터넷을 통해 테스트 관련 논문이나 방법론 등을 한동안 검색해 보았지만, 뾰족한 방법을 찾을 수 없었다. 그래서 ‘그래 없으면 내가 한번 만들어 보자. 어차피 구현한 게 우리니깐 어떻게 테스트해야 할지는 우리가 가장 잘 알고 있겠지’라는 생각으로 테스트를 어떻게 진행할지 내 머릿속에서 방법을 생각해내기 시작했다. 이런 생각은 스타트업에서 일하면서 갖게 된 마인드 중의 하나이다. 정답이 없는 문제를 두려워하거나 어려워하지 않고, 가진 모든 경험과 지식을 동원해 방법을 찾는 것이다.
나는 크게 3가지로 테스트 종류를 나눴다.
1. 기능 테스트 : 각 기능이 의도한 대로 동작을 하는지 확인
2. 통합 테스트 : 여러 기능을 사용 예상 시나리오 대로 테스트를 해서 기능이 올바로 동작하는지 확인
3. 강도 테스트 : 특정 기능을 여러 번 실행시켜서 이에 따른 오류나 메모리 누수가 없는지 확인
테스트를 하면서 발견한 문제는 바로 수정하기보다 테스트 문서의 해당 항목 아래에 빨간색 글씨로 어떤 문제인지 표시해놓고 일단 다른 항목의 테스트로 넘어갔다. 테스트가 성공적으로 완료된 항목은 선을 그어서 지워나갔다. 이렇게 처음부터 끝까지 진행한 후, 발견한 모든 문제에 대해서 하나하나 수정했다. 이 과정을 문제가 발견되지 않을 때까지 반복했고, 그때가 돼서야 비로소 내부 테스트를 완료할 수 있었다.
내부 테스트를 완료 후 베타 테스트를 실시했다. 베타 테스트에는 TestFlight이라는 서비스를 사용했는데, 이 서비스는 iOS용 앱의 베타 테스트를 쉽게 할 수 있도록 도와주는 서비스이다. (이 회사는 2014년 2월 애플에 인수된다.)
홈페이지와 트위터를 통해 베타 테스터를 모집했는데, 꽤 많은 사람이 테스터로 등록했다. 테스터에게 Blogsy 0.9.8 버전을 최초로 배포했다. 배포할 때 어떤 부분을 테스트해줬으면 좋겠다고 명시를 했지만, 생각만큼 실제 도움은 별로 되지 않았다. 왜냐면 테스터들은 호기심 수준에서 사용을 해보는 정도였고, 피드백도 생각만큼 많이 주지 않았다. 몇몇 충성도 있는 사용자가 어느 정도 피드백을 주는 수준이었다. 또 고용관계가 아니라 이 기능 좀 테스트해봐 달라고 개별적으로 부탁하기도 어려웠다. 그래서 실제 테스트는 이 단계에서도 우리 내부에서 많이 이루어졌다. 베타 버전 베포 후에도 많은 버그가 발견되어 여러 버그를 수정해야 했다. 그 이유는 역시 웹뷰를 수정해서 에디터로 사용했던 부분이 컸고, 여러 서비스를 연동해서 사용하기 때문에 각각의 서비스의 예외상황에 대한 처리가 필요했다. 최초 배포 버전인 1.0으로 금방 넘어갈 수 있을 줄 알았던 0.9.8 버전은 0.9.9 버전을 거쳐 0.9.9.10등으로 이어지며 1.0에 쉽게 도달하지 못했다.
한 명의 생명을 출산하는 것 같이 최초 버전을 출시하는 데까지는 마지막까지 많은 수고가 뒤따랐다. 이런저런 문제들을 다 해결한 후 안정적이라 생각이든 후에야 1.0 버전을 완성할 수 있었다. 그 당시 안정적이었다고 생각한 부분은 나중에 그게 아니었음이 밝혀지게 된다. 너무도 많은 버그를 수정하느라 정신없던 그 이야기는 나중에 뒤에서 다룰 생각이다.
