안드로이드 CS 단권화(feat. git, IO 같은 일반 CS도 일부 포함)

09
29

CS🖥️/안드로이드🤖

안드로이드 CS 단권화(feat. git, IO 같은 일반 CS도 일부 포함)

제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다.
잘못된 내용있으면 언제든지 말해주세요!!

안드로이드 4대 구성 요소

액티비티, 서비스, 브로드캐스트 리시버(BR), 콘텐츠 프로바이더(CP)

액티비티 - UI화면을 담당하는 컴포넌트
서비스 - 화면에 보이지 않는 백그라운드 작업을 처리할수있음
브로드캐스트 리시버 - 시스템 단에서 발생하는 이벤트를 앱에서 받아 처리함, 정적(매니페스트 등록), 동적으로 나뉜다.
콘텐츠 프로바이더 - 앱 간의 데이터 공유를 관리 - URI를 사용한다.

액티비티, 프래그먼트, AAC ViewModel, 서비스의 생명주기

다른건 다 잘 알고있고 서비스의 경우가 조금 어렵다.

Unbound 서비스: 서비스가 시작되면 클라이언트가 바인딩되지 않아도 작업을 마치거나 시스템 또는 클라이언트가 명시적으로 중지할 때까지 독립적으로 실행된다.
Bound 서비스: 클라이언트가 서비스에 바인딩되어야 상호작용할 수 있으며, 하나 이상의 클라이언트가 바인딩되어 있는 동안 서비스가 계속 실행되고 모든 클라이언트가 바인딩을 해제하면 서비스는 종료될 수 있다.

두 상태에 따라서 생성 이후 메서드가 onStartCommand일지, onBind(클라이언트가 없으면 onUnbind)일지 갈린다.

ViewModel과 Jetpack의 AAC ViewModel은 어떤 차이?

ViewModel

ViewModel은 MVC, MVP, MVVM 등 다양한 아키텍처 패턴에서 사용되는 프레젠테이션 로직을 처리하는 객체이다.
주로 UI 데이터를 처리하고, 화면의 상태를 유지하는 데 사용되며, 화면 회전 등으로 인해 액티비티가 다시 생성될 때 데이터를 유지할 수 있는 역할을 한다.
특징은 특정 플랫폼에 종속되지 않고, UI와 비즈니스 로직을 분리하는 데 집중한다.

Jetpack AAC ViewModel

Jetpack의 AAC(ViewModel)는 Android Jetpack의 Architecture Component의 일부로, Android 앱의 수명 주기와 긴밀하게 통합된 ViewModel이다.
Android의 수명 주기 관리에 최적화되어 있으며, 화면 회전이나 구성 변경 시에도 액티비티나 프래그먼트가 소멸되지 않는 동안 데이터를 유지할 수 있다.
특징은 액티비티나 프래그먼트의 수명 주기에 맞춰 메모리 누수를 방지하면서도 상태 데이터를 관리할 수 있다는 점이다.
AAC ViewModel은 ViewModelProviders나 Hilt와 같은 DI 프레임워크를 통해 간단하게 인스턴스를 생성하고 주입할 수 있는 기능을 제공한다.

따라서, ViewModel은 다양한 아키텍처에서 사용되는 일반적인 개념이라면, Jetpack AAC ViewModel은 Android의 생명 주기를 자동으로 관리하여 구성 변경 시에도 UI 상태를 유지하는 데 특화된 구현이다.

액티비티와 프래그먼트의 차이?

각 액티비티는 독립적으로 동작하고, 다른 액티비티로 전환할 때에는 인텐트를 통해야 한다.

프래그먼트는 하나의 액티비티 안에서 재사용이 가능한 화면을 의미한다. 독립적으로 동작할 수 없고 항상 액티비티 내에 호스팅되어야 한다.

프래그먼트가 트랜잭션을 사용할 때는, 프래그먼트 매니저를 사용하는데 계층 구조가 아래와 같다.

