경매야 서비스 개발 기록

🏨경매야 플랫폼이란 무엇인가?

 경매야 플랫폼이란 공인중개사, 일반유저 또는 회사에서 부동산 물건을 등록 받아, 경매 또는 매매 방식으로 중개를 해주는 BtoC 서비스를 제공해준다. 경매 방식은 경매 물건과 서명된 입찰 내용 블록체인에 등록하고, 개찰 후 낙찰 결과를 산정하여 유저에게 신뢰있는 경매 서비스를 제공한다.
경매야 온라인 경매 안내

🔥개발 리소스

해당 프로젝트에서는 FE 시스템 설계, 개발 및 리드를 담당했다.
개발 기간은 약 2달 반(2021-01-01 ~ 2021.03.15)이 소요 되었다.
2021.03.15부터 현재까지 계속 운영 및 유지보수를 진행 중이다.
회사 보안을 위해 간단하게 기술 하겠다.

투입 인력

1. FE 개발 6개월 차 1명(me)
2. 1년 미만 만능 BE 개발자 1명😎
3. 퍼블리셔 담당 모바일 개발자(?..!) 1명🤣
4. 중간에 인력 보충으로 온 신입 FE 개발자 1명😣

기술 스텍

• TypeScript
• Next.js
• Express(custiom server)
  next.js 서버 단에서 익숙하고 생태계가 넓은 express를 custom server를 사용
• React.js
  access token 또는 서버에서 관리 해줘야 하는 데이터 저장용도
• Redis (session storage)
• scss
• Matarial-UI
• Atomic Design Pattern
  이전 프로젝트와는 다르게 컴포넌트를 조금 더 효율 적으로 관리 하기 위해 도입한 컴포넌트 디자인 페턴
  

🍥서비스 설계

요구 기능 리스트

매인

• 배너
• 물건목록
• 고객지원

경매, 이벤트, 매매 물건

• 물건 목록
• 물건 상세

경매 하기

• 입찰하기
• 낙찰가 맞추기 이벤트
• 낙찰 및 유찰 참여 내역
• 낙찰가 맞추기 이벤트 참여 내역
• 입찰 내역 검증하기

고객지원

• 공지사항
• FAQ
• 보도자료

계정 관련

• 로그인
• 회원가입
• 아이디, 비밀번호 찾기
• 회원 탈퇴
• 비밀번호 변경

마이페이지

• 입찰 목록 및 상세
• 입찰 및 낙찰 포기
• 환불 계좌 등록 및 삭제
• 낙찰가 맞추기 목록
• 포인트 사용 및 적립 내역
• 친구 추천하기
• 중개사 등록하기

시스템 구성

BE Server와의 통신

BE Server에서는 Rest API, GraphQL의 형태로 데이터를 제공해 주었다. 주로 read 기능은 GraphQL를 사용했고, create, update, delete와 같은 기능은 API 형태로 제공 받았다.
Authenticationd은 로그인시 제공 받은 JWT 토큰을 Redis session storeage에 담아 두고 인증이 필요한 통신에 첨가했다. 이로 인해서 FE Client에서 필요한 통신은 모두 FE Server를 거쳐 가게 설계 했다.

FE Server의 구조

FE Server는 기본적으로 SSR을 위한 Next.js를 사용 했다. Next.js에서는 Express나 Nest 같은 BE 프래임워크를 사용 해서 Custom Server 기능을 지원 해준다. 나는 익숙하고 커뮤니티가 활발한 Express를 선택해 사용 했다. Custom Server를 사용 하지 않아도 FE Server를 구현 할 수 있지만, 조금 더 구조화 시키기 위해 사용 하지 않았다.
참고 : https://nextjs.org/docs/advanced-features/custom-server

server의 폴더 구조는 크게 middleware, plugin, router.api, router.page로 구분해서 사용 했다.(BE와는 다르게 FE는 변경 사항이 많고 end-point가 많아 라우터 설계가 어려웠지만 아래와 같이 작성 하니 변동 성에 강했다.)

server
├─ middleware
│  └─ example
├─ plugin
│  └─ example
│    └─ index.ts
├─ routers
│  ├─ api
│  │  ├─ api.router.ts
│  │  └─ user
│  │     ├─ account
│  │     │  ├─ account.router.ts
│  │     │  └─ controller
│  │     │     ├─ getLogout.ts
│        │     ├─ index.ts
│  │     │     └─ postSignin.ts
│  │     └─ user.router.ts
│  ├─ index.ts
│  └─ pages
│     └─ user
│        ├─ account
│        │  ├─ account.router.ts
│        │  └─ controller
│        │     ├─ index.ts
│        │     └─ signin.ts
│        └─ user.router.ts
└─ server.ts

아토믹 디자인

이전 프로젝트인 경매야 사전 가입 서비스에서는 컴포넌트 관리를 component라는 단 하나의 폴더안에 쑤셔 박아 사용 했었다. 다행이도 사전 가입 서비스는 작은 규모의 프로젝트 였기 때문에 감당이 가능 했지만, 이번 프로젝트에서는 큰 규모의 서비스이기에 대안이 필요 했다. 여러 아키텍쳐를 검색 중 컴포넌트의 재 사용성을 강조하는 아토믹 디자인을 채택 했다. 아래와 같은 구조로 구성 했다. (pages, templetes, organisms, molecules, atoms)

