온톨로지 상품 대체 관계 설계: 단종품과 호환품을 AI가 구분하는 법

온톨로지 상품 대체 관계 설계는 원품과 대체 후보를 별도 품목으로 유지하고, 어느 제품의 어느 사용 조건에서 누가 대체를 승인했는지 관계에 기록하는 일입니다. A를 B로 바꿀 수 있다는 기록만으로 B를 A로 바꾸거나 A를 C로 바꿀 수 있다고 답하면 안 됩니다. AI에는 후보와 확인된 근거를 보여 주는 역할을 맡기고 실제 사용 승인은 회사의 기술 책임자가 내립니다.

단종 공지가 도착하면 구매팀은 후속 모델 목록을 찾고 설계팀은 도면과 시험 기록을 확인합니다. 같은 제조사 카탈로그에 후속 모델이라고 적혀 있어도 기존 설비의 모든 위치에 바로 쓸 수 있다는 뜻은 아닙니다. 장착 공간, 연결 규격, 사용 환경, 고객의 승인 조건 중 하나만 달라도 답이 달라집니다. 검색 시스템에 두 품목의 이름을 별칭처럼 묶어 두면 이런 조건이 사라진 채 예전 부품의 설명과 새 부품의 성능이 섞일 수 있습니다.

이 글의 A·B·C 품목과 제품 P·Q, 시험 기록 및 기간은 관계 모델을 검토하려고 만든 가상 예시입니다. 실제 부품의 호환성이나 안전성을 뜻하지 않습니다. 다룰 범위는 조건부 대체 관계를 표현하고 AI 답변을 검수하는 구간입니다. BOM 전개, 부족 재고 계산, 대체 재고 합산과 구매 주문 실행은 별도 ERP 요구사항으로 남깁니다. 품목을 정확히 찾는 문제와 찾은 품목을 실제로 써도 되는 문제를 구분해 발주 범위를 정하세요.

발주 전에 기술팀과 구매팀이 함께 최근 대체 문의를 몇 건 골라 답이 갈린 이유를 적어 봅니다. 품목명만으로 답할 수 없었던 질문, 도면 판번호가 빠져 보류한 질문, 고객 확인을 기다린 질문이 좋은 표본입니다. 정답 문장만 전달하지 말고 어떤 자료가 있어야 답을 허용할지 함께 기록해야 합니다. 기술 책임자가 아직 판정하지 않은 사례는 미합의 표본으로 유지하며 개발자가 그 빈칸을 임의 기준으로 채우지 않습니다.

W3C 표준은 관계의 의미를 설명하며 호환성을 인증하지 않는다#

2026년 11월 3일 W3C OWL 2 Primer 원문을 확인했습니다. 개체 동일성과 대칭·추이 같은 관계 특성은 서로 다른 의미입니다. 이 글의 대체 판단 레코드, 승인 흐름과 검수표는 회사 업무를 위한 설계 제안입니다. 표준 문서가 특정 부품의 호환성이나 기술 승인을 보장하지는 않습니다.

• W3C OWL 2 Primer: 개체 동일성, 관계 특성 및 열린 세계 가정의 의미를 확인하는 공식 자료.

질문에 문맥이 없으면 확인부터 요청한다#

사용자가 A 대신 무엇을 쓰면 되느냐고 물었을 때 바로 B를 추천하는 시연은 충분하지 않습니다. 제품과 도면판, 적용 위치가 빠졌다면 어떤 정보가 필요한지 묻는 답이 기대값입니다. 사용자가 제품 P라고 답한 뒤에도 관계 R1의 승인 상태와 유효기간을 확인해야 합니다. 결과에는 후보 B와 허용된 사용 문맥, 근거 문서 판번호를 함께 표시하세요. 기술 검토가 끝나지 않은 후보는 승인된 후보와 같은 목록에 섞지 않고 검토 대기라는 상태를 드러냅니다.

방향 검수는 같은 두 품목의 순서를 바꿔 질문하는 방식으로 합니다. R1이 A에서 B로의 대체만 승인했다면 B 대신 A를 쓸 수 있느냐는 질문에는 역방향 승인 근거가 없다고 답해야 합니다. 이를 모든 상황에서 역방향이 불가능하다는 사실로 확대해서도 안 됩니다. 정보 부족과 명시적 금지는 다른 상태입니다. 별도의 역방향 승인이 등록될 수 있는 업무라면 관계 전체를 일괄 비대칭으로 선언하는 방식도 신중히 검토해야 합니다.

연쇄 질문에는 A에서 B로의 승인과 B에서 C로의 승인을 함께 넣습니다. 두 판단이 있어도 A에서 C로의 직접 대체 승인은 저절로 생기지 않습니다. 제품 문맥이나 시험 조건이 다를 수 있기 때문입니다. 화면에서 경로를 보여 줄 수는 있지만 후보 탐색 경로와 사용 승인 관계의 표시를 구분하세요. 관계를 따라 이동하는 조회 옵션이나 AI의 요약 규칙이 승인 조건을 건너뛰지 않는지 실제 질의 결과와 답변을 나란히 보며 검사합니다.

