실패한 SNS 서비스 개발 기록.1
2019년 4월 다니던 회사를 그만두고 같이 일하던 CPO와 음성 기반 SNS 서비스를 만들어 보자는 목표를 가지고 “Effy Live”라는 회사를 설립하였습니다. 많은 우여곡절을 거치며 4년 6개월간 서비스를 개발하고 운영해 왔지만 결국 저는 가시적인 성과 없이 개발을 이어가는 것에 한계를 느끼고, 회사를 그만두게 되었습니다. 정말 많은 시도와 경험이 녹아 있는 서비스였고, 결과물에 대한 자부심도 있었지만 실패한 서비스는 누구의 기억에도 남지 못하고, 그 자부심과 기억 마저도 시간이 지남에 따라 잊혀지고 있다고 느껴져 글을 통하여 그 실패에 대한 경험을 기록해 보려 합니다.
가진 것이라고는 몸뚱이와 SNS 서비스를 이미 한차례 만들어본 경험뿐이었습니다. 1인 개발자가 클라이언트 앱과 백엔드를 포함한 서비스 전체를 설계하고, 개발하는 것은 매우 어려운 도전 과제였고, 저는 그 과제를 해결하기 위하여 필요한 기술부터 찾아보기 시작하였습니다. 이 글에서는 간단하게 어떤 기술 스택을 사용되었는지 간단히 소개하려 합니다.
크로스플랫폼 앱개발을 위한 Flutter!
19년 당시 Facebook의 react native가 대세였지만 저는 고작 발표된 지 1년도 되지 않은 Flutter를 선택하였습니다. 지금 생각하면 무모한 시도였다고 생각되기도 합니다. 하지만 화면을 이미지 엔진을 통하여 직접 그리겠다는 말과 실제를 동작하는 모습은 그동안 쌓아왔던 크로스 플랫폼에 대한 불신을 날려 주기 충분하였습니다.
Firebase 그리고 Firestore, cloud functions …
https://firebase.google.com/?hl=ko
이제는 소규모 팀에서 서비스를 개발할 때 firebase는 빼놓을 수 없는 도구가 되었다고 생각합니다. 저 또한 Effy live를 개발하면서 Authentication, FCM, crashlytics부터 app check, App hosting, remote config, cloud Functions, cloud storage 등 사용할 수 있는 모든 기능을 다 활용하였습니다. 저는 여전히 cloud Functions은 firebase에서 제공하는 많은 기능 중에서 1인 서비스 개발에 가장 도움이 크게 되는 기능이라고 생각합니다. 추후 다른 글에서 Effy Live를 개발하면서 사용된 cloud Functions 대하여 자세히 설명할까 합니다.
Garaph Database. Neo4j
저는 서버 개발을 겸하고는 있지만 어디까지나 모바일앱 개발자이고, RDB에 대한 경험 또한 적습니다. 제가 주로 사용하고, 공부 하였던 databases는 couchDB, mongoDB, Firestore, Neo4j와 같은 흔히 말하는 NoSql 입니다. SNS 서비스 개발에는 복잡한 DB 설계는 필연입니다. graphDB는 태생 부터 노드들 간의 관계를 정의하는 것에 특화 되어있고, RDB와 비교 한다면 상상할 수 없을 만큼 간단하게 노드간의 관계를 정의 하고 질의 할수 있습니다. 가장큰 단점이라면 국내에서는 사용사례가 전무 하다는것 이죠. 이것으로는 먹고 살수 없습니다.
Agora
중국 회사인 Agora는 WebRTC를 이용한 실시간 call과 방송 기능을 제공해 주는 SaaS 업체 입니다. 이미 성능은 많은 대형 고객들로 부터 인정 받았고, 빠르게 Futter에 대응 하여 Futter 초기 버전 부터 라이브러리를 제공 하였습니다. WebRTC 서버를 직접 구현하는 방법도 있었겠지만 개발팀의 크기를 고려해볼 때 그것은 무리한 선택이었을 것입니다.
그리고 GCP, AWS…등등
결론. 나만 좋은 기술 스택
발표후 1년도 되지 않은 Flutter. 50%에 달하는 cloud functions로 이루어진 API. 아무도 쓰지 않는 neo4j.
그때 당시 상황을 고려해 볼 때 요구사항을 만족시키기 위하여 선택할 수 있는 최선의 선택이었다고 생각됩니다. 하지만 나 혼자 만족하고 나 혼자 좋아하는 설계를 가지고 팀원을 설득하고 함께할 팀원을 구하는 것은 매우 어렵습니다. 물론 크게 성공하여 유명해진다면 똥으로 서비스를 만들어도 같이 해줄 사람이 있겠지만 우리는 대부분 성공한 유명 개발자가 아닙니다. 아무리 좋다고 생각되어도 조금은 양보하고 좀 더 많은 사람이 공감할 만한 기술과 설계가 필요하다고 생각합니다. 필요하다면 개발의 범위를 줄여서라도요
