LLM 위임 작업의 문서 손상, 에이전트 시대의 품질 경고

위임형 AI의 병목은 “할 수 있나”가 아니라 “망가뜨리지 않나”다

arXiv에 공개된 DELEGATE-52 연구는 LLM을 단순 질의응답 도구가 아니라 문서를 맡겨 처리하는 대리자로 볼 때 생기는 문제를 정면으로 다룬다. 논문은 코딩, 결정학, 악보 표기 등 52개 전문 영역의 장기 문서 편집 과제를 만들고, 19개 모델을 실험했다. 핵심 결과는 불편하다. 연구진은 Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4 같은 프런티어 모델도 긴 위임 흐름이 끝날 무렵 평균 25%의 문서 내용을 손상시켰다고 보고했다.

이 결과는 바이브 코딩과 에이전틱 엔지니어링의 낙관론에 중요한 제동을 건다. 사람이 “이 파일을 고쳐줘”라고 맡기는 순간, 모델은 정답 한 줄을 내는 것이 아니라 기존 문맥을 보존하면서 변경해야 한다. 이때 오타보다 위험한 것은 조용한 의미 변형, 누락, 무관한 파일의 영향, 반복 수정 중 누적되는 구조 손상이다.

도구 사용이 자동으로 안전성을 높이지 않았다

논문에서 특히 눈에 띄는 대목은 에이전트형 도구 사용이 DELEGATE-52 성능을 개선하지 못했다는 분석이다. 도구 호출, 파일 접근, 단계적 편집은 겉보기에는 더 전문적인 워크플로처럼 보인다. 그러나 문서 크기, 상호작용 길이, 방해 파일이 늘어날수록 손상 정도가 커졌다는 결과는 도구가 곧 신뢰를 뜻하지 않는다는 사실을 보여준다.

이는 Braintrust 평가 키 유출 사건이 던진 평가 인프라 논점과도 이어진다. 에이전트를 제품에 넣는 기업은 “모델이 답을 잘한다”보다 “기존 산출물을 망가뜨리지 않는다”를 별도 지표로 봐야 한다. 예를 들어 원문 보존율, 변경 범위 일치율, 회귀 테스트, diff 설명 품질, 독립 검토 모델의 반박률 같은 운영 지표가 필요하다.

한국 기업은 에이전트 도입 전에 보존 테스트를 만들어야 한다

국내 개발팀과 문서팀은 AI 에이전트를 도입할 때 “작성 속도”보다 “보존 능력”을 먼저 측정해야 한다. 계약서, 제안서, 사내 위키, 코드베이스는 대부분 새 글을 쓰는 일이 아니라 기존 맥락을 유지하며 일부를 고치는 일이다. 따라서 파일을 맡기기 전 기준 버전을 고정하고, 변경 요청과 무관한 영역이 바뀌면 실패로 처리하는 테스트가 필요하다.

Airbnb의 AI 코드 60% 사례가 보여주듯 생성 비율은 빠르게 올라갈 수 있다. 하지만 생성 비율이 높아질수록 리뷰 부담도 커진다. Anthropic의 Claude 정렬 연구가 강조한 “왜 그렇게 행동했는가”의 설명 능력은 문서 위임에서도 필수다. 에이전트가 어떤 문단을 왜 바꿨는지, 무엇을 바꾸지 않았는지를 diff와 함께 설명해야 한다.

제품 설계의 답은 작은 권한과 짧은 루프다

DELEGATE-52의 메시지는 에이전트를 쓰지 말자는 뜻이 아니다. 오히려 에이전트를 더 좁은 권한, 더 짧은 루프, 더 강한 검증으로 설계하라는 신호다. 한 번에 전체 문서를 맡기는 대신 섹션 단위로 작업시키고, 변경 전후 체크섬과 의미 비교를 붙이며, 사용자가 승인하기 전에는 원본에 병합하지 않는 방식이 현실적이다.

OpenAI Realtime API나 Anthropic Claude Code 문서처럼 에이전트형 인터페이스는 계속 확장되고 있다. 하지만 실제 조직의 신뢰는 모델 이름이 아니라 운영 안전장치에서 나온다. 이제 AI 도입 체크리스트에는 “얼마나 잘 생성하는가”와 함께 “얼마나 덜 망가뜨리는가”가 같은 비중으로 들어가야 한다.

FAQ

Q1. DELEGATE-52는 무엇을 측정하나?
52개 전문 영역에서 긴 문서 편집을 LLM에 위임했을 때 원문이 얼마나 보존되는지와 오류가 어떻게 누적되는지를 측정한다.

Q2. 평균 25% 손상은 모든 모델에 똑같이 적용되나?
논문 초록은 프런티어 모델도 평균 25% 수준의 손상을 보였고, 다른 모델은 더 심각하게 실패했다고 설명한다.

Q3. 에이전트 도구를 쓰면 해결되나?
연구진은 도구 사용이 DELEGATE-52 성능을 개선하지 못했다고 보고했다. 도구보다 검증 설계가 중요하다.

Q4. 기업 문서 자동화에 가장 큰 위험은 무엇인가?
큰 오류보다 작은 의미 변형과 누락이 조용히 쌓이는 문제다. 나중에 발견하면 원인 추적과 복구가 어렵다.

Q5. 실무 도입의 첫 단계는 무엇인가?
원문 보존 테스트, 변경 범위 제한, diff 기반 승인, 회귀 검증, 책임자 리뷰를 기본 파이프라인으로 두는 것이다.