Google Deep Review 분석: 설계서의 모순을 찾아 수정으로 연결하기

무엇이 공개됐고, 어디까지 확인했나

Google Research는 2026년 10월 14일 Deep Review를 공개했다. 논문 검토용 Paper Assistant Tool(PAT)을 발전시켜 기술 문서의 논리와 근거를 검토하는 서비스다. 발표 기준으로 주 2회 무료 검토, 추가 사용을 위한 Gemini API 키 연결을 안내한다. 초기 입력은 PDF·일반 텍스트이고 여러 파일 입력은 예정이다. 업로드 문서는 모델 학습에 쓰지 않지만 UI 표시 목적으로 1년 보관한다고 명시한다. 공식 발표

이 조건은 10월 18일 확인한 공개 안내다. 로그인 후 업로드·응답·실제 계정 한도는 시험하지 않았다. 공식 포털은 이번 텍스트 조회에서 내용을 읽을 수 없었다. 따라서 화면의 버튼 위치, API 요청 형식, 문서당 최대 크기나 처리 시간은 여기서 확정하지 않는다. Google Docs·발표 자료를 활용 대상으로 소개하는 것과 원본 파일의 직접 연결·가져오기 지원은 구분해서 확인해야 한다.

기업 설계서를 넣으려면 ‘학습에 쓰지 않는다’와 ‘서버에 남지 않는다’를 같은 말로 읽지 않아야 한다. 팀의 문서 반출·보관 조건과 맞는지 확인하고, 첫 검토에는 공개 가능한 설계 예시를 쓰는 편이 현실적이다. 이 글도 실제 내부 문서를 업로드하는 대신 직접 만든 사례로 활용 방식을 설명한다.

전체를 읽으면서 검토할 부분은 나누는 이유

Deep Review의 발표된 흐름은 문서 분할 → 난도에 따른 계산 배분 → 부분별 병렬 검토 → 통합·외부 근거 확인이다. 각 검토 에이전트는 담당 구간에 집중하면서 문서 전체를 참조한다. 마지막 단계는 지적을 모으고 절 사이의 일관성을 확인한다. 작동 구조

이 구조의 의미는 읽을 수 있는 길이와 검토에 쓸 추론을 구별하는 데 있다. 50쪽을 입력할 수 있어도 모든 주장에 반례를 만들어 볼 여유가 같지는 않다. 개요를 요약하는 일과 복구 조건의 빈틈을 찾는 일은 다른 작업이다. 특정 구간에 검토를 집중하면 ‘어느 주장을 끝까지 따져 볼 것인가’를 더 분명히 정할 수 있다.

PAT v1 논문은 단순 반복 호출이 비슷한 부분에 몰리거나 거짓 지적을 늘릴 수 있다고 설명한다. 구간은 겹치거나 떨어진 페이지를 포함할 수 있고, 통합 단계는 중복과 근거를 대조한다. PAT v1 · 설계와 파이프라인

독자 입장에서는 다음처럼 읽을 수 있다. 요구사항을 검토하는 담당자가 복구 절을 보지 못하면, 문장 자체에는 문제가 없다고 답할 수 있다. 반대로 모두가 전체를 똑같이 훑으면 같은 표현만 여러 번 지적할 수 있다. 검토 책임은 나누고, 판단에 필요한 조건은 공유하는 것이 유용한 이유다. 다만 이런 구조가 모든 모순의 발견을 보장하지는 않는다. 잘못 읽힌 표나 문서 밖의 전제는 여전히 남는다.

사례: 복구 약속과 데이터 보관 정책이 충돌할까

아래는 문서 검토를 맡기기 전에 작성자가 먼저 정답 조건을 정해 볼 가상 서비스 설계서 v0.1이다. Deep Review가 실제로 찾아낸 결과가 아니다.

위치	설계서에 적힌 내용
R1 · 고객 요구	생성 후 30일 이내의 모든 보고서는 장애 신고 후 24시간 안에 재생성할 수 있어야 한다.
D2 · 복구 설계	재생성에는 최초 입력 원본이 필요하다. 완성 보고서나 집계값만으로 원본을 복원할 수 없다.
P3 · 보관 정책	최초 입력 원본은 생성 후 7일에 삭제한다. 별도 사본이나 외부 재취득 경로는 없다.

