[Project] 본방사수

정말 열심히 살았던 본방사수 프로젝트를 마무리하며 회고해 본다,,
(프로젝트 기간: 4개월)

---

# 프로젝트 배경

(1) 개인

대학교 컴퓨터 공학과(지금은 소프트웨어학과이지만..)에 입학 후 1학년 1학기 때 소셜 네트워크라는 페이스북의 탄생에 관해 다룬 영화를 봤었다. 그때 당시 나는 C 언어의 for문을 통해 '*'로 도형을 만드는 프로그램을 짜는 수준이었고, 그렇기에 영화 속 내용들이 썩 와닿지 않아 별로 재미가 없었다.

 

그런데, 언제였을까 군대를 전역한 후, 학교에 복학하기 전 겨울 방학 기간에 우연히 그 영화를 다시 한번 보게 되었고, 놀랍게도 Linux와 Wget, Python, 도메인 등등.. 정말 유명한 이름과 개념들이지만, 처음 봤을 땐 무슨 말인지조차 몰랐던 영화 속 대사들이 하나 둘 이해가 가기 시작했다.

 

그러자, 왠지 모르게 가슴이 뛰기 시작했고 영화 속으로 깊게 빠져들게 되었다.

 

그리고 그날, 나는 다짐했다.

 

영화 속, 마크 저커버그가 그러했듯 나도 학교 기숙사에서 2학년 2학기 겨울방학쯤에 사람들이 사용할만한 쓸모 있는 무언가를 반드시 개발해봐야겠다는...

 

(2) 팀

처음에 어떤 아이템으로, 어떤 서비스를 제공할 것인가에 대해 고민을 정말 많이 했다.

 

그때 당시 나는 마음이 맞는 룸메이트인 같은 과 동기와 개발을 같이 하기로 했고, 서로 이에 대해 고민을 하던 중 학교 앞 자취방들에 대한 정보를 직접 발로 뛰어다녀야만 구할 수 있는 현 상황에 대해 의구심을 가지기 시작했다.

 

기존에 나와있는 부동산 관련 O2O앱들은 아파트 혹은 비교적 큰 매물들을 중점으로 서비스를 제공하다 보니, 학교 앞 자취촌의 원룸들과 같은, 자취생들을 위한 매물은 거의 없었다.

 

좀 더 확인을 해본 결과 이는 지방일수록 훨씬 더 심했고, 이 문제는 나와 룸메이트만이 느낀 것이 아닌 우리 학교 학생들 모두 공통적으로 느끼고 있는 불편함임을 깨달았다.

 

그에 따라, 이 문제를 해결하고자 대학생들을 위한 자취방 정보를 제공하는 본방사수 프로젝트를 시작하게 되었다.

---

# 개발 과정

(1) Frontend(Mobile, Web)

먼저, 프론트엔드의 경우엔 모바일 시대이자 대학생들을 위한 서비스인만큼 웹보단 모바일이 주력이어야 했다.

 

하지만, 프로젝트를 시작했을 때 나와 내 친구의 개발 능력은 모바일 프로그래밍은 고사하고, 기초 웹 프로그래밍 밖에 할 줄 모르는 상태였고, 심지어 프레임워크를 써본 경험도 전무한 시절이었다.

(그때 당시, 모바일 프로그래밍 수업을 듣고 있는 상태이긴 했지만 그냥 Java 기반의 Android 수업이었고, 모바일 생태계에서 점점 저무는 Java로 개발을 하긴 싫었기에 Kotlin으로 프로그래밍을 하고 싶었다.)

또한, 아이폰을 많이 쓰는 대학생 특성상 iOS 앱 개발도 필수인데, 이를 위해서는 Swift 또는 Objective-C를 배워야만 했다.

 

이렇게 놓고 보니, 프로젝트는 무슨 개발 시작 준비하려다 3학년이 될 것 같았다...

