지난글에서 나는 cheerio와 puppeteer를 이용해서 식단표를 크롤링하는데 성공했다

그런데, 마음에 들지 않는 부분이 있었다. 그것은 바로 속도였다. 저 상태는 단순히 값을 저장만하고 콘솔에 찍는 작업만 했는데, 3초가량 시간이 소요됐다. 그래서 직접 chromium을 열어서 크롤링에 도움을 주는 puppeteer를 사용하지 않고 하는 방식으로 변경해보려고 한다.

2. 해결 방안

나는 Postman이라는 개발한 API를 테스트하고, 테스트 결과를 공유하여 API 개발의 생산성을 높여주는 플랫폼을 이용하여 어떤 api 요청을 보내면 식단표가 포함된 데이터를 받아올 수 있는지 체크하고 그것을 코드로 구현하여 속도를 개선해보고자 한다. 사실 이게 더 빠를 것이란 보장은 없지만, 적어도 내 생각에 POST요청 1번, GET요청 1번정도 가 이루어지는데 이렇게 오래 걸리진 않을 것 이란 판단이었다.

1) 남도학숙 페이지로 이동 하여 로그인 할때 어떤 요청이 이루어지는지 파악

로그인 버튼을 눌렀을 때 이루어진 작업들을 크롬 개발자도구의 Network 탭을 통해 확인할 수 있었다.

-> 여기서 1가지 사실을 알았다. 로그인을 할 때 POST 요청을 보내며 request URL은 http://portal.ndhs.or.kr/login 으로 보내면 된다. 그렇게 나는 무작정 Postman으로 post 요청만 보냈는데, 아무리 해도 로그인 페이지의 html만을 받아올 뿐이었다.

2) post요청엔 requestBody영역에 데이터를 전달해야 하잖아?

그렇다. 나는 로그인이라는 것을 할 거 면서 가장 기본적인 아이디 비밀번호 정보를 보내지도 않고 로그인이 되지 않는다고 헤매고 있었다. 다시 개발자 도구에서 Headers 옆에 Payload 창을 보면 보내는 데이터 값들이 나타난다. 로그인 창에서 입력한 아이디는 userId의 value로, 비밀번호는 password로 들어갔다. Postman의 Body 부분에 데이터를 그대로 넣어주고 다시 요청을 보내보니 이번엔 로그인 이후의 페이지가 정상적으로 나타났다.

3) 식단표 탭으로 들어갈때 보내는 요청 파악

이제 로그인 이후 페이지에서 보낼 요청을 보면, GET 요청을 통해 html을 받아온다. 나는 이제 거기서 식단표 영역을 적절히 파싱해서 화면에 보여주기만 하면 내가 계획했던 식단표 보여주는 어플 버전 1 완성이다.

Postman으로 확인했을 때, 역시 식단표가 잘 나왔다.

혹시 리액트 코드를 작성하면서, 삼항 연산자를 엄청나게 사용되는 코드를 작성한 적이 있나. 삼항 연산자는 분명 유용 하지만 남발하게 되면 가독성이 매우 떨어지게 된다. 나의 경우로 말을 하면 사실 삼항 연산자가 2개 이상 중첩되면 바로 의미 이해가 어렵다. 하지만 분명 의미적으로 삼항 연산자가 여러개여야 하는 경우, 즉 분기가 조건의 조건의 조건 등을 타고 가야하는 경우는 무조건 있기 때문에 그러한 상황에서 어떻게 코드를 작성하면 유지보수에 용이한 코드를 작성할 수 있는지 설명하겠다.

예제 코드

우선 위에 코드가 어떤 플로우를 가지고 있는지 생각해보자.

1. signUpState가 default 이면 null을 아니면 A를 반환한다.
2. A는 signUpState가 warning이면 를 아니면 B를 반환한다.
3. B는 signUpState가 info이면 를 아니면 C를 반환한다.
4. C는 signUpState가 success이면 D를 아니면 를 반환한다.
5. D는 user.Internal이 참이면 을 아니면 을 반환한다.

이걸 좀 풀어서 생각하면 결국, signUpStater를 판단해서 그에 맞는 컴포넌트를 반환하고, 특별하게 signUpState가 success인 경우에 내부폼인지 외부폼인지를 판단하겠다는 뜻이다.

자 이걸 바꿔보자.

1. 컴포넌트 안으로 로직을 옮겨라

이 방식은 간단하다. 삼항 연산자로 판단하던 조건을 컴포넌트 안에서 판단하도록 구현하는 것이다.

위의 설명에서 5번 로직인 user.Internal 조건을 가지고 null을 리턴할지, 컴포넌트를 리턴할 지를 컴포넌트 내부에서 결정하도록 구조를 바꾸었다. 놀랍게도 이것이 OOP의 캡슐화 개념이다. 물론 위의 컴포넌트 역시 2개의 컴포넌트로 분리하는 것도 가능하지만 현재 상황에서 그렇게 작업하는 것은 더 지저분하게만 할 뿐이다. 현재 방식이 모듈화에 더 가까운 코드 형태이다.
이제 전체 코드는 이렇게 바뀌었다.

이러한 방식의 장점은 컴포넌트의 구성을 볼때 어떤 조건들이 있고 각 컴포넌트에 영향을 미치는지 파악하기 어렵다는 문제를 해결해준다. 그리고 위에 코드는 아직 signUpState 라는 조건에 대한 로직을 옮기진 않았다. 다시한번 코드 구조를 바꿔볼 수 있겠다. 과정은 생략하고 결과 코드를 아래 첨부하겠다.

처음보다는 낫지만, signUpState 를 컴포넌트 안으로 넣지 않는 한 마지막 남아있는 삼항연산자 한 개는 제거할 수 없다. 또 만약 signUpState를 컴포넌트 안으로 넣게 된다면 의존성이 바인딩 된다. 우리는 과 이 signUpState 상태를 알아야 하는지에 대한 확신이 없는한 의존성을 분리시키는 것이 더 깔끔하다. 그렇다면 어떻게 해야할까

2. 로직은 레이아웃 안에 유지시켜라

무슨 말일까? 기껏 컴포넌트 안으로 조건에 대한 로직을 옮겨서 삼항연산자를 제거해놓고서는 다시 레이아웃에 로직을 나두라니? 당연히 이전 상태로 돌리라는 뜻은 아니다. 위에 방식으로 바꾼 구조의 결과를 보면 코드가 어떤 로직을 원하는지 이해하기 어렵진 않다. 하지만 어떤 동작을 하는지 정확하게 파악하기 위해서는 각각의 컴포넌트를 하나하나 확인해야 한다. signUpState가 어떤 String을 가질때 해당 컴포넌트가 렌더링 되는지 등을 파악하기 위해선 말이다. 그래서 조건을 기준으로 분기하는 로직은 컴포넌트 안으로 넣 돼, 어떤 조건인지는 최종코드에서 볼 수 있도록 바꾸라는 말이다.

이렇게 코드 구조를 바꾸면 엄청나게 코드를 유지보수하기 쉬워진다.

• 새로운 메세지를 넣기를 원하는가? 몇 뎁스의 삼항연산자의 흐름을 알필요가 없다.
• 로직을 바꾸기를 원하는가? 전체 코드 흐름에 상관없이 바꾸고 싶은 컴포넌트의 로직을 바꿔도 사이드 이펙트가 발생하지 않는다
• 논리적으로 코드를 이해하기 어려운가? 단순히 boolean 함수 하나를 반환할 뿐이다. 해당 컴포넌트를 렌더링 할지 말지에 대해서
• 특정 하나의 컴포넌트가 조건이 더 필요할 때와 같은 경우 우리는 너무도 쉽게 개별적 요소를 수정할 수 있다.

이러한 방식을 이용하면 Generic한 컴포넌트를 아래와 같이 구성할 수도 있다.

<Conditional
    when="() => {...}"
>
    <CardContent>...</CardContent>
</Conditional>

이렇게 하면 코드가 복사되는 양을 줄일 수 있다는 장점은 있지만, 레이아웃에 복잡도는 조금 더 올라가긴 한다. 상황에 맞게 잘 사용하자.

또 만약 useEffect 를 props로 넘겨야하는 상황에는 지금까지 방식은 작동하지 않는다. 그런 상황엔 아래 방식을 활용하자.

{condition && <CardContent />}

여담으로 위의 코드 방식이 뭔가 익숙하다고 느끼는 사람이 있을 수 있다. 아마 Vue.js를 공부하고 사용해본 사람이면 비슷하다고 느낄 수 있다. 아래는 Vue.js 방식을 보여주겠다.

Vue.js는 기본적으로 무조건 이렇게 하도록 되어있다.

글 제목이 React + Spring이라 헷갈릴 수도 있을 것 같다. 정확히 우리 프로젝트는 MSA로 설계를 진행하고 있고, 나는 Photorage-web이라는 이름으로 프론트 서버를 현재 띄울 것이다. 그럼 굳이 제목에 Spring을 왜 붙여놨냐하면, 내가 AWS에 배포해보기 위해 관련 글을 찾아볼 때 프론트와 백을 분리한 프로젝트인지 아닌지 알기 어려웠던 기억이 있어서 우리 프로젝트는 프론트와 백이 분리가 되어 있다는 것을 명확히 하기 위해 이렇게 글 제목을 정했다.

그 전에 AWS가 뭔지, EC2가 뭔지 전혀 모르겠다면 [AWS 간단 정리]를 보고와도 좋을 것 같다.

해당 글은 이 글 을 보고 진행한 EC2 생성 과정에서 내가 느꼈던 점에 대해 기록한 글이다.

1. 왜 EC2를 쓰나?

사실 구글에 React AWS 배포 라고 검색을 해보면, EC2를 사용하는 예제보다는 S3 혹은 Amplify를 이용한 서버리스 프로젝트에 소개가 대다수이다. 하지만 나는 현재 이 프로젝트에 백엔드 개발 팀이 분명하게 있고, 또 주제가 사진을 다루는 만큼 단순히 S3를 이용한 웹서버를 띄우는 것에는 무리가 있다고 판단했다. 또 추후 기회가 된다면 SSR로 바꾸는 것도 고려하고 있기 때문에 직접 EC2에 Nginx를 설치하여 웹 서버를 띄워보려고 한다.