Host Activity (호스트 액티비티)
- FragmentActivity: 프래그먼트를 관리할 수 있는 액티비티다. 액티비티는 자신의 supportFragmentManager를 사용하여 프래그먼트를 관리한다.
- supportFragmentManager: 액티비티의 프래그먼트들을 관리한다. 액티비티가 생성될 때 초기화되며, 액티비티(호스트) 내에서 프래그먼트의 추가, 제거, 교체 등 트랜잭션 작업을 수행할 수 있다.
Host Fragment (호스트 프래그먼트)
- Fragment: 프래그먼트는 또 다른 프래그먼트를 포함할 수 있다. 이런 프래그먼트는 호스트 프래그먼트라고 불리며, 자신의parentFragmentManager(호스트의 매니저)와 childFragmentManager(호스트해줄 매니저)를 가지고 있다.
- parentFragmentManager: 호스트 프래그먼트가 포함된 액티비티나 상위 프래그먼트의 FragmentManager다.
- childFragmentManager: 프래그먼트 안에 포함된 자식 프래그먼트를 관리한다. 프래그먼트 내에서 다른 프래그먼트를 추가하거나 관리할 수 있다.
Child Fragment (자식 프래그먼트)
자식 프래그먼트는 호스트 프래그먼트에 속한 프래그먼트다. parentFragmentManager를 통해 상위 호스트 프래그먼트와 연결된다.

그럼 Intent는?

컴포넌트(4대 컴포넌트 모두 포함) 간에 작업을 수행하도록 요청하는 메시지 객체이 명시적, 암시적 인텐트로 나뉜다.
명시적 Intent는 명확하게 시작할 컴포넌트나 액티비티를 지정하는 것,
암시적 Intent는 특정 액션을 수행할 수 있는 컴포넌트를 찾아 실행하는 것을 의미한다.(urlScheme과 같은)

암시적 Intent는 Intent filter를 사용해서 제어할 수 있다.

> PendingIntent도 있다.
Intent를 갖는 클래스로, 기본 목적은 다른 프로세스(애플리케이션)의 권한을 허가하여 가지고 있는 Intent를 마치 본인 앱의 프로세스에서 실행하는 것처럼 사용하는 것이다. Notification 설정할 때 봤을 것이다.
Notification을 클릭해서 그 앱으로 이동하는 건, 다른 프로세스에서 PendingIntent를 사용해서 NotificationManager로 하여금 앱을 실행시키는 것이다.

서비스는?

포그라운드 서비스 - 알림을 표시해 놓고 사용자와 상호 작용하지 않아도 계속 실행되는 걸 말함(음악 플레이어 같은)
백그라운드 서비스 - 사용자가 직접 알지 못하는 작업을 수행할 때 사용
바운드 서비스 - 앱 내에서 서비스를 사용하여 간단한 클라이언트 - 서버 환경을 구성하는 것을 말함(특정 컴포넌트와 서비스간 상호작용) -> onBind, onUnbind가 호출되는

옵션 3개가 있다.

START_STICKY - 안드로이드가 서비스를 강제 중지한 경우, null intent를 보내서 재시작한다.
START_NOT_STICKY - 안드로이드가 서비스를 강제 중지한 경우, 재시작 하지 않는다.
START_REDELIVER_INTENT - 안드로이드가 서비스를 강제 중지한 경우, 이전과 동일한 intent를 보내서 재시작한다.

디자인 패턴? - MVC, MVP, MVVM

디자인 패턴은 소프트웨어 개발을 효율적으로 하기 위해 도입된, 재사용 가능한 설계를 의미한다.

MVC - 모델 - 뷰 - 컨트롤러로 데이터 처리를 담당하는 모델, UI를 담당하는 뷰, 이걸 연결하는 컨트롤러로 구성된다.
MVP - 뷰와 모델 사이에 프레젠터를 둬서 M-V 간의 직접 연결을 끊고, 뷰의 이벤트를 핸들링하는 역할을 한다. MVC의 진화
MVVM - 뷰와 모델 사이에 뷰 모델이 있는 구조로, 데이터 바인딩을 통해 뷰와 뷰모델이 업데이트 되는 방식. 뷰 모델이 중간에서 데이터를 변환하거나 처리하는 것을 담당하고 뷰는 이벤트만 받는 방식을 적용하여, 뷰와 모델 사이의 의존성을 낮출 수 있다.

레거시 대비 - AsyncTask가 무엇인지? 사용시 단점은?

