Data In Hands

OCI WordPress 도메인 연결과 HTTPS 설정 가이드

OCI WordPress 도메인과 HTTPS: 브라우저·서버·인증서 연결 개념 그림

OCI에서 운영하는 WordPress에 도메인을 연결하고 HTTPS를 구성할 때 확인해야 할 항목을 정리했습니다. Oracle Linux 8과 Apache를 사용하는 예시이며, 실제 설치 방식과 접속 경로에 맞게 검토해야 합니다.

도메인이란 무엇일까요?

도메인은 방문자가 사이트에 접속할 때 사용하는 이름입니다. ‘datainhands.com’처럼 기억하기 쉬운 이름을 쓰면 서버 IP가 바뀌어도 DNS를 조정해 같은 사이트 주소를 유지할 수 있습니다.

🤔 OCI WordPress 사이트에 도메인이 특별히 더 필요한 이유

OCI 컴퓨트 인스턴스에서 WordPress를 운영할 때는 도메인을 쓰면 방문자 주소와 서버 위치를 분리해 관리할 수 있습니다. 다만 다음 효과는 관련 설정이 함께 갖춰져야 합니다:

  1. 보안 인증서(SSL) 설정의 용이성
    • 이 글은 도메인 인증서를 사용하는 예시이며, IP 인증서는 별도 지원 조건과 갱신 주기를 확인해야 함
    • 도메인이 있으면 Let’s Encrypt 무료 인증서 사용 가능
  2. 사이트 주소와 서버 위치의 분리
    • IP 변경 시 DNS를 조정해 방문자 주소를 유지할 수 있음
    • 도메인 자체가 데이터베이스 연결·백업·복원의 성공을 보장하지는 않음
  3. 클라우드 환경의 유연성 활용
    • 인스턴스 재생성이나 확장 시에도 동일 주소 유지
    • 로드 밸런서 적용이나 지역 확장이 용이

도메인 연결 전 준비사항

시작하기 전에 다음 항목들을 확인해주세요:

  1. 도메인 구매와 접근 권한 구매한 도메인과 도메인 관리 페이지 접근 권한이 필요합니다. 가비아, 고대디 등 신뢰할 수 있는 업체에서 구매하시면 됩니다.
  2. 서버 정보 확인 OCI 컴퓨트 인스턴스의 공인 IP 주소를 메모해두세요. 콘솔에서 쉽게 확인할 수 있습니다.
  3. WordPress 관리자 접근 WordPress 관리자 페이지에 접속할 수 있는 계정 정보가 필요합니다.

DNS 설정하기: 도메인과 서버 연결의 시작

NAME.COM - Manage DNS Records
NAME.COM - Manage DNS Records

DNS 설정은 도메인 연결의 첫 단계입니다. 도메인 구매처의 관리 페이지에서 다음과 같이 설정합니다:

1. A 레코드 설정 A 레코드는 도메인을 서버의 IP 주소와 직접 연결합니다

NAME.COM - Add A record
NAME.COM - Add A record
[A 레코드]
Host: @ (또는 비워두기)
Answer: [여러분의 OCI 인스턴스 IP]
TTL: 3600

2. www 설정 www가 붙은 주소도 동작하도록 CNAME 레코드를 추가합니다

[CNAME 레코드]
Host: www
Answer: datainhands.com
TTL: 3600
NAME.COM - Add CNAME
NAME.COM - Add CNAME

WordPress 설정 업데이트

WordPress의 주소 설정을 새 도메인에 맞게 변경합니다. 잘못 설정하면 사이트에 접속하지 못할 수 있으므로 신중히 진행하세요.

WordPress 관리자 페이지의 ‘설정 > 일반’ 메뉴에서:

Wordpress - General Settings
WordPress - General Settings
  1. WordPress 주소(URL) 변경
  2. 사이트 주소(URL) 변경

