오픈마켓 프로젝트

배경과 문제

이스트소프트 오르미 프론트엔드 개발 과정의 중간 프로젝트로, 제공된 디자인과 API 명세에 맞춰 오픈마켓 페이지를 구현했습니다. 정해진 화면을 재현하는 데 그치지 않고 프레임워크 없이 여러 페이지를 하나의 애플리케이션처럼 연결하는 것과, 평가 범위에는 포함되지 않았지만 명세로 제공된 판매자 관리 영역까지 완성하는 것을 목표로 삼았습니다.

담당 범위

개인 프로젝트로 상품 목록·검색·상세, 회원 가입과 로그인, 장바구니, 주문과 주문 내역을 포함한 구매자 흐름을 구현했습니다. 여기에 판매 상품을 조회하고 등록·수정·삭제할 수 있는 판매자 센터를 추가했으며, Sass로 화면별 스타일을 나누고 반응형 레이아웃을 구성했습니다.

핵심 기술적 결정

History API 기반 SPA 라우터

라우팅 라이브러리 없이 pushState와 popstate를 이용해 클라이언트 라우터를 구현했습니다. 정적 경로뿐 아니라 /items/:id, /mypage/order/:id처럼 매개변수가 있는 경로를 비교하고 값을 추출하며, 일치하는 경로가 없을 때는 404 화면을 렌더링합니다. 링크 클릭, 브라우저의 앞·뒤 이동, 주소 직접 입력을 같은 라우팅 흐름으로 처리했습니다.

각 경로는 화면을 만드는 함수와 상호작용을 연결하는 함수를 별도로 등록했습니다. 라우팅할 때 본문과 문서 제목, body를 교체한 뒤 현재 화면에 필요한 이벤트를 연결해 페이지 단위 코드를 분리했습니다.

명세에만 있던 판매자 관리 흐름 구현

평가 대상이던 구매자 화면을 마친 뒤, 판매자 계정의 상품 관리 흐름까지 범위를 넓혔습니다. 판매 중인 상품을 표로 조회하고 삭제 확인 대화상자를 제공했으며, 선택한 상품 정보를 등록 폼으로 전달해 동일한 화면에서 신규 등록과 수정을 처리했습니다.

인증 상태에 따른 화면 분기

구매자와 판매자 계정에 따라 헤더와 진입 가능한 화면을 다르게 구성했습니다. 당시에는 브라우저 지문으로 만든 값을 이용해 저장소의 토큰을 암호화했지만, 클라이언트 내부의 암호화만으로 안전한 저장 경계를 만들 수 없고 실행 환경 변화에 따라 지문이 달라질 수 있다는 한계도 확인했습니다.

결과

상품 탐색부터 장바구니와 주문, 주문 내역까지 구매자의 전체 흐름을 연결하고 판매자의 상품 CRUD까지 구현했습니다. 서비스 배포는 종료되었지만, 구현 코드와 당시의 설계 기록은 GitHub 저장소에 공개되어 있습니다.

회고

직접 만든 라우터를 통해 경로 매칭, 히스토리 변경, 동적 매개변수, 화면 렌더링이 어떻게 연결되는지 구체적으로 이해할 수 있었습니다. 반면 화면이 바뀔 때마다 body 전체를 교체하고 경로별 이벤트 함수를 수동으로 등록하는 구조는 애플리케이션이 커질수록 생명주기 관리가 어려워집니다. 지금 다시 만든다면 검증된 라우터를 우선 사용하되, 직접 구현해야 한다면 렌더링 범위와 이벤트 정리 규약부터 명확히 설계하겠습니다.