lieblichoi 님의 상세페이지 ＞ [9팀 최재환] Chapter 1-1. 프레임워크 없이 SPA 만들기

[9팀 최재환] Chapter 1-1. 프레임워크 없이 SPA 만들기

Open
by lieblichoi2025. 7. 7.

과제 체크포인트

배포 링크

https://lieblichoi.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로 다시 구현한다.
  • 이 과정에서 직접 가공하는 것은 최대한 지양한다.

과제 셀프회고

기술적 성장

새로 학습한 개념

  • 프레임워크 없이 SPA 구현: 프레임워크 없이 직접 라우팅 시스템을 구현하면서 SPA의 동작 원리를 보다 깊게 이해할 수 있었습니다. 특히 History API를 활용한 브라우저 히스토리 관리와 동적 컴포넌트 렌더링 방식에 대한 이해가 생겼습니다.

  • 옵저버 패턴 기반 상태 관리: Store 클래스를 통해 중앙 집중형 상태 관리를 구현하면서, 옵저버 패턴의 실질적인 활용법을 익혔습니다. 특히 subscribe/setState 구조를 활용한 UI 업데이트 방식에 대한 이해가 생겼습니다.

기존 지식의 재발견/심화

  • 이벤트 위임 패턴의 중요성: 동적으로 생성되는 DOM 요소들에 대한 이벤트 처리를 위해 전역 이벤트 위임을 구현했습니다. 이를 통해 메모리 효율성과 성능 최적화의 중요성을 느꼈습니다.

  • 레이어드 아키텍처: 잊고 있던 관심사 분리 원칙을 떠올리고 Services와 API 레이어가 분리되어 있는 모습으로 구현했습니다. ProductService에서는 데이터 정규화와 에러 처리를 담당하고, API 레이어에서는 순수한 HTTP 통신만 관리하는 구조가 보기 좋았습니다.

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

  • 무한 스크롤과 상태 관리: 페이지네이션과 무한 스크롤을 동시에 지원하면서도 URL 상태와 동기화하는 것이 꽤 쉽지 않았습니다. 프레임워크가 없는 낯선 구조에서 구현하다보니 더욱 어렵게 느껴졌습니다. 기능 구현 자체는 allProducts 배열을 통한 누적 관리, 그리고 current 파라미터를 통한 페이지 상태 추적으로 비교적 간단했습니다. 그러나 해당 로직을 전역에서 수행하다보니 초기 구현 시 다른 페이지에서까지 불필요하게 동작하는 이슈가 발생했었습니다. 스크롤 이벤트 핸들러 내부에서 경로 기반 비활성화 로직을 추가해 해결했습니다.

자랑하고 싶은 코드

Store 클래스의 상태 관리 로직

// src/store/Store.js의 updateFilters 메서드
updateFilters(newFilters) {
  const updatedFilters = { ...this.state.filters, ...newFilters, page: 1 };
  
  this.setState({
    filters: updatedFilters,
    allProducts: [], // 필터 변경 시 누적 상품 초기화
    pagination: null,
  });

  // URL과 상태 동기화
  if (typeof window !== 'undefined' && window.updateURLParams) {
    window.updateURLParams({
      current: 0,
      category1: updatedFilters.category1,
      category2: updatedFilters.category2,
      search: updatedFilters.search,
      sort: updatedFilters.sort,
      limit: updatedFilters.limit,
    });
  }
}

필터 변경 시 상태 초기화, URL 동기화, 그리고 UI 업데이트가 하나의 메서드에서 일관되게 처리되는 부분이 만족스럽습니다. 특히 side effect를 명시적으로 관리한 점이 좋습니다.

Router 클래스의 동적 라우팅

// src/router/Router.js의 getParams 메서드
getParams() {
  const path = this.getCurrentPath();
  const params = {};

  for (const routePath in this.routes) {
    if (routePath.includes(':')) {
      const routeParts = routePath.split('/');
      const pathParts = path.split('/');
      
      if (routeParts.length === pathParts.length) {
        let isMatch = true;
        for (let i = 0; i < routeParts.length; i++) {
          if (routeParts[i].startsWith(':')) {
            params[routeParts[i].slice(1)] = pathParts[i];
          } else if (routeParts[i] !== pathParts[i]) {
            isMatch = false;
            break;
          }
        }
        if (isMatch) {
          return { path: routePath, params };
        }
      }
    }
  }
  return { path, params };
}

