SLATE-TO는 영상 제작자와 클라이언트가 하나의 프로젝트 공간에서 작업물을 공유하고, 피드백을 남기며, 일정과 파일을 관리할 수 있도록 돕는 협업 서비스입니다.
chazy-d Backend |
sangwon02 Backend |
young0206 Backend |
guingguing Backend |
Kohseoyoung Backend |
| 도메인 | 기능 |
|---|---|
| 인증 | Google OAuth 및 이메일 기반 로그인, JWT 인증, 이메일 인증, 비밀번호 재설정 |
| 회원 | 온보딩, 프로필 조회/수정, 프로필 이미지 업로드, 공개 프로필 조회 |
| 포트폴리오 | 프로젝트 이력 등록/조회/수정/삭제, 영상 링크 기반 썸네일 관리 |
| 프로젝트 | 프로젝트 생성/조회/수정/삭제, 상태 관리, 프로젝트 고정 |
| 멤버 | 초대 링크 기반 프로젝트 참여, 멤버 역할/권한 관리 |
| 영상 | YouTube 영상 등록/검증, 진행 상태 관리, 북마크, 참고 파일 관리 |
| 피드백 | 타임코드 기반 피드백 작성, 답글, 상태 변경 및 해결 처리 |
| 공유 링크 | 외부 게스트용 영상 공유 링크 생성, 게스트 등록, 링크 활성화 관리 |
| 파일/공지 | 프로젝트 파일 업로드/다운로드, 공지 등록/조회, 읽음 처리 |
| 일정 | 개인/프로젝트 일정 관리, 캘린더 조회, 개인 메모 |
| 모집 | 구인구직 공고 등록/조회, 조건별 필터링, 추천 공고, 지원/북마크 |
| 알림 | 알림 조회/읽음 처리, 알림 설정, 최근 활동, 오늘 브리핑 |
배포 실패 시 동작
배포 후 헬스 체크가 실패하면 직전 이미지로 자동 롤백합니다. 다만 최초 배포처럼 직전 이미지 정보를 읽을 수 없으면 롤백하지 못하며, 롤백에 실패한 경우에도 배포는 실패로 기록되고 수동 복구가 필요합니다.
concurrency설정으로 배포가 동시에 실행되지 않도록 차단합니다. Nginx 설정 역시nginx -t검증에 실패하면 이전 설정으로 되돌립니다.
스키마는 Flyway로 버전 관리하며, 마이그레이션 파일은 src/main/resources/db/migration에 있습니다.
운영 환경 반영 전 CI에서 실제 MySQL 컨테이너로 마이그레이션을 검증합니다.
| 브랜치 | 설명 |
|---|---|
main |
운영 환경에 배포되는 안정적인 버전입니다. |
feature/* |
기능 개발용 브랜치입니다. 최신 main에서 분기하여 작업합니다. |
fix/* |
버그 수정용 브랜치입니다. |
refactor/* |
기능 변경 없는 코드 개선용 브랜치입니다. |
docs/* |
문서 수정용 브랜치입니다. |
chore/* |
빌드, 설정, 기타 작업용 브랜치입니다. |
기능 개발은 feature를 사용하고, 나머지 접두사는 아래 커밋 컨벤션의 type과 같은 이름을 사용합니다.
- 모든 작업은
main에서 분기한 작업 브랜치에서 시작합니다. - Pull Request를 생성하고 리뷰를 거친 후
main에 병합합니다.
git switch main
git pull origin main
git switch -c feature/1-login브랜치 이름은 아래 형식을 사용합니다.
feature/{이슈번호}-{기능명}
예시: feature/1-login
프로젝트 초기에는 Dev/Prod 서버를 분리하고 develop을 통합 브랜치로 두는 Git Flow 방식으로 시작했으나, 아래 이유로 main 중심의 단일 브랜치 전략으로 전환했습니다.
1. 배포 대상이 하나입니다.
Git Flow의 develop은 여러 릴리스를 모아 한 번에 내보내는 것을 전제로 합니다. 단일 운영 서버에 변경 사항을 지속적으로 반영하는 구조에서는 모아둘 릴리스 단위가 없어, develop이 main으로 가기 전 대기 지점 이상의 역할을 하지 못했습니다.
2. 통합 브랜치를 검증할 환경이 없어졌습니다.
인프라 비용 절감을 위해 Dev 서버 운영을 종료하면서, develop에 병합해도 동작을 확인할 수 있는 배포 환경이 사라졌습니다. "운영 반영 전에 통합 상태를 검증한다"는 통합 브랜치의 목적 자체가 성립하지 않게 되었습니다.
3. 병합 지점이 둘로 나뉘어 리뷰가 분산되었습니다.
같은 변경에 대해 feature → develop PR과 develop → main PR이 각각 생성되었고, 후자는 이미 리뷰를 마친 커밋의 모음이라 형식적인 승인이 되기 쉬웠습니다. 병합 지점을 하나로 모아 리뷰가 실제로 이루어지는 위치를 명확히 했습니다.
4. 검증 조건을 한 곳에 집중할 수 있습니다.
브랜치 보호와 CI 필수 통과 조건을 main 한 곳에 적용해, 운영에 반영되는 모든 코드가 예외 없이 동일한 검증을 거치도록 했습니다. 브랜치가 둘일 때는 긴급 수정을 양쪽에 각각 반영해야 하고, 한쪽을 누락하면 다음 배포에서 수정이 되돌아가는 위험도 있었습니다.
현재는 Prod 서버만 운영하며, 배포 전 검증은 Dev 서버 대신 CI에서 수행합니다. CI는 실제 MySQL 컨테이너로 Flyway 마이그레이션을 검증하고 전체 테스트와 Docker 이미지 빌드까지 확인하며, 이 검증을 통과해야만 운영 배포가 진행됩니다.
main은 GitHub Ruleset(Protect main)으로 보호되며, 예외 대상(bypass)은 없습니다.
main에 직접 push할 수 없으며, 모든 변경은 Pull Request를 거칩니다.- 승인 1건 이상이 있어야 병합할 수 있습니다.
- CI(
Migration, Build and Docker Image Check) 통과가 병합 조건입니다. - force push와 브랜치 삭제를 차단합니다.
<type>: <작업 내용>
type은 소문자만 사용합니다.subject는 현재형 동사로 작성합니다.
| type | 설명 |
|---|---|
feat |
새로운 기능 추가 |
fix |
버그 수정 |
refactor |
기능 변경 없는 코드 개선 |
docs |
문서 수정 |
test |
테스트 코드 추가/수정 |
chore |
빌드, 설정, 기타 작업 |
deploy |
배포 및 인프라 관련 작업 |
- PR은
main브랜치를 기준으로 생성합니다. - PR 생성 시 Reviewer를 지정합니다.
- 작업 내용, 주요 변경 파일, 검증 결과를 함께 작성합니다.
- 기능 단위가 커질 경우 작은 커밋 단위로 나누어 리뷰 흐름을 명확하게 유지합니다.
src/main/java/com/slatto
├── domain
│ ├── auth, user, project, video, feedback
│ ├── schedule, notification, recruitment, sharelink, inquiry, common
│ └── controller, service, repository, entity, dto 중심으로 구성
├── global
│ ├── config, security, exception, response
│ ├── storage, health, util
│ └── 공통 설정과 횡단 관심사 관리
└── SlattoApplication.java
Java 21 기준으로 실행합니다.
./gradlew bootRun전체 테스트와 빌드는 아래 명령으로 확인합니다.
./gradlew test
./gradlew clean build