[Pre-Project] 프리프로젝트 회고

드디어 프리프로젝트가 종료되었습니다..! 정말 다사다난했고.. 실제로 배포하는 과정까지 거치면서 너무 힘들었던.. 일주일이었습니다.
막상 처음에 기획을 하려니, 어떻게 해야할지 막막해서 이전 기수분들이 진행하셨던 리포지토리를 자주 방문하면서 봤던 것 같아요.

아래는 저희팀의 리포지토리입니다.

GitHub - codestates-seb/seb44_pre_015

 

프리프로젝트를 진행하면서 제일 크게 느낀 것은 두 가지 였습니다•••

1) 일은역시.. 커뮤니케이션이 전부다..
2) 안되는 건 없다..

 

프로젝트를 진행하면서 처음으로 백엔드분들과 소통해야하는 게 두려웠습니다. 백엔드분들이 어떤 언어를 다루시는지, 어떤 툴을 다루시는지 전혀 알지 못해서 아쉬운점이 있었던 것 같아요. 그래도 적극적으로 나서서 프론트엔드의 진행상황이 어떤지 그리고 백엔드의 진행상황이 어떤지 자주 물으려고 했습니다.

역시 .. 일의 중심은 커뮤니케이션이라고, 저희팀은 매일 오전마다 진행상황과 결과물을 공유하면서 어느정도 각자 진행되었는지 빠르게 알 수 있었습니다. 또 필요하다면 오후 5시경에도 회의를 진행하였기 때문에 정말 좋았습니다.

사실 제가 좀 회의를 강행한 경향이 있었는데요, 그럼에도 불구하고 마지막까지 회의에 성실하게 참여해주셨던 저희팀원분들께 너무 감사했습니다.

역시 어떤 분야, 어떤 직종이든 커뮤니케이션이 제일중요하다고 느꼈습니다..

 

● 그놈의 프록시..

처음에 프록시 설정을 하려고하는데, 배웠던대로 package.json에 설정해도 잘안되길래 http-proxy-middleware를 활용해 해결하려고 했으나, 이상하게 vite 프로젝트에서 적용되지 않았습니다. 알고보니 vite 프로젝트에서 적용하는 방법이 다르더군요.. http-proxy-middleware 라이브러리를 사용하지 않아도 vite에서 자체적으로 지원해주고 있었습니다. 그래서 CORS에러를 쉽게 해결할 수 있었습니다.

아래는 참고하여 해결했던 블로그입니다.

Vite Proxy 설정하는 법

 

● 배포과정에서의 http, http문제

저희 백엔드분들과 프론트분들이 정말 많은 고생을 하였기에.. 배포는 무조건적으로 해내고 싶었습니다.. git-action으로도 배포해보고, vercel로도 배포해봤는데 저희 API의 요청이 http였기 때문에 보안상 막히는 문제가 있더군요..

아래의 블로그가 배포과정중에서 저희팀이 직면했던 문제였는데, meta태그를 넣거나 vercel.json파일을 넣어도 해결되지 않았습니다.

Mixed content 문제 해결(https 사이트에서 http 사이트 요청 시 발생하는 보안 문제)

아마 보안상 그냥 막혀있는 것 같았어요. git-action, vercel 모두요. 블로그 글중에서 해결방법이 있었지만 2023년 최근 해결방법은 없었기때문에 이전에 있었던 해결방법도 모두 막혔다고 판단했습니다.

그러던 중 저희 팀원 분 중 한분이 netlify가 http 통신도 지원을 해주는 것 같다는 이야기에 netlify로 배포를 하게 되었고, vite에서 proxy를 설정해주었지만 netlify 서버를 이용해 배포를 하는 것이기때문에 netlify.toml 파일을 추가하여 proxy설정을 해주었습니다.

아래 블로그를 통해 http 통신을 해결할 수 있었습니다.

[배포] Netlify proxy 설정

 

