# 2014년, 간단한 앱을 배포하기 위해 필요한 것들

1. EC2 인스턴스 생성 및 설정
   - 인스턴스 타입 선택 (t2.micro? t2.small?)
   - 키페어 생성, 보안 그룹 설정
   - 월 비용: $10-20 (거의 안 쓰는데도)

2. 서버 설정
   $ ssh ec2-user@your-instance.com
   $ sudo apt-get update && sudo apt-get upgrade
   $ sudo apt-get install nginx nodejs npm
   $ sudo systemctl enable nginx

3. 애플리케이션 배포
   $ git clone your-repo
   $ npm install
   $ pm2 start app.js
   $ sudo nginx -s reload

4. 모니터링 설정
   - CloudWatch 알람 설정
   - 로그 수집 설정
   - 디스크 용량 체크

5. 보안 패치
   - 매달 OS 업데이트
   - 취약점 점검
   - SSL 인증서 갱신

6. 새벽 3시
   "⚠️ High CPU Usage Alert!"
   (방문자는 여전히 10명...)

// 이것이 전부입니다
exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Hello from Lambda!' })
  };
};

// 배포하면 끝
// 서버? 없음
// 설정? 최소한
// 비용? 호출당 과금

// 기존 방식: EC2 서버에서 실행
// - 서버 구축 및 유지보수 필요
// - 24/7 비용 발생
// - 스케일링 복잡

// Lambda 방식: 이벤트에 반응
const AWS = require('aws-sdk');
const sharp = require('sharp');
const s3 = new AWS.S3();

exports.handler = async (event) => {
  // S3에 이미지 업로드되면 자동 실행
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;
  
  // 이미지 다운로드
  const image = await s3.getObject({ Bucket: bucket, Key: key }).promise();
  
  // 썸네일 생성
  const thumbnail = await sharp(image.Body)
    .resize(200, 200)
    .toBuffer();
  
  // 썸네일 저장
  await s3.putObject({
    Bucket: bucket,
    Key: `thumbnails/${key}`,
    Body: thumbnail
  }).promise();
  
  return { statusCode: 200, body: 'Thumbnail created' };
};

// 배포 후:
// - 이미지 업로드할 때만 실행
// - 자동 스케일링 (동시에 1000개 업로드해도 OK)
// - 비용: 실행한 만큼만

// 개발자가 원하는 이상향

// 1. 코드만 작성
async function processPayment(userId: string, amount: number) {
  // 비즈니스 로직에만 집중
  const user = await db.users.findById(userId);
  const charge = await stripe.charge(user.card, amount);
  await db.payments.create({ userId, amount, chargeId: charge.id });
  return { success: true };
}

// 2. 배포
// $ serverless deploy

// 3. 끝!
// - 인프라? 신경 쓸 필요 없음
// - 스케일링? 자동
// - 모니터링? 기본 제공
// - 보안? 관리형

// Lambda 함수가 점점 늘어나고...
// ├─ user-create.js
// ├─ user-update.js
// ├─ user-delete.js
// ├─ payment-process.js
// ├─ payment-refund.js
// ├─ email-send.js
// ├─ notification-push.js
// ├─ image-upload.js
// ├─ image-process.js
// ├─ analytics-track.js
// ... (50개 더)

// 문제 발생:
// "어? payment-process에서 에러가 났는데..."
// "어떤 함수가 어떤 함수를 호출하지?"
// "로그가 50개 함수에 흩어져 있어..."
// "디버깅이 왜 이렇게 어려워?"
// "함수 간 의존성을 어떻게 관리하지?"
// "Cold Start로 첫 요청이 3초 걸려..."

// 전통적인 Express.js 서버
// - 상태 유지 가능 (메모리 캐시)
// - 연결 재사용 (DB 커넥션 풀)
// - 긴 실행 시간 OK

const express = require('express');
const app = express();

// 앱 시작 시 한 번만 초기화
const dbPool = createConnectionPool({
  max: 10,
  min: 2
});

// 메모리 캐시
const cache = new Map();

app.get('/users/:id', async (req, res) => {
  // 캐시 확인
  if (cache.has(req.params.id)) {
    return res.json(cache.get(req.params.id));
  }
  
  // DB 조회 (커넥션 재사용)
  const user = await dbPool.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
  cache.set(req.params.id, user);
  
  res.json(user);
});

app.listen(3000);
// 서버는 계속 실행됨

// Lambda (서버리스)
// - 무상태 (stateless)
// - 커넥션 재사용 제한적
// - 실행 시간 제한 (15분)

const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

// 전역 변수는 제한적으로만 재사용됨
// (Lambda 컨테이너가 재사용될 때만)

exports.handler = async (event) => {
  const userId = event.pathParameters.id;
  
  // 캐시 불가능 (무상태)
  // 매번 DB 조회
  const result = await dynamodb.get({
    TableName: 'Users',
    Key: { id: userId }
  }).promise();
  
  return {
    statusCode: 200,
    body: JSON.stringify(result.Item)
  };
};

// 각 요청마다 독립적으로 실행
// 실행 후 컨테이너는 잠들거나 종료됨

