Firebase 면접 질문 2026: Flutter 인증, Firestore, 보안 규칙

Flutter 직무의 Firebase 면접 질문은 다섯 가지 주제에 집중됩니다. 세 가지 인증 상태 스트림, Firestore 데이터 모델링, 보안 규칙, 오프라인 쓰기, 그리고 모든 읽기에 따라붙는 비용 모델입니다. 2026년에도 Firebase는 Flutter 앱의 기본 백엔드이며, 2026년 10월부터 FlutterFire 플러그인은 BoM 5.x(firebase_core 5.1.0, firebase_auth 7.0.1, cloud_firestore 7.1.0)로 배포됩니다. Android minSdk는 24로 올라갔고, 내부적으로는 Firebase Apple SDK 13을 사용합니다.

2026년 Firebase 면접에서 묻는 것

면접관이 API 세부 사항을 암기했는지 묻는 경우는 드뭅니다. 확인하는 것은 Firebase가 어디에서 규칙을 강제하는지, 각 작업에 어떤 비용이 드는지, 네트워크가 끊기면 무슨 일이 일어나는지를 지원자가 이해하고 있는지입니다. 아래 표는 반복해서 출제되는 주제와 좋은 답변에 들어가야 할 내용을 정리한 것입니다. 각 주제는 뒤쪽의 Flutter 개발자를 위한 Firebase 면접 질문 섹션에서 자세히 답합니다.

Firebase 프로젝트 초기 설정

Flutter 프로젝트에서 Firebase를 사용하기 위한 첫 단계는 올바른 초기화입니다. FlutterFire CLI를 사용하면 iOS, Android, 웹 등 각 플랫폼에 맞는 설정 파일을 자동으로 생성할 수 있습니다. 생성된 firebase_options.dart 파일에는 각 플랫폼별 Firebase 구성 정보가 포함되어 있어 수동 설정의 번거로움을 크게 줄여줍니다.

import 'package:firebase_core/firebase_core.dart';
import 'package:flutter/material.dart';
import 'firebase_options.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // Initialize Firebase with platform-specific config
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(const MyApp());
}

WidgetsFlutterBinding.ensureInitialized() 호출은 Flutter 엔진이 네이티브 플랫폼과 통신할 준비가 되었음을 보장합니다. Firebase 초기화는 비동기 작업이므로 main() 함수를 async로 선언하고 await 키워드를 사용해야 합니다. 이 패턴은 모든 Firebase 의존성이 완전히 로드된 후에 앱이 시작되도록 보장합니다.

Firebase Authentication 구현

Firebase Authentication은 이메일/비밀번호, OAuth 제공업체(Google, Apple, GitHub), 전화번호 SMS 인증, 다중 인증(MFA)을 지원합니다. TOTP 기반 다중 인증은 firebase_auth 6.1.0부터 macOS에서도 사용할 수 있습니다.

이메일/비밀번호 인증

이메일과 비밀번호를 사용한 인증은 가장 기본적이면서도 널리 사용되는 방식입니다. AuthService 클래스를 만들어 인증 관련 로직을 캡슐화하면 코드의 재사용성과 테스트 용이성이 높아집니다.

import 'package:firebase_auth/firebase_auth.dart';

class AuthService {
  final FirebaseAuth _auth = FirebaseAuth.instance;

  // Register with email and password
  Future<User?> register(String email, String password) async {
    try {
      final credential = await _auth.createUserWithEmailAndPassword(
        email: email,
        password: password,
      );
      return credential.user;
    } on FirebaseAuthException catch (e) {
      // Handle specific error codes
      switch (e.code) {
        case 'email-already-in-use':
          throw Exception('This email is already registered');
        case 'weak-password':
          throw Exception('Password must be at least 6 characters');
        default:
          throw Exception('Registration failed: ${e.message}');
      }
    }
  }

  // Sign in with existing credentials
  Future<User?> signIn(String email, String password) async {
    final credential = await _auth.signInWithEmailAndPassword(
      email: email,
      password: password,
    );
    return credential.user;
  }

