지난 2주간 (2024년 4월 30일 ~ 5월 14일) 진행되었던 저의 첫 리액트 프로젝트, “Rolling”에 대한 전반적인 회고를 작성해 보려 합니다. 프로젝트 정보, 기획 내용, 제가 맡았던 기능, 그리고 이번 경험을 통해 배운 점들을 상세히 다루겠습니다.

Rolling: 온라인 롤링 페이퍼 서비스

“Rolling”은 어린 시절 전학 가는 친구에게 반 친구들이 함께 롤링 페이퍼를 작성했던 추억을 모티브로 한 웹사이트입니다. 사용자들은 이 플랫폼을 통해 온라인 롤링 페이퍼를 제작하고 공유할 수 있습니다. 원활한 프로젝트 진행을 위해 다음과 같은 사항들을 팀원들과 함께 정의했습니다.

  • 데일리 스크럼 및 코어 타임 지정: 매일 정해진 시간에 진행 상황을 공유하고 협업 효율성을 높였습니다.
  • 코드 및 커밋 메시지 컨벤션: 일관성 있는 코드 스타일과 명확한 커밋 기록을 유지하기 위해 규칙을 정의했습니다.
  • **이미지 파일 전략 (svg png):** 이미지 종류에 따른 파일 형식 사용 규칙을 정했습니다.
  • Git Branch 전략: 효율적인 버전 관리를 위한 브랜치 운용 전략을 수립했습니다.

팀장의 주도하에 코드 컨벤션을 상세하게 정의하는 시간을 가졌습니다. import 순서부터 함수 형태까지 규칙을 정했는데, 예를 들어 컴포넌트는 일반 함수를 사용하고 그 외 함수는 화살표 함수를 사용하기로 약속했습니다. 지금 생각해보면 함수의 형태는 개발자의 자유에 맡기는 것이 더 좋을 것 같습니다. 각 함수 형태에는 상황에 따른 이유가 있을 수 있기 때문입니다.

하지만 page/ 폴더 내의 컴포넌트 이름에 ~Page 접미사를 붙이지 않기로 한 것은 좋은 결정이었습니다. 이미 폴더로 모듈화되어 있는 컴포넌트 이름에 불필요한 접미사를 붙일 필요가 없다는 팀원의 의견에 동의했습니다. 만약 혼자 진행했다면 무조건 접미사를 붙였을 테지만, 팀원의 다른 관점을 이해하고 수용할 수 있었던 좋은 경험이었습니다. 컨벤션 내용은 다소 엄격했지만, 컨벤션을 정하는 회의를 통해 팀원들의 다양한 시각을 엿볼 수 있었던 점은 긍정적이었습니다.

기술 스택

프로젝트의 빌드 도구로는 Vite를 사용했으며, CSS는 Styled-Components, 텍스트 에디터는 Quill 라이브러리를 활용했습니다. 협업 도구는 기존에 사용하던 Discord와 Github만을 사용하여 진행했습니다. Github의 이슈 관리 및 칸반 보드 기능을 충분히 활용할 수 있다고 판단하여 별도의 추가 도구는 사용하지 않았습니다.

UserFlow

프로젝트 내 각 페이지에서 버튼 클릭과 같은 사용자 인터랙션 발생 시 이어지는 화면 전환 흐름을 시각적으로 도식화하여 정리했습니다.

피그마 시안

피그마 시안은 코드잇에서 제공받았으며, 저희 팀은 별도의 로고나 디자인 변경 없이 기존 디자인을 그대로 유지하여 프로젝트를 진행했습니다. (저작권상의 이유로 피그마 시안 내용은 블러 처리합니다.)

맡았던 역할

프로젝트 첫날, 각자 담당할 기능을 분배하는 과정에서 API 로직 개발이 가장 먼저 논의되었습니다. 평소 프론트엔드보다는 백엔드 작업에 더 흥미를 느껴왔던 저는 주저 없이 API 로직 개발을 맡겠다고 자원했습니다. API 문서를 분석하고, 서버와 주고받는 데이터 형태를 파악하는 작업이 재미있을 것이라고 예상했기 때문입니다. 역시 UI를 개발하는 것보다 JSON 데이터를 분석하는 과정이 더 흥미롭게 느껴졌습니다. 이전 프로젝트 경험을 통해 Swagger나 Postman 등의 API 개발 도구 사용에 익숙했기 때문에 API 로직 개발은 비교적 수월하게 진행되었습니다. API는 모든 팀원이 공통으로 사용하는 함수들이므로 빠르게 완료하는 것을 목표로 했고, 프로젝트 시작 후 3일 안에 모든 테스트를 완료했습니다. 또한, 컴포넌트 개발을 전혀 담당하지 않아 리액트 학습이 부족할 것이라는 우려 때문에 서둘러 API 로직 개발을 마무리하고 리액트 관련 작업을 맡고 싶었던 이유도 있었습니다.

api 로직

  • 사용한 기술: JavaScript fetch 메서드
  • 기술을 선택한 이유: axios가 fetch보다 더 직관적이고 편리한 API를 제공하는 것은 사실이지만, 둘 다 Promise 기반의 비동기 작업을 처리하는 데 사용되므로 성능 면에서 큰 차이는 없다고 판단했습니다. 현재 프로젝트는 새로운 기술을 도입하기보다는 강의에서 배운 내용을 활용하는 데 초점을 맞추는 것이 더 중요하다고 생각하여 fetch를 선택했습니다.하지만 프로젝트를 진행하면서 함수를 호출하는 곳에서 직렬화를 처리하는 것이 더 나은 상황도 있을 수 있다는 생각이 들었습니다. API 함수 내에서 직렬화가 이루어지다 보니, JavaScript 순수 객체 형태로 함수에 데이터를 전달할 때 객체의 특수성이 적용되어 예상치 못한 동작이 발생할 수도 있었기 때문입니다.

