프론트엔드 2명, 백엔드 3명으로 구성된 팀에서 PM·기획·디자인 직군과 협업했습니다. 프론트엔드 2명이 웹·앱·운영 도구를 공동 담당하며 최초 구현 영역과 코드 이해도에 따라 신규 개발과 유지보수를 나눴습니다.
지도 기반 탐색, 예약·결제 웹뷰, TRIT 어드민·TRIT 백오피스를 담당했습니다. 요구사항 검토부터 설계·구현, QA, PR 병합과 자동 배포, 배포 후 오류와 운영 요청 대응까지 참여했습니다.
세부 경험
1. 예약·결제 페이지 웹뷰 통합과 결제 흐름 연결
예약·결제 페이지는 파트너사마다 인원·추가 상품·쿠폰 조건이 달라 앱과 웹에 각각 구현하면 변경 지점이 함께 늘어나는 구조였습니다.
화면을 웹에서 관리하고 앱에서는 웹뷰로 제공하는 방향은 팀에서 결정했습니다. 저는 네이티브 인증 세션을 웹뷰에 전달해 사용하는 방식과 메시지 규격을 설계·구현했습니다. 날짜·인원·옵션·쿠폰 선택값을 결제 준비 요청값으로 변환해 표시 금액과 결제 요청 금액이 일치하도록 관리했습니다.
예약 데이터와 결제 준비 로직을 웹에 모아 앱의 중복 구현을 줄이고 상품 상세부터 예약·확인·결제까지 이어지는 웹뷰 흐름을 연결했습니다.
앱과 웹뷰를 연결한 예약·결제 흐름
2. 웹 플랫폼 401 인증 오류 처리 개선
비로그인 상품 상세에서 사용자 전용 쿠폰 API의 401을 세션 만료로 오인해 홈으로 이동하는 문제를 작업 중 발견했습니다.
HTTP 401만으로 세션 만료를 판단하지 않고, 백엔드가 정의한 토큰 만료 응답이 함께 온 경우에만 토큰을 갱신했습니다. 갱신에 성공하면 원 요청을 한 번만 다시 보내고, 인증 갱신과 TanStack Query의 재시도가 겹치지 않도록 기본 재시도를 비활성화했습니다.
Playwright로 수정 전 홈 이동을 재현하고 수정 후 같은 경로에서 상품 상세가 유지되는지 확인했습니다.
인증 만료와 비로그인 401을 구분한 처리 흐름
3. 지도 탐색 화면 구조화
지도 화면은 검색·상세·길찾기·즐겨찾기·코스 탐색이 섞여 있어 화면 전환과 뒤로가기 후 상태를 추적하기 어려웠습니다.
기존 화면을 확장하며 상태를 성격별로 분리했습니다. 공유 링크나 새로고침 후에도 복원돼야 하는 상태는 URL 쿼리 파라미터로, 하위 컴포넌트가 공유하는 장소·경로·코스는 React Context로, 센서·조작 값은 Zustand로 관리했습니다.
URL만으로 화면 상태를 복원할 수 있게 됐습니다. 디버깅과 기능 추가 시 영향 범위도 좁아졌습니다. 배포 후 선택 마커의 재클러스터링과 길찾기 경로 잘림 피드백을 반영하고 같은 동선으로 재검증했습니다.
URL·React Context·Zustand로 분리한 지도 상태 구조
4. 파트너 운영 도구 개선
4-1. 필수 설정 체크리스트
QA 과정에서 영업시간·환불 정책·메시지 등 필수 정보를 작성하지 않은 파트너사를 확인했습니다.
홈 대시보드 체크리스트를 제안·구현해 미완료 항목을 먼저 보여주고 각 설정 화면으로 바로 이동할 수 있게 했습니다. 완료 상태가 바뀌는지, 모든 항목을 완료하면 카드가 사라지는지 테스트 계정으로 확인했습니다.
파트너 필수 설정 완료 여부를 보여주는 체크리스트
4-2. 환불 정책 설정 개선
환불 정책은 “7일 전 100%, 5일 전 50%”처럼 파트너가 입력하는 기준 규칙과 실제 저장되는 날짜별 정책이 어긋나기 쉬운 구조였습니다.
기준 날짜와 환불률만 입력하도록 단순화하고 중복 날짜·환불률 범위·날짜 순서를 검증해 저장 전 결과를 미리 볼 수 있게 했습니다. Playwright로 생성·수정·삭제 흐름과 입력값이 날짜별 요청 데이터로 정확히 확장되는지 네트워크 요청에서 검증했습니다.
