Modern Backend Framework 2025 — NestJS·Fastify·Hono·Elysia·Spring Boot·FastAPI·Go·Rust·tRPC·GraphQL·gRPC 완전 비교 (Season 7 Ep 2)

프롤로그 — "어떤 프레임워크를 써야 하나요?"

10년 차 백엔드 엔지니어가 신입에게 자주 듣는 질문. 답은 "때에 따라"다. 그런데 이 "때"가 무엇인지 감이 오지 않으니 답답하다.

2025년 백엔드 프레임워크의 지형은 언어별로 몇 개의 대표 선수가 자리 잡은 안정기에 접어들었다. 10년 전 "Spring이냐 Node냐"는 식의 거대한 경합은 끝났고, 이제는 **"우리 팀의 맥락에서 무엇이 맞는가"**를 고르는 게임이다.

이번 글에서는 13개 챕터로 2025년 백엔드 프레임워크의 지도를 그리고, API 패러다임(REST·tRPC·GraphQL·gRPC), 그리고 선택 기준을 정리한다.

1장 · 프레임워크 선택의 7가지 축

프레임워크를 고를 때 고려할 축:

언어 — 팀이 숙련된 언어, 채용 가능성
타입 시스템 — 정적·동적, 타입 추론 강도
성능 — RPS·latency·메모리
생태계 — ORM·인증·모니터링 라이브러리
표현력 — 같은 기능을 몇 줄로
학습 곡선 — 온보딩 시간
커뮤니티·장기 지원 — 5년 후에도 살아있을 가능성

**"빠르니까 Rust"**는 젊은 엔지니어의 로맨스다. Rust가 빠르다고 해서 팀 전체가 Rust로 전환할 때 얻는 이득이, 학습·생산성 감소·인력 확보 비용을 상쇄할지 계산이 필요하다.

이 글의 모든 프레임워크는 "베스트"가 아니라 "쓸 만한 선수들"이다.

2장 · Node/Bun/Deno 진영 — NestJS·Fastify·Hono·Elysia

NestJS — "엔터프라이즈 TypeScript의 Spring"

Angular에서 영감. Controller·Service·Module·DI·Pipe·Guard
TypeScript first. 데코레이터 기반
Microservice 지원 (gRPC·NATS·Kafka·Redis Pub/Sub·RabbitMQ 내장 transporter)
대기업·엔터프라이즈 선호
학습 곡선 있음. 프로젝트 작으면 과함

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

  @Get(":id")
  findOne(@Param("id") id: string) {
    return this.users.findOne(id);
  }
}

Fastify — "빠른 Express의 후계자"

Express의 정신적 후계자. Schema 기반 직렬화로 10배 빠름
JSON Schema를 선언하면 validator + fast serializer + OpenAPI 자동
Plugin 아키텍처로 모듈화
Node.js에서 가장 성숙한 경량 프레임워크

Hono — 런타임 중립의 새 스타

Node·Bun·Deno·Workers·Vercel Edge·Fastly 모두 동일 코드
초경량(~20KB), 빠름, TypeScript first
OpenAPI 통합, zod validation

import { Hono } from "hono";
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";

const app = new Hono();
app.post(
  "/users",
  zValidator("json", z.object({ email: z.string().email() })),
  (c) => c.json({ ok: true })
);
export default app;

Elysia — Bun 전용 속도 괴물

Bun 최적화. Fastify보다 2~3배 빠름 (합성 벤치 기준)
Static code analysis로 엄청난 타입 추론
WebSocket·Stream 내장
Bun 종속이 유일한 약점

선택

대형·엔터프라이즈: NestJS
성능·경량 API: Fastify 또는 Hono
Edge·풀스택: Hono
Bun 극한 속도: Elysia

3장 · JVM 진영 — Spring Boot·Quarkus·Micronaut·Ktor

Spring Boot — 엔터프라이즈의 왕

2014년부터 JVM 표준
생태계 압도적 (Security·Data·Cloud·Batch·Integration)
2024년 Spring Boot 3.x + Java 21 Virtual Threads로 스케일링 혁신
단점: 시작 속도·메모리 (cold start 수 초)

@RestController
@RequestMapping("/users")
public class UserController {
    private final UserService service;

    public UserController(UserService service) {
        this.service = service;
    }

    @GetMapping("/{id}")
    public User findOne(@PathVariable String id) {
        return service.findOne(id);
    }
}

Quarkus — Serverless 시대의 JVM

Red Hat 주도. "Supersonic Subatomic Java"
GraalVM Native Image 컴파일로 시작 시간 100ms 이하
Kubernetes·Serverless에 최적
2025년 Spring의 강한 대안으로 부상

