지난 연말에 신규 서비스를 위한 기획회의에 참석한 직후에 적고 싶었던 글입니다. 어떻게 하면 사용자들을 만족시키는 좋은 서비스를 만들 수 있을까?에 대한 글을 적고 싶었습니다. 너무 당연한 일반론이지만 정리해두면 좋을 것같다는 생각을 했습니다. 당시에는 처음부터 제대로된 컨셉/기획안을 만들어서 빈틈없는 개발을 하거나 빠르게 개발하고 사용자들의 반응에 맞춰서 빠르게 수정보완하는 것에 대한 설명을 적을 예정이었습니다. 그런데 이 한문장이외에 덧붙일 내용도 없었기에 그냥 글을 적지 않기로 했습니다. 그런데 최근 몇 가지 더 생각나서 글을 완성시켜야겠다고 마음먹었습니다. 새로운 방법론이라기보다는 앞서 말한 기획중심의 개발과 개발중심의 기획을 확장/변형한 방법론입니다.
성공하는 서비스를 만들기 위해서 어떻게 해야할까요? 기획 또는 개발을 '설계'라는 용어로 아울러서 말하겠습니다.
기획중심의 설계.
가장 먼저 떠오르는 생각은 시대의 트렌드와 사용자들의 니즈를 잘 파악해서 그 트렌드와 니즈를 파고드는 서비스의 컨셉을 정하고, 그 컨셉에 충실한 완벽한 서비스를 기획한다는 것입니다. 완벽한 기획이라는 것이 그 기획대로만 개발하면 무조건 성공할 수 밖에 없는 것입니다. 현실적으로 불가능한 얘기같지만, 말그대로 기획이 완벽했다면 개발 및 운영에 문제가 발생할 수가 없습니다. 보통의 기획서가 완벽하지 않기 때문에 문제인 것입니다. 실패하는 많은 기획서를 보면 대충 리소스를 산정해서 서비스 개발에 대략 10주 걸리고, 테스트하는데 2주면 되기 때문에 3달 후에는 서비스를 런칭할 수 있다 식으로 계획을 세웁니다. 그런데 실제 개발에 착수하면 예기치 못했던 문제들이 발생하고 리소스는 늘 부족하고 개발기간은 늘 촉박하고 그래서 대강 나온 서비스를 제대로 테스트도 하지 않고 런칭을 합니다. 그러면 런칭 직후부터 문제가 터지기 시작하고 초기의 버그는 사용자들을 떠나게 만듭니다. 요즘처럼 대체제가 많은 시기에는 그런 초기의 서비스 불만은 치명적입니다. 우리가 접하는 많은 서비스들은 기획에서부터 시작한 것들이 많습니다. 예전에는 대체제가 없었기 때문에 사용자들이 기다려줬고, 그래서 현재는 나름 성공/정착한 서비스들이 많습니다. 그러나 최근에는 기획에서 시작한 서비스들이 제대로 성공하는 경우를 못 봤습니다. 완벽하지 못했기 때문입니다. 완벽한 기획안을 못 만들면서도 우리는 늘 관념적으로만 이런거 좋겠지?라고 생각하고 불완전한 기획에서 개발에 들어가고 서비스를 런칭하고 그래서 실패하고 맙니다. 다시 말하지만 기획이 완벽하면 서비스는 성공합니다. 제품의 개발주기가 몇년씩 걸리는 산업에서는 여전히 유효합니다.
개발중심의 설계.
두번째로 떠오른 생각은 적당한 감을 가지고 초기 서비스를 만들어보고 일부 사용자들에게 테스트를 받아보고 보완해서 어느 정도 수준에 오른 서비스를 런칭하는 것입니다. 어느 누군가가 이런 기능/서비스가 필요해라고 말하면 그걸 바로 구현해서 적용해보고 사용자들이 꾸준히 사용하면 기능을 더 개선하고 그렇지 않으면 완전히 없애거나 처음부터 다시 디자인/구현해서 런칭을 하는 것입니다. 구글의 성공 이후에 영원한 베타라는 말이 생겼습니다. 지금 가장 많이 사용하는 Gmail도 초기 몇년동안은 계속 Beta 표시를 달고 서비스가 되었습니다. 일반 사용자들은 그냥 괜찮게 사용하고 있었지만 그래도 계속 베타 마크를 붙이고 서비스했습니다. 알파, 베타 마크가 사용자들에게 문제가 발생할 수 있으니 이해해주세요라는 그런 무언의 압력이기도 하지만, 사용자들의 반응을 보고 꾸준히 개선해나갈께요라는 그런 의지의 표현이기도 했습니다. 기획중심의 설계가 완벽한 기획이 필요했다면, 개발중심의 설계에서는 빠른 구현 및 꾸준한 모니터링이 필요합니다. 극단적으로 몇 시간에서 며칠내로 초기 버전이 구현되지 못하면 또는 초기 반응이 시큰둥하면 바로 접을 수 있어야 합니다. 긍정 또는 부정적인 사용자들의 (명시적/암묵적) 피드백을 얼마나 빨리 많이 수집해서, 그것들을 얼마나 빨리 수정/개선해서 차기 버전으로 만들어내느냐가 성공의 관건입니다. 초기 서비스에 버그가 있었지만 사용자들이 완전히 실망하기도 전에 며칠 또는 몇 시간 내에 문제가 해결되는 것을 보여준다면, 아무리 초기에 치명적인 결함이 있더라도 사용자들은 그 문제가 며칠 내에 해결될거다라는 기대감을 가지게 됩니다. 그래고 나의 피드백이 바로 반영이 되는구나라는 것을 느낀 사용자는 해당 서비스의 열혈 사용자가 될 가능성도 더 높습니다. 적당히 좋은 아이디어/컨셉을 빠르게 구현해서 적용해보면서 가능성이 없으면 초기 비용이 별로 안 들었을 때 바로 접으면 그만이고, 가능성이 있으면 더 많은 리소스를 투입해서 더 나은 서비스로 발전시켜나가면 됩니다.
데이터중심의 설계.
세번째 방법은 기획과 개발의 중간 쯤에 위치하면서 개발중심의 변형입니다. 새로운 서비스를 기획, 구현하기에 앞서서 현존하는 데이터들을 모으고 분석하는 것입니다. 예를들어 검색엔진에서 어느날 갑자기 특정 패턴의 검색어들이 많이 유입된다면 그런 패턴어를 처리해줄 수 있는 검색서비스를 만들어서 제공해주는 것입니다. 다음이나 네이버에서 영화, TV프로그램, 인물 등의 다채로운 정보가 검색에서 스페셜로 노출되는 것도 그런 종류의 검색어들이 상시적으로 많다는 것을 관찰/분석한 이후에 만들어진 것입니다. (간혹 경쟁사에서 서비스를 오픈해서 따라하는 경우도 있지만.. 이런 경우 기획중심의 설계로 들어가는 경우가 많음.) 아니면 트위터에서 오프라인 번개에 대한 니즈가 급증하는 것을 관찰했다면 트위터와 매끄럽게 연계된 번개서비스를 만드는 것입니다. 트위터의 초기에 트위터를 둘러싼 수많은 독립 서비스들이 개발되어 트위터에코를 만들었던 것을 생각하면 됩니다. 데이터중심의 설계는 신규서비스의 설계에 국한한 것이 아니라, 이미 런칭한 서비스의 개선에 더 큰 역할을 합니다. A/B 테스트로 알려졌듯이 새로운 기능이 사용자들에게 좋은 평가를 얻는지 확인하기 위해서 기존 기능과 신규 기능 사이의 버킷테스틀르 통해서 새로운 서비스에서 사용성이 더 좋으면 새로운 기능으로 대체하는 방법을 취합니다. 데이터중심의 설계는 개발중심의 설계와 밀접하게 커플링되어있습니다.
경험중심의 설계.
네번째는 기획중심의 설계의 변형이지만, 근본적인 차이점은 관념과 실제에 있습니다. 기획중심에서는 그냥 주변의 트렌드나 설문조사 등에서 나타난 이야기를 바탕으로 새로운 서비스를 기획하는 것이라면, 경험중심에서는 나 자신이 실제 사용자가 되어서 그 속에서 느꼈던 불편한 점들을 모아서 그것들을 극볼할 서비스를 만드는 것입니다. 때로는 기존 서비스에 만족하지 못해서 대체제/경쟁제를 만드는 것도 가능합니다. 작년 말에 사내외에 다양한 페스티벌을 만들어보고 싶다는 글을 적었었는데, 그 속에는 기본적으로 그런 페스티벌을 기획하고 운영해보면서 스스로 불편함도 느껴보고 또 사용자들의 행동을 가까이에서 관찰해보고 그들의 불편을 해소할 방법을 찾아보고 그걸 서비스화시켜보고 싶다는 것을 염두에 둔 생각이었습니다. 내가 직접 여행을 해보면서 불편한 점이나 좋았던 점 등을 경험해보지 않고, 관념적으로만 이런 게 필요할 것같고 이런 건 ROI가 안 나올 것같고 등과 같은 관념으로만 서비스를 기획하고 만들다보면 결국 리소스는 많이 투입했는데 결과는 좋지 못한 그런 경우가 빈번히 발생합니다. 실생활에서 참가해서 경험해보지 않고서는 어떤 서비스가 진짜 필요한지 이해할 수가 없습니다. 인터넷 기업을 다니는 사람들을 주변에서 관찰해보면 그들이 인터넷과 너무 동떨어져서 생활하는 경우를 자주 봅니다. 생활에서는 인터넷/모바일 서비스를 전혀 이용하지 않으면서 새로운 인터넷/모바일 서비스를 기획/개발하는 경우를 종종 봅니다. 그런 사람들에게서 제대로된 것이 나올 수 있을지 의문입니다.
이상으로 네가지로 나누어서 서비스 개발방법론이라고 거창하게 적었지만, 뭔니뭐니해도 오늘날 가장 중요한 것은 래피드프로토타이핑 rapid-prototyping입니다. 빨리 구현해서 테스트해보는 것이 가장 필요합니다. 기획중심의 설계에서도 기획단계에서부터 이런저런 기능을 테스트해보고 실제 데이터를 보면서 파이널 제품으로 갈 것인지 말 것인지를 결정해야 합니다. 실제 서비스의 프로토타입이나 데이터를 보지도 않고 무조건 위에서 시킨 업무라고해서 끝까지 기획서만 만드느라 많은 시간을 허비해버리고 정작 기획서가 나왔을 때는 이미 트렌드는 끝나가거서 유사제품들이 시장에 넘쳐나는 경우를 종종 봅니다. 특히 이미 성공한 제품/서비스를 가진 기업들일 수록, 후속 서비스에 대한 (대박) 압박 때문에 이런 오류를 자주 보입니다. 그럴수록 초기 단계에서부터 테스트 및 분석을 거치면서 큰 그림을 완성해야 합니다. 확고한 (초기) 컨셉이 정해졌다면, 작게 생각하고 빠르게 만들어서 사용자들의 반응을 관찰/분석해서 좀더 강건한 서비스를 기획/개발하는 것이 정석입니다. 애플에서 매킨토시를 처음 만들 때 케이스만 수십가지/차례 만들었다는 전설적인 이야기, 새로운 애플 제품은 적어도 100가지 디자인 중에 하나가 선택된다는 이야기, 페이스북에서 Q&A기능을 넣었다가 사용자 반응이 미비해서 그냥 빼버린 사례, 그리고 앞서 말했던 구글의 영원한 베타전략 및 A/B테스트에서 교훈을 얻어야 합니다.
대학에서 품질공학 수업을 들으면서 초기 기획/설계 단계에서 오랜 시간을 보내면 최종 제품 개발에서 실패가 적다는 것을 정석으로 가르쳐주고 있습니다. 실물 경제에서는 초기 디자인 단계에서 많은 것들이 검토되면 뒤쪽의 생산 단계에서 문제가 적게 발생한다는 얘기입니다. 몇 년의 준비과정이 필요한 제품의 경우에는 맞는 말이지만 인터넷/모바일 서비스처럼 몇 개월 또는 수주 내에 서비스의 승패를 결정하는 분야에서는 재고되어야할 내용입니다. 그리고 기획/설계 단계에 많은 것들을 점검하고 긴 회의를 거치더라도 앞서 말했듯이 꾸준한 프로토타이핑 및 테스트를 거치지 않으면 완벽한 서비스가 그냥 좋은 서비스에 밀려나고 맙니다. 그리고, 3~6개월만 개발이 지연되어도 트렌드에서 벗어나는 경우도 있지만, 6개월 ~ 1년 이상의 장기적인 마일스톤을 세워두고 꾸준히 개발/개선해야할 서비스나 기반기술들도 있습니다. 양자 모두에서 빠른 프로토타이핑과 테스트는 여전히 필수/유효합니다.
결론적으로 말하자면 현실에서는 다양한 경험에서 서비스 아이디어를 얻고 빨리 구현해서 데이터로 검증을 받아서 새로운 서비스를 만드는 것이 정도가 아닐까 생각합니다. 아이디어만으론 절대 성공할 수 없습니다. 어린 친구들에게 좋은 아이템이 있으면 창업해보라고 부채질을 하지만, 기본적으로 그들이 가진 재능과 패기를 바탕으로 조언하는 것이지 능력이 없는 이들에게는 그런 조언도 해주지 않습니다.
지나치게 일반적인 내용을 너무 길게 적었습니다. 앞서 '정석'이라는 표현도 사용했지만, 실제 성공하는 서비스의 왕도는 없습니다. 각 기업/조직의 문화에 따라서 더 적합한 방식이 따로 있습니다. 일반론에 함몰되지는 말았으면 합니다.
PS. 웃픈 글이 있어서 링크를 겁니다. 게임업계인에게 직접 듣는 게임업계의 슬픈 현실. 대화내용에서 카툰 아래에 나오는 '기획자가 필요없다'는 대목이 최근 IT업계의 현주소입니다.
(2013.01.14 작성 / 2013.01.21 공개)