이슈 #1: 사용자단과 백오피스단 프로젝트 분리

1. 이슈 상황

항목 내용
발생 환경 프로젝트 초기 아키텍처 설계 단계
증상 사용자단(Client)과 관리자단(Admin)을 하나의 프로젝트로 구성할지, 분리할지 결정 필요
영향 범위 전체 프로젝트 구조, 배포 전략, 개발 효율성

2. 해결 방안 후보

방안 장점 단점
A. 모노레포 통합 코드 공유 용이, 단일 저장소 관리 빌드 시간 증가, 불필요한 의존성 포함
B. 폴리레포 분리 독립적 배포, 기술 스택 자유도 공통 코드 중복, 저장소 관리 복잡
C. 모노레포 + 패키지 분리 코드 공유 + 독립 빌드 초기 설정 복잡

3. 선택한 해결법

선택: B안 (폴리레포 분리)

jikguround-client     # 사용자단 (Next.js + Turbopack)
├── SEO 최적화 필요
├── SSR/SSG 활용
└── 모바일 퍼스트 디자인

jikguround-admin      # 관리자단 (Vite + React)
├── CSR 기반
├── 내부 사용자 전용
└── 복잡한 테이블/폼 UI

jikguround-packages   # 공유 패키지 (pnpm workspace)
├── @jikguround/tokens   # 디자인 토큰
├── @jikguround/types    # 공통 타입 정의
└── @jikguround/utils    # 유틸리티 함수

4. 선택 이유

관점 이유
SEO 요구사항 사용자단은 Next.js SSR/SSG로 SEO 최적화 필수, 관리자단은 CSR로 충분
렌더링 성능 통합 시 관리자단의 무거운 컴포넌트(테이블, 차트 등)가 사용자단 번들에 포함되어 성능 저하
디자인 시스템 사용자단(모바일 퍼스트)과 관리자단(데스크톱 중심)의 UI/UX 요구사항이 상이
API 구조 사용자 API와 관리자 API의 엔드포인트, 인증 방식, 응답 구조가 다름
배포 독립성 관리자단 수정이 사용자단 배포에 영향을 주지 않음
팀 협업 각 프로젝트별 독립적인 브랜치 전략 및 코드 리뷰 가능

이슈 #2: 파일 네이밍 컨벤션 (PascalCase vs kebab-case)

1. 이슈 상황

항목 내용
발생 환경 shadcn/ui 도입 후 컴포넌트 파일 네이밍
증상 기존 프로젝트는 PascalCase(Button.tsx), shadcn/ui는 kebab-case(button.tsx) 사용
영향 범위 전체 컴포넌트 파일 구조, 향후 유지보수

2. 해결 방안 후보

방안 장점 단점
A. PascalCase 통일 React 컴포넌트 컨벤션과 일치 shadcn 업데이트/재설치 시 파일명 충돌 위험
B. kebab-case 통일 shadcn과 일관성, 업데이트 용이 기존 React 관례와 다름
C. 혼용 (영역별 분리) 각 영역 컨벤션 유지 일관성 부족, 혼란 가능

3. 선택한 해결법