은행 화면을 닮은 이미지나 직인이 있는 PDF를 받으면 거래가 확인됐다는 느낌이 든다. 하지만 외형이 그럴듯한지, 누가 만든 파일인지, 내용이 바뀌었는지, 실제 돈이 이동했는지는 서로 다른 질문이다.
기업 리서치에서도 계약서·청구서·납품 자료·수금 확인을 같은 증거로 취급하면 사업의 단계를 잘못 읽게 된다. 자료에 붙은 신뢰 표시보다 그 자료가 무엇을 입증하는지 먼저 확인한다.
파일이 진본이라는 확인은 그 파일의 출처와 변경 여부에 관한 근거다. 파일 안에 적힌 거래가 실제로 끝났다는 결론에는 거래 자체의 근거가 필요하다.
1. 모양에서 출처와 확인 경로로 넘어간다
로고·서명 이미지·표의 배치는 누구나 보고 따라 만들 수 있다. 오탈자가 없다는 사실이나 AI가 자연스럽다고 평가한 결과만으로 발행 기관과 실제 거래를 확인할 수는 없다.
어디서 받은 자료인지, 직접 확보한 원본인지, 다른 사람이 전달한 사본인지 구분한다. 파일에 적힌 연락처나 링크만 따라 확인하면 같은 자료가 만든 확인 경로 안에서 돌아올 수 있다. 확인 대상이 제공한 주장과 별도로 확보한 공식 경로를 나눈다.
2. 서명과 변경 확인이 말해 주는 범위를 읽는다
C2PA의 콘텐츠 출처 설명은 디지털 콘텐츠의 출처·이력과 변경 여부를 확인하는 정보가, 그 콘텐츠의 사실성까지 판정해 주지는 않는다고 설명한다.
문서의 서명이나 출처 정보를 검증했다면 누가 무엇에 서명했는지, 어떤 부분과 시점까지 검증됐는지 읽는다. 서명 전에 잘못 입력한 금액이나 사실과 다른 설명이 있었다면 변경 방지가 그 내용을 바로잡아 주는 것은 아니다.
출처 정보가 없다는 이유만으로 가짜라고 확정할 수도 없다. 확인 수단의 부재와 위조를 발견한 결과는 다르다. 검증 표시가 있어도 그 표시의 대상과 범위를 확인한다.
3. 거래의 단계를 하나의 ‘완료’로 묶지 않는다
지급을 요청한 상태, 처리 중인 상태, 지급 계좌에서 출금된 상태와 수령 계좌에 반영된 상태는 구분해서 읽는다. 취소·반환이나 수수료가 있었다면 최종 결과도 달라질 수 있다.
아래는 실제 자료를 볼 때 나누어 확인할 질문이다. 특정 문서 양식이 모든 금융기관에서 같은 의미를 갖는다는 뜻은 아니다.
받은 자료 | 그 자료와 별도로 확인할 질문 |
|---|---|
계약서 | 조건이 충족됐고 계약이 실행됐는가? |
청구서 | 고객이 청구를 받아들였고 실제 지급했는가? |
지급 요청 화면 | 요청이 처리돼 거래 기록에 반영됐는가? |
출금 기록 | 대상 수령인·통화·금액이 맞고 반환이 없는가? |
수령 기록 | 주장한 거래와 같은 건이며 최종 수령액이 맞는가? |
금액이 같아도 다른 날짜의 거래나 다른 수령인의 기록일 수 있다. 식별자·날짜·당사자·통화·금액을 함께 대조한다.
4. 자료 개수보다 확인 경로의 독립성을 본다
한 사람이 만든 PDF와 그 PDF를 캡처한 이미지, 같은 내용을 옮긴 이메일은 세 개의 파일이다. 그러나 독립된 세 번의 거래 확인은 아닐 수 있다.
반대로 공식 거래 기록과 상대방의 수령 기록을 같은 식별자로 연결하면 서로 다른 방향에서 확인할 수 있다. 실제 확보한 자료가 한쪽뿐이라면 그 범위 안에서 결론을 남긴다.
AI는 날짜·금액·식별자와 불일치 후보를 정리하는 데 쓸 수 있다. 원장에 접근해 대조하지 않았는데 거래가 끝났다고 채우게 하지 않는다. 읽은 자료의 정리와 새로운 사실의 확인은 별도 단계다.
5. 필요한 주장에 맞는 증거를 남긴다
‘계약이 존재한다’, ‘매출로 인식했다’, ‘현금을 받았다’는 서로 다른 주장이다. 각 주장 옆에 확인한 자료·시점·범위와 아직 남은 조건을 적는다. 자료가 엇갈리면 정상 거래나 사기 중 하나로 성급히 확정하지 않고 차이를 먼저 조사한다.
모든 자료를 무조건 더 모으는 방식도 효율적이지 않다. 판단에 필요한 항목을 정하고, 관계없는 개인정보를 가린 상태에서도 필요한 대조가 가능한지 살핀다.
좋은 증빙 검토는 파일을 믿을지 말지에서 끝나지 않는다. 그 파일을 근거로 어디까지 말할 수 있는지 정하는 일이다. 문서의 신뢰와 거래의 완료를 분리하면 같은 자료에서 과도한 결론을 만드는 일을 줄일 수 있다.