같은 대상을 가리키는 키가 어긋나는 방식이 두 방향이다. 한쪽만 고치면 반대쪽이 그대로 남는다.
| 방향 | 원인 | 증상 |
|---|---|---|
| 다른 것 → 같은 키 | 절단으로 접미가 잘려나감 | 덮어써서 마지막 것만 남는다 |
| 같은 것 → 다른 키 | 재등록 때마다 접미가 붙는다 | 조회가 아예 안 붙는다 |
두 번째 방향의 실제 모습
B0XXXXXXXX → B0XXXXXXXXAB → ...R / RR / RRR재등록·재생성 때마다 접미가 하나씩 붙는다. 사람이 보면 같은 물건인데 키로는 완전히 다르다.
해법
적용 후 8,858건 중 6,657건(75%)이 붙었다.
★ 전개로도 안 붙는 게 남는다 — 아예 다른 채번 체계로 만들어진 키다. 채번 시점에 대응 키를 같이 박지 않으면 사후 복구가 안 된다. 생성과 등재를 같은 코드에서 처리한다.
첫 번째 방향의 실제 모습 — 덮어쓰기는 "미색인"으로 남는다
외부 SKU가 소스 핸들의 38자 절단이라 변형끼리 같은 키가 된다. index[key] = id로 넣으면 마지막 것만 남고 나머지는 영원히 미색인이다. 처리에 실패한 게 아니라 색인에 자리가 없다.
key → id는 1:N이다. 1:1을 전제한 dict가 틀렸다 → id → key 역인덱스를 따로 두고, 정방향은 리스트로 받는다★ "미색인 N건"이 회차마다 안 줄면 처리 실패가 아니라 키 충돌을 의심한다. 정체된 지표는 "일이 안 됐다"가 아니라 "일이 담길 곳이 없다"일 수 있다. 처리는 매번 정상 종료하고 숫자만 안 움직인다.
절단 길이는 시스템마다 다르다:
| 지점 | 절단 |
|---|---|
| 마켓플레이스 A의 외부 SKU 저장 | 20자 |
| 로컬 색인 키(소스 핸들) | 38자 |
| 마켓플레이스 B의 판매자 관리 코드 | 30자 제한 |
"절단됐다"만 알면 부족하다. 몇 자에서 잘리는지가 충돌 범위를 정한다. 같은 데이터가 채널마다 다른 지점에서 잘려 충돌 집합이 서로 다르다.
★★★ 그리고 대책은 줄이는 게 아니라 순서를 바꾸는 것이다
옵션 이름이 25자에서 잘려 모든 옵션이 같은 이름이 됐다.
"Standard (Single Passport) / Green" ← 앞 25자가 전부 동일
"Green / Standard" ← 변별력이 앞으로★★★ 절단은 항상 뒤를 버린다. 그러니 구별에 필요한 것을 앞에 둔다. 길이를 줄이거나 해시를 붙이기 전에 순서를 보라 — 순서만 바꾸면 사람이 읽을 수 있는 이름이 그대로 남는다.
★ 그리고 흔한 관행이 정확히 반대 방향이다. 공통 접두어(규격명·브랜드명·카테고리)를 앞에 두는 명명은 읽기에는 좋고 절단에는 최악이다. 앞에서 자르는 필드와 뒤에서 자르는 필드에 같은 명명 규칙을 쓰지 마라.
키 전개는 조회하는 쪽 전부에 넣는다
접미·접두 전개를 여섯 개 배치 중 다섯에만 넣으면, 빠진 하나는 그 배치만 영원히 미매칭을 낸다. 처방이 정해진 것과 모든 호출 지점에 들어간 것은 별개다. grep으로 조회 함수 호출부를 전부 세고 나서 끝났다고 한다.