쇼핑몰 웹과 앱 연동 시 장바구니·로그인·푸시 함정

자사몰 웹을 먼저 만들고 나중에 앱을 붙이는 경우가 많습니다.

“같은 서버를 쓰면 되지 않나?”라는 기대와 달리, 장바구니·로그인 유지·푸시·결제 후 복귀는 웹과 앱의 실행 환경이 달라 어긋나기 쉽습니다.

고객 입장에서는 웹에서 담은 상품이 앱에 없고, 앱에서 로그인했는데 결제 중에 풀리고, 배송 출발 푸시는 오는데 주문 상세를 누르면 로그인 화면이 다시 뜹니다. 이 경험은 “앱이 있다”는 마케팅보다 먼저 브랜드 신뢰를 깎습니다.

왜 이런 일이 생기나요?

웹 브라우저는 쿠키·로컬 저장 방식이 익숙합니다. 앱은 자체 저장소, 푸시 토큰, 앱 안 웹 화면(WebView)이 섞입니다. 로그인 유지 방식(세션·토큰)을 채널마다 다르게 두면, “한쪽만 로그인된” 상태가 반복됩니다.

장바구니는 더 민감합니다. 비로그인 장바구니, 로그인 후 병합, 옵션·수량 충돌, 품절 상품 정리 규칙이 없으면 웹과 앱이 서로 다른 바구니를 보여 줍니다.

푸시는 앱만의 강점이지만, 딥링크(푸시 탭 시 열릴 화면)와 로그인 상태가 맞지 않으면 “알림은 왔는데 들어갈 수 없는” 앱이 됩니다. 결제 역시 외부 결제 앱으로 나갔다 돌아올 때 세션이 끊기면 주문이 미확정으로 남습니다.

이렇게 보면 쉬워요

장바구니

• 로그인 전 담은 상품과 로그인 후 서버 바구니 어떻게 합칠지 문장으로 정합니다.
• 같은 옵션 상품은 수량 합산인지, 충돌 시 어느 쪽을 우선하는지 정합니다.
• 품절·판매 중지 상품은 자동 제거인지, 경고 후 유지인지 정합니다.

로그인

• 웹에서 로그인한 상태가 앱 첫 실행에 어떻게 이어지는지(또는 이어지지 않는지) 기대치를 정합니다.
• 앱 안 웹 화면 결제 중 토큰 만료 시 갱신·재로그인 경로를 검수합니다.
• 로그아웃 시 푸시 토큰·장바구니 정책(유지/비우기)을 정합니다.

푸시

• 주문·배송·쿠폰 등 이벤트별로 템플릿과 딥링크 규칙을 둡니다.
• 비로그인·다른 계정으로 바뀐 기기에서 푸시를 눌렀을 때의 동작을 정합니다.
• 알림 권한 거부 시 대체 채널(알림톡·문자) 여부를 운영 정책에 넣습니다.

결제 복귀

• 결제 앱·카드사 앱으로 나갔다 돌아올 때 주문 번호로 상태를 다시 조회합니다.
• “결제 완료 화면만 보고 주문 완료”로 처리하지 않습니다. 서버 확정이 기준입니다.

이렇게 준비하면 좋아요

1. 웹 단독 사용 / 앱 단독 사용 / 웹→앱 전환 / 푸시 진입 시나리오를 표로 만듭니다.
2. 각 시나리오에서 장바구니·로그인·주문 상세가 같아야 하는지 기대치를 적습니다.
3. 하이브리드라면 웹과 앱이 로그인·파일을 주고받는 브릿지 약속을 문서화합니다.
4. 테스트 계정으로 “웹 담기 → 앱 실행 → 로그인 → 결제 → 푸시” 한 줄을 끝까지 돌려 봅니다.
5. 고객센터용 안내 문구를 준비합니다. (예: 장바구니가 다를 때 확인할 것)

• □ 장바구니 병합·충돌 규칙이 문서에 있다
• □ 웹·앱·WebView 로그인 유지 정책이 같다
• □ 푸시 딥링크와 로그인 상태가 맞춰져 있다
• □ 결제 복귀 후 서버로 주문 상태를 재확인한다
• □ 로그아웃·회원 탈퇴 시 토큰·푸시 정리가 있다
• □ 품절 상품 장바구니 처리 규칙이 있다
• □ 실기기에서 웹↔앱 전환 시나리오를 검수했다

자주 하는 실수

• 웹 장바구니를 기기 안에만 저장하고 서버 동기화 없음
• 앱 로그인과 웹 쿠키를 별개로 방치
• 푸시는 보내지만 딥링크가 홈만 가리킴
• 결제 중 세션 만료를 검수하지 않음
• “앱은 웹뷰로 감싸면 끝”으로 권한·토큰을 설계하지 않음
• 채널마다 쿠폰·가격 규칙이 달라 CS 폭증

LB Contents는 쇼핑몰 웹과 앱을 붙일 때 화면 복제보다 장바구니·로그인·푸시·결제 복귀를 한 흐름으로 설계합니다. 웹몰은 있고 앱만 추가하려는 단계의 상담도 가능합니다.