돌미나리

웹사이트의 첫인상을 결정짓는 가장 중요한 요소 중 하나는 '로딩 속도'입니다. 구글은 이를 정량적으로 측정하기 위해 Core Web Vitals라는 지표를 도입했으며, 그중에서도 가장 큰 비중을 차지하는 것이 바로 LCP(Largest Contentful Paint)입니다.

LCP는 페이지에서 가장 큰 콘텐츠(보통 히어로 이미지나 큰 텍스트 블록)가 화면에 렌더링 되는 시간을 의미합니다. 놀랍게도 대부분의 웹사이트에서 LCP 점수를 갉아먹는 주범은 바로 '최적화되지 않은 이미지'입니다. 오늘은 Next.js가 제공하는 강력한 도구인 next/image를 활용하여 LCP 점수를 획기적으로 개선하는 전략을 심층 분석해 보겠습니다.

1. 왜 일반 <img> 태그보다 next/image인가?

전통적인 <img> 태그는 단순히 이미지를 불러올 뿐, 성능 최적화에 대한 어떠한 책임도 지지 않습니다. 반면 Next.js의 Image 컴포넌트는 다음과 같은 작업을 자동으로 수행합니다.

1. 이미지 포맷 최적화: 브라우저가 지원한다면 WebP나 AVIF 같이 용량이 훨씬 작은 최신 포맷으로 자동 변환합니다.
2. 리사이징 (Resizing): 디바이스 크기에 맞춰 최적화된 크기의 이미지를 생성하여 전송합니다. 4K 이미지를 모바일 사용자에게 전송하는 낭비를 막아줍니다.
3. Lazy Loading: 화면에 보이지 않는 이미지는 로딩을 뒤로 미뤄 초기 로딩 속도를 높입니다.
4. Placeholder 제공: 이미지가 로드되기 전 저해상도 이미지나 블러(Blur) 효과를 보여주어 사용자 경험을 개선합니다.

2. LCP 개선의 핵심: priority 속성

LCP 점수를 높이는 가장 쉽고 강력한 방법은 '가장 중요한 이미지'를 먼저 로드하는 것입니다.

보통 페이지 상단의 히어로 이미지나 배너가 LCP 요소가 됩니다. next/image는 기본적으로 레이지 로딩(Lazy Loading)이 적용되는데, LCP 요소에 레이지 로딩이 걸려 있으면 오히려 렌더링이 늦어져 LCP 점수가 나빠집니다.

// LCP 대상이 되는 히어로 이미지 예시
import Image from 'next/image';

export default function Hero() {
  return (
    <section>
      <Image
        src="/hero-banner.png"
        alt="메인 배너 이미지"
        width={1200}
        height={600}
        priority // 이 속성이 LCP 개선의 핵심입니다!
        className="object-cover"
      />
    </section>
  );
}

priority 속성을 추가하면 Next.js는 해당 이미지를 높은 우선순위(Fetch Priority)로 처리하고 프리로드(Preload) 태그를 삽입합니다. 이는 브라우저가 HTML을 파싱 할 때 해당 이미지를 가장 먼저 다운로드하도록 유도하여 LCP 시간을 단축시킵니다.

3. 레이아웃 시프트 방지와 sizes 속성 활용

이미지 로딩 중 화면이 덜컥거리는 현상인 CLS(Cumulative Layout Shift) 역시 성능 점수에 큰 영향을 줍니다. 이를 방지하려면 이미지의 비율을 미리 브라우저에 알려줘야 합니다.

3.1 정적 이미지와 고정 비율

width와 height를 명시하면 Next.js는 이미지 비율에 맞춰 공간을 미리 확보합니다. 만약 반응형 이미지를 구현해야 한다면 sizes 속성을 반드시 사용해야 합니다.

3.2 sizes 속성 최적화

sizes는 브라우저에게 "이 이미지는 뷰포트 크기에 따라 이 정도 너비를 차지할 거야"라고 미리 알려주는 힌트입니다.

<Image
  src="/product.jpg"
  alt="상품 이미지"
  fill
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
/>

