WordPress는 어떻게 하나의 웹페이지를 만들어낼까?

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 겪은 경험과 WordPress, PHP, MariaDB, Docker 공식 문서를 참고해 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종적으로는 운영자가 직접 내용을 검토하고 확인했습니다.

WordPress는 어떻게 하나의 웹페이지를 만들어낼까?

도입

이번 주에는 WordPress와 MariaDB를 중심으로 홈서버에서 웹서비스가 어떻게 동작하는지 살펴봤습니다. 월요일에는 데이터베이스가 어디에 사용되는지 정리했고, 화요일에는 WordPress가 왜 데이터베이스를 필요로 하는지 확인했습니다.

수요일에는 Docker에서 WordPress와 MariaDB를 연결했고, 목요일에는 설치 후 기본 설정을 점검했습니다. 금요일에는 PHP 메모리와 성능 설정을 살펴봤고, 토요일에는 MariaDB 상태값과 쿼리 응답 속도를 숫자로 확인해봤습니다.

그런데 이 모든 내용을 하나로 연결하면 어떤 그림이 될까요? 방문자가 블로그 글 하나를 클릭했을 때, 서버 안에서는 어떤 순서로 일이 진행될까요?

이번 글에서는 한 주 동안 배운 조각들을 하나의 흐름으로 이어보려고 합니다. 방문자가 주소를 입력한 순간부터 브라우저에 웹페이지가 나타날 때까지, WordPress가 어떻게 하나의 화면을 만들어내는지 차근차근 따라가 보겠습니다.

방문자의 요청이 Browser → Web Server → PHP → WordPress → MariaDB를 거쳐 HTML 페이지로 생성되는 전체 구조를 한눈에 정리한 6주차 종합 다이어그램입니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

① 방문자가 주소를 입력한다

모든 과정은 방문자가 브라우저에 주소를 입력하거나 검색 결과에서 글 제목을 클릭하는 순간부터 시작됩니다. 사용자는 단순히 글 하나를 보려고 클릭했을 뿐이지만, 서버 입장에서는 새로운 요청이 들어온 것입니다.

방문자
↓
브라우저
↓
https://example.com/sample-post/

이 요청에는 어떤 주소로 접속했는지, 어떤 브라우저를 사용하는지, 어떤 파일이나 페이지가 필요한지 같은 정보가 함께 전달됩니다. WordPress는 이 요청을 바탕으로 어떤 글을 보여줄지 판단하게 됩니다.

처음에는 웹페이지가 이미 완성된 파일로 서버에 놓여 있고, 브라우저가 그 파일을 가져오는 방식이라고 생각하기 쉽습니다. 하지만 WordPress는 대부분의 경우 요청이 들어올 때 필요한 정보를 조합해 화면을 만들어냅니다.

② 웹서버가 요청을 받는다

브라우저의 요청은 먼저 웹서버에 도착합니다. 홈서버 환경에서는 Nginx나 Apache 같은 웹서버가 이 역할을 맡을 수 있습니다. 웹서버는 들어온 요청을 보고 정적인 파일을 바로 줄지, PHP로 넘겨야 할지 판단합니다.

Browser
↓
Web Server
↓
PHP 처리 필요 여부 판단

이미지나 CSS 파일처럼 이미 존재하는 정적 파일은 웹서버가 직접 전달할 수 있습니다. 하지만 WordPress 글 페이지처럼 데이터베이스와 테마, 플러그인을 거쳐 만들어야 하는 화면은 PHP 실행 과정으로 넘어갑니다.

이 지점에서 웹서버는 안내자 역할에 가깝습니다. 요청을 받아 적절한 처리 경로로 넘기고, 나중에 완성된 결과를 다시 브라우저로 돌려보냅니다.

③ PHP가 WordPress를 실행한다

WordPress는 PHP로 동작합니다. 그래서 동적인 페이지를 만들기 위해서는 PHP가 WordPress 파일을 읽고 실행해야 합니다. 이 과정에서 WordPress의 핵심 파일들이 불러와지고, 필요한 설정도 함께 읽힙니다.

Web Server
↓
PHP
↓
WordPress Core
↓
wp-config.php

