[프로젝트] Pre-Project 마무리 회고

🟢 pre-project 목표

✅ 클론 코딩 : Stack Over Flow

✅ 처음보는 팀원들과의 협업 및 의사소통

✅ 프론트엔드 개발자로서 백엔드 개발자들과의 첫 협업

🟢 달성률?

• 처음에 작성했던 사용자 요구사항 정의서에서 80퍼센트 정도를 완료했다.

• 사용자 요구사항 정의서에 적지는 않았지만 comment 작성 기능도 추가되었다.

• 배포를 완료했다 : 배포 링크 (배포 링크로 들어가면 Read ME 게시글과 검색 방법 게시글 있음!)

• 백엔드 팀이 고생해주신 : API DOCS

🟢 Gain

🕊 tailwind 라이브러리 사용 경험

• tailwind 라이브러리를 처음으로 사용해보면서 부족함을 느껴서 공부하면서 블로깅도 해보았다.
• 스터디원들과 사이드 프로젝트를 하면서 styled component를 사용했을 때 단점들과 tailwind를 사용했을 때 단점이 그다지 다르지 않았다. 어쨌든 Js 코드와 CSS 코드를 한 곳에다 몰아서 쓰게 되면 코드가 지저분해진다.
• 그럼에도 불구하고 클래스명을 지정하고 CSS 파일에서 일일히 클래스명을 검색해서 수정하지 않아도 된다는 점은 좋았다.

🚨 프로젝트 중 만난 여러가지 에러들

한 가지 에러를 해결하면 그 다음 에러가 기다리고 있다는 것을 그냥 인정하고 받아들이자

❗️ 페이지 이동시 페이지 가장 상단으로 이동

이건 에러라기 보다는 그냥 페이지 가장 상단으로 이동하게 만들고 싶어서 찾아보는 과정이었는데 리액트 라우터 페이지를 참고하면 어렵지 않게 ScrollToTop 컴포넌트를 만들어서 Scroll Restoration을 구현할 수 있다.

❗️ 조회수 두 번 증가하는 에러

CRA로 처음 리액트 앱을 만들게 되면 App을 감싸고 있는 Strict Mode를 볼 수 있는데, 이 <React.StrictMode> 모드는 리액트 개발 도중 발생하는 문제를 감지하기 위한 설정으로 개발 모드일 때만 렌더링이 두번 발생된다고 한다. App.jsx에 있는 해당 코드를 지워주자 조회수가 정상적으로 1씩만 증가했다.

❗️ 배포 후 페이지 이동시 404 에러

AWS의 S3를 이용해 클라이언트를 배포했는데 홈 화면까지는 문제없이 잘 랜더링 되지만, 다른 몇몇 페이지로 이동하려고 하니 계속해서 404 에러가 뜨기 시작했다. 구글링을 통해 발견한 블로그글을 통해 해결하기는 했지만, 개발자도구 네트워크 창에서는 404 에러가 남아있었다. 대체 원인이 뭔지 궁금했는데, 전에 TodoList 애플리케이션 프로젝트를 할 때 배포 당시 Browser Router 때문에 배포 후 계속 흰 화면이 떠서 문제였던 것을 Hash Router로 바꾸어서 해결했던 경험이 떠올랐다. 그래서 관련 키워드로도 검색을 해보다가 이 블로그를 찾게 되었는데 해당 블로그의 설명을 통해서 조금이나마 그 이유를 이해할 수 있었다. error.html을 index.html로 고치고 나서도 404 코드가 신경쓰일 때 cloud front를 사용해 에러 코드도 200으로 바꿔줄 수 있다고 한다.

❗️ 회원가입 시 중복 검사 409 에러

이것도 해결해야 할 에러로 만났다기 보다는 회원가입 시 유저 네임이 중복되거나, 이메일이 중복될 때 받는 에러 코드를 기록해두고 싶어서 남겨둔다. 409에러는 서버의 현재 상태와 요청이 충돌했음을 나타내는 conflict 에러인데, 우리는 이 코드와 함께 응답 데이터에 message를 담아서 해당 메시지를 받았을 때 '이미 사용중인 Display name입니다.' 나 '이미 사용중인 이메일 주소입니다.'와 같은 alert 창을 뜨도록 처리했다.

🟢 regret & Improve

📀 API, 데이터 셋 만들 때 프론트의 참여도가 높을 필요가 있다

