안녕하세요, 오늘은 반년정도 사용해오던 배포 CI를 뜯어고친 얘기를 해보려고 합니다.저희 팀은 GitFlow에 가까운 브랜치 전략을 쓰고 있었어요. develop에서 기능을 개발하고, 배포할 때가 되면 release/x.x.x를 파서 버전 코드를 올리고 베이스라인 프로파일과 패치노트를 붙인 다음, main에 머지해서 Play Store로 내보내는 방식입니다. 그리고 마지막에 main을 develop으로 되돌려 반영하는 워크플로가 하나 있었어요.그 마지막 워크플로가 계속 실패하고 있었고 배포과정 자체에 문제가 있는건 아니라서 흐린눈을 하고 있었습니다.얼마나 실패했냐면Sync Main to Develop 워크플로의 실행 이력을 뽑아봤어요. 2026년 1월 4일부터 8월 14일까지 21번 돌았는데요.결과횟수f..

안녕하세요 아키입니다. 지난번에 GMA Next Gen SDK 도입기를 쓰면서 베타 SDK를 붙이느라 겪은 일을 정리했었는데요.그 뒤로 4달 정도 시간이 지났네요. 그동안 GMA SDK는 정식 버전이 됐지만 하이링구얼은 최신버전이 아닌 1.0.1에 눌러앉아 최신 버전을 일부러 안 올리고 있습니다. 이번 글은 그 사이에 무슨 일이 있었는지 정리한 기록이에요. Next Gen SDK 붙일 때 뭘 조심해야 하는지 가늠하는 데 도움이 되면 좋겠습니다. 먼저 한 장으로 요약하면 이렇습니다. 0.25.0-beta01에서 1.0.0으로 올린 건 2026년 4월 23일이에요.특별한 작업은 없었습니다. 베타에서 정식 릴리즈 중 breaking change가 딱 하나 있었는데(AdPreloader.numAdsAvailab..

안녕하세요 아키입니다. 이번엔 Hilingual 프로젝트에 GMA Next Gen SDK를 도입하면서 겪은 일들을 정리해봤어요. 공식 문서를 따라가다 지뢰 밟은 이야기, Compose에 광고를 제대로 녹이기 위해 고민한 이야기, 그리고 혼자 해결 못 해서 Google 엔지니어한테 직접 제보한 이야기를 해보려 합니다. :)왜 하필 베타 SDK였나기존 GMA SDK는 수익화엔 필수였지만 메인 스레드에서 초기화되는 구조 때문에 앱 시작 시간에 영향을 줬어요. 광고 SDK 때문에 앱이 느려지는 건 좀 억울하잖아요?Next Gen SDK는 이걸 구조적으로 해결하려 했습니다. 핵심 변화 세 가지를 꼽자면초기화가 반드시 백그라운드 스레드에서 이뤄져야 하도록 강제해서 ANR을 원천 차단SDK 자체가 Kotlin으로 재..

들어가며얼마전에 레아가 리컴포지션 관련해서 아티클을 공유해주셨어요. 그래서 제가 알고있던 한가지 최적화 기법과 닮아있다고 생각이 들었고 의문이 들었어요. 🤔"도넛 홀 스킵핑이랑 Defer State Read가 결국 같은 말 아닌가?둘 다 '상태를 어디서 읽느냐'의 문제 아님???"직관적으로는 틀린 말이 아니라고 생각해요. 실제로 두 기법의 공통 철학은 "상태를 읽는 위치를 최대한 좁혀라" 이면서 "불필요한 재실행을 줄이는 것." 이라는 목표도 같아요.차이점은 동작하는 레이어가 다릅니다. 목표는 같지만 다른 계층에서 작동하는 두 개의 최적화에 대해서 이 글은 그 차이를 명확하게 짚는 것을 목표로 합니다. 👍🏻1. 전제조건 - Compose의 렌더링 파이프라인두 기법의 차이를 이해하려면 Compose가..

안녕하세요 아키입니다. 오늘은 우테코 미션을 진행하다가 마주쳤던 Compose Preview 렌더링 이슈를 공유해보려 합니다.@Preview(device = Devices.DESKTOP)을 사용하면 텍스트와 경계선이 심하게 흐릿하게 렌더링되는 반면 device = Devices.TABLET으로 바꾸면 훨씬 선명하게 보이는 현상을 겪어본 적 있으신가요? 저는 아래와 같은 경우를 경험했어요.처음에는 또 프리뷰가 말썽이구나 했지만 원인은 코드가 아니라 Android Studio 렌더링 엔진의 스케일링 방식과 기기 프로파일별 DPI 설정의 차이에 있었습니다.원인 분석1. Devices.DESKTOP의 낮은 DPIAndroid Studio의 Compose Tooling에서 정의한 Devices.DESKTOP의 기..

마지막 주를 시작하면서드디어 4주차입니다. 솔직히 마지막 주가 가장 실용적인 주차라고 생각했어요. lateinit이랑 by lazy는 안드로이드 프로젝트에서 거의 매일 쓰는 키워드인데 그냥 "Hilt 필드 주입에는 lateinit, 무거운 연산에는 by lazy" 정도로만 사용해왔습니다. 이번 주차도 디컴파일로 학습을 진행했어요.lateinit과 by lazy, 뭐가 다른가이 둘을 "lateinit은 var에만, by lazy는 val에만" 같은, 사용 상황으로만 구분하는 글은 많지만 바이트코드를 보면 두 개념이 얼마나 다른 방식으로 구현되는지 훨씬 명확하게 드러납니다.lateinit은 그냥 null임Compose 환경에서 lateinit이 가장 자주 등장하는 곳은 Hilt 필드 주입이에요. 생성자 주입..