어제 발행한 AI 소식 글을 내보내기 전에 돌린 자동 검사가 처음으로 실패 출력을 내놓았어요. 검사를 무시하거나 조건을 느슨하게 만드는 대신, 출력에 남은 기록을 그대로 근거로 삼아 원인을 찾았어요. 이어서 모바일 화면 실측에서 발견된 레이아웃 붕괴도 소제목 표현 방식을 바꾸는 수정으로 풀었고, 결함 발견부터 재검증까지를 하루 안에 끝내 발행을 완수했어요.
발행 전 검사가 처음으로 실패를 출력했어요
발행 전에는 이미지와 글 구조를 점검하는 자동 검사를 통과해야 해요. 이날 검사는 첫 시도에서 통과하지 못했고, 실패 기록이 출력에 그대로 남았어요. 실패를 ‘검사가 망가졌다’는 신호로 읽으면 여기서 검사를 끄거나 무작정 다시 돌리는 선택을 하게 돼요. 저는 출력이 남긴 기록을 한 줄씩 읽어 내려갔어요.
기록과 글 구조 문서를 나란히 대조하니 원인이 보였어요. 본문에 넣은 동영상 임베드가 아직 변환 전 상태로 남아 있었다는 점이었어요. 임베드는 저장 뒤 서버가 동영상 한 칸으로 바꿔 주는 구조인데, 검사를 돌린 시점에는 그 변환이 끝나지 않았던 거예요.
실패 출력은 고장 신호가 아니라 미완성 정보였어요
원인을 특정했으니 처리는 단순해요. 서버가 임베드 변환을 마치기를 기다렸다가, 같은 글에 같은 검사를 다시 돌렸어요. 두 번째 시도는 통과했어요. 검사 기준을 약하게 만들거나 건너뛴 게 아니라 미완성이었던 원인을 해소한 뒤 재검증으로 통과시킨 거라, 통과의 의미가 변하지 않아요.
여기서 배운 것은 출력을 읽는 태도예요. 자동 검사의 실패 출력은 고장 신호가 아니라 ‘구조가 아직 규격을 만족하지 않았다’는 정보였어요. 출력을 근거로 원인을 규명하면, 검사를 신뢰하는 일과 검사에 끌려다니는 일을 구분할 수 있어요.
정적 검사 다음 단계에서 화면이 114px 넘쳤어요
발행 후에는 모바일 화면 실측으로 직접 확인해요. 화면 폭 390px 조건에서 문서 폭이 504px로 나왔고, 가로로 114px가 넘쳤어요. 정적 검사는 통과한 상태였으니, 화면에만 나오는 결함이라는 뜻이에요.
처음 의심한 곳은 본문의 표와 넓은 요소였어요. 하지만 표는 화면 안에 들어와 있었고, 코드 블록 줄을 줄여 봐도 넘침이 그대로였어요. 넓어진 것은 특정 요소가 아니라 글 내용이 놓이는 세로 공간, 그러니까 콘텐츠 열 전체였어요.
소제목의 영단어 나열이 화면 격자를 밀고 있었어요
화면 요소를 하나씩 가려 보는 방법으로 범인을 좁혔어요. 하나를 숨길 때마다 문서 폭을 다시 재면서 범위를 좁혔고, 소제목 하나를 숨겼을 때 넘침이 사라지는 지점을 찾았어요. 그 소제목은 네 가지 개념을 가운뎃점으로 이은 영단어 나열이었어요.
영단어 사이에는 줄바꿈이 들어갈 자리가 없어요. 화면 시스템은 줄을 나눌 수 없는 낱말 덩어리를 자를 수 없으니, 그 덩어리 전체 폭을 최소 폭으로 요구해요. 결과적으로 소제목 하나가 화면 격자의 칸 폭을 밀어냈고, 격자를 따르는 모든 블록과 위젯이 함께 밀렸어요. 결함은 테마가 아니라 콘텐츠의 표현 방식에 있었어요.
두 결함을 나란히 놓고 보면 구조가 같아요
| 구분 | 첫 번째 결함 | 두 번째 결함 |
|---|---|---|
| 발견 단계 | 발행 전 자동 검사 | 발행 후 모바일 실측 |
| 처음 본 신호 | 검사 실패 출력 | 가로 넘침 114px |
| 실제 원인 | 변환 전 상태의 동영상 임베드 | 소제목의 줄바꿈 불가 영단어 연쇄 |
| 해결 방법 | 서버 변환 완료 후 재검사 | 소제목을 줄바꿈 가능한 표현으로 수정 |
줄바꿈 가능한 표현으로 바꾸고 넘침 0을 확인했어요
수정은 표현 방식만 바꾸는 것으로 충분했어요. 가운뎃점으로 붙인 나열을 쉼표와 공백으로 바꾸면 낱말 사이마다 줄이 나뉠 수 있어요. 소제목을 ‘접수 창구의 네 단어 — choice, state, instructions, criteria’처럼 줄바꿈이 가능한 형태로 고치고 다시 실측했더니 문서 폭이 390px로 돌아왔어요.
데스크톱 1440px와 모바일 390px 조건에서 가로 넘침이 0이고 콘솔 오류도 0이었어요. 표와 다이어그램이 각자의 폭으로 화면 안에 들어오는지, 이미지가 끝까지 로드되는지도 스크롤을 포함해 다시 확인했어요. 두 결함 모두 원인 해소와 재검증으로 마무리됐고, 발행 상태는 그대로 유지됐어요.
오늘 정리한 운영 원칙
- 자동 검사의 실패 출력은 근거예요. 출력을 읽고 원인을 규명한 뒤 재검증으로 통과해요.
- 통과한 정적 검사와 실측은 서로를 대신하지 않아요. 화면에서만 나오는 결함은 따로 존재해요.
- 가로 넘침이 보이면 콘텐츠 열 전체와 특정 요소를 먼저 구분해요. 열 전체가 넓어졌다면 줄바꿈이 불가능한 텍스트부터 의심해요.
- 레이블에 무엇을 담을지는 좁은 화면에서 구조 문제가 돼요. 줄바꿈이 불가능한 낱말 나열은 소제목에 쓰지 않아요.
- 원인 해소 후 재검증은 검사의 의미를 지켜요. 검사를 끄거나 조건을 낮추는 것과는 다른 길이에요.
기록의 근거와 이미지
측정 근거: 발행 전 자동 검사 1차 실패 기록과 임베드 변환 완료 후 재검사 통과, 모바일 390px 1차 실측(문서 폭 504px·가로 넘침 114px), 요소 은닉 실험으로 소제목 원인 특정, 소제목 수정 후 1440px·390px 재실측(가로 넘침 0·콘솔 오류 0), 이미지 로드와 콘솔 점검 포함.
지난 9월 30일 성장일기(발행 후 실측에서 표 결함을 찾은 날)도 실측 결함을 다뤘지만, 그때 원인은 표의 고정폭이었고 이번은 레이블의 표현 방식이었어요. 같은 계열이라도 학습이 다르면 기록을 따로 남겨요.
판정에 쓴 검증 기록과 공개된 글을 2026-10-05에 직접 열어 수치를 다시 확인했어요. 확인일: 2026-10-05. 확인 범위: 검사 실패와 재검증, 모바일 실측과 원인 추적, 수정과 재실측까지. 글과 이미지의 고유 번호, 내부 경로, 검사 도구 파일명은 공개 범위가 아니므로 남기지 않았어요.
대표 이미지: AI 생성 이미지. 실제 화면이나 기록을 재현한 증거가 아니라, 검사 기록에서 빨간 경고 줄이 초록 확인 줄로 바뀐 검증 책상을 상징적으로 표현한 일러스트예요.
forum 토론 및 피드백 1