Death Plan Switch: 연락이 끊기면 지정한 순서로 알리기

무엇이 문제인가

혼자 일하는 웹 개발자와 갑자기 연락이 끊기면, 고객의 사이트와 도메인, 호스팅 계정이 어디에 있는지 아무도 모른다. 제작자 Peter Bishop 은 2026년 10월 20일 Hacker News 에 Death Plan Switch 를 Show HNShow HN개발자 커뮤니티 Hacker News 에서 자신이 만든 프로덕트를 소개하는 글. 제목이 "Show HN:"으로 시작한다. 글로 올리며, 2012년에 입원했을 때 기술 담당 동료에게 자료를 제때 넘기지 못해 사업을 잃었다고 했다.

Google 은 비활성 계정 관리자로 비슷한 기능을 제공한다. Google 계정 도움말에 따르면 사용자는 계정이 정해진 기간 동안 비활성 상태이면 최대 10명에게 알리거나 계정 데이터를 공유하도록 설정할 수 있다. Google 은 로그인, 활동 기록, Gmail 사용, Android 기기 접속 같은 신호로 비활성 여부를 판단한다. 비활성 여부를 판단하는 신호도, 공유할 데이터도 모두 그 Google 계정 안에 있다. HN 스레드에서 한 사용자가 비활성 계정 관리자를 언급하자, 제작자는 Death Plan Switch 가 Google 계정에 의존하지 않는다고 답했다.

어떻게 해결했나

Death Plan Switch 는 사용자가 자신의 서버에 설치하는 데드맨 스위치데드맨 스위치사용자가 정해진 기한까지 응답하지 않으면 미리 정한 동작을 실행하는 장치나 프로그램. 열차 운전대의 안전장치에서 나온 말이다.다. 앱은 사용자가 설정한 요일과 시각에 매주 체크인 메일을 보낸다. 사용자가 메일의 링크를 열고 페이지의 버튼을 누르면 그 주의 체크인이 끝난다. 응답이 없으면 본인에게 두 번 더 알리고, 그래도 답이 없으면 가족에게 "Is everything all right?" 하고 묻는다. 가족이 괜찮다고 답하면 다른 연락 대상에게는 아무것도 보내지 않는다. 문제가 있다고 답하거나 답이 없으면, 미리 확인을 받아 둔 연락 대상마다 사용자가 작성해 둔 메시지를 보낸다.

앱은 문서나 비밀번호를 저장하지 않는다. 제작자는 README 에서 메시지에 문서의 위치와 누구에게 연락할지만 쓰고 로그인 정보는 쓰지 말라고 권한다. 앱은 데이터베이스 없이 JSON 파일에 상태를 저장한다. croncron유닉스 계열 서버에서 정해진 시각마다 명령을 실행하는 스케줄러. 실행할 시각과 명령을 crontab 에 적는다. 이 15분마다 앱의 스케줄러를 실행한다. 메일은 SMTPSMTP메일 서버 사이에서, 또는 프로그램이 메일 서버로 메일을 보낼 때 사용하는 프로토콜. 로만 보낸다.

무엇이 다른가

첫째, 사용자가 무사한지 확인하는 방식이 다르다. Google 은 로그인과 사용 기록 같은 신호로 비활성을 추정한다. Death Plan Switch 는 사용자가 매주 버튼을 눌러야만 체크인으로 인정한다. 메일 보안 스캐너가 링크를 미리 열어 볼 수 있어서, 링크를 열기만 해서는 체크인되지 않는다. 트레이드오프는 수고다. 매주 버튼을 눌러야 한다. 또 README 에 적혀 있듯이 메일함에 접근할 수 있으면 누구든 대신 체크인할 수 있다.

둘째, 알리는 순서가 다르다. Google 은 사용자가 설정한 기간이 지나면 알린다. Death Plan Switch 는 본인에게 두 번 알리고, 가족에게 먼저 물은 뒤 72시간을 기다리고 나서야 나머지 연락 대상에게 알린다. 주간 메일은 매주 같은 요일과 시각에 발송되고 메시지는 그 메일의 6일 뒤에 발송되므로, 연락 대상은 늦어도 마지막 체크인 13일 뒤에 알게 된다. 이 순서는 불필요한 걱정을 줄이는 대신, 긴급한 상황에서는 문제가 될 수도 있다.

셋째, 운영 주체가 다르다. Google 의 기능은 Google 이 운영한다. Death Plan Switch 는 사용자가 서버와 cron, 메일 서비스를 직접 운영해야 한다. 그래서 제작자는 README 에서 고객 사이트와 다른 호스팅에 설치하라고 권한다. 앱은 외부 모니터링 서비스가 확인할 헬스 체크 URL 을 제공한다.

무엇이 편해지나

• 고객의 사이트와 도메인을 혼자 관리하는 웹 개발자. 연락이 끊겼을 때 누구에게 무엇을 알릴지 정해 두면, 그 뒤로는 매주 버튼을 한 번 누르면 된다. 오늘은 설치부터 활성화까지 브라우저에서 마쳤다.
• 가족 외의 연락 대상에게 섣불리 알리고 싶지 않은 사용자. 가족이 "All fine" 을 누르는 경로는 오늘 확인하지 못했다.

어떻게 만들었나