  // Reactive auth state stream
  Stream<User?> get authStateChanges => _auth.authStateChanges();
}

authStateChanges() 스트림은 사용자의 인증 상태 변화를 실시간으로 감지할 수 있게 해줍니다. 이 스트림을 StreamBuilder나 상태 관리 솔루션과 함께 사용하면 로그인/로그아웃 상태에 따라 UI를 자동으로 업데이트할 수 있습니다.

비밀번호 규칙을 더 이상 클라이언트에만 둘 필요가 없습니다. validatePassword API(firebase_auth 6.0.0부터 제공)는 Firebase 콘솔에서 설정한 정책에 따라 비밀번호를 검사하며, 이 정책으로 최소 길이, 대문자, 소문자, 숫자, 특수 문자를 필수로 지정할 수 있습니다.

Google 소셜 로그인

OAuth 제공업체를 쓰려면 별도 패키지가 필요합니다. google_sign_in 7.0부터 플러그인은 GoogleSignIn.instance로 얻는 싱글턴이 되었고, 초기화는 정확히 한 번만 해야 하며, 인증(authentication)과 권한 부여(authorization)가 분리되었습니다. 오래된 튜토리얼에 나오는 GoogleSignIn().signIn() 호출은 더 이상 컴파일되지 않습니다.

import 'package:firebase_auth/firebase_auth.dart';
import 'package:google_sign_in/google_sign_in.dart';

// Call once at startup, before any other GoogleSignIn method
Future<void> initGoogleSignIn() => GoogleSignIn.instance.initialize();

Future<UserCredential> signInWithGoogle() async {
  try {
    // Shows the native account picker; throws if the user cancels
    final googleUser = await GoogleSignIn.instance.authenticate();

    // Synchronous getter since v7: only the ID token is exposed here
    final googleAuth = googleUser.authentication;

    // Firebase only needs the ID token to create the credential
    final credential = GoogleAuthProvider.credential(
      idToken: googleAuth.idToken,
    );
    return FirebaseAuth.instance.signInWithCredential(credential);
  } on GoogleSignInException catch (e) {
    if (e.code == GoogleSignInExceptionCode.canceled) {
      throw Exception('Sign-in cancelled');
    }
    rethrow;
  }
}

이 패턴은 모든 OAuth 제공업체에 동일하게 적용됩니다. 제공업체의 토큰을 받아 Firebase 자격 증명으로 감싼 다음 signInWithCredential을 호출합니다. 앱이 Google API(Drive, Calendar 등)도 호출해야 한다면, 액세스 토큰은 별도 단계인 authorizationClient.authorizeScopes에서 받습니다. 자세한 내용은 google_sign_in 마이그레이션 가이드에 나와 있습니다.

Firestore 데이터베이스 작업

Cloud Firestore는 Firebase의 NoSQL 클라우드 데이터베이스로, 실시간 동기화와 오프라인 지원을 기본으로 제공합니다. 문서(Document)와 컬렉션(Collection) 기반의 데이터 모델은 JSON과 유사한 구조로 직관적이며, 중첩된 데이터 구조를 효율적으로 처리할 수 있습니다.

CRUD 작업 구현

