[9팀 신홍준] Chapter 1-1. 프레임워크 없이 SPA 만들기

[jun17183]

과제 체크포인트

배포 링크

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

테스트 코드 수정

• '총 개의 상품' 을 '총 n개의 상품' 과 같은 형태로 변경
• 테스트 후 state 초기화
• 너무 빠른 속도로 뒤로가기/앞으로가기 시 생기던 렌더링 문제를 해결하기 위해 속도 지연 추가 (이 부분이 문제가 될 수도 있음을 인지하고 있습니다...)

과제 셀프회고

실무에서는 AI는 커녕 인터넷도 안 되는 환경에서도 종종 일했던 터라 최대한 AI를 활용해 보는 것이 목표였습니다. 하지만 고기도 먹어 본 사람이 더 잘 먹는다는 것처럼 막상 사용하려니 AI와 스스로의 작업 비중이나 역할을 분명하게 나누지 못했습니다.

처음엔 한꺼번에 너무 많은 내용을 주문했습니다.
"순수 JS로 SPA를 구현하는 과제를 진행 중이야. 최대한 리액트처럼 구현했으면 해.
옵저버 패턴을 활용하여 state를 관리하고 이를 각 페이지나 컴포넌트에서 구독한 뒤
이에 따라 페이지 렌더링이 이루어졌으면 해. 라우터도 조건에 맞게 구현해줘.
..."

그래서 첫째날 바로 한 사이트가 뚝딱 만들어 졌습니다.
그러고 테스트를 돌리자 죄다 통과하지 못했습니다.
되돌아보면 /총 개의 상품/ 부분이 /총 n개의 상품/ 과 같이 구현되어서 매치가 되지 않았던 것 뿐인데 직접 작성한 코드가 아니다 보니 파악 자체가 힘들었습니다.

새로 과제를 진행하기로 했습니다. 작업 순서를 정하고 단위를 작게 나누어 이에 따라 AI에게 주문했습니다.

"우선 State Manager의 상위 클래스부터 제작하려 해. 구독과 감지 메서드는 필수로 있어야 하고 이 외 기능은 바로 코드 적용하지 말고 먼저 설명 부탁해."

이렇게 진행하다 보니 나름 순탄하게 흘러갔습니다. 코드 이해도도 높고 버그도 많이 줄었습니다. 하지만 이 과정에서 이미 꽤 많은 시간이 흐른 상태였습니다.

이때 AI 사용량이 바닥이 나고 맙니다. cursor claude 4.0을 사용 중이었는데 그동안 너무 많은 코드 작업을 맡겼던 것 같습니다. 그래서 다른 AI를 사용하려 하니 성능이 현저히 떨어지고, 그동안의 맥락을 따라가지 못하였습니다.

이후로는 거의 직접 작업을 하게 되었습니다. 이 과정에서 시간도 쫓기고 버그도 많이 생겨 필수 과제만 통과하는 것을 목표로 하였고 어찌저찌 완성은 했지만 아쉬움이 많이 남습니다.

그럼에도 고무적인 부분이 있습니다. 과제를 진행하는 동안 AI와 스스로 개발하는 비율이 8:2, 6:4, 3:7과 같이 바뀌는 과정을 겪으며 어떻게 AI를 사용해야 하는지 많이 깨달을 수 있었습니다.

기술적 성장

옵저버 패턴에 대해 대충은 알고 있었지만 정확히 어떤 식으로 동작하는지, 어떤 형태를 띄는지는 잘 몰랐기에 이번 기회에 꼭 한번 사용해 보고 싶었습니다.

덕분에 어느 정도 옵저버 패턴과 좀 더 친숙해 질 수 있는 시간이었고 더하여 렌더링이나 State 관리에 대해서도 조금 더 시야가 넓어졌지 않나 생각합니다.

자랑하고 싶은 코드

아무래도 옵저버 패턴을 자랑하고 싶습니다. 아무래도 어떤 디자인 패턴을 인지하고 적극적으로 사용해 본 적은 처음이라 스스로 뿌듯한 부분입니다.

class StateManager {
  ...

  subscribe(keys, observer) {
    const keyArray = Array.isArray(keys) ? keys : [keys];

    // 각 키에 대해 옵저버 등록
    keyArray.forEach((key) => {
      if (!this.observers[key]) this.observers[key] = [];
      this.observers[key].push(observer);
    });

    // 구독 해제 함수 반환
    return () => {
      keyArray.forEach((key) => {
        if (this.observers[key]) {
          const index = this.observers[key].indexOf(observer);
          if (index > -1) this.observers[key].splice(index, 1);
        }
      });
    };
  }

  /**
   * 특정 키를 구독한 모든 옵저버에게 상태 변경 알림
   *
   * @param {string} key - 변경된 상태 키
   * @param {*} value - 새로운 값
   */
  notify(key, value) {
    if (this.observers[key]) {
      this.observers[key].forEach((observer) => observer(value, key, this.state));
    }
  }

  ...
}

class ProductListPage {
  ...

