[FEDC] 9월 팀 프로젝트 회고

thru·2023년 10월 3일
2

FEDC-MIL

목록 보기
5/7

프론트엔드 데브코스 9월 팀 프로젝트 회고


프론트엔드 데브코스의 첫 번째 팀 프로젝트인 소셜 네트워크 서비스를 마치고 회고를 작성해보려고 한다.

머쓱 레터

우리 팀은 1~2년 전에 커뮤니티 사이에서 화제가 되었다는 내 트리를 꾸며줘! 를 벤치 마킹해서 프로젝트를 진행하기로 했다. 데브코스에서 제공해주는 API는 모든 팀을 커버하기 위해 일반적인 SNS에서 사용하는 종류만 있다는 게 프로젝트 자유도에서 걸림돌이었지만 트리에 붙이는 메세지를 댓글, 트리를 포스트라고 생각하면 충분히 구현할 수 있을 것 같아서 결정했다. SNS 중에선 특이한 컨셉이므로 구상 단계에서 다른 팀과 겹칠 우려도 적을 것이라고 예상했다.

다행히 정말 안겹쳤다. 해당 주제 외에도 몇 가지 후보에 둔 게 있었는데 그 중엔 타 팀과 겹친 주제가 있어서 팀원 모두 이 주제를 선택하길 잘했다고 생각했었다.

처음에는 내 트리를 꾸며줘! 처럼 비밀 편지를 받는 서비스를 생각했는데 기존 서비스와 너무 겹치지 않냐는 의견에 일단 트리를 머쓱이로 바꾸기로 했다. 그리고 이왕 머쓱이로 바꾼거 데브코스 내에서 종종 했던 발표나 팀 피드백을 주고 받는 서비스로 목적을 바꿨다. 기간이 넉넉치 않은 프로젝트인 만큼 대상을 좁혀봐도 좋다는 멘토님의 조언에 아예 사용 대상도 데브코스 수강생으로 확 좁혔다.

덕분에 API에서 제공하는 알림 기능을 사용하지 않고, 슬랙과 연동해서 알림을 주는 방식을 채택할 수 있었다.


개발 이슈

Swiper

장식 선택 목록을 만들면서 좌우 스크롤 요소가 필요했다. 다른 팀원이 먼저 사용해보기도 했고 공식 문서에 예제가 종류별로 잘 나와있어서 Swiper를 사용했는데 약간 난항이 있었다.

grid 미적용

예제에 나와있는 코드대로 grid={{ rows: 2 }}를 속성으로 줬는데 제대로 작동하지 않았다. 구글링해보니 grid={{ rows: 2, fill: 'row' }}로 옵션을 추가하라는 내용이 있었고 해결할 수 있었다.

레이아웃 불안정

gap을 넣으면 가로로 무한정 늘어나고 slidesPerView를 4이외의 값으로 설정해도 정렬이 제대로 되지 않았다. 관련 내용이 없어 이것저것 해보다 className을 지정하고 css로 width를 지정해주니 해결되었다.

breakpoints 조건에서 grid 미적용

반응형 예제를 보고 breakpoints 속성을 추가해서 slidesPerView를 조절했는데 일부 breakpoint에서 grid가 다시 미적용되는 증상이 나타났다. breakpoint 마다 grid: { rows: 2, fill: 'row' } 옵션을 중복으로 지정해주니 해결되었다.


댓글 좌표

기능 구상 후 구체화하는 단계에서 제일 걱정이 많았던 기능은 댓글의 좌표를 설정하는 것이었다. 다른 사람의 머쓱이에 장식을 꾸며주는 경험이 유저들의 관심을 끌 수 있는 핵심 포인트라고 생각해서 꼭 넣고 싶은 기능이었다. 다만 좌표 기준은 어떻게 맞추고 반응형 대응은 할 수 있는 지 명확히 답은 못냈었다. 멘토님께 질문해보니 서비스 구현에 정말 필수적인 기능은 아니니 정 안되면 자유도를 줄여서 문제를 축소하는 것도 한 가지 방법이라고 하셨다.

top: 50%

일단 시도해보고 결정하기로 해서 만드는 중에 position: absolute로 쓸 수 있는 top, left 속성에 퍼센테이지 값도 적용이 된다는 걸 알게 되었고, 생각보다 수월하게 기능을 구현할 수 있었다. 머쓱이 이미지와 댓글 container를 공통 부모로 묶고 top, left 속성과 크기 속성을 모두 퍼센테이지로 설정하니 반응형 대응도 문제없이 가능했다. 잘 안됐다면 성능의 불이익을 감수하고 JS로 구현할 생각을 하고 있었는데 CSS를 적절히 활용하면 간단하게 해결할 수 있다는 걸 깨달았다.


form 연결

react-hook-form ⨉ Swiper

Swiper를 사용했던 장식 선택 모달이 댓글 작성하는 기능을 담당해야 하는 요소라서 react-hook-form을 사용하기로 결정했다. 댓글의 내용과 작성자 닉네임을 작성하는 칸은 inputtextarea로 구현해서 연결이 어렵지 않았는데 장식 선택 Swiper가 문제였다.

