런덤메이트로 프론트엔드 시야를 넓히다

회사에서는 백엔드·서버 운영에 집중하다 보니, 프론트엔드는 “API를 어떻게 소비하는지”를 짐작만 하는 위치에 머물러 있었습니다. 이 감각을 직접 채워보고 싶어서 2026년 1월부터 5월까지, GPS 러닝 기록과 크루 커뮤니티, 실시간 채팅, 랭킹·챌린지 기능을 갖춘 소셜 러닝 앱 “런덤메이트”를 기획부터 App Store 출시까지 만들었습니다.

백엔드에서 보던 실시간 통신을 프론트에서 다시 만나다

회사 프로젝트에서는 Redis Pub/Sub·Stream으로 서버 쪽 실시간 배포 구조를 설계했지만, 그 값이 클라이언트에 도착한 뒤 화면에 그려지기까지의 과정은 프론트엔드 팀원의 영역이라 깊게 들여다볼 기회가 없었습니다. 런덤메이트에서 WebSocket 기반 1:1·크루 채팅을 직접 구현하면서, 연결이 끊겼다가 재연결될 때 메시지 순서를 어떻게 맞춰야 하는지, 소켓 연결 상태를 UI에 어떻게 반영해야 사용자가 헷갈리지 않는지 같은, 서버 쪽에서는 신경 쓰지 않던 문제들을 처음으로 마주했습니다.

화면이 늘어날수록 상태 관리가 중요해졌다

팔로우·크루 소셜 그래프, 게시판·댓글, 영역점령·랭킹·대회 기능, 주간·월간·연간 통계 차트까지 화면이 늘어나면서, 여러 화면이 같은 데이터(예: 내 팔로우 목록, 크루 멤버 상태)를 서로 다른 시점에 참조하는 문제가 생겼습니다. 백엔드에서 캐시 무효화를 설계하던 경험이 여기서도 그대로 적용됐습니다 — “이 데이터가 바뀌면 어떤 화면들이 다시 그려져야 하는가”를 먼저 정리하고, 그 기준으로 상태를 어디에 둘지 결정하는 방식이었습니다.

기획부터 출시까지 완주하며 배운 것

커밋 127건, 변경 파일 402개, 머지 PR 40건 이상을 쌓으며 기획-개발-출시를 혼자 완주했습니다. 백엔드 개발자로서 API 설계는 익숙했지만, 스토어 심사 기준에 맞춰 화면 흐름을 다듬고 실제 사용자 피드백을 반영해 우선순위를 조정하는 과정은 회사 업무에서는 접하기 어려운 경험이었습니다. 이 프로젝트를 통해 “내가 만드는 API가 화면에서 실제로 어떻게 소비되는가”를 체감했고, 이후 회사 업무에서 API를 설계할 때도 응답 구조를 프론트 입장에서 한 번 더 검토하는 습관이 생겼습니다.