GPT-5.5가 50%를 넘었다, 기업 문서 에이전트의 진짜 병목

AI 요약

• 무슨 일: Databricks가 GPT-5.5를 기업 에이전트 워크플로에 제공하기 시작했습니다.
  • OpenAI는 GPT-5.5가 OfficeQA Pro에서 50% 정확도를 넘은 첫 모델이며, GPT-5.4 대비 오류를 46% 줄였다고 밝혔습니다.
• 의미: 기업 AI 에이전트의 병목은 모델 추론만이 아니라 스캔 문서, 오래된 표, 수치 파싱, 근거 검색입니다.
• 배포 경로: GPT-5.5는 Databricks AI Unity Gateway, AgentBricks, Agent Supervisor API 안으로 들어갑니다.
  • 이는 RAG 데모가 아니라 권한, 평가, subagent 조율을 갖춘 production agent 경로에 가깝습니다.
• 주의점: 50% 돌파는 전환점이지만, OfficeQA Pro 논문 자체도 enterprise-grade grounded reasoning에는 아직 큰 여지가 남았다고 봅니다.

OpenAI가 2026년 5월 15일 Databricks의 GPT-5.5 기업 에이전트 워크플로 통합을 발표했습니다. 겉으로 보면 또 하나의 파트너 고객 사례처럼 보입니다. 하지만 이번 발표에서 볼 지점은 “Databricks가 OpenAI 최신 모델을 쓴다”가 아닙니다. 더 중요한 신호는 기업 문서 에이전트의 성패가 모델의 일반 추론 능력만으로 결정되지 않는다는 점입니다.

OpenAI 발표에 따르면 GPT-5.5는 Databricks의 OfficeQA Pro에서 50% 정확도를 넘은 첫 모델이 됐고, agent-harness 설정에서 GPT-5.4 대비 오류를 46% 줄였습니다. OfficeQA Pro는 단순 질의응답 벤치마크가 아닙니다. 스캔된 PDF, 오래된 표, 장문 문서, 수치 값, 여러 문서에 걸친 근거 검색을 함께 요구합니다. 기업 내부에서 실제로 자주 만나는 난장판에 가깝습니다.

이 숫자가 흥미로운 이유는 50%가 높아 보이지 않기 때문입니다. 프론티어 모델 발표에서 우리는 80%, 90%, 인간 전문가 상회 같은 문구에 익숙합니다. 그런데 여기서는 50%가 뉴스입니다. 이는 기업 문서 작업이 얼마나 거칠고, production agent가 얼마나 쉽게 작은 파싱 오류 하나에서 무너지는지 보여줍니다. Databricks와 OpenAI의 이번 발표는 “더 똑똑한 모델” 뉴스이면서 동시에 “기업 AI 에이전트가 왜 아직 어려운가”를 드러내는 뉴스입니다.

OfficeQA Pro는 왜 까다로운가

OfficeQA Pro는 2026년 3월 9일 arXiv에 공개된 Databricks 연구진의 벤치마크입니다. 논문은 이를 “대규모·이질적 문서 코퍼스 위의 grounded multi-document reasoning” 평가로 설명합니다. 코퍼스는 약 100년치 미국 Treasury Bulletins로 구성되고, 89,000페이지와 2,600만 개 이상의 수치 값을 포함합니다. 질문은 133개입니다.

이 구성은 일부러 불편합니다. 현대 SaaS 데이터베이스처럼 깨끗한 JSON이 아닙니다. 오래된 문서, 표, 스캔 품질, 서로 다른 레이아웃, 연도별 서식 차이, 숫자의 단위와 맥락이 섞여 있습니다. 기업 내부의 계약서, 재무 보고서, 감사 문서, 스캔 송장, 정책 PDF, 오래된 엑셀 추출물도 비슷한 문제를 갖습니다. 텍스트 검색으로 관련 페이지를 찾는 것만으로 끝나지 않고, 숫자가 어떤 표의 어느 행과 열에 있는지 이해해야 합니다.

논문 초록에서 더 날카로운 부분은 기존 프론티어 모델의 낮은 점수입니다. Claude Opus 4.6, GPT-5.4, Gemini 3.1 Pro Preview 같은 모델은 parametric knowledge에 의존하면 5% 미만, 웹 접근을 추가해도 12% 미만에 머물렀다고 합니다. 문서 코퍼스를 직접 제공한 frontier agents도 평균 34.1%였습니다. 모델이 강해도 문서 파싱, 검색, 분석 경로가 약하면 정답률은 쉽게 무너진다는 뜻입니다.

