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

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]] — 크래시 → 즉시 삭제 패턴

2026년 4월 · 간헐적 단식 앱을 만드는 개발자의 비하인드

아내가 단식을 시작한 지 2주쯤 지났을 때 이런 말을 했습니다. “단식 시작할 때 체중이랑 끝날 때 체중이 알아서 비교돼서 나왔으면 좋겠어.” 저는 그 순간 되게 당연한 얘기라고 생각했는데, 막상 구현하려고 앉으니까 한 달이 걸렸습니다. 그 한 달이 어떻게 흘렀는지 적어봅니다.

“단식하고 살이 빠졌는지 내가 제대로 모르겠어”

아내는 매일 아침 체중계에 올라가는 타입입니다. 근데 그걸 어디 적어두는 건 아니에요. 숫자를 보고 “오 어제보다 0.1 빠졌네” 하고 체중계에서 내려오는 게 끝입니다. 그래서 일주일 전이랑 비교하고 싶어도 비교할 방법이 없습니다. 머릿속에 숫자 7개를 띄워놓고 있기엔 인간의 기억력이 그렇게 신뢰할 만한 물건이 아니거든요.

그래서 체중 기록 기능은 이미 다이어리에 넣어둔 상태였습니다. 매일 한 번 찍으면 그만이니까요. 근데 아내가 원한 건 그게 아니었습니다.

“오늘 16시간 단식한 게 내 몸에 정말 영향을 준 건지, 어제 저녁에 많이 먹어서 원래 무거웠던 건지, 그게 구분이 안 돼.” 이 말을 듣고 아 싶었습니다. 날짜별 체중이 아니라 "이 단식 한 번"이 만들어낸 변화를 보고 싶어하는 거였어요. 오늘 아침 52.5kg였다가 오후 1시에 52.3kg가 되면, 그 0.2는 단식이 만든 숫자니까요.

다른 앱들은 왜 이걸 안 보여줄까

솔직히 저도 궁금했습니다. 간헐적 단식 앱을 만들기 전에 경쟁 앱들을 꽤 돌려봤거든요. 근데 대부분 "오늘의 체중"만 보여줍니다. 체중 그래프를 보여주는 앱은 있는데, 그 그래프는 일 단위예요. 단식을 기준으로 잘라서 보여주는 앱은 제가 본 것 중에는 없었습니다.

이유를 생각해봤는데요, 한 번 구현해보면 압니다. 생각보다 귀찮거든요. 단식이라는 이벤트에 체중을 묶으려면, 단식 시작할 때 체중을 찍어야 하고 끝날 때도 찍어야 하고, 그 두 값을 단식 ID에 연결해서 저장해야 합니다. 앱을 이미 만들어놨는데 이걸 넣으려면 DB 스키마부터 건드려야 해요. 기존 체중 기록이랑 충돌하지 않게 설계도 다시 해야 하고요.

더 큰 이유가 하나 있습니다. 유저가 귀찮아할 가능성이 매우 높아요. 단식 시작 버튼을 눌렀는데 “체중부터 입력하세요” 팝업이 뜨면, 그 순간 “아 됐어” 하고 앱을 닫을 수 있습니다. 단식 앱의 핵심 경험은 "시작 버튼 한 번으로 바로 시작되는 것"이거든요. 거기에 단계를 하나 추가하는 건 생각보다 위험한 결정이에요.

그래서 저도 한참을 고민했습니다.

시작 버튼을 어떻게 건드리지 않고 체중을 받을까

처음에는 아이디어를 세 개 놓고 저울질했습니다.

A안은 단식 시작 확인 다이얼로그에 체중 필드를 하나 더 끼워넣는 겁니다. 원래 “단식을 시작할까요?” 다이얼로그가 뜨는데, 그 안에 체중 입력칸을 하나 더 넣는 거예요. 비워둬도 상관없고, 숫자 하나 찍고 확인을 누르면 단식이 시작됩니다.

B안은 단식을 일단 시작시킨 다음, 타이머 화면 위쪽에 작은 카드를 하나 띄우는 방식입니다. “시작 체중을 기록하면 단식 후 변화를 확인할 수 있어요” 정도의 메시지에 [기록] [닫기] 버튼. A에서 건너뛴 사람한테만 띄우는 2차 기회였어요.

