데일리베이비 출시 후 회고 — 1초 육아기록에 집착한 이유
목차
출시는 완성이 아니라 시작이었다
지난겨울, 다섯 편에 걸친 육아앱 개발기 시리즈의 마지막 글을 이렇게 마무리했습니다. "사이드 프로젝트의 가장 큰 가치는 완성에 있다"고. 그 문장을 지금도 믿지만, 이제는 절반만 맞는 말이었다는 것을 압니다. 스토어에 앱을 올리는 것은 완성이 아니라 시작이었습니다. 데일리베이비 1.0을 출시하고 반년 가까이 지났고, 버전은 어느새 2.9가 되었습니다. 이 글은 개발기가 아니라 운영기, 그러니까 출시 버튼을 누른 뒤에야 알게 된 것들에 대한 회고입니다.
출시 직후의 현실은 개발 중에 상상하던 것과 꽤 달랐습니다. 심사 통과 메일을 받고 잠깐 들떴다가, 곧바로 크래시 리포트라는 것을 처음으로 받아보게 됩니다. 시뮬레이터와 제 손에 있는 기기 몇 대에서만 돌던 앱이, 제조사도 OS 버전도 화면 비율도 제각각인 실제 기기들 위에서 돌아가기 시작하면 개발 중에는 한 번도 본 적 없는 방식으로 깨집니다. 특정 제조사의 공격적인 배터리 최적화 때문에 백그라운드 동작이 죽는 문제, 생각지도 못한 화면 비율에서 플로팅 바가 시스템 UI와 겹치는 문제 같은 것들은 전부 출시 후에야 그 존재를 알게 됐습니다.
그래서 출시 후 첫 몇 주는 새 기능의 시간이 아니라 수습의 시간이었습니다. 이 시기에 Expo의 OTA 업데이트가 정말 큰 역할을 했습니다. 스토어 심사를 기다리지 않고 자바스크립트 레벨의 수정을 바로 내보낼 수 있다는 것은, 밤에 발견한 버그를 다음 날 아침 수유 시간 전에 고쳐서 배포할 수 있다는 뜻이기도 했습니다. 시리즈 1편에서 OTA를 장점으로 꼽긴 했지만, 그 가치를 몸으로 이해한 것은 출시 이후였습니다.
버전이 2.x대로 넘어오면서는 나름의 리듬이 생겼습니다. 직접 쓰면서 불편한 것을 고치고, 리뷰와 문의로 들어온 피드백을 다음 버전에 반영하고, 그 사이 Expo SDK 54까지 따라 올라오면서 기반을 다지는 일의 반복이었습니다. 화려한 기간은 아니었지만, 시리즈에서 자신 있게 써 내려갔던 설계들이 실제 사용자를 만나 검증받은 기간이었습니다. 어떤 가설은 살아남았고, 어떤 예상은 기분 좋게 빗나갔습니다. 하나씩 정리해 보겠습니다.
2. "1초 기록"이라는 집착은 검증됐을까
데일리베이비에는 기획 단계부터 지금까지 한 번도 바뀌지 않은 원칙이 하나 있습니다. 수유, 기저귀, 수면 기록은 어느 화면에 있든 탭 한 번으로 시작할 수 있어야 한다는 것입니다. 홈이든 캘린더든 통계 화면이든 하단에는 항상 플로팅 퀵액션 바가 떠 있고, 버튼을 누르는 순간 기록이 만들어집니다. 앱 이름 옆에 붙여둔 "1초 육아기록"이라는 문구는 마케팅 카피이기 전에, 개발 내내 스스로를 다잡던 제약 조건이었습니다.
왜 그렇게까지 집착했나
이 집착의 근거는 단순합니다. 새벽 세 시의 수유 장면을 떠올려 보면 됩니다. 왼팔로는 아기를 안고 있고, 방은 어둡고, 쓸 수 있는 것은 오른손 엄지 하나뿐입니다. 이 자세에서 수행할 수 없는 UX는 사실상 존재하지 않는 기능과 같습니다. 날짜를 고르고, 수유 방식을 고르고, 양을 입력하고, 저장 버튼을 누르는 네 단계짜리 폼은 낮에는 아무 문제가 없지만 새벽에는 통과할 수 없는 관문입니다. 그리고 기록 앱은 한 번 거르기 시작하면 빠르게 무너집니다. 기록이 이틀 비면 통계가 의미를 잃고, 통계가 의미를 잃으면 앱을 열 이유가 사라집니다. 기록 앱의 진짜 경쟁자는 다른 앱이 아니라 **"그냥 기록하지 않기"**라는 것이 저의 오랜 가설이었습니다.
그래서 입력을 요구하는 대신 스마트 기본값으로 빈칸을 채웠습니다. 수유 버튼을 누르면 마지막 수유량이 그대로 들어가고, 참고할 이전 기록이 없으면 월령별 추천 수유량이 들어갑니다. 수면은 탭 한 번으로 타이머가 시작되고 다시 탭하면 종료됩니다. "일단 저장하고, 수정은 나중에 해도 된다"는 순서의 역전이 이 설계의 핵심입니다.
퀵 기록의 기본값 결정 (수도코드):
수유 버튼 탭:
IF 마지막 수유 기록 있음 → 양과 방식을 그대로 복사
ELSE → 월령별 추천 수유량 테이블에서 조회
즉시 저장 + 실행취소 스낵바 노출
수면 버튼 탭:
IF 진행 중인 수면 없음 → 타이머 시작
ELSE → 타이머 종료 + 기록 확정
반년이 지나서 확인한 것
결론부터 말하면, 이 철학은 검증됐다고 생각합니다. 제가 직접 반년을 썼고, 아내가 썼고, 스토어 리뷰와 지인들의 피드백에서도 "기록이 빨라서 계속 쓰게 된다"는 취지의 반응을 반복해서 확인했습니다. 흥미로운 것은 정확성에 대한 걱정이 기우였다는 점입니다. 설계 당시에는 기본값으로 대충 저장된 기록이 쌓이면 데이터가 지저분해지지 않을까 걱정했는데, 실제로는 반대였습니다. 20ml쯤 어긋난 기록이라도 존재하는 기록이, 정확하지만 존재하지 않는 기록보다 압도적으로 가치 있었습니다. 육아에서 필요한 것은 개별 기록의 정밀도가 아니라 기록의 연속성에서 나오는 패턴이기 때문입니다.
진짜 병목은 폼이 아니라 앱 실행이었다
다만 운영하면서 새로 알게 된 것이 있습니다. "1초 기록"의 마지막 병목은 입력 폼이 아니라 앱을 여는 행위 그 자체였습니다. 잠금 해제, 앱 아이콘 찾기, 스플래시, 화면 복원. 폼을 아무리 줄여도 이 앞단의 몇 초는 남습니다. 그래서 출시 때부터 있던 홈 화면 위젯의 역할을 운영하면서 다시 평가하게 됐고, 같은 맥락에서 Siri 단축어 지원을 더했습니다. 위젯에서 바로 기록을 시작하고, iOS에서는 음성으로 수유 기록을 남길 수 있습니다. 야간모드 역시 같은 철학의 연장입니다. 새벽의 밝은 화면은 그 자체로 기록을 포기하게 만드는 마찰이기 때문입니다.
물론 전부 계획대로 통한 것은 아닙니다. 마지막 기록이 다음 기록의 좋은 예측이 되지 못하는 경우가 있습니다. 모유와 분유를 오가는 혼합수유가 대표적입니다. 그리고 아기를 재우다 같이 잠들어버려서 수면 타이머가 아침까지 돌아가 있는 문제는, 몇 차례 보완을 거쳤지만 지금도 완전히 우아하게 풀지 못했습니다. 이런 엣지 케이스를 하나씩 다듬는 것이 2.x 업데이트의 상당 부분을 차지했습니다.
3. 예상하지 못한 사용 패턴: 임신에서 육아로 이어지는 기록
출시 전의 저는 데일리베이비를 "아기가 태어난 날부터 쓰는 앱"이라고만 생각했습니다. 저 자신이 그렇게 시작했기 때문입니다. 그런데 운영을 하다 보니 예상 밖의 패턴이 보였습니다. 아기가 아직 태어나지 않은 사용자들, 그러니까 출산을 준비하면서 미리 육아앱을 깔아두는 예비 부모들이었습니다. 생각해 보면 당연한 일입니다. 출산 준비물 목록에는 아기띠와 젖병만 있는 것이 아니라 "육아앱 정하기"도 들어 있고, 정작 태어난 직후의 정신없는 시기에는 새 앱을 고르고 익힐 여유가 없습니다. 앱을 고르는 시점과 앱을 본격적으로 쓰는 시점이 다르다는 것을, 저는 출시 후에야 배웠습니다.
그래서 2.x 버전에서 가장 크게 투자한 영역이 임신모드였습니다. 출산예정일을 입력하면 앱이 임신 주수를 계산해 주고, 산모의 체중과 증상 같은 임신 기록을 남길 수 있습니다. 그리고 아기가 태어나면 출산 완료 버튼 하나로 육아모드로 전환됩니다. 이 전환에서 가장 신경 쓴 것은 기록의 연속성입니다. 임신 중의 기록은 삭제되거나 리셋되는 것이 아니라 아카이브로 고스란히 보존되고, 그 위에서 육아 기록이 이어집니다. 열 달 동안 쌓은 기록이 출산과 함께 사라진다면 그것도 일종의 데이터 인질극이라고 생각했습니다.
예정일은 데이터의 씨앗이 된다
임신모드를 만들면서 발견한 즐거운 부수 효과가 있습니다. 출산예정일이라는 단 하나의 값이 앱 전체에 데이터를 미리 심어준다는 점입니다. 대표적인 것이 예방접종 일정입니다. 시리즈 5편에서 다뤘던 예방접종 자동 일정 생성은 원래 아기의 생년월일을 기준으로 동작했는데, 임신모드에서는 예정일을 기준으로 같은 일정을 미리 만들어 둡니다. 출산 전에 "태어나면 4주 안에 BCG를 맞는구나"를 미리 볼 수 있고, 실제 출생일이 입력되면 전체 일정이 그 날짜 기준으로 다시 계산됩니다. 예비 부모 입장에서는 처음 연 앱이 텅 비어 있는 것이 아니라, 이미 자신의 아기를 위한 일정으로 채워져 있는 셈입니다. 빈 화면을 보여주지 않는 것이 온보딩의 절반이라는 것을 이 기능을 만들면서 실감했습니다.
기록의 민감도는 카테고리마다 다르다
임신모드는 가족 공유 설계에도 새로운 질문을 던졌습니다. 육아 기록은 기본적으로 가족이 함께 보는 데이터입니다. 아빠가 기록한 수유를 엄마가 실시간으로 보는 것이 이 앱의 핵심 가치이기도 합니다. 하지만 임신 기록은 결이 다릅니다. 산모의 체중과 몸 상태에 대한 기록까지 초대된 가족 전체에게 기본 공개되는 것이 맞을까요? 저는 아니라고 판단했고, 그래서 카테고리별 공개 설정을 만들었습니다. 체중과 증상 기록은 기본값이 비공개이고, 작성자 본인이 원할 때만 공개로 전환할 수 있습니다.
구현은 시리즈 4편에서 다뤘던 Supabase RLS의 연장선입니다. "가족이면 볼 수 있다"는 단일 규칙에 카테고리라는 차원을 하나 추가한 것입니다.
기록 조회 정책 (수도코드):
IF 요청자 == 기록 작성자 → 허용
IF 요청자가 가족 멤버:
IF 카테고리가 민감 카테고리(체중, 증상):
작성자가 공개로 설정한 경우에만 허용
ELSE → 허용
ELSE → 차단
실시간 동기화는 육아모드와 동일하게 Supabase Realtime을 그대로 탑니다. 남편이 초대를 수락하면 아내의 임신 주수와 공개된 기록이 실시간으로 넘어오지만, 체중 기록은 넘어오지 않는 구조입니다. 접근 제어가 앱 코드가 아니라 데이터베이스 정책 레벨에서 강제되기 때문에, 클라이언트에 실수로 구멍을 내도 데이터가 새지 않는다는 안심이 있습니다. 참고로 가족 초대는 apporbit.xyz/invite 주소를 통한 Universal Links로 동작하는데, 이 딥링크 구현에서 겪은 삽질은 별도의 글로 정리해 두었습니다.
4. 수익화 회고: 구독 대신 광고를 선택한 이유
수익화는 출시 전에 가장 오래 망설였던 결정입니다. 요즘 육아앱의 표준은 구독입니다. 심화 통계와 광고 제거를 묶어 월 구독으로 파는 모델이 이미 검증되어 있고, 매출의 상한만 보면 그쪽이 맞았을 것입니다. 그럼에도 데일리베이비는 AdMob 배너와 보상형 광고 조합을 선택했고, 구독은 넣지 않았습니다. 반년이 지난 지금도 이 결정을 후회하지 않는데, 이유는 세 가지였습니다.
첫째, 육아 기록은 인질로 잡아서는 안 되는 데이터라고 생각했습니다. 아기의 수유 기록과 성장 기록을 쌓게 해놓고 "계속 보려면 결제하세요"라고 말하는 구조는, 사용자였던 시절의 제가 가장 싫어하던 패턴입니다. 기록하고, 돌아보고, 가족과 공유하는 핵심 기능은 끝까지 무료여야 한다는 것이 출발점이었습니다.
둘째, 구독은 약속이라는 점입니다. 매달 돈을 받는다는 것은 매달 그 값을 하는 운영과 개선을 약속한다는 뜻입니다. 본업과 육아를 병행하는 1인 개발자가 그 약속을 몇 년 단위로 지속할 수 있는가에 대해, 저는 자신 있게 그렇다고 답하지 못했습니다. 지키지 못할 약속이라면 처음부터 하지 않는 쪽이 낫다고 판단했습니다.
셋째, 육아앱의 사용 주기는 본질적으로 한시적입니다. 아이가 자라면 기록할 일이 줄어들고, 언젠가 앱을 졸업하는 것이 자연스럽습니다. 짧게 쓰고 떠날 수도 있는 사용자에게 해지라는 숙제를 안기는 것보다, 쓰는 동안 가볍게 광고를 보게 하는 쪽이 이 앱의 생애주기에 맞는 모델이라고 봤습니다.
구조는 단순하게 유지했습니다. 배너는 기록 동선과 절대 겹치지 않는 위치에만 둔다는 원칙을 세웠습니다. 퀵액션 바 주변은 성역입니다. 새벽에 수유 버튼을 누르려다 광고를 잘못 누르는 경험이 한 번이라도 생기면, 그동안 쌓아온 "1초 기록"의 신뢰가 무너지기 때문입니다. 보상형 광고는 심화 분석 같은 일부 부가 기능을 잠금해제하는 용도로만 씁니다. 광고를 볼지 말지는 전적으로 사용자의 선택이고, 보지 않아도 기록에는 아무 제약이 없습니다.
몇 달을 운영해 본 소감을 솔직하게 적으면, 수익은 소박합니다. 광고 모델로 유의미한 돈을 벌려면 결국 규모가 필요하다는 당연한 사실을 확인했을 뿐입니다. 하지만 이 선택 덕분에 환불 문의도, 결제 오류 CS도, 해지 절차도 없습니다. 1인 운영에서 이 단순함은 숫자로 보이는 것보다 훨씬 큰 가치였습니다. 아쉬운 점도 있습니다. 광고 크리에이티브의 밝기까지는 제가 통제할 수 없어서, 야간모드의 어둠 속에서 광고 영역만 환하게 빛나는 순간이 있다는 것입니다. 야간 사용 맥락과 광고 모델이 충돌하는 이 지점은 앞으로도 계속 고민할 숙제로 남아 있습니다.
다음 계획
반년의 운영을 한 문단으로 요약하면 이렇습니다. 검증된 것은 "기록의 마찰을 없애면 습관이 남는다"는 1초 기록 철학, 매일 쓰는 사용자가 개발자 자신이라는 강점, 그리고 OTA와 RLS로 1인 운영의 부담을 덜어준 Expo와 Supabase라는 스택 선택이었습니다. 빗나간 것은 출시가 곧 완성이라는 착각, 사용자가 육아가 아니라 임신에서 시작한다는 사실을 놓친 것, 그리고 진짜 병목이 폼이 아니라 앱 실행이라는 발견이었습니다. 과소평가한 것은 운영 그 자체의 비용입니다. 스토어 정책 대응, 리뷰와 문의 응대, OS와 SDK 업데이트 추종 같은 일들은 기능 개발만큼의 시간을 꾸준히 가져갑니다.
다음 계획은 시리즈 마지막 글에서 적었던 목록에서 크게 달라지지 않았습니다. 다만 우선순위는 운영 경험이 바꿔놓았습니다. 가장 앞으로 온 것은 다국어 지원입니다. 한국어가 하드코딩된 채로 출시한 것을 후회한다고 썼는데, 그 후회는 반년이 지나며 더 커졌습니다. 새벽 수유는 국경이 없는 경험이기 때문입니다. 쌓인 수유와 수면 데이터를 기반으로 한 패턴 분석, 소아과 상담 때 활용할 수 있는 데이터 내보내기도 여전히 유효한 계획입니다. 임신모드가 그랬듯, 다음 기능도 기능 목록이 아니라 실제 사용 장면에서 출발하려고 합니다.
사이드 프로젝트를 스토어에 올려본 개발자라면 공감하실 것입니다. 출시 전에는 코드가 전부라고 생각하지만, 출시 후에는 코드가 절반이라는 것을 알게 됩니다. 나머지 절반은 실제 사용자의 손에서 벌어지는 일을 관찰하고, 가설을 수정하고, 그 수정을 다시 배포하는 순환입니다. 그리고 그 순환을 버티게 해주는 것은 거창한 비전이 아니라, 오늘 새벽에도 제가 이 앱으로 수유를 기록했다는 단순한 사실입니다. 만드는 사람이 곧 쓰는 사람이라는 것. 반년을 돌아보면 결국 그것이 데일리베이비를 계속 나아가게 한 동력이었습니다.
새벽 수유 중에 한 손으로 기록할 수 있는 앱을 찾고 있다면, 데일리베이비를 한번 써보시기 바랍니다. 임신 중이라면 예정일 하나만 입력해도 앱이 먼저 준비를 시작합니다.