그렇다고 포기할 순 없으니, 열심히 구글링을 해본 결과 모바일 개발 분야에서 네이티브와 하이브리드라는 두 가지 개념이 있다는 사실을 인지하게 되었다. (웹앱은 제외...)

그중 우리는 당연히 하이브리드 세계에 눈을 돌리게 되었고 한 줄기 희망을 찾게 되었다.

 

물론, 하이브리드 세계에서도 고민이 많았는데, 바로 React Native를 사용할지 Flutter를 사용할지에 대한 고민이었다.

결과는, React Native를 하기로 하였는데 Flutter의 경우 레퍼런스가 React Native에 비해 아직은 많이 부족할뿐더러 결정적으로, Dart라는 독립적인 새 언어를 배워야 한다는 부담감이 크게 작용했다.

 

적용할 개발 기술이 결정된 후, 우리는 근 한 달간 React Native 기반 지식을 쌓는데 온 힘을 쏟았다.

지금 돌이켜보면 정말 대단했다. 학기 중이었는데도 학교 수업이 끝난 후 연구실에 남아 새벽 5시까지 공부하고, 또 수업 듣고 과제하고, 다시 새벽까지 공부하고의 반복이었다. (학점도 4 넘은 건 안 비밀)

 

특히, React Native가 비교적 최신 기술이다 보니 자료가 많이 없어, 공홈의 영문 Docs를 해석해가며 공부했는데 이때의 경험이 나의 문제해결능력의 한계치를 끌어올려 준 정말로 값진 경험이었던 것 같다.

그렇게 어느 정도 공부를 한 후, React Native를 통해 본격적인 앱 개발에 들어갔는데, 역시 실전에 들어가니 여러 가지 문제들이 또 생겨났다.

 

첫 번째로는 Expo 관련 문제였는데, 처음 React Native를 입문할 당시 Expo를 통해 공부했어서 당연히 Expo로 프로젝트를 생성해 개발을 하고 있었다.

하지만, 점차 개발을 해나가며 추가하고 싶은 기능들이 생길수록, 네이티브 단에서 API를 제어해야 하는 것들이 많아지기 시작했고, Expo에서 작업하기엔 답답하고 포기해야 하는 것들이 수도 없이 많아졌다.

결국, Expo에서 eject 하였고, 코드를 전면적으로 갈아엎게 되었다. 이 경험을 통해 무언가에 종속된다는 것이 얼마나 무서운 일인지 알게 되었고, 그 후에는 무조건 React Native CLI로 프로젝트를 생성하게 되었다.

 

두 번째로는, 두 플랫폼 간의 차이였다. 무슨 소리인가 하면 아무리 하이브리드 앱일지라도 돌아가는 플랫폼이 극명하게 다르다 보니, 생각지도 못한 문제들이 곳곳에서 발생했다. 대표적으로 특정 위젯이나 모듈이 JSX 상에선 같은 코드일지라도 적용되는 플랫폼마다 다르게 보인다는 것인데, 물론, Platform.OS로 분기하여 처리할 수 있었지만, 그 당시에는 난생처음 겪어본, 원인도 모르게 빵빵 터지는 문제들을 디버깅하느라 애를 먹었던 기억이 아직도 생생하다.

 

마지막으로는, 최적화 작업이었다. 모든 개발을 마치고, 출시를 하고 나서야 보이는.. 정말 경험 없인 알 수 없는 그런 문제들이 수도 없이 존재했다. 진짜 세상에는 정말 많고 많은 사용자가 있기에 모든 사람들의 상황에 맞추어 모든 예외 처리를 한다는 것이 얼마나 어려운 일인지... 해보고 나서야 깨닫게 되었다.

 

이것은 무슨 말이냐 하면, 예를 들어, 집주인분들이 매물을 등록하기 위해 원룸 이름을 기입할 때 클라이언트 단에서 글자 입력을 10글자로 제한해놨음에도 특수문자를 포함해 적으실 경우 byte 상 MySQL의 크기가 뻥나거나,,,