C안은 단식이 끝나고 결과 화면에서 몰아서 받는 방식입니다. “시작할 땐 몇 kg였고, 지금은 몇 kg인가요?” 이렇게요.

처음엔 A+B+C를 다 넣을까 진지하게 고민했습니다. 체중 수집률을 최대한 끌어올리고 싶었거든요. 기능을 만든 이상, 많이 쓰이는 게 낫다고 생각했으니까요.

그러다 어느 날 제가 직접 체감했습니다. 테스트하느라 하루에 단식을 두세 번 시작/중지했는데, 체중 입력을 세 번이나 물어보는 앱이 되니까 저조차도 짜증이 났어요. 아내한테도 써보라고 했더니 표정이 살짝 안 좋았고요. “왜 자꾸 체중을 물어봐?”

그래서 결국 A + C만 남겼습니다. B는 지웠어요. 이미 만들어놓은 StartWeightInputCard.kt 파일을 지울 때 좀 아까웠는데, 유저 경험이 우선이니까요. 시작할 때 한 번, 관심 있는 사람한테만 끝날 때 한 번. 이 원칙으로 정리했습니다.

핵심 원칙: 베네핏을 알려주되 방해하지 않는다. 체중에 관심 없는 유저는 한 번 Skip하면 더 이상 물어보지 않는다.

한 가지 더 신경 쓴 게 있습니다. 시작할 때 체중을 입력한 사람한테만 끝날 때 물어보는 겁니다. 처음에는 “시작 체중이 없어도 끝날 때 두 개 다 입력할 수 있게 해주자” 싶었는데, 그건 사실 회고적으로 찍는 거라 정확도가 낮거든요. “아마 52kg이었을 거야” 하고 찍으면 그 -0.3은 진짜가 아니에요. 그래서 뺐습니다.

시작 다이얼로그 — 프리필 하나가 전부입니다

A안의 다이얼로그는 사실 대단한 UI가 아닙니다. 기존 “단식을 시작할까요?” 확인창에 체중 필드 하나 추가됐을 뿐이에요. 근데 여기 숨은 디테일이 하나 있습니다.

최근 체중이 프리필로 들어갑니다. 어제 아내가 52.5kg을 찍었으면, 오늘 단식 시작할 때 체중 필드에 52.5가 이미 들어가 있어요. 변동이 없으면 그냥 확인만 누르면 됩니다. 0.2kg 달라졌으면 그것만 고치면 되고요.

이게 왜 중요하냐면, 매일 아침 체중계에서 내려와서 앱을 열고 “52, 3, 소수점, 1” 이렇게 한 글자 한 글자 찍는 건 의외로 귀찮거든요. 별것 아닌 것 같은데, 이 귀찮음 때문에 기록이 끊기는 경우가 정말 많습니다. 다이어리 쪽 체중 입력을 만들 때도 같은 방식으로 처리했는데, 확실히 이게 있으니까 기록이 덜 끊겨요.

힌트 텍스트도 짧게 한 줄 깔았습니다. “체중을 기록하면 단식 후 변화를 확인할 수 있어요.” 이 한 문장이 전부예요. 길게 설명하면 아무도 안 읽습니다.

비워두고 확인을 누르면 그냥 단식이 시작됩니다. 아무 경고도 없고, 다음에 다시 물어보지도 않아요. 이게 저한테는 되게 중요한 원칙이었습니다. 한 번 "아니"라고 한 사람한테는 다시 물어보지 않는다. 저도 앱이 자꾸 뭔가를 물어보면 피곤하니까요.

결과 화면의 -0.3kg 셀 — 이 한 칸을 만들려고

그래서 이 글의 주인공이 나옵니다. 단식이 끝나면 결과 화면이 뜨는데요, 그 안에 기록 카드가 네 개 있습니다. 수분, 기분, 체중, 수면. 그중 체중 셀에 보라색 테두리를 둘렀습니다.

