며칠 전에 스토어에서 리뷰 하나를 발견했습니다. 별 5개에, 제가 한 글자도 못 읽는 언어로 긴 칭찬이 달려 있었어요.

언어 설정이 ru-ru인, 러시아 분으로 추정되는 유저였습니다. 해석기를 돌려봤더니 “쾌적하고 사용자 친화적인 인터페이스와 멋지고 무료이며 미니멀한 기능을 갖춘 훌륭한 앱을 만들어주셔서 정말 감사합니다” 라는 뜻이더라고요.

이 리뷰 하나를 받기까지 대략 한 달 정도가 걸렸습니다. 그리고 그 한 달 동안 저는 러시아어를 한 글자도 더 배우지 않았어요. 대신 좀 많이 오만했다는 걸 배웠고, 앞으로는 유저한테 직접 물어볼 줄 아는 앱을 만들어야겠다는 생각을 하게 됐습니다. 오늘 풀어놓을 이야기는 그 한 달입니다.

발단 — ru-ru 유저들이 연속으로 사라졌어요

W15, W16 주간 analytics 리포트를 보다가 눈에 걸리는 줄이 하나 있었어요. 러시아어 설정 유저들이 연달아 D1에서 이탈했다는 내용이었습니다. 설치 다음날 돌아오지 않은 거예요.

모수가 작은 편이라 통계적으로 유의하다고 말하긴 어려웠습니다. 처음엔 그냥 넘기려 했어요. “우연이겠지” 하고요. 근데 다음날 아침에 커피 마시면서 다시 보니까, 우연치고는 너무 깔끔하더라고요. 같은 주간에 영어나 한국어, 일본어 설정 유저들은 그렇게까지 나란히 빠지진 않았거든요. 유독 러시아어만 깔끔하게 이탈하고 있었습니다.

그래서 한 가지 가설이 머릿속에 떠올랐습니다.

설마, 번역 품질이 엉망인 거 아닐까?

오만한 믿음 — “스킬이 있으니까 괜찮겠지”

이 가설이 불편했던 이유는, 케톤에는 이미 /localize 라는 자체 스킬이 있었기 때문입니다. 새 문자열을 추가하면 22개 언어로 자동 번역해주고, 길이 초과 체크하고, format specifier 정합성까지 맞춰주는 도구였어요. 저는 이 스킬을 꽤 신뢰하고 있었습니다. 스킬 문서에도 "quality gates"라고 적어뒀거든요.

그래서 처음 든 생각은 이거였어요. “러시아어 번역이 이상하면 이미 스킬이 걸러냈을 텐데?”

근데 생각해보면 이게 얼마나 오만한 믿음이었는지 조금만 더 들여다보면 바로 보입니다. 제가 러시아어를 한 글자도 못 읽거든요. 폴란드어도, 힌디어도, 우르두어도요. 검증하는 주체인 저 자신이 결과를 읽을 수 없는데 “스킬이 검증해줄 거야” 라고 믿고 있었던 거예요. 이건 신뢰가 아니라 그냥 외면이었습니다.

한번 확인해보자, 싶어서 검수를 돌려보기로 했습니다.

조사 — 에이전트 23명으로 20개 언어 전수 검수

혼자서는 못 합니다. 저는 러시아어 Б도 못 읽으니까요.

그래서 AI 에이전트를 동원했습니다. 언어별로 네이티브 페르소나를 하나씩 세워서 총 19개 페르소나를 만들었어요. 예를 들면 “파리에 사는 30대 여성, Yuka와 Petit BamBou 같은 건강앱을 일상적으로 쓰는 사람” — 이 페르소나가 프랑스어 strings.xml을 한 줄씩 읽어내려가면서 “이건 어색해요”, “이 문장은 Sie와 Du가 섞여 있어요” 같은 리뷰를 남기는 식이었습니다. 거기에 Play Store 마케팅 카피까지 검수하는 에이전트 3명을 더 붙여서 총 23명.

