Prisma, 정말 쓸 만한가?장단점 솔직하게 정리해봤다

Node.js 생태계에서 Prisma는 "그냥 쓰는 ORM"이 됐다. 자동완성이 잘 되고, 스키마 파일 하나로 DB를 관리할 수 있다는 게 매력이다. 그런데 실제로 써보면 생각보다 불편한 지점도 꽤 있다. 이 글에서는 Prisma의 장점과 단점을 솔직하게 정리해본다.

장점이래서 다들 쓴다

타입 안전성이 진짜다

schema.prisma에 모델을 정의하면, 모든 쿼리 결과와 파라미터에 자동으로 타입이 붙는다. TypeScript와 함께 쓰면 런타임 에러가 눈에 띄게 줄어든다. IDE 자동완성도 잘 된다.

스키마 파일 하나로 모든 게 끝난다

prisma/schema.prisma 파일이 DB 구조의 단일 진실 공급원이 된다. 마이그레이션 생성, 클라이언트 코드 생성까지 prisma migrate dev 하나로 연결된다. 팀원이 새로 들어와도 온보딩이 빠르다.

가독성 높은 쿼리 문법

SQL을 직접 쓰거나 메서드 체이닝으로 복잡해지는 다른 ORM과 달리, Prisma는 객체 형태의 쿼리 문법을 사용한다. 중첩 관계 조회도 include 하나로 직관적으로 표현된다.

Prisma Studio — GUI로 데이터 확인

npx prisma studio를 실행하면 브라우저에서 DB 데이터를 바로 보고 수정할 수 있다. 개발 중 빠른 확인에 유용하다.

 

마이그레이션 히스토리 관리

변경 사항이 SQL 파일로 누적되고, prisma migrate deploy로 프로덕션에 안전하게 적용할 수 있다. Docker Compose 기반 배포에서 컨테이너 시작 시 자동 마이그레이션 패턴과 궁합이 좋다.

---

단점이건 알고 써야 한다

복잡한 쿼리는 결국 Raw SQL

GROUP BY, 윈도우 함수, 복잡한 서브쿼리 등 Prisma의 추상화가 커버하지 못하는 영역이 생각보다 넓다. 결국 $queryRaw를 써야 하는 상황이 오고, 그러면 타입 안전성도 사라진다.

N+1 문제가 조용히 발생한다

관계 데이터를 반복문 안에서 조회하면 쿼리가 N번 나간다. Prisma는 이를 자동으로 막아주지 않는다. 의식적으로 include를 쓰거나, findMany로 미리 가져와야 한다.

번들 사이즈와 콜드 스타트

Prisma 클라이언트는 쿼리 엔진 바이너리를 포함하기 때문에 번들이 무겁다. Lambda 같은 서버리스 환경에서는 콜드 스타트가 눈에 띄게 느려지는 경우가 있다.

스키마 변경 시 팀 협업 충돌

여러 명이 동시에 schema.prisma를 수정하면 마이그레이션 히스토리 충돌이 발생할 수 있다. Git 브랜치 전략과 마이그레이션 관리 규칙을 팀 차원에서 미리 정해두지 않으면 골치 아프다.

JPA에 익숙하다면 개념이 다르다

Dirty Checking, 영속성 컨텍스트, LAZY 로딩 같은 JPA 개념이 Prisma에는 없다. 명시적으로 데이터를 가져오고 업데이트해야 하며, 트랜잭션 처리 방식도 다르다. Spring 배경이라면 초반에 적응 비용이 있다.

---

한 줄 결론
Prisma는 중소 규모 Node.js 프로젝트에서 생산성이 높다. 타입 안전성과 개발자 경험은 업계 최고 수준이다. 다만 복잡한 쿼리가 많거나 서버리스 환경이라면 Raw SQL 혼용 전략을 처음부터 고려해야 한다. 무조건 좋은 도구는 없고, 프로젝트 성격에 맞게 선택하는 게 맞다.