6.6 KiB
6.6 KiB
tags
| tags | |||||
|---|---|---|---|---|---|
|
Calendar Skill 자동휴일감지 행동제어 원인확정 리서치
날짜: 2026-03-10 작성자: Codex 관련 계획: Calendar Skill 기반 자동 휴일 감지 행동 제어 시스템 구축 상위 원칙: 문서 작성 원칙, Backend Coding Principles
관련 문서
Facts
1. scheduled_jobs에는 휴일/블랙아웃 정책 필드가 아직 없습니다.
- 실제 DB
scheduled_jobs컬럼은id,name,job_type,cron_expression,enabled,config,created_at,updated_at만 존재합니다. - 계획 문서에 적힌
schedule_policy JSONB컬럼은 아직 추가되지 않았습니다. - 현재 운영 데이터도 각 잡의 정책은
cron_expression과config만 갖고 있습니다.
2. rb8001 스케줄러 로더는 cron만 읽고 실행 가드를 두지 않습니다.
rb8001/app/scheduler/db_loader.py는scheduled_jobs에서cron_expression과 일부config.channel_id만 읽어 APScheduler에 등록합니다.workday,holiday,blackout,schedule_policy같은 키를 해석하는 코드가 없습니다.- 각 잡 실행 함수(
_run_*_with_logging) 앞에 공통 휴일 판정 가드를 거는 코드도 현재 보이지 않습니다.
3. rb8001 스케줄러 API도 정책 필드를 다루지 않습니다.
rb8001/app/router/scheduler_endpoint.py의 생성/수정 API는enabled,cron_expression,config만 처리합니다.- 계획 문서에 적힌
schedule_policy응답/수정 경로는 아직 구현되지 않았습니다. - 관련 테스트
rb8001/tests/test_scheduler_repository.py,rb8001/tests/test_scheduler_endpoint_e2e.py도 휴일 정책 없이 기존 CRUD만 검증합니다.
4. robeing-monitor는 schedule_type, schedule_days를 실제 저장하지 않습니다.
robeing-monitor/app/api/monitor.py의UserPreferencesUpdate/UserPreferencesResponse에는schedule_type,schedule_days필드가 있지만,- 코드 주석에
schedule_type, schedule_days, include_* 컬럼들은 무시라고 적혀 있고, 실제 DB UPDATE/INSERT에도 반영하지 않습니다. UserPreferencesResponse는schedule_type="workday",schedule_days=[]를 고정 기본값으로 돌려줍니다.- 실제 DB
user_preference컬럼도user_id,news_keywords,email_filter,briefing_enabled,briefing_time,updated_at,created_at,id만 있고schedule_type,schedule_days는 없습니다.
5. skill-calendar에는 계획된 휴일 판정 API가 없습니다.
- 계획 문서는
GET /api/workday/check엔드포인트를 요구합니다. - 실제
skill-calendar/routers/calendar.py는POST /events,GET /events,DELETE /events/{event_id}만 제공합니다. - 실응답 기준으로도
http://127.0.0.1:8512/api/workday/check?...는404 Not Found입니다.
6. 현재 구조로는 공휴일/연휴를 cron에서 직접 배제하지 못합니다.
- 운영 잡 다수는 실제로
mon-fricron을 그대로 사용합니다. - 예:
naverworks_daily 0 9 * * mon-fri,coldmail_daily 5 9 * * mon-fri,daily_headlines 10 9 * * mon-fri. - 따라서 연휴 중 평일이 포함되면 현재 구조에서는 기본적으로 실행 대상이 됩니다.
Interpretation
1. 이 계획의 미구현 원인은 "스케줄 정책 저장층 부재"가 핵심입니다.
- 휴일 자동 제어를 하려면 최소한
scheduled_jobs또는 별도 정책 테이블에workday/blackout정책이 저장돼야 합니다. - 현재는 그 저장층 자체가 없어서,
rb8001이 실행 직전에 참조할 정책 데이터가 없습니다.
2. robeing-monitor의 UI/설정 필드는 아직 더미 상태입니다.
- 프런트/응답 모델에는
schedule_type,schedule_days가 보이지만, 실제 저장/조회는 되지 않습니다. - 즉 운영자가 UI에서 값을 바꿔도 현재 구조에서는 실제 실행 정책이 바뀌지 않습니다.
3. skill-calendar는 "일정 CRUD 스킬"까지만 구현되어 있고 "휴일 판정 서비스" 역할은 아직 시작되지 않았습니다.
- Google Calendar 연동과 이벤트 생성/조회/삭제는 있지만,
- 계획의 핵심인
is_workday,is_blackout,should_run,reason판정 레이어는 없습니다.
4. 현재 문제는 단일 버그보다 "계획의 각 레이어가 동시에 비어 있는 상태"에 가깝습니다.
- 저장층 없음
- 판정 API 없음
- 실행 가드 없음
- 운영 설정 persistence 없음
- 테스트도 휴일 정책 기준으로는 아직 없음
Unresolved
1. 휴일 기준 SSOT를 어디에 둘지 미확정입니다.
- Google Holiday Calendar를 단일 기준으로 둘지
- 국가/타임존별 정책을 별도 테이블로 둘지
- 수동 블랙아웃만 우선 둘지 결정이 필요합니다.
2. 정책 저장 위치가 미확정입니다.
scheduled_jobs.schedule_policy컬럼으로 갈지- 별도
scheduled_job_policies테이블로 분리할지 user_preference와 잡 정책을 어떤 경계로 나눌지 정리가 필요합니다.
3. 실행 가드 위치가 미확정입니다.
db_loader등록 단계에서 래핑할지- 각
_run_*_with_logging진입점 공통 헬퍼로 넣을지 - APScheduler listener 레벨에서 막을지는 아직 결정되지 않았습니다.
4. 테스트 기준 날짜/국가 범위가 미확정입니다.
- 계획 문서 예시는
2026-02-16~2026-02-18연휴를 들고 있지만, - 실제 운영 기준 국가/타임존(
KR,Asia/Seoul)를 어디까지 고정할지 별도 확정이 필요합니다.
한 줄 결론
- 현재
260214계획이 안 풀린 직접 원인은 "휴일 정책 저장, 휴일 판정 API, 실행 가드, 운영 설정 persistence" 네 레이어가 모두 아직 구현되지 않았기 때문입니다.