yunwoo-yu 님의 상세페이지[2팀 유윤우] Chapter 1-1. 프레임워크 없이 SPA 만들기

과제 체크포인트

배포 링크

https://yunwoo-yu.github.io/front_6th_chapter1-1/

기본과제

상품목록

상품 목록 로딩

  • 페이지 접속 시 로딩 상태가 표시된다
  • 데이터 로드 완료 후 상품 목록이 렌더링된다
  • 로딩 실패 시 에러 상태가 표시된다
  • 에러 발생 시 재시도 버튼이 제공된다

상품 목록 조회

  • 각 상품의 기본 정보(이미지, 상품명, 가격)가 카드 형태로 표시된다

한 페이지에 보여질 상품 수 선택

  • 드롭다운에서 10, 20, 50, 100개 중 선택할 수 있으며 기본 값은 20개 이다.
  • 선택 변경 시 즉시 목록에 반영된다

상품 정렬 기능

  • 상품을 가격순/인기순으로 오름차순/내림차순 정렬을 할 수 있다.
  • 드롭다운을 통해 정렬 기준을 선택할 수 있다
  • 정렬 변경 시 즉시 목록에 반영된다

무한 스크롤 페이지네이션

  • 페이지 하단 근처 도달 시 다음 페이지 데이터가 자동 로드된다
  • 스크롤에 따라 계속해서 새로운 상품들이 목록에 추가된다
  • 새 데이터 로드 중일 때 로딩 인디케이터와 스켈레톤 UI가 표시된다
  • 홈 페이지에서만 무한 스크롤이 활성화된다

상품을 장바구니에 담기

  • 각 상품에 장바구니 추가 버튼이 있다
  • 버튼 클릭 시 해당 상품이 장바구니에 추가된다
  • 추가 완료 시 사용자에게 알림이 표시된다

상품 검색

  • 상품명 기반 검색을 위한 텍스트 입력 필드가 있다
  • 검색 버튼 클릭으로 검색이 수행된다
  • Enter 키로 검색이 수행된다
  • 검색어와 일치하는 상품들만 목록에 표시된다

카테고리 선택

  • 사용 가능한 카테고리들을 선택할 수 있는 UI가 제공된다
  • 선택된 카테고리에 해당하는 상품들만 표시된다
  • 전체 상품 보기로 돌아갈 수 있다
  • 2단계 카테고리 구조를 지원한다 (1depth, 2depth)

카테고리 네비게이션

  • 현재 선택된 카테고리 경로가 브레드크럼으로 표시된다
  • 브레드크럼의 각 단계를 클릭하여 상위 카테고리로 이동할 수 있다
  • "전체" > "1depth 카테고리" > "2depth 카테고리" 형태로 표시된다

현재 상품 수 표시

  • 현재 조건에서 조회된 총 상품 수가 화면에 표시된다
  • 검색이나 필터 적용 시 상품 수가 실시간으로 업데이트된다

장바구니

장바구니 모달

  • 장바구니 아이콘 클릭 시 모달 형태로 장바구니가 열린다
  • X 버튼이나 배경 클릭으로 모달을 닫을 수 있다
  • ESC 키로 모달을 닫을 수 있다
  • 모달에서 장바구니의 모든 기능을 사용할 수 있다

장바구니 수량 조절

  • 각 장바구니 상품의 수량을 증가할 수 있다
  • 각 장바구니 상품의 수량을 감소할 수 있다
  • 수량 변경 시 총 금액이 실시간으로 업데이트된다

장바구니 삭제

  • 각 상품에 삭제 버튼이 배치되어 있다
  • 삭제 버튼 클릭 시 해당 상품이 장바구니에서 제거된다

장바구니 선택 삭제

  • 각 상품에 선택을 위한 체크박스가 제공된다
  • 선택 삭제 버튼이 있다
  • 체크된 상품들만 일괄 삭제된다

장바구니 전체 선택

  • 모든 상품을 한 번에 선택할 수 있는 마스터 체크박스가 있다
  • 전체 선택 시 모든 상품의 체크박스가 선택된다
  • 전체 해제 시 모든 상품의 체크박스가 해제된다

장바구니 비우기

  • 장바구니에 있는 모든 상품을 한 번에 삭제할 수 있다

상품 상세

상품 클릭시 상세 페이지 이동

  • 상품 목록에서 상품 이미지나 상품 정보 클릭 시 상세 페이지로 이동한다
  • URL이 /product/{productId} 형태로 변경된다
  • 상품의 자세한 정보가 전용 페이지에서 표시된다