WordPress 주소는 설치 파일 위치, 사이트 주소는 방문자가 접속하는 주소입니다. 루트에 설치한 예시에서는 같을 수 있지만, 하위 디렉토리 설치에서는 달라질 수 있습니다. DNS·웹서버·HTTPS 연결과 복구 경로를 먼저 확인한 뒤 실제 구성에 맞게 변경하세요.

wordpress - change wordpress/site URL
wordpress - change wordpress/site URL

  1. 변경사항 저장

    • 설정 저장 후 새로운 도메인으로 리다이렉트될 때까지 대기

Apache 웹서버에서 도메인 설정하기

이 예시는 OCI의 Apache 기반 WordPress 구성을 다룹니다. OCI를 사용한다고 웹서버가 항상 Apache인 것은 아닙니다. 설치된 웹서버와 실제 설정 파일을 확인한 뒤 도메인 설정을 검토하세요.

먼저 터미널에 접속해서 가상 호스트 설정을 시작합니다. 가상 호스트란 하나의 서버에서 여러 웹사이트를 운영할 수 있게 해주는 Apache의 기능입니다.

sudo mkdir -p /etc/httpd/sites-available
sudo mkdir -p /etc/httpd/sites-enabled

이 디렉토리 구조는 설정 파일을 관리하는 한 가지 방식입니다. 디렉토리를 만들거나 심볼릭 링크를 추가하는 것만으로 Apache가 읽지는 않습니다. 실제 Include 경로와 기존 설정의 중복 여부를 확인해야 합니다.

이제 도메인을 위한 설정 파일을 만들어봅시다:

sudo nano /etc/httpd/sites-available/yourdomain.com.conf

아래는 경로와 도메인을 설명하는 구성 예시입니다. 괄호로 붙인 예시 설명은 Apache 지시어가 아니며, 로그 변수와 경로도 배포판에서 제공되는지 확인해야 합니다. 그대로 운영 설정에 넣지 말고 실제 구성에 맞게 검토하세요:

<VirtualHost *:80>
       ServerName yourdomain.com
       ServerAlias www.yourdomain.com (ex. www.datainhands.com)
       DocumentRoot /var/www/html

       <Directory /var/www/html>
           Options Indexes FollowSymLinks MultiViews
           AllowOverride All
           Require all granted
       </Directory>

       ErrorLog ${APACHE_LOG_DIR}/error.log
       CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>

이 설정은 웹서버에게 몇 가지 중요한 정보를 알려줍니다:

  • 해당 IP·포트의 가상 호스트 후보 중 요청 이름에 맞는 구성을 선택하도록 한다
  • www.yourdomain.com도 같은 가상 호스트 이름으로 매칭한다. 별도 Listen 설정과 인증서 이름은 각각 확인해야 한다
  • 웹사이트 파일은 /var/www/html 디렉토리에 있다
  • .htaccess 파일을 통한 설정 변경을 허용하겠다

원본 설정을 백업하고 포함 경로·문법을 확인한 뒤 적용하세요. 아래 restart 예시는 요청을 중단할 수 있으므로 실제 서비스의 reload/graceful 지원과 복구 절차를 먼저 검토해야 합니다.

# 심볼릭 링크 생성
sudo ln -s /etc/httpd/sites-available/yourdomain.com.conf /etc/httpd/sites-enabled/ (ex. datainhands.com.conf)
   
# httpd.conf에 설정 디렉토리 포함
echo "IncludeOptional sites-enabled/*.conf" | sudo tee -a /etc/httpd/conf/httpd.conf
   
# 서버 재시작
sudo systemctl restart httpd

SSL 인증서로 안전한 HTTPS 설정하기

발급받은 인증서를 실제 사이트가 사용하는지도 확인해야 합니다. 브라우저의 인증서 정보가 예상과 다르면 DNS가 가리킨 서버와 해당 사이트의 웹 서버 설정을 대조하세요.

SSL 인증서로 웹사이트와 방문자 사이의 통신을 암호화합니다. 다음은 Oracle Linux 8 환경에서 HTTPS를 구성하는 순서입니다.

먼저 필요한 도구를 설치합니다:

1. 기본 패키지 설치

