230523 Project: SMASH 회고

✍️✍️✍️ 위 글은 작성자의 지식습득에 따라 추후 퇴고 될 수 있음을 알려드립니다(피드백 환영).
✍️✍️✍️ 위 글은 작성자의 개인적인 경험이니 가볍게 읽어주시길 바랍니다.

---

프로젝트 관련글을 두달만에 작성하게 되었다.
사실 3월과 4월에 리액트 관련 토이플젝을 진행하긴 했었지만, 당시 나의 리액트 이해도가 글을 쓰고있는 현재 시점보다 좋지 못했다. 때문에 3월에 진행했던 개인 토이플젝의 완성도와 4월에 진행했던 팀 토이프로젝트에서의 기여도가 높지 못해 회고글을 작성하기가 민망한 관계로, 우선 최적화를 진행해보고 난 후에 후기 정도의 글로 올해 안에 작성해 보는 것이 목표로 하고 보름간의 프로젝트에 대한 글을 시작 해 보겠다.

---

TeamSMASH Pages

0. 시작

5월엔 미니 프로젝트를 진행하게 되었는데, 근태관리 서비스를 만들어보는 프로젝트였다.
프론트엔드와 백엔드가 처음으로 협업하는 프로젝트였는데, 처음으로 진행하는거라 궁금하기도하고 걱정되기도하고 기대되기도 했던 프로젝트였다.

 

1. 서비스 기획

우선 어떤 서비스를 만들까? 우리서비스의 이름은 무엇으로 할까?부터 서비스 기획이 시작되었다. 원래 아이디어라는게 실없는 소리 하면서 진행하다보면 의외로 괜찮은게 나오기도하고 심지어 픽스가 되기도 한다.

첫 FE회의에서 어김없이 잡담 나누면서 중간중간 서비스에 대한 고민 이야기도하면서 회의가 약간 실없이 흘러가고있었다. 잡담을 하기도 했고 회의가 길어지고 있어서 그랬는지 혼자 딴생각을 하게 됐다. 그러던도중,  "연차 갈겨?, 연차 조져? 아니야아니야 단어가 너무 강해, 연차 때려?" 이러면서 머릿속은 팀원의 이야기는 먼나라 이야기가 되었고 혼자 이런 의식의 흐름대로 생각하다가 "연차 때려!"에 꽂혀서 SMASH로 서비스 명을하면 어떨까? 하는 결론에 도달하게 되었다.
이런 생각을 끝내자마자 팀원들한테 회의의 흐름이 어땠는지는 상관 하지않고 "저 여러분... 혹시 스매시 어떠세요? 연차 때려! 해서 기억되기도 좋을 것같고 기획, 브랜딩하기 편한 서비스 명 같아서요...!!" 라고 조심스레 의견을 냈다.
팀원분들은 듣고 바로 좋다고 해주셨고 TeamSMASH로 결정하게 되었다.

 

2. 디자인 및 UI/UX고려

팀원의 구성엔 기획자와 디자이너가 없는 상태였기 때문에 UI/UX와 개발단의 API문서도 고려해야하는 상황이었다.
하지만 너무나 다행이게도 팀장님께서 디자이너 출신이셨기 때문에 완성도 높은 UI와 UX가 나오게 되었다. 몇가지 사항들만 FE팀원들과 수정한 후 BE분들에게 디자인 공유 + 전체 회의를 진행하며 API구성을 위한 UI/UX를 조율하는 시간을 가지게 되었다. 원래 1차 UI에서는 회원가입을 진행 할 때, 프로필이미지도 추가할 수 있었는데, 이미지를 추가하는 API를 분리하면 좋겠다는 BE의 피드백을 수용 해 사이드 바에 나오는 기본정보에서 프로필 이미지를 수정하는 방향으로 바꾸게 되었다.

 

3. 포지션 정하기와 작업진행

포지션 정하기는 어렵지 않게 진행되었다. UI가 잘 나왔기 때문에 누가 얼마나 감당할 수 있을 것 같은지를 공유하니 자연스럽게 업무가 분담되었다. 나는 지난 토이프로젝트인 'SNS 만들어보기'에서 '글쓰기와 이미지 첨부'를 맡았었는데, 그때와 비슷한 포지션인 연차, 반차 당직 신청하기 페이지를 맡게 되었다.

작업을 진행하면서 위기가 있을 때 마다 느꼈던건, "질문하는 것이 참 중요하구나"였다.
아니 나는 내가 뭐라고 자꾸 팀원에게 질문하는 것을 주저할까? 우선 작업을 하다가 막힐 때마다 물어보기엔 '조그만 더 하면 스스로 해결 할 수 있을 것 같은 데' 라는 욕심 때문에 질문하는 것을 미루기도하고 주저하게 되는 것 같다.

때문에 나의 이런 부분을 팀장님이 캐치를 잘 해주셔서 협의를 했고, 그 뒤로는 편안히 물어보게 된 것 같다. 다음 플젝에서는 모든 공유를 빠르게 확실히 그리고 진행상황은 얼마나 되는지 상세히 전달해서 팀의 목표를 이룰 수 있도록 전달하는 습관을 만들어야 겠다.

