파일이 업로드됐어도 AI가 모든 내용을 읽은 것은 아니다

긴 PDF의 업로드가 끝나도 필요한 부록과 각주가 답변에 반영됐는지는 다시 살펴야 한다. 본문의 예정일과 부록의 실행 조건이 함께 있어야 판단할 수 있는 상황이 있기 때문이다. 문서의 지도와 질문, 원문 위치를 연결해 실제 검토 범위를 남긴다.

파일 크기와 컨텍스트 범위를 구분한다

업로드에 허용되는 파일의 크기·개수·형식과 모델이 작업에 활용할 수 있는 내용의 범위는 서로 다른 조건이다. Gemini 파일 업로드 공식 안내는 지원 환경과 업로드·분석의 제한을 설명한다. 현재 사용 중인 계정과 기능에 적용되는 안내를 확인해야 한다.

컨텍스트는 모델이 답변을 생성할 때 참고하는 입력 맥락을 뜻한다. 문서 내용뿐 아니라 요청과 대화 등 작업에 필요한 정보가 영향을 줄 수 있다. 따라서 파일의 바이트 크기를 컨텍스트 범위와 같은 단위로 이해하면 안 된다. 이미지가 많은 큰 PDF와 글자가 촘촘한 긴 문서는 크기와 텍스트 양의 관계가 다를 수 있다.

파일 개수 제한 안에 들어간다는 사실도 모든 절의 정확한 이해를 증명하지는 않는다. 입력 지원 여부, 자료에서 읽을 수 있는 정보, 결과에서 확인한 범위를 나누어 기록하는 편이 정확하다.

긴 문서는 검토할 지도를 먼저 만든다

문서 제목과 버전, 목차, 필요한 절과 부록, 주요 표를 정리한다. 어떤 질문을 어느 부분에서 확인해야 하는지 연결하면 답변이 본문 일부에만 의존하는지 살피기 쉽다.

지도는 AI에게 요약하게 할 수도 있지만 실제 목차와 대조한다. 파일 안에 없는 절이 만들어졌거나 중요한 부록이 빠졌다면 그 지도를 검토 기준으로 그대로 사용하면 안 된다. 입력의 구조를 확인하는 단계에도 원본 확인이 필요하다.

본문과 부록이 서로 다른 조건을 말할 때 확인할 순서

가상의 운영 안내서 본문 12쪽에는 ‘9월 20일 전환 예정’, 부록 86쪽에는 ‘결제 점검 완료 후 적용’이라는 조건이 있다고 하자. 날짜만 물으면 본문의 일정이 답으로 나올 수 있지만 실행 가능한 날짜를 판단하려면 부록의 조건도 필요하다. 업로드된 파일 안에 두 정보가 있다는 사실과 두 정보가 답변에서 연결됐다는 사실은 따로 확인해야 한다.

이런 자료에서는 질문을 ‘언제 전환하는가’ 하나로 끝내지 않는다. 예정 날짜를 찾고, 전환의 전제 조건을 찾고, 지연 시 처리 방법을 찾은 다음 한 결론으로 연결한다. 각 답에 원문 위치를 남기면 빠진 관계를 다시 확인할 수 있다. 질문을 나누는 목적은 많이 묻는 것이 아니라 판단에 필요한 정보의 관계를 남기는 것이다.

페이지 번호는 문서 지도를 만들 때 기준을 맞춘다. 표지와 목차 때문에 PDF의 14번째 페이지에 인쇄 번호 12가 있을 수 있다. 기록에 ‘PDF 순서 14 / 인쇄 번호 12’라고 적으면 다른 사람이 같은 위치를 찾기 쉽다. 페이지 번호가 없는 문서라면 절 제목과 표 제목을 함께 쓴다.

Google Cloud의 긴 컨텍스트 설명은 많은 입력을 받아들이는 기능과 여러 정보를 찾아야 하는 상황의 성능 차이를 다룬다. 따라서 지원하는 토큰 수를 자신의 파일 전체가 정확히 검토됐다는 증거로 쓰기보다는 실제 질문마다 필요한 정보가 연결됐는지 확인하는 편이 낫다.

절별 결과를 합칠 때 빠진 정의를 되살린다

