웹 프레임워크의 본질

🎯 핵심 질문

코드를 작성했는데, 어떻게 전 세계 사람들이 접근할 수 있게 만들까? 이것은 마치 "길거리 포장마차를 열 것인가, 아니면 글로벌 프랜차이즈 레스토랑을 운영할 것인가?"라고 묻는 것과 같습니다. 백엔드 아키텍처의 선택이 당신의 "레스토랑"이 얼마나 많은 고객을 서비스할 수 있을지 결정합니다.

1. 아키텍처 진화를 이해해야 하는 이유

장거리 여행을 계획한다고 상상해 보세요. 자전거를 탈 수도 있고, 자가용을 운전할 수도 있고, 고속열차를 탈 수도 있고, 비행기를 탈 수도 있습니다. 각 방식에는 적합한 상황이 있습니다. 자전거는 짧은 거리에서 운동을 겸할 때 적합하고, 비행기는 대륙을 횡단하는 장거리 여행에 적합합니다.

백엔드 아키텍처의 선택도 마찬가지입니다.

인터넷이 탄생한 이후로 백엔드 아키텍처는 여러 차례 큰 변화를 겪었습니다. 각 변화는 "새로운 유행을 쫓기 위함"이 아니라, 당시 직면한 특정 문제를 해결하기 위한 것이었습니다.

연대	핵심 문제	아키텍처 진화
1990s	웹사이트를 어떻게 구동할 것인가	물리 서버
2000s	코드가 점점 복잡해져 유지보수가 어려움	모놀리식 아키텍처 + MVC
2010s	시스템이 너무 커져 확장과 협업이 어려움	마이크로서비스 + 컨테이너화
2020s	운영 비용과 복잡성을 어떻게 줄일 것인가	서버리스 + 클라우드 네이티브

📊 이 표에서 무엇을 알 수 있나요?

행별로 이 표를 해석해 보겠습니다.

1990s → 2000s: "일단 돌아가기만 하면 된다"에서 "유지보수가 필요하다"로. 웹사이트가 정적 페이지에서 동적 애플리케이션으로 바뀌면서 코드 양이 급증했고, 더 나은 구성 방식이 필요해졌습니다.

2000s → 2010s: "단일 머신"에서 "분산 시스템"으로. 사용자 수가 폭발적으로 증가하면서 단일 서버로는 감당할 수 없게 되어 시스템을 분할하고 수평 확장이 필요해졌습니다.

2010s → 2020s: "직접 운영"에서 "클라우드 서비스"로. 컨테이너와 마이크로서비스는 강력했지만 운영 비용이 너무 높아서, 서버리스는 개발자가 비즈니스 로직에만 집중할 수 있게 해줍니다.

핵심 교훈: 아키텍처 진화는 기술 선택의 게임이 아니라 실제 문제를 해결하는 과정입니다. 각 단계에는 적합한 시나리오가 있으며, "최고의 아키텍처"는 없고 오직 "가장 적합한 아키텍처"만 있습니다.

아키텍처 진화를 이해하는 의미:

바퀴를 다시 발명하지 않기: 많은 "새로운" 개념은 사실 수십 년 전에 이미 원형이 있었습니다. 역사를 이해하면 거인의 어깨 위에 설 수 있습니다
합리적인 기술 선택: 최고의 아키텍처는 없고, 현재 단계에 가장 적합한 아키텍처만 있습니다
기술 뒤에 숨은 트레이드오프 이해: 모든 아키텍처 진화는 개발 효율성, 시스템 성능, 운영 복잡성 사이에서 균형을 맞추는 것입니다
기술 트렌드 예측: 역사는 항상 운율을 맞추며 반복됩니다. 과거의 진화 패턴을 이해하면 미래 방향을 파악하는 데 도움이 됩니다

🏗️Backend Architecture EvolutionUnderstand 30 years of architecture evolution through a restaurant analogy

1990s

🏠

Small family workshop

Physical server

2000s

🏢

Large central kitchen

Monolith

2010s

🏭

Specialized division

Microservices

2020s+

🍽️

Delivery platform

Serverless

🏠

Home kitchen

🍽️ Restaurant scenario

One cook works in a small kitchen and personally buys ingredients, washes, cuts, cooks, and serves. When customers increase, everyone has to queue.

💻 Backend mapping

One physical server handles every request: receiving HTTP requests, reading files, executing CGI scripts, and returning responses. CPU and memory are limited, so extra requests queue up.

⚡ Core pain points

Single-machine bottleneck: too many customers overwhelm the cook
Vertical scaling is expensive: buying a bigger machine is like buying a bigger kitchen
Single point of failure: if the cook is unavailable, the restaurant closes

💡Core idea:Architecture evolves to solve the pain points of the previous era, while introducing new complexity. There is no best architecture, only the architecture that best fits the context.

2. 물리 서버 시대 (1990s)

2.1 물리 서버란 무엇인가?

인터넷 초기에는 백엔드가 데이터센터에 있는 물리 서버(실제 컴퓨터 한 대)였습니다.

💡 쉬운 설명

물리 서버는 여러분의 데스크톱 컴퓨터와 비슷하지만, 다음과 같은 특징이 있습니다:

24시간 365일 꺼지지 않음
전용 데이터센터에 위치 (에어컨, UPS 전원, 소방 시스템 구비)
더 빠른 네트워크 대역폭 (기업용 광케이블)
고정된 공인 IP 주소 (전 세계에서 접근 가능)

이것은 마치 가정집과 레스토랑의 차이와 같습니다. 가정집은 가끔 요리만 하지만, 레스토랑은 전문 주방으로 24시간 영업하고 장비도 더 전문적입니다.

2.2 핵심 특징

