첫 리액트 협업 프로젝트 ‘헌혈하개’ 회고

🎯 프로젝트 개요

개인적으로 더 나아지기 위해서는 무엇이든 부딪혀보는 것이 중요하다고 생각했기 때문에 리액트를 공부하면서 많이 부족하지만 무작정 시작했던 첫 프로젝트였다. 퍼블리셔로 디자이너와는 이미 협업을 해본 경험이 있었지만, 백엔드 개발자와 어떻게 협업을 해야 하는지, 그리고 어떤 부분에서 소통이 필요한지 프론트엔드 개발자로서의 경험을 쌓기 위해 시작하게 됐다.
비록 프로젝트는 완성하지 못한 채 마무리됐지만 협업 과정에서 많은 것을 배울 수 있었고 회고를 통해 배운 점을 정리해 보려고 한다!

1. 프로젝트 목표

다른 생명을 살리기 위해 비윤리적인 환경에서 피를 뽑히며 살아가는 공혈견이 있다는 것을 알게 됐다. 프로젝트는 공혈견을 줄이고, 반려견 헌혈 문화를 장려, 공유하고 더 나은 헌혈 서비스를 제공하는 웹 커뮤니티 사이트를 개발하고자 했다.

2. 프로젝트 팀 구성

디자이너 1명, 프론트 개발자 2명, 백엔드 개발자 1명

3. 프로젝트 기간

2024.12 ~ 2025.03

4. 사용한 기술 스택

• 프론트엔드: React, Vite, Sharndcn, Emotion, React-Query, Zustand, Axios, ReactQuill, Prettier
  
• 백엔드: Java, Spring Boot, Spring Security, JWT, Hibernate, MySQL, Tomcat, AWS, Linux
  
• 디자인: Figma, Zeplin
  
• 버전 관리: Git, GitHub
  
• 기타: Notion, Discord
  

📆 프로젝트 진행 과정

1. 큰 틀 기획

첫 번째 단계로 전체적인 방향과 구조를 논의하면서 프로젝트의 방향성을 확립했다. 각 페이지의 기본적인 기능을 정리하고, 반려견 헌혈에 대한 유저 리서치와 회의를 통해 필요한 기능이 무엇인지 논의했다.

2. 상세 기획

상세 기획 단계에서는 각 페이지에 필요한 기능, 텍스트, 콘텐츠 등을 구체화하고, 기술적으로 어떻게 구현할지, 그리고 구현 가능 여부에 대해 논의했다. 또한 각 페이지의 메뉴 구조도를 작성해 프로젝트 전반의 흐름과 세부적인 요소들을 정리했다. 그러나 아무래도 단기간의 기획만으로는 모든 부분을 완벽하게 정리하기 어렵다는 점을 감안해 유연하게 변화를 수용하기 위한 애자일 개발 전략을 채택하여 진행 했다.

3. 디자인 및 개발

디자이너가 기획을 바탕으로 디자인을 작업하는 동안, 백엔드는 인프라 구성과 배포를 준비하고, 프론트엔드는 도메인 기반의 파일 레이아웃 설계, 코드 컨벤션 규칙 논의, 공통 컴포넌트 제작을 진행했다. 디자인이 마무리되는 각 섹션마다 디자이너와 회의를 통해 디자인 수정 사항을 점검하고, 디자인이 완료된 페이지부터 우선적으로 개발을 진행했으며 이후 해당 페이지를 API와 연동하여 웹 페이지를 구현했다.

💡 협업에서 배운 점

• API 설계과정에서 프론트엔드와 백엔드의 사전 협의의 필요성

  동일한 데이터에 대해 네이밍이 일관되지 않거나 데이터의 의미가 명확하지 않아서 프론트엔드에서 이를 잘못 해석하거나 변형하는 불필요한 로직을 추가해 전달해야 하는 일이 빈번하게 있었다. 사전 협의를 통해 데이터 구조와 타입 정의, 일관된 규칙과 이름을 명확히 정의할 필요가 있다고 느꼈다.

