Cloudflare 캐싱 및 WAF 설정

캐싱은 자주 요청되는 웹 콘텐츠의 복사본을 사용자와 가까운 위치에 임시 저장하여, 원본 서버까지의 왕복 시간과 부하를 줄이는 기술이다. 사용자가 웹사이트를 방문하면, 요청은 먼저 CDN의 가장 가까운 에지 서버로 전달된다. 해당 서버에 요청된 리소스의 캐시된 복사본이 존재하면, 이를 즉시 사용자에게 제공한다. 이를 캐시 적중이라고 한다. 캐시된 복사본이 없거나 만료된 경우에만 요청이 원본 서버로 전달되어 새로운 복사본을 가져오는데, 이를 캐시 미스라고 한다.

캐싱의 주요 이점은 웹사이트 성능과 사용자 경험의 극적인 개선이다. 콘텐츠가 물리적으로 가까운 위치에서 제공되므로 로딩 시간이 단축된다. 이는 특히 지리적으로 멀리 떨어진 사용자에게 유리하다. 또한, 원본 서버로 직접 전달되는 트래픽이 감소하여 서버 부하와 대역폭 사용량이 줄어든다. 이는 서버 비용을 절감하고, 트래픽 급증 시 서버 다운 위험을 낮추는 효과가 있다.

캐싱은 정적 콘텐츠에 가장 효과적이다. HTML, CSS, 자바스크립트 파일, 이미지, 동영상 등 변경 빈도가 낮은 리소스는 긴 TTL로 캐싱하기에 적합하다. 반면, 사용자별로 내용이 달라지는 동적 페이지나 실시간 데이터는 캐싱 설정에 주의가 필요하다. Cloudflare는 다양한 캐싱 수준을 제공하여, 정적 콘텐츠는 완전히 캐싱하고, 동적 콘텐츠는 선택적으로 캐싱하거나 전혀 캐싱하지 않도록 세밀하게 제어할 수 있다.

Cloudflare는 전 세계 300개 이상의 도시에 위치한 데이터 센터로 구성된 광범위한 네트워크를 운영한다. 이 에지 네트워크는 사용자의 요청을 지리적으로 가장 가까운 데이터 센터로 라우팅하여 콘텐츠 전송 속도를 극대화한다. 정적 자산은 이 네트워크의 가장자리에 캐시되어, 원본 서버에 대한 부하를 줄이고 전 세계 사용자에게 낮은 지연 시간으로 콘텐츠를 제공한다.

네트워크의 각 데이터 센터는 Anycast 기술을 사용하여 동일한 IP 주소를 공유한다. 이는 사용자 트래픽이 자동으로 가장 가까운 최적의 위치로 라우팅되도록 보장한다. 캐싱 계층은 다음과 같이 구성된다.

이러한 계층적 구조는 캐시 적중률을 높이고 원본 서버로의 트래픽을 최소화한다. 또한 Tiered Cache 아키텍처를 통해 인기 있는 콘텐츠는 에지에, 덜 인기 있는 콘텐츠는 상위 계층에 효율적으로 저장된다. 결과적으로 웹사이트의 전반적인 성능과 가용성이 향상되며, DDoS 공격과 같은 트래픽 급증 시에도 원본 서버를 보호하는 완충 역할을 한다.

Page Rules는 Cloudflare에서 도메인의 특정 URL 패턴에 대해 다양한 설정을 적용할 수 있는 강력한 도구이다. 캐싱과 관련하여, 특정 페이지나 파일 유형에 대해 표준 캐싱 동작을 재정의하는 데 주로 사용된다. 각 규칙은 URL 패턴(와일드카드 사용 가능)과 해당 패턴에 적용할 일련의 설정으로 구성된다.

주요 캐싱 관련 설정으로는 'Cache Level', 'Edge Cache TTL', 'Browser Cache TTL' 등이 있다. 'Cache Level'은 Cloudflare의 CDN 에지에서 리소스를 캐시할지 여부와 방식을 결정한다. 옵션은 'Bypass'(캐시하지 않음), 'No Query String'(쿼리 문자열 무시하고 캐시), 'Ignore Query String'(쿼리 문자열 무시), 'Standard' 등이 있다. 'Edge Cache TTL'은 Cloudflare의 글로벌 네트워크에서 콘텐츠를 캐시하는 시간을 설정하며, 'Browser Cache TTL'은 최종 사용자의 브라우저 캐시 지속 시간을 제어한다.

