요약: OpenAI는 2026년 6월 omni-moderation-latest와 Responses API, Chat Completions API에서 생성 요청 안에 moderation 객체를 전달해 입력과 출력의 moderation 결과를 함께 받을 수 있도록 업데이트했습니다. 실무 서비스에서는 별도 검수 호출을 줄이고, 사용자 입력과 모델 출력의 리스크를 같은 로그 체계로 남길 수 있다는 점이 중요합니다.
AI 기능을 서비스에 붙이면 처음에는 “모델이 답변만 잘하면 된다”고 생각하기 쉽습니다. 하지만 운영에 들어가면 검수가 더 큰 일이 됩니다. 사용자가 위험한 입력을 넣었는지, 모델 출력이 정책에 걸릴 만한지, 어느 단계에서 차단해야 하는지, 로그를 어떻게 남겨야 하는지 정해야 합니다. 이때 생성 API와 moderation API를 완전히 분리해서 호출하면 코드와 비용, 지연 시간이 모두 늘어납니다.
기존 패턴은 보통 세 단계였습니다. 먼저 사용자 입력을 moderation으로 검사합니다. 통과하면 모델을 호출합니다. 마지막으로 모델 출력을 다시 moderation으로 검사합니다. 이 구조는 명확하지만 호출이 많습니다. 특히 채팅, 고객지원, 커뮤니티 글쓰기 보조처럼 짧은 요청이 자주 들어오는 서비스에서는 왕복 시간이 체감됩니다.
OpenAI API changelog에 따르면 2026년 6월 4일부터 generation request에 moderation 객체를 전달해 입력과 생성 출력 양쪽의 moderation 결과를 같은 응답에서 받을 수 있습니다. 이것은 “검수를 안 해도 된다”는 뜻이 아니라 “검수 결과를 생성 흐름 안에 더 가깝게 붙일 수 있다”는 뜻입니다.
입력 moderation은 사용자가 무엇을 시도하는지 보기 위한 장치입니다. 악성 요청, 금지된 콘텐츠 생성 요구, 개인정보 포함 가능성, 정책 위반 의도가 여기에 걸립니다. 입력 단계에서 막아야 하는 이유는 모델이 불필요하게 위험한 문맥을 처리하지 않게 하기 위해서입니다.
출력 moderation은 서비스가 사용자에게 무엇을 보여주는지 확인하는 장치입니다. 모델이 의도치 않게 위험한 설명을 만들거나, 사용자 입력에 끌려가거나, 민감한 내용을 너무 구체적으로 답할 수 있습니다. 입력이 정상이어도 출력이 문제가 될 수 있기 때문에 두 검수는 별도로 봐야 합니다.
한 요청에서 입력과 출력 결과를 같이 받더라도 저장 구조는 분리하는 편이 좋습니다. 예를 들어 input_moderation, output_moderation, final_action을 각각 남깁니다. 그래야 나중에 “사용자 입력이 문제였나, 모델 출력이 문제였나”를 분석할 수 있습니다.
moderation 결과를 받았다고 해서 모든 경고를 곧바로 차단으로 처리하면 제품 경험이 나빠집니다. 실무에서는 정책 카테고리와 점수에 따라 대응 단계를 나누는 편이 좋습니다.
1단계는 허용입니다. 점수가 낮고 민감 카테고리가 없으면 정상 응답을 보여줍니다. 2단계는 완화입니다. 입력은 허용하지만 출력에서 세부 정보를 줄이거나 안전한 대안 중심으로 답하게 합니다. 3단계는 보류입니다. 커뮤니티 게시글, 공개 댓글, 마켓플레이스 설명처럼 다른 사용자에게 노출되는 콘텐츠는 사람 검토 큐로 보낼 수 있습니다. 4단계는 차단입니다. 명확한 정책 위반, 악용 의도, 반복 위반은 요청을 거절합니다.
이렇게 단계화하면 false positive에 덜 취약합니다. moderation 점수는 운영 신호이지 제품 정책 그 자체가 아닙니다. 점수 하나로 모든 결정을 내리기보다 서비스 맥락과 노출 범위를 함께 봐야 합니다.
검수 기능의 가치는 차단보다 로그에서 나옵니다. 어떤 카테고리가 자주 뜨는지, 특정 기능에서 출력 경고가 많은지, 특정 프롬프트 변경 이후 점수가 올라갔는지 봐야 개선할 수 있습니다. 로그를 남기지 않으면 moderation은 운영자가 체감하기 어려운 블랙박스가 됩니다.
추천 로그 필드는 다음과 같습니다.
개인정보를 그대로 저장하지 않는 것도 중요합니다. 검수 로그에는 원문 전체보다 해시, 짧은 스니펫, 카테고리, 점수 중심으로 남기는 편이 안전합니다. 디버깅을 위해 원문이 필요한 경우에도 보관 기간과 접근 권한을 제한해야 합니다.
출력 moderation 경고가 많다면 모델이 나쁜 것이 아니라 프롬프트가 애매할 수 있습니다. 예를 들어 “자세히 설명해줘”라는 지시가 위험 영역에서 너무 구체적인 답변을 유도할 수 있습니다. 이때 moderation 결과를 보고 프롬프트에 안전한 답변 형식을 추가해야 합니다.
실무에서 효과가 좋은 방식은 “거절문 템플릿”보다 “대체 도움 템플릿”입니다. 사용자가 위험한 요청을 했을 때 단순히 안 된다고 끝내면 재시도만 늘어납니다. 대신 안전한 범위의 개념 설명, 예방 방법, 공식 도움 리소스, 일반적인 체크리스트로 방향을 바꿉니다.
출력 검수 후 재작성 루프를 두는 것도 방법입니다. 1차 출력이 경고를 받으면 바로 차단하지 말고, 안전 지침을 추가해 한 번 더 짧게 재작성합니다. 단, 반복 재작성은 비용과 지연 시간을 키우므로 1회로 제한하는 것이 좋습니다.
커뮤니티 글쓰기 보조 기능을 예로 들어보겠습니다. 사용자가 초안을 입력하면 모델이 제목과 본문을 다듬어줍니다. 이때 입력 moderation에서 높은 위험 점수가 나오면 글쓰기 보조를 중단하고 “공개 게시글로 다듬을 수 없는 내용”이라고 안내합니다. 입력은 낮지만 출력에서 경고가 나오면 모델에게 표현을 완화해 다시 작성하게 합니다. 그래도 경고가 남으면 게시 전 검토 큐로 보냅니다.
중요한 점은 사용자에게 내부 점수를 보여주지 않는 것입니다. “moderation score가 높습니다”라는 말은 제품 언어가 아닙니다. 대신 “공개 게시글로 올리기 어려운 표현이 있어 수정이 필요합니다”처럼 행동 가능한 안내를 줘야 합니다.
관리자 화면에는 다르게 보여줄 수 있습니다. 기능별 경고율, 카테고리 분포, 차단 사유, 재작성 성공률을 보여주면 운영자가 정책을 조정할 수 있습니다. 개발자는 이 데이터를 보고 프롬프트 버전별 품질을 비교할 수 있습니다.
Responses API moderation 점수 통합은 검수 호출을 줄이는 편의 기능을 넘어, AI 기능의 운영 관측성을 높이는 변화입니다. 입력과 출력을 같은 흐름에서 기록하면 어떤 프롬프트가 위험한지, 어떤 기능에서 경고가 많은지, 어디서 사람 검토가 필요한지 빠르게 볼 수 있습니다. 실무 개발자는 API 옵션을 켜는 것보다 먼저 로그 구조와 대응 단계를 설계해야 합니다.