기본적인 CRUD(Create, Read, Update, Delete) 작업은 Firestore 서비스 클래스로 추상화하는 것이 좋습니다. 이렇게 하면 Firestore 관련 로직을 한 곳에서 관리할 수 있고, 나중에 다른 데이터베이스로 마이그레이션할 때도 변경 범위를 최소화할 수 있습니다.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskService {
  final _db = FirebaseFirestore.instance;
  final String _collection = 'tasks';

  // Create a new document with auto-generated ID
  Future<String> createTask(String userId, String title) async {
    final doc = await _db.collection(_collection).add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  // Read a single document by ID
  Future<Map<String, dynamic>?> getTask(String taskId) async {
    final snapshot = await _db.collection(_collection).doc(taskId).get();
    return snapshot.data();
  }

  // Update specific fields without overwriting the entire document
  Future<void> toggleComplete(String taskId, bool completed) async {
    await _db.collection(_collection).doc(taskId).update({
      'completed': completed,
      'updatedAt': FieldValue.serverTimestamp(),
    });
  }

  // Delete a document
  Future<void> deleteTask(String taskId) async {
    await _db.collection(_collection).doc(taskId).delete();
  }
}

FieldValue.serverTimestamp()를 사용하면 클라이언트의 시간 대신 서버 시간을 기록할 수 있습니다. 이는 서로 다른 시간대의 클라이언트들이 일관된 타임스탬프를 사용하도록 보장하며, 시간 기반 정렬이나 필터링에서 정확성을 높여줍니다. cloud_firestore 7.1.0부터는 서버 측 변환에 FieldValue.minimum과 FieldValue.maximum이 추가되었습니다. 읽기 없이 저장된 값과 새로 들어온 값 중 작은 값 또는 큰 값을 유지하므로, 최고 점수 같은 카운터에 적합합니다.

실시간 데이터 스트림

Firestore의 핵심 장점 중 하나는 실시간 리스너입니다. snapshots() 메서드를 사용하면 데이터 변경 시 자동으로 UI가 업데이트되는 반응형 앱을 구현할 수 있습니다.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskStream {
  final _db = FirebaseFirestore.instance;

  // Stream all tasks for a specific user, ordered by creation date
  Stream<List<Map<String, dynamic>>> userTasks(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((snapshot) => snapshot.docs.map((doc) {
              final data = doc.data();
              data['id'] = doc.id; // Include document ID
              return data;
            }).toList());
  }
}

복합 쿼리를 사용할 때는 Firestore 콘솔에서 복합 인덱스를 생성해야 할 수 있습니다. 개발 중에 필요한 인덱스가 없으면 에러 메시지에 인덱스 생성 링크가 포함되어 있어 쉽게 설정할 수 있습니다.

Firestore 보안 규칙

Firestore 보안 규칙은 데이터베이스 접근을 제어하는 핵심 메커니즘입니다. 클라이언트 측 코드는 언제든지 조작될 수 있으므로, 서버 측 보안 규칙으로 데이터 무결성을 보장해야 합니다.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own profile
    match /users/{userId} {
      allow read, update: if request.auth != null
                          && request.auth.uid == userId;
      allow create: if request.auth != null;
      allow delete: if false; // Prevent self-deletion
    }

    // Tasks belong to the user who created them
    match /tasks/{taskId} {
      allow read, write: if request.auth != null
                         && resource.data.userId == request.auth.uid;
      allow create: if request.auth != null
                    && request.resource.data.userId == request.auth.uid;
    }
  }
}

보안 규칙에서 request.auth는 현재 인증된 사용자의 정보를 담고 있으며, resource.data는 기존 문서의 데이터를, request.resource.data는 생성 또는 업데이트되는 새로운 데이터를 나타냅니다. 이러한 컨텍스트 변수들을 활용하여 세밀한 접근 제어를 구현할 수 있습니다.

오프라인 지원 및 캐싱

Firestore는 기본적으로 오프라인 지원을 제공합니다. 네트워크 연결이 끊어진 상태에서도 로컬 캐시에서 데이터를 읽고 쓸 수 있으며, 연결이 복원되면 자동으로 서버와 동기화됩니다. 이 기능은 모바일 앱에서 특히 중요한데, 사용자가 지하철이나 엘리베이터 등 네트워크 상태가 불안정한 환경에서도 앱을 원활하게 사용할 수 있기 때문입니다.

StreamBuilder<DocumentSnapshot>(
  stream: FirebaseFirestore.instance
      .collection('tasks')
      .doc(taskId)
      .snapshots(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return const CircularProgressIndicator();

    final data = snapshot.data!;
    final isPending = data.metadata.hasPendingWrites;

    return Row(
      children: [
        Text(data['title']),
        if (isPending) const Icon(Icons.cloud_upload, size: 16),
      ],
    );
  },
)

metadata.hasPendingWrites 속성을 확인하면 현재 데이터가 서버에 동기화되지 않은 로컬 변경사항인지 알 수 있습니다. 이를 활용하여 사용자에게 동기화 상태를 시각적으로 표시할 수 있습니다. 또한 metadata.isFromCache 속성으로 데이터가 캐시에서 왔는지 서버에서 왔는지 구분할 수도 있습니다.