코드를 작성할 때, 모든 팀원이 사용할 함수라는 점을 고려하여 직관적인 네이밍과 상세한 주석 설명을 포함하려고 노력했습니다. 필요한 매개변수에 대한 설명도 빠짐없이 추가했습니다. 또한, JSON 데이터로의 직렬화 과정 또한 해당 함수 내에서 처리하도록 구현하여 함수를 호출하는 쪽에서 직렬화에 대한 부담을 덜어주었습니다.

message page

  • 사용한 기술:
    • react-responsive의 useMediaQuery
    • react-router-dom의 useNavigate, useParams
    • react-quill의 ReactQuill, Quill
  • 기술을 선택한 이유:
    • useMediaQuery: 반응형 CSS 스타일링을 위해 사용했습니다. 제가 직접 만들지 않은 컴포넌트를 반응형으로 스타일링해야 했기 때문에 라이브러리를 설치하여 적용했습니다. 특정 모바일 사이즈를 기준으로 스타일링했는데, 해당 크기를 정의하는 상수를 utils/ 폴더에 두고 팀원들과 공유했으면 더 효율적이었을 것 같습니다.
    • useParams: API 함수를 호출하여 서버에 메시지를 저장할 때, 메시지를 받는 사람의 ID 값이 필요했기 때문에 URL 파라미터를 추출하기 위해 사용했습니다.
    • useNavigate: 메시지 생성 후 해당 메시지를 받는 사람의 페이지로 리다이렉트하기 위해 사용했습니다.
    • ReactQuill, Quill: 다양한 에디터 라이브러리 중에서 Quill은 브라우저 호환성 및 모바일 확장성이 뛰어나다고 판단하여 선택했습니다. React 18을 지원하고, 유튜브 영상 임베디드, 폰트 변경, 이미지 리사이즈 등 다양한 기능을 제공하여 기능 확장성 측면에서도 좋다고 생각했습니다. 에디터 설정 또한 어렵지 않게 원하는 대로 선택하여 사용할 수 있다는 점이 매력적이었습니다. 또한, 내용이 HTML 형식으로 저장되어 불러와 사용할 때 HTML 파싱만 거치면 되므로 사용하는 입장에서 편리할 것이라고 예상했습니다.

Github Repository

Git을 활용한 협업 도구는 Github 외에도 여러 가지가 있지만, 압도적인 사용자 수와 파일 버전 관리뿐만 아니라 칸반 보드, 이슈 관리, Pull Request (PR) 등 다양한 협업 기능을 제공한다는 점이 매력적이었습니다.

프로젝트 초기 레포지토리 준비를 담당하면서, 팀 프로젝트이므로 개인 계정 대신 Organization을 생성하여 레포지토리를 관리하기로 결정했습니다. 이번 프로젝트에서는 경험해보지 못한 것들을 최대한 시도해보는 것을 목표로 했기 때문에 Organization을 활용하는 것이 좋은 경험이 될 것이라고 생각했습니다.

우선 레포지토리를 생성한 후, 이슈 및 PR 템플릿을 준비하고 각 팀원의 진행 상황을 시각적으로 파악할 수 있는 칸반 보드를 만들었습니다. 또한, 미리 정의한 Git Flow 전략에 따라 main과 develop 브랜치를 생성했습니다. 원활한 코드 관리를 위해 PR Merge 시 2명 이상의 Approve를 필수로 설정하고, PR을 거치지 않고는 Merge가 불가능하도록 브랜치 규칙을 설정했습니다.

하지만 팀원들이 PR과 코드 리뷰에 익숙하지 않아서 PR 확인 후에도 리뷰 작성을 꺼리거나, 리뷰를 작성하지 않았으니 Approve조차 하지 않는 상황이 발생했습니다. 이로 인해 PR이 점점 쌓여가고 코드 충돌 가능성도 높아졌습니다. 다행히 매일 데일리 스크럼을 진행했기 때문에 팀원들을 매일 만날 수 있었고, 저의 Approve 요청 잔소리가 매일 시작되었습니다.

PR 과정은 다소 어려움이 있었지만, 이슈 관리와 칸반 보드 자체는 팀원들이 잘 활용해 주어서 보람을 느꼈습니다.

이번 2주간의 첫 리액트 프로젝트를 통해 리액트의 기본적인 개념을 이해하고 실제 프로젝트에 적용해보는 소중한 경험을 할 수 있었습니다. 비록 짧은 기간이었지만, API 연동, 컴포넌트 개발, 상태 관리 등 다양한 측면에서 리액트를 경험해볼 수 있었습니다. 앞으로 더 깊이 있는 리액트 학습과 다양한 프로젝트 경험을 통해 프론트엔드 개발 역량을 더욱 향상시켜 나가고 싶습니다. 팀원들과의 협업 과정에서 겪었던 어려움과 이를 해결하기 위한 노력 또한 값진 경험으로 남았습니다. 다음 프로젝트에서는 더욱 능숙하게 협업하고, 효율적인 개발 프로세스를 구축할 수 있도록 노력할 것입니다.