네트워크 기초 7편 — 로드 밸런서와 프록시

Table of contents

• 서버 한 대로는 부족해질 때
• 프록시 — 중간에 끼어 있는 무언가
• L4와 L7 — 어느 계층을 보는가
• 분배 알고리즘 — 누구에게 다음 요청을 줄 것인가
  • 라운드 로빈(round-robin)
  • 가중치 라운드 로빈(weighted round-robin)
  • 최소 연결(least-connections)
  • 소스 IP 해시(ip-hash)
• 세션 어피니티 — 같은 사용자는 같은 서버로
• 헬스 체크 — 죽은 서버는 빼야 한다
• TLS 종단 — 암호화를 어디서 벗기는가
• CDN — 로드 밸런서의 먼 친척
• 실무 제품들 — 무엇이 어디에 쓰이는가
  • nginx
  • HAProxy
  • Envoy
  • Cloudflare
• 시리즈를 마치며 — 그리고 다음 방향

서버 한 대로는 부족해질 때

1편부터 여기까지의 흐름을 짧게 되짚어보면 이렇다. IP와 포트로 어디에 말을 걸지 정하고, TCP/UDP로 대화의 방식을 고르고, DNS로 이름을 주소로 바꾸고, HTTP로 요청을 실어 보내고, TLS로 그 요청을 안전하게 감쌌다. 여기까지는 클라이언트와 서버가 일대일이라는 가정 위에 있었다.

그런데 트래픽이 늘면 서버 한 대로는 감당이 안 된다. 선택지는 두 가지다. 기계 사양을 더 키우는 스케일 업(scale up)과, 같은 기능을 하는 기계를 여러 대 두는 스케일 아웃(scale out)이다. 스케일 업은 한계가 있고 비싸다. 그래서 대부분의 웹 서비스는 스케일 아웃을 택한다. 서버를 여러 대 띄우고, 그 앞에 트래픽을 나눠주는 장치를 둔다.

이 장치가 로드 밸런서(load balancer)다. 그리고 로드 밸런서와 비슷하면서도 약간씩 다른 역할을 하는 프록시(proxy)가 같이 등장한다. 이 편에서는 두 개념이 어떤 계층에서, 어떤 방식으로 일을 하는지 정리한다.

프록시 — 중간에 끼어 있는 무언가

먼저 프록시가 뭔지부터 정리한다. 프록시는 클라이언트와 서버 사이에 끼어서 요청·응답을 중계하는 중간 장치다. 끼어 있는 위치에 따라 이름이 갈린다.

flowchart LR
    subgraph FW["포워드 프록시 (클라이언트 쪽)"]
        C1[내부 직원 PC] --> FP[회사 프록시]
        FP --> INT1[인터넷 서버들]
    end
    subgraph RV["리버스 프록시 (서버 쪽)"]
        INT2[외부 사용자] --> RP[리버스 프록시]
        RP --> B1[내부 서버 A]
        RP --> B2[내부 서버 B]
    end

두 프록시의 차이를 한 문장으로 요약하면 이렇다. 포워드 프록시는 클라이언트를 대신하고, 리버스 프록시는 서버를 대신한다.

• 포워드 프록시(forward proxy): 사내 네트워크에서 외부로 나가는 요청을 한곳에 모은다. 쓰임새는 인터넷 접근 제어, 캐시, 감사 로그 같은 것들이다. 클라이언트는 프록시의 존재를 알고 쓴다. 브라우저 설정에 프록시 주소를 넣는 식
• 리버스 프록시(reverse proxy): 서버 앞에 앉아 외부 요청을 받는다. 클라이언트는 대개 프록시의 존재를 모른다. 오직 도메인 하나에 접속할 뿐이다. 그 뒤에 있는 수십 대의 백엔드는 리버스 프록시가 숨긴다

