1주차 화요일 미팅: 초기 개발 환경 세팅 (10.28)

[KingNono1030]

회의에서 다룬 내용

• 관련 문서
  개발 환경 세팅(10.28) 고려사항 #2 문서를 기반으로 초기 개발환경 세팅 진행
  [CHORE] 초기 개발환경 세팅 (Next + 필수 패키지) #4 이슈에서 작업

프로젝트 구조 및 폴더링

• 폴더 구조 설정: 공용 컴포넌트, 페이지, 훅, 상태 관리 등 주요 파일을 용도에 따라 명확히 구분

📂 src
├── 📂 app                # Next.js의 App Router 폴더
│   ├── 📂 (routes)       # 라우트 그룹
│   │   ├── 📂 home       # 메인 페이지 (루트 페이지)
│   │   │   └── page.tsx
│   │   ├── 📂 about      # 서브 페이지 예시
│   │   │   └── page.tsx
│   │   └── layout.tsx    # 전체 앱의 레이아웃
│   └── 📂 api            # API 라우트 (예: Next.js 서버 구성 요소)
│       └── user
│           └── route.ts

기본 앱라우팅 앱 디렉토리 내부

├── 📂 components         # 공용 컴포넌트
│   ├── 📂 common
│   │   └── 📂 Button
│   └── 📂 user
│   │   └── 📂 �UserProfile

컴포넌트 디렉토리

@yongb2n

common: 공통 컴포넌트 -> 도메인 맥락 없는, 쪼갤 수 없는 가장 작은 단위의 컴포넌트
[domain] 컴포넌트 -> 도메인 맥락이 있고 하나 이상의 기능을 수행하는 컴포넌트

@KingNono1030

shared -> 여러 도메인 및 페이지에서 공통으로 사용되는 컴포넌트, 공통 컴포넌트의 조합으로 만들어짐
컴포넌트 디렉토리의 경우 아토믹 디자인 패턴 적용 여부에 따라 추가 논의가 필요할 수 있습니다!

• 아토믹 디자인(Atomic Design) 소개 #9

├── 📂 services              # api 호출 함수
│   └── 📂 api
│       └── auth.ts
│       └── user.ts

@yongb2n 님의 소개

• 폴더 구조 관련 제안 (10.28) #5

lib > api 디렉토리를 쓰는 경험에 대해서도 나누었으나, lib 에는 라이브러리 관련된 내용들만 담아야 한다는 의견
services 디렉토리에서 api 함수들을 관리하는 방법

├── 📂 hooks              # 커스텀 훅
│   └── useFetch.ts
├── 📂 stores              # 상태 관리
│   └── userStore.ts
├── 📂 utils              # 유틸리티 함수
│   └── formatDate.ts
├── 📂 styles             # 전역 스타일링 파일
│   └── globals.css
└── 📂 types              # 타입 정의
    └── user.types.d.ts

이 외에는 이미 익숙한 방식으로 진행하면 좋을 것 같고, 추가 의견 있다면 제안 discussions 을 활용하여 소통합시다 !

• 컴포넌트 구조 정의: 재사용 가능한 공통 컴포넌트와 페이지별 컴포넌트를 미리 나누어 정의

이 부분은 수요일에 마저 논의가 이루어져야 할 것 같습니다. -> 사전 컴포넌트 분석 요구

코드 스타일 및 규칙 설정

• 코드 스타일 통일: ESLint와 Prettier를 함께 설정해 코드 스타일을 통일. Airbnb, Standard, Google 등 규칙 중 하나를 선택

AirBnb lint 룰 적용
prettier 는 추가 플러그인 적용 필요 (import sort, tailwindcss)

• 컨벤션 가이드 작성: 커밋 메시지, 파일 및 폴더 이름 규칙 등을 명확히 정의하고, 이를 팀과 공유. 예시) 커밋 메시지에 Gitmoji를 추가하거나, 메시지 앞에 작업 타입을 붙이는 방식.
• 컨벤션 가이드 #3 컨벤션 가이드 공지

