광고주 매칭 웹 서비스 풀스택 아웃소싱 회고

현수·2023년 2월 27일
0
post-thumbnail

1. 프로젝트 설명

광고주 매칭 서비스 PALO

물품 회사와 TV, OTT 등 영상 프로그램 제작사간에 광고를 서로 매칭해주는 서비스이다.

물품회사와 영상 제작사는 자사 소유의 상품을 홍보하는 게시글을 올릴 수 있다. 그리고 물품회사는 영상 제작사가 올린 홍보 게시글을, 영상 제작사는 물품 회사가 올린 홍보 게시글을 열람할 수 있다. 만약 해당 상품과 자신이 소유한 상품의 광고를 진행하고 싶다면 제안을 전송하여 진행할 수 있다.

관리자는 모든 제안 요청서를 열람할 수 있으며 각 제안 요청자와 수신자에게 개별로 연락하여 광고 매칭을 진행한다.

작업 규모

외주 업체로부터 프로젝트 작업을 요청 받았으며 혼자서 클라이언트 프론트엔드, 백엔드, 어드민 프론트엔드, 백엔드를 제작하였다.

Demo 사이트

PALO Client 데모
PALO Admin 데모
데모 백엔드 서버와 통신하는 데모 사이트이며 아래의 목업 계정을 통해 각 계정 권한별로 기능을 테스트 해볼 수 있다.

회원가입의 이메일 인증과 휴대폰 인증을 제외한 모든 기능이 동작하며 만약 계정 생성을 원할시 이메일 인증번호 입력란과 휴대폰 인증번호 입력란을 공란으로 입력 후 생성 가능하다.

어드민 페이지는 어드민 계정으로만 접근 가능하다.

Mock account

어드민
ID: khsoo2439@naver.com
PW: asd123123asd

광고주
ID: khsoo2439@gmail.com
PW: asd123123asd

제작사
ID: khsoo2439@sch.ac.kr
PW: asd123123asd

Client

  • / : 메인 화면
  • /login : 로그인
  • /signup : 회원가입
  • /program : 프로그램 제작사의 홍보 게시글 모음
  • /ad : 물품 회사의 홍보 게시글 모음
  • /community : 이용안내, 공지사항, 자주묻는질문
  • /mypage : 인적사항, 작성 게시글, 즐겨찾기, 제안 리스트

Admin

  • /login : 로그인
  • /dashboard/app : 클라이언트 웹사이트 방문자수 분석
  • /dashboard/user : 유저 조회 및 삭제
  • /dashboard/community : 커뮤니티 게시글 작성
  • /dashboard/banner : 메인 화면 배너 교체
  • /dashboard/offer : 제안 요청서 확인

기술 스택

Client

  • Javascript
  • React JS
  • Redux
  • Styled Components

Backend

  • Javascript
  • Node JS
  • Express JS
  • Passport JS
  • MySQL
  • Sequelize

사이트 기능 리스트

광고 게시글

  • 자사 상품의 광고 매칭을 위해 홍보하는 게시글
  • 상품 이미지, 기본정보, 카테고리, 선호하는 카테고리 등이 존재
  • 마이페이지에서 생성, 수정, 삭제 가능
  • 프로그램, 광고주 메뉴에서 조회 가능

광고 게시글 북마크

  • 광고 게시글을 조회하면서 마음에 드는 광고 조건을 발견시 즐겨찾기 추가 및 해제 가능
  • 물품 회사는 영상 프로그램만, 영상 제작사는 물품만 즐겨찾기 추가 가능
  • 마이페이지에서 즐겨찾기 목록 확인 가능

광고 제안

  • 선택한 상품과 자사의 상품과 광고를 진행하고 싶을시 광고 제안을 통해 컨택 가능
  • 물품은 영상 프로그램만, 영상 프로그램은 물품만 광고 제안 가능
  • 제안 제목, 제안 내용 작성
  • 제안 전송시 제안 보낸 상품, 제안 받은 상품, 전송자, 수신자 정보가 관리자 페이지로 전송
  • 관리자는 제안 정보를 바탕으로 광고 프로젝트 진행

고객 서비스(커뮤니티)

  • 이용안내, 자주묻는질문, 공지/이벤트 조회 가능
  • 관리자페이지에서 생성, 수정, 삭제 가능

2. KPT (Keep / Problem / Try)

