CDN을 붙였는데 왜 빨라지지 않을까

“CDN을 붙이면 사이트가 빨라진다”는 말은 대체로 맞지만, 그 말을 듣고 붙였는데 체감이 바뀌지 않는 경우도 그만큼 흔합니다. 그리고 그 이유를 설명해 주는 자료는 대개 “캐시가 안 맞아서”에서 멈춥니다. 그래서 다음에 무엇을 봐야 할지 알 수 없는 채로, 애드온을 더 사거나 CDN을 도로 걷어내는 쪽으로 갑니다.

이 글은 CDN이 무엇인지 처음 설명하는 글이 아닙니다. CDN을 켰는데 왜 효과가 갈리는지, 그 갈림이 어디서 결정되는지를 원리로 정리합니다. 결론을 먼저 적어 두면 이렇습니다. CDN은 “요청”을 빠르게 하는 장치가 아니라 “캐시에 맞는 요청”을 빠르게 하는 장치이고, 따라서 켜기 전에 봐야 할 것은 제품이 아니라 내 트래픽 중 얼마가 캐시에 맞는가입니다.

CDN은 무엇을 빠르게 하는가

CDN은 오리진의 응답을 사용자와 가까운 위치(엣지)에 미리 저장해 두었다가, 같은 요청이 오면 오리진 대신 그 위치에서 돌려주는 구조입니다. 빨라지는 이유는 두 가지가 겹칩니다. 하나는 응답이 오는 물리적 거리가 짧아지는 것이고, 다른 하나는 오리진까지 다녀오는 왕복 자체가 사라지는 것입니다.

이 두 가지가 성립하려면 전제가 하나 있습니다. 그 응답이 엣지에 저장해 둘 수 있는 종류여야 한다는 것입니다. 엣지에 저장된 사본이 있어야 오리진을 건너뛸 수 있고, 저장할 수 없는 응답은 매번 오리진까지 가야 하므로 거리도 왕복도 줄지 않습니다.

그래서 CDN의 효과를 정확히 말하면 “사이트를 빠르게 한다”가 아니라 “캐시에 저장된 응답을 빠르게 돌려준다”입니다. 이 한 문장의 차이가 이 글 전체를 가릅니다. 내 사이트가 CDN 효과를 보느냐는 결국, 사용자가 요청하는 것들 중 얼마나 많은 부분이 엣지에 저장될 수 있느냐로 결정됩니다.

효과는 캐시 적중률에 묶인다

캐시 적중률(hit ratio)은 사용자의 요청 중에서 엣지에 저장된 사본으로 응답한 비율을 뜻합니다. 이 비율이 높다는 것은 오리진까지 가지 않고 엣지 선에서 끝난 요청이 많았다는 뜻이고, 낮다는 것은 대부분이 오리진까지 다녀왔다는 뜻입니다.

적중률이 낮을 때 무슨 일이 벌어지는지가 핵심입니다. 엣지에서 사본을 찾지 못한 요청(미스)은 오리진으로 넘어가고, 그 응답은 오리진의 처리 시간과 오리진까지의 왕복을 그대로 겪습니다. 즉 적중률이 낮으면 사용자는 CDN이 없을 때와 거의 같은 경로를 지나게 됩니다. CDN이라는 층이 앞에 하나 더 생겼을 뿐, 실제 응답은 뒤쪽 오리진에서 옵니다.

여기서 오해가 자주 생깁니다. “CDN을 붙였으니 빨라졌을 것”이라는 기대는 적중률이 높다는 것을 조용히 전제하는데, 그 전제는 사이트의 콘텐츠 구성에 따라 성립할 수도, 성립하지 않을 수도 있습니다. 그래서 CDN을 켠 뒤 체감이 바뀌지 않았다면, 제품이나 설정을 의심하기 전에 지금 내 트래픽의 적중률이 얼마인가를 먼저 확인하는 것이 순서입니다.

무엇이 캐시되고 무엇이 안 되는가