규칙은 설정된 순서대로 평가되며, 첫 번째로 일치하는 규칙의 설정이 적용된다. 따라서 더 구체적인 URL 패턴을 가진 규칙을 상위에 배치하고, 일반적인 규칙을 하위에 배치하는 것이 일반적이다. Page Rules는 정적 자산(이미지, CSS, JS)에 대한 캐싱 최적화, 관리자 페이지나 검색 결과와 같은 동적 콘텐츠의 캐시 우회, 또는 특정 API 엔드포인트에 대한 별도 캐시 정책 설정에 유용하다.

현재 Cloudflare는 Page Rules의 후속으로 더 세분화된 제어가 가능한 'Cache Rules' 인터페이스를 권장하고 있다. 그러나 기존 설정의 호환성을 위해 Page Rules는 계속 지원되며, 최대 125개의 규칙까지 생성할 수 있다[1].

Page Rules를 대체하는 새로운 캐싱 관리 인터페이스로, 2022년부터 도입되었다. 더욱 세분화되고 직관적인 규칙 구성이 가능하며, Cloudflare 대시보드의 Caching > Configuration 섹션에서 관리할 수 있다.

Cache Rules는 조건(When)과 동작(Then)으로 구성된 규칙 엔진을 기반으로 한다. 사용자는 URL 경로, 쿼리 문자열, 요청 헤더, 쿠키 값, 국가 코드 등 다양한 조건을 조합하여 캐싱 동작을 정의할 수 있다. 주요 설정 동작에는 다음이 포함된다.

이 인터페이스는 특히 동일한 URL 패턴에 대해 다른 캐싱 정책을 적용해야 하는 복잡한 시나리오에 유용하다. 예를 들어, /api/ 경로의 요청은 캐시를 우회하게 하고, /static/ 경로의 이미지나 CSS 파일은 장기간 캐시하도록 여러 규칙을 중첩하여 설정할 수 있다. 규칙은 위에서 아래로 평가되며, 우선순위를 조정할 수 있다.

브라우저 캐싱 TTL 설정은 Cloudflare가 아닌 최종 사용자의 웹 브라우저에 정적 자원을 얼마나 오래 저장할지 지시하는 헤더를 제어하는 것을 의미한다. 이 설정은 Edge Caching과 구별되며, 서버 부하를 줄이고 사용자의 재방문 시 페이지 로딩 속도를 극적으로 향상시킨다. 일반적으로 이미지, CSS, 자바스크립트 파일과 같은 변경 빈도가 낮은 자원에 대해 긴 TTL을 적용한다.

설정은 Cloudflare 대시보드의 '캐싱' > '구성' 탭 내 '브라우저 캐시 TTL' 옵션에서 관리할 수 있다. 여기서는 전역적인 기본 TTL 값을 시간, 일, 월 단위로 설정하거나, '원본 서버의 캐시 제어 존중' 옵션을 선택할 수 있다. 후자를 선택하면 Cloudflare는 원본 서버에서 전송한 Cache-Control 또는 Expires 헤더를 그대로 브라우저에 전달하여 더 세밀한 제어가 가능해진다.

다양한 파일 유형에 따라 다른 TTL을 적용하려면 Page Rules나 새로운 Cache Rules 인터페이스를 사용해야 한다. 예를 들어, 아래 표는 일반적인 권장 설정의 예를 보여준다.

적절한 브라우저 캐시 TTL을 설정하면 서버의 대역폭 사용량을 줄이고, 사용자 경험을 개선하며, Core Web Vitals 지표 중 하나인 LCP(Largest Contentful Paint)를 향상시키는 데 도움이 된다. 그러나 자원을 변경할 때는 파일명 변경 또는 쿼리 문자열 버저닝과 같은 기술을 통해 캐시 무효화를 정확히 관리해야 한다.

Cloudflare는 다양한 방법으로 캐시된 콘텐츠를 무효화하는 기능을 제공한다. 이는 웹사이트 콘텐츠가 업데이트되었을 때, 사용자에게 즉시 새로운 버전을 제공하기 위해 필수적이다. 캐시 무효화는 Cloudflare 대시보드의 캐싱 섹션 또는 API를 통해 수행할 수 있다.

