미라클알람

무엇인가

끄는 버튼이 없는 모닝 알람입니다. 대신 질문이 있습니다. 소리 내어 답할 때까지 알람은 계속 울리고, 실제로 잠을 깨우는 것은 폰을 더듬어 찾는 동작이 아니라 문장을 만들어내는 동작입니다.

스누즈는 없습니다. 긴 스누즈도, 횟수 제한 스누즈도 아닙니다. 스누즈라는 기능 자체를 넣지 않는다는 제품 결정입니다. 나머지 설계가 전부 그 버튼을 없애려고 만들어진 것이기 때문입니다.

왜 이 실험인가

까다로운 건 아이디어가 아니라 플랫폼입니다. 여기서 크로스플랫폼은 선호가 아니라 확정 요구사항입니다. 한쪽 OS에만 있는 알람은 데모에 가깝습니다. 이게 필요한 사람은 이미 갖고 있는 폰을 쓸 뿐, 폰을 골라서 사지 않기 때문입니다.

이 요구사항 때문에 spike로 돌려볼 가치가 생겼습니다. iOS에서는 알람이 살아남아 계속 소리를 내다가 명시적인 지시에만 멈춰야 하는데, 이건 시스템이 허용하는 경계선에 가깝습니다.

어떻게 동작하는가

스택은 Flutter에 자작 네이티브 플러그인 6종(scheduler, presenter, audio, speech, TTS, permissions)이고 공유 코드는 약 65% 입니다. 음성 인식과 음성 합성은 온디바이스 전용 입니다. 서버도, API 비용도 없고, 새벽 6시에 말한 내용이 폰 밖으로 나가지 않습니다.

iOS 쪽을 성립시킨 발견은 구체적이고, 직접 검증했습니다. AlarmKit 알람은 사용자가 커스텀 “Start” 버튼으로 앱을 열어도 계속 울립니다. AlarmManager.shared.stop(id:) 를 명시적으로 호출해야만 멈춥니다. 그래서 잠금화면에는 “Start” 버튼 하나만 두고, 질문은 알람이 울리는 상태 그대로 앱 안에서 진행합니다.

이 사실이 “iOS는 불가능하다”는 이전 결론을 뒤집었습니다. 그 분석이 틀렸다기보다 다른 질문에 답하고 있었습니다. 전 과정이 잠금화면에서 끝나야 한다고 전제했기 때문입니다. 요구사항이 “Start를 누른 뒤 앱 안에서 진행”으로 바뀌자 그 전제 자체가 사라졌습니다.

마지막 질문 — 오늘 가장 먼저 할 일은? — 은 알람이 이미 꺼진 뒤 묻습니다. 선택 사항이고, 답하지 않아도 알람은 꺼진 채로 있습니다. 알람을 다시 울릴 수 있는 질문은 벌에 가깝고, 이건 그런 물건이 아닙니다.

첫 실행 튜토리얼은 설명 없이 실제 알람 화면에서 바로 시작합니다. 사용자가 질문 세 개에 음성으로 답하면 그 답변이 그대로 사용자의 답으로 저장되고, 타이핑 폴백도 같은 자리에서 익히게 됩니다. 알람이 처음 진짜로 울리는 순간에 새로운 것이 하나도 없도록 만드는 구조입니다.

지금 어디까지 왔는가

2026.09 기준 Spike 단계입니다. iOS 핵심 동작은 검증됐고, 설계는 그 위에 서 있습니다.

남은 불확실성이 하나 있고 가볍지 않습니다. AlarmKit의 자동 무음 타임아웃을 Apple이 문서화하지 않았습니다. 실기기에서 직접 측정해야 합니다. 같은 맥락에서 stopIntent는 스와이프 해제 시 호출되지 않는다는 보고가 있어, 알람 종료 감지를 여기에 의존할 수 없고 의존하지 않았습니다.

iOS deployment target은 26.0 이며 백포트할 수 없습니다. 커스텀 질문은 MVP에서 제외했고, Post-MVP의 Pro 해금 후보로 남겨뒀습니다.