숫자부터 보자
마이크로소프트 연구진이 공개한 사전 논문 'LLMs Corrupt Your Documents When You Delegate'는 불편한 데이터를 들고 나왔다. 19개 LLM을 대상으로 52개 전문 분야, 310개 실제 업무 환경에서 다단계 편집 작업을 시킨 결과, 최고 성능 모델(GPT, Claude, Gemini 최신 버전)조차 20회 반복 편집 이후 평균 문서 내용의 25%를 손실했다. 전체 모델 평균 성능 저하율은 50%에 달했다. 파이썬 코딩 태스크는 그나마 '준비됐다'는 평가를 받았지만, 최고 성능 모델도 52개 분야 중 11개에서만 기준을 통과했다.
이게 왜 지금 중요한가
엔터프라이즈 AI 도입이 가속되고 있는 시점이라서다. SK AX가 OpenAI와 ChatGPT 엔터프라이즈 기반 서비스 파트너 계약을 체결하며 멀티 에이전트 구축과 운영을 전면에 내세운 것처럼, 지금 기업들이 실제로 움직이고 있다. 문제는 '도입 속도'와 '신뢰 가능 범위'가 함께 검토되지 않는다는 점이다. AI가 초안을 쓰고, 에이전트가 문서를 편집하고, 파이프라인이 반복 처리하는 워크플로우—딱 그 구조에서 MS 연구의 데이터가 터진다.
환각 문제가 아니다
이번 연구에서 주목할 지점은 '거짓말'이 아니라 '조용한 훼손'이다. 그레이하운드 리서치의 분석처럼, 핵심은 환각(hallucination)이 아니라 결과물 무결성(output integrity) 문제다. 고성능 모델은 내용을 단순 삭제하는 게 아니라 미묘하게 왜곡하거나 변형한다. 짧은 테스트에서는 성능이 좋아 보이지만, 워크플로우가 길어질수록—문서가 클수록, 상호작용이 쌓일수록—오류가 누적된다. 계약서, 정책 문서, 규정 준수 기록처럼 정확도가 곧 법적 책임으로 연결되는 문서라면 이 리스크는 단순한 품질 이슈가 아니다.
팀 리드로서 어떻게 읽어야 하나
세 가지로 정리된다.
첫째, 도메인별로 신뢰 수준을 다르게 설정해야 한다. 파이썬 코드 생성과 법률 문서 편집은 같은 AI 도구를 써도 검증 강도가 달라야 한다. DELEGATE-52 벤치마크가 보여준 도메인 간 성능 편차는 '만능 에이전트'라는 전제 자체를 흔든다.
둘째, 멀티 에이전트 구조가 항상 답이 아니다. MS 논문 안에서도 일부 멀티 에이전트 구조가 오히려 성능 저하를 심화시킨 사례가 언급된다. '에이전트가 편집하고, 다른 에이전트가 검토한다'는 설계는 직관적으로 맞아 보이지만, 검증 에이전트 자체의 한계도 동일하게 적용된다는 점을 잊으면 안 된다.
셋째, 도메인 전문가를 검증 루프에서 빼면 안 된다. AI 오류를 가장 잘 잡아내는 사람은 해당 도메인을 깊이 아는 사람이다. 비용 절감을 이유로 전문가를 줄이면서 AI에게 그 자리를 맡기는 순간, AI가 조용히 결과를 훼손했는지 판단할 능력도 함께 사라진다.
실전 검증 설계로 이어지려면
인포테크 리서치의 브라이언 잭슨이 제안한 방향은 현장에서 바로 쓸 수 있다. 파인튜닝으로 특정 도메인 성능을 끌어올리고, 수학적·결정론적 검증 단계를 파이프라인에 삽입하며, 오픈소스와 독점 모델 간 커스터마이징 가능성을 미리 따져두는 것. 여기에 하나를 더하자면—AI 에이전트가 처리한 결과물에 대한 '라운드트립 검증', 즉 원본과 결과물 간 차이를 자동으로 추적하는 레이어다. MS 연구에서 활용된 방식이기도 하고, 에이전트 워크플로우에서 가장 빠르게 오류 누적을 감지할 수 있는 구조다.
앞으로의 방향
이 논문은 아직 동료 검토 전이고, 결론을 과잉 해석할 필요는 없다. 하지만 방향은 명확하다. AI 에이전트를 워크플로우에 넣는 것은 막을 수 없는 흐름이고, 엔터프라이즈 도입도 가속될 것이다. 그 안에서 팀 리드가 해야 할 일은 '어디서 믿고 어디서 멈추는가'의 경계를 명시적으로 설계하는 것이다. AI는 글을 못 써서 실패하는 게 아니라, 결과를 유지하지 못해서 실패한다—이 문장이 다음 스프린트 검증 설계의 출발점이 되어야 한다.