가장 기본적인 방법은 단일 URL을 지정하여 무효화하는 것이다. 정확한 URL을 입력하면 해당 페이지만 CDN 에지 네트워크의 캐시에서 제거된다. 여러 페이지를 한 번에 처리해야 할 경우, Page Rules에서 설정한 캐시 태그를 기반으로 무효화할 수 있다. 예를 들어, product-*와 같은 태그 패턴을 사용하면 특정 제품 카테고리의 모든 페이지를 효율적으로 새로 고칠 수 있다. 가장 광범위한 방법은 '모두 무효화'를 선택하여 도메인에 연결된 모든 자산의 캐시를 한 번에 지우는 것이다. 이는 사이트 전체를 재배포했을 때 유용하지만, 전역 캐시가 다시 채워지는 동안 성능에 일시적인 영향을 미칠 수 있다.

무효화 요청을 제출하면, Cloudflare의 글로벌 네트워크에 있는 데이터 센터로 제거 명령이 전파된다. 이 과정은 일반적으로 몇 초 내에 완료되지만, 전 세계 모든 에지 위치에 반영되기까지 최대 30초가 소요될 수 있다[3]. 무효화는 캐시된 정적 콘텐츠에만 적용되며, 원본 서버의 실제 파일에는 영향을 주지 않는다.

Cloudflare는 REST API를 통해 캐시 무효화 작업을 자동화할 수 있는 포괄적인 인터페이스를 제공한다. 이는 대규모 사이트나 빈번한 콘텐츠 업데이트가 발생하는 환경에서 특히 유용하다. API를 사용하면 CI/CD 파이프라인에 캐시 무효화 단계를 통합하거나, 콘텐츠 관리 시스템이 새로운 글을 게시할 때 자동으로 관련 캐시를 지우는 등의 작업을 구현할 수 있다.

주요 API 엔드포인트는 zones/{zone_id}/purge_cache이며, POST 메서드로 요청을 보낸다. 무효화할 대상을 지정하는 방법에 따라 요청 본문의 구조가 달라진다. 단일 URL을 무효화하려면 "files" 배열에 URL을, 여러 URL을 무효화하려면 배열에 여러 URL을 나열하면 된다. 특정 캐시 태그로 표시된 모든 파일을 무효화하려면 "tags" 배열을, 존(zone)의 전체 캐시를 무효화하려면 "purge_everything": true 플래그를 사용한다.

API 요청을 보내기 위해서는 인증이 필요하다. Cloudflare 대시보드에서 생성할 수 있는 API 토큰을 사용하는 것이 일반적이며, 토큰에는 Zone.Cache Purge 권한이 부여되어야 한다. 요청 시 Authorization: Bearer <API_TOKEN> 헤더를 포함시킨다. 성공적인 요청에 대한 응답은 "success": true와 함께 요청 ID를 포함한 JSON 객체를 반환한다.

자동화 시 고려할 점은 API 호출 빈도 제한과 비용이다. 특히 purge_everything은 신중하게 사용해야 하며, 가능하면 태그 기반 또는 URL 기반 무효화를 통해 불필요한 전체 캐시 삭제를 피하는 것이 좋다. 또한 API 응답을 모니터링하고 실패 시 재시도 로직을 구현하는 것이 안정성을 높인다.

WAF는 웹 애플리케이션과 인터넷 사이에 위치하여 애플리케이션 계층(OSI 7계층의 7계층)에서 동작하는 필터링 장치이다. 주된 역할은 악의적인 웹 트래픽을 차단하고 합법적인 트래픽만 애플리케이션에 도달하도록 허용하여 웹 애플리케이션을 보호하는 것이다. 이는 전통적인 네트워크 방화벽이 네트워크 주소와 포트를 기반으로 트래픽을 필터링하는 것과 구별되는 차이점이다.

Cloudflare WAF는 다양한 공격 벡터로부터 웹사이트를 보호하는 다중 보호 기능을 제공한다. 주요 보호 기능으로는 SQL 삽입(SQLi), 크로스 사이트 스크립팅(XSS), 원격 파일 포함(RFI)과 같은 OWASP Top 10에 명시된 일반적인 웹 취약점 공격을 차단하는 것이 포함된다. 또한, 관리형 규칙셋을 통해 자동으로 업데이트되는 규칙으로 신종 제로데이 공격에 대응할 수 있다.

Cloudflare WAF는 단순한 차단을 넘어서 세밀한 제어 기능을 제공한다. 특정 국가나 IP 범위에서의 접근을 차단하거나 허용할 수 있으며, 사용자 에이전트나 HTTP 헤더를 기반으로 한 규칙을 생성할 수 있다. 또한, Rate Limiting 기능을 통해 특정 시간 동안 과도한 요청을 보내는 봇이나 공격자를 식별하고 제한하여 DDoS 공격이나 브루트 포스 공격으로부터 자원을 보호한다.