글자 크기를 디바이스 크기에 비례하게 해놨지만, 개개인 스마트폰 자체적으로 폰트의 크기를 변경할 수 있고 특히, 연세가 있으신 분들의 경우, 최대로 해놓으신다는 사실을 놓쳐 화면 밖으로 글자가 터지고,,,

일반적으론... 그런 행동을 할리가 절대 없겠지만, 부동산 화면과 직거래 화면을 연타로 계속 전환할 시 화면이 멈추는 등,,,

정말로 모든 예외 처리를 했다고 생각했음에도 문제는 발생했다. 이래서 출시가 끝이 아닌 그 뒤 피드백과 업데이트가 생명이라고 하는구나를 몸소 뼈저리게 체험하게 되었다.

 

이렇게 힘겨웠던 모바일과 달리, 웹의 경우는 홈페이지 제작을 3시간... 만에 뚝딱 끝냈는데 처음엔 React로 제대로 만들까 하다 어차피 아는 사람 빼고는 보지도 않을뿐더러, 단순 소개 글만 게시할 생각이었어서 그냥 돌아다니는 템플릿 하나 주워가지고 알맞게 수정해 서버에 올렸다.

---

(2) Backend

백엔드의 경우엔 한 가지만 빼고 정말 정말 순조로웠다.

 

먼저, 클라우드 환경에 서버를 올리기엔 금전적인 부담이 너무 컸는데, 다행히도 학교 교수님이 본체 하나를 연구실에 놓게 해주셔서 해결할 수 있었다. (박희민 교수님 정말 감사합니다.)

그렇게 Node.js 기반의 Express를 사용해 백엔드 작업이 척척 진행됐고, Node.js 공부는 여름방학 내내 해왔던 터라 Rest API 서버는 금방 구축할 수 있었다.

 

그렇다면, 문제는 뭐였냐.. 애플은 앱과 서버 간의 데이터 송수신 시, HTTP 프로토콜을 사용하게 되면 앱 스토어 등록을 reject 하는 것이었다.

(이 점은 보안 때문이니 당연한 거지만, 애플은 개발자를 너무 지치게 한다... I love Apple ^^)

 

SSL 인증서를 서버에 적용해 본 적이 단 한 번도 없었지만, 만약, 이 문제를 해결하지 못한다면 프로젝트가 말짱 꽝이 돼버리므로, 생각지도 못했던 HTTPS 프로토콜을 사용하고자 맨땅에 헤딩하듯이 3일 내내 밤새 구글링을 한 지옥 같았던 경험을 했다.

 

그래도 결국, Express에 무료 SSL 인증서를 적용하는 방법을 찾아냈고, 무사히 해결할 수 있었다.

(이 과정에서 네트워크 지식을 많이 공부하게 되었고, 과정이 힘들수록 얻어 가는 것은 많은 것 같다.)

내가 해결했던 방법 기록한 글 : [Node.js] 무료 SSL 인증서 적용 및 HTTPS 서버 구축 방법

 

데이터베이스의 경우, MySQL과 Firebase를 사용했는데, 집의 이름, 연세, 반세, 위치, 옵션 등등과 같은 일반 정보의 경우 MySQL에 저장했고, 집주인 분들의 회원 정보인 이메일, 비밀번호, 전화번호 등과 같은 민감한 정보들은 보안상 좀 더 안전하게 하고자 Firebase에 저장했다. (물론, 트래픽이 Firebase 무료 한도 내에서 가능할 것임을 예상했기에 공부하면서 사용해볼 겸 도입했다.)

 

지금 돌이켜보니, 데이터베이스 측면에서 아쉬웠던 점이 한 가지 있는데, 업로드되는 자취방 사진들을 파일시스템으로 관리한 것이다.

그때 당시에는, 다른 신경 써야 할 것들이 워낙 많아서, multer를 사용해 이미지 파일들을 처리했는데, MongoDB를 사용해볼 걸 하는 조그마한 아쉬움이 있다. (뭐.. 첫 프로젝트였으니, 심지어 Docker도 사용 안 했다...)

