Nemotron 3.5 공부 정리 | AI 앱 안전 필터, 어디까지 바꿀 수 있을까

Hugging Face 블로그에서 NVIDIA가 Nemotron 3.5 Content Safety를 발표했다는 글을 봤다. 처음엔 기업용 안전 모델 업데이트 정도겠거니 하고 가볍게 읽기 시작했는데, “커스텀 정책”이라는 개념에서 생각이 멈췄다.

콘텐츠 안전 필터라는 걸 지금까지 막연히 갖다 쓰는 라이브러리처럼 생각하고 있었다. 이 모델은 정책을 직접 입력하면 그에 맞춰 동작한다는 식인데, 그게 무슨 의미인지 좀 더 읽어봤다.

1️⃣ 이게 뭐냐?

Nemotron 3.5는 사용자 입력과 AI 응답을 동시에 보고 안전 여부를 판단하는 역할을 한다. 이전 버전(3.0)은 텍스트와 이미지를 따로 검사했는데, 3.5는 두 가지가 조합될 때 비로소 위험해지는 상황도 잡아낼 수 있게 됐다고 한다. 개별 요소는 문제없지만 함께 보면 위험한 경우가 있다는 점을 모델 레벨에서 처리하는 구조다.

기반은 Google의 Gemma 3 4B이고 LoRA로 파인튜닝됐다. 출력은 세 가지 모드로 나뉜다. 단순 이진 판정(safe/unsafe), 판정과 범주를 함께 내보내는 모드, 그리고 THINK 모드다. THINK 모드는 <think> 블록에 판단 근거를 담아 출력하는 방식이다. 감사 목적이나 정책 개선 시 어떤 근거로 판정이 내려졌는지 추적할 수 있다.

👉🏻 가장 흥미로웠던 건 커스텀 정책 기능이었다. 헬스케어 앱이라면 의학 용어가 특정 안전 범주에 걸리지 않아야 하고, 개발자 도구라면 “프로세스 종료” 같은 표현도 차단되면 곤란하다. 이 모델은 앱마다 다른 기준을 직접 넘겨줄 수 있게 설계됐다. 코드 수정이 아니라 정책 파일을 교체하는 방식이라는 점에서, 이전까지 내가 상상하던 안전 필터와 구조가 달랐다.

2️⃣ 내가 든 생각

디자이너 입장에서 안전 필터는 UX 문제이기도 하다. 잘못 걸러지는 게 많으면 유저 경험이 망가진다. 이 모델이 false positive를 줄이는 방향으로 개선됐다는 점은 기술 스펙이기도 하지만, 결국 사용자가 얼마나 막히지 않고 서비스를 쓸 수 있느냐의 이야기이기도 했다.

💡 여기서 드는 질문? 커스텀 정책을 “입력”한다는 게 결국 자연어로 넘기는 건데, 같은 의도를 다르게 표현하면 결과가 달라지지 않을까. 정책을 작성하는 사람의 표현 방식이 필터 품질에 영향을 준다면, 그건 모델 문제라기보다 운영 설계의 문제가 되는 것 같다.

THINK 모드는 별개로 흥미로웠다. AI가 판단 근거를 설명할 수 있다면, “왜 내 게시글이 차단됐나요?” 같은 상황에 대응하는 방식이 달라질 수 있을 것 같다. 지금 대부분의 모더레이션은 결과만 내보내는 구조인데, 근거가 붙으면 유저에게 보여주는 알림 문구나 이의 신청 흐름도 다르게 설계할 수 있지 않을까 싶었다. 디자인적으로 보면 새로운 인터페이스 가능성이 열리는 것 같았다.

3️⃣ 실제로 어디서 쓰이나?

문서에서 눈에 들어온 건 배포 방식이었다. Hugging Face에서 오픈소스로 공개되고, API 방식으로도 쓸 수 있다. 4B 규모라 로컬에서 돌릴 수도 있는 크기고, 응답 속도가 중요한 실시간 앱에서도 쓸 수 있다고 한다.

공부한 내용 기준으로는, 큰 기업 고객을 위한 도구이기도 하지만 구조 자체는 작은 앱에서도 참고할 만한 설계 방식인 것 같았다. “앱마다 다른 안전 기준을 모델 레벨에서 주입한다”는 개념이 꽤 일반화 가능한 패턴처럼 느껴졌다.

⭐️ 마지막으로, 이 모델을 공부하면서 계속 드는 질문

이런 도구를 볼 때마다 자꾸 같은 질문을 하게 되는 것 같다 — “안전의 기준을 누가 설계하는가”. Nemotron 3.5는 정책 입력으로 그 결정권을 앱 쪽에 넘겨줬는데, 그게 좋은 방향인지는 지금 단계에서는 잘 모르겠다. 다만, 선택의 여지가 생겼다는 것 자체가 이전과 달라진 점인 것 같긴 했다.

---

참고 원문: Nemotron 3.5 Content Safety: Customizable Multimodal Safety for Global Enterprise AI