2026 백엔드 개발 완전 가이드

Node.js·Spring Boot·FastAPI 프레임워크 선택과 실무

이 장을 읽기 전에: HTTP의 기본(요청/응답, URL의 구조)과 제2장에서 소개한 언어 개요를 파악하고 있으면 이해가 쉬워진다.

프론트엔드가 "홀과 서빙"이라면, 백엔드는 "주방"이다. 주문(요청)을 받아서, 재료(데이터)를 조리(처리)하고, 요리(응답)를 반환한다. 손님에게는 보이지 않지만, 식당의 품질을 좌우하는 가장 중요한 부분이다.

1. 백엔드의 역할과 책무

이 섹션이 답하는 질문: 백엔드란 구체적으로 무엇을 하는 부분인가?

왜 필요한가

"웹사이트 정도라면 프론트엔드만으로 만들 수 없는가?"라고 생각할 수 있다. 정적 블로그라면 확실히 그렇다. 그러나 사용자 등록, 결제 처리, 데이터의 영속화, 다른 서비스와의 연계가 필요해지는 순간, 백엔드가 필요해진다.

브라우저 위의 코드는 사용자가 자유롭게 읽고 쓸 수 있기 때문에, 비밀 정보(API 키, 데이터베이스 연결 정보)를 프론트엔드에 놓는 것은 불가능하다. 백엔드는 이러한 "신뢰할 수 있는 환경" 에서의 처리를 담당한다.

� 국내 서비스 특이점: "외부 연계" 항목에서 국내 서비스는 토스페이먼츠·카카오페이·네이버페이 등 국내 결제 수단, 카카오 알림톡·네이버 클라우드 SMS 등 국내 알림 채널을 연동하는 경우가 많다. 글로벌 서비스(Stripe, Twilio)와 API 설계 방식이 다를 수 있으므로 별도 확인이 필요하다.

정리

백엔드는 "데이터를 안전하게 관리하고 비즈니스 로직을 실행하는 신뢰할 수 있는 환경"이다. 프론트엔드가 "외관"을 담당하는 데 대해, 백엔드는 "내용"을 담당한다.

2. 프레임워크 선정

이 섹션이 답하는 질문: 백엔드 프레임워크는 무엇을 기준으로 선택하는가?

왜 필요한가

HTTP 요청의 수신, 라우팅, 요청 검증, 응답 생성…… 이것들을 매번 제로부터 작성하는 것은 비효율적이다. 백엔드 프레임워크는 이러한 공통 처리를 추상화하여, 개발자가 비즈니스 로직에 집중할 수 있도록 한다.

백엔드에서는, 먼저 언어와 실행 환경, 다음으로 프레임워크를 선택한다. 수치 벤치마크만으로 결정하는 것이 아니라, 운용·채용·주변 도구까지 포함하여 생각한다.

JavaScript / TypeScript 계열 실행 환경

JavaScript / TypeScript 계열 프레임워크

Python 계열

Go 계열

Java/Kotlin 계열 - 국내 엔터프라이즈 표준

기타

� 국내 채용 시장 현실: 국내 백엔드 공고의 상당수는 여전히 Java + Spring Boot 또는 Kotlin + Spring Boot를 요구한다. 카카오·네이버·토스·라인 등 대형 IT 기업의 백엔드는 Kotlin(Spring) 전환이 진행 중이며, 스타트업은 TypeScript(NestJS/Hono) 또는 Python(FastAPI) 채택이 늘고 있다.

선정 판단 기준

실무에서의 주의점

⚠️ 런타임의 속도 비교만으로 선택하지 않을 것. 실제 병목은 데이터베이스, 외부 API, 큐, 캐시, 배포 구성에 있는 경우가 많다.

⚠️ 프레임워크보다 먼저, 어디서 동작시킬지를 결정하는 편이 중요한 경우가 있다. 예를 들어, Cloudflare Workers 같은 엣지 전제라면 Hono가 자연스럽지만, 장시간 작업이나 무거운 SDK를 많이 사용한다면 통상의 서버 환경이 더 다루기 쉽다. NCP(네이버 클라우드)·카카오 클라우드 환경은 AWS/GCP와 배포 방식이 일부 다를 수 있으므로 공식 문서를 먼저 확인한다.

정리

TypeScript라면 Hono / Fastify / NestJS, Python이라면 FastAPI / Django, Go라면 표준 라이브러리부터 필요에 따라 보완, 국내 엔터프라이즈·금융·공공이라면 Spring Boot(Kotlin/Java)라는 정리가 알기 쉽다. 결국은 성능의 수치보다 팀이 계속 운용할 수 있는가로 선택해야 한다.

