1. 이번 작업의 목표
지난 작업에서는 Frontend와 Backend 프로젝트를 생성하고 기본 실행을 확인했다.
이번에는 사용자의 메모와 일정을 실제로 저장할 수 있도록 PostgreSQL을 연결하고, 초기 테이블과 스키마 관리 방식을 구성했다.
사용한 구성은 다음과 같다.
- PostgreSQL: 사용자·메모·일정 데이터 저장
- Docker Compose: 로컬 DB 실행 환경 구성
- Spring Data JPA: 애플리케이션의 데이터 접근
- Flyway: DB 스키마 생성과 변경 이력 관리
2. PostgreSQL과 Docker
데이터베이스는 PostgreSQL을 선택했다.
현재 필요한 것은 사용자, 메모, 일정 데이터를 저장하고 관계를 관리하는 기능이다. 향후 JSONB나 pgvector를 활용한 기록 검색으로 확장할 가능성도 고려했다. 이번 단계에서는 기본적인 관계형 데이터 저장 기능만 사용한다.
PostgreSQL 17은 Docker Compose로 실행하도록 구성했다. DB 이름과 계정, 포트 등을 Compose 파일에서 관리하고, 데이터는 별도의 Volume에 저장하도록 했다.
다음은 Volume 설정과 관련된 부분이다.
services:
postgres:
image: postgres:17
volumes:
- memory_calendar_postgres_data:/var/lib/postgresql/data
volumes:
memory_calendar_postgres_data:
PostgreSQL 데이터 디렉터리를 named volume에 연결했다. 컨테이너를 다시 생성하더라도 해당 Volume이 유지되고 다시 연결되면 기존 데이터를 사용할 수 있다.
3. JPA와 Flyway 적용
Spring Boot에는 Spring Data JPA와 PostgreSQL Driver를 추가하고, Datasource 설정으로 DB를 연결했다.
JPA는 애플리케이션에서 Entity를 통해 데이터를 조회하고 저장하는 데 사용한다. DB 스키마의 생성과 변경은 Flyway로 관리하도록 역할을 나눴다.
Flyway를 도입한 이유는 스키마 변경 이력을 코드와 함께 관리하기 위해서다. 어떤 테이블과 컬럼을 추가했는지 Migration SQL로 남기고, 다른 환경에서도 같은 변경을 적용할 수 있도록 했다.
초기 스키마는 V1__init_schema.sql에 정의했으며, 사용자·메모·일정을 저장할 users, notes, events 테이블을 구성했다.
관련 설정은 다음과 같다.
spring:
jpa:
hibernate:
ddl-auto: validate
flyway:
enabled: true
Flyway가 Migration을 적용하고, Hibernate는 ddl-auto: validate 설정에 따라 Entity 매핑과 실제 DB 스키마가 일치하는지 검증하도록 했다.
앞으로 스키마를 변경할 때도 Migration 파일을 추가하는 방식으로 관리할 예정이다.
4. 적용 결과
구성 후 PostgreSQL 실행과 Spring Boot 연결을 확인했다. Flyway의 초기 Migration이 적용되어 테이블이 생성됐고, Hibernate의 스키마 검증도 정상적으로 통과했다.
이번 작업으로 데이터를 저장할 환경과 DB 변경을 관리할 기준을 마련했다.
다음에는 이 기반 위에 User Entity와 Repository를 구성하고, 회원가입 기능을 구현한다.