쇼핑몰버그실전사례장바구니웹닥터

단골손님이 장바구니에 470개를 담자, 주문이 멈췄다

빈티지 의류 쇼핑몰을 운영하는 대표님에게 연락이 왔습니다.

"단골손님이 장바구니에 담은 걸 주문도 못 하고, 비우지도 못한대요."

확인해 보니 그 손님의 장바구니에는 상품이 470개 담겨 있었습니다. 빈티지 의류는 모든 상품이 세상에 하나뿐인 1점물이라, 마음에 드는 걸 보이는 족족 담아두는 게 단골들의 정상적인 쇼핑 방식입니다. 그러니까 — 가장 많이 사주는 손님일수록 주문이 안 되는 최악의 버그였던 겁니다.


증상이 이상했다

  • 주문하기를 눌러도, 장바구니 비우기를 눌러도 반응이 없음
  • 대신 "선택옵션 개수 총합 1개 이상 주문해 주십시오"라는 엉뚱한 오류만 반복
  • 적게 담은 손님은 멀쩡하고, 대략 330개 이상 담은 손님만 발생

"많이 담으면 안 된다"는 규칙은 쇼핑몰 어디에도 없었습니다. 그런데 왜?


원인: 상품도, 손님도 아닌 '서버 설정 한 줄'

장바구니 전송 한도 초과 구조

원인을 추적해 보니, 쇼핑몰 프로그램이 아니라 서버 설정에 있었습니다.

주문 버튼을 누르면 장바구니의 모든 정보가 서버로 전송되는데, 상품 1개당 정보가 3칸씩 붙습니다. 470개면 약 1,410칸. 그런데 서버에는 **"한 번에 1,000칸까지만 받는다"**는 기본 설정이 있었습니다.

1,000칸이 넘어가자 서버가 뒷부분을 조용히 잘라버렸고, 하필 잘려나간 자리에 "이건 주문 요청입니다"라는 표시가 있었습니다. 그래서 쇼핑몰은 주문 요청을 받고도 무슨 요청인지 몰라 엉뚱한 오류를 내보냈던 겁니다.

이런 문제의 까다로운 점은, 오류 메시지가 원인과 전혀 상관없는 소리를 한다는 겁니다. 메시지만 보고는 백날 상품 옵션을 뒤져봐야 안 나옵니다.


해결: 당일 수정, 그리고 검증까지

서버 설정의 한도를 1,000칸에서 10,000칸으로 상향했습니다. 수정 자체는 몇 줄이지만, 라이브 쇼핑몰이라 순서를 지켰습니다.

  1. 운영에 영향 없는 별도 공간에서 설정 변경을 먼저 테스트
  2. 이상 없음을 확인한 뒤 실제 쇼핑몰에 반영
  3. 1,413칸짜리 주문을 일부러 만들어 재현 테스트 — 수정 전에는 실패하던 요청이, 수정 후 정상 접수되는 것까지 확인

여기서 끝내지 않고, 그 단골손님의 장바구니에 쌓여 있던 이미 판매완료된 상품 10건을 자동 정리해주는 기능도 함께 붙였습니다. 1점물 쇼핑몰에서는 담아둔 사이 팔려버린 상품이 장바구니에 계속 남아 결제를 방해하거든요.

접수부터 해결·검증까지 당일에 끝났습니다.


이 사례가 말해주는 것

쇼핑몰 버그의 절반은 쇼핑몰 바깥에 있습니다. 프로그램 코드, 서버 설정, 호스팅 환경, 외부 연동 — 어디서든 터질 수 있습니다. 그래서 프론트엔드만, 혹은 서버만 아는 사람은 원인을 못 찾고 헤매기 쉽습니다.

이런 문제는 증상에서 원인 후보를 좁혀가는 진단력이 전부입니다. 그리고 진단이 정확하면, 고치는 건 생각보다 금방입니다.


비슷한 문제를 겪고 계신가요?

"많이 담으면 주문이 안 돼요", "특정 손님만 오류가 나요" 같은 애매한 증상일수록 환영합니다. 원인 진단부터가 제 일이니까요.

  • 건당 3만원, 입금 확인 후 6시간 내 착수 (못 지키면 100% 환불)
  • 프론트엔드 · 백엔드 · AI · DB 풀스택 대응

👉 웹닥터 자세히 보기 · 다른 해결 사례 보기 · 바로 신청하기

이 글이 도움이 되셨나요? AI 도입에 관한 상담이 필요하시면 편하게 연락주세요.

무료 상담 신청