Lovable, 데이터 권한을 통합하는 실시간 서비스 구축

Lovable은 2026년 11월 9일에 보고했으며, Lovable Realtime을 전면 배포하면서 프런트엔드를 Firestore에서 이전했다. 이 맞춤형 서비스는 권한 부여를 한곳에 통합하며, 30일 측정 기간에 동시 구독 수가 최대 206만 건에 달했다.

이번 이전으로 접근 권한과 사용자에게 표시되는 필드에 관한 결정은 Lovable의 Go 백엔드에서 처리하게 됐다. AI 앱 제작 플랫폼을 운영하는 Lovable은 이 서비스를 통해 Firestore와 Spanner의 데이터를 결합하고, 기반 데이터나 사용자의 권한이 변경될 때 사용자 화면을 갱신할 수 있다.

권한과 실시간 데이터 통합

Lovable의 일부 기능은 이전에 브라우저 기반 Firestore를 사용했습니다 onSnapshot 의 업데이트 수신기를 사용했다. 브라우저는 문서 전체를 받았고, Firestore 규칙은 Go API의 권한 모델을 그대로 반영해야 했다. 또한 이 설계에서는 일상적인 문서 변경이 데이터 노출로 이어질 수 있었다. 누군가 필드를 추가하면 그로 인해 어떤 데이터가 사용자의 브라우저에 전달되는지 결정될 수 있었지만, 반드시 그 결과를 인지하는 것은 아니었다.

Firestore 규칙은 Firebase 데이터를 조회할 수 있지만 Spanner는 조회할 수 없다. 이로 인해 Lovable 작업 공간에 사용자와 그룹을 동기화하는 SCIM을 통해 대규모 엔터프라이즈 그룹의 권한을 업데이트하는 데 장애가 생겼다. Lovable은 비즈니스 및 엔터프라이즈 고객을 위해 Go API를 거치는 임시 프록시를 도입해 API의 권한 검사를 재사용했다. 하지만 이 방식은 클라이언트마다 필요한 데이터에 대해 별도의 상위 Firestore 수신기도 열었다. 그 결과 스트림이 중복되고, 일반 데이터베이스 요청과 공유하는 연결 풀의 용량도 소모됐다.

Lovable은 대체 서비스가 기존 데이터베이스 두 가지 모두와 연동되고, 접근 권한을 지속적으로 다시 평가하며, 권한이 취소된 사용자의 스트림을 세션 도중 종료할 수 있어야 했다. 또한 권한이 없는 필드는 데이터가 서버 밖으로 나가기 전에 차단하기를 원했다. Lovable은 검토한 전송, 동기화 및 데이터베이스 통합 방식으로는 상당한 통합 작업이나 데이터베이스 변경, 또는 Postgres로의 복제 없이는 이러한 조건을 모두 충족할 수 없다고 판단했다.

새로 구축한 Go 서비스는 GKE에서 실행되며 브라우저 탭마다 WebSocket 연결 하나를 열고, 여러 구독을 해당 연결 하나로 다중화한다. 변경 데이터 캡처 피드는 Firestore와 Spanner의 변경 사항을 브리지를 거쳐 서비스의 메시지 버스인 NATS로 전달한다. 조건에 맞는 구독은 뷰를 다시 계산하고 xxh3-128 해시를 비교해 결과가 달라진 경우에만 변경분을 전송한다. 단일 구독은 API의 권한 프레임워크를 적용하면서 두 데이터베이스 모두에서 데이터를 가져올 수 있다.

권한 부여를 또 하나의 반응형 데이터 소스로 취급하므로, 일반적인 문서 수정과 별개로 권한 변경만으로도 결과를 새로 계산할 수 있다. Lovable에 따르면 관련 문서가 업데이트될 때마다 다시 계산하는 대신 접근 권한 결정에 관여하는 필드가 변경된 경우에만 계산하도록 해 권한 재계산 횟수를 약 84% 줄였다. 이 서비스에는 7개 팀이 소유한 구독 유형이 약 40개 있으며, 타입이 지정된 인터페이스, 공유 서버 측 구독, 팀별 라우팅 알림을 제공한다.

