편집기 이면

이 문서 편집에 뛰어난 이유는 무엇인가요?

언어 모델은 훌륭한 문장을 작성할 수 있지만, 이를 서식과 함께 다시 제자리에 넣는 것은 별개의 작업입니다. 본문에서는 AI가 문서를 편집하도록 만드는 것이 왜 어려웠는지, 그리고 이를 해결하기 위해 무엇을 구축했는지 설명합니다.

읽는 시간 9분2026년 10월 3일

개요

Word 파일의 조항을 수정해 달라고 챗봇에게 요청하는 것은 동시에 두 가지 일을 시키는 것입니다. 단어를 바꾸는 것과 그 단어를 담고 있는 파일 형식을 다시 쓰는 것입니다. 언어 모델은 첫 번째 작업은 잘하지만 두 번째 작업에는 신뢰성이 떨어집니다.

은 모델로부터 두 번째 작업을 덜어줍니다. 이 글에서는 그것이 왜 중요한지, 긴 문서에서 어떻게 작동하는지, 그리고 챗봇 웹사이트 및 컴퓨터 사용 에이전트와 어떻게 비교되는지 설명합니다.

  1. 01언어 모델은 문서를 페이지가 아니라 마크업으로 읽습니다.
  2. 02잘못된 문자 하나로 인해 파일을 읽을 수 없게 될 수 있으며, 긴 출력물은 잘못된 문자가 포함될 가능성을 높입니다.
  3. 03은 콘텐츠와 서식을 분리합니다. 모델은 단어를 수정하고, 우리의 코드는 파일을 작성합니다.
  4. 04최신 코딩 에이전트가 그러하듯, 긴 문서는 일괄 처리 및 분할되어 컨텍스트가 부여됩니다.
  5. 05채팅 웹사이트는 Python을 사용하여 파일을 편집할 수 있지만, 변경 사항이 조용히 누락될 수 있습니다.
  6. 06컴퓨터 사용 에이전트는 인간처럼 편집하며, 비용은 몇 배나 듭니다.

01

LLM은 서식이 아니라 텍스트만 봅니다

Word에서 계약서를 열면 하나의 페이지가 보입니다. 사내 스타일의 제목, 굵게 표시된 금액, 밑줄 친 기한 등입니다. Word가 이러한 서식을 만들어 주므로 우리는 눈으로 보며 편집할 수 있습니다. 그러나 Word 파일(.docx)의 내부는 복잡한 XML 체계로, 우리가 보는 모든 단어에는 마크업이라고 부르는 숨겨진 태그가 빽빽하게 붙어 있습니다.12

보이는 내용

모델이 보는 것

<w:p>  <w:pPr><w:pStyle w:val="Heading2"/></w:pPr>  <w:r><w:t>4. 임대료</w:t></w:r></w:p><w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">임차인은 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>매월 1일</w:t></w:r>  <w:r><w:t xml:space="preserve">에 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>를 지급해야 합니다.</w:t></w:r></w:p>
그림 1같은 조항을 두 번 보여 줍니다. 단어는 37자이고, 그 주변의 XML은 426자입니다. word/document.xml의 발췌입니다.

LLM은 Microsoft Word, LibreOffice, Pages의 도움을 받지 못하며 마크업에 대한 자체 이해에 의존해야 합니다. 올바르게 편집하려면 LLM이 원래 마크업의 효과를 이해하고 올바른 마크업으로 새 문장을 작성해야 합니다.

02

LLM 출력은 본질적으로 불안정합니다

모델이 크게 향상되었기는 하지만 최신 모델조차 여전히 실수를 범합니다. 52개의 전문 도메인에 걸쳐 19개의 모델을 대상으로 한 2026년 Microsoft Research의 연구에 따르면, Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4 같은 최첨단 모델은 긴 편집 워크플로가 끝날 무렵 문서 내용의 평균 25%를 손상시켰습니다.4

