모바일? 웹?

모바일 🤔? 웹 🤔?

개발을 시작하기 전에 꼭 논의해야 할 것들 중 하나가 모바일 레이아웃으로 진행할지, 웹 레이아웃으로 진행할지 였다.

물론 N-Screen에 대한 요구사항이 있기 때문에, 두 버전 모두 완성한다는 마음가짐으로 임하겠지만...

학습에 사용할 시간도 고려한다면, 두 가지 버전을 완벽하게 해내는 것은 힘들수도 있다고 판단하였다.

하나의 버전만 완성 될 수 있다는 점을 염두에 두었을 때

모바일 레이아웃으로 개발을 시작할지, 웹 레이아웃으로 개발을 시작할지는 매우 중요한 고민이었다.

🧭 기존 선택들과의 연계

위와같이 장단점이 뚜렷한 두 선택지로부터 결정을 내리는 것은 매우 힘들다.

많은 에너지를 쏟고, 고민해 보아도 완벽한 결정을 내릴 수 없기 때문이다.

이럴때는 외부조건을 개입시켜서, 어느정도 밸런스를 깨주어야 선택하기가 쉬워진다.

우리는 기존의 선택사항들을 고려하여, 웹 기반으로 시작하기로 하였다.

📌 웹을 선택한 이유

1️⃣ 많은양의 타이핑이 필요할 경우, 모바일 환경보다는 웹 환경이 편리할 것이라 생각하였다.

실제 서비스되고 있는 사례들을 고려해보거나, 편의성 또는 접근성을 생각한다면 분명 모바일 레이아웃이 맞는 선택같았다.

하지만, 은행 연동을 지원하지 않는다 는 앞서 결정했던 전제를 생각해보면 이야기가 조금 달라졌다.

은행이 연동되지 않는다는 것은 사용자가 모두 직접 타이핑 해야 하는것을 의미했다.

만약 수입이 발생하는 즉시, 또는 지출이 발생하는 즉시 가계부를 꼬박꼬박 작성한다면 불편함이 덜 하겠지만...

일반적으로는, 어느정도 기간동안의 수입 또는 지출을 몰아서 작성하는 경우가 대다수 일 것이라고 생각했다.

이렇게 직접 타이핑하는 양이 많아지는 경우에는 아무래도 웹 환경이 편리하다고 판단하였다.

2️⃣ csv형태의 데이터를 import하거나 export하는 기능 요구사항이 있었다.

모바일 환경에서의 csv파일이 어떻게 관리되는지 자세히 알지는 못하지만

웹 환경에서는 이러한 기능이 자연스럽게 이루어진다고 생각하였다.

3️⃣ 인터랙티브한 서비스

기존의 선택들 중 인터랙티브 한 서비스를 만들자라는 결정이 있었다.

쉽지 않겠지만, UX를 고려한 선에서 과하지 않은 애니메이션이나 이벤트들을 시도해볼 예정이었다.

따라서, 도화지(?)가 넓으면 좀 더 다양한 시도를 해볼 수 있을거라는 생각이 들었다.

4️⃣ 중요한건 통계였다.

가계부 서비스 자체에 대한 논의 중 이 서비스가 제공해야할 가장 핵심적인 데이터는 통계라는 결론이 있었다.

결국 가계부를 작성하는 행위는 데이터를 누적해나가고, 그로부터 시각적으로 쉽게 볼 수 있는 통계자료를 얻기 위함이었다.

사용자는 이 통계자료를 보며 이번달은 뭐가 이렇게 맛있었길래 식비를 잔뜩썼지? 식비좀 줄여야지...등의 자기반성을 할 수 있으며,

이번달은 저번달보다 지출이 현저하게 줄었네? 아... 코로나때문에 술을 안마시고 다녔구나... 그래 술을 줄여야지!등의 자기칭찬을 할 수도 있다.

결론적으로 통계로부터 새어나가는 돈을 막고, 소비패턴을 확립해 나갈 수 있는 것이다.

이렇게 중요한 통계 데이터를 좀 더 인터랙티브하게 표현하기 위해서는 아무래도 웹 환경이 유리할 것이라는 생각이 들었다.
(일자별 통계는 가로화면에 최대 31일까지가 표기되는 경우가 생기는데, 이럴땐 웹 환경이 좀 더 한눈에 보기 편할것 같다.)