OpenAI Safety Usage Dashboard 사용법: 차단 로그를 제품 지표로 바꾸기

요약: OpenAI는 2026년 6월 23일 API 플랫폼에 Safety Usage Dashboard를 공개했습니다. 이 대시보드는 safety_identifier를 기준으로 차단된 Responses 요청을 보여줍니다. 실무적으로는 “왜 막혔는지 느낌으로 보는 화면”이 아니라, 사용자·기능·프롬프트 단위로 안전성 이슈를 제품 지표화하는 출발점입니다.

AI 기능을 운영하다 보면 모델 품질보다 먼저 부딪히는 문제가 있습니다. 어떤 사용자는 정상 업무 요청을 했는데 차단됐다고 느끼고, 어떤 사용자는 명백히 위험한 요청을 반복합니다. 개발팀은 로그를 뒤져야 하고, CS팀은 “AI가 안 된다”는 문의만 받습니다. Safety Usage Dashboard는 이 문제를 줄이기 위한 관찰 도구입니다.

safety_identifier를 꼭 넣어야 하는 이유

Safety dashboard가 의미 있으려면 요청에 safety_identifier를 넣어야 합니다. 이 값은 최종 사용자를 식별하는 안정적인 값이어야 합니다. 이메일이나 전화번호 같은 원본 개인정보를 그대로 넣기보다 내부 user id, 해시된 계정 id, 조직 id와 조합한 값을 쓰는 편이 안전합니다.

나쁜 예시는 다음과 같습니다.

• 요청마다 랜덤 UUID를 넣는다.
• 모든 사용자에게 같은 값을 넣는다.
• 이메일 주소를 그대로 넣는다.
• 프론트엔드에서 사용자가 임의로 바꿀 수 있는 값을 넣는다.

좋은 예시는 다음과 같습니다.

• user_7f3a...처럼 서버에서 발급한 내부 사용자 식별자
• org_123:user_456처럼 조직과 사용자를 함께 볼 수 있는 값
• 개인정보 원본 대신 서버에서 생성한 stable hash
• 비로그인 사용자는 세션 id와 rate limit key를 분리해서 관리

이 값이 안정적이어야 반복 차단 패턴을 볼 수 있습니다. 사용자별로 차단이 몰리는지, 특정 기능에서만 차단이 늘어나는지 구분할 수 있기 때문입니다.

차단 로그를 보는 기본 관점

Safety Usage Dashboard를 열었을 때 먼저 봐야 할 것은 총 차단 수가 아닙니다. 차단 수는 트래픽이 늘면 같이 늘어납니다. 더 중요한 건 비율과 집중도입니다.

추천 지표는 다음과 같습니다.

• 요청 대비 차단율: 전체 Responses 요청 중 차단된 비율
• 기능별 차단율: 글쓰기, 검색, 요약, 코드 생성 등 기능별 비율
• 사용자별 반복 차단: 같은 safety_identifier에서 반복되는 차단 횟수
• 신규 릴리스 전후 변화: prompt 변경, 모델 변경, 정책 변경 후 차단율 차이
• false positive 후보: 정상 업무 플로우에서 갑자기 늘어난 차단

예를 들어 전체 차단율이 0.3%에서 0.6%로 늘었다고 해서 바로 문제라고 볼 수는 없습니다. 하지만 특정 기능의 차단율이 0.2%에서 5%로 뛰었다면 prompt나 입력 전처리 변경을 의심해야 합니다.

false positive를 줄이는 실무 절차

AI 제품에서 안전 차단은 필요하지만, 정상 사용자를 막으면 곧바로 이탈로 이어집니다. 특히 기업용 도구에서는 “보안 감사 보고서 작성”, “취약점 설명”, “사기 탐지 룰 검토”처럼 단어만 보면 위험해 보이지만 실제로는 정상 업무인 요청이 많습니다.

false positive를 줄이려면 차단된 원문을 그대로 개발자에게 뿌리는 방식은 피해야 합니다. 개인정보나 민감 정보가 섞일 수 있기 때문입니다. 대신 아래 구조가 좋습니다.

1. 차단 이벤트를 기능명, 사용자 식별자, 모델, prompt version, timestamp와 함께 저장한다.
2. 원문은 민감정보 제거 또는 짧은 보존 기간을 적용한다.
3. 반복 차단이 많은 기능부터 샘플링 리뷰한다.
4. 정상 업무로 판단되는 케이스는 prompt에 업무 맥락을 더 명확히 넣는다.
5. 여전히 애매한 케이스는 사용자에게 재작성 가이드를 보여준다.

