네이버 블로그 글은 줄바꿈을 바꾸면 AI에 인용될까

네이버 블로그에 쌓아둔 글을 홈페이지로 옮기면 AI 검색에서도 활용할 수 있을까. 이때 먼저 손봐야 할 대상으로 줄바꿈을 지목하는 설명이 있다. 문장을 짧게 끊어 쓰면 AI가 내용을 이해하지 못하므로, HTML의 줄바꿈 태그인 br를 문단 태그인 p로 바꿔야 한다는 주장이다.

이 설명을 그대로 따르면 기존 글의 편집 방식을 전부 바꾸거나 블로그를 다른 플랫폼으로 옮기는 데 돈과 시간을 쓰게 된다. 그런데 그 결정에는 빠진 질문이 있다. 줄이 나뉘었다는 사실이, 검색 서비스가 그 글을 읽지 못했다는 증거일까.

문단을 의미에 맞게 나누는 일은 필요하다. 하지만 줄바꿈만으로 AI 인용 여부를 설명할 수는 없다. 태그가 표현하는 구조, 프로그램이 꺼내는 텍스트, 검색 서비스가 답변에 연결하는 출처는 각각 살펴봐야 한다. 어디에서 문제가 생겼는지에 따라 고쳐야 할 대상도 달라진다.

줄바꿈과 문단 구분은 역할이 다르다

p는 문단을 나타내고, br는 그 자리에서 줄을 바꾼다. HTML 표준은 주소나 시처럼 내용 자체에 줄바꿈이 필요한 경우에 br를 쓰도록 설명한다. 문단 사이를 벌리는 용도로 줄바꿈을 반복하는 것과는 구분된다. HTML 표준의 문단 정의, 줄바꿈 정의

여기까지는 태그의 용법에 관한 설명이다. p가 완결된 문장을 보장한다는 뜻은 아니다. “신청 전에”라는 미완성 구절도 p로 감쌀 수 있다. 반대로 “신청자는 연락처와 희망 일정을 제출합니다”라는 문장 중간에 br를 넣어도 원문에서 단어가 없어지지는 않는다.

화면에 보이는 줄과 원고의 문장도 같지 않다. 같은 글이 넓은 모니터에서는 한 줄, 휴대전화에서는 세 줄로 보일 수 있다. 따라서 눈에 보이는 줄 수만으로 문장 구조가 잘못됐는지 판단하면, 화면 폭에 따른 줄바꿈까지 원고의 문제로 오해하게 된다.

같은 글도 추출 규칙에 따라 다르게 나왔다

서치코리아는 직접 만든 안내문을 서로 다른 HTML로 구성하고, 두 가지 간단한 추출 규칙으로 텍스트를 꺼내봤다. 그중 비교할 만한 것은 문장 중간을 br로 끊은 입력과, 같은 위치에서 p를 나눈 입력이다. 두 입력은 문구와 순서가 같고, 태그 사이에 별도의 공백 문자를 넣지 않았다.

아래는 두 입력의 앞부분이다. 줄을 바꾼 위치와 문구는 그대로 두고, 경계를 표현하는 태그만 달리했다.

한 규칙은 태그를 처리하지 않고 텍스트 조각만 이어 붙였다. 이 방식에서는 두 입력 모두 “신청 전에준비할 자료”처럼 어절 사이의 공백이 빠졌다. br를 p로 바꾼 쪽도 결과가 같았다.

다른 규칙은 br와 닫는 p를 만날 때 개행을 넣고, 연속된 공백을 하나로 정리했다. 이 방식에서는 두 입력 모두 “신청 전에 준비할 자료”로 추출됐다. 바뀐 것은 문장의 내용이 아니라 경계를 처리하는 규칙이었다.

이 결과가 보여주는 것은 특정 태그의 인용 효과가 아니다. 공백이 사라져 어절이 붙는 문제는 문단 태그를 쓰는 것만으로 해결되지 않을 수 있으며, 같은 원문도 추출 방식에 따라 다르게 나온다. 이번 확인은 직접 작성한 HTML과 추출 코드에 한정된다. 네이버 편집기의 실제 저장 방식이나 Google·ChatGPT의 내부 처리를 재현한 실험은 아니다.

읽을 수 있는 글과 답변에 쓰이는 글 사이에는 단계가 더 있다