유효기간은 문서 작성일과 구분합니다. 가상 R1이 특정 기간에만 유효하다고 정했다면 사용자가 과거 시점의 근거를 묻는지 현재 사용 가능성을 묻는지부터 판별해야 합니다. 과거 조회는 당시 관계판과 근거를 보여 주되 지금도 쓸 수 있다는 문장을 붙이지 않습니다. 회사가 정한 기준 시각과 시간대를 저장하고 종료 시각의 포함 여부도 합의하세요. 만료를 앞둔 관계를 누가 재검토할지 정하지 않으면 만료 뒤 운영자가 임시로 상태를 되돌리는 우회가 생깁니다.

문서가 철회되거나 시험 결과에 문제가 생기면 해당 근거를 쓰는 관계를 찾아 보류합니다. 관계를 지우면 과거 답변이 왜 나왔는지 설명하기 어려워지므로 철회 사유와 영향받은 관계판을 남깁니다. 이미 만들어진 검색 색인, 요약 저장본과 답변 캐시도 점검 대상입니다. 원장 상태만 보류로 바뀌고 검색 결과는 옛 승인 문구를 보여 줄 수 있습니다. 각 조회 경로가 같은 승인판을 읽는지 확인하고 최신 상태를 확인할 수 없을 때는 사용 가능 답변을 멈추게 합니다.

운영자에게 문서를 수정할 권한과 대체를 승인할 권한을 함께 줄 필요는 없습니다. 자료 등록자는 새 판을 제안하고 기술 책임자는 적용 문맥을 검토해 승인하는 식으로 나눌 수 있습니다. 회사 규모에 따라 한 사람이 두 역할을 맡더라도 어떤 역할로 무엇을 바꿨는지 이력에 남겨야 합니다. 대량 가져오기와 연동 API로 등록된 관계도 같은 승인 상태를 거치도록 하세요. 화면에서만 승인 버튼을 숨기고 연동에서는 승인 완료값을 그대로 받는 제안은 우회 경로를 남깁니다.

정답·보류·금지 질문을 같은 평가 묶음으로 인수한다#

검수표의 담당자는 답변을 읽은 사람과 기술 판단을 승인한 사람을 구분합니다. 후보가 잘 검색됐다는 검토 의견만으로 기술 승인을 완료하지 않습니다. 문서판을 확인한 시각과 적용 문맥, 미해결 질문을 남기면 승인 담당자가 바뀐 뒤에도 어떤 판단이 남아 있는지 인수할 수 있습니다. 출처를 열 수 없는 평가 표본은 정상 성공으로 세지 않습니다.

인수 표본에는 정상 질문 외에 제품 누락, 다른 도면판, 역방향, 연쇄 대체, 만료와 철회 근거를 넣습니다. 가상 R1의 조건을 모두 만족하는 질문에는 후보 B와 판단 R1의 근거를 보여 주는 것이 기대값입니다. 제품 Q를 넣으면 P의 승인을 가져오지 않아야 하고 원품 식별이 모호하면 품목 확인부터 요청합니다. 승인자가 없는 관계는 검토용으로 남아야 합니다. 이 기대값은 현업이 먼저 확인하고 개발팀이 실행 결과를 연결합니다.

평가 결과에는 최종 문장 외에 질문에서 추출한 품목과 문맥, 조회한 관계판, 적용한 제외 조건, 참고한 문서판을 남깁니다. 답이 틀렸을 때 품목 식별 문제인지 조건 검사 문제인지 문장 생성 문제인지 구분할 수 있어야 고칠 범위가 정해집니다. 일부러 근거가 충돌하는 표본도 준비하세요. 서로 다른 판의 승인과 금지가 겹쳤다면 회사가 정한 우선순위를 적용하거나 충돌 상태로 보류하며 모델이 마음에 드는 문서 하나를 고르게 두지 않습니다.

잘못 게시한 관계를 되돌릴 때는 원품·후보와 문맥이 같은 직전 승인판을 찾고 현재도 그 근거가 유효한지 확인합니다. 과거에 승인됐다는 이유만으로 만료된 판을 복원하면 안 됩니다. 복구 가능한 판이 없으면 보류 상태로 유지하고 기술팀의 재검토로 넘깁니다. 복구 뒤에는 정상 질문과 역방향·연쇄 질문을 다시 실행해 조회와 답변이 같은 판을 사용하는지 확인합니다. 관계 등록자와 다른 운영자가 이 절차를 수행할 수 있어야 합니다.

업체에 받을 자산은 관계 정의서, 입력 필드와 상태표, 승인 역할표, 근거 문서 연결 규칙, 질문별 기대값과 실행 결과입니다. AI 설명을 끄더라도 담당자가 품목과 문맥으로 승인 근거를 직접 찾을 수 있는지도 인수 조건에 넣으세요. 답변 실패 때 기존 기술 검토 절차로 돌아갈 연락 경로가 필요합니다. 기술 책임자의 실제 대체 승인을 자동화 범위에 넣으려면 별도 위험 검토와 회사의 명시적 결정이 선행돼야 하며 이 글의 모델만으로 그 승인을 대신할 수 없습니다.

같은 품목의 중복 식별 문제는 온톨로지 엔터티 해소 설계에서 따로 다룹니다. 승인 뒤 재고 조회와 연결할 범위는 제조 부품 재고 ERP를 참고하세요. 공통 스키마 변경은 온톨로지 스키마 버전 관리와 구분해 계획합니다.