firebase 프로젝트 연동 #19
firebase 프로젝트 연동 #19
Conversation
Firebase 프로젝트를 연동하고 Crashlytics, Analytics, Cloud Messaging 서비스를 설정합니다. google-services.json 파일은 .gitignore에 추가하여 버전 관리에서 제외합니다. 🤖 Generated with [Firebender](https://firebender.com) Co-Authored-By: Firebender <help@firebender.com>
Firebase Analytics를 위한 core:analytics 모듈을 생성하고, 모든 Feature 모듈에서 자동으로 사용할 수 있도록 FeatureConventionPlugin에 통합했습니다. 🤖 Generated with [Firebender](https://firebender.com) Co-Authored-By: Firebender <help@firebender.com>
Firebase Analytics를 위한 core:analytics 모듈을 생성하고, 모든 Feature 모듈에서 자동으로 사용할 수 있도록 FeatureConventionPlugin에 통합했습니다. 🤖 Generated with [Firebender](https://firebender.com) Co-Authored-By: Firebender <help@firebender.com>
개발 환경별 설정 파일인 .cursorrules를 .gitignore에 추가하여 버전 관리에서 제외합니다. 🤖 Generated with [Firebender](https://firebender.com) Co-Authored-By: Firebender <help@firebender.com>
|
Note
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | PR 제목 'firebase 프로젝트 연동'은 변경사항의 핵심을 정확히 반영합니다. Firebase 통합(Crashlytics, Analytics, FCM)과 관련 의존성 추가, core:analytics 모듈 생성 등 전반적인 작업을 포괄적으로 설명합니다. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✨ Finishing touches
- 📝 Generate docstrings
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Post copyable unit tests in a comment
- Commit unit tests in branch
feat#15/firebase-프로젝트-연동
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
.gitignore (1)
55-87: 더 나아가기: Firebase 관련 추가 파일 검토 제안 📋Firebase를 본격적으로 도입하면서, 향후 추가로 고려할 만한 파일들이 있습니다:
google-services-debug.json: 디버그 빌드용 Firebase 설정 (있다면 무시 권장)firebase.json: Firebase 프로젝트 설정 파일 (존재 시 포함 검토)현재 설정은 완벽하지만, 프로젝트 진행 과정에서 이런 파일들이 생길 수 있으니 필요시 추가하시면 됩니다.
build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt (1)
12-18: 모든 Feature 모듈에 Analytics를 자동 포함하는 설계에 대한 고민이 필요합니다.현재 FeatureConventionPlugin에
core:analytics를 추가하면, 이 플러그인을 적용하는 모든 Feature 모듈이 자동으로 analytics 의존성을 갖게 됩니다.장점:
- 일관된 의존성 관리
- 보일러플레이트 감소
고려사항:
- 정말 모든 Feature가 Analytics를 필요로 할까요?
- 향후 추가될 Feature 중 Analytics가 불필요한 경우도 있을 수 있습니다
- 예: 순수 UI 컴포넌트 Feature, 인증이 필요 없는 공개 Feature 등
대안:
- 현재 방식 유지 (모든 Feature에 포함) - Feature 수가 적고 대부분 Analytics가 필요하다면 합리적
- 선택적 적용 - Analytics가 필요한 Feature만 개별적으로 의존성 추가
- 별도 Convention Plugin -
FeatureWithAnalyticsConventionPlugin같은 별도 플러그인 생성현재
feature:login만 있는 상황에서는 큰 문제가 없지만, 프로젝트가 성장하면서 Feature가 늘어날 때를 대비한 설계 방향에 대해 팀 논의가 필요해 보입니다.core/analytics/build.gradle.kts (1)
10-13:apivsimplementation스코프에 대한 설계 결정이 필요합니다.현재 Firebase Analytics를
api스코프로 선언하셨는데, 이는 이 모듈을 의존하는 모든 모듈(모든 Feature 모듈 포함)에서 Firebase Analytics API에 직접 접근 가능하다는 의미입니다.현재 방식 (
api사용):// Feature 모듈에서 직접 Firebase API 호출 가능 Firebase.analytics.logEvent("event_name", bundleOf(...))장점: Feature에서 직접 Firebase API 사용 가능, 간단한 사용법
단점: Firebase 구현이 프로젝트 전체에 노출, 향후 Analytics 라이브러리 교체 시 모든 Feature 수정 필요대안 (
implementation사용 + Wrapper):// core:analytics 모듈에서 제공 interface AnalyticsLogger { fun logEvent(name: String, params: Map<String, Any>) } // Feature에서 추상화된 인터페이스 사용 analyticsLogger.logEvent("button_clicked", mapOf("screen" to "login"))장점: 구현 세부사항 은닉, 라이브러리 교체 용이, 테스트 가능성 향상
단점: 초기 Wrapper 구현 필요추천 방향:
PR 목표가 "Analytics 설정 및 로깅 관련 코드를 별도 모듈로 분리"라고 하셨는데, 현재는 모듈만 분리하고 Firebase API가 그대로 노출되어 있습니다.완전한 모듈화를 위해서는:
implementation으로 변경- Analytics 추상화 인터페이스 제공
- Koin을 통한 의존성 주입
이렇게 하면 진정한 의미의 "분리"가 완성됩니다.
다만, 프로젝트 초기 단계이고 빠른 개발이 필요하다면 현재 방식(
api)도 실용적인 선택일 수 있습니다. 팀 내에서 논의가 필요해 보입니다!참고 자료:
- Gradle - API vs Implementation
- Clean Architecture의 Dependency Rule
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.gitignoreapp/build.gradle.ktsbuild-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.ktbuild.gradle.ktscore/analytics/build.gradle.ktscore/analytics/src/main/AndroidManifest.xmlcore/analytics/src/main/kotlin/com/twix/analytics/di/.gitKeepgradle/libs.versions.tomlsettings.gradle.kts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.gradle.kts
⚙️ CodeRabbit configuration file
**/*.gradle.kts: Gradle 빌드 파일 리뷰 가이드라인
Convention Plugin 활용
- 중복 설정이 Convention Plugin으로 추출되었는가?
- 모듈별로 적절한 Convention Plugin이 적용되었는가?
의존성 관리
- Version Catalog (libs.versions.toml) 사용
- 불필요한 의존성 제거
- 의존성 범위가 적절한가? (implementation/api/compileOnly)
모듈 구조
- 순환 의존성이 없는가?
- 의존성 방향이 올바른가? (domain ← data, feature → domain)
Files:
settings.gradle.ktsbuild.gradle.ktsapp/build.gradle.ktscore/analytics/build.gradle.kts
build-logic/**
⚙️ CodeRabbit configuration file
build-logic/**: Convention Plugin 리뷰 가이드라인
플러그인 설계
- 각 Convention Plugin이 명확한 책임을 가지는가?
- 중복 설정이 제거되었는가?
- 버전 카탈로그(libs.versions.toml) 활용이 적절한가?
빌드 성능
- 불필요한 의존성이 포함되지 않았는가?
- Configuration Cache 호환성
- Build Cache 최적화
유지보수성
- 확장 함수가 가독성을 높이는가?
- DSL이 직관적인가?
Files:
build-logic/convention/src/main/kotlin/com/twix/convention/FeatureConventionPlugin.kt
🧬 Code graph analysis (3)
app/build.gradle.kts (1)
build-logic/convention/src/main/kotlin/com/twix/convention/extension/DependencyHandlerScopeExtension.kt (2)
implementation(7-9)implementation(11-13)
core/analytics/build.gradle.kts (1)
build-logic/convention/src/main/kotlin/com/twix/convention/KoinConventionPlugin.kt (1)
dependencies(6-11)
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 (10)
.gitignore (2)
56-56: Firebase 보안 설정 완벽하게 활성화됨! 🔐
google-services.json의 주석 처리를 제거하고 실제 무시 규칙으로 전환한 것은 보안상 아주 현명한 결정입니다. 이 파일에는 Firebase API 키, 프로젝트 ID 등 민감한 정보가 포함되어 있으므로 깃에 커밋되면 안 됩니다. 마치 집 열쇠를 공개 저장소에 올리는 것과 같죠.
86-87: IDE 설정 파일 분리, 깔끔합니다! ✨
.cursorrules를 무시 목록에 추가하여 개발자별 IDE 설정을 공유하지 않도록 한 점이 좋습니다. 이렇게 하면 각 팀원이 자신의 개발 환경을 자유롭게 커스터마이징할 수 있고, 불필요한 설정 충돌을 피할 수 있습니다.settings.gradle.kts (1)
37-37: 새 analytics 모듈 추가 - 깔끔합니다!멀티 모듈 구조에 analytics 모듈을 추가하는 표준적인 방식입니다. TYPESAFE_PROJECT_ACCESSORS가 활성화되어 있어
projects.core.analytics로 타입 안전하게 참조할 수 있네요. 👍core/analytics/src/main/AndroidManifest.xml (1)
1-4: 라이브러리 모듈의 표준 매니페스트입니다.Android 라이브러리 모듈에 필요한 최소한의 매니페스트 구조입니다. 권한이나 컴포넌트 선언이 필요 없는 유틸리티 성격의 모듈에 적합한 형태네요.
app/build.gradle.kts (2)
4-5: Firebase 플러그인 적용이 올바른 위치에 있습니다!Google Services와 Crashlytics 플러그인을 app 모듈에만 적용한 것은 정확한 접근입니다. 이 플러그인들은 애플리케이션 수준에서만 필요하므로 라이브러리 모듈에는 적용하지 않는 것이 맞습니다.
참고:
google-services: google-services.json 처리 및 Firebase 설정firebase-crashlytics: 크래시 리포트 매핑 파일 생성
37-40: Firebase BOM을 활용한 버전 관리 - 모범 사례입니다!Firebase BOM(Bill of Materials)을 platform으로 선언하여 Firebase 라이브러리들의 버전을 일관되게 관리하는 방식은 Firebase 공식 권장 사항입니다. 이를 통해:
- 라이브러리 간 호환성 보장
- 개별 버전 명시 불필요
- 버전 충돌 방지
Crashlytics 의존성도
implementation스코프로 적절하게 선언되었습니다.build.gradle.kts (1)
10-11: 플러그인 등록 방식이 정확합니다!루트 build.gradle.kts에서
apply false로 플러그인을 등록하는 것은 멀티 모듈 프로젝트의 표준 패턴입니다. 이를 통해:
- 플러그인 버전을 중앙에서 관리
- 필요한 모듈에서만 선택적으로 적용 가능
- Gradle 플러그인 클래스패스 최적화
Version Catalog와 함께 사용하여 더욱 깔끔한 의존성 관리가 되었네요! 👍
core/analytics/build.gradle.kts (1)
1-4: Convention Plugin 활용이 훌륭합니다!
twix.android.library와twix.koinConvention Plugin을 활용하여 반복적인 설정을 제거한 점이 좋습니다. 이를 통해 모듈 간 일관된 설정을 유지할 수 있네요.gradle/libs.versions.toml (2)
21-23: Version Catalog를 활용한 중앙 집중식 버전 관리 - 모범 사례입니다!Firebase 관련 버전들을 Version Catalog에 선언하여:
- 버전을 한 곳에서 관리
- 타이핑 실수 방지 (IDE 자동완성)
- 버전 일관성 보장
특히
google-firebase-bom으로 Firebase 라이브러리 간 호환성을 보장하는 전략이 훌륭합니다.
178-179: 플러그인 버전 선언이 깔끔합니다!Firebase 플러그인들을 Version Catalog에 등록하여 타입 안전하게 참조할 수 있도록 한 점이 좋습니다.
google-services: 4.4.4 (최신 안정 버전)firebase-crashlytics: 3.0.6 (최신 버전)Version Catalog의 alias를 통해
alias(libs.plugins.google.services)형태로 가독성 높게 사용할 수 있네요!
dogmania
left a comment
dogmania
left a comment
There was a problem hiding this comment.
고생하셨습니다! api 부분만 궁금해서 한번 확인 부탁드려용
|
|
||
| dependencies { | ||
| implementation(platform(libs.google.firebase.bom)) | ||
| api(libs.google.firebase.analytics) |
There was a problem hiding this comment.
혹시 이 부분만 따로 api로 뺀 이유가 있을까요?? api로 노출시키면 :feature에서 sdk에 접근이 가능해지는데 특별한 이유가 있는 건지 궁금합니다
모듈을 나눈 만큼, 관련된 책임은 이 모듈에서 담당하고 외부 모듈에서 sdk에 직접 접근하는 건 막는 게 좋을 거 같아요. :core:analytics에 로깅 클래스를 구현하고 외부에는 인터페이스를 통해 접근하는 것으로 구현하면 어떨까요? 그럼 api는 사실상 불필요해지고 implementation으로 바꿔도 될 것 같습니다!
|
아 그리고 모듈 나누는 건 좋아요! |
이슈 번호
#15
리뷰/머지 희망 기한 (선택)
2025.12.31
작업내용
결과물
리뷰어에게 추가로 요구하는 사항 (선택)
깔끔할 것 같아서 모듈로 분리했는데 어떻게 생각해 ?