서버 응답 시간을 줄이는 방법

첫 바이트까지의 대기와 화면 표시 시간

웹 데브는 첫 바이트까지의 시간인 TTFB를 페이지 로드 시작부터 브라우저가 HTML 응답의 첫 데이터를 받을 때까지 걸리는 시간으로 설명합니다. 따라서 TTFB는 서버 내부의 처리 시간만을 뜻하지 않으며, 화면 전체가 완성되는 시간도 아닙니다. 운영자가 화면이 늦게 나타난다는 이유만으로 서버 증설을 요청하면 실제 지연 구간과 다른 작업을 선택할 수 있습니다.

웹 데브는 주요 콘텐츠의 표시 시간을 분석할 때 초기 HTML 문서와 해당 콘텐츠에 필요한 리소스 요청을 먼저 조사하도록 안내합니다. 개발 담당에게는 HTML의 첫 응답을 기다린 기록과 이후 리소스를 받는 기록을 따로 요청합니다. 화면 표시가 늦다는 제보만 있는 상태에서는 서버 응답 개선 항목을 확정하지 않습니다.

이 표는 개발 담당에게 조사할 대상을 전달하기 위한 요청 목록입니다. 한 페이지에서 여러 문제가 함께 나타나면 각 항목의 기록을 연결하되, 모든 조치를 동시에 적용하는 계획부터 수립하지 않습니다. 원인에 관한 자료가 없는 항목은 추가 조사 대상으로 남깁니다.

HTTP 캐싱과 자원 추가의 적용 조건

구글은 마지막 크롤링 이후 페이지가 그대로인 경우 304 상태 코드로 응답하면 저장된 내용을 재사용하여 서버의 대역폭과 자원 소모를 줄일 수 있다고 설명합니다. 운영자는 개발 담당에게 변경 여부를 판단하는 처리와 실제 수정 내용이 응답에 반영되는 절차를 함께 요청합니다. 내용이 그대로라는 판단 없이 재사용 범위부터 넓히지는 않습니다.

구글은 서버 용량 때문에 크롤링이 어려운 경우 사업 여건에 맞게 서버 자원을 추가하는 방안을 안내합니다. 해당 상황의 예로 URL 검사 도구의 호스트 로드 초과를 제시합니다. 운영자는 이런 신호와 서버 기록을 연결해 증설 필요성을 판단하고, 페이지가 느리다는 제보만으로 용량 부족을 확정하지 않습니다.

개발 담당에게 요청할 실행 순서

운영자는 문제가 발생한 페이지와 이용 조건을 정리한 뒤 개발 담당에게 조사 요청을 전달합니다. 자료에는 페이지 제목, 접속 시각, 로그인 여부, 처음 접속했는지 다시 요청했는지를 포함합니다. 개발 담당은 이 조건에서 초기 HTML 응답 대기를 측정하고 요청 기록을 남깁니다.

1. HTML 요청을 먼저 지정합니다. 화면 캡처와 별도로 해당 문서의 첫 바이트 대기를 기록하고, 지연이 나타나는 조건을 기재합니다.
2. 캐싱, 용량 부족, 전달 거리 중 기록이 뒷받침하는 항목을 선택합니다. 개발 담당은 선택 이유와 수정 대상을 설명하고, 운영자는 내용 변경이나 접속 조건에 관한 자료를 전달합니다.
3. 변경한 항목을 기록한 뒤 같은 페이지를 다시 측정합니다. 개발 담당은 응답 대기의 변화와 정상적인 내용 전달 여부를 보고하고, 운영자는 완료 조건의 충족 여부를 판단합니다.

운영자가 준비할 자료에는 내용 수정 내역도 필요합니다. 개발 담당이 변경 없는 요청과 수정 뒤 요청을 각각 시험할 수 있도록, 최근 수정한 문장과 게시 상태를 알려줍니다. 자원 추가를 논의할 때는 이용이 집중되는 업무와 접속 상황을 전달하되 원인을 추정한 문장과 관측한 사실을 따로 기재합니다.

조치별 완료 조건과 재측정 자료

개발 담당의 결과 보고에는 변경한 설정, 적용 대상, 측정 조건, 응답 기록을 포함하도록 요청합니다. 캐싱 작업은 내용이 그대로인 요청과 내용이 수정된 요청의 결과를 모두 받아야 완료 여부를 판단할 수 있습니다. 자원 추가는 변경 전과 이용 조건이 크게 다르면 별도의 측정으로 기록합니다.

