OpenAI API changelog에는 2026년 6월 23일 Safety Usage Dashboard 출시가 기록됐습니다. 이 대시보드는 요청에 포함된 safety_identifier 값을 기준으로 차단된 Responses 요청을 보여줍니다. 문장만 보면 “안전 대시보드가 하나 생겼다” 정도지만, 실제 서비스 운영에서는 꽤 중요한 변화입니다. 이제 차단 이벤트를 단순 에러 로그로만 보는 것이 아니라, 최종 사용자나 세션 단위로 묶어 분석할 수 있기 때문입니다.
AI 기능을 제품에 넣으면 운영팀이 반드시 만나는 질문이 있습니다. “왜 이 사용자는 답변을 못 받았나?”, “특정 기능에서만 차단이 많이 발생하나?”, “정상 사용자인데 프롬프트가 과하게 막히는 건 아닌가?”, “악성 사용자가 반복해서 정책을 건드리는가?” Safety Usage Dashboard는 이 질문에 답하기 위한 관측 지점을 제공합니다.
이 글은 safety_identifier를 어떻게 설계하고, 어떤 지표를 보고, 차단 이벤트를 제품 개선으로 연결할지 정리합니다.
먼저 오해를 줄여야 합니다. safety_identifier는 아무 값이나 넣는 잡다한 태그가 아닙니다. OpenAI changelog의 설명처럼 blocked Responses requests를 end user 식별 값 기준으로 보여주기 위한 값입니다. 따라서 운영 목적에 맞게 안정적이고, 개인정보를 직접 노출하지 않으며, 재현 가능한 형태로 설계해야 합니다.
나쁜 예는 이메일, 전화번호, 실명, 원본 IP를 그대로 넣는 방식입니다. 이런 값은 개인정보 노출 위험이 크고, 로그 공유나 분석 과정에서 부담이 됩니다. 좋은 예는 내부 user id를 해시하거나, 조직 id와 사용자 id를 조합한 비식별 키를 쓰는 방식입니다.
예를 들어 SaaS라면 다음처럼 나눌 수 있습니다.
user_hashworkspace_hash:user_hashanonymous_session_hashservice_account_hash중요한 것은 같은 최종 사용자가 반복 요청할 때 같은 값으로 묶이고, 운영자가 원하면 내부 시스템에서 원인을 추적할 수 있어야 한다는 점입니다. 단, 대시보드나 외부 로그에 개인정보 원문을 남길 필요는 없습니다.
Safety Usage Dashboard를 제대로 쓰려면 safety_identifier가 일부 요청에만 들어가면 안 됩니다. AI 기능이 여러 곳에 흩어져 있을수록 공통 클라이언트 계층에서 넣는 것이 좋습니다. 예를 들어 채팅, 문서 요약, 코드 생성, 이미지 설명, 검색 기반 답변이 각각 다른 서버 함수에 흩어져 있다면 함수마다 사람이 직접 넣는 방식은 금방 빠집니다.
권장 구조는 이렇습니다.
safety_identifier를 자동 주입한다.여기서 기능명을 safety_identifier에 억지로 넣을 필요는 없습니다. 사용자를 묶는 키와 기능을 묶는 키를 섞으면 분석이 애매해집니다. 사용자 식별은 safety_identifier, 기능/실험/모델/프롬프트 버전은 내부 observability에 남기는 편이 낫습니다.
차단 요청 수가 늘었다고 무조건 나쁜 것은 아닙니다. 제품이 성장해서 요청량이 늘었을 수도 있고, 실제로 위험 요청을 잘 막고 있을 수도 있습니다. 봐야 할 것은 절대 수치가 아니라 비율과 분포입니다.
실무에서 유용한 기준은 네 가지입니다.
예를 들어 전체 차단 비율은 낮은데 특정 사용자 몇 명에게 차단이 몰려 있다면 악성 사용이나 엣지 케이스일 수 있습니다. 반대로 특정 기능을 배포한 직후 차단 비율이 전체적으로 올라갔다면 프롬프트가 정책 경계에 너무 가까운 표현을 유도했을 가능성이 있습니다.
특히 개발자 도구, 보안 분석, 의료/법률 보조, 금융 상담처럼 정책 경계에 가까운 제품은 차단 이벤트를 실패가 아니라 제품 신호로 봐야 합니다. 사용자가 무엇을 하려 했고, 제품이 어디까지 도와야 하며, 어떤 안내 문구로 안전하게 우회할 수 있는지 설계해야 합니다.
차단 이벤트를 관측하는 것만으로는 부족합니다. 사용자에게 어떤 메시지를 보여줄지도 중요합니다. 많은 서비스가 안전 차단을 “요청을 처리할 수 없습니다”로 끝냅니다. 이러면 정상 사용자는 이유를 모르고, 악성 사용자는 다른 표현으로 계속 우회 시도합니다.
좋은 차단 UX는 세 가지를 갖춥니다.
예를 들어 보안 교육 도구에서 공격 코드를 직접 생성해 달라는 요청이 막혔다면, “실제 시스템 공격 절차는 제공할 수 없지만, 방어 관점의 점검 체크리스트나 안전한 실습 환경 구성은 도와드릴 수 있습니다”처럼 방향을 바꿔 줘야 합니다.
이때 내부 로그에는 원문 요청, 프롬프트 버전, 모델, 차단 사유, safety_identifier, 사용자에게 보여준 메시지를 함께 남기는 편이 좋습니다. 그래야 대시보드에서 특정 사용자의 차단이 늘었을 때 실제 UX까지 추적할 수 있습니다.
Safety Usage Dashboard의 목적은 “차단 수를 보는 것”이 아니라 제품을 개선하는 것입니다. 차단 이벤트를 주간 리뷰에 넣으면 의외로 많은 문제가 드러납니다.
예를 들어 문서 요약 기능에서 차단이 자주 발생한다면 사용자가 위험한 문서를 올리는 것일 수도 있지만, 시스템 프롬프트가 “원문을 최대한 자세히 재현하라”고 지시해 민감한 내용을 그대로 생성하려는 구조일 수도 있습니다. 코드 생성 기능에서 차단이 많다면 사용자가 악성 코드를 요구하는 것인지, 보안 학습용 방어 코드를 요청하는데 프롬프트가 맥락을 충분히 설명하지 못하는 것인지 봐야 합니다.
개선 루프는 이렇게 잡을 수 있습니다.
이 과정을 거치면 안전 정책이 제품팀과 분리된 부담이 아니라, 품질 관리 루프가 됩니다.
OpenAI Safety Usage Dashboard는 안전팀만 보는 화면으로 두면 가치가 줄어듭니다. 제품, 백엔드, 데이터, CS가 같은 기준으로 차단 이벤트를 해석할 때 효과가 납니다. 특히 safety_identifier는 나중에 붙이기보다 지금 공통 클라이언트에 넣어 두는 편이 비용이 낮습니다.
바로 실행할 체크리스트는 다음과 같습니다.
safety_identifier에 개인정보 원문을 넣지 않도록 규칙을 정합니다.정리하면, Safety Usage Dashboard는 “막힌 요청 목록”이 아니라 AI 제품의 안전 관측 레이어입니다. safety_identifier 설계를 제대로 해 두면 나중에 문제가 터졌을 때 감으로 추적하지 않아도 됩니다.