인프라 입문 & 로드맵를 실무 흐름으로 이해하기
웹 서비스 인프라를 처음 배우는 분을 위한 출발점입니다. 사용자의 요청이 서버에 도달하기까지 거치는 DNS·로드밸런서·리버스 프록시·캐시의 역할, 트래픽이 늘어날 때 시스템을 확장하는 방법, Nginx와 Redis가 아키텍처에서 맡는 자리, 그리고 단계별 학습 로드맵을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
웹 서비스 인프라를 처음 배우는 분을 위한 출발점입니다. 사용자의 요청이 서버에 도달하기까지 거치는 DNS·로드밸런서·리버스 프록시·캐시의 역할, 트래픽이 늘어날 때 시스템을 확장하는 방법, Nginx와 Redis가 아키텍처에서 맡는 자리, 그리고 단계별 학습 로드맵을 정리합니다.
웹 서비스 인프라를 처음 배우는 분을 위한 출발점입니다. 사용자의 요청이 서버에 도달하기까지 거치는 DNS·로드밸런서·리버스 프록시·캐시의 역할, 트래픽이 늘어날 때 시스템을 확장하는 방법, Nginx와 Redis가 아키텍처에서 맡는 자리, 그리고 단계별 학습 로드맵을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
설치 명령을 외우기보다 트래픽, 런타임, 관측, 장애 대응이 어떤 순서로 이어지는지 파악합니다.
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 인프라 입문 & 로드맵를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
인프라 입문 & 로드맵를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
요청이 지나가는 길은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
https://shop.example.com/products/42를 열면 요청은 여러 계층을 거칩니다. 각 계층은 요청을 빨리 처리해서 돌려보내거나, 다음 계층으로 전달합니다. 앞쪽 계층에서 처리될수록 빠르고 비용이 적게 듭니다.| 순서 | 계층 | 여기서 끝날 수 있는 경우 |
|---|---|---|
| 1 | 브라우저 캐시 | 이미 받은 이미지·CSS는 다시 요청하지 않음 |
| 2 | DNS | - |
| 3 | CDN (엣지) | 정적 파일·캐시 가능한 페이지는 엣지에서 즉시 응답 |
| 4 | Nginx (리버스 프록시) | 정적 파일 직접 응답, 요청 제한 초과 시 차단 |
| 5 | 애플리케이션 서버 | - |
| 6 | Redis (캐시) | 캐시에 있으면 DB 조회 없이 응답 |
| 7 | 데이터베이스 | 최종 저장소 — 가장 느리고 비싼 계층 |
리버스 프록시와 로드밸런서: Nginx의 자리은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| Nginx의 역할 | 설명 |
|---|---|
| TLS 종료 | HTTPS 암호화·복호화를 대신 처리해 앱 서버 부담 감소 |
| 로드밸런싱 | 여러 앱 서버로 요청 분배 (라운드로빈, 최소 연결 등) |
| 정적 파일 서빙 | 이미지·JS·CSS를 앱 서버 거치지 않고 직접 응답 |
| 요청 제한 | IP별 초당 요청 수 제한으로 과도한 요청·공격 완화 |
| 경로 라우팅 | /api는 백엔드로, /는 프론트엔드로 분기 |
| 압축·캐싱 | gzip 압축, 응답 캐시 |
여기서는 첫 Nginx 설정: HTTPS + 로드밸런싱을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
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;
}
}캐시 전략: Redis가 빠른 이유은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 활용 패턴 | 예시 | 핵심 포인트 |
|---|---|---|
| 조회 캐시 (Cache-Aside) | 상품 상세, 인기 게시글 | 캐시 없으면 DB 조회 후 저장, TTL 설정 |
| 세션 저장소 | 로그인 세션 | 여러 서버가 세션 공유 |
| 요청 제한 카운터 | API 초당 호출 수 제한 | INCR + EXPIRE 원자적 연산 |
| 순위표 | 실시간 랭킹 | Sorted Set |
| 분산 락 | 중복 결제·중복 발급 방지 | SET NX + 만료 시간 |
| 메시지·스트림 | 간단한 작업 큐, 이벤트 | List, Pub/Sub, Stream |
확장 전략: 트래픽이 10배가 되면은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 전략 | 방법 | 장점 | 한계 |
|---|---|---|---|
| 수직 확장 (Scale-up) | 서버 사양 올리기 | 코드 변경 없음, 가장 쉬움 | 비용 급증, 상한 존재, 단일 장애점 |
| 수평 확장 (Scale-out) | 서버 대수 늘리기 + 로드밸런서 | 이론상 무한 확장, 장애 격리 | 앱이 무상태(stateless)여야 함 |
| 캐싱 | Redis·CDN으로 DB 요청 감소 | 적은 비용으로 큰 효과 | 데이터 최신성 관리 필요 |
| 읽기 복제본 | DB 읽기를 복제본으로 분산 | 읽기 중심 서비스에 효과적 | 복제 지연 |
| 비동기 처리 | 오래 걸리는 작업을 큐로 분리 | 응답 속도 개선 | 처리 결과 추적 필요 |
시작 전 준비물은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 영역 | 무엇을 | 어느 정도 |
|---|---|---|
| Linux | 패키지 설치, 서비스 관리(systemctl), 로그 확인 | Linux 기본 |
| 네트워크 | IP, 포트, DNS, HTTP 헤더, TLS 인증서 | 개념 이해 |
| Docker | 컨테이너로 Nginx·Redis 실행 | Docker 기본 |
| 웹 앱 1개 | 프록시 뒤에 둘 간단한 API 서버 | Backend 로드맵 1단계 수준 |
단계별 로드맵은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 목표 | 학습 내용 | 가이드 | 완료 체크 |
|---|---|---|---|---|
| 0. 기초 | 서버와 네트워크 | Linux 명령, 포트, DNS, HTTP, TLS | Linux | curl로 요청·응답 헤더 분석 |
| 1. 웹 서버 | Nginx로 서비스 노출 | 정적 파일, server/location 블록, 로그 | Nginx | 정적 사이트 배포 |
| 2. 리버스 프록시 | 앱 서버 앞단 구성 | proxy_pass, 헤더 전달, HTTPS(Let's Encrypt) | Nginx | HTTPS로 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시간 기준은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 주차 | 주제 | 결과물 |
|---|---|---|
| 1주 | 네트워크·HTTP·TLS 기초 | curl·개발자 도구로 요청 흐름 분석 노트 |
| 2주 | Nginx 웹 서버 + 리버스 프록시 | HTTPS API 서비스 |
| 3주 | 로드밸런싱 + 요청 제한 | Docker Compose: Nginx + 앱 2대 |
| 4주 | Redis 기본 + 캐시 | 상품 조회 캐시 + 성능 비교 |
| 5주 | Redis 세션·락·Rate Limit | 세션 공유 + 선착순 발급 |
| 6주 | 부하 테스트 + 정리 | k6 테스트 결과 + 아키텍처 다이어그램 |
인프라 입문자가 자주 하는 실수은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 실수 | 문제 | 대신 이렇게 |
|---|---|---|
| 프록시 뒤에서 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 | 전 세계 엣지 서버에 콘텐츠를 캐시해 가까운 곳에서 제공하는 네트워크 |