공부시간 측정 어플리케이션

Teachable Machine

https://teachablemachine.withgoogle.com/

Teachable Machine

 

Teachable Machine은 구글에서 머신러닝 모델을 쉽고 빠르고 간단하게 만들 수 있도록 제작된 웹 기반 도구 입니다.

 

https://www.youtube.com/watch?v=USQGTW34lO8 

 

위 유투브를 참고하면 머신러닝 모델을 만들 수 가 있다.

필자는 같이 프로젝트를 진행하는 분이 예전에 만들어 놓으신 모델을 사용하였습니다.

 

이걸로 뭘 만들껀데?

우선 생각중인 것은 웹캠으로 내가 책상에 앉아있는 것을 감지하고 그 시간을 측정합니다.

그리고 내가 책상에서 없어지면 시간측정을 중지합니다. 이제 이 데이터를 db에 저장하고 db에 저장된 시간을 기준으로 랭킹을 메기는 어플리케이션입니다.

 

추가적으로 친구추가 기능을 만들어서 친구와 공부시간을 비교할 수 있도록 만들면 더 좋을 것 같습니다.

그리고 열품타처럼 랭킹이 실시간으로 변경되게 polling 방식을 공부해야할 것 같습니다..

 

첫번째로 만난 버그

youtube를 보셨으면 아셨지만, 간단한 index.html 파일을 하나만 사용하여 Netfily를 사용해 배포했습니다.

하지만 저의 프로젝트는 리액트와 노드를 사용하려했기때문에 리액트에서 모델을 실행시키는 것 부터 생소했습니다.

 

 

 

우선 초장부터 tmImage를 사용하는데 Import가 되어있지 않아 오류를 만났습니다. 구글링해서 찾았습니다.

 

 

 

my_model 을 찾을 수 없다고 나왔습니다.

 

 

왜냐하면 서버에 있는 파일에 마음대로 접근하면 보안상 위험이 있기때문에 외부에서 접근할 수 있도록 허용한 public 폴더에 my_model을 넣어주었습니다.

 

 

원래는 Json 파일을 public 폴더에 저장하지않고 위와 같은식으로 import하여 사용하는 것이 정석이지만, 이상하게 오류가 발생했고, 여기에 많은 시간을 허비했기때문에 public에 넣어두기로 했습니다. 

 

두번째 걸림돌

 

 

netlify에 프론트만 구현한 react 파일을 배포하려고 하니 업로드가 되지 않았습니다. 

 

왜 안될까? 고민해보고 찾아볼 결과 react 프로젝트를 배포를 할때는 build과정을 거칩니다. 웹페이지를 열때마다 용량이 크다면 성능이 떨어집니다. 기존의 react 프로젝트는 너무 무겁기 때문에, 빌드를 통해 정리하여 용량을 줄인 버전으로 배포합니다.

 

세번째 걸림돌

배포까지 마쳐서 한시름 놨다 싶었는데, 저는 공부시간을 저장해야했습니다. 이때 당연시 DB가 필요했고 서버또한 다뤄야했습니다. 하지만, netlify로는 백엔드 배포까지 할 수 없었습니다. 그래서 저는 예전에 사용했던 HeroKu를 다시 사용하기로 했습니다. 

 

HeroKu가 뭔가요?

 

https://30sdeveloper.tistory.com/entry/AWS-Heroku-%ED%97%A4%EB%A1%9C%EC%BF%A0-%EC%B0%A8%EC%9D%B4-%EB%B9%84%EA%B5%90-%EC%84%A0%ED%83%9D

AWS와 Heroku(헤로쿠)의 차이를 비교해보고 어떤 상황에서 선택할지 알아보자.

 

우선 위글을 읽고 작성한 것을 말씀드리겠습니다. 

 

헤로쿠는 플랫폼 서비스 입니다. 헤로쿠의 깃허브에 제 코드를 보내기만하면, 헤로쿠가 알아서 배포를 해주게 됩니다.

이와 다른 서비스로는 인프라 서비스가 있습니다. 

