마이페이지 활동관리를 4개 서브탭으로 분기하고 리뷰 폼 추가

마이페이지 활동관리 탭을 4개 서브탭으로 분기하고, 리뷰 작성/수정 페이지까지 한 번에 붙인 커밋이었다.

왜 이 구조로 잡았나

활동관리를 단일 페이지로 때우는 건 초기에야 괜찮지만, 콘텐츠 종류가 늘어나면 결국 탭 분기는 피할 수 없다. 이번에 recent(최근 본 항목) / review(리뷰) / inquiry(문의) / wish(찜/북마크) 4개로 나눈 건 사용자가 본인 활동을 목적 단위로 바라볼 수 있게 하기 위해서였다. 한 페이지에 다 때려넣으면 개발자 입장에서 조회 쿼리가 한꺼번에 날아가고, UX 입장에서도 스크롤이 길어져서 찾고 싶은 데이터를 못 찾는 문제가 생긴다.

탭 전환을 클라이언트 사이드에서 처리할지, 서버사이드 요청으로 처리할지는 항상 고민 지점이다. 이번 구조는 서버에서 탭 파라미터를 받아 컨트롤러(내부 클래스)에서 분기하는 방식으로 갔다. SPA 전환 애니메이션 같은 건 없지만, 북마크(즐겨찾기) URL로 특정 탭에 바로 접근할 수 있는 게 이 방식의 장점이다.

변경 파일별로 뭘 건드렸나

CSS 파일이 두 경로(css/sites/, css/slecs/sites/)에 중복으로 있는 건 빌드 파이프라인 구조 때문이고, SCSS 소스는 scss/sites/_viaggioone.scss에서 관리하되 컴파일된 결과물이 두 경로로 나가는 구조로 이해하면 된다. 이런 이중 경로는 나중에 정리가 필요한 기술 부채지만, 지금 당장 손대면 다른 페이지 스타일까지 영향을 주기 때문에 일단 놔뒀다.

리뷰 폼, 작성/수정 공용 설계

reviewForm.jsp 하나로 작성과 수정을 모두 처리하는 건 흔한 패턴이지만, 실수가 자주 나오는 지점이기도 하다.

<%-- reviewSeq가 있으면 수정, 없으면 신규 작성 분기 --%>
<c:choose>
  <c:when test="${not empty reviewForm.reviewSeq}">
    <input type="hidden" name="reviewSeq" value="${reviewForm.reviewSeq}" />
    <%-- 수정 모드: 기존 데이터 pre-fill --%>
  </c:when>
  <c:otherwise>
    <%-- 작성 모드: 빈 폼 --%>
  </c:otherwise>
</c:choose>

이런 식으로 reviewSeq 유무로 분기하는 건 간결한 반면, 폼 유효성 검증 로직이나 서버 컨트롤러의 저장/수정 엔드포인트를 명확히 분리해두지 않으면 한쪽 케이스를 수정했을 때 다른 케이스가 깨지는 사고가 난다. 특히 파일 첨부나 이미지가 붙는 폼이면 수정 시 기존 파일 처리 로직이 복잡해지니까 초기에 케이스를 명확히 정의해두는 게 낫다.

서브탭 구조에서 챙겨야 할 것들

이번 작업 마치고 나서 팀 내부에서 짧게 리뷰했던 포인트들 정리해두면:

• 탭 간 상태 유지: 페이지 이동 후 돌아왔을 때 이전에 보던 탭으로 복귀되는지 — 이번엔 URL 파라미터로 탭 상태를 명시하기 때문에 히스토리 백도 자연스럽게 된다
• 각 탭 데이터의 로딩 시점: 탭 클릭 시마다 서버 요청이 나가는 구조면 첫 진입에서 불필요한 쿼리를 막을 수 있지만, 반대로 탭 전환마다 로딩이 보이는 UX 비용이 생긴다
• wish(북마크) 탭과 bookmarkList.jsp 연결: 북마크는 다른 탭과 달리 본인이 누른 외부 항목에 대한 참조이므로, 항목이 삭제됐을 때 dangling reference 처리가 필요하다 — 이건 후속 작업으로 남김
• SCSS 변경 범위: _viaggioone.scss는 이 사이트 전용 partial이라 다른 사이트 스타일에 영향은 없지만, 탭 컴포넌트 스타일을 사이트 전용 파일에 때려넣으면 나중에 공통 컴포넌트화할 때 발목 잡힌다

탭 하나하나가 독립된 도메인 데이터를 가지다 보니, 이번 커밋 하나에 컨트롤러 + 뷰 2개 + 스타일 3개가 묶여서 들어갔다. 커밋 단위로는 좀 크게 묶인 감이 있는데, 탭 구조를 한 번에 맞추지 않으면 중간 상태에서 탭은 있는데 데이터가 안 붙어있는 UI가 잠깐 노출될 수 있어서 의도적으로 한 덩어리로 올렸다. 이런 "UI 완결성을 위한 묶음 커밋"은 종종 필요한 선택이다.

끝.