📈 워런버핏테스트500

• 이용자 취향을 분석해 주식 포트폴리오를 추천해 주는 웹애플리케이션입니다.

🗂 깃헙 저장소

• https://github.com/WarrenBuffettTest500/Client (프론트엔드)
• https://github.com/WarrenBuffettTest500/Server (백엔드)

🎬 시연 영상

📢 프로젝트 발표 영상

• https://youtu.be/jMw5MIxLY3o?t=3443 (57분 24초부터)

🔗 배포 주소

• https://warrenbuffett-test500.site/
• 무료 API를 사용하고 있습니다. API 요청 제한 횟수를 넘으면 웹사이트가 정상적으로 작동하지 않거나 일부 내용이 undefined로 나타날 수 있습니다.

🎮 실행 방법

• 프론트엔드

  • Git에서 프로젝트를 클론받습니다.

    git clone https://github.com/WarrenBuffettTest500/Client.git
    cd Client
    npm install

  • root 디렉토리에 .env 파일을 만들고 환경변수를 설정합니다.

    npm i -D dotenv
    REACT_APP_API_KEY=<firebase api key>
    REACT_APP_AUTH_DOMAIN=<firebase auth domain>
    REACT_APP_PROJECT_ID=<firebase project id>
    REACT_APP_STORAGE_BUCKET=<firebase storage bucket>
    REACT_APP_MESSAGING_SENDER_ID=<firebase sender id>
    REACT_APP_APP_ID=<firebase app id>
    REACT_APP_DB_URL=<firebase database url>
    REACT_APP_X_RAPIDAPI_KEY=<rapidapi key> // 주식 정보를 불러올 때 사용합니다.
    REACT_APP_LOCALHOST=http://localhost:8080

  • 애플리케이션을 실행합니다.

    npm start

• 백엔드

  • Git에서 프로젝트를 클론받습니다.

    git clone https://github.com/WarrenBuffettTest500/Server.git
    cd Server
    npm install

  • root 디렉토리에 .env 파일을 만들고 환경변수를 설정합니다.

    npm i -D dotenv
    PORT=8080
    JWT_SECRET_KEY=some_long_random_string_to_use_as_jwt_secret_key
    MYSQL_HOST=<mySQL url>
    MYSQL_USERNAME=<mySQL username>
    MYSQL_PASSWORD=<mySQL password>
    MYSQL_DATABASE=<mySQL database>
    X_RAPIDAPI_KEY=<rapidapi key> // 주식 정보를 불러올 때 사용합니다.

  • 서버를 실행합니다.

    npm i -D nodemon
    npm run dev

---

💡 프로젝트 동기

• 주식 투자를 하다 보면 새로운 투자처를 발굴하고 싶을 때가 있습니다. 그럴 때마다 다른 투자자들은 요즘 어떤 기업에 관심을 기울이는지 궁금해집니다.
• 유튜브와 넷플릭스, 아마존 등 많은 기업들이 추천에 기반을 두고 서비스를 만드는 데 맞춰 추천 알고리즘을 직접 써보고 싶었습니다.
• 애플리케이션 안에서 이용자들의 움직임을 추적해 실시간으로 인기를 끄는 기업을 파악해보고 싶었습니다.
• 데이터를 가공해 시각적으로 나타내보고 싶었습니다.

---

🔎 프로젝트 설명

🛠 기술 스택

• 프론트엔드
  • ECMAScript2015+
  • ReactJS
  • Redux (Redux-Toolkit)
  • D3
  • Sass
• 백엔드
  • Node.js
  • Express
  • MySQL (Google Cloud)
  • Sequelize
  • AWS (CodePipeline, Elastic Beanstalk)

🕹 기능 (각 소제목 옆 괄호는 관련 mySQL 모델 이름)