여기서 wp-config.php는 중요한 역할을 합니다. WordPress가 어떤 데이터베이스에 접속할지, 데이터베이스 이름은 무엇인지, 사용자와 비밀번호는 무엇인지 같은 연결 정보가 이 설정과 관련되기 때문입니다.

Docker 환경에서는 이 연결 정보가 환경변수로 들어가기도 합니다. 중요한 것은 WordPress가 혼자 실행되는 것이 아니라, PHP를 통해 동작하고 데이터베이스 연결 정보를 바탕으로 MariaDB와 통신한다는 점입니다.

④ WordPress가 MariaDB에 질문한다

WordPress가 실행되면 이제 필요한 데이터를 찾아야 합니다. 방문자가 어떤 글 주소로 들어왔는지 확인하고, 그 글의 제목과 본문, 작성일, 카테고리, 태그, 댓글, 사이트 설정 등을 MariaDB에서 조회합니다.

WordPress
↓
MariaDB에 요청
↓
게시글 정보
댓글 정보
카테고리 정보
사이트 설정
사용자 정보

화요일 글에서 살펴봤듯이 WordPress는 글을 단순한 HTML 파일로 저장하지 않습니다. 게시글과 설정값 대부분은 MariaDB에 저장되어 있고, WordPress는 필요할 때마다 그 정보를 꺼내 화면을 구성합니다.

그래서 MariaDB가 응답하지 않으면 WordPress는 글을 가져올 수 없습니다. 이때 흔히 볼 수 있는 것이 데이터베이스 연결 오류입니다. 결국 WordPress 페이지가 열리는 과정에서 MariaDB는 보이지 않는 핵심 역할을 맡고 있습니다.

⑤ MariaDB가 데이터를 돌려준다

MariaDB는 WordPress가 요청한 데이터를 찾아 다시 돌려줍니다. 이때 데이터베이스가 빠르게 응답하면 페이지 생성도 자연스럽게 이어집니다. 반대로 쿼리가 느리거나 연결이 지연되면 WordPress 전체가 무겁게 느껴질 수 있습니다.

요청 데이터	MariaDB에서 하는 일	화면에 미치는 영향
게시글	제목, 본문, 작성일 조회	본문 표시
카테고리	분류 정보 조회	글 구조와 목록 표시
댓글	댓글과 승인 상태 조회	댓글 영역 표시
설정값	사이트 제목, 옵션 조회	사이트 기본 동작 반영
사용자	작성자 정보 조회	작성자 표시와 권한 확인

토요일에 살펴본 SHOW STATUS, mysqladmin status, Slow_queries 같은 값은 바로 이런 데이터베이스 응답 상태를 이해하기 위한 기본 신호였습니다.

⑥ WordPress가 HTML을 만든다

MariaDB에서 필요한 데이터를 받아오면 WordPress는 이제 화면을 만들기 시작합니다. 이때 테마가 디자인 구조를 담당하고, 플러그인이 추가 기능을 적용합니다. PHP는 이 모든 요소를 조합해 최종 HTML을 만들어냅니다.

DB Data
+
Theme
+
Plugin
+
WordPress Core
↓
HTML 생성

여기서 금요일에 살펴본 PHP 메모리와 OPcache 같은 성능 설정이 영향을 줄 수 있습니다. PHP가 WordPress를 실행하고 화면을 만드는 과정에서 충분한 메모리와 적절한 캐시가 있으면 반복 작업의 부담을 줄일 수 있기 때문입니다.

물론 플러그인이 많거나 테마가 무겁거나 이미지가 지나치게 크면 HTML이 만들어진 뒤에도 페이지가 느리게 느껴질 수 있습니다. 그래서 WordPress 성능은 하나의 설정만으로 결정되지 않고 여러 요소가 함께 맞물립니다.

⑦ 브라우저에 화면이 나타난다

WordPress가 만든 HTML은 다시 웹서버를 거쳐 브라우저로 전달됩니다. 브라우저는 HTML을 읽고, CSS와 이미지, 스크립트를 불러와 사용자가 볼 수 있는 화면으로 표시합니다.

HTML
↓
Web Server
↓
Browser
↓
웹페이지 표시