상품 상세 페이지 기능

  • 상품 이미지, 설명, 가격 등의 상세 정보가 표시된다
  • 전체 화면을 활용한 상세 정보 레이아웃이 제공된다

상품 상세 - 장바구니 담기

  • 상품 상세 페이지에서 해당 상품을 장바구니에 추가할 수 있다
  • 페이지 내에서 수량을 선택하여 장바구니에 추가할 수 있다
  • 수량 증가/감소 버튼이 제공된다

관련 상품 기능

  • 상품 상세 페이지에서 관련 상품들이 표시된다
  • 같은 카테고리(category2)의 다른 상품들이 관련 상품으로 표시된다
  • 관련 상품 클릭 시 해당 상품의 상세 페이지로 이동한다
  • 현재 보고 있는 상품은 관련 상품에서 제외된다

상품 상세 페이지 내 네비게이션

  • 상품 상세에서 상품 목록으로 돌아가는 버튼이 제공된다
  • 브레드크럼을 통해 카테고리별 상품 목록으로 이동할 수 있다
  • SPA 방식으로 페이지 간 이동이 부드럽게 처리된다

사용자 피드백 시스템

토스트 메시지

  • 장바구니 추가 시 성공 메시지가 토스트로 표시된다
  • 장바구니 삭제, 선택 삭제, 전체 삭제 시 알림 메시지가 표시된다
  • 토스트는 3초 후 자동으로 사라진다
  • 토스트에 닫기 버튼이 제공된다
  • 토스트 타입별로 다른 스타일이 적용된다 (success, info, error)

심화과제

SPA 네비게이션 및 URL 관리

페이지 이동

  • 어플리케이션 내의 모든 페이지 이동(뒤로가기/앞으로가기를 포함)은 하여 새로고침이 발생하지 않아야 한다.

상품 목록 - URL 쿼리 반영

  • 검색어가 URL 쿼리 파라미터에 저장된다
  • 카테고리 선택이 URL 쿼리 파라미터에 저장된다
  • 상품 옵션이 URL 쿼리 파라미터에 저장된다
  • 정렬 조건이 URL 쿼리 파라미터에 저장된다
  • 조건 변경 시 URL이 자동으로 업데이트된다
  • URL을 통해 현재 검색/필터 상태를 공유할 수 있다

상품 목록 - 새로고침 시 상태 유지

  • 새로고침 후 URL 쿼리에서 검색어가 복원된다
  • 새로고침 후 URL 쿼리에서 카테고리가 복원된다
  • 새로고침 후 URL 쿼리에서 옵션 설정이 복원된다
  • 새로고침 후 URL 쿼리에서 정렬 조건이 복원된다
  • 복원된 조건에 맞는 상품 데이터가 다시 로드된다

장바구니 - 새로고침 시 데이터 유지

  • 장바구니 내용이 브라우저에 저장된다
  • 새로고침 후에도 이전 장바구니 내용이 유지된다
  • 장바구니의 선택 상태도 함께 유지된다

상품 상세 - URL에 ID 반영

  • 상품 상세 페이지 이동 시 상품 ID가 URL 경로에 포함된다 (/product/{productId})
  • URL로 직접 접근 시 해당 상품의 상세 페이지가 자동으로 로드된다

상품 상세 - 새로고침시 유지

  • 새로고침 후에도 URL의 상품 ID를 읽어서 해당 상품 상세 페이지가 유지된다

404 페이지

  • 존재하지 않는 경로 접근 시 404 에러 페이지가 표시된다
  • 홈으로 돌아가기 버튼이 제공된다

AI로 한 번 더 구현하기

  • 기존에 구현한 기능을 AI로 다시 구현한다.
  • 이 과정에서 직접 가공하는 것은 최대한 지양한다.

과제 셀프회고

이번 과제를 통해 Vanilla JavaScript만으로 완전한 SPA(Single Page Application)를 구현해보았습니다. 과제에서 제공된 참고 자료와 예시 코드들이 매우 매력적이었지만, 저는 의도적으로 현재까지 제가 이해하고 있는 개념만으로 도전해보기로 했습니다.

프레임워크 없이 직접 상태 관리, 라우팅, DOM 업데이트 로직을 구현하는 과정은 쉽지 않았습니다. 특히 일관된 상태 업데이트 흐름과 라우팅 시스템을 제대로 구축하지 못한 점에서 많은 어려움을 겪었습니다. 내부적으로 상태 변경 → 업데이트 또는 페이지 이동 → 업데이트와 같은 흐름을 명확하게 제어하지 못해, 중복 렌더링이나 예기치 못한 동작이 빈번히 발생했습니다.