• 명확한 소통의 중요성

  화면 정의서를 작성했음에도 불구하고, 일부는 요구사항이 명확하지 않거나 빠져 있는 경우가 많았다. 초반에 디자이너와 세부적인 내용을 함께 확인하는 게 중요하다고 느꼈고, 내가 생각하는 방식과 디자이너가 기대했던 방향의 차이를 줄이기 위해 작업 전 확실한 논의가 필수적이라는 것을 배웠다.

• 컴포넌트 설계의 중요성

  공통적으로 재사용되는 컴포넌트를 설계할 때는 단순히 현재의 요구 사항만 반영하는 것이 아니라, 확장성과 재사용성을 고려해 설계하는 것이 정말 정말 중요하다는 점을 배웠다. 예를 들어 삭제 알림 Alert UI컴포넌트는 한 페이지내에서 여러 유형의 삭제가 있을 수 있기 때문에 deleteType, deleteTargetSeq 같은 구체적인 속성이 필요하다. 이번 프로젝트에서는 여러모로 부족한 부분이 많아서 작업을 하면서 필요한 게 생길 때마다 추가 및 변경하는 번거로움이 많았다.🥲

• Git을 사용한 협업과 pr 작성을 통한 문서화

  각 브랜치에서 컨펌된 파일을 dev 브랜치로 병합할 때, 여러 번의 충돌 해결 과정을 통해 충돌 발생 시 무서워하지 않고 해결할 수 있게 됐다. Pr(pull Request)을 작성하고 팀원의 pr을 확인하면서 pr은 작은 단위로 꼼꼼하게 작성할수록 공유하기 좋다는 것을 깨달았다.

👾 개발하면서 겪은 문제 & 해결 과정

배움이 많이 부족한 상태로 프로젝트를 진행했기 때문에 다양한 기술적 문제가 있었고 이를 해결해 나가는 과정에서 나름대로 정말 많은 것을 배울 수 있었다. 간단하게 생각나는 문제만 적어보면 아래와 같다.

1. 일부 api에서 데이터 조회를 post 요청을 하는 부분이 있었다. 백엔드에게 같은 조회에서 post 요청과 get 요청으로 나눠지는 부분의 기준에 대해 물어보니, 필요한 파라미터가 많거나 민감한 정보가 있으면 조회일 때도 post 요청을 필요로 하기 때문에 RESTful 하지 않은 api 설계를 하는 경우도 있다고 했다. 게시글 데이터의 특성상 최신 데이터가 필요하기 때문에 useQuery가 필요하지만 post 요청은 보통 useMutation을 사용하는 것이 일반적이라고 알고 있었기 때문에 고민했는데 POST 요청은 일반적으로 useMutation을 사용하는 것이 적절하지만, 특정 상황에서는 useQuery를 활용할 수도 있다는 점을 배우게 되었고 데이터의 목적과 상황에 따라 useQuery와 useMutation을 적절히 선택해 사용했다.

2. 리액트의 버전 호환성 이슈로 Quill Editor를 선택해서 사용자가 직접 텍스트와 이미지를 삽입할 수 있는 에디터 창을 구현했다. 기본적으로 Quill Editor는 이미지 삽입 시 Base64 형식으로 저장이 되기 때문에 용량이 크고 서버 저장 시 비효율적이라는 문제가 있었다.
   백엔드와 소통해 Quill Editor에 기존 이미지 아이콘을 클릭했을 때 이미지 업로드 핸들러를 추가해서 사용자가 업로드한 이미지를 formData로 서버에 보내고 서버에서 이미지를 별도로 저장한 후 해당 경로를 반환해 화면에 보이도록 했다.

3. 네비게이션(메뉴, 서브메뉴)에서 현재 활성화된 탭을 유지해야 했지만, 새로고침을 하면 활성화 상태가 풀리는 문제가 있었다. useState로 네비게이션의 활성 상태를 관리하고 있었는데, 새로고침 시 활성화된 메뉴 정보를 잃어버리면서 초깃값이 비어있는 값으로 설정되고 있었고, useLocation을 사용하여 URL을 기반으로 상태 초기화를 방지할 수 있었다.

