백엔드: Spring Boot + PostgreSQL + flyway
백엔드와 DB, 인프라는 제가 혼자 맡은 영역이라 "익숙한 것 vs 검증된 것" 사이에서 검증된 것을 택했습니다. Spring Boot에 Spring Data JPA, PostgreSQL, 그리고 스키마 관리는 flyway로 시작했습니다.
spring.jpa.hibernate.ddl-auto=validate로 못박아 뒀습니다. Hibernate가 알아서 테이블을 바꾸게 두지 않고, 스키마 변경은 반드시 V{n}__{description}.sql 마이그레이션 파일로만 하기로 한 겁니다. 배포된 마이그레이션은 절대 수정하지 않고 새 버전을 추가하는 것도 초반부터 정한 규칙입니다.
실제로 이 프로젝트는 지금 V11까지 왔습니다.
- V1: users, social_accounts
- V2: 전체 도메인 테이블 14개 한 번에
- V3: roles/grades 시스템
- V4~V7: 증상 가이드 도메인 + 다형적 연관 구조로 리팩토링
- V8: 입양 도메인 재설계
- V9: 육아노트 도메인 (일상/병원/투약/몸무게/증상 기록)
- V10~V11: 유니크 인덱스 보완, 퀴즈 도메인
V2에서 만들었던 health_records, 초기 버전 adoptions 테이블은 나중에 V8, V9에서 drop & recreate 됩니다. 처음부터 완벽하게 설계하지 못했다는 뜻이기도 하고, 동시에 "나중에 갈아엎어도 되는 구조"로 만들어뒀다는 뜻이기도 합니다.
인증: 소셜 로그인 위임 + JWT
이메일 회원가입은 만들지 않기로 했습니다. 카카오/네이버 소셜 로그인만 지원하고, 인증은 전부 Spring Security OAuth2한테 위임했습니다. 로그인이 끝나면 백엔드가 JWT(Access 30분 + Refresh 14일)를 발급합니다.
역할은 USER / MANAGER / ADMIN 세 단계, 등급은 활동량 기반 SPROUT(새싹) → CARROT(당근) → CROWN(왕관)으로 잡았습니다. 등급은 아직 자동 승급 로직은 없고 수동 변경만 가능한 상태로 시작했습니다.
이번 편 요약
- Spring Boot + PostgreSQL + flyway, ddl-auto는 validate로 고정
- 소셜 로그인(카카오/네이버) 전용, JWT Access/Refresh 발급
- 역할 3단계 + 등급 3단계 설계
다음 편에서는
이 설계를 실제로 구현하면서 만난 첫 번째 버그 지옥 — 등급 변경 화면 버그와 PostgreSQL 검색 쿼리 에러 이야기입니다.