단일 머신 배포: 모든 애플리케이션이 한 대의 물리 머신에서 실행됨
수동 운영: 수동으로 랙 장착, 배선, 시스템 설치 필요
수직 확장: 성능이 부족하면 더 강력한 머신을 구매해야 함

🔧 수직 확장 vs 수평 확장

수직 확장(Scale Up): 단일 서버의 사양을 업그레이드 (더 많은 CPU, 더 큰 메모리, 더 빠른 디스크).

수평 확장(Scale Out): 더 많은 서버를 추가하여 함께 작동하게 함.

비유:

수직 확장: 작은 레스토랑을 큰 레스토랑으로 개조하고 더 고급스럽게 인테리어하지만, 요리사는 한 명뿐
수평 확장: 프랜차이즈 체인을 열어 각 지점은 크지 않지만 100개의 지점을 운영

장단점:

수직 확장은 간단하지만 상한선이 있음 (최고급 서버는 매우 비싸고 제한적임)
수평 확장은 이론적으로 무한하지만, 데이터 일관성 문제를 해결해야 함

2.3 문제점

느림: 코드를 변경할 때마다 수동으로 업로드하고 서버를 재시작해야 함
비쌈: 확장하려면 더 큰 머신을 구매해야 함 (수직 확장)
확장 어려움: 한 대의 머신이 모든 요청을 처리하므로 CPU가 가득 차면 대기해야 함

🖥️Physical Server Era DemoObserve the processing bottleneck of early CGI servers

👤 User browser

🖥️ CGI server

Waiting for requests

💡Core idea:Process-level isolation improves stability, but it also creates heavy performance overhead.

2.4 물리 서버 시대의 장단점

차원	평가
장점	하드웨어 완전 제어, 성능 예측 가능; 가상화 오버헤드 없음; 데이터 물리적 격리, 높은 보안성
단점	구매 주기 김(수 주); 초기 투자 큼(CapEx); 리소스 활용률 낮음; 확장 어려움
적용 시나리오	금융 핵심 시스템, 정부 기밀 시스템, 데이터 주권에 대한 엄격한 요구사항이 있는 시나리오

💡 CapEx vs OpEx

CapEx(Capital Expenditure): 자본적 지출, 하드웨어 구매에 한 번에 많은 자금을 투자.

OpEx(Operating Expenditure): 운영적 지출, 사용량에 따라 지불 (예: 클라우드 서버).

비유:

CapEx: 집을 사는 것, 한 번에 수백만 원을 지불하고 이후 매월 관리비만 납부
OpEx: 집을 빌리는 것, 매월 임대료를 내고 한 번에 큰 돈을 낼 필요 없음

클라우드 시대의 교훈: 서버리스와 클라우드 서비스는 더 많은 회사가 CapEx에서 OpEx로 전환하게 하여 창업 진입 장벽을 낮춥니다.

3. 모놀리식 아키텍처 시대 (2000s)

3.1 모놀리식 아키텍처란 무엇인가?

프레임워크(Rails / Django / Spring)의 등장과 함께, 모든 기능을 하나의 애플리케이션에 집어넣었습니다.

💡 쉬운 설명

모놀리식 아키텍처(Monolith)는 마치 거대한 쇼핑몰과 같습니다:

의류 코너, 식품 코너, 가전 코너가 모두 같은 건물에 있음
모든 직원이 하나의 관리 시스템에서 근무
건물 전체가 정전되면 모든 구역이 영업 중단

이와 대조적으로 마이크로서비스는 상가 거리와 같습니다: 각 가게는 독립적으로 운영되며, 한 가게가 문을 닫아도 다른 가게에 영향을 주지 않습니다.

🏢Monolithic Architecture DemoObserve how a monolithic application handles requests

Monolithic application process

👤

User module

Healthy

📦

Order module

Healthy

💳

Payment module

Healthy

🏭

Inventory module

Healthy

🗄️

Shared database

💡Core idea:All modules run in the same process and share memory. If one module crashes, the entire process may go down.

3.2 핵심 특징

단일 코드베이스: 모든 기능 모듈이 동일한 프로젝트에 있음
공유 데이터베이스: 모든 모듈이 동일한 데이터베이스를 공유
통합 배포: 전체 애플리케이션을 하나의 패키지로 배포

3.3 장점

개발 단순: 하나의 프로젝트로 모든 기능을 해결
배포 편리: 큰 패키지를 서버에 올리기만 하면 됨
디버깅 용이: 로컬에서 실행하면 모든 기능을 디버깅할 수 있음

3.4 문제점: 눈사태 효과

"채소 써는" 요리사가 실수로 손을 베였다면(코드에 버그 발생), 주방 전체가 멈춰서 상처를 치료해야 하고, 모든 손님이 식사를 하지 못하게 됩니다.

이것이 모놀리식 아키텍처의 가장 큰 위험입니다: 격리성이 낮다.

🚨 실제 눈사태 사례

한 전자상거래 회사의 광군제(11월 11일) 대규모 프로모션:

주문 서비스에서 특정 상품의 가격 계산 오류로 예외 발생
예외가 제대로 포착되지 않아 스레드 풀 고갈
모든 후속 요청(상품 조회, 검색, 사용자 로그인 포함)이 차단됨
전체 웹사이트가 1시간 동안 완전히 마비됨

마이크로서비스를 사용했다면:

주문 서비스는 중단되었지만, 상품 조회, 검색, 사용자 로그인은 여전히 사용 가능
사용자는 최소한 상품을 계속 둘러볼 수 있어 손실을 최소화

3.5 모놀리식 아키텍처의 장단점과 적용 시나리오