Git 워크플로우 전략

• 브랜치 전략: main, develop, feature/기능명 브랜치를 활용한 Git 전략을 미리 정하고, 병합 시 PR 리뷰를 필수로 하는 규칙을 정해 협업의 일관성을 유지.

main ← dev ← feature/기능명

브랜치 타입	설명	예시
feature	새로운 기능 개발	feature/user-profile
fix	버그 수정	fix/validation-error
hotfix	긴급 수정	hotfix/logout-issue
refactor	코드 리팩토링	refactor/update-logic
chore	설정 수정, 패키지 업데이트 등	chore/update-eslint
docs	문서 작업	docs/update-readme

@KingNono1030

브랜치의 생명주기는 pr의 머지됨에 따라 종료
브랜치 생성의 경우 remote 에서 진행함을 권장

• GitHub Discussions 활용: 코드 리뷰, 버그 수정, 기능 추가 등 커뮤니케이션을 GitHub Discussions에 기록해 협업의 흐름을 문서화.

상태 관리 설정

• Zustand 세팅: 각 상태의 역할을 명확히 구분하여 전역 상태와 로컬 상태를 적절히 관리. 전역 상태는 인증 상태, 사용자 정보 등을 담고, 컴포넌트 간 독립적인 상태는 컴포넌트 내부 상태나 React Hook Form으로 처리.

Persist 미들웨어: 상태를 로컬 스토리지 등에 저장하여 새로고침 후에도 상태를 유지하려면 zustand/middleware의 persist를 사용할 수 있습니다.

환경 변수 관리

• 환경 변수 세팅: .env 파일을 활용해 API 키, 서버 URL 등 민감한 정보를 관리. .env.example 파일을 생성하여 개발 환경에 필요한 변수들을 명시.

@yongb2n

.env 자체를 gitignore 에 넣는게 아닌, 민감한 정보는 env local 에서 관리하는게 일반적

패키지 설치 및 스크립트 설정

• 필수 패키지 설치: 프로젝트에서 사용할 주요 패키지 (React Hook Form, Tailwind CSS, Zustand 등)를 설치하고 기본 설정을 완료.

@KingNono1030

