컴퓨터 판매 사이트

BACKGROUND

매일 다나와 가격을 보고 엑셀에 수기로 옮기는 일을 실제로 하고 있습니다. 그 업무를 대체할 수 있는 컴퓨터 판매 사이트를 직접 만들기로 했습니다. 일반 쇼핑몰을 그대로 복제하면 클론 코딩으로 보일 것 같아, 부품 호환성 검증 하나를 깊게 파고 나머지는 표준 이커머스로 채우는 전략을 잡았습니다. 서버가 필요 없는 부분을 먼저 끝내고 정적으로 배포한 뒤, 결제와 DB는 그 위에 얹는 순서로 진행 중입니다.

WHAT I BUILT

호환성 검증 엔진을 순수 함수로

CPU 소켓, 메모리 규격, 그래픽카드 길이, 쿨러 높이, 파워 용량, 성능 병목까지 규칙 11종을 React도 네트워크도 모르는 함수 하나에 모았습니다. 구성을 넣으면 문제 목록이 나오는 형태라 테스트가 붙습니다. 소켓 불일치처럼 물리적으로 조립이 안 되는 것은 오류로 막고, 파워가 빠듯한 것처럼 감수할 수 있는 문제는 경고로만 띄웁니다.

가격의 원천을 엑셀로

현행 업무가 엑셀 수기 입력이라 그 파일을 그대로 입력으로 받습니다. 상품코드로 매칭하고, 0원·중복 행은 거부, 현재가 대비 30% 넘게 튀는 값은 오타로 의심해 보류합니다. 200줄 중 한 줄의 자릿수 실수를 사람 눈으로는 못 잡는데, 이 규칙 한 줄이 잡습니다. 수집원이 엑셀에서 외부 API로 바뀌어도 검증·리포트는 같은 코드를 씁니다.

장바구니에 가격을 저장하지 않기

담긴 상품과 수량만 저장합니다. 가격을 함께 저장하면 그 값이 곧 낡고, 낡은 가격으로 결제 금액을 계산하는 사고로 이어집니다. 금액은 주문을 만드는 시점에 서버가 DB 기준으로 다시 계산해 스냅샷으로 고정하는 설계입니다. 클라이언트가 보낸 금액은 신뢰하지 않습니다.

다나와 크롤링을 하지 않은 이유

기술적으로는 가능했습니다. 하지만 매일 전 품목 가격을 긁는 것은 데이터베이스제작자 권리 침해 소지가 큽니다. 대법원이 크롤링 무죄를 인정한 사건(2021도1533)의 전제가 "수집량이 DB의 상당 부분이 아님"이었는데, 가격 DB는 다나와 사업의 본체입니다. 공식 API와 엑셀 업로드로 방향을 바꿨습니다.

정적 배포로 시작하고 서버는 나중에

상품 목록, 장바구니, 견적짜기는 서버 없이 브라우저에서 전부 돌아갑니다. 그래서 포트폴리오 허브와 같은 정적 배포 파이프라인을 그대로 쓰고, 서버가 꼭 필요한 결제 검증과 웹훅이 들어오는 시점에 배포 방식을 다시 정하기로 했습니다. 견적 공유 링크도 서버 저장 대신 구성을 토큰으로 인코딩해 URL에 싣는 방식으로 먼저 만들었습니다.

WHAT I LEARNED

규칙 엔진을 화면에서 떼어내자 테스트가 먼저 실수를 잡았습니다. 엔진이 아니라 제가 짠 테스트 픽스처가 틀려 있었고, 그걸 테스트 없이 눈으로 확인했다면 넘어갔을 겁니다.

"암호화해 달라"는 요구를 그대로 받지 않았습니다. 정적 사이트에는 복호화 키를 숨길 곳이 없어서 어떤 구현도 난독화 이상이 될 수 없고, 애초에 감출 값도 아니었습니다. 요구 뒤의 문제(주소가 읽기 흉함)를 푸는 쪽이 맞았습니다.

법적 리스크를 근거로 기술 선택을 바꾼 경험이 설계 문서에 그대로 남았습니다. 할 수 있는 것과 해도 되는 것은 다릅니다.