Cloudflare WAF는 사전 정의된 관리형 규칙셋과 사용자가 직접 생성하는 커스텀 규칙의 두 가지 주요 규칙 유형을 제공하여 웹 애플리케이션을 보호합니다.

관리형 규칙셋은 Cloudflare가 자동으로 업데이트하고 관리하는 규칙 모음입니다. 이는 일반적인 OWASP Top 10 취약점, 알려진 취약점 공격, SQL 인젝션, 크로스사이트 스크립팅(XSS)과 같은 일반적인 웹 공격 벡터를 차단하도록 설계되었습니다. 사용자는 규칙셋 전체를 켜거나 끌 수 있을 뿐만 아니라, 개별 규칙의 동작(차단, 챌린지, 로그만)을 세부적으로 조정할 수 있습니다. 주요 관리형 규칙셋에는 다음과 같은 것들이 있습니다.

반면, 커스텀 규칙은 사용자가 특정 요구사항에 맞춰 자유롭게 정의할 수 있는 규칙입니다. 규칙 표현식(Rule Expression)을 사용하여 트래픽의 HTTP 요청 헤더, URI 경로, IP 주소, 국가 코드, 사용자 에이전트 문자열 등 다양한 조건을 조합하여 필터링 로직을 작성합니다. 예를 들어, 특정 경로(/admin)에 대한 접근을 특정 IP 대역으로 제한하거나, 의심스러운 사용자 에이전트 문자열을 가진 요청을 차단하는 규칙을 만들 수 있습니다. 커스텀 규칙은 관리형 규칙셋이 포괄하지 않는 애플리케이션 고유의 위협이나 비즈니스 로직에 대한 보안 정책을 구현하는 데 필수적입니다.

두 규칙 유형은 계층적으로 작동합니다. 일반적으로 커스텀 규칙이 더 높은 우선순위로 평가된 후, 관리형 규칙셋이 적용됩니다[4]. 이 조합을 통해 사용자는 광범위한 알려진 공격으로부터 자동 보호를 받으면서도, 동시에 세밀하고 유연한 맞춤형 보안 정책을 수립할 수 있습니다.

방화벽 규칙은 Cloudflare WAF의 핵심 구성 요소로, 특정 조건을 충족하는 트래픽에 대해 정의된 조치를 수행합니다. 규칙은 규칙 표현식을 기반으로 하며, 트래픽의 출처 IP 주소, 국가, User-Agent 문자열, 요청 경로, HTTP 메서드 등 다양한 요소를 조건으로 사용할 수 있습니다. 각 규칙에는 '차단', '챌린지'(예: CAPTCHA), 'JS 챌린지', '허용', '로깅 전용' 등의 조치를 설정합니다.

규칙은 생성 시 또는 규칙 목록에서 드래그 앤 드롭으로 우선순위를 지정할 수 있습니다. 목록 상단에 위치한 규칙이 가장 높은 우선순위를 가지며, 트래픽은 위에서 아래로 순차적으로 평가됩니다. 일치하는 첫 번째 규칙의 조치가 실행되고 나머지 규칙 평가는 중단됩니다. 따라서 구체적이고 중요한 규칙은 상위에, 일반적인 규칙은 하위에 배치하는 것이 효율적입니다.

규칙 우선순위를 효과적으로 관리하려면, '로깅 전용' 조치를 활용해 새 규칙을 테스트한 후 실제 조치로 전환하는 방법이 유용합니다. 또한, 규칙 표현식 편집기를 사용하면 복잡한 논리(and, or)를 시각적으로 구성할 수 있어 정확한 조건 설정에 도움이 됩니다. 규칙이 너무 많아지면 성능에 영향을 미칠 수 있으므로, 주기적으로 규칙을 검토하고 통합하거나 비활성화하는 것이 좋습니다.

Rate Limiting 규칙 구성은 Cloudflare WAF에서 특정 IP 주소나 요청 패턴이 과도한 요청을 보내는 것을 제한하여 서버 부하와 DoS 공격을 완화하는 기능이다. 이 규칙은 초당, 분당, 시간당 요청 수를 정의한 임계값을 초과하는 트래픽을 차단하거나 도전(캡차)을 제공한다.

규칙 구성은 Cloudflare 대시보드의 방화벽 > WAF > Rate limiting rules 섹션에서 이루어진다. 사용자는 규칙의 이름을 지정하고, 적용할 도메인을 선택한 후, 조건을 정의한다. 조건은 요청 경로(URL), HTTP 메서드, HTTP 헤더, 쿠키 값, ASN 또는 국가 코드 등을 기반으로 세분화할 수 있다. 예를 들어, /api/login 경로에 대한 POST 요청을 특정 국가에서 1분에 10회 이상 시도하는 경우를 탐지하도록 설정할 수 있다. 임계값을 초과한 후의 조치로는 요청 차단, 임시 차단, JS Challenge 또는 Managed Challenge 실행 등이 있다.

