현업 프로젝트(기술스텍 변경) FireBase에서 SpringBoot로

처음 개발을 시작하게 되었을때, Flutter + FireBase로 구성된 가벼운 앱이었습니다. 

해당 앱에서의 기능은 대부분 DB에서 가져와서 보여주는 형식을 가지고 있었고, FireBase는 db에서 데이터를 가져온 횟수만큼 비용이 추가되는 구조를 가지고 있었기에 Backend의 필요성과 Cache의 필요성을 가지게 되었습니다. 또한, 데이터의 필터링과 로직 고도화를 위해서 Backend를 추가해야된다고 생각했습니다.

 

 

하지만, 우선적으로 해야하는 것은 팀을 설득하는 것이었습니다.

Firebase만을 이용한다면 유저 관리 및 알람 등 다채로운 기능을 쉽게 구현하게 해주는 장점이 있습니다. 그리고 시스템 구축의 속도 또한 빠르게 진행할 수 있습니다. 하지만 복잡한 비즈니스 로직을 목표로 하기에는 적합하지 않았고 비용을 최적화하기 위해 택했던 일부 방법이 유저들에게 불편함을 가져올 수 있다고 생각했습니다.

이를 토대로 팀원들을 설득했고, SpringBoot + Redis를 통한 개발을 시작하게 되었습니다.

 

 

이를 통해 유저가 많더라도 DB에서 직접 정보를 가져와서 보여주는 단순한 방식이 아닌, 유저에게 원하는 정보를 쉽게 보여줄 수 있다 라는 장점을 만들수 있게 되었습니다.

또한 Redis, CloudFront 등 캐시를 통해 DB의 부하를 줄이고 데이터를 빠르게 보여줘서 유저들의 사용성을 높였습니다.

 

 

PostgreSQL의 도입에 대해서는 정말 고려를 많이하고 결정하게 되었습니다.

현재 만드는 앱의 특성이 정형화된 자료들이 많았고, 거리기반으로 가져올 필요성, 최종적으로 선을 통한 GeoMeta가 필요하다고 판단했고, 많은 수정이 발생하지 않을것으로 판단했습니다. 이를 기반으로 가장 이상적이면서 가격적으로 최적화된 DB는 postgreSQL라고 여겼습니다. postgreSQL에는 GIS를 통해 거리기반 데이터를 쉽게 다룰수 있었고, Spring Boot로 개발할 때에 원하는 일부 기본 기능이 Hibernate에서 지원하고 있기도 했습니다. 이에 빠른 시간내에 개발 가능하겠다고 여겼습니다.

 

그리고 이러한 결정을 기반으로 인프라를 구축하고 다시 기획을 시작하게 되었습니다.

 

변경을 고려하게 된 요소

1. 좋아요를 클릭을 하게 되면 어뷰징으로 인해 무한으로 클릭하게 되었을때 비용적이 문제가 발생합니다. 따라서 이를 막기 위해 한번 클릭하면 5초 뒤에 다시 좋아요 해제가 가능합니다. 이는 유저에게 불편함을 줍니다.

2. 검색을 했을때, 인덱싱의 요소가 없습니다. 이는 유저들이 원하는 데이터를 찾기 어렵게 만들고, 앱의 필요성에 대해 의문을 가지게 됩니다.

3. 앞으로 목표로하는 기능을 구현하기 위해서 백엔드 개발의 고도화가 필요한 작업이 많았습니다. 이를 개발하기 위해서 인프라 및 백엔드 개발의 필요성을 느꼈습니다.

 

 

 

개선을 통해 변경된 요소

그리고 3개월 동안 개발을 한 결과

1. 1초에 5번 이상 클릭을 하는 것처럼 크로링을 통한 로직이 아니라면 유저들의 클릭을 막지 않습니다.

2. postgre 기반의 데이터 추출로 빠른 시간내에 거리기반 필요한 데이터를 가져오게됩니다.

3. 검색 고도화를 통해 유저들이 검색을 통해 데이터를 가져오게 됩니다.