사용자 입장에서는 글 하나가 열린 것뿐입니다. 하지만 그 뒤에서는 브라우저, 웹서버, PHP, WordPress, MariaDB, 테마, 플러그인이 차례대로 움직였습니다.

이번 주에 따로따로 살펴본 내용들이 여기서 하나로 연결됩니다. MariaDB는 데이터를 기억하고, PHP는 WordPress를 실행하며, WordPress는 데이터를 조합해 HTML을 만들고, 웹서버는 그 결과를 브라우저로 전달합니다.

⑧ 이번 주 전체 흐름 다시 보기

이번 주에 다룬 내용을 하나의 흐름으로 정리하면 아래와 같습니다.

MariaDB 이해
↓
WordPress 데이터 구조 이해
↓
Docker에서 WordPress와 MariaDB 연결
↓
설치 후 기본 설정 점검
↓
PHP 메모리와 성능 최적화
↓
MariaDB 상태값과 쿼리 응답 확인
↓
WordPress 페이지 생성 흐름 이해

이렇게 보니 이번 주는 단순히 WordPress 설치 방법을 배운 것이 아니었습니다. WordPress가 하나의 웹페이지를 만들기 위해 어떤 구성 요소들과 함께 동작하는지 이해하는 시간이었습니다.

운영노트

아래 표는 WordPress가 하나의 웹페이지를 생성하는 과정에서 각 구성 요소가 맡는 역할을 정리한 운영 기록입니다.

구성 요소	역할	이번 주 연결 주제
Browser	사용자 요청 전송과 화면 표시	웹페이지 요청 흐름
Web Server	요청 수신과 응답 전달	웹서비스 구조
PHP	WordPress 실행	PHP 메모리와 성능 설정
WordPress	콘텐츠 조합과 화면 생성	설치와 기본 설정
MariaDB	글, 댓글, 설정 저장	데이터베이스 구조와 성능 확인
Docker	서비스 분리와 연결	WordPress와 MariaDB 컨테이너 연결

에디터의 해석노트

이번 주를 시작할 때는 WordPress 설치와 MariaDB 연결을 각각 따로 생각했습니다. 그런데 한 주를 지나고 보니 두 가지는 분리된 주제가 아니라 하나의 흐름 안에 있었습니다.

WordPress는 화면을 만들고, MariaDB는 데이터를 기억합니다. PHP는 WordPress를 실행하고, Docker는 각각의 서비스를 분리해서 관리할 수 있게 해줍니다. 처음에는 복잡해 보였지만, 요청이 흐르는 순서대로 보니 조금씩 이해가 되기 시작했습니다.

이번 주에 가장 크게 느낀 점은 설치보다 구조가 먼저라는 것입니다. 구조를 이해하고 나면 오류가 났을 때 어디를 봐야 하는지, 성능이 느릴 때 무엇을 확인해야 하는지 판단하기가 훨씬 쉬워집니다.

참고 링크 (References)

1. WordPress Database Description
2. Editing wp-config.php
3. PHP Introduction
4. MariaDB SHOW STATUS
5. Docker Compose Documentation

트러블슈팅

문제: WordPress 페이지가 열리지 않거나 느리게 표시됨

WordPress 페이지가 열리지 않을 때는 한 곳만 의심하기보다 요청 흐름을 단계별로 확인하는 것이 좋습니다. 브라우저에서 시작된 요청이 웹서버, PHP, WordPress, MariaDB 중 어느 지점에서 막혔는지 찾아야 합니다.

확인: 웹서버, PHP, WordPress, MariaDB, Docker 컨테이너 상태를 순서대로 점검

# 컨테이너 상태 확인
docker compose ps

# WordPress 로그 확인
docker compose logs wordpress --tail=100

# MariaDB 로그 확인
docker compose logs mariadb --tail=100

# 컨테이너 리소스 확인
docker stats

원인: 웹서버 포트 문제, PHP 메모리 부족, WordPress 설정 오류, MariaDB 연결 실패, Docker Network 문제, 플러그인 충돌

