[Gemini vs DEEP Agent Lab] 같은 문서, 다른 결과는 왜 만들어질까?

기업 환경에서 하루에도 수천 건씩 처리되는 문서들은 단순히 ‘읽을 수 있는 텍스트’의 집합이 아니다. 계약서, 신고서, 원산지 증명서, 청구서와 같은 실무 문서에서 중요한 것은 문장 자체가 아니라 문서가 가진 구조와 관계다. 항목이 어디에 배치되어 있는지, 어떤 값이 어떤 필드에 속하는지, 반복되는 정보가 어떻게 묶여 있는지가 그대로 유지되어야만 이후의 업무 시스템이 정상적으로 작동한다.

그래서 OCR 이후 단계인 Parser는 문서 자동화 전체 품질을 좌우하는 핵심 단계가 된다. 문자를 읽는 것은 출발점일 뿐이고, 그 문자를 원본 문서의 형태와 관계 그대로 재현하는 것이 Parser의 역할이다. 구조가 무너지면, 그 위에서 돌아가는 KIE, 검증 로직, DB 매핑, 승인 워크플로우는 모두 흔들릴 수밖에 없다.

이번 실험은 이 지점에 초점을 맞췄다. 동일한 문서를 입력했을 때, Gemini와 DEEP Agent Lab이 문서를 얼마나 원형에 가깝게 ‘구조로 재현’하는지를 비교했다. 자연어 요약이나 의미 해석이 아니라, 오직 Parser 결과값이 원본 문서의 형태를 얼마나 충실히 구현했는지만을 기준으로 삼았다.

실험 전제 — 평가는 ‘구조 재현력’ 하나로 통일한다

이번 비교에서 중요한 기준은 단 하나다. Parser 결과가 기존 문서의 형태를 얼마나 정확히 되살렸는가다.

이를 위해 다음과 같은 기준을 명확히 제외했다. 자연어 설명의 유창함, 문맥적 해석, 의미 요약, 추론 기반 보정과 같은 요소들은 이번 실험의 평가 대상이 아니다. 이런 요소들은 문서 분석이나 생성 단계에서는 의미가 있지만, Parser 단계에서는 오히려 구조 왜곡의 원인이 될 수 있다.

평가 대상은 다음과 같은 질문으로 정리된다. 문서의 섹션 구획은 유지되었는가, 테이블은 행과 열의 관계를 잃지 않았는가, 필드와 값의 연결은 정확한가, 반복되는 엔티티는 하나로 뭉개지지 않았는가. 이 질문에 대한 답이 곧 Parser의 성능이다.

모델 접근 방식의 차이 — 같은 입력, 다른 Parser 결과

두 모델은 애초에 문서를 바라보는 관점부터 다르다. 이 차이는 Parser 결과에서 그대로 드러난다.

Gemini는 멀티모달 모델로서 이미지와 텍스트를 함께 처리하지만, Parser 단계에서는 결과를 상대적으로 평면화된 구조로 출력하는 경향을 보인다. 문서의 전체 맥락을 하나의 흐름으로 이해하는 데는 강점이 있지만, 반복되는 항목이나 중첩 구조를 독립된 객체로 유지하는 데에는 한계가 나타난다. 결과적으로 구조는 유지되는 듯 보이지만, 세부 관계가 단순화되는 경우가 많다.

반면 DEEP Agent Lab은 처음부터 문서를 구조적 객체의 집합으로 다루는 Parser를 전제로 설계되어 있다. 문단, 섹션, 테이블, 반복 블록을 분리한 뒤 이들 간의 관계를 유지한 상태로 결과를 생성한다. 그래서 출력 결과 자체가 하나의 문서 구조 모델에 가깝다.

모델 비교 표

• Model Type

• Parsing Approach

• Parsing Unit

• Output Target

이 표는 두 모델의 기술적 지향점 차이를 한눈에 보여주는 역할을 한다.

실제 Parser 출력이 보여주는 차이

Parser 결과를 나란히 놓고 보면 차이는 매우 직관적이다. 같은 문서를 처리했음에도 불구하고, Gemini의 결과는 문서 전체가 하나의 연속된 구조로 정리되는 반면, DEEP Agent Lab의 결과는 원본 문서에서 보이던 섹션 단위, 테이블 단위, 반복 항목 단위가 그대로 유지된다.

특히 반복되는 엔티티나 동일한 양식이 여러 번 등장하는 구간에서 차이가 크게 벌어진다. Gemini의 결과에서는 유사한 항목들이 하나의 블록으로 합쳐지거나, 필드와 값의 대응 관계가 느슨해지는 경우가 발생한다. 반면 DEEP Agent Lab은 각 반복 항목을 독립된 구조로 유지해 이후 시스템에서 바로 순회하거나 검증할 수 있는 형태를 만든다.

결과 비교 표

• 동일 필드의 Parser 결과 나란히 비교

• 구조 유지 여부 시각 강조

이 구간은 독자가 ‘아, 이 결과는 바로 시스템에 쓸 수 있겠다’ 혹은 ‘다시 손을 봐야겠구나’를 직관적으로 판단하게 만드는 핵심 파트다.

정량 지표로 본 Parser 성능 비교

구조 재현력은 감각적인 인상이 아니라 수치로도 확인할 수 있다. 내부 테스트셋 200장을 기준으로, Parser 관점에서 의미 있는 지표만 추려 비교했다.

Parser 성능 비교 테이블

• Structural Reconstruction Accuracy

  Gemini: 74.2%

  DEEP Agent Lab: 97.9%

• Table Structure Preservation

  Gemini: 31.7%

  DEEP Agent Lab: 98.6%

• Field–Value Matching Accuracy

  Gemini: 79.4%

  DEEP Agent Lab: 99.2%

• Processing Speed (sec/page)

  Gemini: 2.8s

  DEEP Agent Lab: 0.7s

이 수치들이 의미하는 바는 명확하다. 구조가 단순한 문서에서는 두 모델의 차이가 덜 드러날 수 있지만, 테이블이 중첩되거나 반복 구조가 많은 문서로 갈수록 Parser 성능 차이는 급격히 확대된다.

카드형 비교로 요약하는 핵심 차이

위의 모든 내용을 요약하면, Parser 관점에서의 차이는 네 가지 지표로 정리된다.

카드형 비교 그래프

• Structural Reconstruction Accuracy

• Table Structure Preservation

• Field–Value Matching Accuracy

• Processing Speed

이 네 가지 지표는 Parser가 실제 실무에서 ‘쓸 수 있는 결과’를 만드는지를 판단하는 최소 조건이기도 하다.

Parser는 문서를 다시 ‘그리는’ 기술이다

이번 실험은 어떤 모델이 더 똑똑한지를 가리기 위한 비교가 아니다. 같은 문서를 입력했을 때, 누가 문서를 더 원래 모습에 가깝게 되살려내는가를 확인하는 과정이었다.

Parser의 본질은 문서를 이해하는 것이 아니라, 문서를 구조적으로 재현하는 것이다. 이 관점에서 보면, 구조 유지율과 관계 보존 능력에서 나타난 차이는 단순한 수치 이상의 의미를 가진다. 그것은 곧 자동화 가능 범위의 차이이기 때문이다.

문서 기반 시스템에서 중요한 것은 ‘읽을 수 있는 결과’가 아니라 ‘그대로 연결할 수 있는 구조’다. 그리고 이 실험은, Parser 단계에서의 설계 철학이 최종 결과를 얼마나 크게 바꾸는지를 분명하게 보여준다.