본문으로 건너뛰기
AIDevOps
  • Learn
  • Learning Paths
  • Practice
  • Open Source
  • Books
  • Engineering

    AI DevOpsAI 서비스 개발·운영 전체 지도LLMOpsLLM 배포·평가·관측실전 프로젝트AI Agent 프로젝트 실습

    Knowledge

    Docs기술 문서 모음Blog엔지니어링 아티클Plogger개발 기록 피드

    Validate

    Certification3단계 역량 인증 · 준비 중
AI Models
LlamaMistralGemmaDeepSeekQwen
🧱 인프라
인프라 입문 & 로드맵NginxRedis
🤖 AI 실전 개발
AI 실전 입문 & 로드맵Hugging FaceLangChainLlamaIndexLLMOps|LangGraphMCPMulti-AgentAgent Evaluation
🧠 AI Core
AI 입문 & 로드맵ML FundamentalsLLM Fundamentals|Python AIC++|PyTorchTensorFlowJAX
🧠 AI Agent 개발
금융 AI AgentLLM API 서버주식 투자 AgentAIOps AI Agent교육 AI Agent코딩 AI Agent
🌱 Spring Cloud
Spring 입문 & 로드맵Spring Cloud GatewaySpring BootJava|Spring AISpring SecuritySpring BatchSpring JPA
🐳 DevOps
DevOps 입문 & 로드맵LinuxDockerCI/CD|Kubernetes 기본K8s 심화/실무PrometheusGrafana
☁️ 클라우드
클라우드 입문 & 로드맵AWSGCPAzureNCPCloudflare
🎨 Frontend
Frontend 입문 & 로드맵JavaScriptTypeScript|ReactNext.js|VueNuxt
📱 Mobile
Mobile 입문 & 로드맵KotlinAndroidFlutter
⚙️ Backend
Backend 입문 & 로드맵Python 기본FastAPIDjangoFlask|CGoGinNode.js
💾 Database
DB 입문 & 로드맵공통 SQLOracleMySQLPostgreSQL|MongoDB벡터 DB
🧪 검증
k6JMeternGrinder
AIDevOps

Engineering AI. From Code to Production.
AI와 AI Agent를 개발하고 운영하기 위한 엔지니어링 학습 플랫폼

Learn

  • 전체 가이드
  • Learning Paths
  • Practice
  • Books

Resources

  • AI DevOps
  • LLMOps
  • 실전 프로젝트
  • Docs
  • Blog
  • Plogger
  • Open Source
  • Certification (준비 중)

Start Here

  • AI Core 로드맵
  • AI 실전 개발 로드맵
  • Spring Cloud 로드맵
  • DevOps 로드맵
  • 인프라 로드맵

 

  • 클라우드 로드맵
  • Frontend 로드맵
  • Mobile 로드맵
  • Backend 로드맵
  • Database 로드맵
© 2026 AI DevOps Korea. All rights reserved.
이용약관개인정보처리방침Sitemaptestforge.kr
  1. Home
  2. Learn
  3. 인프라
  4. 인프라 입문 & 로드맵
웹 인프라 입문자를 위한 첫 가이드

🧭 인프라 입문 & 로드맵 완전 가이드

Visitors

웹 서비스 인프라를 처음 배우는 분을 위한 출발점입니다. 사용자의 요청이 서버에 도달하기까지 거치는 DNS·로드밸런서·리버스 프록시·캐시의 역할, 트래픽이 늘어날 때 시스템을 확장하는 방법, Nginx와 Redis가 아키텍처에서 맡는 자리, 그리고 단계별 학습 로드맵을 정리합니다.

  • Beginner · 입문
  • 업데이트 2026.09.24
  • 약 9분 읽기
  • 11개 섹션
  • 예제 코드 1개
🧭
웹 인프라 큰 그림요청 흐름 이해Nginx·Redis의 역할확장 전략 기초인프라 학습 순서

관련 프레임워크 & 개발환경

🌐Nginx→🔴Redis→🐧Linux→🐳Docker→

목차

0 / 13
  1. 가이드 사용법
  2. 구조 다이어그램
  3. 인프라란 무엇인가
  4. 요청이 지나가는 길
  5. 리버스 프록시와 로드밸런서
  6. 첫 Nginx 설정
  7. 캐시 전략
  8. 확장 전략
  9. 시작 전 준비물
  10. 단계별 로드맵
  11. 6주 학습 플랜
  12. 자주 하는 실수
  13. 핵심 용어 사전