2. EC2 인스턴스 생성

1) AWS EC2 서비스 페이지 접속

AWS에 가입을 하고 루트 사용자로 로그인을 하게 되면 다음과 같은 페이지가 보일텐데, AWS 서비스에서 EC2가 보인다면 선택을 하고, 안보인다면 모든 서비스를 펼쳐서 EC2에 접속을 하자.

2) 인스턴스 생성

1. 왼쪽 메뉴의 인스턴스를 누른다(현재 위에 사진은 인스턴스를 눌렀을 때 화면이다.)

   2. 우측 상단에 인스턴스 시작 버튼을 누른다.

   3) AMI 선택(1단계)

   

해당 사진 우측 빨간 네모안에 보면 총 7단계에 거쳐서 인스턴스를 생성할 수 있게 되어있다. 아마 똑같이 인스턴스 생성을 통해 들어갔는데 위에 사진처럼 뷰가 안보이는 분들도 있을 것이다. 현재 AWS가 웹페이지의 뷰를 새로 만들고 있는 것 같더라. 그럴때는 우측 상단에 기존 탭으로 보기 등의 버튼이 뜰텐데 그것을 누르면 현재와 같은 페이지를 볼 수 있다.

나는 AWS의 체험판 느낌인 프리티어로 생성할 것이기에 왼쪽에 프리티어만을 체크해서 고를 수 있는 운영체제를 살펴보았고, Amazon Linux 2 AMI 64비트를 선택하게 되었다(사실 이쪽 분야는 아는게 너무 없어서 AWS에서 제공하는 설명 보고 최적화 되어있다길래 선택했다).

4) 인스턴스 유형 선택(2단계)

2단계 인스턴스 선택에서 역시 기본으로 선택되어 있는 t2.micro(프리티어)로 선택하였다. 이후 3~5단계에서 세부 설정을 할 수 있지만 참고한 포스팅 글들에서 대부분 넘어가도 괜찮다고 해서 추후 사용하다 뭔가 설정을 추가로 하는일이 있으면 그때 수정하든 새로운 포스팅을 하든 하겠다.

5) 보안 그룹 구성(6단계)

좌측 하단의 규칙 추가 버튼을 위해 http와 사용자 지정 TCP를 추가해주었다. http는 Nginx로 React를 배포할 것이기에 추가하였고, 사용자 지정 TCP는 추후 node.js 등으로 SSR을 할 것을 대비하여 8000포트를 이용해 추가해주었다. 소스 항목을 통해 내 instance(EC2 서버)에 접근할 수 있는 방법을 제한 할 수 있다. 그런데 아직 이런것을 제한했다 어떤 불상사가 생길지 몰라서 나는 Anywhere 에서 접근할 수 있다는 의미인 0.0.0.0/0 으로 두었다(사실 그냥 추가하고 안만지면 저런 상태로 있다)

6) 새로운 키 페어 생성

7단계 검토에서 지정해준 것들을 확인하고 나면 키페어를 생성하는 창이 나온다. 현재 내 사진에는 생성시에 만들어둔 키페어가 있어서 저렇게 나오는데 새 키페어를 생성해서 이름을 작성하고 다운로드 받아둔 뒤 인스턴스를 시작하자.

• 이후 다운받은 프리이빗 키(.pem)을 보안된 위치인 .ssh 하위로 이동 + 프라이빗 키 권한을 설정해주자

  $ mv ~/Downloads/[키페어 이름].pem ~/.ssh/[키페어 이름].pem
  $ chmod 400 ~/.ssh/[키페어 이름].pem

  본 프로젝트는 Mac으로 진행했다. 혹시 윈도우에서 하시는분들은 다른 포스팅을 이 부분 이 조금 다를 것 같은데 ec2 window 프라이빗 키 권한설정 등으로 검색해서 진행하자.

3. 인스턴스 연결

위 사진의 숫자 순서대로 클릭하여 연결 페이지로 들어간다. 그런 다음 설치 되어 있는 내장 터미널이든 따로 사용하는 터미널이 있다면 터미널을 켜주자.

그리고 터미널에 '이 부분 복사' 라고 되어있는 곳을 참고하여 입력하면 되는데, 아마 그대로 입력하면 안되고 IP라던가 현재 인스턴스 이름 등은 자기가 세팅한대로 값을 넣어줘야 한다. 그대로 붙여넣기 하고 왜 안되냐고 투덜거리지 말자(나처럼). 형식은 아래와 같다.

  $ ssh -i [프라이빗 키(.pem) 경로] [AMI의 사용자 이름]@[인스턴스의 퍼블릭 DNS]

이런 화면이 자신의 터미널에 떴다면 연결에 성공한 것이다.

4. 사용할 패키지 설치

AWS 공식문서를 참고하여 설치를 진행했다.

1) nvm 설치 후 node 설치

다음과 같은 코드 흐름으로 진행했는데 nvm으로 분명 노드를 설치를 했음에도 마지막 5단계에 현재 노드 버전을 콘솔로 찍어보려고 하니 command node not found 뭐 이런 느낌의 에러로 노드가 없다고 나왔다. 그래서 nvm --list 명령어를 통해 노드 버전을 확인해보니 분명 있었는데 안되더라.

이런 문제가 발생하신 분은 아래처럼 해보길 바란다 (참고 링크 - https://tttap.tistory.com/120)

1) nvm install node 대신 nvm install [버전 명(숫자) or lts/이름]으로 설치

• 프로젝트 생성을 할 때, 별 생각없이 Vite로 생성을 하고 나서 생각하니까 인턴 하고 있는 회사에서 사용중인 node 14.17.5 버전으로 생성했다. 그래서 EC2 인스턴스의 노드도 메이저 버전 14를 맞추기로 했고, 그 중 LTS를 설치했다. ex) $ nvm install lts/fermium
• lts 이름이 확인하고 싶다면 nvm list 명령어를 통해 확인하자.

2) 1번을 하면 노드가 설치 되었을 것이다. 그러먼 nvm use v14(버전명) 또는 nvm use lts/fermium 등과 같은 명령어를 사용하면 nvm이 현재 사용할 노드 버전을 해당 버전으로 바꾼다.

3) 디폴트 노드 버전을 설정한다.

• nvm alias default 버전명 을 실행하면 된다 ex) $ nvm alias default lts/fermium

2) git 설치 및 프로젝트 클론

  $ sudo yum update // 초기에 package 들을 update 해준다.
$ sudo yum install git // 깃 설치
  $ git clone [url] // 프로젝트 코드 클론 ex) git clone https://github.com/[닉네임]/[레포지토리네임]

5. Nginx 설치 및 설정

사실 여기까지도 상당히 낯설고 어려웠다. 조금 만 더 힘내서 해보자.

1) Nginx 설치

  $ sudo yum install nginx //Amazon Linux 1 환경
  $ sudo amazon-linux-extras install nginx1.12 //Amazon Linux 2 환경(내 경우)

나는 Linux2 환경을 선택해서 아래 코드를 이용하여 설치하였다.

2) React 앱 빌드

지난번에 git clone을 이용하여 프로젝트를 가져왔었다. 해당 프로젝트의 루트 디렉토리로 이동한 후 build를 해주자. 내 글을 그대로 따라 왔다면 해당 프로젝트의 루트 디렉토리는 아래와 같을 것이다. $ home/ec2-user/[프로젝트 명] 해당 파일로 이동하는 명령어는 cd 이다 ex) $ cd home/ec2-user/photorage-web

이동을 완료했다면,

  $ yarn install //필요한 package 설치(미설치 된게 있다면)
  $ yarn build //프로젝트 사전 build 명령어

명령어를 통해 build를 하면 되는데, 나는 React를 Vite라는 툴체인으로 프로젝트를 생성하여서 미리 설정되어있는 yarn build 라는 명령어를 통해 손쉽게 빌드 파일을 만들 수 있다(주의할 점, CRA는 빌드된 결과물이 build 라는 이름의 디렉토리에 담기는데, Vite는 dist라는 이름의 디렉토리에 담긴다.)

3) Nginx 설정

여기서부터는 거의 모르는 내용이라 거의 따라했어서 원문의 내용을 그대로 가져오고 내가 겪었던? 첨언할 부분을 추가하겠다.

3-1. nginx.conf 열기 우선 아래 명령어를 통해 해당 파일을 열면 기본적으로 여러 내용이 이미 설정되어 있는 것을 확인할 수 있다. $ sudo vi /etc/nginx/nginx.conf
nginx.conf 내에서 React 프로젝트의 build로 바로 이어지게 설정할 수도 있지만, 설정들을 깔끔하게 관리하기 위해서 일반적으로 선호되는 방식은 /etc/nginx 내에 sites-enabled 디렉토리를 생성하여 여기에 각 서비스의 설정을 넣고 nginx.conf가 이들을 확인하도록 하는 것이다.
하나의 인스턴스 내부인데도 ‘각 서비스’라고 표현한 것은, 가상 호스트(서버) 개념을 사용할 수 있기 때문이다. 이를 통해 하나의 컴퓨터, 즉 하나의 IP 내에서 여러 웹을 배포할 수 있다.(Nginx의 장점이라 할 수 있겠다. 🤗)

그대로 따라하면 /etc/nginx/ 디렉토리의 nginx.conf 라는 파일이 vi 라는 편집 툴을 이용하여 열리게 될 것이다. vi 사용이 익숙치 않아서 당황할 수 있으나 일단 따라하자.

