LabHub

블로그

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

2026-04-15 · 18 분 읽기 · #backend#framework#nestjs#fastify#hono#elysia#spring-boot#fastapi#go#rust#trpc#graphql#grpc#season7

한국어English日本語

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

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

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

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

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

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

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

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

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

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

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

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

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

Fastify — "빠른 Express의 후계자"

Hono — 런타임 중립의 새 스타

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 전용 속도 괴물

선택

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

Spring Boot — 엔터프라이즈의 왕

@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

Micronaut

Ktor — Kotlin 네이티브

선택

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

FastAPI — 현대 Python의 de facto

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 — 풀스택 배터리 포함

Litestar (구 Starlite)

Flask

선택

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

왜 Go인가

Gin — 가장 인기

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

Chi

Fiber

Huma

선택

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

왜 Rust인가

Axum — 가장 뜨거운

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

Rocket

Poem

선택

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

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

동작 원리

// 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 — 완전 타입 추론

장점

한계

2025 권장

8장 · REST vs GraphQL vs gRPC

REST

GraphQL

gRPC

Connect-RPC

선택

9장 · ORM·Query Builder 선택

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

TypeScript/JS

Python

Java/Kotlin

Go

Rust

2025 조언

10장 · 인증·세션·RBAC

2025 인증 표준

프레임워크별 패턴

Auth as a Service

RBAC vs ABAC

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

2020년대 초의 반성

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

Modular Monolith

Microservice

BFF (Backend for Frontend)

선택

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

Dan McKinley의 Boring Technology

2025년의 Boring Stack 예시

"지루한" 기술의 장점

혁신 토큰을 어디에 쓸까

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

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

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

프레임워크 안티패턴 TOP 10

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

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

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

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

다음 글에서 만나자.

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

— Season 7 Ep 2.

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다