Cloudflare AI Gateway 로그 설정: 제어와 시험

Cloudflare AI Gateway 로그 설정은 팀에 필요한 증거와 보관을 피해야 할 내용에서 시작해야 합니다. 대시보드는 요청을 보이게 하면서 프롬프트, 응답, 메타데이터의 새로운 저장소를 만들 수도 있습니다. 올바른 설정은 운영 용도와 계정의 현재 로그 계약 모두에 달려 있습니다.

게이트웨이가 현재 Workers Logs 방식인지 Legacy Logs인지 먼저 확립하고 수집과 본문 저장을 의도적으로 설정하세요. 합성 표식으로 실제 요청 경로를 시험하고 생성된 기록을 검사해야 합니다. 적절한 경우 유용한 운영 메타데이터를 보관하되 본문 저장을 껐다고 다른 모든 시스템에서도 데이터가 없어졌다고 가정하면 안 됩니다.

고객 메시지가 프롬프트에 포함되는 지원 도우미를 생각해 보세요. 엔지니어는 제공업체 실패를 진단하고 사용량을 귀속해야 합니다. 하지만 전체 메시지를 일반 진단 저장소에 복사할 필요는 없을 수 있습니다. 이것은 설정과 증거의 문제이며 관찰 가능성을 포기할 이유는 아닙니다.

이 안내는 제안하는 운영 설정에 초점을 둡니다. 법적 준수 인증을 제공하지 않으며, 모든 계정의 가격, 보관, 내보내기 조건이 같다고 가정하지 않습니다.

Cloudflare AI Gateway 로그 설정은 적용 조건에 따라 다릅니다

현재 AI Gateway 로그 문서 는 고객이 첫 게이트웨이를 만든 시점으로 구분합니다. 첫 게이트웨이를 2026년 9월 24일 또는 그 이후에 만든 고객은 Workers Logs 가격과 보관 조건을 따르고, 그 이전 고객은 Legacy Logs를 사용합니다. 설정할 실제 계정의 적용 조건을 확인하세요.

오래된 글의 보관 기간이나 로그 허용량을 모든 배포에 적용하지 마세요. 해당 서비스 조건, 선택 설정, 확인 날짜를 기록해야 합니다. 계정이나 로그 구조가 바뀌면 다시 확인하세요.

같은 문서는 전체 로그 항목 수집과 요청 및 응답 본문 저장을 분리합니다. 단순히 로그가 켜졌는지 꺼졌는지 묻는 것보다 더 정확하게 논의할 수 있습니다.

사고 조사 질문부터 정의하기

운영자가 답해야 할 질문을 쓰세요. 어떤 작업 부하가 실패했나요? 어떤 제공업체와 모델 경로를 썼나요? 앱이 재시도했나요? 사용자가 기다리기를 멈추기 전에 응답했나요? 목적지 작업이 아직 미해결인가요?

그중 많은 질문은 제한된 메타데이터와 앱 작업 번호로 답할 수 있습니다. 항상 프롬프트 전체가 필요한 것은 아닙니다. 반대로 내용 품질 조사는 일반 요청 메타데이터로 설명할 수 없는, 명시적으로 통제한 표본을 필요로 할 수 있습니다.

이 용도를 나누세요. 일상 진단에는 한 수집 정책을 쓰고 승인된 조사에는 별도로 검토한 증거 절차를 사용할 수 있습니다. 언젠가 결함 재현에 도움이 될 수 있다는 이유로 모든 고객 글을 영구 보관하지 마세요.

기존 AI Gateway 안내 는 더 넓은 프록시와 비용 제어 역할을 다룹니다. 여기의 설정 작업은 실제 증거가 무엇인지 확립하고 선택한 수집 동작을 입증하는 것입니다.

전체 기록과 본문 제어를 따로 설정하기

