처음으로 인공지능을 활용한 앱을 만들 때 모든 개발자가 마주하는 특정 순간이 있습니다.
재미있는 부분은 아닙니다. 모델이 놀라운 일을 해서 천재처럼 느끼는 부분도 아닙니다. 다른 순간입니다. 1시에 눈을 뜨고 고객 코드를 바라보며, 당신의 Gemini API 키가 평문으로 그곳에 놓여 있고, 브라우저와 십분이면 누구나 열고 읽을 수 있는 JavaScript 파일에 포함될 준비가 되어 있다는 것을 깨닫는 순간입니다.
Sambhav을 만들면서 그 순간이 내게 일어났다 — Sambhav은 실시간 음성 번역을 Whisper를 통해, 이력서 분석을, 그리고 Gemini를 통해 개인 맞춤 지도를 제공하는 AI 경력 플랫폼이다. 앱은 Next.js 15 프론트엔드가 Flask 백엔드와 통신하며, 그 아래에는 Supabase가 있었고, 모든 부분이 어느 시점에서든 LLM과 접촉해야 하는 많은 동적인 부분들이 있었다.
제가 가장 자랑스러웠던 기능: 실시간 모의 면접 모드로 사용자가 자연스럽게 말하고 답변을 기록 받으며, 제미니(Gemini)가 실시간으로 평가해주는 기능. 매끄러웠어요. 잘 작동했어요.
그 아래의 아키텍처는 문제를 야기할 잠재적 책임이었어요.
실제 문제
나가 빠져든 패턴은 이것이었다: 저지연 시간이 낮은 Gemini 호출은 클라이언트 측으로 향했다. 실시간 번역 피드백과 같은 경우, 서버 라운드 트립을 추가하면 경험을 지연되고 깨뜨린 것처럼 느껴졌다. 하지만 클라이언트에서 Gemini를 호출하는 것은 API 키가 클라이언트가 도달할 수 있는 곳에 있어야 했다.
개발자들이 일반적으로 이 문제를 해결하기 위해 시도하는 해결책들은 모두 다른 방식으로 나쁘다.
키를 환경 변수에 넣고 번들러가 노출하지 않기를 바랄 수 있습니다 — 그러나 그렇지 않은 경우가 있으며, 검증하기 어려운 방식으로 노출됩니다. 모든 것을 자신의 백엔드를 통해 프록시할 수 있습니다 — 이 방법은 작동하지만, 이제 두 서비스 간에 세션 상태를 유지해야 하고 Flask 서버는 요청을 전달하는 것 외에는 아무것도 하지 않으며 지연 시간이 발생합니다. 짧은 유효 기간 토큰을 사용할 수 있습니다 — 하지만 그렇게 하면 토큰 생성 및 갱신 시스템을 구축해야 하는데, 이것 자체가 하나의 프로젝트가 됩니다.
더 깊은 문제는 이러한 것들이 할당량 문제를 해결하지 못한다는 점입니다. API 키를 숨겨도, 동기화된 사용자는 여전히 전송 중인 유효한 인증 토큰을 포획하고 재생할 수 있습니다. 키를 훔치기 위해서는 아니지만, 할당량을 다 쓸 뿐입니다. 개인 프로젝트나 해커톤 데모에는 지루한 경계 사례입니다. 실제 사용자가 있는 생산 환경에서는 실제 위협입니다.
프록시 접근 방식을 구현하게 된 이유는 가장 잘 방어할 수 있었기 때문이었지만, 면접 피드백 루프에 의미 있는 지연 시간을 추가하고 세션 관리를 훨씬 더 복잡하게 만들었습니다. Flask 백엔드는 동시에 Whisper 세션 상태, Gemini 맥락, 인증 레이어를 유지해야 했습니다. 문제가 발생했을 때 — 데모에서는 항상 문제가 발생합니다 — 어떤 레이어가 실패했는지 결코 명확하지 않았습니다.
Firebase AI 로직이 실제로 변경되는 것은 무엇인가
Firebase AI 로직은 새로운 것이 아니다 — 하지만 Google이 I/O에서 출시한 것은 6개월 전과 비교하여 실질적으로 다른 도구를 만들었다, 그리고 두 가지 특정 기능의 조합은 위에 언급된 문제를 정확히 해결한다.
첫 번째는 템플릿만 모드_. 이 아키텍처는 간단합니다: 당신의 Gemini 프롬프트 — 시스템 명령어, 모델 구성, 도구 정의 —는 Firebase의 서버에 있지 않습니다. 클라이언트 코드에 있습니다. 클라이언트는 템플릿 ID를 참조합니다. 그것이 전부입니다. 요청이 들어오면 Firebase는 서버 측 템플릿을 실행합니다. 누군가가 클라이언트 요청을 중간에서 가로채고 사용자 지정 시스템 프롬프트를 주입하려고 하면 프레임워크는 그것을 무시합니다. 클라이언트 코드에서 프롬프트 조작으로 가는 경로가 없습니다.
Sambhav의 인터뷰 모드와 같은 경우에는 이것이 평가 기준 — Gemini가 후보자의 답변을 평가하는 방법을 정의하는 프롬프트 —가 frontend에 포함되지 않고, 그것이 속해야 할 서버에 남아있을 것을 의미했을 것입니다. 클라이언트는 대본을 전송하고 구조화된 응답을 받아옵니다.
두 번째는 App Check 재생 보호와 단회 토큰입니다.는 이 달부터 Firebase AI Logic의 App Check 토큰이 단독 사용됩니다. 한 번 사용된 토큰은 사라집니다. 공격자가 유효한 토큰을 전송 중에 포획하더라도 재생하여 추가 Gemini 호출을 할 수 없습니다. 이전에 설명한 쿼타 드레인 공격 — 잘 숨겨진 API 키조차 기술적으로 가능한 공격 —은 이제 인프라 수준에서 해결되었습니다.
지연 시간의 트레이드오프는 현실적이며 인정할 가치가 있습니다: 요청마다 새로운 토큰을 생성하면 네트워크 둘러싸는 과정이 추가됩니다. 몇 초마다 제미니 호출을 하는 실시간 번역 기능의 경우, 그 비용이 누적됩니다. 이는 지연 시간이 민감한 경로에서 활성화하기 전에 분석하는 것이 좋습니다.
하이브리드 추론 부분
제가 생각하기에 보도가 부족한 세 번째 공지사항이 있습니다. 이는 실제로 아키텍처 결정인데 성능 최적화처럼 들리기 때문입니다.
Firebase는 이제 iOS, Android(Gemma 4와 함께), — 곧 GA로 졸업할 — 웹의 Chrome을 포함한 하이브리드 추론을 지원합니다. 모델은 가능하다면 기기에서 로컬로 실행되고, 불가능할 때는 클라우드의 Gemini로 백업됩니다.
이것이 "더 빠르고 저렴한" 이상으로 중요한 이유는 회복탄력성 때문입니다. Sambhav는 해커톤 조건에 맞게 만들어졌는데, 이는 회의실 WiFi에서 작동하도록 의미했습니다. 회의실 WiFi는 적대적입니다. 면접 모드는 간혹 세션 중간에 Gemini 호출이 타임아웃되면서 중단되었고, 이는 누군가 제품을 보여주려는 순간에 정확히 경험을 끊었습니다.
하이브리드 추론은 파이프라인의 가벼운 부분 — 번역 정리, 기본 응답 형식 지정, 간단한 분류 — 가 네트워크 상태와 관계없이 로컬에서 실행될 수 있음을 의미합니다. 더 무거운 추론은 여전히 클라우드로 갑니다. 네트워크가 없을 때 앱도 살아 있습니다.
이를 구현하는 모든 사람에게 실질적인 질문은: 디바이스 내 Gemma 4 모델에서는 완전한 Gemini 품질을 얻지 못합니다. 기능 차이는 현실이며, 지역 경로가 깨진 경험보다는 부드럽게 저하된 경험을 생성하도록 기능을 설계해야 합니다. 이는 단순히 구성 문제가 아니라 설계 문제입니다.
이는 실질적으로 무엇을 의미합니다
Firebase AI Logic GA는 헤드라인 공지가 아닙니다. 유행하지 않을 것입니다. 하지만 클라이언트 애플리케이션에서 AI 기능을 출시하거나 출시하려고 했고 "API 키는 어디에 있고 제가 제한을 어떻게 보호해야 하는가"라는 벽에 부딪힌 모든 개발자에게 이것은 I/O에서 실제로 중요한 공지입니다.
템플릿 전용 모드, 앱 체크 리플레이 보호, 그리고 하이브리드 추론의 조합은 Sambhav을 위해 내가 막춰둔 보안과 회복성 아키텍처 — 프록시 서버, 세션 상태 관리, 수동 토큰 처리 — 이제 Firebase SDK의 최상위 기능이 되었습니다. 파이프라인을 구축할 필요가 없습니다. 설정만 하면 됩니다.
생산에 들어가면서 주의해야 할 점: 템플릿 전용 모드와 재생 보호는 문제의 다른 부분을 해결하고 다른 지연 프로파일을 가지고 있습니다. 기본적으로 모두를 켜지 마세요. 지연에 민감한 경로를 먼저 프로파일링하고, 둘러보는 비용이 어디에 드는지 이해한 후, 거래가 허용되는 곳에 대해 의식 있는 결정을 내리세요.
과거 백엔드 프로젝트가 필요했던 보안 아키텍처는 지금 세 가지 Firebase 설정 옵션에 존재합니다. 이는 실질적으로 출시할 수 있는 것에 대한 중요한 변화입니다.