---
date: 2026-05-25
topic: image-rights-risk-filter
---

# Image Rights Risk Filter

## Summary

신청 이미지를 주기적으로 전수 분석해 운영자에게 0-100 위험도와 검토 근거를 제공하는 내부 권리 리스크 필터를 만든다. 시스템은 승인, 보류, 반려를 자동 결정하지 않고 운영자 판단을 돕는 추천 도구로 동작한다.

---

## Problem Frame

이미지를 상품화하는 운영자는 신청자가 실제 권리자인지, 이미지가 유명인 초상이나 저작권 있는 캐릭터/작품을 포함하는지 1차로 걸러야 한다. 현재 이 판단을 사람이 처음부터 모두 확인하면 검토량이 커지고, 권리 없는 이미지가 상품화되는 법적·운영 리스크가 생긴다.

특히 국내 연예인, 아이돌, 배우, 스포츠 스타, 한국 방송·웹툰·게임·캐릭터 이미지는 신청자가 권리 없이 제출할 가능성이 있다. 반대로 자동 탐지가 틀릴 수 있으므로 시스템이 법적 판단이나 최종 심사를 대신하면 오탐 비용과 책임이 커진다.

---

## Actors

- A1. 신청자: 상품화할 이미지를 제출하지만 자동 분석 결과는 보지 않는다.
- A2. 운영자: 분석 점수와 근거를 확인하고 승인, 보류, 반려 중 최종 상태를 결정한다.
- A3. 필터링 시스템: 배치로 신청 이미지를 분석하고 위험도, 사유, 근거를 생성한다.
- A4. 외부 이미지 분석 API: 계약상 데이터 비저장 조건을 충족할 때만 축소본을 분석해 웹 탐지 근거를 반환한다.

---

## Key Flows

- F1. 배치 위험도 분석
  - **Trigger:** 새 신청 이미지가 쌓이고 정기 배치가 실행된다.
  - **Actors:** A3, A4
  - **Steps:** 필터링 시스템은 모든 신청 이미지를 대상으로 내부 분석을 수행하고, 조건이 충족된 외부 API에는 EXIF가 제거된 축소본만 전송한다. 내부 분석, 외부 검색 근거, 기존 기준 DB, 과거 판정 이력을 합산해 위험도와 사유를 생성한다.
  - **Outcome:** 각 신청에는 0-100 위험도, 사유 목록, 운영 근거가 붙는다.
  - **Covered by:** R1, R5, R6, R8, R9, R11, R12, R13, R15, R25, R26, R27

- F2. 운영자 검토
  - **Trigger:** 운영자가 신청 목록 또는 검토 큐를 확인한다.
  - **Actors:** A2, A3
  - **Steps:** 운영자는 위험도 점수, 사유, 근거 URL, 감지된 엔티티, 유사 이미지 정보를 확인한다. 시스템 추천을 참고하되 직접 승인, 보류, 반려 중 하나를 선택한다.
  - **Outcome:** 최종 판정과 메모가 신청 기록에 남는다.
  - **Covered by:** R12, R13, R16, R17, R18, R19

- F3. 기준 DB 누적
  - **Trigger:** 운영자가 이미지를 반려하거나, 운영자가 위험 엔티티를 직접 등록한다.
  - **Actors:** A2, A3
  - **Steps:** 반려 이미지는 자동으로 기준 DB에 누적되고, 운영자는 별도로 엔티티명, 별칭, 샘플 이미지, 정책 메모, 예외 조건을 등록할 수 있다. 잘못 누적된 항목은 이후 비활성화하거나 정정할 수 있어야 한다.
  - **Outcome:** 이후 신청 이미지의 유사도와 위험도 산정에 누적된 지식이 반영된다.
  - **Covered by:** R20, R21, R22, R23, R24

---

## Requirements