  /**
   * 상태 구독 설정
   */
  setupSubscriptions() {
    // 로딩 상태 구독 (메인 로딩)
    stateManager.productList.subscribe(["loading"], () => {
      this.renderLoading();
    });

    // 추가 로딩 상태 구독 (무한 스크롤용)
    stateManager.productList.subscribe(["isLoadingMore"], () => {
      this.renderInfiniteScrollLoading();
    });

    // 상품 목록 구독
    stateManager.productList.subscribe(["products"], () => {
      this.renderProducts();
    });

    // 총 상품 수 구독
    stateManager.productList.subscribe(["totalProducts"], () => {
      this.updateProductCount();
    });

    // 필터(정렬, 카테고리, 검색어, 페이지 크기) 구독
    stateManager.productList.subscribe(["sort", "category", "searchQuery", "pageSize"], () => {
      stateManager.productList.loadProducts();
    });
  }

  ...
}

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

1. 렌더링 방식
   url 이동 -> 초기 렌더링 -> state 변화 감지 -> state에 따른 렌더링
   과 같은 형태로 구현해 보았는데, 이 과정에서 동기화 문제라던가 렌더링이 되기 전 페이지 이동 등 생명주기(라고 표현하는 것이 맞는지 의문) 관리가 제대로 되지 못하였지 않나 생각합니다.

2. 검색조건 state와 url 동기화
   검색조건을 state에 담아 사용하고 있지만 결국 url과도 동기화해야 하기 때문에 검색조건 정보가 두 군데서 관리되는 느낌이었습니다.

사용자가 직접 url을 치고 들어올 수도 있기에 url이 정보의 근원이라는 원칙을 정하긴 했지만 그럼에도 결국 state 값에 따라 구독 콜백 함수가 실행되는 형태이기에 주객전도가 된 것 같았습니다.

state와 url 간의 동기화 및 관리 방식이 궁금합니다.

3. 단일 책임 원칙
   이번에 최대한 단일 책임 원칙을 지키며 작업하려 했습니다.
   하지만 많은 부분에서 이를 놓친 것 같습니다. 과제 제출 후에도 리팩토링을 진행하며 살펴볼 계획입니다.

학습 효과 분석

가장 큰 배움은 AI 활용입니다. AI에게 어떻게 일을 맡겨야 하는지, AI가 작업한 코드를 어떻게 관리해야 할지 등 많은 것을 느낀 시간이었습니다.

상태 관리와 렌더링 방식에 대해서도 시야가 넓어진 느낌입니다.
직접 구현해 보니 어떤 이슈가 발생할 수 있는지, 어떤 코드가 확장성이 좋은지 등을 알게 되었습니다.

그렇기에 오히려 이 부분에 대해 추가 학습이 필요하다고 느꼈습니다.
올바른 렌더링 방식은 무엇인지, 실제 router는 어떻게 동작하는지,
전역 상태는 어디까지 관리해야 하는지 등 공부하고 싶은 것이 많아진 과제였습니다.

과제 피드백

우선 주제 자체가 마음에 들었습니다. 한번쯤은 직접 해보려고 했지만 선뜻 발걸음이 떼지지 않았는데 이렇게 하게 되어 좋았습니다. 어떻게 보면 짧은 시간, 적은 내용일 수도 있지만 이 안에서도 프론트엔드 개발자로 마주할 수 있는 고민을 미리 느껴볼 수 있었지 않았나 생각합니다.

테스트코드를 활용한 과제 통과 여부 확인도 좋았습니다.
물론 기능은 잘 돌아가는데 왜 테스트가 통과하지 않는지 등과 같은 의문이 있었지만, 모두 실무에서도 충분히 겪을 법한 상황이라 짜증이 나는 한편 웃음이 나오기도 했습니다.

AI 활용 경험 공유하기

우선 진행하려는 작업을 정의하고 이에 대해 AI와 충분히 대화를 하는 편이 좋았습니다. 필요 작업을 명세하고 이를 문서로 만든 뒤, 이 문서를 기준으로 작업을 진행하면 속도도 빠르고 코드 이해도도 많이 챙길 수 있었습니다.

AI에게 맡길 작업의 단위도 되도록이면 작게 작게, 단위테스트와 비슷한 단위로 가져가는 것이 좋았습니다.

다만 테스트 파일을 직접 읽고 이에 맡게 처리하라는 방식은 좋지 못하였습니다. 어떻게든 테스트를 통과하기 위해 작업하다 보니 코드가 어그러졌습니다.

가장 크게 느낀 부분은, 확실히 성능 좋은 최신 버전의 AI가 그렇지 못한 AI보다 월등히 일을 잘한다는 겁니다...ㅎㅎ

리뷰 받고 싶은 내용

• 질문에 앞서 코드 구조
  router.js는 각 페이지의 render 메서드를 호출한 뒤 렌더링이 완료되면 mounted 메서드를 호출하고 있습니다. 그리고 각 페이지의 mounted 메서드에선 상태 구독 설멍 메서드를 호출하고 있습니다.

(render -> 완료 -> mounted -> 상태 구독 -> 상태에 따른 rerender)