백엔드 분들께 알아서 만들어 달라고 하면 당장에 편하고, 우리는 UI 만드는 데 집중할 수 있지만, 실제로 데이터를 사용하게 되었을 때 프론트가 생각하는 것과는 다른 방식으로 데이터들이 들어올 수 있다.

예를 들어서 이번 프리 프로젝트에서 마이 페이지를 구현할 때 로그인한 사용자 본인이 쓴 글에서 tag들만 가져와서 마이 페이지의 tag부분에 보이도록 하고싶었다. 그런데 회원 단건 조회 API를 봤을 때 tag들은 회원의 게시글 속에 포함된 상태로 남아있었기 때문에 데이터를 꺼내 쓰기가 쉽지 않았다.

결국 방법을 찾아서 구현을 하긴 했지만, 이런 걸 미리 백엔드 분들이 API를 만들 때 확인할 수 있었다면 좋지 않았을까? 하는 생각이 들었다.

단지 그냥 내가 백엔드를 잘 모르니까... 아직 기능 구현은 잘 모르겠으니까... 라는 생각으로 뒤로 미뤄두고 나중에 확인하면 된다고 생각하지 말아야 한다.

👼🏻 리팩토링은 어렵다

이번 프로젝트 전반에서 느낀 거지만, 미리 생각하고 미리 설계하는 것은 지난한 일처럼 보일진 몰라도 분명 후반에 가서 웃을 수 있는 일이라는 것이다.

기능 개발을 시작할 때 custom hook을 만들고 시작하냐에 대한 고민이 있었는데, 아직 기능 개발이 어떤식으로 이루어질지 잘 모르겠으니 일단 코드를 작성해보자!는 것이 프론트 팀의 주 대화 방향이었다. 그렇게 코드를 작성해보니 확실히 진행이 빨리 되는 느낌이 들고 좋았지만, 이런 방식은 나중에 리팩토링을 어렵게 만들었다.

대표적으로 fetch가 프로젝트에서 정말 많이 쓰였는데, fetch를 매서드에 따라 나누어 api를 만들어서 사용하려고 하니 이미 각 fetch들이 사용되고 있는 방식이 너무 달라서 (ex: 헤더의 유무, 바디의 유무, 리다이렉션 유무) 좀처럼 하나로 합친 함수를 만들기 힘들었다.

👟 된 거 아닌가? 싶을 때 한 발짝 더 내딛기

사실 절대로 쉽지 않은 것 같다. 인간이라는 게 원래 조금만 번지르르해보이면 이쯤에서 그만하고 쉬고싶다는 생각을 우선 하기 때문이다.

구현하고자 하는 기능은 하나를 만들었다고 끝난 게 아니며, 에러 역시 하나를 해결했다고 끝이 아니었다. 알면서도 계속해서 쉬고 싶은 마음이 들었다. 그런 마음이 들더라도 끝까지 물고 늘어지는 것이 필요하고, 그런 점을 팀원들을 보면서 배웠다.

🤥 학습 루틴 없는 삶 ? 그건 도태의 지름길

주 3회 운동은 잘 지키고 있지만, 저녁 시간대까지 프로젝트 기능 구현을 하다보니 원래 하려고 했던 타 기술 습득이나 영어 공부, 독일어 공부, 알고리즘 공부 등이 소홀해졌다. 메인 프로젝트가 곧 시작하겠지만, 좀 더 정신 잘 잡고 2023년 신년의 기운으로 하루에 조금씩이라도 다른 공부들을 할 수 있도록 학습 루틴을 세워야겠다.

😵‍💫 라이브러리를 효율적으로 사용하는 방법은 뭘까?

이번 프로젝트에서 redux, tailwind 등의 라이브러리를 사용했지만, 뭔가 드라마틱하게 효율적인 개발을 하지는 못한 것 같아서 그 점이 조금 걸린다.

분명 redux로 관리할 수 있는 데이터가 지금 작성해놓은 것보다 더 많을 것 같은데, 리덕스를 사용하지 않아도 될 것 같은데? 하면서 길게 생각해보지 않은 경우들도 있는 것 같다.

어떤 라이브러리나 기술 스택을 사용하든 왜 그걸 사용했는가에 대해 고민해보라고 하던데 그 점을 잘 짚지 못한 것 같아 아쉽다.