위 설정은 모바일에서는 화면 꽉 차게(100vw), 태블릿에서는 절반(50vw), 데스크탑에서는 1/3(33vw) 크기의 이미지만 요청하도록 만듭니다. 불필요하게 큰 이미지를 다운로드하지 않게 되어 로딩 속도가 비약적으로 향상됩니다.

4. 이미지 포맷과 퀄리티 조정 (next.config.js)

더 극단적인 최적화를 원한다면 설정 파일을 통해 이미지 포맷을 제어할 수 있습니다. WebP보다 압축률이 높은 AVIF를 지원하도록 설정해 보세요.

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
};

또한, 기본 퀄리티(75)를 프로젝트 성격에 맞춰 조정하여 용량과 화질 사이의 균형을 맞출 수 있습니다.

5. 실무 트러블슈팅: 외부 도메인 이미지 처리

많은 실무 프로젝트(예: CMS, 쇼핑몰 가비아 이미지 서버 등)에서 외부 URL의 이미지를 가져옵니다. 이때 next/image를 쓰려면 반드시 허용된 도메인 설정을 거쳐야 합니다.

// next.config.js
images: {
  remotePatterns: [
    {
      protocol: 'https',
      hostname: 'your-cdn-server.com',
      pathname: '/images/**',
    },
  ],
},

이 설정을 통해 외부 서버의 이미지도 Next.js 서버가 대신 최적화(Optimization API)하여 사용자에게 전달할 수 있게 됩니다.

리액트(React) 생태계에서 성능 최적화는 언제나 뜨거운 감자입니다. 특히 useMemo와 useCallback은 리액트 개발자라면 반드시 마주하게 되는 도구이지만, 동시에 가장 오용되기 쉬운 도구이기도 합니다. 많은 개발자가 "성능에 좋겠지"라는 막연한 추측으로 모든 함수와 연산에 이 훅들을 적용하곤 합니다.

하지만 리액트 팀의 댄 아브라모프(Dan Abramov)를 비롯한 수많은 시니어 엔지니어들은 "섣부른 최적화(Premature Optimization)는 만악의 근원"이라고 경고합니다. 오늘은 useMemo와 useCallback의 내부 메커니즘을 낱낱이 파헤치고, 실무에서 성능 이득을 정량적으로 측정하여 적용하는 기준을 제시하겠습니다.

1. 메모이제이션(Memoization)의 배신: 공짜 점심은 없다

우선 우리가 사용하는 이 훅들이 공짜가 아니라는 점을 명확히 인지해야 합니다. useMemo나 useCallback을 호출할 때마다 리액트 내부에서는 다음과 같은 비용이 발생합니다.

1.1 메모리 비용 (Memory Overhead)

메모이제이션은 기본적으로 '메모리를 써서 시간을 사는' 행위입니다. 이전 계산 결과나 함수 참조를 메모리에 유지해야 하므로, 앱의 전체적인 메모리 사용량이 늘어납니다. 아주 미미해 보일 수 있지만, 수백 개의 컴포넌트에서 무분별하게 사용될 경우 가비지 컬렉션(GC)에 부담을 줄 수 있습니다.

1.2 비교 비용 (Comparison Overhead)

리액트는 매 렌더링마다 의존성 배열(deps)의 요소들을 하나씩 꺼내 이전 값과 비교하는 얕은 비교(Shallow Compare)를 수행합니다.

• 만약 연산 자체가 매우 단순하다면(예: 두 숫자의 합), 그 연산을 다시 하는 것보다 의존성 배열을 순회하며 비교하는 비용이 더 클 수 있습니다.

2. useMemo: 무거운 연산의 기준과 참조 동일성

useMemo는 특정 연산의 결괏값을 저장합니다. 이 훅의 적용 기준은 크게 두 가지로 나뉩니다.

2.1 연산의 복잡도 (Computational Expense)

가장 흔한 오해는 모든 배열 처리(filter, map, reduce)에 useMemo를 써야 한다는 생각입니다. 하지만 자바스크립트 엔진은 생각보다 훨씬 빠릅니다.

