WithTime: 데이트 코스 추천 서비스를 FE 리드로 완성한 과정

1. 프로젝트는 사용자 불편에서 시작됐다

WithTime은 데이트를 할 때마다 어디를 갈지 반복해서 고민해야 하는 불편에서 출발한 서비스입니다.
사용자는 예산, 지역, 선호 분위기 같은 조건을 조합해 코스를 찾고 싶지만, 실제로는 선택지가 많을수록 오히려 결정이 더 어려워집니다.

이 프로젝트의 목표는 단순했습니다.

저는 이 프로젝트에서 프론트엔드 리드 역할을 맡았습니다.

팀원 대부분이 첫 프로젝트 경험이었고, 함께 작업하던 사람들 중에는 이전에 제가 직접 스터디를 진행했던 팀원도 많았습니다.
그래서 이번 프로젝트에서 가장 중요했던 것은 "최신 기술을 많이 넣는 것"이 아니라, 팀이 끝까지 따라올 수 있는 구조를 만드는 것이었습니다.

제가 세운 기준은 다음과 같았습니다.

결과적으로 React, Zustand, Tailwind CSS, Firebase 중심으로 구조를 잡았고,
복잡한 보일러플레이트 없이 빠르게 완성도를 올릴 수 있는 방향을 택했습니다.

제가 직접 맡은 주요 기능은 다음과 같았습니다.

특히 이 서비스는 "추천"이 핵심이었기 때문에, 화면 구현보다도 상태가 어떻게 이어지는지가 더 중요했습니다.
사용자가 필터를 입력하고, 결과를 보고, 다시 조건을 조정하고, 인증 이후에도 흐름이 끊기지 않아야 했기 때문입니다.

WithTime에서는 사용자의 입력 조건이 여러 화면에 걸쳐 재사용됐습니다.
예산, 장소, 식사 유형, 이동수단, 선호 키워드, 시간대 같은 조건은 추천 결과를 만들기 위한 재료이면서 동시에 사용자 경험의 연속성을 결정하는 데이터였습니다.

그래서 저는 상태 관리에서 다음을 우선했습니다.

이 기준 때문에 Zustand + persist 조합이 잘 맞았습니다.
상태는 가볍게 관리하되, 추천 플로우는 계속 이어지게 만들 수 있었기 때문입니다.

이 프로젝트를 하며 다시 확인한 점은, 전역 상태가 중요한 서비스일수록 "어떤 라이브러리를 썼는가"보다 "무엇을 어디까지 같은 상태로 볼 것인가"를 먼저 정해야 한다는 사실이었습니다.

인증도 단순히 로그인 성공 여부만 처리하는 식으로 보지 않았습니다.
소셜 로그인을 마친 뒤 사용자가 처음 들어온 사람인지, 이미 설정을 마친 사람인지에 따라 다음 화면이 달라져야 했기 때문입니다.

그래서 로그인 이후에는 사용자 상태를 기준으로 다음 흐름을 분기했습니다.

이 흐름 덕분에 인증이 추천 서비스의 초기 사용자 상태와 자연스럽게 이어졌고,
"로그인은 됐지만 다음에 뭘 해야 하는지 모르는" 상태를 줄일 수 있었습니다.

WithTime은 제가 처음으로 AWS 기반 프론트엔드 배포를 직접 경험한 프로젝트이기도 했습니다.

이 조합으로 실제 서비스를 배포했고, 중요한 점은 배포를 혼자만 아는 방식으로 끝내지 않았다는 것입니다.
팀원들도 같은 방식을 재현할 수 있도록 배포 과정을 문서화해 공유했습니다.

프로젝트를 하며 리드의 역할에 대해 다시 생각하게 됐습니다.
많이 구현하는 사람보다, 팀이 재현 가능한 방식으로 일할 수 있게 만드는 사람이 더 중요할 때가 많았습니다.

이 프로젝트에서 가장 크게 배운 것은 기술 선택도 협업 설계의 일부라는 점이었습니다.

WithTime은 단순한 데모데이 프로젝트가 아니라,
제가 "어떻게 팀 기준을 정하고, 어떻게 상태 흐름을 설계하고, 어떻게 지식을 남겨야 하는가"를 실전에서 배운 프로젝트였습니다.