무엇이 캐시되느냐는 대체로 콘텐츠의 성격과 응답 헤더로 결정됩니다. 기본 동작을 갈라 보면 이렇습니다.

• 기본적으로 캐시되는 쪽 — 이미지, CSS, 자바스크립트, 글꼴, 미리 만들어 둔 파일처럼 누구에게나 같은 내용으로 나가는 정적 자원입니다. Cloudflare의 기본 캐시 동작 문서는 확장자를 기준으로 여러 정적 파일 유형을 기본 캐시 대상으로 다룬다고 정리합니다.
• 기본적으로 캐시되지 않는 쪽 — HTML 문서와 JSON 같은 응답입니다. 같은 문서 기준으로 이들은 기본 설정에서 캐시되지 않습니다. 사용자나 로그인 상태에 따라 내용이 달라질 수 있어, 함부로 저장했다가 다른 사람에게 나가면 곤란하기 때문입니다.

여기에 두 가지 신호가 더 관여합니다. 하나는 오리진이 응답에 붙이는 캐시 관련 헤더(Cache-Control 등)로, 이 응답을 저장해도 되는지와 얼마나 오래 들고 있어도 되는지를 알려 줍니다. 다른 하나는 쿠키입니다. 사용자를 구분하는 쿠키가 응답에 얽혀 있으면, 그 응답은 특정 사용자를 위한 것으로 취급돼 캐시 대상에서 빠지는 경우가 많습니다.

그래서 “이 파일은 왜 캐시가 안 되지”라는 질문은 대개 확장자만으로 답하기 어렵습니다. 콘텐츠의 성격, 오리진이 붙인 헤더, 쿠키가 얽혀 있는지를 함께 봐야 합니다. 어떤 요청을 캐시 대상에 넣거나 뺄지는 캐시 규칙으로 조정할 수 있지만, 규칙을 손대기 전에 지금 무엇이 왜 빠지고 있는지를 먼저 읽는 것이 순서입니다.

CDN을 켰는데 안 빨라지는 이유

체감이 바뀌지 않는 상황은 대체로 아래 몇 갈래 안에 들어갑니다. 하나씩 성격이 다르므로, 내 경우가 어디에 해당하는지부터 가리는 것이 중요합니다.

• 캐시할 수 없는 콘텐츠가 대부분일 때. 로그인 이후 화면과 API 응답이 트래픽의 중심이면, 애초에 엣지에 저장될 것이 적습니다. 이 경우 CDN을 아무리 잘 구성해도 대부분의 요청은 오리진까지 가고, 오리진의 속도가 그대로 사용자에게 전달됩니다.
• 캐시 대상은 맞는데 적중률이 낮을 때. 정적 자원이 많더라도, 유효기간이 너무 짧거나 요청이 여러 형태로 흩어져 있으면 엣지가 사본을 오래 들고 있지 못해 미스가 잦아집니다.
• 캐시 키가 잘게 갈릴 때. CDN은 요청을 구분하는 기준(캐시 키)으로 사본을 나눠 저장합니다. 이 기준에 쿼리스트링이나 쿠키가 불필요하게 섞여 들어가면, 사실상 같은 내용인데도 서로 다른 요청으로 취급돼 각각 오리진까지 다녀오게 됩니다.
• 정적 자원이 실수로 캐시에서 빠질 때. 오리진이 정적 파일에까지 사용자 구분 쿠키를 붙이거나 캐시 금지 헤더를 내려보내면, 당연히 캐시돼야 할 응답이 매번 오리진으로 넘어갑니다. 이 경우는 CDN 문제가 아니라 오리진의 응답 설정 문제입니다.
• 병목이 오리진 안쪽에 있을 때. 캐시 미스가 난 요청이 오리진에서 데이터베이스 조회나 무거운 처리를 기다린다면, 그 지연은 CDN 앞단에서 손댈 수 있는 것이 아닙니다.

