파싱 작업 상태(작업 큐)를 버전 이력에서 분리 — 요청 테이블 도입

[m-a-king]

상위 Epic

#824

왜

item_snapshots 가 성격이 다른 두 역할을 겸직하고 있다.

• 버전 이력: name · price · image · currency · extracted_at (상품의 사실)
• 작업 상태: status(PENDING/PROCESSING) · attempt_count · heartbeat (파싱 잡의 사실)

PENDING 은 "아직 상품의 사실이 없는 행"인데 버전 테이블에 산다. #825 정체성 설계 논의(2026-07-30)에서 이 겸직이 어색함의 뿌리라는 결론이 났고, "요청(작업)을 표현하는 테이블"로 분리하는 것이 올바른 목표 구조라는 데 합의했다.

다만 시점은 정체성 공유(#825) 뒤로 미룬다 — 분리는 갓 안정화한 작업 큐 기계(#770 SKIP LOCKED, #803 heartbeat)와 갓 정규화한 참조 구조(4b #514, wish·tournament_item → snapshot_id NOT NULL)를 다시 열고 등록 응답 계약(클라 조율)까지 묶이는 에픽급 작업이라, 회의가 승인한 가격 추적을 먼저 세운다. #825 의 산출물(정규화 · canonical · 별칭 · 출처)은 이 분리 후에도 전부 그대로 살아남으며, 축소되는 것은 병합 연산과 item 단위 락 일부뿐이다.

무엇을

• 요청 테이블 신설 (예: parse_requests): 입력(정규화 URL 또는 image key) · status · attempt_count · heartbeat · 요청 시각. 작업 큐의 claim(SKIP LOCKED) · recover · 상한 판정이 이 테이블로 이동한다.
• item_snapshots 는 순수 버전 이력으로: 파싱 성공 시에만 행이 생기고, PENDING/PROCESSING 상태가 사라진다.
• 참조 재배선: 파싱 중인 wish · tournament_item 이 요청을 가리키는 구조(스키마 변경 + 조회 경로 수정).
• 등록 응답 계약 조정: 파싱 완료 전에는 item · snapshot 이 없는 응답 모양 — 클라이언트와 조율 필수.
• 단계 배포: 장기 브랜치 금지. 테이블 추가 → 잡 상태 이중 기록 → 참조 전환 → 옛 컬럼 정리 순의 additive 단계로 dev 에 흘린다.
• SSE·알림 라우팅 정리 포함: 파싱 완료 신호가 itemId 를 키로 퍼지는 현 구조(파싱 SSE 동기화: item 공유 도입 시 routing별 snapshot 상태 확인 (spurious 갱신 방지) #576 에서 임시 보정)도 잡 상태 겸직의 증상이다. 요청 테이블로 가면 신호가 요청(잡) 단위로 발행되어 라우팅 오염 문제가 뿌리에서 사라진다.
• 상품 정체성 공유 — 링크 정규화·별칭 매핑·snapshot 출처 #825 에서 도입한 병합(재부모화) 연산은 이 분리로 자연 축소된다 — 요청 완료 시점에 canonical 로 find-or-create 하므로 임시 item 자체가 줄어든다.

이행을 쉽게 만드는 선행 조치 (#825 쪽에 반영)

• 카드 뷰는 상품 정체성 공유 — 링크 정규화·별칭 매핑·snapshot 출처 #825 부터 "값 = 마지막 SERVER* READY 파생 조회 + 진행 중 = PENDING/PROCESSING 존재 여부 합성"으로 짓는다. 이 분리 덕에 요청 테이블 전환 시 "진행 중"의 출처 한 곳만 요청 행 조회로 교체하면 되고, 값 조회 다리는 그대로 산다. 상품 정체성 공유 — 링크 정규화·별칭 매핑·snapshot 출처 #825 구현에서 진행 중 판정을 단일 지점으로 모아 두는 것이 이 교체를 한 곳으로 만드는 열쇠다.
• 남는 계약 이슈: 위시 목록 응답이 item.id 를 non-null 로 노출한다(실물 확인 2026-07-31). 요청 테이블 세계에선 파싱 완료 전 item 이 없어 이 필드의 nullable 전환(클라 조율)이 필요하다.

의존

• 상품 정체성 공유 — 링크 정규화·별칭 매핑·snapshot 출처 #825 상품 정체성 공유 (선행 — 이 분리는 그 위에서 안전하게 이뤄진다)
• 클라이언트 일정 조율 (응답 계약 변경)