설계 가이드
식품 제조 AI가 답만 내놓으면 안 되는 이유: 근거를 따라갈 수 있어야 합니다
AI가 “이 업체를 먼저 점검하는 편이 좋겠습니다”라고 답했다고 해볼게요. 설명도 자연스럽고 참고 문서도 붙어 있어요. 그런데 담당자가 그 판단을 회의에 가져가려면 한 가지가 더 필요합니다. 어떤 기록이 우선순위에 영향을 줬는지 직접 확인할 수 있어야 하죠.
아래 내용은 가상의 품질 검토 장면을 바탕으로 한 설계 예시입니다. 특정 고객의 실제 판단이나 성과를 재현한 사례는 아니에요.
설명이 길다고 검증 가능한 것은 아닙니다
“최근 이슈와 과거 이력을 종합했습니다”라는 문장은 이유처럼 들립니다. 하지만 어떤 기간의 어떤 기록을 봤는지 없으면 담당자가 맞는지 확인하기 어렵죠.
화면에서 보여줄 설명은 모델이 내부적으로 생각한 과정을 추측해 적는 글이 아닙니다. 실제로 조회한 자료, 적용한 계산 규칙, 응답에 인용한 근거를 바탕으로 사용자가 검토할 수 있는 설명이어야 해요. 생성된 설명 자체를 판단의 증거로 취급하지 않는 겁니다.
사실·계산·해석의 경계를 나눕니다
가상의 업체 검토 화면을 세 영역으로 나눠보죠. ‘조회된 사실’에는 접수 기록과 조치 상태를, ‘계산 결과’에는 집계 기간과 중복 제외 조건을, ‘AI 해석’에는 그 결과를 어떻게 읽을지 적습니다.
이렇게 나누면 원본 데이터가 틀린 것인지, 계산 규칙이 의도와 다른 것인지, AI가 해석을 과장한 것인지 따로 확인할 수 있어요. “AI가 틀렸다”는 말만 남는 상황을 피하는 데 도움이 됩니다.
같은 기록을 여러 건으로 중복 집계했다면 모델을 바꿔도 문제가 남습니다. 반대로 집계는 정확해도 “증가했다”는 말이 비교 기간의 차이를 무시했다면 설명을 바로잡아야 하죠.
출처는 링크 하나보다 관계가 중요합니다
W3C의 PROV-O는 데이터, 데이터를 다루는 활동, 책임 주체를 구분하고 그 사이의 생성·사용·파생 관계를 표현합니다.[1] 이 관점을 화면 설계에 적용하면 ‘답변에 URL을 붙이기’보다 넓은 질문을 하게 돼요.
이 집계는 어느 원본에서 나왔는지, 어떤 조건으로 계산했는지, 이후 누가 검토했는지를 연결하는 겁니다. 원본 문서 전체를 열어주는 것과 실제로 참고한 항목까지 안내하는 것도 구분해야 하고요.
다만 근거를 연결했다고 정확성이 보장되지는 않습니다. 인용된 문장이 결론을 정말 뒷받침하는지, 다른 예외 조항은 없는지 확인하는 단계가 필요해요.
여덟 행이 다섯 건이 되는 이유를 설명할 수 있나요?
가상의 점검 접수 파일에 8행이 있다고 해볼게요. 이 중 2행은 동일한 사건과 동일한 내용을 다시 전송한 복사본입니다. 중복을 제외하면 고유 사건은 6건이고, 그중 1건은 생산처가 확인되지 않았어요. 확인된 생산처만 대상으로 삼는 이번 집계에는 5건이 들어갑니다.
이 경우 ‘문제 8건’도, 설명 없는 ‘문제 5건’도 충분하지 않습니다. 8은 접수된 행 수이고 5는 이번 조건에 포함한 사건 수예요. 생산처 미확인 1건을 삭제한 것도 아닙니다. 담당자가 연결 관계를 확인할 수 있도록 별도 목록에 남겨야 합니다. 같은 사건의 내용이 다른 두 행이라면 단순 복사본으로 처리하지 말고 수정본인지 충돌인지 먼저 확인하고요.
검토용 결과를 다음과 같이 구성해보세요.
원본 범위: 선택한 기간에 접수된 8행과 해당 파일 버전.
중복 처리: 동일 사건·동일 내용의 재전송 2행을 집계에서 제외.
분석 범위: 생산처가 확인된 고유 사건 5건.
추가 확인: 생산처 미확인 사건 1건. 원본은 보존하고 이번 집계에서만 분리.
결론의 한계: 접수된 사건 수이며, 제품 불량률이나 식품 안전 수준을 뜻하지 않음.
여기에 이전 기간의 4건을 붙였다고 곧바로 “발생률이 25% 늘었습니다”라고 말할 수는 없어요. 이번 기간이 7일이고 이전 기간이 10일이라면 관찰 기간부터 다릅니다. 출하량 같은 업무상 분모도 없다면 발생률을 계산한 것이 아니죠. 생성된 설명은 “서로 다른 길이의 기간에서 5건과 4건이 집계됐으며, 직접적인 발생률 비교는 하지 않았다”는 수준으로 제한하는 편이 정확합니다.
집계 근거를 확인하는 동작도 시험해봅시다. 결과의 5건을 누르면 포함된 사건 ID 다섯 개를 볼 수 있어야 해요. 제외 건수에서는 중복과 미확인을 따로 확인하고, 각 사건에서는 접근 권한 범위 안에서 원본의 해당 위치로 돌아갈 수 있어야 합니다. 원본 파일 전체를 누구에게나 공개하라는 뜻은 아닙니다.
저장할 정보는 한 번의 실행을 식별하는 번호, 조회 조건, 자료 버전, 집계 규칙 버전, 포함·제외 판단을 연결할 식별자 정도부터 정할 수 있어요. 민감한 원문을 일반 로그에 모두 복사하지 말고, 필요한 원본이나 검토용 스냅샷은 보관 기간과 접근 권한을 정해 별도로 관리합니다.
마지막으로 담당자가 미확인 1건을 F-01에 연결한 상황을 넣어보세요. 과거 결과 5건은 당시 조건의 기록으로 남고, 재계산 결과는 6건으로 새로 생겨야 합니다. 두 결과의 차이를 자료 변경과 연결할 수 있다면 추적이 된 것이고, 숫자만 조용히 바뀐다면 아직 연결이 부족한 거예요.
위 숫자와 기록 방식은 검증을 설명하기 위한 자체 예시입니다. 출처 링크가 있다는 사실이나 기록을 남겼다는 사실만으로 계산과 해석의 정확성이 보장되는 것은 아닙니다.
나중에 다시 열어도 당시 조건을 알 수 있어야 합니다
검토 중에 원본 데이터가 수정되면 같은 질문에 다른 결과가 나올 수 있습니다. 그래서 과거 답변을 열었을 때는 당시의 조회 조건과 자료 버전을 보여주고, 현재 자료로 다시 계산한 결과와 구분하는 방식을 권합니다.
담당자가 우선순위를 바꿨다면 최종 상태만 덮어쓰지 않고 변경 이유를 남기도록 설계해요. “AI 제안은 이랬고, 추가 기록을 확인해 사람이 이렇게 조정했다”는 차이가 남아야 이후 검토에도 쓸 수 있습니다.
처음부터 복잡한 감사 시스템을 만들 필요는 없어요. 한 답변에서 원본 항목까지 따라가 보기부터 시작해보세요. 도중에 어떤 연결이 끊기는지 찾는 것이 근거형 AI 설계의 구체적인 출발점입니다.
AI 결과를 보고도 원본을 다시 찾느라 시간이 든다면, 데이터스케쳐스와 답변·근거·검토 이력이 이어지는 방식을 상담해보세요.
참고자료
[1] W3C · PROV-O: The PROV Ontology
데이터·활동·책임 주체와 생성·사용·파생 관계를 구분하는 출처 모델
자료 확인: 2026-10-08. 본문의 가상 상황·화면 구성·점검 절차는 출처의 실제 사례가 아니라 이 글에서 제안한 적용 예시입니다.