차원	평가
장점	개발 단순, 분산 복잡성 고려 불필요; 디버깅 용이, 로컬 실행으로 모든 기능 디버깅 가능; 배포 단순, 하나의 패키지만 실행하면 됨; 트랜잭션 관리 용이, 단일 머신 DB로 ACID 보장
단점	코드 결합도 높음, 비즈니스 성장에 따라 코드 팽창; 기술 스택 단일화, 부분적 업그레이드 어려움; 확장 어려움, 전체만 확장 가능; 장애 격리 불량, 한 모듈 장애가 전체에 영향; 팀 협업 효율 저하, 여러 사람이 같은 코드 수정
적용 시나리오	스타트업 MVP 검증, 소규모 팀(<10명), 비교적 단순한 비즈니스, 확장성보다 출시 속도가 중요한 시나리오
부적합 시나리오	대규모 팀 병렬 개발, 서로 다른 모듈의 빈번한 릴리스 필요, 특정 모듈의 독립적 확장이 필요한 시나리오

🎯 초보자를 위한 조언

백엔드 개발을 배우고 있다면 모놀리식 아키텍처부터 시작하는 것을 강력히 권장합니다:

먼저 걷기를 배우기: HTTP, 데이터베이스, 기본 MVC 아키텍처 이해
그다음 달리기 고려: 프로젝트가 실제로 확장성 문제에 직면했을 때 마이크로서비스 고려
과도한 설계 피하기: 많은 회사의 "마이크로서비스"는 사실 "분산형 모놀리스"로, 유지보수가 더 어려움

학습 경로:

단계 1: Spring Boot / Django / Rails로 완전한 모놀리식 애플리케이션 작성
단계 2: 성능 병목 현상이 발생하면 1-2개의 서비스 분리 시도
단계 3: 팀 규모 >50명, 시스템이 정말 복잡해지면 전면적인 마이크로서비스화

3.6 모놀리식 아키텍처의 기술 스택

언어/프레임워크	특징	대표 기업
Java + Spring	엔터프라이즈 개발 1순위, 생태계 완성도 높음	알리바바, 징동
PHP + Laravel/ThinkPHP	빠른 개발, 중소규모 프로젝트에 적합	초기 Facebook, 웨이보
Python + Django/Flask	개발 효율 높음, 빠른 프로토타입에 적합	Instagram, Pinterest
Ruby on Rails	설정보다 관례, 스타트업의 사랑을 받음	GitHub, Twitter(초기)
Node.js + Express	프론트엔드/백엔드 언어 통일, I/O 집약적 시나리오	Netflix, Uber

4. 컨테이너화와 마이크로서비스 (2010s)

4.1 마이크로서비스가 필요한 이유

모놀리식 아키텍처의 문제점이 2010년대에 집중적으로 폭발했습니다:

코드가 너무 거대함: 한 프로젝트에 수백만 줄의 코드, 신입이 이해하는 데 한 달이 걸림
배포가 너무 느림: 빌드 한 번에 30분, 릴리스 한 번에 조마조마
협업이 너무 어려움: 100명의 개발자가 같은 프로젝트를 수정, 코드 충돌이 매일 발생
확장이 너무 비쌈: "채팅 서비스"만 확장하면 되는데 전체 애플리케이션을 복제해야 함

마이크로서비스의 핵심 아이디어: 큰 애플리케이션을 여러 개의 작은 서비스로 분할, 각 서비스는:

독립적 개발, 독립적 배포
자체 데이터베이스 보유
API를 통해 통신

🐳Docker Containerization DemoSee how containers let applications be packaged once and run anywhere

Traditional deployment

App A

Dependency library v1.0

Operating system

Physical server

Docker containers

App A

Dependency v1.0

App B

Dependency v2.0

Docker Engine

Host operating system

Physical server

📦

Environment consistency

Development, testing, and production environments stay consistent.

🚀

Fast deployment

Second-level startup, image distribution, and rolling updates without downtime.

📊

Resource isolation

CPU and memory limits keep multiple applications from interfering with each other.

🔄

Version management

Versioned images support rollback and gradual rollout.

💡Core idea:Containerization lets applications be built once and run anywhere, solving environment consistency and fast deployment problems.

💡 Docker란 무엇인가?

Docker는 마치 "컨테이너"와 같습니다:

각 컨테이너에는 독립된 화물이 있음 (코드 + 의존성 라이브러리 + 실행 환경)
어디로 운반되든 (어느 서버든), 컨테이너를 열면 바로 작업 시작 가능
"이 머신에는 Python 3.9가 없어", "저 머신에는 특정 라이브러리가 없어" 같은 걱정 불필요

비유:

Docker 없음: 이사할 때마다 가구, 가전, 옷을 하나씩 트럭에 싣고, 새 집에 도착해서 하나씩 정리
Docker 있음: 모든 물건을 컨테이너에 포장, 트럭이 바로 운반, 새 집에 도착하면 내려놓고 바로 사용

핵심 가치: "한 번 빌드하면 어디서나 실행".

4.2 기술 스택 타임라인

📚Technology Stack Evolution TimelineMainstream technology stacks in each era

🖥️Physical server era1990s

Web servers

ApacheNginxIIS

Backend languages

PerlPHPASP

Databases

MySQLPostgreSQLOracle

Deployment

FTPSSHManual

🏢Monolith2000s

Backend frameworks

SpringDjangoRailsLaravel

Frontend tech

jQueryBootstrapJSP

Databases

MySQLRedisMongoDB

Build tools

MavenGradleAnt

🏭Microservices2010s

Containers

DockerKubernetesHelm

Service frameworks

Spring CloudgRPCDubbo

Data stores

RedisMongoDBKafkaES

Observability

PrometheusGrafanaJaeger

☁️Serverless2020s+

Function compute

LambdaVercelCloudflare

BaaS

SupabaseFirebaseAuth0

Frontend frameworks

Next.jsNuxtSvelteKit

Databases

PlanetScaleNeonTurso

4.3 마이크로서비스 아키텍처