여기서 Databricks는 ai_parse_document가 만든 구조화 문서 표현을 제공했을 때 agent 성능이 평균 16.1% 상대 개선됐다고 보고했습니다. 이 대목이 중요합니다. 병목은 “모델이 모른다”만이 아닙니다. 모델에게 어떤 형태의 문서 표현을 주는가, 표와 숫자를 어떻게 보존하는가, retrieval이 어떤 단위로 이뤄지는가가 결과를 바꿉니다.

GPT-5.5의 개선은 어디서 나왔나

OpenAI 발표는 GPT-5.5가 OfficeQA Pro에서 50% 정확도를 넘고, GPT-5.4 대비 오류를 46% 줄였다고 말합니다. 또 Databricks 연구진은 GPT-5.5가 오래된 문서와 스캔 PDF의 숫자를 더 잘 파싱했고, 불필요한 search detour를 줄였다고 설명합니다. 이는 “더 긴 추론”보다 “더 안정적인 작업 경로”에 가까운 개선입니다.

기업 에이전트에서 작은 오류는 크게 증폭됩니다. 예를 들어 스캔 문서의 숫자 하나를 잘못 읽으면, 그 숫자에 기반한 계산이 틀어지고, 그 계산을 근거로 다음 검색 방향이 바뀌고, 최종 답변의 결론도 흔들립니다. RAG 시스템에서는 흔히 검색 품질을 먼저 말하지만, 실제 문서 업무에서는 검색 전에 추출이 있습니다. 텍스트와 표가 잘못 구조화되면 retrieval은 이미 오염된 재료를 검색합니다.

Databricks가 말한 불필요한 search detour도 같은 문제입니다. agent가 질문을 풀기 위해 여러 단계를 이동할 때, 중간에 엉뚱한 검색 경로로 빠지면 비용과 시간이 늘고, 잘못된 근거가 섞입니다. 사람이 문서를 검토할 때도 비슷합니다. 처음부터 잘못된 연도나 표를 붙잡으면, 이후 분석은 그럴듯하지만 틀린 방향으로 정교해집니다. 에이전트는 이 실패를 더 빠르게, 더 많이 반복할 수 있습니다.

따라서 GPT-5.5의 OfficeQA Pro 개선은 모델 점수 이상의 의미가 있습니다. production agent가 더 적은 supervision으로 긴 문서 워크플로를 끝낼 수 있는지, 숫자와 표를 근거로 더 안정적인 판단을 할 수 있는지의 문제입니다. 이 개선이 Databricks 고객 워크플로로 연결된다는 점도 그래서 중요합니다.

Databricks가 붙잡은 것은 모델이 아니라 경로입니다

이번 발표에서 Databricks는 GPT-5.5를 AI Unity Gateway를 통해 제공하고, 고객이 AgentBricks와 Agent Supervisor API로 만든 워크플로 안에서 사용한다고 설명합니다. 이 표현은 짧지만 많은 것을 담고 있습니다. 모델 호출 하나가 아니라, agent workflow의 관문, specialized agents, supervisor, parsing, retrieval, execution을 묶는 경로입니다.

Databricks의 Supervisor Agent 문서를 보면 방향이 더 분명합니다. Supervisor Agent는 Genie Spaces, agent endpoints, Unity Catalog functions, MCP servers, custom agents를 조율해 복잡한 작업을 처리합니다. 사용자는 시장 분석, 내부 프로세스 질의, 티켓 backlog 자동화, 고객 서비스 같은 use case를 만들 수 있습니다. 그리고 subject matter expert의 자연어 피드백으로 조율 품질을 개선합니다.

여기서 핵심은 권한입니다. Databricks 문서는 supervisor가 built-in access controls를 갖고 있으며, end user가 접근 권한을 가진 subagent와 데이터에만 접근한다고 설명합니다. subagent가 Genie Space이면 그 underlying Unity Catalog 객체에 접근권한이 필요하고, Unity Catalog function이면 EXECUTE 권한이 필요하며, external MCP server는 Unity Catalog connection의 USE CONNECTION 권한이 필요합니다.

이것은 기업 에이전트 제품의 현실적인 모양입니다. 챗봇이 “모든 사내 데이터를 검색합니다”라고 말하는 시대는 오래가지 못합니다. 실제 기업에서는 사용자의 직무, 팀, 지역, 보안 등급, 고객 데이터 접근권한, 감사 로그가 중요합니다. 에이전트가 여러 subagent와 tool을 조율한다면, 각 subagent가 보는 데이터와 실행 권한도 분리되어야 합니다. Databricks는 이 문제를 Unity Catalog와 AI Gateway, AgentBricks의 관리면 안으로 끌고 들어갑니다.

