어제부터 계속 생각하지만, 왜 굳이 유라임을 괜히 파이어베이스와 새로운 리엑트 아키텍처로 바꾸려고 했는지 모르겠다. 그렇게 고생해서 유라임 베타까지 만들어 두었는데, 이를 가지고 발전할 생각을 하지 않고 스칼라+플레이 버리려고만 하고 자바스크립트 풀스택으로 바꾸려고만 하고 말이다.
지난 회사에서 몽고DB랑 파이어베이스를 사용해서 열심히 개발해 봤는데, 결과는 실패. 사실 내 아키텍처 문제도 있었다. 기존 유라임 아키텍처를 적용해서 파이어베이스를 연동시키려다 보니 데이터가 너무나도 꼬였다. 좀 심할 정도로. 그런 내 아키텍처적인 책임도 있긴 하다. 그런데 생각해보면 유라임 자체를 내가 처음 설계할 때, Rest기반의 서버/클라이언트 구조로 설계했고, 그래서 플레이로 API서버 만들어 둔 것인데. 그래서 거기에 맞게 리엑트 thunk와 axios로 커뮤니케이션 하는 구조였는데, 이런 구조를 그대로 사용한다고 억지로 끼어 맞추다 보니 프로젝트는 점점 산으로 간 것이다.
기존의 큰 틀은 유지한 채, 몇몇 부분을 빼는 것이 더 좋았었다. 기존 서버의 문제점은 유라임 유저가 많지도 않은데 월 cpu 사용량은 엄청났다. 원인은 백엔드 내부에서 돌리는 배치의 문제. akka로 액터 모델로 설계해둔 내 데이터를 가져오는 배치가 API서버에서 함께 돌다 보니 cpu사용량 때문에 API서버는 항상 과부화 되었다. 거의 시간단위로 배치가 돌다보니 그런 문제점도 있었다.
이 상황에서 해결책은 빅데이터 솔루션을 사용하는 것이었다. 하지만 난 그러지 않았다. 이상하게도 나는 백엔드를 버리는 전략을 택했다. 파이어베이스로 만들면 굳이 백엔드가 필요 없었다. 게다가 파이어베이스는 일정량은 공짜였다. 실시간 데이터베이스도 매력적이었다. 그래서 새로운 프로젝트에서는 몽고DB와 노드JS를 사용했다. 모든게 자바스크립트로 이뤄져서 솔직히 편하긴 했다. 그렇게 처음에는 서버/클라이언트가 분리된 웹서비스를 만들고 잠깐 서비스 했었다. 그러다 파이어베이스를 알게 되었다. 위에서 말한대로, 매력적이었다. 다음 프로젝트에서 몽고디비를 쓰다가 파이어베이스로 바꾸었다.
그런데 그때부터 엄청난 삽질이 시작됬다. 몇개월에 걸친 삽질 끝에 어느정도 “리얼타임”에 걸맞는 제품을 만들긴 했지만, 이미 소스가 꼬일때로 꼬였다. 유라임 기반의 구조에서 사실 백엔드를 바꾸는 것은 그렇게 어렵지 않았다. Node+Express+MongoDB는 생각보다 쉬웠고, 유동적이었다. 하지만 스키마라는 개념이 거의 없으니 솔직히 불편했다. 아직까지 내 머릿속은 스키마의 그 유동성보다는, 어느정도 타입이 보장된 개발이 편한가 보다 싶었다. 몽고DB에 비해 파이어베이스는 그 정도가 훨씬 심했다.
유라임에 파이어베이스를 적용하려고 했다. 단순하게 생각은 로그인부터 모든 디비를 파이어베이스로 바꾸자! 라는 것이었다. 정확히 한달을 삽질했는데, 로그인 2주, 타임라인 2주가 걸렸다. 기능은 유동적이라서 마음에 들었지만 페이징 처리 같은 문제점이 있었다. 데이터도 자꾸만 꼬였다. 그래서 느꼈다. 아, 이건 아니다 라는 것을. 이걸 모두 컨버팅 하는데 분명 적어도 6개월은 족히 걸릴것이라는 생각이 들었다.
사실 그것보다 더 생각이 든 것은 현재 유라임 서비스가 내려가있는 상황이었다. 유저가 많지는 않지만, 난 이렇다 할 공지 없이 벌써 2개월을 문을 닫고 있었다. 물론 서버 운영비도 부담이긴 했지만, 서비스가 가동된 상황에서 파이어베이스에서 로그인도 안되는 랜딩페이지 하나만 띄워두고 유저를 외면했다. 그나마도 있는 유저가 아마 지금은 어떤 생각을 했을까. 생각만 해도 아찔하고, 정말 죄송스럽기까지 하다.
내 결론은, 3년간 열심히 개발했던 유라임에 그 만큼 내 고충도 녹아났을 테이고, 정말 메이저한 개발은 충분히 테스트 된 이후에 반영하자는 것이었다. 지금에서 디비를 싹다 파이어베이스로 바꾼다는 것은 사실 말이 안된다. 아니, 차라리 개발을 하고 나중에 마이그레이션 하면 모를까. 적어도 전재는, 유저가 서비스 이용에 지장이 없게 해야한다는 것이다. 지금처럼 서버를 내렸다가 개발 다 되면 올린다? 이게 무슨 구시대적인 발상인가.
그래서 아마도, 로그인과 푸쉬알람 정도를 파이어베이스로 뺄 것 같다. 기본 기능들은 우선 지금 사용중인 MySQL에 넣어두고, 현재의 Restful API도 유지할 것이다. 다만, 기존에 Kubernetes+Docker 로 올려서 서버가 사용중이지 않을때도 과금했던 정책을, 최근에 GCP에서 나온 Cloud Run으로 갈아타려고 한다. 비용을 최대한 아끼기 위해서다. MySQL도 사실 인스턴스가 비싸긴 한데, 아직까지는 그정도로 안정적인 서비스를 찾기는 힘든 것 같다. NoSQL도 좋긴 한데 아직 RDB에 대한 패러다임을 바꾸고 싶지는 않다. (역시나, 남들 다 NoSQL할때 난 안했는데, 그 생각이 오산이 아니었다.) 서버가 스칼라+플레이 프레임워크로 되어있는데 이 부분도 계속 개선해나갈 것 같다. 지금은 사실 엉망이긴 한데, 스칼라+자바를 버리고 싶지는 않다. 자바스크립트는 내 취향은 아닌 것 같다. 타입스크립트면 모를까. 그런데 타입스크립트는 러닝 커브가 있으니, 우선은 익숙한 것을 해야지..
그리고 데이터 수집 배치는 구글 빅쿼리나 그쪽으로 빼려고 한다. 일일 배치가 가장 좋겠다. 그리고 데이터 시각화에 더 집중하고, 리엑트는 모바일 버전과 SSR에 집중하고 싶다. 당장에 뭐 솔직히 펜시한 기능들이 많은데, 지금은 그 구조를 바꾸기에는 이미 늦었다.
참으로 그렇다. 삽질이 오래되었다. 전 회사도 삽질이었고.. 사서 고생이었다. 물론 배운것도 있다. 너무 무턱대고 신기술을 사용하지 말자고. 아, 이 신기술에 대한 내 욕심은 정말 좀 자제할 필요도 있다. 그건 진짜 욕심이다. 굳이 가져도 되지 않는 욕심. 이번 유라임, 그리고 그간 한 1년 정도 NoSQL과 파이어베이스 등에 대해 삽질한 결론이다. 난 결국, 익숙한게 좋다. 그리고 지금의 스택에서 더 바꾸지 말자. 스칼라, 자바, 플레이 프레임워크, 스프링, 리엑트. 끝.
