[패스트캠퍼스 X 야놀자] FE 1 부트캠프_미니프로젝트

포스팅 소개

안녕하세요~!✋

아마 이 포스팅을 보고 계신 분이라면 아마 어떤 부트캠프가 좋은지 찾아보고 계신 분 이실 것 같은데요!

저도 지금의 부트캠프(패캠에서 운영하는)에 입과 하기 전에는

기왕 공부하는 거라면 좋은 곳에서 공부하고 싶어서 많이 찾아봤었습니다!

그래서 이렇게 기자단 활동을 통해서 여러분의 궁금증을 해소시켜 드리려고 준비했습니다!

예전에 제가 걱정하고 궁금했던 부분들을 어떻게 해결할 수 있었는지를 중점으로 작성해 나갈 예정이니,

다른 포스팅도 같이 잘 확인해 주세요~!

 

필중이의 스펙(2023-06-01기준)

• 전공
  간호학과(4년)
• 커리어
  수술실(1년)
• 코딩 경험
  2023.03.14~2023.06.01(공부기간)
  구글확장프로그램 제작(SKIPAD)
• 알고리즘 역량
  프로그래머스 파이썬(코딩 기초트레이닝, 코딩테스트 입문, Lv1 문제) 총 300문제 풀이.
• 부캠 경험
  SSAFY 1차 CT (탈)
  네이버 부스트캠프 2차 코딩테스트(탈)

 

---

1.  프로젝트 기획

이번 프로젝트에서는 숙박예약 중개 플랫폼을 과제로 받았습니다!

김송아 멘토님

 

FE/ BE 야놀자(현직자) 멘토님

프로젝트 준비를 하면서 멘토님들이 가이드한 방향과 기준을 준수하며 프로젝트에 임했습니다.

2주라는 짧은 시간이 주어졌고,

백엔드 개발자 분들과 처음 협업하는 과정이었기에 최대한 협업에 초점을 맞췄습니다.

한정적인 개발 자원을 이용하기로 하여 튼튼한 앱을 만들어보기로 했습니다.

하지만 대부분의 프로젝트가 그렇듯 초기 설정과 컨벤션에서 시간이 가장 오래 걸렸습니다.

*컨벤션 : 개발의 일관성을 위한 코드 작성 규칙이라고 생각하면 됩니다.

 

그전 토이프로젝트 1, 2 동안에는 리액트에 최대한 익숙해지기 위해 노력했다면,

이번엔 좀 더 거시적인 시야로 SEO를 고려한 NEXT.JS를 사용해 보기로 했습니다.

리액트가 SPA라면 NEXT는 MPA와 같은 성격을 가지고 있습니다.

그것이 가능한 이유는 Server Component가 있기 때문인데, 즉, SSR(server side rendering)이 가능하다는 것입니다.

리액트는 자바스크립트 기반으로 html을 Client side에서 rendering 하는 반면,

넥스트에서는 서버에서 먼저 html을 그려올 수 있기 때문에

구글과 같은 검색 엔진에서 html을 읽을 수 있는 것입니다.

그렇다는 것은 SEO(Search Engine Optimization) 검색엔진 최적화에 유리하다는 것입니다.

 

그래서 다시 새롭게 '리액트'가 아닌  '넥스트 13'이라는 Framework를 공부하며 개발을 시작해 보았습니다.

 

2.  프로젝트 진행

팀원은 모두 8명으로 프런트엔드 5명, 백엔드 3명으로 이루어진 팀이었습니다.

다행히도 모두 개발에 적극적으로 임했으며, 서로의 의견을 존중하려는 태도가 눈에 보였습니다.

그렇게 프런트엔드(이하 FE)에서 제안한 기능과 디자인에 대해서 즉각적으로 피드백을 주고받을 수 있었습니다.

그리고 이렇게 피드백을 잘 주고받을 수 있었던 것도 협업 툴을 적절히 사용했기 때문인데

그중 첫 번째는 ZEP(젭)입니다.

2주간 놀기도(?) 하면서 공부한 장소

 

화면 공유, 음성채팅, 영상채팅, 일반 채팅, 미니게임? 등등... 정말 많은 부분들이 들어간 협업 툴인 것 같았습니다.

특히 특정 공간에 속성을 부여하면 회의실처럼 사용하여 그 공간에 있는 사람들끼리만 대화할 수 있는 것도 유용했었습니다.

