docs: refine calendar holiday control research

journey/research/260310_calendar_skill_자동휴일감지_행동제어_원인확정_리서치.md

@@ -88,5 +88,42 @@ tags: [calendar, scheduler, holiday, blackout, research]
 - 계획 문서 예시는 `2026-02-16~2026-02-18` 연휴를 들고 있지만,
 - 실제 운영 기준 국가/타임존(`KR`, `Asia/Seoul`)를 어디까지 고정할지 별도 확정이 필요합니다.
 
+## 권고안 (2026-03-10 기준)
+
+### 1. 대한민국 공휴일 SSOT 권고안
+- CompanyX 현재 운영 범위가 대한민국 기준이면, 공휴일 데이터 1차 SSOT는 **공공데이터포털의 한국천문연구원 `특일 정보` OpenAPI**로 두는 것이 가장 적절합니다.
+- 권고 근거:
+  - 한국 공휴일/기념일/관공서 휴무 판단에 직접 맞는 데이터셋입니다.
+  - 계획 문서의 `country=KR`, `timezone=Asia/Seoul` 전제와도 가장 자연스럽게 맞습니다.
+  - Google Holiday Calendar보다 국내 제도 변경 추적 기준이 더 명시적입니다.
+- 권고 링크:
+  - 한국천문연구원 특일 정보 OpenAPI: <https://www.data.go.kr/data/15012690/openapi.do>
+  - 법적 기준 확인: 공휴일에 관한 법률 / 관공서의 공휴일에 관한 규정 <https://www.law.go.kr/>
+- 보조 경로:
+  - 수동 블랙아웃 기간은 별도 정책 필드로 병행합니다.
+  - Google Holiday Calendar는 보조 검증/백업 소스로만 두는 편이 안전합니다.
+
+### 2. 정책 저장 위치 권고안
+- 가장 좋은 1차 선택은 **`scheduled_jobs.schedule_policy JSONB` 추가**입니다.
+- 권고 이유:
+  - 이 정책은 사용자 선호가 아니라 **잡 실행 정책**입니다.
+  - 현재 `scheduled_jobs` CRUD와 가장 가깝고, 데이터 경계가 분명합니다.
+  - 별도 테이블보다 적용 비용이 작고, 초기 운영 단순성이 높습니다.
+- 권장 기본 형태:
+  - `{"mode":"workday","country":"KR","timezone":"Asia/Seoul","blackout_ranges":[]}`
+
+### 3. 실행 가드 위치 권고안
+- 가장 좋은 1차 선택은 **각 `_run_*_with_logging` 진입점 앞 공통 가드 헬퍼**입니다.
+- 권고 이유:
+  - 실제 실행/스킵 로그를 잡 단위로 가장 명확하게 남길 수 있습니다.
+  - `db_loader`에서 래핑하는 방식보다 디버깅이 쉽고, 현재 구조에 덜 침습적입니다.
+  - `should_run=false`일 때 왜 스킵됐는지 `reason`을 잡 로그에 직접 남기기 좋습니다.
+
+### 4. 운영 기준 권고안
+- 1차 운영 범위는 **`country=KR`, `timezone=Asia/Seoul` 고정**으로 시작하는 것이 가장 좋습니다.
+- 권고 이유:
+  - 현재 CompanyX 기준에서 요구사항이 명확합니다.
+  - 다국가 일반화보다 오판 여지가 적고, 테스트 케이스도 단순해집니다.
+
 ## 한 줄 결론
 - 현재 `260214` 계획이 안 풀린 직접 원인은 "휴일 정책 저장, 휴일 판정 API, 실행 가드, 운영 설정 persistence" 네 레이어가 모두 아직 구현되지 않았기 때문입니다.