세 문장은 각각 자연스럽다. 문제는 함께 읽을 때 생긴다. 보고서 생성 10일 뒤 장애 신고가 들어왔다고 하자. R1의 대상에는 포함되지만 P3에 따라 원본은 없고, D2에 따라 재생성도 할 수 없다. 24시간이라는 처리 속도 이전에 필요한 입력이 사라지는 문제다.

유효한 지적은 “보관 기간을 늘리세요”로 끝나지 않는다. 먼저 R1·D2·P3의 위치를 짚고, 10일째라는 반례에서 세 조건이 동시에 성립하지 않음을 보여줘야 한다. 그러면 수정 책임자가 다음 중 무엇을 바꿀지 결정할 수 있다.

• 복구 약속의 대상을 7일 이내 보고서로 제한한다. 고객 요구와 계약 범위를 다시 합의해야 한다.
• 승인된 범위에서 원본 보관 기간을 늘린다. 저장 비용과 삭제 정책을 함께 바꿔야 한다.
• 원본 없이 재생성할 수 있는 별도의 복구 표현을 설계한다. 동등한 결과를 만들 수 있는지 실행 검증이 필요하다.

어느 선택이 옳은지는 문장만으로 정할 수 없다. 서비스의 약속과 데이터 취급 조건을 아는 사람이 고른다. AI 지적의 가치는 그 선택이 필요한 위치를 드러내는 데 있다.

같은 숫자라도 지적을 기각해야 하는 경우

R1이 “보고서 생성 후 7일 이내 장애 신고만 재생성 대상”으로 바뀌었다면, 10일째의 반례는 적용되지 않는다. 다만 7일 경계에서 신고 접수와 삭제 작업이 어떤 순서로 일어나는지는 따로 정해야 한다. 기간의 숫자를 맞추는 것과 경계 조건을 완성하는 것은 다른 작업이다.

또 P3에 “원본 삭제 후에도 승인된 복구 사본을 30일간 유지”라는 명시적 예외가 있다면, ‘입력이 전혀 없다’는 지적은 기각할 수 있다. 대신 그 사본이 D2의 입력 요건을 충족하는지 확인한다. 이런 반대 조건을 적어 두면 한 번 받은 지적을 계속 정답처럼 유지하는 오류를 줄일 수 있다.

지적을 수정안으로 바꾸는 짧은 기록

실무에서는 보고서 전체를 다시 읽기보다 지적 하나에 필요한 근거를 묶어 두는 편이 좋다. 아래는 자체 작성한 양식이다. Deep Review의 출력 스키마나 제품 기능이 아니다. 가상 사례와 검토표 받기

문서 버전: v0.1
지적 ID: C1
원문 위치: R1 / D2 / P3
주장: 30일 복구 약속과 7일 원본 삭제를 함께 만족할 수 없다.
성립 조건: 원본 필수, 별도 사본 없음, 재취득 불가
최소 반례: 생성 10일 뒤 장애 신고 → 원본 부재 → 재생성 불가
기각 조건: 복구 대상 제한 또는 유효한 복구 사본의 존재
결정: 요구·보관·복구 방식 중 변경 대상을 담당자가 선택
수정 후 확인: 새 약속의 경계 날짜와 실제 복구 입력 대조

처리 상태는 ‘채택·기각·추가 확인’ 정도로 나눌 수 있다. 채택에는 변경 위치를, 기각에는 반대 근거를, 추가 확인에는 담당자와 필요한 자료를 붙인다. 파일 버전도 고정한다. v0.1에 대한 지적을 v0.2의 다른 문장에 자동 적용하면 올바른 검토가 잘못된 수정으로 바뀔 수 있기 때문이다.

읽는 화면을 직접 구성한다면, 넓은 화면에서는 원문 구간과 지적 상세를 나란히 보여주는 구성이 적합하다. 좁은 화면에서는 지적 하나 아래에 관련 원문과 결정을 세로로 묶는 편이 대조하기 쉽다. 일시 알림에만 기각 사유를 넣으면 나중에 이유를 찾기 어렵다. 이는 검토 기록을 위한 UI 설계 제안이며 실제 Deep Review 화면 설명이 아니다.

