중고 거래 앱 IA — 채팅보다 먼저 약속 상태를 설계하는 법

중고 거래 앱의 IA는 채팅방 목록에서 시작하지 않습니다. 누가 무엇을 제안할 수 있고, 언제 한 약속이 확정되며, 이견이 생기면 무엇을 보류하는지부터 정해야 합니다. 서울 전역의 중고 소형생활가전 직거래를 가정하면, 메시지는 대화를 돕지만 약속의 상태를 대신 판정할 수는 없습니다.

이 글은 공개 기획 묶음의 가설을 바탕으로 작성하고 저장한 중고 거래 앱 전체 IA를 설명합니다. 합정·망원은 마포구 예시 데이터이며 서비스 범위는 서울 전역입니다. 판매자의 상태 고지는 플랫폼의 품질 인증이나 성능 보증이 아닙니다. 공개된 산출물은 서비스 구조를 정리한 기획 문서이며, 실제 앱 출시나 사용자 검증 성과를 뜻하지 않습니다.

공개 IA38의 역할별 서비스 구조. 이용자 앱과 플랫폼 관리자 탭에서 상태와 권한을 나눕니다.

상품과 약속은 다른 상태를 가집니다

상품이 판매중이라는 사실과, 특정 구매자와 시간·장소를 조율하고 있다는 사실은 다릅니다. 둘을 같은 상태로 두면 여러 문의가 들어온 순간부터 화면의 버튼이 모호해집니다. 그래서 상품은 판매중에서 약속조율중, 약속확정, 현장확인중, 거래완료로 흐르고, 약속은 제안됨에서 확정됨·완료됨 또는 취소됨·노쇼기록됨으로 나누는 편이 낫습니다.

여기서 중요한 규칙은 “수락됨”을 별도 중간 상태로 만들지 않는 것입니다. 상대가 수락하는 처리 자체가 원자적으로 확정돼야 합니다. 그래야 두 사람이 거의 동시에 수락하더라도 물건 하나에 활성 확정 약속은 하나라는 정책을 지킬 수 있습니다. 이것은 공정성을 완전히 해결했다는 선언이 아니라, MVP가 먼저 지켜야 할 충돌 방지 경계입니다.

변경과 취소는 되돌리기 버튼이 아닙니다

확정 약속의 변경안을 받았다고 기존 시간과 장소를 바로 바꾸면, 한쪽은 이미 이동 준비를 했는데 다른 쪽 화면에는 새 제안만 남을 수 있습니다. 변경안이 대기하는 동안에는 기존 확정 약속을 유지하고, 상대가 수락한 뒤에만 교체합니다. 이 규칙은 화면 수를 늘리기 위한 장치가 아니라, 지금 유효한 약속을 분명히 보여 주는 방법입니다.

1. 제안은 여러 개 가능하지만 상품당 활성 확정 약속은 하나만 둡니다.

2. 약속이 취소되면 상품은 판매중으로 돌아가고 상대에게 안내합니다.

3. 양쪽이 현장 확인을 마친 판매글은 완료로 유지합니다. 같은 판매글을 다시 판매하지 않고 새 물건은 새 등록으로 시작합니다.

4. 노쇼 신고는 신고자의 기록입니다. 상대 제재나 거래완료를 자동으로 만들지 않습니다.

차단도 같은 원칙을 따릅니다. 차단은 새 메시지와 새 약속 요청을 막는 안전 기능입니다. 이미 확정된 약속을 자동 취소하면 오히려 상대에게 필요한 종료 경로가 사라집니다. 그래서 기존 약속에는 안전 안내와 명시적인 취소 진입을 별도로 둡니다. 신고는 상품·메시지·사용자·노쇼 기록에서 시작할 수 있지만, 접수 사실과 운영 판단은 분리합니다.

현장 확인은 결제 화면이 아닙니다

