문서는 빨라졌는데 검토는 그대로? Google Deep Review로 제안서 검토 설계

핵심 답변: Google Deep Review는 복잡한 문서의 논리와 근거를 점검하는 AI 검토 도구입니다. 기업에서는 제안서 초안에 붙이는 사전 검토 단계로 시험할 수 있습니다. 제가 제안하는 출발점은 주장마다 증거를 연결하고, 일부러 오류를 심은 문서로 검토 품질을 측정하는 것입니다. 좋은 지적의 개수와 함께 잘못된 지적을 확인하는 시간, 실제로 반영한 수정까지 재야 도입 여부를 판단할 수 있습니다.

제안서 한 장을 더 만드는 시간은 짧아졌습니다. 그런데 숫자의 기준이 같은지, 일정과 인력이 맞물리는지, 약속한 성과를 무엇으로 입증하는지 확인하는 시간은 그대로 남아 있습니다. 초안이 세 개에서 열 개로 늘면 검토자의 책상도 그만큼 붐빕니다. 여기서 필요한 질문은 “AI가 얼마나 길게 검토해주나”보다 “검토자가 중요한 쟁점을 얼마나 빨리 판별할 수 있나”입니다.

이 글은 2026년 10월 19일 확인한 공개 자료를 바탕으로 한 제품 해설과 저자의 실험 제안입니다. 아래 제안서 사례와 평가 수치는 설계 설명을 위한 가상 예시이며, LeanX가 Deep Review로 실제 고객 문서를 시험해 얻은 결과가 아닙니다.

1. 제안서의 병목은 문장 뒤에 숨어 있습니다

가상의 AX 구축 제안서를 생각해보겠습니다. 첫 장에는 “월 보고서 작성 시간을 50% 줄인다”고 적혀 있습니다. 뒤의 산출 근거는 보고서가 아니라 회의록 정리 시간을 사용합니다. 인력표에는 주당 10시간을 투입한다고 쓰여 있는데 일정표는 그 사람이 두 프로젝트를 동시에 맡는다는 사실을 빠뜨렸습니다. 문장만 읽으면 자연스럽지만, 서로 연결하면 약속이 흔들립니다.

이런 오류는 맞춤법이나 표현 다듬기로 해결되지 않습니다. 검토자는 목표, 기준선, 계산식, 수행 조건을 오가며 확인해야 합니다. 좋은 사전 검토의 단위는 페이지가 아니라 검증할 수 있는 주장 하나가 됩니다.

저는 문서 검토를 세 종류로 나누어 시작할 것을 제안합니다. 문서 안에서 숫자나 정의가 충돌하는지 확인하는 검토, 외부 근거가 주장을 실제로 뒷받침하는지 확인하는 검토, 그리고 우리 조직이 그 약속을 수행할 수 있는지 판단하는 검토입니다. 마지막 항목에는 담당자의 가용 시간이나 고객과 합의한 범위처럼 문서에 없는 정보가 필요합니다. AI가 확인할 수 없는 조건도 검토 결과에 남겨야 합니다.

2. Deep Review의 현재 범위부터 정확히 읽어야 합니다

Google Research는 2026년 10월 14일 Deep Review를 공개했습니다. 공개 발표 기준 초기 입력은 PDF와 일반 텍스트이며, 여러 파일을 함께 다루는 기능은 향후 예정입니다. 사용자당 매주 두 번의 무료 검토가 제공되고, 사용량을 늘리거나 Deep Review API로 연동하려면 Gemini API 키를 연결하는 경로가 안내되어 있습니다. 업로드 문서는 Google 모델의 학습·미세조정·개선에 쓰이지 않으며, 사용자 화면에 표시하기 위한 목적으로 1년간 저장된다는 정책입니다. 검토 전에는 이 보관 조건까지 함께 확인해야 합니다. Google Research 공개 발표

사용은 Deep Review 공식 포털에서 시작할 수 있습니다. Docs나 발표자료 검토를 설명하는 소개 문구를 보고 원본 형식의 즉시 연동까지 가정하지 말고, 현재 지원 입력으로 준비하는 편이 정확합니다.

기술적 선행 연구인 6월 PAT 논문은 수학·컴퓨터과학의 수식·증명 오류가 있는 논문 26편, 오류 29개로 구성한 부분집합에서 검출을 평가했습니다. 저자들은 그 결과가 원래 SPOT 논문의 점수와 직접 비교되지 않는다고 설명합니다. 당시 파일 파싱 문제와 잘못된 비판도 한계로 다룹니다. 이 연구만으로 한국어 제안서나 계약서의 정확도를 보장할 수는 없습니다. PAT 연구 논문

3. 첫 산출물은 ‘주장과 증거를 연결한 표’입니다

제안서를 바로 업로드하기 전에 다음 표를 만들어두면 사람이 무엇을 확인해야 하는지 선명해집니다. 아래는 가상 제안서의 준비 예시입니다.

