AI 답변에 출처가 있어도, 확인은 끝나지 않는다

AI 답변에 출처가 붙어 있으면 먼저 그 링크를 열어 주장과 원문의 관계를 살펴야 한다. 관련 페이지라는 사실만으로 비용과 지원 범위, 자신의 환경에 대한 결론까지 확인된 것은 아니다. 문장 안의 주장을 나누고 각 주장에 필요한 근거를 연결하는 방법을 다룬다.

NIST의 생성형 AI 위험관리 프로파일은 그럴듯하지만 잘못된 내용을 생성할 수 있는 위험을 다룬다. 중요한 것은 AI 답변을 모두 틀렸다고 취급하는 것도, 문장이 매끄럽다는 이유로 맞다고 간주하는 것도 아니다. 어떤 주장에 어떤 확인이 필요한지 나누는 것이다.

답변을 문장보다 작은 주장으로 나눈다

‘이 기능은 모든 팀에서 쓸 수 있고 추가 비용 없이 자동으로 적용된다’는 문장을 생각해 보자. 여기에는 지원 대상, 비용, 적용 방식이라는 세 주장이 들어 있다. 문장 전체에 링크가 하나 달려 있어도 그 링크가 세 주장을 모두 확인해 주는지는 별도로 봐야 한다.

검토할 때는 핵심 주장마다 원문 위치와 적용 조건을 적는다. 날짜, 수치, 대상, 비용, 예외처럼 잘못됐을 때 결론을 바꾸는 요소를 우선 살핀다. 문장의 표현을 고치는 작업과 사실을 확인하는 작업은 분리한다.

이 표는 실제 서비스 평가 결과가 아니라 검토 구조를 보여주는 설명용 예제다. 실제로 쓸 때는 각 칸에 서비스의 원문과 자신의 환경을 넣어야 한다.

링크를 열고 관련 문장이 있는지 확인한다

연결된 페이지의 제목만 보지 않는다. 답변이 주장한 내용이 본문 어느 위치에 있는지 찾고 앞뒤 문장을 읽는다. 제품 소개 페이지가 연결됐어도 그 페이지에서 지원 조건이나 비용이 확인되지 않으면 해당 주장은 여전히 미확인일 수 있다.

원문이 여러 언어로 제공된다면 문서의 확인 시점과 적용 범위를 살핀다. 서로 다른 버전이나 오래된 안내가 섞여 있는지 확인하고, 날짜가 불분명하면 그 한계를 기록한다. 검색 결과의 짧은 설명만으로 세부 조건을 확정하지 않는다.

원문에서 ‘가능하다’는 표현을 찾았다고 ‘항상 된다’로 확대해서는 안 된다. 기능 지원과 계정 활성화, 지원 기기와 실제 설정은 별개다. 원문 문장에 조건절이나 제한 항목이 있으면 답변에도 그 의미가 남아야 한다.

주장 하나를 확인하는 데 필요한 증거를 좁혀 본다

가상의 답변이 ‘이 도구는 PDF를 지원하므로 우리 계약서 80개를 추가 결제 없이 한 번에 검토할 수 있다’고 말했다고 하자. PDF 지원 문서는 첫 부분의 근거가 될 수 있다. 하지만 파일 개수, 한 번에 처리할 분량, 계정의 요금제, 계약서에서 필요한 정보의 추출 정확도까지 그 문서 하나로 확인되지는 않는다. 답변의 접속사 ‘그러므로’ 뒤에 검토되지 않은 결론이 붙은 셈이다.

먼저 ‘PDF 업로드 지원’에는 형식 안내를, ‘80개 동시 처리’에는 개수 제한을, ‘추가 결제 없음’에는 해당 계정의 이용 조건을 연결한다. 마지막 ‘계약서 검토 가능’은 어떤 작업을 뜻하는지 다시 정한다. 계약 날짜 추출과 조항의 법적 판단은 필요한 자료와 책임이 다른 작업이다. 이렇게 분리하면 일반 기능 소개를 자신의 업무 전체에 대한 근거로 쓰는 실수를 줄일 수 있다.

확인한 사실을 문장에 옮길 때는 범위를 줄여 쓰면 된다. ‘공식 안내에 PDF 업로드 지원이 명시되어 있다. 우리 계정의 동시 처리 한도와 계약서 항목 추출 결과는 별도 확인이 필요하다’는 표현은 덜 호쾌하지만, 다음에 무엇을 해야 하는지 분명하다. 근거가 있는 앞부분까지 버릴 필요도 없다.

