OCI WordPress 운영 가이드: 무료 조건·접속 장애·복구 기준

OCI 프리 티어로 WordPress를 시작하려면 설치 명령보다 먼저 계정에서 만들 수 있는 리소스와 복구 책임을 확인해야 합니다. 이 글은 2026년 4월의 구축 경험을 따라가되, 현재 무료 서버를 반드시 확보할 수 있다는 안내가 아니라 생성 전 확인과 운영 인수 기준을 다룹니다.

이 블로그는 2026년 4월 당시 OCI 프리 티어 인스턴스에 WordPress를 구성해 운영한 경험에서 시작했습니다. 서버 비용을 낮출 수 있다는 점은 분명 매력적이지만, “무료”라는 말만 보고 시작하면 리소스 제공 조건, 유료 전환 가능성, 보안 패치, 백업 책임을 놓치기 쉽습니다.

아래 내용은 당시 구축 흐름을 현재의 운영 점검 기준으로 다시 정리한 것입니다. OCI의 무료 대상 리소스와 한도는 바뀔 수 있으므로 인스턴스를 만들기 전에 Oracle Cloud Free Tier 공식 문서와 콘솔의 예상 비용을 확인하세요.

무료 서버와 무료 운영은 다릅니다

프리 티어 대상 컴퓨트 자원을 선택해도 도메인, 외부 백업, 유료 네트워크 기능, 리소스 한도 초과 등에서 비용이 생길 수 있습니다. 또한 서버를 직접 운영하면 운영체제와 WordPress 업데이트, 침해 대응, 장애 복구도 사용자의 책임입니다.

원문에 적었던 특정 CPU·메모리·트래픽 수치는 2026년 4월 당시 구성과 기록입니다. 현재 모든 계정에서 같은 구성이 제공된다고 단정하지 않습니다.

체험 크레딧과 상시 무료 대상을 섞지 않습니다

Oracle 공식 Free Tier 문서는 기간 제한이 있는 Free Trial과 Always Free를 구분합니다. 체험 크레딧으로 만든 유료 리소스는 계정을 업그레이드하지 않으면 체험 종료 뒤 회수된다고 설명합니다. 따라서 “현재 청구가 없다”와 “이 리소스가 Always Free 대상이다”를 같은 의미로 읽지 않습니다.

생성 전에는 선택한 리소스 이름, 무료 대상 표시, 계정 유형, 체험 종료 뒤 처리 조건을 함께 적어두는 것을 권합니다. 이 글에서는 특정 계정의 콘솔이나 리전 용량을 확인하지 않았습니다.

• 비용 조건을 설명할 수 없으면: 생성을 보류하고 공식 조건과 콘솔 표시의 차이를 먼저 확인합니다.
• 무료 자원을 확보하지 못하면: 유료 셰이프를 대신 선택하기 전에 비용과 운영 목적을 다시 결정합니다.
• 서버 외부에 복구 자료가 없으면: 설치 실습과 실제 블로그 이전을 분리하고 운영 데이터 투입을 미룹니다.

설치 후 인수 기준을 더 구체화하려면 백업 생성과 WordPress 복구 검증의 차이를 함께 확인하세요. 홈페이지가 열리는 것과 서버를 잃어도 되살릴 수 있는 것은 다른 완료 조건입니다.

구축 전에 역할을 네 층으로 나눕니다

1. OCI 네트워크: VCN, 서브넷, 보안 목록 또는 네트워크 보안 그룹
2. 서버: Ubuntu 방화벽, SSH, 패키지 업데이트
3. 웹 스택: Nginx, PHP-FPM, MariaDB
4. WordPress: 관리자, 테마·플러그인, 업데이트, 백업

접속이 안 될 때 이 층을 섞어서 바꾸면 원인을 찾기 어렵습니다. DNS가 서버 IP를 가리키는지, OCI 수신 규칙이 열렸는지, 서버가 포트를 듣는지, Nginx가 올바른 사이트 설정을 읽는지를 순서대로 확인합니다.

1. 인스턴스와 SSH 접근을 준비합니다