RAG 다음의 문제는 오케스트레이션입니다

지난 2년 동안 기업 AI의 기본 해법은 대체로 RAG였습니다. 문서를 벡터화하고, 질문이 들어오면 관련 chunk를 찾아 모델에 넣고, 답변과 출처를 돌려주는 방식입니다. 이 접근은 여전히 유용합니다. 하지만 OfficeQA Pro 같은 작업은 RAG만으로 충분하지 않습니다. 질문 하나가 여러 문서, 여러 표, 여러 계산, 여러 중간 검증을 요구하기 때문입니다.

예를 들어 “특정 기간의 재무 수치 변화가 어떤 정책 변화와 함께 나타났는가” 같은 질문을 생각해 보겠습니다. 시스템은 관련 문서를 찾고, 표에서 수치를 추출하고, 연도별 단위를 맞추고, 누락 값을 처리하고, 정책 문단을 찾아 연결하고, 최종적으로 근거와 계산을 설명해야 합니다. 이 작업은 단일 retrieval call보다 agent workflow에 가깝습니다.

그래서 Databricks가 Supervisor Agent를 강조하는 것은 자연스럽습니다. 하나의 거대한 agent가 모든 일을 하는 대신, 문서 질의 agent, 구조화 데이터 agent, Unity Catalog function, MCP server, custom agent를 조율합니다. supervisor는 어떤 하위 도구를 언제 호출할지 정하고, 결과를 합성합니다. GPT-5.5는 이 흐름에서 더 강한 reasoning model이자 orchestration model로 쓰입니다.

벤치마크 점수와 제품 신뢰 사이의 간격

50%를 넘었다는 수치는 전환점이지만, 동시에 경고입니다. 절반을 넘었다는 말은 여전히 많은 질문에서 틀린다는 뜻입니다. OfficeQA Pro 논문도 agents가 enterprise-grade grounded reasoning에서 신뢰 가능하다고 보기에는 아직 significant headroom이 남았다고 적습니다. 따라서 이 발표를 “기업 문서 업무 자동화가 해결됐다”로 읽으면 곤란합니다.

실무에서 50% 정확도는 사용처에 따라 완전히 다른 의미를 가집니다. 내부 리서치 초안, 문서 탐색, 숫자 후보 추출, 감사 준비를 위한 보조 작업에서는 꽤 유용할 수 있습니다. 반대로 재무 보고서의 최종 수치, 규제 제출, 대출 심사, 의료·보험 청구, 세무 판단처럼 오류 비용이 큰 작업에는 그대로 맡길 수 없습니다. 중요한 것은 모델이 답을 냈는가가 아니라, 어떤 근거와 중간 계산을 남겼고 사람이 어디서 검증할 수 있는가입니다.

이 지점에서 Databricks의 평가·거버넌스 계층이 중요해집니다. AgentBricks는 domain-specific agent를 만들고 subject matter expert 피드백으로 품질을 개선하는 방향을 제시합니다. MLflow evaluation, Unity Catalog governance, AI Gateway 같은 Databricks의 기존 강점도 여기와 맞물립니다. 모델이 좋아질수록 “그냥 모델을 바꾸면 된다”가 아니라 “모델 교체가 agent trajectory와 권한, 평가 결과에 어떤 영향을 주는가”를 봐야 합니다.

OpenAI 발표에 나온 46% 오류 감소도 마찬가지입니다. 오류가 줄었다는 것은 중요하지만, 어떤 오류가 줄었는지 봐야 합니다. 숫자 파싱 오류인지, 문서 검색 오류인지, multi-step orchestration 오류인지, final answer synthesis 오류인지에 따라 개선 방법이 다릅니다. production 팀은 전체 정답률보다 오류 분류와 재현 가능성을 더 원할 수 있습니다.

개발자에게는 문서 파이프라인 뉴스입니다

개발자 관점에서 이번 발표는 모델 선택 뉴스로 끝나지 않습니다. 기업 문서 에이전트를 만들려는 팀이라면 먼저 문서 파이프라인을 봐야 합니다. PDF를 어떤 OCR로 처리하는지, 표를 HTML이나 Markdown으로 펼칠 때 row와 column 의미가 보존되는지, 스캔 품질이 낮은 문서를 어떻게 표시하는지, 단위와 footnote를 어떻게 붙잡는지가 중요합니다.