섀도 트래픽으로 배포 검증

Lovable은 먼저 섀도 모드로 서비스를 실행했다. 프런트엔드는 새 경로 전체를 거치되 페이로드는 버리고, Firestore에서 가져온 데이터로 계속 화면을 렌더링했다. 실제 트래픽과 데이터 형태를 사용한 덕분에 배포 후 재연결 폭주, 잘못 분류된 오류, 실제 데이터에는 너무 작은 페이로드 한도를 발견할 수 있었다. 이후 기능 플래그를 사용해 며칠에 걸쳐 서비스 적용률을 사용자 1%에서 10%, 50%, 100%로 높였다. Lovable은 배포 과정에서 사용자에게 영향을 미치는 사고가 없었고, 모니터링 중인 지표에도 악화가 없었다고 밝혔다.

WebSocket 연결은 특정 인스턴스에 고정되고 몇 시간씩 유지될 수 있으므로, 팟을 추가하는 것만으로는 기존 부하가 옮겨가지 않는다. Lovable은 연결 수를 기준으로 부하를 분산하고, CPU 및 메모리 사용량과 함께 연결 수를 고려해 확장하며, 재연결이 한꺼번에 몰리는 현상을 줄이기 위해 팟당 연결 수에 상한을 둔다. 재연결 후 클라이언트는 캐시된 상태의 지문을 전송한다. 그러면 서버는 권한을 다시 확인한 뒤 데이터가 바뀌지 않았음을 확인할 수 있어 데이터를 다시 전송하지 않아도 된다.

게시물 작성자는 핵심 기능을 구현하는 데 실제 작업일 기준 40일이 걸렸으며, 아키텍처와 예외 사례를 충분히 검토한 뒤에는 구현 대부분을 코딩 에이전트가 처리했다고 밝혔다. 통합 테스트 환경에는 Firestore, Auth, Spanner 에뮬레이터와 임베디드 NATS 서버, 에뮬레이터에서 실제로 발급한 ID 토큰을 결합했다. 이를 통해 에이전트는 전체 스택에 걸친 변경 사항을 테스트할 수 있었다.

운영 성과와 앱 지원 가능성

Lovable은 2026년 9월 5일부터 10월 5일까지 재개된 제어 프레임을 제외하고 데이터 및 패치 프레임 26억 1,000만 건을 보고했다. 또한 계산된 모든 결과에 대해 전체 스냅샷을 생성했다면 애플리케이션 페이로드가 40TB에 달했을 것으로 추산했다. 중복 제거, 변경분 전송, 재연결 시 기존 데이터 재사용을 통해 실제 전송 페이로드는 1.11TB로 줄었으며, 이는 해당 기준치보다 97% 감소한 수치다. 페이로드 수치에는 프로토콜 및 전송 오버헤드가 포함되지 않는다.

Lovable은 소스 데이터베이스에 기록된 시점부터 전송할 프레임이 준비될 때까지의 시간을 측정한 결과, p50은 66밀리초, p99는 249밀리초였다고 밝혔다. 이 측정에는 소켓 쓰기, 네트워크 소요 시간, 클라이언트 처리가 포함되지 않으므로 사용자가 체감하는 전체 업데이트 시간은 나타내지 않는다.

Lovable은 데이터 스냅샷을 제공하는 대신 어떤 일이 발생했음을 데이터 이용자에게 알릴 필요가 있는 경우를 위해 도메인 이벤트 기본 요소를 적극적으로 추가하고 있으며, 이 서비스가 나중에는 Lovable로 구축한 앱에 포함되는 기능이 될 수도 있다고 밝혔습니다. 이러한 확장은 고객이 직접 만든 애플리케이션에 백엔드에서 제어하는 권한과 실시간 뷰를 제공하게 됩니다. 현재 배포된 서비스는 데이터 인프라가 발전함에 따라 Lovable 팀이 더욱 긴밀하게 협업할 수 있도록 이미 공통 기반을 제공하고 있습니다.