StateFlow 업데이트: .value vs .update의 차이와 설계 철학
·
🐸 Android
0. StateFlowAndroid 개발에서 StateFlow는 UI 상태 관리의 표준으로 자리잡았다. Coroutine 기반의 반응형 프로그래밍을 지원하며, ViewModel에서 UI 상태를 관리하는 데 매우 유용하다.StateFlow를 업데이트하는 두 가지 방식의 차이와 Race Condition, 그리고 StateFlow 설계철학에 대해 알아본다.1. StateFlow의 두 가지 업데이트 방식Kotlin의 MutableStateFlow를 업데이트하는 방법은 크게 두 가지이다.1: .value를 통한 직접 할당가장 직관적인 방법이다. 새로운 값을 직접 대입한다.private val _itemPatches = MutableStateFlow>(emptyMap())fun addPatch(id: Long, ..
2025년 회고.
·
💬 회고
카자흐스탄의 빅 알마티 정상에서 미루고 미루다 쓰는 2025년의 회고올해는 무슨 일이 있었을까, 그리고 2026년을 바라보는 나의 목표 또한 기록해본다. 2025년 Keyword새로운 것을 만든다는 것 리멤버에 합류한지 2년이 조금 넘었다. 첫 6개월은 회사에 적응하는 시간이었다.그 이후부터는 제품에 더 적극적으로 참여하기 시작했고, 프로필, 공고 도메인을 거쳐 올해는 신제품을 만드는 신사업팀에 합류하게 되었다. 제로 투 원을 만든다는 건 어떤 경험일까? 특히 신제품을 만들어가는 팀에 처음부터 합류해 제품을 처음부터 끝까지 함께 만들었다는 점은 올해의 큰 경험이자 무언가에 깊게 몰두할 수 있었던 기회였다.'신제품팀'은 '스타트업' 이라고 생각한다. 프로세스가 정해져 있는 팀이 아니라, 프로세스 자체를 만..
해커톤에서 TPO를 한 후기
·
💬 회고
0. 내가 해커톤에 참여한 이유안드로이드 개발자로 일하면서 항상 느꼈던 것이 있다.나는 단순히 코드를 구현하는 개발자가 아니라, 비즈니스 전반과 본질적인 문제를 이해하고 해결하는 사람이 되고 싶다는 것이다. 평소에 비즈니스, 기획, 의사결정 흐름 전반에 관심이 많았고 언젠가는 제품 영역과 기술 영역을 모두 깊이 있게 이해하며 제품 방향성과 기술적 실행을 동시에 리드하는 역할인 TPO(Technical Product Owner) 을 해보고 싶었다.이번 해커톤은 나에게 단순한 행사 참여가 아니라, ‘내 아이디어로 사람들을 설득하고, 제품을 설계하고, 실현까지 해보는’ 것을 검증하고 실현시키기 위함이었다. 게다가 두 팀에게 먼저 함께하자는 제안까지 받으며 감사하면서도 더 큰 책임감을 느꼈다.함께하게 된 팀원들..
서버에서 문자열로 넘어온 날짜가 Date로 잘 매핑되는 이유
·
🐸 Android
안드로이드 개발을 하다 보면 서버에서 날짜를 문자열로 보내주고, 클라이언트에서는 이를 Date 타입으로 받는 경우가 종종 있다.예를 들어, 서버에서 아래와 같은 JSON 응답을 보낸다고 해보자{ "id": 1, "drinkDate": "2025-06-07", "title": "Meeting"} 클라이언트에서는 다음과 같은 데이터 클래스로 매핑한다고 가정하자data class UserCalendar( val id: Int, val drinkDate: Date, // 서버는 String, 클라이언트는 Date val title: String) 서버에서는 drinkDate를 String 형태로 보내주고 있음에도 불구하고, 클라이언트에서는 이를 java.util.Date로 받아도 예외 없이..
코틀린 상태 관리, 불변 데이터 중심으로 생각하기
·
💎 Kotlin
0. 가변성과 상태var 같은 읽고 쓸 수 있는 프로퍼티나 MutableList처럼 내부 상태를 변경할 수 있는 객체를 사용하면 `상태(state)` 를 갖게 된다. 상태를 갖는 객체는 단순히 사용 방법뿐만 아니라 그 `이력(history)` 에 따라 동작이 달라질 수 있기 때문에, 프로그램을 이해하거나 디버깅하기 어려워진다. 예를 들어, 은행 계좌의 잔액을 나타내는 balance라는 상태 값이 있다고 하자. 사용자가 출금하거나 입금할 때마다 이 값은 바뀌고, 특정 시점의 balance 값은 과거에 어떤 동작들이 있었는지에 따라 결정된다. 이런 구조에서는 단순히 현재 코드만 봐서는 전체 동작을 예측하기 어렵다.또 다른 예시로, 필터 기능을 개발한다고 하자. 가격 필터, 출시순 필터, 지역 필터 등이 있고..
값과 참조로부터 시작하는 얕은 복사 깊은 복사
·
💎 Kotlin
1. 값과 참조여기 var a = 2 가 있다. 개발자에게는 단순히 변수 a에 숫자 2를 넣는 것이지만, 컴퓨터는 이것을 메모리에 어떤 공간을 할당하고, 그 공간에 값을 저장하는 것으로 인식한다. 변수 앞에 붙는 선언 키워드로 이 변수는 어떤 성격을 가진다라는 힌트를 컴파일러에게 준다. 컴퓨터는 변수에 값을 할당할 때 두 가지 방식 중 하나로 처리한다.값(value)으로 할당: 실제 데이터를 그대로 저장참조(reference)로 할당: 데이터가 있는 메모리 주소만 저장왜 분리했을까? 모든 데이터를 값으로 저장하면 메모리 사용량이 폭발적으로 증가한다. 이를 해결하기 위한 방법으로 '변하지 않는 값은 한 번 고정을 해놓고 참조를 하게 하자' 로 풀기 시작하였다. 메모리의 입장에서는 한 군데만 차지하면 되기 ..
[Gradle] Android Gradle Plugin과 Gradle 기본 생성 파일
·
🐸 Android
0. IntroGradle 은 빌드도구이다. Java, Kotlin, Python 등 내가 작성한 소스 코드들을 컴파일하고 실행 가능한 파일로 만들어주는 기본적인 빌드 수행을 한다. 하지만 Android 앱 빌드에는 특수한 작업들이 필요하다.예시는 아래와 같다.Android 앱은 `.apk` 또는 `.aab` 형식으로 패키징해야 한다.`.class` 파일을 Android의 `Dalvik(ART)` 실행 환경에서 사용할 수 있는 `.dex` 파일로 변환해야 한다.res/layout.xml, res/drawable/ 같은 Android 리소스를 빌드 과정에서 최적화해야 한다.`AndroidManifest` 에 선언된 앱 정보, 권한, 컴포넌트 설정을 Gradle과 연동해야 한다.빌드 변형 (`Build ..
[Gradle] Java Versions in Android Builds
·
🐸 Android
0. IntroWhether your source code is written in Java, Kotlin, or both, there are several places you must choose a JDK or Java language version for your build.- Android Developers Document우리는 앱 빌드를 위해 JDK 또는 Java 언어 버전을 여러 곳에서 선택해야한다.  `compileOptions` 와 `kotlinOptions` 을 이용하여 Java 버전과 `JVM` 버전을 설정해주는 과정을 먼저 살펴보고, Kotlin과 Java 소스코드가 Gradle 빌드 도구로 JDK 실행환경에서 작동하는 과정을 정리한다. 또 `Gradle JDK`는 어떻게 정의될 수..
[Android] Convention Plugin
·
🐸 Android
0. Convention Plugin멀티 모듈을 적용해나가고 있는 우리팀의 프로젝트 특성상, 모듈마다 공통적으로 작성해야하는 설정들이 있다. build types 이나 compile options 설정 등 보통 동일하게 설정들이 있는데 각 모듈을 생성할 때마다 똑같이 작성해야하는 수고로움이 있다.Convention Plugin은 주로 buildSrc 디렉터리나 별도의 Gradle 플러그인 모듈에서 정의되며, 모듈마다 동일한 설정을 반복하지 않아도 되도록 도와준다. 즉, Gradle에서 반복적인 설정을 캡슐화하여 프로젝트의 공통 규칙을 관리하는 방법이다. 이 블로그글은 적용 방법보다 Convention Plugin을 적용하면서 코드적인 이해를 돕고자 작성했다. 1. Gradle Kotlin DSL 설정 파..
[Hilt] 타입과 의존성
·
🗡️Hilt
Hilt는 타입으로 의존성을 구분한다.의존성이 Hilt 컴포넌트에 바인딩될때, 의존성을 식별할 수 있는 식별자로 class의 패키지명을 포함하고 있는 canonical name을 식별자로 쓰고있다. 어떤 의존성이 컴포넌트에 바인딩이 되고 바인딩된 의존성을 클라이언트가 컴포넌트에 요청할 때 정확하게 구분하고 수행할 수 있는 이유는 어노테이션이 마킹된 위치에 해당 의존성 타입이 명시되어 있기 때문이다.  그렇다면 동일한 타입이 두 번 바인딩될 경우는 어떻게 될까?Hilt입장에서는 클라이언트가 의존성을 요청할 때 어떤 의존성을 주입을 해야할지 모른다. 컴파일 타입에 object 그래프를 점검하고 중복 바인딩 문제가 있는 경우 컴파일을 중단한다. 그리고 DuplicateBindings 이라는 중복 바인딩 에러가..