공개 문서와 제품 페이지, 검색 화면을 운영하다 보면 어느 날부터 사람이 읽는 속도와 다른 요청 패턴을 마주하게 된다. 같은 정보가 여러 주소와 화면 형태로 반복 조회되고, 평소에는 드물던 경로가 원본 서버와 데이터베이스를 계속 호출한다. 이때 운영팀이 먼저 답해야 할 질문은 “AI 에이전트를 막을 것인가”가 아니다.
우리 서비스에서 어떤 공개 요청은 넓게 받아도 되고, 어떤 요청은 캐시·제한·별도 경로가 필요한가를 정해야 한다.
공개 정보를 호스팅하는 서비스에는 자동화된 접근이 점점 더 큰 부담이 될 수 있다. 특히 원본 데이터는 많지 않은데 URL과 표현 방식이 매우 많은 서비스라면, 콘텐츠 양보다 캐시 키 공간이 더 빠르게 커진다. 같은 결과를 여러 번 만들지 않도록 설계하지 않으면 인프라 증설만으로는 운영 부담이 줄지 않는다.
이 글은 CTO와 개발 리드가 요구사항 정의부터 검증, 운영 절차까지 연결할 수 있도록 구성한 실행 청사진이다.
요구사항 단계: 봇 목록보다 요청 비용 지도를 먼저 만든다
처음 산출물은 허용 봇과 차단 봇 목록이 아니다. 공개 엔드포인트마다 요청 한 건이 어디에서 비용을 발생시키는지 정리한 요청 비용 지도다.
다음 네 등급으로 나누면 논의가 빨라진다.
| 요청 등급 | 대상 예시 | 기본 방침 |
|---|---|---|
| 공유 가능한 정적 정보 | 문서, 공지, 제품 설명, 버전 고정 자료 | 긴 캐시 수명과 CDN 배포를 우선 검토 |
| 공개 목록·조회 | 카탈로그, 검색 결과, 상태 목록 | 결과 범위와 호출 빈도를 관리 |
| 계산량이 큰 공개 기능 | 복잡한 필터, 비교 화면, 대량 파일 목록, 무거운 렌더링 | 쿼리 범위 제한, 전용 캐시, 별도 예산 적용 |
| 인증·민감 기능 | 계정, 결제, 관리자, 내보내기 | 인증·권한·감사 정책을 우선 적용 |
여기서 공개 경로는 “브라우저에서 누구나 열 수 있는 주소”를 뜻할 뿐, 원본 시스템을 무제한으로 호출해도 된다는 의미는 아니다. 검색 결과 하나가 데이터베이스 정렬, 외부 API 호출, 대용량 HTML 생성으로 이어진다면 정적 문서와 같은 정책으로 다루면 안 된다.
각 경로에는 아래 항목을 붙인다.
- 요청이 호출하는 애플리케이션, 데이터베이스, 외부 API
- 응답 내용이 로그인 상태, 권한, 지역, 언어, 재고 상태에 따라 달라지는지
- 공유 캐시 가능 여부와 허용 가능한 갱신 지연
- 결과 수, 페이지 깊이, 응답 크기에 대한 상한
- 한도 초과 시 반환할 응답과 담당 승인자
- 장애 때 먼저 보호할 자원, 예를 들어 데이터베이스 연결 수나 외부 API 호출량
이 표는 보안 정책 문서가 아니라 운영 계약서에 가깝다. 제품팀은 공개 범위를 결정하고, 플랫폼팀은 캐시와 제한 규칙을 구현하며, SRE와 운영 담당자는 장애 시 되돌릴 기준을 갖게 된다.
캐시 설계: URL 개수가 아니라 같은 결과를 몇 번 만드는지 본다
에이전트 기반 접근이 늘면 사람이 따라가는 메뉴 구조보다 넓은 주소 공간이 요청 대상이 된다. 정렬 옵션, 필터 조건, 브랜치 이름, 추적 파라미터, 화면 형식이 달라질 때마다 같은 결과를 다시 생성한다면 캐시는 기대만큼 원본을 보호하지 못한다.
따라서 캐시 설계의 출발점은 “이 URL을 저장할 수 있는가”가 아니라 다음 질문이다.
서로 다른 요청이 같은 콘텐츠 결과를 공유해도 되는가?
변경되지 않는 식별자가 있다면 캐시 정책에 반영한다. 문서 버전, 발행 ID, 콘텐츠 해시, 특정 데이터 스냅샷처럼 결과를 고정하는 값이 대표적이다. 반대로 응답 내용에 영향을 주지 않는 추적 파라미터나 화면 장식 값은 캐시 키에 포함할 이유가 약하다.
다만 키를 줄이기 전에 응답 경계를 확인해야 한다. 권한, 테넌트, 지역별 가격, 언어별 고지처럼 내용의 의미를 바꾸는 값은 성능을 위해 제거할 대상이 아니다. 캐시 공유 범위는 플랫폼팀만 정하지 말고 서비스 오너와 보안 담당자가 함께 승인하는 편이 안전하다.
페이지 전체를 저장할지, 공통 부분만 따로 저장할지도 측정 뒤에 결정한다. 예를 들어 본문 데이터는 여러 화면에서 같지만 탐색 메뉴나 사용자 상태만 다르다면 공통 데이터 조각을 재사용하는 방안을 검토할 수 있다. 반대로 조각을 너무 많이 나누면 조립 과정과 캐시 미스가 늘어 전체 응답이 느려질 수 있다.
조각 캐시는 다음 조건에서 우선순위가 높다.
- 여러 화면에서 같은 데이터가 반복 사용된다.
- 공통 부분을 만드는 비용이 화면 조립 비용보다 크다.
- 해당 조각의 공유 범위가 명확하다.
- 캐시 미스 때 원본 호출이 늘어도 서비스가 견딜 여력이 있다.
접근 정책은 허용·제한·차단을 비용 기준으로 연결한다
접근 정책은 “허용”과 “차단” 두 상태만으로 운영하기 어렵다. 공개 정적 문서처럼 넓게 배포해도 되는 경로가 있는 반면, 원본 비용이 큰 검색·비교·렌더링 기능은 제한된 속도와 결과 범위 안에서 제공해야 한다.
권장하는 정책 구조는 세 층이다.
첫째, 선언 층에서는 공개 경로와 비공개 경로를 정리한다. 어떤 콘텐츠가 외부에서 재사용 가능한지, 대량 요청을 어디까지 감당할지, 어떤 기능이 인증을 전제로 하는지를 제품 정책과 기술 문서에 일치시킨다.
둘째, 분류 층에서는 요청을 하나의 표식만으로 판단하지 않는다. 헤더 정보, 인증 여부, 요청 빈도, 경로 유형, 결과 크기, 반복 패턴을 함께 관찰한다. 여기서 목표는 요청자의 의도를 추측하는 일이 아니라, 비용이 큰 경로가 어떤 형태로 호출되는지 파악하는 일이다.
셋째, 집행 층에서는 요청 등급별로 다른 제어를 적용한다. 정적 문서는 CDN과 공유 캐시가 대부분의 요청을 흡수하도록 구성한다. 반면 검색과 필터, 대량 조회 기능에는 페이지 크기, 최대 결과 수, 동시 요청 수, 요청 빈도 제한을 둔다. 원본이 처리할 수 없는 요청을 엣지와 애플리케이션 입구에서 걸러내는 것이 핵심이다.
비용 한도도 월간 예산만 뜻하지 않는다. CPU 시간, 데이터베이스 커넥션, 외부 API 호출, 캐시 메모리, 네트워크 송신량 가운데 무엇을 먼저 보호할지 정하는 기준이다. 한도를 넘으면 속도를 낮출지, 축소된 응답을 줄지, 일시적으로 거절할지를 경로별로 결정해 둬야 한다.
구현 산출물: 요청 흐름도와 롤백 기준을 함께 남긴다
구현 전에 복잡한 아키텍처 다이어그램부터 만들 필요는 없다. 요청 하나가 들어와 응답이 나갈 때까지 어느 계층에서 비용과 제한이 발생하는지 보여 주는 흐름도가 더 유용하다.
- 엣지·CDN: 정적 경로, 동적 경로, 캐시 금지 경로를 나눈다.
- WAF·레이트 리밋: 경로별 요청 빈도와 동시성 제한을 적용한다.
- 공유 캐시: 캐시 키, TTL, 무효화 조건, 오래된 응답 허용 범위를 정의한다.
- 애플리케이션: 검색 조건, 정렬 방식, 결과 크기, 렌더링 시간을 제한한다.
- 데이터베이스·외부 API: 웹 계층과 별도로 타임아웃, 재시도, 동시성 상한을 둔다.
- 관측 계층: 일반 사용자 요청과 자동화로 추정되는 요청의 원본 도달률을 비교한다.
각 단계에는 되돌리기 조건을 적는다. 예를 들어 캐시 키를 바꾸는 배포에는 응답 혼합 여부를 확인할 로그와 즉시 이전 설정으로 복귀할 절차가 필요하다. 레이트 리밋을 강화할 때는 정상 브라우저와 내부 점검 도구가 함께 막히지 않았는지 확인할 대시보드와 예외 처리 담당자를 정한다.
검증은 인기 페이지가 아니라 캐시가 약한 경로에서 시작한다
평균적인 인기 페이지 부하 시험만으로는 운영 위험을 충분히 확인하기 어렵다. 인기 페이지는 캐시 적중률이 높아 원본 부담을 숨기기 쉽기 때문이다.
검증 환경에서는 다음 시나리오를 분리한다.
- 같은 공개 문서를 반복 요청했을 때 원본 호출이 줄어드는지
- 정렬과 필터 조합이 다른 요청이 이어질 때 캐시와 원본의 동작이 어떻게 달라지는지
- 대용량 응답과 작은 응답이 섞일 때 대기열과 타임아웃이 안정적인지
- 캐시 노드 일부가 비어 있거나 제거된 상태에서도 원본 보호 규칙이 작동하는지
- 제한 정책을 적용한 뒤 정상 사용자와 내부 운영 도구의 실패율이 증가하지 않는지
합격 기준도 처리량 하나로 정하지 않는다. 캐시 미스 상태의 원본 CPU와 데이터베이스 부하, 외부 API 사용량, 오류 응답의 일관성, 정상 사용자 지연, 제한 정책의 관측 가능성을 함께 본다.
운영 중에는 세 가지 신호를 우선 감시한다. 전체 트래픽보다 원본 도달률이 먼저 높아지는지, 특정 경로의 응답 시간과 외부 의존성 오류가 함께 오르는지, 제한 규칙 변경 뒤 정상 유입과 자동화 연동이 동시에 줄어드는지다. 이런 변화가 보이면 차단 목록을 늘리기 전에 요청 등급과 캐시 키, 결과 범위를 다시 점검하는 편이 낫다.
이번 주에 할 일은 전면 차단 규칙을 만드는 일이 아니다. 비용이 가장 큰 공개 엔드포인트 세 개를 고르고, 각 항목의 캐시 가능 여부, 호출 상한, 초과 시 응답, 담당자를 한 장의 운영 표로 확정해 보자. 그 표가 있어야 다음 트래픽 급증에서 인프라 증설과 접근 제한 가운데 무엇을 먼저 선택할지 흔들리지 않는다.