3-2. nginx.conf 수정 지금은 앞서 말한 대로 sites-enabled 디렉토리에 따로 설정을 만들어줄 것이므로, server 블럭 행들은 모두 주석 처리(행 앞에 #) 하도록 한다. 그리고 server 블럭 바로 위에 아래와 같이 include /etc/nginx/sites-enabled/*.conf;를 추가함으로써 sites-enabled 하위의 설정 파일들을 포함하도록 한다.

... 
include /etc/nginx/conf.d/*.conf;
(✨ 코드 추가) include /etc/nginx/sites-enabled/*.conf;
# server {
#    listen       80 default_server;
#    listen       [::]:80 default_server;
#    server_name  _;
#    root         /usr/share/nginx/html;
    # Load configuration files for the default server block.
#    include /etc/nginx/default.d/*.conf;
#    location / {
#    }
#    error_page 404 /404.html;
#        location = /40x.html {
#    }
#    error_page 500 502 503 504 /50x.html;
#        location = /50x.html {
#    }
# }
...

위에서도 말했듯 vi를 이용하는게 익숙치 않을 수 있다(나도 그랬다). 저 부분을 못찾을 수도 있는데 우선 처음 터미널에 바로 수정이 되지않을 것이다. 그럴 때 키보드 i를 누르면 해당 파일을 수정하겠다 라는 뜻이 된다. 그 이후 키보드 방향키를 이용하여 아래로 내리다 보면 위에 나오는 설명이 나오는데 차분히 include 구문을 추가해주고 주석처리 진행해주자. 여기까지 했다면 키보드 esc 누르기 > :wq 입력을 해주자. :wq(저장하고 나가기) 라는 뜻이다.

3-3. sites-available, sites-enabled 설정 일반적인 방식은 sites-available 디렉토리에 필요한 파일들을 작성한 후 이들과 연결되는 symbolic link(symlink)를 sites-enabled에 추가하는 것이다. 때문에 /etc/nginx 내부에 두 디렉토리를 모두 생성해 준다. 그리고 sites-available 내에 원하는 이름으로 설정 파일을 생성해 열도록 한다.

$ sudo mkdir /etc/nginx/sites-enabled
$ sudo vi /etc/nginx/sites-available/#######.conf

지금은 도메인 등록도 되어있지 않고, HTTPS를 위한 준비도 되어있지 않으므로, HTTP에 해당하는 port 80에 대해서 아주 기본 설정만 포함한다.

server {
  listen 80;
  location / {
    root /home/ec2-user/#######/#######/build;(본문 내용 -> 삭제)
      root /home/ec2-user/#######/dist;(필자 코드 -> 적용) 
    index index.html index.htm(본문 내용인데 필요 없어 보여서 삭제함);
    try_files $uri $uri/ /index.html;
  }
}

location 뒤의 /는 directive라고 하는 부분인데, IP 주소나 도메인의 뒷부분인 URI에 대응된다. /만 쓰면 ‘/’로 시작하는 모든 URI에 해당한다는 것으로 현재 설정은 이 인스턴스의 IP 주소로 port 80을 통해 들어오는 모든 URL을 연결시켜주는 것이다. root 행에는 아까 Git을 통해 가져온 프로젝트 내부의 build 디렉토리 경로를 입력한다.

자 우선 위에서 #####.conf => [자신의 프로젝트 명].conf 로 이해하고 입력하자. 또 /etc/nginx/sites-available/#####.conf 파일에 입력할 때 위에 적어둔대로 자기의 상황에 맞게 입력하자.

3-4. sites-enabled > symlink 생성 및 Nginx 설정 테스트

  $ sudo ln -s /etc/nginx/sites-available/#######.conf /etc/nginx/sites-enabled/#######.conf
  $ sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

위와 같은 내용이 출력되면 설정의 문법이 정상적이라는 것이다.

위와 같이 안뜬다면 지금까지 흐름에서 주석을 달 때, } 를 몇개 빠뜨렸다거나 프로젝트 루트 설정이 잘못되었다거나 그럴 가능성이 높다. 꼼꼼하게 작성해보자. 추가로 아래엔 기본적이지만 도움이 될 리눅스 명령어를 조금만 적어두겠다.

  $ cd ~~ //~~경로로 이동
  $ ls  //현재 경로에 존재하는 모든 파일 및 디렉토리 표시
  $ pwd //현재 경로를 출력
  $ mkdir ~~ //현재 경로에 ~~이름을 가진 디렉토리(폴더) 만들기
  $ touch ~~ //현재 경로에 ~~이름을 가진 파일 만들기
  $ rm ~~ //현재 경로에 ~~이름을 가진 파일 삭제(디렉토리를 삭제하고 싶으면 $ rm -rf ~~)

3-5. Nginx 동작 이제 Nginx를 동작시키고, 웹 브라우저에서 AWS EC2 인스턴스 IP 주소를 입력하면 build한 React 앱으로 연결되는 것을 확인할 수 있다. (AWS EC2 인스턴스 IP 주소로 바로 연결할 때 https로 들어가지는데, 현재는 http만 설정했기 때문에, http로 수정하면 들어가질 것이다.)

$ sudo systemctl start nginx

만약, 500 Internal Server Error가 발생한다면, build까지의 경로로 접근할 때 거치는 디렉토리들에 대해 외부에서의 실행 권한이 없어서 발생하는 문제일 가능성이 높으므로, 홈 디렉토리인 /home/ec2-user의 권한을 others의 실행 권한을 포함한 711로 설정한다.
$ chmod 711 /home/ec2-user

위에서 이상이 없었다면 정상적으로 본인의 프로젝트의 빌드 파일이 출력될 것이다. 그게 안된다면 프로젝트 빌드 루트를 적었던 etc/nginx/sites-available/#####.conf파일에 오타나 잘못된 내용은 없어는지 살펴보자.

현재 내 빌드 된 웹사이트 - 해당 주소를 통해 누구나 접속 할 수 있지만, 비용절감을 위해 EC2를 사용하지 않을 때는 중지 상태로 두는데 이걸 다시 켜면 IP주소가 바뀌더라. 나중에 고정 도메인을 구해서 그걸 등록해보겠다.

[참고 링크]

• https://velog.io/@tunakim/AWS-EC2-Nginx-%EC%9D%B4%EC%9A%A9%ED%95%B4-React-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%B0%B0%ED%8F%AC
• https://developerbee.tistory.com/205
• https://blog.leehov.in/37
• https://medium.com/@bdv111/aws-ec2%EC%97%90%EC%84%9C-nginx%EB%A1%9C-react-%EC%95%B1-%EC%A7%81%EC%A0%91-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-c1e09639171e
• https://ppost.tistory.com/entry/ReactNginxAWS-AWS-EC2%EC%97%90-React-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%B0%B0%ED%8F%AC%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
• https://tttap.tistory.com/120
• https://ppost.tistory.com/entry/AWS-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4-%EC%83%9D%EC%84%B1-%ED%9B%84-%EC%A3%BC%EC%9D%98%ED%95%A0%EA%B2%83

1. 프로젝트 생성

나는 yarn을 이용해서 프로젝트 생성을 해줬다. npm 명령어도 설명을 위해서 같이 적어두겠다.

yarn create vite [프로젝트 명] --template react-ts or npm create vite@latest [프로젝트 명] --template react-ts

실제 사용 $ yarn create vite photorage-web --template react-ts 참고) 여기서 프로젝트 명, 템플릿은 빼고 명령어를 실행해도 터미널 상에서 설정할 수 있는 로직이 있으니 그렇게 설정해도 된다.

2. 프로젝트 실행

CRA를 할때와 다르게 진짜 순식간에 프로젝트 생성이 끝났다. 위 사진에서 보이는대로 2.57초가 걸렸으니 말이다. 다음으로 아래 명령어를 통해 기본으로 제공되는 화면을 띄워보았다.

$ cd [프로젝트 명]
$ yarn (필요 패키지 다운)
$ yarn dev or yarn vite(개발 서버 실행)

위 코드를 실행하게 되면 localhost:3000 에 아래와 같은 창이 띄워지면 프로젝트 생성에 성공한 것이다.

• [비교] CRA를 이용한 프로젝트 생성 시간 : 약 70초

3. Storybook 추가

UI 관리 툴로 Storybook을 사용할 것이기 때문에 추가 설치를 해줬다.

$ npx sb init --builder @storybook/builder-vite
$ npm run storybook

위 명령어를 실행하면 프로젝트 루트 디렉토리에 .stories 디렉토리가 생기고 src폴더에 관련 컴포넌트들이 위치하게 된다. 또 localhost:6006에 CRA때와 똑같이 띄워지더라.

추가로, 나는 컴포넌트는 src 폴더에서 구조화해서 가지고 있고 그것을 스토리북에 등록하는 stories 파일들은 따로 관리가 하고 싶었다(기본 설정은 stories와 tsx 파일이 같이 있음)

그래서 .stories 폴더의 main.js의 아랫 부분을 수정하고 stories 파일들을 따로 빼주었다.

4. 현재까지 느낀 CRA와 차이점들

1) git이 자동으로 생성이 안된다(CRA는 실행시 자동으로 git이 생성 됨) 2) build 파일 이름이 build가 아닌 dist로 설정된다. 3) 프로젝트 생성 시간이 빠르고, 빌드도 진짜 빠르다 4) 스토리북 관련해서는 아직 CRA가 더 빠르다고 한다.

1. CRA 대안 결정

CRA 없이 프로젝트 기본 설정을 해봤다. 정말 힘들긴 힘들더라. 아직 모르는게 너무 많기 때문이었다. 또 내가 생각했던 webpack 등을 안쓰고 내 입맛대로 커스텀 하면서 프로젝트 세팅을 하기에는 무리가 있다고 판단이 되었다(능력적으로도 시간적으로도). 그러던 중 Toast UI 의 차세대 빌드 도구 비교 라는 글을 보게 되었다. 자세한 설명은 해당 링크를 가서 보면 좋을 것 같다. 이 글에서는 마지막 부분에 있는 비교 표를 기반으로 왜 내가 Vite를 선택했는지 기록해두려 한다.

• 사유 1. 사용 사례

가장 빠른 빌드 속도를 자랑하는 esbuild를 사실 처음에는 마음에 두고 있었는데, 아직 프로덕션에 사용하기에 준비가 되지 않았다고 한다. 일단 사용 사례가 많지는 않고, css 관련 부분에 오류가 많이 존재한다고 한다. 그래서 일단 esbuild는 사용하지 않기로 했다.

• 사유 2. 설치 및 개발 서버

  기본 설치 용량이 가장 가벼운 wmr은 프론트엔드 프레임워크를 위한 템플릿이 준비되어 있지 않았다. 사용하기 위해서는 Preact 라는 것을 사용해야 하는 것 같아 사용하지 않기로 했다.(Preact가 별로다 보다는 팀 프로젝트고 개발자가 나혼자는 아니기 때문에 팀원들의 공통 기술 스택이 React로 결정되어서 React 위주로 생각하고 있다) 또, 개발 서버 관련 해서 처음에 원했던게, HMR이라고 하는 수정사항이 있을때 바로바로 자동으로 새로고침을 해주는 서비스였는데 이건 Snowpack과 Vite 둘다 적용되더라.

• 사유 3. 프로덕션 빌드 및 SSR(서버사이드 렌더링 지원)

  마지막으로 고려했던 부분은 어찌됐든 우리는 실제 서비스를 배포하는 것까지 목표로 하고 있었기에, 사전에 구성된 프로덕션 빌드가 있으면 좋겠다는 생각을 했다. 내가 이것을 직접 구성하는 것은 여러 포스팅을 읽어보니 무지성 esbuild 등을 이용한 프로덕션 배포는 오히려 별로라는 식의 글이 있었기 때문이다. 사실 다른기능의 표에 있는 것들은 내가 생각을 많이 해본 분야는 아니긴 했는데 서버 사이드 렌더링은 기회가 된다면 붙여보고 싶은 기능이었고, CSS 전처리기는 당연히 쓸 생각이었는데 이걸 따로 고려를 해야한다는 것을 이때 알게 되었다.

2. Vite 사용 결정

이렇게 Vite를 사용 결정을 하고 가장 걱정되었던 것은 관련 자료가 너무 없지는 않을지였다. 그래서 Vite 공식 홈페이지 및 여러 포스팅을 둘러봤는데 생각보다 CRA에서 Vite로 넘어오려고 하는 분들이 꽤 있는 것 같아서 믿고 Vite를 써보기로 결정했다. 다행히 React와 TypeScript 모두 지원하더라(그 외에도 Vanila, Vue 등 많은 프레임워크를 손쉽게 시작할 수 있게 구성되어 있어서 맘에 든다)

나는 CRA를 안쓰고 싶었으며, 빠른 빌드 도구인 esbuild 존재를 알았기 때문에 CRA 없이 React + TypeScript의 개발환경을 세팅하는 방법을 우선 알아보았다.

1. 패키지 매니저는 npm을 사용

yarn과 npm의 차이는 https://joshua1988.github.io/vue-camp/package-manager/npm-vs-yarn.html#yarn 참고하면 좋을 것 같다.

2. package.json 파일을 생성 및 설정

> npm init

{
  "name": "webpack-practice",
  "version": "1.0.0",
  "description": "",
  "main": "index.tsx",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}
// npm init 명령어는 package.json에 정보를 기록하고 프로젝트를 초기화한다

3. TypeScript를 설치(선택)

npm i typescript

4. react-dom을 설치

npm i react react-dom
npm i -D @types/react @types/react-dom

• React와 React-dom은 js로 만들어져있고 타이핑을 제공하지 않는다. 따라서 React와 React-dom의 타입은 알지 못하기 때문에 외부 패키지를 사용한다.
  • TS로 만들어진 라이브러리는 따로 @types/____와 같은 타입을 받을 필요가 없다.

5. webpack을 설치

npm i webpack webpack-cli webpack-dev-server -D

• -D는 개발용(webpack은 개발단계에서만 사용되기 때문에)
• devServer: 실시간 개발 모드로 개발하는 중 변경사항이 프로젝트에 반영
• TypeScript 코드를 원하는 JavaScript 코드로 컴파일하려면 ts-config.json이 필요하다.
• ts-loader를 이용해 Typescript를 Javascript로 변환시켜 줘야한다.

6. 바벨(크로스 브라우징 이슈 해결)을 설치 및 설정

npm i -D babel-loader @babel/core 
npm i -D @babel/preset-env @babel/preset-react @babel/preset-typescript

module.exports = {
  presets: [
    "@babel/preset-react",
    "@babel/preset-env",
    "@babel/preset-typescript",
  ],
};

/*
목적에 맞게 여러가지 플러그인(코드 변환을 처리하는 모듈)을 세트로 모아놓은 것을 “프리셋”이라고 한다.
babel-loader : JSX 및 ES6+ 문법을 트랜스파일링
@babel/core : 바벨의 코어
@babel/preset-react : 리액트의 JSX를 트랜스파일링
@babel/preset-env : ES6+ 코드를 ES5로 트랜스파일링하고 브라우저 폴리필을 자동화
*/

7. tsconfig.json 설정하기

tsc --init

• 타입스크립트 컴파일러 옵션은 해당 문서를 참고하자

[TS DOC | Intro to the TSConfig Reference](https://www.typescriptlang.org/tsconfig)

8. 필요한 플러그인 설치

npm i -D html-webpack-plugin clean-webpack-plugin

• 플러그인이란
  • 로더가 파일 단위로 처리하는 반면 플러그인은 번들된 결과물을 처리한다.
  • 번들된 자바스크립트를 난독화 한다거나 특정 텍스트를 추출하는 용도로 사용한다.
• CleanWebpackPlugIn: 번들링을 할 때마다 이전 번들링 결과를 제거
• HtmlWebpackPlugin: HTML 파일에 번들링 된 자바스크립트 파일을 삽입해주고 이 플러그인으로 빌드하면 HTML 파일로 아웃풋에 생성된다.

9. webpack.config.js 설정

const path = require('path');
const webpack = require('webpack');

module.exports = {
  mode: 'development', // 배포용: production
  devtool: 'eval', // 배포용: hidden-source-map   *그냥 source-map을 쓰면 개발자 도구에 소스코드가 노출이 된다.
  resolve: {
    extensions: ['.jsx', '.js', '.tsx', '.ts'], // 웹팩에서 처리해주는 확장자들
  },

  entry: {
    app: './app.tsx',
  },
  // modules, plugins에 적힌 처리과정을 client.tsx에 적용을 해서 최종적으로 app.js를 뽑아낸다(output).
  module: {
    rules: [
      // babel대신에 tsc 설정.
      {
        test: /\.tsx?$/, // tsx나 ts파일을 발견하면
        loader: 'ts-loader', // 해당 loader를 통해서 버전을 변환하겠다 는 뜻.
      },
    ],
  },
  plugins: [], // 현재는 필요없어진 옵션이라고 한다.
  output: {
    filename: '[name].js', // or '[name].js'
    path: path.join(__dirname, 'dist'), // npm webpack을 실행하면 client.tsx를 통해서 webpack처리 후 dist폴더가 생기고 그 안에 app.js가 들어있다.
  },
};

10. index.tsx(entry)와 App.tsx를 만들어줍시다

//index.tsx
import ReactDOM from "react-dom";
import App from "./App";

ReactDOM.render(<App />, document.getElementById("root"));

//App.tsx
const App: React.FC = () => {
    return (
        <div>hello world</div>
    )
};

export default App;

마지막으로 프로젝트를 시작하기 위해 스크립트를 수정해줍시다

"scripts": {
    "dev": "webpack-dev-server --mode=development --open --hot --progress",
    "build": "webpack --mode=production  --progress",
    "start": "webpack --mode=development  --progress"
},

** 참고 링크 **

• https://velog.io/@ginameee/typescript-번들링

내가 ICT 인턴을 진행하는 기업의 서비스는 90%가 Vanila TypeScript로 이루어져있고, 요새 새로 추가하는 신규 기능 같은 경우는 React를 통해 개발을 진행하고 있다. 나는 입사 당시만해도 React를 전혀 몰랐기 때문에 아무런 감흥도 없었는데, 인턴 동기들은 상당히 당황? 했던 것이 CRA(create-react-app) 이라는 툴체인을 사용하지 않은 부분이었다.

CRA가 뭔데?

CRA가 뭔지 React 공식 홈페이지의 말을 인용해보겠다.

React를 배우고 있거나 아니면 새로운 싱글 페이지 앱을 만들고 싶다면 Create React App.

• 많은 파일과 컴포넌트 스케일링

• 서드 파티 npm 라이브러리 사용

• 일반적인 실수를 조기에 발견

• CSS와 JS를 실시간으로 편집

• 프로덕션 코드 최적화

• 별도의 환경설정 없음

  즉 한마디로, 번들러(웹팩) 설정을 해주고 다양한 라이브러리 등을 사용하기 쉽게 해주는 도구인 것이다. 보통 React를 처음 공부할 때 CRA를 많이 이용하여 SPA 및 Component, props, state 등의 개념을 익히기 시작한다. npx create-react-app [프로젝트 명]

  하지만, 분명 단점도 존재한다. 그것은 이미 세팅된 설정들을 바꾸기 어렵고, eject 등의 명령어를 통해 바꿀 수 있지만 그렇게 되면 CRA의 라이브러리 버전 관리를 통한 의존성 문제 제거 등의 다양한 이점을 누리지 못하게 될 수도 있다.(eject 가 뭔지, 대체 방안은 없는지는 다른 글에서 기회가 되면 포스팅 해보겠다)

  요약

  • CRA란?

    • 리액트 프로젝트를 시작하는데 필요한 개발 환경을 세팅해주는 툴

• CRA의 장점

  • webpack, babel과 같은 모듈 번들러, 트랜스파일러를 자동으로 설정해줘서 초보자가 접근하기 쉽습니다.

  • ES6+문법, CSS 후처리와 같은 개발환경을 자동으로 설정해줍니다.

• CRA의 단점

  • 웹팩, 바벨 설정을 변경하기 어렵습니다.(eject 사용해서 수정해줘야함)
  • 작은 프로젝트를 진행할 때 너무 파일이 무겁습니다.

  ---

CRA가 쓰기 싫었던 이유

나는 분명 웹개발 초보이다. 웹팩 등의 바벨 설정 문제가 생기면 해결도 잘 못할 뿐더러 어디서 문제가 발생했는지 파악하기도 어려울 수도 있다. 그런 입장에서 CRA는 최고의 선택일 수 있다. 그럼에도 내가 CRA에 의구심을 갖고 다른 것을 쓰려고 한 이유를 정리해두려 한다.

1. 빌드가 느리다.

빌드가 뭔지 또 그게 어떤 문제로 이어질 지 바로 떠오르지 않았다면, 컴파일, 빌드, 배포 개념 및 CI/CD 개념 정리 를 읽어보는 것을 추천한다.

ICT인턴십을 진행하는 회사의 웹사이트를 빌드하는데 10분정도의 시간이 걸린다. 사실 엄청 긴 시간은 아닐 수 있다. 나도 그렇게 생각했다. 하지만 회사 사수분은 이것이 너무 느리다며 개선을 원했고 그 때 나는 어느 토스 프론트 개발자분의 이글을 보고 CRA가 최선은 아님을 알게 되었다. 그래서 실제 이 토이 프로젝트를 배포하게 된다면, 나는 AWS의 클라우드 서비스를 이용해야 하고 이것은 빌드 시간을 기준으로 요금을 책정한다. 그 말은 즉슨, 빌드 시간이 짧으면 짧을수록 비용을 절감 할 수 있다.

2. 번들링 도구(웹팩 등)을 공부해보고 싶어졌다.

위에서도 잠깐 언급했지만 나는 웹팩이 뭔지 전혀 몰랐는데, 회사에서 일을 해보며 자연스럽게 package.json 을 보며 관심을 갖게 되고 더 나아가 webpack.config 등의 파일을 보는데 두려움이 적어졌다. 번들러, package.json의 이해, npm vs yarn 등의 글 포스팅이 그 관심의 증거이다. 그래서, 이러한 초기 설정 및 프로젝트 관리를 직접 해보고자 하는 마음이 생겨 CRA가 아닌 다른 것들을 찾아보게 되었다.

• 사진 기반의 SNS가 넘쳐나는데, 다른 SNS 서비스들과 다르게 "앨범" 이라는 개념을 조금 더 강하게 도입하고자 함.
• 기존 SNS의 복잡한 기능들 대신 일상/여행의 앨범이라는 개념만으로 구현.
• 친구들끼리의 추억, 가족들끼리의 추억을 담은 앨범으로 시작. 그 순간을 앨범이라는 틀에 넣어서, 이름을 짓고 싶을 수 있음
• 인스타는 그런 느낌의 기능이 부족하고, 네이버 MYBOX는 너무 클라우드 드라이브 느낌에 약간의 사진 앨범 자동 생성 등을 엮은 느낌
• 적당한 SNS + 확장성 + 앨범(사진)의 기능 강화

팀 소개

• UI/UX Designer 겸 Front-end 개발자 1명
• Front-end 개발자 1명(본인)
• Back-end 개발자 2명

총 4명으로 이루어진 팀으로 각자의 목표를 갖고 그것을 성취할 수 있는 프로젝트를 진행하기로 했다. 이번엔 정말 출시 후 서비스 까지를 바라보고 진행 할 예정이다. 혼자 하는 것이 아니니까 좀 더 할 수 있지 않을까 싶다.

내 목표는 아래와 같다.

• 내가 사용하는 언어, 툴에 대해 이해하고 쓰고 왜 그것을 쓰는지 나름의 이유를 갖을 수 있기

• 웹 사이트를 온전히 처음(프로젝트 생성)부터 끝(배포 후 서비스) 까지 개발해보기
• Front-end 개발자로서 내 포트폴리오의 메인 프로젝트를 경험해보기

그래서 해당 목표를 이루기 위해, 어쩌면 개발 시간보다 개념을 찾아보고 그것을 블로그에 포스팅하며 정리하는 시간이 초반엔 훨씬 많을지도 모르겠다. 그렇더라도 이번 Photorage 프로젝트 만큼은 선택에 있어서 많은 고민을 하고 단순히 이걸 많이 쓰니까 이걸 해야지가 아닌 우리 프로젝트에는 이게 더 좋겠네 싶은 것들을 골라서 쓰고 기록해보려고 한다.

기술 스택

• Front-end
  • React(Vite 툴체인, TypeScript 적용)
  • Storybook 도입
  • Styled-Component(CSS in JS) 도입
  • 상태 관리 툴(Recoil or MobX 등 미정)
  • 웹서버 : AWS의 EC2, S3, CloudFront 사용 예정
• Back-end
  • Spring Boot + Node.js
  • MongoDB(NOSQL)
  • API 서버 : AWS 의 EC2 사용 예정(MSA 구조로 여러 서버로 분리)
• 통신
  • Ajax 기반 통신
• 디자인
  • Figma : Storybook 연동
• 협업 및 코드 관리 툴
  • Notion, Slack, GitHub

** 여담 및 각오 ** 그동안 블로그의 몇개 개인 프로젝트를 하는 듯 포스팅을 하다 거의 올리지 못하고 있다. 이유는 단순히 시간을 들이지 못했기 때문이다. 그 이유는 ICT 인턴을 진행하며 퇴근 이후, 개인 프로젝트를 진행할 여유가 없었기 때문이다. 실제 서비스에 모든 영역에 참여하는 것은 당연히 아니지만 그래도 모르는 것이 너무나 많았기에 프로젝트 외적인 공부를 진행하다보니 프로젝트에 시간을 쏟지 못했다. 이제 3달차가 되어가는 입장에서 그동안 공부했던 내용들을 함축해서 적용해 볼 수 있도록 팀 토이프로젝트를 시작해보려 한다(하면서 내가 그동안 놀고만 있지는 않았다는 것을 블로그 포스팅의 깊이와 양에서 보여주고 싶다)

** 참고 링크 **

• https://storybook.js.org/tutorials/intro-to-storybook/react/ko/get-started/

• https://vitejs-kr.github.io/guide/why.html

크롤링(crawling)이란 데이터를 수집하고 분류하는 것을 의미한다. 주로 인터넷상의 웹페이지를 수집해서 분류하고 저장하는 것을 뜻하며 데이터가 어디에 저장되어 있는지 위치에 대한 분류 작업이 크롤링의 주요 목적이다. 크롤링의 주요 대상은 다양한 형태로 존재하는 데이터로, 데이터 생성 스타일에 따라, 정형, 반정형 그리고 비정형 데이터로 구분되기도 하지만, 데이터를 생산하는 주체에 따라 기업과 사용자가 생성하는 데이터로 분류할 수 있다

정적 크롤링

정적 크롤링은 정적인 데이터를 수집하는 방법을 말한다. 정적인 데이터란 변하지 않는 데이터를 의미한다. 한 폐이지 안에서 원하는 정보가 모드 드러날 때 정적 데이터라고 할 수 있다. 즉 정적 크롤링은 주소를 통해 단발적으로 접근하여 한 페이지 내에서 모든 작업이 이루어지기 때문에 속도가 매우 빠르다는 장점이 있지만, 수집 데이터의 한계가 존재한다는 단점이 있다.

동적 크롤링

동적 크롤링은 동적인 데이터를 수집하는 방법을 말한다. 동적인 데이터란 입력, 클릭, 로그인 등과 같이 페이지 이동이 있어야 보이는 데이터를 의미한다. 예를 들어서, 메일함에 있는 메일 제목 데이터를 수집할 때 로그인 과정을 거친 후 메일함에 들어가야 하는 동적인 과정이 필요하다. 이런 경우가 동적인 크롤링이다. 동적인 크롤링은 브라우저를 사용하여 연속적으로 접근하여 수집 데이터의 한계가 없지만, 속도가 느리다는 단점이 있다.[5]

🙏 크롤링 툴

cheerio

cheerio 는 nodejs 의 라이브러리로 http 통신을 통해 데이터를 가져오는 기능을 포함하고 있지 않은 라이브러리이다. 그럼 왜쓰냐?

HTML문서를 문자열로 cheerio에 집어 넣어주면 jQuery 및 쿼리 셀렉터의 선택자 형식으로 데이터를 추출할 수 있기 때문이다. Cheerio와 같은 HTML 문서 파싱 라이브러리를 사용하지 않는다면 정규식으로 매번 필요한 값을 문서에서 찾아야 하기 때문에 생산성 향상에 여러모로 불리 할 수 있다.

만약 HTTP 통신으로 데이터를 가져오고 싶다면 자바스크립트의 기본 라이브러리인 XMR(XMLHttpRequest)을 이용하거나 node js 라이브러리인 request 또는 request-promise 라이브러리를 이용하여 HTTP 통신의 Response 결과를 받아 온 다음 response 결과 중에서 HTML 문서를 cheerio에 로딩시켜 줘야 한다.

puppeteer

Puppeteer는 Chrome 팀이 개발한 Node 라이브러리 입니다.

Headless 혹은 온전한 크롬도 컨트롤 할 수 있는 고차원 API를 제공합니다. 쉽게 말해 Broswer에서 여러분이 수동으로 하는 대부분의 일들을 Puppeteer를 통해 할 수 있습니다.

예시

• 페이지의 스크린샷 혹은 PDF 파일 생성

• 싱글 페이지 어플리케이션 크롤링 및 미리 렌더링 된 컨텐츠 생성

• 폼 제출, UI 테스트, 키보드 입력등 자동화

• 테스트를 작성 하고, 최신의 크롬에서 최신 자바스크립트와 브라우저 기능들을 돌려 볼 수 있습니다.

  👏 계획 및 구현

  계획

  puppeteer 라이브러리를 이용하여 내가 직접 남도학숙 홈페이지에서 식단표를 확인하는 로직을 구현한다. 그 과정에서 필요한 정보를 cheerio를 이용하여 쉽게 가져온다.

  구현

  1. cheerio, puppeteer 설치

  npm install cheerio puppeteer

  위의 명령어를 프로젝트의 루트 디렉토리(MEAL_PLANNER_ALARM_NDHS)에서 실행한다.

[프로젝트 구조] 📂 MEAL_PLANNER_ALARM_NDHS | -- 📂 client(React를 사용한 프론트 디렉토리) | -- 📄 index.js(Express 서버 - 추후 설명 예정) | -- 📄 crawl.js(크롤링 관련 코드)

2. crawl.js 코드

  const puppeteer = require('puppeteer');
const cheerio = require('cheerio');

let MealList = {
    "date": "",
    "breakfast": "",
    "lunch": "",
    "dinner": "", 
 };

async function crawl(){
    // 가상 브라우져를 실행, headless: false를 주면 벌어지는 일을 새로운 창을 열어 보여준다(default: true)
    const browser = await puppeteer.launch({headless: true});
    const page = await browser.newPage();
    const ndhs_id = ''; // 추후 로그인 폼에서 각자의 아이디 비밀번호를 입력받게 할 예정
    const ndhs_pw = '';

    // headless: false일때 브라우져 크기 지정해주는 코드
    // await page.setViewport({
    //     width: 1366,
    //     height: 768
    // });

    //페이지로 가라
    await page.goto('http://portal.ndhs.or.kr/index');

    //해당 페이지에 특정 html 태그를 클릭해라
    await page.click('body > div > div > div > div > div > div.row > div > div.login-body > div > div.col-xs-12.col-sm-5.login-con.pt20 > div > form > ul > li:nth-child(2)');

    //아이디랑 비밀번호 란에 값을 넣어라
    await page.evaluate((id, pw) => {
    document.querySelector('#stuUserId').value = id;
    document.querySelector('#stuPassword').value = pw;
    }, ndhs_id, ndhs_pw);

    //로그인 버튼을 클릭해라
    await page.click('#student > div > div:nth-child(2) > button');

    //로그인 화면이 전환될 때까지 기다려라, headless: false 일때는 필요 반대로 headless: true일때는 없어야 되는 코드
    //await page.waitForNavigation()

    //로그인 성공 시(화면 전환 성공 시)
    if(page.url() === 'http://portal.ndhs.or.kr/dashboard/dashboard'){
        //학사 페이지로 가서
        await page.goto('http://portal.ndhs.or.kr/studentLifeSupport/carte/list');

        // 현재 페이지의 html정보를 로드
        const content = await page.content();
        const $ = cheerio.load(content);
        const lists = $("body > div.container-fluid > div:nth-child(6) > div > table > tbody > tr");
        lists.each((index, list) => {
            MealList[index] = {
                date: $(list).find("th").text().replace('\n\t\t\t\t\t\t\t\t',""),
                breakfast:$(list).find("td:nth-of-type(1)").text(),
                lunch:$(list).find("td:nth-of-type(2)").text(),
                dinner:$(list).find("td:nth-of-type(3)").text()
            }
            console.log(MealList[index]); 

        })
    }
    //로그인 실패시
    else{
        console.log('실패');
        ndhs_id = 'nope';
        ndhs_pw = 'nope';
    }

    //브라우저 꺼라
    await browser.close();     
};


crawl();

** 3. 크롤링 결과 ** 프로젝트 루트 디렉토리에서 node crawl.js 실행 결과

참고 링크

• https://no-free-lunch.tistory.com/10
• http://wiki.hash.kr/index.php/%ED%81%AC%EB%A1%A4%EB%A7%81
• https://velog.io/@recordboy/Express-Puppeteer-React-Express%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%B4-%ED%81%AC%EB%A1%A4%EB%9F%AC-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EB%B0%8F-Heroku%EC%97%90-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0

vscode를 사용하다보면 한번씩 좌측에 있는 탐색기에 하위 폴더가 / 로 보이는 경험을 겪은 적 있을겁니다.

하위 폴더면 하위 폴더 답게 계층구조를 지켜서 화면에 보였으면 한 것이 한 두번이 아닙니다. 해당 문제를 해결하는 것은 매우 간단합니다.

2. 해결 방법

1) vscode 설정창 들어가기

macOS : ⌘ + ,
Windows : Ctrl + ,
Linux : Ctrl + ,
위의 키를 동시에 누르면 설정화면이 나타나고 원하는 항목을 검색하여 설정할 수 있다.  

다음과 같은 화면이 뜨면 설정창을 연 것입니다.

2) explorer.compactFolders 검색 후 Explorer: Compact Folders 체크 해제

