[pill-reminder] 1호 앱으로 '약 복용 알림'을 고른 이유

2026-10-08에 정리한 앱 선정·설계 기록

이미지 출처: Unsplash (라이선스 자유 사용)

핵심 요약

• 3개월 안에 Expo로 안드로이드 앱 4~6개를 출시하고 광고 수익 데이터를 모으기로 했다.
• 주제 10개를 Play Store에서 돌려본 뒤 1호 앱으로 "약 복용 알림" 을 골랐다.
• 포지션은 "심플함 + 광고 적음". 경쟁 앱 상위 리뷰에 광고 과다 불만이 공통되게 보였다.
• MVP는 등록·요일별 반복 알림·복용 체크·히스토리·광고까지. 수익 레이어(IAP, 사업자등록)는 v2에서 결정한다.
• 느슨한 FSD + shared/ 분리로 2호 앱 때 폴더만 복사해도 공통 뼈대가 재사용되게 설계했다.

---

왜 이 글을 쓰나

금액 목표는 두지 않았다. "앱 하나가 터지길 기대하지 않고 여러 개로 확률을 쌓는다"가 전제라서, 첫 3개월의 목표는 "어떤 앱에 사람이 남는지" 라는 데이터 하나다. 그러려면 1호 앱을 어떻게 고르고, 뭘 포기하고, 어떤 뼈대를 세워 두는지가 2호 앱의 속도를 결정한다.

웹 번역기의 아이디어 선정은 아이디어 7개에서 1개로 — 번역기+피드 시작기에 정리했다. 이번 글은 별도로 검토한 안드로이드 앱의 선정 기준과 복약 기능 설계에 집중한다.

---

1. 주제 선정: 10개를 돌려 1개로 좁혔다

구글 플레이에서 찾는 사람은 있는데 상위 앱이 낮은 평점이거나 방치된 주제만 후보에 올렸다. 평가 기준은 세 가지였다.

기준	질문
수요	검색 결과 상위에 다운로드 수가 쌓이는 앱이 있는가
틈새	상위 앱의 저평점 리뷰에 공통 불만이 보이는가
재방문성	하루에 1회 이상 열 유인이 있는가 (광고 노출수 직결)

10개를 돌린 뒤 걸러진 후보 중 "약 복용 알림" 이 세 조건을 모두 통과했다. 특히 저평점 리뷰에 공통으로 보이던 문장이 결정타였다.

*"광고가 너무 많아서 알림만 쓰고 삭제했어요."*

포지션이 비어 있다는 신호다. 틈새가 명확하다.

---

2. 왜 "심플함 + 광고 적음" 포지션인가

약 복용 앱 시장은 플레이어가 많다. 기능으로 이기긴 어렵다. 그래서 반대 방향을 택했다. 기능을 늘리는 대신 광고 수를 줄이고 알림의 신뢰도만 지킨다.

• 타겟은 전연령 범용. 복약은 보편적 상황이라 좁힐 필요가 적다.
• 매일 사용되는 앱이라 적은 광고 노출도 누적되면 수익이 생긴다.
• "광고 적다"는 입소문이 리뷰·평점으로 돌아오면 플랫폼 노출에 복리로 작용한다.

경쟁 열세인 영역에서 "기능 모자람"으로 포지션을 뒤집는 것이 전략의 핵심이다.

---

3. MVP 범위: v1에 넣을 것과 뺄 것

v1은 "심사를 올리는 버전"이다. 넣는 것은 다음과 같다.

• 약 15개 등록, 하루 13회 복용
• 요일별 반복 알림 — expo-notifications 로컬 알림 (영구 무료, 서버·FCM 불필요)
• 복용 체크: 알림 액션 + 홈 버튼 둘 다
• 7일·30일 복용률 히스토리
• 테마 라이트/다크/시스템

광고는 아래 조합(D안)으로 좁혔다.

위치	유형	노출 조건
홈 하단	배너	상시 (유일한 고정 광고)
히스토리 진입	전면	하루 1회 쿨타임
다크 테마 해제	보상형	선택적 (설정에서)

빼는 것: iOS 출시(등록비), 서버 기반 기능, 멀티디바이스 동기화. v1에서는 "하나의 안드로이드 폰에서 완결"이 원칙이다.

---

4. v2 수익 로드맵: 데이터 보고 결정

v2는 출시 1~2개월 뒤 데이터를 보고 넣을지 결정한다.

• 광고 제거 2,900원 (일회성 IAP) + 프리미엄 기능(약 등록 제한 해제 등)
• 전제: 사업자등록. 애드몹 자체는 사업자 없이도 지급되지만, IAP는 사업자 요건이 걸린다.

v1 코드에는 미리 isPremium 훅(현재 false 고정), 광고 모듈의 플래그 체크, 결제 모듈 자리를 비워 둔다. 데이터가 좋으면 v2에서 모듈만 끼우면 되게.

참고: 요금·정책은 2026-10 기준이며 수시 변경 대상이다.

---

5. 아키텍처: 느슨한 FSD + shared/ 분리

핵심 설계 질문은 "2호 앱 때 뭘 복사해 올 것인가" 였다. 복사 단위를 처음부터 폴더로 설계했다.

src/
├── app/            # providers, root navigator
├── pages/          # home, medication-form, history, settings
├── features/       # log-dose, schedule-notifications, compute-adherence
├── entities/       # medication, dose-log
└── shared/         # ui, db, notifications, ads, config  ← 2호 앱 때 폴더 복사

shared/ 안에는 광고·알림·DB·테마 네 개를 격리했다. 2호 앱이 뭐가 될지 모르니, 이 네 가지는 공통일 가능성이 가장 높은 축이다. DB는 expo-sqlite 기준으로 추상화한다.

애널리틱스는 Firebase Analytics 를 쓴다. Spark 티어 범위 안에서 무료, 무제한 이벤트, AdMob 통합이 공식 지원된다 (2026-10 기준).

---

6. 판정 기준: 30일 뒤 숫자로 결정

출시 30일 뒤 설치 수와 매일 쓰는 사람 수(DAU)를 본다. 기준 숫자는 아직 정하지 않았다 — 1호 앱 결과를 본 뒤 정한다. 지금 임의로 정하면 샘플 하나로 틀린 기준을 다음 앱들에 적용할 위험이 있다.

반응이 없으면 그대로 두고 2호로 넘어간다. "앱 하나가 터지길 기대하지 않는다"는 원칙은 매몰비용 억제 장치다.

---

결론 한 줄

1호 앱의 목표는 돈이 아니라 "다음 앱을 더 잘 만드는 데이터"다. 그래서 포지션은 좁고, 뼈대는 재사용 가능하게.

---

후속으로 다룰 내용

• pill-reminder MVP 구현기 — 로컬 알림과 복용 체크 UX
• 공통 템플릿 뼈대 — shared/에 넣을 기능과 앱별로 남길 기능

후속 글의 발행 순서는 아직 정하지 않았다.

관련 글:

• 아이디어 7개에서 1개로 — 번역기+피드 시작기
• Codex와 Claude가 같은 프로젝트를 작업하게 만든 과정

---

※ 본 글의 수치·요금·플랫폼 상태는 2026-10 기준이며, 각 서비스 정책 변경에 따라 달라질 수 있습니다. 특정 서비스에 대한 평가는 특정 관점의 분석이며, 다른 용도에선 다를 수 있습니다.

※ 이 글의 초안 구조화와 교차 리서치 과정에 AI(Claude)를 보조로 활용했습니다. 사실 확인·판단·최종 서술은 필자 책임입니다.