
## Contents

# 개요

이번 프로젝트에서는 MSW의 적극 활용과 에러 및 로딩 처리 등 더 완성도 있는 시스템을 갖추고자 노력했다. 설계한 몇 가지 포인트에 대해 기록해 보고자 한다.

# MSW를 이용한 병렬적 개발 일정 확보

## 개요

이번 프로젝트는 백엔드와 같은 개발 일정으로 진행되었다. 때문에 API 릴리즈에 맞춰 프론트엔드 개발 일정을 진행하기에는 이에 의존적이 될 뿐더러, 정확히 맞지 않는 부분도 존재했다.

가볍게 더미데이터를 상수화해서 작성해두고 출력할 수도 있지만, 나중에 실 API 연결에서 엣지 케이스 및 미비한 비동기 처리가 발견될 확률이 높다.

- MSW를 사용하지 않은 공통 개발 일정

![231218-162326](</posts/나비장터_회고(2)-개발/231218-162326.png>)

- MSW를 사용한 공통 개발 일정

![231218-162333](</posts/나비장터_회고(2)-개발/231218-162333.png>)

우리는 위와 같이 MSW를 통해 명세를 기반한 mock API를 작성하며 개발했다. 이를 통해 독립적인 개발 일정을 확보하고, 그때그때 적절한 비동기 에러 및 로딩 처리를 할 수 있었다.

# 프론트엔드 빌드 및 배포 아키텍쳐

![231218-162340](</posts/나비장터_회고(2)-개발/231218-162340.png>)

husky를 통해 로컬에서 사전 빌드, 테스트 코드 및 lint 유효성을 확인한다.

github에서 actions를 통해 main, develop 브랜치 대상 빌드, 테스트 유효성을 우선 확인하고 코드 리뷰를 진행하도록 했다.

이후 merge되면 스토리북과 vercel에 변경 내용을 자동 배포하여 오류를 최소화하고 결과물을 빠르게 확인할 수 있는 CICD 아키텍쳐를 구성했다.

# NextJS에서 FetchAPI와 에러 및 로딩 처리

## 자체 확장 Fetch 클래스 사용

NextJS에서 axios 등의 서드파티 라이브러리를 사용하면 캐싱 정책 등을 따로 적용해야 하는 수고가 있다.

때문에 NextJS 공식 문서에서도 이를 권장하지 않고, 기존 fetch를 확장한 형태를 사용하기 때문에 fetch를 사용하는 것이 좋다.

```tsx
...

class FetchAPI {
  private baseURL: string
  private headers: { [key: string]: string }

  private static instance: FetchAPI

  private constructor() {
    this.baseURL = ''
    this.headers = {}
  }

	// singleton으로 중복 방지
  public static getInstance(): FetchAPI {
    if (!FetchAPI.instance) {
      FetchAPI.instance = new FetchAPI()
    }
    return FetchAPI.instance
  }

  public setBaseURL(url: string): void {
    this.baseURL = url
  }

  public setDefaultHeader(key: string, value: string): void {
    this.headers[key] = value
  }

	...

  public async post(
    endpoint: string,
    body: any,
    nextInit: RequestInit = {}, // NextJS의 config를 사용할 수 있도록 추가
    customHeaders: { [key: string]: string } = {},
  ): Promise<any> {
    const response = await fetch(`${this.baseURL}${endpoint}`, {
      method: 'POST',
      headers: { ...this.headers, ...customHeaders }, // 공통 옵션 사용
      body: body instanceof FormData ? body : JSON.stringify(body),
      ...nextInit,
    })

    return this.responseHandler(response)
  }

...
```

때문에 `FetchAPI.ts` 에 싱글톤 클래스를 생성해 기존 axios 등에서 누리던 공통 헤더 및 baseUrl 기능 등을 사용하면서도 NextJS에서 권하는 옵션을 사용할 수 있도록 자체적으로 확장했다.

```tsx
// apiClient.ts
import { Environment } from '@/config/environment'
import FetchAPI from '@/lib/fetchAPI'

const apiClient = FetchAPI.getInstance()
apiClient.setDefaultHeader('Content-Type', 'application/json')
apiClient.setBaseURL(Environment.apiAddress())

export default apiClient
```

위처럼 미리 인스턴스를 공통적으로 필요한 설정과 함께 생성하여 활용할 수 있었다.

각 호출에 필요한 함수는 미리 정의해서 사용했다.

```tsx
import ApiEndPoint from '@/config/apiEndPoint'
import apiClient from '../apiClient'

const getTest = async () => {
  const response = await apiClient.get(
    ApiEndPoint.test(),
    { next: { revalidate: 10 } },
    { Authorization: 'Bearer ' },
  )
  return response
}

export { getTest }
```

