D E S I G N & D E V E L O P M E N T

미술품 중개 거래 플랫폼
구축 제안서

작품이 주인공이 되는 화면과, 돈이 정확히 흐르는 구조

신영진 | 백엔드 개발 · 시스템 운영 파트너

화면을 먼저 만들어 보았습니다

디자인을 가장 우려하신다는 말씀을 보고, 설명보다 실제 화면으로 방향을 보여드리는 편이 낫다고 판단했습니다

홈 — 큐레이션

이 주의 작품을 크게 배치하고, 작가와 신작을 아래로 이어 붙였습니다

작품 상세

이미지가 화면 상단을 채우고 UI는 물러납니다. 구매 버튼은 하단에 고정

작가 프로필

작가 소개와 작품을 한 페이지에 모아 작가 단위로 탐색되게 했습니다

관리자 승인

작품·작가 승인을 목록에서 바로 처리합니다

위 화면은 이번 서비스에 맞춰 제작한 것으로, 링크에서 직접 눌러보실 수 있습니다. 실제 작업에서는 아래 방식으로 전체 화면의 완성도를 맞춰 나가겠습니다.

디자인 완성도를 이렇게 확보하겠습니다

20화면이 하나의 서비스로 보이려면, 화면을 하나씩 그리기 전에 규칙을 먼저 정해야 합니다

1작품이 주인공미술품 서비스에서 흔한 실수는 카드·버튼·배지가 작품보다 눈에 띄는 것입니다. UI 색은 배경 한 톤과 강조 한 색으로 제한하고, 작품 이미지가 화면에서 가장 진하게 보이도록 잡습니다

2디자인 규칙 먼저 확정색·서체·여백·모서리·버튼 형태를 문서로 먼저 정합니다. 20화면을 개별로 그리면 후반부 화면이 앞과 달라지는데, 규칙을 먼저 두면 그 문제가 생기지 않습니다

3핵심 3화면 선확정홈·작품 상세·작가 프로필을 먼저 시안으로 만들어 확정받고, 나머지는 그 톤에 맞춰 전개합니다. 전체를 다 그린 뒤 방향을 바꾸면 되돌리기 어렵습니다

4이미지 품질 관리작품 사진은 작가가 올립니다. 원본 크기와 비율이 제각각이면 목록이 지저분해지므로, 업로드 시 자동 리사이즈와 권장 비율 안내를 넣어 화면 품질을 유지합니다

디자인은 기능보다 되돌리기 어려운 영역이라, 초반에 방향을 확정하는 데 시간을 더 쓰는 편이 결과적으로 빠릅니다.

기술 스택과 선택 이유

백엔드는 희망하신 PHP로 구성하고, 프론트엔드·앱 패키징·서버는 아래와 같이 제안드립니다

B A C K E N DPHP + Laravel

결제·정산처럼 돈이 오가는 처리에는 트랜잭션과 예약 작업이 필요합니다. Laravel은 이를 기본 제공해 직접 만들 때보다 오류 여지가 적고, PHP 개발자를 구하기도 쉬워 이후 유지보수에 유리합니다

F R O N T서버 렌더링 모바일 웹

20화면 규모에 별도 프레임워크는 과합니다. 서버에서 화면을 만들어 보내는 방식이 첫 화면 표시가 빠르고, 작품 이미지가 많은 서비스에 유리합니다

A P PWebView 패키징

모바일 웹을 감싸 Android 앱으로 만듭니다. 웹을 고치면 앱도 함께 바뀌어 스토어 재심사 없이 반영됩니다. 푸시 알림은 FCM으로 연동합니다

I M A G E이미지 저장소 + CDN

고화질 작품 이미지를 서버에 그대로 두면 느려집니다. 별도 저장소에 올리고 CDN으로 전달해, 전국 어디서나 빠르게 열리게 합니다

서버 구성 — 초기에는 단일 서버로 시작하되 이미지 저장소를 분리해 둡니다. 이렇게 해두면 나중에 방문자가 늘어 서버를 키우거나 늘릴 때 구조를 다시 짜지 않아도 됩니다. 도메인·SSL은 자동 갱신으로 구성하고, 모든 계정은 발주사 명의로 개설해 드립니다.

결제와 정산 — 가장 신중해야 할 부분

