https://sadturtleman.github.io/Sadturtleman의 개인 블로그입니다. 2026-10-14T02:52:54+09:00 Sadturtleman https://sadturtleman.github.io/ Jekyll © 2026 Sadturtleman /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-10-14T02:30:00+09:00 2026-10-14T02:30:00+09:00 https://sadturtleman.github.io/posts/token-refresh-dispatcher-deadlock/ Sadturtleman

로그인 토큰이 만료되면 알아서 새로 받아 오고 실패한 요청을 다시 보내는 코드를 짜 본 적이 있다면, 처음엔 스무 줄이면 끝난다고 생각했을 것이다. 401이 오면 리프레시 토큰으로 갱신하고, 새 토큰으로 재시도한다. 나도 그렇게 짰다. 그리고 같은 코드에서 석 달 동안 세 번 버그가 났다. 두 번은 레이스 컨디션이었고, 마지막은 앱의 모든 요청이 멈추는 데드락이었다. 이 글은 그 세 번을 순서대로 적는다. 작업한 앱은 RuleUp-ASM/Android다. 안드로이드와 OkHttp 이야기지만 웹에서 axios 인터셉터로 토큰을 갱신하든, 서버에서 커넥션 풀을 쓰든 같은 구조라면 그대로 옮겨 읽어도 된다. 용어 몇 개만 맞추고 가자 용어 이 글에서의 뜻 ...

2026-10-13T22:00:00+09:00 2026-10-13T22:00:00+09:00 https://sadturtleman.github.io/posts/android-apm-3-catalog/ Sadturtleman

빌드에 분석 도구를 붙여 본 적이 있다면 세 가지 걱정을 해 봤을 것이다. 결과가 프로젝트 전체를 다 본 결과인지, 그 도구 때문에 평소 빌드가 느려지거나 깨지지는 않는지, 도구가 중간에 실패하면 무엇이 남는지. 린트든 테스트 커버리지든 의존성 그래프든 같은 걱정이다. 2편에서는 Kotlin 컴파일러 안에서 화면을 찾는 방법을 설계로만 적었다. 오늘 레포에 그 설계를 구현한 PR #4가 들어갔다. 이번 글은 구현하면서 위의 세 걱정에 각각 어떻게 답했는지, 그리고 실제 앱 하나(37개 모듈)에 돌려서 나온 숫자를 어디까지 믿어도 되는지를 적는다. 안드로이드를 몰라도 “빌드 중에 정보를 뽑아 파일로 남기는 도구”라고 생각하고 읽으면 된다. 용어 몇 개만 더 2편의 용어(IR, 등록, UI 진입점, ...

2026-10-13T20:50:00+09:00 2026-10-13T22:26:55+09:00 https://sadturtleman.github.io/posts/android-apm-2-screen-discovery/ Sadturtleman

앱에 화면이 몇 개 있는지 코드만 보고 세어 본 적이 있다면, 생각보다 답이 안 나온다는 걸 알 것이다. 프로젝트에서 Screen 으로 끝나는 함수를 검색하면 숫자는 나온다. 그런데 그 안에는 화면이 아닌 것도 섞여 있고, 이름에 Screen 이 없는 화면은 빠진다. 어떤 화면이 실제로 어디에 등록돼 있는지는 함수 이름보다 호출 관계를 따라가야 보인다. 1편에서 android-apm이 화면 목록을 먼저 만들고 측정을 그 위에 붙인다고 했다. 이번 글은 그 목록을 어떻게 만드는지 다룬다. Kotlin 컴파일러의 FIR과 IR 중 어디서 코드를 읽는지, 왜 굳이 컴파일러 플러그인이어야 했는지, 그래도 모든 화면을 찾을 수는 없는 이유와 그걸 알면서 최대한 많이 찾으려고 정한 규칙을 순서대로 적는다. 웹...

2026-10-13T20:00:00+09:00 2026-10-13T21:00:53+09:00 https://sadturtleman.github.io/posts/android-apm-1-why/ Sadturtleman

“이 화면 왜 이렇게 느려요?”라는 질문을 받으면 보통 이렇게 한다. 앱을 켜고, 그 화면까지 손으로 찾아 들어가고, 프로파일러를 붙여서 한 번 녹화하고, 타임라인에서 그 화면이 뜬 구간을 눈으로 찾는다. 다른 경로로 들어오면 느린지, 다른 기기에서는 어떤지는 그 과정을 다시 반복해야 안다. 화면이 스무 개를 넘기면 “이 앱에 화면이 몇 개고 각각 어디서 들어오는지”부터 바로 답하기 어려워진다. 이 문제를 도구로 풀어 보려고 android-apm 을 만들기 시작했다. 이 시리즈는 그 과정을 기록한다. 1편은 코드보다 먼저, 왜 이걸 만드는지와 다 만들어지면 어떻게 쓰게 되는지를 정리한다. 웹 프론트엔드든 iOS든 “화면이 여러 개 있고, 화면 사이를 오가는 앱”이라면 안드로이드 부분을 자기 플랫폼으...

2026-09-30T13:30:00+09:00 2026-09-30T13:57:16+09:00 https://sadturtleman.github.io/posts/image-latency-is-round-trips/ Sadturtleman

화면에 사진 한 장이 늦게 뜨면 누구나 먼저 “사진이 커서”라고 생각한다. 나도 그랬다. 앱의 마이페이지에서 프로필 사진이 화면이 쓸 수 있게 되기까지 걸린 시간의 78%를 차지했고, 받아 오는 파일은 촬영 원본 1500×2000, 454KB였다. 48dp 동그라미 하나를 그리려고 필요한 픽셀의 100배가 넘는 양을 받고 있었으니 썸네일이 답이라고 확신했다. 썸네일을 준다고 가정하고 실제로 재 보니 p95가 70ms 줄었다. 6%다. 사진 크기를 거의 그대로 두고 요청 경로만 바꿨을 때는 35%가 줄었다. 이 글은 그 사이에서 내가 틀린 지점과, 이미지가 느릴 때 무엇부터 세야 하는지를 정리한다. 작업한 앱은 RuleUp-ASM/Android 이다. 안드로이드 이야기지만 웹이든 iOS든 “API가 ...