Prisma ORM, 데이터베이스 개발과 성능 최적화 #Node.js

wayhope Dev Logs

Prisma란?

Prisma는 Node.js와 TypeScript 환경에서 데이터베이스를 편리하게 다룰 수 있도록 지원하는 ORM(Object-Relational Mapping) 도구다.

ORM은 객체지향 프로그래밍의 객체와 관계형 데이터베이스의 테이블을 연결하는 기술이다. 개발자가 SQL을 직접 작성하는 대신 프로그래밍 언어의 객체와 메서드를 사용해 데이터를 조회하고 생성하거나 수정할 수 있다.

Prisma는 스키마를 기반으로 데이터 모델을 정의하고, 이를 바탕으로 타입이 지정된 Prisma Client를 생성한다. 이를 통해 데이터베이스 접근 코드를 일관성 있게 작성하고 컴파일 단계에서 여러 종류의 타입 오류를 발견할 수 있다.

Prisma는 데이터베이스를 대체하는 기술이 아니다. 실제 데이터 저장과 쿼리 실행은 MySQL, PostgreSQL 등의 데이터베이스가 담당하며, Prisma는 애플리케이션과 데이터베이스 사이의 데이터 접근 계층을 제공한다.

Prisma의 주요 구성 요소

Prisma Schema

Prisma Schema는 데이터베이스 모델과 연결 정보를 정의하는 파일이다. 데이터 모델, 필드 타입, 관계, 데이터베이스 연결 방식 등을 선언적으로 관리할 수 있다.

예를 들어 게임 플랫폼의 사용자 모델은 다음과 같이 정의할 수 있다.

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  nickname  String
  createdAt DateTime @default(now())
}

이 모델은 사용자 식별자, 이메일, 닉네임, 생성 시각을 정의한다.

@id는 기본 키를 지정하고, @unique는 이메일의 중복을 방지한다. @default는 기본값을 설정한다.

스키마를 통해 데이터 모델을 명시적으로 관리하면 데이터 구조와 애플리케이션 코드 사이의 일관성을 유지하기 쉽다.

Prisma Client

Prisma Client는 스키마를 기반으로 생성되는 데이터베이스 접근 라이브러리다. 모델별 조회, 생성, 수정, 삭제 API를 제공하며, TypeScript 환경에서는 입력값과 반환값에 대한 타입 정보를 활용할 수 있다.

사용자 조회는 다음과 같이 작성할 수 있다.

const user = await prisma.user.findUnique({
  where: {
    id: userId
  }
});

SQL을 직접 작성하지 않고도 사용자 식별자를 기준으로 데이터를 조회할 수 있다.

Prisma Client는 내부적으로 필요한 SQL을 생성하고 실행한 뒤, 조회 결과를 JavaScript 객체 형태로 반환한다.

Prisma Migrate

Prisma Migrate는 데이터베이스 스키마의 변경 이력을 마이그레이션 파일로 관리하는 도구다.

개발 과정에서 테이블이나 필드가 변경되면 변경 내용을 마이그레이션으로 생성하고 데이터베이스에 적용할 수 있다.

npx prisma migrate dev --name add_user_profile

이 명령은 개발 환경에서 마이그레이션을 생성하고 적용하는 데 사용된다.

운영 환경에서는 일반적으로 검토된 마이그레이션을 다음과 같이 적용한다.

npx prisma migrate deploy

마이그레이션을 통해 데이터베이스 구조 변경을 코드 변경과 함께 버전 관리할 수 있다. 다만 데이터베이스 변경이 기존 애플리케이션과 호환되는지, 대규모 테이블 변경이 잠금이나 지연을 유발하는지는 별도로 검토해야 한다.

CRUD와 Prisma Client

CRUD는 데이터의 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)를 의미한다. 대부분의 백엔드 서비스는 이 작업을 중심으로 데이터를 관리한다.

데이터 생성

const user = await prisma.user.create({
  data: {
    email: "player@example.com",
    nickname: "Player"
  }
});

새로운 사용자를 생성한다. 데이터베이스의 제약 조건을 위반하면 작업이 실패할 수 있으므로 중복 이메일이나 잘못된 입력을 적절히 처리해야 한다.