먼저 EPEL 저장소와 certbot을 설치합니다:

# EPEL 저장소 추가
sudo dnf -y install oracle-epel-release-el8

# certbot 및 Apache 플러그인 설치
sudo dnf -y install certbot python3-certbot-apache

2. SSL 기본 환경 구성

아래는 임시 자체 서명 인증서 예시입니다. 도메인 검증이나 Certbot 설치의 필수 단계는 아닙니다. Apache가 참조하는 경로와 적용 목적을 먼저 확인하세요:

# SSL 인증서 디렉토리 생성
sudo mkdir -p /etc/pki/tls/certs

# 임시 자체 서명 인증서 생성
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/pki/tls/private/localhost.key \
-out /etc/pki/tls/certs/localhost.crt

# 웹서버 재시작
sudo systemctl restart httpd

자체 서명 인증서는 일반 방문자의 브라우저가 자동으로 신뢰하지 않습니다. 생성 질문의 기본값만으로 도메인 이름이나 신뢰가 검증되지 않으며, 브라우저 경고를 우회해 운영용 HTTPS 확인을 대신해서는 안 됩니다.

3. Let's Encrypt 인증서 발급받기

이제 무료지만 신뢰할 수 있는 Let’s Encrypt 인증서를 발급받습니다:

# 인증서 발급 (Apache 자동 설정)
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

Apache 플러그인은 선택한 인증 방식과 지원되는 구성에서 다음 작업을 수행합니다. 도메인 검증 경로와 설치 권한이 갖춰져야 하며, 리다이렉트는 실제 선택·설정 결과를 확인해야 합니다:

  1. 도메인 소유권을 확인하고
  2. SSL 인증서를 발급받고
  3. Apache 설정을 업데이트하고
  4. 선택한 옵션과 구성에 따라 HTTPS 리다이렉션을 설정합니다

4. 자동 갱신 설정하기

인증서의 만료 전에 주기적으로 갱신 필요 여부를 확인해야 합니다. 유효기간과 갱신 기준은 인증서 프로필·Certbot 버전에 따라 달라지므로 90일 간격으로 갱신한다고 가정하지 마세요:

# 갱신 테스트 실행 
sudo certbot renew --dry-run 

# 자동 갱신 서비스 상태 확인 
sudo systemctl status certbot-renew.timer

 

Let’s Encrypt Certificate - Setting Up Automatic Renewal
Let’s Encrypt Certificate - Setting Up Automatic Renewal

이 예시 timer가 inactive라면 해당 unit이 현재 실행 대기 중이 아니라는 뜻입니다. 다른 이름의 timer나 cron이 갱신을 담당할 수 있으므로, 자동 갱신 전체가 꺼졌다고 단정하지 말고 설치 방식과 기존 스케줄러를 확인하세요.

Check Certificate Expiry Date

이미지의 VALID: 44 days는 그 시점의 남은 유효기간입니다. 이 값만으로 이전 갱신 성공·실패를 판정할 수 없습니다.
이 글에 사용된 과거 인증서는 90일 유효기간 예시이며 현재 모든 인증서에 적용되는 값은 아닙니다. 실제 인증서 프로필과 갱신 기록을 별도로 확인해야 합니다:

자동 갱신 활성화 방법:
certbot-renew.timer 가 실제 설치된 갱신 unit인 경우에만 아래 활성화 예시가 적용됩니다. timer 활성 상태 자체는 갱신 성공을 보장하지 않습니다.

sudo systemctl enable certbot-renew.timer
sudo systemctl start certbot-renew.timer

해당 unit의 실행 대기 여부를 확인하고, 별도로 서비스 실행 결과와 갱신 로그를 점검하세요. 아래의 Active: active (waiting)표시는 대기 상태였고, 인증서 갱신 성공의 증거는 아닙니다

sudo systemctl status certbot-renew.timer
Activate Certbot Renew Timer
Activate Certbot Renew Timer

