<아트집> 최종 프로젝트 회고

서론

데브코스 5개월의 여정을 끝맺을 대망의 최종 프로젝트…
팀원들과 함께 아이디어를 논의하던 것이 엊그제였던 것 같은데
벌써 한 달이라는 시간이 지나가고 모든 것이 마무리되었다.
프로젝트를 하면서 무척이나 힘들었지만,
동시에 개발, 협업, 프로젝트 관리 등 많은 것을 배울 수 있던 귀중한 시간이었다.

팀 소개 & 나의 역할

우리는 프론트엔드 4명, 백엔드 4명으로 구성된 팀이었다.
나는 프론트엔드 팀장을 맡았으며,
개발에서는 ‘후기 작성 & 수정 페이지’, ‘마이 페이지’, ‘프로필 수정 페이지’, ‘헤더’를 구현하였고,
그 외 프로젝트 환경 세팅, Axios를 통한 API 연동, SWR의 도입 등을 맡았다.
한편, 팀장이다보니 개발 외적으로도 해야 할 일들이 많았다.
팀장으로서 회의 진행, 일정 관리, 백엔드와의 소통 등의 업무를 주로 담당하였다.

프로젝트 소개

프로젝트의 이름은 Art.zip(아트집)으로,
미술 전시회에 관한 정보를 조회하고 후기를 공유할 수 있는 서비스이다.

전시회 조회 및 검색

후기 작성 및 공유

아래는 프로젝트의 개요를 정리한 것이다.

자세한 것은 github의 README를 참고해주시기 바란다.

https://github.com/prgrms-web-devcourse/Team-BackFro-Project

프로젝트 관리

문서화

문서화를 꼼꼼히 하기 위해 노력하였다.
개발만큼이나 문서의 정리도 중요한 업무이자 역량이라고 생각했기 때문이다.
특히 중간 프로젝트에서는 개발에 쫓겨 문서 정리를 약간 소홀히 한 경향이 있었는데,
이 점을 반성하여 문서화에 신경을 썼다.
노션을 통해 주요 문서들과 회의록을 체계적으로 정리하였다.

애자일 스크럼

한편, 애자일 스크럼 방식을 도입하여
3~4일의 스프린트 단위로 프로젝트를 진행하였다.
또한, Github의 Projects를 통해 일일 스크럼을 진행하였으며,
당일의 안건을 논의하고 작업 현황을 관리하였다.

프로젝트 일정

백엔드와의 협업이 필수이다보니 사전에 논의해야할 것들이 무척 많았으며,
작업을 병렬적으로 진행하면서도, 공통 일정을 조율하며 합을 맞추는 것이 꽤나 어려웠다.
이 점은 느낀점에서 더 후술하도록 하겠다.
프로젝트 기간은 총 26일이었으며, 아래는 전체 일정을 표로 정리한 것이다.

기술 스택

특히 “Typescript, Next.js, Ant design”은
이번 프로젝트에서 처음 도입했던 기술이었고, 여러모로 무척 인상깊었다.
느낀점을 중심으로 회고하겠다.

1. Typescript

타입스크립트를 사용함으로써 협업을 더 원활하게 진행할 수 있었다.
특히 API 명세에 따른 타입들을 정의함으로써 데이터를 더 명확하게 이해할 수 있었고,
타입 추론, 자동 완성 등의 기능을 적극적으로 사용할 수 있었다.
또한, 컴포넌트의 props에도 타입을 정의함으로써 코드를
한층 견고하고 안정적으로 만들 수 있었다.
또 하나 덧붙이고 싶은 것은,
Cannot read properties of undefined 에러가 획기적으로 줄었다는 것이다.
undefined의 속성에 접근하려고 할 때 발생하는 바로 그 에러다!
타입스크립트가 이와 같은 타입 에러를 컴파일 전에 막아주었기 때문에,
디버깅에 소모하는 시간을 크게 줄일 수 있었다. 매우 만족스러웠던 부분이다.