Keep - 프로젝트 완료 후에도 간직하고 싶은 잘했던 것 / 좋았던 것

데이터베이스 설계
실사용이 가능할 정도로 데이터베이스를 설계 할 수 있었다. 특히 해당 프로젝트는 일대다, 다대다 관계 테이블이 많아 데이터베이스 설계 능력을 기를 수 있었다. 상품 하나가 다수의 카테고리를 소유할 경우 일대다 테이블을 설계하였고 광고 제안 기능 구현에 있어서는 매핑 테이블을 이용하여 다대다 테이블을 설계하였다.

시퀄라이즈 사용
node.js 에서 Mysql을 손쉽게 다루기위해 JS ORM인 시퀄라이즈를 이용했다. 시퀄라이즈를 사용할시 장점은 테이블을 생성하는 코드가 있기 때문에 데이터베이스가 초기화 되거나 환경을 옮길때 생성 코드 실행 한번으로 테이블을 생성할 수 있다는 점이다. 이 점은 테스트 환경, 실서비스 환경에서 DB를 구축할때 용이했다. 또 다른 장점은 JS 문법으로 쿼리를 생성하여 데이터베이스에 접근할 수 있다는 점이다. 하지만 이점은 복잡한 쿼리문을 작성할 때는 직관적으로 작성하기 어려울 때가 있어 때론 단점이 되기도한다. 단점은 SQL뿐만아니라 시퀄라이즈 사용법도 배워야한다는 점이 있을 것 같다.

Passport + Express session 인증
안전한 로그인을 구현하기 위해 검증된 인증 라이브러리인 Passport.js 를 이용했다. 이와 함께 Express session 라이브러리를 이용하여 세션 로그인 방식을 구현했다. 또 isLoggedInisNotLoggedIn 과 같이 로그인중과 비로그인중을 확인할 수 있는 미들웨어를 만들었고 로그인했을 경우만 접근할 수 있는 API에 해당 미들웨어를 두어 권한에 따른 API 접근 통제를 구현했다.

필터 검색
흔히 쇼핑몰에서 많이 사용하는 조건 필터 검색을 구현했고 해당 로직을 구현하면서 쿼리문의 Where 조건을 작성하는 실력이 많이 늘었다. 필터 로직은 다음과 같다.

  1. 필터에서 방송사, 장르, 시청자와 같이 큰 항목별로, 조건들에 대하여 Where OR 을 사용하여 검색 결과 리스트를 얻는다.
  2. 큰 항목별로 리스트가 만들어지면 교집합 알고리즘을 통해 모든 조건에 부합하는 최종 결과 리스트를 얻는다.

필터 조건에는 장르, 세부장르, 직접 입력하여 수치 범위 검색 등 추가 기능이 존재하여 각 기능에 해당하는 로직을 구현하는 경험을 해보았다.

이메일, 휴대폰 인증 구현
회원가입 과정에서 가입하려는 이메일이 유효한지 확인하기 위해 Nodemailer 라이브러리와 Gmail 계정을 이용해 인증번호 발송 기능을 개발했다. 이메일 인증 과정은 다음과 같다.

  1. 서버에서 인증번호를 해시화한뒤 해시값을 클라이언트 쿠키로 전송
  2. 인증번호를 인증하려는 이메일로 전송
  3. 클라이언트측에서 이메일의 인증번호를 확인 후 입력
  4. 입력받은 인증번호의 해시값과 쿠키의 인증번호 해시값을 비교하여 유효성 체크

휴대폰 인증은 네이버 클라우드의 NAVER SMS API 라이브러리를 이용했다. 이메일 인증과 마찬가지로 해시와 쿠키를 이용하여 사용자의 휴대폰을 인증하였다. 다만 이는 휴대폰 소유를 인증하는 것이지 본인인증 기능을 하지 못하는 한계가 있다.