1. OCI 콘솔에서 무료 대상 표시가 있는 셰이프와 이미지인지 확인합니다.
2. 공개 키를 등록하고 개인 키는 외부에 공유하지 않습니다.
3. 공인 IP 사용 여부와 재생성 시 주소 변경 가능성을 확인합니다.
4. SSH 접속 후 운영체제와 아키텍처를 기록합니다.
5. 백업·복구 계획이 없으면 운영 데이터를 먼저 올리지 않습니다.

SSH는 비밀번호 로그인보다 키 인증을 우선하고, 개인 키의 권한을 제한합니다. 관리자 권한 명령을 실행하기 전에 현재 서버와 작업 경로가 맞는지 확인하세요.

2. HTTP와 HTTPS만 필요한 범위에서 엽니다

OCI 네트워크 규칙과 서버 내부 방화벽은 별도 계층입니다. 공개 WordPress라면 일반적으로 웹 트래픽에 80·443 포트가 필요하지만, 데이터베이스 포트는 인터넷에 공개하지 않습니다. SSH 22번 포트도 가능한 범위에서 접속 원본을 제한합니다.

원문에는 특정 iptables 규칙 번호를 전제로 한 명령이 있었습니다. 규칙 순서는 서버마다 달라 그대로 실행하면 기존 정책을 바꿀 수 있으므로 삭제했습니다. 현재 사용하는 방화벽 도구의 상태와 기존 규칙을 먼저 읽고, 변경 후 새 연결과 기존 SSH 연결을 모두 확인해야 합니다.

3. 웹 스택은 버전과 경로를 확인하며 설치합니다

당시에는 Ubuntu에 Nginx, MariaDB, PHP-FPM을 설치하는 LEMP 구성을 사용했습니다. 패키지 이름과 PHP 소켓 경로는 Ubuntu 버전과 저장소에 따라 달라질 수 있습니다. 설치 예시를 복사하기 전에 현재 LTS 버전, WordPress의 공식 요구 사항, 배포판이 제공하는 PHP 버전을 비교하세요.

• Nginx와 PHP-FPM 서비스가 실행되고 재부팅 후에도 시작되는지 확인합니다.
• 데이터베이스는 WordPress 전용 사용자와 데이터베이스를 사용합니다.
• 비밀번호를 셸 기록, 블로그 글, 공개 저장소에 남기지 않습니다.
• 웹 루트 소유권을 일괄 변경하기 전에 필요한 쓰기 범위를 확인합니다.
• 설치가 끝나면 사용하지 않는 기본 사이트와 테스트 파일을 정리합니다.

WP-CLI를 사용할 경우에도 공식 배포 경로와 체크섬을 확인하고, 관리자 비밀번호나 이메일을 명령 기록에 남기지 않는 방법을 선택합니다. 이 글에는 실제 비밀값이 들어간 완성 명령을 제공하지 않습니다.

4. DNS와 TLS는 전파·갱신까지 확인합니다

1. 도메인의 A 레코드가 현재 서버 공인 IP를 가리키게 설정합니다.
2. DNS 조회 결과가 바뀐 뒤 HTTP로 해당 가상 호스트가 열리는지 확인합니다.
3. Certbot 등 사용하는 ACME 클라이언트의 공식 절차로 인증서를 발급합니다.
4. HTTP에서 HTTPS로의 이동과 인증서의 도메인 이름을 확인합니다.
5. 자동 갱신 설정뿐 아니라 갱신 시험 결과와 만료일도 기록합니다.

인증서 자동 갱신이 설정됐다는 메시지만으로 다음 갱신 성공을 보장할 수는 없습니다. 방화벽, DNS, 패키지 변경 뒤에는 다시 시험합니다.

접속 실패는 증상별로 한 층씩 확인합니다

이 표는 원문 네 층 구성을 진단 순서로 풀어쓴 것이며 각 증상의 원인을 확정하는 표는 아닙니다. 변경 전 상태를 기록하고 한 층씩 확인해야, 우연히 접속이 회복된 것을 원인 해결로 오해하지 않습니다.

운영 시작 전에 백업과 복구를 확인합니다