• [CHORE] 초기 개발환경 세팅 (Next + 필수 패키지) #4 이슈
• [#4] 📦️ 필수 패키지 (hookform, zustand, jest, tanstackquery) 설치 #6 pr

chore/package-setup 브랜치에서 패키지, 의존성 관련 작업을 전담해서 관리
pnpm 채택

• 스크립트 설정: package.json에 개발 및 빌드 스크립트를 추가하여, npm run dev, npm run build 등의 명령어로 쉽게 프로젝트를 실행하고 배포 가능.

@KingNono1030

pnpm add, pnpm run dev, pnpm run build ...
추가로 스크립트 설정이 필요한 경우 논의

CI/CD 설정

• 자동화된 테스트와 배포: GitHub Actions 또는 Vercel을 사용해 커밋 시 자동 빌드 및 테스트가 실행되도록 설정하여 코드 안정성을 확보할 수 있습니다.

@KingNono1030

dev 브랜치는 실시간으로 vercel 을 통해 배포 및 빌드 체크
main 브랜치의 경우 aws 로 배포 도전하는게 어떨까 -> aws 경험이 미숙하기 때문에, 당장 개발 단계에서는 vercel

• 배포 환경 세팅: Vercel 또는 Netlify에 프로젝트를 연결해, main 브랜치에 머지될 때마다 자동으로 배포되도록 설정하면, 변경 사항을 빠르게 확인할 수 있습니다.

개발 서버 및 테스트 환경 설정

• 로컬 개발 서버 세팅: 서버와 프론트엔드 간 로컬에서 API 요청을 테스트할 수 있도록 proxy 설정을 추가해 두면 유용.

@KingNono1030

당장은 필요 없어 보임, 백엔드 api 서버와 프론트엔드 개발 환경이 다르기 때문에, 로컬 환경에서도 fetch api 활용 가능할 것으로 보임

• 테스트 라이브러리 설정: Jest와 React Testing Library를 설치해 단위 테스트와 통합 테스트가 가능하도록 미리 세팅하면 테스트 환경 구축이 용이.

@KingNono1030

단위 테스트의 경우 학습이 요구되기 때문에 공부를 해보고 공유하겠습니다.

추가 논의가 필요한 내용

• 아토믹 디자인 패턴 적용 여부
• http requests 라이브러리 선택 (axios vs ky)

[KingNono1030]

📝 GPT 피드백

1. 누락된 내용 확인

초기 개발 환경 세팅과 관련한 필수 요소들이 대부분 포함되어 있지만, 다음과 같은 사항이 추가로 논의되거나 더 명확히 하면 좋을 부분이 있습니다.

• 환경 변수 관리 방식

  • .env 파일과 .env.local 파일의 역할을 명확히 구분하고, 민감한 정보 관리 방식을 정의하면 좋습니다. 예를 들어, .env는 예시 파일로만 사용하고 실제 값은 .env.local에 두며 gitignore에 포함하는 방식으로 관리할 수 있습니다.

• Zustand 설정에 대한 구체적 논의

  • 전역 상태와 로컬 상태 구분은 논의되었지만, 실제 전역 상태를 어떻게 관리할지, persist 미들웨어를 사용할 시 고려할 사항 등이 논의되지 않았습니다. 전역 상태의 구체적 예시를 공유하고, persist 사용 시 주의사항을 추가로 다루면 좋겠습니다.

• CI/CD의 상세한 설정

  • main 브랜치는 AWS로, dev 브랜치는 Vercel로 배포하는 계획이 논의되었으나, AWS 배포에 필요한 구체적 단계(예: AWS S3, CloudFront)를 명확히 하거나, Vercel 설정을 보다 상세히 논의하는 것이 좋겠습니다.

---

2. 추가 논의가 필요한 사항

• 아토믹 디자인 패턴 적용 여부

  • 아토믹 디자인 패턴을 적용할지 여부를 확정할 필요가 있습니다. Atoms, Molecules, Organisms 등으로 계층화할 경우 컴포넌트 폴더 구조가 어떻게 변경될지 논의해보면 좋습니다. 아토믹 디자인 패턴과 도메인 맥락에 따른 컴포넌트 구분을 함께 적용하는 방안도 고려해보세요.

• HTTP 요청 라이브러리 선택 (axios vs ky)

  • 라이브러리 선택 기준을 명확히 하고, 프로젝트에 더 적합한 라이브러리를 선택할 필요가 있습니다. 예를 들어, Axios는 널리 사용되는 확장성과 문서 지원이 강점이고, Ky는 가벼운 API가 강점입니다. 라이브러리의 장단점을 비교하고 선택한 경우 예시와 함께 팀에 공유하면 좋습니다.

• Prettier 추가 설정 및 Import 정렬 규칙

  • AirBnB 스타일과 함께 사용할 Prettier 설정을 명확히 하고, Import 정렬 규칙을 통일해 코드 일관성을 유지하면 좋습니다. Import 순서를 자동 정렬하는 플러그인 (예: eslint-plugin-import-order) 설정 여부를 논의할 수 있습니다.

• 테스트와 관련한 학습 세션

  • Jest와 React Testing Library를 팀원들이 처음 사용한다면, 기초적인 테스트 작성법과 Jest 설정을 공유하는 세션을 진행하는 것이 좋습니다. 추가로 앞으로의 작업에서 어떤 테스트가 필요한지, 간단한 테스트 가이드라인을 마련해보세요.

• 배포 전략과 테스트 전략 통합

  • 현재 Vercel과 AWS로 배포를 계획하고 있으므로, 테스트 및 빌드 자동화 설정을 통합하는 방법에 대해 논의가 필요합니다. 예를 들어, Vercel의 dev 브랜치 빌드 시 테스트 자동화 설정을 추가하고, AWS 배포에 필요한 사전 테스트 단계를 고려해볼 수 있습니다.