목록 페이지에서 상품 목록을 불러오기 전 url에서 검색 조건을 읽어 이를 state와 맞추는 작업을 합니다. 그럼 state가 변경될 것이고 이 state를 구독하고 있는 컴포넌트, 페이지들은 리렌더링이 됩니다.

여기서 의문이 생기는 것이, 결국 모든 기능의 중심은 state인데 정보의 원천이 url인 것이 어색합니다. 보통 실무에선 state와 url의 동기화 문제를 어떻게 해결하나요?

위와 같은 렌더링 방식에서 unmount 함수는 어떻게 관리해야 할지 모르겠습니다.

innerHTML을 사용하고 있기에 window 이벤트 같은 것을 제외하면 굳이 unmount 함수를 구현할 필요가 없나 싶기도 하지만, advanced.spec 테스트 "브라우저 뒤로가기/앞으로가기가 올바르게 작동한다" 항목에서
너무 빠르게 페이지 이동이 발생하다 보니 url은 목록 페이지인데 뒤늦게 상품 페이지가 렌더링이 된 것 같아 결국 테스트 코드를 손보게 되었습니다.

unmount는 언제 사용하는지, 위와 같은 문제를 unmount 함수로 어떻게 해결할 수 있을지 궁금합니다.

옵저버 패턴을 사용해 상태 관리 로직을 구현해 보려 했습니다. 제가 구현한 코드가 옵저버 패턴에 맞게 잘 구성되었는지 검토해 주시고, 보완할 부분을 제안해 주실 수 있을까요? (예시 질문에 있던 항목이지만 제 생각과 너무 일치하여 가져왔습니다!)

팀원들과 코드 리뷰

리뷰 받고 싶은 내용
검색 조건을 state와 url 두 군데서 관리하는 형식이 옳은 방향인가 의문이 듭니다.

사용자가 직접 url을 치고 들어올 수 있는 가능성도 있기에 url을 정보의 근원이지만 렌더링이나 상품 조회 등은 모두 state를 기준으로 동작하기에 뭔가 이상하게 느껴집니다.

그렇다고 검색 조건만 url에서 담당, 나머지 상품 정보 등은 state에서 관리하는 방식은 통일성이 없는 거 같다는 생각이 듭니다.

현재 코드는 url을 정보의 근원으로 두고 state를 url에 맞게 동기화 하는 방식인데, 의견 여쭤보고 싶네요.

// state/ProductListManager.js
class ProductListManager extends StateManager {
  constructor() {
    super();
    /** 상품 관련 상태 정의 */
    this.state = {
      /* 중략 */
      searchQuery: "",
      category: "",
      sort: DEFAULT_SORT,
      pageSize: DEFAULT_LIMIT,
    };
  }

  /* 중략 */

  /**
   * URL에서 검색 조건을 읽어와 현재 state와 비교하여 업데이트합니다
   * @returns {boolean} 상태가 변경되었는지 여부
   */
  syncFromUrl() {
    const urlFilters = this.parseFiltersFromUrl();

    // URL에서 파싱된 조건들을 기본값과 비교하여 최종 필터 생성
    const finalFilters = {
      searchQuery: urlFilters.searchQuery || "",
      category: urlFilters.category || "",
      sort: urlFilters.sort || DEFAULT_SORT,
      pageSize: urlFilters.pageSize || DEFAULT_LIMIT,
    };

    // 현재 state와 비교하여 변경된 부분만 확인
    const hasChanged = Object.keys(finalFilters).some((key) => this.state[key] !== finalFilters[key]);

    if (hasChanged) {
      // 변경된 부분만 업데이트 (페이지는 1로 리셋)
      this.setState({
        ...finalFilters,
        currentPage: 1,
      });
      return true;
    }

    return false;
  }
}

class ProductListPage {
  constructor() { /* ... */ }

  mounted() {
    /* 중략 */
    
    this.initializeFromUrl();
  }

  /**
   * URL에서 검색 조건을 동기화하고 초기 상품을 로드합니다
   */
  initializeFromUrl() {
    // URL에서 검색 조건을 동기화
    const hasChanged = stateManager.productList.syncFromUrl();

    // 조건이 변경되지 않은 경우에만 직접 로딩 (변경된 경우 구독에서 자동 로딩됨)
    if (!hasChanged) {
      stateManager.productList.loadProducts();
    }
  }
}

[jun17183]

배포 링크 추가

[lieblichoi]

제 코드는 전역 상태가 변경되면 모든 구독에 알림이 가는 형태인데, 키별 구독 시스템으로 필요한 부분만 업데이트 할 수 있도록 한게 좋아보입니다! 👍

[lieblichoi]

클로저 기반 클린업 함수 패턴이 useEffect랑 비슷해보이네요..! 멋집니다 👍

[lieblichoi]

다른 key더라도 각각의 key에 같은 observer가 등록될 것 같아요! 하나만 상태가 변경되어도 중복 호출될 수 있어보여서 중복 실행을 방지해주는 로직을 추가하면 어떨까 합니다 💪

[lieblichoi]

첫 주차부터 정말 고생 많으셨습니다! 2주차도 파이팅이에요! 🙌