모놀리스의 문제를 해결하기 위해 큰 주방을 여러 개의 작은 주방(서비스)으로 나누었습니다:

사용자 전담 서비스
주문 전담 서비스
결제 전담 서비스

🏭 Microservices Architecture Demo

Observe how independent services collaborate and communicate

👤User serviceHealthy

Port:8081

Database:MySQL

Dependencies:None

📦Order serviceHealthy

Port:8082

Database:PostgreSQL

Dependencies:User service

💳Payment serviceHealthy

Port:8083

Database:MongoDB

Dependencies:User service, Order service

🏭Inventory serviceHealthy

Port:8084

Database:Redis

Dependencies:Order service

Service-to-service communication flow

User service

Verify user identity

Order service

Create order record

Inventory service

Check stock quantity

Payment service

Process payment request

Order service

Update order status

4.4 Kubernetes 오케스트레이션

컨테이너 수가 수백에서 수천 개에 달하면 "항만 물류 시스템"이 필요합니다:

Kubernetes (K8s): 컨테이너를 적절한 머신에 배치 (스케줄링, 오토스케일링, 롤링 업데이트)
Service Mesh: 서비스 간의 교통 규칙 담당 (서킷 브레이커, 레이트 리미팅, 재시도, 관측 가능성)

☸️ Kubernetes Orchestration Demo

Observe how K8s schedules containers, balances load, and recovers from failures

Control Plane

🌐

API Server

Unified cluster entry point

🗄️

etcd

Distributed key-value store

📋

Scheduler

Pod scheduler

🎮

Controller

Controller manager

Worker Nodes

🖥️Node-1Running

CPU:

45%

Memory:

60%

Running Pods: 5

🖥️Node-2Running

CPU:

30%

Memory:

40%

Running Pods: 3

🖥️Node-3Pending

CPU:

Memory:

Running Pods: 0

💡 Kubernetes core concepts

Pod: The smallest deployment unit. A Pod can contain one or more containers.
Deployment: Manages Pod replica count and rolling updates.
Service: Provides stable network access and load balancing.
Scheduler: Automatically schedules Pods to suitable nodes based on resource needs and policies.

💡 "오케스트레이션"이란 무엇인가?

오케스트레이션(Orchestration)은 대량의 컨테이너를 자동으로 관리하는 시스템을 의미합니다.

비유:

K8s 없음: 100개의 컨테이너를 수동으로 관리, 장애 발생 시 수동 재시작, 트래픽 증가 시 수동으로 머신 추가
K8s 있음: "이 서비스가 항상 10개의 인스턴스로 실행되게 해줘"라고 말하면, 자동으로:
- 리소스가 충분한 서버에 컨테이너 스케줄링
- 컨테이너 장애 시 자동 재시작
- 트래픽 증가 시 자동으로 20개 인스턴스로 확장
- 코드 업데이트 시 롤링 업데이트 (먼저 오래된 인스턴스 1개 중지, 새 인스턴스 1개 시작, 순차적으로 교체)

핵심 포인트: 마이크로서비스는 "분리만 하면 된다"가 아니라, 진짜 어려운 점은 거버넌스와 운영에 있습니다.

4.5 마이크로서비스와 컨테이너화의 장단점

차원	평가
장점	서비스 독립 배포, 기술 스택 이종성 가능; 장애 격리, 단일 서비스 장애가 전체에 영향 없음; 필요에 따라 확장, 핫스팟 서비스만 개별 확장; 팀 협업 친화적, 다른 팀이 다른 서비스 담당; 코드베이스가 작아 이해와 유지보수 용이
단점	분산 복잡성 높음(네트워크 지연, 분산 트랜잭션, 서비스 디스커버리); 운영 비용 높음, 전문 DevOps 팀 필요; 디버깅 어려움, 여러 서비스에 걸친 문제 추적 필요; 데이터 일관성 보장 어려움; 배포 및 모니터링 인프라 요구사항 복잡
적용 시나리오	대규모 팀(>50명), 비즈니스 복잡도 높아 모듈별 독립적 진화 필요, 특정 모듈의 독립적 확장 필요, 다중 언어 기술 스택 필요, 고가용성이 요구되는 시스템
부적합 시나리오	소규모 팀, 단순한 비즈니스, 트래픽이 적고 안정적, 전문 운영 팀이 없는 경우

⚠️ 마이크로서비스의 함정

함정 1: 분산형 모놀리스

10개의 마이크로서비스로 분리했지만 서로 긴밀하게 결합됨:

서비스 A가 서비스 B를 호출, 서비스 B가 서비스 C를 호출, 서비스 C가 다시 서비스 A를 호출
기능 하나를 변경하려면 5개의 서비스를 동시에 수정해야 함
배포 시 순서대로 배포해야 하며, 그렇지 않으면 시스템 오류 발생

이것은 모놀리스보다 더 나쁩니다: 모놀리스의 복잡성을 가지면서 마이크로서비스의 독립 배포 이점은 누리지 못합니다.

함정 2: 과도한 분할

100줄짜리 코드 기능도 독립된 서비스로 분할:

10개의 서비스, 각각 100줄의 코드만 있음
서비스 간 통신 오버헤드(네트워크 직렬화/역직렬화)가 실제 비즈니스 로직보다 더 무거움
운영 비용 폭발: 10개 서비스의 배포, 모니터링, 로그 수집 필요

올바른 접근법: 기능 응집도 관점에서 분할, 하나의 마이크로서비스는 완전한 비즈니스 능력이어야 함 (예: "주문 서비스", "주문 생성 서비스", "주문 조회 서비스"가 아님).

4.6 마이크로서비스 기술 스택