왜 체중만 보라색이냐고 물으면, 솔직히 고민이 많았습니다. 네 카드가 다 동등한 정보인데 하나만 시각적으로 강조하는 게 맞나 싶기도 했거든요. 근데 결국 하이라이트를 넣었어요. 이유는 이 칸이 다른 셀들과 다르게 변화량을 보여주는 유일한 칸이기 때문입니다.

수분 1,000ml는 오늘 내가 한 행동이에요. 수면 7.5시간은 어젯밤 내 컨디션이고요. 기분 "좋아짐"도 내 상태예요. 근데 체중 -0.3kg는 다릅니다. 이건 단식이 만들어낸 결과입니다. 시작할 때 52.6이었고 지금 52.3이니까 그 사이에 -0.3이 생긴 거예요. 유일하게 "단식 전과 후"를 비교하는 숫자입니다.

구현할 때 가장 고민했던 건 이 숫자를 어떻게 계산하느냐였습니다. 원래는 날짜 범위로 체중을 조회하던 구조였거든요. "단식 시작일 근처의 체중"과 "종료일 근처의 체중"을 찾아서 빼는 방식이요. 근데 이건 하루에 두세 번 체중을 찍는 사람한테는 부정확합니다. 그래서 fastingId를 체중 엔티티에 연결해뒀습니다. 이 체중은 어느 단식에 속한 시작 체중인지, 종료 체중인지가 DB에 기록돼요. WeightEntity.fastingId, WeightEntity.fastingWeightType. 보이지 않는 두 칸이 이 -0.3을 정확한 숫자로 만들어줍니다.

그리고 변화량의 색깔도 고민했습니다. 처음엔 -가 나오면 초록, +가 나오면 빨강으로 만들 뻔했거든요. 근데 생각해보니 그건 "체중이 빠지는 게 성공, 늘어나는 게 실패"라는 판단을 앱이 내리는 거예요. 근데 단식을 하는 이유가 꼭 감량만은 아니잖아요. 건강 관리일 수도 있고, 근육을 유지하면서 천천히 조절하는 중일 수도 있고요. 그래서 +든 -든 같은 색으로 보여주기로 했습니다. 숫자만 보여주고, 해석은 유저에게 맡겨두는 쪽으로요.

아내가 처음 이 화면을 본 날

기능을 다 만들고 아내한테 테스트를 부탁했습니다. 아내가 그날 저녁부터 16시간 단식을 시작했고, 다음날 점심에 끝났어요. 결과 화면을 보는 순간 “어, -0.3이네?” 하더라고요. 그리고 바로 “근데 이게 진짜 단식 때문이야?” 하고 물었습니다.

솔직히 저도 모르겠다고 답했어요. 0.3kg는 화장실 한 번 다녀오는 양이거든요. 물 한 컵도 0.25kg이고요. 이 숫자가 진짜 지방이 빠진 결과인지, 아니면 그냥 몸 안의 수분이 좀 움직인 건지는 단기적으로는 모릅니다. 하지만 그걸 감안해도 **“오늘 단식이 끝난 시점에 내 체중이 이 정도로 찍혔다”**는 사실 자체가 의미가 있어요. 일주일, 한 달 모이면 그게 패턴이 되니까요.

아내가 그 다음 단식부터 시작 버튼 누를 때마다 체중을 입력하기 시작했습니다. 그리고 일주일쯤 지나서 이런 말을 했어요. “단식을 안 하면 안 찍었을 텐데, 단식할 때마다 찍게 되니까 오히려 기록이 더 정확해졌어.” 이 말을 듣고 저는 속으로 좀 웃었습니다. 제가 의도한 건 체중 변화를 보여주는 거였는데, 부작용으로 체중 기록 습관까지 생긴 거예요.

저도 요새 단식을 꾸준히 하고 있습니다. 이 기능을 넣고 나서 바뀐 게 하나 있는데, 단식이 끝나는 게 예전보다 재밌어졌어요. 예전엔 그냥 “16시간 다 됐네, 뭐 먹지” 였다면, 지금은 “오늘은 얼마나 바뀌었을까” 하고 결과 화면을 먼저 봅니다. 결과 화면을 보려면 체중계를 찍어야 하고, 그러다 보니 하루에 체중을 두 번 찍는 습관이 생겼어요. 자기 몸에 대한 관심이 커지는 느낌입니다.

