ORM은 무겁고 raw SQL은 불안하다면? Bun에서 타입 안전하게 SQL 쓰는 법

SQL은 직접 쓰고 싶은데 타입은 포기 못 하겠어요

데이터베이스를 다뤄본 분이라면 한 번쯤 이 고민을 해봤을 거예요. SQL을 손으로 직접 쓸까, 아니면 ORM을 쓸까. 둘 다 장단점이 뚜렷하거든요.

ORM이 뭐냐면, 우리가 SQL을 직접 안 쓰고도 코드로 데이터베이스를 다룰 수 있게 해주는 도구예요. db.user.findMany({ where: { age: 20 } }) 이렇게 쓰면 알아서 SELECT * FROM user WHERE age = 20 같은 SQL로 바꿔서 실행해주는 거죠. Prisma, Drizzle, TypeORM 같은 게 대표적이에요. ORM의 진짜 매력은 타입 안전성(type-safety)이에요. 쿼리 결과가 어떤 모양인지 타입스크립트가 미리 알고 있어서, 없는 컬럼을 꺼내려고 하면 에디터가 빨간 줄로 바로 알려주거든요.

문제는 ORM이 만능이 아니라는 거예요. 복잡한 조인이나 윈도우 함수, 서브쿼리 같은 걸 쓰려고 하면 ORM 문법이 오히려 더 어렵고, 가끔은 ORM이 비효율적인 SQL을 몰래 생성해서 성능 문제를 일으키기도 해요. 그래서 많은 개발자가 결국 ‘그냥 SQL 직접 쓰자’로 돌아가는데, 이러면 타입 안전성을 잃어버려요. 쿼리 결과가 any가 되니까 오타를 내도 모르고, 컬럼 이름이 바뀌어도 런타임에서야 터지는 거죠.

그 사이의 답: SQL은 직접 쓰되, 타입은 자동 생성

bun-sqlgen이 노리는 지점이 바로 여기예요. 핵심 아이디어는 이래요. 개발자는 raw SQL을 직접 작성한다. 그러면 도구가 그 SQL을 읽고 결과에 딱 맞는 타입스크립트 타입을 자동으로 만들어준다. ORM처럼 SQL을 숨기지 않으면서도, 직접 SQL을 쓸 때 잃어버리는 타입 안전성은 그대로 챙기는 거죠.

이게 가능한 이유는 SQL이 사실 굉장히 구조적인 언어라서예요. SELECT id, name FROM users라는 쿼리를 보면 결과가 id와 name 두 컬럼을 가진다는 걸 알 수 있고, 데이터베이스 스키마를 들여다보면 id는 정수, name은 문자열이라는 것도 알 수 있잖아요. 이 정보를 조합하면 { id: number; name: string }라는 타입을 기계가 자동으로 뽑아낼 수 있는 거예요. bun-sqlgen은 이 과정을 빌드 타임(코드를 실행하기 전 단계)에 미리 해두는 코드 생성기(code generator)예요.

그리고 이름에서 보이듯 Bun 런타임에 초점을 맞췄어요. Bun이 뭐냐면, Node.js를 대체하려는 빠른 자바스크립트 런타임인데, SQLite 드라이버(bun:sqlite)나 SQL 클라이언트가 아예 런타임에 내장돼 있어요. 그래서 외부 라이브러리를 잔뜩 깔지 않고도 가볍게 DB를 다룰 수 있는데, bun-sqlgen은 이 Bun 환경에 자연스럽게 얹혀서 타입만 보태주는 식이에요.

비슷한 도구들과 비교해보면

사실 이 ‘SQL 우선, 타입 자동 생성’ 접근은 bun-sqlgen이 처음은 아니에요. Go 진영에는 sqlc라는 아주 유명한 도구가 있어요. SQL 파일을 써두면 Go 코드와 타입을 자동으로 만들어주는 건데, 평이 워낙 좋아서 ‘SQL은 직접 쓰는 게 제일 솔직하다’는 철학을 가진 사람들이 많이 써요. 타입스크립트 쪽에는 PostgreSQL용 PgTyped가 비슷한 일을 하고요.

여기서 헷갈리기 쉬운 게 Kysely나 Drizzle 같은 ‘쿼리 빌더’인데, 이건 살짝 결이 달라요. 쿼리 빌더는 SQL을 문자열로 쓰는 게 아니라 db.selectFrom('users').select('name')처럼 메서드를 체이닝해서 SQL을 조립하는 방식이거든요. 타입 안전하긴 한데, 결국 SQL을 코드로 흉내 내는 거라 진짜 SQL이랑은 한 다리 건너 있는 느낌이에요. 반면 bun-sqlgen 같은 코드 생성 방식은 ‘내가 쓴 SQL이 곧 진실’이라서, DB를 깊게 다루는 사람들에게 더 직관적일 수 있어요.

한국 개발자에게

요즘 Bun이 빠른 속도와 올인원 구성(번들러, 테스트 러너, 패키지 매니저가 다 들어 있음) 덕분에 사이드 프로젝트나 신규 서비스에서 점점 채택되고 있잖아요. 만약 Bun으로 가볍게 SQLite 기반 서비스를 만든다면, ‘ORM을 깔기는 무겁고 raw SQL은 타입이 불안한’ 딱 그 애매한 구간에서 이런 도구가 꽤 유용할 수 있어요.

더 중요한 건 이런 도구를 통해 배우는 사고방식이에요. ‘추상화(ORM)로 SQL을 가릴 것이냐, 아니면 SQL을 정면으로 마주하고 도구의 도움을 받을 것이냐’는 백엔드 설계에서 계속 마주치는 선택이거든요. 정답은 없지만, 적어도 ‘ORM이 아니면 타입을 포기해야 한다’는 건 더 이상 사실이 아니라는 걸 알아두면 선택지가 넓어져요.

한 줄 정리: SQL을 직접 쓰는 솔직함과 타입스크립트의 안전망, 둘 다 포기하지 않아도 된다는 게 핵심이에요. 여러분은 ORM파인가요, 아니면 raw SQL파인가요? 그 이유가 궁금하네요.