한편, 타입스크립트의 한계도 어렴풋이 느꼈던 것 같다.
Object.keys를 사용 시, 무조건 string[]으로 타입 추론이 난다던가,
생소한 타입인 경우(예를 들어 Ant design의 타입 등),
타입스크립트가 타입 추론을 올바르게 못 하는 경우가 종종 있었다.
그러한 이슈들 때문에 시간이 꽤나 소비되었고, 어쩔 수 없이 타입 단언을 사용해야만 했다.
타입스립트가 완벽하지 않다는 것을 깨달았던 부분이다.
또한, 타입스크립트는 개발자의 타입 실수는 막아주지만,
사용자(유저)의 타입 실수는 막아주지 못한다. (당연한 말일지도 모르겠다)
예를 들어, 사용자가 폼을 입력할 때 입력값이 올바른 타입인지는 막아주지 못한다.
(그 때는 이미 타입스크립트가 아닌, 트랜스파일링된 자바스크립트이기 때문이다)
따라서 별도의 validation을 구현해야만 했다.
이 또한 타입스크립트의 한계를 어렴풋이 느꼈던 부분이다.

2. Next.js

CRA로 개발했던 중간 프로젝트와는 달리,
이번 프로젝트에서는 SSR 프레임워크인 Next.js를 도입하였다.
Next.js를 도입한 까닭은 우선 SEO 때문이다.
우리 사이트는 ‘전시회의 정보를 제공해주는 사이트’이므로,
검색 엔진에 유리하게 노출되는 것이 특히 중요했고, 따라서 SEO가 중요하다고 판단하였다.
한편, 그 외에도 Next.js는 많은 이점들을 안겨주었다.
페이지 기반 라우팅 시스템, Pre-render, SSR, SSG를 통한 성능 향상,
Next/image 컴포넌트를 사용한 이미지 최적화 지원 등이 그것이었다.

한편, Next.js가 익숙하지 않았기 때문에 개발 도중에 시행착오를 꽤 겪었다.
대표적인 것은 인증 문제였다.
초기에는 토큰을 로컬 스토리지에 저장하여 관리하기로 했는데,
Next.js 서버에서 로컬 스토리지에 접근할 수 없으므로 SSR 시 문제가 발생하였다.
결국 로컬 스토리지가 아닌 쿠키에 토큰을 저장하는 것으로 뒤늦게 바꾸어야만 했다.
그 외에도, react-hydration-error가 종종 발생해서 골치를 썩였다.
이것은 Next.js에 의해 pre-rendering된 리액트 트리와
브라우저의 리액트 트리가 불일치해서 발생하는 에러였는데,
생전 처음 보는 에러였기 때문에 개발 도중에 상당히 머리가 아팠던 것 같다.

결국, Next.js의 동작 방식에 대한 근본적인 이해가 부족한 상태에서
도입을 하였기 때문에 겪었던 문제들이라고 생각한다.
어떤 기술의 사용법을 익히는 것도 중요하지만,
그 기술의 동작 방식에 대한 근본적이고 정확한 이해가 선행되어야 함을 깨달았다.

3. Ant Design

Ant Design이라는 UI 라이브러리를 처음 사용해보았다.
결론부터 말하면…장단점이 너무나 뚜렷했던 녀석이었다고 생각한다.
장점은 여러 컴포넌트(modal, spinner, calender 등)를 쉽게 사용할 수 있다는 것이었다.
이 덕분에 빠른 속도로 마크업 작업을 끝낼 수 있었으며,
API의 연동 등 비즈니스 로직을 풀어나가는데 집중할 수 있었다.
또한, Form 컴포넌트의 성능이 매우 좋았기 때문에
useForm을 사용해서 validation을 효율적으로 처리하는데 도움을 받을 수 있었다.
또한, Antd는 디자이너의 부재 문제를 해결해주었다.
우리 팀에는 디자이너가 없기 때문에 디자인이 가장 큰 고민이었는데,
Antd의 예쁘고 깔끔한 디자인 덕분에 이러한 고민을 조금이나마 덜 수 있었다.