---

(3) Design

사람들에게 실제로 론칭할 프로젝트를 하다 보니, 아이콘부터 시작해 각종 PNG 파일 GIF 파일 등등 디자인적인 요소가 진심으로 중요함을 깨달았다.

 

또한, 개발자와 디자이너가 왜 뗄레야 뗄 수 없는 관계인지 깨닫게 되었다...

이가 없으니 잇몸으로(그림판 3D..) 프로젝트를 꾸역꾸역 진행하다, 도저히 안되겠어서 우리 학교 시각디자인 학과에 찾아가 프로젝트를 같이 할 디자이너를 구했고, 그 결과 UI/UX 부분과 GUI 부분 디자이너 두 분을 모셔올 수 있었다.

 

아이콘의 경우, 출시하기로 정했던 앱 이름(방콕)이 이미 있었던 문제 때문에, 매우 급하게 만들게 되었다.

 

이 글의 맨 위에 있는 대표 그림이 아이콘인데, 그림의 의미는 집을 형상화한 오각형에 자물쇠처럼 표현하여 우리가 “본 방”을 “사수”하자라는 심오한? 의미를 담았다.

(이는 결국 차후 회의에서 새로운 아이콘으로 변경하자는 만장일치 의견이 나와 바뀔 예정이었지만, 밑에 서술할 서비스 종료 이유 때문에 빛을 보지 못하게 되었다.. 지윤아 미안...)

 

UI/UX의 경우, 특히나 더 개발자와의 차이가 드러났던 부분인데 개인적으로 전혀 생각지 못했던, 사소하지만 중요한 부분들까지 고려하여 인터페이스를 구성할 수 있는 계기가 되었다.

• 초기 UI/UX 시안 목업1

• 초기 UI/UX 시안 목업2

---

(4) Marketing

마케팅의 핵심 중점은 집주인분들 설득하기였다.

 

왜냐하면 부동산이 이미 존재하고, O2O 앱 시장 또한 거대 기업이 이미 장악한 레드오션 상태이기에 굳이 우리의 서비스를 사용해야 하는 이유가 없기 때문이었다.

 

그럼에도 불구하고, 이 프로젝트를 실현 가능하다 믿고 진행한 단 한 가지 이유는, 중개 수수료, 즉 복비였다.

 

우리 서비스는 학생들이 학생들을 위해 제공하는 만큼 전부 무료로 진행하기 때문에 공급자인 집주인과 수요자인 자취생 양측 모두 쓸데없이 소모되는 중개 수수료를 없앨 수 있었고, 이는 공유경제의 흐름과 맞아떨어진다 생각했기에 일종의 틈새시장으로서 가능성이 있다고 판단했다. (또한, 무료로 광고를 해주는데 참여를 하지 않을 리가 없을 거라고 생각했다.)

 

하지만, 역시 현실은 생각보다 녹록지 않았다...

우선, 우리는 인력이 너무나도 부족했다.

• 첫 목표 지역 설정 구간

위의 지도가 우리 학교 앞의 자취촌이며, 처음 목표로 설정한 구역들이다.
사진상으로는 체감이 안 올 수 있으나, 저 구역을 다 합하면 원, 투룸이 무려 100개가 넘는다.

 

그 말은 바꿔 말하면, 저 100개가 넘는 곳을 직접 다 돌아다녀야 한다는 소리이다.

 

하지만 이러한 문제는 사소했고 집주인 분들과 콜드콜을 하기 위해, 기말고사 기간에 추위에 덜덜 떨면서 건물 밖에 걸려있는 광고 플래카드들을 일일이 확인해가며 적혀있는 전화번호를 모두 수집했다.

• 처음 수집했던 자료 일부

그 후, 콜드콜을 하기 시작했고 처음 랜덤으로 전화한 10곳의 반응이 생각보다 나쁘지 않았다.

 

결과는 긍정적인 반응과 부정적인 반응이 7 대 3이었는데, 긍정적인 분들은 학생들이 좋은 취지로 하는데 참여하지 않을 이유가 있냐며 격려까지 해주실 정도로 좋은 반응이었다.

 