4. My Issues

내가 작업 중 사용하는 API는 '승인요청'API인데, 승인을 요청하는 모든 내용(연차, 반차, 당직)을 '승인요청' API하나로 요청을 보내 각 요청의 데이터 타입을 구분해 로직을 작성하는 방향으로 작업을 했어야했다.
연결하는 로직을 짤 때 까지는 별이슈가 없었지만, 요청을 할 때, 브라우저 콘솔에서 페이로드의 타입이 계속 연차(DAYOFF)로만 출력이 되었다. 제대로 이유를 알지 못하기도 했고 계속 작업하다보니 내 눈에는 코드의 헛점이 보이지 않는 현상이 발생해서 팀원분들에게 도움을 요청했다.

캘린더와 연차 데이터를 넣어줄 빨간 컨테이너가 있는 연차 신청하기 페이지(dayOffPage.tsx)

우선 이미지를 보면 왼쪽에 고정된 메뉴바가 있고 메뉴마다 페이지가 랜더링 되는 방식으로 구현을 했다.
때문에 연차신청하기(dayOffPage)가 상위 컴포넌트이고, 자식컴포넌트는, 달력(miniCalendar)과 빨간컨테이너(shiftContainer)이다.
tui-calendar 라이브러리를 활용 해 만든 미니달력(miniCalendar)에서 날짜를 드래깅 해 가져오는 데이터를 "시작날짜", "종료날짜"라고 만들어진 인풋에 보여지는 로직으로 작업을 진행했었다.
여기서 페이로드에 연차가 들어가는지만 보려고 고정해뒀던 연차 데이터 타입을 dayOffPage에서 지웠어야 했는데, 깜빡하고 승인요청버튼을 무지하게 눌러댔었다... 허허

다행히도 내 눈에 안보이던 수정할 점을 팀원분께서 발견을 해주셔서 dayOffPage에서 상태를 지우고, shiftContainer에서 연차, 반차, 당직을 타입 정의를 하고 당직페이지에서는 당직의 내용이, 연차, 반차 토글버튼을 두르면 연차반차의 데이터 값이 출력되는 것 까지 진행되어 해결을 할 수 있었고, 이제 데이터를 보내는 일만 남았었다.

하지만 API문서에 BE분이 정의 해놓은 type: DAYOFF(연차), HALFOFF(반차), SHIFT(당직)의 형태로 작성하지 않고 카멜케이스로 넣어두곤 계속해서 왜 타입이 구분이 안되고 연차 타입의 데이터만 전송될까 하며 고민했었다. 실수를 찾은 다음 수정을 하고 배포를 진행한 후에 당직 요청하는 로직에서 SHIFT로 들어가야하는 것을 NIGHTSHIFT로 정의하고 할당해서 또 DAYOFF로 페이로드가 가버리는 작은 이슈를 또 발견했다. 배포를 한 이후여서 깔끔하게 병합하지 못한 점이 너무 아쉽지만, 요구된 기술구현에 실수를 남겨 놓을 순 없기 때문에 후다닥 API 문서에 정의해논 타입의 형태로 수정하고 검증해보니 그제서야 당직을 신청했을 때 연차가 아닌 당직(SHIFT)으로 페이로드에 들어가는 걸 확인 할 수 있었다.

---

연차를 승인을 할 때, 프로필 이미지를 불러오는 로직을 깜빡하고 짜놓질 않아서 이미지가 없는 상태인 이슈, 프로필이 없을 때, 그리고 프로필을 가지고 있을 때 보여져야하는 상황의 로직 등 끝도 없는 잔 이슈들이나 또는 발견하지 못하는 이슈들 때문에 곤욕을 치를 때도 있어 일정 관리를 제대로 하지 못해 밤을 새기도 했고, 기한을 넘기고 머징을 할 때도 있었지만, 그래도 팀원분들의 도움덕분에 무사히 그리고 간신히 1인분을 해낼 수 있었다.
팀원의 중요성과 질문의 중요성 그리고 타이밍의 중요성을 또한번 느끼게 됐다.

다음 플젝에서는 새로운 스타일링인 tail-wind 그리고 대망의 next.js를... 도전해 본다.
토이플젝을 할 당시에도 물론 next.js를 사용하긴 했었지만 라우팅 용도 그 이상도 사용하지 않았었기 때문에 걱정이 된다.
게다가 13버전으로 진행을 할 것이기 때문에 잘 몰라서 오는 두려움이 더 크다..!! 그래도 최선을 다해서 공부해서 작업시간이 지체 되지 않도록 노력해야지...!! 이번엔 1.1인분 할 수 있기를...!! 밤을 조금만 샐 수 있기를..!! 운동을 꾸준히 할 수 있기를..!! 제발:((

아래는 약 보름 동안 만든 TeamSMASH의 리드미를 첨부했다. 궁금하신 분들은 살짝 구경해보시길!
TeamSMASH README.md보러가기

GitHub - smash-teams/smash-teams-FE