[WIL | 항해99] 마지막주차 회고 실전 프로젝트 끝!( feat. FE tip)

시간이 어떻게 흘러갔는 지도 모르겠는데 6주가 흘러가 버렸다!

처음 끝났을 때는 너무 얼레벌레 끝나서 솔직히 어벙벙하고 허탈함과 아쉬운 감정이 많이 들었다.

하지만 생각해보면 나만 처음이 아니라 모두가 처음인 협업 프로젝트였고 누군가를 탓하기엔 

각자가 너무 최선을 다해주었고 고생했다. 우리팀은 모두가 예스맨이고 모두가 쓴 소리를 못하는 둥근 팀이다.

처음엔 이게 너무 다행이라고 생각했는데 프로젝트를 끝내고 보니 오히려 독이 된 거 같다.

서로가 서로를 너무 배려한 나머지 누구 하나 독촉하거나 카리스마로 전두 지휘하는 게 없었다. 

솔직히 이 분위기에서 악역이 되기를 자처하기가 힘들다. 😣

 

  6주라는 시간이 주어지다보니 뒤로 갈수록 기능 구현 데드라인이라는 개념이 흐릿해져갔다. 기능 구현을 빠르게 진행했어야 했던 게 사실 모든 기능이 유기적으로 연결되어 있어서 한 쪽이 늦어져 버리면 구멍이 생겨버린다.

  각각 파트를 나눠서 기능 구현하는 것인데 뭐가 문제인가요? 생각할 수도 있겠지만 사실상 팀원의 역량은 랜덤이라서 각자 맡은 파트를 완벽하게 소화할 수 있다는 전제는 거의 성립되지 않는다. 그래서 보통 잘 하는 팀원분이 빠르게 본인 파트 기능을 구현을 하거나 더딘 팀원 쪽에 붙어서 조력해주는 식으로 하나하나 해결해가야 그 뒤에 상황이 매끄럽게 된다. 우리팀 같은 경우는 새로운 기술로 webRTC와 socket.io를 선정했는데 모두가 그 쪽에 신경쓰느라 기본적인 기능에 대해서는 신경 쓰기가 어려웠다. 마지막 주에 급하게 서로 각자 하던 것을 맞춰보다보니 당연히 될 것이라고 예상했던 기본 기능들이 배포 후 제대로 요청이 가지 않거나 에러 메세지를 뱉어냈다. 

  결론적으로 이번 프로젝트에서는 기본적인 기능만 구현해보고 view 와 관련된 css 작업 그리고 라우팅처리를 했고 프로젝트를 마무리하게 됐다. ( 이 부분이 가장 아쉽다. 어찌 됐든 면접에서는 내가 구현한 기능에 대해서 설명하게 될거라 팀프로젝트에서 어려운 기능을 구현했다 하더라도 내가 직접 구현해본 것이 아니라면 의미가 크게 없다. )

 

  중간에 급격한 우울감과 스트레스로 번아웃이 4번 정도 왔다. 그럴 때마다 병에 걸린듯이 하루 종일 잠을 잤는데 보통 토요일 저녁밥시간 이후에 잠든 뒤 다음 날 일요일 저녁까지 죽은 듯이 잤다. 스트레스로 머리카락도 항해를 진행하면서 너무 많이 빠졌다. 지금도 숭숭... ㅠ ㅠ 항해가 끝나면 규칙적인 생활을 하면서 면접 준비를 할 예정이다( 공부는 정말 체력싸움이라는 걸 느낀다 ).

 

  정말 이상한 게 사실 번아웃이 왔을 때 생각했던 것이 "프로젝트가 끝날 때 쯤엔 코딩을 하기 싫을 수도 있겠다." 였다. 막상 끝나고 나니 최종 프로젝트에서 다른 팀이 한 작품들을 보고 "와 우리도 저 기술써볼걸 아쉽다 배워보고 싶다" 라는 감정이 더 많이 든다. 결론적으로 나의 마지막 감상은 아쉽지만 잘 싸웠다! 인 거 같다. 한 편으로는 안도감도 든다. 정말 자괴감도 많이 들고 회의감도 많이 들었던 시간이었는데 개발을 공부할수록 더 모르겠고 그래서 더 배우고 싶다. 위에서 계속 힘든 경험으로만 쓴 거같아서 덧붙이자면 나는 원래 좋은 면보다는 현실적인 문제를 나열해놓는 것을 좋아한다. 내가 후회했던 점들을 이 글을 본 사람이라면 겪지 않았으면 좋겠는 마음에 공유한다.

