웹 서버와 배포 기초

한 줄 정의

웹 서버는 클라이언트 요청에 정적 파일을 전달하거나 WAS로 전달하는 역청자이며, 배포는 코드를 서버에 올려 인터넷에서 누구나 접근 가능하게 만드는 전체 흐름이다.

핵심 요지

웹 서버(Apache 70% 점유율 historically, Nginx 2004~)와 WAS는 같은 서버 안에서 함께 동작하는 별개의 프로그램
Nginx는 이벤트 기반 아키텍처로 C10K 문제를 해결한 리버스 프록시
Docker(2013)는 코드와 실행 환경을 함께 포장하여 환경 불일치 문제를 해결
CI/CD(GitHub Actions)는 코드 푸시 → 테스트 → 빌드 → 배포를 자동화하여 하루 수백 번 배포를 가능하게 함
DNS 레코드(A, CNAME, MX, TXT, NS)와 HTTPS/Let’s Encrypt(2015)로 완전한 주소가 완성됨
AI 에이전트는 headless 환경, 컨테이너화, automated CI/CD에서 가장 효과적으로 작동
과거 사람이 직접 FTP 클라이언트를 사용하여 수동으로 복사하던 파일 전송 방식은 파일 누락, 팀 협업 충돌, 환경 불일치라는 3대 치명적인 장애를 양산했다.
도메인을 실제 가동 IP와 맵핑한 뒤에는 네임서버의 캐시 설정(TTL) 및 DNS 전파(Propagation) 주기를 정확히 제어하여 중단 없는 환경을 확보해야 한다.

상세

웹 서버 vs WAS

웹 서버	WAS
정적 파일(HTML, CSS, JS)을 그대로 돌려줌	백엔드 코드(Python, Java, Node.js)를 실제로 실행하는 엔진
자판기: 버튼 누르면 이미 만들어진 음료가 나옴	카페 바리스타: 주문이 들어와야 그 자리에서 직접 만들기 시작

웹 서버는 HTTP 통신에만 집중하고, WAS가 언어별 런타임을 포함해 코드 실행을 담당한다.

Nginx 이벤트 기반 아키텍처

Apache는 요청마다 프로세스를 생성해 1만 동시 접속 시 1만 프로세스가 발생해 서버가 죽었다. Nginx(2004, 러시아 개발자 Igor Sysoev)는 이벤트 기반 아키텍처로 이 문제를 해결했다.

핵심 아이디어: 요청마다 프로세스를 만들지 말고, 하나의 프로세스가 여러 요청을 번갈아 처리한다.

결과: 적은 메모리로 엄청난 동시 접속 처리. 현재 전 세계 웹 서버 점유율 1위.

Nginx는 리버스 프록시 역할로 뒤쪽 서버들에게 트래픽을 분배한다.

Docker 컨테이너

“내 컴퓨터에서는 잘 됩니다”问题的 해결책:

Docker(2013): 코드와 환경을 함께 포장(밀키트 개념)
이미지 = 붕어빵 틀, 컨테이너 = 그 틀로 찍어낸 실제 붕어빵
Dockerfile에 레시피를 적으면 어떤 서버에서든 동일한 환경이 만들어짐

CI/CD 파이프라인

GitHub Actions 기반 파이프라인:

코드를 Git에 푸시
GitHub Actions가 자동 실행
코드 설치 + 테스트 실행
테스트 통과 시 도커 이미지 빌드
이미지를 서버에 배포
서버가 새 버전으로 재시작

DNS와 HTTPS

도메인 생태계 3주체: ICANN(총괄), 레지스트리(.com은 Verisign, .kr은 한국인터넷진흥원), 리셀러(가비아, 고대디)

주요 DNS 레코드:

A 레코드: 도메인 → IPv4 주소
CNAME: 도메인 → 다른 도메인 (커스텀 도메인 연결 시 주로 사용)
MX: 이메일 수신 서버
TXT: SPF/DKIM 인증, 도메인 소유 확인

