🌈[프로그래머스] 프론트엔드 데브코스 회고 (4)

🍀 꿀매 포청천 프로젝트 회고

🚀 9월 - 중간프로젝트 기간

이번 9월이란 한 달의 시간동안 데브코스의 꽃 중 하나인 중간 프로젝트를 진행했다. 주어진 api를 가지고 기획 단계부터 개발 단계까지 팀원 모두가 직접 진행하는 단기간 프로젝트로 주어진 시간이 길지 않은 만큼 바쁘게 시간을 보냈다. 그 과정에서 팀프로젝트가 무엇인지 제대로 경험해볼 수 있었는데 제대로된 협업이 처음인 만큼 배운 점도 많고 아쉬웠던 점도 많았다. 9월 한 달을 되돌아보며 회고하는 시간을 갖고자 한다.

🚀 프로젝트를 시작하기 전

당시 우리 팀은 프로젝트를 시작하기 전에 많은 회의 시간을 가졌다. 결정해야할 사항들이 많았으며, 초기 세팅을 튼튼히 한 만큼 앞으로 프로젝트를 진행하는데 편해질 것이라 생각했기 때문이다. 다만 좀 늘어지는 감이 있어 다른 팀들이 개발에 시작했을 때까지도 시작하지 않아 조금 조급한 마음도 들었던 것 같다. 프로젝트를 시작하기 전 정한 사항들은 다음과 같았다.

<목록>

• 개인 목표 및 팀 목표 공유하기
• 기획 진행하기
• 디자인 작업하기
• 컨벤션 및 폴더 구조 정하기
• 기술 스택 정하기
• 역할 분담하기

목표

처음에 팀원들과 이 프로젝트를 통해 어떤 목표를 달성하고 싶은지 개인적과 팀적으로 나누어 공유했는데 최근 팀 회고를 하면서 그 목표가 어느정도 달성되었는지 생각해 볼 수 있었다. 그러면서 목표를 좀 더 구체적으로 정했으면 더 좋았을 텐데 하는 생각이 들었으며, 이를 수치화할 수 있었다면 시작 전과 마무리 후에 어느정도 달성했는지 더욱 와닿았을 거라는 생각이 들면서 개선할 수 있는 점을 발견해 좋았다.

기획

우리 팀에 있어 가장 어려웠고, 미흡했던 부분이라면 기획이었다. 처음 기획 당시 아이디어 회의에서부터 난관을 많이 겪었는데 팀 매칭이 막 이루어진 시점이기도 하고, 제한된 api 환경 속에서 아이디어를 내야 했기 때문에 좀처럼 의견이 활발하게 공유되지 않았다. 다만 그러한 환경 속에서도 나름 재미있는 꿀매 플랫폼이란 아이디어를 건질 수 있었는데 이 아이디어를 잘 구현하지 못했던 것 같다. 프로젝트가 끝난 뒤 팀 프로젝트 공유회를 가지면서 다른 팀들의 결과물을 볼 수 있었는데 기획이 튼튼하다는 것이 느껴진 반면 우리 팀의 기획은 부족한 부분이 많다는 것을 알 수 있었다. 팀 회고 당시에도 나왔던 의견이며, 스스로 생각하길 아이디어 문제라기 보다는 결정된 아이디어를 구체화하는 기획 단계가 미흡했기 때문에 발생한 문제라고 생각한다. 당시 아이디어를 정하는데 많은 시간과 노력을 들인 나머지 그 아이디어를 구체화하지 않고 바로 개발에 들어간 것이 패착인 것 같다. 아이디어를 정했다면 좀 더 다양한 방면에서 그 아이디어를 구체화한 뒤 개발에 들어가야 좀 더 완성도 있는 서비스를 만들 수 있겠다란 반성도 하게 되었다.

디자인

디자인 작업에서는 디자인 총괄 역할을 맡게 된 2명이 메인이 되어 진행하게 되었는데 많은 충돌과 고민의 시간이었다. 디자인 총괄인 2명의 성향이 매우 달랐기 때문에 서로 다른 시각에서 볼 수 있어 디자인의 완성도를 높이는데 기여했다고 생각한다. 그러면서 느낀 점은 디자인이 중요한 부분은 아니지만, 사용자에게 가장 와닿는 부분인 만큼 여러 측면에서 고려해 생각해야 하는 점이 많다는 것을 다시 한 번 느꼈다.

컨벤션 및 폴더 구조