카테고리	기술/도구	역할
컨테이너화	Docker, containerd	애플리케이션 패키징 및 격리
오케스트레이션	Kubernetes, Docker Swarm	컨테이너 관리 및 자동 확장/축소
서비스 디스커버리	Consul, etcd, ZooKeeper	서비스 등록 및 발견
API 게이트웨이	Kong, Zuul, Envoy	통합 진입점, 라우팅, 레이트 리미팅
설정 센터	Apollo, Nacos, Spring Cloud Config	중앙 집중식 설정 관리
모니터링 및 알림	Prometheus, Grafana, ELK	지표 모니터링 및 로그 분석
분산 추적	Jaeger, Zipkin, SkyWalking	분산 요청 추적
서비스 메시	Istio, Linkerd	트래픽 거버넌스 및 보안

5. 서버리스와 클라우드 네이티브 시대 (2020s+)

5.1 서버리스가 필요한 이유

마이크로서비스는 좋지만, 수십 개의 작은 주방을 유지하는 것은 여전히 힘듭니다. 다음과 같은 걱정이 필요합니다:

주방이 충분히 큰가? (서버 확장)
정전되면 어떻게 하나? (고가용성)
컨테이너가 너무 많으면 어떻게 관리하나? (운영 비용)

⚡ Serverless Architecture Demo

Observe on-demand function execution and automatic scaling

🔐

User login

Cold

📦

Order processing

Cold

🖼️

Image processing

Cold

💾

Data backup

Cold

Auto-scaling status

Concurrent requests:0

Running instances:0

Cold starts:0

Traffic simulator

💡 Serverless core traits

On-demand execution: Functions run only when invoked, so idle functions do not create runtime cost.
Automatic scaling: Scale automatically from zero to thousands of instances without manual intervention.
Cold start: The first call after a long idle period may have extra latency and may need warm-up strategies.
Event driven: Respond to HTTP requests, message queues, scheduled tasks, and other event sources.

💡 서버리스는 진짜 "서버가 없는 것"이 아닙니다

서버리스는 "서버를 관리할 필요가 없다"는 의미이지, 실제로 서버가 없다는 뜻이 아닙니다.

비유:

물리 서버 시대: 땅을 사고, 건물을 짓고, 인테리어하고, 요리사를 고용하고, 식재료를 구매... 모든 것을 직접 함
클라우드 서버 시대: 이미 인테리어된 레스토랑을 임대하지만, 요리사는 직접 고용하고 운영 관리
서버리스 시대: 메뉴만 디자인하면 됨, 클라우드에 공유 주방이 있고 전문 요리사가 있으며, 주문하면 그들이 만들고 건당 지불

핵심 변화:

예전: 서버 구매 → 환경 설정 → 코드 배포 → 모니터링 → 확장 → 유지보수
지금: 코드 작성 → 업로드 → 사용량에 따라 지불

마치 배달 음식처럼: 주방이 필요 없고, 메뉴만 디자인하면 누군가가 만들어 줍니다.

5.2 서버리스란 무엇인가?

Serverless = FaaS + BaaS

FaaS(Function as a Service, 서비스형 함수):

함수만 작성 (예: "사용자 등록 시 환영 이메일 발송")
클라우드 제공자가 이 함수를 실행하고 자동으로 확장/축소
대표 사례: AWS Lambda, 알리바바 클라우드 함수 컴퓨팅

BaaS(Backend as a Service, 서비스형 백엔드):

로그인 → Auth0 / Supabase Auth
결제 → Stripe
데이터베이스 → Supabase / Firebase / DynamoDB
메시지 → Kafka / SQS

🎯 서버리스 적용 시나리오

최적 시나리오:

간헐적 트래픽: 배달 앱, 점심시간에 트래픽 폭주, 한밤중에는 사람이 없음. 서버리스는 점심에 자동으로 1000대의 머신을 할당하고, 한밤중에는 0대로 축소
이벤트 기반: "사용자가 이미지 업로드 시 자동으로 이미지 압축"
빠른 검증: 소규모 팀, MVP, 해커톤 프로젝트

부적합 시나리오:

장시간 실행 작업: 비디오 트랜스코딩 (1시간 실행될 수 있음, 함수 최대 실행 시간은 보통 15분)
저지연이 필요한 애플리케이션: 고빈도 트레이딩 (콜드 스타트 지연이 수십 밀리초에서 수 초까지)
세밀한 하위 계층 제어가 필요한 경우: OS 커널 튜닝, GPU 직접 접근

5.3 서버리스와 클라우드 네이티브의 장단점

차원	평가
장점	운영 비용 제로, 개발자는 비즈니스 코드에만 집중; 자동 확장/축소, 트래픽 피크에 완벽 대응; 사용량 기반 과금, 트래픽 없을 때 비용 거의 제로; 빠른 출시, 몇 분 만에 글로벌 배포 가능; 고가용성 내장, 클라우드 서비스가 자동 장애 조치 처리
단점	콜드 스타트 지연(수백 밀리초에서 수 초); 실행 시간 제한(보통 5-15분); 디버깅 어려움, 로컬에서 클라우드 환경 완전 시뮬레이션 어려움; 벤더 종속 위험; 장시간 실행 또는 컴퓨팅 집약적 작업에 부적합; 고빈도 지속 트래픽에서 비용이 기존 방식보다 높을 수 있음
적용 시나리오	이벤트 기반 처리(이미지 처리, 메시지 알림); 간헐적 트래픽 애플리케이션(이벤트 페이지, 프로모션); 빠른 프로토타입 검증 및 MVP; 저빈도 API 또는 백그라운드 작업; 전담 운영 팀이 없는 소규모 팀
부적합 시나리오	지속적 저지연이 필요한 애플리케이션; 장시간 컴퓨팅 작업; 콜드 스타트에 민감한 시나리오(고빈도 트레이딩); 하위 인프라에 대한 세밀한 제어가 필요한 시나리오