3. 결과

원하던 대로 하위 폴더임이 여실히 드러나는 계층 구조를 그대로 보여주게 됩니다.

1. CRA
   • JS : npx create-react-app test
   • TS: npx create-react-app testts —template typescript

[프로젝트 구조]![](https://velog.velcdn.com/images/choi-ju12g/post/88b45cd7-2c4f-460a-b2f1-a4974f5ead1b/image.png)

[package.json] - 빨간색 줄들이 TS 프로젝트에 추가되어 있음.
![](https://velog.velcdn.com/images/choi-ju12g/post/0bf49c13-81b5-4f89-9cd6-425098b9eb9d/image.png)

[tsconfig.json]

```javascript
{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx"
  },
  "include": [
    "src"
  ]
}
```

2. Storybook 추가

• JS : npx -p @storybook/cli sb init
• TS : npx -p @storybook/cli sb init --type react_scripts

[프로젝트 구조]

[스토리북 실제 화면] 왼쪽 : JS, 오른쪽 : TS

2.JS프로젝트 변환

1. 타입스크립트 추가 → package.json dependencies 추가

# package.json
npm install --save typescript @types/node @types/react @types/react-dom @types/jest

# or

yarn add typescript @types/node @types/react @types/react-dom @types/jest

2. tsconfig.json 추가

//tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "src/",
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react",   //
    "esModuleInterop": true
  },
  "include": [
    "src"
  ],
  "exclude": [
    "**/*.test.ts",
    "**/*.test.tsx"
  ]
}

