TypeScript 생태계 2026 완전 정리 — Bun · Deno · Hono · Elysia · NestJS · Effect · tRPC · Drizzle · Prisma · Zod · Vitest 딥다이브

"JavaScript의 자유 위에 TypeScript의 안전을 얹고, 그 위에 Effect로 함수형 효과를, Bun으로 속도를, Hono로 엣지를 더한다 — 이것이 2026년의 TypeScript 백엔드다." — TypeScript Conf 2025 키노트 요약

TypeScript가 2012년 Anders Hejlsberg의 손에서 0.8로 등장한 이후 14년이 지났다. 그 사이에 TypeScript는 단순한 "타입을 붙인 JavaScript"에서, 거대한 백엔드와 풀스택 생태계의 표준 언어로 자리잡았다. 2026년 5월 기준, npm 다운로드 통계에서 TypeScript 컴파일러는 매주 1억 다운로드를 넘기고, Stack Overflow Developer Survey 2025에서 TypeScript는 "가장 사랑받는 언어" 4위, "가장 많이 쓰는 언어" 3위에 올랐다.

특히 백엔드 영역의 변화가 극적이다. Node.js는 22 LTS와 24 Active 두 메이저가 공존하고, Bun 1.2는 더 이상 "실험적인 빠른 런타임"이 아니라 실제 프로덕션에서 채택되는 대안이 되었으며, Deno 2.x는 npm 호환성을 완성하면서 다시 무대로 돌아왔다. Hono는 V8 isolate 위에서 가장 많이 쓰이는 엣지 프레임워크가 됐고, Elysia는 Bun 전용 고성능 프레임워크로, NestJS 11은 엔터프라이즈 표준으로 자리잡았다. 이 글에서는 TypeScript 5.6, 런타임 3종, 웹 프레임워크 7종, ORM 5종, 검증 라이브러리 5종, 워크플로우 엔진, 테스트 도구, 빌드 도구, 그리고 한국·일본의 실제 채택 사례까지 한 번에 정리한다.

1. 2026년 TypeScript 백엔드 지도

2026년 5월 시점, TypeScript 백엔드는 크게 다음 다섯 축으로 정리된다.

가장 큰 변화는 "런타임 선택이 더 이상 'Node냐 아니냐'의 문제가 아니다"라는 점이다. Bun 1.2는 Node 호환 모드에서 거의 모든 npm 패키지를 돌리고, Deno 2.x는 npm:/jsr: 스킴으로 npm 생태계를 그대로 흡수했다. 그래서 2026년의 선택 기준은 "어떤 런타임이 가장 빠른가"가 아니라 "우리 팀의 운영 도구·관측 도구·플랫폼이 어느 쪽을 지원하는가"로 옮겨갔다.

2. TypeScript 5.6 — using declarations · isolated declarations · ISO 8601 Date

TypeScript 5.6은 2025년 후반에 정식 릴리스되었고, 2026년 5월 기준 5.7이 RC 단계다. 백엔드 관점에서 5.6의 핵심 기능 세 가지를 짚어둘 가치가 있다.

첫 번째는 using declarations (ECMAScript Explicit Resource Management). using db = await pool.connect() 처럼 선언하면 스코프를 벗어날 때 자동으로 Symbol.dispose나 Symbol.asyncDispose가 호출되어 리소스가 닫힌다. DB 커넥션, 파일 핸들, 트랜잭션 같은 자원 관리에 RAII에 가까운 패턴을 쓸 수 있게 됐다.

두 번째는 isolated declarations (--isolatedDeclarations). 모든 export에 명시적 타입 어노테이션을 강제하는 모드로, 빌드 도구가 타입 정보를 추론 없이 추출할 수 있다. Bun, esbuild, swc, oxc 같은 비-tsc 빌더가 .d.ts 파일을 직접 생성할 수 있어, 모노레포에서 tsc -b의 병목을 크게 줄였다.

세 번째는 ISO 8601 Date 처리 개선. new Date('2026-05-16T00:00:00Z') 같은 ISO 문자열 처리에서 타임존 추론과 Intl API가 모두 강화됐고, 백엔드 로깅·관측 도구의 타임스탬프 일관성이 좋아졌다.

// using declarations 예시
import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })

async function fetchUser(id: string) {
  await using client = await pool.connect()
  const result = await client.query('SELECT * FROM users WHERE id = $1', [id])
  return result.rows[0]
  // 스코프 종료 시 client[Symbol.asyncDispose]() 자동 호출
}

5.6은 또한 --noUncheckedSideEffectImports를 추가해, import './styles.css' 같은 사이드이펙트 임포트가 타입 체크 단계에서 누락되지 않도록 강화했다.

3. Node.js 22 LTS와 24 Active — built-in fetch, test runner, watch mode

Node.js는 2026년 5월 시점에 22.x가 LTS(Active LTS 단계), 24.x가 Active(개발 중인 다음 LTS 후보), 26.x가 곧 분기를 준비 중이다. 22 LTS의 변화 중 백엔드에 직접 영향을 주는 것들을 정리한다.