**분석 범위**
- R1. 시스템은 신청 이미지를 대량 배치 방식으로 전수 분석해야 한다.
- R2. 1차 위험 유형은 유명인/연예인 초상권 위험과 저작권 캐릭터/작품 이미지 위험으로 둔다.
- R3. 1차 튜닝 범위는 한국 중심으로 하며, 국내 연예인, K-pop, 한국 방송·영화·웹툰·게임·캐릭터를 우선한다.
- R4. 글로벌 IP, 브랜드, 로고, 상표, 스톡 이미지 도용은 1차 핵심 범위가 아니지만 외부 검색 결과에서 강한 근거가 우연히 발견되면 사유로 기록할 수 있다. 단, 이를 위한 별도 탐지기, 튜닝, 관리 화면은 1차 범위에 포함하지 않는다.

**내부 분석**
- R5. 시스템은 이미지 해시와 유사 해시를 생성해 동일 이미지, 변형 이미지, 과거 반려 이미지, 운영자 등록 샘플과 비교할 수 있어야 한다.
- R6. 시스템은 얼굴 또는 사람 존재 여부를 탐지해 초상권 검토 신호로 사용해야 한다.
- R7. 얼굴 또는 사람이 감지됐다는 사실만으로 고위험 처리하지 않고, 유명인 또는 권리물 근거가 함께 있을 때 위험도를 크게 올려야 한다.

**외부 검색 및 데이터 제한**
- R8. 외부 API 사용은 전송 이미지 콘텐츠가 저장·학습·공개·제3자 공유되지 않는다는 조건과 요청 메타데이터 로그 범위·보관 기간이 법무·개인정보 기준에서 허용된다는 조건이 확인된 경우에만 허용한다.
- R9. 외부 API에는 내부 원본이 아니라 EXIF가 제거되고 운영 기준상 허용된 최대 해상도 이하로 줄어든 축소본만 전송한다.
- R10. Google 이미지 검색 또는 Google Lens 웹 UI 자동화와 스크래핑은 사용하지 않는다.
- R11. Google Cloud Vision `WEB_DETECTION`은 데이터 사용 조건 확인 후 조건부 후보로 사용하되, 비동기 오프라인 배치 방식은 사용하지 않는다.

**위험도와 근거**
- R12. 분석 결과는 0-100 위험도 점수와 사유 목록으로 제공해야 한다.
- R13. 위험 사유는 운영자가 이해할 수 있는 단위로 제공해야 하며, 얼굴/사람 감지, 해시 유사도, 웹 엔티티, 일치·유사 이미지, 근거 URL, 과거 반려 이력 등을 포함할 수 있어야 한다.
- R14. 팬아트 또는 AI 생성 이미지도 특정 유명인, 캐릭터, 작품과 연결되는 강한 근거가 있으면 고위험으로 분류할 수 있어야 한다.
- R15. 분석 실패나 애매한 경우는 낮은 위험도로 숨기지 않고 중간 위험도 사유로 표시해야 한다. 단, 실패 사유는 이미 탐지된 고위험 신호나 기존 위험도를 낮추는 근거로 사용하지 않는다.

**운영자 검토**
- R16. 시스템은 신청 상태를 자동으로 변경하지 않고 추천만 제공해야 한다.
- R17. 운영자의 최종 상태는 승인, 보류, 반려로 제한한다.
- R18. 자동 분석 결과는 신청자에게 노출하지 않고 운영자 내부 검토용으로만 사용한다.
- R19. 운영자는 최종 판정과 판정 메모를 남길 수 있어야 한다.

**기준 DB와 운영 지식**
- R20. 기준 DB는 처음 비어 있는 상태로 시작할 수 있어야 하며, 검색 결과, 운영자 등록, 반려 판정을 통해 누적되어야 한다.
- R21. 운영자는 위험 엔티티를 등록할 때 엔티티명, 별칭, 유형, 관련 키워드, 이미지 수준 샘플 지문, 정책 메모, 예외 조건을 관리할 수 있어야 한다. 얼굴 임베딩이나 특정 개인 식별용 생체 템플릿은 샘플 지문으로 저장하지 않는다.
- R22. 반려 판정 이미지는 이후 유사 이미지 탐지 기준으로 자동 누적되어야 한다.
- R23. 자동 누적 항목과 수동 등록 항목은 구분되어야 한다.
- R24. 오판으로 인한 기준 DB 오염을 줄이기 위해 누적 항목을 비활성화하거나 정정할 수 있어야 한다.