이미지는 과거 상태 출력의 예시입니다. 현재 서버 상태를 보여주는 증거는 아닙니다. 당시 certbot-renew.timer가 활성화(active) 상태였고, 다음 실행 시간이 2025-02-09 19:36:02 GMT로 표시됐다는 의미입니다. 현재 unit 이름·일정과 동일하다고 가정하지 마세요.

이 예시의 일정은 12시간마다 갱신 확인을 보여줍니다. 실제 주기는 설치된 스케줄러에 따릅니다. 확인 작업의 실행과 실제 인증서 갱신은 구분해야 합니다.

과거 예시 인증서는 90일 동안 유효했지만, 모든 프로필이 같은 기간을 쓰지는 않습니다.
과거 버전의 30일 기준 갱신 설명도 현재 버전의 기준으로 고정해서 적용하면 안 됩니다. 설치 버전과 인증서 프로필을 확인하세요. certbot renew 명령어는 매번 실행되지만, 인증서의 유효기간이 충분히 남아 있으면 실제로는 갱신되지 않습니다.

자동 갱신 활성화 방법 2:
cron은 timer 대신 사용할 수 있는 스케줄러입니다. 기존 갱신 작업을 먼저 확인하고 중복 실행·불필요한 reload를 피하도록 운영 방식을 정하세요.

다음 명령으로 편집 화면을 엽니다. cron 예시는 실제 설치 경로·권한·일정을 검토한 뒤 사용하세요.

sudo crontab -e

그리고 편집창에서 아래와 같은 줄을 추가합니다.

0 2 * * * certbot renew --quiet && systemctl reload httpd

위 cron 항목은 매일 새벽 2시에 Certbot으로 인증서 갱신 필요 여부를 확인하고, 갱신이 필요한 인증서의 갱신을 시도합니다.
Certbot이 종료 코드 0으로 끝나면 Apache 설정을 다시 읽도록 reload를 요청합니다. 갱신할 인증서가 없어도 종료 코드가 0일 수 있으므로, 실제 인증서 갱신 없이도 reload가 요청될 수 있습니다.

5. 보안 설정 마무리하기

필요한 네트워크 경로와 SELinux 권한을 각각 확인하세요. 아래 network-connect boolean은 httpd의 외부 연결 권한이며 일반적인 TLS 수신 허용 스위치가 아닙니다. HTTPS와 HTTP-01 검증 경로도 구분해야 합니다:

# SSL 접근 권한 부여 
sudo setsebool -P httpd_can_network_connect 1 

# HTTPS 포트 허용 
sudo firewall-cmd --permanent --add-service=https 
sudo firewall-cmd --reload

브라우저의 연결 정보를 열어 HTTPS 사용 여부와 인증서 이름·유효기간·신뢰 체인을 확인하세요. 아이콘은 브라우저마다 다르며 사이트 전체의 안전성을 보장하지 않습니다.

HTTPS 구성만으로 검색 순위 향상을 약속할 수는 없습니다. 우선 방문자 연결의 보안과 올바른 HTTPS URL 전달을 확인하세요.

마지막 점검사항

설정 후에는 DNS 응답, 인증서와 WordPress 주소를 확인하세요.

1. DNS 전파 확인하기
도메인 설정이 전 세계에 전파되려면 시간이 좀 걸립니다. 다음 명령어로 확인해보세요:

ping yourdomain.com

2. SSL 인증서 확인하기
브라우저에서 실제 도메인의 연결 정보와 인증서·리다이렉트·혼합 콘텐츠를 확인합니다. 아이콘 하나만으로 전체 구성이 검증되지는 않습니다.

3. WordPress 주소 확인하기
관리자 대시보드에서 모든 URL이 새 도메인으로 잘 바뀌었는지 확인합니다.

DNS 응답, 실제 HTTPS 요청, WordPress 관리자와 방문자 경로를 각각 확인한 뒤 적용 결과를 판단하세요. 설명을 따라 설정했다는 사실만으로 운영 환경의 정상 동작이 입증되지는 않습니다.

문제 해결 가이드

도메인 연결에 문제가 생기면 다음 증상별로 확인하세요.