검토할 주장	문서 안의 근거	확인할 질문	사람이 가진 추가 정보
월 보고 시간 50% 감소	4쪽 시간 조사표	조사한 업무와 약속한 업무가 같은가?	예외 처리·최종 승인 시간
6주 안에 적용 완료	8쪽 일정표	데이터 제공과 검수 기간이 포함됐는가?	고객의 데이터 반출 일정
연간 3천만 원 절감	10쪽 계산표	단가·빈도·도입비를 같은 기준으로 계산했는가?	내부 인건비 산정 기준

주장을 전부 동일하게 취급할 필요는 없습니다. 숫자, 일정, 적용 범위, 성과 보장처럼 고객의 결정을 바꾸는 문장을 우선 고릅니다. “업무 효율을 높입니다”라는 표현은 검증하기 어렵지만, “월 20건의 보고에서 건당 30분을 줄입니다”는 계산과 관찰로 확인할 수 있습니다.

입력 PDF를 만들 때 표와 주장의 위치를 함께 보존하세요. 부록을 합쳤다면 원래 출처, 날짜, 버전을 표시합니다. 현재 여러 파일 입력이 예정 단계인 만큼 첫 실험은 범위를 좁힌 단일 문서로 설계할 수 있습니다. 다만 파일을 합쳤다는 이유로 개인정보나 고객 기밀을 넣을 권한이 새로 생기는 것은 아닙니다. 공개·가상 자료부터 시작하면 평가 설계에 집중할 수 있습니다.

4. 검토 의견은 사람이 판정할 수 있는 형태로 바꿉니다

AI가 “근거가 부족합니다”라고만 말하면 담당자는 문서를 다시 처음부터 읽어야 합니다. 다음 여섯 항목을 갖춘 이슈 기록으로 정리하는 것이 제가 제안하는 운영 방식입니다. 이는 Deep Review의 고정 출력 형식을 설명하는 것이 아니라, 결과를 받은 뒤 팀이 사용할 기록 양식입니다.

• 위치: 해당 쪽과 주장 문장.
• 문제: 어떤 두 정보가 충돌하거나 무엇이 누락됐는지.
• 근거: 원문 표·계산·참조 자료의 확인 가능한 위치.
• 영향: 가격·일정·적용 범위 등 어떤 결정이 달라지는지.
• 확인 질문: 작성자에게 무엇을 더 물어야 하는지.
• 처리: 수정, 추가 확인, 기각 중 무엇으로 끝났는지.

예를 들어 “절감액이 과장됐다”보다 “10쪽은 월 20건, 4쪽은 월 12건을 기준으로 계산해 연간 절감액이 달라집니다. 어느 빈도를 사용할지 확인이 필요합니다”가 유용합니다. 검토자는 양쪽 위치를 읽고 판단할 수 있고, 작성자도 수정할 지점을 압니다.

근거가 없는 지적은 별도로 표시해야 합니다. 문서에 없는 고객 의도를 추측한 의견과 실제 산술 오류를 같은 경고로 쌓으면 중요한 문제를 놓치기 쉽습니다. 새로 제안된 문장도 원래 자료로 확인한 뒤 반영합니다. 검토 도구가 만들어낸 수정안 역시 확인 대상입니다.

5. ‘오류를 심은 문서’로 작은 시험을 설계합니다

첫 도입 실험에는 정답을 알고 있는 자료가 필요합니다. 제가 제안하는 방법은 공개된 자료로 가상의 제안서 두 버전을 만드는 것입니다. 하나는 내부 계산과 정의를 맞춘 기준본, 다른 하나는 일부 오류를 넣은 시험본입니다. 기준본도 완벽하다고 가정하지 않고, 두 명이 독립적으로 확인한 뒤 시작합니다.

시험본에는 연간 수치와 월간 수치 혼용, 본문과 표의 대상 범위 불일치, 일정 의존관계 누락, 비율 계산의 분모 변경, 증거보다 강한 성과 표현을 각각 하나씩 넣어볼 수 있습니다. 위치와 정답은 별도 표에 보관하고 검토 입력에서는 제외합니다. 문서마다 예측 가능한 위치에만 오류를 넣지 말고 유형과 위치를 바꿔야 합니다.

비교 대상은 같은 문서를 읽는 기존 검토 방식과 AI를 보조로 쓰는 방식입니다. 같은 담당자가 두 번 읽으면 앞서 본 오류를 기억할 수 있으므로 담당자를 교차 배정하거나 비슷한 난도의 다른 문서를 준비합니다. 도구의 사용 가능 횟수에 맞춰 소수 문서로 시작하고, 결과가 엇갈리면 관찰 범위를 넓힙니다. 주당 두 번의 무료 검토만으로 성능을 일반화할 만큼 큰 표본을 확보했다고 말하기는 어렵습니다.