데이터 조회

const user = await prisma.user.findUnique({
  where: {
    email: "player@example.com"
  }
});

고유한 이메일을 기준으로 사용자를 조회한다. 해당 데이터가 없으면 결과는 null일 수 있으므로 후속 코드에서 이를 고려해야 한다.

데이터 수정

const user = await prisma.user.update({
  where: {
    id: userId
  },
  data: {
    nickname: "NewNickname"
  }
});

특정 사용자의 닉네임을 변경한다. update는 조건에 맞는 레코드가 존재하지 않을 경우 오류가 발생할 수 있다.

데이터 삭제

await prisma.user.delete({
  where: {
    id: userId
  }
});

사용자 레코드를 삭제한다. 실제 서비스에서는 연관 데이터, 외래 키 제약 조건, 소프트 삭제 정책 등을 함께 고려해야 한다.

이처럼 Prisma는 데이터 접근 로직을 일관된 형태로 작성하도록 지원한다. 그러나 인증과 권한 검증, 입력값 검증, 비즈니스 규칙은 개발자가 별도로 구현해야 한다.

관계형 데이터 모델과 트랜잭션

실제 서비스에서는 사용자, 인벤토리, 경기 결과, 포인트 내역처럼 서로 연결된 데이터가 존재한다.

Prisma는 모델 간 관계를 정의하고 관련 데이터를 조회할 수 있도록 지원한다. 또한 트랜잭션을 사용해 여러 데이터베이스 작업을 하나의 논리적 작업으로 처리할 수 있다.

예를 들어 경기 보상으로 사용자의 포인트를 증가시키고 정산 내역을 저장한다고 가정하자.

await prisma.$transaction(async (tx) => {
  await tx.user.update({
    where: {
      id: userId
    },
    data: {
      points: {
        increment: rewardPoints
      }
    }
  });

  await tx.rewardHistory.create({
    data: {
      userId,
      points: rewardPoints
    }
  });
});

트랜잭션 내부의 작업이 실패하면 해당 트랜잭션의 변경 사항은 롤백된다. 이를 통해 포인트는 증가했지만 정산 내역은 저장되지 않는 식의 불일치를 방지할 수 있다.

단, 이 예제만으로 모든 정산 문제가 해결되는 것은 아니다. 중복 요청에 의한 보상 중복 지급, 동시성 제어, 재시도 정책, 멱등성 키 등은 별도로 설계해야 한다.

Prisma의 장점

타입 안정성

Prisma Client는 스키마를 기반으로 타입 정보를 생성한다. 따라서 잘못된 필드명이나 허용되지 않는 입력값을 개발 과정에서 발견하는 데 도움이 된다.

특히 TypeScript를 사용하는 대규모 백엔드 프로젝트에서는 데이터 모델과 애플리케이션 코드의 불일치를 줄이는 데 유용하다.

개발 생산성

일반적인 CRUD 작업에서 반복적인 SQL 작성과 결과 매핑 코드를 줄일 수 있다. 데이터 모델을 중심으로 코드를 작성할 수 있어 개발 속도와 유지보수성을 높이기 쉽다.

스키마와 마이그레이션 관리

데이터 모델과 변경 이력을 코드로 관리할 수 있다. 개발 환경과 운영 환경에서 데이터베이스 구조를 일관되게 유지하는 데 도움이 된다.

데이터 접근 코드의 일관성

팀에서 공통적인 데이터 접근 패턴을 사용하기 쉽다. 조회 조건, 데이터 변경, 관계 처리 등을 일관된 API 형태로 작성할 수 있다.

Prisma의 성능과 한계

Prisma는 편리한 추상화 계층을 제공하지만, 모든 상황에서 직접 SQL을 작성하는 방식보다 빠른 것은 아니다.

성능을 평가할 때는 ORM 자체의 처리 비용과 데이터베이스 쿼리의 실행 비용을 구분해야 한다.

ORM 계층의 오버헤드