로드 밸런서는 리버스 프록시의 일종이다. 그래서 nginx·HAProxy 같은 도구가 리버스 프록시이자 로드 밸런서로 동시에 불린다. 이 글에서 “프록시”라 쓰면 기본적으로 리버스 프록시를 가리킨다.

L4와 L7 — 어느 계층을 보는가

로드 밸런서의 가장 중요한 구분은 OSI 어느 계층에서 결정을 내리느냐다. OSI는 네트워크 기능을 7개 계층으로 나눈 모델로, 2편에서 간략히 봤다. 로드 밸런서 맥락에선 L4(전송 계층 — TCP/UDP) 와 L7(애플리케이션 계층 — HTTP) 만 기억하면 된다.

flowchart TB
    subgraph L4["L4 로드 밸런서 (TCP/UDP)"]
        L4IN[패킷] -->|IP + 포트만 본다| L4DEC[분배 결정]
        L4DEC --> L4B1[백엔드]
    end
    subgraph L7["L7 로드 밸런서 (HTTP)"]
        L7IN[HTTP 요청] -->|호스트, 경로, 헤더, 쿠키| L7DEC[분배 결정]
        L7DEC --> L7B1[백엔드]
    end

L4 로드 밸런서는 IP와 포트만 보고 패킷을 분배한다. HTTP 헤더나 URL 경로는 신경 쓰지 않는다. 장점은 속도와 단순함. 연결마다 수 마이크로초 수준의 처리로 가능하고, 프로토콜을 가리지 않아 TCP 기반이면 뭐든 처리한다. MySQL 연결, Redis 연결, gRPC, 나아가 게임 서버의 커스텀 프로토콜도 L4로 분산할 수 있다.

L7 로드 밸런서는 HTTP 메시지를 파싱한다. 호스트 헤더, URL 경로, 쿠키, HTTP 메서드까지 본다. 그래서 “/api는 백엔드 A로, /static은 백엔드 B로”, “api.example.com과 admin.example.com을 다르게” 같은 정교한 라우팅이 가능해진다. 6편의 TLS 종단도 L7의 영역이다. 암호문을 여기서 풀어야 HTTP 헤더를 볼 수 있으니까.

실무에서는 두 계층을 섞어 쓴다. L4 앞단이 들어오는 모든 트래픽을 클러스터의 L7 로드 밸런서에 넘기고, L7이 HTTP 세부를 처리하는 식이다. 구글의 Maglev, AWS의 NLB + ALB 조합이 이 패턴이다.

분배 알고리즘 — 누구에게 다음 요청을 줄 것인가

여러 백엔드 중 어느 서버에 다음 요청을 보낼지 고르는 규칙이 분배 알고리즘이다. 많이 쓰는 네 가지를 보자.

라운드 로빈(round-robin)

이름 그대로 차례대로 돌려가며 보낸다. 가장 단순하다. 백엔드가 세 대면 1 → 2 → 3 → 1 → 2 → 3 순서로 요청이 배분된다.

flowchart LR
    R[들어온 요청<br/>1,2,3,4,5,6,7,8] --> LB[LB: round-robin]
    LB -->|1,4,7| A[서버 A]
    LB -->|2,5,8| B[서버 B]
    LB -->|3,6| C[서버 C]

백엔드들이 동일한 성능과 부하를 가진다고 가정할 때 잘 동작한다. 요청의 처리 시간이 들쭉날쭉하면 누구는 놀고 누구는 밀리는 불균형이 생긴다.

가중치 라운드 로빈(weighted round-robin)

서버마다 가중치를 준다. 사양이 다른 서버를 섞어 쓸 때, 혹은 새 버전으로 점진적으로 트래픽을 옮길 때(카나리 배포) 유용하다. A:3, B:2, C:1이면 여섯 요청 중 A에 셋, B에 둘, C에 하나가 간다.

최소 연결(least-connections)