위에서 생성한 apiClient를 불러와 쉽게 정의할 수 있었다.

## 에러 처리

fetchAPI의 구현을 보면 get, post, put, delete 등의 http 메서드의 return에서 `responseHandler` 를 거치는 것을 확인할 수 있다.

![231218-162403](</posts/나비장터_회고(2)-개발/231218-162403.png>)

이는 아래와 같은 형태로 구현했다.

![231218-162410](</posts/나비장터_회고(2)-개발/231218-162410.png>)

- response를 확인하고 이의 status를 확인해 각 케이스에 맞는 커스텀 에러로 throw한다.
- 각 커스텀 에러는 케이스에 맞는 에러 메세지와 함께 사전에 정의해두었다.

이는 곧 전역 또는 지역 단위의 ErrorBoundary로 전파된다. 실제 구현은 NextJS13의 error 템플릿을 통해 작성하여 명확한 모듈 단위의 목적 분리가 용이했다.

`error.tsx` 를 작성하면 자동으로 해당 위치의 layout을 ErrorBoyndary로 래핑한다. 다음과 같은 구조로 이해할 수 있다.

![231218-162422](</posts/나비장터_회고(2)-개발/231218-162422.png>)

https://nextjs.org/docs/app/building-your-application/routing/error-handling

각 에러 컴포넌트는 throw된 error를 받아 적절한 화면 또는 리다이렉팅을 처리하도록 했다.

![231218-162429](</posts/나비장터_회고(2)-개발/231218-162429.png>)

위 코드와 같이 렌더링 과정에서 일어난 문제에 대한 알맞은 화면을 제공한다.

## 접근 제한

또한 접근할 수 없는 페이지를 사전에 차단하기 위해 서버 사이드에서 middleware를 거쳐 이를 처리하도록 했다. 이를 통해 비인가 사용자가 페이지에 처음부터 접근할 수 없도록 하거나, 사전에 로그인 페이지로 이동하도록 했다.

![231218-162436](</posts/나비장터_회고(2)-개발/231218-162436.png>)

## 로딩 처리

React의 Suspense를 NextJS13에서는 `error.tsx`를 활용하듯 `loading.tsx`로 처리할 수 있다.

NextJS에서는 특히 SSR을 활용할 때 서버로부터 html을 전달받기까지의 시간이 추가로 요구된다. 중간 프로젝트에서 이를 처리하지 않아 클릭 후 html 수신까지의 시간 동안 아무 반응이 없어 사용자에게 혼동을 준 문제가 있었다.

loading을 적절히 두어 로딩 화면을 보여주도록 했다.

https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming

## 전체 구조

![231218-162445](</posts/나비장터_회고(2)-개발/231218-162445.png>)

다음과 같은 구조를 통해 허용되지 않은 컨텐츠를 사전에 노출되지 않도록 처리하고, 런타임 중 생기는 로딩과 에러를 효율적으로 처리할 수 있도록 했다.

# headless한 공통 컴포넌트 구조

tailwind를 통해 효율적인 공통 컴포넌트 구조를 생성하고자 했다.

## 문제

![231218-162452](</posts/나비장터_회고(2)-개발/231218-162452.png>)

다음과 같이 특정 스타일을 변수로 관리하고 이를 주입해 사용하는 것은 적절하다고 볼 수 있으나, 타입 시스템의 추천 기능과 공통 사항을 관리하거나 다른 종류의 스타일 조각들을 관리함에 있어 불편을 야기한다.

## 해결

![231218-162500](</posts/나비장터_회고(2)-개발/231218-162500.png>)

![231218-162506](</posts/나비장터_회고(2)-개발/231218-162506.png>)

cva를 통해 기본 스타일과 선택적 style prop을 지정하고, twmerge와 clsx를 결합하여 조건부 스타일 및 중복 스타일을 조정하도록 했다.

![231218-162513](</posts/나비장터_회고(2)-개발/231218-162513.png>)

이를 통해 정의해 둔 스타일과 추가로 주입하고 싶은 스타일을 자유롭게 활용할 수 있다.

![231218-162522](</posts/나비장터_회고(2)-개발/231218-162522.png>)

- 해당 방식은 공용 컴포넌트를 커스텀하고, 수정하는데에 높은 자유도를 제공한다.
- 사진과 같이 타입 시스템에도 친화적인 방식을 제공하기 때문에 이를 적극 활용했다.

![231218-162529](</posts/나비장터_회고(2)-개발/231218-162529.png>)

# Form 관리

![231218-162536](</posts/나비장터_회고(2)-개발/231218-162536.png>)