3. API 설계 패러다임

이 섹션이 답하는 질문: REST, GraphQL, gRPC… API 설계 방법은 어떻게 선택하는가?

왜 필요한가

API(Application Programming Interface)는 프론트엔드와 백엔드 사이의 "대화의 규칙"이다. 배달 앱에 비유하자면, "메뉴 번호로 주문하는가"인지 "원하는 재료를 직접 지정하는가"의 차이다. 규칙이 명확하지 않으면, 주문이 통하지 않는다(버그), 예상한 항목이 오지 않는다(사양 불일치)가 발생한다.

---

// REST — 표준적인 자원 조작 패턴

// GET /api/orders → 주문 목록

// POST /api/orders → 주문 생성

// GET /api/orders/:id → 특정 주문 조회

// PUT /api/orders/:id → 주문 수정

// DELETE /api/orders/:id → 주문 삭제

// tRPC — TypeScript 타입이 클라이언트까지 전파

import { initTRPC } from '@trpc/server';

import { z } from 'zod';

const t = initTRPC.create();

export const appRouter = t.router({

order: t.router({

getById: t.procedure

.input(z.object({ id: z.string() }))

.query(async ({ input }) => {

return await db.order.findUnique({ where: { id: input.id } });

// 반환 타입이 자동으로 클라이언트 측 타입으로 추론됨

}),

create: t.procedure

.input(z.object({

productId: z.string(),

quantity: z.number().min(1),

}))

.mutation(async ({ input, ctx }) => {

return await db.order.create({ data: { ...input, userId: ctx.userId } });

}),

}),

});

---

선정 판단 기준

⚠️ 막히면 REST부터 시작한다. 세계에서 가장 널리 사용되고 있으며, 거의 모든 HTTP 클라이언트가 대응하고 있다. TypeScript 풀스택이라면 tRPC가 매력적이지만, TypeScript 경계 안에서 닫히는 설계에 어울린다.

실무에서의 주의점

⚠️ GraphQL은 "클라이언트가 자유롭게 쿼리를 조합할 수 있다"는 반면, 부주의한 쿼리로 서버에 과도한 부하를 주는 리스크가 있다. 도입하는 경우는 N+1 대책, 깊이 제한, 쿼리 비용 제어를 생각할 필요가 있다.

⚠️ gRPC는 내부 서비스 간 통신에서는 강하지만, 브라우저에서 직접 사용하는 전제에서는 설계가 약간 무겁다. 공개 API인가 내부 API인가에 따라 어울리는 방식은 달라진다.

� 국내 오픈 API 현황: 공공 데이터 포털(data.go.kr), 네이버 개발자 센터, 카카오 개발자 센터 등 국내 주요 API는 대부분 REST 기반이다. 공공 API를 연동하는 서비스라면 REST 설계 숙련도가 특히 중요하다.

정리

대부분의 프로젝트는 REST로 충분하다. TypeScript 통일이라면 tRPC가 매력적이다. GraphQL은 "복수의 클라이언트가 다른 데이터 구조를 필요로 하는" 경우에 검토한다.

4. LLM API 통합 패턴 (AI 시대의 새로운 책무)

이 섹션이 답하는 질문: 백엔드가 LLM을 오케스트레이터로 사용하는 경우, 무엇에 주의해야 하는가?

왜 필요한가

LLM을 사용하는 기능에서는 프론트엔드에서 직접 모델 API를 호출하는 것보다, 백엔드에서 호출을 중계·제어하는 편이 안전한 경우가 많다. 이유는 API 키 보호, 입력 검증, 비용 제어, 감사 로그, 툴 실행 제어가 필요하기 때문이다.

백엔드는 단순한 프록시가 아닌 신뢰 경계로서 동작할 필요가 있다.

전형적인 책무 분담

구현 이미지

1. 스트리밍 — Hono + Vercel AI SDK

---

import { Hono } from 'hono';

import { streamText } from 'ai';

import { anthropic } from '@ai-sdk/anthropic';

const app = new Hono();

app.post('/chat', async (c) => {

const { text } = await c.req.json();

// 입력 길이 제한 — 비용 제어

if (text.length > 2000) {

return c.json({ error: '입력이 너무 깁니다' }, 400);

}

return c.streamText(async (stream) => {

const result = await streamText({

model: anthropic('claude-sonnet-4-20250514'),

messages: [{ role: 'user', content: text }],

maxTokens: 1000,

});

for await (const chunk of result.textStream) {

await stream.write(chunk);

}

});

});

---

2. 툴 호출 — 권한 제어 포함

---

const completion = await llm.generate({

messages,

tools: [fetchUserDataTool, searchProductsTool],

});