**근거 보관과 운영 안정성**
- R25. 시스템은 위험도 점수, 위험 사유, 해시/유사 해시, 감지 결과, 웹 엔티티, 근거 URL, 분석 시각, 분석 버전, 외부 API 사용 여부, 운영자 판정과 메모를 운영 근거로 보관해야 한다.
- R26. 내부 원본 이미지, 축소본, 분석용 파생 파일, 이미지 지문, 운영 근거 데이터는 접근 권한, 보관 기간, 삭제, 정정 정책의 적용 대상이어야 한다.
- R27. 외부 API 비용과 장애에 대비해 재분석 방지, 사용량 한도, 실패 재시도, 외부 API 비활성화 운영 모드를 제공해야 한다.

---

## Acceptance Examples

- AE1. **Covers R5, R12, R13, R22.** 과거 반려 이미지와 유사한 신청 이미지가 들어오면, 배치 분석 후 높은 해시 유사도 사유와 함께 위험도가 상승하고 운영자 화면에 근거가 표시된다.
- AE2. **Covers R6, R7, R12.** 사람 얼굴이 있는 일반 사진이 들어오면 얼굴 감지 사유는 남지만, 유명인 또는 권리물 근거가 없으면 얼굴 감지만으로 고위험이 되지 않는다.
- AE3. **Covers R8, R9, R10, R11.** 외부 API 조건이 확인되지 않았거나 비활성화된 상태에서는 원본·축소본 모두 외부로 전송하지 않고 내부 분석 결과만으로 점수를 산정한다.
- AE4. **Covers R14.** AI 생성풍 이미지가 특정 캐릭터명, 작품명, 일치 이미지 URL 등 강한 근거와 함께 탐지되면 사진 원본 복제가 아니어도 고위험 사유가 붙는다.
- AE5. **Covers R15.** 이미지 손상이나 API 장애로 분석에 실패하면 해당 신청은 낮은 위험도로 처리되지 않고, 분석 실패 사유와 함께 중간 위험도 검토 대상으로 남는다. 이미 다른 분석에서 고위험 근거가 발견된 경우 실패 사유는 그 위험도를 낮추지 않는다.
- AE6. **Covers R16, R17, R18.** 위험도 90점 이미지가 분석되어도 시스템은 상태를 반려로 바꾸지 않고, 운영자만 승인, 보류, 반려 중 하나를 선택할 수 있다.
- AE7. **Covers R20, R21, R23, R24.** 운영자가 유명인 또는 캐릭터 엔티티를 수동 등록하면 이후 점수 계산에 반영되고, 잘못 등록된 항목은 비활성화해 새 분석에 반영되지 않도록 할 수 있다.
- AE8. **Covers R21, R26.** 운영자가 유명인 샘플 이미지를 등록하면 시스템은 이미지 수준 지문과 운영 메모를 관리하되, 특정 개인을 식별하기 위한 얼굴 생체 템플릿은 저장하지 않는다.

---

## Success Criteria

- 운영자는 신청 이미지를 처음부터 모두 수동 조사하지 않고도 고위험 후보를 우선 검토할 수 있다.
- 권리 없는 유명인·캐릭터 이미지가 상품화 단계로 넘어갈 가능성이 낮아진다.
- 위험도 산정 근거가 남아 운영자 판정, 재검토, 정책 개선에 사용할 수 있다.
- 빈 기준 DB로 시작해도 외부 검색 근거와 운영자 판정 누적으로 시간이 갈수록 내부 기준이 강화된다.
- 자동 판정이 아니라 추천 도구로 동작해 오탐으로 인한 자동 반려 리스크를 줄인다.
- 후속 계획 단계가 분석 범위, 운영 흐름, 데이터 보관, 외부 API 제한, 비목표를 새로 invent하지 않아도 된다.

---

## Scope Boundaries

