AI Tech Briefing

긴 문서를 AI에게 맡기면 어디가 조용히 망가질까

DELEGATE-52는 긴 전문 문서를 LLM에 맡겨 고치게 했을 때 숫자, 기록, 구조 같은 핵심 내용이 얼마나 남아 있는지 도메인별 평가기로 확인한 벤치마크다.

2026-05-10

왜 중요한가

AI 활용은 이제 질문에 답을 받는 수준을 넘어, 문서·코드·기록을 맡겨 고치게 하는 쪽으로 넓어지고 있다.
이때 위험한 점은 모델이 그럴듯한 오답을 말하는 것만이 아니다. 원문 파일 안의 숫자, 레코드, 주석, 구조가 눈에 잘 띄지 않게 바뀌거나 사라질 수 있다.
논문은 19개 LLM을 평가했고, 상위권 모델들도 긴 작업을 거친 뒤 평균 25%의 문서 내용 손상을 보였다고 주장한다.
평가 방식도 눈여겨볼 만하다. 단순한 문장 유사도가 아니라 회계, 악보 표기, 결정학, Python 같은 분야별 파서와 평가기로 그 문서에서 중요한 단위가 보존됐는지 확인한다.
raw 노트, knowledge 문서, 논문 초안, 운영 문서를 LLM이 고칠 때는 전체를 다시 쓰게 하기보다 필요한 부분만 고치고, 변경점과 보존 조건을 확인하는 흐름을 기본값으로 둬야 한다.

이 연구가 짚는 문제는 “AI가 글을 얼마나 잘 쓰나”보다 더 실무적이다. 긴 문서를 통째로 맡겼을 때, 겉보기에는 그럴듯한 결과물 안에서 원래 지켜야 할 세부 내용이 얼마나 새는지를 보려는 평가다.

그래서 더 큰 컨텍스트 창만으로는 부족하다. 실제 문서 도우미라면 변경 전후 비교, 버전 관리, 숫자·인용·레코드 보존 확인, 되돌리기 같은 안전장치가 함께 있어야 한다.

법무/재무/의료/연구지원 팀: 긴 문서나 기록을 AI에게 “정리해서 다시 써줘”라고 맡기는 workflow의 위험을 평가하는 기준으로 쓸 수 있다.
제품팀: document assistant의 핵심 기능은 더 큰 context window만이 아니라 diff, versioning, invariant validation, source preservation, rollback이다.
enterprise AI adoption 팀: 직원에게 AI 사용을 독려하기 전에 어떤 문서는 whole-file rewrite 금지, 어떤 문서는 validator 필수인지 정책화하는 데 쓸 수 있다.
benchmark/eval 팀: 일반 LLM judge보다 domain-specific parser와 reversible edit pair를 조합한 장기 workflow benchmark 설계 예시로 볼 수 있다.

AI evaluation을 단발 정확도에서 장기 위임 workflow의 누적 손상률로 확장하는 참고 사례가 된다.
회의록, 장부, 실험 기록, 논문 draft를 LLM에게 맡길 때 “최종 문서만 보기”가 아니라 원문 대비 diff, 숫자/인용/레코드 보존 check를 붙이는 근거가 된다.
파일 편집은 가능하면 전체 rewrite보다 line/section-level patch, exact replacement, AST/structured edit, rollback 가능한 diff preview를 쓰도록 운영 원칙에 반영할 만하다.
raw/knowledge 노트 갱신 후 invariant 체크(링크 보존, 날짜/slug 보존, 표 항목 수 보존 등)를 자동화하는 방향으로 연결할 수 있다.
긴 문서나 기록을 AI에게 “정리해서 다시 써줘”라고 맡기는 workflow의 위험을 평가하는 기준으로 쓸 수 있다.
document assistant의 핵심 기능은 더 큰 context window만이 아니라 diff, versioning, invariant validation, source preservation, rollback이다.
직원에게 AI 사용을 독려하기 전에 어떤 문서는 whole-file rewrite 금지, 어떤 문서는 validator 필수인지 정책화하는 데 쓸 수 있다.
일반 LLM judge보다 domain-specific parser와 reversible edit pair를 조합한 장기 workflow benchmark 설계 예시로 볼 수 있다.

이번 hands-on은 전체 벤치마크 재현이 아니다. API 비용과 시간이 커서 repo, dataset, evaluator 수준에서 확인했다.
논문에서 agentic tool use가 개선하지 못했다고 한 대목은 기본 harness 기준이다. HN에서도 최신 coding agent의 편집 도구 묶음과는 다르다는 비판이 있었다.
문서 전체를 다시 주고받는 방식은 숙련된 AI engineer가 쓰는 search/patch 방식보다 불리할 수 있다.
다만 비전문 사용자가 긴 문서를 통째로 넣고 “수정해서 다시 줘”라고 하는 실제 사용 방식과는 꽤 가깝다.
공개 dataset은 재배포 가능한 subset이며, 논문 전체 벤치마크와 완전히 같지는 않다.
분야별 evaluator도 절대적인 정답 판정기가 아니라 손상을 잡아내기 위한 proxy로 봐야 한다.

문서 도우미 제품들이 더 큰 context window만 내세우는 데서 그치지 않고 diff, versioning, invariant validation, rollback을 기본 기능으로 넣는지 볼 것.
최신 coding agent식 edit tool suite가 whole-document round-trip보다 실제 손상률을 얼마나 줄이는지 비교할 것.
기업 AI 도입 정책에서 whole-file rewrite 금지 문서와 validator 필수 문서를 나누는 흐름이 생기는지 볼 것.