📝 앙골라 프로젝트 회고

2023.09.01 ~ 2023.09.27 약 한달동안 진행했던, 프로젝트 앙골라에 대한 회고

---

🌱 프로젝트 소개

앙골라 서비스는 특정 주제에 대해 사용자들이 A와 B 중 하나를 선택하여 각자의 의견을 공유할 수 있는 밸런스 게임 플랫폼이다. 앙골라는 SNS 기반 웹 서비스이며, 모바일에서도 이용이 가능하게끔 대응하였다.
로그인한 사용자들은 다양한 주제의 밸런스 게임에 참여할 수 있고, 직접 포스트를 작성할 수 있다. SNS 커뮤니티답게 검색, 좋아요, 팔로우, 알림 및 댓글 기능 뿐만 아니라 레벨과 투표 등 게임 요소의 기능 또한 함께 구현했다.

앙골라 페이지

---

🥚 앙골라 팀

우리 팀은 나를 포함 총 5명으로 구성되었다. 팀원 중 디자인을 매우 잘하시는 분이 계셔서 우리 모두의 귀여운 앙골라 캐릭터가 탄생하였다. (거의 파워레이저인줄...)
나는 내 최애 컬러 민트!!(초록 아님)

너무 너무 좋은 팀원들을 만났다. 이런 동료들과 함께할 수 있어 너무 행운이라고 느껴졌다! 프로젝트를 위한 회의가 지루하다고 느껴본 적 한 번 없고, 일주일에 4번 오프라인 모임을 했던 적이 있을 정도로 자주 만났다! 팀원 중 세 분이 집돌이, 집순이이신데, 함께 나와주셔서 너무 감사했다 🙇‍♂️
헤어지기 너무 아쉽지만, 다른 팀원 모두 다음에 다시 만났을 때 얼마나 많이 성장하였을지가 기대된다. 언젠가 다시 만나길 🙏

---

🐣 기술 스택

TS + React + Vite를 기본적으로 사용하였고, CSS style로는 Emotion을 선택하였다.
추가로 code format을 위해 ESLint와 Prettier을 사용했고, HTTP 통신을 위한 axios, 상태관리를 위해 recoil, data fetching를 위한 react quary 등을 사용하였고, vercel로 배포하였다.

css style은 빠른 개발을 위해 개인적으로 tailwind를 사용하고 싶었다. 하지만 tailwind에 익숙했던 팀원 분이 없으셨고, 대부분 emotion을 선호하셨다. 나도 익숙하지 않았던 emotion을 다뤄보고 싶다고 생각하여 선택하였지만, 결과적으로는 만족!
tailwind는 클래스 이름이 너무 길어질 수 있어서 중요한 비즈니스 로직이 한 눈에 안들어 올 때가 종종 있는데, CSS-in-JS인 emotion은 별도의 클래스명 없이 컴포넌트 단위로 스타일을 캡슐화하여 코드의 가독성을 높여주었다.

Typescript로 팀 프로젝트를 진행한 것이 처음이어서, 걱정이 많이 되었다. 하지만 프로젝트를 진행하다보니 너무 당연하게 typescript를 사용하고 있어 놀랐다! (드디어 조~금 TS에 익숙해졌구나...! 대단해 나 자신😇) 사실 그냥 모르는 부분이 나올 때마다 깔짝깔짝 검색하며 땜빵 떼우는 식으로 해결하는 느낌이 없잖아 있었기에 재대로 학습을 해야될 것 같다!

우리 소중한 앙골라 팀원들과의 협업 Tool로는 Slack, Notion, Github과 Discode, 디자인을 위한 Figma를 사용하였다.
프로젝트에 열중되어 새벽 2시까지 회의했던 앙골라 팀 너무 멋있고 자랑스럽다😤

---

🐥 개발 문화

본격적인 프로젝트 시작에 앞서, 앙골라 팀원들과 개발 문화 및 컨벤션을 정하였다. 팀 프로젝트에서 이런 규칙을 정해보는 것이 처음이어서 생소하였고, 생각보다 구체적으로 정하여서 놀랐다😳 이런 소중한 경험을 간단히 적어보고자 한다.

Branch 전략