// ✅ 서버리스가 적합한 경우

// 1. 이벤트 기반 작업
// - 이미지 처리, 파일 변환
// - 웹훅 처리
// - 예약된 작업 (cron)

// 2. 간헐적 트래픽
// - 하루 몇 번만 호출되는 API
// - 주기적인 데이터 동기화
// - 백오피스 도구

// 3. 빠른 프로토타입
// - MVP 개발
// - PoC (Proof of Concept)
// - 해커톤

// 4. 마이크로서비스
// - 작고 독립적인 서비스
// - 느슨한 결합
// - 명확한 책임

// ❌ 서버리스가 부적합한 경우

// 1. 웹소켓 / 긴 연결
// - 실시간 채팅
// - 게임 서버
// - 스트리밍

// 2. 고정된 높은 트래픽
// - 24/7 높은 부하
// - 예측 가능한 트래픽
// - → EC2가 더 저렴할 수 있음

// 3. 상태가 중요한 애플리케이션
// - 인메모리 캐시가 필수
// - 복잡한 세션 관리
// - 커넥션 풀 의존

// 4. 레이턴시가 중요한 경우
// - Cold Start 허용 불가
// - 밀리초 단위 응답 필요
// - 게임, 금융 거래 등

# 전통적인 워드프레스 블로그 (2010년)

User → Nginx → PHP → MySQL → HTML 생성 → Response
# 매 요청마다 서버에서 HTML 생성
# 느림, 비쌈, 스케일링 어려움

# JAMstack 블로그 (2020년)

Build Time:
  Markdown → Static Site Generator → HTML/CSS/JS
  
Runtime:
  User → CDN → HTML (즉시 전송!)
  Comments? → API (서버리스)
  Search? → API (서버리스)
  
# 빠름, 저렴, 스케일링 자동

// Next.js with Vercel
// pages/api/users.ts - API Route (서버리스!)

export default async function handler(req, res) {
  // 이 코드는 Vercel의 서버리스 함수로 실행됨
  const users = await db.users.findMany();
  res.json(users);
}

// pages/index.tsx - 정적 생성
export async function getStaticProps() {
  // 빌드 타임에 한 번 실행
  const posts = await fetchPosts();
  return { props: { posts }, revalidate: 60 };
}

export default function Home({ posts }) {
  return (
    <div>
      {posts.map(post => (
        <Article key={post.id} {...post} />
      ))}
    </div>
  );
}

// 배포
// $ git push
// → Vercel이 자동 배포
// → 정적 파일은 전 세계 CDN에
// → API는 서버리스 함수로
// → 끝!

# Vercel 배포 예제

# 1. 프로젝트 생성
$ npx create-next-app my-app
$ cd my-app

# 2. Git 연결
$ git init
$ git add .
$ git commit -m "Initial commit"
$ git remote add origin https://github.com/username/my-app.git
$ git push -u origin main

# 3. Vercel 연결
$ vercel login
$ vercel

# 끝!
# - 자동 HTTPS
# - 전 세계 CDN
# - 서버리스 API
# - CI/CD 자동
# - 도메인 연결 간단

# 이후 배포
$ git push
# → 자동으로 프로덕션 배포

# PR 생성 시
# → 자동으로 프리뷰 배포
# → 고유 URL 생성

# 전통적인 CDN (2000년대)

User (Seoul) → CDN (Seoul) → Origin (US West)
                 ↓
               Cache
                 ↓
User (Seoul) → CDN (Seoul) [Cache Hit!]

# 정적 파일만: HTML, CSS, JS, 이미지
# 동적 컨텐츠는 Origin까지 가야 함

# Edge Computing (2020년대)

User (Seoul) → CDN Edge (Seoul)
                    ↓
                [Code 실행!]
                    ↓
                 Response

# Origin 서버까지 안 가도 됨
# 레이턴시 최소화
# 개인화 가능

// Cloudflare Worker 예제
// 전 세계 엣지에서 실행됨

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
});

async function handleRequest(request) {
  const url = new URL(request.url);
  
  // A/B 테스트
  const variant = Math.random() < 0.5 ? 'A' : 'B';
  
  // 지역별 개인화
  const country = request.cf.country; // 'KR', 'US', etc
  const language = country === 'KR' ? 'ko' : 'en';
  
  // HTML 수정
  const response = await fetch(url);
  let html = await response.text();
  html = html.replace('{{language}}', language);
  html = html.replace('{{variant}}', variant);
  
  return new Response(html, {
    headers: { 'Content-Type': 'text/html' }
  });
}

// 전 세계 어디서든 < 50ms 응답

// app/api/edge/route.ts
import { NextRequest, NextResponse } from 'next/server';

export const runtime = 'edge'; // Edge에서 실행!

export async function GET(request: NextRequest) {
  const geo = request.geo;
  
  // 사용자 위치 기반 응답
  const message = geo?.country === 'KR' 
    ? '안녕하세요!' 
    : 'Hello!';
  
  return NextResponse.json({
    message,
    location: geo?.city,
    country: geo?.country,
    latency: 'sub-50ms'
  });
}