과제를 마무리하면서 pnpm test를 통해 기능 단위 테스트는 모두 통과했지만, 전체 구조를 개편하고자 시도했을 때 이벤트 핸들링과 함수들이 적절히 분리되지 않은 탓에 하나의 변경이 여러 부분에 영향을 주는 상황을 마주하게 되었습니다. 결국 구조적 문제로 인해 개선을 완전히 이루지 못한 것이 아쉽게 느껴졌습니다.

하지만 이 경험은 제가 앞으로 코드를 작성할 때 단순히 동작만을 목표로 하기보다는 전체 구조와 흐름, 유지보수성까지 고려하며 신중하게 설계해야 한다는 경각심을 갖게 해주었습니다. 한 번의 실패처럼 느껴질 수 있는 순간이었지만, 개발자로서 성장할 수 있었던 아주 값진 시간이었습니다.

기술적 성장

새로 학습한 개념

Observer Pattern(옵저버 패턴) 에 대해 새롭게 학습했습니다. 상태 변화에 따라 UI를 자동으로 갱신하는 구조를 만들기 위한 이론적 기반으로서 옵저버 패턴이 어떻게 활용될 수 있는지 이해하게 되었고, 추후 프레임워크 없이 상태 관리를 구현할 때 유용하게 쓸 수 있는 개념이라는 것을 느꼈습니다. 실제 구현에는 적용하지 못했지만, 상태 변경 → UI 갱신 흐름의 일관성 확보를 위해 반드시 필요한 설계라는 점을 깨달았습니다.

기존 지식의 재발견/심화

이벤트 위임(Event Delegation) 은 실제 구현에 적용해보며 그 효율성과 유용함을 체감할 수 있었습니다. 동적으로 생성되는 요소에 일일이 이벤트 리스너를 붙이지 않아도 되고, 루트 요소에 한 번의 이벤트 바인딩으로 전체를 제어할 수 있어 코드의 간결함과 성능 측면 모두에서 이점을 확인할 수 있었습니다.

구현 과정에서의 기술적 도전과 해결

전체 SPA 아키텍처 구축 참고 자료 없이 처음부터 SPA의 전체 구조를 설계하는 것이 가장 큰 도전이었습니다. 라우팅 시스템, 상태 관리, 컴포넌트 시스템을 어떻게 연결할지 막막했지만, AI와의 대화를 통해 핵심 개념들을 학습하고 하나씩 직접 적용해보며 점진적으로 구조를 만들어갔습니다.

페이지 레벨 생명주기 관리 각 페이지 컴포넌트가 마운트/언마운트될 때의 상태 관리가 핵심 과제였습니다. MainPage.onMount 형태로 페이지 함수에 할당하여 Route 이동 시 인메모리 영역에 담아둔 현재 컴포넌트와 이전 컴포넌트를 기억하고 있다가 실행시켜주는 형태로 해결하였습니다.

자랑하고 싶은 코드

아쉽게도 정말 없습니다 🥲 이렇게까지 스파게티를 만들줄은 몰랐어요..

개선이 필요하다고 생각하는 코드

리팩토링이 필요한 부분

중복된 상태 초기화 로직, 하드코딩된 렌더링 호출, 이벤트 코드 분리, 메인 코어 시스템

코드 설계 관련 고민과 결정

컴포넌트 라이프사이클 패턴

React의 useEffect를 모방한 onMount/onUnmount 패턴을 도입했습니다. 처음에는 단순히 함수만 호출하려 했지만, 페이지 이동 시 상태 정리와 초기화가 필요하다는 것을 깨닫고 이 패턴을 선택했습니다.

고민했던 점:

  1. 함수에 메서드를 직접 할당하는 방식이 JavaScript적으로 자연스러운가?
  2. 클래스 기반 컴포넌트로 구현할지, 함수 + 메서드 방식으로 갈지

결정한 이유:

  1. Vanilla JS에서 클래스보다 함수가 더 가볍고 직관적
  2. 기존 함수형 컴포넌트 패턴과 일관성 유지

상태 초기화 전략 페이지 전환 시 상태를 어느 시점에 초기화할지 고민했습니다.

시도한 방법들:

  1. 페이지 진입 시에만 초기화 → 이전 페이지 상태가 잠깐 보이는 문제
  2. 페이지 이탈 시에만 초기화 → 뒤로가기 시 빈 화면 문제
  3. 현재 방식: 양쪽 모두에서 초기화 → 중복 코드 발생하지만 안정적 단 성능적으로도 별로며 일관되지 않음

학습 효과 분석

  • 가장 큰 배움이 있었던 부분

