긴 문서를 AI에게 맡기면 손볼수록 나아질 거라 기대하게 됩니다. 마이크로소프트 리서치가 19개 모델에 20회씩 편집을 시켜본 결과는 정반대였죠. 마지막 회차의 문서에서는 원래 내용의 4분의 1이 조용히 사라져 있었습니다.
DELEGATE-52는 마이크로소프트 리서치의 Philippe Laban 연구팀이 만든 벤치마크입니다. 코딩부터 결정학, 악보 표기까지 52개 전문 분야의 문서를 19개 LLM에 넘기고, 한 번이 아니라 20회 연속으로 편집을 시켰죠. Gemini 3.1 Pro·Claude 4.6 Opus·GPT 5.4처럼 당시 가장 강했던 모델도 평균 25%를 훼손했고, 19개 전체 평균은 50%였습니다.
출처: LLMs Corrupt Your Documents When You Delegate – arXiv
오타가 아니라 문법이 멀쩡한 오류
논문이 쓴 표현은 “sparse but severe”입니다. 잔오류가 잔뜩 생기는 게 아니라, 적은 수의 치명적인 변경이 일어난다는 뜻이죠. 숫자 한 자리가 바뀌거나, 문장 중간의 조건절이 빠지거나, 인용된 이름이 슬쩍 달라지는 식입니다.
이런 오류는 읽어도 걸리지 않습니다. 문법도 맞고 앞뒤도 자연스러워서 교정을 한 번 본다고 잡히지 않죠. 원본에 뭐라고 적혀 있었는지 기억하는 사람만 발견할 수 있는 종류의 오류인 겁니다.
측정 방식도 이 지점을 겨냥해 설계됐습니다. 연구팀이 택한 방법은 문서를 분야별 구성 요소로 쪼갠 뒤 원본과 대조하는 것. 레시피라면 재료의 이름·수량·단위와 조리 단계로, 파이썬 코드라면 함수·클래스·임포트로 파싱하는 식이죠. 편집 지시는 전부 정보 손실 없이 되돌릴 수 있게 만들어져 있어, 원본과 벌어진 차이가 그대로 훼손량이 됩니다.
조금씩 나빠지는 게 아니라 어느 순간 무너진다
훼손은 회차마다 균등하게 쌓이지 않았습니다. 모델들은 어느 지점까지 멀쩡하게 버티다가 특정 회차에서 급격히 무너졌죠. 강한 모델의 우위도 덜 망가진다기보다, 무너지는 시점이 뒤에 있다는 쪽에 가깝다는 것.
이 차이는 실무에서 체감이 다릅니다. 품질이 서서히 떨어진다면 중간에 알아채고 멈출 수 있죠. 그런데 15회까지 괜찮다가 16회에서 무너지는 패턴이라면, 멈출 타이밍을 감으로 잡을 방법이 없는 겁니다.
문서가 클수록, 대화가 길수록 빨리 무너진다
훼손을 키우는 조건은 세 가지였습니다. 문서 크기, 상호작용 횟수, 그리고 작업과 무관한 파일이 함께 놓여 있는 상황이죠. 그중 크기의 영향이 가장 두드러집니다. 20회를 거친 뒤 1,000토큰짜리 문서는 정확도 91%를 유지한 반면, 10,000토큰 문서는 60%까지 떨어졌습니다.
도구를 붙이면 나아질 거라는 기대는 데이터가 받아주지 않았습니다. 파일 도구를 갖춘 기본적인 에이전틱 하네스를 씌우자 성능은 오히려 6%가량 나빠졌고, 입력 토큰은 2~5배 더 들었죠. 에이전트로 감싸면 알아서 해결된다는 통념이 여기서는 통하지 않는 겁니다.
파이썬만 통과한 시험
대부분의 모델이 논문의 기준선인 98% 정확도를 넘긴 분야는 52개 중 파이썬 하나뿐이었습니다. 이 영역에서는 19개 중 17개 모델이 기준을 통과했죠. 성적이 가장 좋았던 Gemini 3.1 Pro조차 52개 분야 중 11개에서만 그 선을 넘었습니다.
파이썬이 유독 안전했던 배경은 짐작하기 어렵지 않습니다. 학습 데이터가 압도적으로 많고, 구조가 엄격해 틀리면 곧바로 티가 납니다.
우리가 실제로 다루는 문서는 대체로 그 반대편이죠. 보고서, 제안서, 계약 초안, 회의록은 내용이 틀려도 문장이 성립합니다. 훼손은 바로 그 자리에서 일어나고, 그래서 눈에 띄지 않습니다.
같은 문제를 코드 쪽에서 다르게 푼 사례도 있습니다. 어시스턴트에게 파일 수정 권한을 아예 주지 않고 코드를 직접 옮겨 적는 방식인데, 원본을 아는 사람이 없어지는 상황 자체를 막는다는 점에서 방향이 겹치죠.
LLM에게 파일을 못 건드리게 했다, 인지 부채를 막는 어느 개발자의 규칙
써보려면
필요한 것: 새 도구가 아니라 편집을 맡기는 방식의 변경. 편집 전 원본을 따로 남겨둘 수 있는 환경(버전 관리나 사본 복제)이면 충분합니다.
시작 지점: 문서 전체를 넘기고 “다듬어줘”라고 하는 대신, 고칠 구간을 지정해 한 번에 하나씩 요청합니다. 같은 대화에 편집을 계속 쌓지 말고 회차를 끊어 새로 시작하는 것도 방법이죠.
잘 맞는 상황 / 안 맞는 상황: 문단 하나, 특정 주장 하나, 한 섹션처럼 범위를 못 박은 편집에서는 훼손이 크게 줄어듭니다. 반대로 긴 문서를 통째로 넘기는 개방형 지시, 그리고 같은 문서를 여러 세션에 걸쳐 계속 고쳐나가는 작업은 이 연구가 측정한 실패 조건과 정확히 겹칩니다.
참고자료:
답글 남기기