콘텐츠 발행 및 배포

콘텐츠를 만들었으면 세상에 내보내야 하잖아. 호스팅, 배포, 분산, 추적 — 이게 웹 운영의 뒷단이야.

가상 호스팅은 하나의 물리 서버에서 여러 웹사이트를 운영하는 기술이야. 사이트마다 서버를 따로 두면 돈이 어마어마하니까, 하나를 나눠 쓰는 게 경제적이지. 근데 HTTP/1.0 시절에는 요청에 호스트명이 안 들어갔어. GET /index.html만 보내면 서버가 이게 어떤 사이트의 index.html인지 알 수가 없었거든. IP 기반, 포트 기반, 경로 기반 같은 임시방편이 있었지만, 결국 HTTP/1.1이 Host 헤더를 필수로 만들면서 해결됐어. Host: www.siteA.com — 서버가 이걸 보고 어떤 가상 호스트의 리소스를 줄지 결정하는 거야. Host 헤더가 없으면 400 Bad Request를 돌려줘야 해.

호스팅 방식은 몇 가지로 나뉘어. 전용 호스팅은 물리 서버를 독점하는 거라 성능/보안이 좋지만 비싸고, 공유 호스팅은 여러 고객이 서버를 공유하니까 저렴하지만 옆집 트래픽 폭주에 영향받을 수 있어. 관리형 호스팅은 업체가 서버 관리까지 대행하는 거고. 그리고 현대에 거의 필수인 CDN — 전 세계에 분산된 서버에 콘텐츠를 캐시해두고 사용자에게 가장 가까운 데서 제공하는 거야. Cloudflare, CloudFront, Akamai가 대표적이지. 빠른 사이트를 만들려면 결국 압축 + 캐시 + CDN + 이미지 최적화를 조합하는 거야.

배포 얘기로 넘어가면, 웹 콘텐츠를 서버에 올리는 방법도 진화해왔어. FTP로 직접 올리던 시절에는 여러 사람이 같은 파일을 동시에 건드리면 충돌이 나고 버전 관리가 안 됐지. Microsoft의 FrontPage 서버 확장이 초기 해결책이었는데, HTTP POST 위에 RPC를 얹어서 원격 파일 관리를 했어. 근데 지금은 완전히 역사 속 기술이야.

WebDAV는 HTTP를 확장해서 원격 저작을 지원하는 프로토콜이야. HTTP가 "읽기 전용" 웹이라면, WebDAV는 "읽기/쓰기" 웹을 만들려는 시도였지. PROPFIND(속성 조회), PROPPATCH(속성 수정), MKCOL(디렉터리 생성), COPY, MOVE, LOCK/UNLOCK 같은 새 메서드를 추가했어. 특히 잠금 메커니즘이 핵심인데, 여러 사용자가 동시에 같은 문서를 편집하면 덮어쓰기 충돌이 생기거든. 배타적 잠금은 한 사람만 수정 가능하게 하고, 공유 잠금은 여러 사람이 동시에 잠금을 걸면서 서로의 변경을 인지해. WebDAV는 207 Multi-Status, 422 Unprocessable Entity, 423 Locked 같은 새 상태 코드도 추가했어. 지금은 CalDAV(캘린더), CardDAV(연락처) 같은 틈새 분야에서 명맥을 유지하지만, 일반적인 웹 배포는 Git + CI/CD가 완전히 대체했어.

이제 리다이렉션이야. 하나의 서버로 모든 트래픽을 감당하기 어려우니까, 요청을 가장 적절한 곳으로 보내는 기술이 필요해. 목표는 세 가지 — 신뢰성(한 서버가 죽어도 다른 게 대체), 부하 균형(트래픽 분산), 지연 최소화(가장 가까운 서버로). 리다이렉션은 웹의 여러 계층에서 동작하거든.