Micronaut

Compile-time DI (reflection 없음)
빠른 시작, 작은 메모리
Kotlin·Groovy·Java 지원

Ktor — Kotlin 네이티브

JetBrains 공식
Coroutine 기반 비동기
DSL 스타일, 간결함
네이버·토스·카카오의 Kotlin 서비스에서 사용

선택

전통 엔터프라이즈: Spring Boot
Serverless·Kubernetes: Quarkus
Kotlin 중심: Ktor
시작 속도: Micronaut 또는 Quarkus

4장 · Python 진영 — FastAPI·Django·Litestar·Flask

FastAPI — 현대 Python의 de facto

2018년 Sebastián Ramírez 작
Pydantic + async → 자동 validation + OpenAPI
Starlette 기반, uvicorn/hypercorn 런타임
2024~2025년 주간 다운로드 압도적 1위

from fastapi import FastAPI
from pydantic import BaseModel, EmailStr

app = FastAPI()

class UserIn(BaseModel):
    email: EmailStr
    age: int

@app.post("/users")
async def create(u: UserIn):
    return {"ok": True, "email": u.email}

Django — 풀스택 배터리 포함

20년 역사, 여전히 관리자 패널·ORM·Auth·Admin이 매력
Django Ninja로 FastAPI 스타일 개발 가능
주요 장점: 관리자·Admin·보안 기본값이 훌륭

Litestar (구 Starlite)

FastAPI의 대안, 더 빠르고 더 유연하다고 주장
DI·Controllers·Routers·OpenAPI
작지만 신성장 커뮤니티

Flask

여전히 널리 쓰이지만 신규 프로젝트에서 FastAPI로 대체 경향
마이크로서비스·스크립트에 적합

선택

API 중심 신규: FastAPI 또는 Litestar
풀스택·관리자 앱: Django
단순·레거시 마이그레이션: Flask
과학 계산·AI 서비스: FastAPI + Ray/Celery

5장 · Go 진영 — Gin·Echo·Chi·Fiber·Huma

왜 Go인가

컴파일 속도·단일 바이너리·goroutine·GC
Kubernetes·Docker·Prometheus·Terraform의 언어
한국 대기업 백엔드·인프라 팀에서 증가

Gin — 가장 인기

Martini 스타일 미들웨어·라우터
주간 다운로드 Go 웹 1위
단순·빠름

r := gin.Default()
r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id")
    c.JSON(200, gin.H{"id": id})
})
r.Run(":8080")

Echo

Gin과 유사, 더 풍부한 middleware
WebSocket·Auto TLS 내장

Chi

Go idiomatic 철학, net/http 호환
가장 얇은 라우터
대형 서비스에서 선호

Fiber

Express 스타일 API
fasthttp 기반 (표준 net/http 안 씀 → 호환성 주의)
극단적으로 빠름

Huma

OpenAPI first — 타입만 정의하면 문서·validator 자동
2024~2025년 부상

선택

빠른 시작: Gin, Fiber
표준 중심·대형: Chi
OpenAPI·타입 안전: Huma

6장 · Rust 진영 — Axum·Actix·Rocket·Poem

왜 Rust인가

컴파일 타임 메모리 안전
GC 없음, 예측 가능한 latency
극도로 빠름 (Go보다 2~3배 cases)
학습 곡선 높음

Axum — 가장 뜨거운

Tokio 팀이 만듦
Type-safe routing, tower middleware
Tokio·Hyper 기반
2024년부터 Rust 웹의 사실상 1위

use axum::{routing::get, Router};

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(|| async { "Hello" }));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Actix Web

오래된 1강. 성능 벤치마크 최상위
Actor 모델 기반
API 복잡도 높음

Rocket

DSL 우아함
과거 nightly 필요 → 2023년 stable 지원
학습에 친화적

Poem

OpenAPI·GraphQL·gRPC 내장
Rust에서 "all-in-one" 선택

선택

처음 Rust 웹: Axum 또는 Rocket
극한 성능: Actix
일체형 도구: Poem

7장 · tRPC — TypeScript End-to-end 타입

2020년 Alex Johansson 작. "TypeScript Type을 API 계약으로".

동작 원리

서버에서 함수를 procedure로 등록
클라이언트는 타입이 자동 추론됨
스키마·OpenAPI 작성 없이 풀스택 타입 공유

// server.ts
export const appRouter = router({
  user: router({
    byId: publicProcedure
      .input(z.object({ id: z.string() }))
      .query(({ input }) => db.user.findUnique({ where: input })),
  }),
});
export type AppRouter = typeof appRouter;

// client.ts
const user = await trpc.user.byId.query({ id: "abc" });
// user: User | null — 완전 타입 추론

