매칭 플랫폼 백엔드 Data Access Layer(ORM) 기술 선정

1. 상황 및 요구사항

• 백엔드 환경: TypeScript 기반의 Node.js 서버 환경.
• DB 환경: PostgreSQL (JSONB, Native Array, PostGIS 적극 활용 예정).
• 핵심 목표:
  1. 1인 개발(또는 소규모) 체제에서 비즈니스 로직에 집중하기 위한 압도적인 개발 생산성(DX) 확보.
  2. 런타임 에러를 방지하는 강력한 타입 안정성(Type Safety) 및 자동 완성.
  3. PostgreSQL의 특수 데이터 타입들과의 매끄러운 호환성.

---

2. ORM, 써야 할까? (Raw Query vs ORM)

• Raw Query (pg, postgres.js 등): 쿼리 튜닝이 자유롭고 성능이 가장 뛰어남. 하지만 DB 데이터를 TypeScript 객체로 맵핑하는 보일러플레이트 코드를 수동으로 작성해야 함.

💡 결정: 본 프로젝트는 유저, 학원, 학교, 설문 결과 등 엔티티 간의 관계가 복잡하게 얽혀 있음. 쿼리 작성 시간보다 비즈니스 로직 구현이 훨씬 중요하므로, 데이터를 객체 지향적으로 다루고 타입 추론을 자동화해 주는 ORM 도입을 확정함.

---

3. 어떤 ORM을 쓸 것인가? (TypeScript 생태계 비교)

A. TypeORM

• 특징: 데코레이터(@Entity()) 기반의 전통적이고 안정적인 ORM.
• 단점: 최근 업데이트가 더디고, 초기 세팅이 번거로움. 특히 PostgreSQL의 특수 타입(Array, JSON)을 다룰 때 타입 추론이 완벽하게 매끄럽지 않은 경우가 발생함.

B. Drizzle ORM

• 특징: 최근 생태계에서 가장 주목받는 'SQL-like' ORM. 무거운 엔진 없이 SQL과 거의 1:1로 매칭되어 성능이 매우 우수하며 서버리스 환경에 적합함.
• 단점: SQL 제어권이 높은 대신, 개발자가 직접 관계(Relations)와 스키마를 코드로 엮어주어야 하는 수고로움이 동반됨.

C. Prisma

• 특징: schema.prisma 파일 하나로 DB 설계, TypeScript 타입 생성, 마이그레이션을 동시에 해결하는 차세대 ORM.
• 장점 (PostgreSQL 시너지): DB의 핵심 무기인 Native Array와 JSONB를 스키마 레벨에서 가장 깔끔하게 지원함(예: String[], Json). 내장된 GUI 툴인 **'Prisma Studio'**를 통해 비정형 데이터를 직관적으로 관리할 수 있음.

💡 결정: 1인 개발 체제에서는 스키마가 '단일 진실 공급원(SSOT)' 역할을 하여 개발 피로도를 극단적으로 낮춰주는 것이 중요함. 압도적인 자동 완성(Auto-completion)과 개발 경험(DX)을 제공하는 Prisma를 최종 선택함.

---

4. 예상되는 반박 및 내 생각 (Trade-off & Architecture)

Q1. Prisma는 LBS를 위한 PostGIS 연산이나 고도로 복잡한 통계 쿼리를 지원하지 못하는 명확한 한계가 있지 않은가?

• 내 생각: 정확한 지적임. Prisma만으로는 PostGIS의 K-NN(<->) 거리 계산 쿼리를 객체 메서드 형태로 깔끔하게 작성할 수 없음.
• 하지만 전체 애플리케이션의 80%는 기본적인 CRUD와 JSON/배열 데이터 조작임. 이 80%의 영역은 Prisma의 생산성으로 빠르게 쳐내고, 나머지 20%의 복잡한 위치 기반 쿼리만 $queryRaw를 활용해 안전한 원시 쿼리(Raw Query)로 분리하는 '실용주의적(Pragmatic)' 접근법이 프로젝트 완성 속도를 극대화하는 최선의 전략임.

Q2. Prisma는 내부에 Rust 기반의 무거운 Query Engine을 띄우기 때문에, 서버 메모리 소모가 크고 성능 병목이 생길 수 있다는 우려가 있는데?

• 내 생각: 과거 버전에서는 분명히 존재했던 단점이나, 최근 Prisma 5+ 버전부터 Node-API 및 JSON 프로토콜을 도입하여 엔진 오버헤드와 콜드 스타트 문제가 획기적으로 개선되었음.
• 여전히 얇은 ORM(Drizzle 등)보다는 무겁지만, 완벽한 타입 추론과 런타임 에러 사전 방지라는 강력한 이점이 그 단점을 상쇄하고도 남음. 적절한 인덱스 설계와 커넥션 풀링(Connection Pooling)을 동반한다면, 현재 예상되는 트래픽 규모에서는 엔진 오버헤드보다 **'개발자 리소스 절약'**이 주는 비즈니스적 가치가 훨씬 큼.

---

5. 결론

1. 백엔드 Data Access Layer에 생산성과 타입 안정성을 모두 잡기 위해 ORM 도입을 결정함.
2. 여러 대안 중, PostgreSQL의 특수 기능(Array, JSONB)과 완벽한 시너지를 내며, 스키마 주도 개발(Schema-driven)로 압도적인 DX를 제공하는 Prisma를 최종 채택함.
3. ORM이 모든 것을 해결할 수 없음을 인정하고, PostGIS 등 한계에 부딪히는 지점은 적극적으로 원시 쿼리를 혼용하는 유연한 아키텍처를 가져갈 계획임.