캐시 플러그인은 작은 인스턴스의 부하를 줄이는 데 도움이 될 수 있지만, 특정 플러그인이 모든 환경에서 정답은 아닙니다. 페이지가 실제로 캐시되는지, 로그인 사용자와 동적 페이지가 잘못 캐시되지 않는지 확인합니다.

운영 인수 때는 로그아웃 상태에서 HTTPS 홈페이지와 대표 글이 열리는지, 재부팅 후 Nginx·PHP-FPM·데이터베이스가 정상 시작되는지도 확인합니다. 백업 위치·시각과 격리 복구 시험 결과를 함께 남깁니다.

운영 기록: 준비 완료와 복구·배포 완료의 차이

2026-04-01 기록: 사이트 정비와 점검의 부작용

이전 후 운영 준비로 연락처 페이지(ID 161), ads.txt, 개인정보처리방침·연락처 메뉴와 소유권 확인을 정리했다. 13편에 H2와 내부·외부 링크, 포커스 키워드를 보강한 것도 그날의 작업량이다. 승인 결과나 검색 유입 증가를 측정한 수치가 아니며, H2 4~6개·내부 링크 3개 같은 당시 분량을 모든 글에 강제할 규칙으로 삼지 않는다.

점검 중에는 게이트웨이 복구용 테스트 메시지가 실제 사용자 Telegram 대화로 나간 실수도 있었다. LaunchAgent의 entrypoint는 entry.js를 가리켰지만 실제 파일은 index.js였고, openclaw doctor --fix로 고아 세션 파일 8개를 정리했다고 기록했다. 외부 임베딩 API 키가 없어 쓰지 못하던 검색은 기존 Ollama의 nomic-embed-text로 설정했다. 이 명령·경로는 과거 조치 이력이며 현재 서버에 그대로 실행할 처방은 아니다. 복구 확인도 실제 사용자 대화가 아닌 격리된 대상으로 해야 한다는 실패 사례로 남긴다.

2026-04-14 기록: 백업 보관과 의도적인 정지

829MB 백업 데이터의 보관과 30일을 넘긴 백업 정리를 확인했다. 이 크기는 해당 날짜의 생성·보관 이력이지 무결성 검사나 격리 복구 시험 결과가 아니다. 같은 날 King 봇은 사용자 지시에 따라 자동 재시작을 취소하고 수동 재개 전까지 멈춰 두었다. 운영 점검은 모든 프로세스를 켜는 일이 아니라 의도한 상태를 유지하는 일이기도 하다.

2026-04-24 기록: 백업은 됐지만 rsync와 API 확인은 실패

새벽 백업은 backups/oci/2026-04-24에 4.8GB로 완료됐다고 기록했다. 그러나 프로젝트 보드의 로컬 status.yaml 재생성과 lint 통과 뒤 OCI 배포에서는 rsync가 timeout됐고 대시보드 API는 connection refused였다. 로컬 원본이 갱신된 것과 사용자가 보는 운영 화면에 반영된 것은 다른 상태였다.

같은 날 밤 22시 일기 cron도 300초 timeout으로 끝났고, 확인 당시 4월 24일 글은 publish와 draft 어느 쪽에도 없었다. GPT-5.5 설정 전환과 doctor 점검이 있었지만 이 기록만으로 timeout 원인을 모델이나 제한 시간 하나에 돌릴 수 없다. 백업 성공, 배포 실패, 생성 결과 부재를 분리해 남겨야 재시도 위치를 정할 수 있다. 이 사례들의 복구 완료나 현재 서비스 상태는 이번 편집에서 새로 검증하지 않았다.

대표 사례 기준일: 2026-04-01. 통합 게시 기록: 2026-04-01~2026-04-24. 2026-09-03 무료 제공 단정과 환경 의존 명령을 정리했고 2026-09-10 운영 기준을 보완했습니다. 현재 OCI 요금·한도·리전 용량·서버 사양과 실제 복원 결과는 이번 편집에서 확인하지 않았습니다.

편집: 2026-09-13. 기존 기록의 구조를 정리한 것으로 새 실행·성능 시험이나 현재 서비스 상태 확인을 뜻하지 않습니다.