프로덕션 아키텍처: Repository 패턴

대규모 애플리케이션에서는 데이터 소스를 추상화하는 Repository 패턴이 권장됩니다. 이 패턴은 비즈니스 로직과 데이터 접근 로직을 분리하여 코드의 테스트 용이성과 유지보수성을 높여줍니다.

abstract class TaskRepository {
  Future<String> create(String userId, String title);
  Stream<List<Task>> watchAll(String userId);
  Future<void> update(String id, Map<String, dynamic> fields);
  Future<void> delete(String id);
}

// firebase_task_repository.dart
class FirebaseTaskRepository implements TaskRepository {
  final _db = FirebaseFirestore.instance;

  @override
  Future<String> create(String userId, String title) async {
    final doc = await _db.collection('tasks').add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  @override
  Stream<List<Task>> watchAll(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((s) => s.docs.map(Task.fromFirestore).toList());
  }

  // ... update and delete implementations
}

추상 클래스로 인터페이스를 정의하면 테스트 시 Mock 객체를 쉽게 주입할 수 있습니다. 또한 Firebase 외의 다른 백엔드로 마이그레이션해야 할 경우에도 Repository 인터페이스를 구현하는 새로운 클래스만 작성하면 됩니다. Riverpod이나 BLoC 같은 상태 관리 솔루션은 Firestore를 알지 못한 채 이 Repository 인터페이스만 사용합니다.

FlutterFire 5로 업그레이드할 때 깨지는 것

2026년 10월 메이저 릴리스(BoM 5.0.0, firebase_auth 7.0.0, cloud_firestore 7.0.0, firebase_core 5.0.0)는 Dart API보다 빌드 요구 사항을 더 많이 바꿉니다. 빌드나 코드 리뷰에서 문제가 되는 지점은 다음과 같습니다.

• Android minSdk 24: 플러그인은 Firebase Android BoM 35를 기반으로 합니다. minSdk가 21이나 23인 프로젝트는 컴파일되지 않습니다.
• Apple SDK 13: Firebase Apple SDK는 Swift Package Manager 기준 13.0.0(CocoaPods 기준 12.19.0)으로 올라갔고, Swift 패키지는 macOS 11을 요구합니다.
• App Check: activate의 매개변수 이름이 providerWeb, providerAndroid, providerApple로 바뀌었습니다.
• 지원 중단: cloud_firestore 7.0.0에서 setIndexConfigurationFromJSON이 지원 중단되었고, firebase_ml_model_downloader는 더 이상 배포되지 않습니다.
• 6.x 계열에서 이미 제거됨: fetchSignInMethodsForEmail()과 User.updateEmail(). 로그인 전에 이메일이 어떤 제공업체를 쓰는지 확인하는 코드는 다시 설계해야 합니다. 이메일 열거 보호 기능이 그 정보를 숨기기 때문입니다.

패키지별 전체 변경 목록은 FlutterFire 릴리스 노트와 cloud_firestore 변경 기록에 있습니다.

Flutter 개발자를 위한 Firebase 면접 질문

면접에서는 Firebase 서비스에 대한 개념적 이해와 실제 구현 능력을 함께 평가합니다. 다음 질문들은 2026년 Flutter 개발자 면접에서 자주 나옵니다. 프레임워크 쪽 질문은 Flutter 면접 질문 가이드에서 다룹니다.

authStateChanges()는 idTokenChanges(), userChanges()와 어떻게 다릅니까?

authStateChanges()는 로그인과 로그아웃 이벤트에서만 발생합니다. idTokenChanges()는 여기에 더해 ID 토큰이 갱신될 때(약 1시간마다)도 발생합니다. userChanges()는 이 모든 이벤트에 updateDisplayName() 같은 프로필 변경까지 포착합니다. 대부분의 화면 이동 가드에는 authStateChanges()로 충분합니다.

기기가 오프라인일 때 Firestore 쓰기를 하면 어떻게 됩니까?

쓰기는 로컬 캐시와 대기 중인 쓰기 큐에 저장됩니다. snapshots() 리스너는 metadata.hasPendingWrites == true 상태로 변경된 데이터를 즉시 받습니다. 연결이 복구되면 Firestore가 대기 중인 쓰기를 자동으로 동기화하며, 서버에 마지막으로 도달한 쓰기가 최종 값이 됩니다.

채팅 애플리케이션의 데이터는 Firestore에서 어떻게 모델링해야 합니까?

각 문서에 메타데이터(참여자, 마지막 메시지 타임스탬프)를 담는 chats 컬렉션을 두고, 각 채팅 문서 아래에 messages 하위 컬렉션을 둡니다. 이 구조로 사용자의 채팅 목록을 효율적으로 조회하면서 대화별로 메시지를 페이지네이션할 수 있습니다. 목록 화면에서 하위 컬렉션을 읽지 않도록 마지막 메시지는 상위 문서에 비정규화해 둡니다.

DateTime.now() 대신 FieldValue.serverTimestamp()를 써야 하는 이유는 무엇입니까?

DateTime.now()는 기기 시계를 사용하므로 부정확하거나 조작되었을 수 있습니다. FieldValue.serverTimestamp()는 Firestore 서버 시계를 사용해 모든 클라이언트에서 일관된 순서를 보장합니다. 메시지 정렬, 활동 피드, 감사 로그 같은 기능에서 중요합니다.

Firestore에서 복합 쿼리는 어떻게 처리되며, 인덱스 요구 사항은 무엇입니까?

where와 orderBy로 여러 필드를 조합하는 쿼리에는 복합 인덱스가 필요합니다. 단일 필드 인덱스는 자동으로 생성되지만, 복합 인덱스는 firestore.indexes.json 또는 Firebase 콘솔에서 직접 정의해야 합니다. 쿼리가 실패하면 Firestore는 누락된 인덱스를 만드는 링크를 로그에 남깁니다.

배치 쓰기 대신 트랜잭션을 써야 하는 경우는 언제입니까?

같은 작업 안에서 읽은 데이터에 쓰기가 의존할 때 트랜잭션이 필요합니다. 예를 들어 재고가 0보다 클 때만 재고를 줄이는 경우입니다. 읽은 문서가 커밋 전에 바뀌면 SDK가 콜백을 재시도하므로, 콜백에는 부수 효과가 없어야 합니다. 배치 쓰기는 읽기 없이 여러 쓰기를 원자적으로 수행합니다. 문서를 생성하면서 다른 곳의 카운터를 갱신하는 경우가 그 예입니다. 오프라인 동작도 다릅니다. 배치는 큐에 쌓이지만, 트랜잭션은 연결이 없으면 실패합니다.

final db = FirebaseFirestore.instance;

// Transaction: read then write, retried on contention
await db.runTransaction((tx) async {
  final ref = db.collection('products').doc(id);
  final snap = await tx.get(ref);
  final stock = snap.get('stock') as int;
  if (stock <= 0) throw Exception('Out of stock');
  tx.update(ref, {'stock': stock - 1});
});

// Batched write: atomic writes, no reads
final batch = db.batch();
batch.set(db.collection('orders').doc(), {'productId': id});
batch.update(db.collection('stats').doc('orders'), {
  'count': FieldValue.increment(1),
});
await batch.commit();

Firebase에서 관리자 역할은 어떻게 구현합니까?

Admin SDK를 통해 신뢰할 수 있는 환경에서 커스텀 클레임을 설정하며, Flutter 클라이언트에서 설정하지 않습니다. 클레임은 ID 토큰 안에 담기므로 규칙은 별도의 문서 조회 없이 request.auth.token.admin == true로 읽을 수 있습니다. 커스텀 클레임 문서에 따르면 페이로드 상한은 1000바이트이고, 클라이언트는 토큰이 갱신된 뒤에야 새 클레임을 보게 됩니다. 갱신은 currentUser.getIdToken(true)로 강제할 수 있습니다.

보안 규칙과 App Check의 차이는 무엇입니까?

보안 규칙은 특정 사용자가 특정 문서를 읽거나 쓸 수 있는지를 결정합니다. App Check는 요청이 정상 기기의 정상 앱에서 왔음을 증명하여, 공개 API 키를 재사용하는 스크립트를 차단합니다. 서로 다른 질문에 답하므로 프로덕션 앱에는 둘 다 필요합니다. FlutterFire 5부터 App Check는 providerAndroid, providerApple, providerWeb으로 활성화합니다.

Firestore 화면이 비싸지는 이유는 무엇이며, 페이지네이션은 어떻게 합니까?

Firestore는 문서 읽기, 쓰기, 삭제 단위로 과금합니다. 범위 제한이 없는 컬렉션에 리스너를 걸면 첫 로드에서 조건에 맞는 모든 문서를 읽고, 이후에는 변경된 문서마다 읽기 1회가 발생합니다. 페이지네이션은 오프셋이 아닌 쿼리 커서를 사용합니다. 첫 페이지는 limit(20), 다음 페이지는 startAfterDocument(lastDoc)로 가져오면 각 페이지는 반환된 문서만큼만 비용이 듭니다.

Firestore와 Realtime Database 중 무엇을, 왜 선택합니까?

Firestore는 문서를 컬렉션에 저장하고, 인덱스 기반 복합 쿼리를 지원하며, 작업 단위로 과금합니다. Realtime Database는 하나의 JSON 트리에 데이터를 저장하고, 하나의 자식 키에 대한 얕은 쿼리만 제공하며, 주로 대역폭과 저장 용량으로 과금합니다. 그래서 접속 상태 표시처럼 작고 매우 잦은 업데이트에 적합합니다. 대부분의 신규 Flutter 앱은 Firestore로 시작하고, 접속 상태 표시에만 Realtime Database를 추가합니다.

더 많은 Flutter 면접 준비를 위해, 전용 연습 모듈에서 이 주제들을 인터랙티브 퀴즈와 시간 제한 과제로 다룹니다.

참고 자료

• Firebase release notes for Flutter: BoM 5.0.0과 5.1.0의 내용, minSdk 24, App Check 매개변수 이름 변경
• cloud_firestore changelog: 6.3.0의 Pipelines, 7.1.0의 FieldValue.minimum/maximum과 findNearest 거리
• firebase_auth changelog: 6.0.0의 validatePassword, 6.1.0의 macOS TOTP, fetchSignInMethodsForEmail 제거
• google_sign_in migration guide: 7.0의 싱글턴, initialize, authenticate, 권한 부여 분리
• Firebase custom claims: 1000바이트 상한과 토큰 갱신

면접을 위한 Flutter Firebase 핵심 정리

• FlutterFire BoM 5.1.0은 firebase_auth 7.0.1과 cloud_firestore 7.1.0을 포함하며 Android minSdk 24를 요구합니다
• google_sign_in 7은 GoogleSignIn().signIn()을 GoogleSignIn.instance.initialize()와 authenticate()로 대체했으며, Firebase에는 idToken만 있으면 됩니다
• authStateChanges()는 반응형 스트림을 제공하여 수동 확인 없이 앱 전체의 로그인 상태를 관리합니다
• snapshots()를 통한 실시간 동기화는 폴링을 없애고 StreamBuilder와 바로 연결되어 UI를 자동으로 갱신합니다
• 프로덕션에서는 보안 규칙이 필수입니다. request.auth.uid를 문서의 소유자 필드와 항상 대조하고, 역할에는 커스텀 클레임을 사용합니다
• 트랜잭션은 재시도와 함께 읽은 뒤 쓰고, 배치 쓰기는 쓰기만 수행합니다. 문서 읽기가 모두 과금되므로 페이지네이션에는 커서를 사용합니다
• 모바일에서는 오프라인 지속성이 추가 코드 없이 동작합니다. 동기화 상태를 사용자에게 알리려면 hasPendingWrites를 사용합니다
• Repository 패턴은 Firebase를 비즈니스 로직과 분리하여 테스트와 향후 마이그레이션을 쉽게 만듭니다