기능 목록에는 한 줄이지만, 실제로는 이 프로젝트에서 가장 오류가 생기기 쉬운 영역입니다

고액 결제 대응	미술품은 단가가 높아 카드 한도나 승인 실패가 자주 발생합니다. 결제 수단을 카드 외에 계좌이체·간편결제로 넓혀두고, 실패 사유를 구매자가 알 수 있게 표시하는 것이 이탈을 줄입니다
결제대금예치(에스크로)	전자상거래법상 일정 금액 이상 선불 거래는 결제대금예치나 소비자피해보상보험 가입이 요구될 수 있습니다. PG사 선정 전에 적용 대상인지 확인이 필요하며, 해당되면 에스크로를 지원하는 PG로 선정해야 합니다
작가 정산과 원천징수	작가가 사업자인지 개인인지에 따라 정산 처리가 달라집니다. 개인 작가에게 지급할 때 원천징수가 필요한 경우가 있어, 작가 등록 시 구분 정보를 받아두지 않으면 나중에 소급 정리가 어렵습니다. 세무 처리 방식은 세무 담당자 확인을 거쳐 확정하는 것을 권장드립니다
취소 · 환불	구매 후 취소가 발생하면 이미 잡힌 정산을 되돌려야 합니다. 정산을 즉시 지급이 아닌 주기 지급으로 두고, 지급 전 취소는 정산에서 제외되도록 설계하면 사고를 줄일 수 있습니다
기록을 남기는 구조	주문·결제·정산은 수정하지 않고 상태와 이력으로 관리합니다. 나중에 "이 금액이 왜 이렇게 나왔는지" 추적할 수 없으면 분쟁 시 대응이 불가능합니다

성공적인 마무리의 기준

아래가 충족되면 이 프로젝트가 성공적으로 마무리되었다고 봅니다

1화면이 서비스 인상을 만드는 것20화면이 하나의 서비스로 보이고, 작품이 가장 먼저 눈에 들어오는 것. 말씀하신 대로 미술품 서비스는 여기서 신뢰가 결정됩니다

2결제부터 정산까지 한 번 완주하는 것실제 카드로 결제해 작가 정산까지 이어지는 흐름을 오픈 전에 최소 1건 완주해 보는 것. 각 기능이 개별로 동작하는 것과 처음부터 끝까지 이어지는 것은 다릅니다

3금액을 추적할 수 있는 것정산 금액이 어떤 주문에서 나왔는지 관리자 화면에서 확인 가능한 것. 돈이 오가는 서비스에서 가장 중요한 요건이라고 봅니다

4앱이 스토어에 올라가는 것Android 앱이 심사를 통과해 실제 설치 가능한 상태. 심사 반려 대응까지 포함해 마무리로 봅니다

2번을 특히 강조드립니다. 결제·정산은 각각 테스트하면 문제없어 보여도, 실제로 이어 보면 중간에서 어긋나는 경우가 많습니다. 오픈 전 실거래 1건 완주를 일정에 넣는 것을 제안드립니다.

확인이 필요한 부분

공고만으로 판단이 어려워 미팅 시 여쭙고 싶은 사항입니다

?관리자 페이지 분량미팅 시 안내하신다고 하셨는데, 화면 수에 따라 전체 공수가 크게 달라져 가장 먼저 확인이 필요합니다

?정산 방식수수료율이 작가마다 다른지, 정산 주기가 어떻게 되는지, 지급은 수동인지 자동인지 — 설계 전에 정해져야 합니다

?사업자 준비 상황통신판매업 신고와 PG 가맹 심사가 완료되어야 실제 결제가 가능합니다. 심사에 시간이 걸리므로 개발과 병행해 진행하시는 편이 좋습니다

?작품 판매 방식한 작품이 한 점만 판매되는지(판매 후 노출 종료), 에디션처럼 여러 점이 있는지에 따라 재고 처리 구조가 달라집니다

?배송 처리작가가 직접 발송하는지 본사를 거치는지 — 미술품은 파손 위험이 있어 배송 방식이 정산·환불 정책과도 연결됩니다

보이는 것과
보이지 않는 것

작품이 돋보이는 화면과, 금액이 틀리지 않는 구조를 함께 만들겠습니다.
디자인 데모는 직접 눌러보실 수 있습니다.