[BE-10] 통합 와이어업 (SecurityConfig·application.yml·피처 플래그)

작업 내용 (설계 의도)

변경 사항

공유 파일(설정·보안)을 단독으로 수정하는 마지막 통합 티켓. Single Writer 경계상 다른 티켓과 분리해 마지막 wave에 단독 배치. 근거 TDD: §Release Scenario·§실패경로.

  • infrastructure/security/SecurityConfig.kt/internal/alerts/**를 permitAll(컨트롤러가 grafana=Authorization: Bearer·내부raise=X-Alert-Token으로 자체 검증) 또는 전용 필터로 시크릿 검증. 기존 인가 규칙 미변경.
  • application.yml — alerting 설정 블록 추가: alerting.enabled(피처 플래그, 기본 false), alerting.webhook-token(${ALERT_WEBHOOK_TOKEN}), alerting.discord.webhook-url(${DISCORD_WEBHOOK_URL}recipient-user-id, alerting.llm.*(모델·${ALERTING_LLM_API_KEY}·timeout), alerting.telemetry.*(prometheus/loki/tempo base-url — ⑤ 계약 재사용). 기존 management.metrics.tags.env 미변경.
  • application.ymlmanagement.metrics.distribution.percentiles-histogram.http.server.requests: true 추가(INFRA-02 실측: Grafana P95 규칙의 http_server_requests_seconds_bucket 히스토그램 미노출 → 없으면 규칙 NoData).
  • 피처 플래그 게이팅: alerting.enabled=false면 webhook은 202만 반환·처리 스킵(무중단 배포·롤백).

롤백: alerting.enabled=false(즉시 비활성). 설정/보안 변경은 단일 PR revert.

의존

  • BE-08, BE-09 (엔드포인트·worker 존재)
  • BE-02, BE-06 (Discord·LLM properties 소비 키)

다이어그램

클래스 의존

flowchart LR
    SC["SecurityConfig"] --> EP["/internal/alerts/**"]
    YML["application.yml alerting.*"] --> Flag["alerting.enabled 플래그"]
    Flag --> WH["AlertWebhookApiController"]

테스트 케이스

  • /internal/alerts/grafana가 인증 필터를 통과해 컨트롤러 시크릿 검증까지 도달한다.
  • alerting.enabled=false면 webhook이 202만 반환하고 파이프라인을 트리거하지 않는다.
  • alerting.enabled=true면 정상 파이프라인이 동작한다.
  • 기존 도메인 API 인가 규칙(/admin/·/mcp/ 등)이 변경되지 않는다(회귀).
  • 환경변수 미주입 시 앱이 부팅에 실패하지 않는다(기본값·플래그 OFF).