규칙을 설정할 때는 정상 사용자 경험을 저해하지 않도록 임계값을 신중하게 설정해야 한다. 예를 들어, 정적 자원보다는 로그인 또는 결제 API 엔드포인트에 더 엄격한 제한을 적용하는 것이 일반적이다. 또한, 규칙이 적용된 후에는 WAF 이벤트 로그를 모니터링하여 오탐지(false positive)가 발생하지 않는지 확인하고, 필요에 따라 임계값이나 조건을 조정해야 한다. Rate Limiting 규칙은 관리형 규칙셋과 함께 사용되어 애플리케이션 계층(레이어 7)의 고급 공격으로부터 효과적으로 보호한다.

사용자 정의 규칙 표현식은 Cloudflare WAF에서 특정 트래픽 패턴을 정확히 식별하고 차단하거나 허용하기 위한 강력한 도구이다. 이 표현식은 WAF 규칙의 조건부 논리를 구성하는 핵심 요소로, HTTP 요청의 다양한 부분을 검사하는 데 사용된다. 표현식은 Cloudflare의 규칙 표현식 언어(Wirefilter syntax)를 기반으로 작성되며, 요청의 URL, 헤더, 메서드, 출발지 IP 주소, 쿼리 문자열 매개변수, 쿠키 값 등을 평가할 수 있다. 이를 통해 표준 관리형 규칙셋으로는 대응하기 어려운 애플리케이션 고유의 위협이나 비즈니스 로직에 맞는 접근 제어 정책을 구현할 수 있다.

표현식 작성은 주로 방화벽 규칙 또는 Rate Limiting 규칙 생성 인터페이스에서 이루어진다. 일반적인 구조는 (http.request.uri.path contains "/admin") and (not ip.src in {192.0.2.0/24})와 같다. 이 예시는 경로에 "/admin"이 포함되고, 출발지 IP가 특정 대역에 속하지 않는 요청을 매칭한다. 사용 가능한 필드는 매우 다양하며, 몇 가지 주요 예시는 다음과 같다.

표현식에는 and, or, not 같은 논리 연산자와 eq(같음), ne(같지 않음), contains, matches(정규식 매치) 같은 비교 연산자를 조합하여 복잡한 조건을 만들 수 있다. 정규식을 사용할 때는 matches 연산자를 활용하며, 예를 들어 http.request.uri.path matches "^/api/v[0-9]+/users/.+$"와 같이 작성하여 특정 패턴의 API 경로를 대상으로 할 수 있다. 작성한 표현식의 정확성을 확인하기 위해 Cloudflare 대시보드에는 표현식 미리보기(Expression Preview) 기능이 제공되어, 최근 실제 트래픽에 대한 테스트 결과를 즉시 확인할 수 있다.

WAF 규칙과 같은 보안 규칙은 요청의 라이프사이클 초기에 평가된다. 특정 요청이 보안 규칙에 의해 차단되거나 챌린지를 받으면, 해당 요청은 Cloudflare의 에지 서버에서 더 이상 처리되지 않고 오리진 서버에 도달하지 못한다. 이는 차단된 요청에 대해서는 캐싱 동작이 발생하지 않음을 의미한다.

반대로, 보안 규칙이 특정 요청을 허용하면 정상적인 캐싱 프로세스가 진행된다. 그러나 일부 WAF 규칙은 요청의 특성을 검사하기 위해 요청 본문을 확인해야 할 수 있다. 이러한 "요청 본문 검사"가 활성화된 규칙은, 캐시 키에 요청 본문이 포함되지 않는 한 일반적으로 정적 콘텐츠의 캐싱에는 영향을 미치지 않는다. 하지만 동적 요청이나 POST 메서드와 같이 기본적으로 캐싱되지 않는 요청의 처리 속도를 저하시킬 가능성이 있다.

성능 최적화를 위해서는 보안 규칙의 적용 대상을 신중하게 정의하는 것이 중요하다. 예를 들어, 정적 자원(CSS, JavaScript, 이미지 파일) 경로에 대해서는 불필요한 WAF 검사를 비활성화하여 에지 캐시에서의 빠른 응답을 보장할 수 있다. 이는 Page Rules 또는 Cache Rules를 사용하여 특정 URL 패턴에 대한 보안 규칙을 건너뛰도록 설정함으로써 달성된다.

