Codex와 Claude는 전용 문서 도구 없이도 Word 문서를 편집할 수 있습니다. 이들은 .docx 파일을 ZIP 패키지로 열고, XML을 검사하며, 적절한 노드를 찾기 위해 Python 또는 C# 코드를 작성하여 내용을 변경한 뒤 패키지를 다시 저장할 수 있습니다.

이 방식이 작동은 하지만, 에이전트는 편집 작업뿐만 아니라 편집을 위한 도구 세트까지 생성해야 합니다. 아주 작은 요청이라도 Word의 run(실행 단위) 전체에서 텍스트를 찾고, 서식을 유지하며, 변경 내용 추적(tracked changes)을 처리하고, 문서의 유효성을 유지하기 위한 코드로 변질될 수 있습니다.

저는 이미 해당 도구들을 구현하고 있는 Model Context Protocol (MCP) 서버가 에이전트가 방출하는 출력 토큰(output tokens)을 줄일 수 있는지 알고 싶었습니다. 저는 찾기(find), 바꾸기(replace), 서식 지정(format), 메모(comment), 변경 내용 수락(accept revisions)과 같은 Word 작업을 도구로 노출하는 OfficeAgent.NET을 사용했습니다. 에이전트는 XML 조작 코드를 작성하는 대신, 압축되고 구조화된 도구 호출(tool call)을 통해 변경 사항을 설명할 수 있습니다.

테스트 내용

네 가지 에이전트 및 모델 조합이 동일한 Word 계약서를 편집했습니다:

• Claude Code와 Sonnet 5;
• Claude Code와 Opus 4.8;
• Codex와 GPT 5.6 Sol;
• Codex와 GPT 5.6 Terra.

각 조합은 동일한 7가지 편집 작업을 받았습니다:

• 변경 내용 추적이 포함된 텍스트 변경;
• 단락 서식 지정;
• 콘텐츠 컨트롤(content control) 채우기;
• 문장 삽입;
• 표 삽입;
• 검토 메모 추가;
• 모든 변경 내용 수락.

벤치마크는 두 가지 경로를 비교했습니다:

• 직접 편집 (Direct editing): 에이전트가 문서 MCP 없이 Open XML SDK 또는 원시 OOXML을 사용함.
• MCP 편집 (MCP editing): 에이전트가 OfficeAgent.NET을 통해 편집을 수행함.

주요 비교는 작업 및 조건당 5회씩 시도되었습니다. Open XML SDK를 기반으로 직접 구축된 별도의 검증기(verifier)가 저장된 문서를 확인했습니다. 아래의 토큰 수치는 검증에 성공한 시도들의 중앙값(median)을 사용합니다.

이 벤치마크는 기존 문서에 대한 편집만을 다룹니다. 문서를 처음부터 생성하는 것은 다른 작업 부하이며 포함되지 않았습니다.

결과

MCP output tokens relative to direct editing

7개의 태스크 전반에 걸쳐, 태스크 수준의 MCP/직접 출력 토큰 비율(task-level MCP/direct output-token ratios) 중앙값은 다음과 같았습니다:

• Claude Code, Sonnet 5: 33%
• Claude Code, Opus 4.8: 28%
• Codex, GPT 5.6 Sol: 36%
• Codex, GPT 5.6 Terra: 51%

수치가 낮을수록 좋습니다. 예를 들어 33%라는 결과는, 중앙값 태스크 수준 비교 시 MCP 워크플로가 직접 편집(direct editing) 방식의 출력 토큰(output tokens) 중 약 3분의 1만을 사용했음을 의미합니다.

28개의 태스크 및 모델 비교 모두에서 MCP 경로를 사용했을 때 성공적인 시도(successful-attempt)의 중앙값이 더 낮았습니다.

이 감소 폭은 모든 작업에서 동일하지 않았습니다. 수정 사항을 수락(Accepting revisions)하거나 주석을 추가(adding comments)하는 작업이 일부 단순한 서식 지정(formatting) 및 삽입(insertion) 작업보다 더 큰 이점을 얻었습니다.

