Firebase 프로젝트 하나를 여러 앱이 같이 쓸 때 — 데이터 안전하게 나누는 법

Q: Firebase 프로젝트 하나를 여러 앱이 같이 쓸 때 — 데이터 안전하게 나누는 법

한 Firebase 프로젝트를 여러 앱이 쓸 때는 컬렉션 접두사로 영역을 나누고, 규칙 맨 아래에 기본 거부(match /{document=**} allow read,write: if false)를 깔아야 합니다. 그래야 규칙에 명시하지 않은 컬렉션이 자동으로 막혀 앱끼리 데이터가 새지 않습니다.

왜 프로젝트를 공유하나

Firebase는 프로젝트 단위로 비용·인증·저장소가 묶입니다. 앱이 여러 개면 프로젝트도 여러 개 만드는 게 원칙이지만, 초기 비용·관리를 아끼려고 한 프로젝트에 여러 서비스를 담는 경우가 많습니다. 이때 가장 큰 위험은 한 앱의 실수가 다른 앱 데이터까지 노출시키는 것입니다.

1. 컬렉션 접두사로 영역을 나눈다

앱마다 컬렉션 이름에 접두사를 붙여 섞이지 않게 합니다.

// 앱 A
appA_users, appA_orders
// 앱 B
appB_posts, appB_comments
// 공용(있다면)
shared_config

2. 기본 거부를 반드시 깐다

규칙 맨 아래에 “명시되지 않은 모든 것은 거부”를 둡니다. 이게 없으면 새로 만든 컬렉션이 무방비로 열립니다.

rules_version = '2';
service cloud.firestore {
  match /databases/{db}/documents {

    match /appA_users/{uid} {
      allow read, write: if request.auth.uid == uid;
    }
    // ... 앱별 규칙 ...

    // ★ 기본 거부 — 맨 아래
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

주의 — 기본 거부는 재귀 와일드카드라, 명시하지 않은 하위 컬렉션까지 전부 막습니다. 새 기능으로 하위 컬렉션(예: appA_orders/{id}/history)을 추가하면 규칙을 함께 갱신해야 합니다. 안 그러면 “권한 없음” 오류가 납니다.

3. 익명 로그인을 조심한다

여러 앱이 같은 프로젝트의 인증을 공유하면, 한 앱에서 만든 익명 계정이 다른 앱 규칙을 통과할 수 있습니다. request.auth != null만으로 허용하지 말고 본인 uid 대조를 항상 넣으세요.

언제 프로젝트를 분리해야 하나

서비스가 커지고 사용자·데이터가 늘면, 비용 분리·장애 격리·권한 관리를 위해 프로젝트를 나누는 게 좋습니다. 이관은 데이터 마이그레이션이 필요하니 트래픽이 적은 시간에 계획적으로 합니다.

자주 묻는 질문

한 프로젝트에 앱 몇 개까지 괜찮나요?

기술적 제한보다 관리·위험 관점의 문제입니다. 초기에는 접두사+기본거부로 나눠 쓰고, 매출·데이터가 커지면 분리를 검토하세요.

기본 거부를 넣으면 앱이 멈추지 않나요?

명시한 컬렉션은 정상 동작합니다. 다만 규칙에 없는 컬렉션은 막히니, 새 컬렉션 추가 시 규칙을 함께 갱신하세요.

점검을 맡기면 무엇을 받나요?

규칙·권한·익명 로그인·접두사 분리 상태를 점검해 위험도별 리포트와 수정안을 드립니다.

함께 읽기: Firebase 보안 규칙 체크리스트 · 무료 보안 체크리스트