단점은, Antd의 디자인을 커스텀하기가 너무 까다로웠다는 점이다.
Antd의 컴포넌트에서 일부 속성(폰트, 컬러 등)만 바꾸려할 때,
적용이 잘 안 되는 경우가 많았다.
또는 간신히 적용이 되었다고 해도, 그 변경점이
기존의 다른 속성들과 충돌을 일으켜 디자인이 이상해지고는 하였다.
우리는 Emotion을 사용했었는데,
어쩌면 Antd와 Emotion의 호환이 안 맞았던 것인지도 모르겠다.
Antd가 아니라 MUI를 사용했다면 어땠을까하는 생각이 들었던 부분이다.
그리고 또한, Antd의 컴포넌트는 고유의 동작 방식을 가지고 있었다.
동작 방식이라 함은 props로 전달하는 속성, 메서드, 그것들의 타입 등을 말한다.
예를 들어, 이미지를 업로드할 수 있는 Upload라는 컴포넌트가 있다.
이미지가 업로드된 후를 처리하려면 onChange에 함수를 넘겨야 한다.
onChange는 매개 변수, 반환값, 그것들의 타입이 다 정해져 있어서
그것을 반드시 준수해야만 했고, 그러한 까다로운 제한 때문에 시간을 꽤 소비해야만 했다.
또한, File 타입을 확장한 UploadFile 등 Antd 고유의 타입들도 많았던 까닭에
타입스크립트를 작업하는 것이 한층 더 까다로웠다.
그것들은 생소한 타입이어서 타입스크립트가 잘 인식을 못하는 경우도 발생했던 것이다.
이러한 점들이 Antd를 사용하면서 아쉬웠던 부분이다.

결론적으로, Antd와 같은 UI 라이브러리의 장단점을 잘 느낄 수 있었다.
내가 결론내린 바는 이렇다.
간단한 것을 구현할 때, 예쁘게는 만들고 싶지만 디자인 실력이 부족할 때,
직접 만들기 번거로운 컴포넌트를 사용하고 싶을 때 UI 라이브러리를 사용하면 좋을 것 같다.
반면에 디자인적으로 커스텀이 많이 필요하거나,
컴포넌트가 제공해주는 것 이상의 심화 기능을 추가하려 한다면 좋지 않다고 생각한다.
그 경우에는 문제가 더 복잡해질 수 있다.
Antd 컴포넌트는 고유의 동작 방식이 정해져 있어, 그것이 커스텀에 큰 제약을 걸기 때문이다.
한편, UI 라이브러리를 제대로 사용하기 위해서는 그것에 대한 사전 공부가 필수임을
잊어서는 안 될 것 같다. 사용법이 쉽다고 간과해서는 안 된다.
공식 문서를 꼼꼼히 읽으면서 확실히 이해를 한 뒤에야,
컴포넌트의 기능을 온전히, 제대로 사용할 수 있을 것이다.

나의 작업

후기 작성 & 수정 페이지

전시회의 후기를 작성 및 수정할 수 있는 페이지 구현

• 다녀온 전시회 검색 기능
  • 검색어 자동 완성 UI
  • 커스텀 훅으로 디바운스 적용
  • 기술 문서: https://gitul0515.github.io/프로젝트리뷰/2022/09/08/아트집.html
• 후기 내용 입력 폼
  • 다녀온 날짜, 제목, 내용, 공개 여부
  • 유효성 검사
• 다수 이미지 파일 업로드 및 삭제

유저 페이지 & 프로필 수정

• 유저의 정보를 조회할 수 있는 페이지 구현
  • 작성한 후기, 좋아요 누른 후기 및 전시회 조회
  • SWR을 사용한 데이터 fetching
  • 페이지네이션
• 프로필 정보를 수정할 수 있는 페이지 구현
  • 프로필 사진, 닉네임, 비밀번호 수정
  • useForm을 사용한 유효성 검사

반응형 헤더

• 로그인 상태, 현재 페이지, 디바이스 환경에 따라 스타일 변화
• useClickAway 훅을 사용하여 Dropdown 구현

최적화

• 버튼 중복 클릭 등 API의 과도한 호출 방지
  • 커스텀 훅으로 디바운스 적용
  • 기술 문서: https://gitul0515.github.io/프로젝트리뷰/2022/09/04/아트집.html
• Next/Image를 활용한 이미지 최적화
  • 이미지 사이즈 경량화, lazy loading, placeholder 등
• SEO
  • 메타 태그 설정 등

프론트엔드 팀장

• 백엔드와의 소통 및 의견 조율을 위한 노력
• 회의 진행, 일정 관리, 발표
• 발표 영상: https://www.youtube.com/watch?v=GRonUVaSoFE&t=9

느낀점

1. 백엔드와의 귀중한 협업 경험

