2학기 공통 프로젝트를 시작할 때만 해도 길어 보였던 7주라는 시간이,
어느새 다 끝나고 벌써 다음 프로젝트를 준비하고 있다.
프로젝트는 예비부부를 위한 스마트 웨딩플래너 서비스였고,
우수 프로젝트에 선정되어 발표회에도 참가하게 되었다.
개발을 SSAFY에서 처음 시작했으니,
공통 프로젝트는 당연하게도 관통에 이어 내 두 번째 프로젝트였으며, 6명이 FE, BE, 인프라를 나눠서 담당하는 첫 대규모(?) 프로젝트였다고 할 수 있겠다.
전공자와 함께하게 되는 첫 번째 프로젝트였기에, (경험자 + 전공자)프론트 엔드와 팀을 해서 노하우와 스킬을 훔치겠다는 마음가짐으로 팀 구성을 시작했다.
하지만 SSAFY 특성상 프론트 엔드 개발을 희망하는 사람이 거의 없었기에, 경험자는 고사하고 전공자 프론트 엔드를 찾기도 힘들었다.
(구했는데 취직해서 나갔음 ㅜㅜ)
그래도 같이 프론트 엔드를 맡은 친구가 매사에 엄청 열심히 하고
정말 많은 부분에서 내가 생각도 못한 인사이트를 많이 제공해 줘서, 딱히 전공자 프론트 엔드가 필요하지 않았던 것 같다.
0. 프로젝트 구조
우리는 일정 관리가 핵심 주제였기에, 일정 관리의 접근성을 위해서는 웹보다 앱으로 접근해야 한다고 생각했다.
WebApp을 기반으로, 여유가 주어진다면 PWA를 통해 어플로 발행하고 푸시 알림까지 구현하는 것을 목표로 프로젝트를 시작했다.
1. 기술 스택
1.0 React
공통 프로젝트만을 위해 방학 때부터 쉬지 않고 공부해 온 리액트만큼은 절대 포기할 수 없었고,
당연히 프론트 엔드 팀원을 구할 때 리액트를 사용할 사람을 모집했다.
1.1 TypeScript
타입 스크립트를 사용해보고 싶었지만, 같은 프론트 엔드 친구와의 상의 끝에, 6명(내 기준 최고 규모)으로 구성된 프로젝트에서 위험을 감수하기보다는
React를 확실하게 익히고 가자는 마인드로 타입 스크립트는 사용하지 않기로 했다.
1.2 NextJs
프로젝트 기획 당시에는 사용해 보지도, 공부해보지도 않은 Next를 적용하는 게 위험 부담만 커지는 것이 아닌가 했다.
실제로 많은 문서들이 React를 Next로 마이그레이션 하는 것은 방법도 많이 나와있고 가능하다고 했지만, 반대의 경우는 거의 불가능하다고 말하고 있었다.
우리 프로젝트가 SSR이 꼭 필요한 서비스인지도 의문이 들었고,
타입 스크립트를 배제한 것과 같은 이유로 리액트 자체에 더 집중하기 위해 Next도 사용하지 않기로 했다.
1.3 Redux
방학 때, 리액트의 전역 상태관리 툴로 Redux Toolkit만을 공부해 왔다. 아는 게 리덕스 밖에 없었고, 리덕스가 당연히 정석이라고 생각했기 때문이다.
하지만 기획 단계에서 리덕스를 사용해보지 않은 프론트 엔드 팀원에게, 나조차 제대로 이해하지 못한 리덕스를 가르쳐주면서 하는 것은 독이라고 생각
더 가벼운 상태관리 툴을 찾다가 Zustand를 발견하게 되었고, 실습 코치님께 여쭤본 결과 6명 정도의 프로젝트에서는 훨씬 가벼운 Zustand를 사용하는 것이 좋을 것이라고 추천받아 Redux도 사용하지 않게 되었다.
1.4 Zustand
Redux 대신 사용하게 된 전역 상태관리 툴.
React 자체 내장기능이라고 생각할 정도로 비슷한 형식을 가지고 있다.(커스텀 Hook이라고 생각하면 쉽다)
Redux와 비교했을 때, 코드가 정말 말도 안 되게 짧다.(보일러 플레이트가 없다시피 함)
배우기 정말 간단했지만, 뭔가 제대로 정리된 한글 문서가 없어서 내가 찾아서 공부해야 했다.
1.5 Tanstack-Query (React-Query)
기획 당시에만 해도 사용할 생각이 없었는데, 이름 들어본 김에 공부해 봤다가 꼭 넣고 싶어서 넣은 기술.
가끔 구글링 하다 보면 리액트 쿼리와, 리덕스 혹은 주스탠드와 같은 전역 상태관리 툴을 비교하는 글들이 있는데
내가 지금까지 공부하고 사용해 본 바에 의하면, 둘은 비교하기 어렵다고 생각한다..?
아예 다른 툴이라고 생각하는데, 그 이유는
1. 리액트 쿼리는 axios와 같은 api 통신을 도와주는 툴
2. 캐싱 기능이 있어서 상태관리가 아예 불가능 한 건 아닌 것 같긴 한데,,, 이걸 상태관리 툴로 봐야 하나 싶음?
둘을 그냥 같이 쓰면 서로 장점만 극대화되는 것 같으니까, 역할을 구분해서 필요한 곳에 잘 사용하자.
사용하면서 너무 편했지만, 사실 이런 것들은 바닐라 JS로 직접 만들어보거나 뜯어봐야 하지 않을까 하는 생각이 들었다...
2. 어려웠던 점
기본적으로 우리 반의 컨설턴트님께서는 기본적인 완성도를 기반으로 평가하신다고 말씀하셨었다.
오동작은 하지 않는지, 동작 과정에서 문제가 생기지는 않는지 등등, 꼼꼼하신 QA를 통해 어플의 오류를 많이 찾아주셨고,
그 과정에서 정말 상상하지도 못했던 오류들을 마주하고 수정해 나가면서 개발 경력이 없던 나에게는 정말 많은 도움이 되었다.
2.1 Validation (유효성 검사)
글자 수 제한, 비밀번호 유효성 검사 등은 몇몇 컴포넌트에 적용을 못 시킨 것이어서 놓친 걸 잡아주셨다 정도였지만,
채팅방에서 파일의 확장자를 바꿔서 올린다거나, 크기가 0인 파일을 업로드한다거나 등의 문제는 생각조차 해보지 못한 문제들이었다.
모두 고쳐냈지만, 정말 짚어주시지 않았다면 나는 생각도 못했을 것 같다..
2.2 채팅방 (웹소켓)
처음 연결해보는 웹소켓, 그것도 내가 처음부터 작성한 코드도 아니고 먼저 작업한 코드를 이어받아서 더 어려웠다.
프런트 엔드가 2명으로 상대적으로 부족한 상황이라, AI를 맡고 있던 친구가 어느 정도 코드를 작성하고 넘겨줬는데
모든 상태 및 변수들이 로컬로만 정의되어 있어서, 우선 전역으로 빼고 시작을 했다.
(지금 생각해보면 다른 곳에서 사용도 안 하는데 전부 로컬 또는 Props 정도로만 처리해 줬어도 됐을 것 같기도 하고)
이상하게 웹소켓이 연결되고 5초 정도가 지나면 연결이 해제되길래, HeartBeat가 안 보내지고 있는 건가? 생각을 했다. 근데 웹소켓을 구현해 봤던 백엔드 친구가, 우리가 사용하고 있는 SockJS를 사용하면 자동으로 하트비트를 보내준다고 하네?
개발자 도구 네트워크 탭을 열어보니, connect 요청을 계속보내고 있었다. 5초 뒤면 우리가 제한해 놓은 3000개가 모두 꽉 차서 첫 연결이 끊어졌던 것임...
코드를 확인해보니 connect 요청을 컴포넌트가 마운트 됐을 처음만 보내는 것이 아니고 계속해서 보내고 있는 것을 발견했다. 수정 이후 그런 일은 발생하지 않았고, 혹시 몰라 disconnect도 다시 한번 수정했다.
2.3 디자인 패턴?
기획 단계에서 우리는 아토믹 디자인 패턴을 사용하자고 얘기를 하고 프로젝트를 시작했다. 하지만 진행하면서, 이건 atom인가? 이건 molecule인가? 하는 고민을 계속해서 반복하게 되었고, 결국 아토믹 패턴을 사용하기로 한 근본적인 이유마저 무너지게 되었다.
(이게 card야 tab이야,, 이건 atom이야 molecule이야 뭐야,,)
나름 figma 작업을 열심히 해놓고 시작했다고 생각했는데, (다음 프로젝트는 아마 FSD 패턴을 사용할 것 같지만)다시 아토믹 패턴을 사용하게 된다면 너ㅓㅓㅓ무 모든 것을 재사용하려고 하지 않을 것 같다. 너무 재사용성을 신경 쓰다 보니 오히려 더 복잡해진 느낌이 있었음..
3. 후기
진짜 9 to 9 그 이상으로 열심히했다. 프론트 엔드가 2명이기도 했고(물론 백엔드 팀원들이 도와준다고 했음),
내 기준 최대 규모의 프로젝트였기에 의욕이 넘쳤던 것도 있고,,,
결국 프론트 엔드는 둘이서 전부 구현해 내서 너무 뿌듯했다.
백엔드 친구들이 프론트가 사용하기 쉽도록 API를 많이 만들어서 구분해 주고, 고도화해 줬기 때문에 가능한 일이었지만,,
끝나고 회식하는데 발표회 진출팀으로 선발되었다고해서 모두 기뻐하는 모습이 제일 기억에 남는다.
팀원들 다 너무 고생했는데, 결과마저 좋아서 너무 행복한 기억으로 남을 것 같음..
(솔직히, 다 너무 좋은 사람들이고 && 많이 친해졌고 && 프로젝트로 많이 배워서, 수상은 하면 좋고 아님 말고였는데 역시 뭔가 되면 기분이 좋다)
'✏️ Personal > SSAFY' 카테고리의 다른 글
| [SSAFY] 삼성청년소프트웨어 아카데미 12기 1학기 회고 (2) | 2024.12.03 |
|---|