상태 관리의 복잡성 체감

단순해 보이는 전역 상태 관리를 직접 구현해보니 다음과 같은 문제들을 마주쳤습니다:

  1. 상태 변경 시 어떤 컴포넌트를 언제 리렌더링할지
  2. 상태 간의 의존성 관리 (예: 카테고리 변경 시 상품 목록 초기화)
  3. 메모리 누수 방지를 위한 정리 작업

이를 통해 Redux의 단방향 데이터 플로우나 React의 useState가 왜 그런 방식으로 설계되었는지 깊이 이해할 수 있었습니다.

프레임워크 없는 SPA의 한계와 가능성

  • 한계: 코드량이 많아지고 관리 포인트가 증가
  • 가능성: 번들 크기가 작고 커스터마이징이 자유로움

추가 학습이 필요한 영역

  1. 성능 최적화: Virtual DOM이나 배치 업데이트 없이도 성능을 향상시킬 수 있는 방법들
  2. 메모리 관리: 대규모 애플리케이션에서 메모리 누수를 방지하는 패턴들
  3. 상태 관리 패턴: Flux, Redux, MobX 등의 상태 관리 패턴들의 실제 필요성
  4. SPA를 구축하기 위한 패턴들: 옵저버 패턴, 배치업데이트 등
  5. 테스트 코드에 대한 학습: 테스트 코드가 원하는 바를 확실하게 알기위한 학습

과제 피드백

  • 테스트 환경 독립적인 환경 개선: 어떤 테스트는 환경이 공유되고 어떤 테스트는 환경이 공유안되는 부분 일관적이게 개선

과제에서 모호하거나 애매했던 부분

  • 테스트가 틀린건가 내가 틀린건가 헷갈릴때가 있었습니다!

과제에서 좋았던 부분

  • 처음으로 테스트 코드가 있는 환경을 경험해봤는데 더 체계적인 회사의 실무 비즈니스 같아서 좋았습니다!

AI 활용 경험 공유하기

Cursor, Claude

초기 단계 (추상적 질문): "Vanilla JavaScript로 SPA 라우터를 구현할 때 고려해야 할 핵심 요소들이 뭐가 있을까요?"

구체화 단계 (문제 상황 공유): "현재 이런 방식으로 라우터를 구현했는데, 브라우저 뒤로가기 시 상태가 꼬이는 문제가 있습니다. [코드 첨부] 어떤 부분을 개선해야 할까요?"

검증 단계 (코드 리뷰 요청): "이 코드가 메모리 누수나 성능 이슈를 일으킬 수 있는 부분이 있는지 검토해주세요." "이 코드가 최선일까? 더 추상화 가능하거나 불필요한 부분이 있을까?"

리뷰 받고 싶은 내용

발제때 코치님의 우선 만들고 더 잘돌아가게 만든다에 공감하기에 우선만들고 리팩토링을 진행해보려 했는데요!

가장 코어한 시스템인 라우터, 렌더링에 관련된 라이프사이클, 상태관리 자체가 많이 고려하지 않은상태로 만들었다보니 해당 부분을 리랙토링해야겠다고 생각했습니다!

작은 단위로 리팩토링을 해보려 했기에 라우터 -> 렌더링 -> 상태관리로 진행해보려 했는데 이 중 하나만 건드려도 문제들이 많이 생겨 어디가 문제인지 파악하는게 너무 어려웠습니다.

코어한 기능에 문제가있는데 조금만 건드려도 문제가 다발적으로 터지는 상황에서 리팩토링을 진행하시는 플로우가 궁금합니다.

만약 라우터쪽 코드를 조금 수정했더니 에러가 어디서 몇개가 났는지 파악이 되지않다면 어디서부터 건드려야 하는지 파악이 안되더라구요ㅎㅎ..

이벤트 위임 코드들을 events 한 파일에 몰아넣었는데 이 코드의 개선방법도 궁금합니다.

main.js router.init(main)을 실행하는데 인자로 넘긴 main 함수는 popstate 이벤트시 실행됩니다.

이때 중복으로 main을 호출할 경우 isMainRunning 변수를 통해 다시 실행되지 않고 return 시켰었는데 그렇게하면 빠르게 뒤로가기 앞으로가기 이벤트가 발생할 경우 이벤트가 실행되지 않아 업데이트 되지 않는경우가 있습니다.

그렇다고 isMainRunning을 제거하면 이벤트들이 중복으로 많이 실행되어 많은 리렌더링이 일어나는게 느껴지는데요

현재 구조에서 리렌더링 플로우를 정상적으로 만드려면 어떻게해야할까요?