성능 측정 기법: performance.now() 어떤 연산이 useMemo를 쓸 만큼 무거운지 알고 싶다면, 브라우저 콘솔에서 직접 측정해 보세요.

const startTime = performance.now();
doSomethingExpensive(data);
const endTime = performance.now();
console.log(`연산 소요 시간: ${endTime - startTime}ms`);

일반적으로 1ms 이상 소요되는 연산은 useMemo를 고려할 만한 '유의미한' 비용으로 간주합니다. 만약 0.1ms 미만의 연산이라면 useMemo를 사용하는 것이 오히려 손해일 가능성이 높습니다.

2.2 참조 동일성 유지 (Referential Identity)

연산 속도보다 실무에서 더 중요한 이유는 참조값 고정입니다. 리액트에서 객체({})나 배열([])은 내용이 같아도 매번 새로운 참조를 가집니다.

• 이 값이 useEffect의 의존성 배열에 들어간다면? -> 무한 루프나 불필요한 이펙트 실행의 원인이 됩니다.
• 이 값이 React.memo로 감싸진 자식 컴포넌트의 Props로 전달된다면? -> 자식은 내용이 변하지 않았음에도 리렌더링 됩니다.

이런 경우, 연산의 복잡도와 상관없이 참조를 일관되게 유지하기 위해 useMemo를 반드시 사용해야 합니다.

3. useCallback: 함수 리렌더링과 자식 컴포넌트의 관계

useCallback은 함수 참조를 고정합니다. 많은 초보자가 "함수 생성을 방지해서 성능을 높인다"라고 생각하지만, 자바스크립트에서 함수를 새로 생성하는 비용은 현대 브라우저에서 거의 무시해도 될 수준입니다.

3.1 React.memo와의 환상적인 조합

useCallback이 효과를 발휘하는 유일한 시점은 자식 컴포넌트가 리렌더링을 방어하고 있을 때입니다.

// 자식 컴포넌트가 memo로 최적화되어 있음
const ExpensiveList = React.memo(({ onItemClick }) => {
  console.log("목록 리렌더링 중...");
  return (
    <ul>
      {/* 복잡한 리스트 아이템들 */}
    </ul>
  );
});

const Parent = () => {
  const [text, setText] = useState("");

  // 이 함수가 useCallback으로 감싸져 있지 않다면,
  // 부모가 글자를 입력할 때마다 참조가 바뀌어 ExpensiveList가 리렌더링됨
  const handleClick = useCallback((id) => {
    console.log(id);
  }, []); // 의존성이 없으므로 단 한 번만 생성됨

  return (
    <>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      <ExpensiveList onItemClick={handleClick} />
    </>
  );
};

만약 ExpensiveList가 React.memo로 감싸져 있지 않다면, 부모가 렌더링 될 때 자식도 어차피 렌더링 되므로 useCallback은 메모리만 낭비하는 꼴이 됩니다.

4. 실무 트러블슈팅: 최적화가 오히려 성능을 해치는 신호

블로그 독자들에게 실질적인 도움을 주기 위해, 최적화 훅을 제거해야 할 때의 신호를 정리해 봅니다.

1. 의존성 배열이 너무 빈번하게 바뀜: deps에 포함된 값이 렌더링마다 바뀐다면 메모이제이션은 작동하지 않고 비교 연산만 추가될 뿐입니다.
2. 기본형 데이터 타입에 사용: 문자열, 숫자, 불리언은 값을 직접 비교하므로 참조 고정이 필요 없습니다.
3. 컴포넌트 하위 계층이 단순함: 자식 컴포넌트들이 매우 가볍다면, 리렌더링 되는 비용이 최적화 로직을 타는 비용보다 저렴합니다.

5. 정량적 측정: React Profiler 활용하기

"느낌적인 느낌"으로 코드를 짜지 마세요. 리액트 개발자 도구의 Profiler 탭은 가장 강력한 무기입니다.

1. Record 버튼을 누르고 서비스의 주요 동작(클릭, 입력 등)을 수행합니다.
2. Flamegraph 차트를 확인합니다.
3. "Why did this render?" 섹션을 통해 특정 컴포넌트가 리렌더링 된 이유가 단순히 Props의 참조값 변화 때문인지 확인합니다.