💰 비용 비교: 언제 서버리스가 더 비쌀까?

시나리오 1: 저빈도 접근

기존 서버: 월 $20 (접근 여부와 관계없이)
서버리스: 100만 회 요청 × $0.0002/회 = $20 (트래픽이 있을 때만 과금)
결론: 저빈도 시나리오에서는 서버리스가 더 저렴

시나리오 2: 고빈도 지속 접근

기존 서버: 월 $20
서버리스: 1억 회 요청 × $0.0002/회 = $20,000
결론: 고빈도 지속 시나리오에서는 기존 서버가 더 저렴

시나리오 3: 간헐적 트래픽

기존 서버: 피크 대응을 위해 월 $100의 서버 필요 (평소 리소스 활용률은 10%에 불과)
서버리스: 피크 시 $20, 평소 거의 $0
결론: 간헐적 트래픽 시나리오에서는 서버리스가 비용 절감

교훈: 무턱대고 서버리스로 전환하지 말고, 실제 트래픽 특성에 따라 비용을 계산해야 합니다.

5.4 서버리스 기술 스택과 플랫폼

카테고리	기술/플랫폼	특징
FaaS 플랫폼	AWS Lambda	최초의 FaaS 서비스, 가장 성숙한 생태계
	Azure Functions	마이크로소프트 클라우드 통합도 높음, .NET 친화적
	Google Cloud Functions	GCP 서비스와 깊은 통합
	알리바바 클라우드 함수 컴퓨팅	국내 생태계 완성도 높음, 콜드 스타트 최적화 우수
	텐센트 클라우드 클라우드 함수	위챗 생태계와 통합
	Vercel/Netlify Functions	프론트엔드 개발자 친화적, 엣지 배포
BaaS 서비스	Firebase	Google의 모바일 백엔드 솔루션
	Supabase	PostgreSQL 기반 Firebase 오픈소스 대안
	AWS Amplify	AWS의 모바일 및 웹 앱 개발 플랫폼
배포 도구	Serverless Framework	멀티 클라우드 배포, 활발한 커뮤니티
	Terraform	코드형 인프라
	Pulumi	프로그래밍 언어로 인프라 정의

6. 각 아키텍처 단계 비교 및 선택 가이드

6.1 아키텍처 진화 전체 비교

🏗️Architecture Evolution ComparisonCore architectural traits across four eras

🖥️

Physical server

1990s

Single node

🏢

Monolith

2000s

Centralized

🏭

Microservices

2010s

Distributed

☁️

Serverless

2020s+

No server ops

🏢

Monolith (2000s)

🏗️ Architecture traits

Single codebase and unified stack
Shared database and transactional consistency
Unified deployment and whole-system release
In-process communication without network overhead

✅ Advantages

Simple development and onboarding
Convenient local testing
Simple deployment as one package

❌ Pain points

Tight coupling makes small changes risky
Single stack makes new technology hard to introduce
Large teams become hard to coordinate

🔧 Typical technologies

Spring/Django/RailsTomcat/GunicornMySQL/PostgreSQLMaven/Gradle

💡Core idea:Architecture evolves to solve prior pain points, while also introducing new complexity.

차원	물리 서버	모놀리식 아키텍처	마이크로서비스+컨테이너	서버리스
팀 규모	1-5명	5-50명	50-500명	1-20명
배포 복잡도	매우 높음	낮음	매우 높음	매우 낮음
운영 비용	높음	중간	매우 높음	낮음
확장성	낮음	수직 확장 제한적	수평 확장 우수	자동 확장
기술 스택 유연성	없음	단일	다양화	제한적
콜드 스타트	없음	없음	컨테이너 시작 시간	지연 있음
적용 시나리오	레거시 시스템, 특수 규정 준수 요구	스타트업, 단순 비즈니스	대형 인터넷 기업, 복잡한 비즈니스	빠른 검증, 이벤트 기반

6.2 기술 선택 결정 트리

선택 시작
    │
    ├─ 팀에 전문 운영 인력이 있는가?
    │   ├─ 예 → 마이크로서비스 또는 물리 서버 고려
    │   └─ 아니오 → 계속 판단
    │
    ├─ 빠르게 출시하여 아이디어를 검증해야 하는가?
    │   ├─ 예 → 서버리스 또는 모놀리식
    │   └─ 아니오 → 계속 판단
    │
    ├─ 팀 규모 > 50명?
    │   ├─ 예 → 마이크로서비스 고려
    │   └─ 아니오 → 계속 판단
    │
    ├─ 트래픽에 뚜렷한 피크-밸리 특성이 있는가?
    │   ├─ 예 → 서버리스
    │   └─ 아니오 → 모놀리식 아키텍처 (스타트업에 권장)
    │
    └─ 특수 요구사항(규정 준수, 레거시 시스템)?
        └─ 예 → 물리 서버

🎯 초보자를 위한 선택 조언

개발자나 소규모 팀이라면:

단계 0 (학습): 로컬에서 모놀리식 애플리케이션 실행, HTTP, 데이터베이스, 기본 아키텍처 이해
단계 1 (MVP): 모놀리식 애플리케이션을 클라우드 서버에 배포 (예: 알리바바 클라우드 ECS, AWS EC2)
단계 2 (성장): 팀 >10명, 비즈니스가 복잡해지면 1-2개의 마이크로서비스 분리 고려
단계 3 (성숙): 팀 >50명, 트래픽 백만 단위, 전면적 마이크로서비스화

핵심 원칙: 처음부터 마이크로서비스를 도입하지 마세요. 그것은 "성급한 최적화"입니다. 아키텍처가 비즈니스 성장과 함께 진화하게 하세요.

6.3 다양한 시나리오별 권장 아키텍처

시나리오 1: 개인 개발자/부업 프로젝트