채점할 때는 AI가 정확한 문구를 반복했는지보다 같은 실질적 문제를 찾았는지 봅니다. 하나의 오류를 다섯 번 지적했다면 한 건으로 묶습니다. 반대로 두 오류를 하나의 모호한 문장으로 뭉쳤다면 각각 확인할 수 있는지도 점검합니다. 평가자는 어떤 방식의 결과인지 가린 상태에서 근거를 판정하면 편향을 줄이는 데 도움이 됩니다.

인위적으로 넣은 오류는 평가하기 쉽다는 장점이 있지만 실제 업무의 복잡함을 모두 대표하지는 못합니다. 이 단계는 후속 시험 여부를 고르는 장치입니다. 다음 단계에서는 사용 권한이 있는 실제 문서를 별도 표본으로 검토해야 합니다.

6. 검토량보다 정밀도와 수정률을 봅니다

제가 먼저 기록할 지표는 네 가지입니다. 오류 발견율은 심어둔 오류 중 실제로 찾은 비율입니다. 지적 정밀도는 중복을 제거한 전체 지적 중 사람이 근거를 확인해 유효하다고 판정한 비율입니다. 수정 반영률은 유효하다고 판정한 지적 중 최종본에 수정이나 명확한 보완이 반영된 비율입니다. 마지막으로 검토 완료 시간은 결과를 읽고 사실을 확인하고 작성자와 조율하는 시간을 모두 포함합니다.

가상 예로 오류 열 개 중 여덟 개를 찾았지만 총 지적 마흔 개 중 유효한 것이 여덟 개라면, 발견율은 80%여도 정밀도는 20%입니다. 검토자는 남은 지적을 기각하느라 시간을 쓸 수 있습니다. 여기서 관찰할 과잉 지적은 유효하지 않은 지적의 비중과 그 확인 시간입니다. 실제 오류가 없는 기준본에서도 얼마나 문제가 있다고 주장하는지 함께 보아야 합니다.

수정 반영률도 높을수록 무조건 좋은 것은 아닙니다. 작성자가 비판을 검토하지 않고 모두 수용하면 잘못된 수정이 늘 수 있습니다. 유효 판정은 작성자 외의 검토자가 맡고, 미반영 사유를 남깁니다. 중요한 누락을 한 번 잡은 효과와 작은 표현 지적 열 번의 효과도 구분합니다.

성공 기준은 시험 전에 정하세요. 예를 들어 “중대한 수치 모순은 모두 발견하고, 근거 없는 지적을 확인하는 시간까지 포함해 기존 검토보다 짧게 끝난다”는 목표를 둘 수 있습니다. 이는 제가 제안하는 측정 기준이며 제품 성능 수치가 아닙니다. 결과가 기준에 못 미치면 문서 종류를 좁히거나 적용을 보류합니다. API 사용 시에는 비용과 재검토 횟수도 문서 한 건 기준으로 합산해야 합니다.

7. 2주 뒤에 남길 것은 수정된 문서와 결정 기록입니다

첫 주에는 공개·가상 제안서로 주장-증거표와 오류 정답표를 준비합니다. 기준본과 시험본을 검토해 무엇을 잘 찾고 어떤 지적이 시간을 쓰게 했는지 확인합니다. 둘째 주에는 승인된 문서 범위 안에서 표본을 추가하고, 기존 방식과 비교해 검토 시간과 수정 결과를 기록합니다. 주당 제공량이나 연결 조건이 맞지 않으면 기간을 늘려 충분한 표본을 모읍니다.

최종 기록에는 문서 버전, 사용 시점, 입력 범위, 발견한 문제, 유효 판정, 수정 내용, 남은 불확실성을 남깁니다. 고객에게 보낼지 결정하는 담당자도 명확히 합니다. 상업적 조건이나 법적 의미를 확정하는 일은 해당 책임자의 검토를 거쳐야 합니다. 이 글의 실험 제안은 그 책임을 AI로 옮기지 않습니다.

앞서 업무 소프트웨어의 실행면 변화를 다뤘다면, 이번에는 그 화면에서 만들어지는 문서가 어떤 근거로 승인되는지 연결해볼 차례입니다. Claude Code의 검증 루프와 마찬가지로 완료 여부를 판정할 수 있는 기준을 먼저 마련해야 실제 개선을 확인할 수 있습니다.

Deep Review를 통해 시험해볼 변화는 사전 검토가 끝난 뒤 사람이 더 좋은 결정을 내릴 수 있느냐입니다. 먼저 제안서 한 종류를 고르고, 주장 열 개와 확인 가능한 근거부터 연결해보세요. 다음 작성자는 그 기록을 이어받아 같은 문제를 더 일찍 확인할 수 있습니다.

우리 업무에 맞는 2주 AX 검토 실험 설계하기

공식 출처

• Google Research: Deep Review 공개 발표 — 2026-10-14
• Deep Review 공식 포털
• Google 연구진 PAT 논문 — 2026-06-26, v1

제품 조건 확인일: 2026-10-19. 이 글의 업무 설계·가상 사례·실험 기준은 저자의 제안이며, 실제 도입 성과를 보고한 내용이 아닙니다.