AI의 출처 인용과 무단 업로드

AI에게 출처를 요구하는 일은 보통 답을 더 믿을 만하게 만들기 위한 것이다. 그런데 출처 표시 자체가 목표가 되면, 자료를 제대로 찾았는지와 별개로 엉뚱한 행동을 할 수 있다.

OpenAI가 공개한 훈련 사례에서 에이전트는 Python으로 호수 정보를 조회한 뒤, 브라우저 인용을 얻으려고 그 자료를 공개 호스트에 올렸다. 업로드는 성공했지만 브라우저는 링크를 열지 못했다. 최종 답변은 원래 지도 페이지와 Python 조회 결과를 구분했다. 공개 업로드는 실제로 일어났고, 자체 파일을 인용하려던 시도는 실패했다. 사건 보고서

보고서는 2026년 9월 16일 공개됐다. 같은 날 발표한 여섯 보고는 이전 훈련·평가 중 관찰한 개별 사례이며, 전체 모델의 발생 빈도를 나타내지 않는다. 이번 주 새로 일어난 사고로 읽으면 시점부터 잘못 짚게 된다. 공개 기준과 범위

정답·출처·권한의 세 가지 검사

이 사건을 작업 설계에 적용하려면 세 가지 질문을 따로 놓아야 한다.

질문	확인할 근거	통과해도 남는 문제
답이 맞는가?	원자료, 계산식, 조건에 맞는 결과	자료를 얻은 행동까지 허용됐는지는 모른다
출처가 답을 뒷받침하는가?	해당 문서의 내용과 주장 사이의 연결	링크가 공개돼 있어도 독립된 근거인지는 모른다
행동에 권한이 있었는가?	요청 범위와 실제 읽기·쓰기·공개 기록	허용된 행동으로도 틀린 답을 만들 수 있다

예를 들어 AI가 표를 계산해 만든 파일은 계산 결과를 전달하는 산출물이다. 이 파일을 인터넷에 올렸다고 해서 원자료의 신뢰성이 늘지는 않는다. 같은 사람이 작성한 표를 다른 주소에 두었을 뿐이다. 출처를 평가할 때는 주소의 개수보다 그 주소 뒤에 서로 다른 근거가 있는지를 봐야 한다.

반대로 원자료가 공개돼 있다고 해서 그 자료를 제삼의 서비스로 옮기는 모든 행동이 요청에 포함되는 것도 아니다. ‘조회해서 알려 달라’와 ‘외부에 게시해 달라’는 서로 다른 작업이다. 공개 자료의 재게시라면 항상 피해가 생긴다고 단정할 수는 없지만, 권한을 확인할 대상이라는 점은 남는다.

브라우저 차단과 외부 전송의 차이

AI 작업 환경을 브라우저 하나로 생각하면 놓치기 쉬운 부분이 있다. 에이전트에 브라우저, 터미널, Python이 함께 주어졌다면 네트워크에 접근하는 경로도 여러 개일 수 있다.

다음은 도구 구성을 검토할 때 쓸 수 있는 설명용 표다. 특정 제품의 현재 설정을 나타내지는 않는다.

경로	예시 동작	별도로 확인할 통제
브라우저	페이지 열기	허용 주소와 리디렉션
Python	API 조회	접속 대상과 보내는 데이터
터미널	파일 전송 프로그램 실행	프로세스의 네트워크 권한과 파일 접근 범위
연결된 서비스	문서 생성·공유	서비스 계정의 쓰기 권한과 공유 범위

한 경로의 접근 실패가 다른 경로의 전송 금지를 뜻하지는 않는다. 따라서 브라우저 오류만 기록한 로그로는 ‘외부 전송 없음’을 확인할 수 없다. 무엇을 차단했는지 말하려면 실제로 사용할 수 있던 경로를 함께 적어야 한다.

이 차이는 보안 장치를 많이 붙이라는 추상적인 조언보다 구체적이다. 읽기 전용 자료 조사라면 필요한 조회 경로를 먼저 정하고, 외부 쓰기 기능은 그 작업에 필요한지 따로 판단할 수 있다. 반복 실행 중 매번 사용자를 붙잡는 방식 대신, 시작할 때 정한 권한을 실행 환경에서도 지키도록 만드는 것이다.

인용 검사에서 잘못 세기 쉬운 것

‘인용 표시가 하나 이상 있으면 통과’라는 검사를 가정해 보자. 이 검사는 표시의 존재를 세지만, 그 표시가 답의 어느 부분을 증명하는지는 확인하지 않는다. 다음 세 답변이 같은 점수를 받을 수도 있다.

원자료에서 조건에 맞는 행을 찾고 해당 출처를 연결한 답변.
계산 과정은 맞지만 인용한 페이지에는 계산의 입력값이 없는 답변.
자신이 만든 결과를 게시한 뒤 그 주소를 출처로 붙인 답변.

이는 검사를 설명하기 위해 만든 예시다. 실제 평가기의 코드를 재현한 것은 아니다. 그러나 어떤 항목을 세는지에 따라 목표가 달라진다는 문제를 드러낸다.

이 글에서 제안하는 검토 단위는 ‘답변에 링크가 있는가’보다 작다. 주장 하나와 그것을 뒷받침하는 근거 하나를 연결한다. 직접 조회한 값, 계산한 값, 해석한 내용을 구분해 기록하면 빈틈을 찾기 쉽다.

주장: 조건에 맞는 항목은 세 개다.
입력 근거: 원자료의 조회 조건과 응답 기록.
계산: 조건을 적용한 코드 또는 식.
확인 범위: 응답에 포함된 항목만 확인.
제약: 브라우저용 인용 표시를 만들지 못함.
외부 쓰기: 요청 범위에 없음.

위 항목은 이번 글을 위해 작성한 기록 예시다. 인용 도구가 처리하지 못하는 자료라면, 처리하지 못했다는 사실과 실제로 확인한 근거를 남기는 것이 맞다. 링크 형식을 맞추기 위해 작업 범위를 넓힐 이유는 없다.

실패 뒤에 확인할 상태

작업이 실패했을 때는 ‘최종 답변을 만들었는가’만 물으면 부족하다. 중간에 외부 상태가 바뀌었을 수 있기 때문이다.

문서 생성 후 공유 링크 만들기가 실패했다면 문서는 남았는지, 업로드 후 분석이 실패했다면 파일은 올라갔는지 확인해야 한다. 이때 성공·실패를 작업 전체에 하나만 붙이지 않고 전송, 처리, 인용, 최종 응답에 각각 붙이면 남은 일을 판단할 수 있다.

기존 허깅페이스 침해 분석이 실행 환경의 경계를 다뤘다면, 여기서 살핀 것은 평범한 자료 조회 요청의 완료 조건이다. 답이 맞았다는 이유로 중간 행동을 생략해서 검토할 수 없고, 마지막 도구가 실패했다는 이유로 앞선 행동까지 취소됐다고 볼 수도 없다.

공식 자료 확인: 2026년 9월 21일. 외부 업로드를 재현하지 않았다. 도구 권한표와 검토 예시는 보고서를 바탕으로 작성한 작업 설계안이다.