금을 팔려면 보통 매장에 직접 가야 하고, 그 자리에서 제시받은 금액을 그대로 받아들이게 됩니다. GOLDIE는 이 과정을 비대면으로 옮긴 서비스입니다. 사용자는 시세를 먼저 확인하고, 예상 금액을 계산해 보고, 접수 후 물건을 보내고, 감정 결과를 확인한 뒤 정산을 받습니다.
네이티브 앱 안에서 도는 웹뷰 형태였고, 프론트엔드는 내가 혼자 맡았습니다. 로그인·본인인증·결제·실시간 채팅처럼 보통 여러 사람이 나눠 맡는 영역을 전부 다뤄야 했다는 점이 이 프로젝트의 성격을 결정했습니다.
가장 신경 쓴 것은 '돈이 걸린 화면의 신뢰감'이었습니다. 금액이 화면마다 다르게 보이거나, 새로고침했더니 숫자가 달라지거나, 접수 중간에 뒤로 가기를 눌렀더니 입력이 날아가면 사용자는 서비스 자체를 의심하게 됩니다. 계산 로직을 한 곳으로 모으고, 단계별 입력을 URL과 스토어에 나눠 남긴 이유입니다.
미성년자 거래 제한 같은 규제 요건도 화면 설계에 직접 영향을 줬습니다. 본인인증에서 받은 생년월일을 기준으로 특정 기능 자체를 막아야 했는데, 이런 제약은 나중에 붙이면 화면 곳곳에 조건문이 흩어집니다.
문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.
결정 01
결정 02
결정 03
결정 04
금 시세를 실시간으로 받아 Recharts로 추이를 시각화.
시세를 기준으로 예상 금액을 대화형으로 안내하는 견적 흐름.
네이버·카카오·구글·애플 소셜 로그인과 일반 회원가입을 Auth.js로 구축.
PASS 본인인증을 연동하고 생년월일 기준으로 미성년 기능 제한을 적용.
Firebase Realtime Database로 사업자와 사용자 간 채팅을 구현.
Sweet Tracker API를 연동해 접수한 물건의 배송 상태를 확인.
포트원(PortOne) 결제를 붙여 정산·결제 흐름을 처리.
접수 → 수거 → 감정 → 정산까지 현재 위치를 타임라인으로 표시.
돈이 걸린 화면에서는 기능보다 신뢰가 먼저입니다. 숫자가 한 번이라도 어긋나 보이면, 그 뒤에 아무리 좋은 기능을 붙여도 사용자는 처음의 의심을 기억합니다. 계산을 한 곳에 모으고 테스트로 못 박아 두는 건 그 뒤로 그냥 기본이 됐습니다.
혼자 전담한다는 것은 자유롭다는 뜻이 아니라, 내가 세운 규칙을 지적해 줄 사람이 없다는 뜻이었습니다. Storybook과 테스트를 도입한 것은 결국 미래의 나에게 리뷰를 맡기는 장치였다고 생각합니다.
다단계 폼은 처음부터 '중간에 나갔다 돌아온다'를 전제로 설계해야 합니다. 나중에 붙이려면 각 단계가 이미 서로를 참조하고 있어서 되돌리기가 어렵습니다.