가장 중요한 부분이면서도 기본적인 규칙으로 처음 한 팀원의 의견으로 커밋 메시지 규칙을 정했으며, 그 외에도 브랜치명 규칙, 디자인 패턴 적용, pr 규칙, merge 규칙 등 많은 것들을 상의해 결정했다. 그 중 일부만 공유한다면 먼저 커밋 메시지 같은 경우 이모지를 활용했는데, 이모지를 활용한 것은 처음이었지만 나름대로 재미있었고, 보는 눈도 즐거워서 좋았다고 생각한다.

<커밋 메시지 규칙>

• 🎉 (tada) 새로운 기능 추가
• 🐛 (bug) 버그 수정
• 🚧 (construction) 작업 진행 중
• 📝 (memo) 문서 작성
• 🧪 (test_tube) 테스트 코드 작성
• ✨ (sparkles) 리팩토링
• 🔥 (fire) 코드 삭제
• 🧹 (broom) 코드 정리 - lint
• 🚚 (truck) 파일 이동

참고 링크

그 외에도 주에 1번 씩 splint 회의를 가져 그동안 develop에 merge한 내용들을 release branch에 merge해 배포해보고, 에러 사항들을 찾는 작업도 진행했다.

<브랜치 규칙>

• main : 마지막에 배포되는 브랜치 release 1.0.0
• develop : feature브랜치에서 merge되는 브랜치
• release : 매주 스프린트 후 배포가 되는 브랜치
• feat : 최소한의 기능 브랜치

ex_)feat-1(이슈번호)-login__button

기본적으로는 github flow를 살짝 변형시켜 활용했다.

<폴더 구조>
폴더 구조는 기본적으로 컴포넌트에 아토믹 디자인 패턴을 적용했으며, next.js를 사용하는 만큼 그에 맞춰 폴더 구조를 계획했다. 이 아토믹 디자인 패턴을 사용하면서 느낀 점은 공용 컴포넌트의 재사용성과 효율성이 무척 좋았다는 점인데 덕분에 협업하기에도 편했으며, 특히 atoms 영역의 컴포넌트들은 다른 사람이 만든 것을 가져다 쓰는 경우가 빈번했다.

atomic 디자인 패턴을 컴포넌트에 적용

Services → API호출 담당

Components/UI → 공통된 컴포넌트(로직X)

Components/Services → 서비스 로직과 엮인 컴포넌트

Templates까지는 스타일적 요소만 → Pages에서 로직이 들어가게

컴포넌트폴더 안에 스토리북 파일과 SCSS파일 모두 넣기

ex) 버튼 컴포넌트 폴더에는 스토리북 + SCSS + 컴포넌트 자체가 들어간다.

api호출은 app/services에서 역할을 담당

Atomic Design 관련 참고 자료

기술 스택

• Next.js 13
• SCSS
• Axios
• Tanstack Query
• Zustand
• Vercel
• Storybook

역할 분담

• 프로젝트 초기 세팅
• 디자인 (2)
• 노션 기록
• 깃허브 관리

🚀 프로젝트 진행 중

팀프로젝트를 하면서 conflict를 많이 겪어보고 해결해보면서 익숙해지고 싶었는데 그 바램대로 후반으로 가면 갈수록 conflict를 많이 겪고, 해결해야만 했다. 스스로의 코드에 대한 conflict는 문제가 되지 않았으나 다른 사람 코드와의 conflict는 신중하게 다뤄야 했고, 잘못 해결하는 순간 그 사람의 코드가 삭제되거나 잘못된 코드로 merge되는 경우가 있었기에 가장 좋은 방법은 그 해당 코드를 작성한 팀원과 소통하는 것이었다. 실제로 그렇게 할 경우 몇 분 내로 해결이 가능했으며, 훨씬 쉽고 수월했다.
이번에 프로젝트를 하면서 겪었던 일화 몇 가지를 소개하고자 한다.

api response 형태

api 명세서에서 response에 어떠한 데이터가 올지 나와있었는데 그것을 100% 믿으면 안된다는 것을 배웠다. 그 전까지는 항상 api 명세서대로 진행하면 문제가 없을 것이라 생각하며 직접 확인하지 않고 진행하는 경우가 많았다. 그러나 이번 프로젝트에서는 그렇게 하면서 에러가 많이 발생했는데 그 이유가 효율성을 위해 데이터를 축소하기 때문이었다.
예시로 response 형태로 User 객체가 오는 경우가 있었다.

User

