B컷전문 | 개발과 인생의 이야기

사내 AI가 정책 변경을 요약한 보고서에 공식 문서 링크를 붙였다. 담당자는 링크가 있다는 이유로 문장을 믿었지만, 원문은 다른 시행일을 설명하고 있었다. 뒤늦게 숫자를 고쳤어도 이미 전달된 보고서와 후속 안내는 그대로 남았다. 필요한 것은 출처 목록만이 아니라 어떤 주장에 어떤 근거를 붙였고, 누가 무엇을 고쳤는지 확인할 수 있는 경로다.

이번 글은 AI가 만든 정보의 출처 확인과 수정 이력을 설계하는 방법을 다룬다. 아래 표와 흐름은 가상 서비스의 설계 예시이며 특정 제품의 기본 기능이나 법적 보존 의무를 뜻하지 않는다. 원문 보관과 개인정보 처리 범위는 조직 규정과 이용 조건을 별도로 확인해야 한다.

1. 링크가 있다는 것과 근거가 맞다는 것은 다르다

검증은 세 단계로 나눈다. 먼저 링크가 실제로 열리는지, 다음으로 발행 주체·문서 버전·기준일이 맞는지, 마지막으로 원문의 해당 구절이 생성된 주장을 뒷받침하는지 확인한다. 최신 문서를 찾았다고 과거 시점의 수치까지 검증되는 것은 아니다. 공식 문서라도 적용 지역, 대상 제품, 단위가 다르면 다른 결론이 나올 수 있다.

W3C의 PROV 개요는 출처 정보(provenance)를 데이터나 결과물을 만드는 데 관여한 대상, 활동, 사람에 관한 정보로 설명한다. 이는 품질과 신뢰성을 평가하는 데 활용할 수 있지만, 이력이 존재한다는 사실 자체가 내용의 정확성을 증명하지는 않는다.

2. 주장 단위로 확인 상태를 남긴다

문단 끝에 링크 다섯 개를 몰아 넣지 말고, 날짜·수치·정책·제품 제약처럼 판단을 바꾸는 주장에 식별자를 붙인다. 직접 확인한 사실, 작성자의 해석, 가상의 예시는 표시를 달리한다.

기록 항목	남길 내용
주장 ID와 내용	claim-01 / 적용 시작일은 11월 1일
근거	원문 URL, 문서 제목·버전, 확인한 절·페이지
시점과 범위	발행일, 관찰 시각, 적용 지역·제품·대상
검증 상태	확인됨 / 일부만 확인 / 상충 / 확인 불가
검토 책임	검토자, 승인 시각, 추가 확인 사유

‘확인됨’은 원문과 범위가 일치할 때만 쓴다. 링크를 못 열거나 수치가 다른 자료와 충돌하면 추측해서 채우지 않는다. 발행에 중요한 주장은 보류하고 담당자에게 확인 요청을 넘긴다. 위험과 불확실성이 높은 사례의 인계 기준은 7화의 사람 개입과 예외 처리와 연결할 수 있다.

3. 최소 이력은 입력·생성·검토·발행을 연결한다

서비스에서는 결과물 ID를 중심으로 입력 문서 버전, 사용한 모델 식별자, 프롬프트 템플릿 버전, 생성 시각, 근거 목록, 검토 결과, 발행 버전을 연결한다. 같은 입력과 설정이 있어도 생성 결과가 반드시 재현되지는 않으므로 실제 산출물도 함께 식별해야 한다. 민감한 입력 원문을 무조건 로그에 복사하는 것은 피한다.

NIST AI RMF Core는 위험 관리를 생애주기 전반에 걸친 지속적 활동으로 다루며 Govern, Map, Measure, Manage 기능으로 구성한다. 다음의 이력 필드는 이를 실무에 적용하기 위한 한 가지 설계안이지 NIST가 지정한 의무 형식은 아니다.