Form을 효율적으로 관리하고 다양한 형태에서 활용하기 위해, Input을 받고 보이는 부분과 validation 모듈, hook을 통해 비동기 통신과 상태를 관리하는 세 가지 영역으로 나눠서 구현했다.

![231218-162546](</posts/나비장터_회고(2)-개발/231218-162546.png>)

위와 같이 Template은 hook으로 부터 필요한 상태만 전달받는다.

각 컴포넌트는 form의 상태를 통해 input을 갱신하거나, validation 실패에 대한 에러 메세지를 전달받을 수 있다.

![231218-162556](</posts/나비장터_회고(2)-개발/231218-162556.png>)

hook은 서버와의 통신 및 이후 처리 등을 담당한다. 여기서 에러 및 로딩에 대한 처리 등을 해줄 수 있다.

![231218-162607](</posts/나비장터_회고(2)-개발/231218-162607.png>)

![231218-162612](</posts/나비장터_회고(2)-개발/231218-162612.png>)

validation은 appValidation을 통해 사전에 정의한 zod 메서드를 통해 이루어진다.

이는 어떤 이점이 있을까?

![231218-162621](</posts/나비장터_회고(2)-개발/231218-162621.png>)

한 서비스에서는 보통 특정 필드에 대한 같은 validation 기준을 공유한다. 이를 일일이 react hook form에서 처리하면 중복 코드가 생기고, 기준이 수정될 때 불편함을 야기할 수 있다.

위와 같이 validation 기준을 zod 메서드를 통해 사전에 정의해 둔 뒤 이를 필요한 hook에 사용하면 그런 불편함을 효과적으로 해소할 수 있으며, 또한 타입 친화적인 이점도 챙길 수 있다.

# 서버 컴포넌트 관련된 문제 사항

NextJS의 SSR은 생각보다 여러 기능들에서 추가적인 접근 방식에 고려를 요한다. 최근 여러 NextJS 기반 프로젝트를 진행하면서 줄곧 깨닫고 있다.

이번 프로젝트에서 있었던 문제들을 기록해보자.

## MSW 서버 initialize 문제

NextJS13은 기본적으로 서버 렌더링으로 동작한다. CSR로 호출하는 경우에는 문제가 없었으나, SSR로 처리되는 경우에는 mock server가 initialize되기 전에 함수가 호출되어 mock route를 인식하지 못하는 문제가 있었다.

### 해결

```tsx
'use client'

import { useState, type PropsWithChildren, useEffect } from 'react'
import { Environment } from '@/config/environment'

const isMockingMode = Environment.apiMocking() === 'enabled'

const MSWComponent = ({ children }: PropsWithChildren) => {
  // mocking을 활성화하지 않았다면 바로 children을 return하기 위함
  const [mswReady, setMSWReady] = useState(() => !isMockingMode)

  useEffect(() => {
    // msw 실행 메서드를 lazy load
    const init = async () => {
      if (isMockingMode) {
        const initMocks = await import('../lib/msw/initMockApi').then(
          (res) => res.initMockApi,
        )
        await initMocks()
        setMSWReady(true) // mock server 실행 완료
      }
    }

    if (!mswReady) {
      init()
    }
  }, [mswReady])

  if (!mswReady) return null

  return <>{children}</>
}

export default MSWComponent
```

MSW 활성화 시 전역에 wrapper를 두어 렌더링 이전에 MSW가 활성화 될 수 있도록 하였다.

## 인증이 필요한 API 요청

```tsx
const token = accessToken
if (token) {
  apiClient.setDefaultHeader('Authorization', token)
  return getValidateUser()
}
```

인증(header에 jwt 토큰을 담아 요청하는)이 필요한 요청의 경우 로그인 시 fetchAPI 클래스에 해당 토큰을 공통 헤더로 설정하기 때문에 별도의 코드가 필요하지 않았다.

```tsx
const AuthProvider = ({ children }: { children: React.ReactNode }) => {
  const { isLoggedIn, currentUser } = useValidate()

  const contextValue = useMemo(
    () => ({ isLoggedIn, currentUser }),
    [isLoggedIn, currentUser],
  )

  return (
    <AuthContext.Provider value={contextValue}>{children}</AuthContext.Provider>
  )
}
```

또 로그인 여부와 유저의 간단한 정보가 전역에서 context로 전달되기 때문에 필요 시 이를 사용하면 됐다.

문제는 SSR 시에 이 공통 헤더가 아직 지정되지 않은 상태라 인증 에러가 나타난다는 것이었다.

### 해결

토큰을 쿠키에 저장해 활용하고 있었는데 `next/headers` 를 통해 서버에서 쿠키 정보를 얻어올 수 있었다.