다만, 부정적인 반응에서 생각하지 못했던 변수가 있었다.

 

그것은 바로 이 서비스가 활성화될 시, 집의 정보(방 사진 및 가격)들이 학생들뿐만이 아니라 다른 집주인분들에게도 전부 공개가 되므로 자칫, 가격 경쟁이 붙을 것 같다는 우려였다.

 

물론, 학생들의 입장에서는 이렇게 된다면 더 나은 서비스와 더 저렴한 가격에 방을 구할 수 있게 되므로 선순환으로 작용하겠지만, 집주인분들의 입장에서는 그렇지 않다는 사실을 깨닫게 되었다.

 

하지만, 이 또한 시장의 흐름이라고 생각하신다는 긍정적인 집주인분들의 조언 덕분에 완전히 서비스 활성화를 위한 전력 질주를 시작했고, 만약 서비스가 활성화된다면 부정적이었던 분들도 자연스레 참여하게 될 것이라 생각했다.

 

그렇게 한 집, 두 집 계약을 맺으면서 회원가입을 시켜 드리기 시작했고, 처음에는 길바닥의 전단지를 주워가며 서비스를 알리려 전화를 걸었지만, 나중에는 서비스를 이용하려 먼저 전화가 걸려온 배달의 민족이 그러했듯이, 우리에게도 집주인 분들이 먼저 서비스를 이용하고 싶다는 전화가 오는 놀랍고도 기뻤던 경험을 할 수 있었다.

---

# 프로젝트 결과

(1) 프로젝트 결과

본방사수 홈페이지 ☞ 본방사수 홈페이지
본방사수 Android 앱 ☞ 본방사수 Android 앱(플레이 스토어)
본방사수 iOS 앱 ☞ 본방사수 iOS 앱(앱 스토어)

 

현재 글 쓴 날 기준으로는 서버를 열어놨기에 직접 설치해 사용해볼 수 있지만, 미래에는 닫혀 있으므로 사진과 함께 기록해 둔다.

• 실제 앱 화면(방 구하기 화면)

• 실제 앱 화면(방 내놓기 화면)

학생들에게 홍보는 에브리타임을 이용해 글을 작성했다.

 

다만, 홍보를 저 이외에 아무것도 하지 않았는데, 그 이유는 출시 당시 등록된 매물이 약 30개 정도밖에 되지 않아서 널리 퍼뜨리기엔 절대적으로 부족한 양이라 판단했고, 반응이 좋으면 20년도 여름방학 시즌에 기능과 매물들을 더 보강하여 제대로 론칭할 계획이었다.

 

홍보 결과 에브리타임 실시간 인기 글 및 HOT 게시물에 선정되었고, 반응 또한 매우 좋았다.

• 실시간 인기 글 등극 당시

• 댓글 반응 중 일부

에브리타임 홍보 후, 당일 설치수는

 

플레이 스토어 : 103명
앱 스토어 : 117명

 

도합 220명이 설치했고, 3일 뒤에는 300명을 돌파했다.

 

(홍보를 더 이상 안 했지만, 지금은 더 높으려나?)

 

이후, 집주인분들에게 앱을 통해 방을 계약했다는 소식이 들려왔고, 이렇게 들려온 추산된 계약 건수는 6건이며, 묵인하거나 학생이 앱을 보고 왔다는 말을 하지 않았을 경우까지 생각한다면 아마도 10건은 되지 않았었을까 싶다.
(출시 이후, 집주인분들 사이에 앱을 통해 계약이 잘 된다는 소문이 퍼져 먼저 앱을 이용하고 싶다는 전화가 속출했기 때문이다.)

---

# 프로젝트 종료

마지막으로, 이 글을 쓰게 됐듯이 순항할 것만 같았던 프로젝트를 종료하게 되었다.

 

그 이유에는 여러 가지 요인들이 있지만 크게 2가지만 뽑자면,

 

