분석 보고서: NSFWJS 기반 T2Editor SafeAI (NSFW)의 기대 성능
T2Editor 9.1.0의 SafeAI(NSFW)는 서버 추론형 고정 성능 제품이 아니라, 브라우저 안에서 TensorFlow.js + NSFWJS가 직접 추론하는 구조입니다. 따라서 성능은 모델 종류, 백엔드(WebGPU/WebGL/WASM/CPU), 브라우저 구현, 사용자 기기 성능에 따라 달라집니다. 이 문서는 공식 자료가 보장하는 범위와 T2Editor에서 현실적으로 기대할 수 있는 수준을 구분해서 설명합니다.
문서 목적
이 문서는 다음 질문에 답하기 위해 작성되었습니다.
- NSFWJS를 붙인 T2Editor SafeAI는 얼마나 정확할 것으로 기대할 수 있는가?
- WebGPU, WebGL, WASM, CPU 중 어떤 백엔드에서 어떤 운영 기대치를 가져야 하는가?
- 기본 제공
MobileNetV2Mid를 선택한 이유는 무엇인가? - 이 기능을 보안 장치로 봐야 하는가, 아니면 사용자 보조 필터로 봐야 하는가?
결론 먼저
T2Editor 9.1.0의 SafeAI(NSFW)는 업로드 전 사용자 측 경고/차단 보조 시스템으로는 적합하지만, 법적/정책적 책임이 걸린 최종 심사 엔진으로 간주하면 안 됩니다.
요약하면 다음과 같습니다.
| 항목 | 기대 평가 | 해설 |
|---|---|---|
| 정확도 | 중상 | NSFWJS 공식 자료 기준으로 small 모델은 약 90%, midsized 모델은 약 93% 수준이라고 안내됩니다. T2Editor는 이 중 MobileNetV2Mid를 채택하므로 기본 모델보다 높은 정확도를 기대할 수 있습니다. |
| 응답성 | 중상~상 | 지원 브라우저/하드웨어에서 webgpu가 가장 유력한 최고 성능 경로입니다. 다만 미지원 환경에서는 webgl, wasm, cpu로 내려가며 체감 속도 차이가 커질 수 있습니다. |
| 초기 로딩 | 중 | 첫 모델 로딩 비용은 분명 존재합니다. 자체 호스팅과 캐싱으로 첫 로딩 부담을 줄일 수 있습니다. |
| 운영 안정성 | 중상 | self-hosted 자산으로 바꾸면 외부 CDN 장애와 핫링크 문제를 피하기 쉽습니다. |
| 심사 엔진 적합성 | 낮음 | 단독 최종 판정 엔진으로 쓰기엔 공식 자료 자체가 '완벽하지 않다'고 전제합니다. |
공식 자료가 말하는 정확도
NSFWJS 공식 README는 이 라이브러리가 완벽하지는 않지만 꽤 정확하다고 설명하면서, small 모델은 약 90%, midsized 모델은 약 93%라고 안내합니다. T2Editor 9.1.0에서 채택한 방향은 MobileNetV2Mid이므로, 공식 자료만 놓고 보면 기본 MobileNetV2보다 한 단계 높은 정확도 기대치를 갖는 구성이 됩니다. NSFWJS 공식 저장소
이 문장을 T2Editor 관점으로 번역하면 다음과 같습니다.
- 안전 이미지 대부분을 무리 없이 통과시키는 보조 필터로는 충분히 실용적이다.
- 노출 가능성이 있는 이미지에 경고를 거는 1차 필터로는 유용하다.
- 하지만 오탐지와 미탐지를 완전히 제거할 수준으로 읽으면 안 된다.
공식 정확도 수치는 T2Editor의 실제 운영 데이터가 아닙니다. 따라서 문서나 운영 보고서에는 "공식 자료 기준 기대 정확도"라고 표현하는 것이 안전합니다.
왜 MobileNetV2Mid를 기본값으로 잡았는가
NSFWJS 공식 자료는 내장 모델로 MobileNetV2, MobileNetV2Mid, InceptionV3를 제시합니다. 또한 MobileNetV2Mid는 graph 모델로 로드해야 할 수 있다고 안내합니다.
T2Editor SafeAI 기준에서 MobileNetV2Mid가 기본값으로 적합한 이유는 다음과 같습니다.
- 기본 MobileNetV2보다 정확도 기대치가 높다.
- InceptionV3보다 운영 비용을 덜 공격적으로 가져갈 수 있다.
- 브라우저 추론형 에디터 플러그인에 넣기에 균형이 좋다.
즉, MobileNetV2Mid는 T2Editor SafeAI를 "최고 정확도 단독 지향"이 아니라 "브라우저에서 충분히 실용적인 균형형 판별기"로 두는 선택이라고 볼 수 있습니다.
속도 기대치: 왜 WebGPU 우선인가
NSFWJS 공식 README는 백엔드 선택 가이드에서 다음과 같이 설명합니다.
webgpu: 지원 브라우저/하드웨어에서 often fastestwebgl: 현대 브라우저에서 강한 기본 선택wasm: WebGL 사용이 어렵거나 제한된 환경에서 유용한 fallbackcpu: 호환성은 넓지만 일반적으로 더 느림
이 설명은 T2Editor 9.1.0의 구현 방향과 정확히 맞닿아 있습니다. 즉 SafeAI는 webgpu -> webgl -> wasm -> cpu 순으로 시도하는 것이 가장 현실적인 전략입니다.
공식 자료는 "WebGPU가 항상 fastest"라고 단정하지 않고 "often fastest"라고 설명합니다. 따라서 문서나 UI에서도 "WebGPU면 무조건 초고속" 같은 표현은 피하는 편이 맞습니다.
속도 기대치: 사용자 체감 기준
T2Editor SafeAI는 서버가 아니라 사용자 브라우저에서 분류합니다. 따라서 체감 성능은 다음 순서로 갈립니다.
| 환경 | 기대 체감 | 운영 해석 |
|---|---|---|
| 최신 데스크톱 + WebGPU 지원 브라우저 | 가장 좋음 | 다중 이미지 업로드 시에도 비교적 자연스러운 반응을 기대할 수 있습니다. |
| 최신 데스크톱 + WebGL | 좋음 | WebGPU보다 느릴 수 있으나 실사용엔 충분한 경우가 많습니다. |
| 중급 모바일 + WebGL | 보통 | 이미지 수가 많으면 검사 대기 시간이 늘 수 있습니다. |
| 제한 환경 + WASM | 보통~낮음 | 그래픽 가속이 어려운 환경에서 기능 유지용으로 유용합니다. |
| CPU only | 낮음 | 호환성 최후 보루입니다. 대량 업로드엔 불리합니다. |
여기서 중요한 것은, TensorFlow.js 공식 자료도 성능 측정을 로컬 벤치마크 도구로 직접 측정하라고 안내한다는 점입니다. 즉, SafeAI 운영팀이 실제 성능을 알고 싶다면 서버 스펙이 아니라 대표 사용자 기기군에서 직접 재야 합니다. TensorFlow.js 공식 저장소
초기 로딩과 캐싱 기대치
NSFWJS 공식 자료는 self-hosting 모델을 사용할 때 번들 크기를 줄일 수 있고, 브라우저에서는 모델 캐싱을 고려하라고 안내합니다. 또한 호스팅 모델을 직접 불러오면 패키지에 base64로 포함된 번들보다 초기 로딩 면에서 이점이 있을 수 있다고 설명합니다.
T2Editor 9.1.0에서 이를 반영해 기대할 수 있는 효과는 다음과 같습니다.
- 첫 사용 시: 모델 파일 다운로드 + 초기화 비용이 있습니다.
- 같은 세션/재방문 시: 브라우저 캐시 상태에 따라 재다운로드 비용이 줄어들 수 있습니다.
- 자체 호스팅 시: 외부 모델 호스팅 변경, 핫링크 차단, 응답 지연 리스크를 줄일 수 있습니다.
self-hosting이 성능에도 유리한가
대체로 그렇지만, 정확히는 "성능과 안정성에 모두 유리할 가능성이 높다"가 맞습니다.
공식 자료는 self-hosting이 다음과 같은 이유로 유리할 수 있다고 설명합니다.
- 번들 크기 절감
- raw binary 파일 직접 로드
- 초기 로드 시간 개선 가능성
- production 전환 시 권장
T2Editor 운영 관점에서는 여기에 다음 이점이 추가됩니다.
- 에디터 설치 경로(
/plugin/editor/t2editor/...)와 일관된 자산 관리 - 방화벽/망분리 환경 대응
- 외부 CDN 의존도 감소
- 배포 시 캐시 정책을 직접 통제 가능
모델 교체 시 기대 성능 변화
기본 MobileNetV2Mid 외 모델을 쓸 수는 있지만, 기대 성능은 달라집니다.
| 모델 | 기대 정확도 | 기대 속도 | 운영 적합성 |
|---|---|---|---|
| MobileNetV2 | 중 | 상 | 저사양/빠른 반응 우선 환경 |
| MobileNetV2Mid | 중상 | 중상 | 기본값으로 가장 균형적 |
| InceptionV3 | 상 방향 기대 | 중~하 | 더 높은 비용을 감수할 수 있는 환경 |
이 표는 공식 문서 수치 + 일반적인 TFJS 모델 특성을 합친 해석표입니다. 공식 자료는 InceptionV3의 입력 크기가 299라고 안내하고, MobileNetV2Mid는 graph 모델 주의사항을 명시합니다. 입력 해상도와 모델 구조가 커질수록 일반적으로 추론 비용도 늘어날 가능성이 큽니다.
이 문서의 모델별 속도 비교는 방향성 분석입니다. NSFWJS 공식 README는 모델별 FPS 수치를 보장하지 않습니다.
T2Editor SafeAI의 현실적인 역할
T2Editor에서 이 기능의 가장 적절한 역할은 다음입니다.
- 업로드 시 즉시 경고를 보여주는 프론트 보조 장치
- 커뮤니티 운영에서 1차 사용자 억제 장치
- 서버 전송 전 사전 걸러내기
반대로 이 역할로 과대 해석하면 안 됩니다.
- 법적 확정 판정기
- 완전 자동 삭제 엔진
- 사람 검토가 필요 없는 정책 집행기
공식 README 자체가 "완벽하지 않다"고 전제하는 만큼, T2Editor SafeAI도 정책 집행 보조 도구로 설명하는 것이 맞습니다.
운영 권장안
초보자 / 웹마스터
- 기본값은
MobileNetV2Mid유지 - self-hosted 자산 사용
webgpu -> webgl -> wasm -> cpu폴백 유지- 의심 이미지(
suspect)는 자동 허용보다 경고 후 선택 정책 권장
개발자
- 대량 업로드 시 동시 추론 수를 무리하게 높이지 않기
- 첫 모델 로딩과 재방문 캐시를 분리해서 측정하기
- 대표 기기군별로 체감 시간 기록하기
- 서버 필터가 별도로 있다면, SafeAI는 프론트 1차 판별기로만 두기
AI agent / 문서 작성자
- "정확도 93%"를 절대 성능처럼 쓰지 말고, 공식 자료 기준 midsized model 기대치라고 써야 합니다.
- "WebGPU가 가장 빠르다" 대신 지원 브라우저/하드웨어에서 대체로 가장 빠른 경향이라고 표현해야 합니다.
이 보고서의 한계
이 문서는 공식 자료와 현재 코드 구조를 기반으로 한 해석 문서입니다. 다음은 직접 측정하지 않았습니다.
- 특정 스마트폰 기종별 FPS
- 특정 이미지 개수별 평균 업로드 대기 시간
- 한국형 운영 데이터셋 기준 오탐/미탐률
따라서 운영 보고서에 이 문서를 인용할 때는 "공식 자료 기반 기대 성능 분석"으로 분류하는 것이 적절합니다.
참고 자료
수정 요약
- NSFWJS 공식 자료를 바탕으로 T2Editor SafeAI의 기대 정확도와 성능 특성을 분석하는 보고 문서 추가
- 과장된 성능 보장 표현을 피하고 운영 적합성 관점으로 정리