백엔드와 협업하는 귀중한 경험을 할 수 있어서 좋았다.
프론트 팀원들과 협업한 적은 있었지만, 백엔드 팀원들과의 협업은 이번이 처음이었다.
기획부터 시작해서 API 명세에 대한 조율, 개발 단계에서의 소통, 마무리까지
실제 프로젝트 전반의 흐름을 익힐 수 있던 귀중한 경험이었다고 생각한다.
한편, 프론트와 백엔드의 지식 및 관점의 차이로 인해 소통에 다소 어려움이 있었다.
프론트의 ‘전역 상태 관리’ 개념을 백엔드 팀원들이 잘 이해하지 못하거나,
반대로 백엔드에서 데이터를 저장 및 유저의 인증을 관리하는 방식에 대해
프론트 측의 이해가 부족해서 소통의 어려움이 있었다.
그 외에도 API 명세를 일부 수정하는 등, 후반부에도 잦은 회의들이 이어졌다.
어쩔 수 없었다는 생각이 들면서도…
그 때문에 개발에 쏟는 시간을 빼앗기게 되어 많이 아쉬웠던 부분이다.
그로 인해 후반부에도 버그 리포팅과 해결이 미진해서 다소 아쉬웠다.
우리가 초반에 더 명확하게 기획 및 설계를 하고,
여타의 공통 문제들에 대해 상호 의견 일치를 이루었다면
더 좋았을 것이라는 생각이 들어 큰 아쉬움이 남는다.
“튼튼한 기획과 설계가 좋은 개발을 낳는다”는 것을 깨달은 경험이었다.

2. 문서화 & 애자일 스크럼

실제 개발보다는 아니더라도, 그에 버금가게 중요한 것이 ‘문서화’라고 생각한다.
회의를 하면서 의견을 나누고 결론내린 것에 대해
문서로 명확하게 정리하지 않으면, 금방 기억에서 잊혀지고 흐지부지 되어버린다.
중간 프로젝트에서 아쉬웠던 부분이었기에,
이번 최종 프로젝트에서는 문서화를 체계적으로 하기 위해 많은 노력을 기울였다.
노션의 캘린더에 회의록을 매일 정리하고, 주요 문서들을 꼼꼼히 정리하였다.
또한, github의 Discussions를 적극 활용해서 주요 이슈들에 대해 정리하고 토론하였다.
이처럼 문서화를 꼼꼼히 한 덕분에 나중에 찾아보기가 용이했고,
장기적으로는 개발의 편의성을 크게 높여주었다.
이번 프로젝트에서 만족스러웠던 부분 중 하나이다.

한편, 애자일 스크럼 방식을 도입하여 스프린트 단위로 프로젝트를 관리하였다.
스프린트 주기는 3~4일로 두었으며,
스프린트 첫날에는 해당 기간동안 각자 해야할 일을 정했으며,
스프린트 마지막날에는 달성 여부를 점검 및 회고하는 방식으로 진행하였다.
이 덕분에 프로젝트의 전반적인 흐름을 계획하고, 작업 상황을 점검하는 등
프로젝트를 효과적으로 관리할 수 있었다고 생각한다.
실무에서 애자일 스크럼 방식을 많이 사용하는 까닭을 이해할 수 있었고,
몸소 체험해볼 수 있던 귀중한 경험이었다고 생가한다.

3. 향후 리팩토링

완벽한 프로젝트와 코드는 이 세상에 없다고 생각한다.
우리의 프로젝트 역시 마찬가지다.
프로젝트 기간이 끝났다고 해서 손을 놓아버리는 것이 아니라,
꾸준한 리팩토링을 통해서 개선해나가는 것이 필요한 것이다.
당장 해결이 시급한 것은 ‘사이트의 속도가 느리다’는 문제점이다.
추론하건대, 이것은 사이트에서 많은 양의 이미지 파일을 사용하고 있으며,
이 때문에 로딩 속도가 오래걸리기 때문이라고 생각한다.
next/image를 사용하여 이미지 용량을 경량화하는 작업을 통해 개선해야만 한다.
그 외에도 컴포넌트를 더 잘개 쪼개고 추상화하기, validation 강화하기,
반응형 시 레이아웃 개선하기, 테스트 코드의 추가 등이 필요할 것 같다.
이와 같은 리팩토링을 통해 더 많은 것을 익히고 배울 수 있을 것이라고 생각한다.