나는 현재 보오 앱을 firebase로 개발했다.
1인 앱 개발을 하다보니 백엔드까지 신경쓴다면 내가 생각한 아이디어 검증도 제대로 못하고 기술적인 부분에만 계속 매달려있어야할 것 같아서 처음부터 firebase로 개발했는데, 이제 센터와 적극적으로 보오 앱을 활성화시키려고 보니 장기적으로 봤을 때 firebase의 한계점이 보여서(=비용의 부담) 추후 AWS로 마이그레이션할 계획을 미리 세우게 됐다.
***물론 이 마이그레이션은 보오 앱이 DAU(일일 활성화 유저 수)가 일정 수치 이상일 경우에만 진행시킬 예정이다. 지금은 앱이 완전 새싹 단계이기 때문에 내가 굳이 AWS로 무리해서 이전할 필요는 없다. 지금은 오히려 firebase를 이용하는 게 나에게 더 나은 옵션이다.
내가 느낀 가장 큰 firebase 한계점은 역시 비용이다.
솔직히 firebase로 개발하기 참 좋았고 공식 문서도 잘 되어있어서 별 무리없이 뚝딱 뚝딱 앱을 만들었는데 비용 부분이 앱의 사용자가 급격히 늘어났을 때 감당이 안될 거 같았다.
이런 부분에서 AWS가 참 괜찮다고 느꼈고 보오 앱이 일정 수준 성장한 이후에는 AWS로 서버 이전할 계획인데 그 구체적인 계획은 아래와 같다.
보오 앱의 Firebase에서 AWS로 마이그레이션 계획
*이 마이그레이션 부분은 제가 심도 깊게 알아본 부분이 아니기 때문에 부족한 부분이 있을 수 있습니다. 찐 정보는 보오 앱이 잘돼서 firebase에서 AWS로 넘어갈 때 적어볼테니 이 계획은 그냥 계획으로만 봐주시길 바랍니다.
내가 Firebase에 저장하는 데이터
- 동물 사진(보호센터가 올림)
- 동물 정보(보호센터가 올림)
- 봉사활동 일정(보호센터가 올림)
- 봉사활동 예약 내역(유저가 올림)
- 유저 회원 정보(유저가 올림)
- 토큰(보호센터 & 유저가 올림, 푸시알림용)
이러하다.
마이그레이션의 경우, firebase에서 자연스럽게 데이터를 추출해서 aws로 바로 넣어줄 수 있을지도 모르겠지만, 마이그레이션 도중 데이터 유실도 있을 수 있기 때문에(서버에서 추출한 데이터가 aws에 호환되지 않는 경우) 여기에서는 마이그레이션 도중 데이터 유실이 있는 경우에 대해서 적어보겠다.
최악의 경우에 대비하기 위해서 말이다.
데이터 유실이 없는 경우에는 firebase에서 데이터 추출해서 쉽게 aws로 넣어주기만 하면 된다.
firebase에서 aws로 데이터 이전이 안 될 경우(최악의 상황 가정해봄)
firebase에서 aws로 데이터 이전이 안 될 경우, 앱 유저 입장에서는 이런 상황이 펼쳐진다.
어느날 보오 앱에 들어가봤는데 데이터는 다 유실됐고 앱 내 자료가 하나도 없다. 그래서 놀라서 앱을 삭제하고 다시 깔았는데 그 앱에서도 예전 정보를 볼 수 없고 방금 올라온 정보만 보인다. 본인이 예전에 회원 가입한 것도 다 없어져서 다 새로해야하는 상황이 됐다.
이게 바로 firebase에서 aws로 데이터 이전이 안될 때 유저가 겪는 상황이다.
내가 유저입장이 되면 화가 많이 날 거 같은데 사실 서버 마이그레이션이 스무스하게 이루어져도 어느날 유저가 앱에 들어갔을 때 앱 내 데이터가 다 사라져 있을 수 밖에 없긴 하다(이거는 유저 앱이 전 서버에 연결되어있어서 그렇다. 전 서버의 데이터를 다 지우면 앱에서 받아올 데이터가 없어서 앱에 띄워줄 데이터도 없어진다.).
이렇듯 서버 마이그레이션을 진행할 경우, 유저가 앱에 들어가봤을 때 앱 내 데이터가 모두 사라져있는 일은 당연히 있을 수 밖에 없고 서버 마이그레이션이 스무스하게 되었는지 안되었는지는 나중에 유저가 앱을 지우고 다시 깔았을 때 예전 정보들이 앱에 잘 들어가있느냐 없느냐에 따라 갈리게 된다.
firebase에서 aws로 데이터 이전이 잘 된 경우에는 유저가 앱을 지우고 다시 깔았을 때 예전 정보들이 잘 살아있고 사용 시 불편함이 없는 상태가 되고, firebase에서 aws로 데이터 이전에 실패한 경우에는 유저가 앱을 지우고 다시 깔았을 때 예전 정보들이 다 유실되어있고 사용 시 불편함이 매우 큰 상태가 된다.
이러하기 때문에 전 서버에서 새로운 서버로 데이터 이전에 실패할 경우, 앱 신뢰도와 앱 사용자를 전부 다 잃을 수 있는 막대한 리스크가 생긴다.
이때문에 개발자라면 이런 최악의 상황에 대비를 꼭 해놔야하고 나도 그래서 어젯밤 내내 고민해서 이 상황에 대한 나름의 대비책을 내놨다.
내 앱의 경우, 유저가 꼭 필요한 데이터는
- 보호센터가 올리는 동물 사진
- 보호센터가 올리는 동물 정보
- 보호센터가 올리는 봉사활동 일정
인데, 서버가 마이그레이션 되더라도 유저가 꼭 필요한 데이터는 무조건 사수해야 앱 신뢰도와 앱 사용자를 지킬 수 있다.
근데 내 앱의 경우, 유저가 꼭 필요한 데이터는 모두 보호센터가 올리는 데이터들이었으므로 나는 몇달 전부터 보호센터 앱에서 동물 사진, 동물 정보, 봉사활동 일정을 전 서버(firebase)에도 올리고 새로운 서버(aws)에도 올리는 방법을 생각해냈다.
이렇게 되면 서버 마이그레이션하며 피치못하게 데이터 유실이 있어도 꼭 필요한 데이터들은 새로운 서버에 올라가게 되어서 최악의 상황은 모면할 수 있게되는데 그리하면 유저가 화나서 앱을 완전히 삭제해버리고 보호센터의 신뢰도 잃는 일을 최소화시킬 수 있다.
이게 가능한 것은 내 앱이 특수하게 유저용, 보호센터용으로 나누어져있고 내가 보호센터와 긴밀히 협력하고 있는 구조이기 때문인데 내가 만약 다른 앱을 개발했다면 이렇게 대비책이 나오기 어려웠을 거 같다.
요약하자면 서버 마이그레이션하며 피치못하게 데이터 유실이 있을 것 같다는 판단이 들면 몇달 전, 내가 보호센터 선생님께 연락을 드려 ‘앱 업데이트 한번만 해주세요’ 부탁드리고 업데이트 된 앱에서 보호센터 데이터들을 전 서버와 새로운 서버 둘 다에 올리도록 하는 것이 최선이겠다.
물론 내가 직접적으로 소통할 수 없는 유저들의 경우, firebase에서 aws로 데이터 이전이 안되는 최악의 경우에는 그들의 정보(회원가입 정보, 봉사활동 예약 내역)를 모두 잃을 수 있지만 그 부분은 앱에 미리 공지를 올리는 식으로 해결할 생각이다.
유저용 앱에 ‘불편을 드려서 정말 죄송하다, 서버를 대대적으로 옮겨서 재회원가입과 센터에 봉사활동 신청한 분이면 다시 신청해야한다’고 공지를 띄우는 것이 최선일 것 같아 보인다.
이것도 마이그레이션 3주 전이나 2주 전부터 미리 공지를 띄워서 공지를 받지 못한 유저가 없도록 할 예정이다.
내가 지금 당장 aws로 이전하지 않는 이유
사실 이렇게 궁극적으로 aws를 사용할 계획이 있다면 어찌보면 기회비용이 가장 작은 지금, 앱이 새싹 단계여서 리스크가 가장 작을 때 하는 게 제일 나을 수 있다고 생각하긴 하지만
나는 현재
- 내 아이디어 검증 및 유저 & 센터가 필요한 기능들을 계속 테스트해보며 앱을 안정화시켜야하고
- 창업을 했기 때문에 사실 기술적인 부분 말고도 마케팅, 센터와의 소통 등도 해야한다.
이걸 나 혼자 해야하기 때문에 내가 지금 백엔드 작업이 전혀 필요 없는 firebase를 사용하는 것은 큰 이득이며 내가 사람들의 니즈를 충족시킬만한 서비스를 더 잘 만들 수 있게 해준다고 생각한다.
그리고 솔직히 말하면, 당장 aws로 이전하기도 어렵다. 나는 aws 사용에 대해 모르는 것들이 많기 때문에 사전 공부가 필요하며 공부를 한 후, aws로 서버를 이전시키는 게 가장 바람직해보인다.
이런 이유로 지금은 firebase를 이용하여 개발을 계속 이어나갈 예정이고 추후 DAU(일일 활성 방문자 수)가 어느정도 넘어가면 그때는 aws로 서버 이전을 고려해볼 생각이다.
위에는 firebase에서 aws로 데이터 이전이 안 될 때, 그 최악의 경우만을 적어놨는데, 실질적으로 마이그레이션 할 때는 데이터 이전이 가능한 것들이 많아서 마이그레이션이 좀 쉽길 바란다(아직 적극적으로 안 찾아봐서 잘 모르겠다).
보오 앱이 잘돼서 firebase에서 aws로 마이그레이션할 때 또 글을 써보겠다.