getCurrentPath() 메서드에서 window.location.pathname으로 실제 브라우저 경로를 가져옵니다. 이렇게 얻은 경로 정보를 getParams() 메서드로 전달하여 동적 라우팅을 수행합니다.

정규식을 사용하는 대신 문자열을 '/'로 분할한 후 각 부분을 순차적으로 비교하는 방식을 택했습니다. 이렇게 하면 routeParts[i].startsWith(':')로 동적 파라미터를 간단히 식별할 수 있습니다.

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

main.js의 과도한 책임 현재 main.js가 655라인에 달하며 앱 초기화, 이벤트 핸들링, 상품 로딩, URL 관리 등 너무 많은 책임을 가지고 있습니다.

// 현재 main.js에 모든 로직이 집중됨
function setupEventHandlers()
function handleGlobalClick(e)
async function loadProducts()

개선 방안:

  • EventHandler 클래스로 이벤트 로직 분리
  • ProductController로 상품 관련 로직 분리
  • URLManager로 URL 관리 로직 분리

전역 이벤트 위임의 복잡성

function handleGlobalClick(e) {
  // 장바구니 버튼
  if (e.target.matches('.add-to-cart-btn') || e.target.closest('.add-to-cart-btn')) {
    // ...
  }
  // 상품 상세 링크
  if (e.target.matches('.product-link') || e.target.closest('.product-link')) {
    // ...
  }
  // 카테고리 버튼
  if (e.target.matches('.category-btn') || e.target.closest('.category-btn')) {
    // ...
  }
  // ... 20여 개의 조건문
}

이벤트 핸들러가 단일 함수에 모든 이벤트 처리 로직이 집중되어 가독성과 유지보수성이 떨어집니다.

컴포넌트 간 결합도

// ProductDetailContainer에서 직접 DOM 조작
const mainElement = document.querySelector('main');
if (mainElement) {
  mainElement.innerHTML = ProductDetail({
    product: this.product,
    relatedProducts: this.relatedProducts,
  });
}

컴포넌트가 특정 DOM 구조에 의존하고 있어 재사용성이 떨어집니다.

학습 효과 분석

가장 큰 배움이 있었던 부분 프레임워크의 편리함 없이 직접 모든 것을 구현하면서 웹 애플리케이션의 동작 원리를 이해할 수 있었습니다. 특히 React의 상태 관리, 라우팅, 컴포넌트 렌더링이 내부적으로 어떻게 작동하는지 짐작할 수 있었습니다.

추가 학습이 필요한 영역

  • 컴포넌트 라이프사이클 관리: 현재는 단순한 문자열 렌더링이지만, 실제로는 컴포넌트의 마운트/언마운트, 업데이트 최적화 등이 필요합니다.
  • 타입 안정성: TypeScript 도입을 통한 런타임 에러 방지와 개발 경험 개선이 필요합니다.
  • 번들링과 모듈 시스템: 현재는 브라우저 네이티브 모듈을 사용하지만, 실제 프로덕션에서는 번들링 최적화가 중요합니다.

실무 적용 가능성 이번 경험을 통해 프레임워크 선택의 기준이 명확해졌습니다. 단순한 기능이라면 바닐라 JS로도 충분하지만, 복잡한 상태 관리와 컴포넌트 간 상호작용이 많아질수록 프레임워크의 필요성을 실감했습니다. 아키텍처 설계의 중요성 또한 체감했습니다.

과제 피드백

과제에서 좋았던 부분

  • 요구사항이 촘촘하게 구성되어 있어 개발 계획을 단계적으로 수립할 수 있었습니다.
  • MSW를 통한 API 모킹을 처음 사용해봤는데, 생각보다 구조도 간단해서 활용하기 편했습니다. 물론 이미 만들어져있는 데이터이기에 더욱 편하게 느껴졌을거라 생각합니다.

모호하거나 애매했던 부분

  • E2E 및 단위 테스트의 명세와 요구사항 간의 간극이 아쉬웠습니다. 요구사항을 토대로 개발한 후 테스트의 명세를 맞추는 것이 쉽지 않았습니다.

