SST3

Fast Company에 실린 10 Web 2.0 Ideas that Failed를 읽고.

이 기사는 큰 성공을 거둔 회사와는 달리 일찌기 문을 닫게 된 웹2.0 회사들이 운영했던 서비스를 설명하고, 그들이 실패한 이유를 한줄로 요약했다. 각 서비스에 대한 설명을 옮길 수는 없고, 실패사례를 통해서 무엇을 배울 수 있는지 되새겨 볼 필요가 있겠다.

• RSS Calendar의 실패사례 : 포레스터, Pew의 보고서에 따르면 미국 인구의 5~6%만이 RSS를 활용한다고 한다. RSS를 이용할 준비가 되지 않은 사람들에게 RSS 활용 서비스는 불필요할 뿐인 걸 보여줬다.
• MyKinda의 실패사례 : 양질의 전문 컨텐트를 싣는 것은 많은 비용을 필요로 한다. 충분한 광고매출을 일으킬만큼 많은 방문자를 확보하지 못했다면 잔고만을 깎아먹게 된다.
• Windows Live Expo의 실패사례 : 공룡 마이크로소프트의 크레이그리스트에 대한 도전이었지만, 실패로 돌아갔다. 경쟁자가 이미 탄탄한 기반을 가지고 있다면, 뭔가 더 특별한 것을 제공해야만 한다.
• MingleNow의 실패사례 : 야후에 인수됐지만 성공하지 못했다. 야후는 또 다른 소셜 네트웍 서비스에 집중할만한 자금을 갖고 있지 않다.
• ProtectMyPhotos의 실패사례 : 온라인 미디어 저장 서비스는 이미 포화상태. 게다가 경쟁 서비스들은 모두 소셜한 기능 중심의 개선을 하고 있는데, 전혀 그런 서비스를 하지 못했다.
• Meetro의 실패사례 : 위치 기반의 인스턴트 메신저 서비스. 좋은 아이디어로 많은 관심을 받았지만 기술적인 문제가 지속적으로 발생하고 팀은 흥미와 열정을 잃게 됐다. 핵심아이디어에 집중하고 거기에 열정을 잃지 않는 팀을 유지해야 한다.
• Akimbo의 실패사례 : 회사 경영과 브랜드 관리를 잘못한다면, 충분한 매출이 있고, 자금이 있더라도 회사를 살릴 수 없다.
• Couchville의 실패사례 : 사용성이 쉬운 제품이라고 해서 필요한 제품이 되는 것은 아니다.
• Sonific의 실패사례 : 온라인 음악 스트리밍 서비스를 하려거든, 먼저 컨텐트 사업자들과 제휴를 성사시켰어야지.

지난주말에 책 리뷰를 하나 받은 게 있어서 읽다가, 고객 지원과 관련하여 다시 상기하게 된 사실. 고객지원이나 서비스 개발이나 모두 중요한 사업의 일부라는 것. 고객지원에 대해서 잘 알고 있는 스타트업도 있겠지만, 몇명 안되는 리소스로 많은 아이디어를 실행해 가는 대부분 스타트업 상황에서는 고객지원은 대개 신기능 개발에 밀리게 마련이다. (당연한 얘기아니냐고 혀를 차시는 분은 스타트업 아니시다.)

애플 스토어 내부가 50%는 판매를 위한 시설이고, 50%는 서비스와 고객지원으로 구성돼있다는 얘기로 시작해서 관심을 끈 Ross Mayfield의 글은 그런 구조를 갖지 않는 다른 업체들과 어떤 차이를 보이는지 설명하고 있다. (아래 사진은 지난 5월에 뉴욕 센트럴파크 입구에 있는 애플 스토어에서 내가 직접 찍은 것)

그러면서 예전 회사가 생각났다. 유료주문을 받던 서비스였기에 전화응대를 하는 직원이 2명이 있었고, 항상 적체되는 문제점이 있었다. 왜 그렇게 그런 문제들이 풀리기 힘들었던 것일까. 한쪽에선 문제들을 쏟아놓고, 한쪽에선 치명적인 문제가 아니라면 바로 처리하지 못하는 이유와 잠시 그걸 넘어갈 수 있는 미봉책만 제시하고.