Prisma는 요청을 처리하는 과정에서 쿼리 구성, 결과 변환 등의 작업을 수행한다. 따라서 매우 단순한 쿼리를 대량으로 실행하거나 지연 시간이 극도로 중요한 상황에서는 직접 SQL을 실행하는 방식보다 추가 비용이 발생할 수 있다.

다만 실제 차이는 쿼리 유형, 데이터 크기, 연결 풀 설정, Prisma 버전과 사용 방식에 따라 달라진다. ORM을 사용한다는 이유만으로 성능이 크게 떨어진다고 단정할 수는 없다.

비효율적인 쿼리

ORM을 사용해도 비효율적인 SQL이 실행될 수 있다.

대표적인 문제는 다음과 같다.

  • 필요한 것보다 많은 데이터를 조회하는 경우
  • 적절한 인덱스가 없는 경우
  • N+1 쿼리 문제가 발생하는 경우
  • 복잡한 관계 조회로 데이터베이스 부하가 증가하는 경우
  • 불필요한 데이터 변환과 애플리케이션 처리가 발생하는 경우

이러한 문제는 ORM을 다른 라이브러리로 교체하는 것만으로 해결되지 않을 수 있다. 실제 SQL과 데이터베이스 실행 계획을 분석해야 한다.

복잡한 집계와 대량 처리

복잡한 통계 쿼리, 대규모 집계, 데이터 마이그레이션, 대량 삽입 작업에서는 직접 작성한 SQL이 더 적합할 수 있다.

Prisma에서도 Raw Query를 사용해 SQL을 직접 실행할 수 있다. 따라서 ORM 전체를 제거하기보다 일반적인 CRUD는 Prisma로 처리하고, 성능이나 표현력 측면에서 필요한 쿼리만 SQL로 작성하는 혼합 방식도 고려할 수 있다.

Raw Query를 사용할 때는 매개변수 바인딩을 활용해 SQL 인젝션을 방지해야 한다.

Prisma와 직접 SQL 비교

Prisma와 직접 SQL은 서로 대체 관계라기보다 서로 다른 추상화 수준의 데이터 접근 방식이다.

비교 항목Prisma직접 SQL
개발 생산성일반적인 CRUD 작성이 편리함쿼리와 결과 처리를 직접 관리
타입 안정성생성된 타입을 활용할 수 있음별도 타입 정의와 검증이 필요할 수 있음
쿼리 제어ORM API와 Raw Query를 통해 제어SQL을 세밀하게 직접 제어
성능추상화 계층의 추가 비용이 발생할 수 있음오버헤드를 줄일 여지가 있음
유지보수모델 중심으로 관리하기 편리함SQL과 애플리케이션 코드 관리가 중요함
복잡한 집계상황에 따라 Raw Query가 필요함복잡한 쿼리를 직접 표현하기 좋음

직접 SQL을 사용한다고 항상 빠른 것도 아니다. 비효율적인 SQL은 ORM 없이 작성해도 느리다. 결국 중요한 것은 실제 쿼리의 품질과 실행 계획이다.

Prisma와 다른 데이터 접근 도구

Node.js 환경에서는 Prisma 외에도 다양한 데이터 접근 도구를 사용할 수 있다.

Drizzle ORM

Drizzle ORM은 SQL과 가까운 방식으로 데이터베이스 쿼리를 작성하려는 개발자에게 적합하다. 타입 안정성을 제공하면서도 쿼리의 구조를 비교적 명시적으로 표현할 수 있다.

Knex.js

Knex.js는 SQL 쿼리 빌더다. ORM처럼 모델 중심의 추상화를 제공하기보다는 프로그래밍 코드로 SQL 쿼리를 구성하는 데 초점을 맞춘다.

mysql2와 pg

mysql2와 pg는 각각 MySQL 계열과 PostgreSQL 데이터베이스에 접근할 때 사용하는 드라이버다. SQL을 직접 작성하고 데이터 접근 계층을 세밀하게 제어하려는 경우 적합하다.

이 도구들은 추상화 수준과 제공 기능이 다르므로 단순한 성능 순위로 비교하기보다 프로젝트의 요구사항에 맞춰 선택해야 한다.