문서를 나눠 검토하면 각 절의 내용은 잘 보이지만 전체 정의가 사라질 수 있다. 본문의 ‘사용자’가 부록에서는 유료 구성원만을 뜻한다면 그 정의 없이 인원 표를 비교할 수 없다. 반복 용어와 공통 조건은 따로 기록해 각 절의 결과와 함께 본다.

같은 항목에 대한 결과가 서로 다르다면 우선 원문에서 수정 이력과 적용 시점을 찾는다. 오래된 일정이 본문에 남았거나 서로 다른 대상의 안내가 한 파일에 묶여 있을 수 있다. 어느 한 답이 더 단정적이라는 이유로 선택하지 않는다.

마지막에는 원문 목차를 기준으로 검토한 부분과 남은 부분을 표시한다. 필요한 판단의 범위가 본문 3절과 부록 2개라면 그 범위를 쓰고, 나머지를 보지 않았다면 전체 문서 검토라고 표현하지 않는다. 이런 기록이 있어야 새 버전에서 부록 하나가 바뀌었을 때 어떤 결론을 다시 봐야 하는지 찾을 수 있다.

질문을 나누되 앞뒤 조건을 함께 제공한다

긴 문서를 절별로 나누면 범위를 좁혀 확인하기 쉽다. 그러나 한 절만 떼면 용어 정의나 적용 조건이 다른 곳에 있을 수 있다. 질문에 필요한 범위와 연결되는 정의·각주를 함께 제공하고, 잘라낸 부분의 위치를 기록한다.

예를 들어 요금표의 숫자만 제공하면 기간과 대상, 별도 주석이 빠질 수 있다. 기술 안내의 절 하나만 떼면 문서 앞부분의 지원 기기 조건을 놓칠 수 있다. 범위를 줄이는 목적은 단서를 제거하는 것이 아니라 검토할 관계를 명확하게 하는 것이다.

Google Cloud 프롬프트 설계 안내는 작업을 명확하게 구성하는 전략을 다룬다. 이를 자신의 자료에 적용할 때는 입력 단위와 확인할 질문을 함께 나누고, 마지막에 전체 결론을 다시 대조한다.

답변이 실제로 어느 부분을 이용했는지 확인한다

모델에게 근거 페이지와 문장을 표시하게 할 수 있다. 그 위치를 원본에서 열어 실제 내용이 맞는지 확인한다. 존재하지 않는 페이지나 다른 문장을 연결했다면 미확인으로 남긴다. 페이지 번호는 PDF의 실제 페이지 순서와 인쇄된 번호가 다를 수 있으므로 어느 기준을 썼는지도 명확히 한다.

‘문서 전체를 확인했다’는 답변만으로 범위를 증명할 수는 없다. 중요한 절마다 질문과 결과를 대조하고, 부록·각주·표처럼 놓치기 쉬운 구조를 직접 살핀다. 답변이 잘 나온 일부 질문을 전체 검토 성공으로 확대하지 않는다.

필요한 숫자와 조건이 결과에 없다면 원문에서 다시 확인하고 범위를 좁혀 재질문할 수 있다. 재질문 결과도 같은 방식으로 대조한다. 여러 번 질문했다고 자동으로 검증이 끝나는 것은 아니다.

추출 문제와 분석 문제를 나눈다

스캔 PDF는 OCR이 필요할 수 있고, 2단 문서와 표는 읽기 순서나 셀 관계가 달라질 수 있다. 원래 파일의 정보가 제대로 읽히지 않았다면 질문을 자세하게 쓰는 것만으로 문제가 해결되지 않을 수 있다.

OCR 결과 확인과 PDF 표 검토를 먼저 적용해 기계가 처리할 자료의 상태를 살핀다. 원문은 정확한데 출력이 조건을 빠뜨린 경우와, 입력 텍스트부터 틀린 경우에는 다시 확인할 단계가 다르다.

작업을 마치면 문서 버전, 다룬 절과 페이지, 직접 대조한 수치·조건, 남은 미확인 부분을 기록한다. 결과가 요약인지 전체 항목 추출인지도 표시한다. 긴 문서의 검토 품질은 업로드 성공 표시보다 필요한 질문에 근거가 연결돼 있고 확인 범위가 분명한지로 판단하는 편이 낫다.