카페24도 클라우드웨이즈도 아닌, Vultr 서울에 워드프레스를 '맨손으로' 올린 이유

유튜브는 다들 클라우드웨이즈를 추천하고, 국내 블로거는 카페24를 많이 쓴다. 그런데 나는 둘 다 아닌 Vultr 서울에 빈 서버를 빌려 워드프레스를 직접 올렸다. 왜 이 고생을 사서 했는지, 그리고 그 과정에서 만난 500 에러를 어떻게 잡았는지 실제 화면과 함께 남깁니다.

 

왜 카페24도 클라우드웨이즈도 아니었나

블로그 호스팅을 알아보며 가장 먼저 걸린 건 카페24의 트래픽 정책이었습니다. 국내 저가 플랜은 하루 트래픽이 소진되면 사이트가 차단됩니다. 수익형 블로그 입장에선 가장 무서운 시나리오입니다. 글 하나가 터져서 방문자가 몰리는 그 순간, 사이트가 죽어버릴 수 있다는 뜻입니다.

그래서 눈을 돌린 게 유튜브가 그렇게 미는 클라우드웨이즈였습니다. 그런데 조금 파보니, 유튜버들이 유독 이걸 추천하는 데에는 후한 제휴(어필리에이트) 수수료도 한몫한다는 걸 알게 됐습니다. 정보가 틀린 건 아니지만, "다들 추천하니까 정답"이라고 받아들이면 안 되는 이유입니다. 게다가 클라우드웨이즈는 결국 관리를 대신 해주는 대가로 웃돈을 받는 서비스입니다.

나는 이미 집에서 홈랩을 굴리며 Docker, Nginx Proxy Manager, 리버스 프록시까지 직접 만져본 사람으로 서버에 SSH로 들어가 명령어를 치는 게 두렵지 않았습니다. 그렇다면 관리 대행에 웃돈을 낼 이유가 없다는 말과 같습니다. 같은 값이면 Vultr 서울 리전을 직접 쓰는 게 더 싸고, 더 자유롭습니다.

 

기준	카페24	클라우드웨이즈	Vultr 직접
트래픽	일일 소진 시 차단	컷오프 없음	컷오프 없음
국내 속도	좋음	서울 선택 시 좋음	서울 리전, 좋음
관리 난이도	낮음	중간	높음(직접)
월 비용	저가~	기본금 + 추가금	가성비 최고

 

Vultr 서울에 서버 세우기 (약 10분)

Vultr는 한마디로 "빈 컴퓨터를 시간 단위로 빌려주는 회사"입니다. 카페24처럼 워드프레스가 깔린 걸 주는 게 아니라, 인터넷에 연결된 우분투 서버 한 대를 통째로 빌려 그 위에 뭘 올릴지는 '내 몫'입니다.

설정은 이렇게 잡았습니다. Type은 Cloud Compute(Shared CPU), Location은 Seoul, 이미지는 Ubuntu 24.04 LTS, 플랜은 2GB NVMe(High Frequency)로 월 12달러. 여기서 주의할 건 최저가인 2.5달러 플랜은 IPv6 전용이라 일반 웹사이트엔 못 쓴다는 점. 그리고 비밀번호 로그인보다 안전한 SSH 키를 미리 등록해두고 배포했습니다.

배포 버튼을 누르고 1~2분 기다리니 상태가 Running으로 바뀌고 공인 IP가 나왔습니다. 이 IP가 앞으로 이 서버의 주소입니다. 도메인은 추후에 추가하기로 하고, 사진의 플랜을 선택하면 12달러지만 자동으로 자동 백업 옵션이 추가되어 요금의 20%가 붙습니다. 자동 백업은 지금 단계에선 불필요해서 옵션 해제를 하고, 결제를 하였습니다. 추가로 필요할 때 다시 옵션 선택하고 결제 하면 됩니다.

 

root를 바로 쓰지 않는 이유 — 기본 보안

SSH로 처음 접속하면 root 계정으로 들어가집니다. 하지만 root를 그대로 쓰는 건 위험할 수도 있어서 작업용 사용자를 따로 만들고 sudo 권한을 줬습니다. 그리고 방화벽(UFW)으로 꼭 필요한 포트(SSH·80·443)만 열었습니다.

# 작업용 사용자 생성 + sudo 권한 adduser mj usermod -aG sudo mj   # 방화벽 ufw allow OpenSSH ufw allow 80/tcp ufw allow 443/tcp ufw enable

마지막으로 SSH 설정에서 비밀번호 로그인과 root 원격 로그인을 아예 차단했습니다. 여기서 초보가 자주 서버에 스스로 잠기는데, 방법은 간단합니다.

 

잠기지 않는 법

비밀번호 로그인을 끄기 전에, 반드시 새 터미널 창에서 새로 만든 계정의 키 로그인이 되는지 먼저 확인합니다. 확인될 때까지 기존 창은 절대 닫지 않습니다. 잘못되면 그 창에서 되돌려야 합니다.

 

LEMP 스택, 홈랩과 똑같았다