Cloudflare의 캐싱과 WAF 설정은 성능 향상과 보안 강화라는 상충되는 목표를 동시에 달성해야 한다. 과도한 보안 규칙은 정상 트래픽까지 차단하여 캐시 적중률을 떨어뜨리고 지연을 증가시킬 수 있으며, 반대로 캐싱을 지나치게 공격적으로 설정하면 동적 콘텐츠나 보안 검증이 필요한 요청이 잘못 캐싱될 위험이 있다. 따라서 두 기능의 설정을 신중하게 조정하여 서비스의 특성에 맞는 최적의 균형점을 찾는 것이 중요하다.

균형을 맞추기 위한 첫 번째 단계는 트래픽을 정확히 분류하는 것이다. 정적 자산(이미지, CSS, JS 파일)은 Cache Everything 규칙과 긴 TTL을 적용하여 성능을 극대화하되, WAF의 SQL 인젝션이나 XSS 필터링은 반드시 적용해야 한다. 반면, 로그인 세션, 장바구니, API 엔드포인트와 같은 동적 콘텐츠는 캐싱에서 제외하거나 매우 짧은 TTL을 설정한 후, WAF의 Rate Limiting 및 관리형 규칙셋을 더 엄격하게 적용하여 보호에 중점을 둔다.

다음 표는 일반적인 콘텐츠 유형에 따른 권장 설정 균형을 보여준다.

마지막으로, 설정 적용 후 Cloudflare Analytics의 캐시 적중률과 WAF 이벤트 로그를 꾸준히 모니터링해야 한다. 보안 이벤트가 급증하는 특정 엔드포인트가 있다면, 해당 경로에 대한 캐싱 규칙을 재검토하고 보안 규칙을 미세 조정할 수 있다. 또한 Cloudflare Workers를 사용하면 요청의 특성에 따라 캐싱과 WAF 검사를 동적으로 제어하는 복잡한 로직을 구현할 수 있어, 균형을 맞추는 데 유연성을 더한다.

캐시 적중률은 Cloudflare의 캐싱 성능을 평가하는 핵심 지표이다. 이는 사용자 요청이 Cloudflare의 에지 서버에서 직접 처리된 비율을 나타낸다. 캐시 적중률이 높을수록 원본 서버의 부하가 줄어들고, 웹사이트 응답 속도가 빨라지며, 대역폭 사용량이 감소한다. 반대로 캐시 적중률이 낮으면 대부분의 요청이 원본 서버로 전달되어 성능 저하와 비용 증가로 이어질 수 있다.

캐시 적중률은 Cloudflare 대시보드의 '개요' 또는 '캐싱' 앱 내 '분석' 탭에서 확인할 수 있다. 주요 분석 지표는 다음과 같다.

낮은 캐시 적중률의 일반적인 원인은 정적 리소스에 대한 캐싱 설정 부재, 과도하게 짧은 TTL, 또는 쿠키나 세션 ID와 같은 동적 매개변수를 포함하는 URL 패턴이다. 이를 개선하기 위해 Page Rules 또는 Cache Rules를 사용하여 정적 파일(이미지, CSS, JS)에 대한 캐싱을 활성화하고, 적절한 브라우저 캐시 TTL을 설정해야 한다. 또한, '쿼리 문자열 정렬' 기능을 사용하면 URL에 불필요한 매개변수가 있어도 동일한 콘텐츠를 하나의 캐시 항목으로 인식하도록 할 수 있다.

캐시 적중률 모니터링은 주기적으로 수행하여 설정 변경의 효과를 측정하고, 새로운 콘텐츠나 애플리케이션 변경이 캐싱 효율에 미치는 영향을 평가해야 한다. 특정 시간대나 지역에서 캐시 적중률이 급격히 떨어지는 경우, 해당 패턴의 트래픽을 분석하고 맞춤형 캐싱 규칙을 적용하는 것이 효과적이다.

Cloudflare WAF는 탐지된 모든 위협과 트래픽 결정에 대한 상세한 로그를 생성한다. 이러한 이벤트 로그는 보안 인시던트를 조사하고, WAF 규칙의 효과를 평가하며, 잘못된 차단(false positive)을 식별하는 데 필수적이다.

