🤔 Why

프로젝트나 스크럼을 진행하면서 저희가 왜 이러한 선택을 했는지 기록을 하는 공간입니다.

Day01

❓ Gradle -> KTS 마이그레이션 했는지

공식문서 - Groovy -> KTS
우아한 형제들 기술블로그 - Gradle Kotlin DSL 이야기

• Kotlin으로 변경을 한다면 IDE에서 제공해주는 기능을 더 잘 사용할 수 있다.
  • 코드 자동완성
  • 오류코드 강조

---

❓ 멀티 모듈 사용 이유

• 캡슐화
  • 의존성 분리
• 팀 협업
  • 각 모듈이 갖는 책임을 명확하게 가능하다.
  • 다른 사람이 우리 프로젝트를 봤을때 gradle만 보고서 해당 모듈이 어떤 모듈인지 알 수 있다.
  • 혹은 클린 아키텍처를 알고 있는 사람이라면 현재 분리된 레이어만 보고도 예상이 가능하다.

❓ 싱글 액티비티 vs 멀티 액티비티

• 상세 화면과 같이 여러 부분에서 사용되고, 툴바가 바뀌는 경우 액티비티 필요

-> 멀티 액티비티 사용

---

❓ Koin vs Hilt(Dagger2)

• Koin은 런타임에 의존성을 주입한다.
  • 런타임에 에러가 발생하기에 내가 주입을 하지 않아도 앱은 빌드가 된다.
• Hilt는 컴파일 타임에 주입에 대한 검증을 마친다.
  • Android X 라이브러리와 함께 사용할 수 있는 다양한 라이브러리 제공 (ViewModel, WorkManager 등)
  • 명확한 Scope, 보일러 플레이트 코드 감소(Dagger2 에서 직접 Component를 만들고 설정하던 과정이 간소화됨)
  • 컴파일 타임에 주입을 하므로 앱 시작시 문제가 있다면 즉시 알 수 있다.

결과적으로는 Koin 보다 Hilt를 선택한 이유는 유저는 더 빠르게 서비스를 이용할 수 있는 것과 개발자는 더 안정적으로 서비스를 제공이 가능해졌다는 부분입니다.

---

❓ DI(Hilt) 위치

data vs app

• 우리 조에서 핫한 주제였다.
• data레이어에 존재해야 할지 app레이어에 존재해야 할지

왜 data에 존재해야 하는지는 아래와 같다.

• 우리가 의존성을 주입하는 것들이 대부분이 data, domain 객체이다.
• data는 domain을 알고 있으므로 data 레이어에 두는 것이 옳다.

app에 존재해야 하는 이유는 아래와 같다.

• app이 모든 레이어를 알고 있다.
• 그러므로 어떤 의존성이든 app에서 처리가 가능하다.
• 우리가 현재 구현하게 될 provide는 대부분이 SingleTon(Application)인데 그러면 Application과 같이 있는게 맞지 않나

결과적으로 app 레이어에 있어야 하는 이유가 좀 더 타당하다고 팀내에서 결론이 났습니다.

❓ minSDK

21 vs 23

21를 선택 해야 하는 이유

• 98.8% 의 유저를 지원할 수 있다.
• 더 많은 버전에 따른 대응을 학습 할 수 있다.

23를 선택 해야 하는 이유

• 96.2% 로 2.6% 정도의 차이는 무시할 수 있다.
• 학습이 아닌 실제로 출시할 앱이다
• 지문 인식API가 SDK 23 이후 부터 지원한다.

결과적으로 출시가 목표이기 떄문에 23버전 이상으로 결정을 하였습니다.

---

❓ Firebase Database 의 선택

Realtime Database Vs Cloud Firestore

Realtime Database

• 데이터를 JSON 트리로 저장

  • 복잡한 계층적인 데이터는 대규모로 구성하기 어려움

• 제한된 정렬 및 필터링이 있는 심층 쿼리

  • 정렬이나 필터링이 가능하지만 둘 다는 안된다
  • 쿼리는 항상 하위 트리를 반환 한다
  • 쿼리의 성능은 데이터가 증가하면 저하 된다

• 확장시 샤딩이 필요합니다

  • 단일 DB 당 200,000 개의 동시 연결 및 1,000 write/s 이며 그 이상으로 확장 시 DB를 분할 해야한다

• 가격

  • 저장된 크기 15GB 기준 $70

Cloud Firestore

• Document모음으로 저장

  • 복잡한 계층정인 데이터는 Document내의 하위 Collection을 이용하여 구성하기 쉬움

• 복합 정렬 및 필터링이 있는 인덱싱된 쿼리

  • 단일 쿼리에서 필터를 연결하고 속성에 대한 필터링 및 정렬을 결합할 수 있다.
  • Collection의 Document만 반환하고 하위 Collection은 반환하지 않습니다.
  • 쿼리 성능은 기본적으로 Indexing 되기 때문에 데이터 크기가 아닌 결과 크기에 비례한다.

• 스케일링은 자동

  • 1,000,000개의 동시 연결 및 10,000 write/s 이며 Firebase 에서 한도를 늘릴 계획

