[FEATURE] Enrich stage priority-aware 처리 — Redis ZSET intermediate queue

[juhy0987]

배경

메타 이슈 #515 의 Phase 2 Sub 6 — Enrich stage 가 단일 토픽 (issuetracker.validated) 소비 + Kafka partition FIFO 라서 priority sub-ordering 부재.

선택된 메커니즘: 옵션 2-C — Redis ZSET intermediate queue (Parser/Validate 와 동일 패턴).

본 이슈는 #522 (Parser) 가 도입할 pkg/queue.PriorityZSetQueue 추상화를 재사용. Parser 머지 후 시작 권장. Validate 와 병렬 진행 가능.

변경 방향

인입 단계 (Kafka → Redis)

• Enrich consumer 가 TopicValidated 메시지를 받으면 Redis ZSET 에 즉시 적재
• ZSET key: enrich:queue
• score 계산: priority × 1e10 + arrival_timestamp_ms
• 적재 직후 Kafka commit

처리 단계 (Redis → Worker)

• Enrich worker pool 이 ZSET 에서 ZPOPMIN 으로 pop
• LLM enrichment 로직 그대로 보존 (quota 처리 포함)
• 처리 실패 시 bus.RetryScheduler 경유

재사용

• pkg/queue.PriorityZSetQueue (Parser 이슈 [FEATURE] Parser stage priority-aware 처리 — Redis ZSET intermediate queue #522 도입)
• 환경변수 네이밍 컨벤션 일관: ENRICH_ZSET_*

완료 조건

• Enrich consumer 가 Kafka 메시지 → ZSET 적재 + Kafka commit
• Enrich worker pool 이 ZSET 에서 pop + 처리
• Kafka publish 실패 시 RetryScheduler 경유
• 단위 테스트: ZSET 통합 — Parser 의 추상화 재사용 검증
• 통합 테스트: high priority enrich job 이 normal 보다 먼저 처리 + LLM quota 흐름 영향 없음
• graceful shutdown
• .env.example: ENRICH_ZSET_QUEUE_KEY, ENRICH_ZSET_POP_BATCH_SIZE, ENRICH_ZSET_MAX_SIZE
• 메트릭 dashboard 추가

위험 / 롤백

• Redis 부하 누적 — Parser + Validate + Enrich 세 개 ZSET 사용 → capacity 재점검
• LLM enrichment 자체가 지연 단계 — priority queue 가 quota 소진 패턴에 영향 줄 수 있음 (high 가 quota 빠르게 소진하면 normal/low 가 stale 누적). 본 이슈 작업 시 quota 정책과의 상호작용 명시
• Feature flag ENRICH_PRIORITY_QUEUE_ENABLED=false

의존성

• 선행: #522 (Parser) — pkg/queue.PriorityZSetQueue 추상화 도입
• 병렬 가능: #523 (Validate)

관련

• Parent: #515
• 선행 PR: PR [FEAT#510] normal/low crawl 토픽 Redis 버퍼링 + 주기적 Kafka backlog drain #511, PR [FEAT#512] BufferDrainer leader election + publish-fail Kafka 재시도 경로 #516
• internal/processor/enrich/ — 684 LoC 변경 대상