ERP에서는 A100, PDF에서는 AS-100인데 AI가 같은 제품인 줄 알까요?

ERP에는 A100-BK, 기술 PDF에는 AS-100, 영업 엑셀에는 에어리스 100 검정, 웹사이트에는 Airless 100 Black이라고 적혀 있습니다. 현장 담당자는 네 이름이 같은 제품을 가리킨다는 사실을 압니다.

AI 검색에는 이 경험이 없습니다. 문자열이 비슷하면 같은 제품이라고 추측하고, 다르면 별개 제품으로 나눌 수 있습니다. 그 결과 재고는 검정 제품을 찾았는데 매뉴얼은 다른 용량의 제품을 가져오거나, 단종된 모델의 사양을 현재 상품 설명에 섞기도 합니다.

이 문제는 프롬프트를 길게 쓰거나 더 좋은 검색 모델로 바꾼다고 해결되지 않습니다. 회사 안에서 네 이름을 같은 제품으로 연결한 근거가 데이터로 있어야 합니다.

이름이 비슷하다고 같은 제품은 아닙니다

제품명은 사람이 읽고 찾기 위한 속성입니다. 같은 제품도 부서와 고객, 국가에 따라 다른 이름을 쓸 수 있습니다. 반대로 이름이 거의 같아도 용량, 재질, 전압이나 국가 인증이 다르면 별개로 관리해야 합니다.

AI가 문자열 유사도만으로 다음 값을 자동 병합하면 위험합니다.

• A100-BK와 A100-WH: 색상만 다른 제품인가, 재질도 다른가
• AS-100과 AS-100R: 개정 모델인가, 별도 호환품인가
• 에어리스 100과 에어리스 100 EU: 설명만 다른가, 인증 사양이 다른가
• 같은 모델의 2025년 생산분과 2026년 생산분: 매뉴얼과 부품이 같은가

제품을 묶는 기준은 이름이 아니라 회사가 승인한 식별 관계여야 합니다. 이름은 바뀔 수 있지만 어떤 제품·변형·배치에 속하는지는 운영 규칙으로 결정해야 합니다.

모든 이름을 바꾸지 말고 연결표를 만듭니다

ERP와 PLM, 영업 파일과 웹사이트의 이름을 하나로 강제하면 기존 주문·도면·고객 문서가 깨질 수 있습니다. 현업이 사용하는 코드는 유지하고, 그 위에 시스템 간 식별 연결표를 두는 편이 안전합니다.

예시의 PRD-004281-BK는 제품의 검정 변형을 가리키는 내부 통합 ID입니다. 어떤 체계를 쓰든 중요한 것은 원래 코드를 지우지 않고, 누가 언제 이 관계를 승인했는지 남기는 일입니다.

외부 유통 식별자가 필요한 제품은 GTIN 같은 표준 키를 함께 사용할 수 있습니다. GS1 체계에서 GTIN은 제품 마스터 데이터에 접근하는 키로 쓰이고, 더 세밀한 추적이 필요하면 배치나 일련번호를 결합합니다.[1] 모든 제조사가 같은 키를 써야 한다는 뜻은 아닙니다. 내부에서도 제품, 변형, 배치와 개별 장비 중 어느 수준을 구분하는지 먼저 정해야 한다는 원칙이 중요합니다.

제품, 변형, 버전을 한 칸에 넣지 않습니다

같은 제품이라는 말도 업무마다 의미가 다릅니다. 영업은 색상과 용량이 다르면 별도 상품으로 보고, 서비스팀은 같은 부품을 쓰는 모델군을 하나로 묶을 수 있습니다. 품질팀은 같은 모델이라도 생산 배치가 다르면 분리해야 합니다.

제품 데이터를 다음 수준으로 나누면 질문의 대상이 분명해집니다.

• 모델: 여러 판매 품목이 공유하는 기본 설계
• 제품·변형: 색상, 용량, 전압, 국가 사양이 확정된 판매 단위
• 버전: 특정 시점부터 적용된 설계나 사양 변경
• 배치: 같은 조건에서 생산되어 품질 이력을 공유하는 묶음
• 개별 장비: 일련번호로 구분되는 실제 한 대

GS1 System Architecture는 모델, 거래 품목, 제품 변형, 배치와 개별 인스턴스를 서로 다른 식별 수준으로 구분합니다.[2] 저는 여기에 버전을 하나 더 둡니다. 같은 변형이라도 설계나 사양이 바뀐 시점부터는 적용되는 매뉴얼과 부품이 달라질 수 있기 때문입니다. 고객이 부품 호환성을 묻는지, 특정 장비의 수리 이력을 묻는지에 따라 AI가 찾아야 할 수준도 달라집니다.

저라면 하나의 제품명 필드에 이 구분을 밀어 넣지 않습니다. 통합 ID 사이의 관계를 따로 두고 이 변형은 이 모델에 속함, 이 버전은 이 날짜부터 적용, 이 배치는 이 버전으로 생산처럼 연결합니다.

속성마다 믿을 원본을 정합니다

통합 제품 ID가 생겨도 값 충돌은 남습니다. ERP에는 판매 중, 웹에는 단종, PDF에는 이전 사양이 적혀 있을 수 있습니다. 이때 AI가 가장 자주 등장한 값을 고르면 안 됩니다.

속성별로 값을 책임지는 원본 시스템과 속성 담당자를 정합니다.