목차 13개 섹션
  1. 가이드 사용법
  2. 구조 다이어그램
  3. 인프라란 무엇인가
  4. 요청이 지나가는 길
  5. 리버스 프록시와 로드밸런서
  6. 첫 Nginx 설정
  7. 캐시 전략
  8. 확장 전략
  9. 시작 전 준비물
  10. 단계별 로드맵
  11. 6주 학습 플랜
  12. 자주 하는 실수
  13. 핵심 용어 사전

가이드 사용법

읽는 방향

인프라 입문 & 로드맵를 실무 흐름으로 이해하기

웹 서비스 인프라를 처음 배우는 분을 위한 출발점입니다. 사용자의 요청이 서버에 도달하기까지 거치는 DNS·로드밸런서·리버스 프록시·캐시의 역할, 트래픽이 늘어날 때 시스템을 확장하는 방법, Nginx와 Redis가 아키텍처에서 맡는 자리, 그리고 단계별 학습 로드맵을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.

핵심 관점

인프라 / 운영

설치 명령을 외우기보다 트래픽, 런타임, 관측, 장애 대응이 어떤 순서로 이어지는지 파악합니다.

웹 인프라 큰 그림요청 흐름 이해Nginx·Redis의 역할확장 전략 기초인프라 학습 순서

구조 다이어그램

글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 인프라 입문 & 로드맵를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.

학습 흐름

다이어그램 렌더링 중…

아키텍처 관점

다이어그램 렌더링 중…

인프라란 무엇인가

인프라 입문 & 로드맵를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.

인프라(Infrastructure)는 애플리케이션이 실행되고, 사용자와 연결되고, 빠르고 안정적으로 응답하도록 받쳐주는 모든 기반을 말합니다. 서버, 네트워크, 로드밸런서, 캐시, 저장소, 인증서가 여기에 포함됩니다.

애플리케이션 코드가 아무리 좋아도 인프라가 약하면 트래픽이 몰릴 때 서비스가 멈춥니다. 반대로 잘 설계된 인프라는 같은 코드로도 수십 배의 사용자를 감당하게 해줍니다. 이 카테고리는 그중 모든 웹 서비스에 거의 반드시 등장하는 두 가지 — Nginx(트래픽의 관문)와 Redis(속도의 핵심)를 다룹니다.
인프라 요소역할대표 기술
DNS도메인 이름 → IP 주소 변환Route 53, Cloudflare DNS
CDN정적 파일을 사용자 가까운 곳에서 제공Cloudflare, CloudFront
로드밸런서 / 리버스 프록시요청을 여러 서버로 분배, TLS 처리Nginx, ALB
애플리케이션 서버비즈니스 로직 실행FastAPI, Spring Boot, Node.js
캐시자주 쓰는 데이터를 메모리에 보관Redis
데이터베이스영구 저장PostgreSQL, MySQL

요청이 지나가는 길

요청이 지나가는 길은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

사용자가 https://shop.example.com/products/42를 열면 요청은 여러 계층을 거칩니다. 각 계층은 요청을 빨리 처리해서 돌려보내거나, 다음 계층으로 전달합니다. 앞쪽 계층에서 처리될수록 빠르고 비용이 적게 듭니다.
순서계층여기서 끝날 수 있는 경우
1브라우저 캐시이미 받은 이미지·CSS는 다시 요청하지 않음
2DNS-
3CDN (엣지)정적 파일·캐시 가능한 페이지는 엣지에서 즉시 응답
4Nginx (리버스 프록시)정적 파일 직접 응답, 요청 제한 초과 시 차단
5애플리케이션 서버-
6Redis (캐시)캐시에 있으면 DB 조회 없이 응답
7데이터베이스최종 저장소 — 가장 느리고 비싼 계층

Tip

성능 개선의 기본 원칙은 "요청을 가능한 한 앞쪽 계층에서 끝내는 것"입니다. DB까지 가는 요청을 줄일수록 시스템은 빨라지고 저렴해집니다.

리버스 프록시와 로드밸런서: Nginx의 자리

리버스 프록시와 로드밸런서: Nginx의 자리은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

