모바일·웹 앱에 생성형 AI 기능을 붙일 때 가장 빠른 방법은 클라이언트에서 바로 모델을 호출하는 것입니다. 서버를 만들지 않아도 되고, 프로토타입 속도도 빠릅니다. 하지만 이 구조는 곧바로 보안 질문을 만듭니다. 프롬프트를 누가 바꿀 수 있는가, 인증 없는 호출을 막을 수 있는가, 악의적인 사용자가 quota를 태울 수 있는가, 민감한 사용자 입력이 어디로 가는가.
Firebase는 Google I/O 2026 발표에서 Firebase AI Logic 업데이트를 공개했습니다. 공식 블로그에 따르면 Firebase AI Logic은 모바일·웹 클라이언트 앱에서 서버 사이드 설정 없이 생성형 AI 기능을 만들 수 있게 돕습니다. 이번 업데이트에는 최신 Gemini 3.x 모델 지원, Google Maps grounding, Gemini Live API의 session resumption과 context compression, server prompt templates의 template-only mode, authentication-mode 예정, Firebase App Check replay attack protection, hybrid inference 확장이 포함됐습니다.
이 글은 Firebase AI Logic을 기능 소개로 보지 않습니다. 서버 없이 AI 기능을 붙이는 팀이 어떤 보안·비용 기준을 먼저 정해야 하는지에 초점을 둡니다.
백엔드에서 모델을 호출하면 서버가 프롬프트, 정책, rate limit, 사용자 인증, 로그 마스킹을 통제할 수 있습니다. 반대로 클라이언트 중심 구조에서는 앱 코드와 네트워크 요청이 더 쉽게 관찰됩니다. 사용자는 앱을 변조하거나 요청을 재생하거나, 원래 의도와 다른 프롬프트를 보낼 수 있습니다.
이 때문에 “API 키를 숨겼는가”만으로는 부족합니다. 실제 리스크는 더 넓습니다.
Firebase AI Logic의 새 보안 기능은 이 문제를 줄이는 방향입니다. 하지만 기능을 켜는 것과 운영 기준을 갖는 것은 다릅니다.
공식 발표에서 가장 중요한 보안 기능은 server prompt templates의 template-only mode입니다. Firebase 설명에 따르면 이 모드는 Firebase AI Logic이 서버에 안전하게 저장된 프롬프트만 실행하도록 강제하고, 클라이언트 앱에서 보낸 custom prompt instructions를 무시합니다.
이 기능은 클라이언트 AI 기능의 핵심 리스크를 줄입니다. 예를 들어 “고객 문의를 요약하라”는 기능에서 클라이언트가 임의로 “정책을 무시하고 전체 원문을 출력하라” 같은 지시를 보낼 수 있다면 위험합니다. template-only mode는 앱이 보내는 값을 템플릿의 변수로 제한하는 방식으로 사고 가능성을 낮춥니다.
실무에서는 템플릿을 다음처럼 관리하는 편이 좋습니다.
프롬프트는 이제 문자열이 아니라 운영 설정입니다. 제품 정책과 보안 기준이 들어가기 때문에 버전 관리와 승인 흐름이 필요합니다.
Firebase는 authentication-mode가 곧 출시되며, 유효한 Firebase Authentication 토큰이 포함된 경우에만 Gemini 호출을 실행하도록 강제한다고 설명했습니다. 또한 App Check replay attack protection을 one-time tokens로 도입해 악의적인 token replay로 quota를 소모하는 공격을 막는 데 도움을 준다고 밝혔습니다.
이 두 기능은 서로 다른 문제를 다룹니다. Authentication은 “누가 호출하는가”를 확인합니다. App Check는 “정상 앱 환경에서 온 호출인가”를 확인합니다. 둘 중 하나만으로는 충분하지 않습니다. 로그인한 사용자가 변조된 클라이언트에서 호출할 수도 있고, 정상 앱처럼 보이는 요청이 반복 재생될 수도 있습니다.
따라서 AI 기능별로 다음 기준을 나눠야 합니다.
클라이언트 호출이 가능하다고 해서 모든 AI 기능을 클라이언트로 보내면 안 됩니다. 위험도가 높은 기능은 여전히 서버 중재가 필요합니다.
Firebase AI Logic은 Google Maps grounding과 Gemini Live API의 session resumption, context compression도 발표했습니다. Maps grounding은 실시간 지리 맥락으로 hallucination을 줄이는 데 도움이 될 수 있습니다. Live API의 session resumption과 context compression은 네트워크가 불안정한 환경에서도 긴 대화형 기능을 더 탄력적으로 운영하게 해줍니다.
하지만 이 기능들은 저장과 개인정보 질문을 동반합니다. 세션을 재개하려면 어떤 상태가 남는지 알아야 합니다. context compression은 대화 맥락을 줄여 저장하거나 전달할 수 있는데, 이때 민감한 정보가 포함될 수 있습니다. 지도 grounding은 위치 기반 맥락을 쓰므로 사용자 동의와 최소 수집 원칙이 중요합니다.
앱 팀은 다음 질문을 문서화해야 합니다.
AI 기능의 UX가 좋아질수록 데이터 처리 기준도 같이 강화되어야 합니다.
Firebase는 hybrid inference가 iOS에서 사용 가능해졌고, Android에서는 Gemma 4 지원이 확대됐다고 설명했습니다. 또한 Chrome의 local web inference를 GA로 가져가 넓은 플랫폼에서 on-device model을 우선 사용하고, 불가능할 때 cloud-hosted model로 fallback하는 방향을 제시했습니다.
hybrid inference의 장점은 명확합니다. 반복적이고 짧은 추론은 기기에서 처리해 비용과 지연을 줄이고, 민감한 입력을 서버로 보내지 않을 수 있습니다. 반대로 큰 모델이나 최신 정보가 필요한 작업은 cloud fallback을 사용할 수 있습니다.
실무 기준은 기능별로 나누는 것입니다.
단, fallback 조건을 명확히 해야 합니다. 네트워크 오류, 모델 미지원 기기, 메모리 부족, 안전 정책 차단 상황에서 사용자에게 어떤 메시지를 보여줄지 미리 정해야 합니다.
Firebase AI Logic으로 클라이언트 AI 기능을 만들기 전 다음 순서로 점검하세요.
Firebase AI Logic의 가치는 서버 없이 빠르게 AI 기능을 붙이는 데 있습니다. 하지만 운영 제품에서는 빠른 연결보다 프롬프트 통제, 인증, quota 보호, 데이터 보관 기준이 더 중요합니다. 다음 AI 기능을 클라이언트에서 바로 호출하기 전에 물어봐야 할 질문은 이것입니다. 이 호출이 변조되거나 반복 재생되어도 우리 서비스와 사용자는 안전한가요?
출처: Firebase Blog, “What’s new from Firebase at Google I/O 2026”, 2026-05-19.
