커머스 웹사이트 구축
빈티지 조명이 좋아 브랜드를 만들었다. 판매는 네이버 블로그와 인스타그램으로 시작했다. 주문이 들어올 때마다 구매 안내 메시지를 보내고 주문 내역을 수기로 취합해야 했고, 팔릴수록 이 방식으로는 감당이 어려웠다. 체계적으로 관리할 수 있는 커머스 사이트가 필요하다고 판단했다.
처음에는 cafe24면 충분할 줄 알았다. 교양 수업에서 배운 HTML과 CSS 관련 지식이 조금 남아 있어서, 템플릿을 수정하는 정도는 조금만 공부하면 어렵지 않겠다고 생각했다. 그런데 원하는 화면을 만들기에는 아는 것이 부족했다. 책을 사서 다시 공부했고, 기능을 손보려면 JavaScript가 필요하다는 것도 알게 됐다. 할 수 있는 것이 많지 않았지만 그 과정이 재미있었다. 더 제대로 만들고 싶어 공부를 이어갔고, 그 과정에서 개발자가 되기로 결심했다. arffy는 그 출발점이다.
cafe24 같은 기성 쇼핑몰 플랫폼 기반으로 계속 개발할 수 있는지부터 부딪혀 봤다. 기성 플랫폼은 위젯과 템플릿 기반이라, 색상과 폰트를 바꾸는 수준은 되지만 정해진 틀을 벗어난 레이아웃이나 인터랙션을 코드 레벨에서 다루기는 어려웠다. 로그인과 회원가입 같은 화면은 플랫폼 공통의 모양을 크게 벗어나지 못해 브랜드의 느낌과 겉돌았다. 브랜드의 인상을 화면 구석까지 반영하려 할수록 템플릿이 허용하는 범위와 부딪혔다.
그래서 직접 만들기로 했다. 고객이 보는 스토어부터 운영자가 쓰는 관리자 페이지까지.
모든 화면은 피그마로 먼저 디자인한 뒤 코드로 옮겼다.
다만 처음부터 체계가 있지는 않았다. 반복해서 쓰이는 컴포넌트를 필요할 때마다 새로 만들었더니, 디자인이 바뀔 때마다 쓰인 곳을 피그마와 코드에서 일일이 찾아 고쳐야 했고, 놓친 곳에서 UI가 미묘하게 어긋나기도 했다. 그래서 아토믹 디자인을 기준으로 디자인 시스템을 도입했다. 컬러 팔레트와 타이포그래피 스케일, 아이콘 가이드라인을 Foundation으로 정의하고, 컴포넌트를 최소 단위부터 화면까지 조합해 올라가는 상향식으로 정리했다.

분류에서 애매했던 것은 분자와 유기체의 경계다. 기준은 맥락의 유무로 뒀다. 그 자체로는 맥락이 없어 재사용 폭이 넓으면 분자로(Modal, ButtonSet), 이름만으로 역할과 정보가 드러나면 유기체로(ProductCard, ImageCarousel) 분류했다.
결제는 PortOne으로 카카오페이, 토스페이, KG이니시스를 연동했다. 가장 신경 쓴 것은 검증이다. 검증은 세 단계로 나눴다.
첫째, 주문 선생성. 결제창을 띄우기 전에 서버에 주문을 먼저 만들고, 주문 고유값(merchant_uid)과 금액을 받아온다. 결제부터 띄우고 주문을 나중에 만드는 것이 아니라, 주문이 먼저 존재하게 했다.
둘째, 금액 대조. 서버가 내려준 금액과 화면이 들고 있던 금액을 비교해, 다르면 결제를 중단한다. 클라이언트에서 금액이 조작되는 경우를 막기 위해서다.
셋째, 서버 사이드 재검증. 결제가 끝나면 그 결과를 그대로 믿지 않는다. imp_uid와 merchant_uid를 서버로 보내, 서버가 PortOne에 실제 결제 내역을 다시 확인한다. 클라이언트가 성공이라고 응답해도 최종 판단은 서버가 한다. 실패한 결제도 같은 검증을 거쳐 결과 화면으로 분기했다.

에러 처리는 두 영역으로 나눴다. 입력 단계의 오류는 커스텀 에러 클래스로 다뤘다. 필수 값 누락, 형식 오류 등의 에러를 각자의 클래스로 정의해, 사용자에게는 어떤 값이 왜 문제인지가 토스트로 안내된다.
API 오류는 백엔드와 함께 정의했다. 클라이언트는 합의한 서버 응답의 에러 코드 체계에 따라 메시지와 동작을 분기한다. 이 처리를 API 영역의 Error Boundary가 맡고, 거기서 잡히지 않는 오류는 전역 Error Boundary가 받는 2단 구조다.
고객 스토어에는 상품 목록과 상세, 장바구니, 주문과 주문 조회, 문의를 뒀다.
관리자 페이지에는 운영에 실제로 필요한 것들을 담았다. 상품 등록과 수정, 주문 목록과 상세 조회, 환불 접수, 공지 관리, 문의 응대까지. SNS에서 수기로 하던 구매 안내와 주문 취합이 화면으로 대체됐다.