1. 회원가입 및 로그인 (user)
   • Firebase를 이용해 구글 소셜 로그인을 합니다.
   • 서버에서 이용자 정보를 확인하고 JsonWebToken을 발급합니다. 브라우저 토큰을 받아 local storage에 담습니다.
   • 이후 local storage에 토큰이 있다면 별도 로그인 과정을 거치지 않습니다. 브라우저가 자동으로 토큰을 서버에 보내 이용자 정보를 불러옵니다.
   • 로그인을 하지 않아도 웹사이트를 둘러볼 수 있지만 포트폴리오를 등록하거나 추천받을 수는 없습니다.
   • 이용자가 회원가입을 하면 users 테이블에 추가합니다. Firebase를 통해 받은 uid를 primary key로 관리합니다. 아래에서 설명할 preferenceInfoId를 foreign key로 설정했습니다.
   • 이용자를 삭제하면 아래 preferenceInfo와 portfolioItem들도 cascade로 지워집니다.
2. 투자성향 설정 (preferenceInfo)
   • 회원가입을 하면 투자성향을 등록하는 페이지로 리다이렉트합니다.
   • 관심 섹터와 위험 선호도, 자산 중 주식 비중, 선호 주식 종류, 예상 투자 기간 등을 받습니다. 이 정보는 포트폴리오를 추천하는 데 사용합니다.
   • 투자성향을 등록하지 않아도 웹사이트를 이용할 수 있지만 투자성향에 기반한 포트폴리오 추천은 받을 수 없습니다. 또한 로그인할 때마다 처음에 투자성향을 설정하는 페이지로 리다이렉트해 등록을 유도합니다.
   • preferenceInfo들은 이용자 uid를 foreign key로 참조합니다.
3. 포트폴리오 등록 (portfolioItem)
   • 포트폴리오 관리 페이지에서 보유 주식을 등록할 수 있습니다. 기업 심볼과 평균단가, 보유량을 입력합니다.
   • 입력한 정보는 portfolioItems 테이블에 행으로 추가합니다. Foreign key로 userUid를 참조합니다.
   • 포트폴리오를 등록하면 각 기업별 비중을 원 그래프로 보여줍니다. D3를 이용했습니다. 원 그래프에서 기업 파이를 누르면 해당 기업 상세페이지로 이동합니다.
   • 외부 api를 이용해 실시간 주식 가격을 불러옵니다. 실시간 정보를 이용해 클라이언트에서 총 자산과 전체 수익, 전체 수익률, 각 기업별 손익과 수익률 등을 계산해서 보여줍니다.
   • 자바스크립트가 숫자를 부동 소수점으로 관리해 나타나는 문제는 Decimal이라는 라이브러리를 이용해서 해결했습니다.
4. 메인페이지 포트폴리오 추천
   • 이용자는 투자성향 또는 보유주식을 기준으로 포트폴리오를 추천받도록 고를 수 있습니다.
   • 투자성향 기준 (content-based filtering)
     • 이용자들이 등록한 투자성향을 수치화해 각 이용자의 위치를 구합니다.
     • 로그인한 이용자와 나머지 이용자들 사이의 Euclidean distance를 각각 구합니다.
     • 거리가 가까운 순서로 정렬한 뒤 각 이용자의 포트폴리오 정보를 묶어 클라이언트로 보냅니다.
   • 보유주식 기준 (user-based collaborative filtering)
     • 보유주식을 기준으로 포트폴리오를 추천할 땐 이용자들 사이 거리를 재는 방법이 적절하지 않았습니다. (전 재산이 100만 원이면서 애플 주식을 100만 원 보유한 사람과 전 재산이 1000억 원이면서 애플 주식을 1000억 원 보유한 사람은 euclidean distance이 멀지만 취향은 매우 비슷함)
     • 따라서 보유주식을 기준으로 포트폴리오를 추천할 땐 cosine similarity를 이용했습니다. 거리가 아닌 기울기를 이용한 셈입니다.
     • 이용자들의 벡터값이 보유 주식을 토대로 구합니다.
     • 로그인한 이용자와 나머지 이용자들 사이의 cosine similarity를 계산해 취향이 비슷한 순서로 정렬하고 클라이언트에 보냅니다.
   • 투자성향 기준 추천이 보유주식 기준 추천보다 오래 걸립니다. 전자는 투자성향을 사용해 거리를 재고 정렬을 마친 뒤 포트폴리오 정보를 추가로 불러와야 하는 반면 후자는 처음에 포트폴리오 정보를 불러온 뒤 더 이상 데이터베이스에 접근할 필요가 없기 때문입니다.
   • Intersection Observer API를 이용해 현재 불러온 포트폴리오 가운데 마지막 포트폴리오가 화면에 나타나면 다음 포트폴리오 15개를 불러오도록 설정했습니다.
   • 이용자는 추천받은 포트폴리오를 눌러 포트폴리오 페이지로 이동할 수 있습니다. 다만 본인의 포트폴리오 페이지에 들어갔을 때와 달리 자산 규모와 손익, 수익률 등은 보이지 않고 포트폴리오에 들어 있는 기업들과 현재 가격만 확인할 수 있습니다.
