--- title: "LLM에게 문서 작업 맡기면 조용히 25%가 망가진다는 논문" published: 2026-05-09T08:44:34.000Z canonical: https://jeff.news/article/2381 --- # LLM에게 문서 작업 맡기면 조용히 25%가 망가진다는 논문 arXiv 논문은 LLM이 긴 위임형 문서 편집 워크플로에서 얼마나 문서를 망가뜨리는지 DELEGATE-52 벤치마크로 측정했다. Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4 같은 프론티어 모델도 긴 작업 끝에는 평균 25%의 문서 내용을 손상시켰고, 도구를 쓰는 agentic workflow도 성능을 개선하지 못했다. - 새 논문이 LLM 위임 작업의 찝찝한 부분을 정면으로 찌름. “맡기면 문서를 망가뜨린다”는 제목 그대로임 - 논문 제목은 `LLMs Corrupt Your Documents When You Delegate` - 2026년 4월 17일 arXiv에 제출된 Computation and Language 논문임 - 핵심 질문은 단순함. LLM에게 긴 문서 편집을 맡겼을 때, 결과물이 얼마나 원래 의도를 잘 보존하느냐임 - 연구진은 DELEGATE-52라는 벤치마크를 만들었음 - 긴 위임형 워크플로를 시뮬레이션함 - 코딩, 결정학, 음악 표기 같은 52개 전문 도메인을 포함함 - 요즘 말로 하면 vibe coding이나 에이전트형 문서 작업을 더 현실적으로 재현하려는 테스트임 > [!IMPORTANT] > 프론티어 모델도 긴 위임 작업 끝에는 평균 25%의 문서 내용을 손상시켰다는 게 가장 센 결과임. “가끔 실수함”이 아니라, 긴 작업에서는 조용히 누적되는 구조적 문제로 봐야 함. - 실험 대상은 19개 LLM이고, 프론티어 모델도 예외가 아니었음 - 논문 초록에 언급된 프론티어 모델은 Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4임 - 이 모델들도 긴 workflow가 끝날 때 평균적으로 문서 내용의 25%를 corrupt했다고 보고함 - 다른 모델들은 더 심하게 실패했다고 되어 있음 - “도구 쓰면 괜찮겠지”도 아니었음 - 추가 실험에서 agentic tool use가 DELEGATE-52 성능을 개선하지 못했다고 밝힘 - 파일 읽기·쓰기나 외부 도구 호출을 붙여도, 장기 문서 보존 문제가 자동으로 해결되진 않았다는 뜻임 - 이건 코딩 에이전트 쓰는 개발자한테 꽤 직접적인 경고임 - 손상은 특히 세 조건에서 더 심해짐 - 문서 크기가 커질수록 악화됨 - 상호작용 길이가 길어질수록 악화됨 - distractor 파일이 있으면 악화됨 - 실제 레포에서 에이전트에게 “이거 전반적으로 손봐줘”라고 맡기는 상황과 너무 닮아 있음 - 논문이 말하는 실패 양상은 “대충 못함”이 아니라 “드문드문 심각하게 망가뜨림”에 가까움 - sparse but severe errors라고 표현함 - 즉 전체가 눈에 띄게 엉망이 되는 게 아니라, 문서 어딘가에 치명적인 오류가 섞이는 패턴임 - 더 무서운 건 이 오류가 긴 상호작용 동안 누적된다는 점임 - 개발자 입장에서는 LLM을 대리 작업자로 쓸 때 검증 전략이 핵심이라는 얘기임 - 작은 diff, 테스트, 타입체크, 포맷 검사, 문서 스냅샷 비교 같은 안전장치가 없으면 조용한 손상을 놓치기 쉬움 - 특히 요구사항 문서, 설정 파일, 마이그레이션 문서처럼 “문장 하나 틀리면 의미가 바뀌는” 파일은 더 위험함 --- ## 기술 맥락 - 이 논문이 보는 문제는 모델이 답변을 잘하느냐가 아니라, 긴 작업을 맡겼을 때 기존 문서를 얼마나 보존하느냐예요. 채팅 벤치마크에서는 좋아 보여도, 실제 업무에서는 원문을 유지하면서 일부만 바꾸는 능력이 훨씬 중요하거든요. - DELEGATE-52가 긴 workflow와 전문 도메인을 넣은 이유도 여기에 있어요. 짧은 문장 수정은 모델이 잘해도, 여러 번 지시를 받고 파일이 커지고 주변 파일이 섞이면 주의가 분산되고 이전 제약을 잃기 쉬워요. - agentic tool use가 개선을 못 했다는 결과는 꽤 중요해요. 도구는 모델에게 손과 발을 달아주지만, 어떤 내용을 보존해야 하는지 판단하고 변경 범위를 통제하는 능력 자체를 보장하진 않거든요. - 그래서 실무에서는 “LLM이 편집했다”를 완료 조건으로 보면 위험해요. 테스트 가능한 산출물은 테스트를 돌리고, 문서는 diff 중심으로 리뷰하고, 긴 파일은 섹션 단위로 작업을 쪼개야 조용한 문서 손상을 줄일 수 있어요. ## 핵심 포인트 - DELEGATE-52는 코딩, 결정학, 악보 표기 등 52개 전문 분야의 긴 문서 편집 위임 작업을 시뮬레이션함 - 19개 LLM 실험에서 프론티어 모델도 긴 워크플로 종료 시 평균 25%의 문서 내용을 손상시킴 - 문서 크기, 상호작용 길이, distractor 파일 존재가 손상 정도를 더 키움 ## 인사이트 바이브 코딩이나 문서 편집 에이전트의 진짜 리스크는 ‘틀렸다고 크게 티 나는 답변’보다 ‘문서 어딘가를 조용히 망가뜨리는 변경’이다. 이 논문은 LLM을 대리 작업자로 쓰려면 결과물 전체를 검증하는 체계가 먼저라는 꽤 불편한 메시지를 던진다.