• Built-in fetch와 WebSocket: undici 기반의 fetch는 22에서 안정 상태로 승격, WebSocket 클라이언트도 표준화.
• node:test: 내장 테스트 러너가 22에서 안정. Jest나 Mocha 없이도 가벼운 단위 테스트가 가능.
• --watch 모드: node --watch app.ts만으로 파일 변경 감지·재시작. nodemon 대체.
• --env-file=.env: dotenv 없이도 환경변수 파일 로딩.
• Permission Model: --permission --allow-fs-read=... 같은 권한 격리, Deno 스타일.

24.x는 V8 12.8, ICU 75를 업데이트하고, node --experimental-sqlite로 SQLite 내장을 베타로 노출한다. 또한 24부터는 node --experimental-strip-types로 TypeScript 파일을 트랜스파일 없이 직접 실행할 수 있다(타입 체크는 별도).

# Node 22 LTS에서 TypeScript 직접 실행 (실험)
node --experimental-strip-types app.ts

# 내장 테스트 러너로 .test.ts 실행
node --test --experimental-strip-types '**/*.test.ts'

# .env 파일 로드 + 권한 모델
node --env-file=.env --permission --allow-fs-read=./data app.ts

2026년 기준, Node.js 본체에 TypeScript 실행이 들어오면서 "Node + tsx" 조합의 필요성이 줄었다는 평가가 많지만, 여전히 프로덕션 환경에서는 tsc로 사전 빌드하는 흐름이 표준이다.

4. Bun 1.2 — Node 호환, 빠른 시작, 내장 번들러·SQLite·Redis

Bun은 Jarred Sumner가 2021년 시작한 Zig 기반 JavaScript 런타임으로, JavaScriptCore(WebKit) 엔진을 쓴다. 2024년 1.0이 나오고 1.5년 만에 1.2까지 발전하면서 "실험적 빠른 런타임"에서 "Node 대체재"로 성격이 변했다.

1.2의 주요 특징:

• Node 호환성: node_modules, CommonJS, ESM, package.json의 모든 필드를 그대로 지원. Express, Fastify, NestJS, Next.js 대부분이 그대로 돈다.
• 속도: 콜드 스타트가 Node 대비 4배 빠르고, bun install이 npm 대비 25배 빠르다(공식 벤치마크 기준).
• 내장 번들러: bun build 명령으로 esbuild급 번들링을 별도 도구 없이.
• 내장 테스트: bun test는 Jest 호환 API를 제공.
• 내장 SQLite: import { Database } from "bun:sqlite".
• 내장 Redis/HTTP/WebSocket: Bun.serve(), Bun.redis()로 외부 의존 최소화.
• Bun.lockb → bun.lock: 1.2에서 텍스트 lockfile 옵션을 추가, 코드리뷰 친화도가 올라감.

// Bun.serve()로 HTTP 서버 (Hono 없이 순수 Bun)
import { Database } from "bun:sqlite"

const db = new Database(":memory:")
db.run("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
db.run("INSERT INTO users (name) VALUES (?)", ["Toss"])

Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url)
    if (url.pathname === "/users") {
      const rows = db.query("SELECT * FROM users").all()
      return Response.json(rows)
    }
    return new Response("Not Found", { status: 404 })
  },
})

console.log("Listening on http://localhost:3000")

2026년에는 Vercel, Cloudflare, Railway, Fly.io 같은 PaaS가 모두 Bun 빌드 런타임을 1급 지원하고, 한국에서는 토스 일부 사이드프로젝트와 라이브 백엔드, 일본에서는 메르카리·LayerX의 일부 마이크로서비스가 Bun으로 운영된다.

5. Deno 2.x — npm·jsr 호환, Permissions, Deno Deploy

Deno는 Ryan Dahl이 Node를 만든 뒤 "10가지 후회"를 정리해 2020년 출시한 런타임이다. 1.x 시기에는 "npm 비호환"이라는 큰 한계가 있었지만, 2.0(2024년 10월) 이후 분위기가 바뀌었다.

2.x의 핵심:

• npm/jsr 호환: import express from "npm:express", import zod from "jsr:@zod/zod" 처럼 직접 임포트. node_modules 자동 생성도 옵션으로 제공.
• Workspace 모노레포: deno.json에 workspaces 필드.
• Permission 모델: 기본 권한 없음. --allow-net, --allow-read 등으로 허용.
• deno compile: 단일 바이너리 생성. Lambda/Worker 배포에 적합.
• Deno Deploy: 전세계 35개 리전의 V8 isolate 기반 엣지 플랫폼.
• 내장 deno test, deno lint, deno fmt.

// deno.json에 의존성 명시 + 권한 격리 실행
// $ deno run --allow-net --allow-env main.ts
import { Hono } from "jsr:@hono/hono"
import { z } from "npm:zod@4"

const app = new Hono()

const UserSchema = z.object({ id: z.string(), email: z.string().email() })

app.post("/users", async (c) => {
  const body = UserSchema.parse(await c.req.json())
  return c.json({ ok: true, user: body })
})

Deno.serve({ port: 8000 }, app.fetch)

2026년 기준 Deno는 jsr.io 패키지 레지스트리를 안착시키며, "TypeScript 우선 보안 런타임"이라는 정체성을 굳혔다. 단, 채택률은 여전히 Node·Bun보다 낮고, 주된 사용처는 엣지·CLI·스크립트 영역이다.