장점

설정·보일러플레이트 최소
컴파일 시 계약 불일치 감지
Next.js·Remix·Expo 풀스택에 최적

한계

TypeScript 클라이언트 전용 — 다른 언어 클라이언트는 OpenAPI 별도
마이크로서비스 간 통신에는 부적합 (서비스마다 TypeScript가 아닐 수 있음)

2025 권장

단일 저장소 Next/Remix 풀스택 → tRPC 강력 추천
다언어·공개 API → OpenAPI 기반 REST 또는 gRPC

8장 · REST vs GraphQL vs gRPC

REST

HTTP 메서드 + 리소스
캐싱·프록시·CDN과 궁합 최고
OpenAPI 3.1로 스키마·클라이언트·문서 자동 생성
여전히 2025년 대다수 공개 API의 표준

GraphQL

2015년 Facebook 공개
필드 단위 요청 — 오버페칭 해소
한 엔드포인트·복잡한 스키마
단점: 캐싱 어려움, N+1, 학습 곡선
2024~2025년 많은 대기업이 "GraphQL Federation → REST로 회귀" 사례. 단순 CRUD엔 과함.

gRPC

Google, Protobuf 기반 바이너리
마이크로서비스 간 통신 최적
서버 스트리밍·양방향 스트림 지원
HTTP/2 필수 → 브라우저 직접 호출 어려움 (gRPC-Web 필요)
2025년 내부 서비스 통신의 de facto

Connect-RPC

gRPC의 단점(브라우저 호환) 해결
HTTP/1.1·HTTP/2 동시 지원
TypeScript·Go·Swift·Kotlin 클라이언트
"gRPC + REST의 좋은 면"

선택

공개 API: REST + OpenAPI
마이크로서비스 내부: gRPC 또는 Connect
복잡한 다중 엔티티 뷰: GraphQL (선별적)
타입 안전 풀스택: tRPC

9장 · ORM·Query Builder 선택

프레임워크 위에 올리는 DB 레이어.

TypeScript/JS

Prisma — 타입 추론 강력, Migration·Studio UI
Drizzle ORM — Edge 호환, SQL에 가까움, 빠름
Kysely — Query Builder, 최대 타입 안전
TypeORM — 오래된 선택, 점유 하락

Python

SQLAlchemy 2.0 — 2.0에서 async 네이티브
Django ORM — Django 생태계
Tortoise ORM — FastAPI·async 중심

Java/Kotlin

JPA/Hibernate — Spring 기본
jOOQ — Query Builder, 타입 안전
Exposed — Kotlin DSL

Go

GORM — 가장 인기
Ent — Facebook, graph 모델
sqlc — SQL 파일 → Go 코드 생성

Rust

SQLx — compile-time checked SQL
SeaORM — Django 스타일 ORM
Diesel — 가장 오래된 Rust ORM

2025 조언

**"ORM vs Raw SQL"**은 스펙트럼이다
복잡한 분석 쿼리는 Raw SQL
단순 CRUD는 ORM/Query Builder
N+1 쿼리는 모든 ORM의 숙제

10장 · 인증·세션·RBAC

2025 인증 표준

OAuth 2.1 + OIDC 공개 API
Passkey·WebAuthn 1차 사용자 인증
JWT·PASETO 세션 토큰
Session Cookie도 여전히 유효

프레임워크별 패턴

NestJS: @nestjs/passport, @nestjs/jwt
Spring: Spring Security
FastAPI: fastapi-users, authlib
Rails: Devise
Go: 직접 구현 or golang-jwt/jwt
Rust: axum-login, tower-sessions

Auth as a Service

Auth0·Clerk·Stytch·WorkOS·Kinde·SuperTokens·Keycloak
2025년 대기업·스타트업 모두 SaaS 선호 증가

RBAC vs ABAC

RBAC: 역할 기반 (admin·editor·viewer)
ABAC: 속성 기반 (사용자·리소스·환경 조합)
조직 권한 복잡 → OpenFGA·Oso·Cerbos 권장

11장 · 모노리스 vs 마이크로서비스 vs BFF

2020년대 초의 반성

2010년대 "모든 것은 마이크로서비스"의 유행 이후, 많은 팀이 복잡도 폭발을 경험. 2024~2025년은 **"먼저 모노리스, 필요할 때 쪼개라"**가 중론.

Modular Monolith

단일 배포 가능 단위
내부는 모듈·패키지로 엄격 분리
성장하면 일부 모듈만 분리

Microservice

독립 배포·스케일
팀 경계·도메인 경계와 일치
Saga·분산 트랜잭션·관측성 비용 큼

