부제: JPA·Snowflake·MyBatis·Flyway, 그리고 Drizzle
이번 편은 DB·ORM·마이그레이션. 회사에서는 Aurora MySQL 도 있었고, 이번 글의 축은 JPA → Snowflake·MyBatis와 Flyway, 그리고 지금의 Postgres·Drizzle이다.
용어
- JPA / Hibernate: 엔티티 ↔ 테이블 매핑의 자바 표준 쪽. 구현체로 Hibernate가 흔하다.
- dialect: DB마다 다른 SQL 문법·함수를 ORM이 맞춰 번역하게 하는 설정 축.
- MyBatis: SQL을 직접 적고 결과를 객체에 매핑하는 SQL 매퍼.
- Snowflake: 클라우드 데이터 웨어하우스. OLTP DB와 SQL 뉘앙스가 달라 ORM dialect가 꼬이기 쉽다.
- Flyway: 스키마 변경을 버전 순서대로 적용하는 마이그레이션 도구.
- PostgreSQL: 이번 학습 베이스의 메인 DB.
- Drizzle ORM: TS 친화 SQL 추상화. Next 전용은 아니다 — Node 런타임이면 붙일 수 있고, Next 예제에서 자주 보여 한 묶음처럼 느껴질 뿐이다.
- drizzle-kit: 스키마 생성·푸시 등을 돕는 CLI.
1) 처음엔 JPA 위주
JPA로 시작했다. CRUD·엔티티 중심에 익숙했다. 어노테이션으로 테이블 매핑을 잡고, 기본 CRUD는 JpaRepository 하나면 거의 처리됐다. 편리했다.
2) Snowflake 연동·dialect 이슈·MyBatis
Snowflake를 붙이면서 MyBatis를 쓰게 됐다. dialect 문제였다.
그 문제는 끝내 해결했다고 말하긴 어렵다. ORM이 만들어 주는 SQL·타입·페이지네이션이 기대와 어긋나는 지점이 있었고, SQL을 더 직접 잡는 쪽으로 무게가 옮겨갔다.
잠깐 개념: 왜 우회가 나오나
Snowflake 쪽 SQL·타입은 범용 ORM이 깔끔히 흡수하기 어려운 부분이 있기 쉽다. MyBatis/네이티브 SQL로 빼는 패턴은 흔히 듣는다.
3) 시간이 지날수록 MyBatis 쪽이 손이 갔다
시작은 JPA였는데 점점 MyBatis 선호 체감이 있었다.
4) Flyway — 만족, 대신 배포 줄이 늘었다
전반적으로 만족이다. 예전엔 형상관리를 깊게 안 했는데 미리 도입하길 잘했다고 본다.
배포 시 프로세스가 하나 더 느는 느낌은 있다. 작은 팀에겐 허들이 될 수 있고, 역할이 세분화된 조직에겐 품질 관리에 도움이 될 수 있다는 게 내 생각이다.
잠깐 개념: 마이그레이션 도구
“지금 DB 버전이 뭔지”를 추적하고 순서대로 스키마 변경을 적용하게 해 준다.
5) 지금 — Postgres 17 + Drizzle
docker-compose에 postgres:17-alpine. package.json에 drizzle-orm, drizzle-kit, postgres 드라이버, 스크립트 db:push, db:migrate, db:generate, db:studio, docker:up.
Drizzle은 처음이었다. Sequelize·TypeORM 정도는 알았는데 이쪽은 새로웠다.
6) 트레이드오프
자동화는 안정에 도움이 되지만, 팀 규모·성숙도에 따라 허들로 느껴지는 지점이 다르다. 지금은 연습으로 받아들인다.
5편은 SSO·Husky·테스트와 Better Auth·Biome·verify로 마무리한다.