만약 참조값 변화가 원인이라면, 그때가 바로 useMemo나 useCallback을 투입할 "골든 타임"입니다.

6. 결론: 유연하고 영리한 최적화 전략

프런트엔드 성능 최적화는 기술이라기보다 '트레이드오프(Trade-off)'에 가깝습니다. 가독성을 희생하고 메모리를 더 써서 렌더링 성능을 얻을 것인가, 아니면 약간의 렌더링을 허용하고 깔끔한 코드를 유지할 것인가의 선택이죠.

매번 코드를 수정할 때마다 서버에 접속해서 git pull을 받고, 빌드를 다시 하고, 프로세스를 재시작하는 과정은 번거롭고 실수하기 쉽습니다. 이러한 반복 작업을 자동화하여 개발자가 오직 '코드'에만 집중할 수 있게 해주는 기술이 바로 CI/CD입니다.

오늘은 별도의 서버 설치 없이 GitHub에서 제공하는 강력한 자동화 도구인 GitHub Actions를 사용하여, 코드를 푸시하면 내 EC2 서버에 즉시 배포되는 환경을 만들어보겠습니다.

1. CI/CD란 무엇인가?

• CI (Continuous Integration): 지속적 통합. 개발자들이 작업한 코드를 자주 병합하고, 그때마다 자동으로 테스트와 빌드를 수행하여 코드의 품질을 검증하는 과정입니다.
• CD (Continuous Deployment): 지속적 배포. 검증된 코드를 실제 운영 서버에 자동으로 반영하는 과정입니다.

2. GitHub Actions의 핵심: Workflow 파일

GitHub Actions는 프로젝트 루트의 .github/workflows/ 디렉토리에 있는 YAML 파일을 통해 동작합니다.

2.1 배포 시나리오 (Workflow)

1. 개발자가 main 브랜치에 코드를 Push합니다.
2. GitHub Actions가 가상 환경을 실행하여 코드를 **빌드(Build)**합니다.
3. 빌드가 성공하면 SSH를 통해 내 EC2 서버에 접속합니다.
4. 서버에서 최신 코드를 받고 서비스를 재시작합니다.

3. 실전! 자동 배포 스크립트 작성하기

먼저 GitHub 저장소의 Settings > Secrets and variables > Actions에서 서버 접속 정보(IP, Username, SSH Key)를 등록해야 안전합니다.

3.1 deploy.yml 예시

name: Deploy to EC2

on:
  push:
    branches: [ main ] # main 브랜치에 푸시될 때 실행

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 저장소 코드 가져오기
        uses: actions/checkout@v3

      - name: SSH 접속 후 배포 명령 실행
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd /home/ubuntu/my-project
            git pull origin main
            npm install
            pm2 restart all # Node.js 서비스 재시작 예시

4. CI/CD 도입 시 얻게 되는 효과

• 빠른 피드백: 코드를 올리자마자 빌드 오류나 테스트 실패 여부를 알 수 있습니다.
• 배포 실수 방지: 수동으로 명령어를 입력하다 발생할 수 있는 오타나 누락을 원천 차단합니다.
• 생산성 향상: 배포에 소요되는 시간을 줄여 핵심 로직 개발에 더 많은 시간을 투자할 수 있습니다.
• 안정적인 릴리즈: 정해진 절차에 따라 기계적으로 배포되므로 서비스의 안정성이 높아집니다.

5. 실무 꿀팁: Slack/Discord 알림 연동

배포가 성공했는지 실패했는지 매번 GitHub 사이트에서 확인할 수는 없습니다. GitHub Actions에 알림 스텝을 추가하면 배포 결과를 실시간으로 메신저로 받아볼 수 있습니다.

6. 결론: 자동화는 선택이 아닌 필수입니다

스무 차례에 걸쳐 리눅스 서버 기초부터 보안, 모니터링, 그리고 자동 배포까지 달려왔습니다. CI/CD 구축은 이 모든 여정의 마침표이자, 진정한 엔지니어로 거듭나는 시작점입니다.