// 배포하면 자동으로 전 세계 엣지에 배포됨

// ⚡ Edge Functions (Cloudflare, Vercel Edge)
// - 실행 시간: < 50ms
// - 메모리: 128MB
// - 언어: JavaScript/TypeScript, Rust, C++
// - Cold Start: < 5ms
// - 비용: 매우 저렴

// 적합한 경우:
// - 간단한 로직
// - 낮은 레이턴시 필수
// - 지역별 개인화
// - 인증/인가
// - 리다이렉션

async function edgeHandler(request: Request) {
  // 가볍고 빠른 작업만
  const auth = await verifyToken(request.headers.get('authorization'));
  if (!auth) {
    return new Response('Unauthorized', { status: 401 });
  }
  return fetch(request);
}

// 🚀 Lambda Functions (AWS, GCP, Azure)
// - 실행 시간: 최대 15분
// - 메모리: 최대 10GB
// - 언어: 거의 모든 언어
// - Cold Start: 100ms-3s
// - 비용: 상대적으로 비쌈

// 적합한 경우:
// - 복잡한 로직
// - 긴 실행 시간
// - 많은 메모리
// - DB 연결
// - 파일 처리

async function lambdaHandler(event) {
  // 복잡하고 무거운 작업
  const image = await downloadImage(event.imageUrl);
  const processed = await heavyImageProcessing(image);
  await uploadToS3(processed);
  await updateDatabase(event.id, processed.url);
  return { statusCode: 200 };
}

// 1. 점진적 마이그레이션
// 레거시 시스템을 점진적으로 교체

export async function middleware(request: NextRequest) {
  const url = new URL(request.url);
  
  // 새로운 페이지는 Next.js로
  if (url.pathname.startsWith('/new')) {
    return NextResponse.next();
  }
  
  // 기존 페이지는 레거시 서버로
  return NextResponse.rewrite('https://legacy.example.com' + url.pathname);
}

// 2. Feature Flags
// 사용자별로 기능 토글

export async function middleware(request: NextRequest) {
  const user = await getCurrentUser(request);
  const flags = await getFeatureFlags(user.id);
  
  // 응답 헤더에 플래그 추가
  const response = NextResponse.next();
  response.headers.set('x-features', JSON.stringify(flags));
  return response;
}

// 3. 지능형 캐싱
// 사용자 상태에 따라 캐시 전략 변경

export async function edgeHandler(request: Request) {
  const isPremium = await checkPremiumStatus(request);
  
  if (isPremium) {
    // 프리미엄 유저는 항상 최신 데이터
    return fetch(request, { cache: 'no-cache' });
  } else {
    // 무료 유저는 캐시된 데이터
    return fetch(request, { cache: 'force-cache' });
  }
}

// 4. 봇 차단 및 보안
// 엣지에서 악의적인 요청 차단

export async function middleware(request: NextRequest) {
  const ip = request.ip;
  const userAgent = request.headers.get('user-agent');
  
  // 봇 감지
  if (isBot(userAgent) && !isGoodBot(userAgent)) {
    return new NextResponse('Forbidden', { status: 403 });
  }
  
  // Rate limiting
  const rateLimit = await checkRateLimit(ip);
  if (rateLimit.exceeded) {
    return new NextResponse('Too Many Requests', { 
      status: 429,
      headers: { 'Retry-After': '60' }
    });
  }
  
  return NextResponse.next();
}

// 서버리스 애플리케이션도 서버 위에서 돌아감
// 단지 우리가 관리하지 않을 뿐

// Lambda 함수는 실제로는:
// - EC2 인스턴스에서 실행됨
// - Container로 격리됨
// - AWS가 모든 것을 관리함

// 우리는 이것만 신경 쓰면 됨:
export async function handler(event) {
  return { statusCode: 200, body: 'Hello' };
}

// 나머지는 AWS가:
// - 인스턴스 프로비저닝
// - 스케일링
// - 로드 밸런싱
// - 장애 복구
// - 모니터링
// 모두 자동

// 서버리스가 숨기는 복잡성들

// 1. 분산 시스템의 복잡성
// - 네트워크 지연
// - 부분 실패
// - 일관성 문제

// 2. Cold Start
// - 첫 요청은 느림
// - 사용자 경험 영향

// 3. 벤더 종속
// - AWS Lambda → GCP로 이전 어려움
// - API 차이

// 4. 디버깅의 어려움
// - 로컬 재현 어려움
// - 분산 추적 필요

// 5. 비용 예측의 어려움
// - 트래픽 급증 시 비용 폭탄
// - 모니터링 필수

# 추상화의 역사

1990s: Physical Servers
       "서버 랙에 설치하고 케이블 연결"
       
2000s: Virtual Machines (AWS EC2)
       "가상화로 빠른 프로비저닝"
       
2010s: Containers (Docker)
       "격리와 이식성"
       
2014~: Serverless (Lambda)
       "서버 추상화, 코드만 작성"
       
2020~: Edge Computing
       "지리적 분산, 레이턴시 최소화"
       
미래: ?
      "더 높은 수준의 추상화"