---
term: '백엔드 (서버 측)'
seoTitle: '백엔드란? 의미, 프론트엔드 vs. 백엔드, 아키텍처'
headline: '백엔드란? 애플리케이션의 서버 측 완벽 정리'
slug: backend-meaning
category: backend-compute
shortDefinition: '백엔드는 UI 뒤에서 앱의 요청을 처리하고 데이터를 저장하는 코드, 데이터베이스, 인프라로 이루어진 서버 측 시스템입니다.'
relatedTerms:
  - baas-vs-custom-backend
  - api
  - serverless-architecture
  - backend-sdk
  - decoupled-architecture
  - scaling-application-backends
contrastsWith:
  - decoupled-architecture
faq:
  - question: '백엔드는 무엇을 뜻합니까?'
    answer: '애플리케이션에서 사용자가 결코 보지 못하는 부분입니다. 인터페이스에서 요청을 받고, 비즈니스 규칙을 적용하고, 데이터를 읽고 쓰고, 응답을 돌려보내는 서버 측 코드, 데이터베이스, 인프라를 말합니다. 프론트엔드가 자동차의 계기판이라면 백엔드는 엔진과 연료 계통입니다. 운전석에서는 보이지 않지만, 움직이는 모든 것을 책임집니다.'
  - question: '프론트엔드란 무엇입니까?'
    answer: '애플리케이션에서 사용자가 보고 상호작용할 수 있는 부분입니다. 브라우저나 모바일 앱이 사용자의 기기에 그려 내는 화면, 버튼, 폼, 내비게이션이 여기에 속합니다. 프레젠테이션 계층입니다. 입력을 받고 결과를 보여 주지만, 그 결과 뒤의 결정과 데이터는 백엔드에 있으며, 프론트엔드는 API를 통해 백엔드에 접근합니다.'
  - question: '프론트엔드와 백엔드의 차이는 무엇입니까?'
    answer: '코드가 어디서 실행되고 누구와 대화하느냐의 차이입니다. 프론트엔드는 사용자의 기기(브라우저나 앱)에서 실행되며 화면을 렌더링하고, 입력을 받고, API를 호출합니다. 백엔드는 여러분(또는 플랫폼)이 통제하는 서버에서 실행되며 데이터, 규칙, 보안을 소유합니다. 둘은 API에서 만납니다. 프론트엔드가 묻고, 백엔드가 결정하고 답합니다.'
  - question: '백엔드는 서버와 같은 것입니까?'
    answer: '정확히는 아닙니다. 서버는 네트워크 요청에 응답하는 기계나 프로세스이고, 백엔드는 인터페이스 뒤의 시스템 전체, 즉 애플리케이션 코드, 데이터베이스, 인증, 백그라운드 작업, 그리고 이들이 실행되는 서버를 말합니다. 하나의 백엔드가 여러 서버에 걸칠 수 있으며, 서버리스 아키텍처에서 "서버"는 밀리초 단위로 임대될 뿐 직접 관리되는 일이 없습니다.'
  - question: '백엔드의 유형에는 무엇이 있습니까?'
    answer: '누가 서버를 운영하느냐로 나뉩니다. 여러분의 팀이 머신이나 컨테이너를 프로비저닝하고 운영하는 서버 기반 백엔드, 제공업체가 인프라를 운영하고 사용량만큼 과금하는 서버리스 백엔드(커스텀 코드를 위한 Function as a Service와 스택 전체를 위한 Backend as a Service), 그리고 어느 한 주체도 시스템을 운영하지 않고 피어들이 네트워크로 상태를 공유하는 탈중앙화 백엔드입니다. 오늘날 대부분의 제품은 앞의 두 가지를 조합합니다.'
  - question: '데이터베이스는 백엔드입니까?'
    answer: '아니요. 데이터베이스는 백엔드의 한 구성 요소이며, 대개 가장 중요한 구성 요소입니다. 데이터베이스는 데이터를 저장하고 꺼내 오고, 백엔드는 그것을 API, 검증, 권한, 로직으로 감싸 클라이언트가 직접 건드리지 못하게 합니다. 인증과 접근 규칙을 갖춘 생성된 API로 데이터베이스를 노출하는 플랫폼은 백엔드이지만, 데이터베이스만 덩그러니 있는 것은 백엔드가 아닙니다.'
  - question: 'Backend as a Service(BaaS)란 무엇입니까?'
    answer: '구축하는 대신 설정하는 관리형 백엔드입니다. 호스팅되는 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 사용자 인증, 파일 스토리지, 푸시 알림, 커스텀 로직을 위한 서버리스 함수를 제공합니다. 여러분은 프론트엔드와 제품에 중요한 규칙을 계속 작성하고, 나머지는 플랫폼이 운영합니다. 모바일 앱이나 웹 앱에 프로덕션 백엔드를 갖추는 가장 빠른 방법입니다.'
  - question: '백엔드 개발자는 무슨 일을 합니까?'
    answer: '데이터 모델을 설계하고, API를 구축하고 문서화하고, 비즈니스 로직과 백그라운드 작업을 구현하고, 인증과 권한 체계를 안전하게 구현하며, 트래픽이 늘어나도 시스템이 빠르고 가용 상태를 유지하게 합니다. 실제로는 업무의 상당 부분이 배포, 모니터링, 확장, 백업 같은 운영이며, 관리형 플랫폼이 흡수하는 것이 바로 이 부분입니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Introduction to the server side — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction'
  - name: 'Client-Server overview — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'The Twelve-Factor App'
    url: 'https://12factor.net/'
  - name: 'Frontend and backend — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Frontend_and_backend'
