오늘의 목표는 프로젝트 명세서의 공유와 개발 시작을 위한 기술과 협업을 위한 기반을 정하는 것 이였습니다. 아래에 상세 내용을 공유합니다.

프로젝트 방향성 공유 및 최종 목표 확정

오늘은 프로젝트에서 모든 팀원이 동일한 목표를 향해 나아갈 수 있도록 방향성을 맞추는 데 집중했습니다.

  • 역할 분담(R&R) 확정: 5인 병렬 개발 방식을 위해 이전에 제시했던 기능별 풀스택 개발 방식을 기반으로 각 팀원의 역할과 책임 영역을 확정했습니다.
    • A : 로그인 기능, 네비게이션 배너
    • B : 프로젝트 세팅, 기능 구현
    • C : 배포, 기능 구현
    • D : Prisma ORM, 기능 구현, 네비게이션 배너
    • E : 기능 구현

데이터베이스 스키마(DB Schema) 최종 결정

프로젝트에서 중요한 자료가 될 데이터베이스 구조에 대하여 토론 했고, 최종 스키마를 확정했습니다. 이 과정에서 기술적 의도와 기획 의도 에 대한 결정을 내렸습니다.

  • 논의 1 : user_achievementscreated_at 필드
    쟁점: 업적 달성 시점을 직접 저장할 것인가(역정규화), 필요할 때마다 다른 데이터를 분석하여 계산할 것인가(정규화).
    결정 : created_at 필드를 삭제하기로 결정.
    근거 : 우리 서비스는 고도의 조회 성능 최적화보다 데이터의 중복을 없애는 '정규화' 원칙을 따르는 것이 더 합리적이라고 판단했습니다. 로직의 복잡성이 약간 증가하더라도, 데이터 무결성을 유지하는 방향을 선택했습니다.

  • 논의 2 : feedbacks 테이블의 참조 관계
    쟁점 : AI 피드백을 '챌린지' 단위로 할 것인가, '루틴' 단위로 할 것인가.
    결정 : 현재 ERD 구조(챌린지 참조)를 유지하기로 결정.
    근거: '1주일마다 루틴에 대한 피드백' 기능은 중요하지만 현재 설계상 챌린지를 통해 하위 루틴 데이터에 접근이 가능하다. 또한, 우리의 컨셉은 '챌린지'에 대한 것이므로 챌린지 단위의 종합 피드백 기능을 안정적으로 구현하는 데 집중하고, 필요시 추후에 확장하는 방향으로 합의했습니다.
    최종 스키마 생성: 위의 결정 사항을 반영하여, 모든 팀원이 동의한 최종 schema.prisma 파일을 생성할 예정입니다.
    이제 모든 백엔드 개발은 이 스키마를 기준으로 진행되며, 수정이 필요시 책임자에게 문의합니다.

기술 스택(Tech Stack) 선정 및 확정

프로젝트의 개발과 효율적인 유지보수를 위해 트렌드를 반영한 기술 스택을 최종 확정했습니다. 이는 개발 속도와 애플리케이션의 성능에 대하여 중요한 기반이 될 것 입니다.

  • 코어 프레임워크 & 언어 : Next.js TypeScript를 채택하여, 서버사이드 렌더링의 이점과 타입 안정성을 모두 확보했습니다.
  • 개발 환경 및 툴체인 : Bun을 공식 런타임 및 패키지 매니저로 사용하여, 빠른 개발 환경을 구축하기로 했습니다.
  • UI 및 스타일링 : Tailwind CSS를 통한 빠른 UI 개발과 Ant Design의 컴포넌트 라이브러리를 병행하여 사용하기로 결정했습니다.
  • 상태 관리 : 클라이언트 상태는 Zustand로 서버 상태(API 데이터)는 TanStack Query(React Query)로 관리하여 복잡성을 낮추고 성능 최적화를 목표로 삼았습니다.
  • 백엔드 및 데이터베이스 : Next.js API Routes Prisma ORM, 그리고 PostgreSQL을 사용하여 타입 세이프하고 안정적인 백엔드 시스템을 구축을 목표로 했습니다.
  • 인증 및 배포 : NextAuth.js로 간편하게 인증 기능을 구현하고, Vercel을 통해 원클릭 배포 및 CI/CD 환경을 구성 예정입니다.

3개발 환경 및 협업 규칙(Convention) 수립

효율적인 병렬 개발과 코드 품질 유지를 위해, 프로젝트의 기술적/협업적 기반을 논의중입니다.

  • 공통 UI 컴포넌트 논의
    디자인 기획을 바탕으로 앱 전체에서 반복적으로 사용될 버튼, 입력창, 헤더 등 공통 UI 컴포넌트를 개발 우선순위를 논의 예정입니다.

  • 팀 컨벤션 확정
    Git 브랜치 전략: issue#번호 형식으로 브랜치를 생성하고, 작업 전 반드시 이슈를 등록하는 규칙을 수립했습니다. 명확한 이슈 관리를 위해 템플릿 사용을 의무화 했습니다.
    커밋 메시지: 통일된 형식의 커밋 메시지 템플릿을 사용하기로 했습니다.
    머지 전략: 스쿼시 머지(Squash and Merge) 방식을 사용하기로 했습니다. 팀원은 주말을 이용해 스쿼시 머지의 장단점과 사용법에 대해 각자 학습하기로 했습니다.

정리

 데이터베이스 설계부터 협업 컨벤션까지 프로젝트의 기반을 다졌습니다.

준비는 끝나가며, 각자 분배받은 역할에 따라 확정된 컨벤션과 스키마를 바탕으로 기능 개발에 가까워졌습니다.

728x90