검수 범위는 app/src/main/res/values-*/strings.xml 20개 + fastlane/metadata/android/*/ Play Store 카피 전수였습니다. 이게 몇 시간이 걸리더라고요. 에이전트들이 병렬로 돌아가는데도, 결과를 취합해서 HTML 리포트로 뽑고 다시 읽고 정리하는 시간까지 하면 하루를 통째로 썼습니다.

그리고 결과가 나왔는데, 솔직히 좀 충격이었어요.

발견 — 한두 곳이 아니었습니다

결과를 요약하면 20개 언어 전부에서 크고 작은 이슈가 나왔습니다. 의학 효능 주장이 원문에 없는데 번역본에 추가돼 있다든지, 브랜드명 "Ketone"이 언어마다 Keton, Cetona, Chetone, ケトン 식으로 제각각 현지화돼 있다든지, 숫자 체계가 한 화면 안에서 데바나가리랑 라틴이 섞여 있다든지… 카탈로그로 정리해보니 언어를 넘나들며 반복되는 패턴이 10가지 정도였어요.

발단이 ru-ru 이탈이었으니 러시아어에서 특히 눈에 띈 것 몇 개만 짧게 짚어보겠습니다.

러시아어에는 "금식/단식"에 해당하는 단어가 크게 두 가지가 있다고 합니다. 하나는 정교회 사순절 같은 종교적 금식, 하나는 건강 목적의 세속 단식이요. 케톤은 세속 건강 앱인데 번역본에는 종교 단어가 여기저기 섞여 있었어요. 러시아 네이티브 페르소나의 리뷰를 읽다가 이런 말을 봤습니다. “건강앱을 켰는데 ‘사순절 시작’ 이라고 적혀 있으면 종교 앱인가 싶을 거예요.” 제가 만든 건 간헐적 단식 타이머인데 러시아 유저는 절반쯤 종교 앱 느낌으로 읽고 있었던 거예요.

그 외에도 러시아어는 굴절 언어라서 과거분사에 성별이 들어간다고 하더라고요. "나는 했다"가 남성형 기본값으로 쫙 깔려 있어서 여성 유저 입장에서는 자기 얘기처럼 안 읽히는 구조였고요. 반말과 존대가 한 앱 안에서 왔다갔다 하는 톤 혼용도 있었습니다. 정책 하나만 먼저 정해뒀어도 막을 수 있던 건데, 그 정책이 없었던 거예요.

실행 — 스킬을 다시 짰습니다

여기서 솔직히 고민이 들었어요. 러시아어만 고치고 끝낼 것인가, 아니면 이 10개 패턴이 앞으로 새 번역에 또 들어가지 않도록 구조적으로 막을 것인가.

후자를 택했습니다. 어차피 다음 번역에도 같은 함정이 반복될 거니까요.

세 가지를 손봤어요.

첫째, 용어집을 대폭 확장했습니다. 원래 .claude/glossary.md 에는 “케토시스는 ketosis로 번역” 같은 의학 용어 9개만 있었어요. 이걸 7개 정책으로 재구성해서, 브랜드명 보호·의학 주장 hedge·종교 단식 용어·톤 일관성·성별 중립·숫자 체계·중복 번역 금지까지 언어별 매트릭스로 담았습니다. 위에서 얘기한 러시아어 이슈들이 여기에 다 들어갔어요.

둘째, /localize 스킬에 Semantic QA 단계를 끼워넣었습니다. 기존 스킬은 "기계적 품질"만 체크했거든요. 길이 초과, format specifier, 중복 키 같은 거요. 여기에 “의미적 품질” 체크를 추가했습니다. 브랜드명이 현지화됐는지, 원문에 없는 의학 주장이 들어갔는지, 남성형 과거분사가 강제되는지 같은 걸 정규식과 에이전트 리뷰로 잡아내는 거예요.

새 /localize 파이프라인은 이런 흐름이 됐습니다.

주황색 부분이 이번에 새로 추가된 단계예요. 나머지는 원래 있던 것들인데 순서랑 범위를 다시 짰습니다.

셋째, /localize-audit 이라는 새 스킬을 하나 더 만들었습니다. 기존 /localize 는 “새 문자열을 번역할 때” 쓰는 증분 도구였어요. 근데 이번에 필요했던 건 “이미 있는 번역을 전수 검수” 하는 역방향 도구였거든요. 그래서 이번에 수동으로 한 작업을 그대로 스킬로 박제했습니다. 다음에 비슷한 의심이 들면 명령어 한 줄로 돌릴 수 있게요.

여기까지 쓰고 나서 v1.1.1 배포를 시도했습니다. 그리고 바로 Play Store API가 거부하더라고요. "폴란드어 제목이 30자 한도를 넘었다"고요. 검수 과정에서 폴란드어 Play Store 제목을 좀 더 자연스럽게 고치다가 속격 굴절 때문에 단어 길이가 늘어나버린 거예요. Semantic QA 끝나고 나서 길이 재검증을 안 한 탓입니다. 이 사고는 또 다른 교훈이었습니다 — “길이는 예전에 통과했으니까 안전” 이라는 가정이 얼마나 위험한지. 결국 “Ketone: Post Przerywany IF” (26자)로 줄여서 재배포했고, v1.1.1은 그렇게 세상에 나갔습니다.

보상 — 2일 뒤의 그 리뷰

v1.1.1 배포가 4월 15일 저녁이었어요. 그 리뷰가 도착한 게 4월 17일이었습니다. 딱 이틀 뒤요.

솔직히 말씀드리면, 이 리뷰와 v1.1.1 업데이트의 인과관계를 증명할 방법은 없습니다. 우연의 일치일 수도 있어요. 이 유저분이 пост vs голодание 이슈를 눈치채고 달라진 걸 체감해서 리뷰를 남긴 건지, 아니면 그냥 어느 날 앱이 마음에 들어서 별점을 준 건지, 저는 모릅니다. 앞으로도 알 길이 없을 거예요.

다만 타이밍이 좀 극적이긴 했어요. 한 달 동안 ru-ru 이탈 6명 붙잡고 씨름하다가, 번역 고쳐서 배포하고, 이틀 뒤에 러시아 유저한테서 첫 5성 리뷰가 온다는 게 말이에요.

답장을 남겨야 하는데 저는 러시아어를 못하잖아요. 그래서 번역기를 띄우고 한국어로 “이 앱을 계속 써주셔서 정말 감사합니다. 앞으로도 잘 부탁드립니다” 같은 말을 적어서 러시아어로 돌렸어요. 돌린 문장을 다시 한국어로 역번역해서 이상하지 않은지 확인한 다음 답글을 달았습니다. 제가 러시아 유저와 나눈 첫 번째 대화입니다. 둘 다 기계 번역으로 대화한 거지만요.

근데 — 왜 러시아어를 지원하냐고요?

이 지점에서 한 번 솔직하게 말씀드리고 싶은 게 있습니다.

러시아어를 한 글자도 못 읽는 제가 왜 러시아어를 지원하고 있을까요? 아랍어도요. 힌디어, 우르두어, 벵골어, 태국어, 베트남어도 마찬가지예요. 1인 개발자가 22개 언어를 깔아두는 게 무리수라는 건 저도 압니다. 이번 같은 사건이 일어날 수밖에 없는 구조거든요.

근데 저는 인디 개발자니까요. 한국어랑 영어만 지원하면 타겟 시장이 좁아도 너무 좁아요. 반대로 22개 언어를 깔아두면 이론적으로는 세계 어디서든 접속해서 쓸 수 있는 앱이 됩니다. 마케팅 비용 0원짜리 앱한테는 이 "어디서든 쓸 수 있다"는 게 꽤 중요한 레버예요. 지난 주에 첫 유입이 생긴 국가가 몇 개 더 늘었거든요.

완벽하지 않은 걸 압니다. 아직 제가 못 읽는 언어의 번역본에 어떤 이슈가 남아있는지 다 모릅니다. 이번에 10개 패턴을 잡았지만 11번째 패턴이 또 있을 거예요. 그래도 AI 에이전트라는 도구가 손에 쥐어진 이상, 주어진 도구를 끝까지 써서 할 수 있는 데까지는 해보자는 쪽입니다. 23명 페르소나 세워서 검수 돌리고, 결과 보고 스킬 업그레이드하고, 다시 배포하고. 이번에 한 게 그 과정이었어요.

배운 것 — 데이터만 보면 추측밖에 못 합니다

이번 사건에서 진짜로 배운 건 따로 있습니다.

ru-ru D1 이탈 6명이라는 데이터는 "뭔가 문제가 있다"까지는 알려줬어요. 하지만 “왜” 는 끝내 알려주지 않았습니다. 제가 번역 품질을 의심한 건 데이터가 알려준 답이 아니라 저의 추측이었어요. 맞았을 수도 있고, 틀렸을 수도 있습니다. Бегун=Бегун 중복을 본 979fbfe8 유저가 진짜로 그 화면 때문에 나갔는지, 아니면 그냥 잊어버린 건지, 지금도 모르거든요.

데이터만 보고 “아마 이것 때문일 거야” 라고 추측해서 한 달 동안 에이전트 23명 동원하고 스킬 세 개 고치는 건 좀 가성비가 떨어집니다. 추측이 틀렸으면 이 한 달은 그냥 헛수고였을 거예요. 러시아 유저한테 “혹시 번역이 이상한가요?” 라고 한 번만 물어볼 수 있었다면, 하루 만에 답이 왔을 텐데 말이죠.

그래서 다음에 배포할 기능이 이거입니다.

다음 배포 — 유저한테 직접 물어볼 수 있는 채널

다음 버전에서 더보기 화면 상단에 “당신의 한마디가 필요해요” 라는 카드를 하나 추가하려고 합니다. 탭하면 모달이 올라오고, 자유 입력 텍스트 필드와 선택 이메일, 그리고 번역·버그·제안·칭찬 네 가지 카테고리 칩이 뜨는 간단한 폼이에요. 제출하면 Firestore의 feedback 컬렉션에 그대로 쌓입니다.

로그인 없어도 되고, 이메일도 선택 입력이에요. 그냥 유저가 "이 번역 이상해요"라고 한 문장 툭 던지고 앱으로 돌아갈 수 있으면 됩니다. 제가 Firebase 콘솔에서 읽고, 번역기로 번역해서, 필요하면 답을 남기는 식으로 운영할 생각이에요.

이게 있었으면 이번 한 달 중 적어도 절반은 아꼈을 거라고 생각합니다. 러시아 유저 중 한 명이라도 “이거 종교 앱 같은데요?” 라고 한 줄만 남겨줬으면 제가 거기서부터 팠을 거예요. 데이터만 보고 추측하는 대신요. 그리고 네이티브 스피커가 번역 오류를 지적해주기 시작하면, 기계 QA로는 절대 못 잡는 차원의 품질 개선이 열릴 거라고 봅니다. 어떤 문장이 "문법은 맞는데 어색하다"인지, 어떤 단어가 "직역은 맞는데 실제로 안 쓴다"인지는 결국 그 언어를 모국어로 쓰는 사람만 알거든요.

마치며

한 달 동안 있었던 일을 정리하고 나니 이런 느낌입니다. 한 명의 러시아 유저에게 긍정 리뷰 하나를 받기까지 에이전트 23명이 동원됐고, 스킬 세 개가 갈아엎어졌고, 배포가 한 번 거부당했고, 용어집이 아홉 배쯤 커졌습니다. 효율로 따지면 말이 안 되지만, 인디 개발자한테는 리뷰 하나가 꽤 큰 동력이 됩니다. 그래서 이만큼 한 걸 후회하진 않아요.

다음번에는 추측하지 않는 방법을 만들어둘게요. 유저가 직접 말해줄 수 있는 창을 하나 열어두는 것. 그게 이번 사건에서 제가 얻은 가장 실용적인 교훈이었습니다.

러시아 유저분, 다시 한 번 감사합니다. 답글 러시아어는 번역기가 도와줬지만 마음은 진짜였어요.

👉 케톤 — Play Store에서 보기

Related Documents

• [[retro-localize-skill-gap]]
• [[insight-i18n-cross-language-patterns]]
• [[translation-review-2026-04-14]]
• [[user-feedback-channel]]
• [[spec-user-feedback-channel]]

안드로이드 앱에 오픈소스 라이선스 화면 붙이다 크래시를 두 번 냈습니다

2026년 4월 · 더보기 화면 하나 고치는 데 일주일 걸린 이야기

#안드로이드개발 #오픈소스라이선스 #AboutLibraries #JetpackCompose #인디개발자블로그

인디 앱 개발하시는 분들, 더보기 메뉴에 “오픈소스 라이선스” 항목 하나쯤은 다 있으실 거예요. 제 앱 케톤에도 있습니다. 이게 사실 별거 아닌 화면이잖아요. 앱에 쓴 오픈소스 라이브러리 목록 쭉 뿌려주는 그 흔한 화면.

근데 이 별거 아닌 화면 하나 때문에 최근 일주일을 꽤 시끄럽게 보냈습니다. 크래시를 두 번이나 냈거든요. 한 번은 인기 있는 라이브러리를 고른 탓이었고, 다른 한 번은 최신 버전이 제일 안전할 거라고 믿은 탓이었습니다. 둘 다 제 선택의 결과였고요.

이번 글은 남 탓이 아니라 제 라이브러리 고르는 습관에 대한 반성문에 가깝습니다. 같은 실수 안 하시라고 공유합니다.

첫 번째 삽질 — “제일 유명한 거 쓰면 되겠지”

시작은 이랬습니다. 케톤 더보기 탭에 오픈소스 라이선스 화면을 넣자. 안드로이드 개발자라면 가장 먼저 떠오르는 게 구글이 공식으로 제공하는 play-services-oss-licenses죠. 플러그인 붙이면 빌드 시 알아서 라이선스 목록 만들어주고, Activity 하나 띄워주면 끝. 간단합니다.

저도 그냥 그걸 썼습니다. 별 고민 없이요. “구글 공식인데 뭐 문제 있겠어” 하는 마음으로요.

1
2

// MoreScreen.kt
startActivity(Intent(context, OssLicensesMenuActivity::class.java))

이 두 줄이면 끝납니다. 쉽죠. 릴리즈 때도 잘 돌아갔고, 저도 몇 번 눌러봤는데 라이선스 목록 멀쩡하게 뜨더라고요. 그렇게 한참을 잊고 지냈습니다.

그러다 Crashlytics에 빨간 딱지가 하나 떴습니다

4월 11일이었어요. Crashlytics 들여다보다가 새 Fatal Exception이 하나 올라와 있는 걸 봤습니다.

1
2

OssLicensesActivity.onCreate(): NullPointerException
Attempt to read from field 'java.lang.String nc.b.r' on a null object reference

OssLicensesActivity.onCreate() 안에서 NPE. nc.b.r이 뭔지도 모르겠고 (난독화된 필드명이라 원래 모릅니다), 스택트레이스는 전부 구글 라이브러리 내부였습니다. 제 코드는 한 줄도 안 나와요. 그냥 startActivity로 Activity 띄운 게 전부니까요.

그리고 여기서부터 좀 아팠는데요. 이 크래시를 맞은 분들이 있었습니다. 루마니아 부쿠레슈티에서 신규 유저 두 분이 그날 저녁에 설치를 했어요. 한 분은 온보딩 29초 만에 끝내고 체중 입력하고 단식 타이머 들어가서 56초 탐색하다 크래시. 다른 한 분은 온보딩 스킵하고 단식 바로 시작했다가 화면 탐색 중 크래시. 그리고 두 분 다 크래시 뜨고 2분 안에 앱을 지웠습니다.

물론 그 두 분이 그냥 앱이 별로라서 나갔을 수도 있어요. 근데 하필 크래시 난 2분 뒤에 삭제한 걸 보면… 네, 크래시 때문이었다고 저는 굳게 믿고 있습니다. 앱 자체가 부족해서였다면 더 슬프니까요.

GitHub 이슈를 열어봤더니

혹시나 싶어서 google/play-services-plugins 리포로 가봤습니다. 같은 NPE 스택트레이스 이슈가 있더라고요. #119. 2023년에 올라왔고, 댓글도 여럿 달려있는데, 미해결 상태로 남아있었습니다.

그때서야 라이브러리 릴리즈 페이지를 열어봤어요. play-services-oss-licenses:17.1.0, oss-licenses-plugin:0.10.6. 둘 다 2023년 이후로 새 릴리즈가 없습니다. 이슈는 쌓여있는데 대응이 없어요.

솔직히 좀 놀랐습니다. "구글 공식"이라는 타이틀에 속았다고 하긴 좀 그래요. 정확히는 제가 도입 전에 확인을 안 한 거죠. 라이브러리 페이지 들어가서 마지막 릴리즈 날짜랑 열린 이슈 대충 훑어보는 데 1분도 안 걸리는데, 그 1분을 안 쓴 건 저거든요.

[!note] 교훈 하나
인기 ≠ 활발한 관리. 구글이 만들었든, star가 몇천 개든, 마지막 커밋이 언제인지부터 보자.

그래서 교체하기로 했습니다. 대안으로 유명한 건 AboutLibraries. Compose 친화적이고, 활발히 관리되고 있고, UI도 커스터마이징 가능하고. 좋아 보였어요. 최신 버전이 11.6.3이길래 당연히 그걸 썼습니다.

그러고 나서 두 번째 삽질이 시작됐어요.

두 번째 삽질 — “최신이면 제일 안전하겠지”

AboutLibraries 11.6.3을 libs.versions.toml에 적어 넣고, 플러그인 붙이고, LibrariesContainer 컴포저블 쓰고, Navigation에 LicenseRoute 하나 추가했습니다. 빌드 성공. APK 잘 나오고. 기기에 설치.

더보기 탭 들어가서 “오픈소스 라이선스” 탭. 화면 로딩. 크래시.

1
2
3

java.lang.NoSuchMethodError: No static method FlowRow(
  ...FlowRowOverflow;...
) in class Landroidx/compose/foundation/layout/FlowLayoutKt;

NoSuchMethodError. 이거 보면 대충 감이 옵니다. 컴파일은 됐는데 런타임에 실제 메서드를 못 찾는 거. 뭔가 ABI가 틀어진 거죠. 근데 **FlowRow**가 왜 없어요? Jetpack Compose Foundation에 분명히 있는데?

한참 파봤습니다. 답은 좀 허무한데 이런 구조였어요.

• AboutLibraries 11.6.3은 JetBrains Compose(org.jetbrains.compose) 1.7.3으로 컴파일돼 있습니다. KMP 지원용이에요.
• **JetBrains Compose의 FlowRow**는 FlowRowOverflow라는 파라미터를 추가로 받습니다.
• **Jetpack Compose의 FlowRow**는 그 파라미터가 없어요.
• 제 프로젝트는 순수 안드로이드 — Jetpack Compose입니다.

Gradle은 의존성 해석할 때 JetBrains Compose를 Jetpack Compose로 리다이렉트해줍니다. 그래서 빌드는 성공해요. 근데 컴파일 시점에 라이브러리 코드 안에 박힌 메서드 시그니처는 JetBrains 버전 그대로라, 런타임에 실제 FlowRow를 호출하면 "그런 메서드 없는데요?"가 뜨는 겁니다.

이게 그 유명한 ABI 불일치라는 놈이었어요. 같은 이름 쓰는 두 스택(Jetpack vs JetBrains)이 섞일 때 빌드 성공이 런타임 호환을 보장하지 않는다는 거.

버전을 쭉 내려봤습니다. 11.2.3이 Jetpack Compose로 컴파일된 마지막 안정 버전이더라고요. 내리고 실행. 조용. 라이선스 화면이 얌전히 뜹니다. KetonTheme 색상까지 잘 적용돼서요.

[!note] 교훈 둘
최신 버전이 항상 안전한 건 아니다. 특히 같은 이름(“Compose”)을 쓰는 두 스택이 섞일 수 있는 라이브러리라면, 내 프로젝트 스택이랑 맞는 버전이 따로 있는지 확인하자.

이 두 번째는 사실 진짜 깊은 함정이었어요. 라이브러리 README 어디에도 "KMP 버전이라 Jetpack Compose 프로젝트에서는 11.2.3 쓰세요"라고 안 적혀있거든요. 그냥 “latest version: 11.6.3” 이렇게만 되어 있어요. 그래서 저처럼 최신 버전부터 집어넣는 사람은 한 번은 당합니다. 당한 사람이 저만은 아닐 거예요. 아마도…

그래서 지금은

지금은 AboutLibraries 11.2.3 + Compose 네이티브 UI로 돌아가고 있습니다. KetonTheme 색상도 적용됐고, slideAnimatedComposable로 들어가는 애니메이션도 앱 전체랑 일관되게요. 크래시도 조용해졌고, 더보기 > 오픈소스 라이선스 들어가면 라이브러리 목록이 깔끔하게 뜹니다.

루마니아에서 크래시 맞으셨던 두 분은 이미 앱을 지우고 가셨으니 이제 이 글을 보실 일은 없겠지만, 혹시라도 이 글 보고 계신다면 진심으로 죄송합니다. 그때 제가 라이브러리 한 번만 더 들여다봤으면 그 크래시는 안 났을 텐데요.

다음부터 쓸 라이브러리 선정 체크리스트 (1분 컷)

이번에 아프게 배워서 이제는 라이브러리 고를 때 이거부터 봅니다.

1. 마지막 릴리즈가 언제인가 — 2년 넘게 릴리즈 없으면 일단 한 번 더 생각합니다. 유명세랑 방치는 별개예요.
2. open issues와 PR이 살아있는가 — 이슈는 쌓이는데 답변이 없으면 신호입니다. 특히 크래시 리포트가 방치돼 있으면 피하는 게 좋아요.
3. 내 스택과 호환되는가 — 특히 "Compose"처럼 같은 이름 쓰는 두 스택(Jetpack vs JetBrains)이 있는 영역에서는, 라이브러리가 어느 쪽으로 컴파일됐는지 확인하는 게 중요합니다. dependencies 트리에서 org.jetbrains.compose.*가 transitive로 딸려오면 KMP 쪽 빌드예요.

앞의 두 개는 라이브러리 깃허브 페이지만 열면 30초면 확인합니다. 세 번째는 좀 품이 드는데, ./gradlew app:dependencies | grep compose 한 줄이면 대부분 판별 가능해요. 빌드 성공 ≠ 런타임 호환, 이거 하나만 머리에 넣어두시면 됩니다.

라이브러리 하나 잘못 고른다고 앱이 망하진 않아요. 근데 오늘 봤듯이 첫 세션에서 크래시 맞은 유저는 거의 100% 이탈합니다. 그것도 우리가 손 써볼 틈도 없이요. 그게 무서운 거예요.

저는 이번에 두 번 맞고 배웠는데, 이 글 읽으시는 분들은 한 번도 안 맞으시길 바라면서 마칩니다.

👉 케톤 — Play Store에서 보기

#안드로이드개발 #오픈소스라이선스 #AboutLibraries #JetpackCompose #인디개발자블로그 #Crashlytics #라이브러리선정 #안드로이드크래시 #KMP #ComposeABI

Related Documents

• [[oss-licenses-crash]] — Problem 정의
• [[spec-oss-licenses-crash]] — AboutLibraries 교체 Spec
• [[learn-aboutlibraries-compose-compat]] — ABI 함정 상세 학습 노트
• [[insight-crash-retention-killer]] — 크래시 → 즉시 삭제 패턴