---

~실전 프로젝트를 앞둔 FE들에게 얘기해주고 싶은 tips~

(라고 썼지만 걍 제가 아쉬웠던 것들 써놓은 거임ㅎ)

• 본인이 맡은 기능을 담당하는 페어 BE와 (다른 백엔드 분들보다) 더 많이 소통하고 기능을 빨리 맞춰보세요. 각자 로컬에서 잘 돌아가는건 1차 완성이지 최종 완성이 아니라고 생각합니다. 만약 해당 기능에 아직 담당이 없다면 가만히 있지말고 백엔드와 소통 후 구체적인 답변을 받아내세요!
• 둘 다 잡아야 겠지만 우선 순위를 두자면 "기능구현 > view구현" 이라고 생각합니다.  처음부터 공통으로 사용할 CSS 컴포넌트를 만들고 진행한다면 해당하지 않으니 스킵해주세요!
  • 저는 뷰에 있는 디테일에 좀 집착했었는데 러프하게 나마 view를 잡아두시고 나중에 디테일을 잡아도 괜찮을 거 같습니다. 어차피 디자인은 디자이너님이 야금야금 수정하셔요. CSS에 너무 집착안하셨으면 좋겠다는 말! 왜냐면 제가 그랬다가 시간을 좀 많이 잡아먹혔어요 ㅎㅎ..손도 느린데 그걸 그냥 보고 못 넘기겠어서 ㅎㅎ..
• 겁먹지말고 새로운 기술을 적용시켜 보세요! 예를 들어, 기존에 리덕스를 썼고 배웠다면 리액트 쿼리를 적용해서 전역 상태 관리를 해본다든가 .. 물론 가장 중요한건 사용하는데 이유가 타당해야 한다고 생각해요. 이유도 모르고 새로운 기술이니까 좋게 봐주지 않을까?! 하고 도입하는 것은 아니라고 생각합니다.
• 패키지나 라이브러리를 충분한 검색을 거쳐서 선정하고 적용하세요. 저는 실제로 캐로셀을 구현할 때 처음 적용했던 라이브러리를 다른 라이브러리로 바꾸면서 같은 일을 두번하게 됐는데요. 검색을 충분히 했다면 시간을 단축할 수 있었을 거 같습니다. 또한, 패키지를 갖다 쓰는 게 더 효율적인지 근본적으로 생각하고 적용하시는 게 좋을 거 같습니다. 저는 패키지를 갖다 쓰면서 내부적인 오류가 발생했을 때 오히려 그 패키지의 오류를 해결하는 데 시간이 더 많이 걸렸습니다 ㅎㅎ

예를 들어, swiper.js를 사용하여 캐로셀을 구현시 이미지 슬라이더 중 하나를 클릭하면 onClick 이벤트에 콜백 인자로 swiper 객체가 들어있습니다. 해당 객체를 사용하면 swiper.clickedIndex 속성을 통해서 클릭된 슬라이더의 인덱스 값을 알 수 있는데요. 문제는 클릭 이벤트가 발생했을 때 swiper의 슬라이더가 제대로 인식하지 못할 때가 있다는 겁니다. 구글링을 엄청했는데 정확한 이유는 아직도 알 수 없고 swiper가 모바일 친화적인 라이브러리라서 그런 게 아닐까 생각하고 있습니다. 혹시 이유를 아시는 분이 있다면 알려주세요...^ ^

 

p.s. 마지막으로 많이 부족하고 승질머리인 저와 함께해주신 4조 팀원분들 너무 감사합니다.

각자 꼭 취업해서 멋진 개발자로 만나요🤍 (쌩까지 말란 소리)