AsyncTask는 백그라운드 작업을 간단하게 처리하고, 그 결과를 UI 스레드에서 쉽게 업데이트할 수 있도록 설계된 클래스이다.
Android 11(API 레벨 30)에서 Deprecated되어, 코루틴, WorkManager, Handler과 같은 대안을 사용한다.

단점으로는 아래와 같다.

메모리 누수 (Memory Leaks):
AsyncTask는 액티비티와 프래그먼트에서 자주 사용되었는데, 만약 액티비티가 백그라운드로 전환되거나 소멸되는 동안 AsyncTask가 계속 실행 중일 경우, 액티비티가 가비지 컬렉션(GC)에 의해 수집되지 않아 메모리 누수가 발생할 수 있다.
취소 및 중단의 어려움:
AsyncTask는 cancel() 메서드를 통해 작업을 취소할 수 있지만, 백그라운드에서 작업이 이미 진행 중인 경우, 작업이 중단되지 않고 계속 진행되는 경우가 있었다.
cancel(true)를 호출하면, isCancelled() 값이 true로 설정되지만, 실제로 실행 중인 백그라운드 작업을 강제로 중단하지 않음. -> 플래그만 바꾼다.
즉, 개발자가 백그라운드 작업 내부에서 취소 요청을 확인하고 처리해야 한다.
Thread.interrupt()로 직접 꺼버려야했다.
작업 관리의 어려움:
비동기 작업의 상태를 관리하고, 실행 중인 작업을 적절히 취소하는 것은 위에서 말했듯 AsyncTask에서 직접적으로 지원되지 않아서, 여러 AsyncTask가 동시에 실행되거나 연속적으로 실행될 때는 관리가 어렵다.
ThreadPool 제한:
AsyncTask는 내부적으로 스레드 풀을 사용했는데, 기본적으로 실행 가능한 스레드 풀의 크기가 작기 때문에, 많은 AsyncTask를 동시에 실행할 경우 스레드 풀의 대기열에 쌓여 작업이 지연될 수 있었다.
작업 순서 불확실성:
AsyncTask는 Android 3.0(Honeycomb) 이후로 execute()를 호출할 때 기본적으로 직렬 실행되었지만, 이전 버전에서는 병렬 실행이 기본값이었다. 이로 인해 동작이 버전에 따라 달라졌고, 개발자가 명시적으로 executeOnExecutor()를 호출하여 병렬 실행을 명시해야 했다. 안정성이 떨어진다는 말.

대안으로 사용되는 WorkManager는 JetPack에 포함된 Android의 새로운 작업 스케줄링 라이브러리로, 백그라운드 작업을 안정적으로 처리할 수 있다. 특히, 긴 시간 실행되거나 네트워크에 의존하는 작업을 처리할 때 유용하다. 작업이 취소되었거나 장치가 재부팅된 경우에도 작업을 다시 시작할 수 있도록 설계되어 있다.

의존성 주입을 사용해봤는지? 왜 썼는지?

의존성 주입(Dependency Injection, DI)은 객체 간의 의존성을 외부에서 주입받는 방식으로, 코드의 유지보수성, 테스트 용이성, 가독성을 높이는 데 중요한 역할을 한다.

저는 Hilt를 사용했는데, Hilt는 Google이 관리하는 Android 특화 DI 라이브러리로, 복잡한 설정 없이 DI를 쉽게 구현할 수 있는 장점이 있다.Dagger에 비해 보일러플레이트 코드를 대폭 줄여주고, 명시적인 컴포넌트 설정 없이도 간편하게 의존성을 주입할 수 있다.

	Hilt	Dagger
설정 복잡도	간단함, 자동 컴포넌트 설정	복잡함, 수동 컴포넌트 설정
보일러플레이트 코드	적음	많음
Android 특화	Android에 최적화됨	Android 특화 아님, Dagger-Android 필요
생명 주기 관리	Android 생명 주기 관리 자동화	생명 주기 관리 수동 설정 필요
테스트 용이성	Hilt 테스트 모듈 제공, 간편한 테스트 작성	테스트용 컴포넌트/모듈을 수동으로 설정해야 함
사용성	Android 프로젝트에 최적화	다양한 환경에서 사용 가능
빌드 속도	상대적으로 빠름	컴포넌트가 복잡할 경우 빌드 시간이 길어질 수 있음

