얼마집 제품 로그 2 (앱 런칭까지)
이 글은 저희 제품 로그의 2편이고, 이전 글(1편)이 있습니다!
한국프롭테크는 현재 채용을 진행하고 있습니다! 많은 관심 부탁드려요!
https://career.koreanproptech.com/
세번째 MVP
두번째 MVP를 런칭하고 1–2주의 시간이 흘렀습니다. 우리는 집주인이 가격에 민감하기 때문에, 당장 거래가 일어나지 않더라도 거래 당사자들의 의사(호가)를 보여주는 것이 의미 있을 것이라고 생각했지만, 거래 당사자들 입장에서는 거래가 일어날 것도 아닌데(거래 연결 기능이 있었으나 핵심이 아니었음) 굳이 호가를 입력할 의미가 없다고 생각하는 것으로 보였습니다. 어쩌면 집주인들은 네이버 부동산의 매물로 나온 호가와, 신고되는 실거래가 정도면 충분하다고 느끼는 것은 아닌가 하는 의심이 들었습니다. 이대로라면 두번째 MVP를 기획하며 세웠던 가설도 실패한 것으로 봐야했습니다.
그러던 와중에, 저희가 유저의 니즈를 파악하기 위해서 모니터링하던 다수의 카톡방과 네이버 카페들이 있었는데요, 그곳에서 특이한(?) 현상을 관찰할 수 있었습니다. 바로 아파트 소유주들의 채팅방인데요,
이 소유주 채팅방의 방장 분들은 실제 소유주만 입장시키기 위해, 방 비밀번호 + 온갖 개인정보가 담긴 서류 + 각종 아파트/동네 관련 퀴즈를 총동원해서 소유주 인증을 진행하고 있었습니다. 여기에, 저희의 기존 MVP가 가지고 있던 집 등록 과정을 활용하면, 복잡한 소유주 인증 과정이 훨씬 간편하게 만들 수 있겠다는 확신이 들었고, 그러다 보면 기존 소유주 채팅방을 대체할 수 있는 기회도 있을 것이라 생각했습니다. 이 시점에 특히 고민을 많이 했던 것 같은데요, 당시의 기록을 아래 링크에도 많이 남겨 두었습니다.
개발
문제는 제가 한 번도 채팅 서비스를 구현해본 적이 없다는 것이었습니다 ㅜㅜ 물론 직전 회사에서 라이브 커머스 채팅이나 1:1 DM 같은 프로젝트들을 런칭할 때, 당시 채팅 백엔드로 Firebase Realtime Database를 사용했다는 이야기를 들은적은 있었습니다. 하지만 제가 해당 프로젝트의 담당자는 아니었기 때문에, 관련 코드를 직접 작성한 적은 없었습니다. 고민이 커졌지만, 결론을 내려야 했습니다.
- 겨우 백엔드(Firebase) 하나 안다고 채팅 서비스 전체를 직접 구현하기에는, 채팅에 대해 내가 모르는 부분이 너무 많다.
- 시간이 없다.
저희 팀이 원하는 것은 간편하게 인증할 수 있는 소유주 채팅방이 타겟 고객에게 통하는지 확인하는 것이지, 멋진 채팅 서비스를 구현하는 것은 아니었습니다. 그래서 저는 잘 알려진 채팅 솔루션인 Sendbird를 사용하기로 마음 먹었습니다.
시작하자마자 수백달러의 요금을 끊고 시작해야 했지만 ㅜㅜ 그만큼 개발 기간은 획기적으로 단축 되었습니다. UIKit과 Javascript SDK의 도움으로 저는 채팅 서비스를 약 3–4일만에 런칭할 수 있었습니다. (쓰고 보니 무슨 센드버드 광고 같은데 아닙니다! 그냥 스스로도 놀랐던 기억이 나서…)
자동 인증 구현
세번째 MVP로 만든 ‘인증 소유주 채팅방’에 유저들이 조금씩 반응하기 시작했습니다. 그러다보니 ‘소유주 인증’ 기능 자동화에 대한 필요성을 느꼈는데요, 당시에는 다음과 같은 문제가 있었기 때문이었습니다.
- 하루에도 수십건이 넘는 소유주 인증 요청을 수동으로 처리하느라 다른 업무를 진행하기 어려움
- 유저의 인증 요청으로부터 완료까지 걸리는 시간을 단축 (기존에는 아무리 빨라도 5–10분이 걸리거나, 다른 업무 때문에 늦어지면 몇 시간을 넘기기도)
그래서 휴대전화 본인인증 정보와 등기부등본 소유자 매칭 모듈을 만들어 시스템에 적용했습니다. 저와 대표님은 인증 지옥에서 벗어날 수 있었고, 유저의 인증 시간은 1분 이내로 대폭 줄어들었습니다. 이 때 만든 자동 소유주 인증 기능은 아직까지도 저희 서비스의 주요 기능 중 하나입니다.
앱 개발
이렇게 자동화가 필요할 정도로 반응이 있다보니, 저희는 3번째 MVP에 대해 어느정도 확신을 갖게 되었고, 앱 제작을 해도 되겠다는 결심을 하게 되었습니다. 마침 기존 MVP는 웹이기 때문에, 채팅 서비스에서 필수인 푸시 알림을 사용할 수 없다는 피드백을 받았던 참이기도 했습니다.
앱 제작 도구로 ReactNative를 선택했습니다. MVP를 만들면서 React 코드에 익숙해지고 있었기 때문이기도 했고, 네이티브 앱 제작 경험은 전혀 없었던 저에게 적합한 플랫폼이었습니다. 과거에 짧게 RN을 사용해 본 경험도 있기 때문에 망설임 없이 골랐습니다.
지금 생각해보면 처음부터 껍데기만 RN을 사용하고 주요 페이지들은 웹뷰로 구성하면 어땠을까 하는 생각이 듭니다. 실제로 현재는 일부 페이지를 웹뷰로 구현하고 있습니다. 이 부분에 대해서는 다음편에서 이야기 해보겠습니다.
RN를 사용한 김에, 유연한 배포를 위해 CodePush를 적용했습니다.
처음에는 적극적으로
CodePush를 사용했으나, 딥링크 문제가 있다는 것을 알게 된 이후로 사용하지 않았습니다. 이 부분도 다음편에서 좀 더 자세히 이야기 해보겠습니다. 결국 한동안 꼬박꼬박 앱스토어/플레이스토어를 통해 배포를 하다가, 최근에 웹뷰 구현을 늘려가면서 다시 유연하게 배포할 수 있는 영역을 늘려가고 있습니다.
여전히 디자이너는 없었기 때문에, 기존 MVP의 디자인을 그대로 사용했습니다. 센드버드의 UIKit은 RN에서 사용할 수 없었기 때문에, 제가 직접(...) 임의로 디자인을 입혀서 개발했습니다.
약 한달간, MVP의 기능들을 앱으로 옮겼고 2021년 11월 말에 스토어에 런칭할 수 있었습니다. 생전 처음해보는 네이티브 앱 배포였기 때문에 여러 시행착오들이 있었으나, 어찌…어찌… 성공했습니다…
다음
다음에는 아마,
- 실패했던 라운지 프로젝트 이야기
- 디자이너분을 모셔오고 나서의 채팅방을 개선하고, 카페를 추가했던 이야기
- 시드 투자에 성공한 이야기
- 컨텐츠 탭을 오픈하게 된 이야기
- 개발자분을 모셔오면서 웹뷰를 적극적으로 적용했던 이야기
같은 주제들이 남아있을 것 같은데, 천천히 풀어보려고 합니다!