```tsx
import { cookies } from 'next/headers'
import { Environment } from '@/config/environment'

const getServerCookie = () => {
  const cookieStore = cookies()
  const token = cookieStore.get(Environment.tokenName())

  return token?.value
}
```

위와 같이 서버 컴포넌트에서 토큰 정보를 얻는 메서드를 작성했다.

```tsx
const getUserInfo = async (): Promise<User> => {
  const token = getServerCookie()
  const res = await apiClient.get(
    ApiEndPoint.getValidateUser(),
    {},
    {
      Authorization: `${token}`,
    },
  )
  return res.data.userInfo
}
```

SSR 요청에서는 다음과 같이 토큰 정보를 추가해 줄 수 있도록 했다.

## Refresh Token 로직

refresh token 기능을 통해 access token을 갱신하는 과정에서 예상치 못한 문제가 있었다.

![231218-162641](</posts/나비장터_회고(2)-개발/231218-162641.png>)

처음 구현은 위에서 활용한 auth context 내에서 useEffect와 tanstack query를 활용해 access token의 만료를 확인하면 refresh token을 통해 갱신이 이루어지도록 했다.

![231218-162649](</posts/나비장터_회고(2)-개발/231218-162649.png>)

문제는 access token이 만료된 상황 + SSR이 있는 페이지에 최초 접속할 경우, 서버에서는 hook이 작동하기 이전에 요청이 이루어지기 때문에 refresh token이 유효함에도 갱신하지 못하고 에러 처리가 이루어졌다.

### 시도

처음에는 위에서 구현한 `getServerCookie`에서도 토큰이 유효한지 여부를 검증하는 추가 로직을 통해 유효하지 않을 경우 refresh 요청을 통해 토큰을 갱신하는, 클라이언트와 같은 로직을 통하도록 했다.