Jetpack Navigation에서 popUpTo와 popUpToInclusive 차이

popUpTo

popUpTo는 역방향 탐색 시 백 스택에서 특정 목적지까지의 프래그먼트를 제거하는 속성이다.
이 속성은 탐색할 때 특정 목적지 이후에 있는 모든 프래그먼트를 백 스택에서 제거하는 데 사용된다.
예를 들어, popUpTo="@+id/destination_home"로 설정하면 destination_home 목적지까지 역방향으로 탐색하며, destination_home 이후의 모든 프래그먼트가 제거된다.
destination_home 자체는 백 스택에 남아 있어, 여전히 그 프래그먼트로 돌아가게 된다.

popUpToInclusive

popUpToInclusive는 popUpTo와 함께 사용되며, 지정된 목적지 자체를 백 스택에서 제거할지 여부를 결정하는 속성이다.
기본값은 false로 설정되어 있으며, 이때는 popUpTo로 지정된 목적지 자체는 백 스택에서 제거되지 않고 남아 있다.
popUpToInclusive="true"로 설정하면, 지정된 목적지도 포함하여 백 스택에서 제거된다.
예를 들어, popUpTo="@+id/destination_home" popUpToInclusive="true"로 설정하면, destination_home과 그 이후의 모든 프래그먼트가 제거된다.

따라서, popUpTo는 특정 목적지 이후의 프래그먼트를 제거하고, popUpToInclusive는 그 지정된 목적지 자체도 제거할지 여부를 결정하는 속성이다.

좀 더 부연설명하면,

네비게이션 그래프가 A -> B -> C -> D 라고 가정하자.
여기서 D에서 A로 돌아가면서 B와 C를 백스택에서 제거하려면 popUpTo="B"와 함께 popUpToInclusive=true를 설정하면 된다. 그럼 목적지인 B로 갈 때, B도 날리기 때문에 그 전의 backstack인 A만 남고 B, C, D가 백스택에서 모두 제거된다.

	popUpTo	popUpToInclusive
기능	백 스택에서 특정 목적지까지의 프래그먼트를 제거하지만, 지정된 목적지 자체는 남겨둠	백 스택에서 특정 목적지와 그 이후의 모든 프래그먼트를 제거하며, 지정된 목적지 자체도 제거함
동작 방식	지정된 목적지까지의 경로에서 그 목적지 이후의 프래그먼트만 제거함	지정된 목적지뿐만 아니라 그 이전의 모든 프래그먼트를 함께 제거함
사용 예시	popUpTo="@+id/home": home 목적지 이후의 모든 프래그먼트를 제거하고 home은 남겨둠	popUpTo="@+id/home" popUpToInclusive="true": home과 그 이후의 모든 프래그먼트를 함께 제거함
사용 목적	특정 목적지 이후의 백 스택을 정리하고, 지정된 목적지로 돌아가기 위해 사용	특정 목적지 자체도 제거하여, 그 이전의 프래그먼트로 돌아가거나 새로운 경로를 설정하고자 할 때 사용

Dispatchers의 종류와 특징?

Dispatchers.Main: UI 관련 작업 (메인 스레드).
Dispatchers.IO: 네트워크, 파일 입출력 작업 (I/O 바운드 작업).
Dispatchers.Default: CPU 집약적인 작업 (CPU 바운드 작업).
Dispatchers.Unconfined: 특정 스레드에 얽매이지 않으며, 상황에 따라 실행 스레드가 달라짐.

동기 비동기, Blocking Non-Blocking

동기와 비동기는 작업의 순차성과 대기 상태에 대한 차이를 나타내며, 블로킹과 넌블로킹은 작업 중 대기 여부에 따라 구분되는 개념이다.

mermaid

접기

동기(Synchronous)

동기 방식은 작업이 순차적으로 실행되며, 하나의 작업이 완료되기 전에는 다음 작업이 시작되지 않는다.
각 작업은 서로 의존하며, 작업 A가 완료되어야 작업 B가 시작된다.
이 방식은 블로킹 상태를 초래할 수 있다. 즉, 이전 작업이 끝날 때까지 다음 작업이 대기 상태에 놓이게 된다.
예: 파일을 읽을 때, 파일이 완전히 읽힐 때까지 코드가 다음 단계로 넘어가지 않는다.