6. 패키지 매니저 — npm 11 · pnpm 10 · Yarn 5 Berry · Bun

2026년 5월 시점, JavaScript 패키지 매니저 4종은 각자의 영역을 굳혔다.

pnpm 10의 변화가 가장 흥미롭다. pnpm install의 lifecycle script 실행을 기본 차단(보안), pnpm dlx가 npx 대체로 일반화, catalogs 기능으로 모노레포 의존성 버전 중앙 관리. npm 11은 워크스페이스 명령 일관성과 audit fix 정확도를 개선했고, Yarn 5는 Plug'n'Play를 기본으로 두면서도 nodeLinker: node-modules 옵션으로 호환 모드를 안정화했다.

# pnpm 10 catalogs 예시 (pnpm-workspace.yaml)
# catalog 정의 → 모든 패키지에서 catalog:default 참조
#
# packages:
#   - 'apps/*'
#   - 'packages/*'
# catalog:
#   typescript: ^5.6.0
#   zod: ^4.0.0

# 워크스페이스 전체에 패키지 설치
pnpm -r add zod@catalog:

# Bun 워크스페이스
bun install --frozen-lockfile

# Yarn 5 (Berry) Plug'n'Play
yarn install --immutable

성능 벤치마크상 Bun이 가장 빠르지만(콜드 인스톨 기준 npm 대비 25배), 한국·일본의 대규모 모노레포에서는 pnpm 10이 가장 폭넓게 쓰인다. Toss, 쿠팡, 메르카리, freee가 모두 pnpm 기반.

7. Hono — V8 isolate에서 가장 많이 쓰이는 엣지 프레임워크

Hono(炎)는 한국계 일본 개발자 Yusuke Wada가 만든 초경량 웹 프레임워크다. Express 스타일 API에 ultra-fast 라우터와 어떤 런타임에서도 돌아가는 호환성을 결합했다.

지원 런타임이 광범위하다: Cloudflare Workers, Deno, Bun, Node.js, AWS Lambda, Vercel Edge, Fastly Compute. 같은 코드를 그대로 옮길 수 있다는 것이 핵심 가치.

2026년 5월 시점 주요 특징:

• Ultra-fast Router: TrieRouter / RegExpRouter / LinearRouter — 환경별 최적 라우터 자동 선택.
• 타입 안전 미들웨어: 미들웨어가 컨텍스트에 더한 값이 다음 핸들러 타입에 반영됨.
• hono/zod-validator, hono/typebox-validator: 검증 라이브러리 통합.
• hono/jsx: 서버사이드 JSX 렌더링 (React 의존 없음).
• HonoX: Hono 기반 메타 프레임워크(Next.js 풀스택 대안).

// hono로 작성한 최소한의 REST API
import { Hono } from "hono"
import { zValidator } from "@hono/zod-validator"
import { z } from "zod"

const app = new Hono()

const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1),
})

app.get("/", (c) => c.text("Hello Hono!"))

app.post("/users", zValidator("json", CreateUserSchema), async (c) => {
  const body = c.req.valid("json")
  // body는 { email: string; name: string } 타입으로 추론됨
  return c.json({ ok: true, user: body }, 201)
})

// Cloudflare Workers, Deno, Bun, Node 모두 동일
export default app

Cloudflare가 공식 채택한 결과 2026년 기준 Workers 코드의 70% 이상이 Hono로 작성되고, Vercel, Deno Deploy, Bun, Fastly에서도 빠르게 확산 중. NPM 다운로드는 2024년 주당 50만에서 2026년 5월 주당 350만으로 7배 성장.

8. Elysia — Bun 전용 고성능 프레임워크

Elysia는 Hono와 자주 비교되지만 방향이 다르다. Bun에 특화해 JIT 최적화 가능한 코드 생성을 적극 활용하고, 타입 시스템을 통한 Eden end-to-end 타입 안전성을 제공한다.

핵심 차별점:

• Bun 네이티브: 다른 런타임 호환을 포기하고 Bun에서 최대 성능.
• 컴파일 타임 라우팅: 코드 생성으로 가장 빠른 라우팅.
• Eden: 서버 라우트 타입이 클라이언트에서 그대로 추론되는 tRPC 유사 기능.
• TypeBox 통합: 검증 라이브러리로 TypeBox를 기본 채택.
• OpenAPI 자동 생성.

import { Elysia, t } from "elysia"

const app = new Elysia()
  .get("/", () => "Hello Elysia")
  .post(
    "/users",
    ({ body }) => ({ ok: true, user: body }),
    {
      body: t.Object({
        email: t.String({ format: "email" }),
        name: t.String({ minLength: 1 }),
      }),
    }
  )
  .listen(3000)

export type App = typeof app
// 클라이언트에서 Eden을 통해 App 타입을 그대로 import

벤치마크상 단순 JSON 응답 처리량이 Hono+Bun 대비 1.5배 이상, Express 대비 20배 이상 빠르다. 다만 Bun 의존이 강해 멀티 런타임 전략을 쓰는 팀에는 부적합.

9. NestJS 11 — 엔터프라이즈 표준, Angular 풍 DI

NestJS는 Kamil Myśliwiec가 2017년 만든 Angular 스타일 DI 컨테이너 기반 백엔드 프레임워크다. 2026년 5월 시점 11.x가 메이저로, 다음 변화가 핵심:

• Express 5와 Fastify 5 모두 1급 지원: 어댑터 선택 가능.
• TypeScript 5.6 + Stage 3 데코레이터 정식 지원.
• Microservices·GraphQL·WebSocket·Bull 큐 모듈 표준화.
• OpenAPI/Swagger 자동 생성 안정성 향상.
• Standalone 애플리케이션 모드 — HTTP 없이 CLI 도구로도 활용.

NestJS의 가치는 "대규모 팀이 컨벤션 충돌 없이 함께 일할 수 있는 구조"다. Module / Controller / Service / Provider 계층이 명확하고, 의존성 주입이 강제되어 단위 테스트가 쉽다.

import { Controller, Get, Post, Body, Injectable, Module } from "@nestjs/common"
import { IsEmail, MinLength } from "class-validator"

class CreateUserDto {
  @IsEmail()
  email!: string

  @MinLength(1)
  name!: string
}

@Injectable()
class UsersService {
  private users: CreateUserDto[] = []
  create(dto: CreateUserDto) {
    this.users.push(dto)
    return dto
  }
  findAll() {
    return this.users
  }
}

@Controller("users")
class UsersController {
  constructor(private readonly users: UsersService) {}

  @Get()
  list() {
    return this.users.findAll()
  }

  @Post()
  create(@Body() body: CreateUserDto) {
    return this.users.create(body)
  }
}

@Module({
  controllers: [UsersController],
  providers: [UsersService],
})
export class AppModule {}

한국에서 카카오엔터프라이즈, 쿠팡 일부 팀, 야놀자가, 일본에서는 사이버에이전트·LINE의 일부 서비스가 NestJS 기반. "Spring Boot에 익숙한 자바 개발자가 TS로 넘어오기에 가장 익숙한 모양"이라는 평이 많다.

10. Fastify 5 · Express 5 · h3/Nitro · Encore.ts — 나머지 백엔드 프레임워크

Fastify 5는 Matteo Collina와 Tomas Della Vedova가 만든 Node 표준 고성능 프레임워크다. Express 대비 2배 이상 빠르고, JSON 스키마 기반 검증, 풍부한 플러그인 생태계가 강점. 2026년 5월 기준 v5에서 ESM/TypeScript 타이핑이 크게 개선됐다.

Express 5는 17년만의 메이저 업데이트(2024년 GA). async 에러 처리 표준화, Express Router를 라이브러리로 분리, body parser 내장. 여전히 npm 다운로드 1위 백엔드 프레임워크.

h3/Nitro는 Nuxt 팀(UnJS)이 만든 H3 ASGI-스타일 핸들러와 그 위의 Nitro 서버 빌더. Nuxt는 Nitro 위에 빌드되고, 일반 백엔드로도 직접 쓸 수 있다. Cloudflare/Vercel/Deno/Bun 등 다양한 어댑터 제공.

Encore.ts는 "백엔드 데이터 인프라까지 코드로 정의"하는 풀스택 백엔드. DB·큐·크론·API를 모두 TypeScript 타입으로 선언하고 Encore가 인프라를 프로비저닝. 사용량은 작지만 DX가 화제.

// Fastify 5 + Zod 4 plugin
import Fastify from "fastify"
import { z } from "zod"
import { serializerCompiler, validatorCompiler, ZodTypeProvider } from "fastify-type-provider-zod"

const app = Fastify({ logger: true }).withTypeProvider<ZodTypeProvider>()
app.setValidatorCompiler(validatorCompiler)
app.setSerializerCompiler(serializerCompiler)

app.route({
  method: "POST",
  url: "/users",
  schema: {
    body: z.object({ email: z.string().email(), name: z.string().min(1) }),
    response: { 201: z.object({ ok: z.literal(true) }) },
  },
  handler: async (req, reply) => {
    // req.body 타입이 z.infer<...>로 자동 추론
    return reply.code(201).send({ ok: true })
  },
})

await app.listen({ port: 3000 })

11. Effect — TypeScript의 함수형 효과 시스템

Effect(이전 Effect-TS)는 Michael Arnaldi 주도로 만들어진, ZIO/Cats Effect/RIO에서 영감을 받은 TypeScript 효과 시스템 라이브러리다. 2024년 3.0이 나오고 2026년 5월 기준 3.10대로 안정화됐다.

핵심 개념:

• Effect<A, E, R>: 성공값 A, 실패 타입 E, 의존성 R. 타입에 에러와 의존성이 명시.
• Structured Concurrency: Effect.all, Effect.race, Effect.fork로 fiber 기반 동시성.
• Retry/Schedule: Effect.retry(Schedule.exponential("100 millis")) 같은 선언적 재시도.
• Layer: 의존성 주입 시스템. 모듈 간 R 합성.
• Schema: 검증·디코딩·인코딩 통합 (Zod 대안).
• STM: 소프트웨어 트랜잭셔널 메모리.

import { Effect, Schedule, Console, Layer } from "effect"

const fetchUser = (id: string) =>
  Effect.tryPromise({
    try: () => fetch(`/api/users/${id}`).then((r) => r.json()),
    catch: (e) => new Error(`fetch failed: ${String(e)}`),
  })