DNS 응답, 접속 경로, 서비스 리스너와 애플리케이션 오류를 나눠 확인하세요. 특정 원인이 대부분이라고 단정하지 말고 발생 시각과 요청에 맞는 로그를 대조해야 합니다:

사이트 접속이 되지 않는 경우

사이트에 접속이 되지 않는다면, 먼저 DNS 설정이 제대로 전파되었는지 확인해야 합니다. 재귀 DNS의 캐시는 TTL과 기존 응답에 따라 갱신됩니다. 모든 환경에 적용되는 고정 대기 시간이나 전 세계 전파 완료 시점은 없습니다.

다음 명령어로 DNS 설정을 확인해보세요:

ping yourdomain.com
nslookup yourdomain.com

응답 IP가 다르다고 DNS 갱신 지연만 원인인 것은 아닙니다. CDN·프록시·로드 밸런서를 경유하면 인스턴스 IP와 달라도 정상일 수 있습니다. 실제 권한 DNS의 A/AAAA/CNAME과 조회한 리졸버의 캐시를 구분하고, ping 무응답은 HTTPS 실패나 DNS 오류로 단정하지 마세요.

SSL 인증서 관련 문제

SSL 인증서와 관련된 문제는 대부분 인증서 발급 과정이나 Apache 설정에서 발생합니다. 다음 단계로 문제를 확인해보세요:

# Apache 설정 문법 검사
sudo apache2ctl configtest

# SSL 인증서 상태 확인
sudo certbot certificates

# Apache 오류 로그 확인
sudo tail -f /var/log/httpd/error.log

오류 로그는 원인을 좁히는 자료입니다. 요청 시각·접속 경로와 함께 대조해야 하며 로그 하나로 원인이 확정되지는 않습니다. 로그에서 ‘SSL’ 또는 ‘certificate’ 관련 오류 메시지를 찾아보세요.

WordPress 관리자 페이지 접속 문제

도메인 변경 후 관리자 페이지에 접속할 수 없는 경우가 있습니다. 저장된 URL과 상수, DNS·웹서버·HTTPS 연결 중 어느 단계에서 실패했는지 먼저 구분해야 합니다. URL 적용값을 임시로 지정하는 다음 예시는 모든 접속 장애를 해결하는 방법이 아닙니다:

wp-config.php 파일에 다음 두 줄을 추가합니다:

define('WP_HOME','https://yourdomain.com'); 
define('WP_SITEURL','https://yourdomain.com');

이 상수는 데이터베이스의 home/siteurl 값을 바꾸지 않고 적용값을 덮어씁니다. 상수가 정의된 동안 해당 관리자 URL 항목은 편집할 수 없습니다. 원본과 복구 경로를 확보한 뒤 저장된 URL을 안전하게 바로잡고 상수를 해제해야 합니다.
먼저 상수만 지우면 잘못된 저장값으로 되돌아가 다시 접속을 잃을 수 있습니다.

유지보수 체크리스트

도메인을 연결한 뒤에도 인증서와 갱신 작업, DNS 설정을 정기적으로 확인하세요.

매월 확인할 사항

자동 갱신 확인 주기와 실제 만료일·실행 결과를 함께 점검해야 합니다. 월간 점검은 운영 기록 검토의 예시일 뿐이며, 짧은 유효기간의 인증서에는 더 빠른 실패 감지와 대응이 필요합니다:

# SSL 인증서 상태 확인
sudo certbot certificates

# 자동 갱신 서비스 상태 확인
sudo systemctl status certbot-renew.timer

분기별 확인 사항

3개월마다 한 번씩은 좀 더 깊이 있는 점검이 필요합니다:

  1. 도메인 만료일 확인
  2. DNS 설정 이상 여부 점검
  3. Apache 설정 파일 백업
  4. 보안 업데이트 설치

 

정기 점검에서 이상을 발견하면 원인을 확인하고 조치하세요.

도메인 연결과 관리에 관한 질문은 댓글로 남겨주세요.

위로 스크롤