현장확인중은 두 사람이 실물을 대조하기 시작했다는 기록입니다. 전원과 핵심 기능, 외관·위생, 구성품처럼 판매자가 미리 고지한 항목을 공통 목록으로 다시 볼 수 있습니다. 전원이나 핵심 기능을 확인할 수 없으면 미확인·보류로 남기며, 외관이나 구성품만 확인하고 전체 확인을 끝내지 않습니다. 한쪽만 완료하면 상대 확인 대기입니다. 이견이 나면 완료를 보류하고 기록을 남깁니다. 플랫폼이 실제 만남, 작동 상태, 거래 대금 지급을 확인하거나 보증한다는 뜻은 아닙니다.

이 구분 때문에 플랫폼 결제, 송금, 에스크로, 택배와 배송 추적은 이번 범위에 넣지 않습니다. 현장 확인 뒤의 대금 지급은 당사자가 별도로 결정하는 방식이며, 이 서비스는 결제 당사자나 보관자가 아닙니다. 신뢰를 설명하려고 범위를 부풀리면 나중에는 화면보다 약속 문구가 더 위험해집니다.

전체 IA는 역할을 나누되 기록은 이어야 합니다

실제 IA는 이용자 앱과 플랫폼 관리자, 두 탭으로 구성했습니다. 구매와 판매는 같은 계정 안에서 거래별로 바뀌는 역할이므로 별도 앱으로 나누지 않았습니다. 이용자 앱에는 인증·계정 복구·판매글 관리·검색·관심 상품·대화·약속·현장 확인·신고·문의·개인정보 요청을 담았습니다. 관리자 탭에는 계정 초대와 권한, 판매글 검토, 신고·이견 지원, 상태 오류 정정, 정책·개인정보·감사 기록을 배치했습니다. 운영자가 양측 확인을 대신 만들어 거래를 완료하거나, 이용자가 완료 뒤 핵심 기록을 조용히 바꾸는 흐름은 허용하지 않습니다.

전체 102개 항목 중 독립 화면은 66개입니다. 나머지는 메뉴 10개, 모달 17개, 섹션 9개입니다. 화면설계에서는 이 전체 IA를 연결한 뒤 이용자 대표 흐름 7개를 선택합니다. 7장은 전체 서비스의 화면 수가 아니라 검토할 시제품의 범위입니다.

IA의 구조와 실제 서비스 구현은 각각 검증해야 합니다. 다음 검증은 상태 이름이 실제 대화와 맞는지, 판매자와 구매자가 변경 대기 중 기존 약속을 이해하는지, 이견 보류가 지원 요청으로 자연스럽게 이어지는지를 보는 일입니다. 공개 기획 묶음의 가상 답변도 실제 인터뷰 결과가 아닙니다.

자주 묻는 질문

여러 사람이 같은 물건을 원하면 먼저 메시지를 보낸 사람이 예약되나요?

아닙니다. 문의는 여러 개 가능하지만, 상대 수락이 처리될 때만 하나의 활성 확정 약속을 만듭니다. 이 규칙이 실제 사용자에게 공정하게 느껴지는지는 검증이 필요합니다.

약속 시간이 지나면 거래가 자동으로 끝나나요?

아닙니다. 시간 경과, 한쪽의 완료 기록, 한쪽의 노쇼 신고만으로 거래완료나 상대 제재를 자동 처리하지 않습니다. 양쪽 현장 확인과 이견 기록을 분리합니다.

차단하면 이미 잡힌 약속도 사라지나요?

자동 취소하지 않습니다. 새 접촉은 막고, 기존 확정 약속에는 안전 안내와 별도의 취소 경로를 둡니다.

약속 기반 서비스의 IA는 메뉴를 많이 그리는 문서가 아니라, 예외가 생겼을 때 누가 무엇을 바꿀 수 있는지 정하는 문서입니다. 기획 인터뷰에서 서비스 가정을 정리하고, 상담에서 역할과 상태 흐름을 함께 검토할 수 있습니다. 상태 고지의 책임선을 먼저 정리한 글은 중고 거래 앱 기획에서 이어집니다. 공개 IA를 보며 각 상태의 담당자와 예외 처리 경로를 확인해 보세요.