온톨로지 AI의 ERP 변경 검증: 동시 수정과 재시도 인수 기준

2026년 10월 기준, ERP 변경형 AI는 실행 직전 원장 상태를 다시 확인해야 합니다. 재검증할 수 없으면 자동 반영을 보류합니다.

AI가 주문의 납기를 조회하고 변경안을 만들었습니다. 담당자가 승인하는 사이 다른 직원이 주문을 취소했다면 어떻게 해야 할까요? 처음 읽은 값으로 그대로 쓰면, 승인 당시 의도와 다른 업무 결과가 남을 수 있습니다.

온톨로지는 고객·주문·계약의 관계를 따라 판단 근거를 찾는 데 쓰입니다. 그 판단을 ERP 변경으로 연결할 때는 조회한 데이터와 실제 원장을 구별해야 합니다. 이 글은 그 사이의 차이를 검수하는 제안 설계입니다. 등장하는 주문과 처리 상황은 설명을 위한 가상 예시이며 실제 고객 사례가 아닙니다.

어떤 자동화에 변경 검증이 필요한가요?#

ERP의 주문·재고·담당자 같은 값을 직접 바꾸는 자동화에 필요합니다. 문서 검색이나 답변 초안만 제공한다면 먼저 출처와 접근 권한을 검수합니다. 실제 원장 변경이 생기는 지점부터 승인 시점과 실행 시점의 차이를 확인합니다.

표는 2026년 10월 기준의 설계 구분이며 제품별 지원 기능 비교가 아닙니다. 도구를 누구에게 열지 정하는 단계라면 온톨로지 MCP의 읽기·실행 경계를 먼저 확인하세요. 이 글의 범위는 권한이 있는 요청을 실제로 반영하기 직전과 그 이후입니다.

실행 검수는 왜 최종 데이터까지 봐야 하나요?#

도구 호출이 정상 종료됐다는 기록만으로 업무 완료를 판정할 수 없기 때문입니다. 접수 응답, 대기열 등록, 원장 반영, 외부 알림은 서로 다른 상태일 수 있습니다. 인수 기준에는 원장에 남아야 하는 결과를 적어야 합니다.

Anthropic은 2026년 1월 9일 공개한 에이전트 평가 설계 문서에서 실행 기록과 환경의 최종 상태를 구분합니다. 예약했다고 답한 대화와 데이터베이스에 실제 예약이 있는지는 별도로 확인해야 한다는 관점입니다. 이 글은 그 관점을 ERP 변경 검수에 적용했습니다.

Palantir의 Action types 공식 문서는 업무 규칙에 따라 객체의 속성과 관계를 바꾸는 동작을 설명합니다. 제출 조건 문서에서는 사용자와 객체·관계·입력에 따른 제출 가능 조건을 다룹니다. 이는 해당 제품의 설계입니다. 외부 ERP까지 하나의 트랜잭션으로 묶인다는 뜻은 아닙니다. 두 공식 문서와 평가 문서의 확인일은 2026년 10월 23일입니다.

승인한 변경과 실행할 변경을 어떻게 맞추나요?#

변경 대상·변경 전후 값·판단한 원천 버전·승인 범위를 같은 요청에 연결합니다. 실행 서비스는 실제 변경 시점에 그 조건이 여전히 맞는지 확인해야 합니다. 아래 흐름과 필드는 구축 시 협의할 제안이며 공통 표준이나 Ontokit의 기본 제공 기능을 선언한 것이 아닙니다.

1. 주문 식별자와 원천 시스템을 고정합니다. 고객 이름이나 화면의 행 번호만으로 대상을 찾지 않고 온톨로지 객체와 ERP의 식별자 매핑을 확인합니다.
2. 읽은 버전·조회 시각·변경 전후 값을 변경안에 붙입니다. 값의 근거를 되짚어야 한다면 AI 답변 출처 추적도 함께 설계합니다.
3. 승인한 대상과 값을 요청 내용에 연결합니다. 실행 직전 주문 상태나 값이 달라졌다면 자동으로 승인 범위를 늘리지 않고 새 변경안을 보여줍니다.
4. ERP가 제공하는 조건부 갱신이나 트랜잭션으로 버전 확인과 저장 사이의 경합을 제어합니다. 재조회만 하고 나중에 무조건 저장하면 그 틈에 다시 수정될 수 있습니다. 대응 기능이 없으면 자동 반영 범위를 줄입니다.
5. 요청 ID와 입력 내용을 함께 저장하고, 같은 요청의 재전송은 기존 처리 결과로 연결합니다. 반영 뒤에는 원장 상태를 대조하고 후속 동기화 상태도 별도로 남깁니다.

네트워크가 끊겨 응답을 못 받았다고 저장까지 실패한 것은 아닙니다. 결과를 확인할 수 없는 요청은 결과 불명으로 두고, 원장 조회나 운영자 확인으로 상태를 확정합니다. 같은 작업을 새 요청으로 다시 보내는 방식은 중복 변경을 만들 수 있습니다.

동시 수정과 재시도는 어떤 표본으로 검수하나요?#

정상 변경과 함께 승인 후 변경·응답 유실·입력 충돌·부분 성공을 각각 재현합니다. 모델의 답변, 실행 서비스 기록, 실제 원장 결과를 같은 요청으로 대조해야 합니다. 다음 표는 주문 납기 변경의 가상 인수 매트릭스입니다.