• 입력: 문서 ID·버전과 접근 권한, 필요한 부분만 남긴 근거 위치
• 생성: 결과물 ID, 모델·템플릿 버전, 생성 시각과 처리 상태
• 검토: 주장별 상태, 승인·수정·거절 사유, 검토자
• 발행: 공개 버전, 전달 채널과 대상, 수정 전후 연결

보존 기간과 열람 권한을 먼저 정하고 암호화·삭제·감사 정책을 적용한다. 출처 추적을 이유로 개인정보 전체를 영구 저장하지 않는다. 보존이 허용되는 원문 사본이나 해시가 있더라도 해시는 파일이 달라졌는지 확인하는 수단일 뿐 진실성을 보장하지 않는다.

4. 실전 예시: 정책 시행일을 잘못 안내했다면

가상의 지원 서비스가 시행일을 10월 1일로 안내했지만 공식 정책은 11월 1일이었다고 하자. 오류를 발견한 뒤 화면의 날짜만 바꾸면 이전 안내를 받은 사용자를 놓친다.

1. 관련 주장과 현재 발행 버전을 표시하고 추가 자동 발송을 멈춘다.
2. 공식 정책의 해당 절, 버전과 적용 대상을 다시 확인한다. 상충 자료가 있으면 승인 담당자가 결론을 낸다.
3. 정정본에 이전 값·수정 값·수정 이유·근거·수정 시각을 기록하고 새 버전으로 발행한다.
4. 이전 버전을 받은 대상과 연결된 보고서·알림·캐시를 찾아 영향 범위를 확인한다.
5. 오류가 판단에 영향을 줬다면 같은 전달 채널로 정정 안내한다. 필요한 조치는 조직 정책에 따라 결정한다.
6. 잘못된 주장과 원인을 평가 사례에 추가해 같은 오류를 다음 배포에서 검사한다.

변경 로그는 예를 들어 ‘v1.1: 시행일 10월 1일 → 11월 1일, 정책 문서의 적용일과 공지일을 혼동하여 정정’처럼 쓴다. 맞춤법 수정과 의미를 바꾸는 정정은 구분한다. 과거 오류를 조용히 덮지 않되, 일반 사용자에게 보일 정정 요약과 권한 있는 담당자가 볼 상세 감사 기록은 분리할 수 있다.

5. 자주 실패하는 지점과 점검표

• 링크는 있지만 근거 구절이 없다: 주장을 뒷받침하는 절·표·페이지와 적용 범위를 남긴다.
• 오래된 자료를 최신 사실로 쓴다: 원문 발행일과 관찰 시각, 데이터 기준일을 구분하고 만료 시 재확인을 요구한다.
• 요약을 원문으로 오인한다: AI의 해석과 직접 확인된 사실을 따로 표시한다.
• 정정본만 바꾸고 전달본은 놓친다: 발행 버전별 전달 이력과 의존 산출물을 추적한다.
• 모든 입력을 로그에 쌓는다: 목적에 필요한 식별자와 최소 근거만 보존하고 권한·삭제 정책을 적용한다.

배포 전에는 근거 없는 주장 비율, 주장과 출처의 일치 여부, 상충 자료를 보류하는지, 잘못 전달된 버전의 영향 범위를 찾을 수 있는지 테스트한다. 정정까지 걸린 시간도 측정하되 빠르게 고치려다 추가 오류를 만드는지 함께 살핀다. 검색된 문서와 답변의 연결 품질은 3화의 RAG 검색 품질과 근거 검증에서 이어서 확인할 수 있다.

요약

AI 정보의 신뢰는 링크의 개수가 아니라 주장과 근거의 일치, 시점과 범위, 책임 있는 검토, 추적 가능한 정정에서 만들어진다. 중요한 주장을 단위별로 확인하고 입력부터 발행까지 이력을 연결하자. 오류가 발견되면 새 버전을 만드는 데서 멈추지 말고, 이전 안내를 받은 사람과 후속 산출물까지 정정 경로에 포함해야 한다.

참고 자료

• W3C: PROV Family of Documents 개요
• NIST: AI RMF Core