BFF (Backend for Frontend)

프론트엔드마다 전용 백엔드
모바일·웹·IoT·AI 에이전트 각각의 BFF
GraphQL 또는 tRPC가 BFF 레이어에 적합
Apollo Federation·Envoy Gateway·BFF Edge

선택

1-10명 팀: Modular Monolith
10-50명: 도메인별 서비스 + BFF
50+: 다수 Microservice + Platform 팀

12장 · 프레임워크가 아닌 것 — "Boring Technology"

Dan McKinley의 Boring Technology

조직이 감당할 수 있는 혁신의 토큰은 유한
이미 검증된 기술에 대부분을 쓰고, 새 기술은 한 두 개만
"최신 기술 스택으로 쌓아 올린 서비스"는 일반적으로 더 빨리 무너진다

2025년의 Boring Stack 예시

Next.js + tRPC + Prisma + Postgres + Vercel (풀스택 TS)
Spring Boot + JPA + MySQL + Kubernetes (JVM 엔터프라이즈)
FastAPI + SQLAlchemy + Postgres + AWS ECS (Python)
Ruby on Rails + Postgres + Heroku/Render (빠른 시작)

"지루한" 기술의 장점

문서·커뮤니티·Stack Overflow가 풍부
채용 가능성 높음
5-10년 뒤에도 유지보수 가능
AI 도구와의 궁합 좋음 (학습 데이터 많음)

혁신 토큰을 어디에 쓸까

핵심 경쟁력에 쓰자 (AI 모델·알고리즘·데이터 파이프라인)
웹 프레임워크·DB 선택 같은 "기본"에는 검증된 것 사용

13장 · 체크리스트·안티패턴·다음 글 예고

프레임워크 선택 체크리스트 (14개)

팀 언어 역량이 첫 번째 기준
정적 타입 가용성 (TypeScript·Java·Kotlin·Rust)
채용 시장에서 구할 수 있는 엔지니어
배포 환경과 궁합 (Serverless·Kubernetes·VM·Edge)
성능 요구가 실제로 있는가 (대부분은 DB가 병목)
생태계 의존성 — ORM·Auth·Monitoring·Queue
API 표준 선택 (REST·tRPC·GraphQL·gRPC)
관측성 — OpenTelemetry 통합
DevOps — Docker·CI·배포 난이도
문서·학습 자료 한국어 여부
장기 지원 — 최소 3-5년 유지될 것인가
보안 업데이트 주기
팀 학습 곡선과 온보딩 비용
Boring Technology 원칙 — 혁신 토큰 아껴라

프레임워크 안티패턴 TOP 10

"최신이라서" 선택 — 벤치마크만 보고 결정
마이크로서비스 먼저 — 분산 복잡도를 처음부터
GraphQL을 단순 CRUD에 — 오버엔지니어링
Framework A + Framework B 섞기 — 경계 모호
ORM·Raw SQL 혼용 — 어느 쪽도 제대로 안 됨
인증 직접 구현 — Auth SaaS·표준 라이브러리
모니터링·로깅 나중에 — 시작부터 탑재
벤치마크 숫자 신뢰 — 실전 병목은 DB·네트워크
타입 없는 API 경계 — OpenAPI·tRPC·Protobuf
언어·프레임워크를 개인 취향으로 선택 — 팀 합의 없음

다음 글 예고 — Season 7 Ep 3: "데이터베이스 2025"

프레임워크 선택의 다음은 데이터 저장소. Ep 3은 2025년 데이터베이스.

Postgres의 지배 — 왜 모두 Postgres로 회귀하나
Distributed SQL: CockroachDB·Spanner·TiDB·YugabyteDB·Neon
NoSQL의 성숙: MongoDB·DynamoDB·Cassandra·Redis
Vector DB: pgvector·Pinecone·Weaviate·Qdrant·Milvus
Time Series: TimescaleDB·InfluxDB·QuestDB
Graph: Neo4j·ArangoDB·Neptune·PostgreSQL Graph
Edge DB: D1·Turso·Supabase·Neon Branch
SQLite의 재발견 — libSQL·Turso·Cloudflare D1
Serverless Postgres: Neon·PlanetScale·Supabase·Xata
샤딩·레플리케이션·Read Replica
한국 서비스의 DB 선택 사례

"프레임워크는 6개월마다 바뀌어도, DB는 10년을 간다."

다음 글에서 만나자.

"좋은 프레임워크는 팀의 속도와 품질을 동시에 높인다. 나쁜 프레임워크는 둘 다 떨어뜨린다. 그 차이는 기술 스펙이 아니라 팀과의 맞물림에서 온다."

— Season 7 Ep 2.