Cloudflare는 전체 항목 수집에 cf-aig-collect-log, 요청과 응답 본문 저장에 cf-aig-collect-log-payload를 문서화합니다. 본문 제어를 false로 설정하면 원시 본문 없이 메타데이터를 유지할 수 있습니다. 전체 항목을 끄면 메타데이터를 포함한 항목 자체가 수집되지 않습니다. 적용 전에 현재 헤더 의미를 읽으세요.

다음은 예시 헤더 정책일 뿐 완전한 요청이나 실제 배포 결과의 증거가 아닙니다.

1cf-aig-collect-log-payload: false

정책은 신뢰할 앱 구성 요소에 적용하세요. 비신뢰 호출자가 임의 게이트웨이 제어 헤더를 넣어 조직의 증거 정책을 바꾸게 해서는 안 됩니다. 서버가 어떤 헤더를 전달하고 설정하며 제거할지 결정해야 합니다.

한 번의 성공 요청으로 기본값을 추론하지 마세요. 게이트웨이 수준 설정과 요청별 덮어쓰기 경로를 별도로 검증해야 합니다. 주 모델 경로에서 되는 설정도 대체 경로나 다른 클라이언트에서는 다르게 동작할 수 있습니다.

실제 적용 정책 기록하기

앱 측 설정을 버전 관리하고 관련 게이트웨이 설정을 기록하세요. 어떤 요청 종류가 본문을 보관하고, 어떤 것은 메타데이터만 남기며, 어떤 것은 수집을 막는지 설명해야 합니다.

개발자가 다른 모델 통합을 추가할 때 로그 경로도 검토해야 합니다. 그렇지 않으면 팀은 전체 정책이 하나라고 믿는 동안 서로 다른 보관 동작의 경로가 쌓일 수 있습니다.

메타데이터가 다른 본문이 되지 않게 하기

내용을 드러내지 않는 작업과 요청 번호로 게이트웨이 증거를 앱 기록에 연결할 수 있습니다. 지원 사례 번호만으로 기존 접근 모델 아래 원본을 찾을 수 있을지 모릅니다. 제목이나 고객 이메일을 메타데이터에 복사하면 본문을 제외한 이유가 무너집니다.

허용 메타데이터 스키마를 정의하세요. 필드 이름뿐 아니라 값도 검사해야 합니다. label이라는 필드도 사용자의 글로 채우면 개인 또는 기밀 내용을 포함할 수 있습니다.

앱과 게이트웨이 참조를 조사에 충분할 만큼 일관되게 유지하세요. 운영자는 전체 프롬프트를 도구 사이에 복사하거나 모든 엔지니어에게 고객 시스템 접근을 주지 않고도 실패를 추적할 수 있어야 합니다.

합성 표식으로 수집 검증하기

독특한 표식을 넣은 비민감 테스트 요청을 보내세요. 적절한 로그 목적지에서 표식이 의도한 정책 아래 본문 저장, 메타데이터, 내보내기, 관련 앱 로그에 나타나는지 확인해야 합니다.

정상 응답, 상위 오류, 앱에서 사용한다면 대체 경로도 시험하세요. 오류 처리는 정상 수집 경로 밖의 진단 필드에 요청 본문을 복사하기 쉬운 지점입니다.

Cloudflare의 인증 게이트웨이 문서 가 그 접근 제어의 기준입니다. 로그 설정이 엔드포인트도 보호한다고 가정하지 말고 실제 배포의 자격 증명과 경로를 확인하세요.

내보내기와 다른 저장소도 검토하기

게이트웨이 본문 억제가 앱, 모델 제공업체, 외부 관찰 서비스에서 아무것도 보관하지 않는다는 증거는 아닙니다. 실제 데이터 경로를 그리고 각 저장소를 자체 계약으로 검토하세요.

로그를 내보낸다면 누가 목적지를 읽을 수 있고 사본은 언제 만료되는지 문서화하세요. 한 서비스에서 기록을 지웠다고 이전 내보내기도 삭제됐다고 입증되지는 않습니다. 운영 절차서는 어느 시스템이 어떤 증거를 책임지는지 설명해야 합니다.