서버를 운영하다 보면 "지금 CPU 점유율이 얼마지?", "어제 밤에 트래픽이 얼마나 몰렸을까?"와 같은 질문에 답해야 할 때가 많습니다. 매번 터미널에 접속해 htop을 입력하는 것은 번거로울 뿐만 아니라 과거의 데이터를 추적하기도 어렵습니다.

오늘은 오픈소스 모니터링의 표준이라 불리는 Prometheus(프로메테우스)와 시각화 도구인 Grafana(그라파나)를 연동하여, 누구나 한눈에 이해할 수 있는 멋진 서버 대시보드를 만드는 방법을 알아보겠습니다.

1. 모니터링 시스템의 두 주인공

1.1 Prometheus (데이터 수집기)

서버의 메트릭(Metric, 수치 데이터)을 수집하고 저장하는 역할을 합니다. "서버의 현재 CPU는 20%다"라는 정보를 일정 시간마다 가져와서 자신의 데이터베이스에 쌓아둡니다.

1.2 Grafana (데이터 시각화)

Prometheus가 수집한 딱딱한 숫자 데이터를 가져와 예쁜 그래프, 게이지, 차트로 그려주는 도구입니다. 커스터마이징이 매우 자유로워 나만의 관제 센터를 만들 수 있습니다.

2. 데이터의 원천: Node Exporter 설치

Prometheus가 서버의 하드웨어 정보를 읽어가려면, 서버 안에 정보를 내보내 주는 Node Exporter라는 작은 프로그램이 떠 있어야 합니다.

1. Node Exporter 설치:
2. Bash

    

   sudo apt update
   sudo apt install prometheus-node-exporter -y
   

3. 이제 9100번 포트를 통해 서버의 실시간 상태가 텍스트 형태로 출력되기 시작합니다.

3. Prometheus 및 Grafana 구축 (Docker 활용)

설치 과정을 단순화하기 위해 Docker Compose를 사용하는 것이 가장 효율적입니다.

3.1 docker-compose.yml 설정 예시

version: '3.8'
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

4. Grafana에서 대시보드 구성하기

설치가 완료되었다면 http://서버IP:3000으로 접속합니다. (기본 계정: admin / admin)

4.1 데이터 소스 연결

• Configuration > Data Sources에서 Prometheus를 선택합니다.
• URL에 http://prometheus:9090을 입력하고 저장합니다.

4.2 대시보드 템플릿 가져오기 (꿀팁)

처음부터 그래프를 하나씩 그리는 것은 매우 어렵습니다. Grafana 커뮤니티에는 이미 잘 만들어진 템플릿이 많습니다.

1. Create > Import로 이동합니다.
2. 유명한 Linux 모니터링 템플릿 번호인 1860을 입력하고 로드합니다.
3. 순식간에 CPU 사용량, 메모리, 디스크 I/O, 네트워크 트래픽이 포함된 전문가용 대시보드가 완성됩니다!

5. 모니터링 시스템 도입의 효과

• 장애 선제 대응: 트래픽 증가 추이를 보고 서버 증설 시점을 미리 파악할 수 있습니다.
• 원인 분석: 장애가 발생했던 시점의 그래프를 되돌려 보며 무엇이 문제였는지 명확히 짚어낼 수 있습니다.
• 보고 및 공유: 복잡한 로그 대신 시각화된 그래프를 통해 팀원이나 클라이언트에게 시스템 상태를 직관적으로 설명할 수 있습니다.

6. 결론: 데이터 기반의 서버 운영

"측정할 수 없으면 관리할 수 없다"는 경영학의 격언은 서버 운영에도 그대로 적용됩니다. Prometheus와 Grafana는 여러분의 서버를 투명하게 들여다볼 수 있는 강력한 돋보기가 되어줄 것입니다.

공들여 만든 웹 서비스가 출시 당일, 예상보다 많은 사용자가 몰려 서버가 다운된다면 그보다 아찔한 상황은 없을 것입니다. 서버가 한 번에 얼마나 많은 요청을 처리할 수 있는지, 어느 정도의 동시 접속자 수에서 속도가 느려지는지 미리 파악하는 과정이 바로 **부하 테스트(Load Testing)**입니다.

