Firebase

웹서비스를 만들때는 서버쪽에 고려할 부분이 참 많은데, 솔직히 좀 빡세다.

예를들면, 호스팅, 데이터베이스, 배포, 도메인 등등...

그 때문에 웹 서비스를 통해 제공하고자 하는 그 실제적인 "가치"를 주기위한 노력보다,

웹 서비스가 죽지않고 잘 "가동, 유지" 되도록 구성하는데 더 많은 시간과 노력이 든다.

서비스를 통한 가치개발 < 서비스 유지를 위한 부가적인 노력 

딱 봐도 주객이 전도 되었다. 간단한 웹서비스를 구상해도, 너무 많은 리소스가 필요하다.

유지보수까지 생각한다면, AWS를 쓴다 해도, 이건 도무지 공수가 나오지 않는다.

하지만 현 시대에서 서비스가 중단되는 일은 있을 수 없는 일이나 마찬가지이다. 따라서 서버 가용시간을 포기할 수는 없다.

 

딱 이런 상황에서 Firebase 를 사용한다면

서버가 죽지않고 잘 동작하게 만드는 노력보다, 본질적인 서비스 개발에 더 집중할 수 있다.

개발시간 및 노력 자원을 훨씬 효율적이고 효과적으로 사용할 수 있게된다.

 

물론 장점만 있는 것은 아니다. 서버가 없으므로, 서버가 하는 기본적인 역할들은 프론트엔드에서 모두 처리해야 한다.

당연히 보안에 대한 고민이 생길수밖에 없다.

데이터베이스는 선택할수도 없이 무조건 Firebase의 NoSQL을 쓸 수밖에 없다.

그리고 서비스가 프론트에서 처리할 수 없는, 서비스 고유의 서버에서만 처리할 수 있는 특수한 로직이 필요한 경우라면, 추가적인 작업이 필요하다.

예를들어, 카카오 맵처럼 길찾기 기능이 필요하다던가, 게임이라던가, 고객의 민감한 정보가 저장된다던가, 대용량 데이터에 대한 막대한 연산이 필요하던가, 절대 공개할 수 없는 서비스알고리즘이라던가, 특히 수주받아서 개발하는 서비스일수록 독특한 요구사항이 있다.

이런 종류의 서비스들에는 Firebase를 적용하기 어렵다.

 

하지만 단순히 데이터를 저장하고, 불러오고, 업데이트하고, 약간의 계산만 있으면 되는 종류의 서비스도 굉장히 많다.

예를들면 새로운 SNS 서비스를 만든다거나, 단순한 현황 대시보드같은, 혹은 랜딩페이지 같이 이런 간단한 웹페이지를 구현하고자 한다면,

이런 종류의 서비스들에는 Firebase는 최고의 선택이다.

 

그러므로 만일 1인 개발자로서 살아가는 꿈을 꾸고 있거나

새로운 서비스를 만들고자 하는 창업 및 (고수준의 서비스가 필요없는) 스타트업의 경우에는, 고민할 필요없이 Firebase를 사용하면 된다.