3. 서비스에서 내가 맡은 부분

뭐야 나 그래도 한 달 동안 많은 걸 했었군요....

navbar

• 메인페이지, 프로필 페이지 하단 navbar
  사파리 화면에서도 navbar 보이게 하기...는 여기서 확인...

메인 피드 페이지

• 스크랩 저장, 취소 기능
• 배너 클릭시 홍보용 노션으로 이동
• 유저들이 요청한 큐레이션 카드 렌더링
• affix 헤더

필터 기능

• 지역, 방문 예정 시간대, 음주 여부, 방문 인원 수 (원하는 카테고리만 취사 선택 가능.)에 따른 필터링 -> 필터링 이후에는 메인 피드에 필터링된 큐레이션 카드만 렌더링

게시글 상세페이지

• affix 헤더
• 헤더 백 버튼
• url 공유 버튼
• 해당 큐레이션 카드 렌더링
• 해당 큐레이션에 달린 답글 렌더링
• 유저 본인이 작성한 글일 경우 채택 버튼 활성화
• 타 유저에게는 채택 여부 렌더링
• 큐레이션 답글 작성 버튼

큐레이션 답글 작성 페이지

• 식당 검색 기능, 식당 검색 초기화
• 식당 사진 업로드 기능, 사진 업로드 초기화
• 답글 설명 작성(최대 38자)

프로필 페이지

• affix 헤더
• 유저 정보(프로필 사진, 닉네임, 먹BTI, 등급, 채택 건 수) 렌더링
• 탭 분리
• 유저가 작성한 글 렌더링(내 게시글 탭)
• 유저가 스크랩한 글 렌더링(가보자고 탭)

4. 그래서 성장했니 ?

이번 프로젝트를 통해 성장했냐고 묻는다면 확실하게 대답할 수 있다. 성장했다.....!!!!
처음 세오스를 들어왔을 때의 내 상태를 떠올려보면 그 때의 나는 Next.js가 있는지도 몰랐고 typescript는 사용해본 적이 없었으며 전역 상태관리의 필요성을 느끼지 못하고 있었다.
프론트 과제를 하면서 typescript를 사용하면 에러문이 꽤나 자세히 나오는 것을 알 수 있었고 이래서 프로젝트의 크기가 커지면 typescript를 사용하는구나~ 라고 자연스럽게 이해할 수 있었다. 또한 프론트 스터디 과제에서 리코일을 사용해보면서 전역으로 상태관리를 하면 하나하나 props를 전달할 필요가 없다는 것을 배웠다. 이렇게 하나씩 찍먹을 해보는 과정을 거치고 모무를 개발할 때에는 찍먹했던 것들을 씹어서 삼키는 연습을 하게 되었다. typescript는 여전히 나를 화나게 하지만 그래도 type에러 쯤에는 덤덤해지는 용기를 갖게 되었고 리덕스 구조를 머리 속으로 대충은 그릴 수 있게 되었다. 그리고 무엇보다 돌아가는 서비스를 만들었자놔요....

그리고 나 생각보다 끈질기구나.. 라는 것을 알았다. 막판 1주일은 휴가를 반납하고 진짜 코딩만 했다. 솔직히 1주일 전까지만 해도 우리 잘못하다간 QA는 커녕 마무리를 못하게 될 수도 있겠다는 생각이 있었다. 그러나 팀원들이 지금까지 고생했던 것을 생각하면 개발 마무리를 못하고 데모데이를 가는 일만은 없기를 바랐기 때문에 진짜 열심히 했다. 처음 시작할 때 이걸 한 달만에 만들 수 있다고...?라고 생각했었는데, 결국에는 기획에서 넘겨주었던 기능들을 다 구현하고 배포까지 무사히 마친 우리를 보며 조금 많이 뿌듯했다^^...!!

• 백, 프 모각코 한 날 스크린 타임 😶‍🌫️, 그리고 밤낮 바뀐 내 바이오 리듬

백, 프론트 모각코를 하는 날에는 기본 10시간 동안 밥만 먹고 코딩만 했다. 맨날 말로만 작업하다가 술먹자~~라고 얘기해놓고서 모이면 다들 개발에 열중하느라 시간이 가있는지도 몰랐다. 어쩌면 우리는 모무에 진심이었는지도....

