팀 프로젝트: 글로벌 노마드

판매자와 체험자가 공존하는 체험 예약 플랫폼인 '글로벌 노마드' 프로젝트를 완료했다. Next.js App Router 환경에서 캘린더와 지도 뷰 SDK를 활용하는 것을 목표로 시작한 프로젝트다. 개발을 진행하며 직면했던 문제와 해결 과정을 START 기법으로 정리한다. Situation (상황) 4명의 프론트엔드 개발자가 협업하여 플랫폼을 구축했다. Gi

Next.js App Router 환경에서 마이페이지 프로필 수정 기능을 구현하던 중 데이터 동기화 문제를 겪었다. 서버 컴포넌트에서 유저 정보를 프리패칭(Pre-fetching)하여 클라이언트 컴포넌트로 넘기고, 클라이언트에서는 React Query와 Zustand를 이용해 상태를 관리하는 구조였다. 닉네임이나 프로필 이미지를 변경하는 API 호출이 성공

체험 신청 내역 모달을 구현하던 중, 전달받은 디자인 시안의 컴포넌트 배치에 어색함을 느꼈다. 코드를 작성하며 데이터 흐름을 살펴보니 기존 구조는 사용자의 인지 흐름과 맞지 않는다고 판단했다. 결과적으로 디자인 시안의 배치를 임의로 수정하여 구현했다. 변경 전후 비교는 다음과 같다. | Before (기존 시안) | After (개선된 UI) | | :--

현재 개발 중인 서비스에는 사용자의 입력을 받고 그 값을 검증해야 하는 폼(Form) 인터페이스가 유독 많았다. 아이디와 비밀번호 단 2가지만 입력받는 간단한 로그인 폼부터, 제목, 카테고리, 설명, 가격 등 9개가 넘는 필드를 꽉꽉 채워야 하는 '내 체험 등록' 기능까지 폼의 규모도 다양했다. 초기에는 컴포넌트 내부에 개별적인 상태를 두고 조건문으로 필드

Next.js App Router를 도입한 가장 큰 이유는 서버 컴포넌트(RSC)를 활용한 프리렌더링(Pre-rendering)과 이를 통한 SEO 최적화였다. 하지만 프로젝트를 진행하던 중 인증이 필요한 데이터를 서버 컴포넌트에서 페칭하려 할 때 구조적인 한계에 부딪혔다. 기존 인증 로직은 로그인 성공 시 발급받은 액세스 토큰과 리프레시 토큰을 브라우저의

Tailwind CSS를 사용해 재사용 가능한 UI 컴포넌트를 설계하다 보면 조건부 스타일링 처리에서 한계에 부딪힌다. 템플릿 리터럴과 삼항 연산자가 중첩되면서 코드가 지저분해지는 것은 물론이고 가장 큰 문제는 클래스 우선순위 충돌이다. 컴포넌트 내부에 기본 여백(p-4)을 설정해 두었는데 외부에서 props로 새로운 여백(p-8)을 주입할 경우 두 클래스