const program = Effect.gen(function* () {
  const user = yield* fetchUser("u_1").pipe(
    Effect.retry(Schedule.exponential("100 millis").pipe(Schedule.compose(Schedule.recurs(3))))
  )
  yield* Console.log(`got user: ${JSON.stringify(user)}`)
})

Effect.runPromise(program)

Effect를 풀스택으로 채택한 팀(예: Effectful Tech, 일부 핀테크)은 "예외가 사라졌다"는 표현을 쓴다. 의존성·에러·동시성 모두 타입에 표현되므로 대규모 백엔드 리팩터링이 안전해진다. 다만 학습 곡선이 가팔라, 작은 팀에는 과한 도구로 평가되기도 한다.

12. tRPC 11 — End-to-end 타입 안전 RPC

tRPC는 Alex Johansson이 만든 "REST나 GraphQL 없이 TypeScript 타입만으로 클라이언트·서버를 연결"하는 RPC 도구다. 2024년 v11이 나오면서 React Query v5, Tanstack Router, Next.js App Router와의 통합이 완성됐다.

핵심 특징:

• 타입 추론 only: 코드 생성 단계 없음. 서버 타입을 클라이언트가 그대로 import.
• Procedures: query·mutation·subscription 세 종류.
• Adapters: Express, Fastify, Next.js, Bun, Hono, AWS Lambda 모두 지원.
• Links: HTTP, WebSocket, batch, splitLink.
• v11 변화: AbortSignal 지원, output transformer 강화, FormData 입력.

// 서버
import { initTRPC } from "@trpc/server"
import { z } from "zod"

const t = initTRPC.create()

export const appRouter = t.router({
  user: t.router({
    byId: t.procedure
      .input(z.object({ id: z.string() }))
      .query(({ input }) => ({ id: input.id, name: "Toss user" })),

    create: t.procedure
      .input(z.object({ email: z.string().email(), name: z.string() }))
      .mutation(({ input }) => ({ ok: true, ...input })),
  }),
})

export type AppRouter = typeof appRouter

// 클라이언트
// import type { AppRouter } from "./server"
// const trpc = createTRPCClient<AppRouter>({...})
// const u = await trpc.user.byId.query({ id: "u_1" })
// → u: { id: string; name: string } 자동 추론

tRPC는 같은 모노레포에서 BE/FE를 함께 쓰는 풀스택 팀에 압도적 DX를 제공한다. 한국 토스, 일본 메르카리의 일부 풀스택 팀이 채택. 단, 다른 언어·외부 클라이언트와의 연동에는 GraphQL/OpenAPI가 더 적합.

13. GraphQL — Pothos · Yoga · Apollo Server 5

GraphQL은 2015년 Facebook에서 공개된 쿼리 언어로, TypeScript 생태계에서 가장 성숙한 분야 중 하나다. 2026년 핵심 스택:

• Pothos: 코드 우선 스키마 빌더. 데코레이터·플러그인 시스템.
• GraphQL Yoga 5: The Guild이 유지보수하는 가벼운 GraphQL 서버. Hono/Fastify 어댑터.
• Apollo Server 5: 가장 널리 쓰이는 GraphQL 서버. 2025년 5.0에서 Express 5/Fastify 5 어댑터.
• GraphQL Codegen: 스키마에서 TS 타입과 React Query 훅 생성.

// Pothos + GraphQL Yoga (Hono 위에서)
import SchemaBuilder from "@pothos/core"
import { createYoga } from "graphql-yoga"
import { Hono } from "hono"

const builder = new SchemaBuilder({})

builder.queryType({
  fields: (t) => ({
    hello: t.string({
      args: { name: t.arg.string({ required: true }) },
      resolve: (_, { name }) => `Hello, ${name}`,
    }),
  }),
})

const yoga = createYoga({ schema: builder.toSchema() })
const app = new Hono()
app.all("/graphql", (c) => yoga.fetch(c.req.raw, c.env))

export default app

대규모 BFF 패턴, 모바일 클라이언트와 함께 쓰는 백엔드, 마이크로프론트엔드를 합치는 GraphQL Gateway에서 여전히 GraphQL이 강세.

14. 검증 라이브러리 — Zod 4 · ArkType · Valibot · Effect Schema · TypeBox

런타임 검증 라이브러리는 TypeScript 백엔드의 핵심 인프라다. 5종을 비교한다.

Zod 4는 2025년 정식 릴리스로 v3 대비 번들 크기 50% 감소, 일부 케이스에서 검증 속도 3배 향상. ArkType은 type({ email: "string.email", age: "number<150" })처럼 TS 구문을 문자열로 표현하는 독특한 접근. Valibot은 트리쉐이킹으로 미사용 검증 코드를 빌드에서 제거. Effect Schema는 Effect 효과 시스템과 자연스럽게 연동. TypeBox는 JSON Schema가 즉시 필요한 경우(Fastify, Elysia) 1순위.

// Zod 4 vs Valibot vs ArkType 같은 스키마 비교
import { z } from "zod"
const ZodUser = z.object({ email: z.string().email(), age: z.number().min(0).max(150) })

import * as v from "valibot"
const ValibotUser = v.object({
  email: v.pipe(v.string(), v.email()),
  age: v.pipe(v.number(), v.minValue(0), v.maxValue(150)),
})