cta:
  title: '직접 만들지 않아도 되는 프로덕션 백엔드'
  text: 'Back4app은 첫날부터 여러분의 앱에 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 함수를 제공합니다. 서버 측 전체를 구축하는 대신 설정하면 됩니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-11-03'
translationKey: backend-meaning
---

**백엔드는 UI 뒤에서 앱의 요청을 처리하고 데이터를 저장하는 코드, 데이터베이스, 인프라로 이루어진 서버 측 시스템입니다.** 사용자가 있는 모든 소프트웨어는 두 부분으로 이루어집니다. 사용자가 보고 만지는 절반, 즉 화면, 버튼, 폼이 프론트엔드입니다.

사용자가 결코 보지 못하는 절반, 버튼이 무엇을 할 수 있는지 결정하고 앱을 닫은 뒤에도 무슨 일이 있었는지 기억하는 절반이 백엔드입니다. 오래된 정비사 비유는 지금도 유효합니다. 운전자는 계기판을 다루고, 정비사는 엔진을 다룹니다.

이 항목은 엔진에 관한 글입니다.

<YouTubeEmbed
  id="qBI82DOEyHM"
  title="What is a Backend?"
  description="백엔드가 무엇인지, 프론트엔드와 어떻게 다른지, 애플리케이션의 서버 측이 무슨 일을 하는지 설명하는 짧은 영상입니다."
  uploadDate="2022-01-19"
  duration="PT2M13S"
/>

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 정의 | 인터페이스 뒤의 모든 것: 서버 코드, 데이터베이스, 인증, 작업, 인프라 |
| 경계 | API. 프론트엔드가 묻고, 백엔드가 검증하고 결정하고 답함 |
| 계층 | API · 비즈니스 로직 · 데이터 · 인증 · 백그라운드 작업 · 인프라 |
| 호스팅 모델 | 서버 기반 · 서버리스(FaaS와 BaaS) · 탈중앙화 |
| 2026년의 기본값 | 범용적인 부분(데이터베이스, 인증, API)은 빌리고, 여러분만의 로직만 작성 |

## 요청 하나를 처음부터 끝까지

백엔드를 가장 명확하게 보는 방법은 요청 하나가 백엔드를 가로지르는 과정을 지켜보는 것입니다. 사용자가 "미완료 작업 보기"를 탭하면, API 반대편에서는 다음과 같은 일이 일어납니다:

```text
GET /classes/Todo?where={"done":false} HTTP/1.1    ← 프론트엔드가 요청함
Authorization: Bearer eyJhbGci…                     ← 요청하는 주체

  백엔드 ─┬─ API 계층         요청을 파싱하고 토큰을 확인함
          ├─ 인가             이 사용자가 이 행들을 읽어도 되는가?
          ├─ 비즈니스 로직    규칙을 적용함(호출자의 작업만)
          ├─ 데이터 계층      데이터베이스를 쿼리하고 결과를 가공함
          └─ 응답             200 OK + JSON, 100ms 이내

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }
```