비밀번호 변경
유저의 비밀번호는 해시화되어 저장되기 때문에 유저가 비밀번호를 분실하여 정보를 요청하여도 제공할 수 없다. 다만 비밀번호를 새롭게 초기화함으로 분실된 계정에 다시 접근할 수 있다. 비밀번호를 변경하는 로직은 다음과 같다.

  1. 비밀번호 초기화 세션 토큰 값을 저장하는 데이터베이스를 활용
  2. 비밀번호 초기화를 요청한 이메일, 랜덤 생성한 토큰 값, 토큰 세션을 유지할 만료기간데이터베이스에 저장
  3. 프론트엔드의 비밀번호 변경 페이지 라우터 경로 값과 토큰, 이메일을 조합하여 쿼리 스트링을 만들고 변경할 계정 이메일로 메일을 전송
  4. 메일로 받은 링크에 접속할 경우 비밀번호 페이지 변경 페이지 접속
  5. 새롭게 변경한 비밀번호와 쿼리 스트링에 있는 이메일, 토큰, 만료기간 검증을 위해 백엔드 서버로 전송
  6. 백엔드에서는 세션 데이터베이스에 만료기간을 만족하면서 이메일과 토큰 정보가 존재하는지 확인
  7. 세션이 확인될 경우 비밀번호 변경 진행

Problem - 프로젝트 중 겪었던 어려움 / 프로젝트 완료 후에도 아쉬움으로 남는 것

페이지 접근 권한 분리
프론트엔드에서 로그인 여부에 따라 접근할 수 있는 페이지를 제한했다. 제한하는 방법은 다음과 같았다. 리덕스으로 로그인 상태를 관리했고 페이지 코드에 로그인 상태 조건문을 두어 페이지가 렌더링 될 때마다 로그인 조건을 만족하지 못할 경우(비로그인) 로그인 페이지로 리다이렉션하게 했다.
다만 이 방법의 단점이 로그인 검증 로직 전에 페이지가 렌더링이 완료되어 잠깐 유저에게 페이지가 보여진다. 이후 로그인 검증 로직이 실행되고 페이지 리다이렉션이 진행된다. 이때문에 페이지를 새로고침할 때마다 페이지가 깜박거리는 현상이 발생하고 만약 로그인 하지 않은 상태에도 다른 로그인 관련 로직이 실행될 수 있다. 해당 프로젝트에서는 이로인한 치명적인 문제가 발생하지 않도록 설계했지만 다음 프로젝트에서는 좀 더 효율적인 프론트엔드의 권한 분리 방법이 필요할 것 같다.

Try - Problem 중 해결된 사항에 대한 해결 방법 / 해결되지 않은 사항에 대한 피드백

쿠키 CSRF 문제
본 프로젝트에서는 로그인, 이메일 인증, 휴대폰 인증에서 브라우저 쿠키를 이용한다. 이때 서버에서 인증관련 쿠키를 프론트엔드로 전송할 때 쿠키를 전달 받지 못하는 문제를 겪었다. 이때 크롬 개발창에서 네트워크 Response 헤더를 확인해보면 서버와 클라이언트 서버 주소가 다르기 때문에 CSRF 문제로 쿠키를 받아올 수 없다는 점을 확인할 수 있었다. 이를 해결하기 위해서는 쿠키에 Same-Site 옵션을 설정하라고 하는데 해당 옵션은 또 https 환경에서만 동작한다는 것이 문제 였다. 이를 해결하기 위해 쿠키를 http 헤더를 통해 직접 전송하는 것이 아닌 body에 쿠키값을 담아 전송하고 클라이언트단에서 직접 쿠키를 설정하는 방법으로 문제를 해결했다.

3. 느낀점

React, Express, Mysql을 이용하여 처음으로 풀스택 개발을 해보았다. 풀스택을 하면서 느낀점이 혼자 모든 것을 개발하기 때문에 결국 나만 볼 수 있는 코드로 빠르게 작성된다. 즉 코딩 컨벤션이 지켜지지 않게되고 유지보수하기 어려운 코드가 탄생하게된다. 물론 외주 프로젝트 특성상 짧은 시간내에 결과를 만들어야하기 때문에 코드 리팩토링을 하며 작성하기 어려운점 때문도 있다.

그래도 풀스택으로 프론트엔드와 백엔드 서버 그리고 배포까지 혼자서 모든 것을 해냈다는 점에 의의가 있다고 생각한다. 나는 프론트엔드 개발자를 희망하지만 실제 개발 프로젝트를 하려면 백엔드와 같이 다른 분야의 개발자와 소통 능력도 중요하다고 생각한다. 그리고 이번 경험은 웹 개발 전체 프로세스를 이해하는데에 도움이 되었고 이는 다른 분야의 개발자와 소통 능력을 향상 시킬 것으로 기대한다.

0개의 댓글