import { type } from "arktype"
const ArkUser = type({ email: "string.email", age: "0 <= number <= 150" })

// 모두 같은 결과: { email: string; age: number }

2026년 5월 npm 다운로드 기준 Zod가 압도적 1위, Valibot이 2위로 빠르게 성장, ArkType이 다크호스로 떠오르는 중.

15. ORM — Drizzle 0.40 · Prisma 6 · Kysely · MikroORM 6

JS/TS의 ORM 영역은 2024–2025년에 가장 격변한 분야다.

• Drizzle 0.40+: 가장 빠르게 성장. SQL DSL 그대로 TypeScript로 표현. 빌드 타임 마이그레이션 생성. Edge 런타임 1급 지원.
• Prisma 6: 가장 널리 쓰임. 2025년부터 Rust 엔진을 deprecate하고 TypeScript-only로 전환 진행 중. Prisma Postgres(자체 Serverless DB) 출시.
• Kysely: Type-safe SQL 빌더. ORM이 아닌 쿼리 빌더에 가까운 미니멀리즘. Drizzle보다 더 SQL에 가까움.
• MikroORM 6: TypeORM의 빈자리를 채운 데이터 매퍼 ORM. Unit of Work 패턴.
• TypeORM: 여전히 사용되지만 신규 채택은 줄어듦. NestJS의 데코레이터 친화 ORM.

// Drizzle 0.40 — 스키마와 쿼리
import { drizzle } from "drizzle-orm/postgres-js"
import { pgTable, serial, text, timestamp } from "drizzle-orm/pg-core"
import { eq } from "drizzle-orm"
import postgres from "postgres"

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  name: text("name").notNull(),
  createdAt: timestamp("created_at").defaultNow(),
})

const sql = postgres(process.env.DATABASE_URL!)
const db = drizzle(sql)

// 추론된 타입: { id: number; email: string; name: string; createdAt: Date }[]
const rows = await db.select().from(users).where(eq(users.email, "a@toss.im"))

Drizzle은 2024년 후반부터 Vercel, Cloudflare, Neon이 공식 권장 ORM으로 채택했고, 한국·일본 신규 프로젝트의 ORM 선택에서 Prisma와 거의 동률 또는 우위. Prisma는 Prisma Postgres로 "ORM+DB 번들"이라는 새 비즈니스 모델에 집중.

16. 워크플로우 엔진 — Temporal · Inngest · Trigger.dev · Hatchet · Restate

장기 실행 워크플로우(승인, 결제, 배치, 멀티 스텝 AI 파이프라인)는 TS 백엔드의 최대 난점 중 하나였다. 2026년에는 다음 다섯 도구가 표준 후보.

// Inngest 워크플로우 (멀티 스텝 + 재시도 + 대기)
import { Inngest } from "inngest"

const inngest = new Inngest({ id: "toss-app" })

export const onboardUser = inngest.createFunction(
  { id: "onboard-user", retries: 3 },
  { event: "user/signup" },
  async ({ event, step }) => {
    await step.run("send-welcome-email", async () => {
      // 이 단계는 실패 시 자동 재시도, 결과는 영속화
      return sendEmail(event.data.email)
    })

    await step.sleep("wait-1-day", "24h")

    await step.run("send-day1-tips", async () => sendDay1Tips(event.data.email))
  }
)

각 도구는 "단계 결과를 어디에 영속화하는가"가 핵심 차이. Temporal은 자체 서버, Inngest는 클라우드 SaaS+오픈소스, Trigger.dev는 자체 호스팅 가능, Hatchet은 Postgres, Restate는 자체 분산 KV.

17. 테스트 — Vitest 3 · Bun test · node:test · Playwright · Jest

테스트 도구는 빌드 도구와 함께 가장 빠르게 통합되는 영역이다.

• Vitest 3: Vite 기반의 TS 친화 테스트 러너. Jest 호환 API. 2025–2026년 사실상 표준.
• Bun test: Bun 런타임 내장. Vitest 호환 API. Bun 사용 팀의 1순위.
• node:test: Node 22+ 내장. 외부 의존 없이 가벼운 테스트.
• Playwright: 브라우저 E2E의 표준. Microsoft 유지보수.
• Jest 30: 여전히 사용 중. 단 신규 프로젝트의 채택은 감소.

// Vitest 3 단위 + Playwright 컴포넌트 테스트
import { describe, it, expect } from "vitest"
import { sum } from "./math"

describe("sum", () => {
  it("adds two numbers", () => {
    expect(sum(1, 2)).toBe(3)
  })

  it("handles negatives", () => {
    expect(sum(-1, -2)).toBe(-3)
  })
})

// Playwright (e2e/login.spec.ts)
// import { test, expect } from "@playwright/test"
// test("login", async ({ page }) => {
//   await page.goto("/login")
//   await page.getByLabel("email").fill("a@b.com")
//   await page.click("text=Sign in")
//   await expect(page.locator("h1")).toHaveText("Welcome")
// })

Vitest의 가장 큰 강점은 Vite와 같은 변환 파이프라인을 공유한다는 점. Next.js·Remix·SvelteKit·Astro와의 단위 테스트가 매끄럽다.

18. 빌드 도구 — tsup · tsc · esbuild · swc · oxc · Bun bundle