처음 시도한 것은 Swiper 뒤에 임시 input을 만들어두고 장식 선택 시 input 값을 설정하는 방법이었다. useFormregister도 잘 작동해서 값을 작성하지 않고 제출 시 focus를 맞춰주는 것도 좋았는데 문제는 첫 선택 시 인식을 못했다. useRef기반인 react-hook-form과 싱크 문제가 있는 거라고 생각하고 방향을 틀었다.

다음으로 시도한 것은 chakra uiuseRadio 훅이다. chakra ui의 양식 중에 radio 버튼이 아닌 컴포넌트도 radio 기능을 하게 만들어주는 useRadio 훅이 있는 걸 확인하고 적용해보았다. radio의 값이 변경되는 것은 확인했는데 form에서 값을 감지하지 못했다. 각기 다른 두 라이브러리를 사용해놓고 자동으로 인식하길 바라는 건 욕심이었나 싶어서 다시 방향을 틀었다.

최종적으론 useRadioGrouponChange 속성에 react-hook-formsetValue를 넣어서 강제로 동기화를 시켰다.

지금 정리해보니 이럴거면 useRadio가 굳이 없어도 작동하겠다는 생각이 든다.


Keep

의사 결정

팀의 의사결정을 질질 끌지 않고 일단 해보고 수정하는 방향으로 결정해서 개발 흐름이 막히는 경우가 적었다. 특히 와이어 프레임과 페이지 디자인은 처음 접해보는 입장에서 막막했는데 일단 각자 페이지를 맡아서 만들어보고 다같이 하나씩 보면서 깎아나가는 방식이 인상 깊었다. 나는 혼자 몰래 해오고 이거 어때요? 하는 방식에 익숙한데 이번 처럼 팀이 다 같이 하면서 시간도 적게 쓰려면 어떻게 진행해야 하는지 계속 곰씹어 봐야겠다.

목적 설정

기능을 논의하는 과정에서 과제의 취지에 맞출지 서비스에 맞게 간추릴지 고민이 있었다. 일단 기본 기능을 구현하던 중에 잘 나오면 공식에서 써볼 수 있다는 매니저님의 말에 서비스 쪽으로 확 기울었다. 그래서 채팅, 팔로우, 좋아요 기능은 싹 빼버리고 핵심 기능에 집중하면서 알림은 슬랙을 이용해 강화하는 방향을 선택했다. 사실 과제에 취지에 맞추는 것도 학습자라는 입장에서 큰 의의가 있을 것 같다. 다만 어느 쪽이든 확고하게 목적을 설정하는 게 의욕에 도움이 되는 것 같다.

QA

예전에 했던 팀 프로젝트는 마지막에 부랴부랴 완성하느라 버그는 대충 보이는 것만 후딱 처리하고 넘어가서 피드백에 버그 제보 투성이였다. 이번엔 기능 쳐낸 덕분인지 여유가 좀 있어서 QA 시간을 따로 잡아서 진행했다. 버그가 많을까 싶었는데 많았다.


Problem

저조한 사용률

홍보글을 슬랙에 작성하긴 했지만 아무래도 피드백을 주고 받는 상황이 자율적으로는 발생하기 어려운 것 같다. 적어도 "그냥 구글폼 쓰고말지" 하는 경우는 막을 수 있게 사용 허들을 더 낮출 필요가 있어 보인다.

성능 최적화

고해상도 이미지를 배경, 머쓱이, 장식까지 기본 UI에서 상당히 많이 쓰고있는데 관련 최적화 처리를 안했다. 이미지 스프라이트나 해상도 다양화를 적용해보면 좋을 것 같다.


Try

찐 익명

지금은 API 한계 상 닉네임만 익명으로 보이게 구현했는데 진짜로 익명 댓글 작성 API를 만들어서 회원가입 없이도 피드백은 남길 수 있게 해보고 싶다.

목록

현재 댓글 순위로 보여주고 있는 포스트 목록이 불명확하다는 피드백이 많았다. 전체 목록 페이지를 추가하거나 태그 같은 걸 추가해서 모아서 목록을 볼 수 있게 하는 것도 좋을 것 같다.


개인적으로 Try

질문하기

팀원 분들은 질문을 적극적으로 한 것 같은데 나는 많이 안했다. 초반에 컨셉 잡을 때 이해한 걸 재확인하는 질문은 몇 번 했는데 개발하면서 질문은 전혀 없었다. 위에 개발 이슈를 정리하면서 보니 어려움을 겪지 않았던 것도 아닌데 너무 혼자 몰두하는 것에 익숙한 것 같다. 다음엔 문제있으면 슬랙에라도 질문 던져놓고 파는 식으로 연습을 해야겠다.

내 개발만 하지 않기

중간에 거대 PR이 있었는데 약간 통제에서 벗어나서 자라온 코드를 한 번의 PR 리뷰 만으로 개선할 수 있을까라는 생각을 하면서 페어 프로그래밍이 필요하겠다는 판단이 들었다. 그런데 내가 할 구현이 남아있다는 핑계로 행동에 옮기지는 않았다. 정말론 생소함과 상대 기분에 대한 과한 우려가 원인이었을 것 같다. 얼마 안돼서 팀장님이 바로 Live Share를 하는 걸 보고 반성했다.

profile
프론트 공부 중

0개의 댓글