카드 한 장 한 장이 상품이고, 같은 카드라도 등급과 상태에 따라 값이 달라집니다. 목록에서 수백 장의 카드 이미지를 빠르게 훑을 수 있어야 하면서, 상세에서는 카드 표면의 미세한 상태까지 확인할 수 있어야 하는 상반된 요구가 있었습니다.
일반 사용자와 파트너 사업자가 같은 서비스를 쓰되 할 수 있는 일이 다르고, 거기에 운영자용 백오피스까지 필요했습니다. 프론트엔드는 내가 전담했기 때문에 웹뷰 앱과 백오피스를 모두 만들어야 했는데, 두 화면은 성격이 너무 달라서 같은 스택으로 묶지 않는 편이 나았습니다.
거래에는 구매·판매·교환·경매가 섞여 있었습니다. 각각 진행 단계가 다르고 되돌릴 수 있는 지점도 다릅니다. 이 부분을 화면 조건문으로 다루면 금방 손을 댈 수 없게 된다는 것이 초반의 가장 큰 고민이었습니다.
문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.
결정 01
결정 02
결정 03
결정 04
구매자·판매자·파트너의 화면과 기능을 권한 정의에서 파생시켜 접근을 제어.
시리즈·등급·가격대·상태를 조합해 좁히고, 조건은 URL에 남아 공유 가능.
커서 기반 페이징으로 실시간 등록에도 중복 없이 이어붙입니다.
구매·판매·교환·경매를 각각 다른 상태 정의로 다루는 거래 화면.
토스페이먼츠 결제와 포트원 본인인증을 연동.
Firebase Realtime Database로 거래 당사자 간 채팅을 구현.
Sweet Tracker API로 거래 후 배송 상태를 확인.
사용자·상품·거래 관리와 SheetJS 기반 엑셀 다운로드.
한 사람이 사용자 화면과 운영 화면을 모두 만들면 좋은 점이 하나 있습니다. 운영자가 무엇을 힘들어하는지 알고 사용자 화면을 만들게 된다는 것입니다. 반대로 나쁜 점은 두 화면의 기준이 나 한 사람에게 있어서, 내가 놓친 것은 아무도 못 잡는다는 점이었습니다.
실시간으로 바뀌는 목록은 UI 문제로 보이지만 사실 API 계약 문제입니다. 프론트에서 아무리 잘 감싸도 offset 페이징 위에서는 답이 안 나옵니다. 초반에 백엔드와 커서 규약을 맞춘 게 이 프로젝트의 분기점이었습니다.
상태를 정의로 먼저 적어 두는 방식은 처음에 느리게 느껴졌지만, 후반에 거래 유형이 추가됐을 때 값을 다 회수했습니다. 화면을 만들기 전에 가능한 상태를 적는 습관은 이후로도 계속 쓰고 있습니다.