라이브러리·앱 빌드 도구 또한 다층 구조다.

2026년 5월 기준 백엔드 빌드 워크플로우의 사실상 표준은 "tsc로 타입 체크, tsup/esbuild로 출력" 조합. oxc는 oxlint(빠른 ESLint 대체)와 함께 빠르게 성장 중이고, 일부 팀은 ESLint를 oxlint로 교체하면서 lint 시간을 1/30로 단축했다.

# 라이브러리: tsup
pnpm add -D tsup
pnpm tsup src/index.ts --format esm,cjs --dts

# 앱: esbuild 직접
pnpm add -D esbuild
node --experimental-strip-types build.ts

# oxc 기반 lint
pnpm add -D oxlint
pnpm oxlint .

19. 모노레포 — Turborepo · Nx · Bun workspaces · pnpm workspaces

여러 TS 패키지를 한 저장소에서 관리하는 모노레포 도구 비교.

• Turborepo 2.x: Vercel 유지보수. 작업 캐싱·병렬 실행에 강점.
• Nx 20: 풍부한 플러그인·코드 생성기. 엔터프라이즈에서 광범위.
• pnpm workspaces 10: 패키지 매니저 자체의 워크스페이스.
• Bun workspaces: 빠른 install, 단순.

대부분 팀은 "패키지 매니저는 pnpm/Bun, 태스크 러너는 Turborepo/Nx" 조합으로 간다.

20. AI/ML SDK — Vercel AI SDK · transformers.js · vec-tor

TS 백엔드에 LLM·임베딩을 통합하는 표준이 만들어졌다.

• Vercel AI SDK 4: OpenAI/Anthropic/Google/Mistral/Bedrock 등 추상화. Streaming, tool use, RAG 1급 지원.
• transformers.js: Xenova가 만든 Hugging Face 모델 브라우저·Node 실행 라이브러리. ONNX Runtime 기반.
• vec-tor / 자체 벡터 라이브러리: Drizzle/Prisma + pgvector 조합으로 임베딩 저장.

// Vercel AI SDK로 스트리밍 LLM 응답 + 도구 호출
import { generateText, tool } from "ai"
import { anthropic } from "@ai-sdk/anthropic"
import { z } from "zod"

const result = await generateText({
  model: anthropic("claude-3-5-sonnet"),
  messages: [{ role: "user", content: "What is the weather in Seoul?" }],
  tools: {
    getWeather: tool({
      description: "Get weather for a city",
      parameters: z.object({ city: z.string() }),
      execute: async ({ city }) => ({ city, tempC: 22 }),
    }),
  },
  maxSteps: 5,
})

console.log(result.text)

LLM 통합이 표준화되면서, 백엔드 TS 개발자는 더 이상 Python으로 점프하지 않아도 LangChain 수준의 추상화를 누릴 수 있게 됐다.

21. 한국 채택 — Toss · 네이버 · 쿠팡 · 카카오

Toss (토스): 프론트엔드는 전사 TypeScript 100%. 백엔드도 점진적으로 Spring Boot 일부를 NestJS/Hono로 마이그레이션. 2024년부터 Toss Tech 블로그에 NestJS 운영 경험, 모노레포 구조, ts-pattern 활용 사례가 다수 공개됐다. 토스증권의 일부 사이드 BFF는 Bun으로 운영.

네이버: Whale 브라우저, 라인웍스, 네이버페이의 일부 BFF·게이트웨이 레이어가 TypeScript 기반. 사내 모노레포 도구 자체 개발. 일부 팀은 Hono+Cloudflare로 엣지 API 운영.

쿠팡: 프론트엔드 풀 TypeScript. 백엔드 신규 마이크로서비스 중 일부를 NestJS로. 쿠팡플레이의 BFF가 대표 사례.

카카오: 카카오엔터프라이즈, 카카오페이 일부 팀에서 NestJS 채택. 카카오스타일은 풀스택 TS.

한국 시장의 특징은 "SI/은행권은 여전히 Java/Spring, 핀테크·커머스·콘텐츠는 점진적 TS 전환" 패턴이다.

22. 일본 채택 — Mercari · freee · LayerX · CyberAgent

Mercari (메르카리): 마이크로서비스 다수가 Go였지만, 신규 BFF·미디어 변환 서비스에 TypeScript 마이크로서비스 도입. 일부 서비스에 Bun 채택. 자체 GraphQL Gateway는 TS.

freee (프리): 회계 SaaS. 프론트엔드 TS + Rails 백엔드 일부 TS 전환. NestJS와 tRPC 사용.

LayerX: 인보이스 SaaS Bakuraku. TypeScript 백엔드 비율이 매우 높음. Effect와 Drizzle 채택 사례 공개.

CyberAgent: AbemaTV, Tapple 등 다양한 자회사. NestJS·Hono 사용. 자체 모노레포 도구 운영.

일본 시장은 "Go·Rails 등 다양한 스택을 유지하면서 TS 영역을 BFF·실시간·엣지로 확장" 패턴이 강하다.

23. 보안 — 의존성 감사, lockfile, 권한 모델

TS 백엔드의 공급망 보안은 2024년 xz utils 사건 이후 다시 주목받았다.