5. 실시간 인기 주식 (hit)
   • 이용자가 특정 기업 상세페이지에 들어가면 hits 테이블에 timestamp와 함께 조회 정보를 생성합니다.
   • 실시간 인기 주식 목록을 조작하는 등 오남용 시도를 막기 위해 같은 이용자가 30분 안에 같은 기업을 조회했을 때는 조회 정보를 만들지 않습니다. 이용자는 cookie를 이용해 판별하고 시간은 updatedAt으로 확인합니다.
   • 클라이언트는 1분에 한 번 서버에 실시간 인기 주식 정보를 요청해 화면에 띄웁니다.
   • 서버는 한 시간에 한 번 30분이 지난 조회 정보들을 지웁니다. Cronjob을 사용했습니다.
6. 상세페이지
   • 상세페이지에 들어가면 해당 기업의 주가 그래프를 확인할 수 있습니다. 일별, 주별, 월별로 제공합니다. D3로 그렸습니다.
   • 해당 기업과 섹터 및 산업이 같고 시가총액이 0.5배에서 1.5배 이내인 기업들을 띄워줍니다.
   • 특정 기업의 상세페이지에 들어가 있는 이용자들끼리 채팅을 할 수 있습니다. Firebase Realtime Database를 이용했습니다.

---

📅 작업 흐름

• 2020.11.30 ~ 2020.12.4 (1주): 브레인스토밍, 기획, 목업 구축
  • 추천, 시각화, 방문자 추적, 데이터 등 핵심어를 들고 아이디어를 구상했습니다.
  • 소재 후보로 주식, 영화, 책 등을 놓고 고민했습니다. 별점을 이용한 영화 추천은 식상하고 책은 범위가 너무 넓다고 생각해 범위를 적절하게 한정할 수 있는 주식을 골랐습니다. 또 주식은 추천 서비스를 만들 소재로 적합하다고 생각했습니다.
  • 처음엔 mobile-first 반응형 웹애플리케이션을 구상했지만 시간 관계상 데스크톱 화면에 구성을 맞췄습니다. 메인페이지만 그리드를 이용해 화면 크기에 대응하도록 설계했습니다. Figma를 이용해 목업을 만들었습니다.
  • 관계형 데이터베이스를 처음 써봐서 하루를 들여 SQL을 공부했습니다. 그래도 스키마 모델링에 시간이 많이 들었습니다. 개발단계에서는 sequelize가 mongoose와 비슷한 면이 많아 다행히 걸림돌이 크지 않았습니다.
  • 프론트엔드와 백엔드 과제들을 최대한 잘게 나눠 테스크카드들을 만들고 개발을 준비했습니다. 과제 및 일정은 노션으로 관리했습니다.