오늘은 별도의 복잡한 설치 없이 Node.js 환경에서 간편하게 사용할 수 있는 부하 테스트 도구인 Artillery를 활용하여 내 서버의 체력을 측정하는 방법을 알아보겠습니다.

1. 부하 테스트(Load Testing)는 왜 필요한가?

부하 테스트는 단순히 서버를 괴롭히는 것이 아니라, 시스템의 **병목 지점(Bottleneck)**을 찾아내기 위해 수행합니다.

• 최대 수용 인원 파악: 현재 서버 사양(EC2 인스턴스 등)에서 동시 접속자 몇 명까지 안정적인지 확인합니다.
• 리소스 부족 지점 발견: CPU가 먼저 차오르는지, 메모리가 부족한지, 혹은 DB 연결 개수가 모자란지 파악합니다.
• Auto Scaling 기준 수립: 서버가 자동으로 늘어나야 하는 기준(CPU 70% 등)을 정하는 근거가 됩니다.

2. Artillery 설치 및 첫 테스트 시작

Artillery는 YAML 파일로 테스트 시나리오를 작성할 수 있어 매우 직관적입니다.

2.1 설치하기

npm을 통해 전역으로 설치하거나 npx로 바로 실행할 수 있습니다.

npm install -g artillery

2.2 간단한 명령어로 테스트하기

가장 기본적인 테스트는 명령어 한 줄로 가능합니다. 아래는 10명의 가상 사용자가 1초에 1번씩 총 100번의 요청을 보내는 예시입니다.

artillery quick --count 10 -n 100 https://your-api-domain.com

3. 시나리오 기반의 정밀 테스트 (YAML 설정)

실제 서비스와 유사한 환경을 만들기 위해 script.yml 파일을 작성하여 테스트를 수행하는 것이 좋습니다.

config:
  target: "https://api.example.com"
  phases:
    - duration: 60      # 60초 동안 테스트 진행
      arrivalRate: 5    # 초당 5명의 가상 사용자 투입 (평상시 트래픽)
    - duration: 120
      arrivalRate: 5
      rampTo: 50        # 2분 동안 초당 접속자를 50명까지 점진적으로 증가 (피크 타임)
  
scenarios:
  - name: "메인 페이지 접속 및 상품 상세 조회"
    flow:
      - get:
          url: "/"
      - think: 1        # 1초 대기 (사용자 행동 모의)
      - get:
          url: "/products/1"

3.3 테스트 실행 및 리포트 생성

artillery run -o report.json script.yml
# 결과를 HTML 리포트로 변환
artillery report report.json

4. 테스트 결과 해석하기 (지표 읽는 법)

테스트가 끝나면 터미널이나 HTML 리포트에 여러 수치가 나타납니다. 무엇을 중요하게 봐야 할까요?

• Scenarios created/completed: 생성된 가상 사용자가 요청을 모두 마치고 성공적으로 종료되었는지 확인합니다.
• RPS (Requests Per Second): 초당 처리량입니다. 서버가 초당 몇 개의 요청을 소화하는지 보여줍니다.
• Latency (p95, p99): 응답 속도입니다. p95가 500ms라면 전체 사용자 중 95%가 0.5초 이내에 응답을 받았음을 의미합니다. 이 수치가 급격히 올라가면 서버가 힘겨워하고 있다는 신호입니다.
• HTTP 2xx vs 5xx: 500번대 에러가 발생하기 시작하는 시점이 바로 내 서버의 한계치입니다.

5. 결론: 부하 테스트는 '신뢰'를 만드는 과정입니다

부하 테스트를 마쳤다면, 이제 "우리 서버는 동시 접속자 500명까지는 응답 속도 0.3초를 유지할 수 있습니다"라고 자신 있게 말할 수 있습니다. 수치화된 데이터는 인프라 증설이나 코드 최적화의 명확한 기준이 됩니다.