많은 RAG 실패는 모델이 약해서가 아니라 입력 표현이 나빠서 발생합니다. 표가 줄 단위 텍스트로 무너지고, 페이지 번호와 섹션 제목이 사라지고, 헤더가 반복되지 않고, 통화 단위가 잘려 나가면 강한 모델도 추측을 시작합니다. OfficeQA Pro가 좋은 사례인 이유는 이런 지저분한 문서 현실을 정면으로 평가하기 때문입니다.

두 번째로 볼 것은 tool trajectory입니다. agent가 어떤 문서를 먼저 검색했고, 어떤 subagent를 호출했고, 어떤 중간값을 계산했고, 어느 시점에 경로를 바꿨는지 기록해야 합니다. 잘못된 답변만 보고 “모델이 틀렸다”고 말하면 고치기 어렵습니다. 파싱이 틀렸는지, retrieval이 틀렸는지, supervisor가 잘못 위임했는지, 계산 도구가 빠졌는지 분해해야 합니다.

세 번째는 권한 있는 retrieval입니다. 기업 문서 agent는 데이터 접근권한을 우회하면 안 됩니다. 사용자가 볼 수 없는 문서에서 근거를 가져오면 보안 사고입니다. 반대로 권한이 너무 좁으면 agent는 맥락이 부족해 허술한 답을 냅니다. Databricks 문서가 subagent별 end user 권한을 강조하는 이유가 여기에 있습니다.

AI 팀에게는 control plane 뉴스입니다

AI 팀과 플랫폼 팀에게 더 큰 질문은 control plane입니다. GPT-5.5 같은 모델은 앞으로 계속 바뀝니다. Claude, Gemini, Mistral, 오픈 웨이트 모델도 각자 다른 강점을 가집니다. 그러나 기업 workflow가 특정 모델 호출에만 묶이면 모델 교체와 평가가 어려워집니다. AI Gateway, agent registry, evaluation, permission, logging, feedback loop가 필요합니다.

Databricks는 이 층을 자사 데이터 플랫폼 위에서 풀려 합니다. Unity Catalog는 데이터와 function 권한을 관리하고, AI Unity Gateway는 모델 접근 경로를 통제하며, AgentBricks와 Supervisor Agent는 하위 agent와 tool을 묶습니다. 이 구조는 Snowflake Cortex AI, Microsoft Fabric과 Copilot, Salesforce Agentforce, ServiceNow AI Agent Orchestrator 같은 흐름과 같은 전장에 있습니다. 모두 “모델을 어디서 부를 것인가”보다 “기업 데이터와 권한 안에서 agent를 어떻게 운영할 것인가”를 묻고 있습니다.

이 경쟁에서 OpenAI의 역할도 달라집니다. OpenAI는 직접 ChatGPT와 Codex 제품을 밀고 있지만, 동시에 Databricks 같은 플랫폼 안에서 모델 공급자와 agent reasoning layer가 됩니다. 고객은 Databricks의 데이터·거버넌스·agent workflow 안에서 GPT-5.5를 쓰게 됩니다. 이는 OpenAI가 모든 enterprise workflow UI를 직접 소유하지 않아도, 핵심 추론 엔진으로 들어갈 수 있음을 보여줍니다.

반대로 Databricks 입장에서는 특정 모델 하나에 모든 가치를 맡기기 어렵습니다. 기업 고객은 OpenAI, Anthropic, Google, 오픈 모델을 함께 비교하고 싶어 합니다. 따라서 Databricks의 진짜 차별점은 “GPT-5.5를 제공한다”보다 “어떤 모델이든 enterprise document workflow에서 평가하고, 권한 아래 배포하고, subagent로 조율할 수 있다”에 가까워야 합니다.

커뮤니티 반응이 조용한 이유

이번 발표는 개발자 커뮤니티에서 폭발적인 토론을 만든 종류의 뉴스는 아닙니다. Hacker News의 큰 독립 스레드는 확인하기 어려웠고, GeekNews에는 3주 전 GPT-5.5 공개 요약 안에 OfficeQA Pro 수치가 포함되어 있었습니다. Reddit의 agent 관련 토론도 GPT-5.5가 내부 agent benchmark에서 얼마나 의미 있는지, high-stakes 작업에서 human-in-the-loop와 observability가 충분한지 묻는 수준입니다.

