SQL Shape 최적화를 통한 Prisma vs JDBC 성능 격차 해소

Context

ORM 사용 시 발생하는 성능 저하의 원인을 단순 추상화 계층의 비용으로 오해하는 경향 분석. 실제로는 Query Shape 설계 미흡과 N+1 문제로 인한 SQL 발행 횟수 증가가 성능 병목의 핵심 지점임을 식별.

Technical Solution

• Naive, Idiomatic, Best-effort 3단계 구현 레벨 설정을 통한 정밀 비교 환경 구축
• Prisma의 include API가 유발하는 다중 쿼리 발행 특성과 JDBC의 Join 쿼리 구조 대조 분석
• Aggregation 요구사항 발생 시 Prisma $queryRaw 도입을 통한 SQL 발행 횟수를 4회에서 1회로 최적화
• AtomicLong 기반의 CountingJdbc 래퍼를 설계하여 런타임 내 실제 SQL/request 횟수를 정량적으로 측정
• Node.js 24 LTS와 Java 21/25 환경에서 동일한 PostgreSQL 16 데이터셋을 활용한 제어 변수 설정

Impact

• read-by-id 시나리오에서 Prisma $queryRaw 적용 시 SQL/request 횟수를 4회에서 1회로 감소
• 동일 SQL 발행 시 PostgreSQL 실행 계획(Execution Plan) 및 실행 시간(0.242ms) 동일함 확인
• Java 25 도입 시 Java 21 대비 read-by-id 성능 약 20% 향상 확인

Key Takeaway

런타임 언어나 ORM 라이브러리의 선택보다 Query Shape 최적화가 성능에 압도적인 영향을 미침. 개발자 편의성을 위한 ORM의 추상화 계약(Contract)을 이해하고, 병목 지점에서 Raw SQL로 전환하는 전략적 선택이 필수적임.