Google의 생성형 검색 안내는 완벽한 시맨틱 HTML을 요구하지 않는다고 명시한다. 의미에 맞는 HTML은 화면 낭독기 등으로 페이지를 이용하는 데 도움이 되지만, 코드가 완벽해야 Google이 내용을 이해하는 것은 아니라는 설명이다. Google의 기술 구조 안내

그렇다면 본문이 정상적으로 읽히는데도 왜 답변에 나오지 않을까. 읽을 수 있는 페이지라도 그 질문에 필요한 정보가 없을 수 있다. 이 경우 문장의 경계를 아무리 정확하게 표현해도 답의 근거가 될 내용은 생기지 않는다.

가령 고객이 “행사 촬영을 맡길 때 자막 편집까지 포함되나요”라고 묻는다고 하자. 글 전체가 촬영 장비와 현장 분위기를 소개하는 데 쓰였다면, 문단 구조가 아무리 정돈돼 있어도 그 질문에 답할 정보는 없다. 필요한 것은 태그 교체보다 서비스에 포함되는 작업과 제외되는 작업에 관한 설명이다.

이때 원고에서 “자막 작업을 지원합니다”라고만 쓰면 여전히 판단이 어렵다. 발언 전체를 옮기는 자막인지, 주요 장면에만 넣는 자막인지, 번역도 포함되는지에 따라 고객이 이해하는 서비스가 달라지기 때문이다. 답변할 내용을 충분히 갖추는 작업은 문장을 짧게 만드는 작업보다 앞선다.

기존 글을 옮기기 전에 한 편부터 판단하는 방법

먼저 그 글로 답하려는 고객의 질문을 하나 정한다. “이 회사는 무슨 일을 하나”보다 “기존 홈페이지의 콘텐츠를 수정해서 AI 검색에 대응할 수 있나”처럼, 읽은 뒤 독자가 결정을 내려야 하는 질문이 적합하다. 그다음 현재 원고에서 답이 되는 문장을 찾아본다.

답이 없다면 제목과 태그를 바꾸기 전에 내용을 보강해야 한다. 수정할 수 있는 항목, 새로 만들어야 할 항목, 작업에 필요한 접근 권한, 완료 여부를 확인하는 방법을 구체적으로 설명하는 식이다. 업체 소개 문장을 반복하는 것보다 실제 작업의 경계를 알려주는 편이 이 질문에는 직접적이다.

답은 있는데 외부에서 본문을 가져왔을 때 핵심 문장이 빠진다면, 원고와 별개로 게시 방식이나 접근 설정을 점검해야 한다. HTML의 텍스트에 없는 이미지 속 설명을 찾는 경우와, 텍스트는 있지만 접근이 막힌 경우는 해결할 일이 다르다. 단순히 “AI가 못 읽는다”고 묶으면 어느 쪽을 고쳐야 할지 알 수 없다.

답도 있고 본문도 정상적으로 전달된다면, 그다음은 실제 질문에서 어떤 출처가 제시되는지 관찰할 차례다. 서비스와 질문, 실행 날짜, 답변 전체, 연결된 페이지를 함께 남겨야 다음 확인과 비교할 수 있다. 한 번 인용되지 않았다는 이유만으로 줄바꿈을 원인으로 지목하지 않는다.

홈페이지 이전도 이 과정에서 판단해야 한다. 콘텐츠 구조나 주소, 수정 권한을 직접 관리할 필요가 있는지 살펴볼 수는 있다. 그러나 “네이버에 썼으니 AI가 읽지 못한다”는 설명만으로 이전을 결정할 근거는 부족하다. 글의 내용이 부족한 문제는 장소를 옮겨도 남고, 전달 과정의 문제는 문장을 늘려도 해결되지 않는다. 먼저 어느 문제인지 찾아야 수정할 일이 줄어든다.

자료 확인일은 2026년 10월 13일이다. 텍스트 추출 예제는 10월 12일 작성한 코드와 입력·출력을 재확인했다. 전체 결과 중 문장 중간을 나눈 두 입력을 비교했다. 추출 코드·HTML 입력·전체 실행 결과는 아래 자료 내려받기에서 확인할 수 있다. Python 코드는 TXT 파일로 제공하며 실행할 때 마지막 .txt를 지우면 된다. 검토한 주장의 맥락은 아래 원문 링크에서 확인할 수 있다.