웹 푸시 알림 서비스 개발 후 그만 둔 후기 : 클리앙

블로그 : https://medium.com/@kiyeopyang/%EC%9B%B9-%ED%91%B8%EC%8B%9C-%EC%95%8C%EB%A6%BC-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%83%8C%EB%94%94-4357a27a393b

저는 올해 1월 말부터 8월까지 샌디라는 웹 푸시 알림 서비스를 개발했습니다. 지금은 서비스를 접고 정리를 하였습니다. 어떤 생각으로 이 서비스를 시작하였고 왜 망했는지를 다시 돌아보고 싶었습니다. 그리고 다시는 같은 실수를 반복하지 않기 위해 이 글을 작성합니다. 다른 분들에게도 도움이 되었으면 좋겠습니다.

저희 서비스는 웹 푸시 알림을 보낼 수 있는 SaaS 입니다. 웹 사이트에서 웹 푸시 알림을 쉽게 연동하고 전송하여 고객의 재방문을 유도할 수 있는 툴입니다.

소개서 : https://drive.google.com/open?id=1jE9Rt7dxZCY3vcrGxy6YJV-m4zoPLvFb

사용 시나리오 영상

서비스 종료 후 보존을 위해 녹화한 영상:

모든 것이 무너진 순간

위기는 갑작스레 찾아왔습니다. 생활을 위해 대출을 해야겠다고 생각하고 실행하기까지 5분도 걸리지 않았습니다. 그 시기에 여자 친구와도 헤어졌습니다. 같이 일하는 동료와도 흐뜨러지고 있었습니다. 바로 일을 구해야한다는 압박감은 엄청났고 동시에 2학기나 남은 학교도 저의 발목을 잡았습니다. 정말 형편없는 현실과 마주치게 되었습니다. 이 순간이 약 7개월간의 여정이 끝났던 순간입니다.

왜 이런 결과가 발생했을까요? 이 모든 것은 우연히 악재가 겹쳐 예상치 못한 실패였을까요? 단지 불운했던 것이었을까요? 이제와서 다시 뒤돌아봅니다. 그 순간에는 어떤 생각도 할 수 없었거든요.

시작 직전

웹 푸시 SaaS를 처음 생각한 것은 2년 반 전입니다. 한창 PWA(Progressive Web App) 개념이 시작되고 있었을 때입니다. PWA는 웹을 앱처럼 작동시키는 새로운 개념입니다. PWA가 갖는 하나의 기능이 웹 푸시 알림으로, 웹 사이트가 앱처럼 푸시 알림을 날릴 수 있는 기능입니다.

이 시기에 저는 친구 한명과 함께 서비스를 하나 만들고 있었습니다. 스타벅스의 사이렌오더와 같은 형태를 PWA로 구현하고 있었죠. (

)

모바일 웹으로 주문하고 웹 푸시 알림을 받을 수 있습니다.

모바일로 주문하고 알림을 받는데에 푸시 알림은 필수였습니다. 그래서 저는 이 때 웹 푸시 알림을 심도있게 경험할 수 있었습니다. 아쉽게도 서비스는 프로토타입 개발 후 여러 관계자를 만나며 비즈니스 장벽이 너무 높다고 판단하여 접게 되었습니다.(그리고 이 시기에 PWA는 사실 아주 극초기였습니다. 현실적으론 앱 밖에 대안이 없었죠. 그 시기에 전 2~3년 후면 PWA가 더 흥할 것이라 생각했습니다. 하지만 지금도 2~3년 전과 비슷합니다. 앞으로도 애플이 본격적으로 받아들이지 않는 한 비슷할 것이라 생각합니다.)

모바일 웹으로 푸시 알림을 받을 수 있다는 것은 아주 큰 혁명이였습니다. 앱을 다운받지 않고도 앱과 같은 경험을 줄 수 있으니깐요. 저는 위 아이템을 개발하며 모바일 푸시 알림의 잠재성을 생각하게 되었습니다.

