AI 초안 79편을 워드프레스에 넣어 보니, 69편은 본문 전체가 블록 하나였다
AI에게 초안을 받아 워드프레스에 올릴 때, 저는 완성된 HTML을 그대로 본문에 넣습니다. 화면에는 제목도 표도 코드도 제대로 나옵니다. 그래서 지금까지 문제가 있다고 생각해 본 적이 없었습니다. 오늘 두 블로그에 발행된 글 79편의 본문을 데이터베이스에서 꺼내 워드프레스가 그것을 어떻게 이해하는지 세어 봤습니다.
79편 중 69편은 본문 전체가 블록 하나로 잡혔습니다. 평균 4,830자짜리 글 한 편이 편집기에서는 나눌 수 없는 덩어리 한 개입니다. 그리고 그 69편에는 화면이 깨진 글이 하나도 없습니다. 오늘 잰 것은 그 두 가지가 어떻게 동시에 성립하는지입니다.
워드프레스가 본문을 나누는 기준
워드프레스는 본문을 HTML 태그가 아니라 주석으로 나눕니다. 편집기에서 문단 하나를 쓰면 본문에는 이렇게 저장됩니다.
<!-- wp:paragraph -->
<p>문단입니다.</p>
<!-- /wp:paragraph -->가운데 <p>는 브라우저가 그리는 데 쓰고, 바깥의 주석 두 줄은 워드프레스가 “여기부터 여기까지가 문단 블록 하나”라고 표시해 두는 것입니다. 브라우저는 주석을 무시하고 지나갑니다. 그래서 주석이 없어도 화면은 똑같이 나옵니다.
주석이 없는 본문을 워드프레스가 읽으면, 나눌 근거가 없으므로 전체를 이름 없는 덩어리 하나로 처리합니다. 편집기에서는 이것이 “클래식” 블록 한 개로 보입니다. 79편이 어느 쪽인지 세어 봤습니다.
| 구분 | 편수 | 비율 |
|---|---|---|
| 전체 발행 글 | 79 | 100% |
| 블록 주석이 하나라도 있는 글 | 10 | 12.7% |
| 블록 주석이 하나도 없는 글 | 69 | 87.3% |
본문 글자 수로 보면 더 뚜렷합니다. 두 블로그 본문을 합치면 380,677자인데, 그중 333,251자, 87.5%가 블록 주석 바깥에 있습니다. AI 초안을 다루는 쪽 블로그만 따로 보면 44편 203,610자가 전부, 100%가 바깥입니다. 블록 주석이 단 한 개도 없습니다.
언제부터 이렇게 됐나
발행한 달로 나눠 보면 시점이 분명합니다.
| 발행 월 | 글 수 | 글당 블록 주석 평균 | 블록 밖 글자 비율 |
|---|---|---|---|
| 2026년 6월 | 3 | 70.3 | 0.0% |
| 2026년 7월 | 37 | 15.2 | 81.6% |
| 2026년 8월 | 26 | 0.0 | 100.0% |
| 2026년 9월 | 13 | 0.0 | 100.0% |
6월에 쓴 세 편은 글당 평균 70개의 블록 주석을 가지고 있고 바깥에 남은 글자가 0입니다. 편집기 화면에서 블록을 하나씩 쌓아 만든 글입니다. 7월부터 비율이 뒤집히고, 8월 이후로는 한 개도 없습니다. 편집기를 거치지 않고 완성된 HTML을 본문에 바로 넣는 방식으로 바꾼 시점과 일치합니다.
바꾼 이유는 분명했습니다. 표가 다섯 개, 코드 블록이 두세 개 들어가는 글을 편집기에서 블록으로 조립하는 것보다, HTML로 한 번에 만들어 넣는 쪽이 훨씬 빠릅니다. 대신 블록 주석은 사람이 직접 쓰지 않으면 붙지 않습니다.
태그별로 얼마나 바깥에 있나
본문에 들어 있는 태그를 하나씩 세고, 각각이 블록 주석 구간 안에 있는지 밖에 있는지 나눴습니다.
| 태그 | 전체 | 블록 안 | 블록 밖 | 바깥 비율 |
|---|---|---|---|---|
| p 문단 | 2,237 | 433 | 1,804 | 80.6% |
| h2 소제목 | 539 | 89 | 450 | 83.5% |
| h3 작은 제목 | 155 | 44 | 111 | 71.6% |
| figure 표·이미지 틀 | 170 | 18 | 152 | 89.4% |
| table 표 | 151 | 18 | 133 | 88.1% |
| pre 코드 | 114 | 46 | 68 | 59.6% |
| ul 목록 | 89 | 37 | 52 | 58.4% |
| ol 번호 목록 | 25 | 2 | 23 | 92.0% |
| img 이미지 | 19 | 0 | 19 | 100.0% |
| blockquote 인용 | 10 | 0 | 10 | 100.0% |
어느 태그도 예외가 아닙니다. 그리고 여기서 한 가지가 눈에 띕니다. 블록 안에 있는 것들은 대부분 6월과 7월 초에 편집기로 만든 글의 몫입니다. 이미지와 인용은 블록으로 만든 것이 아예 없습니다.
클래스 이름도 같이 빠집니다
워드프레스가 블록으로 만든 태그에는 wp-block-으로 시작하는 클래스가 붙습니다. HTML을 직접 써 넣으면 그 클래스는 제가 쓴 만큼만 붙습니다. 어떤 태그에 붙었고 어떤 태그에 빠졌는지 세어 봤습니다.
| 태그 | 전체 | 클래스 있음 | 클래스 없음 |
|---|---|---|---|
| figure | 170 | 170 (wp-block-table 151, wp-block-image 19) | 0 |
| h2 | 539 | 83 (wp-block-heading) | 456 |
| ul | 89 | 37 (wp-block-list) | 52 |
| pre | 114 | 36 (wp-block-code) | 78 |
| table | 151 | 7 (has-fixed-layout) | 144 |
figure만 100%입니다. 제가 표와 이미지를 넣을 때 <figure class="wp-block-table"> 형태로 쓰기 때문입니다. 나머지는 맨 태그입니다. 소제목 539개 중 456개에 클래스가 없습니다.
목록이 가장 극단적입니다
태그 중에서 차이가 가장 크게 벌어진 것은 목록이었습니다. 목록을 가진 글과 목록 블록을 가진 글을 따로 세어 봤습니다.
| 구분 | 워드프레스 쪽 | AI 쪽 |
|---|---|---|
| 목록이 들어 있는 글 | 31편 | 31편 |
| ul과 ol 합계 | 73개 | 41개 |
| 그중 목록 블록으로 잡힌 것 | 39개 | 0개 |
양쪽 다 31편에 목록이 들어 있는데, 한쪽은 절반 이상이 블록이고 다른 쪽은 하나도 아닙니다. AI 쪽 41개는 전부 맨 <ul> 태그입니다.
블록으로 잡힌 39개를 따로 열어 보니 항목이 143개, 목록 하나당 평균 3.7개였습니다. 항목 하나는 평균 17.3자로 짧고, 절반 가까이가 세 개나 네 개짜리입니다. 그리고 39개 전부 바로 앞이 문단이었습니다. 문단으로 설명하고 목록으로 나열하는 형태가 그대로 남아 있습니다.
표와 견주면 쓰임이 갈리는 것도 보입니다. 79편에 표가 151개, 목록이 114개로 표가 1.3배 많습니다. 표는 79편 전부에 들어 있고 목록은 62편에 들어 있습니다. 나열할 것이 생기면 목록보다 표로 가는 쪽이 굳어져 있다는 뜻입니다. 이것은 블록 주석과는 다른 문제지만, 본문을 데이터로 꺼내지 않았으면 역시 보이지 않았을 부분입니다.
그런데 왜 화면은 멀쩡한가
여기가 오늘 잰 것 중 가장 중요한 부분입니다. 클래스가 빠지면 그 클래스를 노리는 스타일이 걸리지 않습니다. 그러면 표가 무너지거나 코드 블록이 흐트러져야 합니다. 실제로는 그렇지 않습니다. 두 가지를 확인했습니다.
첫째, 워드프레스는 블록별 스타일 파일을 그 블록이 쓰인 글에만 붙입니다. 그래서 블록 주석이 없는 글에는 붙일 근거가 없습니다. 두 블로그의 글 26편을 열어 실제로 어떤 스타일 파일이 붙었는지 봤습니다.
| 구분 | 페이지 수 | 표가 있는 페이지 | 표 스타일이 붙은 페이지 |
|---|---|---|---|
| 워드프레스 쪽 블로그 | 15 | 15 | 14 |
| AI 쪽 블로그 | 11 | 11 | 0 |
AI 쪽 블로그 11개 페이지는 블록 스타일 파일을 한 개도 불러오지 않습니다. 표도 코드 블록도 들어 있는데 그렇습니다.
둘째, 그런데도 표가 정상으로 보이는 이유는 테마가 같은 일을 이미 하고 있기 때문입니다. 테마 스타일시트를 열어 표에 걸리는 규칙을 찾아봤습니다.
global.min.css : table { margin:0 0 1.5em; width:100% }
content.min.css : .wp-block-table table { border-collapse:collapse }워드프레스의 블록 스타일이 넣어 주는 것이 border-collapse:collapse와 width:100%인데, 테마가 그 둘을 태그 이름만으로 이미 걸어 두었습니다. 그래서 블록 스타일이 안 붙어도 결과가 같습니다. 소제목 쪽도 마찬가지입니다. wp-block-heading을 노리는 규칙은 배경색이 지정된 제목에만 여백을 주는 것 하나뿐이고, 저는 제목에 배경색을 쓴 적이 없습니다.
정리하면, 87.5%가 블록 주석 밖에 있다는 사실이 화면에 나타나지 않은 것은 설계가 안전해서가 아니라 쓰고 있는 테마가 마침 그 자리를 덮고 있었기 때문입니다. 테마를 바꾸면 같은 본문이 어떻게 보일지는 보장되지 않습니다.
실제로 치르고 있는 값
화면이 아니라면 무엇을 잃고 있는지가 남습니다. 69편의 본문을 워드프레스가 어떻게 쪼개는지 다시 셌습니다.
| 항목 | 값 |
|---|---|
| 본문이 덩어리 하나뿐인 글 | 69편 (전부) |
| 그 덩어리가 본문에서 차지하는 비율 | 평균 100.0% |
| 덩어리 한 개의 글자 수 | 평균 4,830자 (중앙값 4,686) |
| 가장 긴 덩어리 | 8,054자 |
| 가장 짧은 덩어리 | 3,584자 |
69편 모두 예외 없이 덩어리 하나입니다. 편집기에서 이 글을 열면 표 하나만 고치려 해도 4,800자짜리 HTML 안에서 그 표를 찾아야 합니다. 문단을 위아래로 옮기는 기능도, 블록 단위 되돌리기도 쓸 수 없습니다.
그래서 바꿀 것인가
바꾸지 않기로 했습니다. 근거는 이렇습니다.
- 발행 후에 편집기에서 본문을 고치는 일이 지금은 없습니다. 고칠 것이 있으면 원본 HTML을 고쳐 다시 올립니다.
- 블록 주석을 붙이려면 발행 스크립트가 태그마다 짝이 맞는 주석을 넣어야 하고, 하나라도 어긋나면 편집기가 “이 블록에 예기치 않은 오류가 있습니다”를 띄웁니다. 지금 없는 문제를 만들 위험이 더 큽니다.
- 화면에 나타나는 차이는 오늘 확인한 범위에서 없습니다.
대신 조건을 적어 둡니다. 테마를 바꾸거나, 목차 생성처럼 블록 구조를 읽는 기능을 붙이거나, 편집기에서 직접 고치는 일이 생기면 그때는 87.5%가 그대로 비용이 됩니다. 그때 다시 재기 위해 오늘 숫자를 남깁니다.
정리
AI가 만들어 준 HTML은 브라우저 기준으로는 완전합니다. 태그가 닫혀 있고 표가 정상이고 제목 단계가 맞습니다. 부족한 것은 브라우저가 읽지 않는 부분, 워드프레스가 자기 구조를 표시해 두는 주석입니다. 그 주석은 눈에 보이는 어디에도 나타나지 않기 때문에, 79편을 발행하는 동안 한 번도 문제로 드러나지 않았습니다.
이런 종류의 어긋남은 화면을 보고는 찾을 수 없습니다. 표의 모양을 셌을 때나 숫자 표기를 셌을 때도 그랬듯이, 본문을 데이터로 꺼내 세어 봐야 나옵니다. 오늘 나온 숫자 중 가장 정직한 것은 87.5%가 아니라, 그 87.5%가 79편 동안 아무 증상도 만들지 않았다는 사실 쪽입니다. 증상이 없다는 것이 문제가 없다는 뜻은 아니고, 아직 그 자리를 다른 것이 덮고 있다는 뜻이었습니다.