리버스 프록시는 사용자와 애플리케이션 서버 사이에 서서 요청을 대신 받아 전달하는 서버입니다. 사용자는 뒤에 서버가 몇 대인지, 어떤 언어로 만들어졌는지 알 수 없습니다. Nginx는 가장 널리 쓰이는 리버스 프록시이자 웹 서버입니다.
Nginx의 역할설명
TLS 종료HTTPS 암호화·복호화를 대신 처리해 앱 서버 부담 감소
로드밸런싱여러 앱 서버로 요청 분배 (라운드로빈, 최소 연결 등)
정적 파일 서빙이미지·JS·CSS를 앱 서버 거치지 않고 직접 응답
요청 제한IP별 초당 요청 수 제한으로 과도한 요청·공격 완화
경로 라우팅/api는 백엔드로, /는 프론트엔드로 분기
압축·캐싱gzip 압축, 응답 캐시

첫 Nginx 설정: HTTPS + 로드밸런싱

여기서는 첫 Nginx 설정: HTTPS + 로드밸런싱을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.

아래 설정은 HTTPS로 들어온 요청을 두 대의 앱 서버로 분배하고, 정적 파일은 Nginx가 직접 응답합니다. 실무 Nginx 설정의 대부분이 이 구조의 변형입니다.
/etc/nginx/conf.d/app.confNGINX
upstream app_servers {
    least_conn;                       # 연결 수가 가장 적은 서버로
    server 10.0.0.11:8000;
    server 10.0.0.12:8000;
}