예를 들어 보안 교육 앱이라면 system prompt에 “이 제품은 방어적 보안 교육과 내부 정책 점검을 돕는다”는 맥락을 넣어야 합니다. 단순히 “취약점 설명해줘”라는 사용자 입력만 모델에 보내면 의도 판단이 흔들릴 수 있습니다.

abuse 대응은 차단 수보다 반복 패턴을 본다

반대로 진짜 abuse도 있습니다. 어떤 사용자는 금지된 요청을 표현만 바꿔 반복합니다. 이때 중요한 건 단일 요청 차단이 아니라 반복 패턴입니다.

safety_identifier를 기준으로 아래 조건을 만들 수 있습니다.

• 10분 안에 5회 이상 차단: 일시적 쿨다운
• 하루 20회 이상 차단: 기능 제한 또는 추가 인증
• 여러 계정이 같은 IP/조직에서 같은 패턴 반복: 조직 단위 알림
• 차단 후 곧바로 prompt injection 시도 증가: 세션 폐기

이 규칙은 제품 성격에 맞춰 조정해야 합니다. 개발자 도구나 보안 도구는 위험 키워드가 정상적으로 많이 등장하므로 단순 차단 횟수 기준이 과도할 수 있습니다. 대신 “차단된 요청의 의도 범주”와 “정상 기능 맥락”을 같이 봐야 합니다.

운영 로그와 대시보드를 연결하는 방법

Safety Usage Dashboard만 보고 끝내면 분석이 끊깁니다. 제품 DB 또는 로그 시스템에도 최소 필드를 남겨야 합니다.

추천 필드:

• request_id
• safety_identifier
• user_id 또는 org_id의 내부 참조값
• feature_name
• prompt_version
• model
• blocked 여부
• fallback 노출 여부
• 사용자가 재시도했는지 여부
• 최종 성공 여부

이렇게 저장하면 “차단됐다”에서 끝나지 않고 사용자 경험까지 볼 수 있습니다. 차단 후 사용자가 문구를 바꿔 성공했는지, 그냥 이탈했는지, CS 문의로 이어졌는지 연결할 수 있습니다.

사용자 안내 문구도 제품 품질이다

차단이 발생했을 때 “정책상 처리할 수 없습니다”만 보여주면 사용자는 무엇을 바꿔야 할지 모릅니다. 특히 정상 업무 요청이 막힌 경우 불만이 커집니다.

좋은 안내 문구는 세 가지를 포함합니다.

• 어떤 범주의 요청이 제한됐는지 짧게 설명
• 안전한 대체 요청 예시 제공
• 필요하면 사람 검토 또는 고객지원 경로 제공

예를 들어 보안 문서 작성 도구라면 “공격 실행 절차는 도와드릴 수 없지만, 방어 관점의 점검 체크리스트나 위험 설명 문서로 바꿔 작성할 수 있습니다”처럼 대체 행동을 제안해야 합니다.

실행 체크리스트

• Responses API 요청에 안정적인 safety_identifier를 넣는다.
• 이메일, 전화번호 같은 개인정보 원본을 식별자로 쓰지 않는다.
• 기능명, prompt version, model, blocked 여부를 내부 로그에도 남긴다.
• 전체 차단 수보다 기능별 차단율과 반복 사용자 패턴을 본다.
• 정상 업무가 막힌 케이스는 prompt 맥락과 입력 전처리를 먼저 점검한다.
• abuse 의심 케이스는 쿨다운, rate limit, 추가 인증을 단계적으로 적용한다.
• 차단 안내 문구에는 대체 요청 예시를 넣는다.
• 릴리스 전후 차단율 변화를 배포 체크리스트에 포함한다.

OpenAI Safety Usage Dashboard는 안전팀만 보는 화면이 아닙니다. 제품팀은 false positive를 줄이고, 개발팀은 prompt 변경 영향을 추적하고, 운영팀은 반복 abuse에 대응할 수 있습니다. 핵심은 safety_identifier를 대충 넣지 않는 것입니다. 식별자가 안정적이어야 차단 로그가 제품 지표가 됩니다.