관련 에러 해결

• [디버깅] Cannot use JSX unless the '--jsx' flag is provided.ts(17004) 해결**** 참고 링크 : https://steadily-worked.tistory.com/632 해결 법 : tsconfig.json 의 “jsx” : “react-jsx” 를 “react” 로 변경
  • (React) Argument type 'HTMLElement or null' not assignable to parameter type 'Element or DocumentFragment' 에러 해결법 1 : tsconfig.json 의 “strict” : “true” 를 “false” 로 변경 (스트릭트 모드 사용 X 방법) 해결법 2 : index.tsx 에서
  • const* root = ReactDOM.createRoot(document.getElementById('root')) 를 const root = ReactDOM.createRoot( document.getElementById('root') as HTMLElement ); 로 타입을 지정

3. 스토리북 컴포넌트 jsx → tsx 변환 (스토리북 빌드시 제공된 예시 Button 가지고 비교)

   1) Button.jsx 의 확장자를 tsx로 바꾸고, propTypes로 정의된 Prop를 Interface로 타입을 지정해준다.

// JSX 방식
import PropTypes from 'prop-types';

Button.propTypes = {
  primary: PropTypes.bool,
  backgroundColor: PropTypes.string,
  size: PropTypes.oneOf(['small', 'medium', 'large']),
  label: PropTypes.string.isRequired,
  onClick: PropTypes.func,
};