이 목록에서 공통으로 드러나는 것은, “CDN이 안 빨라진다”는 한 문장 안에 성격이 다른 원인이 섞여 있다는 점입니다. 캐시 대상이 아니어서인지, 대상은 맞는데 적중률이 낮아서인지, 아니면 병목이 오리진 안쪽에 있어서인지를 나누지 않으면, 손대는 자리가 어긋납니다.

동적·API 응답은 어떻게 다루나

동적 응답은 CDN이 다루는 방식 자체가 정적 자원과 다릅니다. 사용자마다, 요청 시점마다 내용이 달라지는 응답은 하나의 사본으로 여러 사람에게 돌려줄 수 없으므로, 기본적으로 캐시 대상이 아니라 오리진으로 그대로 넘어갑니다.

다만 “동적이면 CDN이 전혀 무의미하다”는 것도 정확하지 않습니다. 갈라 보면 이렇습니다.

• 내용이 매번 다른 응답 — 로그인 사용자의 대시보드, 실시간으로 계산되는 값, 사용자별 개인화 화면은 캐시로 다룰 여지가 거의 없습니다. 이 부분은 오리진의 처리 속도가 곧 사용자 체감입니다.
• 모두에게 같지만 자주 바뀌는 응답 — 로그인과 무관하게 누구에게나 같은 목록이나 공개 데이터라면, 짧은 유효기간을 두고 캐시하는 방식을 검토할 수 있습니다. 이때는 얼마나 오래된 내용까지 허용할지를 함께 정해야 합니다.
• 동적 페이지에 섞인 정적 조각 — 화면 전체는 동적이어도 그 안의 이미지·스크립트·스타일은 정적입니다. 이 조각들이 캐시되면 화면을 구성하는 시간의 일부는 줄어듭니다. 다만 화면의 뼈대가 되는 응답이 오리진에서 늦게 오면, 조각이 빨라져도 첫 화면이 뜨는 시점은 그 늦은 응답에 묶입니다.

정리하면, 동적 서비스에서 CDN이 기여하는 지점은 있지만 그 크기와 위치는 정적 서비스와 다릅니다. 무엇이 진짜로 동적이고 무엇이 동적 화면에 딸려 온 정적 조각인지를 구분해야, CDN이 손댈 수 있는 자리와 그렇지 않은 자리가 나뉩니다.

오리진이 느리면 CDN이 못 가린다

캐시 미스가 난 요청은 결국 오리진까지 갑니다. 그래서 오리진 자체가 느리면, 캐시되지 않는 모든 요청에서 그 느림이 사용자에게 그대로 전달됩니다. CDN은 앞에 선 층이지, 뒤의 오리진을 대신 빠르게 만들어 주는 장치가 아닙니다.

이 지점은 흔히 TTFB(첫 바이트까지의 시간)로 드러납니다. 캐시 적중이 일어난 요청에서는 엣지가 곧바로 응답을 시작하므로 이 시간이 짧지만, 미스가 난 요청에서는 엣지가 오리진의 응답을 기다린 다음에야 사용자에게 첫 바이트를 보냅니다. 즉 미스 요청의 첫 바이트 시간에는 오리진의 처리 시간과 오리진까지의 왕복이 그대로 들어 있습니다. 캐시되지 않는 응답이 여전히 느리다면, 그 느림의 출처는 대개 CDN 앞이 아니라 오리진 안입니다.

그래서 “CDN을 붙였는데 특정 화면이 계속 느리다”는 상황에서 먼저 확인할 것은, 그 화면이 캐시에 맞는지입니다. 캐시되지 않는 화면이라면 문제는 CDN 설정이 아니라 오리진의 처리에 있을 가능성이 높고, 그때는 CDN 쪽 손질이 아니라 오리진 최적화로 방향을 잡아야 합니다.

효과를 눈으로 확인하는 법