현재 활성 연결이 가장 적은 서버에 다음 요청을 보낸다. 요청마다 처리 시간이 크게 다른 워크로드(웹소켓, 스트리밍, 긴 분석 쿼리)에서 라운드 로빈보다 훨씬 공평하다. 연결 카운터를 유지해야 하니 약간의 상태가 필요하지만 비용은 작다.

소스 IP 해시(ip-hash)

클라이언트 IP를 해시해서 어떤 서버로 보낼지 결정한다. 같은 IP에서 온 요청은 항상 같은 서버로 간다. 이게 다음 항목, 세션 어피니티의 기반이다.

세션 어피니티 — 같은 사용자는 같은 서버로

HTTP는 기본적으로 stateless다. 그런데 로그인 세션을 서버 메모리에 올려두는 구식 앱에선, 같은 사용자 요청이 같은 서버로 가지 않으면 세션이 깨진다. 이 상황을 해결하는 게 세션 어피니티(sticky session)다.

두 가지 구현이 흔하다.

• IP 기반: 클라이언트 IP를 해시해 같은 서버로 고정. NAT 뒤에 사람들이 몰려 있으면 한 서버로 쏠릴 수 있다
• 쿠키 기반: 로드 밸런서가 응답에 특수 쿠키를 붙여둔다. 다음 요청에서 그 쿠키를 보고 같은 서버로 보낸다. IP 방식의 편향을 피할 수 있고 정확도도 높다

sequenceDiagram
    participant U as 사용자
    participant LB as 로드 밸런서
    participant B1 as 백엔드 1
    U->>LB: 첫 요청
    LB->>B1: 라운드 로빈으로 선택
    B1-->>LB: 응답
    LB-->>U: Set-Cookie: LB_ROUTE=B1
    U->>LB: 두 번째 요청 (Cookie: LB_ROUTE=B1)
    LB->>B1: 쿠키 해석 → 같은 서버로
    B1-->>U: 세션이 유지된 응답

세션 어피니티는 유용하지만 근본적으로는 우회 수단이다. 서버에 상태를 두는 건 스케일 아웃의 적이다. 새 서버를 추가해도 이미 붙어 있는 세션이 옮겨가지 않고, 한 서버가 죽으면 그 서버에 어피니티를 가진 사용자 전부가 로그아웃된다. 요즘은 세션을 Redis 같은 외부 저장소로 빼서 서버를 완전 무상태로 만드는 쪽을 선호한다. 그러면 어떤 서버로 보내도 같은 응답을 만들 수 있다.

헬스 체크 — 죽은 서버는 빼야 한다

백엔드 중 일부가 죽거나 이상해졌을 때 로드 밸런서가 그걸 모르면, 트래픽이 그쪽으로 계속 흘러가 5xx 오류가 쏟아진다. 그래서 로드 밸런서는 주기적으로 백엔드에 헬스 체크(health check)를 보낸다.

# 개념적인 헬스 체크 설정 예시 (nginx upstream)
upstream backend {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
}

• L4 헬스 체크: TCP 연결이 되는지만 본다. 빠르지만 “앱은 죽었는데 포트는 열려 있는” 경우를 못 잡는다
• L7 헬스 체크: 특정 URL에 HTTP 요청을 보내 200 응답을 기대한다. /health 엔드포인트가 DB 연결까지 확인하도록 만들어두면 “앱이 진짜로 살아 있는가”를 판단할 수 있다

Kubernetes의 readiness·liveness 프로브도 같은 개념이다. 어느 레이어에서 하든 “트래픽을 받을 수 있는 상태인가” 를 주기적으로 묻는 게 핵심이다.

TLS 종단 — 암호화를 어디서 벗기는가

6편에서 본 TLS 핸드셰이크는 CPU 비용이 꽤 든다. 백엔드 서버 수십 대가 각자 TLS를 처리하면 자원이 중복 소모된다. 그래서 많은 현장에서는 로드 밸런서에서 TLS를 복호화하고, 그 뒤부터는 내부 HTTP로 보낸다. 이 지점을 TLS 종단(termination)이라 부른다.

