[kysely] 1. 어떻게 처음 발견하게 되었는가 - 1?

예전에 토이 프로젝트에서 nestjs를 사용하면서 mysql DB와 연결하기 위해 TypeORM을 사용했던 적이 있었다. 당시에는 DB를 먼저 설계하고 그 다음 DB를 서버와 연동했는데, 아래의 nestjs의 공식 문서에 TypeORM을 활용하는 방법이 친절하게 설명되어 있어서 이를 사용했었다. 

Database | NestJS - A progressive Node.js framework

Documentation | NestJS - A progressive Node.js framework

 

하지만 쓰다보면서 이게 내가 원하는 것은 아닌것 같은데...? 하는 생각이 조금씩 들었다. 어색했던 지점은 다음과 같다.

• TypeORM은 서비스를 Entity(이하 엔티티) 기반으로 바라보며, DB에서 가져온 정보도 모두 엔티티로 변환한다. 그리고 DB에서 정보를 가져오는 과정을 모두 typeorm에 맡긴다. 즉, 서비스 입장에서 DB는 엔티티를 불러오거나 저장하기 위한 용도로 사용하는 것이고, 테이블을 어떻게 설계해서 최적화를 할지, 쿼리를 어떻게 날려서 최적화를 할지 하는 고민은 내가 아닌 typeorm의 몫이며, typeorm은 이를 잘 수행해내지 못한다. typeorm은 일반적인 상황에서의 쿼리를 만들어내는 것에 어느 정도 잘 대응해주는 대신 개발자가 개입해야 하는 특수한 상황에서는 그리 친절하지 못하다. 물론 raw query를 작성해서 날리는 것도 가능하긴 하지만... 이 길로 가는 순간 기존에 편하게 사용할 수 있던 타입힌트가 잘 제공되지 않고, 기존 엔티티들에 제공되던 기능들도 사용이 어렵고, ... 그럴 거면 orm을 쓸 이유가 줄어든다.
• 검색하다 보면 'orm을 쓰면 DB에 대해 잘 모르고 쿼리를 작성할 줄 몰라도 DB를 쓸 수 있도록 기능을 제공해준다'는 측면을 긍정적으로 바라보는 글들이 많이 발견된다. mysql, postgresql, sqlite, ... 등을 직접 다뤄본 적이 없어도 이를 활용해서 서비스를 만들 수 있게 된다는 것. 물론 이런 관점으로 서비스를 바라보고 구현하는 것이 도움이 되는 경우도 있겠지만, DB를 알고 쿼리를 작성할 수 있는 입장에서는 굳이...? 싶다는 생각이 든다. 오히려 쿼리를 직접 작성하지 못하고 orm이 제공해주는 인터페이스를 통해서 간접적으로 작성해야 하는데, 이게 꽤 답답한 느낌을 준다.
• 엔티티 기반으로 마이그레이션 코드를 작성하게 되어있는 것도 문제. 나는 내가 직접 DB에 테이블을 만들고 이를 서버에 연결하고 싶은데, orm의 관점으로는 엔티티를 먼저 구현하고 이에 대응되는 테이블 생성을 orm의 migration 기능에 맡겨야 하는 것이다. 물론 테이블을 엔티티로 바꿔주는 것에 대한 수요가 당연히 존재하고(Converting database to ypeorm entities (Reverse engineering) · Issue #540 · typeorm/typeorm · GitHub), 이를 수행해주는 패키지가 있긴 하다(GitHub - Kononnable/typeorm-model-generator: Generates models for TypeORM from existing database.). 하지만 이 프로젝트는 현재 더 이상 관리가 되지 않고 있는데(Maintenance phase · Issue #329 · Kononnable/typeorm-model-generator · GitHub), 프로젝트 개발자는 프로젝트를 더 이상 관리하지 않기로 한 이유로 'typeorm에 데이터 손실을 유발할 수 있는 치명적인 버그가 오랫동안 고쳐지지 않고 있음'을 들고 있다. 저 이슈 글의 마지막에 '새로 typeorm을 쓰려고 하는 사람들에게 재고할 기회를 주기 위해 이 프로젝트를 maintenance 상태로 돌린다'고 써놓은 것은 덤.

그래서 TypeORM을 대체할 수 있는 방식을 찾아다니다가 query builder의 존재에 대해 알게 되었다. 아래의 글에 orm과 query builder를 사용하는 관점의 차이에 대해 간단하면서도 잘 설명되어 있는것 같아서 가져와보았다. (추후 시간 나면 번역 예정)

Why Prisma ORM? Comparison with SQL query builders & ORMs | Prisma Docs

Why Prisma ORM? Comparison with SQL query builders & ORMs

SQL vs ORMs vs Query Builders | Compare | Prisma's Data Guide

SQL vs ORMs vs Query Builders | Compare | Prisma's Data Guide

 

위의 글에는 prisma orm이 최고라고 써있는데(prisma에서 작성한 글이니 당연히 그렇겠지만), 사실 위의 내용들을 찾아보던 당시 이런 홍보에 혹해서 prisma를 사용해볼까 고민했었다. TypeORM 말고 prisma 쓰세요- 같은 글들도 잘 정리되어 있어서(Prisma ORM vs TypeORM | Prisma Docs) 꽤 관심이 가기도 했고, typeorm model generator 프로젝트의 마지막 정리 글에 typeorm을 대체할만한 다른 프로젝트 중 하나로 언급이 되어있기도 했기 때문이다.

 

하지만 자료를 좀 더 찾아보던 중 mysql의 도형 타입들을 지원하지 않는다는(?) 문서를 발견하고 넘어갔던 기억이 있다. 지금 글을 작성하고 있는 시점(2024년 3월)에도 mysql에 있는 각종 geometry 타입들에 대한 Native type mappings 지원을 하지 않는 것으로 보인다.

https://www.prisma.io/docs/orm/overview/databases/mysql#native-type-mappings

MySQL database connector

이에 대해 자세히 알아보고 나서 prisma를 사용할지에 대한 고민을 했어도 좋았겠지만 당시에는 대체할만한 다른 프로젝트를 더 찾아보자고 하는 쪽으로 더 생각이 기울었고, 그래서 쿼리 빌더쪽을 좀 더 자세히 살펴보기 시작하는데...

 

(다음 글에 이어서 계속)