해결: 요청 흐름을 기준으로 문제 지점을 좁혀갑니다. 웹페이지가 아예 열리지 않으면 웹서버와 포트를 먼저 확인하고, 데이터베이스 오류가 보이면 MariaDB 연결 정보와 로그를 확인합니다. 느리게 열리는 경우에는 PHP 설정, 플러그인, MariaDB 상태값을 함께 살펴봅니다.

• 페이지가 아예 안 열림: 포트, 컨테이너 상태, 웹서버 로그 확인
• DB 연결 오류: DB_HOST, DB_USER, DB_PASSWORD, Docker Network 확인
• 관리자 화면 느림: PHP 메모리, 플러그인, MariaDB 상태값 확인
• 이미지 로딩 느림: 이미지 용량, 캐시, 업로드 설정 확인
• 쿼리 지연: Slow_queries와 slow query log 확인

이번 주에 배운 내용은 모두 이 문제 해결 흐름으로 연결됩니다. 구조를 알면 문제를 더 작은 단위로 나눠서 볼 수 있습니다.

마무리

WordPress는 단순히 글을 보여주는 블로그 프로그램처럼 보이지만, 실제로는 여러 구성 요소가 함께 움직이는 시스템이었습니다. 브라우저의 요청은 웹서버를 거치고, PHP가 WordPress를 실행하며, WordPress는 MariaDB에서 데이터를 가져와 HTML을 만들어냅니다.

이번 주에는 이 흐름을 하나씩 나눠서 살펴봤습니다. 데이터베이스의 역할, WordPress와 MariaDB의 연결, Docker 설치, 기본 설정, PHP 성능, MariaDB 상태값까지 모두 따로 배운 것처럼 보였지만, 마지막에는 하나의 웹페이지 생성 과정으로 연결되었습니다.

결국 홈서버 운영에서 중요한 것은 명령어를 많이 외우는 것이 아니라, 요청이 어떤 순서로 흐르는지 이해하는 일이라는 생각이 들었습니다. 이 흐름을 알고 나면 문제가 생겼을 때도 조금 더 침착하게 원인을 찾아갈 수 있습니다.

이번 주 핵심 체크포인트 10

• MariaDB는 WordPress의 게시글, 댓글, 설정값을 저장합니다.
• WordPress는 HTML 파일을 미리 저장하는 방식만으로 동작하지 않습니다.
• 방문자의 요청은 웹서버를 거쳐 PHP와 WordPress로 전달됩니다.
• PHP는 WordPress를 실행하는 핵심 런타임입니다.
• wp-config.php 또는 환경변수는 DB 연결의 핵심입니다.
• Docker에서는 localhost보다 서비스명이 중요할 수 있습니다.
• PHP 메모리와 업로드 제한은 WordPress 성능에 영향을 줄 수 있습니다.
• MariaDB 상태값은 mysqladmin status와 SHOW STATUS로 확인할 수 있습니다.
• Slow Query는 데이터베이스 성능 문제를 찾는 중요한 신호입니다.
• 구조를 이해하면 설치, 오류 해결, 성능 점검이 훨씬 쉬워집니다.

다음 주 예고

이번 주에는 WordPress와 MariaDB가 함께 웹페이지를 만들어내는 구조를 이해했습니다. 다음 주에는 이 구조를 실제 운영 환경에서 더 안전하게 유지하기 위해 백업, 복구, 데이터 보호와 관련된 내용을 살펴볼 예정입니다.

홈서버는 잘 설치하는 것도 중요하지만, 문제가 생겼을 때 다시 복구할 수 있어야 오래 운영할 수 있습니다. 다음 주에는 데이터를 어떻게 지키고, 어떤 기준으로 백업을 설계해야 하는지 차근차근 이어가 보겠습니다.

6주차를 마치며

이번 주에는 WordPress를 설치하는 방법보다 먼저 구조를 이해하는 데 집중했습니다. 처음에는 각각 따로 보였던 MariaDB, Docker, PHP, WordPress가 이제는 하나의 흐름으로 연결되기 시작했습니다.

다음 주에는 이 구조를 안전하게 운영하기 위한 백업과 복구를 살펴보면서 홈서버 운영의 또 다른 중요한 축을 이어가겠습니다.