사전 렌더링(프리렌더)을 쓰는 경우

빌드 단계에서 만드는 본문 HTML

웹 개발 문서인 웹 데브는 정적 사이트 생성 또는 사전 렌더링을 요청 시점이 아닌 빌드 단계에서 HTML 페이지를 생성하는 방식으로 설명합니다. 운영자는 이 설명을 바탕으로 방문 요청 전에 공개할 본문을 확정할 수 있는지 판단해야 합니다. 사이트 제작에 사용한 기술 이름만으로 적용 가능성을 정하지 않고, 본문을 가져오는 시점과 HTML을 만드는 과정을 개발 담당에게 설명하도록 요청합니다.

빌드는 사이트를 공개할 파일을 만드는 작업으로 이해하면 됩니다. 사전 렌더링을 적용하려면 이 작업에서 페이지에 들어갈 내용과 그 내용을 가져올 자료에 접근할 수 있어야 합니다. 화면의 테두리나 메뉴만 미리 생성하고 주요 설명은 나중에 불러오는 구조라면, 본문 전달이라는 목적에 맞게 작업 범위를 다시 정해야 합니다.

자바스크립트 의존과 적용 가능성

구글 검색 센터는 일부 자바스크립트 사이트의 초기 HTML에 실제 콘텐츠가 없어, 페이지 내용을 읽으려면 자바스크립트 실행이 필요하다고 설명합니다. 또한 모든 크롤러가 자바스크립트를 실행할 수 있는 것은 아니므로 사전 렌더링을 좋은 방법으로 제시합니다. 운영자는 공개할 설명이 초기 HTML에 있는지부터 조사하고, 빠진 내용을 빌드 단계에서 생성할 수 있는지 개발 담당에게 묻습니다.

본문이 이미 응답 HTML에 충분히 포함되어 있다면, 자바스크립트를 사용한다는 이유만으로 사전 렌더링을 추가할 필요는 없습니다. 반대로 본문이 실행 뒤에만 생성되더라도 빌드 때 필요한 자료를 확보할 수 없다면 현재 구조 그대로 적용하기 어렵습니다. 이런 페이지는 구현 가능성과 자료 공급 방식을 함께 논의하고, 이름이 같은 기능을 도입하는 것으로 작업을 끝내지 않습니다.

본문 의존부터 적용 결과까지의 순서

운영자는 개발 담당에게 사이트 전체의 도입 가능성보다 후보 페이지의 본문 전달 과정을 먼저 설명하도록 요청합니다. 후보마다 공개할 문장과 내용을 수정하는 업무가 달라질 수 있으므로, 페이지 유형과 운영 조건을 함께 전달합니다. 화면 이미지에만 의존하지 않고 본문 텍스트와 수정 경로를 준비합니다.

1. 본문 전달의 자바스크립트 의존을 조사합니다. 운영자는 공개해야 할 주요 문장을 추리고, 개발 담당은 해당 문장이 응답 HTML에 있는지와 실행 뒤에 추가되는지를 대조합니다.
2. 빌드 단계의 HTML 생성 가능성을 확인합니다. 개발 담당은 본문 자료를 가져올 수 있는 시점과 생성할 페이지 범위를 설명하고, 운영자는 내용 수정 후 필요한 공개 절차를 합의합니다.
3. 적용 결과의 본문 전달을 재확인합니다. 개발 담당은 배포된 페이지의 응답 HTML을 확보하고, 운영자는 승인한 본문 및 실제 렌더링 결과와 대조해 누락이나 오래된 문장을 기록합니다.

운영자가 준비할 자료에는 후보 페이지 목록, 공개할 본문, 내용을 수정하는 위치, 수정 후 공개 승인 절차를 포함합니다. 개발 담당에게는 현재 응답 HTML과 본문을 가져오는 과정, 빌드 및 배포 절차를 설명할 자료를 요청합니다. 서로 다른 자료가 같은 페이지와 같은 수정본을 가리키도록 페이지 이름과 수정 이력을 함께 기재합니다.

페이지 범위와 갱신 방식의 기록

적용 범위는 운영자가 공개할 내용을 정하고 개발 담당이 생성 가능성을 판단한 뒤 확정합니다. 도입할 페이지 이름만 기록하면 본문 일부가 여전히 실행에 의존하는지 놓칠 수 있습니다. 아래 항목은 사이트의 실제 페이지에 맞게 채우는 작업 기록이며, 각 행이 도입을 권장하는 페이지 유형을 뜻하지는 않습니다.