flowchart LR
    CLIENT[클라이언트] -->|HTTPS| LB["L7 LB<br/>TLS 종단"]
    LB -->|HTTP| B1[백엔드 1]
    LB -->|HTTP| B2[백엔드 2]
    LB -->|HTTP| B3[백엔드 3]

장점은 명확하다. 인증서 관리가 한 곳에 모이고(갱신이 편하다), 백엔드는 TLS를 몰라도 되고, HTTP 헤더 기반 라우팅이 자연스럽게 가능해진다. 단점은 LB와 백엔드 사이 구간이 평문이라는 점이다. 내부 네트워크라도 안전하지 않다고 보는 제로 트러스트(Zero Trust, “내부도 신뢰하지 않는다”는 보안 모델) 시대에는 이 구간도 TLS로 다시 감싸는(mTLS, 상호 TLS) 패턴이 늘고 있다. Istio 같은 서비스 메시가 그 작업을 자동화해준다.

CDN — 로드 밸런서의 먼 친척

CDN(Content Delivery Network — 사용자와 물리적으로 가까운 서버에서 콘텐츠를 제공하는 분산 네트워크)은 로드 밸런서와 비슷하면서 결이 다르다. 로드 밸런서가 한 데이터센터 안에서 트래픽을 분배한다면, CDN은 전 세계에 깔린 엣지 서버로 콘텐츠를 분산시킨다.

사용자의 위치와 가장 가까운 엣지에서 응답을 돌려주니 지연이 크게 줄고, 원본 서버(오리진)의 부하도 빠진다. 동작 원리는 대체로 이렇다.

flowchart TB
    U1[서울 사용자] --> E1[엣지: 서울]
    U2[런던 사용자] --> E2[엣지: 런던]
    U3[상파울루 사용자] --> E3[엣지: 상파울루]
    E1 --> O["오리진<br/>(미국 US-East 데이터센터)"]
    E2 --> O
    E3 --> O
    E1 -.->|캐시 히트면 원본 호출 생략| U1

• DNS로 가까운 엣지 안내: 사용자가 도메인을 조회하면 CDN의 DNS가 사용자 IP 기반으로 가장 가까운 엣지의 IP를 준다. 애니캐스트(anycast) 같은 저수준 기법도 쓰인다
• 엣지에서 캐시 판단: 엣지가 요청받은 자원을 이미 가지고 있으면(캐시 히트) 오리진까지 안 간다. 없으면(캐시 미스) 오리진에 요청하고, 응답을 엣지에 저장한 뒤 돌려준다
• 캐시 TTL: 서버가 5편에서 본 Cache-Control 헤더로 “얼마나 저장해도 되는지”를 지시한다. 정적 자원은 길게, API 응답은 짧게 혹은 no-store로 관리한다

요즘의 CDN(Cloudflare, Fastly, CloudFront 같은)은 단순 캐시를 넘어 엣지에서 코드까지 돌린다. 라우팅 규칙, A/B 테스트, WAF(Web Application Firewall — 웹 공격 차단), 엣지 함수. 오리진에 가기 전에 엣지에서 많은 일이 끝난다. “CDN이 곧 애플리케이션의 앞단”이 되어가는 추세다.

실무 제품들 — 무엇이 어디에 쓰이는가

마지막으로 실무에서 이름값을 하는 제품들을 정리한다. 각각 강점이 다르다.

nginx

오래 자리 잡은 리버스 프록시이자 웹 서버. 리눅스 배포판에 기본 패키지가 있어 진입 장벽이 낮고, 설정 문법이 선언적이다. L7 라우팅, TLS 종단, 정적 파일 서빙, 캐싱까지 한 덩어리로 해결한다. Kubernetes의 ingress-nginx로도 가장 많이 쓰이는 컨트롤러다.

