[런치캐치 개발일지 #5] 로그인 흐름과 스와이프 피드

About this offer

오늘은 사용자 앱의 입구(스플래시 → 로그인 → 온보딩)와 핵심 화면인 스와이프 피드를 만들었다. API 연동 전이라 로그인과 피드 데이터는 모두 mock이다. 0. 작업 방식: Figma MCP로 디자인 읽기 이번 작업은 Claude Code에 Figma MCP를 연결해서 진행했다. 화면을 만들 때마다 Figma 링크의 노드를 읽어서, 크기·색·글자 스펙을 눈대중이 아니라 실제 값으로 가져왔다. 활용 방법 화면 스펙 읽기: 노드를 읽으면 요소별 크기, 여백, 색 토큰, 글자 크기가 나온다. 예를 들어 포스터 카드는 폭 328, 사진 높이 320, 모서리 12, 가게 이름 24px Bold처럼 정확한 값으로 확인했다. 디자인 시스템과 비교: 화면 값이 디자인 시스템 스케일에 있는지 확인했다. 화면은 좌우 여백 20px인데 그리드는 16px이고, 버튼 모서리 14px은 Radius 스케일(4, 8, 12, 16)에 없었다. 이런 경우는 디자인 시스템 기준으로 맞췄다. 디자인 수정: 스플래시 버튼 삭제처럼 Figma 자체를 고칠 때는 Codex에 Figma MCP 작업을 맡겼다. 이 과정에서 화면만 봤다면 지나쳤을 불일치도 꽤 찾았다. 성별 선택 칩 중 "기타"가 레이어 이름은 아직 "입력 안 함"이고 스타일도 달랐다. 마스코트 컴포넌트 이름이 Coupon Success 인데, 실제 그림은 X 표시된 쿠폰(쿠폰 없음)이었다. 디자인 시스템 안에서도 Button 컴포넌트(모서리 14)와 Radius 스케일이 서로 달랐다. 코드에서는 모두 디자인 시스템 기준으로 맞춰서 구현했다. 1. 로그인 흐름 로그인 상태 관리 (Context) 로그인한 사용자 정보는 라우트 가드, 온보딩 완료 처리, 마이페이지 등 여러 화면에서 필요하다. props로 한 단계씩 내려주면 중간 컴포넌트가 쓰지도 않는 값을 계속 넘겨야 한다. 그래서 React Context로 앱 전체에 공유했다. 파일 역할 authContext.ts 로그인 정보가 지나갈 통로를 만든다 AuthProvider.tsx 실제 값( useState )을 들고 아래로 전달한다 useAuth.ts 화면에서 const { user, login } = useAuth() 로 꺼내 쓴다 AuthProvider 를 앱 가장 바깥에 두니, 어느 화면에서든 로그인 정보를 바로 받을 수 있게 됐다. 상태별 라우트 가드 사용자 상태를 세 가지로 나눴다. 상태 갈 수 있는 화면 다른 화면에 들어오면 로그인 전 스플래시, 로그인 스플래시로 이동 온보딩 중 온보딩 온보딩으로 이동 회원 탭 화면 스와이프로 이동 화면마다 조건을 넣지 않고, 라우터에서 화면 묶음 단위로 감쌌다. { element: <RequireAuth access="guest" />, children: [스플래시, 로그인] }, { element: <RequireAuth access="onboarding" />, children: [온보딩] }, { element: <RequireAuth access="member" />, children: [탭 화면] }, 앞으로 화면을 추가할 때는 알맞은 묶음 안에 넣기만 하면 된다. 스플래시 화면 하단 버튼 삭제 처음 디자인은 스플래시에 [시작하기] 버튼이 있고, 버튼을 누르면 로그인 화면으로 넘어가는 구조였다. 그런데 로그인 화면에도 소개 문구와 [카카오로 시작하기] 버튼이 있어서, 사용자는 비슷한 화면을 두 번 보고 버튼도 두 번 눌러야 했다. 스플래시는 앱을 열 때 브랜드를 잠깐 보여주는 화면이면 충분하다고 판단했다. 그래서 버튼을 없애고, 1.5초 뒤 로그인 화면으로 자동으로 넘어가게 했다. 넘어갈 때는 replace 로 이동해서 방문 기록에서 스플래시를 지웠다. 로그인 화면에서 뒤로 가기를 눌러도 스플래시가 다시 나오지 않는다. 2. 스와이프 피드 드래그 제스처 (Pointer Events) 일정이 빠듯해서 버튼으로 찜/패스를 먼저 완성하고, 드래그 제스처는 그다음에 붙였다. 제스처도 결국 같은 찜/패스 함수를 부르기 때문에, 버튼으로 동작을 먼저 확인해 두니 제스처는 "끌기와 방향 판단"만 추가하면 됐다. 제스처 라이브러리는 새 패키지라 팀 합의가 필요해서, 브라우저 기본 기능인 Pointer Events로 직접 만들었다. onPointerDown // 시작 위치 기억 onPointerMove // 움직인 만큼 카드 이동, 살짝 기울이기 onPointerUp // 카드 폭의 30% 넘게 밀었으면 찜/패스, 아니면 제자리로 touch-action: pan-y 를 줘서 위아래로 끌면 화면이 스크롤되고, 좌우로 끌 때만 카드가 움직이게 했다. 화면 높이에 맞춘 카드 크기 이 부분에서 시행착오가 있었다. 고정 높이: Figma대로 카드 높이를 고정했더니, 긴 폰에서 카드 아래가 130px 정도 비었다. 남는 공간 채우기: 카드가 남는 높이를 모두 차지하게 했더니, 이번엔 사진이 세로로 길쭉해졌다. 4:5까지만: 사진이 4:5 비율까지만 늘어나게 제한하고, 남는 공간은 카드 묶음 위아래로 나눴다. <div className="@container ..."> <div className="max-h-[calc(125cqw+10.5rem)] flex-1 ..."> 125cqw 는 컨테이너 폭의 125%라서, 사진 높이가 폭 × 1.25를 넘지 않는다. 짧은 폰에서는 사진이 줄어서 스크롤 없이 한 화면에 들어가고, 긴 폰에서도 길쭉해지지 않는다. 찜 피드백 (배지와 토스트) 찜을 해도 카드만 넘어가서 저장됐는지 알기 어려웠다. 그렇다고 스와이프는 연속으로 하는 동작이라, 찜할 때마다 알림을 띄우면 방해가 된다. 그래서 두 가지로 나눴다. 헤더 찜 개수 배지: 찜할 때마다 숫자가 늘면서 살짝 튄다. 방해 없이 쌓이는 게 보인다. 첫 찜에만 토스트: 그날 처음 찜했을 때만 "찜 목록에 담았어요 · 11:00부터 받을 수 있어요"를 띄운다. 런치캐치에서 찜은 발급이 아니라 11:00 선착순에 참여하는 것이라, 이 규칙을 처음에 한 번 알려주는 게 중요했다. 느낀 점 이번 작업에서 Figma MCP를 써보니 정말 편했다. Claude Code가 Figma를 직접 읽어 들이고, 그 내용을 바탕으로 코드를 짠다는 게 신기했다. 디자인을 보고 크기와 색을 하나하나 옮겨 적던 과정이 줄어들면서, 개발이 훨씬 편해지고 있다는 게 느껴졌다. 오늘 작업 중 겪은 의존성 문제는 런치캐치 트러블슈팅 #1 에 따로 정리했다.