Prisma란? 기존 MySQL과의 차이, 마이그레이션까지 정리

1. Prisma란?

Prisma는 Node.js/TypeScript 백엔드(서버)에서 DB를 다룰 때 쓰는 ORM(객체 관계 매핑) 라이브러리다.
브라우저용이 아니라, 서버 코드에서만 사용한다.

원래(전통적인) 방식은 두 가지다.

• 직접 SQL: mysql, pg 같은 드라이버로 쿼리 문자열을 실행한다.
• 다른 ORM: TypeORM, Sequelize, Drizzle 등.

Prisma는 그중에서 스키마 파일 하나로 타입·마이그레이션·클라이언트까지 맞춰 주는 Node/TS용 ORM이라고 보면 된다.

---

2. Prisma의 단점 (요지)

• 러닝 커브: 스키마 문법, generate / migrate 개념, 빌드 타임과 런타임 구분을 알아야 한다.
• 복잡한 쿼리 한계: Raw SQL보다 복잡한 조인·서브쿼리·윈도우 함수는 표현이 어렵거나 불가능해서, 결국 $queryRaw로 빠져나올 때가 있다.
• 번들/빌드 이슈: 생성된 클라이언트가 꽤 크고, Edge/브라우저에는 부담이 있어 보통 서버 전용으로 쓴다.
• 마이그레이션 관리: 스키마와 DB 상태를 맞춰야 해서, 팀·브랜치 전략에 따라 마이그레이션 충돌이 생기면 손이 갈 수 있다.
• 벤더 종속: Prisma 방식(스키마·문법·도구)에 맞춰 개발하게 되고, 나중에 다른 ORM으로 바꾸려면 이전 비용이 든다.

---

3. 기존 MySQL과 Prisma의 차이

MySQL과 Prisma는 같은 DB(MySQL)를 쓰더라도 쓰는 방식이 다르다.

 

① 기존 MySQL vs Prisma 구조

 

② 스키마 ↔ DB 동기화 방향

 

3-1. “기존 MySQL”이란 (Node에서)

• MySQL 서버: 실제로 데이터를 저장하는 DB 엔진.
• Node에서의 “기존” 방식: mysql, mysql2 같은 드라이버로 SQL 문자열을 직접 보내는 방식.

// mysql2 예시 – SQL 문자열 직접 작성

const [rows] = await connection.query(

  'SELECT id, name, email FROM User WHERE orgId = ?',

  [orgId]

);

// rows는 그냥 배열. 필드 이름 오타나 타입은 런타임에만 알 수 있음

 

역할: “연결 + SQL 실행”만 해 준다.
테이블/컬럼 이름, 타입, 관계는 코드로 보장되지 않아서, 오타나 타입 실수는 실행해 봐야 알 수 있다.

3-2. Prisma란

역할: schema.prisma에 모델(테이블/컬럼/관계)을 정의해 두면, 그걸 기준으로 타입이 붙은 클라이언트를 만들어 준다.
“기존 MySQL 드라이버로 SQL 직접 쓰는 것”과 비교되는 건 이 클라이언트(ORM) 이다.

// Prisma – 스키마 기반, 자동 완성·타입 체크

const users = await prisma.user.findMany({

  where: { orgId },

  select: { id: true, name: true, email: true },

});

// users 타입이 정해져 있음. email 오타 시 컴파일 단계에서 에러

 

실제 동작: 내부에서 MySQL(또는 PostgreSQL 등)에 SQL을 생성해서 보낸다.
즉, “기존 MySQL” 위에 한 겹 더 쌓인 추상화 레이어라고 보면 된다.

3-3. 비교 요약

구분기존 MySQL (드라이버)Prisma

무엇을 쓰나	DB 엔진(MySQL) + mysql/mysql2 같은 패키지	같은 DB + Prisma 클라이언트(ORM)
쿼리	직접 SQL 문자열 작성	prisma.user.findMany() 같은 메서드 (Prisma가 SQL 생성)
타입	보통 수동이거나 약함	스키마에서 생성해서 TypeScript 타입 자동
마이그레이션	직접 SQL/스크립트로 관리	prisma migrate로 스키마 → DB 변경 관리
복잡한 쿼리	자유로움	복잡해지면 한계 있음, raw SQL로 보완

 

한 줄로:
기존 MySQL = “Node에서 MySQL 드라이버로 SQL 직접 쓰는 방식”이고,
Prisma = “스키마를 정의해 두고, 그걸로 타입·메서드를 만들어서 같은 MySQL(또는 다른 DB)에 접근하게 해 주는 백엔드용 도구”라서, 쓰는 레이어(드라이버 vs ORM) 가 다르다.

---

4. “스키마를 마이그레이션한다”는 뜻

기존에는 SQL로 직접 DB를 조작했다.
Prisma는 스키마 파일을 가져와서(정의해서) 코드로 쓰는 방식이라, 스키마와 DB 구조를 맞춰 줘야 한다.
그래서 “스키마를 마이그레이션한다”는 말이 나온다.

4-1. 방향: 보통은 “스키마(Prisma)가 기준 → DB를 맞춤”

• 코드베이스에서 수정하는 건 schema.prisma (모델/테이블 정의).
• 실제 DB 구조를 바꾸는 건 prisma migrate (또는 db push).
• 즉, **“Prisma 스키마가 바뀌면 → 그걸 DB에 반영해 줘”**가 마이그레이션이다.
  **“DB가 바뀌었으니 Prisma에 반영해 줘”**는 기본 흐름이 아니다 (그때는 수동으로 스키마 수정하거나 introspect로 가져온다).

기존 SQL 방식과 비교하면:

• 예전: “테이블 추가/컬럼 추가해라” → 직접 CREATE TABLE, ALTER TABLE 같은 SQL을 작성해서 DB에 실행.
• 지금(Prisma): “테이블/컬럼을 스키마 파일에 정의해 두고” → **prisma migrate**가 그 차이를 읽어서, DB를 그 스키마에 맞게 바꾸는 SQL을 만들어 실행해 준다.

그래서 **“코드(에디터)에서 스키마만 바꾸면, 그 바뀐 스키마대로 DB를 변경해 주는 것”**이 마이그레이션이다.

4-2. DB가 먼저 바뀌는 경우

다른 팀이 SQL로 DB만 수정했거나, 레거시 DB를 그대로 쓰는 경우에는 DB → Prisma 방향이 필요할 수 있다.
그때는 prisma db pull(구 introspect)로 현재 DB 구조를 읽어서 schema.prisma를 자동으로 만들거나 갱신한다.
그다음부터는 그 스키마 기준으로 Prisma 클라이언트를 쓰면 된다.

정리하면:

• 스키마 ↔ DB 동기화는 두 방향 다 가능하다.
• 일반적인 흐름: “스키마 바꿈 → migrate로 DB 반영”.
• DB가 이미 바뀌어 있는 경우: pull로 스키마에 반영한 뒤, 역시 스키마를 기준으로 개발.

4-3. 한 줄 요약

• 마이그레이션: 코드에서 Prisma 스키마를 바꿨을 때, 그 내용을 실제 DB에 반영하는 것 (스키마가 기준, DB를 맞춤).
• DB가 먼저 바뀐 경우엔 db pull / introspect로 스키마를 DB에 맞추고, 그다음부터는 다시 스키마가 기준이 된다.