왜
위시 고도화(가격 추적)가 회의에서 승인됐다. 그런데 현재 구조는 등록마다 새 item 행을 만들어 같은 링크가 사람마다 다른 상품이 된다 — 운영 실측으로 URL item 511행 = 고유 392개, 한 링크가 최대 37행이며, 같은 링크인데 저장 가격이 서로 다른 사례가 2건 실증됐다. 값은 등록 시점에 박제되어 살아있는 위시의 57%가 31일 이상 낡았고, 갱신 기능은 운영에서 한 번도 실행된 적 없다(전체 snapshot 버전이 전부 1개).
가격 추적은 "링크 하나 = 상품 하나" 정체성 위에서만 성립한다. 정체성이 갈라져 있으면 갱신 비용이 행 수에 비례해 폭발하고, 사용자 간 가격 divergence 가 구조적으로 재생산된다.
무엇을
링크 정규화·귀결점 유니크·별칭 매핑으로 상품 정체성을 공유하고, snapshot 에 출처(기계/수기·편집자)를 기록하며, 뷰는 항상 마지막 기계 추출값을 향한다(수기값은 이력에 남되 기본 접힘, 서버는 전부 내려줌). 그 위에 동시 갱신 수렴과 주기 갱신을 얹는다.
회의 결정사항 (2026-07-28)
- 가격만 추적한다. 재고는 사이즈·컬러와 결합이 커 제외. 옵션(사이즈/컬러) 입력은 등록 플로우가 길어져 이번에는 전혀 고려하지 않는다. 카테고리는 별도 문제(자체 분류 체계 필요)로 분리.
- 토너먼트: 진행 중은 최신값, 완료된 이력은 출전 시점 값 고정.
- 수기값은 신뢰하지 않는다. 카드·가격 추적은 항상 마지막 기계 추출 성공값을 향한다. 수기값은 이력 데이터에 포함해 내려주되 뷰 기본값은 접힘(타인이 고친 값으로 표시). 수기 수정은 상태 무관 언제든 허용으로 변경.
- 기존 511행 병합은 보류. 신규 등록부터 적용(forward-only). 최종적으로는 유니크로 수렴하는 것이 옳다는 방향만 합의.
하위 작업
왜
위시 고도화(가격 추적)가 회의에서 승인됐다. 그런데 현재 구조는 등록마다 새 item 행을 만들어 같은 링크가 사람마다 다른 상품이 된다 — 운영 실측으로 URL item 511행 = 고유 392개, 한 링크가 최대 37행이며, 같은 링크인데 저장 가격이 서로 다른 사례가 2건 실증됐다. 값은 등록 시점에 박제되어 살아있는 위시의 57%가 31일 이상 낡았고, 갱신 기능은 운영에서 한 번도 실행된 적 없다(전체 snapshot 버전이 전부 1개).
가격 추적은 "링크 하나 = 상품 하나" 정체성 위에서만 성립한다. 정체성이 갈라져 있으면 갱신 비용이 행 수에 비례해 폭발하고, 사용자 간 가격 divergence 가 구조적으로 재생산된다.
무엇을
링크 정규화·귀결점 유니크·별칭 매핑으로 상품 정체성을 공유하고, snapshot 에 출처(기계/수기·편집자)를 기록하며, 뷰는 항상 마지막 기계 추출값을 향한다(수기값은 이력에 남되 기본 접힘, 서버는 전부 내려줌). 그 위에 동시 갱신 수렴과 주기 갱신을 얹는다.
회의 결정사항 (2026-07-28)
하위 작업