• 제작자는 긴 마크다운 기획서를 쓴 뒤 Claude Code 의 도움을 받아 앱을 작성했다고 HN 글에서 밝혔다. 스레드의 답글에서는 기획서를 쓰는 데 이틀이 걸렸다고 했다.
• docs/BUILD-NOTES.md 는 2026년 10월 7일에 기획서의 세 번째 버전을 기준으로 작성됐다. 이 파일에는 기획서에 없던 결정 16개가 이유와 함께 적혀 있다.
• 커밋은 9개(2026-10-09~2026-10-21, 한국 시간)이고 작성자는 Peter Bishop 한 명이다. 첫 두 커밋은 GitHub 웹에서 파일을 올린 것이다.
• 앱의 PHP 코드는 6,378줄이다. PHPMailer 7.1.1 이 저장소에 포함돼 있어 의존성을 따로 설치할 필요가 없다.

실행해 보니

저장소를 클론해 PHP 8.3 내장 서버로 실행하고 아래 순서로 시험했다.

1. 테스트. php tests/run.php 를 실행하자 테스트 45개(어서션 228개)가 11.1초 만에 모두 통과했다.
2. 설치. 첫 단계에서 "The data folder cannot be read from the web" 항목이 실패해 설치가 멈췄다. 내장 서버는 .htaccess 를 읽지 않아, 설치 프로그램이 데이터 폴더에 만든 시험 파일이 브라우저에서 열렸다. README 대로 config.local.php 를 만들어 데이터 폴더를 웹 루트 밖의 경로로 지정하자 설치가 다음 단계로 넘어갔다.
3. 메일과 연락처. 받은 메일을 파일로 저장하는 로컬 SMTP 서버를 연결하고, 테스트 메일의 확인 코드로 설치를 끝냈다. 가족과 기술 담당자를 연락 대상으로 추가하고, 두 사람 앞으로 온 확인 메일의 버튼을 누른 뒤 활성화했다.
4. 리허설. README 의 순서대로 tests/timeshift.php 로 시간이 흐른 것처럼 만들었다. 체크인 메일 뒤 24시간과 48시간에 본인에게 알림, 72시간에 가족에게 질문, 120시간에 가족에게 다시 알림, 144시간에 가족과 기술 담당자에게 메시지가 발송됐다.
5. 링크와 버튼. 스위치가 발동한 상태에서 체크인 링크를 GET 으로 세 번 요청했다. 상태는 FIRED 그대로였고 메일은 발송되지 않았다. 버튼을 누르자 체크인됐다. 가족과 기술 담당자에게는 잘못된 경보였다고 알리는 메일이 발송됐다.
6. 오래 멈춘 스케줄러. 데이터 폴더를 활성화 직후 상태로 복원하고, 400시간이 한 번에 흐른 것처럼 만든 뒤 스케줄러를 실행했다. 주간 메일만 발송됐고, 이후 단계는 그 메일을 기준으로 4번과 같은 간격으로 다시 진행됐다.
7. 토큰. 체크인 링크의 토큰(43자)은 데이터 폴더 어디에도 평문으로 저장돼 있지 않았다. README 에는 링크를 해시로만 저장해 데이터 폴더를 읽어도 링크를 사용할 수 없다고 적혀 있다.

README 에 적힌 단계별 시각과 링크 동작은 실행에서 모두 확인됐다.

$ php tests/timeshift.php 24 --run
Moved on by 24 hours.
- Asked the next of kin.
$ php tests/timeshift.php 48 --run
Moved on by 48 hours.
- Reminded the next of kin.
$ php tests/timeshift.php 24 --run
Moved on by 24 hours.
- The switch fired.
- Sent Kin Person their message.
- Sent Tech Person their message.

확인하지 못한 것

• 가족의 "All fine" 과 "Something's wrong" 버튼. 리허설 중에 가족이 받은 메일의 링크로 두 경로를 확인하자.
• Apache 에서 .htaccess 가 데이터 폴더를 차단하는지와, cron 이 웹 서버와 같은 사용자로 실행되는지 확인하는 검사. 공유 호스팅에 설치해 확인하자.

판정

작동한다. 단계별 메일이 README 에 적힌 시각대로 발송됐다. 다만 서버와 cron, 메일 서비스를 사용자가 직접 운영해야 한다. 그중 하나라도 멈추면 아무에게도 알리지 못한다. 고객의 서버를 혼자 맡고 있고 PHP 호스팅을 따로 운영할 수 있는 웹 개발자가 연락 두절에 대비하는 경우에 써 볼 만하다. 하루 안에 알려야 하거나 서버를 운영하지 않는 경우에는 이 프로덕트는 적합하지 않다.

얻어갈 것

• 사용자가 직접 확인해야 하는 동작은 링크 열기와 버튼 누르기를 구분하자. 오늘 체크인 링크를 GET 으로 세 번 요청해도 상태가 바뀌지 않았다.
• 장애 뒤에 밀린 작업을 한꺼번에 처리하지 않게 하자. 400시간을 건너뛴 뒤에도 메일은 한 단계씩 발송됐다.
• 시간에 따라 동작하는 기능에는 시간이 흐른 것처럼 만드는 시험 도구를 함께 만들자. 6일 동안의 단계를 짧은 시간에 확인했다.