모든 값을 한 데이터베이스로 옮길 필요는 없습니다. 어디에서 읽어야 하는가와 두 값이 다를 때 누가 결정하는가를 연결표에 남기면 됩니다.

저는 충돌을 발견한 AI가 자연스러운 문장으로 하나를 선택하게 두지 않습니다. 판매 상태와 기술 사양처럼 결과에 영향을 주는 값이 다르면 답변을 멈추고, 충돌한 두 값과 원본 위치를 속성 담당자에게 보여주는 편이 맞습니다.

PDF는 제목이 아니라 적용 범위로 찾습니다

문서 폴더에 최종.pdf, 최종2.pdf, AS100_수정.pdf가 함께 있으면 사람도 최신 문서를 확신하기 어렵습니다. 문서를 잘게 나눠 벡터 검색에 넣어도 이 문제는 그대로입니다.

검색할 각 문서에는 최소한 다음 정보가 붙어야 합니다.

• 문서 ID와 문서 종류
• 적용되는 제품·변형·버전 ID
• 개정번호와 승인 상태
• 효력 시작일과 종료일
• 적용 국가와 언어
• 폐기 또는 대체 문서 ID

질문에 나온 제품 ID와 날짜, 국가를 먼저 확정한 뒤 그 범위에 맞는 승인 문서만 검색합니다. 유사한 문장을 찾은 뒤 권한과 버전을 확인하는 순서보다, 검색 후보를 만들기 전에 제외하는 편이 안전합니다.

새 문서가 승인됐을 때는 파일만 추가하면 끝나지 않습니다. 이전 문서의 효력 종료일을 기록하고 검색 색인과 캐시에서도 제외해야 합니다. 그렇지 않으면 AI는 오래된 문서와 새 문서를 모두 근거로 가져옵니다.

AI는 연결을 확정하지 않고 후보를 만듭니다

수천 개 품목의 별칭을 사람이 처음부터 모두 연결하는 일은 오래 걸립니다. AI는 코드, 사양, 문서 문맥과 기존 연결 사례를 보고 같은 제품일 가능성이 높은 후보를 만드는 데 사용할 수 있습니다.

다만 후보와 확정 관계를 분리해야 합니다.

• 코드가 정확히 일치하고 승인 규칙을 통과한 관계
• 사양과 이름이 유사해 제품 담당자 확인이 필요한 후보
• 용량·재질·국가 사양이 충돌해 병합하면 안 되는 후보
• 어느 제품에도 연결되지 않은 문서와 행

제품 담당자가 승인한 관계만 운영 검색과 자동화에 사용합니다. 승인 기록에는 근거가 된 코드와 속성, 승인자와 시점을 남깁니다. 나중에 잘못 연결됐을 때 어떤 답변과 문서가 영향을 받았는지 추적할 수 있어야 합니다.

한 제품군에서 연결 실패부터 셉니다

전 제품을 한 번에 정리하면 연결 규칙을 만드는 동안 현업이 바뀌고 예외가 쌓입니다. 복잡하지만 범위를 통제할 수 있는 제품군 하나로 시작하는 편이 낫습니다.

먼저 다음 숫자를 셉니다.

• 통합 ID에 연결되지 않은 ERP·엑셀 행
• 두 개 이상 통합 ID에 연결된 코드
• 원본 시스템끼리 값이 충돌한 속성
• 승인 상태나 효력일이 없는 PDF
• 단종 제품에 남아 있는 공개 페이지와 검색 조각
• 제품 담당자가 판단해야 했던 연결 후보

그다음 실제 질문으로 확인합니다. AI가 제품을 하나로 특정했는지, 질문에 맞는 변형과 버전을 골랐는지, 유효한 문서만 사용했는지, 값 충돌에서 멈췄는지 평가합니다.

정답률만 보고 제품 연결 문제를 숨기면 모델을 바꿀 때마다 같은 오류를 다시 만납니다. 미연결·중복·충돌·폐기 문서의 수를 함께 관리해야 데이터가 나아졌는지 알 수 있습니다.

AI가 제품을 알기 전에 회사가 제품을 연결해야 합니다

ERP 코드, PDF 모델명, 영업 별칭과 웹 상품명은 서로 달라도 됩니다. 억지로 한 이름으로 바꾸는 것이 목표가 아닙니다. 네 값이 어느 제품·변형·버전을 가리키는지 회사가 승인한 연결 관계로 설명할 수 있어야 합니다.

검색 모델을 바꾸기 전에 한 제품군의 식별 연결표부터 만드세요. 속성별 원본과 속성 담당자를 정하고, 문서에 제품 ID·버전·효력일을 붙입니다. AI는 연결 후보를 빠르게 만드는 데 쓰되 확정은 제품 담당자가 합니다.

이 기반이 없으면 AI는 회사 안의 불일치를 자연스러운 문장으로 감춰 보여줍니다. 기반이 생기면 어떤 모델을 쓰더라도 같은 제품과 유효한 근거를 기준으로 답을 비교할 수 있습니다.

출처

• [1] https://ref.gs1.org/standards/lightweight-verification-messaging/1.1.0/ — GS1, Lightweight Messaging Standard for Verification of Product Identifiers(2026년 8월 16일 확인)
• [2] https://ref.gs1.org/architecture/system-architecture/ — GS1, GS1 System Architecture(2026년 8월 16일 확인)