RE:carrot: 사용자가 만든 거래 규칙을 시스템으로 옮기다
한 판매글에 여러 물품을 함께 올리는 사람들은 자신만의 규칙을 만든다. 사진과 본문에 번호를 붙이고, 물품마다 가격을 적고, 팔린 물품에는 판매 완료 표시를 더한다. 구매자와는 채팅으로 남은 물품과 실제 결제 금액을 다시 맞춘다.
RE:carrot는 이 장면에서 시작한 팀 역기획 프로젝트다. 핵심 질문은 기능을 얼마나 더할지가 아니었다.
사용자가 본문과 채팅으로 직접 만든 거래 규칙을 시스템 안으로 옮기면 어떨까?
RE:carrot 발표자료
16장의 슬라이드로 문제 정의부터 개선안까지 확인할 수 있습니다.
슬라이드 1 / 16, RE:carrot 표지
한 게시글 안에서 거래 단위가 달라진다
당근의 중고거래에는 대화를 통해 거래를 조율하는 방식이 있고, 바로구매처럼 앱에서 결제한 뒤 택배 발송으로 이어지는 방식도 있다. 이번 프로젝트는 그중 한 게시글에 여러 물품이 함께 담긴 상황을 살펴봤다.
겉으로는 게시글 하나지만 실제 거래는 물품마다 다르게 움직인다. 어떤 물품은 먼저 팔리고, 어떤 물품은 남는다. 구매자는 여러 물품 중 일부만 원할 수 있고, 선택한 조합에 따라 결제 금액도 달라진다. 거래가 끝난 뒤 남겨야 할 판매 기록과 후기도 물품마다 다를 수 있다.
하지만 게시글이 하나의 상태와 대표 가격, 하나의 거래 기록으로만 보이면 사용자가 그 차이를 직접 메워야 한다. 본문에 적은 번호와 상태표, 채팅에서 주고받는 재확인은 그 간격을 메우기 위한 사용자의 운영 방식이라고 봤다.
“한 번에 올리고, 필요한 만큼 나눠 팔고 싶어요”
우리는 이 문제를 살펴보기 위해 복수 물품 판매자라는 가설형 사용자를 세웠다. 여러 물품을 게시글 하나로 빠르게 등록하되, 판매는 필요한 만큼 나눠 진행하고 싶은 사람이다.
이 페르소나는 실제 한 사람을 그대로 옮긴 것이 아니다. 발표에서 거래 흐름과 설계 가정을 점검하기 위해 구성한 프로젝트 가설이다.
판매자 여정은 등록 방식 결정, 촬영과 번호 부여, 게시글 작성, 문의 대응, 거래와 수정 반복, 거래 종료와 기록으로 정리했다. 앞부분에서는 한 번에 정리할 수 있다는 기대가 있지만, 문의에 답하고 판매 상태를 고치고 거래 기록을 확인하는 뒤 단계로 갈수록 피로와 막막함이 커진다는 가설을 세웠다.
구매자 여정은 게시글 발견, 남은 물품 확인, 구매 의사와 금액 확인, 수령과 후기로 이어진다. 원하는 물품이 남아 있는지 확인하고, 선택한 물품의 실제 결제 금액을 채팅으로 다시 맞추는 단계가 핵심 마찰이라고 봤다.
두 여정을 나란히 놓자 같은 구조가 판매자와 구매자에게 서로 다른 일을 만들고 있었다.
세 가지 페인포인트
1. 게시글은 하나지만 판매 관리는 물품마다 필요하다
구매자는 사진과 본문을 오가며 어떤 물품이 남았는지, 실제 가격은 얼마인지 확인해야 한다. 정보가 충분하지 않으면 판매자에게 다시 묻는다.
판매자는 물품이 팔릴 때마다 본문이나 사진의 상태를 직접 고친다. 게시글 하나를 유지하면서 그 안의 여러 물품을 수작업으로 관리하는 셈이다.
2. 물품은 여러 개지만 결제 가격은 하나다
게시글의 대표 가격이 최저가나 합산가처럼 쓰이면 구매자가 고른 물품 조합과 결제 금액이 바로 이어지지 않을 수 있다. 이때 판매자와 구매자는 채팅으로 합의한 금액을 다시 확인하거나, 결제가 가능한 가격으로 맞추는 절차를 거치게 된다.
문제는 가격 정보가 없다는 데 있지 않았다. 어떤 물품을 골랐는지와 얼마를 결제해야 하는지가 같은 구조 안에서 연결되지 않는다는 점에 있었다.
3. 여러 물품을 팔아도 판매 기록은 게시글 기준 한 건이다
한 게시글에서 여러 거래가 끝나도 기록은 게시글 한 건으로 보일 수 있다. 무엇이 언제 팔렸는지 따로 살펴보기 어렵고, 물품마다 달랐던 거래 경험과 후기를 구분해 남기기도 어렵다.
상태, 가격, 기록의 세 문제는 서로 떨어져 있지 않았다. 모두 게시글 하나와 그 안의 여러 물품을 같은 거래 단위로 다룰 때 생기는 간격이었다.
설계 원칙: 게시글 하나에서도 거래는 물품마다 관리한다
팀은 개선 원칙을 한 문장으로 정리했다.
사용자가 본문과 채팅으로 하던 관리를 시스템 안에서 구조화한다.
게시글은 여러 물품을 모아 보여주는 단위로 유지하되, 판매 상태와 결제 금액, 판매 기록은 물품 단위로 이어지게 하는 방향이다.
이 원칙을 세 가지 개선안으로 풀었다.
개선안 1. 팔린 물품만 자동으로 판매 완료
판매자는 물품을 번호, 상품명, 가격, 수량으로 나눠 등록한다. 게시글 안에 각 물품이 독립된 항목으로 들어가는 방식이다.
거래가 끝나면 판매자가 본문을 다시 고치지 않아도 해당 물품의 상태만 판매 완료로 바뀌도록 설계했다. 게시글 전체를 닫는 대신, 남은 물품과 팔린 물품이 한 화면 안에서 구분된다.
개선안 2. 고른 물품의 합계로 바로 결제
구매자는 남아 있는 물품 중 원하는 항목만 선택한다. 선택한 물품의 가격 합계는 바로 표시되고, 게시글의 대표 가격과 따로 맞출 필요 없이 그 금액으로 결제 흐름에 들어간다.
결제 화면에서도 물품별 내역을 다시 보여준다. 사용자가 무엇을 골랐고 각 물품의 가격이 얼마인지, 최종 금액이 어떻게 구성됐는지를 한 흐름에서 확인하도록 했다.
개선안 3. 결제마다 거래를 만들고 물품별 후기를 연결
판매자는 게시글 전체의 거래를 한눈에 보되, 구매자가 결제할 때마다 거래 기록 한 건이 만들어지도록 설계했다. 거래마다 포함된 물품, 금액, 진행 상태를 확인할 수 있다.
후기도 거래마다 따로 받고, 그 거래에 포함된 물품과 연결한다. 게시글 하나 아래에 여러 거래가 생겨도 어떤 물품이 어떤 경험과 이어졌는지 구분해 남길 수 있게 한 것이다.
화면을 더하는 대신 단위를 다시 나눴다
프로토타입에서는 물품 등록, 판매 상태 반영, 선택 합계 확인, 결제 내역, 판매 기록과 후기까지 하나의 흐름으로 연결했다. 이는 현재 당근이 제공하는 공식 기능을 소개하거나 앞으로의 정책을 예측한 것이 아니다. 팀이 발견한 문제를 검토하기 위해 만든 독립적인 역기획 설계안이다.
이번 작업에서 가장 크게 배운 점은 화면보다 먼저 데이터와 거래의 단위를 정해야 한다는 것이었다. 게시글, 물품, 거래를 모두 하나로 보면 사용자의 수작업을 화면 밖으로 밀어내게 된다. 반대로 세 단위를 구분하면 상태는 물품에, 결제는 선택한 조합에, 기록과 후기는 실제 거래에 연결할 수 있다.
다만 이 설계가 실제 사용자에게 더 편한지는 별도 검증이 필요하다. 여러 물품을 나눠 등록하는 일이 새로운 부담이 되지는 않는지, 부분 판매 이후 남은 물품이 충분히 명확한지, 채팅 거래와 바로구매 사이에서 사용자가 자연스럽게 선택할 수 있는지를 사용자 테스트로 확인해야 한다.
RE:carrot는 당근과 제휴하거나 당근의 의뢰를 받아 진행한 프로젝트가 아닙니다. 공개된 서비스와 프로젝트에서 관찰한 화면을 바탕으로 문제를 정의하고 개선 흐름을 제안한 독립 역기획입니다.