프로젝트 과정 중에 가장 크게 배웠던 것들은 이 두가지였던 것 같습니다. 배포 과정을 직접 해보니까 정말.. 많은걸 배울 수 있었습니다. 이외에도 웹 에디터를 프로젝트에 적용한 것이 신기했습니다. 이전에 혼자 나만의 블로그를 만들어보자며 next.js로 연습했던 적이 있습니다. 그때 웹에디터를 적용하다가 하지못했었는데 이번 프로젝트에 적용해볼 수 있었어서 좋았습니다..

 

● 아쉬웠던 점,  그리고 개선하고 싶은 점

1) 프론트엔트 팀장으로서 여러므로 책임감있게 통솔하려고 했으나, 실제로 저희 팀원들이 제가 책임감이 있었다고 느꼈었을지 걱정이 되는 부분이 있습니다. 정말 코드를 짜는 시간은 순수 일주일이었는데, 일주일동안 이슈, 칸반, 브렌치를 관리하기가 쉽지 않았습니다.. 그럼에도 불구하고 팀원분들과 함께 애자일 방법을 최대한 준수하면서 프로젝트를 진행하려고 했으나 급한 hot-fix들이 자주 터져서 지켜지기가 많이 어려웠던 것 같습니다. 시간에 쫓기는 만큼 이슈까지 작성하기란 쉽지 않았습니다•••

그래도 최대한 이슈작성과 git-flow방식을 준수하면서 브렌치를 나누고 PR해주시는 저희팀원분들께 감사했습니다. 따라서 메인프로젝트에서는 최대한 애자일 방법을 더욱 준수하면서 진행하고 싶습니다. (칸반, 이슈 활용 적극도를 매우 높이고 싶습니다.)

2) 폴더 구조를 제대로 짜지 않고 프로젝트에 도입한 것이 조금 아쉬웠습니다. 프론트 팀장으로서 마음이 급급하다보니 가장 중요한 점을 놓치고 말았던 것 같습니다. 다음 프로젝트에서는 폴더구조를 명확히 구분하고 프로젝트를 진행하는 것이 맞다고 판단했습니다.

3) 추가적으로 husky의 도입이 정말 중요하겠다.. eslint, prettier를 도대체 왜 쓸까 왜 배울까 했는데 역시 모든건 팀활동에서 나타나는구나 싶었습니다.. husky, eslint, prettier 다음 프로젝트에서 무조건 도입하겠다고 결심했습니다.

4) 브랜치 규칙.. hot-fix가 생기면 생각보다 잘 지켜지지 않습니다. 매우 매우 매우 더 엄격히 준수할 수 있는 방안과 제도를.. 명시해야겠다고 생각했습니다.

5) 커밋컨벤션같은 경우에도 기본적으로 이뤄지는 커밋컨벤션이 조금 제한적이라고 느껴질 때가 있었습니다. 따라서 팀에따라 일반적인 커밋컨벤션 말고도 커스텀하여 세분화하는것도 나쁘지 않을 것 같다는 생각이 들었습니다.

 

● 최종적으로 느낀점

소통이 전부다!

진짜 소통이 전부다! 백엔드 잘몰라도 그냥 미친듯이 물어보고 가능한지 여쭤봐보고 시간내로 구현이 안되면 타협하는것 까지도 모두 소통이기때문에 정말 소통이 전부라고 느꼈습니다.. 그리고 안되면 될때까지.. 새벽까지 구현해보고 포기해보는게 맞다고 생각했습니다.. 역시 안되는건 없다. 정말로 중꺽마가 제일 중요한 것 같습니다.. 그리고 저희팀.. 정말 최정예의 팀이었습니다. 주말에도 늘 계셔주시고, hot-fix도 주말에 해결해주시고.. 진짜다들 책임감이 너무 넘치셔서 좋았습니다. 저녁 12시까지~ 새벽이 넘어가도 디스코드 채널에 계시는 모습보고 정말 저도 같이 열심히 하게 된 것 같아요. 우리팀 최고입니다. 정말 최고. 

 

아래는 저희 배포링크 입니다!

StackOverflow