팀에서 시험할 때는 C1이 있는 문서와 그 충돌을 해소한 문서를 함께 준비하자. 두 문서에서 모두 같은 오류를 주장하면 지적의 근거를 다시 봐야 한다. 반대로 첫 문서를 통과시켰다고 모순이 없다고 판정하지 않는다. 이 대조는 실행을 제안하는 절차이며 이번 글에서 모델을 호출한 실험은 아니다.

PAT의 성능 숫자를 읽을 때 남겨야 할 조건

2026년 6월 26일 PAT v1의 SPOT 평가는 수학·컴퓨터과학의 식·증명 오류로 좁힌 26편, 29개 오류를 다룬다. 표의 탐지율은 Gemini 3.1 Pro 단일 호출 55.2%, 같은 모델을 쓴 PAT 89.7%다. 논리적 동등성을 판단하는 자동 채점과 저자 측 사람의 감사를 사용했으며, 기존 SPOT 결과와 직접 비교할 수 없다고 명시한다.

두 표시값의 차이는 34.5%포인트다. 이를 ‘모든 문서의 정확도가 34.5% 향상’으로 바꾸면 분모와 과제가 사라진다. 이 평가는 이미 알려진 오류를 찾았는지 묻는다. 정상 설계서에 얼마나 많은 잘못된 지적을 내놓는지, 현재 서비스가 한국어 요구사항을 얼마나 잘 읽는지, 팀의 총검토 시간이 줄었는지는 별도로 측정해야 한다. 현재 Deep Review의 Argon 지원 발표와 과거 PAT 평가도 같은 실행 버전이 아니다. 현재 제품 발표

저자 설문은 또 다른 종류의 근거다. ICML의 3월 30일 회고는 실험 결과가 있는 논문의 응답자 중 31%가 피드백을 받고 새 실험을 했다고 보고한다. 이는 실제 행동에 관한 자기 보고이고 오류 탐지율이나 시간 절감률은 아니다. 당시 피드백은 공식 심사와 분리돼 저자에게만 제공됐다.

숫자를 한 표에 합치기 전에는 원문의 집계도 대조해야 한다. ICML 회고는 설문 응답 869건을, PAT v1 표는 ICML 코호트 n=733을 표시한다. 이 글에서는 차이의 원인을 확인하지 못했으므로 모집단이 같다고 가정하거나 평균을 만들지 않았다. 논문도 거짓 오류 지적과 PDF 해석 문제를 한계로 기록한다. PAT v1 · 설문과 한계

내 업무에서는 무엇부터 맡길까

요구사항·제약·근거가 여러 절에 흩어진 설계서는 시험할 가치가 있다. 먼저 문서 버전과 확인할 주장을 정하고, 복구 사례처럼 정답 조건을 사람이 설명할 수 있는 작은 묶음부터 비교한다. 반복 실행의 보고서 길이나 지적 수보다, 실제로 채택한 지적과 이를 확인하는 데 든 시간을 기록하는 편이 업무 판단에 도움이 된다.

반대로 단순한 문장 교정만 필요하거나 입력 자료가 아직 모이지 않았다면 깊은 검토의 추가 비용을 정당화하기 어렵다. 문서 밖의 운영 사실이 핵심인 경우에는 현장 기록을 먼저 확보해야 한다. 그 기록이 빠진 상태에서는 AI의 추측도 사람의 추측도 충분한 근거가 되지 못한다.

Antigravity를 쓰는 팀은 별도 경로도 비교할 수 있다. 공식 Teamwork 문서는 유료 플랜의 /teamwork-preview와 문서 검토 경로를 안내한다. 이는 IDE·CLI의 에이전트 작업 경로이며 Deep Review 포털의 무료 횟수·보관 조건이 그대로 적용된다는 뜻은 아니다. Antigravity Teamwork 문서

긴 문서를 넣었는데도 조건을 놓치는 원인을 더 보고 싶다면 긴 문맥과 RAG의 역할 구분을, 모델 접근과 실행 도구의 차이가 궁금하다면 Gemini 4 Argon 분석을 이어 읽으면 된다. 다음 설계 검토 때 이 글의 양식을 다시 쓰려면 저장 기능을 이용하고, 새 분석은 RSS로 받아볼 수 있다.