같은 대화를 프론트엔드 쪽에서 보면, 플랫폼마다 한 줄로 바꿔 주는 SDK를 거칩니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}
```

## 프론트엔드 vs. 백엔드

사람들이 가장 많이 검색하는 구분을 표 하나로 정리합니다:

| | 프론트엔드 | 백엔드 |
| --- | --- | --- |
| 실행 위치 | 사용자의 기기: 브라우저, 모바일 앱, 데스크톱 | 여러분이나 제공업체가 통제하는 서버 |
| 소유하는 것 | 레이아웃, 상호작용, 로컬 상태, 접근성 | 데이터, 비즈니스 규칙, ID, 보안 |
| 실패 양상 | 한 사용자의 화면이 깨짐 | 모든 사용자에게 잘못된 데이터나 다운타임 |
| 대표 언어 | JavaScript/TypeScript, Swift, Kotlin, Dart | JavaScript/TypeScript, Python, Java, Go, C#, Ruby, PHP, Rust |
| "완료"의 의미 | 보기에도 쓰기에도 제대로임 | 정확하고, 안전하고, 부하 속에서도 여전히 빠름 |
| 코드를 볼 수 있는 사람 | 누구나. 기기로 배포되므로 | 여러분의 팀만. 서버를 절대 떠나지 않으므로 |

보안에서 중요한 것은 마지막 행입니다. 프론트엔드에 있는 것은 무엇이든 사용자가 읽고 수정할 수 있습니다. 그래서 검증, 권한, 시크릿은 백엔드에 있어야 하며, 모든 [API](/glossary/ko/api/) 호출은 서버가 확인하기 전까지 신뢰할 수 없는 것으로 취급됩니다.

## 클라이언트 측과 서버 측

이 두 용어는 백엔드의 두 종류가 아니라, 모든 요청의 양쪽 끝입니다. *클라이언트 측*은 사용자의 기기에서 실행되는 모든 코드입니다. 인터페이스를 렌더링하고, 임시 상태를 보관하고, 요청을 보냅니다.

*서버 측*은 사용자가 닿을 수 없는 머신에서 실행되는 모든 코드입니다. 그 요청을 받고, 실제 로직을 실행하고, 데이터베이스를 읽고 쓰고, 응답합니다. "백엔드"와 "서버 측"은 이 두 번째 절반을 가리키는 말로 혼용되며, 이 항목도 마찬가지입니다.

```mermaid
flowchart LR
  accTitle: 프론트엔드, 백엔드, 그리고 그 사이의 API
  accDescr: 사용자 기기의 프론트엔드가 API를 통해 백엔드로 요청을 보냅니다. 백엔드는 비즈니스 로직, 인증, 백그라운드 작업을 담고 있으며, 데이터베이스 및 외부 서비스와 통신한 뒤 응답을 반환합니다.
  F["프론트엔드<br/>(브라우저, 모바일 앱)"] -->|"API를 통한 요청"| B["백엔드<br/>로직 · 인증 · 작업"]
  B --> D[("데이터베이스")]
  B --> S["외부 서비스<br/>(결제, 이메일, AI)"]
  B -->|"응답"| F
