Claude API로 콘텐츠 모더레이션 구축하는 방법: 확장 가능한 자동 안전 시스템
왜 콘텐츠 모더레이션에 Claude를 쓰는가
사용자 생성 콘텐츠(UGC)를 다루는 모든 플랫폼은 모더레이션이라는 과제와 마주한다. 커뮤니티 댓글, 상품 리뷰, 채팅 메시지, 게시판 글 등 매일 쏟아지는 콘텐츠를 사람이 일일이 검토하는 방식은 규모가 커질수록 한계에 부딪힌다. 인력 비용은 급증하고, 검토 속도는 떨어지며, 판정 기준은 심사자마다 흔들린다.
전통적인 키워드 필터는 가장 단순한 대안이지만, 맥락을 이해하지 못한다는 치명적 한계가 있다. “죽이다”라는 단어가 게임 공략에서 쓰이는 것과 위협 메시지에서 쓰이는 것은 완전히 다른 맥락인데, 키워드 필터는 이를 구분하지 못한다. 결과적으로 오탐이 폭증하고, 정상적인 사용자가 불필요하게 차단당하는 일이 발생한다.
머신러닝 기반 분류기는 키워드보다 나은 성능을 보이지만, 학습 데이터 수집과 모델 훈련에 상당한 투자가 필요하다. 새로운 유형의 유해 콘텐츠가 등장할 때마다 데이터를 추가하고 재학습시켜야 한다.
Claude가 이 문제에 효과적인 이유는 세 가지다.
첫째, 맥락 이해 능력이 뛰어나다. 동일한 단어라도 주변 맥락에 따라 의미가 달라진다는 것을 파악한다. 풍자, 비유, 인용과 실제 유해 발언을 구분할 수 있다.
둘째, 정책 변경에 즉시 대응할 수 있다. 새로운 규정이 추가되거나 기존 규정이 변경되면 시스템 프롬프트만 수정하면 된다. 모델 재학습이 필요 없다.
셋째, 판정 근거를 자연어로 설명할 수 있다. “이 콘텐츠는 정책 3.2항의 혐오 발언 조항에 해당합니다”와 같은 구체적인 설명을 제공하므로, 이의 제기에 대한 대응이 용이하다.
모더레이션 정책 정의
3단계 분류 체계
효과적인 모더레이션 시스템의 출발점은 명확한 정책 정의다. 정책이 모호하면 아무리 좋은 모델을 써도 일관된 결과를 얻을 수 없다. 실무에서 가장 많이 사용되는 3단계 분류 체계를 기반으로 정책을 구성한다.
승인(approve): 정책 위반 없음. 게시를 허용한다.
플래그(flag): 위반 가능성이 있어 사람의 검토가 필요한 콘텐츠. 즉시 게시하되 검토 대기열에 추가하거나, 검토가 완료될 때까지 게시를 보류할 수 있다. 어떤 방식을 선택할지는 플랫폼의 성격에 따라 다르다.
거부(reject): 명백한 정책 위반. 게시를 차단하고 사용자에게 사유를 안내한다.
카테고리별 기준
분류를 세분화하려면 위반 카테고리를 정의해야 한다. 플랫폼의 성격에 따라 카테고리는 달라지지만, 일반적으로 다음과 같은 항목을 포함한다.
MODERATION_POLICY = {
"categories": {
"hate_speech": {
"description": "인종, 성별, 종교, 성적 지향, 장애 등을 이유로 특정 집단을 비하하거나 차별하는 발언",
"severity": "high",
"examples_reject": [
"특정 민족 전체를 비하하는 표현",
"장애를 조롱하는 발언"
],
"examples_flag": [
"논쟁적이지만 의견 표현의 범위에 있는 발언",
"역사적 맥락에서 차별적 용어를 인용하는 경우"
],
"examples_approve": [
"차별 문제를 비판적으로 논의하는 건설적 글",
"교육 목적으로 역사적 사건을 설명하는 글"
]
},
"violence": {
"description": "폭력을 조장하거나 구체적인 위협을 포함하는 콘텐츠",
"severity": "high",
"examples_reject": [
"특정인에 대한 구체적 폭력 위협",
"테러 행위를 찬양하거나 선동하는 글"
],
"examples_flag": [
"폭력적 표현이 포함되었으나 비유적 사용인지 불분명한 경우"
],
"examples_approve": [
"뉴스 보도에서 폭력 사건을 사실적으로 전달",
"자기 방어에 대한 일반적 논의"
]
},
"sexual_content": {
"description": "성적으로 노골적인 콘텐츠 또는 미성년자 관련 성적 콘텐츠",
"severity": "high",
"examples_reject": [
"미성년자 관련 성적 콘텐츠 (즉시 차단 및 신고)",
"노골적 성인 콘텐츠 (플랫폼 정책에 따라)"
]
},
"spam": {
"description": "상업적 스팸, 사기 시도, 피싱 링크",
"severity": "medium",
"examples_reject": [
"피싱 URL을 포함한 메시지",
"무관한 상업 광고를 반복 게시"
],
"examples_flag": [
"자기 블로그 링크를 포함하되 관련성이 있는 글"
]
},
"misinformation": {
"description": "검증 가능한 사실에 반하는 허위 정보를 의도적으로 퍼뜨리는 콘텐츠",
"severity": "medium",
"examples_reject": [
"건강에 위험을 초래할 수 있는 의료 허위 정보"
],
"examples_flag": [
"출처가 불분명한 주장",
"부분적으로 사실이지만 맥락이 빠져 오해를 유발하는 글"
]
},
"personal_info": {
"description": "타인의 개인정보를 동의 없이 노출하는 콘텐츠",
"severity": "high",
"examples_reject": [
"타인의 주소, 전화번호, 주민등록번호 노출",
"사적 대화 내용을 동의 없이 공개"
]
}
}
}각 카테고리에 구체적인 예시를 포함하는 것이 핵심이다. Claude는 추상적 규칙보다 구체적 예시를 통해 판단 기준을 더 정확하게 학습한다.
분류 시스템 프롬프트 작성
프롬프트 구조
시스템 프롬프트는 모더레이션 시스템의 두뇌와 같다. 프롬프트가 명확하고 체계적일수록 판정 품질이 높아진다.
MODERATION_SYSTEM_PROMPT = """당신은 온라인 플랫폼의 콘텐츠 모더레이터입니다. 사용자가 작성한 콘텐츠를 분석하여 플랫폼 정책 위반 여부를 판정합니다.
## 판정 기준
### 거부 (reject)
다음에 해당하면 즉시 거부합니다:
- 특정 집단에 대한 명백한 혐오 발언 또는 차별 선동
- 특정인에 대한 구체적 폭력 위협
- 미성년자 관련 성적 콘텐츠
- 타인의 개인정보 (주소, 전화번호, 주민등록번호 등) 무단 노출
- 피싱, 사기, 악성 링크
- 건강에 심각한 위험을 초래할 수 있는 의료 허위 정보
### 플래그 (flag)
다음에 해당하면 사람의 검토를 위해 플래그합니다:
- 맥락에 따라 해석이 달라질 수 있는 논쟁적 표현
- 차별적 용어가 포함되었으나 비판, 인용, 교육 목적일 가능성이 있는 경우
- 출처가 불분명한 사실적 주장
- 자해나 위험 행위에 대한 모호한 언급
- 상업적 의도가 의심되지만 확실하지 않은 경우
### 승인 (approve)
위의 거부/플래그 조건에 해당하지 않는 일반적인 콘텐츠는 승인합니다. 다음은 승인 대상입니다:
- 건설적 비판과 의견 표현
- 불만이나 부정적 경험의 공유 (규칙 위반이 아닌 한)
- 뉴스나 사실의 전달
- 교육 목적의 민감한 주제 논의
## 중요 원칙
1. 맥락을 반드시 고려합니다. 동일한 단어라도 맥락에 따라 판정이 달라집니다.
2. 의심스러울 때는 거부보다 플래그를 선택합니다. 과도한 검열은 플랫폼 신뢰를 해칩니다.
3. 풍자, 비유, 인용을 실제 유해 발언과 구분합니다.
4. 문화적 맥락을 고려합니다. 한국어 관용 표현과 인터넷 신조어를 이해합니다.
## 응답 형식
반드시 아래 JSON 형식으로만 응답하세요. 다른 텍스트는 포함하지 마세요.
{
"decision": "approve" | "flag" | "reject",
"category": "해당 카테고리 (approve인 경우 null)",
"confidence": 0.0-1.0,
"reasoning": "판정 근거를 1-2문장으로 설명",
"severity": "low" | "medium" | "high" (approve인 경우 null)
}"""프롬프트에서 주목할 점은 다음과 같다.
거부, 플래그, 승인 순서로 규칙을 나열했다. 가장 중요한 판정부터 체크하도록 유도하는 구조다.
“의심스러울 때는 플래그”라는 원칙을 명시했다. 이 한 줄이 오탐 비율을 크게 낮춘다.
JSON 형식을 정확히 지정했다. 후처리에서 파싱이 실패하면 전체 파이프라인이 멈추므로, 출력 형식을 엄격하게 통제한다.
프롬프트 검증
프롬프트를 작성한 후에는 반드시 다양한 유형의 콘텐츠로 테스트해야 한다. 특히 경계 사례(edge case)를 집중적으로 테스트한다.
test_cases = [
# 명확한 거부
{"content": "XX 민족은 모두 xxx해야 한다", "expected": "reject"},
# 명확한 승인
{"content": "오늘 점심 뭐 먹을지 고민이네요", "expected": "approve"},
# 경계 사례: 교육적 맥락의 민감한 주제
{"content": "역사 수업에서 배웠는데, 과거에는 XX라는 차별적 용어가 공식 문서에 사용되었습니다", "expected": "approve"},
# 경계 사례: 게임 맥락의 폭력적 표현
{"content": "보스를 죽이려면 화염 마법을 써야 한다", "expected": "approve"},
# 경계 사례: 풍자
{"content": "아 정말 죽여주는 노래다", "expected": "approve"},
# 경계 사례: 부정적이지만 합법적인 리뷰
{"content": "이 가게 최악이다. 서비스도 엉망이고 음식도 맛없다. 다시는 안 간다", "expected": "approve"},
]100개 이상의 테스트 케이스를 준비하고, 정확도가 95% 이상이 될 때까지 프롬프트를 반복 수정하는 것을 권한다.
모더레이션 파이프라인 구현
단건 처리
먼저 단건 콘텐츠를 처리하는 기본 함수를 만든다.
import anthropic
import json
client = anthropic.Anthropic()
def moderate_content(content: str, content_type: str = "comment") -> dict:
"""단일 콘텐츠를 모더레이션합니다."""
user_message = f"""다음 {content_type}을 모더레이션해주세요.
---
{content}
---"""
response = client.messages.create(
model="claude-haiku-3-5-20241022",
max_tokens=256,
system=MODERATION_SYSTEM_PROMPT,
messages=[{"role": "user", "content": user_message}]
)
try:
result = json.loads(response.content[0].text)
result["input_tokens"] = response.usage.input_tokens
result["output_tokens"] = response.usage.output_tokens
return result
except json.JSONDecodeError:
return {
"decision": "flag",
"category": "parse_error",
"confidence": 0.0,
"reasoning": "모더레이션 응답 파싱 실패. 수동 검토 필요.",
"severity": "medium"
}모델은 Claude Haiku를 사용한다. 모더레이션은 비교적 단순한 분류 작업이므로 Haiku로도 충분한 성능을 낼 수 있고, 비용은 Sonnet의 약 10분의 1이다. JSON 파싱이 실패하면 안전하게 flag로 분류한다. 파싱 실패 자체를 무시하면 유해 콘텐츠가 빠져나갈 수 있다.
배치 처리
대량의 콘텐츠를 처리하려면 비동기 방식이 필수다.
import asyncio
from anthropic import AsyncAnthropic
async_client = AsyncAnthropic()
async def moderate_single(content: str, semaphore: asyncio.Semaphore) -> dict:
"""세마포어로 동시 요청 수를 제어하면서 단건 처리"""
async with semaphore:
response = await async_client.messages.create(
model="claude-haiku-3-5-20241022",
max_tokens=256,
system=MODERATION_SYSTEM_PROMPT,
messages=[{"role": "user", "content": f"다음 콘텐츠를 모더레이션해주세요.\n\n---\n{content}\n---"}]
)
try:
return json.loads(response.content[0].text)
except json.JSONDecodeError:
return {"decision": "flag", "category": "parse_error", "confidence": 0.0}
async def moderate_batch(contents: list[str], max_concurrent: int = 20) -> list[dict]:
"""대량 콘텐츠를 병렬로 처리합니다."""
semaphore = asyncio.Semaphore(max_concurrent)
tasks = [moderate_single(content, semaphore) for content in contents]
results = await asyncio.gather(*tasks, return_exceptions=True)
processed = []
for i, result in enumerate(results):
if isinstance(result, Exception):
processed.append({
"decision": "flag",
"category": "error",
"reasoning": f"처리 중 오류: {str(result)}"
})
else:
processed.append(result)
return processedsemaphore로 동시 요청 수를 제한하는 것이 중요하다. Anthropic API의 rate limit을 초과하지 않도록 max_concurrent를 조절한다. 계정 티어에 따라 초당 요청 수 제한이 다르므로, 자신의 계정 한도를 확인한 후 설정한다.
실시간 스트림 처리
실시간 채팅이나 댓글처럼 콘텐츠가 지속적으로 유입되는 경우, 큐 기반 처리가 적합하다.
import asyncio
from collections import deque
class ModerationStream:
def __init__(self, max_concurrent=20):
self.queue = asyncio.Queue()
self.semaphore = asyncio.Semaphore(max_concurrent)
self.results = {}
async def submit(self, content_id: str, content: str):
"""모더레이션 대기열에 콘텐츠를 추가합니다."""
await self.queue.put((content_id, content))
async def process_loop(self):
"""대기열에서 콘텐츠를 꺼내 처리하는 무한 루프"""
while True:
content_id, content = await self.queue.get()
asyncio.create_task(self._process_one(content_id, content))
async def _process_one(self, content_id: str, content: str):
async with self.semaphore:
result = await moderate_single(content, self.semaphore)
self.results[content_id] = result
await self._handle_result(content_id, result)
async def _handle_result(self, content_id: str, result: dict):
if result["decision"] == "reject":
await self._remove_content(content_id)
await self._notify_user(content_id, result["reasoning"])
elif result["decision"] == "flag":
await self._add_to_review_queue(content_id, result)이 구조에서는 콘텐츠가 먼저 게시되고 모더레이션이 비동기로 이루어진다. 거부 판정이 나오면 즉시 콘텐츠를 숨기고 사용자에게 알림을 보낸다. 이 방식은 사용자 경험을 해치지 않으면서도 유해 콘텐츠를 신속하게 처리할 수 있다는 장점이 있다.
다만, 게시와 모더레이션 사이의 시간차 동안 유해 콘텐츠가 노출될 수 있다는 점은 인지해야 한다. 위험도가 높은 플랫폼에서는 게시 전 모더레이션(동기 방식)을 고려해야 한다.
대규모 비용 관리
비용 구조 이해
Haiku 기준으로 단건 모더레이션의 비용을 계산해보자.
시스템 프롬프트: 약 800토큰. 사용자 콘텐츠: 평균 200토큰(짧은 댓글 기준). 응답: 약 100토큰. 합계: 약 1,100토큰.
Haiku 가격이 입력 $0.80/MTok, 출력 $4.00/MTok이라고 가정하면, 단건 비용은 약 $0.0012다. 하루 10만 건을 처리하면 일 비용은 약 $120, 월 비용은 약 $3,600이다.
이 비용은 사람 모더레이터 1인의 월급보다 저렴할 수 있지만, 무시할 수 없는 규모다. 비용을 줄이는 전략을 살펴보자.
비용 최적화 전략
1단계 필터로 비용 절감: 모든 콘텐츠를 Claude에 보내기 전에 간단한 규칙 기반 필터를 먼저 적용한다.
import re
def pre_filter(content: str) -> str | None:
"""규칙 기반 사전 필터. 명확한 경우 Claude 호출을 건너뜁니다."""
# 빈 콘텐츠 또는 너무 짧은 콘텐츠
if len(content.strip()) < 3:
return "approve"
# URL만 포함된 스팸성 콘텐츠
url_pattern = r'https?://\S+'
text_without_urls = re.sub(url_pattern, '', content).strip()
if len(text_without_urls) < 5 and re.findall(url_pattern, content):
return "flag" # URL만 있는 콘텐츠는 플래그
# 명확한 피싱/사기 패턴
phishing_patterns = [
r'계좌.*보내',
r'당첨.*클릭',
r'비밀번호.*입력',
]
for pattern in phishing_patterns:
if re.search(pattern, content):
return "reject"
return None # 사전 필터로 판단 불가 -> Claude에 전달이 사전 필터만으로도 전체 트래픽의 20-30%를 Claude 호출 없이 처리할 수 있다.
프롬프트 캐싱 활용: Anthropic의 prompt caching 기능을 사용하면 시스템 프롬프트 부분의 비용을 크게 줄일 수 있다. 동일한 시스템 프롬프트를 반복 사용하므로, 캐싱 효과가 매우 크다.
배치 API 활용: 실시간 처리가 필요하지 않은 콘텐츠(게시 후 수 시간 뒤 검토해도 되는 경우)는 Anthropic의 Batch API를 사용한다. 배치 처리는 실시간 API 대비 50% 할인된 가격이 적용된다.
비용 대비 효과 분석
사람 모더레이터와의 비교를 해보면 다음과 같다.
사람 모더레이터 1인이 하루에 처리할 수 있는 콘텐츠는 약 2,000건이다. 이는 건당 평균 15초를 기준으로 한 수치다. 한국 기준 월 인건비를 300만 원이라고 하면, 건당 비용은 약 75원이다.
Claude Haiku의 건당 비용은 약 1.5원이다. 50배 저렴하다. 물론 Claude만으로 모든 모더레이션을 대체할 수는 없다. 플래그된 콘텐츠를 최종 판단하는 사람 검토자는 여전히 필요하다. 하지만 1차 필터링을 Claude가 담당하면, 사람 검토자는 전체의 5-10%만 처리하면 된다. 기존에 10명이 필요했던 인력을 1-2명으로 줄일 수 있다는 의미다.
다국어 지원
한국어 모더레이션의 특수성
한국어 콘텐츠를 모더레이션할 때는 몇 가지 특수한 사항을 고려해야 한다.
초성 필터 우회: 사용자가 욕설의 초성만 적는 방식(ㅅㅂ, ㅄ 등)으로 필터를 우회하려는 시도가 빈번하다. Claude는 이러한 초성 패턴의 의미를 대체로 파악할 수 있다.
신조어와 인터넷 은어: “극혐”, “노답”, “갈갈이” 같은 인터넷 은어는 맥락에 따라 유해할 수도 아닐 수도 있다. 시스템 프롬프트에 주요 은어 목록과 판단 기준을 포함시키면 정확도가 높아진다.
문화적 맥락: 한국어에서는 직접적인 비하 표현 외에도 특정 지역, 성별, 세대에 대한 미묘한 편견이 담긴 표현이 있다. 이러한 표현의 맥락을 이해하도록 시스템 프롬프트에 관련 지침을 추가한다.
다국어 파이프라인
글로벌 플랫폼에서는 여러 언어의 콘텐츠를 동시에 처리해야 한다.
LANGUAGE_SPECIFIC_RULES = {
"ko": "한국어 초성 욕설(ㅅㅂ, ㅄ 등)과 인터넷 은어를 이해하고 맥락에 따라 판단합니다.",
"ja": "일본어의 경어 체계와 간접적 표현에 주의합니다. 직접적 비하가 아닌 수동공격적 표현도 고려합니다.",
"en": "슬랭, 사이버 불링의 미묘한 형태(subtweeting, vaguebooking 등)를 인식합니다.",
"zh": "중국어 간체와 번체를 모두 처리합니다. 동음이의어를 이용한 검열 우회를 인식합니다."
}
def get_moderation_prompt(language: str) -> str:
base = MODERATION_SYSTEM_PROMPT
lang_rules = LANGUAGE_SPECIFIC_RULES.get(language, "")
if lang_rules:
base += f"\n\n## 언어별 추가 규칙 ({language})\n{lang_rules}"
return baseClaude는 대부분의 주요 언어를 지원하므로, 언어별로 별도 모델을 학습시킬 필요가 없다는 것이 큰 장점이다. 다만 언어별 미묘한 차이를 시스템 프롬프트에 반영하면 정확도가 더 올라간다.
오탐(False Positive) 처리
오탐이 더 위험한 이유
모더레이션에서 오탐(정상 콘텐츠를 유해로 판정)은 미탐(유해 콘텐츠를 정상으로 판정)만큼이나 위험하다. 오탐이 빈번하면 사용자들이 플랫폼에 대한 신뢰를 잃고, 자유로운 표현을 위축시키는 결과를 초래한다.
오탐 비율을 관리하기 위한 전략은 다음과 같다.
confidence 기반 이중 검증
async def moderate_with_double_check(content: str) -> dict:
"""낮은 confidence의 reject는 이중 검증합니다."""
result = await moderate_single(content)
# 높은 confidence의 approve는 바로 통과
if result["decision"] == "approve" and result.get("confidence", 0) > 0.9:
return result
# reject이지만 confidence가 낮으면 한 번 더 검증
if result["decision"] == "reject" and result.get("confidence", 0) < 0.85:
second_opinion = await moderate_single(
content,
model="claude-sonnet-4-20250514" # 더 정교한 모델로 재검증
)
if second_opinion["decision"] != "reject":
return {
"decision": "flag",
"category": result["category"],
"reasoning": "1차 거부 판정이 2차 검증에서 번복됨. 수동 검토 필요.",
"confidence": 0.5,
"first_opinion": result,
"second_opinion": second_opinion
}
return result이 패턴은 비용을 약간 높이지만, 오탐으로 인한 사용자 불만을 크게 줄인다. 전체 콘텐츠 중 reject이면서 confidence가 낮은 경우는 1-2%에 불과하므로, 추가 비용은 미미하다.
이의 제기 프로세스
async def handle_appeal(content_id: str, user_message: str) -> dict:
"""사용자의 이의 제기를 처리합니다."""
original = get_moderation_record(content_id)
appeal_prompt = f"""사용자가 모더레이션 판정에 이의를 제기했습니다.
원본 콘텐츠:
{original['content']}
원래 판정: {original['decision']}
판정 사유: {original['reasoning']}
사용자 이의 내용:
{user_message}
이의 제기를 고려하여 원래 판정이 적절했는지 재검토해주세요.
판정을 유지하거나 변경할 수 있으며, 변경 시 그 이유를 설명해주세요."""
response = client.messages.create(
model="claude-sonnet-4-20250514", # 이의 제기는 상위 모델로 처리
max_tokens=512,
system=MODERATION_SYSTEM_PROMPT,
messages=[{"role": "user", "content": appeal_prompt}]
)
return json.loads(response.content[0].text)이의 제기는 Sonnet 이상의 모델로 처리하는 것이 좋다. 사용자가 시간을 들여 이의를 제기한 만큼, 더 신중한 판단이 필요하기 때문이다.
모니터링과 개선
핵심 지표
프로덕션 모더레이션 시스템은 다음 지표를 지속적으로 추적해야 한다.
정확도(accuracy): 전체 판정 중 올바른 판정의 비율. 사람 검토자가 샘플을 검증하여 측정한다. 목표는 95% 이상이다.
오탐률(false positive rate): 정상 콘텐츠 중 거부 또는 플래그된 비율. 목표는 2% 이하다.
미탐률(false negative rate): 유해 콘텐츠 중 승인된 비율. 목표는 1% 이하다.
평균 처리 시간(latency): API 호출부터 판정까지의 소요 시간. 실시간 시스템에서는 2초 이내를 목표로 한다.
이의 제기 번복률: 이의 제기 후 판정이 변경된 비율. 이 수치가 높으면 정책이나 프롬프트에 문제가 있다는 신호다.
지속적 개선 루프
def weekly_review():
"""주간 모더레이션 품질 리뷰"""
# 1. 이번 주 플래그된 콘텐츠 중 사람이 검토한 결과 수집
flagged_reviews = get_human_reviews(period="7d", decision="flag")
# 2. Claude의 판정과 사람의 최종 결정 비교
disagreements = [r for r in flagged_reviews if r["ai_decision"] != r["human_decision"]]
# 3. 불일치 패턴 분석
patterns = analyze_disagreement_patterns(disagreements)
# 4. 패턴에 기반하여 시스템 프롬프트 개선 제안 생성
suggestions = generate_prompt_improvements(patterns)
return {
"total_reviewed": len(flagged_reviews),
"disagreements": len(disagreements),
"agreement_rate": 1 - len(disagreements) / len(flagged_reviews),
"patterns": patterns,
"suggestions": suggestions
}주간 리뷰를 통해 Claude의 판정과 사람의 판정이 불일치하는 패턴을 찾고, 시스템 프롬프트를 개선하는 루프를 만든다. 이 과정을 반복하면 시간이 지남에 따라 정확도가 꾸준히 향상된다.
마무리
Claude API로 콘텐츠 모더레이션 시스템을 구축할 때의 핵심을 정리한다.
정책이 모든 것의 기반이다. Claude는 정책을 얼마나 잘 정의하느냐에 따라 성능이 결정된다. 모호한 정책은 모호한 판정을 낳는다.
3단계 분류(approve, flag, reject)가 실무에서 가장 잘 작동한다. 이진 분류(허용/차단)는 경계 사례를 처리하기 어렵다.
Haiku가 비용 대비 성능의 최적점이다. 모더레이션은 간결한 분류 작업이므로 경량 모델로도 충분하다.
오탐을 두려워하되, 미탐은 더 두려워해야 한다. 의심스러울 때는 차단보다 플래그가 낫다.
사전 필터와 캐싱으로 비용을 관리한다. 모든 콘텐츠를 Claude에 보낼 필요는 없다.
이의 제기 프로세스는 시스템 신뢰의 핵심이다. 사용자가 자신의 콘텐츠가 부당하게 차단되었다고 느끼면 플랫폼을 떠난다.
주간 리뷰와 프롬프트 개선을 자동화한다. 모더레이션은 배포하면 끝이 아니라, 지속적으로 진화해야 하는 시스템이다.