AI 활용 경험 공유하기

사용한 AI 도구 주로 Cursor + Claude를 활용했으며, 복잡한 로직 구현과 디버깅에 Gemini를 보조적으로 사용했습니다.

프롬프트 작성 과정 컨텍스트와 현재 프로젝트의 구조 및 설계를 최대한 자세하게 주입한 프롬프트가 가장 효율적이고 높은 성과를 보여주었습니다.

AI가 일을 더 잘 하게 만든 방법

  • 코드 리팩토링 요청 시 관련 파일 컨텍스트 먼저 주입
  • 그 이후 특정 함수나 로직을 추가로 제공
  • 에러 발생 시 에러 메시지와 함께 관련 코드 컨텍스트 제공
  • 구현 후 직접 기능을 동작해보고 발견한 에러와 예상되는 side effect를 공유해 코드 품질 개선

내가 작성한 코드와 비교하기 구조 이해를 위해 풀어져 작성된 제 코드와 비교했을 때 AI가 작성한 코드가 더욱 간결했습니다.

리뷰 받고 싶은 내용

1. main.js 파일 분리 계획 피드백

현재 main.js가 655라인에 달하며 다음과 같은 여러 책임을 가지고 있습니다:

// 현재 main.js에 집중된 책임들
- 앱 초기화 및 인스턴스 생성
- 전역 이벤트 핸들링
- 상품 로딩/페이지네이션 로직
- URL 파라미터 관리
- 장바구니/모달 렌더링
- 필터 상태 관찰 및 동기화

다음 두 가지 분리 방안 중 어떤 것이 더 적절할까요?

방안 A: 기능별 매니저 클래스 분리

class EventManager {
  constructor(store, router) { /* 이벤트 위임 로직만 담당 */ }
}
class ProductManager {
  constructor(store, service) { /* 상품 로딩/페이지네이션만 담당 */ }
}
class URLManager {
  constructor() { /* URL 파라미터 관리만 담당 */ }
}

방안 B: MVC 패턴 기반 분리

class AppController {
  constructor(model, view) { /* 비즈니스 로직 조율 */ }
}
class ProductController {
  constructor(model, view) { /* 상품 관련 로직만 */ }
}

특히 전역 이벤트 위임을 유지하면서도 가독성을 확보하는 방법이 궁금합니다. 현재는 handleGlobalClick에 20여 개의 조건문이 있어 유지보수가 어려운 상황입니다.

2. 문자열 기반 컴포넌트 렌더링의 개선 방안

현재 모든 컴포넌트가 리터럴로 HTML을 반환하는 구조입니다:

// 현재 방식의 문제점
export function ProductDetail({ product, relatedProducts = [] }) {
  return `
    <div class="bg-white rounded-lg shadow-sm mb-6">
      ${product.description ? `<div>${product.description}</div>` : ''}
      ${relatedProducts.map(item => `<div>${item.name}</div>`).join('')}
    </div>
  `;
}

문제점:

  • 조건부 렌더링 시 가독성 저하 (중첩된 삼항 연산자)
  • 이벤트 바인딩을 위한 별도 로직 필요
  • 부분 업데이트 불가 (전체 재렌더링)
  • 타입 안전성 부족

고민하는 개선 방안들:

방안 A: DOM 조작 기반 컴포넌트

class ProductDetailComponent {
  constructor(container) {
    this.container = container;
  }
  
  render({ product, relatedProducts }) {
    // createElement로 DOM 직접 조작
    const element = document.createElement('div');
    element.className = 'bg-white rounded-lg shadow-sm mb-6';
    // ...
    this.container.appendChild(element);
  }
  
  update(newProps) {
    // 필요한 부분만 업데이트
  }
}

방안 B: 가상 DOM 패턴 구현

// 간단한 가상 DOM 구조
export function ProductDetail({ product, relatedProducts }) {
  return createElement('div', { className: 'bg-white...' }, [
    product.description && createElement('div', {}, product.description),
    ...relatedProducts.map(item => createElement('div', {}, item.name))
  ]);
}

바닐라 JS 환경에서 성능과 개발 경험의 균형을 고려할 때, 어떤 방향이 가장 현실적이고 효과적일지 궁금합니다.