[포스코x코딩온] 풀스택 부트캠프 10주차 정리 -2 (2차 프로젝트 회고完)

12/ 28

 얼추 이제 끝난 것 같다. 그래서 중간점검을 하면서 백엔드나 프론트엔드에서 버그가 생기는지를 머지 후 확인하기로 했다. 백엔드의 경우 에러가 날 경우 멈추지만, 프론트의 경우 HTML의 특성상 그냥 무시하고 진행하기 때문에 치명적인 에러가 아니라면 드러나지 않는다. 그렇기 때문에 프론트쪽에서 더 유심히 봐야했다. 나는 디자인적으로 사소한 변화를 눈치채지 못했지만 다들 눈치 채셔서 되게 대단했다. 

 

 - 다른 폴더에서 작업을 하시다가 모든 페이지를 합쳤기 때문에 경로 문제가 발생했다. 다만 내가 404에러 핸들러를 미들웨어로 마지막에 설정해놨기 때문에 오류 메세지가 뜨지 않았다. 그래서 프론트 콘솔에서 404에러가 뜬 경우 에러 핸들러를 해제하고 원인을 찾을 수 있었다.

 - axios같은 경우는 console에 나오지만 class가 두개가 있어서 eventlistener가 적용되지 않는 에러가 조금 있었다. 그런건 하나 하나 찾아서 수정했다.

다만 MVC를 했음에도 불구하고 프론트 측에서 적지 않은 코드 중복 (axios로 보내는 로그아웃 로직 등)이 있음을 확인했다. 나중에 다 통합해버려야겠다.

 - (head나 header를 export하는 ejs 파일에서 안의 파일에 닫는 태그를 넣지 않아야 메인 ejs에서 추가가 가능한데 하지 않았기에 생긴 문제 중 하나가 아닐까 생각한다. 다만 곧 react로 프로젝트를 진행하면 이거 개선을 하지 못하는게 아닐까 싶다.

어차피 다른 분들이 어떻게 짜셨는지 다 기억나니까 내가 조금씩 수정하면 될 것 같다.)-

---

12/ 29

프론트 페이지의 z-index에 관한 문제를 수정했다.  z-index를 주는 값에서도 차이가 나버리니까 (a는 10, 20, 30으로 주고 b는 -1, 0, 1로 줌) backdrop 위에 다른 것들이 가 있었다. 

다만 z-index를 바꿔도 해결되지 않았다.

근본 원인은 1차 프로젝트에서 알게 되었던 z-index는 형제 요소끼리만 적용된다는 것에 있었다. 

z-index는 부모 안에서의 형제 요소끼리 z-index를 정하기 때문에 부모 요소의 z-index가 낮아버리면 자식 요소의 z-index가 아무리 높아도 뒤로 갈 수 밖에 없는 것이다. 이전 프로젝트가 도움이 되었다.

팀원분이 ejs에 있는 script를 static/js로 빼셨는데 갑자기 글쓰기가 되지 않는 오류가 발생했다. (401 에러 페이지로 redirect 되었다.) 처음에는 MVC가 원인인지 몰라서 다른 이상한 것들을 바꾸다가 해결되지 않아서 점점 거슬러 올라갔다.