// TSX 방식
interface ButtonProps {
  primary?: boolean;
  backgroundColor?: string;
  size?: 'small' | 'medium' | 'large';
  label: string;
  onClick?: () => void;
}

4. jsx에서 any타입에 지정해두지 않은 속성을 받았다면, prop 설정에서 props를 옵셔널(?)를 붙여주도록 하자.( 위 타입스크립트 프롭스의 primary, size, onClick)

5. jsx의 defaultProps 값은 실제 컴포넌트의 프롭스에서 값을 지정해준다

// JSX
Button.defaultProps = {
  backgroundColor: null,
  primary: false,
  size: 'medium',
  label: '',
  onClick: undefined,
};

export const Button = (
{ primary, 
backgroundColor, 
size, 
label, 
...props }) => {
  const mode = primary ? 'storybook-button--primary' : 'storybook-button--secondary';
  return (
    <button
      type="button"
      className={['storybook-button', `storybook-button--${size}`, mode].join(' ')}
      style={backgroundColor && { backgroundColor }}
      {...props}
    >
      {label}
    </button>
  );
};

// TSX
export const Button = ({
  primary = false,
  size = 'medium',
  backgroundColor,
  label,
  ...props
}: ButtonProps) => {
  const mode = primary ? 'storybook-button--primary' : 'storybook-button--secondary';
  return (
    <button
      type="button"
      className={['storybook-button', `storybook-button--${size}`, mode].join(' ')}
      style={{ backgroundColor }}
      {...props}
    >
      {label}
    </button>
  );
};

내 지난 포스팅 React-Storybook 0. 프로젝트 생성 및 스토리북 등록 에서 나는 앞으로 내가 만들게 될 리액트 컴포넌트 들을 최대한 재사용성을 높여서 등록하고, 그것들을 모아두겠다고 말했었다. 그렇게 CRA를 이용하여 프로젝트를 만들어 봤었다.

그런데 여기서 미쳐 생각하지 못했던 문제가 생겼다. 바로 CRA를 할때 TS, 즉 타입스크립트를 이용하도록 생성하지 않았던 것이다.

그렇게 우선, 예시로 주어진 컴포넌트의 확장자를 .jsx 에서 .tsx 로 바꾸어 보았지만 역시 어림도 없었나보다.빨간줄의 에러를 상당히 많이 볼 수 있었다.

물론 그 당시에는 프로젝트를 생성한지 얼마 안되었기 때문에, 사실 프로젝트를 지우고 다시 TS 프로젝트로 만들면 됐다. 하지만 만약 이미 JS로 프로젝트를 만들었는데 그 이후 타입스크립트를 도입하고 싶을 떄, 할 수 있어야 하기에 방법을 찾아 한번 직접 바꿔보려고 한다.

2. 영문 포스팅 글 번역

원본 링크 : https://medium.com/opensanca/migrating-from-js-to-ts-cra-b5f679086c5a

참고 링크 : https://create-react-app.dev/docs/adding-typescript/

Javascript를 Typescript로 바꾸기(CRA)

자바스크립트로 짜여진 CRA 프로젝트를 타입스크립트로 바꾸는 방법에 대해서 설명하겠다.

**CRA 공식 문서** 를 참고 해도 되지만, 이 글을 읽으면 더 깊은 학습을 할 수 있을 것을 약속한다.

당신의 타입스크립트로의 모든 코드베이스를 바꾸는 훌륭한 전략을 소개할 것인데,