문제는 cookie의 set()은 server component에서 불가능하다는 것이다. Server Action 또는 Route Handler를 통해서만 처리될 수 있었다(https://nextjs.org/docs/app/api-reference/functions/cookies#cookiessetname-).

애초에 백엔드 응답에서 cookie를 set 해주면 될 터였지만, 해당 기능이 구현되어 있지 않았고 토큰만 보내주는 형태였다. 추가 수정을 요청할 수 있는 상태가 아니었다.

### 해결

일단 해당 경우에 에러 페이지를 통하도록 했다. 이후 클라이언트 hook이 init되고 auth hook에서 refreshToken이 확인될 경우 토큰 및 로그인, 유저 정보를 갱신하여 최초에 새로고침 처리가 되도록 방식을 수정했다.

물론 api 응답에서 cookie를 설정해주는 것이 가장 효과적인 방식이지만, api 스펙이 이를 충족하지 못 할 경우 client에서 갱신 후 새로고침을 통해 토큰을 갱신하면 간단한 방식으로 문제를 해결할 수 있다.

reissue가 잦게 일어나지 않기 때문에 해당 방식으로 처리했지만, 다른 경우에는 무조건 새로 고침을 강제하는 것은 사용자 경험에 치명적일 수 있을 것 같다.

# 회고

## 잘한 점

- NextJS의 각종 기능을 활용해 봄
  - Intercepting route, loading, error, middleware, 폰트, 이미지 최적화 등
- 적절한 에러 및 로딩 처리에 투자
- 공통 문제를 해결하고자 노력하고, 이를 공유함
- 이유 있는 기술만을 활용
  - 불필요한 전역 상태를 추가하지 않음

## 아쉬운 점

- 타입 정의, 폴더명 컨벤션 등을 초반에 챙기지 못해 불필요한 시간 소요
- 백엔드에 미리 문제될 만한 부분을 확인해주지 못함
  - CORS 이슈에 대한 백엔드 설정
  - OAuth 방식에 대해 잘못 이해하고 있는 부분을 조금 더 빨리 알려줄 수 있었을 듯

# 관련 링크

- 나비장터: [https://nabi-market-client.vercel.app](https://nabi-market-client.vercel.app/)
- 깃허브: https://github.com/team-nabi/nabi-market-client


나비장터 회고(2)-개발


## Contents

# 근황

10~12월은 나비장터 프로젝트를 진행했다. 저번 중간 프로젝트에서 아쉬웠던 기획적인 부분과 NextJS에서 권장하는 기능들을 더욱 제대로 사용해보자는 의도가 있었다.

이번 프로젝트는 백엔드 3명, 프론트엔드 3명으로 처음부터 끝까지 새로 모든 것을 만드는 과정이었다.

# 나비장터 소개

나비장터는 기존 중고장터에서 경쟁력이 떨어지는 애매한 가치의 물건들을 물물교환 형태로만 제한하여 거래하는 물물교환 거래 서비스이다.

물물교환의 특성을 십분 활용하기 위해 등록된 물건을 바탕으로 거래를 제안하고 수락한 후에 채팅 등의 소통이 가능하도록 했다. 이를 통해 사용자에게 불필요한 소통 비용을 줄이고, 마치 서로의 패를 교환하는 느낌으로 소소한 재미 포인트를 주려 의도했다.

# 타임 테이블

![231218-162113](</posts/나비장터_회고(1)-개요_및_소통/231218-162113.png>)

- 10.12~10.22: 기획, 디자인 작업
- 10.23~10.29: 개발 환경 설정 및 기초 세팅
- 10.30~11.05: 공통 컴포넌트 개발
- 11.06~11.12: 카드 리스트 조회, 인증 및 인가
- 11.13~11.19: 카드 업로드 및 수정, 거래 관련 기능
- 11.20~11.26: 채팅, 인기 게시글 기능, API 연결 및 에러 처리
- 11.27~12.03: QA 및 추가 에러 처리, 성능 최적화

# 역할

나는 이번 프로젝트에서 로컬 작업으로부터 배포까지 이어지는 전체적인 과정의 설정, MSW와 백엔드와의 통신, NextJS의 여러 기능에 대한 기초 설정, 인증 및 인가 처리, 카드의 업로드 및 수정, 마이페이지, 채팅의 구현을 했다.

또한 프론트엔드 팀의 스케쥴을 맞추기 위한 스프린트 및 각자의 테스크를 분배하는 역할을 주도했다.

# 스프린트 및 협업

## 문서화

기본적으로 노션에 여러 카테고리를 만들어 문서화를 진행했다. 다만 몇 가지의 예외를 두었다.

1. 백엔드 및 전체적인 공유가 필요한(할 수 있는) 내용은 슬랙으로 공유하되, 노션의 버그 템플릿을 작성하여 공유하기
2. 프론트엔드 내에 공통적인 개발 공유 사항 및 에러는 Github의 Wiki와 Discusstions 활용하기

특히 [Wiki](https://github.com/team-nabi/nabi-market-client/wiki)를 작성하여 공유한 것은 좋은 경험이었다. 관련 질문이 있을 때 링크를 전달하여 소통이 간결해 진 점이 기본이지만, 스스로도 까먹은 부분을 다시 확인할 수 있었고 또 후에 누군가 프로젝트에 참여하거나 내 구현의 의도를 파악할 때 쉽게 할 수 있을 것이다.

## 스프린트 및 스토리

![231218-162128](</posts/나비장터_회고(1)-개요_및_소통/231218-162128.png>)

스프린트는 디자인과 기획을 바탕으로 스토리를 작성하고 이를 세부 테스크로 나누어 각 스토리 포인트를 팀원들과 함께 의논하여 나누는, 저번과 비슷한 방식으로 진행했다.

## Jira

![231218-162136](</posts/나비장터_회고(1)-개요_및_소통/231218-162136.png>)

다만 이번에는 백엔드와의 현황 공유도 쉽게 할 겸 + 깃과 슬랙에서 티켓도 활용하며 할 겸 해서 Jira를 활용했다.

예전에 회사에서 Jira를 도입하자고 할 때는 매우 어려워 많은 학습이 필요하다는 이야기가 많았는데, 사용하다 보니 그렇게 어렵지도 않고 장점도 많은 것 같다.

## 백엔드와의 소통

![231218-162143](</posts/나비장터_회고(1)-개요_및_소통/231218-162143.png>)

API 명세와 이의 관리가 가장 중요했다. API 및 DB 스키마 설계에 적극적으로 참여해서 같은 기획적 이해를 공유하고자 했다. 또한 문서를 바탕으로 변경 및 요청 사항을 공유할 수 있도록 했다.

![231218-162149](</posts/나비장터_회고(1)-개요_및_소통/231218-162149.png>)

```bash
{
    "code": "SUCCESS",
    "message": "성공하였습니다.",
    "data": {
        "cardList": [
            {
                "cardId": 4,
                "cardTitle": "string",
                "itemName": "string",
                "priceRange": "PRICE_RANGE_ONE",
                "thumbnail": "썸네일이미지",
                "status": "TRADE_AVAILABLE",
                "createdAt": "2023-11-15T17:18:40",
                "modifiedAt": "2023-11-15T17:18:40"
            }
        ],
        "nextCursorId": "2023111517184000000004"
    }
}
```

위와 같이 요청, 응답 등을 공유하여 최신화 등을 그때그때 요청할 수 있도록 했다.

## 주간 회고 등

![231218-162159](</posts/나비장터_회고(1)-개요_및_소통/231218-162159.png>)

데일리 통합 스크럼 및 주간 회고를 통해 진행 상황 공유와 아쉬운 부분이 빠르게 논의될 수 있는 시간과 장소를 만들었다.

일례로 슬랙과 카카오톡을 목적 구분 없이 혼동해서 사용해 문제가 있었는데, 이를 주간 회고에서 공유하여 일상적 목적 또는 급한 호출에만 카카오톡을 사용하도록 구분하고 슬랙 소통에 대한 추가 룰을 만들어 프로젝트 마무리까지 소통을 명확하게 유지할 수 있었다.

# 회고

## 잘한 점

잘한 점은 위에서 기술한 내용들이지만, 이번 프로젝트에서 새로 느낀 점들이 있다.

- 중간 프로젝트에서 기획을 급하게 하여 완성해보니 불필요한 기능이 있었는데, 이번 프로젝트에서는 이에 투자하여 그런 부분이 없이 담백하게 완성할 수 있었다.
- 팀원들의 의견 존중하기
  - 몇몇 기능들을 개발함에 있어서 팀원들과 다른 의견이 꽤 있었다. 이에 중간점을 타협하여 진행함을 통해 프로젝트 기한에 맞춰 기능을 완성할 수 있었다.
- 의지 북돋아주기
  - 이 부분은 스스로 잘 했다기 보다는 팀원들에게 감사한 점인데, 서로 할 수 긍정적인 언사를 반복해서 전체적인 분위기를 좋게 만들 수 있었다. 사소해 보여도 이 부분이 없었다면 프로젝트가 지금처럼 잘 되지는 않았을 것 같다.

## 아쉬운 점

- 팀원들의 이해 진도가 맞지 않았던 부분
  - 초기 기획 및 기초 개발 과정에서 많은 회의가 필요했다. 이 때 집중도가 떨어지면 내용을 놓치기 마련인데, 이 때문에 반복해서 과거 내용을 끌고 온 경우가 몇 있었다.
  - → 명시적으로 회의록, 문서에 읽음을 체크하는 양식 등을 설정하면 좋았을 것 같다.
- 때문에 기획 시간이 다소 길어졌던 점
  - 중간 프로젝트에서의 아쉬움으로 기획을 탄탄히 하고자 했으나, 이번에는 하루이틀 더 소요되었다.
  - 물론 급하게 하는 경우보다는 좋으나, 이전 개선 사항 등을 통해 불필요한 소통을 줄여 필요한 정도의 시간만 투자됐으면 좋았을 것이다.

# 관련 링크

- 나비장터: [https://nabi-market-client.vercel.app](https://nabi-market-client.vercel.app/)
- 깃허브: https://github.com/team-nabi/nabi-market-client


나비장터 회고(1)-개요 및 소통


## Contents

# 근황

9월에는 데브코스의 중간 팀 프로젝트가 있었다.

이 달 내내 프로젝트만 했으니 내용이 다 관련해서 채워지지 않을까 싶다.

# 중간 프로젝트에 대해…

## 환경

![231003-165947](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-165947.png>)

중간 프로젝트의 과제명은 **API를 활용한 웹 제작**이다.

사실 너무 당연한 내용이라 상세 내용 공개 전까지 뭘까 싶었는데 제공되는 API를 대상으로 자유롭게 프로젝트를 진행하는 것이었다.

팀 자원은 프론트만 5명과 API 제작자와의 소통.

API를 추가하거나 수정할 수 없고, 필요 시 JSON에 내용을 추가해 사용하는 식이다.

기한은 9월 1일~27일.

## 기획

### 목표

API가 한정되어 있고, 기한이 짧다 보니 상세한 시장 조사 등은 생략되었고, 각자 소기의 목표를 설정해 이루고자 하였다.

나는 사용자 경험 측면에서 완성도 있는 서비스 기능을 제공하고자 했다.

### 명명

우리 팀은 각종 거래에 대한 평가와 피드백 공유가 가능한 커뮤니티 사이트를 만들기로 했다.

프로젝트 명은 여러 의견을 취합한 끝에 서비스와 직접적으로 연관된 키워드인 _꿀매_ 에 평가와 관련되며 사용자의 관심을 끌 만한 특이한 어감과 적합한 뜻의 키워드인 중국 송나라 시대의 명판관 _포청천_ 을 결합한 _꿀매포청천_ 으로 정했다.

## 역할

팀에서 NextJS를 사용하기로 했기 때문에 내가 초기 개발 설정을 담당하게 됐다.

또한 이번 프로젝트 진행에서 관련 개발 경험이 상대적으로 많은 나는 일정 배분이나, 공통 사항에 대한 개발 및 리뷰 등을 위주로 역할을 수행하게 됐다.

제공되는 API 외에는 모든 것을 알아서 해야하는 프로젝트이다 보니 초기 역할을 나눌 필요가 있었다.

특히 팀의 전문이 아닌 디자인에 인력을 다수 배정하고, 그 외 문서 담당과 프로젝트 개발 초기 담당을 정했다.

![231003-170004](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170004.png>)

한창 개발이 진행될 때 이전의 역할을 나눈 때에는 당장 필요한 테스크를 두고, 적합성에 문제가 없는 경우는 선호도를 순위 매겨 불만을 최소화 할 수 있도록 노력했다.

## 개발 프로세스

### 깃허브 브랜치

위에서 언급한 조건들을 고려해 제안했다.

- 1안
  ![231003-170017](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170017.png>)
  - 개별 personal develop을 두고 스프린트 종료 시 develop에 합치는 루틴
  - 짧은 기간 안에 lean하게 협업하고 공통 컴포넌트를 사용하기 위해 적절치 못한 구조라 생각해 폐기
- 2안
  ![231003-170031](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170031.png>)
  - 각 이슈 별로 feature를 두고 develop에 지속적으로 통합.
  - 각 스프린트 별로 진행사항과 기능 구현을 유지할 release 브랜치를 설정하고 버전 1.0을 위한 main 브랜치를 설정
  - 빠른 충돌 해결과 공통 컴포넌트 사용을 위해 깃헙플로우를 약간 변형하여 사용

### 폴더 구조 및 컴포넌트 관리

간단히 서비스 관련 없는 공통 컴포넌트와 서비스 관련 공통 컴포넌트 그리고 지엽적인 컴포넌트를 관리하는 것을 제안했고, 팀원들도 환경을 고려해 이에 공감했으나 아토믹 디자인 패턴을 경험해보고 싶다는 의견이 더러 있었다.

조금 과하다는 생각은 있었지만 팀에 좋은 경험이 될 것 같아 도입하기로 했다. 기본적인 컨셉을 설명하고, 예시를 작성하여 공유했다.

### 스크럼 및 스프린트 룰

- 스크럼

![231003-170048](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170048.png>)

기존 진행하던 데일리 스크럼을 프로젝트 위주의 주제로 사용했다.

- 스프린트

일반적으로 스프린트는 2주에서 4주 정도로 진행하는 것이 일반적이나, 짧은 기한에 맞추어 일주일 단위로 설정했다.

![231003-170100](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170100.png>)

일단 기획과 디자인 틀을 잡고 함께 유저 스토리를 작성했다.

![231003-170107](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170107.png>)

그리고 매 스프린트 시작일에 큰 기능을 정의하고, 이에 해당하는 스토리를 부여했다.

회의 때 하나씩 살펴보며 팀원들이 생각하는 예상 작업 일 수를 산정하고 그에 맞추어 각 인원이 가능한 가용 시간에 맞추어 역할을 부여했다.

![231003-171231](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171231.png>)

이전 과정을 통해 정해진 스프린트의 스토리를 기반으로 이슈를 작성하고, 이슈 넘버를 각 브랜치에 포함해 쉽게 협업자 간 개발 현황 또는 목표를 파악하도록 했다.

![231003-171242](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171242.png>)

때문에 pull request 시에 자연스레 이슈와 해당 내용을 연결 지어 코드 변경 사항의 목적을 처음부터 설명할 필요가 없도록 했다. 때문에 코드 리뷰 간 서비스적인 맥락을 쉽게 파악토록 하고자 했다.

## 신경쓴 내용

이번 프로젝트에서(특히 NextJS를 사용하며) 내가 신경 쓴 부분은 좋은 사용자 경험을 위한 렌더링과 제한된 API를 최대한 커스텀하기 위한 방법이었다.

### NextJS 자체 백엔드를 통해 제한된 API에서 클라이언트 처리가 아닌 서버 처리로 더 많은 기능 제작

![231003-171256](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171256.png>)

- 이번 프로젝트의 조건 한계를 보완하기 위해 기 존재하는 API의 별도 응용을 클라이언트에 부여하지 않고 NextJS 백엔드에 위임함으로써 관심사를 분리하고 쉽게 모듈을 사용하기 위한 노력을 했다.
- 그 응용 사례의 대표적 예시가 ‘싫어요’ 기능 구현이다.

### SSR과 tanstack query prefetch를 통해 주요 화면에 대해 로딩을 노출하지 않고 좋은 사용자 경험 제공

![231003-171312](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171312.png>)

- 메인 페이지는 보다시피 노출하는 컨텐츠 양이 적지 않다.
- 그래서 다음과 같이 사용자의 FCP(First Contentful Paint)에 대해 좋은 경험을 부여하기 위해 전략적인 SSR과 CSR의 내용을 선택했다.
- 최초 사용자의 눈길이 가게 될 내용에 대해 서버사이드 렌더링으로 별도의 로딩 또는 스켈레톤 처리를 하지 않도록 하고, 그 이후에 상세 내용에 대해서 클라이언트 사이드 렌더링으로 전체 내용이 구성될 수 있도록 했다.

_프로젝트에 대한 자세한 발표 내용은 아래 링크에서 확인 가능합니다._

[꿀매포청천 소개](https://www.youtube.com/watch?v=i837NMZmLk8&ab_channel=지그재그)

# 잘한 점

- 기술 제안, 일정 산정 및 배분, 개발 프로세스 관리, 전체적인 개발적 간섭(?)을 하게 됐는데 나름 만족스런 결과물이 나온 것 같다.
  ![231003-171449](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171449.png>)
  - 팀 회고에서도 이 부분에서는 다들 만족스럽다고 해서 뿌듯했다.
  - 갈등도 딱히 없었고, 최대한 그 소지를 줄이고자 했다.
  - 짧은 일정 상 끊을 때 끊는 것을 의도했는데, 안 했으면 일정을 지키지 못 했을 것 같다.
- 팀원에게 맡긴 부분은 확실히 맡기기
  - 팀원에게 각자 challenge가 될 만한 과제를 맡겼다.
  - 나도 누군가의, 누군가도 나의 코드가 만족스럽지 않을 수 있다.
  - 일정 상 모든 개발의 부분을 딥하게 micromanagement 할 수도 없고, 할 필요도 없다.
  - 간섭 대신 자유롭게 어려움을 겪을 때 공유할 수 있는 장소와 시간을 만들고, 리뷰에서 처리할 수 있도록 했다.
  - 이를 사용하지 않는 경우에 대해서는 개인의 책임으로 하도록 의무와 책임을 자유롭게 했다.
- 매 스프린트 종료 시 배포를 통해 버그와 개선 사항을 처리하도록 했다.
- 공통 사항에 대한 공유가 활발히 이루어 진 것 같아 만족스럽다.
- 저번 팀에서의 피드백을 바탕으로 내 작업물 등에 대해 설명할 때 간단한 UML 등을 활용해 더 쉽게 이해할 수 있도록 노력했다.
  ![231003-171504](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171504.png>)

# 아쉬운 점 및 반성

- 세심한 일정 공유가 부족했다.
  - 최대한 일정을 산정하려 해보지만 테스크에 대해 정확한 예측을 하는게 쉽지 않다.
  - 억지로 테스크를 부과하지는 않았지만, 팀원들이 착해서 개인 일정을 고려하지 않고 수용하는 경우가 있던 것 같다.
  - 때문에 매 스프린트에 말미에 급하게 개발이 이루어져 잦은 충돌과 문제를 겪었다.
  - → 배포 일정을 자주 처리하면 조금 더 lean하게 할 수 있지 않을까
- 기술 공유가 부족했다.
  - 급한 때가 됐을 때나 회의가 진행된 이후 모르는 부분을 공유하는 경우가 있어 총 시간이 더 소요됐다.
  - 팀원 분 중에 초기에 NextJS에 대해 간략히 발표회를 연 분이 있는데, 나도 이렇게 했으면 더 원활한 프로젝트가 됐을 것 같다.

→ 위 아쉬움들을 종합해보니 초반에 먼저 상세히 설명회 식으로 열었으면 설명에 대해 집중도 챙기고 한 번에 의문점도 해소하고 갈 수 있지 않았을까 하는 생각이 든다.

- 초기 세팅에서 프로젝트 외의 문제점도 있었다.
  - 기억하기 위해 적자면, 노드 버전이 다르고 안정화 버전이 아닌 최신 버전을 사용해 문제가 생긴 케이스도 있었다. 미리 체크하고 가면 삽질을 조금이나마 줄일 수 있겠다.
- 기획 단계에서 아쉬움
  - 키 포인트를 중심으로 가지를 뻗어나가는 식으로 해야겠다.
  - 디자인에 따라 개발 난이도가 달라짐을 인식해야겠다.

# 관련 링크

- 깃허브

https://github.com/prgrms-fe-devcourse/FEDC4_Price-PCC_DONGYOUNG

- 발표 영상

[꿀매포청천 소개](https://www.youtube.com/watch?v=i837NMZmLk8&ab_channel=지그재그)

- 홈페이지

[꿀매포청천](https://price-pcc.vercel.app/)


write

나비장터 회고(2)-개발

나비장터 회고(1)-개요 및 소통

꿀매포청천 프로젝트 회고