[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.yml—management.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).