측정 중에 페이지 내용이나 전달 경로까지 함께 변경하면 어떤 작업이 응답 대기에 영향을 주었는지 가리기 어렵습니다. 가능한 범위에서 조치를 순차적으로 적용하고, 동시에 처리해야 했다면 함께 변경한 항목을 빠짐없이 기재합니다. 운영자는 보고서의 빠르다는 평가보다 원본 요청 기록과 적용 범위가 일치하는지를 대조합니다.

응답 대기가 줄었어도 본문이 오래된 상태로 전달되거나 필요한 접속이 실패하면 작업을 완료하지 않습니다. 개발 담당에게 오류가 발생한 조건을 전달하고, 해당 조치를 유지할지 수정할지 결정하도록 요청합니다. 성능 결과와 내용 전달 결과는 보고서에서 별도 항목으로 기록합니다.

CDN 적용 결과의 판정 범위

CDN 작업의 결과는 실제로 전달 경로를 변경한 요청을 기준으로 판단합니다. 웹 데브는 서버를 이용자와 지리적으로 가까운 곳에 배치하면 리소스 전송 시간을 줄일 수 있으며, 이를 위한 방법으로 CDN을 안내합니다. 파일의 전달 거리를 줄인 결과를 곧바로 HTML 응답 대기의 개선으로 기재하지 않습니다.

개발 담당에게는 CDN이 전달하는 대상에 초기 HTML 문서가 포함되는지, 일부 파일만 포함되는지 설명을 요청합니다. 파일만 전달 경로가 달라졌다면 그 파일의 전송 결과를 작업 성과로 기록합니다. HTML도 적용 대상이라면 해당 문서의 응답 기록으로 효과를 별도로 판정합니다.

웹 데브는 외부 출처에서 이미지를 전달할 때 추가 연결 비용이 발생할 수 있다고 설명합니다. 운영자는 CDN 적용 여부만 묻기보다 새 연결이 필요한 요청과 그 요청의 지연 자료를 개발 담당에게 요청합니다. 전달 거리가 짧아졌다는 설명만 있고 실제 요청 결과가 없다면 완료 판단을 유보합니다.

서로 다른 요청 결과의 혼용 방지

변경 전에는 처음 접속한 요청을 측정하고 변경 뒤에는 재사용된 요청을 측정했다면, 두 결과를 같은 조건의 개선으로 처리하지 않습니다. 첫 요청과 재요청은 보고서에서 따로 정리하고 각각 대응하는 기록끼리 대조합니다. 로그인 상태나 이용 위치가 달라진 측정도 조건 차이를 기재한 뒤 판단합니다.

HTML 응답 대기와 화면 표시 시간이 서로 다른 방향으로 달라질 수도 있습니다. 웹 데브는 한 구간에서 줄인 시간이 다른 지연 구간으로 이동하면 주요 콘텐츠의 표시 시간은 개선되지 않을 수 있다고 설명합니다. 운영자는 HTML 대기를 줄인 작업의 결과를 기록하면서 화면 표시 문제까지 해결됐다는 문장은 별도의 근거가 있을 때만 사용합니다.

변경 뒤에도 대기가 남으면 개발 담당에게 기존 조치를 더 확대하기 전에 남은 대기의 발생 위치를 설명하도록 요청합니다. 캐싱 작업을 했다는 사실만으로 서버 용량 부족을 제외하거나, 증설했다는 사실만으로 전달 경로 문제를 제외하지 않습니다. 추가 작업은 아직 해결되지 않은 요청 기록을 근거로 정합니다.

임시 공지와 예약 변경의 캐싱 경계

내용을 자주 수정하지 않는 페이지라도 일시적인 안내가 들어가면 캐싱 범위를 다시 판단해야 합니다. 운영자는 긴급 공지의 게시와 종료, 예약한 문구 변경처럼 응답 내용이 달라져야 하는 업무를 개발 담당에게 전달합니다. 평소 수정 빈도가 낮다는 이유로 이런 업무까지 같은 처리에 포함하지 않습니다.

캐싱 대상은 페이지 이름만으로 정하기보다 실제로 전달되는 내용의 변화 조건을 기준으로 정합니다. 개발 담당에게 본문 외에 공통 안내 문구가 변경되는 경우도 시험하도록 요청합니다. 업무 담당자가 수정한 곳과 서버가 변경 여부를 판단하는 범위가 다르면, 해당 조건을 수정 대상에 포함합니다.

이어서 읽을 주제

병원 홈페이지 리뉴얼은 개편 과정에서 서버 작업의 범위와 완료 조건을 어떻게 정할지 이어 읽을 주제입니다. 병원 영상 편집은 완성한 영상의 편집 작업과 사이트에 전달하는 기술 작업의 요청 범위를 따로 정리할 때 이어 읽을 주제입니다.