콘텐츠 검토 정확도와 판정 규칙을 명시적 정책으로 개선

review_loop.py를 리팩토링하면서 모델 업그레이드와 판정 규칙을 정책 문서 수준으로 명시했다.

왜 모델을 바꿨나

처음에는 Haiku를 썼다. 빠르고 비용 효율적이니까. 그런데 보니까 검토 정확도가 중요한 지점들이 있었다. 특히 verdict(검증 판정)를 내릴 때 경계 케이스(borderline case)에서 헷갈렸다. "이게 규정에 저촉되는지 안 되는지" 판단이 애매한 콘텐츠들 말이다.

Sonnet으로 업그레이드한 이유는 단순한 성능 추구가 아니라, 팀이 감당할 수 있는 오류율(error rate)의 선을 정했기 때문이다. Haiku의 처리량은 좋지만, 그 대신 수동 재검토 케이스가 늘어났다. 결국 Sonnet으로 정확도를 높여서 재검토 비용을 줄이는 게 net positive인지 계산해야 했다. 이건 단순 모델 성능 문제가 아니라 운영 효율의 문제였다.

임계값과 분리 룰을 명시한 이유

가장 까다로운 부분은 임계값의 모호함이었다. 예를 들어:
- verdict의 confidence score가 0.7이면 통과? 0.8이면?
- 어떤 속성은 엄격하게, 어떤 속성은 관대하게 봐야 하는가?
- 마스킹(민감 정보 처리)과 광고(광고/비광고 판정)를 섞어서 평가하면 안 되나?

이런 규칙이 암묵적으로만 존재했을 때 가장 문제가 되는 건:
- 사람마다 다르게 해석한다 (코드리뷰 때 "어? 이건 왜 통과했어?" 발생)
- 모델 평가할 때 기준이 흔들린다 (같은 케이스도 날 따라 판정이 달라짐)
- 신규 담당자가 온보딩할 때 전수(傳授)가 불가능하다

규칙을 코드로 박은 방식

이번 리팩토링에서 핵심은 정책을 설정 파일 수준에서 관리하는 거였다. 예를 들면:

# 변경 후: 규칙이 명시적 상수로 정의됨
VERDICT_THRESHOLDS = {
    'confidence_min': 0.75,
    'strict_attributes': ['privacy', 'harmful'],  # 엄격한 기준
    'lenient_attributes': ['style'],  # 관대한 기준
}

MASKING_RULES = {
    'enabled': True,
    'sensitive_patterns': [...]  # PII 마스킹 규칙
}

AD_SEPARATION_RULES = {
    'treat_as_ad': [...],  # 광고로 분류할 조건
    'treat_as_content': [...]  # 일반 콘텐츠로 분류할 조건
}

이렇게 하면 논쟁의 여지가 줄어든다. "왜 이건 통과했어?"라는 질문이 올 때 "임계값이 0.75인데 이건 0.78이라서"라고 명확하게 답할 수 있다.

팀 입장에서 본 개선

이런 명시화의 진짜 가치는:

1. 새로운 팀원 온보딩 — 규칙을 문서가 아니라 코드에서 읽을 수 있다
2. 모니터링과 개선 — "최근 오판이 많다"면, 어느 임계값을 조정할지 명확하다
3. 감사(audit) — 왜 이 콘텐츠가 통과/거절됐는지 역추적이 쉽다
4. 모델 실험 — Haiku→Sonnet 바꿀 때 baseline 설정이 명확하다

배운 점

회사 초창기나 프로토타입 단계에서는 "일단 빠르게" 하는 게 맞다. Haiku도 훌륭한 선택이었다. 하지만 운영이 안정화되고 팀이 커질수록, 규칙과 임계값을 코드와 정책 문서의 중간 지점에서 관리해야 한다.

특히 검토, 분류, 판정 같은 업무는 주관적 여지가 크기 때문에, 명시적 규칙이 단순 기술 개선이 아니라 거버넌스 도구가 된다. 다음번 리팩토링할 때도 이 패턴을 기억해야겠다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.