반응이 조용한 이유는 이해할 수 있습니다. Databricks의 고객 워크플로와 OfficeQA Pro는 화려한 데모보다 지루한 enterprise 문제에 가깝습니다. 스캔 PDF, 오래된 표, 권한, 평가, subagent orchestration은 짧은 영상으로 보여주기 어렵습니다. 하지만 실제 기업 도입에서는 바로 이런 지루한 문제가 성패를 가릅니다.

AI 에이전트 시장은 이제 두 층으로 나뉘는 듯합니다. 하나는 사용자가 바로 체감하는 Codex 모바일, Copilot 앱, Claude Code 같은 작업 표면입니다. 다른 하나는 Databricks, Snowflake, Salesforce, ServiceNow, Microsoft가 다루는 데이터·권한·workflow 표면입니다. 전자는 개발자의 손에 보이고, 후자는 조직의 운영 시스템 안에 숨어 있습니다. 이번 발표는 후자에 속합니다.

지금 팀이 확인할 것

첫째, 문서형 agent를 만들고 있다면 benchmark를 다시 잡아야 합니다. 일반 QA 정확도나 LLM judge 점수만으로는 부족합니다. 스캔 문서, 오래된 양식, 표, footnote, 단위 변환, 여러 문서 비교, 누락값 같은 실패 패턴을 포함해야 합니다. OfficeQA Pro가 그대로 맞지 않더라도, 그 정신은 가져올 만합니다.

둘째, parsing layer를 모델 밖의 일로 취급하지 말아야 합니다. OCR, table extraction, layout preservation, metadata, chunking은 agent 품질의 일부입니다. 특히 숫자와 표가 중요한 산업에서는 “모델이 알아서 읽겠지”가 가장 위험한 가정입니다. 모델이 좋아질수록 나쁜 입력을 더 그럴듯하게 보정해 버릴 수도 있습니다.

셋째, supervisor 구조를 쓴다면 권한과 관측성을 먼저 설계해야 합니다. 어떤 subagent가 어떤 데이터에 접근하는지, 사용자가 그 subagent를 호출할 권한이 있는지, tool call 결과가 로그에 남는지, 사람이 어느 지점에서 중간값을 검증할 수 있는지 정해야 합니다. Databricks 문서도 arbitrary code tool이 민감 정보 노출 위험을 만들 수 있다고 경고합니다.

넷째, 모델 교체를 평가 이벤트로 만들어야 합니다. GPT-5.5가 GPT-5.4보다 낫다는 발표가 있어도, 내부 문서와 내부 workflow에서 같은 개선이 나타나는지는 별도 문제입니다. 모델이 검색 detour를 줄였는지, 더 많은 tool call을 쓰는지, 비용이 어떻게 바뀌는지, hallucination이 줄었는지, 민감 데이터 접근 패턴이 변했는지 봐야 합니다.

50%의 벽이 말하는 것

GPT-5.5가 OfficeQA Pro에서 50% 정확도를 넘었다는 뉴스는 낙관과 경계를 동시에 줍니다. 낙관적인 이유는 enterprise document reasoning 같은 지저분한 작업에서도 모델과 agent harness가 실제로 개선되고 있기 때문입니다. 경계해야 하는 이유는 그럼에도 아직 절반 언저리라는 사실 때문입니다.

이 숫자는 AI 에이전트의 현재 위치를 꽤 잘 보여줍니다. 데모에서는 이미 많은 일이 가능해 보입니다. 하지만 production에서는 스캔 품질, 오래된 표, 권한, 검색 경로, 수치 계산, 감사 가능성이 한꺼번에 문제를 만듭니다. 강한 모델은 필요조건입니다. 충분조건은 아닙니다.

Databricks와 OpenAI의 이번 발표는 그래서 단순 파트너십 뉴스가 아닙니다. 기업 AI 에이전트가 어디서 다음 성능을 얻어야 하는지 보여줍니다. 더 큰 모델만이 아니라 더 나은 문서 표현, 더 정확한 retrieval, 더 투명한 tool trajectory, 더 단단한 권한 모델, 더 반복 가능한 평가 루프가 필요합니다. GPT-5.5가 50%의 벽을 넘긴 것은 시작입니다. 이제 남은 싸움은 그 점수를 실제 기업 업무에서 신뢰 가능한 워크플로로 바꾸는 일입니다.

출처

• OpenAI, Databricks brings GPT-5.5 to enterprise agent workflows
• OfficeQA Pro: An Enterprise Benchmark for End-to-End Grounded Reasoning
• Databricks, Use Supervisor Agent to create a coordinated multi-agent system
• Databricks, Create an AI agent
• GeekNews, GPT-5.5 공개