• 2020.12.07 ~ 2020.12.18 (2주): 개발
  • Git, eslint, database, 환경변수 등 설정
  • 주식 정보 api 탐색
  • S&P500 기업 기본 정보 데이터베이스 구축
  • 이용자 및 투자성향, 포트폴리오 목데이터 생성
  • 이용자 인증
  • 주식 정보 등록, 수정, 삭제 api 작성
  • 메인페이지, 포트폴리오페이지, 상세페이지 UI 제작
  • 원 그래프 및 캔들스틱 차트 제작 (D3)
  • 추천 알고리즘 학습 및 작성
  • 실시간 인기 주식 구현 (hits 테이블 추가로 생성)

---

🧶 직면 과제 (및 해결 과정) + 느낀점

📊 워런버핏테스트'500' - S&P500 기업으로 한정

• 주식 정보에 직접 접근할 수 없어 외부 api에 의존해야 하는 상황에서 api마다 제공하는 정보가 각기 파편적이라는 문제에 부딪쳤습니다.
• 특히 어떤 상장사들이 있는지 한 번에 조회할 수 있는 api를 찾기가 힘들었습니다. 특정 기업을 조회한 이용자에게 비슷한 기업들을 추천하려면 상장사 전체 목록이 꼭 필요했습니다.
• 그래서 서비스를 제공하는 기업을 S&P500에 포함된 기업으로 한정하기로 결정하고 데이터베이스를 직접 구축했습니다.
• companyProfiles라는 테이블을 만들어 각 기업의 섹터, 산업, 시가총액 등을 저장했습니다.
• 실제 서비스라면 시가총액처럼 실시간으로 변화하는 정보는 데이터베이스에 담으면 안 되겠지만 api 요청을 내보내는 횟수를 줄이려 고육책을 썼습니다.

💾 MySQL