Word 파일에서는 사소한 실수 하나만으로도 파일을 사용할 수 없게 만들기에 충분합니다. 여기서는 모델이 단일 슬래시를 누락했습니다.

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">임차인은 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>매월 1일</w:t></w:r>  <w:r><w:t xml:space="preserve">에 </w:t></w:r>  <w:r><w:rPr><w:b>1<w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>를 지급해야 합니다.</w:t></w:r></w:p>
그림 2슬래시 하나가 빠지면 굵게 태그가 열린 채로 남습니다. XML이 더 이상 올바른 형식이 아니므로 Word에서 파일을 정상적으로 열 수 없습니다.3

XML은 잘못된 마크업을 전혀 허용하지 않습니다. 파일은 형식이 제대로 갖추어져 있거나 그렇지 않거나 둘 중 하나입니다. Word는 손상된 파일을 복구할 수 있는 경우도 있지만, 복구된 사본에는 텍스트나 서식이 누락되어 있을 수 있습니다.

더 긴 출력, 더 많은 실수

위험은 길이에 비례하여 커집니다. 긴 구조화된 출력에 대한 2025년 벤치마크인 LongProc에 따르면, 공개 가중치 모델은 출력 토큰 2,000개에서 흔들리기 시작하고 GPT-4o는 8,000개에서 크게 저하되는 것으로 나타났습니다.5 또 다른 연구에 따르면, 모델이 모든 관련 사실을 검색할 수 있더라도 입력이 길어짐에 따라 성능이 13.9%에서 85%까지 떨어집니다.6 10페이지 분량의 Word 문서는 약 10,000개 토큰에 해당하므로, 오류 없이 10페이지 전체를 한 번에 편집하려고 하는 것은 성공 확률이 매우 희박한 일입니다.

<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.1</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> Harlow &1 Pike LLP은(는) 본 임대차계약에 따라 발생하는 모든 사항에 대하여 임대인을 대리합니다.</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24/>2</w:rPr><w:t>5.2</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 임차인은 임대 목적물을 양호하고 충분히 수선된 상태로 유지해야 합니다.</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.3</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 모든 통지는 서면으로 작성되어 별지 2에 명시된 주소로 전달되어야 합니다.</w:t></w:p>3<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.4</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 임대인은 임대료가 21일 이상 연4
  1. 1텍스트 안의 이스케이프되지 않은 앰퍼샌드(&). XML에서는 엔티티로 이스케이프해야 합니다.
  2. 2누락된 닫는 따옴표. 그 뒤의 모든 내용이 값의 일부로 읽힙니다.
  3. 3문단이 끝나기 전에 닫히지 않은 런(run).
  4. 4출력이 단순히 멈춥니다. 긴 생성 결과는 길이 제한에 도달하거나 태그 중간에 시간 초과가 발생할 수 있습니다.
그림 3모델 출력의 4가지 조항, 4가지 종류의 오류. 그중 하나만으로도 파일은 읽을 수 없게 됩니다.

03

이 이를 해결하는 방법

당사에서는 서식과 콘텐츠를 분리하는 맞춤형 프로그램을 작성합니다. 모델은 변경해야 할 단어들과 페이지의 렌더링된 이미지를 함께 수신하므로, Word 프로그램의 지원을 받게 됩니다. 그런 다음 당사의 코드는 편집된 단어들을 원래의 런(run)에 다시 넣고 파일의 나머지 부분은 그대로 둡니다.

내 파일

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">임차인은 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>매월 1일</w:t></w:r>  <w:r><w:t xml:space="preserve">에 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>를 지급해야 합니다.</w:t></w:r></w:p>

은 콘텐츠와 서식을 분리합니다

추출된 콘텐츠

임차인은 매월 1일에 US$2,400를 지급해야 합니다.

렌더링된 페이지

둘 다 모델로 전송됩니다

언어 모델단어를 편집합니다. XML은 절대 건드리지 않습니다.

모델이 수정된 콘텐츠를 반환합니다

모델 출력

임차인은 매월 1일매월 5일에 US$2,400US$2,600를 지급해야 합니다.

은 단어들을 원래의 런(run)에 다시 써 넣습니다

수정된 내 파일

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">임차인은 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>매월 5일</w:t></w:r>  <w:r><w:t xml:space="preserve">에 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,600</w:t></w:r>  <w:r><w:t>를 지급해야 합니다.</w:t></w:r></w:p>