main 브랜치는 건들지 않고, dev 브랜치를 판 후, 각 기능 단위로 dev에서 브랜치를 분기시켰다. 각 기능이 완료가 되면 dev로 PR을 날린 후, merge하여 관리하였고, main 브랜치는 마지막 배포 전에 merge하였다.

main > dev > feature (기능 단위)

또한, feat/#이슈번호/기능명와 같이 브랜치를 명명하는 규칙도 정하였다.

Commit 규칙

커밋 메세지 형식: prefix: #이슈번호 - 커밋메세지
prefix는 init, feat, refactor, fix 등 팀원들과 회의를 통해 앙골라만의 규칙을 정했다.
또한 커밋을 자주 하자는 규칙을 정했는데, 이전까지 커밋을 거의 하지 않았던 나에게는 주의가 필요한 규칙이었다. 최대한 나누어 커밋을 많이 하려고 노력했다!

개발 순서

Issue 파기 > Kanban 보드 > 개발 > Commit > Push > PR > Merge > Issue 닫기 > Kanban 보드

Issue와 PR은 템플릿을 만들어 사용함으로 협업 간 통일성을 유지하였다.

머지 데이

🌟머지데이🌟는 팀 협업에 매우 큰 도움이 되었다고 생각된다!!
스프린트 별로 업무를 분배한 후, 각 스프린트의 일정을 산정하여 프로젝트를 진행하였다. 각 스프린트가 끝나는 다음 날은 머지데이로 정하여 각자 수행했던 파트의 PR을 dev 브랜치로 모두 merge하고 테스트하였다.
이는 팀원들이 PR을 확인하여 merge하는 시간을 효율적으로 만들었고, 스프린트 분배에 도움이 되어 코드 간 큰 충돌없이 프로젝트를 순조롭게 진행시켜주었다.
머지데이를 통해 PR을 다 함께 검토하고 merge함으로서 예상치 못한 충돌이나 오류를 줄이고 함께 해결할 수 있었다.
물론 충돌이 발생할 때도 많이 있었지만, 동료들과 함께 고민하니 금방 해결되었고, 다들 "git 박사"라 불릴 정도로 git에 익숙해졌다.

이외에도 디렉토리 구조나 code 규칙을 정함으로서 통일성을 유지할 수 있었고, 협업 능력을 올릴 수 있는 계기가 되었다고 생각된다.

---

🐓 API 설계

첫 스프린트로 API Hook을 구현하였다. 주어진 API 중에서 우리에게 필요한 API를 선정하고, 카테고리별로 분배하여 스프린트를 진행했다.

apis 폴더 안에 카테고리 별로 api 파일을 나누었고, 각 파일 안에서 필요한 여러 api hook들을 정의하였다.
분리된 axios instance를 호출하여 react-query를 적용시켰다.
서버 데이터를 읽어(read)오기 위해 useQuery를 사용하였고, 서버의 데이터를 변경(create, update, delete)시키기 위해 useMutation을 사용했다.

---

🍗 내가 구현한 파트

• 포스트 관련 API Hook
• Button 컴포넌트
• 회원가입 페이지 UI 및 기능
• 로그인 페이지 UI 및 기능
• 포스트 페이지 UI 및 기능

---

🐉 Trouble shooting

1. 회원가입 페이지 유저 데이터 refetch

프로젝트 마지막 날...어떠한 오류도 없을 것이라 믿어 의심치 않았지만...최종 QA 중에 내가 맡은 부분에서 오류가 발견되었다... 🤯
두 명의 사용자가 동시에 회원가입 페이지에 접속하여, 한 명이 회원가입을 완료하게 되면, 다른 한 명은 이전에 가입된 사용자와 같은 이메일 또는 닉네임을 사용할 수 없어야 하는데, 중복검사에서 거르지 못하는 문제가 발생했다.
회원가입 페이지 접속시에, 전체 user 데이터를 한 번만 fetch 하기 때문에 회원가입 도중에 새롭게 가입된 유저의 데이터를 비교할 수 없어서 발생된 문제였다.
이를 해결하기 위해 이메일 또는 닉네임의 중복검사 버튼을 클릭할 때, 업데이트된 user 데이터를 받아와서 중복 비교를 해주는 로직을 구현하여야했다.
useQuery로부터 refetch 함수를 사용하면 데이터가 새롭게 업데이트 되는 것은 알고 있었지만, useQuery는 비동기로 처리되어 refetch와 동시에 로직 내 데이터가 업데이트 되지 않았다.
다 같이 한참 고민하다가 팀원분이 해결해주셨다 🥹
refetch에 .then()을 사용하여 그 안에서 로직을 처리해주면 되는 것이었다!
이 사건을 통해 refetch 함수는 Promise 객체를 반환하는 것을 알게 되었고, then() 메서드를 통해 비동기 작업이 완료된 후 데이터를 처리할 수 있는 것을 절대로 잊어버리지 못할 것 같다.