비동기(Asynchronous)

비동기 방식은 여러 작업이 동시에 실행될 수 있으며, 하나의 작업이 완료되기를 기다리지 않고 다음 작업이 진행된다.
작업 간에 의존성이 없으며, 각 작업이 별도의 스레드 또는 프로세스에서 실행될 수 있다.
이 방식은 넌블로킹 상태를 유지하여, 작업을 기다리는 동안 다른 작업을 동시에 수행할 수 있다.
예: 네트워크 요청을 보내고, 응답이 올 때까지 다른 코드를 계속 실행한다.

Blocking

블로킹 작업은 호출된 함수나 작업이 완료될 때까지 실행 흐름이 멈추는 것을 의미한다.
즉, 작업이 완료될 때까지 프로그램이 대기 상태에 빠지며 다른 작업을 할 수 없다.
예: 파일을 블로킹 방식으로 읽으면, 파일이 완전히 읽혀질 때까지 다른 작업을 수행할 수 없다.

Non-blocking

논블로킹 작업은 호출된 작업이 즉시 반환되며, 실행 흐름이 중단되지 않고 계속 진행된다.
작업이 완료되기를 기다리지 않고 다른 작업을 동시에 진행할 수 있다.
예: 파일을 논블로킹 방식으로 읽으면, 파일 읽기 요청 후 즉시 다음 작업을 진행하며, 나중에 파일 읽기가 완료되면 알림을 받는다.

섞는다면 아래와 같이 적용된다.

Sync + Blocking: 작업이 완료될 때까지 기다리고, 순차적으로 실행된다.
Async + Blocking: 비동기적 작업이지만, 완료될 때까지 기다린다.
Sync + Non-blocking: 순차적으로 실행되지만, 즉시 반환되므로 다른 작업을 수행할 수 있다.
Async + Non-blocking: 비동기적 작업이며 즉시 반환되어 다른 작업을 동시에 처리할 수 있다.

Serializable과 Pacelable 차이

	Serializable	Parcelable
성능	느림: Java Reflection을 사용하여 직렬화/역직렬화를 처리하므로 오버헤드가 발생하고 속도가 느림. 대량의 객체를 직렬화할 때 성능 저하가 더 심해질 수 있음.	빠름: 필드를 명시적으로 직렬화/역직렬화하며, Android의 Binder 메커니즘을 사용해 최적화된 방식으로 처리하므로 성능이 뛰어남.
메모리 사용	더 많은 메모리 사용: Java의 기본 직렬화 메커니즘을 사용하며, 불필요한 데이터를 포함할 수 있어 메모리 사용량이 많아짐.	더 적은 메모리 사용: 필요한 데이터만 직렬화하며 불필요한 데이터는 포함되지 않으므로 메모리 사용량이 적음.
구현 복잡도	구현이 간단: 'implements Serializable'만 추가하면 되며, 별도의 메서드 작성 없이도 자동으로 직렬화/역직렬화가 가능함.	구현이 복잡: 각 필드를 직접 처리하는 'writeToParcel' 및 'createFromParcel' 메서드를 명시적으로 작성해야 하므로 코드 작성이 복잡함.
호환성	호환성 문제: 클래스 구조가 변경되면 역직렬화 시 문제가 발생할 수 있으며, 버전 불일치나 필드 변경으로 인해 역직렬화 오류가 발생할 가능성이 있음.	유연한 호환성: 명시적으로 직렬화 메서드를 작성하기 때문에 클래스 구조 변경에 더 유연하게 대응할 수 있음. 필드 추가나 삭제 시 문제가 발생하지 않음.
사용 환경	Java 및 Android에서 사용 가능: Android뿐만 아니라 Java 표준 라이브러리에서도 사용 가능.	Android 전용: Android IPC 및 컴포넌트 간 데이터 전달에 최적화되어 있으며, Java 표준 환경에서는 사용 불가.

OkHttp와 Retrofit2의 차이

OkHttp와 Retrofit은 둘 다 네트워크 통신을 위한 라이브러리이지만, OkHttp는 더 낮은 수준의 HTTP 클라이언트 라이브러리이고, Retrofit은 OkHttp를 기반으로 동작하는 고수준의 REST 클라이언트 라이브러리이다. Wrapping된게 Retrofit이라고 봐야된다.

	OkHttp	Retrofit