✓ 유효한 .docx. 굵게, 색상, 밑줄이 그대로 유지됩니다.

그림 4간소화된 수정 파이프라인. 강조 표시된 텍스트는 파일에서 변경된 유일한 부분입니다.

이것은 두 가지 문제를 한 번에 해결합니다. 모델은 이전에 볼 수 없었던 서식을 이제 볼 수 있게 되며, 가장 깨뜨리기 쉬웠던 마크업을 더 이상 작성하지 않습니다.

일반 목적의 챗봇에서는 이 레이어를 찾을 수 없습니다. 추출, 렌더링 및 재조립 프로그램은 의 자체 엔지니어들이 직접 구축하고 유지관리합니다.

04

긴 컨텍스트 문제 해결

일부 수정 작업은 길 수 있습니다. 여러 페이지에 걸쳐 이어지는 단락이거나 수백 곳에 일관되게 적용되는 하나의 변경 사항이 이에 해당합니다. 이러한 작업을 위해 당사는 소프트웨어 엔지니어링에서 교훈을 얻었습니다. 2026년 3월, Anthropic은 공개 npm 패키지 내에 자사의 AI 코딩 에이전트인 Claude Code의 소스 코드를 실수로 게시했습니다.7

유출된 해당 코드 에디터가 주는 교훈은 명확합니다. 긴 내용을 수정하려면 쪼개야 한다는 것입니다. 우리는 문서를 일괄 처리(batching)라는 기법을 사용해 여러 페이지 그룹으로 나누고, 긴 문단을 문장 단위로 쪼개어 각 수정 작업이 올바르게 이루어질 만큼 충분히 작게 만듭니다.

문서를 분할하면 새로운 문제인 '컨텍스트'가 생깁니다. 2페이지의 정의를 사용해 60페이지의 단락을 어떻게 편집할까요? 여기서 AI 코드 에디터(Cursor, GitHub Copilot, OpenAI Codex)의 2년간 경험이 빛을 발합니다. 그들의 해답은 컨텍스트 엔지니어링으로, 관련 정보를 모아 집중된 컬렉션으로 만든 뒤 깨끗한 컨텍스트 윈도우를 가진 서브 에이전트에 전달하는 것입니다.8 우리는 문서에도 같은 방식을 적용합니다. 꼼꼼한 독자처럼 논리적으로 관련된 정보를 묶은 다음, 편집 대상과 함께 실제 수정을 수행하는 서브 에디터에 전달합니다.

1문서 일괄 처리

1–40쪽41–80쪽81–120쪽121–160쪽161–200쪽201–240쪽241–280쪽281–300쪽

2긴 문단 나누기

제18.3조 · 60쪽
문장 1문장 2문장 3문장 4문장 5

3컨텍스트를 수집한 후 병렬로 편집

정의된 용어2–12쪽

당사자 및 역할1쪽

이전 개정 사항34쪽

서브 에디터 11–40쪽 + 컬렉션

서브 에디터 241–80쪽 + 컬렉션

서브 에디터 381–120쪽 + 컬렉션

그림 5300페이지 분량의 문서를 세분화한 모습입니다. 각 서브 에디터는 문서의 작은 조각과 그 조각이 의존하는 컨텍스트를 받습니다.

예시: 판결문 비공개 처리

변호사는 판결문 내의 모든 증인 이름을 비공개 처리하고, 주니어 변호사가 조사할 인용 판례 목록을 원합니다.

  1. 검색. 은 일반적인 패턴 매칭을 통해 모든 인명과 판례 인용을 찾아냅니다. 아직 어떠한 모델도 필요하지 않습니다.
  2. 분류. 각 이름은 주변 문장과 함께 모델로 전달되어 증인, 변호사, 판사 중 무엇인지 판별합니다. 그 답변들을 모아 증인 목록을 구축합니다.
  3. 수집. 같은 방법으로 인용된 판례 모음을 구축합니다.
  4. 실행. 각 증인 이름이 발견된 위치를 정확히 알고 있으므로, 원본 파일에서 다른 곳은 건드리지 않고 오직 그 위치만 가립니다.