내용 갱신은 편집 화면에서 저장하는 업무와 생성 파일을 공개하는 업무를 따로 기록합니다. 두 업무가 연결되는 방식에 따라 편집을 마쳤어도 공개 페이지에는 이전 본문이 남을 수 있기 때문입니다. 운영 담당과 개발 담당은 누가 재생성을 시작하고 누가 공개 결과를 승인하는지 정하며, 실패했을 때 전달할 담당도 명시합니다.

생성 파일과 실제 응답의 차이

적용 완료의 판단 대상은 빌드 작업이 성공했다는 기록보다 공개 페이지가 전달하는 본문입니다. 생성한 파일에 내용이 있어도 다른 파일이 배포되거나 이전 응답이 전달되면 방문 요청에서 받는 본문은 달라질 수 있습니다. 개발 담당은 생성 결과와 공개 페이지의 응답을 연결해 검사하고, 운영자는 승인한 문장이 전달되는지 대조합니다.

미리 만든 HTML의 주요 설명과 렌더링 뒤의 설명이 서로 다른 경우에는 차이가 생긴 이유를 가려야 합니다. 실행 뒤 최신 문장으로 교체되는 구조라면, 실행하지 못하는 환경에는 이전 설명이 전달될 수 있습니다. 운영자는 문장 수만 비교하지 않고 조건, 대상, 예외처럼 의미를 결정하는 내용이 같은 수정본인지 검사합니다.

구글 서치 콘솔 도움말은 렌더링된 페이지의 스크린샷을 통해 요소가 존재하고 의도대로 표시되는지 확인할 수 있다고 설명합니다. 운영자는 이를 화면 표시를 조사하는 자료로 활용하되, 스크린샷만으로 요청에 응답한 HTML의 본문까지 판단하지 않습니다. 개발 담당이 확보한 응답 HTML과 화면 결과를 각각 기록해 본문 전달과 표시 상태를 따로 평가합니다.

내용 수정 뒤의 재생성 시험

처음 공개한 페이지가 정상이어도 내용 수정이 같은 방식으로 반영되는지는 별도 시험이 필요합니다. 운영자는 승인 가능한 수정 내용을 준비하고, 개발 담당은 앞에서 정한 절차에 따라 재생성과 배포를 진행합니다. 수정 전후의 본문을 기록해 공개 응답과 렌더링 결과가 어느 수정본을 전달하는지 판단합니다.

문장 수정뿐 아니라 새 페이지 추가와 기존 내용 삭제도 운영 절차에 포함합니다. 수정한 상세 본문은 반영됐지만 목록 설명은 이전 상태로 남는 식의 불일치가 있는지 조사할 수 있습니다. 재생성이 실패하면 새 내용을 공개했다고 처리하지 않도록, 완료 통보의 조건을 실제 배포 결과와 연결합니다.

작업 기록에는 적용 페이지, 사용한 본문 수정본, 생성 결과, 공개 응답, 남은 차이를 기재합니다. 모든 차이를 렌더링 실패로 단정하지 않고 편집 누락, 생성 누락, 배포 누락 가운데 어느 단계에서 발생했는지 개발 담당에게 설명을 요청합니다. 해결되지 않은 페이지는 완료 목록에서 제외하고 후속 작업 대상으로 관리합니다.

외부 자료를 가져오지 못한 빌드

빌드 단계에서 외부 자료를 가져오지 못했을 때 어떤 HTML을 생성하는지도 적용 판단에 포함합니다. 오류 안내만 담긴 파일이나 본문이 빈 파일을 정상 결과처럼 배포한다면, 평소에는 내용을 전달하던 페이지도 자료 공급 실패 때 달라질 수 있습니다. 개발 담당에게 필요한 자료가 없을 때 생성을 중단하는지, 이전 공개본을 유지하는지, 실패 사실을 누구에게 전달하는지 묻습니다.

운영자는 실패 상태에서 공개해도 되는 내용의 조건을 정합니다. 이전 설명을 유지할 수 없는 변경이라면 배포를 보류할 담당과 승인 절차를 명시하고, 내용 없이 생성된 페이지가 완료 처리되지 않도록 작업 기록에 실패 상태를 남깁니다.

이어서 읽을 주제

병원 홈페이지 리뉴얼은 제작 구조를 변경할 때 내용 편집과 공개 절차를 함께 정하는 문제를 이어 읽는 데 도움이 됩니다. 병원 홈페이지 SEO는 생성된 페이지의 본문 전달 외에 검색 접근과 페이지 설명을 어떤 항목으로 관리할지 이어 읽을 주제입니다.