🎅 오너먼트 프로젝트

[ 스크립트 공유 ] 장바구니 비동기 처리와 커뮤니티 일화

보배 진 2026. 1. 6. 17:35

 

 

 

 

 

 

 

 

장바구니 페이지 비동기 처리 구현

장바구니 페이지에서는 사용자 경험을 개선하기 위해 비동기 처리 방식(Ajax)을 적용하여 기능을 구현했습니다.
비동기 처리는 작업을 요청한 뒤 결과를 기다리지 않고도 다음 작업을 수행할 수 있는 방식으로,
페이지 전체를 새로고침하지 않고도 필요한 데이터만 서버와 주고받을 수 있다는 장점이 있습니다.

장바구니 페이지에 비동기를 적용한 가장 큰 목적은
사용자가 상품 수량을 변경하거나 상품을 삭제할 때, 화면이 즉각적으로 반응하도록 하기 위함이었습니다.
기존의 동기 방식에서는 요청마다 페이지가 새로고침되어 불필요한 렌더링과 데이터 재전송이 발생하지만,
비동기 처리 방식을 사용하면 서버 요청과 전송 데이터를 최소화하여
보다 빠르고 끊김 없는 사용자 경험을 제공할 수 있습니다.


주요 기능 구성

장바구니 페이지의 핵심 기능은 다음 네 가지로 구성되어 있습니다.

  • 상품 수량 변경
  • 상품 삭제
  • 총 금액 자동 계산
  • 구매 버튼 비활성화

이 기능들은 각각 비동기를 통해 서버와 통신하며,
기능별로 독립적인 로직으로 분리해 모듈화된 구조로 구현했습니다.

이러한 구조를 통해
사용자 경험 측면에서는 수량 변경이나 삭제 시 즉각적인 화면 반응을 제공하고,
유지보수 측면에서는 특정 기능을 수정하더라도 다른 기능에 영향을 주지 않도록 설계했습니다.
또한 추후 쿠폰 적용이나 배송비 계산과 같은 기능이 추가되더라도
기존 구조를 크게 변경하지 않고 확장할 수 있도록 고려했습니다.

기술적인 측면에서는
비동기 처리를 통해 장바구니 상태를 일관되게 관리하며,
프론트엔드와 서버 간 데이터 동기화를 효율적으로 처리할 수 있도록 구현했습니다.


수량 변경 공통 로직 – updateCartCount

updateCartCount 함수는 장바구니 상품의 수량 변경을 처리하는 공통 로직입니다.
수량 변경은 버튼 클릭 방식과 직접 입력 방식 두 가지가 존재하지만,
실제 처리 로직을 하나의 함수로 통합하여 중복 코드를 제거했습니다.

이를 통해 수정이나 확장이 필요할 경우
이 함수 하나만 변경하면 되기 때문에 유지보수성과 확장성을 높일 수 있었습니다.

함수 내부에서는 수량의 최소값과 최대값을 각각 1과 99로 제한하여
잘못된 입력이 발생하지 않도록 프론트엔드 단계에서 사전에 차단했습니다.
이 기준 값은 설계 단계에서 팀원들과 협의하여 결정한 값입니다.

이후 비동기 요청을 통해 서버에 수량 변경을 전달하고,
서버에서 정상적으로 처리된 경우에만 화면의 수량과 항목별 금액을 갱신하도록 구현했습니다.
이를 통해 서버에 저장된 데이터와 화면에 표시되는 데이터가 항상 동일한 상태를 유지하도록 했습니다.

마지막으로 수량 변경이 완료되면 총 금액을 다시 계산하여
변경된 장바구니 상태가 즉시 화면에 반영되도록 처리했습니다.


총 금액 계산 및 구매 버튼 제어 – updateTotalPrice

updateTotalPrice 함수는 장바구니에 담긴 모든 상품의 총 금액을 계산하고,
구매 버튼의 활성화 여부를 제어하는 역할을 합니다.

장바구니 테이블의 각 상품 행을 순회하며,
빈 장바구니 안내 메시지와 같은 실제 상품이 아닌 행은 제외한 뒤
상품 가격과 수량을 가져와 총 금액을 계산합니다.
이때 가격 문자열에서 콤마와 ‘원’ 문자를 제거해 숫자 형태로 변환하여 계산을 수행했습니다.

총 금액이 없거나 0원 이하인 경우에는
잘못된 결제 요청을 방지하기 위해 구매 버튼을 비활성화했고,
정상적인 금액이 있는 경우에만 구매 버튼을 활성화하도록 구현했습니다.

계산된 총 금액은 즉시 화면에 반영되어,
상품 수량 변경이나 삭제 이후에도
장바구니 상태가 실시간으로 정확하게 표시되도록 했습니다.


이벤트 처리 구조 설계

이벤트 처리 구조에서는
장바구니 페이지에서 자주 사용되는 요소들을 미리 변수로 분리했습니다.
구매 버튼, 장바구니 목록 영역, 총 금액 표시 영역 등을 사전에 저장해
DOM 탐색을 반복하지 않도록 했고,
이를 통해 코드 가독성과 성능을 함께 고려했습니다.

수량 증가(+)·감소(–) 버튼 클릭 시에는
클릭된 버튼이 속한 상품 행을 기준으로
장바구니 고유 번호와 현재 수량을 가져온 뒤,
증가 또는 감소된 값을 계산해 updateCartCount 함수로 전달합니다.

이렇게 이벤트 처리와 실제 비즈니스 로직을 분리함으로써
코드 구조를 보다 명확하게 유지할 수 있었습니다.

또한 사용자가 수량을 직접 입력하는 경우에도
포커스를 벗어나는 시점에 입력 값을 검증한 뒤
동일하게 updateCartCount 함수를 호출하도록 구현했습니다.
이를 통해 수량 변경 방식과 관계없이
항상 동일한 로직을 거치도록 통일할 수 있었습니다.


커뮤니케이션 경험 – 개발 방식 차이 조율

팀 프로젝트를 진행하며 가장 인상 깊었던 경험 중 하나는
팀원 간 문제 해결 접근 방식의 차이를 조율했던 과정입니다.

에러가 발생했을 때
저는 로그를 통해 문제 지점을 좁혀가는 방식을 선호했고,
다른 팀원은 전체 구조를 다시 검토하며 수정하는 방식을 선호했습니다.
초기에는 접근 방식에 대한 논의가 길어지면서
문제 해결보다 의견 조율에 시간이 소요되기도 했습니다.

또한 로그 출력 방식, 변수 네이밍, 주석 작성 방식 등
사소한 부분에서도 차이가 있었기 때문에
팀원들과 하나씩 규칙을 정하며 맞춰 나갔습니다.

프로젝트 초반에는 이러한 조율 과정이 혼자 개발할 때보다
오히려 더 많은 시간을 요구했지만,
매주 팀 회의와 협업을 반복하며
점차 팀만의 개발 기준이 정립되기 시작했습니다.

예를 들어
DTO의 멤버 변수에는 테이블명을 접두어로 붙이거나,
로그 출력 시 파일명을 명시하는 등의 규칙을 함께 정했습니다.

이 경험을 통해
문제 해결 과정에서 중요한 것은
누가 맞느냐가 아니라 얼마나 소통하고, 상황에 맞게 조율할 수 있는가라는 점을 배웠습니다.
팀 프로젝트는 결국 개인의 실력뿐 아니라
팀 전체의 합을 맞춰가는 과정이라는 것을 체감할 수 있었습니다.