Firebase 프로젝트 연동 및 서비스 설정

[chanho0908]

이슈 번호

#15

리뷰/머지 희망 기한 (선택)

2025.12.31

작업내용

• 크래시틱스/애널리틱스/FCM Gradle 의존성만 간단하게 추가했슴니다 :)

결과물

리뷰어에게 추가로 요구하는 사항 (선택)

• 애널리틱스 설정을 core:util에 넣을까 고민하다 애널리틱스 설정 및 로깅 관련 코드는 모듈로 분리해서 관리하면
  깔끔할 것 같아서 모듈로 분리했는데 어떻게 생각해 ?

Summary by CodeRabbit

릴리스 노트

• 새로운 기능

  • Firebase Crashlytics를 통한 앱 충돌 보고 기능 추가
  • 분석 및 사용자 이벤트 추적 기능 추가

• 기타

  • Firebase 및 Google Services 플러그인 의존성 업데이트
  • 프로젝트 모듈 구조 확장

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Actionable comments posted: 4

📜 Review details

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0b8390f and da0f4ea.

📒 Files selected for processing (5)

• .gitignore
• app/build.gradle.kts
• build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt
• build.gradle.kts
• gradle/libs.versions.toml

🧰 Additional context used

📓 Path-based instructions (2)

**/*.gradle.kts

⚙️ CodeRabbit configuration file

**/*.gradle.kts: Gradle 빌드 파일 리뷰 가이드라인

1. Convention Plugin 활용

   • 중복 설정이 Convention Plugin으로 추출되었는가?
   • 모듈별로 적절한 Convention Plugin이 적용되었는가?

2. 의존성 관리

   • Version Catalog (libs.versions.toml) 사용
   • 불필요한 의존성 제거
   • 의존성 범위가 적절한가? (implementation/api/compileOnly)

3. 모듈 구조

   • 순환 의존성이 없는가?
   • 의존성 방향이 올바른가? (domain ← data, feature → domain)

Files:

• app/build.gradle.kts
• build.gradle.kts