게임 서버에서 Prisma 활용하기

실시간 멀티플레이 게임 플랫폼에서는 모든 데이터를 같은 방식으로 처리할 필요가 없다. 데이터의 수명, 일관성 요구사항, 접근 빈도, 지연 시간 목표에 따라 데이터 접근 방식을 구분하는 것이 중요하다.

Prisma가 적합한 영역

  • 회원 가입과 계정 관리
  • 사용자 프로필 조회 및 수정
  • 게임 기록과 전적 저장
  • 운영 도구의 데이터 관리
  • 일반적인 보상 내역 및 거래 기록
  • 관계형 데이터의 CRUD 작업

이러한 영역에서는 개발 생산성과 데이터 모델 관리의 이점이 크다.

직접 SQL을 고려할 영역

  • 복잡한 랭킹 및 통계 집계
  • 대량 데이터 조회와 처리
  • 성능 병목이 확인된 핵심 쿼리
  • 데이터베이스 기능을 세밀하게 활용해야 하는 작업

Prisma의 Raw Query를 이용하면 기존 데이터 접근 구조를 유지하면서 특정 쿼리만 직접 SQL로 작성할 수 있다.

Redis와 메모리 기반 처리가 적합한 영역

  • 온라인 상태와 세션 관리
  • 매칭 대기열
  • 임시 게임 상태
  • 빈번하게 변경되는 실시간 데이터
  • 짧은 만료 시간을 갖는 캐시 데이터

이러한 데이터는 접근 빈도와 지연 시간 요구사항에 따라 Redis나 메모리 기반 구조를 고려할 수 있다. 다만 데이터 손실 허용 범위와 복구 정책에 따라 영속화 전략도 함께 설계해야 한다.

실시간 전투 상태를 매 프레임마다 관계형 데이터베이스에 저장하는 구조는 일반적으로 적합하지 않다. 실시간 상태는 메모리에서 처리하고, 필요한 시점에 결과를 데이터베이스에 기록하는 구조가 더 합리적이다.

Prisma 성능 최적화 전략

Prisma의 성능을 개선하려면 ORM을 제거하기 전에 실제 병목을 측정하고 분석해야 한다.

필요한 데이터만 조회하기

select를 사용하면 필요한 필드만 조회할 수 있다.

const user = await prisma.user.findUnique({
  where: {
    id: userId
  },
  select: {
    id: true,
    nickname: true
  }
});

불필요한 필드 조회와 데이터 전송을 줄이면 데이터베이스와 애플리케이션의 처리 부담을 낮출 수 있다.

인덱스와 실행 계획 확인하기

조회 조건에 맞는 인덱스를 설계하고 실제 실행 계획을 확인해야 한다. Prisma API를 최적화하더라도 데이터베이스가 비효율적인 실행 계획을 선택하면 성능 개선에는 한계가 있다.

N+1 쿼리 방지하기

반복문 안에서 개별 조회를 수행하면 데이터 건수에 비례해 쿼리 수가 증가할 수 있다. 필요한 관계를 적절하게 조회하거나 in 조건을 사용한 일괄 조회 등을 통해 쿼리 수를 줄일 수 있다.

연결 풀과 동시성 관리하기

데이터베이스 연결은 무제한으로 늘릴 수 없다. 연결 풀의 크기와 애플리케이션 인스턴스 수를 함께 고려해야 한다.

특히 여러 서버 인스턴스가 동시에 데이터베이스에 연결하는 환경에서는 전체 연결 수가 데이터베이스의 처리 한계를 초과하지 않도록 관리해야 한다.

성능 지표 측정하기

쿼리 실행 시간만 측정해서는 충분하지 않다. 다음 지표를 함께 확인해야 한다.

  • 요청의 p95 및 p99 응답 시간
  • 데이터베이스 쿼리 실행 시간
  • 초당 처리 요청 수
  • 데이터베이스 연결 사용량
  • CPU와 메모리 사용량
  • 쿼리 수와 오류율

동일한 데이터와 동일한 쿼리 조건으로 Prisma와 직접 SQL을 비교해야 의미 있는 결과를 얻을 수 있다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다