표의 기준일은 2026년 10월 23일이며 모든 행은 자사 제안 설계입니다. 반영 직후 다른 정상 작업이 다시 값을 바꿀 수도 있습니다. 현재 값만 비교하지 말고 요청과 연결된 버전·변경 이력을 함께 확인해야 합니다. 테스트 환경은 각 표본의 시작 상태로 복원해 이전 실행 결과가 다음 검사를 대신 통과시키지 않도록 합니다.

합격 여부는 업무 책임자와 시스템 담당자가 먼저 정합니다. 예를 들어 허가받지 않은 변경을 한 번이라도 저장하면 해당 표본은 실패로 판정할 수 있습니다. 이 기준은 검수 정책의 제안이며 업계 평균이나 측정된 성공률을 뜻하지 않습니다.

어떤 조건에서는 자동 반영을 멈춰야 하나요?#

원장 상태를 확인할 수 없거나 요청 결과를 추적할 수 없다면 승인만으로 자동 반영을 열지 않습니다. 온톨로지의 관계를 정리해도 원천 시스템의 갱신 제약과 외부 부작용이 사라지지는 않습니다.

• ERP에 조건부 갱신·업무 잠금 등 경합 제어 수단이 없다면 조회 결과가 최신이라는 이유만으로 쓰기를 허용하지 않습니다. 담당자의 원장 확인과 수동 반영을 유지할 범위를 정합니다.
• 멱등키를 실행 서비스에만 저장하면 외부 시스템이 이미 처리했는지 모를 수 있습니다. ERP의 요청 식별자·상태 조회 기능과 보존 기간을 확인하고 보장 가능한 범위를 명시합니다.
• ERP 변경과 메시지 발송이 따로 실행된다면 일부 단계만 성공할 수 있습니다. 후속 단계 재처리와 업무 보상을 구분하고, 되돌릴 수 없는 부작용은 운영자에게 보여줍니다.

무조건 재시도하는 정책이나 전체 흐름의 무조건 롤백은 이 문제를 풀지 못합니다. 담당자 이관과 보상 흐름은 AI 워크플로우의 승인·예외 설계와 연결하되, 원장 반영 여부를 먼저 확정하는 절차를 두세요.

알파카랩스와는 어떤 구축 범위를 확인하나요?#

알파카랩스는 공개 서비스 안내에서 업무 개념과 원천 매핑, 출처·권한·현업 검수, AI 연동과 운영 인수 범위를 함께 설계한다고 설명합니다.Ontokit 소개도 원천 시스템을 유지하며 객체·관계와 답변 근거를 연결하는 구축 방식을 안내합니다. 이는 자사의 제공 범위 설명이며 외부 인증이나 자동 변경의 성과 검증은 아닙니다.

이번 주제에서 함께 확인할 질문은 구체적입니다. 어느 원장이 기준인지, 변경 직전 무엇을 검사할 수 있는지, 부분 성공을 누가 정리할지입니다. 원천 시스템 접근과 변경 권한이 확인돼야 실제 연동 가능 범위를 정할 수 있습니다. 위 인수 매트릭스가 모든 시스템에서 기본 제공된다고 가정하지 않습니다.

발주 전에는 온톨로지 업체 선정 기준과 함께 테스트 데이터·검수 증적·운영 책임을 같은 범위로 요청하세요. 비용과 일정은 원천 API, 변경 종류, 복구 조건을 확인한 뒤 협의합니다.

ERP 변경 검증에서 자주 묻는 질문#

온톨로지에 최신 데이터가 있으면 ERP 재조회는 생략해도 되나요?

갱신 지연과 조회 이후의 수정 가능성이 남습니다. 실행 시 원장이 가진 버전·상태와 승인한 조건을 비교해야 합니다. 조건부 갱신을 지원하지 않는 원천은 자동 반영 범위를 제한하고 수동 검수 절차를 둡니다.

사람이 승인한 요청도 다시 승인을 받아야 하나요?

승인 후 대상·값·업무 상태가 바뀌면 기존 승인 범위에 포함되는지 확인합니다. 승인한 내용과 다른 변경이라면 실행을 중단하고 새 변경안을 보여줘야 합니다. 재승인 조건은 업무 책임자와 정합니다.

멱등키를 넣으면 중복 반영이 완전히 없어지나요?

멱등키가 적용되는 범위 안에서 같은 요청을 구분할 수 있습니다. 외부 ERP가 요청 식별자를 저장하거나 결과를 조회할 수 있는지에 따라 보장 범위가 달라집니다. 같은 키에 다른 입력이 오면 충돌로 처리하고 결과 불명 상태를 무조건 재실행하지 않습니다.

에이전트가 성공이라고 답했는데도 실패일 수 있나요?

에이전트 응답과 원장의 최종 상태는 별개입니다. 요청한 대상·값·관련 상태가 실제로 반영됐는지 읽어 확인해야 합니다. 작업은 접수·처리 중·성공·실패·결과 불명 등을 구분해 표시합니다.

ERP 변경 후 알림 전송에 실패하면 변경도 되돌리나요?

ERP 변경과 외부 알림을 하나의 원자적 처리로 가정하지 않습니다. 알림 실패만 재처리할지 업무 변경에 보상이 필요한지 별도 정책으로 정합니다. 복구가 새로운 업무 변경이라면 그 복구에도 권한·검수 기준을 적용합니다.