localhost:3000은 왜 친구 컴퓨터에서 열리지 않는가
localhost는 특별히 약속된 도메인 이름이고, 의미는 딱 하나 "지금 이 컴퓨터 자신"입니다. 실제 IP 주소로는 127.0.0.1인데, 매번 치기 번거로워 전 세계가 이름 하나로 약속해 둔 것입니다. 그래서 친구가 자기 브라우저에 localhost:3000을 치면 친구 컴퓨터의 3000번 포트를 찾아갈 뿐입니다. 서버도, 도메인도, DNS도, HTTPS도 아직 없는 상태이고, 이 공백을 채우는 과정 전체가 배포입니다.
배포는 왜 어려운 문제였는가
초창기 배포는 FTP로 파일을 복사하는 일이었습니다. 단순해 보이지만 사고가 끊이지 않았습니다. 파일 하나를 빠뜨리면 사이트가 반쪽만 업데이트된 채 돌아가고, 팀원 둘이 같은 서버에 올리다 서로 작업을 덮어쓰고, 내 컴퓨터엔 Node 18인데 서버엔 14가 깔려 있어 "내 컴퓨터에선 됐는데"가 반복됐습니다.
세 문제의 해법은 각각 따로 나왔습니다. 기록이 없어 생긴 문제는 2005년 Git이 커밋과 브랜치로 풀었고, 환경이 달라 생긴 문제는 2013년 Docker가 코드와 실행 환경을 밀키트처럼 한 박스에 포장하는 방식으로 풀었습니다. 사람 손을 타서 생긴 문제는 CI/CD가 맡아, 푸시 한 번이면 테스트·빌드·배포가 파이프라인을 따라 자동으로 흘러갑니다. 하루에 수백 번 배포하는 시대는 이렇게 열렸습니다.
Nginx는 어떻게 웹 서버의 표준이 되었는가
한때 전 세계 웹 서버의 70% 이상이 아파치였습니다. 그런데 아파치는 접속자 한 명마다 프로세스를 하나씩 만들었고, 동시 접속 1만 명이면 프로세스도 1만 개라 메모리가 버티지 못했습니다. 이른바 C10K 문제입니다. 2004년 러시아 개발자 이고르 시소예프가 만든 Nginx는 적은 수의 프로세스가 수많은 요청을 번갈아 처리하는 이벤트 기반 구조로 이를 정면 돌파했고, 지금은 점유율 1위입니다. 정적 파일은 직접 주고 코드 실행이 필요한 요청은 뒤쪽 WAS로 넘기는 리버스 프록시, 즉 병원 안내데스크 역할까지 겸합니다.
Vercel은 무엇을 대신해 주고, 무엇을 가져가는가
서버 임대, Nginx 설치, Docker 설정, CI/CD 구성, SSL 인증서 발급까지 직접 하면 며칠이 걸립니다. Vercel은 GitHub 저장소를 연결하는 것으로 이 전부를 대신합니다. 푸시할 때마다 자동으로 재배포되고, 커스텀 도메인을 붙이면 HTTPS도 자동 적용됩니다.
대가는 제어권입니다. 편리한 플랫폼일수록 세밀한 서버 설정을 건드리기 어렵습니다. 프로토타입은 Vercel이나 Railway로 시작하고, 요구가 복잡해지면 거의 모든 설정이 가능한 AWS로 옮기는 흐름이 일반적인 이유입니다.
비개발자가 이 지도를 왜 알아야 하는가
몰라도 쓸 수는 있습니다. 다만 알고 쓰면 막혔을 때 어느 단계의 문제인지 감이 옵니다. AI에게 "배포해 줘"라고 하는 사람과 "빌드 단계에서 환경 변수가 인식이 안 되는 것 같아", "Vercel에 가비아 도메인을 연결하려는데 CNAME을 어떻게 잡아야 해"라고 묻는 사람의 결과물은 다를 수밖에 없습니다. 비개발자 바이브 코딩의 실력은 이 질문의 구체성에서 갈립니다. SH Consulting의 AX 교육에서 코드 작성만큼 배포를 비중 있게 다루는 이유입니다.