권장 아키텍처: 서버리스 (Vercel/Netlify) 또는 모놀리식 애플리케이션
이유: 운영 비용 거의 제로, 사용량 기반 과금, 빠른 출시
예시 기술 스택: Next.js + Vercel + Supabase

시나리오 2: 스타트업 MVP 검증

권장 아키텍처: 모놀리식 아키텍처 + 클라우드 서버
이유: 개발 속도가 빠르고, 팀이 인프라보다 비즈니스 로직에 집중할 수 있음
예시 기술 스택: Spring Boot / Django / Rails + RDS + ECS

시나리오 3: 성장 중인 회사 (10-50명 팀)

권장 아키텍처: 모듈형 모놀리스 또는 경량 마이크로서비스
이유: 코드 결합 문제가 발생하기 시작하지만, 아직 완전한 마이크로서비스 복잡성은 필요 없음
예시 기술 스택: Spring Cloud / Go Micro + Kubernetes

시나리오 4: 대형 인터넷 기업

권장 아키텍처: 마이크로서비스 + 서비스 메시 + 미들웨어 플랫폼 아키텍처
이유: 팀 규모가 크고, 비즈니스가 복잡하며, 독립적인 릴리스 주기와 기술 스택이 필요
예시 기술 스택: 자체 개발 RPC 프레임워크 + Istio + 자체 구축 PaaS 플랫폼

시나리오 5: 이벤트 기반/간헐적 트래픽 애플리케이션

권장 아키텍처: 서버리스 + 이벤트 버스
이유: 트래픽 변동이 크고, 극단적인 비용 최적화와 자동 확장/축소 필요
예시 기술 스택: AWS Lambda + API Gateway + EventBridge

7. 요약 및 학습 로드맵

7.1 핵심 요점

백엔드 아키텍처의 진화는 본질적으로 덧셈과 뺄셈을 하는 것입니다:

시대	아키텍처	개발자가 할 일	운영자가 할 일
물리 서버 시대	단일 머신	스크립트 작성, 수동 배포	데이터센터 및 하드웨어 유지보수
모놀리식 시대	하나의 덩어리	모든 비즈니스 로직 작성	몇 대의 큰 서버 유지보수
마이크로서비스 시대	분할	단일 비즈니스에 집중	K8s 클러스터 유지보수 (매우 힘듦!)
서버리스	함수	핵심 함수만 작성	차 마시기 (클라우드 제공자가 모두 처리)

핵심 인사이트:

아키텍처 진화는 "새로운 기술이 오래된 기술을 대체하는 것"이 아니라 적용 시나리오의 변화입니다
은탄환은 없으며, 각 아키텍처에는 적용 가능한 경계가 있습니다
아키텍처 선택 시 고려할 사항: 팀 규모, 비즈니스 복잡도, 트래픽 특성, 운영 역량

7.2 학습 로드맵 제안

커리어 단계에 따라 다음 학습 경로를 권장합니다:

단계 1: 기초 다지기 (0-1년)

목표: 백엔드 핵심 개념을 이해하고, 독립적으로 모놀리식 애플리케이션 개발 가능

백엔드 언어 하나 마스터 (Java/Python/Go 중 하나 선택)
HTTP 프로토콜과 RESTful API 설계 학습
관계형 데이터베이스 마스터 (MySQL/PostgreSQL)
캐싱 기초 이해 (Redis)
Git과 기본 Linux 명령어 학습
실습 프로젝트: 모놀리식 아키텍처로 CRUD 애플리케이션 완성 (예: 블로그 시스템, 할 일 목록)

단계 2: 역량 확장 (1-3년)

목표: 분산 시스템을 이해하고, 마이크로서비스 개발에 참여 가능

마이크로서비스 아키텍처와 분할 전략 심화 학습
Docker와 Kubernetes 기초 마스터
메시지 큐 학습 (Kafka/RabbitMQ)
분산 트랜잭션과 일관성 이해
모니터링과 로그 마스터 (Prometheus/ELK)
실습 프로젝트: 모놀리식 애플리케이션을 3-5개의 마이크로서비스로 분할, Docker로 배포

단계 3: 전문성 심화 (3-5년)

목표: 대규모 시스템 설계 가능, 기술 선택 역량 보유

클라우드 네이티브 아키텍처 심층 이해 (Service Mesh, Serverless)
용량 계획 및 성능 튜닝 마스터
멀티-액티브 아키텍처와 재해 복구 설계 이해
DDD(도메인 주도 설계) 학습
기술적 판단력과 아키텍처 사고 배양
실습 프로젝트: 백만 명 사용자 지원 시스템 아키텍처 설계, 고가용성 및 탄력적 확장 방안 포함

7.3 지속적 학습 리소스 추천

도서:

《데이터 중심 애플리케이션 설계》(DDIA) - 분산 시스템 필독서
《클라우드 네이티브 패턴》
《마이크로서비스 설계》
《도메인 주도 설계》

온라인 리소스:

AWS/Azure/알리바바 클라우드 공식 아키텍처 문서
CNCF(Cloud Native Computing Foundation) 프로젝트 문서
주요 기업 기술 블로그 (Netflix Tech Blog, 알리바바 기술 공식 계정 등)

8. 용어집 (Glossary)

