Firebase 프로젝트를 여러 앱이 같이 쓸 때

왜 프로젝트를 공유하나

Firebase는 프로젝트 단위로 비용·인증·저장소가 묶입니다. 앱이 여러 개면 프로젝트도 여러 개 만드는 게 원칙이지만, 초기 비용·관리를 아끼려고 한 프로젝트에 여러 서비스를 담는 경우가 많습니다.

가장 큰 위험: 한 앱의 실수가 다른 앱 데이터까지 노출시키는 것입니다. 그래서 공유 프로젝트는 '나누는 규칙'이 특히 중요합니다.

안전하게 나누는 3원칙

공유 프로젝트 보안 3원칙

컬렉션 접두사로 영역 분리appA_users, appB_posts처럼 앱별 접두사로 섞이지 않게.

기본 거부를 맨 아래명시 안 된 모든 것은 거부. 새 컬렉션이 무방비로 열리는 것을 막음.

본인 uid 대조auth != null만으로 허용하지 말고 request.auth.uid == uid를 항상.

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 대조를 항상 넣으세요(보안 규칙 실수 TOP 5).

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

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

자주 묻는 질문

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

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

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

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

익명 로그인만 쓰면 위험한가요?

익명 로그인 자체보다, auth != null만으로 허용하는 규칙이 위험합니다. 공유 프로젝트에서는 한 앱의 익명 계정이 다른 앱 규칙을 통과할 수 있으니 본인 uid 대조를 반드시 넣으세요.

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

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

무료 점검부터 시작하세요

여러 앱이 한 Firebase 프로젝트를 쓰고 있다면, 규칙·접두사·익명 로그인 상태를 점검해 데이터가 새는 지점을 먼저 찾아 드립니다.

무료 점검 문의 → appmonster.co.kr

문의: appmonster.kr@gmail.com