{
  "coverImage": String, // 커버 이미지
  "image": String, // 프로필 이미지
  "role": String,
  "emailVerified": Boolean, // 사용되지 않음
  "banned": Boolean, // 사용되지 않음
  "isOnline": Boolean,
  "posts": Post[],
  "likes": Like[],
  "comments": String[],
  "followers": [],
  "following": [
    {
      "_id": "6169e91316cb2265df003c6d",
      "user": "6169e58216cb2265df003bf4",
      "follower": "6169e206aa57d952c6dc1edd",
      "createdAt": "2021-10-15T20:48:19.816Z",
      "updatedAt": "2021-10-15T20:48:19.816Z",
      "__v": 0
    }
  ],
  "notifications": Notification[],
  "messages": Message[],
  "_id": String,
  "fullName": String,
  "email": String,
  "createdAt": String,
  "updatedAt": String
}

api 명세서대로라면 response로 User 가 올 때 저런 형태로 와야 했다. 그러나 모든 경우에서 저런 형태로 오지 않았다. 어떤 경우에는 User 객체가 온다고 했지만, User 객체 중 _id 값만 string으로 온 경우도 있었다. 보통 object가 와야 하는데 string으로 id값만 오는 경우가 많았다. 이는 멘토님께서 알려주셨는데 항상 큰 데이터를 보내는 것은 효율적이지 않아서 이런 식으로 데이터를 축소하는 경우가 현업에서는 많다고 한다. 그래서 그때마다 그에 맞는 type을 설정해 모든 경우의 수를 고려해 개발해야 한다고 조언해주셨다. 처음에는 이를 모르고 명세서만 믿고 개발하다가 type error가 발생하거나 있어야 할 데이터가 없다고 하는 경우가 많았는데 이를 안 뒤로는 데이터를 먼저 확인한 뒤 그에 맞는 데이터 타입을 만들고 사용하는 방식으로 바꾸게 되었다.

usequery

이번 프로젝트를 하면서 처음 접하게 된 개념 중 하나가 usequery 였다. 발생한 문제는 회원가입을 해 새로운 회원이 추가될 때 사이드바에 있는 전체 회원 목록에 바로 반영이 되어야 했는데 그러지 않은 문제로 이때 사용자 목록을 불러오는데 usequery를 사용했었다. 이에 이 부분은 다른 팀원이 짠 코드였고, usequery가 무엇이고 코드를 이해하는 시간을 가져야 했다. 이에 나름대로 생각한 해결방법은 query key를 다르게 주는 것이었고, 그 이유는 동일한 query key로 데이터를 불러오기 때문에 서버에서 데이터를 불러오는 것이 아닌 기존의 처음 호출할 때 가져온 데이터를 불러오기 때문에 발생한 문제라고 생각했기 때문이다. 나름대로 usequery에 대해 이해한 바로는 동일한 query key로 데이터를 가져올 때 처음에 가져온 데이터가 있다면 그 또 다시 데이터를 불러오는 것이 아닌 기존의 가져온 데이터를 주는 것으로 나름대로 호출 횟수를 줄여주는 것으로 이해했는데 이 문제를 나름대로의 방법으로 해결한 뒤에도 또 새로운 문제들이 계속 발생했기 때문에 아직까지도 어려운 개념으로 좀 더 공부가 필요한 것 같다.

• 회원가입 후 바로 반영되게 하기 위해 query key를 다르게 준다.
• 이때 query key는 기존의 키에 current user 의 User 객체를 추가로 준다.
• 회원가입 후 사이드바에 있는 전체 회원 목록에 바로 반영되었다.(문제 해결)
• 계정 정보를 수정한 뒤 수정된 닉네임 또는 프로필 사진이 사이드바에 바로 반영되지 않는다.(추가 문제 발생)
• 보통 query key에는 object를 주지 않는다고 한다.(추가 정보 획득)
• current user의 User 객체 대신 _id만 string 값만 추가로 준다.(추가 해결 방법)
• 회원가입 문제는 해결했지만 계정 정보 수정은 여전히 반영되지 않는다.(이유 : id는 변하지 않기 때문에 동일한 query key로 가져오게 됨)
• 그렇다고 query key에 닉네임과 프로필 사진을 추가로 더 주는 것은 뭔가 비효율적인 것 같다.
• 해결 방법 모색 중(수정부터는 다른 팀원이 맡음)
• reload 하기 / next js의 ISR방식을 도입하기 등의 방법을 이용해 해결했다.
• 최종적으로는 시간적 문제로 reload로 해결하게 되었다.

