Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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"

- 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

const app = new Hono();

app.post(

"/users",

zValidator("json", z.object({ email: z.string().email() })),

);

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개)

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년 데이터베이스.

- 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.