build-logic/**

⚙️ CodeRabbit configuration file

build-logic/**: Convention Plugin 리뷰 가이드라인

1. 플러그인 설계

   • 각 Convention Plugin이 명확한 책임을 가지는가?
   • 중복 설정이 제거되었는가?
   • 버전 카탈로그(libs.versions.toml) 활용이 적절한가?

2. 빌드 성능

   • 불필요한 의존성이 포함되지 않았는가?
   • Configuration Cache 호환성
   • Build Cache 최적화

3. 유지보수성

   • 확장 함수가 가독성을 높이는가?
   • DSL이 직관적인가?

Files:

• build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt

🧬 Code graph analysis (2)

app/build.gradle.kts (1)

build-logic/convention/src/main/kotlin/com/twix/convention/extension/DependencyHandlerScopeExtension.kt (2)

• implementation (7-9)
• implementation (11-13)

build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt (1)

build-logic/convention/src/main/kotlin/com/twix/convention/extension/DependencyHandlerScopeExtension.kt (2)

• implementation (7-9)
• implementation (11-13)

🔇 Additional comments (4)

.gitignore (1)

56-56: Firebase 설정 파일 제외 처리 잘하셨습니다! 👍

google-services.json 파일을 버전 관리에서 제외하는 것은 Firebase 프로젝트의 필수 보안 관행입니다. 프로젝트별 민감한 설정 정보가 포함되어 있어 공개 저장소에 노출되면 안 되는 파일이죠.

build.gradle.kts (1)

10-11: 플러그인 선언 방식이 프로젝트 컨벤션을 잘 따르고 있습니다! 🎯

루트 build.gradle.kts에서 apply false로 플러그인을 선언하는 것은 멀티모듈 프로젝트의 표준 패턴이며, Version Catalog 활용도 적절합니다.

gradle/libs.versions.toml (2)

70-73: Firebase 라이브러리 정의가 깔끔하게 작성되었습니다! ✨

Firebase BOM을 활용한 라이브러리 정의가 올바르게 구성되어 있습니다:

• BOM으로 버전을 중앙 관리하고
• 개별 라이브러리는 버전 없이 선언하는 패턴

이는 Firebase 공식 문서에서 권장하는 방식이며, 버전 호환성 문제를 예방할 수 있습니다. 잘하셨습니다! 👏

---

178-179: 플러그인 정의가 Version Catalog 컨벤션을 잘 따르고 있습니다! 🎯

Google Services와 Firebase Crashlytics 플러그인을 Version Catalog에 적절하게 정의하셨습니다. 이를 통해 프로젝트 전체에서 일관된 버전 관리가 가능해집니다.

[coderabbitai]

Actionable comments posted: 3

♻️ Duplicate comments (1)

gradle/libs.versions.toml (1)

21-23: Firebase 버전 업데이트가 필요합니다 📦

이전 리뷰에서 이미 지적되었던 내용이지만, Firebase 관련 버전이 최신이 아닙니다:

• google-firebase-bom = "34.0.0" → 34.7.0으로 업데이트 권장 (2025년 12월 11일 출시)
• google-firebase-crashlytics = "3.0.2" → 3.0.6으로 업데이트 권장 (2025년 8월 7일 출시)
• google-services = "4.4.4" ✅ 최신 버전입니다!

최신 BOM 버전은 보안 패치와 안정성 개선을 포함하고 있으므로, 초기 설정 단계에서 최신 버전을 사용하는 것이 장기적으로 유리합니다.

참고: Firebase Android 릴리스 노트

🧹 Nitpick comments (2)

build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt (1)

13-13: 모든 Feature 모듈에 Analytics 의존성 추가 - 아키텍처 관점 검토 🏛️

FeatureConventionPlugin에 core:analytics를 추가하면, twix.feature 플러그인을 적용하는 모든 feature 모듈이 자동으로 analytics 의존성을 갖게 됩니다.

장점:

• 모든 화면에서 일관된 방식으로 사용자 행동 추적 가능
• 중복 의존성 선언 불필요
• 팀 전체가 analytics 사용을 잊지 않음

고려사항:

• 정말 모든 feature에서 analytics가 필요한가요?
• 향후 analytics가 불필요한 feature 모듈이 생길 가능성은 없을까요?
• 예: 내부 관리자 전용 feature, 테스트용 feature 등

대안적 접근:
만약 일부 feature만 analytics가 필요하다면, 별도의 Convention Plugin을 만드는 것도 고려해볼 수 있습니다:

// twix.feature (기본)
// twix.feature.analytics (analytics 포함)

다만, 현재 프로젝트에서 analytics가 보편적인 요구사항이라면 현재 구조가 더 간결하고 실용적일 수 있습니다!

결론: 현재 단계에서는 이대로 진행하시되, 향후 analytics가 불필요한 모듈이 생기면 구조를 재검토하는 것을 추천드립니다.

As per coding guidelines, Convention Plugin은 명확한 책임을 가져야 하며, 향후 확장성을 고려한 설계가 중요합니다.

core/analytics/build.gradle.kts (1)

10-13: Firebase BOM 사용은 정확합니다! 버전 관리가 깔끔하네요. 🎯

다만 현재 core:analytics 모듈이 아직 구현이 없는 상태인데, 이것이 오히려 좋은 기회입니다. 지금이 바로 올바른 아키텍처 기반을 다질 시점입니다.

현재 상황:

• api(libs.google.firebase.analytics) 선언으로 인해 Firebase Analytics가 모든 feature 모듈의 공개 API 일부가 됨
• Feature 모듈들은 convention plugin을 통해 자동으로 core:analytics 의존성을 가짐
• 아직 실제 분석 코드가 없는 상태

Clean Architecture 관점의 개선:
지금이 추상화 계층을 도입하기에 가장 좋은 타이밍입니다. 다음과 같이 진행해보세요:

// core/analytics/src/main/kotlin/com/twix/analytics/AnalyticsLogger.kt
interface AnalyticsLogger {
    fun logEvent(name: String, params: Map<String, Any>)
}

// core/analytics/src/main/kotlin/com/twix/analytics/FirebaseAnalyticsLogger.kt
class FirebaseAnalyticsLogger(
    private val firebaseAnalytics: FirebaseAnalytics
) : AnalyticsLogger { ... }

이렇게 하면:

1. Firebase 구현체를 implementation으로 숨길 수 있음
2. Feature 모듈들은 AnalyticsLogger 인터페이스만 의존
3. 향후 분석 도구 교체가 용이함

다음 단계:

1. implementation으로 변경
2. AnalyticsLogger 인터페이스 작성
3. Koin 모듈에서 구현체 주입 설정

지금 기초를 다져두면 나중에 리팩토링할 일이 줄어들 거예요. 👍

📜 Review details

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between eec7a53 and ba9da9b.

📒 Files selected for processing (10)

• .cursorrules
• .gitignore
• app/build.gradle.kts
• build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt
• build.gradle.kts
• core/analytics/build.gradle.kts
• core/analytics/src/main/AndroidManifest.xml
• core/analytics/src/main/kotlin/com/twix/analytics/di/.gitKeep
• gradle/libs.versions.toml
• settings.gradle.kts

🧰 Additional context used

📓 Path-based instructions (2)

**/*.gradle.kts