내 웹사이트의 서버가 한국에 있다면, 미국이나 유럽에 있는 사용자는 사이트 로딩 속도가 현저히 느려질 수밖에 없습니다. 물리적인 거리가 멀수록 데이터가 오가는 시간이 길어지기 때문입니다. 이러한 지연 시간(Latency)을 획기적으로 줄여주는 마법 같은 기술이 바로 **CDN(Content Delivery Network)**입니다.

오늘은 AWS의 강력한 CDN 서비스인 CloudFront를 도입하여 전 세계 어디서나 쾌적한 속도를 보장하고, 서버의 부하를 줄이는 캐싱 전략을 상세히 알아보겠습니다.

1. CloudFront(CDN)란 무엇인가?

CloudFront는 전 세계 곳곳에 흩어져 있는 **엣지 로케이션(Edge Location)**이라는 캐시 서버망을 활용합니다. 사용자가 웹사이트에 접속하면, 한국 서버까지 올 필요 없이 가장 가까운 엣지 로케이션에서 미리 복사해둔 콘텐츠(이미지, JS, CSS 등)를 전달합니다.

1.1 CDN 도입의 주요 이점

• 로딩 속도 개선: 사용자 근처에서 데이터를 전달하므로 물리적 거리로 인한 지연이 사라집니다.
• 원본 서버 부하 감소: 대부분의 요청을 CDN이 처리하므로 실제 EC2 서버의 CPU와 대역폭 사용량이 줄어듭니다.
• 보안 강화: AWS Shield와 연동되어 DDoS 공격을 1차적으로 방어하며, SSL 인증서 적용이 매우 간편합니다.

2. CloudFront 배포(Distribution) 생성하기

이제 내 EC2 서버나 S3 버킷을 원본(Origin)으로 설정하여 CloudFront를 구축해 보겠습니다.

1. AWS 콘솔에서 CloudFront 서비스로 접속합니다.
2. [배포 생성] 버튼을 클릭합니다.
3. 원본 도메인(Origin Domain): 내 EC2의 도메인 주소나 S3 버킷 주소를 선택합니다.
4. 뷰어 프로토콜 정책: 보안을 위해 Redirect HTTP to HTTPS를 권장합니다.
5. 캐시 설정: 기본값인 CachingOptimized를 선택하면 AWS에서 권장하는 최적의 캐싱 정책이 적용됩니다.

3. 핵심 캐싱 전략: TTL(Time To Live) 관리

CDN의 핵심은 **"얼마나 오랫동안 데이터를 보관할 것인가?"**입니다. 이를 제어하는 수치가 바로 TTL입니다.

• 정적 콘텐츠 (이미지, 폰트 등): 내용이 거의 바뀌지 않으므로 TTL을 길게(예: 1년) 설정하여 캐시 효율을 극대화합니다.
• 동적 콘텐츠 (HTML, JSON 등): 실시간 데이터가 중요하므로 TTL을 짧게 설정하거나, 캐싱을 아예 하지 않도록 설정합니다.

3.1 캐시 무효화 (Invalidation)

만약 이미지를 수정했는데 CDN에 이전 이미지가 남아있다면 어떻게 할까요? 이때 사용하는 기능이 **'무효화(Invalidation)'**입니다. 특정 경로(예: /images/*)를 무효화하면 엣지 로케이션의 데이터를 즉시 삭제하고 원본에서 새 데이터를 가져오게 합니다.

4. Route 53과 CloudFront 연결하기

이제 내가 가진 멋진 도메인으로 접속했을 때 CDN을 거치도록 설정해야 합니다.

1. Route 53 호스팅 영역으로 이동합니다.
2. 기존의 A 레코드를 수정하거나 새로 만듭니다.
3. 별칭(Alias) 스위치를 켭니다.
4. 트래픽 라우팅 대상: CloudFront 배포에 대한 별칭을 선택하고 생성한 배포 주소를 지정합니다.

5. 결론: 진정한 글로벌 서비스로의 진화

CloudFront 도입은 웹 서비스의 품질을 한 단계 격상시키는 중요한 결정입니다. 단순히 '속도'뿐만 아니라 '비용 절감'과 '보안'까지 챙길 수 있는 일석삼조의 전략이기 때문입니다.