src
  ├─ pages
  │  ├─ 404.tsx
  │  ├─ user
  │  │  └─ account
  │  │     └─ signup.tsx
  │  ├─ _app.tsx
  │  ├─ _document.tsx
  │  └─ _error.tsx
  ├─ styles
  │  ├─ globals.scss
  │  ├─ index.scss
  │  ├─ SpoqaHanSans-kr.scss
  │  └─ _variables.scss
  ├─ templates
  │  ├─ styles
  │  │  └─ user
  │  │     └─ account
  │  │        └─ signup.scss
  │  ├─ user
  │  │  ├─ account
  │  │     └─ signup.tsx
  │  └─ _error.tsx
  ├─ ui
  │  ├─ atoms
  │  │  └─ input
  │  │     ├─ InputCheckbox.tsx
  │  │     └─ styles
  │  │        └─ InputCheckbox.scss
  │  ├─ molecules
  │  │  └─ card
  │  │     ├─ AuctionMiscarriageCard.tsx
  │  │     └─ styles
  │  │        └─ AuctionMiscarriageCard.scss
  │  └─ organisms
  │     ├─ carousel
  │        ├─ AuctionItemsCarousel.tsx
  │        └─ styles
  │           └─ AuctionItemsCarousel.scss
  └─ utils
     ├─ lib
     └─ redux
        ├─ actions
        ├─ reducers
        └─ store.ts

이미지 및 파일 관리

경매야에는 파일을 정적이 아닌 동적으로 관리해야 하는 포인트가 있다. 예를 들면 배너 이미지, 물건 관련 이미지 또는 파일들이 있다. 개발 초기 설계 단계에서 "파일 관리 서버가 필요하다." 라는 의견을 내었지만 한정 되어 있는 개발 기간과 인력으로 포기 후 파일 시스템 구조로 개발 하게 되었다. (아래와 같은 구조이다.)
이와 같은 구조는 개발과 론칭 이후에 치명적인 이슈를 남기게 되었는데....😥 파일이 프로젝트 내에서 관리가 되어 깃허브에 같이 푸쉬 된다는 점, 배너를 바꾸기 위해서는 서버를 재 배포를 해야 하는 상황이 생긴다는 점이 있었다. 이러한 문제점을 해결 하기 위해서 AWS S3를 사용 하게 되었는데 이에 관련한 이야기는 여기에서 확인 할 수 있다.

file
  ├─ auction
     ├─ thumbnail
     │  └─ image.jpg
     └─ images
        └─ image1.jpg
        └─ image2.jpg

🧬이슈와 해결

FE 서버 빌드 오류

서비스 론칭이 1주 전쯤에 발생 했던 오류였다. 분명 이전에는 괜찮았는데 로컬에서는 빌드가 정상적으로 되었지만 AWS EC2에서는 알 수 없는 이유로 빌드가 되지 않았다. 결국 론칭 날까지 해결을 못했고 개발 모드로 실행 시킬 수 밖에 없었다. 사건은 론칭 1주 후인 부동산 페어에서 터졌다. 개발자 모드로 돌리는 서버는 일 평균 200 ~300 명 정도의 접속도 감당하지 못했다. 이런 일이 있고 나서 성능이 높은 EC2로 바꿔, 빌드 배포를 했을 때는 거짓말 처럼 잘 되었다. 아직 까지 그 이유는 모르겠다....😂

변경이 너무 많은 기획

서비스 개발과 론칭 이후 까지 변경 요청이 가장 많이 들어온 페이지는 아마 메인 페이지 였을 거다. 초기 개발 단계에는 기획 단계에 나온 디자인으로 나름의 최적화를 해서 개발을 했는데, 이는 중간에 디자인 변경 요청이 들어온 후 오히려 발목을 잡게 되었다. 이후 메인페이지는 디자인이 조금씩 여러번 바뀌었는데, 이러한 변경 요청은 개발 기간을 늘어지게 하는 요인 중 하나였다. 물론, 개발자는 경영진과 유저의 친화적으로 개발해야 한다고 생각을 해기 때문에 이해 할 수 있었다. 이러한 고질 적인 문제를 해결하기 위해서는 초기 개발 단계에 최적화를 하지 않고 코드를 작성 하는게 아닐까 생각 했다. (미래는 고려 하지만 과하게 생각하지는 말자!! 😮)

🌹결과 화면

사이트 링크

경매야 : https://www.auctionok.co.kr

경매애 메인 페이지

경매, 이벤트, 매매 물건 목록 및 상세

경매하기

고객 지원

계정 관련

마이페이지

🍗아쉬웠던점

• 아토믹 디자인 아키텍쳐를 웅장한 마음으로 적용 시켰지만 흉내를 내는 정도로 밖에 사용을 못한것 같다.
• Next.js의 강점중 하는 초기에 SSR 방식으로 빠른 로드를 하고 이후에는 CSR 방식으로 빠른 렌더를 제공해 준다는 것인데 CSR기능을 잘 활용 하지 못한 것 같다.
• 개발 여건상 BE 서버에 검색과 필터 기능이 없었다. 이를 해결 하기 위해 FE에서는 전체 목록을 가져와 코드로 필터를 걸어야 하는 상황이 있었다.
• FE 파트에서 협업을 하게 되었는데 개발자 모두 개발 스타일이 다 달랐다. 이를 위한 규칙을 정했지만 효과는 미미했다...

🎇느낀점

처음으로 큰 규모의 프로젝트를 초기 설계 단계부터 론칭을 거처 유지 보수까지 할 수 있는 기회가 되었다. FE 개발의 큰 싸이클을 경험 했는데 역시 쉽지 않았다. 문제점도 많았고 위기도 많았지만 팀원들과 같이 해결하면 정말 값진 경험이었던 것 같다.