스택노트

AI 코딩 도구 요금제가 6월에 죄다 바뀌었습니다 — 6년차가 안드 개발에 실제 쓰는 조합과 비용

월 $130, 약 18만원. 6년차 안드 개발자인 제가 이번 달 AI 코딩 도구에 실제로 결제한 금액입니다. 6월 요금제 개편 이후로 조합을 싹 다시 짰어요. 솔직히 이번 달 카드값 보고 잠깐 멈칫했네요. 작년 이맘때까지만 해도 깃허브 코파일럿(GitHub Copilot) $10 하나로 버텼는데, 1년 사이에 13배가 된 셈이지요. 근데 다시 줄일 생각은 별로 없습니다. 그만큼 작업 단위 자체가 바뀌었더군요. 2026년 6월 AI 코딩 도구 요금제 개편 정리이번 6월에 한꺼번에 터진 변화가 꽤 많습니다. 안드로이드 개발자한테 직접 영향 가는 것만 추리면 네 가지로 정리되더라고요. 1. 깃허브 코파일럿 Pro ($10/월) 가격은 그대로인데 6월 1일부터 사용량 기반(AI Credits)으로 전환됐어요. ..

안드로이드 배터리 드레인, 밤새 깨어 있던 8시간을 추적한 기록

예전에 출시한 앱 리뷰에 '밤새 30% 빠진다'는 별 1점이 달렸는데요. 제 테스트폰에선 도무지 재현이 안 되더라고요. 그래서 '가짜 밤'을 만들기로 했습니다. dumpsys와 Battery Historian으로 8시간 동안 기기가 깨어 있던 지점을 분 단위로 끊어낸 기록입니다. 같은 리뷰를 받고 막막한 분들이 똑같이 헛돌지 마시라고 정리해두었어요. 안드로이드 배터리 드레인, '가짜 밤'부터 만들기야간 드레인은 책상 위에서 잘 안 잡힙니다. 화면 끄고 충전선만 뽑아둔다고 Doze 모드가 즉시 풀로 들어가지 않거든요. 그래서 adb로 강제로 야간 환경을 흉내 내야 합니다. # 충전 케이블 뽑힌 상태로 위장adb shell dumpsys battery unplug# 내 앱을 사용 빈도 낮은 상태로 표시adb..

SharedPreferences를 DataStore로 옮긴 110ms 사냥 기록

저사양 테스트 폰을 켰는데 스플래시에서 110ms가 그냥 날아갔습니다. StrictMode 로그를 까보니 getBoolean() 한 줄이 메인 스레드를 잡고 있더라고요. 처음엔 "에이, 그래봐야 몇 십 ms겠지" 싶었는데, 막상 저사양 기기에서 측정해보니 체감이 됐어요. 결국 그 한 줄을 추적해 DataStore로 옮겼고, 일부 키는 끝까지 SharedPreferences에 남겼습니다. 그 과정을 정리해봤어요. StrictMode로 잡은 SharedPreferences 메인 스레드 호출Application onCreate에 StrictMode.ThreadPolicy.Builder().detectDiskReads().penaltyLog()를 켜두면 메인 스레드에서 디스크 I/O가 일어날 때마다 logcat..

지난 봄에 채팅 리스트 화면을 한참 들여다보고 있었어요. 데이터가 1만 건쯤 쌓인 계정에서만 스크롤이 툭툭 끊기더라고요. 컴포즈 리컴포지션을 한 시간 넘게 뒤졌는데, 정작 범인은 Room 쿼리 한 줄이었습니다. 증상 분리, UI 지연인가 Room 쿼리 지연인가처음엔 당연히 젯팩 컴포즈(Jetpack Compose) 쪽을 의심했어요. LazyColumn 의 key 가 빠진 건지, remember 자리를 잘못 잡은 건지부터 봤거든요. 근데 시스트레이스(Systrace, 현재는 Perfetto 가 후속) 를 따 보니 메인 스레드는 멀쩡한데 IO 디스패처에서 100ms 가 넘는 블록이 계속 잡히더라고요. 데이터 양에 비례해서 프레임이 떨어지면 사실 UI 쪽보다 쿼리 쪽일 확률이 높습니다. 저 같은 경우엔 DAO..

스택트레이스에 가장 자주 등장하는 클래스가 범인일 거라고 AI는 말합니다. 근데 ANR의 진짜 범인은 보통 '아무것도 안 하고 대기 중인 스레드'에 있지요. 얼마 전에 Play Console 에서 ANR 발생률이 임계 0.47% 선을 슬슬 건드리길래, 클로드 코드(Claude Code) 와 챗GPT 한테 logcat 덤프를 통째로 던져봤습니다. 의외로 빨리 좁혀주는 영역이 있고, 진짜 엉뚱한 방향을 가리키는 영역이 명확히 갈리더라고요. 6년차 안드로이드(Android) 개발자 입장에서 "AI 한테 먼저 읽혀도 되는 자리" 와 "절대 그러면 안 되는 자리" 를 나눠봤습니다. AI 크래시 로그 분석, 토큰 빈도 오진이 가장 큰 함정AI 가 스택트레이스를 읽는 방식은 결국 토큰 빈도 기반입니다. Activit..