이는 제안된 메커니즘을 뒷받침합니다: 도구가 문서 특화적인 절차(document-specific procedure)를 더 많이 흡수할수록, 모델이 생성해야 하는 구현 코드(implementation code)는 줄어듭니다.

토큰 절감과 비용 절감은 동일한 것이 아닙니다

Claude session cost relative to direct editing

출력 토큰(output-token)의 감소는 컸습니다. 하지만 세션 비용(session-cost)의 감소는 그보다 작았습니다.

Claude의 경우, 태스크 수준의 세션 비용 비율(session-cost ratio) 중앙값은 다음과 같았습니다:

• Sonnet의 경우 직접 방식 대비 83%
• Opus의 경우 직접 방식 대비 84%

14개의 Claude 태스크 및 모델 비교 중 2개는 출력 토큰을 더 적게 사용했음에도 불구하고 MCP 사용 시 비용이 약간 더 높았습니다.

그럴듯한 원인은 입력 오버헤드(input overhead)입니다. MCP 도구 정의(tool definitions)는 컨텍스트(context)를 추가하는 반면, 새로운 입력(fresh input), 캐시 읽기(cache reads), 캐시 쓰기(cache writes), 그리고 출력 토큰(output tokens)은 서로 다른 가격이 책정됩니다. 이 벤치마크는 각 구성 요소의 기여도를 분리하여 측정하지는 않았습니다.

기록된 수치는 모델 세션 비용(model-session costs)이며, 총 소유 비용(total cost of ownership)은 아닙니다. 여기에는 MCP 서버를 호스팅, 보안 유지 또는 관리하는 비용은 포함되지 않았습니다. Codex는 비교 가능한 USD 비용을 보고하지 않았으므로, 에이전트 간의 달러 단위 비교는 수행하지 않았습니다.

이 결과가 증명하지 않는 것

본 실험은 파일럿(pilot) 테스트였습니다:

• 하나의 Word 문서
• 지원되는 7가지 편집 작업
• 2개의 에이전트 환경
• 에이전트당 2개의 모델
• 주요 비교 셀당 5회의 시도

직접적인 베이스라인(baseline)은 Open XML SDK를 사용할 수 있었으나, 성숙한 재사용 가능 Word 편집 추상화(abstraction)는 갖추고 있지 않았습니다. 이미 이러한 추상화를 보유한 팀이라면 차이가 더 작게 나타날 수 있습니다.

검증기(verifier)는 요청된 OOXML 변경 사항이 존재하는지 확인했습니다. 이는 완전한 시각적 동일성을 증명하거나 문서 내 다른 곳에서 발생할 수 있는 모든 의도하지 않은 변경을 배제하지는 않았습니다.

또한 이 결과가 모든 MCP 서버가 토큰을 줄여준다는 것을 의미하지는 않습니다. 해당 작업이 지원되어야 하며, 에이전트가 실제로 도구 경로(tool path)를 사용해야 합니다.

결론

일부 Word 편집 워크플로(workflows)에서 MCP 서버는 문서 특화 구현 사항을 대화에서 분리하여 재사용 가능한 도구로 옮김으로써, 에이전트가 더 적은 출력 토큰(output tokens)을 생성하도록 할 수 있습니다.

이 파일럿 테스트에서 작업 수준의 MCP/직접 방식 중앙값 비율(median task-level MCP/direct ratio)은 에이전트와 모델에 따라 28%에서 51% 사이였습니다.

실질적인 교훈은 MCP가 자동으로 에이전트를 저렴하게 만든다는 것이 아닙니다. 잘 맞춤화된 도구가 모델로부터 방대한 양의 절차적 작업(procedural work)을 제거할 수 있다는 것입니다.

AI 에이전트를 사용하여 Word 문서를 편집하는 팀이라면, 가장 자주 수행하는 작업들을 대상으로 이를 테스트해 볼 가치가 있습니다.

이 벤치마크에 사용된 프로젝트는 GitHub에서 확인할 수 있습니다: OfficeAgent.NET