Apple Foundation Models 프레임워크와 Firebase를 사용한 iOS 콘텐츠 검열 레이어 구축

Robin Winters 작성 · 2026년 4월 2일 최초 게시 · 2026년 10월 2일 재게시

원본 LinkedIn 에디션 · 읽기 쉬운 HTML 에디션 · Robin의 포트폴리오

원문 표현, 이미지 및 캡션을 그대로 사용했습니다. 기술적 관찰과 의견은 원래 맥락을 유지합니다.

"마틴, 너 그거 삭제될 거고 다음 30일 동안 포스팅 금지당할 거야"

Apple 생태계에서 콘텐츠 검열 레이어(moderation layer)를 구축할 때, 개발자인 우리가 도달하고자 하는 광범위한 사용자들을 위해 즐겁고 안전한 경험을 만들 수 있도록 도와주는 많은 도구와 가이드라인이 있습니다.

저는 Swift와 SwiftUI로 iOS 네이티브 제품을 만듭니다. 그래서 시스템이 실제로 사용될 때 어떻게 작동하는지에 대해 매우 신경을 씁니다. 또한, 사용자들이 이상한 방식으로 건드리기 시작했을 때도 잘 유지되는지 여부에 대해서도 관심을 가집니다. 검열은 이 두 가지가 만나는 지점입니다. 잘못된 분류기(classifier)나 모호한 거부 배너는 제품 버그이지만, 사용자들은 둘 다 똑같은 것으로 경험합니다.

아래에서는 몇 가지 주의사항을 제외하고 기본적으로 필요한 곳 어디에 적용할 수 있는 새로운 콘텐츠 검열 레이어를 iOS용으로 구축하는 방법을 설명하겠습니다.

점점 더 정교한 디자인들을 가지고 이것저것 만져본 끝에, 각 측면이 매우 다른 역할을 수행하는 하이브리드 아키텍처(hybrid architecture)를 선택하게 되었습니다:

• Apple의 Foundation Models framework를 사용하면 빠르고 개인적인 온디바이스 텍스트 분류 및 재작성 제안을 얻을 수 있습니다.
• Auth, App Check, 감사 로그(audit logs), 검토 후크(review hooks)가 있는 서버 권한 결정 경로에는 Firebase callable functions를 사용합니다.
• 이미지와 비디오는 그 자체로 특별한 종류의 어려움이 있기 때문에, 미디어를 별도로 처리하기 위해 Cloud Storage 트리거(Cloud Storage triggers)를 사용합니다.

주의사항: Apple 모델의 주된 제약 사항은 해당 모델이 지원되는 지역의 Apple Intelligence가 탑재된 기기에서만 실행된다는 것입니다. 또한 Apple은 개발자들에게 이 기능을 기반으로 구축하기 전에 가용성을 확인하도록 명시적으로 안내하고 있습니다. 자체 지침에서도 생성형 기능이 사용 불가능할 때도 경험이 작동하는지 확인할 것을 권고합니다. 저는 사용자가 지원되지 않는 기기, 지역 또는 언어 설정 때문에 검열 기능이 사라지는 것을 원치 않지만, 이는 시간이 지나면서 더 현대적인 장치가 광범위하게 채택됨에 따라 해결될 것입니다.

참고 자료: WWDC25 Foundation Models, SystemLanguageModel 가용성, Generative AI HIG

흐름도(flowchart)를 좋아하는 분들을 위한 재미있는 다이어그램입니다:

재미는 상대적인 개념입니다.

클라이언트 측에서는 콘텐츠가 기기를 떠나기 전에 텍스트만으로 모더레이션 신호를 위해 Apple의 모델을 사용합니다. 이는 즉시 두 가지 장점을 제공합니다. 첫째, 빠릅니다. 둘째, 모든 초안을 백엔드에 전송하지 않고도 사용자에게 명백한 문제에 대해 경고할 수 있습니다.

Apple의 Foundation Models 프레임워크는 추출(extraction), 요약(summarization), 분류(classification)와 같은 작업을 위해 설계되었기 때문에 이 목적에 적합합니다. 제가 기기에서 원하는 바로 그 종류의 좁은 작업입니다.