고등법원

킹스 벤치부

Harrow v Kestrel Logistics Ltd

변경 전: Mrs Justice Holloway

판결

Mrs Justice Holloway: 본 청구는 2024년 3월 14일 피고의 창고에서 발생한 하역장 붕괴 사고에서 비롯되었습니다. 원고는 Ms Priya Raman의 대리를 받았고 피고는 Mr Thomas Whitby의 대리를 받았습니다. 본인은 4일 동안 구두 증언을 청취했습니다.

핵심 목격자인 Mr Daniel Okafor(은)는 야간 근무 지게차 운전사였습니다. Mr Okafor(은)는 법정에서 하역장의 경고등이 몇 주 동안 고장 상태였으며 이를 두 번 보고했다고 진술했습니다. 2월에 하역장을 점검한 계약업자인 두 번째 목격자 Ms Margaret Ellison(은)는 자신의 보고서에서 즉각적인 수리를 권고했다고 확인해 주었습니다. 저는 두 목격자 모두 신중하고 신뢰할 만하다고 판단했습니다.

적법하게 구내에 있는 자에 대한 점유자의 주의 의무는 확립되어 있으며, 본인은 Donoghue v Stevenson [1932] AC 562의 이웃 원칙을 출발점으로 삼습니다. 새로운 상황에서 의무를 부과하는 것이 공정하고 정당하며 합리적인지 여부는 Caparo Industries plc v Dickman [1990] 2 AC 605에 의해 판단되지만, 본 사안의 상황은 새롭지 않습니다. Mr Whitby는 청구된 손해가 인과관계상 지나치게 멀다고 주장했습니다. 이 주장은 Hadley v Baxendale (1854) 9 Exch 341에 비추어 검토되어야 합니다.

Mr Okafor 및 Ms Ellison의 증거를 문서와 함께 검토한 결과, 피고가 결함을 알고도 조치를 취하지 않았음을 확신합니다. 청구는 책임 여부와 관련하여 인용됩니다. 손해배상액은 추후 심리를 통해 산정됩니다. 명확하고 집중된 변론을 해 주신 Ms Raman 및 Mr Whitby께 감사드립니다.

그림 6보기를 전환하여 결과를 확인하세요. 판결과 이름은 허구이며, 인용된 세 건의 판례는 실제입니다.

05

chatgpt.com, claude.ai 및 기타 채팅 웹사이트에서도 동일한 작업을 수행할 수 있습니까?

그럴 때도 있습니다. 이러한 웹사이트에는 종종 Python 인터프리터가 포함되어 있어, 모델이 Word 또는 PowerPoint 파일을 열고 코드로 해당 XML을 편집할 수 있습니다.

하지만 코드는 여전히 불안정한 모델에 의해 작성되며, 원본과 결과를 대조하여 검증하는 장치가 없습니다. 내부 테스트에서 우리는 종종 예기치 않은 삭제와 수정이 포함된 문서를 받았습니다. 한 극단적인 경우, 20페이지짜리 문서가 아무런 경고도 없이 10페이지로 줄어들어 돌아왔습니다.

Python을 사용하는 채팅 웹사이트

20페이지
10페이지

완료되었습니다! 요청하신 대로 문서를 업데이트했습니다.

누락된 10페이지에 대한 언급이 없습니다.

변경 내역

  • 4쪽 · 제2.1조

    삼십(30)일 육십(60)일

    되돌리기
  • 9쪽 · 제6.3조

    공급자 계약상대방

    되돌리기
  • 17쪽 · 별지 1

    US$2,400 US$2,600

    되돌리기

새 문서 생성

그림 7왼쪽: 내부 테스트에서 경고 없이 발생한 내용 잘림. 오른쪽: OneTurn에서는 AI가 한 모든 변경 사항이 목록으로 표시되며 되돌릴 수 있습니다.

알림 없이 일어나는 누락이나 수정은 중요한 작업에서 치명적입니다. 에서는 AI 에이전트가 만드는 모든 변경 사항이 기록됩니다. 각각을 검토하고, 원하는 항목을 되돌리고, 새 문서를 생성할 수 있습니다.