OOM 났다고 -Xmx 를 올리면 빌드가 오히려 더 잘 죽습니다. CI 러너에선 힙을 줄여야 살아나는 경우가 훨씬 많더라고요. 지난 봄에 사이드 프로젝트를 깃허브 액션(GitHub Actions) 으로 옮기면서 제대로 한 번 데인 적이 있어요. 로컬 32GB 머신에선 멀쩡히 도는 안드로이드 멀티 모듈 빌드가, 깃허브 액션 기본 러너만 올라가면 어김없이 죽더라고요. 로그엔 "Daemon disappeared unexpectedly" 한 줄, 그리고 exit code 137. 처음엔 당연히 메모리가 부족한가 싶어서 org.gradle.jvmargs=-Xmx5g 로 올렸는데, 그게 사고의 시작이었습니다. Gradle OOM 진단, exit code 137 과 JVM OOM 은 다른 문제이게 가장 중요한 분기점..

예전에, 친구가 운영하던 1인 앱 프로젝트의 업로드 키스토어(upload keystore) 가 노트북 SSD 사망과 함께 통째로 날아간 적이 있어요. 그때 제가 옆에서 같이 복구 절차를 밟았는데, 새벽에 깃허브 단톡방에 "키 날아갔다 어떡하지" 메시지가 올라왔던 게 아직도 생생하네요. 다행히 플레이 앱 사이닝(Play App Signing) 에 가입돼 있었고, 업로드 키 재설정 신청을 넣어 2~3 영업일 만에 다시 배포 라인을 살릴 수 있었습니다. 그 한 주 동안 굴려본 절차와, 같은 사고를 안 겪게 보관 체계를 다시 짠 기록을 남겨둡니다. 재설정이 가능해진 건 분명 다행이지만, 그걸 평소 운영의 기본값으로 잡으면 안 된다는 쪽으로 정리됐어요. 보관을 단단히 해두는 게 여전히 출발점이라고 봅니다. 업로드..

지난 분기 어느 금요일 저녁 7시였습니다. QA 팀장님한테 카톡이 왔습니다. "어제 보내주신 apk 어디 갔어요? 카톡 만료됐는데요." 그때 다시 빌드 돌리면서 결심했습니다. 이번 주말 안에 무조건 갈아엎겠다고요. 카톡 APK 배포의 한계, 단톡방에 쌓이던 정체불명 빌드들가장 큰 문제는 버전 추적이 안 된다는 점이었습니다. 단톡방에 .apk 파일이 한 주에 대여섯 개씩 쌓이는데, QA 분들이 "지금 보는 게 최신 맞나요?" 물어보면 저도 다시 빌드 번호를 확인해야 했어요. 그 확인 작업에만 주 2~3시간이 그냥 녹았더라고요. 카톡 파일은 일정 기간이 지나면 만료됩니다. 회귀 테스트 들어가서 "지난주 빌드 다시 깔아주세요" 요청이 오면, 그 자리에서 빌드를 다시 돌리거나 사내 NAS 를 뒤져야 했지요. 클..

새벽 1시 반, .aab 파일을 플레이 콘솔(Play Console)에 끌어다 놓고 출시 비율 칸에 5를 쳤다고 생각했는데, 화면엔 50이 박혀있더라고요. 그 자리에서 자동화를 결심했습니다. 다행히 출시 직전 검토 화면에서 잡아서 사고로 이어지진 않았는데, 그 순간 식은땀이 흐르는 걸 보면서 "이건 사람 손에 맡길 일이 아니다" 싶었어요. 그 다음 주말에 깃허브 액션(GitHub Actions)으로 옮겨놓은 워크플로를 약 4개월 굴려본 기록을 풀어볼게요. 결과적으로 한 분기 동안 출시 비율 오입력 사고는 0건이었고, 릴리스 1회당 손이 가는 시간은 18분에서 30초로 줄었습니다. Play 콘솔 수동 배포의 함정 — 왜 자동화가 필요했나수동 릴리스는 PR 리뷰를 아무리 빡빡하게 돌려도 마지막 한 발이 사람..

지난주에 태그 묶음 화면 새로 짜는데, 가로 스크롤로 뒤쪽 칩이 잘려나가더라고요. 결국 Compose 1.11 FlexBox API 로 줄바꿈 지점을 통째로 갈아엎었습니다. Row + horizontalScroll 로 칩 12개 깔았더니 생긴 문제QA 검수가 들어왔는데, 가로 스크롤 끝에 숨어 있는 필터 칩 4개를 사용자가 인지 못 한다는 리포트가 올라왔습니다. 화면 폭이 좁은 기기에서는 12개 칩 중 절반이 오른쪽 너머로 사라져 있는 상태였어요. 요구 조건은 단순했습니다. 화면 폭에 따라 자동 줄바꿈, 칩 간격 8dp, 줄 간격 12dp 유지. 말로 풀면 한 줄인데 코드로 옮기는 부분이 매번 발목을 잡았습니다. FlowRow·SubcomposeLayout 으로 우회하던 한계처음에는 FlowRow 를 ..