소스: What’s New in Apple Intelligence

Swift 측면은 대략 다음과 같습니다:

import FoundationModels

@Generable
...

제가 마음에 드는 몇 가지 점이 있습니다. 응답이 구조화되어 있어서 모델의 복잡한 데이터(model soup)를 파싱할 필요가 없습니다. 이 기능은 기본적으로 비공개이며, 모델을 사용할 수 없을 때도 앱이 계속 작동합니다. 단순히 사전 검사(preflight hint)를 건너뛰고 콘텐츠를 서버로 전송할 뿐입니다.

Apple의 모델은 존재할 때 훌륭하지만, 저는 최상의 기기 환경에서만 작동하는 중재 시스템(moderation system)을 구축하고 있지는 않습니다. 사용자가 콘텐츠를 제출하면 Firebase가 역할을 이어받습니다. 저는 호출 가능 함수(callable function)를 사용하여 앱이 콘텐츠, 로컬 중재 신호(local moderation signal)가 존재할 경우 해당 신호, 그리고 사용자의 인증 컨텍스트(auth context)를 표준 경로를 통해 전송하도록 합니다. Firebase 문서에서는 여기서 유용한 세부 사항을 언급합니다: 호출 가능 함수는 사용 가능한 경우 Auth 및 App Check 토큰을 자동으로 포함하며, App Check 강제 적용은 서버 측에서 활성화할 수 있습니다.

소스: Callable functions, App Check for Cloud Functions

서버 측면은 이제 인프라처럼 보입니다. 멋지네요.

import { onCall, HttpsError } from "firebase-functions/v2/https";
import { getFirestore } from "firebase-admin/firestore";

...

여기서 일관성을 확보할 수 있습니다. 모델이 모든 것을 소유하는 대신, 모델 출력 주변에 검토 워크플로우를 계층화할 수 있습니다. 또한, 나중에 누군가 항소하거나 과도한 모더레이션(over-moderation)이 발생했을 때 결정을 내린 실제 이유를 기록할 수도 있습니다. 또한, 텍스트와 이미지는 다르게 실패합니다. Cloud Storage 트리거 함수는 에셋을 가져와 해시하고, 더 무거운 검사를 실행한 다음, 모든 대용량 업로드 시 클라이언트를 차단하지 않고 모더레이션 상태를 다시 쓸 수 있습니다. Firebase는 Storage 트리거 처리를 표준 사용 사례로 제시합니다.

참고: Cloud Functions 사용 사례

몇 가지 외부 예시:

Reddit은 좋은 예입니다. 시간이 지남에 따라 '성숙한' 모더레이션이 어떻게 보이는지 보여줍니다. 그들은 AutoModerator, Safety Filters, 그리고 모더레이션 큐(moderation queue)를 가지고 있습니다. 또한, 신고 시스템 남용에 대한 문서화된 흐름도 가지고 있습니다.

Meta의 예는 Oversight Board의 유방암 인식 사례입니다. 자동화된 노출(nudity) 강제가 합법적인 건강 콘텐츠를 포착했습니다. 만약 모더레이션 스택이 피부를 보고 오작동한다면, 제품은 도움을 주어야 할 사람들에게 처벌을 가하기 시작합니다.

따라서 빌드는 의미가 있는 곳에서 좁게 유지해야 합니다. 빠른 텍스트 사전 검사를 위한 장치 내(on device) Foundation Models, 최종 조치를 위한 Firebase Functions, 명백한 사항에 대한 하드 규칙, 복잡한 중간 단계를 위한 검토 큐입니다. 지원되지 않는 장치를 위한 폴백(Fallbacks), 그리고 사용자에게 무슨 일이 일어났는지 알 수 있도록 상태 기반 UI(state driven UI)가 필요합니다.

이해가 되셨기를 바랍니다! 물론 이것은 현재 실험적인 단계일 뿐이지만, Apple의 Foundation Model 프레임워크를 사용하여 어떤 것을 구축하든 어떻게 모더레이션(moderation)을 계층화할지 생각하는 좋은 방법이라고 생각합니다.

서로에게 훌륭하게 대해주세요,

🤘Robin