데이터의 유일성(Uniqueness) 관리

당연한 얘기겠지만, 데이터는 유일성을 가지며 관리되어야 합니다. 그런데 리스트에서 전달되는 상품들은 말 그대로 상품의 정보들만 전달되고, id나 고유값 같은 유일성을 판단할 수 있는 값이 없어 직접 추론해야만 했습니다.

추론 결과 상품의 코드 역할을 하는 값을 pcode라 정의하고, 이 pcode와 색상값을 합쳐 unique한 id로 잡기로 결정했습니다. 즉 "pcode+색상"이 상품 데이터의 유일성을 결정하는 것입니다. 예를 들어 위 케이스의 경우 MODELLO 필드와 COLORE 필드를 읽어 "8001236 A2442" 로 유일성을 판단합니다.

리스트, 파서의 신뢰도 문제

문제는 엑셀 파일에서 파싱한 데이터들이 정확하지 않다는 점에 있었습니다. 이번 리스트에서 작업한 상품은 다음에 작업할 필요가 없어야 고유성 관리에 의미가 있는데 상품코드가 매우 중구난방인 상태였습니다.

노이즈 : "Z12135 0001", "Z1213**.**5 0001"

pcode가 분리되거나 일부만 전달 : "201W3104 RED", "201W3104501199 RED"

그들만의 약자 사용 : "BB50B1B0UC BLACK", "BB50B1B0UC BLK"

전산화가 안되어 수기로 옮기다가 생긴것으로 추정 : "AAA8", "AAAB"

컬러코드 : "H00025430 BLACK 001", "H00025430 001", "H00025430 BLACK"

리스트 자체뿐만 아니라 파싱을 하는 개발자가 각 명품 브랜드의 고유 넘버 방식을 숙지하지 못한 채 그때그때 필드명, 눈썰미 등으로 어떤 필드를 유니크 용도로 사용할지 결정 후 업로드를 하기 때문에 잘못된 케이스도 많았습니다.

결국 이러한 엣지 케이스를 체크하지 못한채 수만개의 상품을 자동 파싱 업로드를 시키고 있었습니다.

중복 상품 발생

그래서 사실은 같은 상품인데 중복 업로드된 케이스가 다수 발견되었습니다. 상품 업로드 담당 인원들은 워낙 많은 상품을 추가하기 때문에 자신이 같은 상품을 반복 등록하고 있다는 사실을 나중에야 알게 되었습니다. 리스트 전달 후 빠른 상품 업로드 및 노출이 이 서비스의 핵심인데, 이러한 이슈는 매우 크리티컬한 이슈였습니다.

첫번째로 기존에 있는 중복 상품들을 찾기 위해 시스템에 있는 상품코드들을 문자열 유사도(levenshtein distance) 계산을 통해 체크하여 중복 상품들을 병합하는 방법을 고려했습니다. 하지만 유사도 기록 데이터의 용량, 매우 낮은 퍼포먼스 이슈가 많았습니다.

결국 완전 자동화에는 실패하고 유일성 판단 값들을 네 필드에 나누어 저장 후(pcode 분석 필요, 후술), 상품마다 이 필드들 기준으로 추론하여 의심되는 중복 상품 케이스를 모두 조회하여 수동으로 병합할 수 있는 페이지를 작업하여 제공했습니다.

pcode 분석 프로세스의 필요성

또한 상품 업로드시에도 pcode를 사람이 검수하는 프로세스를 피할수 없다고 판단, 처음 시스템에 들어오는 상품코드를 모두 분석하여 알맞게 정정 및 4개 필드에 나눠서 기록하는 프로세스 및 페이지를 작업하여 제공하는 방향으로 픽스했습니다.