Baas.io 로 소셜데이팅 서비스 만들기

Baas : Backend as a service

현재 다양한 클라우드 서비스 모델이 존재한다. Saas, Paas, Iaas 그리고 모바일 어플리케이션 개발에 특화된 Baas 까지 시간이 지날수록 다양한 기능과 안정성이 높아진 클라우드 서비스가 생겨나고 있다.

사실, 많은 모바일 어플리케이션 개발에 있어서 공통적인 서버 기능이 있다. 로그인/회원가입 프로세스부터 데이터 저장, 푸쉬, 구독, follow 등 이러한 기능들에 대한 api를 제공해주는 것이 Baas의 핵심이다. 몇가지 장점을 거론하자면, NoSQL을 도입해 확장성이 용이하다는점. 서버 구축과 운영에 시간을 할애할 필요 없이 모바일 프론트 앱 개발에만 집중하면 된다는 점등이 있다.

특히, 미국에는 parse 라는 facebook이 전폭적으로 지원하는 Baas 서비스가 이미 큰 반향을 일으키고 있다. 한국에는 KT가 운영하는 Baas.io(https://baas.io/) 있다.

소셜데이팅 서비스인 데이아띠는 Baas.io를 전폭적으로 활용하였다.

이번 글은 이를 활용해 서비스를 개발하면서 얻은 팁과 여러 애로사항 등을 통해 앞으로의 Baas의 미래에 대해 전망해보고자 한다.

하루가 다르게 수많은 새로운 어플리케이션이 쏟아지는 현재, 모바일 어플리케이션 시장은 포화단계에 이르렀고 소비자의 마음을 움켜쥐기 위해서는 아이디어만으로는 승부를 보기 힘든 시대가 되었다. 괜찮은 아이디어가 있더라도 이것이 고객에게 통할 것인지 알아보기 위해서는 빨리 배포하여 반응을 알아보는 것이 최선의 방법이다. 이런 방법론이 오늘날 린스타트업의 초석이 되었고, 이에 따라 개발 환경도 변화할 당면한 근거로 작용하는 것이다.

질문답변을 소셜데이팅의 접목시키려는 내 아이디어를 검증하기 위해서 모바일 앱과 서버를 모두 구축하기는 버거운 일이다. 함께할 팀원을 설득할 수 있겠으나, 최소한의 MVP라도 만들어 시장의 반응을 통해 함께할 것을 제안하는 것도 나쁘지 않은 계획이다. 여러가지의 경우의 수를 따져보고 결국 이 클라우드 서비스를 이용하고자 했다.

-Sandbox

이 서비스를 활용한 어플리케이션을 처음 테스팅하기 위해서, sandbox를 활용하면 빠르고 쉽게 활용할 수 있다. 무엇보다 유저 권한이 자유롭게 풀려있으므로, 데이터 컬렉션과 파일의 접근과 디바이스 푸쉬를 바로 이용할 수 있다.

기본적인 서버 api를 구성하기 위해, 별도 프로젝트를 생성하여 어플리케이션의 기능에 대한 함수를 만들고 테스팅하였다. Baas.io 사이트의 startup 프로젝트를 다운받으면, 기본적으로 푸쉬에 대한 기반 소스와 설정이 포함되어있다. 이를 활용하면, 푸쉬 테스트 또한 쉽게 할 수 있다.

-SignUp-SignIn 에 따른 유저 권한 문제

샌드박스를 벗어나 실서비스를 운영하기위해서는 새로운 프로젝트를 Baas.io상에 생성하고 그에 대한 인증키와 권한을 설정할 필요가 있다. 즉, 기존의 샌드박스에 생성한 코드 그대로 실행할 경우, 인증관련 에러가 호출되게 된다. 이러한 에러로그가 아직은 상세하게 나오지않아 조금 헤맸는데, 앞으로 더 나아지길 기대한다. 콘솔창에 들어가보면 [데이터브라우저/roles]에 세개의 기본 권한이 있다.(guest/default/admin)

각 role에는 permission을 설정하고 이를 통해 상세하게 데이터브라우저를 접근할 수 있는 path를 추가할 수 있다. 각 path는 CRUD 별로 상세하게 설정 가능하다. 그리고 특정한 멤버에게 이 권한을 줄수 있다. 최종 마스터 유저에게 admin 권한을 줄 수 있는 것이다.

그리고, SignUp과 SignIn을 했냐 안했냐에 따라 구성한 기본적인 권한의 상태가 자동적으로 달라지게 된다. SignUp을 할경우, 해당 단말기의 uuid 또한 자동적으로 저장이되고, 푸쉬를 사용할 경우 GCM에도 등록이 되는데, 이에 따라 다른 단말기에서 같은 아이디로 SignIn을 할경우, 인증 관련 에러가 호출된다.

SignIn을 한 경우, 세션을 유지하는 AccessToken은 1일 간 유효하므로, 하루가 지나 다시 해당 앱에서 api를 호출할 경우, 인증관련 에러가 역시 호출된다. 따라서, 다시 로그인을 할 수 있도록 유도하는 방향으로 가야한다.

-Data,Query 활용

데이터를 저장하고 꺼내와 사용하기 위해서 기존의 MySQL과 같은 관계형 모델에 익숙한 개발자들은 NoSQL 이용에 자칫 낯설수 있다. 엔티티를 생성하여 저장하는 것만으로 자동으로 해당 컬렉션의 엔티티로 분류가 되며, 그 엔티티의 고유한 UUID가 부여된다. 처음부터 명시적인 데이터 스키마를 구축하는 관계형 모델과 대비되는 방식이다. 그리고 JOIN과 같은 자주 사용했던 기능도 지원이 되지 않는다. 대신 Baas.io에서는 connect를 통해 각 엔티티 사이에 relation를 연결하는 기능을 지원한다.

데이아띠에서 이를 주로 활용한 사례는 질문과 답변을 연결하는 부분인데, 한 질문에 여러 답변을 follow 하여, 이를 쉽게 가져올 수 있다. ‘매칭 페이지’에서 각 질문별 답변을 이런 식으로 구현하였다. 질문을 매개로 답변으로 소통하는 것이 주 특징이므로 충분히 구현가능하였다. 속도도 생각보다 나쁘지 않다. 그리고, 해당 데이터를 처리하기 위해서 대부분 async한 통신을 주로 이용하게된다.

그리고 Query를 이용하게 되면, 기존의 SQL을 다루는 것과 비슷한 방식으로 데이터를 검색할 수 있는데 제약이 있다. 예를 들어, count()나 random()을 이용할 수가 없고, having이나 group_by 같이 자주 쓰이는 것 역시 이용하기 어렵다. 따라서, 가령 질문을 배열하여 섞고 배치하는 태스크를 작성하고자 할 때, 질문 리스트를 가져와서 도메인 언어 상에서 직접 구현하는 수 밖에 없었다. JOIN이 안된다는 특징때문에 해당 정보를 엮어서 조회하기 보다는 각 엔티티에 필요한 정보를 집어넣어서 그 엔티티를 호출하는 식으로 구현해야 한다. 예를 들어, 질문에 대한 유저 정보는 닉네임이나 사진 정보 같이 필요한 부분만 엔티티의 프로퍼티로 저장했다.

-File

이미지 파일을 저장하고 로드하는데 주로 이용했다. 파일을 로컬 디바이스에 저장하고 이를 로드 처리하는 태스크를 구현했고, 이미지 로드 라이브러리 (https://github.com/nostra13/Android-Universal-Image-Loader ) 를 사용해 자동으로 이미지를 캐싱하도록 했다. 해당 이미지 파일의 UUID를 다른 user, question과 같은 엔티티에 저장하여 이용할 수 있었다.

-REST API

linux의 crontab과 같은 예약어를 실행할 수 있는 api가 구현당시에는 없었기 때문에,( 현재는 Pasta라는 커스텀 api를 만들 수 있는 기능을 지원한다) 이를 개발하기 위해, 따로 개인 서버상에 기능을 구현하였고, 개발 콘솔의 데이터를 접근하기 위해 REST API를 이용하였다. Android API와 마찬가지 형태로 데이터를 검색하고 처리할 수 있기에, 매일마다 질문을 매칭하고, 새로운 가입자의 상태를 바꾸는 등의 처리를 예약 태스크로 등록하여 운용하였다.

이밖에 HelpCenter나 Group 같은 유용한 기능을 지원하므로 관심있는 분은 공식사이트 매뉴얼을 참고하길 바란다. ( https://baas.io/develop_guide/ )

이를 이용해 구현한 소셜 데이팅 서비스 데이아띠는 현재, 안드로이드 버전으로 런칭되어 있다.

( https://play.google.com/store/apps/details?id=com.bpsound.dayatti )