다만 문제는... 다른 사람이 들어오거나 나갈 때는 알림 소리가 따로 나지 않아서 사적인 이야기는 지양해야 하는 주의점이 있습니다ㅎㅎ

아무튼 2주간 재밌게 협업할 수 있었던 좋은 툴이었습니다.

 

두 번째는 트렐로입니다.

트렐로는 기본적으로 atlassian으로 다들 알고 계실 거 같은데요.

특히 JIRA라는 협업 툴이 굉장히 유명한데요.

트렐로 역시 협업 툴로서 유용하게 사용할 수 있습니다.

팀원, 타 팀의 팀원에게 요청을 보낼 때, 간단하게 댓글이나 자료를 첨부하여 리스트를 달아놓으면 되는데요.

일반 메신저와 차이는 크게 없다고 느낄 수 있지만.. 새벽에도 요청을 달아놓을 수 있다는 점에서 정말 좋았습니다.

상대에게는 알림이 갈지 안 갈지는 상대방이 설정하기 나름이지만, 저는 개발을 시작할 때만 알림이 오도록 설정하여

딱히 새벽에 알림이 울리는 불쾌함은 느끼지 않았습니다ㅎㅎ

한마디로 요약하면 소통비용을 줄일 수 있다!!

 

 

세 번째는 명불허전... 깃허브입니다ㅎㅎ

깃허브 이슈, 프로젝트를 도입했는데요.

FE보다는 BE에서 프로젝트를 사용했는데요.

확실히 개발 일정을 한눈에 확인할 수 있었고,

어디서 막히고 있는지와 누가 어디까지 했고 요청을 어떻게 보내면 될지에 대해 파악할 수 있어 너무 좋았습니다.

 

이상 협업과 관련하여 사용했던 툴들에 대한 소개였습니다.

 

이제부터는 개발 과정에서 느꼈던 이슈나 어려움에 대해서 얘기해보려 합니다.

 

솔직하게 말하면... NEXT를 공부하면서 개발을 시작하는 게 너무 어려웠습니다...🥲

이번 프로젝트 콘셉트에 맞춰서 기술 스택을 선택했지만, 이해도가 너무 낮다 보니

개발의 진행속도는 나지 않고 하루하루 시간은 지나가고 자기 효능감이 하루가 멀다 하고 녹아내려 갔습니다.

그래도 공식문서 및 팀원들과 머리를 맞대며 개발을 진행했습니다.

그렇게 어찌어찌 굴러는 가는 프로젝트를 완성할 수 있었습니다만...

코드에 대한 근거도 부족하고 여전히 타협하며 작성하는 부분이 많았습니다.

그치만..! 그렇기 때문에 더 중요한 것이 리팩토링이겠죠?😆

그래서 다음 리팩토링에서는 더 단단한 로직을 구성하기 위해 노력할 것입니다.

최대한 복잡한 로직은 제거하고 컴포넌트도 단순화하여 분리하기 하는 것을 목표로 하고 있습니다.

 

그리고 저번 프로젝트를 하면서 느꼈던 것이었지만

라이브러리 사용을 하더라도 이해를 하면서 사용해야 한다는 것이고,

또, 공식문서를 잘 읽어보는 것이 중요하다는 것을 알았습니다.

 

미니프로젝트 깃허브 링크👇

GitHub - Dont12/KDT_Y_FE_Mini-Project: 🏨STAYINN | Discover and Reserve Your Stay

 

 

 

3.  프로젝트 회고+리팩토링

"아! 협업 생각보다 고려할게 참~많다"

라고 생각했습니다.

처음 개발을 시작했을 때는 아무것도 몰라서 보이는 대로 따라 해 보는 것이 우선순위였습니다.

그리고 이제 어떤 기능이 있는지 알게 되었을 무렵엔 프런트엔드 개발자들끼리 협업을 해보았습니다.

혼자 개발을 할 때는 기획을 두루뭉술하게 잡고 개발을 시작했는데,

협업을 할 때에는 중간에 마음대로 바꾸는 것도 어려웠을뿐더러 진행상황 보고, 변경사항 보고 등..

굉장히 고려할 것이 많았습니다.

그리고 백엔드와의 협업에서는 더 나아가

화면을 구성하는 많은 요소들, 그리고 그 요소들을 띄우기 위한 여러 기능들은 단순히 프런트만의 일이 아니라는 것을 알았습니다.

