웹앱을 운영하면서 마주한 가장 큰 숙제는 "느리다"는 사용자 피드백과, SEO 성과 지표에서 조용히 쌓여가던 크롤링 오류입니다. 원인을 추적해 보니 세 가지 지표가 서로 맞물려 있었습니다. TTFB(Time To First Byte), 캐시 적중률, 그리고 검색 봇 재방문 시 응답 안정성. 이게 왜 중요하고, 어떻게 서로 연결되어 있는지, 어떤 방법으로 개선했는지 공유합니다.
TTFB 사용자 경험의 첫 관문
TTFB가 중요한 이유
TTFB는 사용자가 요청을 보낸 시점부터 서버로부터 첫 바이트를 받기까지 걸리는 시간입니다. 이 값이 크다는 건 단순히 "느리다"는 문제가 아니라, 그 뒤에 이어질 모든 렌더링과 상호작용의 시작점이 지연된다는 뜻입니다.
특히 콘텐츠 소비 중심의 페이지에서는 TTFB가 사용자 체감 속도의 대부분을 결정합니다. 사용자는 "검색 → 클릭 → 대기"의 흐름에서 이 대기 구간을 가장 민감하게 느끼기 때문입니다.
TTFB가 SEO에 미치는 영향
TTFB는 단순히 UX 지표가 아닙니다. Google의 Core Web Vitals에서 LCP(Largest Contentful Paint)는 TTFB를 포함하고 있고, 크롤러 역시 TTFB가 높으면 크롤링 예산(crawl budget)을 빠르게 소진합니다. 즉, TTFB가 느리면
- 사용자는 이탈하고
- 검색 엔진은 덜 방문하며
- 인덱싱되는 페이지 수가 줄어드는 악순환이 발생합니다.
개선 방향
공략 허브 TTFB 개선 과정에서 우리가 본 핵심 레버는 크게 세 가지였습니다.
- 서버 응답 경로 최적화: DB 쿼리, 외부 API 호출 등 블로킹 구간 축소
- 정적 응답 비중 확대: 동적으로 매번 만들어낼 이유가 없는 콘텐츠는 미리 만들어두기
- 엣지 캐시 활용: 최대한 사용자와 가까운 곳에서 응답하기
이 중에서도 두 번째와 세 번째는 곧바로 다음 주제인 캐시 적중률과 이어집니다.
캐시 적중률은 TTFB를 지탱하는 구조적 힘
캐시 적중률이 곧 TTFB다
TTFB를 개선하는 가장 강력한 방법은 "서버를 빠르게 만드는 것"이 아니라 "서버를 거치지 않는 것"입니다. 캐시 적중률이 올라가면
- 오리진 서버 부하가 줄고
- 응답은 엣지에서 즉시 반환되며
- TTFB는 수백 ms 단위에서 수십 ms 단위로 떨어집니다.
콘텐츠는 대부분 업데이트 주기가 명확하고, 읽기 요청이 쓰기 요청보다 압도적으로 많은 특성을 가집니다. 이런 특성은 캐시 친화적이지만, 반대로 캐시 설계가 잘못되면 그 잠재력을 전혀 끌어내지 못합니다.
캐시 적중률을 떨어뜨리는 흔한 원인
실무에서 캐시 적중률이 낮을 때 가장 흔히 발견되는 원인들입니다.
- 불필요하게 세분화된 캐시 키: 사용자별로 달라질 필요 없는 응답에 사용자 식별자가 들어가 있는 경우
- 지나치게 짧은 TTL: 변경 주기가 하루 단위인데 TTL을 1분으로 잡아둔 경우
- 쿼리 파라미터로 인한 키 분산:
utm_*같은 추적 파라미터가 캐시 키에 포함되어 같은 콘텐츠가 수십 개의 키로 쪼개지는 경우 - Vary 헤더 과다 설정:
Accept-Language,User-Agent등이 불필요하게 Vary에 포함되어 캐시가 파편화되는 경우
캐시 적중률을 올리는 관점
적중률을 높이는 작업은 결국 "무엇이 정말 요청별로 달라져야 하는가"를 다시 따져보는 일입니다. 많은 경우, 우리가 "동적"이라고 믿었던 부분이 사실은 하루에 한 번만 달라지면 충분한 콘텐츠였습니다. 이런 부분을 분리해내고, 공용 캐시로 옮기는 것만으로도 적중률은 크게 올라갑니다.
캐시 적중률 상승은 TTFB 개선의 가장 큰 기여 요인이었고, 동시에 오리진 서버의 부담을 줄여 다음에 이야기할 "안정성"까지 끌어올리는 기반이 되었습니다.
검색 봇 재방문 시 응답 안정성
봇은 사람보다 정직하다
사용자는 한 번 느리거나 오류를 만나도 다시 시도하거나 잊어버립니다. 하지만 검색 봇은 다릅니다. 봇은 방문할 때마다 응답 상태를 기록하고, 그 기록을 기반으로 크롤링 빈도와 인덱싱 여부를 결정합니다.
즉, 검색 봇이 재방문했을 때
- 5xx 에러를 만나면 → 일시적 장애로 판단, 크롤링 빈도 감소
- 타임아웃을 만나면 → 서버 상태 불량으로 판단, 크롤링 예산 회수
- 일관되지 않은 응답을 만나면 → 콘텐츠 신뢰도 하락
이런 신호가 누적되면 랭킹 하락으로 이어집니다. 그리고 가장 무서운 점은, 이 과정이 대시보드에서 잘 보이지 않는다는 것입니다. 사용자 트래픽은 멀쩡해 보여도, 봇 트래픽만 조용히 나빠지고 있을 수 있습니다.
왜 "재방문 시" 안정성이 특히 중요한가
검색 봇은 처음 발견한 페이지보다 이미 인덱싱한 페이지를 재방문하는 비중이 훨씬 큽니다. 재방문 시 응답이 불안정하면
- 인덱스에서 탈락하거나
- 갱신이 지연되어 오래된 내용이 노출되거나
- 사이트 전체의 신뢰도 평가가 낮아집니다.
공략 허브처럼 콘텐츠가 꾸준히 업데이트되는 사이트에서는 이 재방문 크롤링의 안정성이 곧 검색 노출의 생명선입니다.
안정성은 캐시에서 온다
재미있는 점은, 봇 응답 안정성을 가장 크게 끌어올린 요인도 결국 캐시 적중률 상승이었다는 것입니다. 이유는 단순합니다.
- 캐시 적중 시: 엣지에서 즉시 응답 → 오리진 장애와 무관하게 안정적
- 캐시 미스 시: 오리진까지 도달 → 부하 상황에서 타임아웃/에러 가능성↑
봇이 방문하는 URL 패턴은 대체로 고정적이므로, 이 URL들이 캐시에 잘 올라가 있으면 봇은 거의 항상 빠르고 일관된 응답을 받게 됩니다. 결과적으로 크롤링 빈도가 회복되고, 인덱싱 커버리지가 넓어집니다.
성능 개선은 종종 "서버를 키우자", "코드를 최적화하자"는 방향으로 흐르기 쉽습니다. 하지만 웹앱 개선 과정에서 배운 것은, 요청을 빠르게 처리하는 것보다 불필요한 요청을 하지 않는 것이 훨씬 강력하다는 점이었습니다.
그리고 이러한 효과는 일반 사용자에게만 돌아가지 않습니다. 검색 봇에게도 동일하게 작용하며, 그 영향은 장기적인 트래픽 성장으로 이어집니다.