# nginx로 /api는 백엔드, 나머지는 정적으로
upstream api_backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/tls/example.crt;
    ssl_certificate_key /etc/nginx/tls/example.key;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location / {
        root /var/www/html;
    }
}

위 설정에서 /api/로 들어온 요청은 두 백엔드 중 한쪽으로 라운드 로빈된다. X-Forwarded-For 헤더로 원본 클라이언트 IP를 백엔드에 전달하는 것도 리버스 프록시의 기본 매너다.

HAProxy

이름 그대로(High Availability Proxy) 고성능 로드 밸런싱에 초점을 맞춘 제품. L4·L7 모두 강력하고, 풍부한 상태 통계와 세밀한 튜닝 옵션이 특징이다. 통신사·금융·게임 서버처럼 극단적 트래픽을 다루는 곳에서 자주 보인다.

Envoy

구글·리프트가 주도해 만든 현대적 프록시. 클라우드 네이티브 환경에 맞춰 동적 구성과 관찰 가능성을 1급 시민으로 삼았다. 설정을 xDS API로 원격에서 바꿀 수 있어 서비스 메시(Istio, Consul Connect)의 데이터 플레인으로 널리 쓰인다. HTTP/2, HTTP/3, gRPC를 기본으로 지원한다.

Cloudflare

제품이라기보다 전 세계 규모의 CDN 겸 보안 네트워크. 사용자는 도메인의 네임서버만 Cloudflare로 바꾸면 곧바로 그 인프라 위에 올라간다. DDoS 방어, WAF, 캐시, 엣지 컴퓨팅(Workers)이 한 플랫폼에 통합돼 있다. AWS의 CloudFront, Fastly, Akamai가 비슷한 영역의 경쟁자다.

선택은 결국 워크로드와 운영 역량의 함수다. 단일 서비스에 nginx 한 대로 충분한 경우도 있고, 엣지부터 메시까지 Envoy+Cloudflare로 묶어야 하는 경우도 있다. 도구를 먼저 고르지 말고, 풀어야 할 문제를 먼저 정의하는 게 순서다.

시리즈를 마치며 — 그리고 다음 방향

네트워크 기초 시리즈에서 다룬 것은 크게 이런 지도였다. IP와 포트로 주소를 매기고, TCP와 UDP로 대화의 성격을 고르고, DNS로 이름을 찾고, HTTP와 TLS로 안전한 웹 요청을 만들고, 로드 밸런서와 프록시로 그 요청을 여러 서버에 분배한다. 일곱 편을 관통하면 브라우저 주소창에 URL을 쳤을 때 일어나는 일이 한 장의 흐름으로 보이게 된다.

여기서 더 깊이 들어가고 싶다면 방향은 몇 가지로 갈린다.

• 네트워크 운영: tcpdump·Wireshark로 실제 패킷을 관찰하고, ss·netstat·ip로 소켓과 라우팅을 다루는 기술. iptables·nftables·eBPF 같은 커널 수준 네트워킹도 여기에 속한다
• 클라우드 네트워킹: VPC·서브넷·라우팅 테이블, NAT Gateway, Transit Gateway, VPC 피어링, 프라이빗 링크 등 클라우드 사업자의 네트워킹 모델
• 관측 가능성: 로드 밸런서와 서비스 메시가 쏟아내는 메트릭·트레이스를 Prometheus·OpenTelemetry로 수집하고 해석하는 작업
• 보안 심화: mTLS, 제로 트러스트, SPIFFE/SPIRE 같은 워크로드 아이덴티티, 그리고 WAF·DDoS 대응

네트워크는 그 자체가 최종 목적이 아니라, 시스템을 이해하는 공용어에 가깝다. 백엔드를 만들든 DevOps를 하든 보안을 보든, 여기서 쌓은 어휘가 다른 영역의 글을 읽을 때 번역기 역할을 한다. 이 시리즈가 그 번역기의 기초가 되면 의도한 바를 다한 것이다.

네트워크 기초 시리즈는 여기서 마친다.