지난 시간까지는 앱의 구조와 디자인에 대한 설계를 진행했었다. 그러나 기술적으로 과연 내가 구현하려는 아이디어가 실현 가능한지도 미리 확인하고 싶었다. 완벽하게 디자인을 한 후 기술적으로 구현 가능한지 확인한다면 이는 린 스타트업이라고 할 수 없다. 따라서 디자이너로서의 나는 잠시 멈추고 개발자로 돌아와서 기술로 해결하려는 문제가 무엇이고 어떤 기술을 사용하는 것이 가장 적합한지 확인하는 시간을 가져보았다.
요구사항 분석
일단 가장 중요한 요구사항은 일 단위 지출내역을 목표한 금액과 비교해서 예산을 수정하는 것이다. 예산은 사용자가 직접 입력하면 되지만(한 주가 지나면 소비내역을 반영해서 자동으로 수정되게 하고 싶다) 지출은 수동 입력과 카드 등 사용내역 수집 2가지 방법이 있다. 결제 내역은 금융결제원에서 제공하는 API를 사용하면 되지 않겠느냐고 막연하게 생각했었다. 그러나 확인해 보니 카드 청구서가 아닌 실시간 승인내역을 가져오는 것은 생각보다 쉽지 않았다. coocon혹은 codef API와 같은 솔루션을 계약 후 사용해야 될 것 같은데 당분간은 직접 입력 방식으로 해결해야 할 것 같다. 만약 계약 금액에 생각보다 너무 비싸면 다시 두 가지 방법이 있을 것이다.
- 직접 결제데이터를 가져올 수 있는지 알아본다. (카드사 스크래핑?)
- 자동 수집에 대한 기획을 pivot 한다.
이제 두 번째 큰 문제는 바로 결제내역을 보고 카테고리를 나눠야 한다는 점이다. 카드사용 내역의 특정 단어를 확인해서 이게 커피값인지, 아니면 음식점인지 확인해야 할까? 정말 막막한 부분이다. 이런 용도로 머신러닝을 사용해야 할까? 대학원 수업을 통해 답을 얻을 수 있기를 기대해본다.
요구사항을 정리하면 다음과 같다.
1. 사용자는 예산을 설정할 수 있다.
2. 설정된 예산은 지출 내역과 비교하여 주 단위로 자동 수정되어야 한다.
3. 지출 내역은 사용자가 직접 입력하거나 카드결제 내역을 수집하여 작성한다.
a. 지출 내역은 항목별로 자동 (혹은 수동) 분류가 가능해야 한다.
b. 지출 내역은 추가/삭제가 가능해야 한다.
c. 지출 내역은 지출일자, 금액, 이름, 사용카드? 정보가 필요하다.
4. 사용자는 상시 설정한 예산 대비 현재 사용가능 금액을 확인할 수 있어야 한다.
5. 사용자는 최소 3가지 카테고리에 대한 일별 예산 설정이 가능해야 한다. 이를 해결하기 위한 간단한 데이터 구조를 생각해 보았다.
1. 예산을 설정하면 사용자와 연결된 예산 스키마를 추가한다.
a. 예산은 주 단위로 진행 될 것이기 때문에 날짜 입력이 필요하다.
2. 지출 내역 또한 사용자와 연결된 컬럼을 추가해 수집한다.
a. 지출 내역은 결제건별로 일시, 금액, 이름, 결제수단, 업종코드?(가능하다면) 등으로 구성
b. 개별 지출 내역에 대한 CRUD 구현
3. 한 주가 마무리 되면 예산과 지출을 비교하여 수정 예산을 보여주어야 한다.
a. 수정 예산 계산이 어딘가에서 이루어져야 한다.
b. 추후 주간 보고서도 보여줄 예정
4. 예산을 소비와 비교해 상시 확인하려면 예산 - 지출을 상시 계산해야 한다.
a. 이를 그래프 등으로 시각화 하려면 데이터 가공이 필요할 수 있다.
5. 사용자가 일별 3개 항목의 예산을 따로 설정할 수 있으려면 역시 카테고리 분류가 필요할 것이다.기술스택
일단 앱을 개발하기 위한 몇 가지 옵션이 있을 것 같다.
1. 리액트 네이티브로 개발한다.
2. 네이티브 언어로 개발한다.
3. 플러터로 개발한다.
사실 다른 언어를 새로 배워서 공부할 겸 시작한 프로젝트라면 플러터에 도전해 보겠지만 지금은 너무 할 것이 많기 때문에 일단 리액트 네이티브로 개발해 보기로 한다. 플러터에 비해 사용성이 낮거나 너무 손이 많이간다는 이야기도 들었지만, 토스도 리액트 네이티브를 쓴다는 점에서 과연 기술은 개발자 나름이라는 생각이 들었다.
다음은 DB인데 이 부분은 정말 아무 감이 없었다. 첫 회사에선 플러터 + 파이어베이스 조합을 사용했었다. 매뉴얼도 구글스럽지만 내용은 전부 있었고 코드를 짜기에는 정말 큰 어려움이 없었던 기억이 있다. 그러나 가장 큰 문제는 바로 속도였다. 이상하게 어떤 데이터는 아예 2-3초 동안 오지 않았다. 사용하지 않으면 인스턴스를 스스로 꺼버리는 것이 문제라고 들었다. 그렇다면 다른 옵션은 무엇이 있을까?
- Firebase
- Realm
- SQLite
일단 Realm은 엄청 빠른 속도가 장점이라고 한다. MongoDB에 인수되었다고 하며 게다가 오픈소스다. 그렇다면 단점은 무엇일까? Auto-increment 기능이 없고 RAM 사용이 늘어난다? 라고 하는데 초반에는 큰 문제가 될 것 같지는 않았다. 그러하면 SQLite는 어떨까? 마찬가지로 Lightweight하고 무료라는 점이 비슷했지만 Max database size가 존재했고 관계형 DB라는 점은 앞으로 설계가 어떻게 바뀔지 몰라서 부담이었다.
결론적으로 React Native + TypeScript + Realm 조합으로 레포세팅을 진행해 보기로 하였다.
프로젝트 이름?
그런데 생각지도 못한 문제가 생겼다. 과연 이 프로젝트 이름은 무엇으로 해야 하는가? 아직 단 한 번도 생각해 본 적이 없었다. 결국 소비(혹은 save) + 내비게이션이라는 뜻으로 savi(세이비?)라고 지었다. 솔직히 이게 베스트는 아닐 것 같지만 추후 브레인스토밍을 통해 더 좋은 이름을 찾아보기로 하고 일단 개발 준비를 진행했다.
다음 글에선 데이터 스키마를 조금 더 구체화 시켜 보았습니다.
References
React Native Local Database For Super Smart Applications