• 이전까지 mongoDB만 쓰다가 관계형 데이터베이스를 처음으로 다뤄서 애를 먹었습니다.
• NoSQL의 sub-schema에 익숙하고 자바스크립트를 이용하면서 nested array 또는 nested object를 중심으로 사고를 하는 탓에 모델을 짜는 데 시간이 많이 걸렸습니다. 테이블 단위로 생각을 하려니 '관계형' 데이터베이스를 사용하는데 관계가 끊기는 느낌이 들었습니다.
• 특히 user 모델이 이용자의 portfolio나 portfolioItems를 참조하도록 만들고 싶었으나 결국 portfolioItems 각각에 userUid를 foreign key로 달았습니다. 따라서 특정 이용자의 포트폴리오를 찾고자 한다면 portfolioItems를 모두 훑으며 where로 해당 이용자에게 소속한 행들만 뽑아내야 합니다.
• 그래도 ACID 속성 등 SQL의 강점을 엿볼 수 있었습니다. 회원탈퇴 기능을 추가한다면 cascade 기능을 유용하게 쓸 수 있을 것 같았습니다.
• 이전 프로젝트(https://github.com/Goo-Git)에서 관계형 데이터베이스를 썼으면 좋았겠다고 생각하기도 했습니다.
  • 이전 프로젝트 '구깃'은 문서 버전관리가 가능한 협업 웹애플리케이션입니다.
  • 당시 mongoDB를 사용하면서 새 브랜치를 만든 뒤 새 문서를 담기 전에 에러가 발생하면 브랜치를 삭제해야 하는지 등 고민을 많이 했습니다. 이용자들이 같은 문서를 동시에 작업한 뒤 각각 저장했을 땐 문서를 브랜치에 어떻게 덧붙일지도 생각해야 했습니다.
  • 특히 삭제 작업을 할 때 문제가 생길 여지가 많다고 느꼈습니다. 브랜치를 삭제할 브랜치를 먼저 지울지, 문서들을 훑으며 먼저 지울지, 브랜치를 공유한 이용자들 사이의 관계를 먼저 끊어야 할지 고민했습니다. 중간에 에러가 생기면 롤백할 방법을 찾기도 힘들었습니다.
  • 이럴 때 '관계형' 데이터베이스가 힘을 발휘할 수 있겠다 생각했습니다. 트랜젝션 단위로 작업을 관리하고 문제가 생겼을 때 롤백해 데이터를 일관적으로 관리할 수 있기 때문입니다.
• Join 등 SQL 데이터베이스의 특징이 두드러지는 문법 자체는 공부했으나 어떤 상황에서 사용해야 하는지 아직 감을 잡지 못해 프로그램 안에서 실사용하지 못 한 점이 아쉽습니다.
• 추후에 쿼리를 최적화하는 작업도 시도해보고자 합니다.

🎨 D3

• 외부 프레임워크나 라이브러리를 쓸 때 종종 어려움을 겪습니다. 뒤에서 어떤 일이 벌어지는지 확실히 모르는 채 외부 라이브러리를 쓰기보다는 직접 코드를 쓰는 편을 선호합니다.
• D3는 특히나 리액트와 함께 쓰면서 초반에 애를 먹었습니다.
• 예를 들면 포트폴리오페이지에서 포트폴리오에 기업을 추가하거나 주식 정보를 수정하면 스테이트가 바뀌는 데 맞춰 원 그래프도 다시 그려져야 했는데 파이 크기는 변하지만 기존 텍스트와 새로운 텍스트가 겹쳐서 나타나는 문제가 발생했습니다. 실제 DOM에 기존 텍스트가 남아 있었기 때문입니다.
• 이 문제를 해결하기 위해 원 그래프를 그리기 직전에 svg에서 이전 정보를 모두 삭제하는 코드를 추가해야 했습니다.

🗃 Item-based Collaborative Filtering

• 추천 알고리즘은 대표적으로 content-based filtering과 collaborative filtering이 존재한다고 공부했습니다. 그리고 collaborative filtering은 다시 user-based collaborative filtering과 item-based collaborative filtering으로 나뉩니다.
• Content-based와 user-based는 구현을 했지만 item-based는 시간이 모자라고 복잡해서 알고리즘을 짜지 못 한 점이 아쉽습니다.
• Item-based collaborative filtering은 아마존이 도입했습니다. User-based가 이용자들을 각각 비교해 추천을 한다면 item-based는 item 각각, 워런버핏테스트500에 적용한다면 주식 각각을 비교해서 추천을 합니다. 방향이 User → item이 아니라 item → user로 반대인 셈입니다.

🥇 실시간 인기 주식

• 실시간 인기 주식 기능을 마지막에 넣고 보니 이전 인기 주식 목록과 비교해서 순위 등락을 표시해 주면 좋겠다는 생각이 들었습니다. 그러나 생각보다 작업이 클 것 같아서 실행하진 못했습니다.
• 우선 실시간 인기 주식을 이전 순위와 비교하려면 당연히 이전 정보를 들고 있어야 합니다. 현재는 1분 마다 클라이언트에서 요청을 보내 스테이트를 업데이트하고 있습니다.
• 그러나 순위를 비교하려고 하면 순위 정보를 순전히 클라이언트 쪽에서 스테이트로 관리하면 안 되겠다고 생각했습니다. 이용자가 최초로 접속했을 땐 이전 순위 정보가 없기 때문입니다.
• 또한 등락을 보여주지 않을 땐 그때그때 정보만 서버에서 클라이언트로 보내주기 때문에 이용자들 사이에 순위가 다르게 뜨는 것이 문제가 되지 않았는데 순위 등락을 보여주려니 이용자들 사이(특히 방금 접속한 이용자)에 등락이 다르게 나타나는 문제가 생길 것 같았습니다.
• 이런 문제를 해결하려면 데이터베이스에 trendingStocks와 같은 테이블을 새로 만들고 previous와 current 행을 계속해서 업데이트해야 한다고 생각했습니다.
• 사전 기획의 중요성을 깨달은 사례 가운데 하나입니다.

---