⚙️ CodeRabbit configuration file

**/*.gradle.kts: Gradle 빌드 파일 리뷰 가이드라인

1. Convention Plugin 활용

   • 중복 설정이 Convention Plugin으로 추출되었는가?
   • 모듈별로 적절한 Convention Plugin이 적용되었는가?

2. 의존성 관리

   • Version Catalog (libs.versions.toml) 사용
   • 불필요한 의존성 제거
   • 의존성 범위가 적절한가? (implementation/api/compileOnly)

3. 모듈 구조

   • 순환 의존성이 없는가?
   • 의존성 방향이 올바른가? (domain ← data, feature → domain)

Files:

• settings.gradle.kts
• build.gradle.kts
• app/build.gradle.kts
• core/analytics/build.gradle.kts

build-logic/**

⚙️ CodeRabbit configuration file

build-logic/**: Convention Plugin 리뷰 가이드라인

1. 플러그인 설계

   • 각 Convention Plugin이 명확한 책임을 가지는가?
   • 중복 설정이 제거되었는가?
   • 버전 카탈로그(libs.versions.toml) 활용이 적절한가?

2. 빌드 성능

   • 불필요한 의존성이 포함되지 않았는가?
   • Configuration Cache 호환성
   • Build Cache 최적화

3. 유지보수성

   • 확장 함수가 가독성을 높이는가?
   • DSL이 직관적인가?

Files:

• build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt

🧬 Code graph analysis (2)

build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt (1)

build-logic/convention/src/main/kotlin/com/twix/convention/extension/DependencyHandlerScopeExtension.kt (2)

• implementation (7-9)
• implementation (11-13)

app/build.gradle.kts (1)

build-logic/convention/src/main/kotlin/com/twix/convention/extension/DependencyHandlerScopeExtension.kt (2)

• implementation (7-9)
• implementation (11-13)

🔇 Additional comments (7)

.gitignore (1)

56-56: 보안 설정 완벽합니다! 🔒

google-services.json 파일을 .gitignore에 추가하신 것은 매우 올바른 결정입니다. 이 파일에는 Firebase 프로젝트의 API 키와 설정 정보가 포함되어 있어, 공개 저장소에 노출되면 보안 위험이 발생할 수 있습니다.

참고: 팀원들이 로컬에서 빌드할 수 있도록 README나 별도 문서에 google-services.json 파일을 어디서 받아야 하는지 안내를 추가하면 더욱 좋겠습니다!

core/analytics/src/main/AndroidManifest.xml (1)

1-4: 라이브러리 모듈의 미니멀 매니페스트 구성 👍

Analytics 모듈을 위한 최소한의 매니페스트 구성이 적절합니다. 라이브러리 모듈은 특별한 컴포넌트나 권한 선언이 필요하지 않은 경우 이렇게 간단하게 구성하는 것이 좋습니다.

Firebase Analytics는 기본적으로 매니페스트 병합(manifest merger)을 통해 필요한 권한과 서비스를 자동으로 추가하므로, 추가 설정 없이도 정상 동작합니다.

.cursorrules (1)

10-27: 아키텍처 가이드라인이 훌륭합니다! 📚

멀티 모듈 구조와 MVI 패턴에 대한 명확한 가이드라인을 문서화하신 것이 인상적입니다. 특히:

• 모듈 간 의존성 규칙 (Line 18: feature 모듈 간 직접 의존 금지)
• MVI 패턴의 핵심 원칙 (Line 22: 단방향 데이터 흐름, Line 23: 불변 State)
• 비즈니스 로직 분리 (Line 27: UseCase/Repository 활용)

이런 원칙들이 실제 이번 PR의 core:analytics 모듈 설계에도 잘 반영되어 있습니다. 공통 기능을 core 모듈로 추출하고, feature 모듈들이 이를 의존하는 구조가 가이드라인과 정확히 일치하네요! 🎯

gradle/libs.versions.toml (1)

70-73: Version Catalog를 활용한 깔끔한 의존성 관리 👏

Firebase 의존성을 BOM(Bill of Materials) 패턴으로 관리하는 것은 모범 사례입니다!

google-firebase-bom = { module = "...", version.ref = "..." }
google-firebase-crashlytics = { module = "..." }  // 버전은 BOM에서 관리

이렇게 구성하면:

• BOM이 호환되는 라이브러리 버전을 자동으로 관리
• 각 Firebase 라이브러리의 버전 충돌 방지
• 업데이트 시 BOM 버전만 변경하면 됨

코딩 가이드라인의 "Version Catalog 사용" 원칙을 정확히 따르고 계십니다! 🎯

settings.gradle.kts (1)

37-37: 멀티 모듈 구조 확장이 체계적입니다 🏗️

새로운 core:analytics 모듈을 settings에 추가하신 것이 기존 모듈 구조와 일관성 있게 잘 정리되어 있습니다:

:core:util
:core:ui
:core:navigation
:core:design-system
:core:network
:core:analytics  ← 새로 추가

Analytics를 core 모듈로 분리한 것은 .cursorrules Line 19의 "공통 기능은 적절한 core 모듈로 추출" 원칙에도 부합합니다. 이렇게 하면 여러 feature 모듈에서 일관된 방식으로 분석 기능을 사용할 수 있어 좋습니다!

app/build.gradle.kts (1)

4-5: 플러그인 선언이 일관되게 개선되었습니다 ✨

이전 리뷰에서 지적되었던 플러그인 선언 방식의 불일치가 해결되었습니다:

alias(libs.plugins.google.firebase.crashlytics)
alias(libs.plugins.google.services)  // ✅ alias 패턴으로 통일

Version Catalog의 alias를 일관되게 사용하여 가독성과 유지보수성이 향상되었습니다. 코딩 가이드라인의 "Version Catalog 사용" 원칙을 잘 따르고 계십니다!

build.gradle.kts (1)

10-11: 루트 레벨 플러그인 선언이 올바릅니다 🎯

Firebase 관련 플러그인을 루트 build.gradle.kts에서 apply false로 선언한 것은 멀티 모듈 프로젝트의 표준 패턴입니다:

alias(libs.plugins.google.services) apply false
alias(libs.plugins.google.firebase.crashlytics) apply false

이렇게 하면:

• 플러그인 버전을 중앙에서 관리
• 필요한 서브모듈(예: app)에서만 선택적으로 적용
• 버전 충돌 방지

실제로 app/build.gradle.kts에서 이 플러그인들을 alias로 적용하고 있어, 전체 구조가 일관성 있게 잘 설계되었습니다!