💡 프로젝트 주제

👥 프로젝트 구성원과 R&R

팀원 주요 담당
이영인 콘텐츠 데이터 관리
이종원 콘텐츠 평가 및 큐레이팅
정종현 사용자 관리 - OAuth
최성현 팔로우와 DM
한상엽 실시간 같이 보기 기능

🗓️ 프로젝트 일정 요약

항목 기간 내용
기획 및 요구사항 정리 7/28 ~ 7/30 프로젝트 방향성 논의, 기능 리스트 작성
1차 개발 스프린트 7/30 ~ 8/13 프로토타입을 위한 기능 구현 시작
중간 점검 & 회고 8/13 프로토타입 기능 시연 + 피드백 수렴
2차 개발 스프린트 8/14 ~ 8/28 최적화, 테스트, 버그 수정, 배포 준비
발표 자료 준비 8/28~8/29 발표 자료 준비 및 오류 수정
최종 발표 & 회고 8/29 발표 자료 정리 및 시연

⚙️ 기술 스택 및 협업 도구

분류 사용 예정 도구
Backend Java Spring Boot, Lombok, Spring Data JPA, PostgreSQL, springdoc-openapi, QueryDSL, actuator, validation, jacoco
Database Postgre Database, H2
API 문서화 Swagger
협업 도구 Discord, GitHub, Notion, Jira
일정 관리 Jira(일정표)
배포 도구 AWS

🧩 규칙 수립

항목 내용
네이밍 컨벤션 camelCase (변수, 함수), PascalCase (클래스), kebab-case (파일, URI), snake_case(DB 테이블명(복수형), DB 칼럼명, 외래키(fk_부모테이블_자식테이블), 유니크키(uq_부모테이블_자식테이블))
커밋 컨벤션 feat(기능), fix(버그), refactor(패키지, 코드 로직 개선), docs(READ.md), style(변수명, 코드 이쁘게 개선), test, chore(의존성 추가) 등
브랜치 전략 main, develop, fix/이슈번호
Github workflow 전략을 쓰되, develop 브랜치를 만든 뒤, 지라에서 티켓당 브랜치를 하나 만든다.
PR 규칙 코파일러가 코드를 1차적으로 리뷰하고
코드 작성한 본인이 승인, 이후 깃허브 담당 인원이 Merge 진행.
충돌 발생 시, 코드 작성한 사람과 협의해서 코드 고친 뒤 Merge 진행
스크럼 오전 9시 10분
어제 무엇을 했고, 오늘 무엇을 할 것이다.
어제 PR 올렸지만 Merge 안 된 것은 무엇이 있고, 이슈 상황은 이것이 있다.
커피 타임 오후 3시 - 4시 쉬어가는 시간
코드 스타일 구글 표준 스타일
불참 불참 시 미리 공유, 불참자의 책임은 팀원이 대체
패키지 구조 도메인 중심 패키지 구조

🚨 예상 문제점 / 아쉬운 점

프로젝트 준비 과정 또는 멘토링을 통해 발견된 잠재적 이슈들을 정리해 주세요.

🔧 개선 사항

멘토님의 피드백을 반영하거나 팀 논의를 통해 도출한 개선 포인트를 정리해 주세요.