5. 아쉬웠던 부분

5-1. 코드 재사용률

디자인이 중간에 한 번 크게 갈아엎혔기 때문에 기존에 변수로 저장해놓았던 색상들을 사용할 수 없는 상태가 되었다. 사용하는 색상의 범위를 미리 알 수 없었기에 ,, 디자인에서 피그마를 넘겨주면 곧바로 적용하는 방식으로 개발이 진행되었고 자잘한 색상이나 폰트 크기 같은 것들은 그냥 복붙^&^ 을 이용했다. 아마.. 깃허브에 들어가서 보면 알겠지만 이러한 이유로 styled-component의 길이가 매우매우 길다. 그 중에 많은 부분이 중복된 부분일 것이다.
뿐만 아니라 충분히 hook으로 분리해서 사용할만한 함수 같은 경우에도 인수 처리를 하기 귀찮아서,, 와 같은 이유들로 분리하지 않고 사용했다. 충분히 중복을 줄이면서 개발할 수 있었겠지만.. 그냥 급급한 마음에 잡아먹혔던 것 같다. (모든게 핑계지요... ) 프로젝트 시작 전에 클린 코드는 미뤄두고 일단은 기능 개발이 중요하다고 프론트 멘토님께서 말씀해주셨었는데 이건 클린 코드가 아닌 것이 아니라 더티 코드인 수준이다. 반드시 계획을 세워서 차근차근 리팩토링을 해나갈 것이다...ㅜ

5-2. 에러 처리

RTK를 사용할 때 createAsyncThunk 내부에서 try catch문을 사용하지 않는 것이 좋다고 얘기를 들었었다. 에러가 발생해야 action이 rejected 상태로 가기 때문이었다. (혹시 아니라면 알려주세요... plz) 그러나 이게 결코 에러 처리를 하지 말라는 뜻은 아니었을 것이다. 그러나 에러 처리를 할 시간조차 부족해보였던 나는 그냥 에러처리는 과감하게 건너뛰고 (과감한게 아니라 멍청한거겠죠,,,) 개발을 진행했다. 중간 중간 팀원과 thunk 내부에서 API를 이용하여 에러 처리를 하자고 이야기가 나오긴 했었지만 이를 실행하지 못한 것은 다 내 탓이다. 다행인지는 모르겠지만 비동기 통신에서는 큰 에러가 발생하지 않았따.. . 그러나 나중에도 이렇게 미흡하게 에러처리를 한다면 분명 RTK 신께서 노해서 엄청난 에러 벌을 내려주실지도 모른다.

5-3. 소통의 부재, 좋은 소통 방법이 뭔가요 대체..

본 프로젝트는 소통에 있어 너무 미흡했던 것 같다. 개발 중간 중간 개발 현황과 이슈에 대해 팀원 전체와 의논하는 시간을 가졌어야만 했는데 개발이 바쁘다는 이유로 이를 외면한 채 프로젝트를 진행했던 것 같다. 또한 프로젝트를 본격적으로 시작하기 전에 전반적인 백, 프론트, 디자인 일정을 맞춰놓고 시작했어야 했다.
좋은 소통 방법은 무엇일까 엄청나게 많은 고민을 하게 된 시간들이었다. 회사도 아닌 단순한 동료의 관계도 아닌 동아리에서 만난 우리는 어쩌면 조금은 더 단호하게 행동했어야 했는지도 모른다. 디자인이 딜레이 될 때마다 나는 괜찮다고만 말했었다. 괜찮지 않은데 괜찮다고 말하는 물러터진 방식의 소통은 결코 팀을 위한 것이 아니라는 것을 몸소 깨닫게 되었다. 나의 미흡한 소통으로 인해 어쩌면 우리 팀은 마이페이지를 완성하지 못하고 데모데이에 참석했을지도 모른다. 앞으로는 일에 있어 더 단호하고 정확한 태도를 갖출 수 있도록 해야겠다고 다짐했다.

5-4. 개발에 밀려 놓쳐버린 디자인 디테일

