Flutter와 NestJS로 Froppy를 만들며 배운 것
2시간 전
Froppy는 스포츠 선수와 팬을 연결하는 커뮤니티로 시작했습니다.
선수는 활동을 기록하고, 팬은 팔로우와 좋아요를 통해 응원하며, 이후에는 멤버십으로 연결되는 구조를 만들고 싶었습니다.
처음에는 이렇게 생각했습니다.
화면을 만들고 API만 연결하면 서비스가 완성되지 않을까?
직접 만들어보니 가장 재미있었던 것도, 가장 어려웠던 것도 기능들이 서로 연결되는 순간이었습니다.
가장 재미있었던 순간
Flutter로 화면을 만들고 NestJS API에서 데이터를 받아왔을 때, 아이디어가 실제 서비스처럼 움직이기 시작했습니다.
-
회원가입한 사용자가 프로필을 만들고
-
게시물을 작성하면 피드에 나타나고
-
다른 사용자를 팔로우하면 관계가 저장되고
-
좋아요를 누르면 숫자가 바뀌는 과정
각각은 작은 기능이지만, 서로 연결되자 비로소 하나의 커뮤니티처럼 보였습니다.
특히 Flutter의 Hot Reload는 수정한 화면을 바로 확인할 수 있어 개발 자체가 꽤 재미있었습니다.
로그인은 버튼 하나가 아니었다
이메일과 Google, Kakao, Naver 로그인을 지원하려고 했습니다.
사용자에게는 로그인 버튼 하나지만, 내부에서는 생각할 것이 많았습니다.
-
소셜 서비스마다 다른 사용자 정보
-
이메일이나 프로필이 없는 경우
-
기존 회원과 소셜 계정의 중복 처리
-
토큰 저장과 만료
-
앱을 다시 실행했을 때 로그인 유지
이때 처음 알았습니다.
사용자에게 단순해 보이는 기능일수록 개발자는 더 많은 경우를 처리해야 한다.
좋아요도 숫자 하나를 올리는 일이 아니었다
좋아요 버튼을 누르면 화면은 즉시 반응해야 합니다.
하지만 서버 저장에 실패하면 어떻게 해야 할까요?
화면에서 먼저 숫자를 올리면 빠르게 느껴지지만, 서버 요청이 실패하면 다시 되돌려야 합니다. 사용자가 버튼을 연속으로 누르면 중복 요청도 막아야 합니다.
작은 버튼 하나에도 다음이 필요했습니다.
화면 상태 + 서버 데이터 + 중복 요청 방지 + 실패 복구
빠른 화면과 정확한 데이터 사이에서 균형을 맞추는 일이 생각보다 어려웠습니다.
팔로우를 만들자 피드가 복잡해졌다
팔로우 관계를 저장하는 것까지는 단순했습니다.
문제는 그다음이었습니다.
-
팔로우한 사람의 글만 보여줄 것인가
-
최신 글과 추천 글을 어떻게 섞을 것인가
-
팔로우 취소 시 피드를 즉시 바꿀 것인가
-
게시물이 많아지면 어떻게 나눠 불러올 것인가
기능 하나를 추가할 때마다 다른 기능의 설계까지 달라졌습니다.
이 과정은 어렵기도 했지만, 커뮤니티 서비스의 구조를 직접 이해해가는 재미도 있었습니다.
가장 어려웠던 것은 정상 동작이 아니었다
개발 초반에는 기능이 성공하는 경우만 생각했습니다.
하지만 실제 서비스에서는 실패하는 경우가 더 중요했습니다.
로그인이 만료됐을 때 네트워크가 끊겼을 때 이미지 업로드가 중단됐을 때 같은 버튼을 여러 번 눌렀을 때 결제 결과가 서버와 다를 때
화면을 만드는 것은 비교적 빨랐지만, 실제로 사용할 수 있는 서비스로 만드는 것은 수많은 예외를 처리하는 일이었습니다.
Froppy를 만들며 배운 것
Froppy를 정식 서비스로 성장시키지는 못했지만, 프론트엔드와 백엔드가 연결되는 전체 과정을 직접 경험했습니다.
그리고 한 가지를 분명히 배웠습니다.
서비스는 기능을 많이 추가해서 완성되는 것이 아니라, 작은 실패를 하나씩 해결하면서 완성된다.
완성된 결과보다도, 아이디어가 데이터와 화면으로 연결되고 실제로 움직이기 시작했던 과정이 가장 재미있었습니다.
Froppy는 멈춘 프로젝트지만 아이디어가 데이터와 화면으로 연결되고, 실제로 움직이는 서비스를 처음부터 끝까지 만들어본 경험은 남았습니다.
다음 서비스를 만들 때도 저는 기능의 수보다, 사용자가 겪을 작은 실패를 먼저 살펴보려 합니다.