Kysely 언제 써야 하는가 — QueryDSL 대안으로서 Node 백엔드에서의 정확한 사용 시점

Node/TypeScript 환경에서 데이터 접근 계층을 설계할 때 항상 부딪히는 문제가 있다.

• ORM은 편하지만 복잡한 쿼리에 약하다
• Raw SQL은 강력하지만 타입 안정성이 없다

이 사이에서 Kysely는 명확한 포지션을 가진다.

👉 “타입 안전 + SQL 직접 제어”

이 글에서는 언제 Kysely를 써야 하는지를 실무 기준으로 정리한다.

---

🚀 Kysely 한 줄 정의

Kysely는 TypeScript 기반의 타입 안전 SQL Query Builder다.

• SQL을 그대로 쓰면서
• 컴파일 타임 타입 체크를 보장한다

👉 쉽게 말하면
“Node에서 QueryDSL 역할”

---

✅ 1. Kysely를 써야 하는 시점

🔥 1) 정산 / 통계 / 집계 쿼리

가장 대표적인 사용 케이스다.

 

const result = await db
.selectFrom("settlement")
.select([
"status",
sql<number>`SUM(amount)`.as("totalAmount"),
])
.groupBy("status")
.execute()

 

왜 Kysely인가?

• ORM → group by, sum 복잡
• QueryDSL → Java에서만 가능

👉 Node에서는 Kysely가 정답

---

🔥 2) 복잡한 JOIN + 동적 조건

 

await db
.selectFrom("payment as p")
.innerJoin("refund as r", "p.id", "r.payment_id")
.where((qb) =>
qb.or([
qb("p.status", "=", "COMPLETED"),
qb("r.status", "=", "APPROVED"),
])
)

 

특징

• 조건 조합 자유도 높음
• SQL 제어 가능

👉 ORM으로는 유지보수 지옥

---

🔥 3) N+1 문제 회피가 중요한 경우

ORM은 구조상 N+1이 발생하기 쉽다.

👉 Kysely는 애초에 SQL 기반이라
한 번에 조회 설계 가능

---

🔥 4) Read Model (CQRS) 설계

👉 이게 핵심이다

Write → ORM (Prisma / TypeORM)
Read → Kysely

 

이유

• write: 트랜잭션, 엔티티 중심
• read: 성능, 조회 최적화

👉 Kysely는 조회 전용 계층에 최적

---

🔥 5) 대용량 데이터 (Batch / Analytics)

• 수백만 건
• 정산 배치
• 로그 분석

👉 ORM 쓰는 순간 성능 망가진다

👉 Kysely + 인덱스 설계 = 안정

---

❌ 2. Kysely 쓰면 안 되는 시점

❌ 1) 단순 CRUD

 

createUser()
updateUser()

 

👉 이건 Prisma가 더 빠르고 깔끔

---

❌ 2) 도메인 중심 로직

• 엔티티 상태 변경
• 트랜잭션 처리

👉 ORM이 맞다

---

❌ 3) 팀이 SQL 못 다룰 때

👉 Kysely는 결국 SQL이다

• JOIN 이해 못하면 못 씀
• 인덱스 모르면 성능 박살

---

⚖️ 3. Kysely vs ORM vs QueryDSL

기준                                                               Kysely                                   Prisma                        QueryDSL

 

타입 안전	높음	높음	매우 높음
SQL 제어	매우 높음	낮음	높음
복잡 쿼리	강함	약함	강함
생산성	중	높음	중
런타임 성능	높음	중	높음

---

🧩 4. 실무 추천 아키텍처

정산 시스템 기준

[ Write Model ]
- Prisma / TypeORM
- 트랜잭션 처리
- 도메인 로직

[ Read Model ]
- Kysely
- 집계 / 조회 / 리포트

[ Batch ]
- Kysely
- 대량 데이터 처리

 

👉 이 구조가 가장 안정적이다

---

⚠️ 5. 실무에서 자주 터지는 문제

1) SQL 설계 없이 Kysely 쓰는 경우

👉 그냥 ORM보다 더 위험

---

2) 인덱스 없이 집계 돌리는 경우

👉 정산 시스템 바로 장애

---

3) 타입만 믿고 쿼리 검증 안 하는 경우

👉 데이터 정합성 깨짐

---

🔥 6. 핵심 결론

👉 Kysely는 “ORM 대체재”가 아니다

👉 “QueryDSL 역할을 하는 조회 최적화 도구”

---

💡 한 줄 요약

👉 복잡한 조회가 시작되는 순간, Kysely로 넘어가라