러브 42 – 42 네트워크 멤버를 위한 데이팅 앱

2 minute read

다운로드 링크

배경

42서울

현재 42서울이라는 소프트웨어 교육 프로그램을 듣고 있다. 프랑스의 에꼴42를 본부로 전세계에 여러 42 캠퍼스가 있다. 이곳에서는 42 API를 제공하는데, oAuth 인증과 REST API를 제공한다. 이를 사용해 간단한 앱을 만들어보고자 했다. oAuth 인증을 제공한다는 것은 42 네트워크 멤버만 이용할 수 있는 서비스를 만들 수 있다는 것인데, 파릇파릇한 봄 분위기에 맞춰 캠퍼스에 낭만이 싹트면 좋을 것 같아서 틴더 비슷한 데이팅 앱을 만들기로 했다.

앱 기능

앱 기능은 세 가지로 나눌 수 있으며, 각각 BottomNavigationView의 한 탭으로 표현된다.

프로필

picture 6

본인 프로필을 확인하고 수정할 수 있다.

찾기

picture 7

틴더처럼 다른 사용자의 간단한 프로필이 나오며, 좌우로 스와이프하요 ‘싫어요’ ‘좋아요’를 선택 가능하다.

매치

picture 8

서로 좋아요를 눌렀다면 이 탭에 뜨게 된다.

앱 구조

picture 9
구글 권장 아키텍처
View
View
ViewModel
ViewModel
Retrofit
Retrof...
Firebase
Fireba...
Room
Room
LocalDataSource
LocalDataSource
RemoteDataSource
RemoteDataSource
Repository
Repository
Text is not SVG - cannot display

MVVM과 비슷한 구글 권장 아키텍처를 사용했다.

  • 뷰에서 액티비티와 프래그먼트로 화면을 표시, 뷰모델을 관찰해 UI 업데이트
  • 뷰모델은 AAC 뷰모델을 사용해 로직 처리, 상태 저장
  • 레포지토리는 메모리 캐시 역할 겸 상황에 맞게 LocalDataSource 또는 RemoteDataSource에서 데이터 불러오기
  • 로컬 DB는 룸, 백엔드는 파이어베이스, API와 통신은 Retrofit

oAuth 2.0

picture 10
출처: 페이코 개발자 센터
  • Authorization Server: 사용자가 로그인 ID/PW를 제공하면 Authorization Code를 Redirect URL과 함께 발급한다. 42 API 설정에서 Redirect URL을 앱의 딥 링크로 설정하여 액티비티를 띄운다.
  • Authorization Code: 이를 통해 Access Token을 Authorization Server에서 발급받을 수 있다.
  • Resource Server: 실제 사용자가 필요로 하는 정보를 제공하는 서버
  • Access Token: Resource Server와 통신하기 위해 필요로 하는 토큰. 유효기간이 짧다.
  • Refresh Token: Access Token이 만료됐을 시 재발급받기 위해 필요한 토큰. Access Token과 함께 발급된다.

oAuth 2.0을 사용한 인증을 하는 것이 처음이라 하는 법을 몰라서 처음에는 헤맸다. 특히 42 API Docs가 살짝 불친절해서 애를 먹은 점도 있었다.

러브 42는 사용자 프로필을 처음 설정할 때 사용자 정보를 불러와서 미리 채워넣는데, 이 과정을 위해 사용자 정보를 42 API에서 불러올 필요가 있다. 이를 위해 SignInActivity에서 42 API 로그인 화면을 띄워주고, 로그인 성공 시 SetProfileActivity로 연결되는 Redirect URL을 설정한다. SetProfileActivity에서는 Redirect URL과 함께 온 Authorization Code를 이용해 Access Token을 발급받고, 이를 통해 Resource Server에서 사용자 정보를 가져온다.

picture 11
SignInActivity에서 띄운 Chrome custom tab. Authorize를 누를 시 SetProfileActivity로 연결된다

Firebase

나처럼 간단한 앱 개발을 하고 싶은 사람을 위해 구글에서 무료로 Firebase라는 백엔드 아닌 백엔드를 제공한다. 백엔드 코드 없이 DB 및 여러 가지를 구성하여 서비스에 연동해 사용할 수 있으며, 문서화도 잘 돼있어서 아주 편리했다. 세상 참 좋다!

사용자 정보는 FireStore Database, 사용자 사진은 Firebase Storage에 저장을 했다.

picture 12
42 네트워크의 intra ID는 사용자 당 중복 없이 하나만 발급이 돼서 문서의 제목으로 적절하다.

실시간 업데이트

파이어베이스는 DB의 변경 사항을 클라이언트로 실시간 업데이트가 가능한데, 이를 수용하기까지 좀 시간이 걸렸다.

일회성 쿼리

처음에는 Room에서 쿼리를 불러오는 것처럼 일회성 쿼리로 정보를 불러왔다. 그러니 버튼을 눌러주거나 액티비티 또는 프래그먼트가 초기화될 때만 정보가 업데이트돼 실시간으로 좋아요와 싫어요가 많이 바뀌는 러브 42의 경우 맞지 않는 방식이라 판단했다.

Flow(일정 시간마다 API 요청)

마침 코틀린 Flow를 학습하고 있어서 실제로 적용할 곳이 필요했는데, 실시간 업데이트를 나타내기에 Flow가 적합할 것 같아서 이 방식으로 수정해봤다. Flow는 빌더 내에서 일정 시간마다 API 요청을 하고, ViewModel에서 collect하여 UI는 이를 관찰하여 업데이트한다.
아주 잘 동작했지만, 5초 단위로 API 요청을 설정하고 테스트하다 파이어베이스 콘솔을 보니 나 혼자 시간 당 5000번의 요청을 하고 있어서, 이대로 가다간 실제 서비스를 했다간 무료 요청 횟수를 넘어버릴 것이 뻔해서 다른 방법을 찾았다.

실시간 업데이트 수신

Cloud Firestore로 실시간 업데이트 가져오기

파이어베이스에는 문서 또는 쿼리 참조에 addOnSnapshotListener 함수를 통해 콜백을 등록하여 실시간 업데이트를 수신할 수 있다. 이를 사용해 실시간으로 업데이트 될 때마다 UI를 업데이트하게 하니 불필요한 요청도 없어졌다.

후기

처음으로 진행해본 개인 프로젝트여서 아주 의미가 깊다. 아직 사용자가 많이 없지만, 많은 42 멤버들이 가입을 하여 본인의 짝을 만나면 아주 보람찰 것 같다. oAuth 2.0 인증의 개념과 사용 방법, Firebase 연동 방법 및 실시간 업데이트 쿼리 수신 등 여러가지를 배웠다. 추후에 매치가 생기면 FCM을 통해 알림을 전송하는 것까지 구현할 예정이다.

Comments