Talorys에서 백업을 가져올 때는 새로 생기는 자동화뿐 아니라 이미 켜져 있던 알림의 다음 실행 시각도 살펴야 합니다. 검토한 소스에서는 백업이 기존 자동화 하나를 일시정지시키거나 전체 시간대를 바꾸면 모든 예약을 다시 잡습니다. 이때 백업에 들어 있지 않은 반복 알림도 다음 실행 시각이 달라질 수 있습니다. 작은 팀의 개인 작업 알림을 옮긴다면, 복원 건수보다 복원 전후의 켜짐 상태·시간대·다음 실행 시각을 비교하는 편이 정확합니다.
확인일: 2026년 10월 16일. 문서·소스 검토 및 AI 조사 지원으로 작성했습니다. 기준은 10월 16일 01:36 UTC의 소스 커밋 19e0ca2입니다. 아래 시간표는 코드에서 도출한 가상 사례이며 앱 설치, 실제 백업 복원, 알림 수신 시험은 하지 않았습니다.
Talorys를 살펴볼 만한 이유
Talorys는 개발자 rociiu가 관리하는 단일 사용자용 AI 비서입니다. 본인의 Cloudflare 계정에 대화·기억·노트·할 일·예약 알림을 배포합니다. 팀 공동 작업 공간은 아니지만, 개발자 개인의 작업 기록과 정기 알림을 한곳에 두려는 용도로 살펴볼 수 있습니다. 개발자에게 데이터를 보내지 않는다는 설명과 별개로, 저장과 모델 처리는 Cloudflare 서비스를 사용합니다.
저장소는 10월 10일 생성됐고, 10월 16일 20:35 UTC에 GitHub 별 1,245개를 확인했습니다. Trendshift의 완료된 날짜별 집계는 10월 14일 +41개, 15일 +138개입니다. 집계 시간대와 정확한 수집 경계는 확인하지 못했으므로 이를 연속 24시간 증가량으로 읽으면 안 됩니다. Hacker News 토론은 확인 시점에 329점·댓글 155개였습니다. 관심 신호이며 안정성이나 실제 도입 규모를 뜻하지는 않습니다.
공식 create-talorys 배포 패키지는 0.1.6이며 10월 13일 07:47 UTC에 게시됐습니다. 설치 도구의 요구 조건은 Node.js 22 이상이고, 코드는 MIT 라이선스입니다. 다만 이 글은 게시된 패키지를 실행한 평가가 아니라 명시한 소스 커밋의 동작 해설입니다. npm 0.1.6과 그 뒤의 모든 소스 변경이 같다고 가정하지 않습니다.
백업의 자동화 항목은 현재 상태에 따라 처리됩니다
기본 경로는 Settings → Privacy → Download backup과 Choose backup file입니다. 가져오기 구현은 자동화의 이름이 아니라 ID로 기존 항목을 찾습니다. 다음은 유효한 일정이 들어 있고 오류 없이 처리되는 경우입니다.
| 백업과 현재 상태 | 해당 자동화의 처리 | 전체 예약 재설정 조건 |
|---|---|---|
| 현재 없는 ID | 새 항목을 일시정지 상태로 추가 | 이 추가만으로는 발생하지 않음 |
| 현재 켜진 ID, 백업은 꺼짐 | 현재 항목을 일시정지 | 발생 |
| 이미 꺼진 ID, 백업도 꺼짐 | 꺼진 상태 유지 | 이 항목만으로는 발생하지 않음 |
| 백업에 없는 현재 항목 | 삭제하지 않고 유지 | 다른 항목의 일시정지나 시간대 변경으로 함께 영향을 받을 수 있음 |
기존 ID와 만났다고 백업의 이름·메시지·일정으로 덮어쓰거나 꺼진 자동화를 다시 켜지도 않습니다. 중요한 연결 고리는 그다음입니다. 실제로 켜진 항목을 하나라도 정지시켰거나 가져온 시간대가 달라졌으면, 가져오기 함수가 전체 예약을 다시 설정하는 rearmAll을 호출합니다.
가상 사례: A를 정지했는데 B의 다음 알림이 밀리는 경우
다음 두 알림이 있고 시간대는 계속 UTC라고 하겠습니다. 다른 작업이나 예약 실행과 겹치지 않는 단순한 상황입니다.
- A: 현재 켜져 있는 알림. 가져올 백업에는 같은 ID의 A가 꺼진 상태로 들어 있습니다.
- B: 60분 간격 알림. 현재 다음 실행은 09:45이고, 가져올 백업에는 B가 없습니다.
- 09:20 무렵 백업을 가져오며, 새로 추가되는 자동화는 없습니다.
먼저 A가 일시정지됩니다. 이 변화가 전체 예약 재설정을 일으킵니다. rearmAll 구현은 각 항목의 기존 예약을 취소하고, 켜져 있는 항목은 다시 예약합니다. 따라서 B는 여전히 켜져 있지만 원래의 09:45 예약을 그대로 쓰지 않습니다.
다시 예약할 때 기준 시각은 그 호출 순간의 현재 시각입니다. interval 계산은 여기에 60분을 더합니다. B를 다시 예약하는 시각이 약 09:20이라면 다음 실행은 약 10:20으로 이동합니다. 이는 다시 예약하는 순간부터 60분을 더한 가상 계산이며 실제 처리 지연이나 알림 도착을 측정한 결과가 아닙니다.
같은 백업에서 A가 현재도 이미 꺼져 있었다면 새로 정지된 항목은 없습니다. 시간대도 같고 다른 정지 변화도 없다면 이 가져오기 경로는 전체 예약 재설정을 호출하지 않으므로 B의 예약은 유지됩니다. 새 자동화 하나를 일시정지 상태로 추가하는 것만으로도 이 재설정이 일어나지는 않습니다.
시간대만 달라져도 기존 예약은 다시 계산합니다
시간대도 별도 경로입니다. 백업의 자동화 목록이 비어 있어도 settings.timezone이 UTC에서 Asia/Seoul로 바뀌면 기존 예약을 다시 계산합니다. 예를 들어 매일 09:00 규칙은 이제 서울 시각의 09:00을 뜻합니다. 원래의 09:00 UTC와는 다른 순간입니다. 이 경우는 프로젝트의 시간대 복원 테스트에도 포함돼 있습니다. 테스트 파일을 읽은 것이며 이 글에서 해당 테스트를 실행한 것은 아닙니다.
복원 여부를 결정할 때 쓸 기준
개인 메모와 작업 알림을 함께 옮기고 실행 시각을 다시 조정해도 괜찮다면, 현재 데이터를 먼저 내보내고 현재 시간대와 중요한 알림의 켜짐 상태·다음 실행 시각을 따로 기록해 비교하는 방식이 적합합니다. Automations 화면의 Next 표시는 설정된 시간대를 사용하므로, 시각 숫자와 시간대를 함께 읽어야 합니다.
반대로 기존 알림의 실행 간격을 정확히 보존해야 하거나 일부 노트만 필요한 상황이라면 전체 백업 가져오기를 서두를 이유가 적습니다. 소량의 필요한 내용을 직접 옮기거나 중요 일정이 없는 때로 복원을 미루는 편이 단순합니다. 이전 백업을 다시 가져오는 작업도 같은 병합 규칙을 거치므로 이를 완전한 되돌리기 버튼으로 생각하면 안 됩니다.
데이터 병합은 데이터베이스 트랜잭션 안에서 처리되지만 전체 예약 재설정은 그 뒤에 기다리는 별도 단계입니다. 따라서 모든 저장과 외부 예약 처리가 한 번에 성공하거나 취소된다고 확대해서 해석할 수 없습니다. 오류나 동시 실행이 있는 경우, 실제 알림 전달, Cloudflare 장애 복구까지 이 가상 사례가 검증하지는 않습니다.
Talorys는 Cloudflare 무료 요금제 범위에 맞추려는 프로젝트지만 계정별 할당량이 있고, 유료 요금제에서는 사용량에 따라 비용이 생길 수 있습니다. 설치에는 본인 Cloudflare 계정과 배포 권한도 필요합니다. 공식 안내의 요구 조건과 한계를 먼저 읽고, 초기 도입은 중요하지 않은 개인 작업으로 제한하는 편이 좋습니다. 이 소스 검토에서 가져갈 핵심은 하나입니다. 자동화의 내용이 보존됐는지와 다음 실행 예약이 보존됐는지는 따로 확인해야 합니다.
댓글
댓글 쓰기