일단 .. 반응형까지는 아니더라도 width 조정을 끝까지 못한 것이 너무너무 아쉽다. (아이폰 11에서 보면 진짜 양옆에 패딩 마냥 있는 공백이 나를 속터지게 만든다. ) 그럴 수 밖에 없는 것이 내부 컴포넌트를 모두 px.. 심지어 absolute로 위치를 아예 박아버린 것도 있어 대공사 작업이 될 것이 뻔해 건들 생각조차 하지 못했다. 앞으로 absolute는 꼭 필요한 일이 아니라면 사용을 자제할 것이다.
또한 디자인에서 넘겨준 부분은 마땅하게 디자인적인 이유가 있을 텐데 개발 일정에 밀려 디자인 디테일을 많이 챙기지 못한 부분이 아쉽다. 매거진 컨셉의 디자인이라 디자인적인 요소에서 선이나 각진 모서리를 많이 사용했는데 필터 bottom-sheet의 모서리는 둥글다. 디자인에서는 각진 모서리를 요구했지만 내가 이를 구현하지 못했기 때문이다... 분명 radius를 조정하는 방법이 있을텐데 우선순위에 밀려 데모데이까지 디자인을 100% 반영하지 못한 것이다. 디자인 팀에서 고심해서 넘겨준 것일 텐데 디테일한 부분을을 놓친 부분이 미안했다. 리팩토링 하면서 반영하지 못했던 디자인 부분들도 함께 추가해 나갈 것이다.

5-5. 코딩 컨벤션 맞추기

모무의 프론트 개발자는 두 명이었다. 물론 각자 1인분씩은 알아서 잘 할 것이라는 것을 너무 잘 알고 있었지만 그래도 코딩 컨벤션은 꼼꼼하게 맞추고 시작할걸이라는 생각이 들었다. 둘 다 개발자들과 제대로 협업해보는 것이 처음이라 처음 컨벤션을 맞출 때 브랜치 네이밍이나 깃 플로우, 커밋, pr 내용 정도만 맞추고 개발을 시작했다. 에러라고 함은 내가 혼자 하루 종일 쳐다보고 있는 것보다 다른 사람의 눈을 빌려보면 더 빠르게 해결할 수 있는 경우가 다수 있다. 그러나 함수, 변수 네이밍 등등을 꼼꼼하게 맞추지 않은 경우, 내 코드보다 다른 사람의 코드를 해석(해독이라 해야하나요...)하는 데에는 훨씬 큰 시간과 비용이 따른다. 서로의 코드를 확인할 일이 많지는 않았지만 리뷰나 확인을 확실히 하기 위해서는 다음부터 코딩 컨벤션을 더 꼼꼼하게 맞추고 협업을 시작해야겠다는 생각이다.

코딩 컨벤션 참고 자료

6. 마무리

그래도 아쉬움보다는 얻어가는 것이 훨씬 많았던 프로젝트였다. 성장뿐만 아니라 사람 또한 ❕🍉 이 프로젝트를 통해 다음 프로젝트에서는 어떻게 협업을 해나가야할지 조금은 감이 잡힌 것 같다. 짧은 기간 동안 프론트에서 할 수 있는 부분에서는 최선을 다했다고 생각한다.(로그인~ 먹BTI 분기처리, SSR 적용 등등,,, ) 또한 어떤 서비스를 만들 수 있게끔 기획하고 디자인을 제공해주고 db와 서버를 담당해주는 팀원들이 있었기에 내가 온전히 프론트에만 집중해서 개발을 할 수 있었다고 생각한다. 아마 팀원들이 없었다면 이렇게 완성도 있는 결과물을 만들어 내지 못했을 것이다. 아마 어디가서도 이렇게 밸런스 있는 팀을 꾸려서 프로젝트를 진행해보는 기회는 흔치 않을 것이라 생각된다. 너무 감사하게도 협업의 과정과 그 힘을 고스란히 느낄 수 있는 6, 7, 8월이었다. 그동안 팀원들 그리고 나 자신 너무 수고했고 모무는 아직 끝나지 않았습니당 ! ㅎㅎ (다들 떠난다면 나 혼자 리팩토링이라도 하겠어요 .. )