이 부근에 페이스북, 유튜브도 슬슬 웹 푸시를 도입하기 시작했습니다. 그리고 지금부터 2년 전, 웹 푸시 솔루션이 외국에서 굉장히 많이 생기는 것을 목격했습니다.

iZooto라는 서비스와 더불어 OneSignal, WebEngage, PushEngage, 이 외에도 수많은 웹 푸시 솔루션이 생기고 있었습니다. 외국에서 상당히 많은 회사들이 생기고 있으니 한국에서도 당연히 비즈니스 기회가 있을 것라고 판단했습니다.

1년 반 전, GCP(Google Cloud Platform)에 기반한 초기 형태의 웹 푸시 SaaS를 개발하게 됩니다. iZooto, OneSignal의 서비스를 리버스 엔지니어링하며 구조를 파악했습니다. 이 때는 웹 푸시와 관련된 한계와 서비스 아키텍쳐를 하나부터 끝까지 다 파악했습니다. 공부를 위해 연습용으로 만든 것에 가깝습니다. 도메인은 webpush.kr로 구매했을 정도로 웹 푸시 자체의 힘을 믿고 있었습니다.

저는 이 프로토타입을 만든 이후 바로 밀고나가기 전에 외주 개발을 하기로 결정을 했습니다. 이게 1년 반 전입니다. 저는 이를 가지고 영업을 진행하였고 다소 쉽게 외주 개발을 딸 수 있었습니다. 그렇게 몇가지 외주 프로젝트를 진행하고 몇개월은 서비스 개발에 집중할 수 있는 운전자금을 마련할 수 있었습니다. 그리고 올해 2월, 같이 일할 수 있는 동료를 만나게 됩니다. 디자이너였던 그 친구를 통해 웹 푸시 솔루션의 모든 모습이 달라지게 됩니다.

여기까지가 본격적인 샌디의 시작 직전입니다. 웹 푸시 솔루션을 본격적으로 시작하기에 충분한 경험을 쌓았으며 외국에서 많이 생기고 있는 비즈니스라는 것을 관찰했습니다. 이에 동료가 생기며 본격적으로 시작하게 됩니다.

시작

대박이 날 것이라 생각했습니다. 앱과 같은 경험의 웹 페이지는 모든 사람의 서비스 경험을 바꿀 수 있는 엄청난 것이라고 믿었습니다. 페이스북, 인스타그램, 유튜브 등 많은 서비스가 PWA와 웹 푸시 개념을 도입하는 것을 보고 있었습니다. 본능적으로 이것은 기회라고 생각했습니다. 마음을 먹자마자 저는 잠이 안왔습니다. 빨리가지 않으면 누군가 따라올 것이다라는 마음에 사로잡혔습니다.

먼저 4월에 기존에 만들었던 것을 기반으로 프로토타입을 다시 만들어 쇼핑몰을 운영하는 운영자들에게 어필을 해보기로 했습니다.

4월에 극초기 프로토타입을 완성 후 소개자료를 만든 다음, 쇼핑몰을 하고 있는 운영자들을 대상으로 온라인으로 직접 연락을 드렸습니다. 아래와 같은 응답을 들을 수 있었습니다.

웹에서 푸시 알림을 보낼 수 있다니 몰랐다
큰 몰에서 사용하면 효과가 좋을 것 같다
계속 개발 상황을 알려달라

저희는 가장 크게 걱정했던 부분이 “아이폰에서 지원되지 않는다”라는 점이었는데 이 부분에 대한 점은 전혀 부정적인 얘기를 들을 수 없었습니다. 이 점이 가장 가치있었던 피드백이었습니다.

----- 다음 내용엔 좀 개발적인 내용이 있습니다. (생략하시려면 ---*--- 부분으로 건너 띄시면 됩니다.)