06

OpenClaw나 Manus 같은 컴퓨터 사용 에이전트도 이렇게 할 수 있나요?

이러한 에이전트는 사람이 하는 방식대로 컴퓨터를 제어합니다. Microsoft Word 또는 PowerPoint에서 문서를 연 다음 스크롤하고 클릭하며 입력합니다.11 사람과 동일한 프로그램을 사용하기 때문에 사람처럼 편집할 수 있으며, 그 결과는 대개 인상적입니다.

그 대가는 비용과 속도입니다. 에이전트는 스크롤하면서 스크린샷을 찍는 방식으로 문서를 읽으며, 작은 단계마다 다음에 무엇을 할지 결정하기 위한 모델 호출이 필요합니다. 풀HD 스크린샷 하나만 해도 자체적으로 약 1,500~2,700개의 토큰 비용이 듭니다.10 OSWorld 벤치마킹에서 가장 우수한 에이전트조차도 필요한 단계보다 2.7~4.3배 더 많은 단계를 거쳤으며, 후반부 단계는 초기 단계보다 최대 3배 더 오래 걸렸습니다.9

컴퓨터 사용 에이전트

  1. 스크린샷 찍기
  2. 모델이 다음 작업을 결정합니다
  3. 스크롤, 클릭 또는 입력
  4. 모든 단계에 대해 반복

  1. 텍스트를 한 번 읽기
  2. 일괄 편집
  3. 파일 쓰기
20페이지 계약서, 30개 수정컴퓨터 사용 에이전트
모델 호출≈ 180≈ 12
호출당 토큰 수≈ 10,000≈ 4,000
전체 토큰≈ 1,800,000≈ 48,000
차이점약 37배, 또는 OSWorld에서 측정한 추가 단계를 반영하면 약 100~160배
그림 8가정: 약 11,000단어, 문서를 읽기 위한 스크린샷 60장, 수정 1건당 작업 4회, 각 호출에 스크린샷과 최근 기록 포함. OneTurn은 텍스트를 한 번 읽고 수정 사항을 일괄 전송합니다.

우리의 추정에 따르면, 컴퓨터 사용 에이전트는 동일한 편집을 수행하는 데 보다 LLM 토큰을 최대 100배 더 많이 사용할 수 있으며, 완료하는 데 훨씬 더 오래 걸립니다.

출처

  1. WordprocessingML 문서의 구조Microsoft Learn · Open XML SDK 설명서
  2. ECMA-376: Office Open XML 파일 형식Ecma International · 표준
  3. 워드 프로세싱 문서 유효성 검사Microsoft Learn · Open XML SDK 설명서
  4. 위임하면 LLM이 문서를 손상시킵니다Laban, Schnabel, Neville · Microsoft Research · 2026년
  5. LongProc: 긴 절차적 생성에 대한 롱컨텍스트 언어 모델 벤치마킹예(Ye) 외 · COLM 2025
  6. 완벽한 검색에도 불구하고 문맥 길이만으로도 LLM 성능이 저하됨Du 외 · Findings of EMNLP 2025
  7. Anthropic, npm 소스 맵 파일을 통해 Claude Code 소스를 실수로 노출InfoQ · 2026년 4월 7일
  8. AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링Anthropic Engineering · 2025년 9월 29일
  9. OSWorld-Human: 컴퓨터 사용 에이전트의 효율성 벤치마킹Abhyankar, Qi, Zhang · MLSys 2026
  10. 비전: 해상도 및 토큰 비용Claude 플랫폼 문서
  11. Meta의 Manus, OpenClaw 열풍 속에서 AI 에이전트를 개인 기기에 가져오기 위한 데스크톱 앱 출시CNBC · 2026년 3월 18일

그림들은 이 기사를 위해 제작된 삽화입니다. XML은 실제 WordprocessingML이며, 파일 이름, 인물 및 판결은 허구입니다.

망가뜨리면 안 되는 문서에 사용해 보세요.

무료로 사용해 보기 →