```

## 백엔드의 구성 요소

고전적인 설명은 프론트엔드를 *프레젠테이션 계층*, 백엔드를 *데이터 접근 계층*이라 부르고, 백엔드를 함께 동작하는 세 가지, 즉 하드웨어 자원, 그 위에서 실행되는 소프트웨어, 그리고 이들과 사용자 사이의 네트워크 인프라로 설명합니다.

지금도 맞는 말이지만, 백엔드를 책임의 스택으로 읽는 편이 더 유용합니다. 그 대부분은 규모와 관계없이 모든 제품에 존재합니다:

- **API 계층** – 공개 계약입니다. 프론트엔드와 다른 시스템이 호출하는 [REST](/glossary/ko/rest-api/) 또는 GraphQL 엔드포인트입니다.
- **비즈니스 로직** – 제품을 그 제품답게 만드는 규칙입니다. 유효한 주문이란 무엇인지, 누가 무엇을 승인할 수 있는지, 점수를 어떻게 계산하는지 같은 것들입니다.
- **데이터 계층** – [데이터베이스](/glossary/ko/nosql-vs-sql/)와, 이를 모델링하고 쿼리하고 마이그레이션하는 코드입니다.
- **인증과 인가** – [호출자가 누구이며 무엇을 할 수 있는지](/glossary/ko/authentication-vs-authorization/)를 모든 요청에서 강제합니다.
- **백그라운드 작업** – 이메일, 리포트, 동기화, 정리처럼 요청을 막아서는 안 되는 모든 일을 위한 [작업과 스케줄](/glossary/ko/background-jobs-task-schedulers/)입니다.
- **인프라** – 이 모든 것이 실행되는 서버, 컨테이너, 함수에 배포, 로깅, 모니터링, 백업, [확장](/glossary/ko/scaling-application-backends/)을 더한 것입니다.

앞의 다섯 가지는 제품 작업입니다. 여섯 번째는 운영이며, 현대의 호스팅 모델은 바로 이 부분을 없애기 위해 존재합니다.

## 백엔드 아키텍처

이 주제의 원래 버전은 서버리스, 서버 지향, 탈중앙화라는 세 가지 계열을 설명했고, 이 분류는 지금도 유효합니다. 바뀐 것은 기본값입니다. 2026년에는 대부분의 새 제품이 서버리스 계열에서 출발하고, "서버 지향"은 점점 머신보다 컨테이너를 뜻하게 되었습니다.

**서버 기반 백엔드.** 여러분의 팀이 물리 머신, 가상 머신, 컨테이너를 프로비저닝하고, 런타임과 데이터베이스를 설치하고, 이를 운영합니다. 통제도 최대, 책임도 최대입니다. 용량, 패치 적용, 가용성, 온콜 순번이 모두 여러분의 몫입니다.

이 방식을 지지하는 고전적인 논거는 여전히 유효합니다. 여러 애플리케이션이 데이터를 공유하는 단일 지점, 간단한 연동, 보호해야 할 단일 접근 지점이 그것입니다. 내부 구조는 [모놀리스든 마이크로서비스든](/glossary/ko/microservices-vs-monolith/) 될 수 있으며, 운영 모델은 같습니다.

**서버리스 백엔드.** 제공업체가 인프라를 운영하고 사용량만큼 과금합니다. 두 가지 형태가 있습니다. 커스텀 코드를 0부터 확장되는 함수로 배포하는 [Function as a Service](/glossary/ko/serverless-architecture/)와, 데이터베이스, 인증, API, 스토리지, 함수가 관리형 플랫폼으로 제공되는 Backend as a Service입니다.

이점은 속도입니다. 첫 기능을 만들기 전에 구축해야 할 서버가 없습니다. 그 대가는 가장 낮은 계층에 대한 통제권입니다. 호스팅 모델의 전체 사다리는 [IaaS vs. PaaS vs. BaaS vs. FaaS](/glossary/ko/iaas-paas-baas-faas/)에서 비교합니다.

**탈중앙화 백엔드.** 단일 운영자가 없으며, 상태는 블록체인이나 콘텐츠 주소 지정 스토리지처럼 대개 오픈소스인 P2P 네트워크에 존재합니다. Bitcoin과 Ethereum이 대표적인 예이며, 이런 앱의 프론트엔드도 서버가 아니라 IPFS나 Swarm 같은 네트워크에 같은 방식으로 호스팅되는 경우가 많습니다.

검열 저항성과 중앙 통제 지점의 부재를 얻는 대신, 지연 시간, 처리량, 그리고 전혀 다른 프로그래밍 모델이라는 대가를 치릅니다. 실제 용도가 있는 틈새이지, 나머지 두 가지를 대체하는 범용 수단은 아닙니다.

## 서버 기반 vs. 서버리스 vs. BaaS vs. 탈중앙화

| 모델 | 서버를 운영하는 주체 | 여러분이 작성하는 것 | 확장 방식 | 적합한 대상 |
| --- | --- | --- | --- | --- |
| 서버 기반 | 여러분의 팀 | 전부: 앱, 데이터 계층, 운영 | 직접 관리하는 용량 추가 | 특수한 요구 사항, 완전한 통제, 기존 운영 팀 |
| 서버리스(FaaS) | 제공업체 | 함수와 데이터 계층 | 호출 단위로, 0부터 | 이벤트 기반 로직, 급증하는 트래픽, 소규모 팀 |
| BaaS | 제공업체 | 프론트엔드 + 커스텀 로직만 | 사용량 단위로, 플랫폼이 관리 | 인증, 데이터, API가 빨리 필요한 모바일 앱과 웹 앱 |
| 탈중앙화 | 피어 네트워크 | 스마트 컨트랙트, 클라이언트 | 네트워크 성장 | 신뢰를 최소화한 시스템, 공유되는 공개 상태 |

## 일반적인 사용 사례

- **모바일 앱과 웹 앱** – 계정, 세션보다 오래 남는 데이터, 기기 간 동기화에는 모두 서버 측이 필요합니다.
- **다중 사용자 제품** – 협업, 마켓플레이스, 채팅처럼 한 사용자의 행동을 다른 사용자가 봐야 하는 모든 것입니다.
- **결제와 민감한 작업** – 시크릿과 돈은 절대 기기에 있어서는 안 됩니다. 백엔드가 키를 보관하고 제공업체와 통신합니다.
- **연동과 자동화** – 사용자가 온라인이든 아니든 실행되는 웹훅, 예약 작업, 파이프라인입니다.
- **AI 기능** – 모델 호출, 검색, 툴 실행은 서버 측에서 실행됩니다. 그곳에서는 키가 비공개로 유지되고 결과를 캐시하고 감사할 수 있습니다.

## 어떤 백엔드 방식을 선택해야 할까? 결정 매트릭스

| 상황 | 선택할 것 |
| --- | --- |
| 이번 주 안에 인증, 데이터, API가 필요한 새 모바일 또는 웹 제품 | BaaS. 범용적인 80%는 설정하고, 여러분만의 20%는 직접 작성 |
| 안정적인 기준선 없이 트래픽이 몰리는 이벤트 기반 로직 | 서버리스 함수 |
| 관리형 플랫폼으로는 표현할 수 없는 엄격한 요구 사항 | 컨테이너와 실질적인 운영 계획을 갖춘 서버 기반 |
| 아무도 운영하지 않는 것이 핵심인 시스템 | 탈중앙화 |
| 변경이 더딘 기존 서버 기반 백엔드 | 범용적인 부분부터 [관리형 백엔드](/glossary/ko/baas-vs-custom-backend/)로 옮기고, 커스텀 핵심은 유지 |

## 한계와 트레이드오프

- **백엔드는 실수가 모두의 문제가 되는 곳입니다.** 프론트엔드 버그는 화면 하나를 망가뜨리지만, 백엔드 버그는 데이터를 손상시키거나 노출합니다. 검증, 권한, 테스트가 코드베이스의 어느 곳보다 여기서 중요합니다.
- **운영은 사라지지 않고 이동할 뿐입니다.** 관리형 플랫폼이 서버, 확장, 백업을 흡수하더라도 데이터 모델, 접근 규칙, 예산은 여전히 누군가의 몫입니다. 잊고 싶은 책임이 아니라 계속 맡고 싶은 책임을 기준으로 모델을 골라야 합니다.
- **통제와 속도는 반대 방향으로 당깁니다.** 스택을 직접 운영하는 부분이 많을수록 커스터마이징의 폭은 넓어지고 모든 일이 오래 걸립니다. 직접 운영하는 부분이 적을수록 더 빨리 출시하지만, 제공업체의 로드맵과 [요금](/glossary/ko/cloud-vendor-lock-in/)에 더 많이 의존하게 됩니다.
- **네트워크는 계약의 일부입니다.** 프론트엔드에서 백엔드로 가는 모든 호출은 느릴 수 있고, 중간에 실패할 수 있고, 두 번 도착할 수 있습니다. 지연 시간 예산, 재시도, 멱등성은 첫 엔드포인트부터 백엔드의 관심사입니다.
- **"서버리스"에도 서버는 있습니다.** 콜드 스타트, 실행 제한, 사용량 기반 과금은 실제 제약입니다. 단지 비용 곡선이 다른, 다른 누군가의 머신일 뿐입니다.

## Back4app에서의 백엔드

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다.

위의 계층에 대응시키면 이렇습니다. 데이터 계층과 API 계층은 여러분의 데이터 모델에서 생성되고, 인증과 [클래스 수준 권한](/glossary/ko/class-level-permissions-clp/)이 모든 요청에서 누가 무엇을 할 수 있는지 강제하며, [Cloud Code](/glossary/ko/cloud-code-serverless-functions/)가 여러분의 제품에 고유한 비즈니스 로직과 백그라운드 작업을 담고, 호스팅, 확장, 백업, 모니터링 같은 인프라 계층은 플랫폼이 맡습니다.

이 페이지 맨 위에서 해부한 요청은 실제 Back4app의 전송 형식이며, 그 요청을 보낸 [SDK](/glossary/ko/backend-sdk/)가 모든 주요 플랫폼에서 프론트엔드가 그 백엔드와 대화하는 방법입니다.