• 가격

  • 저장된 크기 15GiB 기준 $2.52

출시 후 DB 의 가격적인 측면, 쿼리의 성능 등을 이유로 Cloud Firestore를 선택 했습니다.

Day02

❓ Material3

프로젝트에 도입을 해야할까?

도입하려는 이유

• 새로운 기술 도입에 대한 시도
• 가이드를 기준으로 개발하여 시간 단축

도입하지 않아도 되는 이유

• Material3 방식으로 디자인을 작업하기에 시간이 더 걸린다.
• 작업한 결과물이 Material3와 어울리지 않다 판단

Material3를 도입하지 않기로 결정

---

❓ 지도와 장소 검색 api

네이버 vs 카카오, 어떤 Open Api를 사용해야 할까?

api가 필요한 요구사항

• 사용자 위치 반경 500m 중 소지 기프티콘 사용처를 지도에 표시

1. 사용자 현재 좌표 기준 반경 500m 내 키워드 검색
2. 검색 결과에 따라 지도에 정보 표시

검색

네이버 지역 검색 api

카카오 로컬 api

사용자 현재 좌표 기준 반경 500m 내 키워드 검색이 필요하기 때문에 검색 api는 카카오 로컬 Api로 빠르게 결정되었다.

지도

장소 검색 api를 카카오로 확정된 뒤 장단점을 비교해보았다.

💚 네이버 지도

장점

• 예쁘다.
• 윈도우 환경의 에뮬레이터에서도 구동할 수 있다.
• 무료로 월 1억건 사용 가능 (일 333만회 사용 가능)

단점

• 카카오, 네이버 개발자 센터에 둘 다 앱 등록을 해야한다.

💛 카카오 지도

장점

• 카카오 로컬 api를 사용하는 김에 같이 등록해서 사용할 수 있다.

단점

• 맥이 아닌 환경에서는 에뮬레이터 구동 불가 (테스트 기기로 개발해야함)
• 무료로 1일 300,000회 사용 가능
• 안 예뻐요.

검색 api는 REST API이기 때문에 앱 자체에 큰 영향을 주지는 않을 것 같아 예쁘면서도 사용횟수가 많고, 에뮬에서도 돌아가는 네이버지도를 선택했다.

Day 03

❓ 이미지를 어떻게 불러와야 할까?

Firebase 와 기기에 파일로 이미지를 저장하고 있고, Firebase 의 요청 수(비용)를 줄이기 위해 파일에 존재한다면 파일에서 가져오는 방식을 선택하려고 한다

• Firebase 의 Storage 에 이미지가 저장되어 있고, Cloud Firestore(이하 FirebaseDB) 에 사용자 및 기프티콘 정보가 저장되어 있다
• Room 에는 FirebaseDB Document 의 id 를 가지고 있고, 파일의 위치 정보를 가지고 있다

이미지 저장 및 요청 로직

1. 파일이 존재한다면 파일에서 가져온다
2. 파일이 존재하지 않는다면 파이어베이스에 요청한 후 룸에 정보를 갱신한 후 파일을 저장하고 다시 불러와야 한다

Data 레이어에서 가져와야 하는데 파일의 유무를 확인하기 위해서는 context 가 필요하다. 그럼 어떤 레이어에서 처리해야 할 지 고민이었다.

1. Network 레이어를 만들고, Presentation과 Data 레이어에서 Network 레이어를 알게 한다
2. 파일의 유무는 Presentation 에서 하고, 존재하지 않는 경우에만 Data 레이어에 요청한다

❓ 일반 기프티콘, 금액권 기프티콘 모델 구조

• 추상 클래스
• 인터페이스
• sealed class
• Boolean 으로 구분

모든 속성이 동일하고 금액권 여부만 차이가 나기 때문에 Boolean 속성으로 구분하는 것으로 결정

❓ 데이터 흐름이 올바른가?

현재로서는 파이어베이스와 Room 이 동일하고 고유한 아이디를 사용하기 위해 파이어베이스의 Document ID 를 사용하려고 했다. 그래서 플로우가 파이어베이스를 항상 거쳐야 했고, 이때 Network 연결에 문제가 생겼거나 파이어베이스 접근에 문제가 생긴 경우 Room 에서 데이터를 일단 가져온 후 동기화 하는 작업이 필요했다

하지만 고유한 아이디만 가질 수 있다면 해결될 문제였고, 로그인 한 유저가 고유한 아이디 값을 가진다고 가정했을 때 해당 아이디와 기프티콘 아이디를 결합하면 고유한 아이디를 사용할 수 있을 것이라 판단했다

❓ SNS 로그인 어떻게 지원할까

위의 문제로 인해서 유저의 고유한 아이디를 얻어야 했다.

기존의 SNS 로그인은 Kakao, Naver, Google 을 지원하도록 계획했지만 파이어베이스는 Kakao, Naver 로그인을 지원하지 않는다.

이렇게 됐을 때 가능한 경우는 다음과 같았다.

