Cloudflare의 새 API 지표 화면은 조사할 대상을 고르는 데 활용해 보세요. 같은 operation과 같은 기간을 놓고 요청 수, 오류, 지연, 응답 크기, 보안 관측을 차례로 보면 다음에 확인할 질문을 정하기 쉬워집니다. 트래픽이 가장 많은 API와 오류 비율이 가장 높은 API가 서로 다를 수 있으므로, 어떤 사용자 동작에 영향이 있는지까지 함께 적어 보세요.
Cloudflare는 2026년 11월 11일 Web Assets > Operations에 지표 중심 보기와 서버 쪽 정렬을 추가했다고 발표했습니다. 이 글은 여러 API를 관리하는 운영자가 화면의 순위를 어떻게 조사 질문으로 바꿀지 설명합니다. 공식 공지와 관련 문서를 11월 12일 확인했으며, 실제 고객 계정의 지표를 수집하거나 보안 정책을 변경한 사례를 제시하는 글은 아닙니다.
먼저 같은 API를 보고 있는지 확인해요
Cloudflare 문서에서 operation은 HTTP 메서드, 호스트 패턴, 경로 패턴으로 구분되는 요청 묶음입니다. URL의 일부가 비슷하더라도 조회 요청과 변경 요청은 동작이 다를 수 있어요. 조사 메모에는 화면에 보이는 이름 옆에 메서드와 호스트·경로 조건을 적어 두면 좋습니다. 서로 다른 대상을 한 API의 전후 수치처럼 비교하는 일을 줄일 수 있어요.
예를 들어 상품을 읽는 요청과 주문을 생성하는 요청은 업무에서 담당하는 일이 다릅니다. 같은 서비스의 경로라고 해도 정상적인 요청 수와 실패의 영향이 같다고 가정하기는 어려워요. 이 글의 예시는 실제 사이트의 수치를 가져온 것이 아니라, 조사 대상을 정할 때 메서드와 목적을 함께 기록하는 방식을 보여 주기 위한 것입니다.
시간 범위도 먼저 맞추세요. Endpoint Management 문서는 최근 24시간 또는 7일의 상세 지표를 볼 수 있다고 안내합니다. 하루 중 특정 행사 구간과 평소 한 주를 그대로 비교하면 트래픽 패턴의 차이가 섞여요. 어떤 구간을 보고 있는지, 해당 구간에 배포나 행사·장애 대응이 있었는지 한 줄씩 적어 보세요.
요청 수와 오류 비율에 각각 질문을 붙여요
이번 공지에서 말하는 지표 보기에는 트래픽과 오류가 포함됩니다. 트래픽 관점은 많은 요청이 지나가는 동작을 찾는 출발점이 될 수 있어요. 오류 관점은 실패가 몰리는 대상을 고를 때 쓸 수 있습니다. 두 화면의 순위를 같이 읽고, 실제로 어느 사용자 동작이 영향을 받았는지 확인할 차례입니다.
단순한 계산 예시를 볼게요. 가상의 API A에서 요청 10건 가운데 5건이 오류이고, API B에서 요청 1만 건 가운데 100건이 오류라면 오류 비율은 각각 50%와 1%입니다. 비율만 보면 A가 높고 오류 건수만 보면 B가 큽니다. 이것만으로 조사 순서를 확정할 수는 없어요. 주문 완료처럼 중요한 동작인지, 시험 요청인지, 같은 사용자의 반복 요청인지까지 봐야 합니다.
따라서 오류 메모에는 분모가 되는 요청 수와 오류 건수를 함께 남겨 보세요. 작은 표본의 높은 비율을 큰 장애처럼 부풀리거나, 많은 이용자가 겪은 실패를 낮은 비율이라는 이유로 지나치지 않게 하는 방식입니다. 모든 API에 적용할 임계치를 이 글에서 정하지는 않습니다. 서비스의 정상 패턴과 담당 업무를 기준으로 정할 항목이에요.
공식 문서는 오류를 4xx와 5xx, 그리고 합계로 구분해 볼 수 있다고 설명합니다. 이 구분은 조사를 시작할 단서예요. 어떤 상태 코드가 늘었는지, 원래 예상한 거절인지, 실제로 실패하면 안 되는 요청인지 확인할 수 있습니다. 상태 코드 그룹 하나만으로 공격이나 원본 장애의 원인을 확정하지는 마세요.
지연을 볼 때는 측정 대상부터 읽어 보세요
Endpoint Management가 설명하는 지연은 밀리초 단위의 평균 원본 응답 시간입니다. 화면의 수치를 사용자에게 보이는 전체 체감 시간이나 가장 느린 요청의 시간으로 바로 바꾸어 말하면 범위가 달라져요. 어떤 구간을 측정한 값인지 확인한 뒤 서비스 로그나 애플리케이션 관측과 연결하는 편이 좋습니다.
가상의 업무 화면에서 ‘검색 결과가 늦게 나온다’는 문의를 받았다고 해 볼게요. 해당 검색 operation의 평균 지연이 같은 시간에 바뀌었는지 살펴보고, 동시에 요청 수와 오류가 어떻게 움직였는지 적을 수 있습니다. 지연이 변하지 않았다면 다음 조사는 브라우저 동작이나 다른 요청 등으로 넓힐 수 있겠죠. 대시보드는 원인을 미리 정하는 도구보다 조사의 범위를 좁히는 자료로 쓰면 좋습니다.
평균값만으로 일부 이용자의 느린 요청을 충분히 설명하지 못할 수도 있어요. 이 글은 새 화면에 특정 백분위 지표가 추가됐다고 가정하지 않습니다. 필요한 질문이 평균으로 답해지지 않는다면 현재 사용 가능한 로그와 관측 도구에서 추가 자료를 확인하고, 아직 모르는 구간은 그 상태로 남겨 두세요.
특히 지연 칸이 비어 있을 때는 주의가 필요합니다. 공식 문서는 Workers가 경로에서 동작하거나 Workers 기반 제품이 개입하여 요청이 원본으로 직접 전달되지 않는 경우 일부 성능 지표가 채워지지 않을 수 있다고 설명해요. 빈칸을 지연 0으로 쓰기 전에 해당 경로의 처리 방식을 확인하세요. 관측할 수 없는 값과 실제 측정값은 기록에서도 나누어야 합니다.
응답 크기와 보안 보기를 함께 읽는 법
응답 크기는 원본이 돌려주는 평균 바이트 수로 설명됩니다. 큰 응답을 찾았다면 그 API가 원래 많은 데이터를 주는 용도인지부터 물어보세요. 상세 조회나 목록, 파일 관련 동작은 목적이 다를 수 있어요. 같은 operation의 이전 구간과 비교하고, 응답 데이터나 배포 내용이 바뀌었는지 확인할 수 있습니다.
예를 들어 목록 API의 평균 응답 크기가 바뀌었다면 필드가 추가됐는지, 조회 조건과 데이터 양이 달라졌는지 조사할 수 있어요. 이때 응답 크기 증가를 곧바로 데이터 유출이라고 부르면 확인한 사실을 넘어서게 됩니다. 보안 보기에서 얻은 단서가 있다면 해당 이벤트와 요청을 담당 절차에 따라 확인하는 다음 단계가 필요해요.
보안 항목의 접근 조건도 기능별로 읽어 보세요. Endpoint Management 페이지는 모든 플랜에서 사용할 수 있는 것으로 안내하지만, 같은 문서가 설명하는 민감 정보 탐지에는 별도의 Enterprise·애플리케이션 보안 플랜 조건이 있습니다. 목록 화면을 열 수 있다는 사실만으로 모든 보안 탐지 기능을 같은 조건으로 사용할 수 있다고 정리하면 안 됩니다.
민감한 요청이나 응답을 조사할 때는 내용을 통째로 일반 메모나 공개 이슈에 복사하기보다, 필요한 식별 정보와 확인 시각을 담당자가 접근할 수 있는 기록에 남겨 주세요. 이 글의 목적은 실제 API나 개인 데이터를 외부로 보내는 것이 아니라, 어떤 원본 자료를 더 확인해야 하는지 질문을 정하는 데 있습니다.
발견, 프로필 학습, 보호 동작을 차례로 구분해요
Web Assets는 Cloudflare를 거치는 트래픽에서 operation을 발견하고 목록에 모읍니다. Endpoint Management 문서는 발견된 항목이 목록에 들어가는 것만으로 프로필 학습이 시작되지는 않는다고 설명해요. 학습을 검토한다면 먼저 메서드·호스트·경로가 의도한 대상을 가리키는지 확인할 수 있습니다.
Application Profiles 안내는 학습된 동작을 바탕으로 애플리케이션별 맥락을 다루는 별도 내용을 설명합니다. 따라서 이번 지표 보기의 순위를 확인한 행위, 프로필을 학습한 상태, 보호 정책을 검토하거나 적용한 상태를 각각 기록해 보세요. 예를 들어 ‘오류가 많은 항목을 찾았다’는 결과만으로 보호 조치가 완료됐다고 보고하지 않는 방식입니다.
목록을 정리하는 변경도 기록이 필요합니다. 공식 문서는 operation의 메서드·호스트·경로를 고치면 ID가 달라진다고 안내합니다. 기존 ID에서 보던 추세와 새 ID의 지표를 같은 대상으로 이어 읽을 때는 이 변경을 알려 주세요. 비교 구간 중간에 분류 기준이 바뀌었다면 수치 변화의 설명에도 포함되어야 합니다.
특히 operation 삭제는 신중히 다루세요. 문서에 따르면 전체 operation을 삭제하면 관련 성능·분석 추적이 중단되고 이전 이력은 복원할 수 없습니다. 삭제 뒤 다시 추적이 시작되는 상황에서도 이전 기록을 그대로 되찾는 것은 아니에요. 이 글에서는 정렬 화면을 살펴보기 위해 운영 항목을 지우는 절차를 제안하지 않습니다.
조사 메모를 한 항목으로 끝내 보세요
목록 전체에 동시에 손대기보다, 이번에 확인할 사용자 동작 하나를 정해 보세요. operation의 메서드·호스트·경로, 관측 기간, 요청 수와 오류, 지연·크기에서 눈에 띈 점, 아직 모르는 구간을 짧게 적는 방식입니다. 이어서 확인할 원본 로그나 담당자를 정하면 단순 순위표가 다음 행동으로 연결됩니다.
아래는 직접 만든 인계 예시입니다. ‘주문 생성 operation의 오전 구간에서 오류 건수와 비율을 함께 확인했습니다. 지연 칸은 경로의 Workers 개입 여부를 확인하기 전이라 해석을 보류했습니다. 같은 시각의 원본 로그와 배포 기록을 담당자에게 확인합니다.’ 실제 장애 보고를 인용한 문장은 아니며, 관찰과 미확인을 나누는 형식입니다.
지표를 본 뒤 설정을 바꿀 필요가 생겼다면 현재 대상을 확인하고 변경 권한·영향·복원 절차를 먼저 검토하세요. 같은 시간에 배포와 보호 정책을 여러 개 바꾸면 어떤 변화와 관련됐는지 판단이 어려워질 수 있어요. 이 글의 화면 안내는 문서로 확인했으며 실제 계정의 조사·학습·보호 정책 적용을 수행하지 않았습니다.
자주 묻는 질문과 공식 자료
지표 정렬의 맨 위 항목부터 처리하면 되나요? 어떤 지표로 정렬했는지 먼저 읽고, 표본과 업무 영향을 함께 확인해 보세요. 요청 수·비율·평균값은 각각 답하는 질문이 달라요. 조사 순서는 해당 서비스의 담당자와 운영 기준으로 정할 항목입니다.
Workers 경로의 지연이 비어 있으면 정상인가요? 문서에 설명된 관측 제한에 해당할 수 있습니다. 빈 값을 0이나 정상으로 바꾸지 말고 실제 경로와 다른 관측 자료를 확인하세요. 화면에서 아직 답을 얻지 못했다는 상태도 필요한 기록입니다.
새 보기를 쓰면 보안 조치가 자동으로 끝나나요? 이번 공지는 지표 중심 보기와 정렬 개선에 관한 내용입니다. 발견된 항목의 검토, 프로필 학습, 실제 보호 정책과 권한은 각각 확인해야 합니다. 표시와 운영 조치를 한꺼번에 완료로 적지 않는 것이 좋겠어요.
공식 확인일은 2026년 11월 12일입니다. 다음 날 개별 계정에서 보일 메뉴나 모든 하위 기능의 이용 조건을 보장하지 않으며, 실제 계정에 표시된 기능과 계약 범위를 함께 확인해 주세요.
- 11월 11일 지표 보기 개선 공지
- Endpoint Management 지표·제한 안내
- Web Assets의 operation 정의와 발견 방식
- Application Profiles 안내
보안 도구를 고를 때의 비용·오탐·운영 조건은 AWS WAF와 Cloudflare를 비교한 기존 글에서 함께 살펴볼 수 있습니다.
'소프트웨어개발' 카테고리의 다른 글
| Hyperdrive 연결 한도 1,500개로 확대: DB 풀을 늘리기 전 볼 세 가지 (0) | 2026.11.13 |
|---|---|
| GitHub 대시보드가 더 촘촘해졌어요: 여섯 항목에서 할 일 찾기 (0) | 2026.11.12 |
| Cloudflare One Client Windows 베타: 연결됐는데 느릴 때 볼 지표 (0) | 2026.11.12 |