로그는 Cloudflare 대시보드의 보안 > 이벤트 섹션에서 확인할 수 있다. 여기서는 시간 범위, 작업(예: 차단, 챌린지, 건너뛰기), 규칙 ID, 도메인, 클라이언트 IP 주소 등을 기준으로 이벤트를 필터링하고 검색할 수 있다. 각 이벤트 항목을 클릭하면 요청 세부 정보, 적용된 규칙, 위협 점수, 사용자 에이전트, 요청 경로 등 포괄적인 컨텍스트를 확인할 수 있다. 예를 들어, 특정 IP 주소가 반복적으로 악성 요청을 보낸 경우, 해당 IP의 모든 이벤트 기록을 추적하여 패턴을 분석할 수 있다.

로그 데이터는 보안 태세를 지속적으로 개선하는 데 활용된다. 특정 관리형 규칙이 정상 트래픽을 자주 차단하는 것을 발견하면, 해당 규칙에 대해 '건너뛰기' 또는 '로그 모드'로 조정하여 영향을 평가한 후 영구적인 예외를 구성할 수 있다[5]. 또한, 로그를 통해 새로운 공격 벡터를 식별하면, 이를 바탕으로 새로운 사용자 정의 방화벽 규칙을 작성하여 사전에 대응할 수 있다.

캐시 적중률이 낮은 경우, Cloudflare의 기본 캐싱 동작은 정적 파일에만 적용된다는 점을 확인해야 합니다. 동적으로 생성되는 콘텐츠(예: 세션 데이터, 개인화된 페이지)나 Cache-Control 헤더에 no-cache, private, no-store 지시어가 포함된 응답은 캐시되지 않습니다. 문제 해결을 위해 원본 서버의 응답 헤더를 검토하고, Page Rules 또는 Cache Rules를 사용하여 특정 URL 패턴에 대한 캐싱 동작을 재정의할 수 있습니다.

보안 규칙에 의해 정상 트래픽이 차단되는 경우가 발생할 수 있습니다. 이는 WAF의 관리형 규칙셋이 과도하게 엄격하게 설정되었거나, 사용자 정의 Rate Limiting 규칙의 임계값이 너무 낮을 때 일어납니다. Cloudflare 대시보드의 방화벽 이벤트 로그에서 차단된 요청의 이유와 규칙 ID를 확인한 후, 해당 규칙을 비활성화하거나 예외를 추가하는 방식으로 조정할 수 있습니다.

전체 캐시를 무효화했음에도 일부 지역에서 오래된 콘텐츠가 제공될 수 있습니다. Cloudflare의 글로벌 네트워크에 변경 사항이 전파되려면 최대 30초가 소요됩니다. 또한, 최종 사용자의 브라우저 캐시나 중간 프록시 캐시도 영향을 미칠 수 있습니다. API를 통한 태그 기반 무효화를 사용하면 관련된 자원들만 정확히 갱신할 수 있어 효율적입니다. 지속적인 문제는 Cloudflare의 캐시 상태 확인 도구를 이용해 특정 데이터센터의 캐시 응답을 진단해야 합니다.

Argo Smart Routing은 Cloudflare의 글로벌 네트워크를 활용하여 사용자 요청이 원본 서버에 도달하는 최적의 경로를 실시간으로 선택하는 유료 서비스이다. 이는 전통적인 BGP 라우팅보다 지연 시간을 줄이고 안정성을 높여 전반적인 웹사이트 성능을 개선한다.

Argo Smart Routing은 캐싱과 밀접하게 연동되어 작동한다. 우선, Cloudflare 에지 네트워크에 캐시된 콘텐츠에 대한 요청은 원본 서버까지 이동할 필요가 없으므로, Argo의 경로 최적화 이점이 직접 적용되지 않는다. 그러나 캐시 미스가 발생하여 원본 서버에서 데이터를 가져와야 할 때, Argo는 가장 빠르고 안정적인 네트워크 경로를 동적으로 선택한다. 이는 TTL이 만료된 캐시를 새로 고치거나, 동적 콘텐츠를 제공할 때 특히 유용하다.

성능 최적화를 위해 Argo와 캐싱을 함께 구성할 때는 다음 사항을 고려한다.

결과적으로, Argo Smart Routing은 캐싱 전략을 보완하는 고급 성능 계층으로 작동한다. 강력한 캐싱 정책으로 정적 콘텐츠 전송을 가속화하고, Argo는 필연적으로 발생하는 원본 호출에 대한 네트워크 경로를 최적화한다. 이 두 기술을 함께 사용하면 캐시 적중 시의 빠른 응답과 캐시 미스 시의 최적화된 원본 연결을 결합하여 일관된 저지연 사용자 경험을 제공할 수 있다.

