google_calendar

📅 Google Calendar API 동기화 방식 비교

🪝 Webhook vs. Scheduling ⏰

⏳ 1. Scheduling(주기적 조회) 방식

주기적으로 Google Calendar API를 호출하여 일정 변경 사항을 감지하는 방식이다.
(ex: 5분마다 Google Calendar API를 호출하여 변경된 이벤트를 조회)

장점

1. 구현이 간단함

   • Webhook을 설정할 필요 없이, 주기적으로 API를 호출하는 방식으로 쉽게 구현 가능.
   • 별도의 구독 관리가 필요 없음.

2. Webhook 만료 문제 없음

   • Webhook과 달리 주기적 조회 방식은 만료되지 않아 재등록 과정이 필요 없음.

단점

1. 실시간 동기화 불가능

   • 일정 변경을 감지하는 주기에 따라 최대 몇 분의 지연이 발생할 수 있음.
   • 빠른 응답이 필요한 서비스에는 적합하지 않음.

2. 불필요한 API 호출 증가

   • 일정이 변경되지 않았더라도 정해진 주기마다 API를 호출해야 함.
   • Google API의 Rate Limit을 초과할 가능성이 있음.
   • API 호출 횟수 증가로 인해 네트워크 비용 및 서버 부하 증가.

3. 사용자 경험(UX) 저하 가능성

   • 일정 변경이 즉시 반영되지 않으므로, 사용자 입장에서 동기화가 지연될 수 있음.

✅ 2. Webhook(푸시 알림) 방식

Google Calendar의 Push Notifications(Webhook) 기능을 활용하여 일정이 변경될 때 즉시 동기화하는 방식이다.

장점

1. 실시간 동기화

   • 일정 변경이 발생하면 즉시 감지하여 업데이트 가능.
   • 사용자 경험(UX)이 향상됨.

2. API 요청 수 감소

   • 일정 변경이 있을 때만 동기화를 수행하여 불필요한 API 호출을 줄일 수 있음.
   • Google API의 Rate Limit(요청 제한) 문제를 방지할 수 있음.

3. 비용 절감

   • 불필요한 API 요청을 줄여 네트워크 비용 및 서버 부하 감소.

단점

1. 구현이 복잡함

   • Webhook URL을 설정하고, Google Calendar API에서 Webhook 구독을 관리해야 함.
   • 서버에서 Webhook 요청을 검증하고 처리하는 로직을 구현해야 함.

2. Webhook 만료 및 재등록 필요

   • Google Calendar API의 Webhook 구독은 만료될 수 있으므로 주기적으로 재구독해야 함.
   • 구독이 끊어지면 동기화 누락 가능성이 있음.

결론

우리 서비스는 높은 실시간성을 필요로 하고 요청하는 API를 줄여 네트워크 부하를 감소시키는 게 적절하다고 판단하여 푸시 알림 방식을 선택하였습니다.

---

공식 문서

에러 처리