에이전트 캘린더 조율
회의를 협상하고, 집중 시간을 보호하며, 캘린더 데이터에서 컨텍스트를 추론하는 AI 에이전트를 구축하세요. 시간대 복잡성을 탐색하고, 에이전트 간 스케줄링을 구현하며, Google 캘린더 API 및 MCP를 사용하여 맞춤형 캘린더 로직을 설계합니다.
의사 결정 지점
충돌 감지 시
수신된 회의 요청이 기존 일정과 충돌함
├─ 발신자 = 관리자/임원 → 자동 수락, 기존 일정 이동 제안
├─ 회의 = 1:1/긴급 태그 → 24시간 내 대안 제안
├─ 집중 블록 충돌
│ ├─ 블록 우선순위 = 높음(심층 작업) → 자동 거절
│ └─ 블록 우선순위 = 중간 → 대안 시간 제안
└─ 동료 회의와 중복 → 3개의 대안 슬롯 제안
자동 거절 vs 대안 제안 결정
요인: 발신자_계층(임원/관리자/동료/외부) × 회의_유형(1:1/팀/전체회의) × 집중_블록_우선순위
임원 + 모든 유형 → 항상 대안 제안
관리자 + (1:1 또는 긴급) → 대안 제안
동료 + 정기 + 낮은 참석률 → 자동 거절
외부 + 사전 관계 없음 → "캘린더 링크 사용"과 함께 자동 거절
높은_우선순위_집중_블록 중 → 발신자 관계없이 자동 거절
시간대 인식 슬롯 선택
다중 참가자 스케줄링:
├─ 모두 동일 시간대 → 현지 근무 시간 사용 (9-17시)
├─ 2개 시간대, 차이 <6시간 → 겹치는 시간 창 찾기
├─ 2개 시간대, 차이 >6시간 → 이른/늦은 분할 (한 명은 오전 8시, 다른 한 명은 오후 6시)
└─ 3개 이상 시간대 → 비동기 대안 또는 순환 일정 제안
에너지 모델 슬롯 순위
시간대 우선순위 (내림차순):
1. 오전 9-11시 (인지 최고) → 심층 작업 예약, 일상 회의 거절
2. 오전 11시-오후 12시 (지속적 집중) → 중요한 회의만 허용
3. 오후 2-4시 (협업 최적 시간) → 팀 회의 선호
4. 오후 4-5시 (마무리) → 1:1, 상태 업데이트에 적합
5. 오후 1-2시 (점심 후 슬럼프) → 복잡한 회의 회피
실패 모드
시간대 인식 정기 회의 충돌
증상: 매주 오전 9시 회의가 겨울에는 충돌하지만 여름에는 충돌하지 않음; 시간대 간 정기 회의가 DST 변경 후 실패
감지: if recurring_event && timezone_conversion && conflict_pattern_seasonal
수정: 항상 singleEvents: true로 정기 일정을 확장하고, 각 인스턴스를 UTC로 변환하여 충돌 확인, DST 전환 후 재평가
버퍼 강제 변동
증상: 에이전트가 버퍼를 만들기 위해 동일한 회의를 반복적으로 재일정; 회의가 슬롯 간에 바운스됨
감지: if same_meeting_rescheduled > 2 times in 24h for buffer_reasons
수정: 첫 번째 재일정 후 회의 고정, 회의 중요도에 따라 버퍼 요구 사항 동적 조정
에너지 모델 초기 구축 문제
증상: 새 에이전트가 사용자의 최악의 인지 시간에 회의를 예약; 확립된 패턴을 무시
감지: if meeting_satisfaction_score < 3 for meetings_scheduled_by_agent
수정: 명시적 사용자 선호도로 부트스트랩, 거절 패턴에서 학습, 자동 스케줄링 전 2주 관찰 기간 필요
스키마 비대화 개인정보 누출
증상: 에이전트가 외부 시스템에 너무 많은 캘린더 세부 정보를 공유; 이벤트 설명이 LLM에 유출됨
감지: if external_api_call contains event.description OR attendee.email
수정: 데이터 최소화 계층 구현, 외부 호출 전 PII 제거, 스케줄링에 대해 사용 가능/바쁨만 사용
재귀적 협상 루프
증상: 두 에이전트가 끝없이 상호 제안; 회의 시간에 수렴하지 않음
감지: if negotiation_rounds > 3 && no_accepted_slot
수정: 2번의 대응 후 인간에게 에스컬레이션, "충분히 좋은" 수락 임계값 구현, 협상 시간 제한
실제 예제
시간대 간 회의 협상
시나리오: 귀하의 에이전트(시카고)가 API 검토를 위해 동료 에이전트(도쿄)와 30분 회의가 필요합니다. 둘 다 에너지 제약이 있습니다.
1단계: 초기 분석
- 시카고: 오전 9시-오후 5시 CST = 오전 12시-오전 6시 JST (다음 날)
- 도쿄: 오전 9시-오후 6시 JST = 오후 7시-오전 4시 CST (전날)
- 겹치는 시간 창: 오후 7-8시 CST = 오전 9-10시 JST
2단계: 에너지 모델 확인
- 시카고 오후 7시 = 근무 종료 (에너지: 6/10)
- 도쿄 오전 9시 = 인지 최고 시간 (에너지: 9/10)
- 불균형 감지 → 타협 필요
3단계: 제안 생성
에이전트 시카고 → 에이전트 도쿄: 제안
슬롯: [
"2024-03-19T01:00Z" (시카고: 오후 7시, 도쿄: 오전 10시),
"2024-03-19T23:00Z" (시카고: 오후 5시, 도쿄: 오전 8시),
"2024-03-20T00:00Z" (시카고: 오후 6시, 도쿄: 오전 9시)
]
우선순위: 보통
주제: "API 검토 - 시간대 복잡성 논의"
4단계: 대응 제안
에이전트 도쿄 → 에이전트 시카고: 대응
이유: "복잡한 기술 논의를 위해 도쿄 늦은 아침 선호"
대안: [
"2024-03-19T02:00Z" (시카고: 오후 8시, 도쿄: 오전 11시),
"2024-03-20T01:00Z" (시카고: 오후 7시, 도쿄: 오전 10시)
]
제약: "오전 11시 30분 JST 스탠드업 전 15분 버퍼 필요"
5단계: 해결 시카고 에이전트가 오후 8시 CST / 오전 11시 JST 슬롯을 수락하고, 설명에 두 시간대를 모두 포함하는 이벤트 생성: "API 검토 - 오후 8시 CST / 오전 11시 JST+1"
초보자 vs 전문가:
- 초보자: 도쿄의 인지 시간을 확인하지 않고 시카고 편의 시간에 예약
- 전문가: 에너지 불균형을 인식하고, 도쿄가 신선할 때 시카고 늦은 시간을 제안
품질 게이트
- 모든 타임스탬프는 내부적으로 UTC로 저장되며, 표시/API 경계에서만 변환
- IANA 시간대 이름이 전체적으로 사용됨 (UTC 오프셋 문자열("-05:00" 등) 없음)
- 사용 가능/바쁨 쿼리는 이벤트 세부 정보를 제거하고 외부 에이전트와 시간 블록만 공유
- 버퍼 강제로 연속 회의 간 최소 10-15분 확보
- 집중 블록은 "바쁨"으로 표시되지만 협상 시 실제 회의보다 낮은 우선순위
- 에너지 모델은 사용자의 인지 최고 시간과 회의 피로 패턴을 고려
- OAuth 토큰은 저장 시 암호화되며 자동 새로고침 흐름 구현
- 속도 제한은 지수 백오프를 사용하여 Google 캘린더 API 할당량 처리
- 정기 이벤트는 충돌 감지 전에 개별 인스턴스로 확장
- 다중 캘린더 병합은 다른 권한의 개인/업무 캘린더에서 테스트됨
- 에이전트 협상은 실패한 라운드 후 인간에게 에스컬레이션되는 시간 제한 있음
- 감사 로그는 롤백 기능이 있는 모든 캘린더 변경 사항을 캡처
NOT-FOR 경계
이 스킬은 다음 용도가 아닙니다:
- 캘린더 UI 컴포넌트 구축 →
form-validation-architect사용 - 프로젝트 Gantt 차트 또는 마일스톤 추적 →
project-management-guru-adhd사용 - 포모도로 타이머 또는 시간 추적 앱 →
adhd-daily-planner사용 - 일반 에이전트 아키텍처 패턴 →
agentic-patterns사용 - 기본 에이전트 프레임워크 구축 →
agent-creator사용
다음 경우 다른 스킬에 위임:
- 사용자가 ADHD 특화 시간 관리 필요 →
adhd-daily-planner - 지속적인 에이전트 메모리 구축 →
always-on-agent-architecture - 캘린더 외 다중 에이전트 조율 →
multi-agent-coordination - 백그라운드 데몬 아키텍처 →
daemon-development
이 스킬은 캘린더 데이터 구조, 스케줄링 알고리즘 및 회의 조율 로직에 특화되어 있습니다.