server {
    listen 443 ssl;
    server_name shop.example.com;

    ssl_certificate     /etc/letsencrypt/live/shop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shop.example.com/privkey.pem;

    location /static/ {               # 정적 파일은 Nginx가 직접
        root /var/www;
        expires 7d;
    }

    location / {                      # 나머지는 앱 서버로 전달
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Tip

설정을 바꾼 뒤에는 항상 nginx -t로 문법을 검사하고 nginx -s reload로 무중단 반영하세요. restart는 기존 연결을 끊습니다.

캐시 전략: Redis가 빠른 이유

캐시 전략: Redis가 빠른 이유은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

Redis는 데이터를 메모리에 저장하는 키-값 저장소입니다. 디스크 기반 DB보다 수십~수백 배 빠르기 때문에 자주 읽지만 자주 바뀌지 않는 데이터를 보관하기에 적합합니다. 단, 메모리는 비싸고 휘발성이 있으므로 "원본은 DB, 사본은 Redis"가 기본 원칙입니다.
활용 패턴예시핵심 포인트
조회 캐시 (Cache-Aside)상품 상세, 인기 게시글캐시 없으면 DB 조회 후 저장, TTL 설정
세션 저장소로그인 세션여러 서버가 세션 공유
요청 제한 카운터API 초당 호출 수 제한INCR + EXPIRE 원자적 연산
순위표실시간 랭킹Sorted Set
분산 락중복 결제·중복 발급 방지SET NX + 만료 시간
메시지·스트림간단한 작업 큐, 이벤트List, Pub/Sub, Stream

Tip

캐시에서 가장 어려운 문제는 "언제 지우느냐(무효화)"입니다. 처음에는 짧은 TTL로 시작하고, 데이터가 바뀔 때 해당 키를 삭제하는 방식을 함께 쓰세요.

확장 전략: 트래픽이 10배가 되면

확장 전략: 트래픽이 10배가 되면은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

수평 확장의 전제 조건은 애플리케이션 서버가 상태를 갖지 않는 것입니다. 세션이나 업로드 파일을 서버 메모리·디스크에 두면 요청이 다른 서버로 갈 때 사라집니다. 그래서 세션은 Redis로, 파일은 오브젝트 스토리지로 옮기는 것이 확장의 첫걸음입니다.
전략방법장점한계
수직 확장 (Scale-up)서버 사양 올리기코드 변경 없음, 가장 쉬움비용 급증, 상한 존재, 단일 장애점
수평 확장 (Scale-out)서버 대수 늘리기 + 로드밸런서이론상 무한 확장, 장애 격리앱이 무상태(stateless)여야 함
캐싱Redis·CDN으로 DB 요청 감소적은 비용으로 큰 효과데이터 최신성 관리 필요
읽기 복제본DB 읽기를 복제본으로 분산읽기 중심 서비스에 효과적복제 지연
비동기 처리오래 걸리는 작업을 큐로 분리응답 속도 개선처리 결과 추적 필요

시작 전 준비물

시작 전 준비물은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

Nginx와 Redis는 Docker로 몇 초 만에 띄울 수 있어 실습 환경 준비가 매우 쉽습니다.
영역무엇을어느 정도
Linux패키지 설치, 서비스 관리(systemctl), 로그 확인Linux 기본
네트워크IP, 포트, DNS, HTTP 헤더, TLS 인증서개념 이해
Docker컨테이너로 Nginx·Redis 실행Docker 기본
웹 앱 1개프록시 뒤에 둘 간단한 API 서버Backend 로드맵 1단계 수준

단계별 로드맵

단계별 로드맵은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

단계목표학습 내용가이드완료 체크
0. 기초서버와 네트워크Linux 명령, 포트, DNS, HTTP, TLSLinuxcurl로 요청·응답 헤더 분석
1. 웹 서버Nginx로 서비스 노출정적 파일, server/location 블록, 로그Nginx정적 사이트 배포
2. 리버스 프록시앱 서버 앞단 구성proxy_pass, 헤더 전달, HTTPS(Let's Encrypt)NginxHTTPS로 API 서비스
3. 로드밸런싱여러 서버로 분산upstream, 분배 알고리즘, 헬스체크, 요청 제한Nginx앱 서버 2대 분산 + 1대 장애 테스트
4. 캐시Redis 도입자료구조, TTL, Cache-Aside, 세션 저장Redis캐시 적용 전후 응답 시간 비교
5. 고급 Redis동시성·안정성분산 락, Rate Limit, 영속성(RDB/AOF), 복제Redis선착순 쿠폰 중복 발급 방지
6. 검증한계 측정부하 테스트, 병목 분석k6처리량(RPS) 한계 리포트
7. 다음 단계운영 자동화로 확장컨테이너 오케스트레이션, 클라우드DevOps 로드맵, 클라우드 로드맵-

6주 학습 플랜: 하루 1시간 기준

6주 학습 플랜: 하루 1시간 기준은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

마지막 주의 부하 테스트는 꼭 해보세요. 캐시와 로드밸런싱이 실제로 얼마나 효과가 있는지 숫자로 확인하는 경험이 인프라 감각을 만듭니다.
주차주제결과물
1주네트워크·HTTP·TLS 기초curl·개발자 도구로 요청 흐름 분석 노트
2주Nginx 웹 서버 + 리버스 프록시HTTPS API 서비스
3주로드밸런싱 + 요청 제한Docker Compose: Nginx + 앱 2대
4주Redis 기본 + 캐시상품 조회 캐시 + 성능 비교
5주Redis 세션·락·Rate Limit세션 공유 + 선착순 발급
6주부하 테스트 + 정리k6 테스트 결과 + 아키텍처 다이어그램

인프라 입문자가 자주 하는 실수

인프라 입문자가 자주 하는 실수은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

Redis는 단일 스레드로 명령을 처리하므로, 오래 걸리는 명령 하나가 모든 요청을 막을 수 있다는 점을 항상 기억하세요.
실수문제대신 이렇게
프록시 뒤에서 X-Forwarded-* 헤더 누락앱이 모든 요청을 프록시 IP·HTTP로 인식proxy_set_header로 원본 정보 전달
설정 변경 후 문법 검사 없이 재시작서비스 전체 중단nginx -t 후 reload
Redis를 원본 저장소로 사용재시작·장애 시 데이터 유실원본은 DB, Redis는 캐시·보조
TTL 없는 캐시 키메모리 고갈, 오래된 데이터모든 캐시 키에 만료 시간
KEYS * 명령 사용대량 키에서 Redis 전체가 멈춤SCAN 사용
Redis를 인증 없이 외부에 노출데이터 탈취, 서버 장악내부망 전용 + 비밀번호/ACL

핵심 용어 사전

핵심 용어 사전은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.

용어한 줄 설명
리버스 프록시서버 앞에서 요청을 대신 받아 뒤의 서버로 전달하는 서버
업스트림 (Upstream)Nginx가 요청을 전달하는 뒤쪽 서버 그룹
TLS 종료HTTPS 암호화를 프록시에서 풀고 내부는 HTTP로 전달하는 구성
TTL캐시 데이터가 유효한 시간
캐시 적중률요청 중 캐시에서 바로 응답한 비율
캐시 스탬피드캐시가 동시에 만료되어 요청이 DB로 한꺼번에 몰리는 현상
무상태 (Stateless)서버가 요청 간 상태를 저장하지 않아 어떤 서버든 처리 가능한 성질
헬스체크서버가 정상인지 주기적으로 확인하는 요청
Rate Limiting일정 시간 동안 허용하는 요청 수를 제한하는 기법
CDN전 세계 엣지 서버에 콘텐츠를 캐시해 가까운 곳에서 제공하는 네트워크

Tip

다음 단계는 Nginx 가이드입니다. 정적 파일 서빙부터 리버스 프록시까지 직접 설정해보세요.

다음 가이드 →Nginx