용어	전체 명칭	설명
Backend	-	서버 측 시스템, 비즈니스 로직, 데이터 저장 및 외부 인터페이스 처리
CGI	Common Gateway Interface	초기 동적 웹 기술, 스크립트를 통해 요청을 처리하고 결과를 반환
Monolith	-	모놀리식 아키텍처, 모든 비즈니스 로직을 동일한 애플리케이션에 패키징
Microservices	-	마이크로서비스 아키텍처, 비즈니스를 여러 독립 서비스로 분할
Container	-	컨테이너화 기술, 애플리케이션과 의존성을 이식 가능한 단위로 패키징
K8s	Kubernetes	컨테이너 오케스트레이션 플랫폼, 컨테이너 스케줄링, 확장/축소 및 거버넌스 담당
Service Mesh	-	서비스 메시, 마이크로서비스 간 통신 거버넌스, 관측성 및 보안 담당
Serverless	-	서버리스 컴퓨팅, 개발자는 함수만 작성, 플랫폼이 자동 실행 및 확장/축소
BaaS	Backend as a Service	플러그 앤 플레이 방식의 백엔드 클라우드 서비스 (인증, 데이터베이스, 결제 등)
CI/CD	Continuous Integration / Delivery	지속적 통합 및 지속적 배포, 테스트 및 배포 프로세스 자동화
Observability	-	관측 가능성, 로그/지표/추적을 활용하여 시스템 실행 상태 이해

웹 프레임워크의 본질 ​

1. 아키텍처 진화를 이해해야 하는 이유 ​

Home kitchen

🍽️ Restaurant scenario

💻 Backend mapping

⚡ Core pain points

2. 물리 서버 시대 (1990s) ​

2.1 물리 서버란 무엇인가? ​

2.2 핵심 특징 ​

2.3 문제점 ​

2.4 물리 서버 시대의 장단점 ​

3. 모놀리식 아키텍처 시대 (2000s) ​

3.1 모놀리식 아키텍처란 무엇인가? ​

3.2 핵심 특징 ​

3.3 장점 ​

3.4 문제점: 눈사태 효과 ​

3.5 모놀리식 아키텍처의 장단점과 적용 시나리오 ​

3.6 모놀리식 아키텍처의 기술 스택 ​

4. 컨테이너화와 마이크로서비스 (2010s) ​

4.1 마이크로서비스가 필요한 이유 ​

Traditional deployment

Docker containers

4.2 기술 스택 타임라인 ​

4.3 마이크로서비스 아키텍처 ​

🏭 Microservices Architecture Demo

Service-to-service communication flow

4.4 Kubernetes 오케스트레이션 ​

☸️ Kubernetes Orchestration Demo

💡 Kubernetes core concepts

4.5 마이크로서비스와 컨테이너화의 장단점 ​

4.6 마이크로서비스 기술 스택 ​

5. 서버리스와 클라우드 네이티브 시대 (2020s+) ​

5.1 서버리스가 필요한 이유 ​

⚡ Serverless Architecture Demo

💡 Serverless core traits

5.2 서버리스란 무엇인가? ​

5.3 서버리스와 클라우드 네이티브의 장단점 ​

5.4 서버리스 기술 스택과 플랫폼 ​

6. 각 아키텍처 단계 비교 및 선택 가이드 ​

6.1 아키텍처 진화 전체 비교 ​

Monolith (2000s)

🏗️ Architecture traits

✅ Advantages

❌ Pain points

🔧 Typical technologies

6.2 기술 선택 결정 트리 ​

6.3 다양한 시나리오별 권장 아키텍처 ​

시나리오 1: 개인 개발자/부업 프로젝트 ​

시나리오 2: 스타트업 MVP 검증 ​

시나리오 3: 성장 중인 회사 (10-50명 팀) ​

시나리오 4: 대형 인터넷 기업 ​

시나리오 5: 이벤트 기반/간헐적 트래픽 애플리케이션 ​

7. 요약 및 학습 로드맵 ​

7.1 핵심 요점 ​

7.2 학습 로드맵 제안 ​

단계 1: 기초 다지기 (0-1년) ​

단계 2: 역량 확장 (1-3년) ​

단계 3: 전문성 심화 (3-5년) ​

7.3 지속적 학습 리소스 추천 ​

8. 용어집 (Glossary) ​

웹 프레임워크의 본질

1. 아키텍처 진화를 이해해야 하는 이유

2. 물리 서버 시대 (1990s)

2.1 물리 서버란 무엇인가?

2.2 핵심 특징

2.3 문제점

2.4 물리 서버 시대의 장단점

3. 모놀리식 아키텍처 시대 (2000s)

3.1 모놀리식 아키텍처란 무엇인가?

3.2 핵심 특징

3.3 장점

3.4 문제점: 눈사태 효과

3.5 모놀리식 아키텍처의 장단점과 적용 시나리오

3.6 모놀리식 아키텍처의 기술 스택

4. 컨테이너화와 마이크로서비스 (2010s)

4.1 마이크로서비스가 필요한 이유

4.2 기술 스택 타임라인

4.3 마이크로서비스 아키텍처

4.4 Kubernetes 오케스트레이션

4.5 마이크로서비스와 컨테이너화의 장단점

4.6 마이크로서비스 기술 스택

5. 서버리스와 클라우드 네이티브 시대 (2020s+)

5.1 서버리스가 필요한 이유

5.2 서버리스란 무엇인가?

5.3 서버리스와 클라우드 네이티브의 장단점

5.4 서버리스 기술 스택과 플랫폼

6. 각 아키텍처 단계 비교 및 선택 가이드

6.1 아키텍처 진화 전체 비교

6.2 기술 선택 결정 트리

6.3 다양한 시나리오별 권장 아키텍처

시나리오 1: 개인 개발자/부업 프로젝트

시나리오 2: 스타트업 MVP 검증

시나리오 3: 성장 중인 회사 (10-50명 팀)

시나리오 4: 대형 인터넷 기업

시나리오 5: 이벤트 기반/간헐적 트래픽 애플리케이션

7. 요약 및 학습 로드맵

7.1 핵심 요점

7.2 학습 로드맵 제안

단계 1: 기초 다지기 (0-1년)

단계 2: 역량 확장 (1-3년)

단계 3: 전문성 심화 (3-5년)

7.3 지속적 학습 리소스 추천

8. 용어집 (Glossary)