CDN이 실제로 일하고 있는지는 화면의 빠르기라는 인상이 아니라 응답 신호로 확인하는 편이 정확합니다. Cloudflare는 응답에 캐시 처리 결과를 담은 상태 값을 실어 보내며, Cache responses 문서가 그 값들의 의미를 정리합니다. 실무에서 자주 보게 되는 것은 다음과 같습니다.

이 값을 읽는 요령은, 어떤 요청에 어떤 값이 붙는지를 나눠서 보는 것입니다. 정적 파일 요청에 HIT이 잘 붙는다면 캐시는 제 역할을 하고 있는 것이고, 반대로 정적 파일에 DYNAMIC이나 반복되는 MISS가 붙는다면 캐시 대상에서 빠졌거나 사본이 유지되지 못하고 있다는 신호입니다. 로그인 화면이나 API 응답에 DYNAMIC이 붙는 것은 정상이므로, 이 값 하나만 보고 문제라고 판단하지 않으셔야 합니다.

빌드업웍스의 운영 경험에서는, “느려요”라는 인상만으로 CDN 설정을 손대기 시작하면 손대는 자리가 어긋나기 쉽습니다. 느린 요청의 응답 신호를 먼저 나눠 읽고 그것이 캐시 대상인지 아닌지를 가른 다음에 손대는 편이, 결과적으로 되돌리는 일이 적었습니다.

CDN이 답이 아닌 문제

CDN을 붙이는 것으로 풀리지 않는 문제도 분명히 있습니다. 오히려 이 구분을 먼저 하지 않으면, CDN에 시간을 들이는 동안 정작 병목은 그대로 남습니다.

• 오리진 안쪽의 지연. 데이터베이스 조회가 느리거나, 요청마다 무거운 계산이 도는 구조라면, 그 지연은 캐시되지 않는 요청에서 계속 드러납니다. 이 부분은 CDN 앞단이 아니라 오리진의 쿼리·인덱스·처리 구조를 봐야 합니다.
• 개인화·실시간 중심 서비스. 사용자마다 다르고 매 순간 바뀌는 응답이 트래픽의 중심이라면, 캐시로 다룰 여지 자체가 작습니다. 이런 서비스에서 성능의 무게중심은 오리진의 응답 속도에 있습니다.
• 오리진 설정이 캐시를 막고 있는 경우. 정적 자원에까지 캐시 금지 헤더나 사용자 쿠키가 붙어 있으면, CDN을 아무리 잘 구성해도 저장할 것이 없습니다. 이때 손댈 곳은 CDN이 아니라 오리진의 응답 설정입니다.

판단의 순서는 간단합니다. 느린 요청을 하나 골라, 그것이 캐시에 맞는지부터 확인하십시오. 캐시에 맞는데 느리다면 캐시가 유지되지 못하는 이유를 CDN 쪽에서 찾고, 캐시에 맞지 않는데 느리다면 원인은 오리진 안에 있을 가능성이 높습니다. CDN을 붙이기 전에 오리진을 먼저 봐야 하는 경우는, 바로 이 두 번째에 해당하는 요청이 느림의 중심일 때입니다. AWS와 Cloudflare를 함께 쓸 때 깨지는 자리에서는 CDN을 구성한 뒤에 캐시가 두 벌로 갈리며 생기는 문제를 이어서 다룹니다.

다음 단계

CDN을 검토하기 전에, 지금 느린 것이 캐시에 맞는 요청인지 오리진 안쪽의 문제인지부터 가리는 것이 순서입니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 비용과 구조를 함께 확인해, 병목이 CDN 앞에 있는지 뒤에 있는지 방향을 정리하는 출발점이 됩니다. 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

CDN과 오리진을 함께 설계하거나 구성을 정비하려는 단계라면 AWS 인프라 설계·구축 범위에서 어디까지가 저희 몫이고 어디부터 별도인지 확인해 보십시오. 지금 구조에서 무엇부터 손대는 것이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Cloudflare Docs — Default Cache Behavior
• Cloudflare Docs — Cache responses
• Cloudflare Docs — Cache Rules