역할	저수준 HTTP 클라이언트	고수준 REST 클라이언트
API 설계	URL, 헤더, HTTP 메서드를 수동으로 작성해야 함	인터페이스(어노테이션)로 API 엔드포인트를 선언하고 자동으로 HTTP 요청을 생성함
데이터 변환	JSON 파싱을 직접 처리해야 함	Gson, Moshi 등의 라이브러리로 자동으로 JSON을 Java/Kotlin 객체로 변환함
비동기 처리	수동 콜백을 통해 비동기 요청을 처리해야 함	코루틴 또는 RxJava와 통합되어 비동기 요청을 쉽게 처리할 수 있음
기능	HTTP/2, WebSocket, 캐싱, 타임아웃 설정 등 네트워크 프로토콜과 관련된 저수준 기능 제공	자동 데이터 변환, 더 간편한 API 호출, 에러 처리 등 REST API 호출을 위한 고수준 기능 제공
사용 사례	네트워크 연결 세부 제어 및 HTTP 프로토콜의 직접 구현이 필요한 경우 사용	REST API 통신을 간단하게 처리하고 자동 데이터 변환이 필요한 경우 사용

git merge와 rebase의 차이?

	git merge	git rebase
동작 방식	두 브랜치의 이력을 병합하고, 새로운 머지 커밋(Merge Commit)을 생성함	한 브랜치의 커밋들을 다른 브랜치 위에 재배치하여 이력을 재작성함
커밋 히스토리	병합 시, 두 브랜치의 이력을 그대로 유지하며, 병합 커밋을 추가해 이력에 분기점이 생김	브랜치의 커밋들을 다른 브랜치 위에 재배치하므로, 히스토리가 깔끔하게 직선형으로 유지됨
사용 예시	기능 개발이 완료된 후, 기존 이력을 그대로 유지하면서 변경 사항을 병합할 때 사용	기능 브랜치를 메인 브랜치 위에 재배치하여 이력을 깔끔하게 정리할 때 사용
충돌 해결	병합 시 충돌이 발생하면, 충돌을 해결하고 병합 커밋을 생성함	재배치 과정에서 충돌이 발생하면, 각 커밋마다 충돌을 해결하고 커밋을 다시 작성해야 함
장점	이력의 모든 커밋을 유지할 수 있으며, 협업 시 이력을 명확히 구분할 수 있음	간결한 이력을 유지할 수 있으며, 브랜치가 직선형으로 깔끔하게 관리됨
단점	병합 커밋으로 인해 이력 관리가 복잡해질 수 있음	히스토리가 재작성되므로, 협업 중인 브랜치에서 rebase를 잘못 사용할 경우 혼란을 초래할 수 있음
사용 상황	협업 브랜치 병합 시 기존 이력 유지가 중요한 경우	개인 작업 브랜치에서 히스토리 관리를 간결하게 하고자 할 때 사용

rebase는 커밋 히스토리를 재구성해서 깔끔한 커밋 그래프를 만들어준다.

git과 git flow의 차이는 무엇인가요?

	Git	Git Flow
정의	분산 버전 관리 시스템으로, 코드 변경 사항을 관리하고 협업을 도와주는 도구	Git을 기반으로 한 브랜칭 전략으로, 소프트웨어 개발 프로세스를 구조화하여 관리하는 방법론
기능	파일을 추적하고 버전 기록을 남기며, 분산 환경에서 협업을 가능하게 함	기능 브랜치, 릴리스 브랜치, 핫픽스 브랜치 등 명확한 브랜칭 규칙을 정하고, 이를 통해 개발 프로세스를 관리함
주요 명령어	git init, git add, git commit, git push, git merge, git rebase 등	Git 명령어를 기반으로, 특정 브랜치 전략을 따름. develop, feature, release, hotfix, master 브랜치를 사용
사용 목적	소스 코드의 버전 관리 및 협업을 지원하며, 모든 형식의 프로젝트에 사용 가능	주로 소프트웨어 개발 프로세스에서 사용되며, 코드의 릴리스 준비와 배포를 체계적으로 관리하기 위한 브랜칭 전략
브랜치 구조	자유롭게 브랜치를 만들고 관리할 수 있으며, 특정 브랜칭 규칙은 없음	master, develop, feature, release, hotfix 등의 명확한 브랜치 구조를 따름
복잡도	Git 자체는 브랜치 전략이 명확하지 않아 자유롭게 사용 가능	고정된 브랜칭 규칙을 따르므로 프로젝트가 복잡할 수 있지만, 체계적인 개발 프로세스를 유지하는 데 도움을 줌
사용 상황	모든 프로젝트에서 사용 가능, 단일 브랜치나 간단한 브랜칭 전략을 사용할 때 적합	대규모 프로젝트나 팀 협업에서 체계적인 브랜칭 전략을 필요로 할 때 적합. 명확한 릴리스 관리와 배포 주기가 필요할 때 사용