그것을 위해 3가지 스텝으로 분류했다.

1. 어떻게 스스로 타입스크립트를 구성하고, linter/prettier 등을 고치고 jest를 통합시킬 것인가?
2. 간단한 리팩토링을 통해 최대한 머리아프지 않게 현재 당신의 코드를 타입스크립트로 바꾸는 전략
3. 내가 지금까지 공부했고, 나를 도왔고, 내가 범했던 다양한 실수들 그리고 거기서 나의 문제를 해결해줬던 config들 소개

Configs(구성)

첫째, 어플리케이션 작동에 문제가 없게 하는데 초점을 맞출 것이다.

둘째, 코딩 생활을 더 쉽게 만들어주는 linter랑 prettier를 고칠 것이다.

셋째, JS와 TS에서 모두 작동하는 테스트 코드를 구성할 것이다.

App

이 설정은 가장 쉽다. CRA 구성은 JS,TS를 동시에 모두 지원하기에 너는 단지 타입스크립트 컴파일러를 구성하면 된다. 여기서 생각해봐야할 점은, 이전에 구성한 적 없는 tsconfig.json 파일을 어디서 가져오는 지에 대한 것이다.

그래서 타입스크립트 템플릿으로 CRA를 사용하여 새로운 프로젝트를 만든 후 생성되는 tsconfig.json을 이용하고 몇 가지 설정을 추가할 것이다. (ex baseUrl (NODE_PATH 바꾸기 위함)).

타입스크립트 CRA 프로젝트를 너의 어플에 적용하기 위해서는 TS Dependencies를 설치하고 너의 app's root 에 tsconfig.json 을 추가해라.

yarn add typescript @types/react @types/react-dom @types/node

//tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "src/",
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react",
    "esModuleInterop": true
  },
  "include": [
    "src"
  ],
  "exclude": [
    "**/*.test.ts",
    "**/*.test.tsx"
  ]
}

Linter/Prettier

linter와 prettier 에 대해 말하자면 입아프자. 나는 타입스크립트에서 작동하도록 내 eslint 설정을 업데이트 했다. 만약 아직 linter나 prettier를 사용하지 않는다면, 아무리 작은 사이드 프로젝트라 할 지 라도 당장 너가 하던 것을 멈추고 추가할 것을 권한다.

아래의 dependencies를 eslint나 prettier 에 추가하고, .eslintrc.js (.ts 파일 확장자를 인식하기 위한 파일) 을 업데이트하고 타입스크립트 플러그인을 사용해라.

yarn @typescript-eslint/eslint-plugin @typescript-eslint/parser

// .eslintrc.js
module.exports = {
  plugins: ['prettier', 'react', '@typescript-eslint'],
  extends: [
    './node_modules/kcd-scripts/eslint.js',
    'plugin:@typescript-eslint/eslint-recommended',
    'plugin:@typescript-eslint/recommended',
    'prettier/@typescript-eslint',
  ],
  rules: {
    'prettier/prettier': 'error',
    'react/jsx-filename-extension': [
      1,
      { extensions: ['.js', '.jsx', '.tsx'] },
    ],
  },
  settings: {
    'import/resolver': {
      node: {
        extensions: ['.js', '.jsx', '.ts', '.tsx'],
        paths: ['src'],
      },
    },
  },
}

//prettier.config.js
const prettierConfig = require('kcd-scripts/prettier');

module.exports = Object.assign(prettierConfig, {
  bracketSpacing: true,
  endOfLine: 'lf',
});

Tests

너의 모든 테스트와 컴포넌트들은 JS로 작성되어 있다. jest는 컴포넌트가 JS로 작성되었든 TS로 작성되었든 신경쓰지 않고 적용된다. 아무것도 할 필요가 없다.

그런데 TS 컴포넌트를 추가하고 나면, TS 테스트 코드를 작성하고 싶을 수 있다. 이 경우에는 TS로 작성된 테스트를 변환하도록 jest.config.js 를 손봐야 합니다. jest에 dependencies를 추가하고 업데이트 해라.

yarn add ts-jest @types/jest

//jest.config.js
const { jest: jestConfig } = require('kcd-scripts/config')

module.exports = Object.assign(jestConfig, {
  globalSetup: '<rootDir>/src/setupJest',
  modulePaths: ['<rootDir>/src/'],

  transform: {
    ...jestConfig.transform,
    '\\.tsx?$': 'ts-jest',
    '^.+\\.jsx?$': 'babel-jest',
  },

  globals: {
    'ts-jest': {
      tsConfig: 'tsconfig.json',
    },
  },
})

변환 전략

TS와 JS 둘다 작동가능하게 하는 하이브리드 앱을 구성하는 것은 쉽다. 전체 어플리케이션을 바꾸는 것은 엄천난 도전이 될 것이다. 나는 내 어플리케이션을 변환하는데 도움을 준 4가지 전략을 소개한다.

첫째, 작은 것(leaves) 부터 변환을 시작해라.

너의 어플리케이션은 마치 나무처럼 동작 할 것이다 .나무 처럼 동작한다면 가능한 다른 내부적인 의존성이 없는 마지막 컴포넌트 부터 재작성 하기 시작해라. 그렇게 하면 충돌이 적어질 것이고 모든 leaf가 변환이 되었다면 그 모든 부모 컴포넌트 들을 변환해서 루트까지 변환해 가라.

둘째, 너의 테스트 코드 부터 재작성해라. 너의 코드 베이스의 각각의 테스트 코드 확장자를 .js 에서 .ts로 바꾸고 생기는 문제들을 먼저 고쳐라. 그렇게 고쳐진 테스트 코드들은 타입스크립트로 재작성 될 너의 코드들의 수많은 비준수 사항, 오류 등을 잡아 낼 수 있을 것이다.

셋째, 새로운 기능부터 시작해라.

오직 새로운 기능만을 TS로 작성하면 새로운 기능을 테스트하기 위한 새로운 코드와 새로운 루틴을 작성하면 사용이 더 쉬워진다. 새로운 기능은 당신이 예측하기 쉽고, 컨트롤 가능한 영역의 영향을 노출한다.

넷째, 필요할 때 마다 변환해라.

사실 이 것은 가장 어려울 수 있지만 가장 현실적이다. 손 볼 필요가 있는 특정한 파일이 있다면 그 파일만 우선적으로 변환해라. 만약 너가 그 파일에 대한 테스트 코드가 있다면( 사실 이것이 반드시 있기를 바란다.), 그 테스트 코드를 먼저 수정하고 그 후에 너의 컴포넌트를 변환하기를 추천한다. 그렇게 새로운 제품 요청사항이나 디자인 변화 등의 변경사항에 너의 컴포넌트를 수정 해나가라.

스토리북 소개

이 가이드는 전문 개발자들이 디자인 시스템을 배울 수 있는 방법을 다루고 있습니다. 자바스크립트(JavaScript), 깃(Git), 그리고 지속적인 통합 환경(Continuous Integration, CI)에 대해 어느 정도 경험을 하고 읽기를 권해드립니다. 또한 스토리 작성이나 설정 파일 수정 등의 스토리북의 기본 사용법을 알고 있어야 합니다(스토리북 소개를 참고하세요). 링크 : https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/introduction/

쉽게 이해하자면 우리는 리액트로 특히 함수형 컴포넌트로 뷰를 구성할 때, 재사용성을 고려하면서 만들게 된다. 함수형 컴포넌트 자체가 새로운 뷰를 만들 때, 이미 있는 컴포넌트들의 재조립을 해서 뷰를 구성하고 없는 부분을 추가로 구성하는 방식을 지향하고 있기 때문이다. 이런 상황에서 쉽게 컴포넌트를 관리할 툴이 필요했던 것이다. 그렇게 스토리북은 큰 노력을 들이지 않고 우리의 React Components를 등록하고 확인할 수 있도록 도아줄 것이다.

아래 사진은 스토리북 공식 홈페이지에서 말하는 사용하는 도구들이다.

프로젝트 생성 및 스토리북 등록

참고 링크 : https://storybook.js.org/tutorials/intro-to-storybook/react/ko/get-started/

1. React 프로젝트 생성(CRA) 우선 앞으로 만들 컴포넌트 들을 모아둘 프로젝트를 CRA를 이용하여 생성하겠다

$ npm create-react-app <프로젝트 디렉토리 명>
// npm create-react-app react-storybook-component

$ cd <프로젝트 디렉토리 명>
// cd react-storybook-component

2. 스토리북 설치 다음은 스토리북 CLI를 사용해서 프로젝트에 스토리북을 설치한다.

$ npx -p @storybook/cli sb init

참고로 npx는 의존성 등의 문제를 잡아주는 노트 패키지를 설치시켜주는 노드 패키지라고 한다. 만약 깔려있지 않아 npx를 사용할 수 없다면 아래의 명령어를 통해 npx를 우선 설치해주자.

npm install npx -g

package.json 파일에 스크립트와 dveDependencies에 스토리북 이름이 붙은 코드들이 추가된 것을 확인할 수 있다면 정상적으로 설치가 된것이다.

3. 스토리북 구동 이렇게 설치한 스토리북을 구동시켜보면 스토리북에서 기본으로 제공하는 컴포넌트들을 확인할 수 있다.

   $ npm run storybook

   

이렇게 한번 컴포넌트를 등록을 해주고 나면(물론 처음 컴포넌트를 만들 때는 별도의 .stories.jsx 라는 파일을 만들어주어야 하긴 한다) 컴포넌트의 프롭스 등을 바꿔보며 손쉽게 수정, 생성할 수 있다.

그래서 앞으로 사이드 프로젝트나 일을 하면서 내가 개발하게 된 컴포넌트들을 여기다 모아놓고 다른 프로젝트를 할 때 가능한 재상용이 용이하게 하여 이용해보려고 한다.

https://github.com/Choi-Ju12g/react-storybook-component

JavaScript는 두 가지 원시 타입(Primitive Type)과 참조타입(Reference Type)이 있다.

원시 타입은 쉽게 말해, 정수, 실수, 문자, 논리 리터럴등의 실제 데이터 값을 저장하는 타입이고,