1. 각각 로그인 API 에서 고유한 식별 정보를 내려주는 지 확인하고 각각의 콘솔에서 관리해야 한다
2. 파이어베이스의 인증 시스템으로 Kakao와 Naver 의 고유 식별 번호(혹은 이메일)를 넘겨서 파이어베이스 콘솔에서 한 번에 관리한다
3. 일단은 Google 로그인만 지원한다

현재는 Google 로그인 만 지원하더라도 대부분의 사용자를 커버할 수 있다는 점과 로그인 수단이 달라진다고 해서 서비스의 내용이 달라지는 것은 아니기 때문에 추후에 추가로 지원하는 방향으로 결정하게 되었다

❓ 기프티콘의 ID 는 무엇을 기준으로 할까?

• 사용자마다 고유의 ID 가 있고, 기프티콘 마다 고유의 ID 가 있다
• 사용자의 ID 는 로그인 API에서 유일성을 지원해준다고 해도 기프티콘의 ID 는 겹칠 위험이 있다

다음의 의견들이 나왔다

1. 사용자의 ID 와 기프티콘의 ID 를 결합해서 유일한 ID 를 만들자
2. 기프티콘의 UUID 를 사용하자

1번 의견은 사용자의 ID 를 따로 둬야 특정 사용자의 전체 기프티콘 목록을 가져올 수 있기 때문에 정보가 중복될 수 있다

반면 2번 의견은 UUID 만 겹치지 않는다면 기프티콘의 ID 만으로도 구분할 수 있고, 정보도 중복되지 않기 때문에 2번 의견을 따르기로 했다

UUID 가 겹칠 확률

• UUID 는 36 자리의 숫자 + 알파벳 으로 구성된다
• UUID 는 총 340,282,366,920,938,463,463,374,607,431,768,211,456 개의 경우의 수가 존재한다
• 수십 조 개의 UUID(v4)를 생성할 때 단 하나의 중복될 확률은 인간이 매년 하늘에서 운석에 맞을 확률과 같다
• 그 확률은 0.00000000006% 이다
• 출처: UUID 가 겹칠 확률

Day08

지도를 캐싱하는 이유

왜 지도를 캐싱하게 됐을까

Day18

다이얼로그(+뷰모델)를 재활용하면 안 되는 이유

문제 상황

스낵바, 토스트, 다이얼로그, 프래그먼트 등 객체를 생성하고 재활용하며 사용하고 있었다. 문제는 뷰모델을 가지는 바텀시트 다이얼로그를 사용하면서 발생했다.

바텀시트 다이얼로그를 변수에 담아서 가지고 있었고, 필요할 때 해당 객체를 show 하면서 재사용하고 있었는데, 이 다이얼로그 내에서 사용하는 ViewModel 에서 viewModelScope.launch 블록을 타지 않아서 원하는 동작이 실행되지 않는 문제였다.

우리가 사용하던 부분은 다음과 같다

1. 뷰모델을 by viewModels() 를 통해서 생성하고 있다. 이때 (우리의 경우) 프래그먼트의 객체 String 을 키로 사용하여 뷰모델을 생성하고 ViewModelStore 에 저장하고 있는다
2. 프래그먼트는 BottomSheetDialogFragment 를 구현하여 다이얼로그를 생성한다

왜 이런 문제가 발생했을까

바텀시트 다이얼로그를 show() 하게 되면 아무리 객체를 가지고 있다 하더라도 정상적으로 프래그먼트의 생명주기를 타게된다. 즉, 다이얼로그를 닫으면서 onDestroy 가 되고, 이 과정에서 ViewModel 도 onCleared 가 호출된다.

그리고 다이얼로그를 다시 show() 하면 똑같은 생명주기를 탄다. 하지만 이때 ViewModel 은 init 이 되지 않는다.

Etc

❓ SharedPreferences? DataStore?

SharedPreferences가 가졌던 문제

• UI Thread에 안전하지 않음
  • commit() 동작에서 별도의 스레드를 사용하지 않고 호출된 Thread에서 파일을 쓴다.
  • 그와 동시 UI Thread에서 호출할 수 있다 😨 권장되지는 않지만 대용량의 데이터를 다룬다면 UI Thread가 Block하면서 버벅이거나 ANR 발생의 위험성이 존재한다.
• Runtime Exception 에 취약
  • Exception에 대한 에러 핸들링을 제공하고 있지 않음.
  • 런타임에 에러가 발생하면.. 앱이 강제 종료된다.

DataStore가 가진 이점

• 비동기 API 지원
  • Kotlin Coroutine, Flow를 지원하여 비동기적이고 일관된 트랜잭션 방식으로 데이터 저장
  • IO Dispatcher를 사용해 데이터를 조작한다.
• Strong Consistency 보장
  • 다중 스레드 환경에서 동일한 데이터가 추출될 수 있도록 하는 Transaction API 제공
• Proto DataStore을 사용한다면 type safey 지원

💡 SharedPreferences의 문제점 보완되었고 Flow를 지원한다는 점에서 Flow를 적극 사용하는 삡에게 DataStore을 사용하지 않을 이유가 없다!