추적, 예외 추적기, 지원 스크린샷도 검토하세요. 게이트웨이를 올바르게 설정했어도 더 넓은 집단이 보는 티켓에 고객 프롬프트를 붙여 넣을 수 있습니다.

일상 회귀 시험은 합성 사례로 하세요. 결함 조사에 실제 내용이 필요하다면 기록 없이 일반 정책을 바꾸지 말고 구체적인 수집 목적과 통제된 접근을 확립해야 합니다.

유용한 증거와 유지보수의 예산 잡기

구현에는 데이터 경로 검토, 요청 정책 연결, 메타데이터 스키마, 접근 준비, 검증이 포함됩니다. 반복 비용은 적용 로그 조건, 양, 하위 저장소에 달려 있으므로 추정 전에 계정의 현재 요금을 확인하세요.

게이트웨이 조건과 납품 시험을 식별하는 GBP 제안을 요청하세요. 설정만 하는 일과 여러 모델 경로 및 내보내기 목적지의 앱 로그를 다시 만드는 일은 다릅니다.

인계에는 실제 정책, 책임, 합성 시험 결과, 증거가 없을 때 조사하는 절차를 포함해야 합니다. 특히 새 클라이언트, 경로, 로그 저장소처럼 재검증을 일으키는 설정 변경도 적으세요.

당사의 범위가 정해진 AI 통합 파일럿 에서 이 경계를 검토할 수 있습니다. 계정 적용 조건, 모델 경로, 현재 저장소, 사고 질문을 포함해 게이트웨이 로그 평가 요청 을 보내 주세요. 기본값이 허용한다는 이유만으로 내용을 모으지 않고 유용한 관찰 가능성을 확보할 수 있습니다.

자주 묻는 질문

모든 AI Gateway 계정이 같은 로그 조건을 쓰나요? 아닙니다. 현재 문서는 첫 게이트웨이를 2026년 9월 24일 또는 그 이후에 만든 고객과 이전 고객을 구분합니다. 가격이나 보관 가정에 의존하기 전에 Workers Logs 또는 Legacy Logs 중 무엇이 적용되는지 확인하세요.

프롬프트와 응답 본문 없이 메타데이터를 보관할 수 있나요? 문서화된 본문 수집 제어는 적절한 설정에서 메타데이터 전용 항목을 지원합니다. 실제 게이트웨이와 요청별 정책을 검증하고 실제 로그 목적지의 시험 결과를 확인하세요.

두 수집 헤더는 어떻게 다른가요? 전체 항목 제어는 로그 항목 수집 여부를 결정합니다. 본문 제어는 메타데이터를 남길 수 있는 상태에서 원시 요청과 응답 본문 저장을 결정합니다. 전체를 끄면 메타데이터도 사라지므로 필요한 증거로 선택하세요.

본문을 억제하면 어떤 서비스도 데이터를 저장하지 않나요? 아닙니다. 다른 앱 로그, 제공업체, 내보내기, 관찰 도구는 자체 동작과 계약이 있습니다. 하나의 설정을 보편적인 보관 보장으로 취급하지 말고 전체 경로를 검토하세요.

고객 데이터 없이 로그를 어떻게 시험하나요? 비민감 요청에 합성 표식을 넣고 관련 기록과 내보내기를 검사하세요. 정상 결과, 오류, 재시도, 대체 경로를 포함하고 메타데이터에 표식이 간접적으로 들어가지 않는지도 확인하세요.

클라이언트가 로그 정책을 골라도 되나요? 그 권한을 의도한 경우에만 가능합니다. 신뢰할 서버 구성 요소에 조직 정책을 적용하고 어떤 제어 헤더를 수락하거나 덮어쓰는지 정의하세요. 일반 호출자가 증거 정책을 조용히 바꾸면 안 됩니다.

평가는 무엇을 납품해야 하나요? 적용 계약, 데이터 저장소, 실제 수집 정책, 접근 책임자, 보관 결정을 식별해야 합니다. 합성 검증 결과와 새 모델 경로나 로그 저장소를 반복 확인할 절차도 포함하세요.