AWS 는 인프라서비스이며 AWS는 인프라 즉, 서버만 제공해줄뿐 모든것을 사용자가 알아서 설정하게됩니다.

 

그러면 뭐가 더 좋을까요?

 

컨트롤 

헤로쿠는 이미 만들어진 틀이 있기때문에 코드만 넣으면 되지만, 그 만큼 사용자가 custom 하기 힘듭니다.

반대로 AWS는 본인이 다 설치해야되는 대신, 자기 입맛에 맞게 헤로쿠보다 사용을 할 수 있습니다.

 

시간 

시간적인 측면에서는 간단한 헤로쿠가 따로 공부를 해야하는 AWS 보다 더 낫다고 할 수 있습니다.

 

가격 

가격적인 측면에서는 헤로쿠도 AWS 위에서 작동하는 서비스 이기때문에 그만큼 인센티브가 붙는다고 할 수 있습니다.

그러므로 장기간 사용할 때에는 AWS를 공부해서 사용하는 것이 가격적인 측면에서 이득이 됩니다.

 

 

다시 돌아와서 기존의 localhost에서 프로젝트를 만들때는 , front와 back 모두 실행을 해서 axios를 사용하여 통신했습니다.

Axios 란?

Axios는 브라우저, Node.js를 위한 Promise API를 활용하는 HTTP 비동기 통신 라이브러리입니다.

 

그런데 배포 단계에서는 front에서 이미 build를 한 파일을 back 쪽으로 옮겨야 했습니다. 그 후 back을 실행하여 build 파일을 사용해야했는데요.

 

root > front , back (2개의 폴더로 이루어짐)

 

 

우선 heroku-prebuild는 헤로쿠가 start 하기전에 먼저 이루어져야하는 스크립트 문입니다.

모두 start에 작성하지 왜 따로 작성했나?

그 이유는 heroku start는 60초내에 수행되지 않으면 시간초과가 났습니다. 그러므로 작업을 분할해 60초내에 수행될 수 있도록 한 것입니다.

 

heroku-prebuild

1. cd front root -> front 이동

2. npm ci 

근데 왜 npm ci 일까? 이때까지 npm i 썼잖아.

npm i 는 package.json 을 기준으로 다운로드합니다. 프로젝트에 처음 express 모듈을 설치(npm install express)하면 package.json 파일에 "express": "~4.16.1" 처럼 Tilde Ranges 표기법으로 버전이 명시됩니다. 이후에 package-lock.json 파일이 없는 상황에서 node install 명령어로 로컬에 모듈을 설치할 때 4.16.1 버전보다 높은 버전이 npm에 publish 되어 있다면 높은 버전의 express 모듈이 로컬에 설치됩니다. 이는 개발당시의 버전과 달라져 예기치 않던 버그가 발생할 수 있습니다.

이와 같은 상황을 막기위해서는 npm ci를 사용하면, package-lock을 기준으로 다운로드를 하는데 이는 의존성 패키지의 세부 버전을 모두 적어둔 파일 입니다. npm ci 로 설치하면 -lock 파일을 기반으로 설치하고, 덕분에 모든 환경에서 정확히 동일한 버전의 패키지를 받을 수 있어요. 또한 패키지 설치 할 때 버전 채킹이 없어서 훨씬 빠릅니다. (2배정도)

 

다시 돌아와서

3. npm run build 

4. mv build ../back (front에 있는 build 폴더를 back으로 옮긴다.)

 

그 후 

1. cd back

2. npm ci

3. node index.js

 

 

back의 index.js에서 옮겨진 build 폴더안의 index.html을 res.sendFile 해야한다. 

__dirname은 현재 폴더의 절대경로이다. 지금 폴더는 back이니까 back폴더의 경로겠다.

 

그리고 헤로쿠에서 사용하는 Port 주소가 담겨있는 환경변수를 설정한다.

 

 

이제 아래의 절차를 따라하여 Heroku에 나의 프로젝트를 push 하면 된다.

 

 

그리고 

 

root의 package.json에 engines 추가하는 것 잊지말자. 이것때문에 또 고생했다.