개발에 있어서는 많은 부분은 기존의 개발했던 것을 다시 개발하는 것으로 충분했습니다. 큰 설계를 잡는 건 어렵지 않았습니다. 다만 메시징 서비스인만큼 클라우드를 더욱 본격적으로 사용해야겠다고 결정했고 GCP에서 AWS로 모든 것을 옮기기로 결정했습니다. SQS와 DynamoDB, Lambda를 이용해서 가장 효율적으로 메시징 서비스를 만들 수 있을 것이라 생각했기 때문입니다. SNS를 사용할 수 있었으면 좋았을텐데 SNS는 웹 푸시를 지원하지 않았습니다.

아직도 기억이 나는 순간이 있습니다. 올해 2월쯤, 빨리 개발해야한다는 압박감에 잠이 오지 않아 새벽 1시에 탐앤탐스에 가서 개발을 했었습니다. 그 때 보았던 영상들이 굉장히 흥미로웠기에 아직도 기억에 남습니다. AWS 유튜브에서 아키텍쳐에 관한 영상을 보며 개발을 하였습니다. (ex.

)

퍼포먼스와 효과적인 관리가 필요한 부분은 전부 대부분 Lambda, SQS, DynamoDB를 통해 이뤄질 수 있도록 개발했습니다. 최소한의 부분만 EC2로 돌렸습니다. 모든 부분이 순조롭게 개발이 되었습니다. 다만 FCM 사용이 의무화되며 FCM과 관련된 부분을 결정하는 것은 좀 골치아팠습니다. FCM 내부의 서비스를 사용해서 푸시 알림을 구현해야할지, FCM은 키만 가져오는 도구로 쓸지를 결정해야했습니다. 하지만 FCM은 1000개까지만 전송 그룹을 지정할 수 있었기에 키만 가져오기로 결정했습니다. (놀랍게도 저희는 1000개 이상의 사이트를 고객으로 삼을 수 있다고 믿었습니다.)

푸시에 관한 개발 중에 가장 크게 어려웠던 부분은 맥에서 웹 푸시 알림을 보낼 수 있도록 하는 것이었습니다. 애플은 APN이라고 하는 완전히 독립적인 푸시 서비스를 운영합니다. FCM과 관련된 부분은 npm의 web-push를 사용하고, 와일드 카드 도메인, 그리고 이에 맞는 service-worker, manifest를 구현하고 적절히 다뤄주는 것으로 처리할 수 있었습니다. 다만 APN은 좀 다르게 구현을 해야 했습니다. 먼저 키를 받는 것부터 달랐습니다. 직접 APN 관리 사이트에 들어가서 클릭으로 하나하나 푸시 알림에 대한 인증서를 “먼저” 받아두어야 했습니다. 1000개의 인증서를 받기 위해 직접 크롤러를 구현했고 대략 7~8시간 걸려 1000개의 인증서를 받게 되었습니다. 즉 저희는 이 때부터 1000개의 웹 사이트에 기존 푸시에 더해 사파리 푸시까지 보낼 수 있게 되었습니다. APN에 관련된 자료나 라이브러리는 거의 참고할 수 있는 것이 없더군요. 굉장히 어렵게 시행착오를 겪었고 결국 성공했습니다.

---*---

6월 중순 쯤, 1000개의 웹 페이지에 적용할 수 있는 서비스가 완성이 됩니다. 하지만 저희는 단순한 푸시 알림 이상의 것을 하고 싶었습니다. 사용자가 어떤 푸시 알림을 받을 수 있을지 결정할 수 있고, 쉽게 수신 거부할 수 있는 위젯을 제공하고 싶었습니다. 그래서 저희는 Intercom의 위젯을 리버스 엔지니어링하며 따라 만들었습니다.

웹 사이트 우하단에 노출되는 위젯을 이용하면 고객은 푸시 알림 구독을 자유자재로 컨트롤 할 수 있습니다. 원하는 내용만 알림 받을 수 있게 하는 것, 그것이 아주 이상적이라고 생각했습니다. 게다가 위젯을 통해 유저는 놓친 푸시 알림도 볼 수 있을 것이라고 생각했습니다. 위젯을 통한 컨텐츠 전달은 덤이구요.

