LLM에게 문서 작업 맡기면 조용히 25%가 망가진다는 논문

• 새 논문이 LLM 위임 작업의 찝찝한 부분을 정면으로 찌름. “맡기면 문서를 망가뜨린다”는 제목 그대로임

  • 논문 제목은 LLMs Corrupt Your Documents When You Delegate
  • 2026년 4월 17일 arXiv에 제출된 Computation and Language 논문임
  • 핵심 질문은 단순함. LLM에게 긴 문서 편집을 맡겼을 때, 결과물이 얼마나 원래 의도를 잘 보존하느냐임

• 연구진은 DELEGATE-52라는 벤치마크를 만들었음

  • 긴 위임형 워크플로를 시뮬레이션함
  • 코딩, 결정학, 음악 표기 같은 52개 전문 도메인을 포함함
  • 요즘 말로 하면 vibe coding이나 에이전트형 문서 작업을 더 현실적으로 재현하려는 테스트임

• 실험 대상은 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 중심으로 리뷰하고, 긴 파일은 섹션 단위로 작업을 쪼개야 조용한 문서 손상을 줄일 수 있어요.