그러다보니 js파일 ejs 문법(<%= somethin' %>)을 쓰고 있음을 알게 되었다. 나도 이걸로 고생 깨나 해서 바로 해결할 수 있을 줄 알았다...

어차피 브라우저측 js니까 ejs 파일에서 변수를 정의하고 거기서 ejs 값을 할당하는 방식으로 해결했었기 때문에 그렇게 적용했다.

나였다면 위에 넣고 defer를 했을 것 같은데 뭐 사람마다 방식이 다르니까.

 

하지만 적용되지 않았다. 분명히 내 머리 속 시뮬레이션 상 고쳐져야하는데 오류가 전혀 고쳐지지 않았다. 알고보니까  static/js 경로로 script를 빼시면서 같은 함수가 두개씩 넣어버리셨다는 사실을 알게 되었다. 내가 바꾸고 있었던 건 밑 함수라서 적용이 안되었던 것 같다. java의 경우 메소드 오버로딩이 되었을 텐데 js는 적용되지 않나..? 

애초에 parameter가 바뀐 것이 아니고 안에 실행 코드가 바뀐 거라서 java였어도 에러가 났을 것 같다. (애초에 프론트라서 js를 써야하나?)

 

그리고 오토포맷이 되어서 ''가 ""가 되어 <%- %>문법이 적용되지 않을 경우(script 안), 백틱으로 바꾸면 오토포맷의 영향을 받지 않고 해결됨을 확인했다. js 에서 백틱은 무적이다.

얼추 끝난 것 같아서 서버 배포를 하려했다. 어렵지 않게 file zilla로 프로젝트 폴더를 옮기고 npm install을 하는데 갑자기 서버가 멈췄다.

진짜 아무 생각도 안나서 리더님께 도움을 요청하니 인스턴스를 삭제하고 새로 만드는 것도 하나의 방법이라는 말을 들었다. 

마감이 하루남았는데 db데이터도 내 서버로 저장했기 때문에 다시 서버를 만들 경우 리스크가 너무 커서 고려도 하지 않고 서버가 돌아오길 기도했다.

중지하고 다시 시작했는데도 오류가 계속 떠서 심호흡을 하고 다시 확인해보니 public IP주소가 바뀐 것을 확인할 수 있었다. 중지하고 다시 시작하면 IP주소가 바뀌는건지. 아니면 에러가 떠서 IP주소가 바뀐 건지는 잘 모르겠다. 

어쨌건 서버와 db를 새로운 IP주소로 연결하고 프로젝트 폴더를 내 서버 경로에 넣고 node app.js로 nginx를 실행했다.

하지만 돌아온 건 내가 예전에 실습했던 압도적 감사 html이었다.

알고보니까 그때 실습을 아파치로 했는데 아파치는 80번 포트를 이용하고 나는 8000번 포트를 이용하고 있기 때문에 내 서버로 들어갈 경우 정상 배포 포트인 80번으로 먼저 들어가지는 거였다.

그래서 내 서버 아이피:8000을 하니까 의도한 프로젝트 페이지가 등장했다. 그래서 80번 포트를 이용하고자 아파치를 중지하고 다시 안쓸거기 때문에 아파치 삭제 후 node app.js를 했다. 그런데 아파치가 좀비가 되었는지 다시 그 페이지가 떴다...

다시 한번 중지하고 app.js를 실행하니 배포 권한이 없다는 다른 오류가 생겼다. 구글링 해보니 이 오류는 알고보니까 권한이 없는 사용자가 1024 이하의 PORT로 배포하면 생기는 오류임을 알 수 있었다. 그래서 권한을 부여하려고 했는데 다른 팀 또한 8000번 포트로 그냥 배포해버렸고 리더님도 상관 없다고 해서 굳이 배포 권한을 부여하지 않았다.

이것만 하면 배포 끝일줄 알았는데 서버를 배포하려면 PM2를 써서 Node JS 무중단 서비스를 해야한다는 것을 몰랐다. apachi의 대체재가 nginx라고 생각해서 nginx만 설정했던건데 putty창을 닫으니까 프로젝트 url 요청에 응답하지 않았다. 분명 배운건데 까먹었다. 이걸로 리더님께 약간의 쿠사리를 먹었으니 나중에는 안까먹을 것 같다.

 

 

만들고 나니 프론트 분들이 정말 고생하셨다는 게 ejs파일의 길이에서 느껴졌다.

 

---

+ 서버가 맛가고 나서 mysql 워크벤치에서 내 서버 mysql이 연결이 안된다....

아마도 key의 문제인 것 같아서 새로운 서버 ip로 들어가서 id rsa키를 새로 발급받았는데도 안된다.

그래서 rsa를 삭제하고 새로 발급 후 했는데도 안된다....

이유가 뭘까..... 이건 진짜 모르겠다. 어떤 에러인지라도 알려주던가

이거 해결못하면 RDS를 쓰자