2. 포스트 페이지 뒤로가기 오류

포스트 페이지에서 뒤로가기가 안되는 현상이 발생했다.
포스트 페이지는 댓글만 보여주는 post/:postId,
투표 전 댓글를 작성할 수 있는 post/:postId?show=true,
투표 후 투표율을 볼 수 있는 post/:postId?show=true&voted=A URL이 존재하고, 이는 useSearchParams() 로 구현했다.
뒤로가기 안되는 문제를 해결하기 위해 디버깅을 해보니 URL 주소에서 쿼리스트링 값이 변경될 때마다 history stack이 매우 많이 쌓이는 것을 확인할 수 있었다.

이 문제의 원인은 두 가지가 있었다.

첫 번째는 useEffect의 불필요한 의존성을 너무 많이 추가한 것이었다.
포스트 페이지에는 매우 많은 로직이 들어가있고, useEffect 훅도 많이 사용되고 있었다. 나는 처음엔 useEffect의 의존성으로 필요한 것들만 넣었는데 ESLint 경고가 나타나서 이를 없애기위해 불필요한 의존성을 추가하여 훅이 몇 번이고 계속 호출되는 현상이 나타났던 것이다.
이 eslint 경고는 "react-hooks/exhaustive-deps"로 효과 훅에 누락된 종속성이 있을 때 경고를 띄우는 것이었다. 이를 무시하고 필요한 의존성만 추가하니, history stack이 여러번 쌓이는 것을 막을 수 있었다.
리액트 훅에 대해 잘 이해하고 사용하여야 효율적이고 최적화된 사이트를 만들 수 있다는 것을 깨닫게 되었다.

두 번째는 history stack에 투표 전(댓글 작성) 페이지 기록을 남겼기 때문이다.
댓글 작성할 수 있는 페이지에서 투표를 완료하여 투표율 페이지로 이동한 후, 뒤로가기가 되지 않았다.
그 이유는 투표 후 투표율 페이지에서 뒤로가게 되면 이론상 댓글을 작성하는 페이지로 이동해야하는데 이 페이지에서는 user의 투표여부에 따라 투표율 URL로 쿼리스트링을 바로 변경시켜주는 로직이 있기 때문이었다. 그래서 이미 투표를 하였기에 뒤로가기를 눌러도 계속 투표율 URL이 유지되는 것이었다.
이를 해결하기 위해서 쿼리스트링 변경 시, 현재 페이지를 history stack에 남기지 않게 replace를 사용하였다. 즉, setSearchParams(searchParams, { replace: true }); setSearchParams 함수에 replace 옵션을 주어 해결할 수 있었다!

---

👑 KPT 회고

이번 프로젝트에 대해 KPT 회고를 적어보겠다.

Keep

• 화목한 팀 문화 형성
  팀 문화를 잘 형성함으로서 팀에 대한 소속감과 프로젝트에 대한 애정을 증대할 수 있었다. 팀원들의 개인 앙골라 캐릭터를 만든다거나 코어타임에 지각 할 시, 커피를 사는 것 등 약간의 오락적인 요소들도 한 번 더 팀원들과 소통을 하게끔 만들어 팀 분위기를 잘 조성시켜주었다.

• 원활한 의사소통을 위한 노력
  팀원 간 원활한 의사소통은 사소한 마찰도 방지시켜주었다. 자신의 의견은 적극적으로 어필하되 돌아오는 피드백을 적극 검토하고, 상대를 배려하며 의사소통이 진행되었던 것이 너무 좋았다. 이는 내가 팀 내에서 적절히 의견을 표출할 수 있게끔 만들었고, 화기애애한 팀 분위기를 이끌어낼 수 있었다.