첫 번째로, 집주인분들의 고령화이다. 젊으신 분들도 있지만 대게 나이 드신 분들이 많았고, 그에 따라 스마트폰을 사용을 어려워하셨다. 우리의 핵심 키는 공짜인 만큼 집주인분들이 직접 매물을 올리고 내려주셔야 하는데, 할머니 할아버지분들 혹은 기성세대의 경우 우리가 찾아가서 매물을 등록해 드려야만 했다.

 

나를 포함한 팀원들을 이를 위한 인력으로 소모할 순 없기에 서비스 순환이 성립하지 못하는 구조였으며,

이를 근본적으로 해결하고자 UI/UX를 어르신들을 대상으로 최대한 쉽고 간편하게 구성하고, 사용설명서까지 만들어 배포했으나 소용없는 일이었다.

• 본방사수 사용설명서

두 번째는 첫 번째 이유의 복합적인 연장선인데, 사실상 프로젝트 종료 결정의 핵심적인 이유이다.

 

간단히 말하자면, 인기가 많아질수록 오프라인 관리를 감당하기 버거웠다.

 

애초에 프로젝트를 시작한 목적과 이유가 개발 실력을 높이고 실전 경험을 쌓기 위해서였는데 점점 사용하고자 하는 집주인 분들이 늘어나면서 개발 이외의 시간 즉, 마케팅 및 영업으로 소비하는 시간이 엄청나게 소모되었다.

 

초기에는 낮에 집주인분들을 만나 뵙고, 저녁에 코딩하고 수정하고, 찜질방에서 자고 이런 식의 패턴으로 근근이 버텼지만, 후반부로 가면 갈수록 마치 배보다 배꼽이 더 커져간달까, 원래의 목적과 본분이 퇴색되는 느낌을 심하게 받았다.

 

만약, 이 본방사수를 사업화한다면 지속적인 유지가 가능하겠지만, 뚜렷한 비즈니스 모델이 없었을뿐더러 인생을 걸고 도전하기엔 아직 부족한 것도 많고, 무엇보다 스타트업으로 시도할 만한 아이템은 아니라고 생각했다. (다운로드 수가 일정 이상이 되면 펀딩을 해주시겠다는 집주인 분도 계셨고, 바로 광고비를 주시겠다는 분들도 계셨다. 마음만은 감사했지만 억지로 주신 한 분을 제외하고 모두 받지 않았다.)

• 집주인분들에게 서비스 종료 공지 후 받았던 답문 중 일부 (왠지 모르게 눈물이 날뻔했다...)

따라서, 장고 끝에 미련 없이 프로젝트를 여기서 종료하기로 결정했지만, 이번 본방사수 프로젝트는 아마도 나의 인생에 있어 한 획을 그을 프로젝트였으며, 많은 것들을 깨닫고 알게 해준 어디 가서도 얻지 못할 값진 경험이었다.

---

막상 적고 나니, 기술 관련 기록 글이기보단 그냥 일기 형식이 된 것 같은데, 어차피 코드는 GitHub에 다 저장되어 있기도 하고(관련 Repo는 전부 Private ^^), 지금 돌이켜보면 첫 프로젝트였기에 기술적으로 눈에 띄는 것이 없었을뿐더러, 오히려 부족한 부분이 많이 보이므로 과정과 경험들을 기록해둘 겸 작성했다.

 

Thanks to)
나의 은사님이신 김진희 교수님,
서버지원 및 개발여건을 마련해주신 박희민 교수님,
SSL 관련 난제를 해결하는 데 큰 도움을 주신 정승도 교수님,
그리고
정말 고생 많았고 항상 고마운 디자인팀 지윤이와 미애,
같이 0부터 공부하며 개발하느라 힘들었던 진영이 형,
1학년이었어서 어려울 텐데도 열심히 공부하고 잘 따라와준 지우,
마지막으로
근 몇 달간 영화 같은 삶을 산 나의 룸메이트 김록원