// 시도한 방법들 - query key에 변하는 값들을 넣어주기
import { useQuery } from '@tanstack/react-query'
import { useCurrentUser } from '@/hooks/useCurrentUser'
import { getAllUsers } from '@/services/user'
import { UserSummary } from '@/types/user'

const useGetAllUsers = () => {
  const { currentUser } = useCurrentUser()
  return useQuery({
    queryKey: [
      'getAllUsers',
      currentUser?._id,
      currentUser?.coverImage,
      currentUser?.fullName,
      currentUser?.name,
    ],
    queryFn: async () => {
      const data: UserSummary[] = await getAllUsers()
      return data
    },
  })
}

export default useGetAllUsers

// 시도한 방법들 - reload 하기 
return (
    <form
      onSubmit={handleSubmit(async (data) => {
        try {
          await editProfile(data)
          setCurrentName(data.fullName)
          notify('success', '닉네임이 수정되었습니다.')
          setValue('fullName', '')
          location.reload()
        } catch (error) {
          notify('error', '닉네임 수정에 실패했습니다.')
        } finally {
          location.reload()
        }
      })}
      style={{ display: 'flex', justifyContent: 'space-between' }}
    >
... 중략 ...

그 외에도 공용적인 부분을 담당하면서 내 코드의 영향력을 실감하게 된 사례들도 있었고, 제한된 api안에서 최대한 원하는 바를 구현하기 위해 로직을 구상했던 일들도 다수 있었다. 수많은 에러와 어려움을 만났지만 그래도 원했던 바는 모두 구현을 나름대로 한 것 같아 다행이었다.

🚀 프로젝트가 끝난 뒤

프로젝트가 끝난 뒤 팀 회고를 하면서 반성회 겸 좋았던 점들을 말하는 시간을 가졌는데 다들 비슷한 생각을 하고 있었다는 것에 조금 놀랐다. 나만 이렇게 생각한 것이 아니었구나 란 생각에 진작 말했으면 좋았을걸 하는 생각도 있었던 것 같다.
가장 아쉬운 점으로 나를 포함해 다들 2가지를 뽑았는데 다음과 같다.

기획

이 부분은 위에서 언급했다시피 다들 아이디어 회의에 지치고, next에 도전한다는 기대감에 관심과 흥미가 모두 개발쪽으로 가 아이디어를 구체화하는 단계를 건너뛴 점에 아쉬움을 느꼈었다. 이 단계를 거치지 않은 만큼 우리 팀의 결과물은 기획부분에서 아쉬움을 보였기 때문이다. 그때당시를 다들 회상하면서 앞으로 있을 최종 프로젝트에서는 꼭 개선해야 겠다며 다짐을 하게 된 계기가 되기도 했다.

소통 & 질문

가장 어려운 문제가 소통과 질문이었다. 다들 고민이 많았던 문제였는데 모르는 것이 있으면 팀원들과 공유하고 다같이 빠르게 해결한다. 이것은 말로나 이론적으로는 쉽지만 실제 실천하기는 쉽지 않았다. 먼저 어떤 것을 어떻게 질문해야 하는지 부터 모르는 경우도 있었다. 즉 너무 포괄적이라 질문하기가 어려웠던 것이다. 이럴 경우 혼자 할 수 있는 데까지 최대한 삽질하는 수밖에 없었다. 이러한 점이 최종 프로젝트 때에는 일단 상황 공유라도 해야겠다는 생각으로 발전했다. 그 외에도 지금까지 들인 시간이 아까워서, 조금만 더 하면 할 수 있을 것 같아서, 질문을 하기 위해서는 질문 내용을 정리해야 하기 때문에 그 시간이 아까워서, 등등 많은 이유가 나왔었다. 모든 의견에 나도 공감하는 바였다. 다만 그 상황을 해결하지 않았기 때문에 우리 팀은 중간 프로젝트때 시간에 쫓기고 삽질을 많이 했던게 아닐까 싶다.
조금 어렵더라도 어떻게 해야할지 모르겠더라도 일단 말이라도 꺼내보는 용기가 필요한 것 같다. 그 외에도 소통과 관련해 소통 방법, 공유 방법, 소통한 내용을 기록으로 남기는 방법 등 많은 면에서 좋았던 점도 있고 미흡했던 부분도 있었다. 다만 이러한 것들을 중간 프로젝트를 경험삼아 최종 프로젝트 때에서 반복하지 않는다면 충분히 그것만으로도 의미가 있었던 것 같다.

깃허브 링크
배포 링크