참조 타입은 객체(Object)의 번지를 참조(주소를 저장)하는 타입으로 메모리 번지 값을 통해 객체를 참조하는 타입이다.

👋🏻 원시형 타입

원시형 타입은 복사를 할 때 값 자체를 복사한다.

const number = 1;
const num2 = number;

console.log(num2);
>>> 1

위와 같은 코드에서 num2 는 1이라는 값 자체를 받아온 하나의 정수 데이터 타입이다. 또 값 자체를 받아왔기 때문에 아래와 같이 할당 이후에 number의 값을 바꿔도 num2의 값은 바뀌지 않는다.

let number = 1;
const num2 = number;
number = 2;

console.log(num2);
>>> 1

✍🏼 참조형 타입

객체와 배열은 참조형 타입이다.

const Person = {
  name: "max"
};

const person2 = Person;

console.log(person2);
>>> [object Object] {
          name:"max"
    }

여기서 Person 매모리에 객체가 저장되고, person2는 메모리에 포인터가 저장된다. 그래서 const person2 = Person; 구문 이후에 Person의 이름을 바꾸고 똑같이 콘솔에 값을 찍어보면 참조형 타입에 대한 이해 없이 바라봤을 때와 다른 결과값을 볼 수 있다.

const Person = {
  name: "max"
};

const person2 = Person;
Person.name = "min";

console.log(person2);
>>> [object Object] {
          name:"min"
    }

분명 값을 넘겨준 이후에 값을 바꾸었지만 값은 똑같이 변했다. 이것이 참조했다고 하는 이유이다. 단지 포인터를 복사해서 새로운 객체가 가르키도록 했기 때문이다. 이를 이해하는 것은 중요하다. 다른 곳에서 같은 객체를 참조하고 있다가 데이터 변경이 일어났을 때 예상치 못한 효과가 발생할 수 있기 때문이다. 그렇다면 이것을 완전히 새로운 객체로 받으려면 어떻게 해야할까?

바로 객체를 만들고 다른 인스턴스의 속성을 전개하면 된다.

const Person = {
  name: "max"
};

const Person2 = {
  ...Person
}

Person.name = "min";

console.log(Person2);
>>> [object Object] {
          name:"max"
    }

다음과 같이 하면 진짜로 우리가 원하는 객체의 복사가 일어난다.

나는 현재 남도 학숙(지역 학사)에 살고 있다. 그렇게 아침과 저녁을 보통 학숙에서 나오는 밥을 먹는데, 매번 식사 메뉴를 확인하기 위해서는 아래와 같은 과정을 거쳐야 했다.

1. 핸드폰 크롬에 남도학숙 검색.
2. 남도학숙 사이트에서 남도학숙 학사관리 시스템 입장.
3. 로그인
4. 학생 생활 지원 -> 식단표 -> 식단 확인

이 일련의 과정이 우선 귀찮았다 . 그리고 학사는 아무래도 많은 학생들의 밥을 해야해서 그런지 정말 맛있어보이는 메뉴인데 입에 안맞고, 기대도 안했는데 너무 맛있었던 경험이 꽤 있었다. 그래서 남도학숙 식단 어플을 만들어서 쉽게 식단 메뉴를 확인하고 나만의 별점을 매겨서 내가 맛있게 먹었던 메뉴가 나오는 날에는 별도의 알림을 보내 줄 수 도 있는 어플을 만들어 보려한다. 참고로 어느정도 만들고 나면 남도학숙에 무료로 뿌려서 피드백도 받아보고 가능하면 서비스를 해보려고 한다.

🙏 기능 정의

• 어떤 어플?

  • React와 Node.js를 이용한 웹 뷰 어플리케이션

• 기능

  • 로그인(남도학숙 아이디 비번)
  • 로그인 유지 혹은 자동 로그인(쿠키/세션스토리지 사용)
  • React의 SPA 화면
  • 남도학숙 식단표 크롤링

• 배포

  • Github Pages 같은 무료 호스팅 사이트를 이용 예정.

• 기술 스택

  • React(함수형 컴포넌트 방식)
  • css in js 방식으로 styled-components 생각
  • node.js

👏 계획

이 프로젝트는 오래 걸릴 것이다. 기능이 많아서도 내가 투자할 시간이 없어서도 아니다. 내가 사용할 기술 하나하나에 이유와 목적을 가지고 시작할 것이고, 그것을 다 기술할 것이며 해결해 나가보려고 한다.

참고자료 : SPA without server(깃헙 페이지 동작 가능) 하게 해준 github repo

문제점

지난번 [무작정 포트폴리오] 3. SPA 구현(Vanilla JS)에서 SPA 구현에 성공한 듯 보였다.

하지만 이를 위해서 예제로 express라는 서버를 사용하였고, 서버의 역할은 새로운 url의 요청이 들어올 때, 사용자가 지정한 형식으로 url을 변경하여 <a>의 href 속성값을 맞춰주며 SPA를 구현했기에 깃헙 페이지나 평소에 사용하던 vscode의 extension인 'live server'를 이용하게 되면 원하는 동작이 실행되지 않았다.

해결법

해결법은 지난 포스트의 server.js(express)가 해주었던 url 변경(라우팅 조작)을 Github Pages의 동작에 맞춰주면 된다. (ex.~/post -> ~/<repo 이름>/post 와 같은 형식으로 변경해야한다.)

📂portfolio(프로젝트 폴더) | |---- 📂static |      |---- 📂 css |      |---- 📂 js |             | ---- 📂 components |             | ---- index.js(수정) |             | ---- lib.js(생성) |---- index.html |---- server.js(삭제)

🎈 lib.js

const PROJECT_TITLE = '<repo 이름>';

export function u(url) {
  return `/${PROJECT_TITLE}${url}`;
}

lib.js는 간단하다. Github Pages의 기본 설정을 보면 레포지토리 이름이 마지막에 위치하게 된다. ~/<repo 이름>의 형식으로 말이다. 그래서 레포 이름을 상수값으로 설정해두고, 인자를 그 뒤에 붙인 문자열을 반환하는 함수를 작성한다.

👑 index.js

이는 정규 표현식(Regrex)에 대한 이해가 필요한 부분이긴 하나 목적은 확실하다. 내가 버튼에 연결해둔 링크 뒤의(href="<이름>") <이름> 부분을 주소(url) 끝부분에 ~/<이름> 으로 만드는 것이 목적이다. 그리고 문자열 매치 함수 역시 커스텀으로 손봐 이용 할 수 있게 되었다.

한계

당연히 수동으로 url의 결과값을 예상하여 수정하는 방식이었기에, 한계가 존재한다. 1. 페이지 새로고침 2. 유효한 경로값 입력 이를 해결하기 위해서는 매번 첫 페이지로 돌아가야 한다. 이에 대한 해결은 local static server(in SPA mode)나 Netlify config로 할 수 있다곤 하는데 당장은 고려하지 않을 예정이다. 이유는 내가 만들 포트폴리오 사이트는 정적 사이트이며 사용자와 인터랙션 하는 일이 거의 예상 가능한 범위 내이기 때문에 당장은 신경 쓰지 않으려고 한다.

잠정 중단

3월부터 ICT인턴십을 하게 되면서 회사에서는 바닐라 타입스크립트와 리액트를 사용하게 되었다. 물론 그것이 내가 자바스크립트를 이용한 포트폴리오 제작에 추가적인 공부를 할 시간이 없다는 이유는 아니다. 단지 현재 회사에서 더 많은 것을 얻고 싶다. 프론트 개발자로서는 정말 많은 일과 기능을 구현해 볼 수 있는 회사에 인턴을 4달동안 할 수 있기에 더욱 집중해보려고 한다. 그래서 잠시 포트폴리오 사이트 제작은 멈추고(대신 포트폴리오 정리는 노션을 이용해서 내용을 미리 채워 두겠다), 리액트를 이용한 개인 프로젝트를 진행 해보려 한다.

📢 첫 결과 화면

2.19 ~ 2.21 까지가 합격한 학생이 인턴 기업을 확정하는 기간이었다. 나는 안타깝게도 1기업 서류 탈락, 2기업 면접 탈락이라는 결과를 맞이해야 했다. 내가 많이 부족한 것은 당연히 알고 있었고, 사실 붙는게 매우 어려울 것이라 생각했어서 그렇게 아쉽진 않았다. 정말 진심으로 말이다.

그렇게 복학을 준비하며 공부를 이어나가고 있었다. 그런데 2.21 오후 4시 경 C기업에서 전화를 한통 받게 된다.

첫 마디가 "예비 순위가 높으셔서, 몇 가지 더 확인하고 싶어서 연락드렸습니다" 였다. 질문은 졸업까지 남은 학기와 원하는 개발 파트 재확인이었다. 그렇게 전화를 받고나니 공부가 손에 안잡혔다. 괜히 붙을 것만 같고 그랬다. 추가 합격 기간은 2.22 부터였기에 내일즈음에나 결과가 나오겠거니 하고 있었는데, 전화 통화 2시간 뒤인 오후 6시경 추가합격 공지를 받았다.

🎁 최종 결과

너무도 감사하게 인턴의 기회를 얻었다. 그리고 붙은 기업은 3개 중 내가 가장 가고 싶어 했던 기업이다. 인턴으로 하게 될 업무가 굉장히 명확하게 나와있었고, 웹 프론트엔드 개발자를 뽑는 기업이었으며, React라는 프레임워크를 사용한다. 또 살게 될 학사에서 편도 40분 정도의 거리였으며, 점심 식사비 지원을 시작으로 복지는 유연근무제(13시간), 재택근무(주 13회), 개발 장비 제공, 복장 완전 자율, 외부 교육 및 기술 세미나 적극 지원, 도서 구입 지원 등 처음 회사에서 일해보게 될 나한테는 하나하나 너무 매력적이고 많았다.

이번 기회를 정말 잘 살려서 어떻게든 개발자로서의 능력을 키우고 성장할 것이다. 저번 글에서 말했던 것처럼 이제는 진짜 인턴 일지 같은 형식으로 내가 만들고 공부한 것 등을 정리해서 올릴 수 있도록 하겠다.