서비스를 직접 기획하고 만든 사람들은 고객들이 느끼는 고민을 함께 느낄 수 있어야 한다. 함께 실망할 수 있어야 하고, 그런 마음을 가질때라야 직접적인 도움을 줄 수 있다. 또 그런 모습을 통해서 고객도 그 회사를 신뢰할 수 있다. 스타트업에서 서비스 개발과 고객지원의 구성비율은 얼마가 적절할까라는 질문에 대해. 그 둘의 비율을 나누기보다, 서비스를 기획개발하는 업무 담당자들이 고객의 목소리를 듣고 직접 고객을 돕는데 얼마만큼의 시간을 할애할 수 있는지, 개별 해당 직원의 시간의 비율을 나누어보는 것이 어떨까.

티켓 만드는 사람, 티켓 처리하는 사람 따로 있나.

석사논문 통과를 앞두고 헉헉대던 1995년 11월부터 회사 생활을 시작했으니, 이 바닥에 들어온지 13년째가 된다. 윈도우95가 겨우 깔리기 시작하고, 맥OS도 System7이던 시절, 인터넷이란 말은 전산과 애들에게나 익숙했을 때. 회사 선배들도 전산과 석박사 출신들이었지만 이미 회사 생활을 시작한지 몇년 정도 된터, PC통신에는 익숙할지 몰라도 인터넷은 영 젬병이었다. (이 형들은 도스 시절 날고 뛰는 개발자였지만, 윈도우용 프로그래밍으로 들어오기를 너무나 힘들어하기도 했다.)

그리고 인트라넷이라는 말이 나왔는데, 그 뜻인즉슨 인터넷 기술을 사내 커뮤니케이션 개선에 적용하고자 하는 시도를 일컫는 것. 웹2.0이라는 말이 공전의 히트를 친 다음, 자연스럽게 엔터프라이즈2.0이 바로 따라 나온 현상도 바로 기존의 그 흐름을 그대로 따른 것이라 할 수 있다. 서두가 길어졌지만 당시 소프트웨어를 다루는 회사였지만 대부분 사내 커뮤니케이션은 종이로 된 결재문서와 업무 프로세스를 따르고 있었다. (아이고, 지금은 상상하기도 힘들다.)

그때 메일 프로그램을 깔고 이걸 업무에 적용하고자 하는 시도들을 했었던 때가 생각난건, 최근에 저 유명한 37signals가 그들의 플래그쉽 웹 애플리케이션인 백팩을 다중 사용자 버전으로 내놓으면서, 우리 회사 미투데이의 인트라넷으로 도입하면서부터다. 다중 사용자 버전이 없을 당시부터 백팩을 유료로 쓰고 있었지만, 새로 추가된 기능들은 너무나 매력적이다.

Newsroom, Journal은 기존에 없던 기능인데, 개별적으로 존재했던 Pages와 Writeboard를 환상적으로 엮어준다. 이걸 사내 분류체계에 의한 디렉토리로 엮는 것보다, 직원들이 최근에 새로 작성했거나 수정한 Activity Log를 보여주는 Newsroom에서 엮어주는 게 백팩 다중 사용자 버전의 핵심이다. 어떤 작업을 했다는 걸 알리기 위해 이메일이나 메신저를 해야할 필요성을 없애준다.

Journal은 미투데이 로그같은 기능이다. 나는 이 기능을 우리 스탭들에게 적극 이용할 것을 요구하고 있다. 주로 아침에 오늘 할 일을 기록하고, 업무를 마칠 때 그 업무를 제대로 마쳤는지 돌아볼 수 있도록 하기 위해서. 단지 한 줄일 뿐이지만 정교한 업무관리보다도 더 힘이 있다. 그리고 중간 중간 새로 발생한 일들에 대해서도 기록한다. ‘회장님 지시사항’같은 뉘앙스의 글들이 쌓일때면 좀 미안한 생각이 들기도. Calendar 기능도 다중사용자 버전이 추가되면서, 개인일정과 그룹일정을 손쉽게 분류해서 이용할 수 있고, iCal용 피드도 제공해 주니까 내가 기존에 사용하던 업무 스타일을 그대로 유지할 수 있다.

페이스북과 트위터가 보여준 소셜함을 자신들의 기업용 애플리케이션에 성공적으로 적용한 37signals에 박수를.

우리 회사의 주요 업무내용이 나오기 때문에 스크린샷을 보여드리지 못함이 아쉬울 따름이다. 인터넷 애플리케이션 수준의 엔터프라이즈 애플리케이션이 절실함을 개개 직원들이 먼저 느끼고 있을테다. 엔터프라이즈2.0은 그래서 말이 된다. 20명 내외의 팀으로 구성된 스타트업 기업이라면 백팩 도입을 어서 검토해 보시라.

너무 큰 회사라서 이런 툴을 쓰지 못한다면, 회사를 박차고 나오는 것도 검토해 보시고.