코드스테이츠 프론트엔드 부트캠프 4개월 간의 교육과정 이후 2주간의 프리 프로젝트를 함께 진행한 프론트엔드 2명, 백엔드 2명 총 4명의 팀원들과 협업하여 파이널(메인) 프로젝트를 진행했고 프론트엔드로 참여했다.
1. Intro
프로젝트 명: 나만의 작은 설렘
프로젝트 형태: 수강생 프로젝트
팀원: 김형섭(팀장), 김주현, 한성욱, 이슬
프로젝트 기간: 2022.09.08 - 2022.10.12. (5주)
배포 링크 : https://www.seollem.link/
깃헙 링크: https://github.com/codestates-seb/seb39_main_035
프로젝트 일지: 링크
2. 프로젝트 기획(목적)
이번 프로젝트는 기획 단계부터 경험해 본 첫 프로젝트였다. 초반 회의에서 나온 여러 아이디어 중 유저가 남긴 독서 기록을 책 형태로 다시 볼 수 있는 기능이 가장 많은 표를 얻었고, 등록한 책들의 진행 상황을 입력하면 이를 시각화해서 독서에 대한 동기부여를 제공할 수 있는 서비스를 기획하게 됐다. 로그인한 유저의 개인적인 독서 기록이라는 점과 우리 팀이 구입한 도메인 seollem(설렘!)을 결합해서 프로젝트 명을 ‘나만의 작은 설렘’으로 결정했다.
3. 프로젝트에 사용한 기술 스택(프론트엔드)
TypeScript, React, Redux-toolkit, redux-persist,styled components, axios, react-router
TypeScript
- 멘토님이 적극 추천하셨고, 프론트 팀원이신 성욱님도 도입 해보자고 하셔서 만나게 된 타입스크립트! 프로젝트 기획 후 추석 명절에 코딩앙마 강의와 공식사이트의 핸드북으로 기본만 후다닥 익히고 프로젝트를 시작했다. 프로젝트 초반에는 수많은 에러를 만났고… 오히려 개발 속도가 느려지는 느낌이었다. 하지만 프로젝트 중반 부터는, 팀원이 작성한 컴포넌트를 사용하는 경우에 타입스크립트에서 제공하는 코드 자동완성이나 에러 피드백이 굉장이 유용했다. 코드를 이해하는데 수월해지기때문에 협업하는 상황에서는 장점이 많다는 거구나!를 몸으로 느낄 수 있었다. 이번 프로젝트에서는 아주 기초적인 수준에서만 적용했지만 더 공부해서 제대로 활용해보고 싶다.
Redux-toolkit
- 프리 프로젝트에서도 사용한 리덕스 툴킷을 사용했다. redux를 사용할때 작성해야하는 보일러플레이트 코드를 줄일 수 있었고, redux-devtool등 라이브러리들이 내장되어 있어서 개발 환경에서 편리하게 사용할 수 있었다. redux-persist도 함께 사용해서 store를 세션 스토리지에 저장해놓고 새로고침 시에도 상태가 유지되도록 했다. 어려웠던 점은 typescript와 함께 사용하면서 type 정의하는 부분이었는데, 공식문서를 통해서 해결했다. 프리와 메인 두번의 프로젝트에서 사용하면서 프리 프로젝트 때 사용했던 방식이 왜 잘못되었는지(잘못된 사용보다는 왜 내 의도대로 동작하게 사용하지 못했는지?)를 알게돼서 많이 배울 수 있었던 스택이었다.
4. KPT(keep problem Try) 회고
지난번 프리프로젝트 회고 try
- 문서화(깃헙 협업기능 활용하기)를 더 신경써서 해보자(이슈 세분화해서 작성, 이슈 번호로 커밋 등등) ✅
- 설계 부분에 더 많은 시간을 써서 효율적으로 개발에 돌입하기 ✅ ✨
- 상태관리 더 공부하기 (redux-toolkit 활용도 높이기) ✅ ✨
- 프로젝트 구조 관리 프로젝트 후반부까지 포기하지 말기
- 재사용되는 부분, ui 통일되어야 하는 부분은 컴포넌트로 더 쪼개서 만들기✨
- 개발 일정을 계획할때 후반부 수정하는 부분을 넉넉히 잡아두기. 클라이언트배포도 개발단계에서 지속적으로 해서 막판에 몰아서 배포 오류를 파악해야하는 상황을 피하자! ✅ ✨👍 잘한 점
프리프로젝트 팀 회고 및 설계 과정의 오버 커뮤니케이션
프리프로젝트의 배포 실패(정확히는 통신 실패)를 경험하고, 메인 프로젝트만큼은 꼭 기능을 완성해서 배포하자고 다짐했던 팀 회고부터가 우리 메인 프로젝트의 시작점었던 것 같다. 회고 과정에서 이야기 했던 1. 설계 부분에 더 많은 시간을 써서 최대한 구체적으로 결정하고 효율적으로 개발에 돌입하기, 2. 클라이언트 배포도 최대한 빨리 진행하기는 프로젝트 초반부터 진행과정 내내 팀원들이 염두해두고 있는 부분이었고, 그 덕분에 프로젝트를 완성시킬 수 있었다고 생각한다. 기획 단계에서 나왔던 아이디어들 가운데 현재 팀의 역량으로 구현 가능한가를 고려해서 기획을 결정한 것도 좋은 선택이었다. 화면정의서를 작성하는 부분에서는 해당 화면에서 필요한 데이터를 정의하면서 api도 함께 설계했는데, open api 선택부터 프로젝트에서 핵심적인 부분들을 대부분 결정할 수 있었다. 오버 커뮤니케이션으로 단단한 설계를 한 덕분에 기능 개발 기간에 큰 이슈가 없었다고 생각한다.
프로젝트 초반 1차 배포를 진행하면서 CORS 해결
프로젝트 기능 구현 2주차, 클라이언트에서 알라딘 open api를 직접 호출해서 페이지를 구현했다. (요청횟수 등의 문제로 서버에서 알라딘 api를 호출하는 걸로 설계했지만 mock 데이터 느낌으로 이용했다. 개발 환경에서는 http-proxy-middleware 라이브러리를 이용해서 프록시 설정으로 cors 문제를 피할 수 있었다.) 그러던 중 계획한 aws s3 클라이언트 1차 배포를 진행하면서 cors 에러를 만나게 됐다. 멘토님께 에러 상황을 공유하며 질문드리니까 서버 response로 access-control-allow-header 값이 들어오지 않는다고 키워드를 던져주셨고, 프리 프로젝트에서도 알라딘 api와 마찬가지로 서버에서 엔드포인트가 다른 요청을 허용해주는 처리를 하지 않았다는 걸 알게됐다.(한 줄 요약하면 1차 배포를 하면서 프리 프로젝트 때의 통신 실패 이유도 알게된 것!) 백엔드 쪽에서 요청을 허용해주는 cors filter 적용해서 배포하면서 서버 통신 문제를 해결하게 됐다. (이것도 한번에 후루룩 해결되진 않았지만… 구체적인 내용은 프로젝트 일지에 정리되어 있다.)
프로젝트 전반에 사용되는 레이아웃, ui 컴포넌트 재사용
프리 프로젝트 이후 가장 반성했던 부분이 컴포넌트로 묶어서 재사용성을 높일 수 있는 부분도 그냥 코드를 복붙해서 페이지에서 활용되는 부분이었다. 당연히 개발할때 효율도 낮았고 코드도 지저분했다. 이번에는 꼭 컴포넌트 쪼개기에 신경쓰자고 다짐했고 이 부분은 어느정도 지켜졌다. 서버 api가 배포되기 전에 화면설계를 보면서 반복해서 사용될 수 있는 부분을 파악했고 pageLayout, Title, Button, Modal, Rating 컴포넌트를 만들어서 프로젝트 곳곳에서 요긴하게 사용했다.
문서화
프로젝트 기간 내내 일지를 작성했다. 그냥 그날 할일 정리하고 어려움 부딪혔던 부분 캡쳐, 시도해본 해결 방법, 참고한 블로그 링크 등을 정리했다. 다시 읽어보니 문장으로 정리하지 못한 날도 많고 내용이랄게 없는 날도 많다. 그래도 덕분에 에러가 나면 일단 캡쳐를 하고 보는 습관이 생겨서 팀원들에게 에러 상황을 공유하는데도 큰 도움이 됐다.
🥲 아쉬운 점
깃헙으로 프로젝트 관리
프로젝트 일지 작성이나, 프론트 아침 조회 등등 노션 워크스페이스에 프로젝트 전반에 대한 문서화는 꼼꼼히 했지만, 깃헙에 이슈를 세분화해서 작성하고 관련된 이슈 커밋을 날리고 이런 부분은 많이 소홀했다. 깃헙에 프로젝트 관리하는 부분은 제대로 지켜지지 않았다. 은연 중에 우리 팀은 프로젝트 진행에 대한 커뮤니케이션이 잘 되고 있다고 핑계를 대면서 이슈 작성에 소홀했다.. 다른 팀 깃헙을 구경해보니 이슈나 마일스톤으로 깔끔하게 프로젝트 관리를 한 과정이 보여서 좋아보였다. 이번 프로젝트에 적극적으로 사용하면서 깃헙 프로젝트 관리 툴에 익숙해질 수 있었는데 아쉽다. 다음 번에는 꼭 잘 작성하는 걸로!
프로젝트 구조 관리
지난번에도 반성했던 부분이었지만 엄청 개선되지는 못했다. 컴포넌트 폴더에 페이지 전반에서 사용되는 컴포넌트와 특정 페이지에서 사용되는 컴포넌트들이 혼재되어 있는 상태고 역시나 프로젝트 후반부에 가서는 혼란을 야기했다. 프로젝트 기간이 끝나고 가장 신경쓰였던 부분이어서 여러 레퍼런스를 찾아보았고, 리팩토링 과정의 1순위 과제가 됐다..!
서버 API 나오기 전에 효율적으로 개발하기
서버 api가 나오기 전에 개발한 부분에서 수정해야할 부분이 꽤나 있었다는 점이 아쉽다. 물론 이유는 더미데이터나 mock service worker 등등을 빠르게 적용하지 않고 알라딘 api로 직접 호출해서 페이지를 구현했기 때문이다. 이번에는 백엔드 기능 구현이 엄청 빠르게 돼서 한 이틀 정도의 삽질이기는 하지만, 서버 api랑 딱맞는 데이터로 구현하고 있었으면 시간 낭비가 적었을텐데 하는 아쉬움이 남는다.
나의 부족한 실력🥲
내가 구현을 맡았던 부분에서는 이미지 슬라이더, 캘린더, 에디터 등등 라이브러리를 많이 사용했다. 우리 프로젝트에 딱맞게 커스텀하는게 어려웠고 일정이 많이 소요되었다. 처음부터 개발하지 않아도 되는 편리함 때문에 라이브러리를 사용하는 것이지만, 기본적인 구현 원리에 대한 이해가 부족했기 때문에 라이브러리를 가져와서 적용시키는데도 어려움이 많았다고 생각한다. 라이브러리로 구현했던 부분을 처음부터 만들어보는 시간을 가져볼 계획이다. 프로젝트 기간이 막판에 백엔드 주현님이 리프레시 토큰 발행 부분을 구현하셨는데 다른 에러 처리나 발표 준비에 밀려서 이 부분을 프론트에서 구현해내지 못했다. 이 부분까지 마무리해서 아름답게 버젼1을 마무리하고 싶다.
💪 Try
프로젝트 이후, 개인적으로 아쉬웠던 부분을 리팩토링하려고 한다. 일단, 프로젝트 폴더 구조 정리, css 단위 통일, 리프레시 토큰 기능 추가를 해보려고 한다. 팀 전체적으로 서비스를 유지하면서 기능을 더 추가해보자는 이야기가 나와서 그것도 진행하게 될 것 같다. 아직 본격적으로 회의를 진행하지는 않았지만 기획 때 나왔던 아이디어들을(다 읽은 책에 대해서 축하팝업 띄우는 기능과 작성한 메모를 공유하는 기능) 추가해보고 싶다.
5. Outro
잡세션을 진행하면서 밀려오는 현타로 계획했던 것보다 늦게 메인프로젝트 회고를 작성하게됐다. 프로젝트 기간동안 체력 관리에 소홀한 결과로 프로젝트가 끝나고 몸살이 세게 나버렸다. 더 늦으면 메인 프로젝트 경험이 다 잊혀질 것 같아서 만사 제쳐두고 회고를 적는다.
팀 프로젝트를 진행하면서 얻은 가장 큰 수확은 내가 뭘 잘 모르는지(css, react hooks, 네트워크에 대한 이해)에 대해서 좀 더 명확히 알게됐다는 점이다. 부트캠프 4개월 차에 과제도 힘들고 내 이해 수준을 수업진도에 맞추는게 정말 힘들었다. 지금 생각해보면 내가 할 수 있을까라는 의심에 잡아먹힌 시점이었고 공부도 제일 재미없었던 것 같다. 그 당시 나의 고민이나 힘듦이 너무 막연하고 총체적이었는데 이제는 ‘이부분을 리팩토링 해봐야지, 이걸 더 공부해봐야지 하는식으로’ 좀 더 구체적인 형태로 바뀐 것 같다.
최악의 멘탈 상태에서 그래도 끝까지는 해보자라고 마음을 다잡고 시작한 프로젝트였는데 생각보다 과정이 즐거웠다. 설계한대로 기능을 구현하는 것도, 오류가 나서 안되던걸 되게 만드는 것도 너무너무 재미있었다. 무엇보다도 프리 프로젝트에서 해결하지 못해서 찝찝했던 통신 문제를 해결하고 프로젝트를 완성할 수 있어서 좋았다. (집착적인? 내 성격이 프로젝트 진행하면서는 장점처럼 느껴졌다ㅎㅎ)
마지막으로 이 모든걸 함께한 분들께 감사를 전하고 싶다. 서로서로 배려하면서 적극적으로 소통하고 각자 자기 역할을 책임감있게 구현한 덕분에 프로젝트를 마무리할 수 있었다고 생각한다. 친절한 팀원들과 sos 칠때마다 항상 적극적으로 답변해주셨던 멋진 멘토님까지🫶 너무너무 수고하셨고 정말 감사했다! 모두모두 항상 건강하시고 하시는일 다 잘되시길!
