하이링구얼 프로젝트는 규모가 커짐에 따라 오타 수정 같은 경미한 변경에도 빌드 시간이 평균 10분~14분 소요되어 개발 효율이 저하되는 문제가 발생했어요.이를 해결하기 위해 Gradle 설정과 GitHub Actions 워크플로우를 최적화하여 빌드 시간을 1분대로 단축한 과정을 공유해요.1. 병목 원인 분석빌드 로그를 분석한 결과, 성능 저하의 주원인은 두 가지였어요.Gradle 설정 미흡: 병렬 빌드나 캐싱 같은 핵심 성능 옵션이 꺼져 있어 시스템 자원을 효율적으로 쓰지 못하고 있었어요.CI 캐싱 전략 부재: 기존 actions/cache는 Gradle의 복잡한 의존성 구조를 섬세하게 다루지 못해, 라이브러리 하나만 바뀌어도 캐시가 깨져(Miss) 매번 새로 다운로드해야 했어요.2. 해결 방법2.1. ..

안드로이드 개발에서 멀티플랫폼을 사용하지 않는 이상, 대부분의 네트워크 통신은 Retrofit을 기반으로 합니다. 저도 예외는 아닌데요ㅎㅎ 잘 아시다시피 Retrofit은 내부적으로 OkHttp 위에서 동작하고, 토큰 기반 인증 로직을 구현하려면 결국 OkHttp의 특성을 직접 다루게 됩니다.특히 리프레시 토큰을 이용한 토큰 재발급 과정은 단순히 “새 토큰 받아오기”가 아니라 여러 요청이 동시에 들어오는 상황에서의 동시성 문제까지 함께 고민해야 해서 생각보다 까다로운데요... 동시성은 어느 언어든 개발자를 괴롭히네요... 😅이 글은 제가 OkHttp + Retrofit + Coroutines 조합을 사용하면서, Authenticator 안에 runBlocking을 섞어 쓰던 구조를 어떻게 리팩토링했는지..

안녕하세요👋🏻 오랜만에 트러블 슈팅을 가져왔어요ㅎㅎ프로덕션 환경에서 Google 로그인을 사용하던 중 특정 사용자 기기에서 로그인 버튼을 눌러도 아무 UI가 보이지 않는 문제가 제보됐어요. 앱은 멈추지 않았고 크래시도 발생하지 않았으며 에러 로그도 남지 않았어요. 사용자 입장에서는 “아무 반응 없음”으로 보이는 상황이었어요.이 문제는 QA 환경에서는 재현되지 않았고 개발자 기기에서도 동일한 문제가 나타나지 않았어요. 소수의 기기에서만 발생했고 100여명의 안드로이드 유저중에 제보를 받은건 단 2건이었어요🥲원인을 찾기 위해 Credential Manager의 내부 동작 방식을 여러모로 뜯어봤는데요!이 글은 그 과정을 정리한 기록이에요. 저와 같은 현상을 겪으셨다면 스트레스 받지 마시고 해결하시길..1..

열심히 Develop 에서 코드를 짜고 QA까지 통과했다면 릴리즈를 위해서 AAB 를 추출해야겠죠?앞으로 CI/CD로 자동화까지 고려하고 있지만, 기본적인 워크 플로우를 알고있어야 자동화에 문제가 생겨도 핸들링이 가능할테니 차근차근 따라옵시다.1. release/version branch1.1 브랜치 만들기먼저 릴리즈를 위한 커밋을 하기 위해서 develop에서 release/버전명 (예: release/1.0.0) 브랜치를 생성해줍시다.이렇게 만들었다면 브랜치를 이동해주세요!1.2 Baseline Profile 생성하기최신 코드에 맞춰서 Baseline Profile도 업데이트 해줘야 앱 성능에 도움이 됩니다.먼저 빌드 변형(Build Variant)을 release로 변경해줍니다. 그 후에 Andro..

이전 포스팅에서 멀티모듈 설계와 같이 빌드 로직을 설계했었어요. 당시에는 사용하는데에 문제가 없었고 나름 잘 설계했다고 생각했었어요. 이전 방식은(해당 포스팅) feature나 data 같은 아키텍처 레이어별로 미리 만들어둔 플러그인을 적용하는 방식이었어요. 그러나 최근에 baselineprofile처럼 특수한 모듈이 생기면서 문제가 보이기 시작했어요.baselineprofile 모듈을 추가 하면서 테스트 환경에 중복되는 설정을 줄이려고 하니 플러그인을 재사용하기 어려웠어요. 그리고 Hilt가 필요 없는 :core:designsystem 같은 모듈에도 Hilt 설정이 적용되고 있었어요. 그리고 추후에 Proto dataStore 를 적용한다고 가정했을때도 지금의 플러그인을 사용할 수 없었어요. 이번 포스..

시작은 불편함에서..Android 15부터 Edge-to-Edge가 기본으로 적용되면서, 이제 앱의 콘텐츠가 시스템 바 아래까지 확장되는 것이 표준이 되었어요. 덕분에 개발자들은 더 넓은 화면을 자유롭게 사용할 수 있게 되었습니다. 하지만 동시에 디자인에 맞춰 상태 바(Status Bar)의 색상을 화면과 자연스럽게 연결해야 하는 과제가 생겼어요😅저도 이 작업을 진행하면서 고민이 많았어요. 이전에는 systemuicontroller 같은 라이브러리를 사용하면 간단히 해결됐지만 Android 16(Tiramisu)부터 Deprecated 되었고, 더 근본적인 문제가 있었어요.LaunchedEffect나 DisposableEffect 안에서 시스템 바 색상을 변경하는 코드를 호출해야 했는데, 이 방식은 스..