Hacker News 2026.06.18 34

웹 기술로 알람 시계를? Capacitor가 건드린 의외의 난제

알람 시계 하나가 왜 흥미로운 프로젝트일까

Show HN에 알람 시계 앱 하나가 올라왔어요. 알람 시계라니, 세상에서 제일 흔한 앱 아니냐 싶죠? 그런데 이 프로젝트가 흥미로운 건 만든 방식이에요. 네이티브(Java/Kotlin이나 Swift) 대신, 웹 기술(HTML·CSS·자바스크립트)을 감싸서 앱으로 만드는 Capacitor로 알람 시계를 구현했거든요. 그리고 사실 이게 생각보다 훨씬 어려운 도전이에요.

Capacitor가 뭐냐면

Capacitor는 아이오닉(Ionic) 팀이 만든 런타임이에요. 쉽게 말하면 우리가 만든 웹 앱을 네이티브 앱 껍데기 안에 쏙 넣어주는 도구예요. 웹뷰(브라우저 화면을 앱 안에 띄우는 부품) 위에서 우리 웹 코드가 돌아가고, 카메라·위치·알림 같은 진짜 네이티브 기능이 필요하면 '플러그인'이라는 다리를 통해 OS 기능을 불러다 쓰는 구조죠. 웹 개발자가 가진 기술 그대로 iOS·안드로이드 앱을 낼 수 있다는 게 가장 큰 매력이에요. 비슷한 친구로는 예전의 코르도바(Cordova)가 있었고, 결이 좀 다른 React Native나 플러터(Flutter)도 같은 크로스 플랫폼 가족이에요.

알람이 왜 어렵냐면

여기서 핵심 질문. '그냥 setTimeout으로 시간 맞춰서 소리 울리면 되는 거 아냐?' 안 돼요. 그게 이 프로젝트의 모든 어려움이 시작되는 지점이에요.

스마트폰 OS는 배터리를 아끼려고, 화면이 꺼지거나 앱이 백그라운드로 가면 그 앱의 코드 실행을 사정없이 멈춰버려요. 심하면 앱을 통째로 종료시키기도 하고요. 그러니 웹뷰 안에서 도는 자바스크립트 타이머는 화면이 꺼지는 순간 같이 잠들어 버려서, 정작 알람이 울려야 할 새벽 7시에 아무 일도 안 일어나요. 알람 시계에서 이건 그냥 버그가 아니라 제품의 존재 이유가 무너지는 치명적 결함이죠.

그래서 제대로 된 알람은 '내가 시간을 재는' 게 아니라 'OS에게 이 시각에 깨워달라고 예약을 거는' 방식으로 만들어야 해요. 안드로이드에선 AlarmManager라는 시스템에 정확 알람(exact alarm)을 등록해요. 최근 안드로이드는 배터리 보호를 위해 도즈(Doze)라는 절전 상태를 두는데, 여기서도 정확히 울리게 하려면 SCHEDULE_EXACT_ALARM 같은 특별 권한을 따로 받아야 해요. iOS는 더 빡빡해요. 백그라운드에서 임의 코드를 돌리는 걸 거의 허용하지 않아서, 보통은 로컬 알림(local notification)을 OS 스케줄러에 미리 등록해 두는 방식으로 우회해요.

결국 이 Capacitor 알람 시계의 진짜 알맹이는 예쁜 웹 UI가 아니라, 이 네이티브 예약 기능을 웹 코드에서 부를 수 있게 이어주는 플러그인 부분이에요. 웹의 편한 개발 경험과 네이티브의 까다로운 제약, 그 사이를 메우는 다리를 잘 놓았느냐가 이 프로젝트의 완성도를 가르는 거죠.

업계 맥락에서 보면

'그냥 PWA(웹앱을 앱처럼 쓰는 기술)로 하면 안 되나?' 싶을 수 있는데, 바로 이 알람이 PWA의 한계를 보여주는 대표 사례예요. 웹 표준만으로는 OS의 정확 알람 스케줄러에 접근할 방법이 없어서, 신뢰할 수 있는 알람은 못 만들거든요. 그래서 Capacitor처럼 네이티브 다리를 놓는 방식이 필요한 거고요. React Native나 플러터도 결국 같은 네이티브 API를 자기 식으로 감싸 쓴다는 점에선 똑같아요.

한국 개발자에게 주는 시사점

웹 개발자가 사이드 프로젝트로 모바일 앱을 내보고 싶을 때 Capacitor는 정말 진입 장벽이 낮은 선택지예요. 다만 이 사례가 주는 교훈은 분명해요. '웹 기술로 만든다고 OS의 제약까지 사라지는 건 아니다.' 알림, 백그라운드 작업, 정확 알람처럼 OS가 깊게 관여하는 기능은 결국 안드로이드·iOS의 동작 방식을 이해해야 제대로 만들 수 있어요. 오픈소스로 공개돼 있으니, 플러그인이 네이티브 알람을 어떻게 부르는지 코드를 뜯어보면 크로스 플랫폼의 경계를 배우기에 딱 좋은 교재예요.