작은 숫자가 만드는 큰 루프

기능 하나를 길게 설명했는데, 사실 이 -0.3kg 셀을 만든 이유를 한 문장으로 요약하면 이거예요. "다음 단식이 기다려지게 만들고 싶었습니다."

단식은 혼자 하는 싸움이에요. 옆에서 응원해주는 사람이 있는 것도 아니고, 눈에 보이는 상이 있는 것도 아닙니다. 그래서 뭔가 작은 보상이 필요해요. 이 보상이 하루 만에 5kg 빠지는 극적인 결과일 필요는 없습니다. 오히려 그런 숫자가 나오면 의심하게 돼요. 진짜로 효과가 있었던 건지 몸이 뭔가 이상해진 건지 구분이 안 되니까요.

-0.3kg 정도가 딱 좋습니다. 확실한데 과하지 않은 숫자. “오늘 단식이 내 몸에 아주 조금 영향을 줬구나” 하고 납득되는 정도요. 그리고 이 숫자가 다음 단식의 동기가 됩니다. “내일도 해볼까” 하는 마음이 드는 건 이 작은 숫자 덕분이에요.

사실 아직 저희 앱 유저는 많지 않습니다. 마케팅이 약하거든요. 그래도 매일 아내랑 쓰면서 불편한 게 생기면 그날 밤에 고치고 있어요. 이 -0.3kg 셀도 그렇게 나왔습니다. 아내의 한 마디에서 시작해서, 한 달 동안 디자인을 세 번 갈아엎고, B안을 만들었다가 지우고, 그러고 나온 기능입니다.

다 만들고 나서 생각해보니 당연한 결과물인데요, 만드는 동안에는 이게 맞는지 계속 흔들렸어요. 결국 "아내가 쓰기 편한가?"를 기준으로 잡았고, 그게 지금까지 이 앱을 버티게 해주는 유일한 기준입니다.

아쉬운 점

솔직하게 적자면, 아직 부족한 게 있습니다.

2주 이상 쌓인 데이터를 “단식 한 번당 평균 -얼마” 같은 요약으로 보여주지는 못해요. 결과 화면에서 이번 한 번의 변화는 보이지만, “지난 10번의 단식 평균 -0.15kg” 같은 리포트는 아직 없습니다. 이건 다음에 꼭 넣고 싶은 부분이에요.

그리고 이 -0.3kg 셀에 대한 해석이 아직 유저한테만 맡겨져 있습니다. 예를 들어 “이 변화는 주로 수분일 가능성이 높아요” 같은 맥락 설명을 붙이면 오해가 줄어드는데, 그게 아직 없어요. 섣부르게 자동 분석 텍스트를 넣었다가 잘못된 정보를 주는 것보다는 낫다고 생각해서 지금은 숫자만 보여주고 있는데, 언젠가는 맥락까지 넣고 싶습니다.

안드로이드 전용인 건 항상 아쉬운 부분이에요. 아내가 안드로이드를 써서 이쪽부터 만들었는데, iOS 쓰시는 분들한테는 죄송합니다. 혼자서 양쪽 다는 아직 어렵네요.

마무리

기능 하나 설명하는 데 꽤 길게 썼습니다. 근데 이 짧은 -0.3kg 한 줄에 꽤 많은 고민이 들어가 있다는 걸 말씀드리고 싶었어요. 완벽한 기능은 아닙니다. 다만 직접 매일 쓰는 사람이 매일 만지고 있는 기능이고, 불편하면 그날 저녁에 고칩니다. 그게 이 앱의 전부일지도 모르겠습니다.

간헐적 단식을 하고 있는데 “내가 정말 뭔가 하고 있는 건가?” 하는 의심이 드는 분이 있다면, 한번 써보셔도 좋을 것 같습니다. 하루 만에 극적인 변화를 보여주지는 않지만, 단식 한 번 한 번이 내 몸에 어떤 영향을 주는지 작은 숫자로 확인하는 재미가 있습니다.

👉 케톤 — Play Store에서 보기