이제 빈 서버에 웹호스팅 환경을 얹을 차례입니다. 웹서버 Nginx, 데이터베이스 MariaDB, 그리고 PHP. 흔히 LEMP 스택이라 부릅니다. 홈랩에서 우분투에 서비스 올리던 것과 과정이 거의 똑같아서, 오히려 익숙했습니다.

한 가지 꼭 챙긴 건 데이터베이스를 만들 때 문자셋을 utf8mb4로 지정한 것. 이걸 놓치면 나중에 한글이나 이모지가 깨지니 꼭 유의하시기 바랍니다.

CREATE DATABASE ddlabx_wp   DEFAULT CHARACTER SET utf8mb4   COLLATE utf8mb4_unicode_ci;

 

PHP를 설치한 뒤에는 버전과 소켓 경로를 꼭 확인해야 합니다. php -v로 버전을, ls /run/php/로 실제 소켓 파일명을 봤는데, 이게 뒤에 나올 502 오류를 예방하는 핵심입니다. 저의 경우는 PHP 8.3.6, 소켓은 php8.3-fpm.sock이었습니다.

 

그리고 500 에러

워드프레스 파일을 올리고, 설정 파일(wp-config.php)에 DB 정보와 보안키를 넣고, Nginx 설정까지 끝냈습니다.

문법 검사(nginx -t)도 통과. 이제 설치 마법사만 돌리면 된다는 마음으로 브라우저에서 서버 IP를 열었는데

새하얀 화면에 HTTP ERROR 500. 순간 멘탈이 흔들렸지만, 여기서 중요한 단서가 하나 있었습니다. 흔한 502가 아니라 500이라는 점. 502는 PHP가 아예 안 돌 때, 500은 PHP는 돌았는데 코드가 에러를 낼 때 뜨는 화면 입니다. 즉 서버 연결이 아니라 코드(설정 파일) 문제라는 뜻입니다.

처음보는 에러에 로그부터 확인해봤습니다. 모든 에러는 로그 확인이 가능한 경우 로그부터 보는게 첫 순서 입니다.

sudo tail -n 20 /var/log/nginx/error.log

로그에 원인이 그대로 찍혀 있었습니다.

PHP Parse error: syntax error, unexpected identifier "define" in /var/www/ddlabx/wp-config.php on line 51

설정 파일 51번째 줄의 문법 오류. 확실히 하려고 PHP 문법 검사기로 한 번 더 확인해봤습니다.

php -l /var/www/ddlabx/wp-config.php Parse error: ... on line 51

범인은 보안키(salt) 8줄이었습니다. 워드프레스는 로그인 쿠키를 암호화하는 보안키 8줄을 설정 파일에 넣어야 하는데, 공식 사이트에서 생성한 값을 붙여넣는 과정에서 줄이 어긋나 붙어버린 것입니다. 한 줄에 define(이 두 번 들어가면 그 순간 문법이 깨진다.

처음엔 그 줄만 손보려고 끙끙댔는데, 오히려 더 꼬였습니다. 그래서 깨끗한 샘플 파일로 되돌린 뒤, 처음부터 다시 채워 넣었습니다.

# 깨진 파일 백업 후, 샘플로 초기화 cd /var/www/ddlabx sudo cp wp-config.php wp-config.php.bak sudo cp wp-config-sample.php wp-config.php   # 보안키 새로 생성해서 그대로 교체 curl -s https://api.wordpress.org/secret-key/1.1/salt/

DB 정보 3줄과 보안키 8줄을 다시 정확히 넣고 저장한 뒤 검사하니

No syntax errors detected in wp-config.php

브라우저를 새로고침하자 드디어 워드프레스 설치 마법사가 떴습니다.

이번 삽질에서 남은 교훈 ① 500과 502는 다르다. 500이면 코드, 502면 연결/소켓 문제로 방향을 좁힐 수 있다. ② 감으로 고치지 말고 error.log와 php -l부터 본다. 원인이 줄 번호까지 찍힌다. ③ 붙여넣기 실수로 꼬였을 땐, 한 줄씩 매달리기보다 깨끗하게 되돌려 다시 하는 게 빠를 때가 있다.

06  마무리: 서버는 그대로 운영에 쓴다

여기까지가 빈 우분투 서버를 받아서 워드프레스가 돌아가기까지의 기록입니다. 지금은 도메인 없이 IP로만 접속하는 상태지만, 이 서버는 연습용이 아니라 그대로 운영 서버가 됩니다. 나중에 도메인의 DNS만 이 서버 IP로 돌리고 SSL을 발급하면 완성될 것 입니다.

솔직히 시작 전엔 "관리형 호스팅 놔두고 굳이?" 싶었다. 그런데 막상 해보니 홈랩에서 하던 것과 결이 똑같았습니다. Nginx 설정 문법, 방화벽, 서비스 재시작 이미 손에 익은 것들이었습니다. 서버가 조금이라도 익숙한 사람이라면, 관리 대행에 웃돈을 내기 전에 직접 한번 세워보길 권합니다. 그 과정에서 만나는 500 에러 한 번이, 사실은 가장 값진 경험되어 네트워크 전문가로 가는 길에 빛을 비출 것이라고 생각합니다.