저희가 남는 시간에 만들었던 “유튜브 채널 바로가기” 서비스에도 이 툴을 달아보았습니다. (남는 시간에 이런 것을 만든 것은 정말 잘못되었던 일입니다.)

완성

모든 게 완성이 되었습니다. 7월경 샌디는 다음과 같은 기능을 가지게 되었습니다.

1000개의 웹 사이트에 사파리, 크롬, 웨일 등의 웹 푸시 지원
위젯을 이용하여 최종 유저가 구독 여부를 쉽게 컨트롤 가능
대시보드를 통해 쉽게 컨텐츠 관리, 푸시 알림 전송, 결과 보고서 조회

하지만 저희는 고객이 없었습니다. 목표로 했던 서비스는 완성이 되었으나 바로 이용을 요청할 수 있는 고객하나 없었습니다. 기존에 연락했던 잠재적인 고객(쇼핑몰 운영자)들에게 연락해보아도 반응은 싸늘합니다. 돈은 다 떨어졌고 마음은 흔들리기 시작합니다. 무엇이 잘못되었던 것일까요? 저는 4월에 초창기 잠재 고객의 피드백을 받고 서비스를 더욱 고도화시키려고 밤낮없이 일해왔습니다. 이보다 열심히 하지 못할 정도로 열심히하고 하루종일 이 생각만 했는데 터무니없이 무너져버렸습니다.

하지만 돌아보면 4월 잠재 고객의 피드백을 받은 이후로 단 하나도 제대로 쌓은 것이 없었다는 것이 보입니다. 그것이 가장 결정적인 패착이었습니다.

현실 감각을 놓치고, 생활 패턴을 잃고 많은 일이 있었지만 이는 표면상의 문제였고 근본적인 문제는 “고객의 반응과 관련 없이 더 좋은 것을 만들어서 내놓겠다는 생각”에서 나왔다고 생각을 합니다. 이에 따라 고객에겐 오히려 애매한 서비스로 발전하게 되었고 기능은 더 많지만 망가져버린 서비스가 되었습니다.

더 많은 기능, 더 좋은 버전

아주 단순했던 초기 버전, 단순히 웹 푸시만 간단하게 보낼 수 있었던 버전(소개용)은 잠재 고객들의 반응은 “흥미롭다. 더 알고 싶다.” 였습니다. 이 때 바로 초창기 서비스를 내놓았어야 했습니다. 그것이 현실에 발을 딛는 첫번째 스텝이었을 것입니다. 하지만 저는 다른 선택을 합니다. 더 많은 기능, 더 좋은 버전으로 시장에 내놓겠다는 선택입니다.

아래 기능들은 그 이후에 개발을 착수했던 기능입니다.

최종 유저가 쉽게 구독 허용 / 거부를 할 수 있는 기능
최종 유저가 구독하고 싶은 내용만 구독할 수 있는 기능
맥에서도 가능한 푸시 알림
컨텐츠 전달을 위한 위젯

1번은 실제 고객 피드백에서 나온 기능이었습니다. 2번, 3번은 피드백엔 없었지만 장기적으로 필요한 기능이라고 생각했습니다. 4번은 2번을 만들며 나온 파생된 기능이었으며 웹 푸시랑은 직접적인 연관은 없었습니다. 고객이 실제 필요하다고 말한 기능은 1번뿐인데 저는 1,2,3,4를 다 개발하려고 했고 이는 무려 3개월이나 더 걸리게 됩니다. 1번만 개발을 했었다면 1~2주에 개발이 완료가 되어 5월에 서비스를 런칭할 수 있었을 겁니다. 하지만 저는 더 많은 기능을 붙여서 더 좋게 내놓고자 (심지어 고객이 말하지도 않은 기능으로) 하였고 이는 오히려 고객에게 부담으로 작용하게 되었습니다. 최종적으로 더 반응은 싸늘해졌기 때문입니다. 오히려 “서비스가 무엇인지 애매하다.” 라는 피드백을 듣게 되었습니다. “웹 푸시” 에서 “컨텐츠 전달” 이라는 것으로 “발전”했다고 생각했지만 그것은 실제론 퇴보였습니다.