Cloudflare Workers는 CDN 에지 네트워크에서 실행되는 서버리스 함수 플랫폼이다. 이를 활용하면 정적 캐싱만으로 처리하기 어려운 복잡한 로직에 기반한 동적 캐싱 전략을 구현할 수 있다. Worker는 사용자의 요청을 가로채서, 사용자 정의 조건에 따라 오리진 서버로의 요청 여부를 결정하거나, 캐시된 응답을 변조하여 반환할 수 있다.

동적 캐싱의 일반적인 구현 패턴은 요청의 특성(예: 쿠키, 헤더, URL 경로 변수)을 검사하여 캐시 키를 생성하는 것이다. 예를 들어, 로그인 상태가 아닌 사용자에게는 공통 콘텐츠를 캐시하여 제공하고, 로그인한 사용자의 요청은 오리진 서버로 직접 전달하도록 구성할 수 있다. Worker 스크립트 내에서는 cache API를 사용하여 캐시 저장소에 직접 접근하고, fetch() 함수를 이용해 오리진 요청을 제어한다.

다음은 Worker를 사용한 간단한 동적 캐싱 로직의 예시이다. 이 코드는 특정 API 경로의 요청에 대해, Authorization 헤더의 존재 여부에 따라 캐싱 동작을 분기한다.

```javascript

addEventListener('fetch', event => {

event.respondWith(handleRequest(event.request))

})

async function handleRequest(request) {

const url = new URL(request.url)

// /api/ 경로의 요청만 동적 캐싱 처리

if (url.pathname.startsWith('/api/')) {

// 인증 헤더가 없는 경우 캐시를 확인

if (!request.headers.has('Authorization')) {

const cache = caches.default

let response = await cache.match(request)

if (!response) {

// 캐시 미스 시 오리진에서 데이터 가져와 캐시에 저장

response = await fetch(request)

// 성공적인 응답만 캐시 (예: 상태 코드 200)

if (response.status === 200) {

const responseToCache = response.clone()

event.waitUntil(cache.put(request, responseToCache))

}

}

return response

}

// 인증 헤더가 있는 요청은 캐시 없이 오리진으로 직접 전달

}

// 다른 요청은 기본 처리

return fetch(request)

}

```

이러한 접근 방식은 개인화된 콘텐츠와 공용 콘텐츠가 혼합된 사이트의 성능을 극대화하는 데 유용하다. 또한, Worker를 통해 외부 API의 응답을 일정 시간 동안 캐시하거나, 여러 데이터 소스를 조합한 결과를 생성하여 캐시하는 등 기존의 Page Rules나 Cache Rules로는 구현하기 어려운 고도로 유연한 캐싱 정책을 수립할 수 있다.

Cloudflare의 WAF 설정은 도메인의 보안 등급에 따라 자동으로 조정되는 기본 규칙과 수동 조정이 가능한 커스텀 규칙을 결합하여 운영된다. 보안 등급은 Cloudflare 대시보드의 '보안' > 'WAF' 섹션에서 '보안 수준 및 규칙' 아래에 위치하며, 기본적으로 '중간'으로 설정되어 있다. 이 등급은 관리형 규칙셋이 트래픽에 대해 얼마나 공격적으로 대응할지를 결정하는 기준이 된다.

보안 등급은 '꺼짐', '낮음', '중간', '놈'의 네 단계로 구분된다. 각 등급은 OWASP 핵심 규칙셋 및 Cloudflare 관리 규칙셋의 동작 민감도를 제어한다. 예를 들어, '낮음' 등급은 알려진 취약점에 대한 탐지만 수행하는 반면, '놈' 등급은 의심스러운 트래픽에 대해 더 광범위하게 차단하거나 도전 질문을 발행한다. 이 설정은 전체 도메인 또는 특정 Page Rules를 통해 지정된 URL 경로에 개별적으로 적용할 수 있다.

특정 상황에 맞게 설정을 세부 조정하려면 'WAF' > '관리형 규칙'으로 이동하여 개별 규칙 그룹의 '모드'를 수정해야 한다. 예를 들어, 사이트에 파일 업로드 기능이 있다면 '파일 업로드 검사' 규칙 그룹의 동작을 '차단'에서 '로그만'으로 변경하여 기능을 보존하면서 모니터링할 수 있다. 이러한 등급 조정과 규칙별 모드 설정을 결합하면 사이트의 정상 트래픽 흐름을 방해하지 않으면서도 효과적인 보안 계층을 유지할 수 있다.