마치 백조처럼 우아하지만 발을 열심히 구르는 것과 같이 백엔드에서는 많은 로직과 데이터 구조를 고려해야 하는 것이었습니다.

이제 앞으로 파이널 프로젝트를 앞두고 있는데,

UIUX 디자이너, PM 분들과도 소통할 생각을 하니 벌써 심장이 두근거립니다!!

 

그리고 추가로 유튜브를 돌아다니다가 팀워크와 개인기량에 대한 영상을 보았습니다.

물론 개발자 직군에 대한 이야기는 아니었습니다만,

요즘 팀워크를 매우 중요시하고 또 부트캠프에서 역시 협업을 강조하는데요.

과연 팀워크를 좋게만 바라볼 수 있을까요?

팀워크에 이면에 숨겨진 나는 어떤 모습일까요?

질소 과대포장된 과자와 같은 모습은 아닐지 생각해 봐야겠습니다.

앞으로 부트캠프를 수강할 계획이신 분들, 협업을 해보고 싶으신 분들 모두 염두에 두셨으면 하는 부분이 있습니다.

팀의 성과를 개인의 성과로 착각해서는 안된다는 것입니다.

결국 중요한 것은 본인의 기량이기 때문입니다.

어느 집단을 가더라도,

아 저 사람이랑 같이 일해보고 싶다.

혹은 같이 얘기해보고 싶다 등,

이렇게 러브콜을 받는 사람들이 있는데요.

이 사람들의 대부분의 공통점은 팀워크도 좋지만 개인 기량이 우수하기 때문인 경우가 많습니다.

따라서 팀워크만을 염두에 두지 말고 개인 기량을 기르는 데에도 집중하면 좋겠습니다.

 

🛠️리팩토링 (2023-12-04~2023-12-11)

이번 리팩토링은 사실 너무 부끄러운 점이 많습니다.🥲

개인적인 완성도뿐만 아니라 다른 분들의 레이아웃과 기능에도 영향을 끼쳤기 때문입니다.

그래서 이번 프로젝트의 리팩토링은 주로 버그 수정과, 레이아웃 고정이 되겠습니다.

가장 먼저 이슈를 생성했습니다.

 

 

생각보다 많은 오류가 있었습니다.

그중 오류를 일으켰던 것은 공식문서를 참고하지 않고 대부분 블로그 참고가 문제였습니다.

공식문서는 뭔가 딱딱한 문구로 읽기가 매우 꺼려지기 때문에 기피했었습니다.

하지만 이번을 계기로 반성하고 차분히 읽어보며 필요한 부분을 짚어내는 능력을 길러볼 생각입니다.

 

리팩토링 기간 동안에는 그동안 생각만 해놨던 오류들에 대해 시간을 들여 해결할 수 있었습니다.

덕분에 공부와 병행하며 코드의 질을 높일 수 있었습니다.

이전에는 단순히 자신의 컴포넌트에만 집중을 했다면

이번에는 다른 팀원의 코드에도 관심을 가지고 코멘트 또한 달아보았습니다.

그리고 오류를 해결하는 데 있어서 이러한 점이 도움을 많이 주었는데요.

 

위와 같은 주소창에서 manage, newpost 등을 params라고 하여 하나의 매개변수로서 사용할 수 있습니다.

그리고 그 뒤에? 와 = 기호로 연결된 부분에서는 searchparams라고 하여 더 구체적으로 관리하기 위한 매개변수정도로 소개할 수 있는데요.

그래서 이 매개변수를 잘 받아와야 알맞은 화면을 렌더링 해줄 수가 있습니다.

문제는 이러한 매개변수를 주는 곳이 여러 페이지

즉, 다른 팀원들이 코드로 작성한 부분인데

이러한 부분을 보지 않고는 제 화면에서 나오는 오류를 잡아내기란 불가능합니다.

따라서

위의 사진처럼 다른 팀원의 코드를 보고 수정을 부탁하는 등

소통의 부재로 일어난 문제들을 요청하는 것이 필요합니다.

 

그동안 시간에 쫓겨 다른 팀원의 코드를 확인하기 어려웠는데

리팩토링 기간에는 여유를 가지고 확인할 수 있어 한층 더 성장할 수 있는 귀한 시간이었습니다.

 

 

 

*본 포스팅은 패스트캠퍼스 리포트 활동으로 제작되었습니다.