근거 기록에 원문 전체를 복사할 필요는 없다. 문서 제목, 해당 절, 확인 날짜, 자신의 해석을 남기면 된다. 실제 값을 확인하지 못한 항목에는 예상 숫자를 넣지 않는다. 검토 과정에서 찾은 다른 기능의 제한을 현재 기능에 잘못 적용하지 않았는지도 살핀다.

두 문서의 내용이 다를 때는 적용 대상을 먼저 맞춘다

오래된 안내와 새 안내가 다르다면 게시 날짜만 비교하기 전에 제품명, 계정 종류, 기능 이름을 맞춘다. 개인용 앱의 문서와 개발자용 API의 문서는 같은 브랜드 아래 있어도 서로 다른 대상일 수 있다. 앞선 문서가 틀렸다기보다 적용 대상이 다른 경우다.

현재 계정의 조건을 확인할 수 있는 원문이 없다면 그 지점에서 미확인으로 남긴다. 추측을 단정형 문장으로 바꾸면 다음 사람이 확인이 끝난 정보로 받아들인다. 반대로 근거와 미확인 항목을 구분해 두면 필요한 추가 자료를 정확히 요청할 수 있다.

마지막으로 제목에도 같은 범위를 적용한다. 본문은 ‘일부 환경에서 지원’이라고 쓰면서 제목에 ‘모든 PDF 분석 가능’이라고 적으면 독자는 가장 넓은 주장을 먼저 읽게 된다. 제목, 도입, 결론에 같은 적용 범위가 유지되는지까지 보는 것이 공개 전 검토다.

원문에 없는 결론과 계산을 구분한다

공식 안내에서 직접 확인한 사실, 그 사실을 바탕으로 계산한 값, 여러 사실을 연결해 내린 판단을 나눠 표시한다. 계산에는 입력값과 단위를 남기고, 판단에는 어떤 조건에서 결론이 성립하는지 적는다.

예를 들어 문서가 파일 업로드를 지원한다고 설명한 것과 ‘우리 팀의 모든 PDF를 오류 없이 분석할 수 있다’는 결론은 거리가 있다. 두 번째 문장을 쓰려면 실제 파일 종류와 처리 범위에 대한 추가 확인이 필요하다. 출처가 있는 일반 기능 설명을 자기 환경의 성공 보증으로 바꾸지 않는다.

Microsoft의 Copilot 출력 검증 안내는 결과를 사용하기 전에 검토하는 과정과 단순한 문장 다듬기를 구분한다. 이를 실제 작업에 적용할 때도 AI에게 ‘더 자연스럽게’ 바꾸라고 요청한 뒤 사실 확인이 끝났다고 생각하지 않아야 한다.

AI에게 재검토를 맡겨도 독립 확인은 남는다

AI에게 주장 목록을 만들게 하거나 원문과 다른 부분을 표시하게 할 수 있다. 이 작업은 검토 대상을 찾는 데 도움이 되지만, 같은 도구의 재답변이 스스로 정확성을 인증하는 것은 아니다. 중요한 수치와 조건은 원자료에서 직접 대조한다.

다른 모델이 같은 답을 했다는 사실도 독립적인 근거 문서가 생겼다는 뜻은 아니다. 두 답변이 같은 잘못된 자료를 바탕으로 했을 수 있다. 의견이 일치하는지보다 실제 근거가 무엇인지 확인해야 한다.

출처를 찾지 못했다면 문장을 지우거나 ‘확인되지 않았다’고 남기는 선택이 가능하다. 답변의 모든 빈칸을 그럴듯한 설명으로 채울 필요는 없다. 업무에서 중요한 것은 완결된 모양이 아니라 사용할 수 있는 상태를 정확히 구분하는 것이다.

공유할 때는 검토한 범위를 남긴다

검토를 마친 자료에는 근거를 확인한 날짜와 문서, 아직 해결하지 못한 항목을 남긴다. 전체 답변을 ‘검증 완료’라고 표시하기보다 지원 범위 확인, 비용 미확인, 계산 재확인처럼 상태를 나누면 다음 사람이 판단하기 쉽다.

원자료가 변경되거나 입력 문서가 바뀌면 이전 검토의 결과를 그대로 가져오지 않는다. 무엇이 바뀌었는지 확인하고 영향받는 주장부터 다시 살핀다. AI 출력의 버전 관리는 입력과 결과를 연결해 보관하는 방법을 다룬다.

요약 자료를 검토하는 상황이라면 요약에서 빠진 조건 찾기를 함께 볼 수 있다. 원문에 맞는 개별 문장도 중요한 조건을 빠뜨리면 전체 결론을 오해하게 만들 수 있기 때문이다. 출처 대조와 범위 대조는 서로 보완하는 작업이다.