[REFAC] crawler/worker 의 lock 인프라 → internal/locks 분리 (이슈 #195 단계 2)

[juhy0987]

Parent: #195

어떤 작업인가요?

internal/crawler/worker/ 안에 fetcher 전용 코드 (Kafka consumer pool / pool manager / fetcher worker 등) 와 단계 공통 인프라 (IngestionLock / ProcessingLock / JobPriorityResolver) 가 섞여 있음. 단계 공통 부분을 internal/locks/ 로 분리하여 fetcher / parser / validator 가 동등하게 import 하는 위치로 이동.

분리 대상 식별

• IngestionLock (Publisher 가 Kafka enqueue 직전 호출 — 단계 무관)
• RedisIngestionLock 구현체
• ProcessingLock (fetcher / parser / validator 모두 사용)
• RedisProcessingLock / NoopProcessingLock 구현체
• 기타 lock 관련 타입 (ProcessingKey 등)

PriorityResolver 등 fetcher 외에서도 쓰이는지는 작업 시 확인 — 단독 사용이면 fetcher 영역 유지.

Scope

이동

• internal/crawler/worker/{ingestion_lock.go, processing_lock.go, ...} → internal/locks/
• 패키지명 worker → locks

변경 후 구조

internal/locks/
├── ingestion.go    (IngestionLock interface + RedisIngestionLock)
├── processing.go   (ProcessingLock interface + Redis/Noop 구현)
└── ...

작업 항목

1. lock 관련 파일 식별 및 git mv 로 이동
2. 패키지 선언 (package worker → package locks) 일괄 변경
3. import 경로 치환:
   • issuetracker/internal/crawler/worker.IngestionLock → issuetracker/internal/locks.IngestionLock
   • 기타 lock 타입 동일
4. fetcher worker / publisher / parser worker / validator worker 의 import 갱신
5. test/internal/crawler_core/ 등 테스트 mirror 디렉토리 정리
6. go build ./... && go test -race ./... 통과

Out of scope (다른 sub-issue)

• crawler/parser/ 이동 ([REFAC] crawler/parser → parser/rule 통합 (이슈 #195 단계 1) #196)
• crawler/{core,handler,implementation,domain,rate_limiter} 와 crawler/worker/ 의 fetcher worker 부분 → processor/fetcher/ 이동 ([REFAC] crawler 잔여 fetcher 영역 → processor/fetcher 이동 (이슈 #195 단계 3, 메타 이슈 close) #198)

위험도

Low-Medium

• 단계 분리 작업이라 간단해 보이지만, crawler/worker 안에서 fetcher worker 와 lock 의 cross-import 가 있을 수 있음 — 작업 시 의존성 그래프 확인 필요
• 변경 후 internal/locks 가 fetcher/parser/validator 모두에서 import 되는 hub 위치
• 테스트는 mock lock 사용 — 동작 변경 없음