Let’s Encrypt(2015) 이후 SSL 인증서가 무료가 되었으며, Certbot과 연동해 자동 갱신까지 지원된다. 현대 배포 플랫폼(Vercel, Railway)은 커스텀 도메인 연결 시 SSL을 자동으로 적용한다.

스케일링과 로드 밸런싱

수직 확장(Scale Up): CPU/메모리 업그레이드 — 한계가 있고 비용이 기하급수적으로 증가
수평 확장(Scale Out): 같은 서버를 복제해 여러 대로 증설 — 클라우드 덕분에 가능

로드 밸런서가 서버들 앞에서 트래픽을 고르게 분배하고, 오토스케일링이 트래픽에 따라 서버를 자동으로 늘리고 줄인다.

에이전트 네이티브 관점

AI 에이전트가 배포를 수행하려면:

Headless 환경: CLI/API로 동작해야 하므로 클릭 기반 플랫폼보다 명령형 접근이 유리
컨테이너화: Docker 이미지로 환경을 포장하면 에이전트가 일관된 환경에서 실행 가능
CI/CD 통합: GitHub Actions 파이프라인을 파일로 정의해 두면 에이전트가 코드를 푸시만 하면 배포가 완료됨
Secret 관리: 환경 변수/API Key는 콘솔 클릭 대신 infisical run 같은 명령으로 주입
DNS 설정: A 레코드, CNAME 변경을 CLI로 수행 가능

예를 들어 Quartz 배포는 GitHub Actions에서 node 22, npm ci, npx quartz build, Pages artifact 업로드로 명령으로 표현된다. 이런 배포 절차는 스크린샷보다 에이전트가 검토하고 수정하기 쉽다.

1. FTP 배포의 3대 치명적 리스크

파일 누락 (File Omission): 다수의 빌드 파츠 중 단 하나의 파일이 낙오되어 복사되어도 애플리케이션의 특정 동작 경로가 기습 붕괴함.
팀 협업 충돌 (Collaborative Conflict): 여러 명의 개발자가 하나의 서버 파일을 사전 협율 없이 덮어씌우는 바람에 이전 세션 코드가 증발하는 형상 관리 통제 실패.
환경 불일치 (Environment Mismatch): 개발 환경의 Node/Python/Java 버전과 운영 서버의 미스매치로 인해 로컬의 정상 픽스가 배포 시 크래시로 발현됨 (이를 Docker 컨테이너가 붕어빵 틀처럼 통일하여 완전 해결).

2. DNS 전파(Propagation)와 TTL 메커니즘

TTL (Time to Live): 개별 DNS 레코드가 타사 네임서버에 캐싱되어 머무는 유효 시간(초 단위). 레코드 교체가 임박했다면 TTL을 임시로 수초 수준으로 낮춰 신속히 적용시켜야 한다.
전파 지연: 전 세계에 분산된 수천 개의 DNS 네임서버 캐시가 완전히 최신화되는 시간은 짧게는 수분에서 길게는 최대 48시간까지 소요되므로, 잦은 설정 조작을 지양하고 캐시 주기를 기다리는 호흡이 요구된다.

예시

Nginx 리버스 프록시 설정으로静的 파일은 Nginx가 직접 처리, 동적 요청은 WAS(Node.js, Python)로 전달
GitHub Actions로 main 브랜치 푸시 시 자동으로 Docker 빌드 → EC2에 배포
Let’s Encrypt + Certbot으로 SSL 인증서 자동 발급 및 갱신
Vercel/Railway에 GitHub 연결만으로 git push → 배포 자동화

3. DNS 주요 레코드의 쓰임새 요약

A 레코드: 도메인을 실제 IPv4 주소(예: 123.456.78.9)로 직결.
CNAME: 도메인을 다른 호스트명에 위임하여 연결 (예: Vercel이나 CDN 서비스를 이용할 때 IP 변경 시 유동적으로 대응).
TXT: 주로 SPF(Sender Policy Framework) 및 DKIM(DomainKeys Identified Mail) 등 이메일 발신 신뢰도 텍스트를 기재하여, SendGrid나 Resend 등의 API 메일 발송 시 스팸함으로 직행하는 것을 차단함.

LLM Wiki

탐색기