• 개발 문화 및 문서화
  팀 개발 문화와 문서화 작업은 프로젝트 작업에 큰 도움을 주었다. 개발 문화를 정함으로서 헤메이지 않고, 빠르게 개발을 진행할 수 있었고, 통일성을 가질 수 있었다. 또한 논의된 것들을 문서화함으로서 놓치는 부분을 바로 잡을 수 있었고, 이전에 진행했던 내용들도 계속 참고할 수 있어 개발에 큰 도움을 주었다.

Remind
적절한 팀 문화를 형성하여 소속감을 가지고, 팀원들과 많이 교류하기
타인에 대한 배려와 원활한 의사소통을 할 수 있도록 노력하기
팀의 개발 문화와 컨벤션을 정하고, 문서화에 최선을 다하기

Problem

• 모바일에 대응에 미흡
  너무 당연하게 웹 위주로 프로젝트를 진행했다. 반응형을 구현하긴 했지만, 우선 순위에서 벗어나 있었다. 그러다보니 모바일에서 UI가 깨지는 현상이 꽤 많이 있었으며, 주변 지인으로부터도 많은 피드백을 받았다. (특히 회원가입 페이지....미처 신경쓰지 못했다...)
  배포 후, 홍보를 위해 지인들에게 url 주소를 뿌리면 95%는 모바일로 접속해서 볼 것이다. 현대는 모바일 시대라는 것을 잊지 말자.

• 짧은 QA 기간
  프로젝트 마지막 날에 다 함께 최종 테스트 중, 예상치 못한 버그를 발견하였다. 이 버그를 해결하느라 예정된 일정이 늦춰졌다. PR리뷰가 꼼꼼하지 못했다고 생각할 수도 있지만, 팀원 모두가 PR리뷰를 100% 완벽하게 할 수는 없다고 생각된다. 우리는 1차 QA만 진행하였지만, 조금 더 QA 기간과 횟수를 늘리고 꼼꼼하게 진행한다면 충분히 사전에 문제를 발견할 수 있을 것 같다고 생각된다.

• 문서화하지 못한 트러블 슈팅
  프로젝트 진행 중 많은 문제들과 마주하였는데, 개발하는데 조급하여 이러한 문제들을 문서화해두지 않았다. 이는 반복되는 문제가 생겼을 때, 기억이 나지 않아 다시 해결해야하는 상황이 종종 발생되었다.

Solution(Action Item)
모바일 대응을 가장 우선으로 고려하여 웹 페이지 제작
QA에 시간과 인풋을 더 투자하기
마주한 이슈들에 대한 트러블 슈팅을 문서화

Try

• 팀원의 문제도 나의 문제!
  하나의 문제 상황이 발생하였을 때, 팀원 모두가 자신의 일처럼 생각하며 해결하려고 노력하였다. 이는 문제 상황을 매우 빠르게 해결해주었고, 효율성을 높여주었다. 나는 다른 팀원들에 비해 이러한 부분이 조금 더 부족했던 것 같다. 분배되어진 업무여도 모두 자기 일처럼 관심을 가지는 노력이 더 필요하다고 느꼈다.

• Commit 자주하기
  commit을 최대한 자주 하려고 노력했다. 하지만, 막상 개발하게되면 commit을 잊어버리거나 여러 코드를 건들여서 commit을 분리하기 애매한 상황이 자주 있었다. 조금 더 세분화해서 commit을 진행해야된다고 생각되었다.

Solution(Action Item)
팀 내에 생기는 모든 이슈에 관심을 가지고, 해결하려고 노력하기
commit을 세분화하여 자주 하기

---

💭 마무리

이번 팀프로젝트를 통해 동료의 중요성이 개발 환경에 얼마나 큰 영향을 미치는지 깨닫게 되었다. 너무나 우수하고 배려심 넘치고, 유쾌한 동료들을 만나서 정말 재밌게 프로젝트를 진행할 수 있었다. 마음 같아서는 그냥 우리 다섯 명이서 회사차리고 계속 함께 개발하고 싶다...🥺
좋은 동료 덕분에 성장도 많이 할 수 있었다. 우리 앙골라 팀원 쭉 꽃길만 걷기를 🌸
마지막 최종 프로젝트도 좋은 팀원분들을 만난 것 같아 다행이다. 남은 기간 함께 즐겁고 열정적으로 코딩하고 싶다!
2달 뒤에 내가 어떻게 달라져있을지 궁금하다.