개발할 기능이 많아지며 밤 늦게까지 코딩을 했었습니다. 그러고 나면 “오늘도 열심히 살았다.” 라는 생각에 푹 잘 수 있었죠. 하지만 “열심히”가 “사업”이 아니라 “코딩”에만 집중되었던 것 같습니다. 그리하여 코딩을 열심히 하고 있는 것을 사업을 열심히 하고 있다는 것으로 착각했습니다.

개발 기간이 길어지며 초창기에 소통을 유지했던 잠재 고객들도 소통이 끊기게 되었습니다. 결국 개발이 완료되었을 때 “우리 고객은 누구지?”, “이제 어떻게 고객을 찾지?”라는 터무니없는 질문을 다시 하게 되었습니다. 제품이 어느 순간 고객으로부터 떨어져나와버린 것입니다. 어느새 제 머리속에 있는 것만을 만들게 된 형태가 되었습니다. 마치 저만의 예술작품처럼 말이죠.

4월까진 열심히 가던 운동도 어느새 가지 않게 되고 일만 하게 되었습니다. 같이 일하는 동료가 제품에 대해 의문을 던졌을 때 어느새 제가 답변을 못하게 됩니다. 나는 왜 이걸 하고 있지? 라는 의문을 수 없이 스스로에게 했었습니다. 이런 의문이 든다면 의문의 줄기를 따라 처음으로 돌아가야 합니다. 하지만 저는 그러지 않았습니다. 현재 상황에서 그에 대한 답을 “만들어” 내려고 했던 것 같습니다. 스스로 합리화하고 내부에서 합리화시키는 과정을 반복하며 어느새 고객에게 무언가를 물어보고 질문하는 것조차 부담스럽게 되었습니다.

고객의 말보다 제 머릿속의 생각을 중시했습니다. 그것이 실패의 이유였다고 생각합니다. 처음부터 고객 반응을 받자마자 이에만 집중을 했었으면 좀 달라졌을 수도 있었습니다. 아마 좀 더 빨리 망해서 지금보단 낫지 않았을까라는 생각이 듭니다. 지금은 위젯과 여러 기능을 섞으며 애매한 서비스가 되었지만 웹 푸시만으로 밀고 나가도 쉽지 않았을 것이라고 봅니다.

웹 푸시 솔루션은 부딪혀보니 생각보다 여러 한계점이 많았습니다. 유튜브나 페이스북, 트위터, 인스타그램 등의 유수의 외국 서비스들이 웹 푸시를 이용하는 이유는 앱을 빼고 국제적인 고객에게 어필하기에 그것보다 좋은 푸시 메시지 채널이 없기 때문입니다. 외국에 웹 푸시 솔루션이 많은 이유도 그 이유 때문이라고 생각을 합니다. 하지만 한국에서만 본다면 이야기는 달랐습니다.

카카오톡 플러스 친구가 첫번째 이유입니다. 사용자에게나 비즈니스 사업자에게나 이보다 편한 채널은 없습니다. 그리고 두번째로, 저희는 초창기 잠재 고객으로 쇼핑몰 운영자를 생각하고 있었습니다. 하지만 스마트스토어의 약진으로 웹 푸시 솔루션을 이용할 수 없는 쇼핑몰이 대다수였습니다. 이에 따라 저희 서비스가 초기에 잡았던 고객군은 이미 잠재 고객이 되기 쉽지 않았죠. 그리고 앱 푸시 메시지 솔루션을 운영하는 모 회사와 미팅 후에 국내에서만 푸시 메시지 솔루션을 운영하기에는 이익을 내는 데에는 상당한 어려움이 있을 것이라고 생각했습니다. 차라리 하려면 외국 기업들처럼 국제적인 서비스로 운영을 하였어야 했는데 그러기엔 저희 서비스가 차별점이 없었습니다. 그렇게 그만두게 되었습니다.

긴 글 읽어보아 주셔서 감사드립니다.