HTTP 리다이렉션은 서버가 3xx 상태 코드와 Location 헤더로 다른 URL을 알려주는 거야. 간단하지만 왕복이 추가되니까 느려. DNS 라운드로빈은 같은 도메인에 여러 IP를 매핑해서, 요청마다 다른 IP를 돌려주는 방식이야. 더 똑똑한 DNS는 서버 부하랑 지리적 위치를 고려해서 최적의 IP를 반환하는데, 이걸 **GSLB(Global Server Load Balancing)**라고 해. 애니캐스트는 여러 서버가 같은 IP를 공유하고 라우터가 가장 가까운 서버로 보내주는 기술이야 — CDN에서 많이 써.

로드 밸런서는 서버들 앞에서 트래픽을 분산하는 장치야. 라운드로빈(순서대로), 최소 커넥션(가장 한가한 서버로), 해시 기반(같은 클라이언트가 항상 같은 서버로, 세션 지속성) 같은 알고리즘을 써. **MAC 주소 전달(DSR)**이라는 기법을 쓰면 로드 밸런서가 병목이 되지 않아 — 패킷의 MAC만 바꿔서 서버로 보내고, 서버가 클라이언트에 직접 응답하니까.

프락시 쪽에서는 인터셉트 프락시(투명 프락시)가 클라이언트 모르게 트래픽을 가로채서 캐시로 보내는 방식이 있고, WCCP라는 Cisco 프로토콜이 라우터와 캐시 간 통신을 표준화했어. 캐시끼리 협력하는 프로토콜도 있는데, ICP는 "이 URL 사본 있어?"라고 형제 캐시에 물어보는 거고, CARP는 URL 해시로 담당 캐시를 미리 정해서 물어볼 필요 없이 바로 찾아가는 거야.

마지막으로 로깅. 서버가 처리한 HTTP 트랜잭션을 기록하는 거야. 문제 진단, 사용 통계, 보안 감사, 과금 — 로그 없이는 서버를 운영할 수 없지. 가장 전통적인 건 일반 로그 포맷(Common Log Format)인데, IP, 사용자, 시간, 요청줄, 상태 코드, 바이트를 한 줄에 담아. 여기에 Referer와 User-Agent를 추가한 게 결합 로그 포맷(Combined Log Format)이고, 현대에는 이게 표준이야.

209.1.32.44 - frank [10/Oct/2024:13:55:36 -0700] "GET /index.html HTTP/1.1" 200 2326 "http://www.example.com/links.html" "Mozilla/5.0"

현대에는 텍스트 로그 대신 JSON 구조화 로그를 많이 써. 파싱하기 쉽고 ELK Stack이나 Datadog에 바로 넣을 수 있거든. Apache에서는 LogFormat 지시자로 커스텀 포맷도 만들 수 있어.

캐시 때문에 서버 로그만으로는 정확한 트래픽을 못 재는 문제가 있어. 캐시가 대신 응답하면 원 서버에 요청이 안 가니까. **적중 계량(Hit Metering)**은 캐시가 "이 리소스를 몇 번 제공했다"고 서버에 보고하는 프로토콜이야. 광고 노출 횟수 측정이나 유료 콘텐츠 과금에 중요하지.

그리고 잊지 말아야 할 건 — 로그에는 개인정보가 담겨 있다는 거야. IP 주소, Referer, User-Agent, Cookie — 이런 것들로 사용자를 추적할 수 있거든. 최소 수집, 보관 기한 설정, 접근 제한, 익명화 같은 원칙을 지켜야 하고, GDPR이나 개인정보보호법 같은 법규도 준수해야 해.

---

정리

5장 읽고 기억할 거 세 가지:

1. Host 헤더가 가상 호스팅의 핵심이야. 하나의 서버에서 여러 사이트를 운영할 때 요청이 어디로 가야 하는지 알려주는 거고, 현대 웹 배포는 Git + CI/CD가 표준이야
2. DNS 라운드로빈 + 로드 밸런서가 실용적인 부하 분산 조합이야. DNS로 대략적 분산, 로드 밸런서로 정교한 분산을 하고, CDN의 애니캐스트가 지리적 분산을 해결해
3. 로그는 서버 운영의 눈이지만 개인정보도 담고 있어. 결합 로그 포맷이 표준이고, 적중 계량으로 캐시 뒤의 트래픽도 측정할 수 있어