- 자동 승인, 자동 보류, 자동 반려 상태 변경은 포함하지 않는다.
- 신청자에게 위험 점수, 검색 근거, 자동 분석 사유를 노출하지 않는다.
- Google 이미지 검색 또는 Google Lens 웹 UI 자동화와 스크래핑은 포함하지 않는다.
- 글로벌 IP를 1차 튜닝 중심으로 삼지 않는다.
- 브랜드, 로고, 상표, 스톡 이미지 도용을 위한 별도 탐지기, 튜닝, 관리 화면은 1차 핵심 범위에 포함하지 않는다.
- 특정 개인 얼굴 인식 자체를 내부에서 직접 수행하지 않는다.
- 이 기능은 법률 자문이나 최종 권리 판단을 대체하지 않는다.

---

## Key Decisions

- 검토 큐 분류 중심: 자동 차단보다 운영자가 볼 위험 후보를 정렬하고 설명하는 것이 1차 목표다.
- 배치 전수 분석: 신청자 제출 흐름을 지연시키지 않고도 모든 신청 이미지에 위험 근거를 붙인다.
- 한국 중심 우선순위: 국내 연예인, K-pop, 방송, 웹툰, 게임, 캐릭터 위험을 먼저 잡는다.
- 내부 원본 저장과 외부 축소본 전송 분리: 원본은 내부 운영 저장소에 보관하되, 외부 API에는 제한된 파생 이미지만 보낸다.
- 외부 API 조건부 사용: 공식 API의 데이터 사용 조건과 계약이 확인된 경우에만 사용한다.
- 운영 지식 누적: 초기 DB가 비어 있어도 반려 판정과 운영자 등록으로 필터 품질을 개선한다.

---

## Dependencies / Assumptions

- Google Cloud Vision은 온라인 즉시 응답 방식에서 이미지 데이터를 메모리 처리하고 디스크에 저장하지 않는다고 공식 문서에 설명되어 있으나, 일부 요청 메타데이터는 임시 로그될 수 있다. 실제 사용 전 계약 조건, 메타데이터 로그 범위, 조직의 법무·개인정보 기준 확인이 필요하다. 참고: https://docs.cloud.google.com/vision/docs/data-usage
- Google Cloud Vision의 얼굴 탐지는 특정 개인 식별을 지원하지 않으므로, 유명인 판단은 웹 엔티티, 유사 이미지, 운영자 등록 지식, 판정 이력 같은 근거 조합으로 다뤄야 한다. 참고: https://docs.cloud.google.com/vision/docs/detecting-faces
- Google Cloud Vision의 웹 탐지는 웹 엔티티, 일치 이미지, 유사 이미지, 이미지가 포함된 페이지 같은 근거를 반환할 수 있다. 참고: https://docs.cloud.google.com/vision/docs/detecting-web
- 외부 API 비용과 쿼터는 신청량에 따라 커질 수 있으므로 사용량 제한과 비활성화 모드가 운영상 필요하다.
- 반려 이미지 자동 누적은 필터 성능을 높이지만, 잘못된 반려가 기준 DB를 오염시킬 수 있어 정정 흐름이 필요하다.
- 내부 원본 이미지 보관을 허용하더라도 원본, 축소본, 파생 파일, 이미지 지문은 각각 별도의 보관·접근·삭제 정책을 가져야 한다.
- 샘플 이미지 지문은 이미지 유사도와 중복 탐지를 위한 값으로 한정하고, 특정 개인 얼굴을 식별하기 위한 생체 정보 저장소로 확장하지 않는다.

---

## Outstanding Questions

### Deferred to Planning

- [Affects R5, R12][Technical] 이미지 해시와 유사 해시의 정확도 기준, 점수 가중치, 재분석 주기를 정해야 한다.
- [Affects R6, R7][Technical] 얼굴/사람 탐지 모델 또는 API를 어떤 방식으로 구성할지 정해야 한다.
- [Affects R8, R11][Needs research] Google Cloud Vision 사용 전 계약, DPA, 이미지 콘텐츠 보관, 요청 메타데이터 로그, 지역 설정 조건을 최종 확인해야 한다.
- [Affects R12, R13][Technical] 위험도 0-100 산식과 운영자 화면의 사유 우선순위를 정해야 한다.
- [Affects R25, R26][Technical] 원본 이미지, 축소본, 파생 파일, 이미지 지문, 근거 URL, 판정 이력의 보관 기간, 삭제 정책, 접근 권한을 정해야 한다.