• npm audit / pnpm audit: 알려진 CVE 검사.
• pnpm install의 lifecycle script 차단(10.x): 악성 postinstall 차단.
• Sigstore / Provenance: npm 패키지 빌드 출처 검증.
• Node 22의 Permission Model: --allow-fs-read로 파일시스템 격리.
• Deno 기본 권한 거부.
• Snyk, Socket, GitGuardian: 외부 보안 스캐너.

2026년에는 npm·jsr 양쪽 모두 attestation(서명된 빌드 출처)이 기본이 되었고, 대형 회사일수록 자체 npm registry mirror(Verdaccio, Sonatype Nexus, Artifactory)를 두고 외부 의존성을 캐싱한다.

24. 관측 — OpenTelemetry · pino · Sentry

TS 백엔드 관측 표준은 다음과 같이 정리됐다.

• OpenTelemetry JS SDK: 추적·메트릭·로그 표준. Node·Bun 모두 지원.
• pino: Fastify와 함께 가장 빠른 JSON 로거.
• Sentry: 에러 추적·성능 모니터링·세션 리플레이.
• Datadog · New Relic · Grafana Cloud: APM 상용.

// OpenTelemetry + Pino
import { NodeSDK } from "@opentelemetry/sdk-node"
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http"
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node"
import pino from "pino"

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: "http://otel-collector:4318/v1/traces" }),
  instrumentations: [getNodeAutoInstrumentations()],
})
sdk.start()

export const log = pino({ level: process.env.LOG_LEVEL || "info" })

Hono와 Elysia는 OpenTelemetry 미들웨어 패키지를 제공하고, NestJS는 공식 OpenTelemetry 모듈이 있다.

25. 비교 표 — 실제 선택 기준

마지막으로 큰 그림을 비교 표로 정리한다.

웹 프레임워크

ORM

검증

26. 마이그레이션 로드맵 — 레거시 Node에서 2026 스택으로

기존 Express + TypeORM 기반 서비스를 2026 스택으로 옮기려면 다음 순서가 합리적이다.

1. 타입스크립트 5.6+로 업그레이드하고 strict: true, noUncheckedIndexedAccess: true를 켠다.
2. 패키지 매니저를 pnpm 10으로 전환, lockfile을 갱신, catalog로 의존성 버전 통일.
3. 테스트를 Vitest 3로 전환 (Jest 호환 API).
4. Zod 4로 입력 검증 표준화. 핸들러 입력·출력에 Zod 스키마를 강제.
5. 새 모듈은 Hono 또는 Fastify 5로. Express 라우터를 점진적으로 옮긴다.
6. ORM을 Drizzle 또는 Prisma 6로 전환. 가장 큰 작업.
7. 관측을 OpenTelemetry로 통합, Sentry로 에러 추적.
8. CI에 oxlint + tsc + vitest를 병렬 실행, 빌드 시간을 단축.
9. 장기 작업은 Inngest 또는 Temporal로 분리.
10. Effect 도입은 별도 의사결정. 모든 팀에 맞지는 않으므로 신중하게.

이 로드맵의 핵심은 "한 번에 모든 것을 바꾸지 말 것"이다. 한 가지씩 점진적으로, 측정 가능한 지표(빌드 시간, p99 레이턴시, 에러율)로 효과를 검증한다.

27. 마무리 — 2026년의 선택

2026년의 TypeScript 백엔드는 더 이상 "Node + Express + Jest" 한 줄이 아니다. 런타임을 고를 수 있고, 프레임워크를 고를 수 있고, ORM과 검증과 워크플로우와 빌드를 각각 고를 수 있다. 선택지가 많다는 건 좋은 일이지만, 동시에 "어떤 조합이 우리 팀의 운영 환경과 잘 맞는가"라는 질문에 답해야 한다는 뜻이다.

이 글의 결론을 한 줄로 요약하면: 새 프로젝트라면 "Bun 또는 Node 22 + Hono + Drizzle + Zod 4 + Vitest 3 + pnpm 10"이 가장 적은 마찰로 갈 수 있는 기본값이다. 엔터프라이즈 규모면 NestJS 11을, 함수형 효과를 원하면 Effect를, 엣지에 갈 거면 Hono+Cloudflare를, 풀스택 단일 모노레포면 tRPC 11을 더한다.

선택의 자유는 책임을 동반한다. 어떤 도구를 고르든, 1년 뒤 우리 팀이 그 도구를 즐겁게 운영할 수 있는지를 먼저 물어라.

References

• TypeScript: typescriptlang.org
• Node.js: nodejs.org
• Bun: bun.sh
• Deno: docs.deno.com
• Hono: hono.dev
• Elysia: elysiajs.com
• NestJS: nestjs.com
• Effect: effect.website
• tRPC: trpc.io
• Drizzle ORM: orm.drizzle.team
• Prisma: prisma.io
• Zod: zod.dev
• Valibot: valibot.dev
• ArkType: arktype.io
• Vitest: vitest.dev
• pnpm: pnpm.io
• Fastify: fastify.dev
• Express: expressjs.com
• h3/Nitro: unjs.io
• Temporal TS SDK: docs.temporal.io
• Inngest: inngest.com
• Vercel AI SDK: sdk.vercel.ai
• Toss Tech: toss.tech
• Mercari Engineering: engineering.mercari.com