Git은 버전 관리 도구이며, 소스 코드의 변경 사항을 관리하는 시스템이다.
Git Flow는 Git을 기반으로 한 브랜칭 전략으로, 개발, 릴리스, 배포 프로세스를 체계적으로 관리하기 위한 방법론이다.

interface와 abstract 차이? -> 일반적인 정의, 코틀린에서의 정의

일반	Interface	Abstract Class
구현 내용	구현이 없는 메서드를 선언하며, 디폴트 메서드로 일부 구현 가능	일반 메서드와 추상 메서드 모두 포함 가능. 일반 메서드는 구현 내용을 가짐
다중 상속	한 클래스가 여러 인터페이스를 구현할 수 있음	한 클래스는 하나의 추상 클래스만 상속 가능
멤버 변수	멤버 변수를 가질 수 없음. 상수만 선언 가능	멤버 변수를 가질 수 있으며, 공통 상태를 관리 가능
생성자	생성자 없음	생성자 있음. 상속된 클래스에서 생성자를 통해 초기화 가능
목적	주로 동작(행동)을 정의하고, 서로 다른 클래스들이 같은 동작을 구현하도록 요구할 때 사용	공통된 특성 및 동작을 가진 클래스들 간의 상속 관계를 정의할 때 사용
인스턴스화	인터페이스는 인스턴스화 불가, 구현한 클래스에서만 사용 가능	추상 클래스도 인스턴스화 불가, 반드시 하위 클래스에서 구현되어야 함
사용 상황	클래스 간 공통적인 행동을 정의하거나, 여러 구현체가 필요할 때 사용	공통적인 속성과 동작을 가진 여러 클래스에서 기본 동작을 공유하거나 일부만 구체적으로 구현해야 할 때 사용

인터페이스는 구현이 없는 메서드 선언을 제공하며, 여러 클래스에서 공통적으로 구현할 동작을 정의하고, 다중 상속이 가능하다.
추상 클래스는 추상 메서드와 일반 메서드를 모두 포함하며, 상속을 통해 공통 동작을 재사용할 수 있다. 단일 상속만 가능하다.

kotlin	Interface(여기서 좀 차이가 있다)	Abstract Class
구현 내용	추상 메서드와 기본 구현을 포함한 메서드 모두 선언 가능	추상 메서드와 구현된 메서드 모두 포함 가능
다중 상속	한 클래스가 여러 인터페이스를 구현할 수 있음	한 클래스는 하나의 추상 클래스만 상속 가능
프로퍼티(중요)	추상 프로퍼티와 기본 getter를 선언 가능. 상태(멤버 변수)는 가질 수 없음	프로퍼티와 멤버 변수를 포함할 수 있으며, 상태를 관리 가능
생성자	생성자를 가질 수 없음	생성자를 가질 수 있음. 하위 클래스에서 상속을 통해 생성자 호출 가능
목적	여러 클래스에 공통 동작을 정의하고, 같은 동작을 구현하도록 요구할 때 사용	공통된 상태와 동작을 가진 클래스들 간에 공통 구현을 공유할 때 사용
인스턴스화	인터페이스는 인스턴스화 불가, 구현한 클래스에서만 사용 가능	추상 클래스도 인스턴스화 불가, 반드시 하위 클래스에서 구현되어야 함
사용 상황	여러 클래스가 동일한 동작을 구현해야 하며, 다중 상속이 필요한 경우	클래스 간에 공통된 상태와 동작을 공유하고, 단일 상속 구조를 유지해야 할 때 사용