4. 폼 안에서 여러 개의 API 요청 버튼이 있을 때, 의도치 않은 폼 제출이 되는 문제가 있었다.
   HTML에서 form 태그 내부에 있는 button의 기본 타입을 설정하지 않으면 button이라고 알고 있었는데 알고 보니 기본 타입이 submit이라 발생하는 문제였다. 최종 제출 버튼만 type=”submit”으로 설정하고 API 요청 버튼은 type=”button”으로 설정하여 각 버튼의 역할을 명확히 구분해 줬다.

아쉬운 점과 개선하고 싶은 부분

1. 개발을 하면서 설계를 보완하면 되겠지라는 생각은 위험하다

이번 프로젝트를 진행하면서 이 정도면 충분히 설계됐으니 만들면서 필요한 부분은 보완해 나가자는 마음으로 개발을 시작했다. 하지만 초반 설계가 튼튼하지 않으면 이후 개발 과정에서 예상치 못한 문제들과 불필요한 수정 작업이 계속 발생한다는 것을 직접 경험했다. 이러한 경험을 바탕으로, 다음 프로젝트에서는 초반 설계에 더 많은 시간을 투자하여 예상되는 문제나 변경 사항을 미리 고려해 탄탄한 설계를 기반으로 개발을 진행하고 싶다.

2. 리액트에 대한 이해 부족

프로젝트를 진행하면서 리액트에 대한 이해가 많이 부족하다고 느꼈다. 이후 다시 공부하면서 돌아보니 불필요한 상태를 과도하게 사용했고, 단순히 기능을 구현하는 것에 집중하다 보니 코드의 확장성과 유지보수성을 충분히 고려하지 못했다. 앞으로는 React의 동작 원리를 깊이 이해하고 효율적이고 유지보수하기 쉬운 코드를 작성하고 싶다.

3. 코드 리뷰 및 협업

내 작업에 집중하느라 팀원의 코드를 충분히 살펴보지 못했고 코드 리뷰와 코드의 일관성을 유지하는 부분을 소홀히 했다는 점이 아쉬웠다. 다음에는 코드 리뷰를 꼼꼼히 진행해 의견을 나누면서 프로젝트를 진행하고 싶다.

4. 프로젝트 시작 전에 팀원들과 목표와 방향성을 명확히 정하기

프로젝트를 진행하면서 팀원들 간의 목표와 열정이 다를 경우, 프로젝트 진행이 어려워질 수 있다는 점을 실감했다. 필요한 아이디어라고 생각했기 때문에 프로젝트를 완성도 있게 마무리하고 싶었지만 팀원 간의 열정과 책임감이 달랐기 때문에 결국 프로젝트 진행이 불가능해졌다. 이번 경험을 통해 기술적인 역량도 중요하지만, 가장 중요한 것은 팀원들의 책임감과 협업 태도가 프로젝트의 완성도에 가장 큰 영향을 미친다는 것을 알았고 다음에는 더 나은 협업을 통해 완성도 높은 프로젝트를 만들고 의미 있는 결과물을 남기고 싶다.

마무리 및 다음 목표

비록 완성하지 못한 채 마무리한 프로젝트이지만 분명한 건 프로젝트를 하기 전보다는 스스로가 많이 성장했다고 느낀다. 이번 경험을 통해 다음에는 어떤 부분을 더 신경 써야 할지, 또 내가 부족한 부분이 무엇인지에 대해 알 수 있었다. 해당 프로젝트는 범위가 넓어 단기간에 완성하기 어려운 만큼 실력을 더욱 다듬은 후 장기적으로 기간을 잡아 다시 도전할 계획이다. 다음 프로젝트에서는 욕심을 부리지 않고 규모가 크지 않더라도 초반 설계, 유지 보수성과 확장성을 고려한 코드 작성, 효율적인 협업에 집중하고자 한다.

🔗 헌혈하개🐶 프로젝트 깃허브