[REFACTOR] Webhook delivery 계층 분리 및 structured log 전환

[minyongP]

관련 작업 / 이슈

• Resolves [REFACTOR] Webhook delivery 계층 분리 및 structured log 전환 #87
• See also [REFACTOR] Webhook delivery 아키텍처 정리 (SMTP alignment) #88

---

이번 PR의 중점

• WebhookAlertService에 몰려 있던 예약/수정/취소 와 delivery worker 책임을 분리했습니다.
• webhook_alert_log 테이블 의존을 제거하고 SLF4J structured log 기반 운영 추적으로 전환했습니다.
• webhook scheduler를 application에서 infrastructure로 이동해 레이어 경계를 맞췄습니다.

---

내용 요약 (Description)

• 내용:
  • WebhookAlertNotifier, WebhookAlertDeliveryService, WebhookAlertMessageResolver, WebhookAlertEventLogger로 책임을 분리했습니다.
  • webhook_alert_log 관련 엔티티/리포지토리/테스트를 제거하고 webhook_alert.last_error + Flyway migration으로 정리했습니다.
  • nextScheduledAt 전략은 유지하면서 전송 전/후 deferred schedule 우선 적용 흐름을 보존했습니다.
  • retryable / non-retryable 실패 분류는 별도 policy 클래스를 두지 않고 WebhookAlertDeliveryService 내부로 흡수해 과설계를 줄였습니다.
  • WebhookAlertScheduler, WebhookAlertSchedulerProperties를 infrastructure 패키지로 이동했습니다.

알림 서비스 아키텍처

flowchart TD
    A["WorkspaceProblemService"] --> B["WebhookAlertNotifier"]
    C["WebhookAlertScheduler"] --> D["WebhookAlertDeliveryService"]
    D --> E["WebhookAlertMessageResolver"]
    D --> F["WebhookSender"]
    D --> G["WebhookAlertEventLogger"]
    F --> H["TemplatedWebhookSender"]
    H --> I["WebhookAlertTemplateRenderer"]
    H --> J["MattermostWebhookSender"]
    J --> K["RestTemplateWebhookTransport"]

Loading

클래스 다이어그램

classDiagram
    class WebhookAlertNotifier {
      +reserveOrUpdate(...)
      +deactivate(...)
      +cancel(...)
    }

    class WebhookAlertDeliveryService {
      +recoverStuckProcessing(now)
      +reserveDueAlertIds(now, limit)
      +deliver(alertId, now)
    }

    class WebhookAlertMessageResolver {
      +resolve(alert)
    }

    class WebhookAlertEventLogger {
      +logCreated(...)
      +logDelivered(...)
      +logRetryScheduled(...)
      +logFailed(...)
    }

    class WebhookSender {
      <<interface>>
      +send(hookUrl, message)
    }

    class TemplatedWebhookSender
    class MattermostWebhookSender
    class RestTemplateWebhookTransport
    class WebhookAlert

    WebhookAlertNotifier --> WebhookAlert
    WebhookAlertDeliveryService --> WebhookAlert
    WebhookAlertDeliveryService --> WebhookAlertMessageResolver
    WebhookAlertDeliveryService --> WebhookSender
    WebhookAlertDeliveryService --> WebhookAlertEventLogger
    WebhookSender <|.. TemplatedWebhookSender
    TemplatedWebhookSender --> MattermostWebhookSender
    MattermostWebhookSender --> RestTemplateWebhookTransport

Loading

작업 근거

• parent issue #88의 마지막 구현 단계로 webhook delivery 구조 정리를 마무리합니다.
• 앞선 #89, #90에서 분리한 HTTP client / sender 책임 위에 서비스 구조를 정리하는 작업입니다.

---

테스트

• 테스트 시나리오 설명:
  • ./gradlew verify 통과
  • ./gradlew test --tests 'com.ujax.domain.webhook.WebhookAlertTest' --tests 'com.ujax.domain.webhook.WebhookAlertRepositoryTest' --tests 'com.ujax.application.webhook.WebhookAlertNotifierTest' --tests 'com.ujax.application.webhook.WebhookAlertDeliveryServiceTest' --tests 'com.ujax.application.webhook.WebhookAlertEventLoggerTest' --tests 'com.ujax.infrastructure.scheduling.webhook.WebhookAlertSchedulerTest' --tests 'com.ujax.application.problem.WorkspaceProblemServiceTest'
  • 로컬에서 실제 Mattermost webhook 대상으로 예약 알림 E2E 발송 확인
    • PROCESSING_STARTED / DELIVERED structured log 확인
    • 발송 후 webhook_alert row 삭제 확인

---

PR 체크리스트

• 관련 이슈(작업 항목)를 PR 설명에 연결했다.
• ./gradlew verify 를 로컬에서 실행해 모두 통과함.
• 불필요한 로그, 디버깅 코드, 주석을 제거했다.
• 이 변경과 충돌할 수 있는 다른 PR이나 변경 사항이 없는지 확인했다.

---

Breaking Change 여부

• Yes (호환성 깨짐 있음)
• No

Yes인 경우, 무엇이 어떻게 깨지는지, 배포/마이그레이션 시 주의사항을 남겨 주세요.

• webhook_alert_log 테이블이 제거됩니다.
• Flyway migration V6__drop_webhook_alert_log_and_add_last_error.sql 적용이 필요합니다.
• 운영 중 webhook_alert_log 조회에 의존하는 코드/쿼리가 있다면 structured log(Loki) 기반 조회로 전환해야 합니다.

---

로그 / 스크린샷 (선택)

• 실제 E2E 테스트에서 event=webhook_alert eventType=PROCESSING_STARTED, eventType=DELIVERED 로그를 확인했습니다.

---

기타 정보 / 의존성 (선택)

• 관련 TODO:
  • webhook sender/transport에서 infra 예외를 application-friendly result로 번역하는 후속 리팩터링 여지
• 추후 리팩토링/성능 개선 포인트:
  • WebhookAlertMessageResolver를 별도 query/use-case로 더 명확히 분리할 수 있음
• 다른 모듈/서비스와의 의존성 또는 영향:
  • WorkspaceProblemService가 WebhookAlertNotifier를 사용하도록 변경됨
  • scheduler 위치가 infrastructure로 이동함