OpenAI moderation scores 사용법: 생성 결과까지 한 번에 검사하기

OpenAI API changelog에는 2026년 6월 4일 moderation scores가 Responses API와 Chat Completions API에 추가됐다는 내용이 있다. generation request에 moderation object를 전달하면 모델 입력과 생성 출력에 대한 moderation 결과를 함께 받을 수 있다는 업데이트다.

이 기능은 콘텐츠 서비스, 커뮤니티, 상담봇, 자동 작성 도구를 운영하는 개발자에게 유용하다. 기존에는 입력 moderation, 생성, 출력 moderation을 따로 호출하는 구조가 흔했다. 이제는 생성 요청 안에서 입력과 출력을 같이 검사하는 패턴을 더 쉽게 만들 수 있다.

왜 출력 moderation이 중요한가

많은 팀이 사용자 입력만 검사한다. 사용자가 위험한 말을 넣지 않았으면 모델 출력도 안전할 거라고 가정한다. 하지만 실제 운영에서는 그렇지 않다. 모델이 검색 결과, 사용자 프로필, 이전 대화, 도구 응답을 조합하면서 예상 밖의 내용을 생성할 수 있다.

예를 들어 커뮤니티 글 자동 요약 기능을 생각해보자. 원문에는 노골적인 표현이 없지만, 모델이 맥락을 잘못 해석해 공격적인 문장으로 요약할 수 있다. 고객센터 봇에서는 사용자의 불만을 해결하려다 법적 책임을 단정하는 표현을 만들 수 있다. 코드 assistant에서는 보안과 관련된 설명이 방어 목적을 넘어설 위험도 있다.

따라서 입력만 보는 moderation은 절반짜리 방어다. 생성 결과까지 검사해야 실제 사용자에게 노출되는 내용을 통제할 수 있다.

기존 3단계 구조의 문제

기존 구조는 대개 다음과 같았다.

1. 사용자 입력을 moderation API로 검사한다.
2. 통과하면 모델을 호출한다.
3. 모델 출력을 다시 moderation API로 검사한다.
4. 통과하면 사용자에게 보여준다.

이 구조는 명확하지만 단점이 있다. 호출 횟수가 늘고, latency가 증가하고, 실패 처리 코드가 복잡해진다. 특히 실시간 채팅에서는 출력 moderation 때문에 답변 표시가 늦어진다.

generation request 안에서 moderation 결과를 함께 받을 수 있으면 이 흐름을 단순화할 수 있다. 물론 모든 상황에서 별도 moderation 호출이 사라지는 것은 아니다. 고위험 서비스나 규제 산업에서는 별도 정책 엔진과 사람이 보는 검토 단계가 여전히 필요하다. 다만 일반적인 SaaS 기능에서는 기본 안전망을 더 간결하게 만들 수 있다.

moderation scores를 로그로 바꾸기

moderation 결과를 단순 pass/fail로만 쓰면 가치가 줄어든다. scores를 로그로 남기면 제품 지표가 된다. 어떤 기능에서 위험 점수가 높아지는지, 어떤 프롬프트 변경 후 차단이 늘었는지, 어떤 사용자 세그먼트에서 false positive가 많은지 볼 수 있다.

권장 로그 필드는 다음과 같다.

• request_id
• user_id 또는 safety_identifier
• feature_name
• input_moderation_categories
• output_moderation_categories
• max_input_score
• max_output_score
• action_taken: allow, block, redact, review
• model
• prompt_version
• created_at

여기서 prompt_version이 중요하다. 프롬프트를 바꾼 뒤 output moderation score가 올라간다면 모델 문제가 아니라 지시문 문제일 수 있다. 예를 들어 “더 자극적으로 써줘” 같은 마케팅 문구가 의도치 않게 위험 점수를 올릴 수 있다.

차단, 마스킹, 검토를 나누기

모든 위험 신호를 즉시 차단하면 사용자 경험이 나빠진다. 반대로 모두 허용하면 운영 리스크가 커진다. moderation scores를 쓸 때는 action을 세분화해야 한다.

추천 기준은 네 단계다.

1. allow: 낮은 점수, 정상 노출
2. soft warning: 점수는 낮지만 민감 카테고리 근처, 사용자에게 표현 완화 안내
3. redact: 일부 민감 정보나 표현을 마스킹하고 노출
4. block or review: 높은 점수, 노출 차단 또는 관리자 검토

예를 들어 사용자가 의료 관련 질문을 했다고 해서 무조건 차단할 필요는 없다. 하지만 모델이 진단을 단정하거나 약물 복용을 지시하는 출력은 review나 block이 맞다. 점수와 카테고리를 같이 봐야 한다.

또한 action 기준은 기능별로 달라야 한다. 개인 메모 앱의 기준과 공개 커뮤니티 게시글의 기준은 다르다. 공개 게시글은 더 보수적으로, 개인 작업 공간은 사용자 통제권을 더 주는 방식이 가능하다.

safety_identifier와 함께 쓰기

OpenAI는 Safety Usage Dashboard에서 safety_identifier 기반 blocked Responses requests를 보여준다고 안내한 바 있다. moderation scores도 이 식별자와 함께 운영하면 계정 단위 패턴을 볼 수 있다.

주의할 점은 개인정보를 그대로 넣지 않는 것이다. 이메일, 전화번호, 실명 같은 값을 safety_identifier로 보내면 안 된다. 내부 user id를 해시하거나, 안정적인 익명 식별자를 쓰는 편이 안전하다.

이 식별자를 쓰면 다음 질문에 답할 수 있다.

• 특정 기능에서 차단이 늘었는가
• 특정 사용자군에서 반복적인 정책 위반 시도가 있는가
• 프롬프트 변경 후 false positive가 증가했는가
• 모델 변경 후 출력 위험 점수가 낮아졌는가

운영팀은 이 데이터를 바탕으로 정책을 조정할 수 있다. 감으로 “요즘 차단이 많아진 것 같다”고 말하는 대신, 실제 score와 action 분포를 볼 수 있다.

스트리밍 응답에서의 처리

스트리밍 UI에서는 moderation이 더 어렵다. 토큰이 생성되는 즉시 사용자에게 보여주면, 출력 moderation 결과가 도착하기 전에 위험 문장이 노출될 수 있다. 반대로 모든 생성을 끝까지 기다리면 실시간성이 사라진다.

실무에서는 기능 위험도에 따라 세 가지 전략을 쓴다.

• 낮은 위험: 스트리밍 노출, 최종 결과 score 기록
• 중간 위험: 문장 단위 버퍼링 후 노출
• 높은 위험: 전체 생성 후 moderation 확인, 통과 시 노출

커뮤니티 자동 게시글, 법률·의료·금융 조언, 보안 관련 답변은 전체 생성 후 확인하는 편이 안전하다. 일반 요약이나 내부 초안 작성은 버퍼링 또는 사후 기록으로 충분할 수 있다.

실행 체크리스트

• 입력 moderation만 하고 있는 기능을 먼저 목록화한다.
• 사용자에게 직접 노출되는 생성 출력은 output moderation 대상에 포함한다.
• moderation 결과를 pass/fail이 아니라 score와 category로 저장한다.
• prompt_version과 model을 함께 기록한다.
• allow, warning, redact, block, review 액션을 기능별로 정의한다.
• safety_identifier는 개인정보가 아닌 안정적인 익명 식별자를 쓴다.
• 스트리밍 UI는 위험도에 따라 즉시 노출, 버퍼링, 전체 검토 중 하나를 선택한다.

출처: OpenAI API changelog의 moderation scores 업데이트와 Safety Usage Dashboard 안내 기준.