---
title: 새로운 Copilot Studio 환경에서 문서 레드라이닝하기
description: 벤더가 수정한 계약서, 뭐가 바뀌었는지 몇 초 만에 확인하는 Copilot Studio의 redlining-content 스킬 제작 과정과 핵심 교훈을 소개해요.
date: 2026-09-04
  tags: [Copilot Studio, 문서 레드라이닝, 에이전틱 루프, redlining-content]
cards:
  - /cards/document-redlining/card-01.png
  - /cards/document-redlining/card-02.png
  - /cards/document-redlining/card-03.png
  - /cards/document-redlining/card-04.png
  - /cards/document-redlining/card-05.png
  - /cards/document-redlining/card-06.png
  - /cards/document-redlining/card-07.png
author: Lissa
source: https://interlinear.work/notes/document-redlining/
---

> **원문:** [Redlining Documents with the New Copilot Studio Experience](https://microsoft.github.io/mcscatblog/posts/redlining-documents-new-copilot-studio-experience/)
> **게시일:** 2026-07-15 · **저자:** Andrew Hess, Remi Dyon

> **팁:** CAT Agent Skills 갤러리에서 [redlining-content](https://microsoft.github.io/cat-agent-skills/skills/redlining-content/) 스킬을 다운로드하여 설치할 수 있어요.

"무엇이 바뀌었지?" 벤더가 자신들의 수정 사항이 어딘가에 숨어 있는 계약서를 이메일로 보내와요. 여러분은 모든 차이점을 명확하게, 수락(Accept)하거나 거부(Reject)할 수 있는 변경 내용 추적(Track Changes)으로 표시된 상태로 보고 싶죠. 쉬워 보이나요? 수작업으로는 몇 시간이 걸릴 수 있고, 저희의 첫 자동화 시도조차 고통스러울 만큼 느렸어요. 결국 저희는 100페이지짜리 문서를 몇 초 만에 처리할 수 있게 됐어요.

먼저, 변경 내용 추적이 실제로 어떻게 동작하는지 살펴볼게요. Word의 `.docx` 파일은 사실 XML로 가득 찬 zip 파일이고, 텍스트가 그걸 설명하는 태그로 감싸진 구조예요. 변경 내용 추적을 켜고 편집하면 Word는 단순히 텍스트를 바꾸는 게 아니라, 편집 내용을 특별한 XML 태그로 감싸요. 추가한 내용은 `w:ins`로, 삭제한 내용은 `w:del`로 감싸는 거죠(삭제된 단어는 그대로 유지되며, 취소선 처리된 것으로 표시될 뿐이에요). 각 태그는 누가 언제 변경했는지도 기록해요.

_`.docx` 내부에서 추적된 변경 사항은 `w:ins`와 `w:del` 태그로 감싸진 텍스트에 불과해요._

"추적된 변경 사항"이란 결국 그게 전부예요. Word가 변경 내용 추적으로 표시하고 수락/거부할 수 있게 해주는 OOXML<sup>1</sup> 마크업으로 태그된 텍스트인 거죠.

설명하기는 간단하지만 만들기는 정말 어려워요. 출력물은 각 편집이 진짜 OOXML 마크업(삽입은 `w:ins`, 삭제는 `w:del`)으로 반영된 `.docx`여야 하고, 동시에 원본의 정확한 서식이 그대로 살아남아 Microsoft Word에서 깔끔하게 열려야 해요. 가운데 정렬된 제목은 가운데 정렬을 유지해야 하고, 14pt 제목은 14pt를 유지해야 하며, 표는 표로 남아야 해요. 충실도(fidelity)를 잘못 처리하면 "레드라인"은 그저 원본보다 못한 복사본이 될 뿐이에요.

이 글은 [새로운 Copilot Studio 오케스트레이터](https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/overview)를 위한 redlining-content [스킬](https://microsoft.github.io/mcscatblog/posts/skills-for-copilot-studio/)을 만든 이야기예요. 처음 동작한 버전은 문서 하나당 15분이 걸렸어요. 최종적으로 도달한 버전은 15초가 걸려요. [에이전틱 루프](https://microsoft.github.io/mcscatblog/posts/agentic-improvement-loop/)가 어떻게 저희를 전자에서 후자로 데려다줬는지 소개할게요.

## 루프가 스스로 Python 참조 스크립트를 작성한 과정

저희는 `.docx` 또는 `.dotx` 파일을 `.docx` 또는 `.pdf` 파일과 비교할 수 있는 프로세스가 필요했고, 이를 위해 Python을 사용했어요. 저희가 만든 것 중 가장 중요한 건 Python 코드 자체가 아니라, 그 Python을 *발견해낸 프로세스*였어요. 저희는 빈 파일에서부터 레드라인 엔진을 직접 작성한 적이 없어요. 에이전틱 루프가 그걸 하도록 두었고, 살아남은 것을 코드화했어요.

이 과정은 네 개의 뚜렷한 단계로 진행됐고, 각 단계가 다음 단계를 가르쳤어요.

_빈 파일에서 코드화된 참조 스크립트까지 스킬을 이끈 네 가지 단계예요._

### 1단계: 코드 없이 실행하기

가장 좋은 첫수는 **코드 없이** 시작하는 것이었어요.

에이전트는 의지할 스크립트 없이 두 파일을 놓고 추론하면서 레드라인을 직접 만들려고 시도했어요. 결과는 틀렸어요. 최악의 실패는 두 파일 형식 사이를 잇기 위해 PDF로 *변환*하려 한 거였는데, DOCX 템플릿과 업로드된 PDF를 모두 형식 변환에 밀어 넣었어요. DOCX에서 PDF로 갔다가 다시 돌아오는 과정은 서식을 완전히 파괴했어요. 레이아웃이 밀리고 간격이 바뀌었고, 그렇게 망가진 결과물 위에서 변경 내용 추적이 실행되자 아무도 실제로 만들지 않은 단락 나눔과 간격 차이가 "레드라인"으로 표시됐어요. 출력물은 노이즈로 가득했고, 검토자가 신뢰할 수 있는 건 아무것도 없었어요. 저희가 원한 결과는 아니었지만, 무엇을 피해야 하는지는 정확히 알려줬어요. 형식 간 변환을 아예 하지 말 것.

DOCX든 DOTX든 템플릿이 이미 있으니, 그 초기 템플릿을 그대로 사용하고 변경 사항만 반영하면 돼요!

### 2단계: 루프를 돌게 두기

변환이 해롭다는 걸 알게 된 후, 저희는 에이전트가 **직접 레드라이닝하는 Python을 작성**하도록 풀어놓고 그냥 루프를 돌게 뒀어요. 여기가 에이전틱 루프가 그 이름값을 하는 지점이에요. 에이전트는 스크립트를 작성하고, 실행하고, 오류를 만나고, 트레이스백을 읽고, 다시 작성하고, 다시 실행해요. 저희의 개입 없이 계속 반복해요. 실패 하나하나가 스승이었어요. `lxml` 크래시, 잘못된 형식의 XML, 잘못된 요소 중첩, 충돌하는 리비전 ID를 겪으며 루프를 돌았어요. 이 실패/재작성 사이클 전체가 약 **15분** 걸렸어요. 그리고 마침내 어느 실행에서 깔끔하게 열리고, 진짜 추적된 변경 사항이 있으며, 실제로 정확한 레드라인이 담긴 `.docx`가 나왔어요.

> **참고:** 실패는 낭비가 아니라 반복 그 자체예요. 루프가 읽는 모든 트레이스백은 올바른 코드의 탐색 공간을 좁혀줘요. 저희의 일은 엔진을 작성하는 게 아니라, 루프에 명확한 목표를 주고 시행착오를 통해 구현에 수렴하도록 두는 것이었어요.

### 3단계: 하드코딩 제거하기

마침내 에이전트가 올바르게 레드라이닝된 문서를 출력했어요. 하지만 하드코딩된 값이 가득했어요. 특정 단락 인덱스, 리터럴 문자열, 고정된 ID, 박혀 있는 파일 경로까지요. 업로드된 파일 이름과 템플릿 파일 이름이 스크립트에 그대로 들어 있었어요. 그래서 에이전트에게 한 가지 지시를 더 내렸어요. **모든 하드코딩된 값을 제거하고 일반화하라.** 특정 단락 인덱스는 "이 단어가 매핑되는 단락"이 됐어요. 리터럴 교체 문자열은 템플릿과 제출본 간의 diff가 됐고요.

### 4단계: 의사코드(Pseudocode)

상수를 제거하고 나온 건 본질적으로 **하드코딩된 값이 없는 가벼운 의사코드**였어요. 특정 파일에 종속된 실제 코드가 아니라, 에이전트가 무엇을 작성할지 파악할 때 재사용할 수 있는 출발점이었죠. 이게 스킬의 `scripts/redline.py`로 곧장 들어갔어요. 이게 트릭의 전부예요. 이전에는 에이전트가 요청마다 그 실패/재작성 루프를 통해 해법을 다시 도출해야 했어요. 이후에는 에이전트가 단순히 *코드화된 스크립트를 실행*해요. 비용이 많이 드는 부분, 즉 올바른 코드를 작성하려는 에이전틱 실험 루프는 이제 저희의 의사코드에서 나온 실질적인 지침으로 사전에 처리돼요.

_메타 교훈: 에이전틱 루프가 발견한 것을 재사용 가능한 스크립트로 코드화하세요._

> **팁:** 같은 출력을 약 60배 빠르게. 루프의 발견을 스크립트로 코드화하는 것은 15분짜리 추론 마라톤을 15초짜리 함수 호출로 바꿔놓았어요.

## 벽: pip install이 없다

이 프로젝트의 흥미로운 제약은 모두 하나의 사실로 귀결돼요. 새로운 Copilot Studio 런타임에서는 Python 패키지를 설치할 수 없다는 것이에요. 컨테이너에 탑재된 것이 곧 사용할 수 있는 전부예요. PDF를 DOCX로 변환하는 데 `pdf2docx`가 훌륭했을지 몰라도, 사용할 수 없었어요. 없는 거고, `pip install`도 없어요.

출시 전까지 저희가 밟은 경로, 즉 시도했던 모든 PDF→DOCX 접근법과 각각의 결말은 다음과 같아요.

| 접근법 | 서식 | 표 | 정렬 | 판정 |
|---|---|---|---|---|
| 텍스트 추출 → 문서 재구성 | 손실 | 평문 텍스트 | 손실 | 실패 |
| `pdf2docx` | N/A | N/A | N/A | 사용 불가 |
| `pymupdf` | N/A | N/A | N/A | 사용 불가 |
| `python-docx`(출력 생성) | 양호 | 보통 | 스타일 적용 시 초기화 | 추상화 수준 과다 |
| `pypdfium2` + 재구성 | 정확 | 실제 표 | 정확 | 이미지 전용 |
| **템플릿 사용 + 단어 diff**(`pdfplumber`로 PDF 읽기, 변환 없음) | 바이트 단위 완벽 | 셀 단위 | 네이티브 | **출시** |

_PDF를 레드라인으로 바꾸기 위해 시도한 접근법들이에요. DOCX로 변환하는 방식은 실패하거나 사용할 수 없었고, `pdfplumber`로 PDF의 텍스트를 읽어 템플릿과 diff하는 접근이 통했어요._

반복 작업을 하면서 PDF를 DOCX로 변환하려고 여러 Python 패키지를 시도했어요. 하지만 명백한 답은 처음부터 거기 있었어요. `pdfplumber`는 사용할 수 *있고*, PDF의 텍스트를 직접 읽어내요. 그러니 단순하게 가면 되죠. 초기 템플릿은 아예 변환하지 말고, DOTX나 DOCX 그대로 두고, `pdfplumber`로 제출본의 단어를 뽑아낸 다음, 템플릿에 레드라이닝 변경 사항을 반영하는 거예요.

> **참고:** 현재 Copilot Studio에서 사용할 수 있는 스킬은 향후 변경될 수 있어요.

저희는 계속 PDF를 Word 문서로 *변환*하려 했어요. 처음에는 그게 문제처럼 보였지만, 사실 변환할 필요가 전혀 없다는 걸 깨달았어요. 이미 있는 건 `pdfplumber`, 레이아웃을 인식하는 텍스트 추출기([페이지 단위 PDF 인용](https://microsoft.github.io/mcscatblog/posts/pdf-page-level-citations/)의 기반이기도 한 바로 그 구성 요소)였고, 그것만으로 충분했어요. 이 스킬은 아무것도 변환하지 않아요. `pdfplumber`로 제출본의 *단어*를 읽은 다음, 여러분이 이미 갖고 있는 Word 템플릿 위에 레드라인을 직접 만들어내요.

## 돌파구 이후

그 관점 전환이 오늘날 출시된 스킬이 됐어요. 출력물은 실제 초기 템플릿 *그 자체*이며, 수정 사항이 `w:ins` / `w:del` 요소로 직접 주입돼요. 변환도, 골칫거리도, 불필요한 레드라이닝을 유발하는 상속된 스타일도 없어요.

_redlining-content 스킬의 최종 폴더 구조예요._

최종 파일 구조는 다음과 같아요.

- **Assets 폴더** — `template.dotx`
- **References 폴더** — `docx-submissions.md`, `pdf-submissions.md`
- **Scripts 폴더** — `redline.py`
- **SKILL.MD** — 모든 것을 하나로 묶어주는 지침

그리고 스킬이 런타임에 실제로 하는 일은 다음과 같아요.

1. 두 개의 파일을 사용해요. 기준선(baseline)이 되는 템플릿(DOTX 또는 DOCX)은 스킬의 Assets 폴더에 번들로 포함돼 있고, 사용자가 제출본(DOCX 또는 PDF)을 업로드해요.
2. 에이전트는 각 파일에서 단어를 읽어내요. Word 파일은 단락 텍스트를 그대로, PDF는 `pdfplumber` 텍스트 추출로 읽어요(PDF를 Word로 변환하지 않아요).
3. 에이전트는 제출된 문서 유형에 따라 포함된 두 참조 문서 중 하나(`docx-submissions.md` 또는 `pdf-submissions.md`)를 읽도록 안내받아요.
4. `difflib.SequenceMatcher`를 사용해 두 개의 평평한 단어 리스트로 한 번에 비교하므로, 줄바꿈이나 페이지 나눔이 거짓 차이를 만들지 않고 실제 단어 변경만 집계돼요.
5. 변경되지 않은 단락은 바이트 단위 그대로 유지하고(원본 서식 전부 온전히), 실제로 바뀐 단락만 다시 만들어요.
6. 모든 차이를 Word의 추적된 변경 사항으로 표시해요. 삽입은 `<w:ins>`로, 삭제는 `<w:del>`로 감싸요.
7. 모든 변경 사항의 작성자는 "Copilot Studio AI"예요.
8. (DOCX 제출본의 경우) 표는 셀 단위로 diff하며 각 셀의 너비/테두리/음영을 보존해요. PDF의 표는 그대로 통과시켜요.
9. 변경 내용 추적이 켜진 일반 DOCX를 출력하며, 모든 변경과 삭제를 표시해요.

> **주의:** PDF 레드라인은 문자 단위로 완벽한 비교가 아니라 검토용 초안(best-effort draft)으로 취급하세요. `.docx` 제출본이 고충실도 경로예요. 그 단어와 표에는 실제 구조가 담겨 있기 때문이에요.

_이 스킬은 100페이지가 넘는 문서에서 테스트됐어요._

## 그런데 이건 Copilot Studio용인가, Cowork용인가?

크게 보면, 작업을 감싸는 비즈니스 프로세스가 있느냐에 달려 있어요. 정말 "이 두 문서를 비교해서 레드라이닝해줘"가 전부이고 더 큰 워크플로가 없다면, [Cowork](https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/)가 아마 더 잘 맞을 거예요. 파일을 가리키고 작업하게 두면 돼요.

하지만 특정 문서와 특정 프로세스의 맥락에서 운영하는 순간, Copilot Studio가 앞서 나가요. 항상 같은 고정 템플릿과 비교해 레드라이닝한다거나, 이메일로 들어오는 제출본을 가로채 라우팅하고, 규칙을 적용하고, 매번 변경 내용 추적이 적용된 문서를 돌려줘야 하는 경우를 생각해보세요. 그건 일회성 작업이 아니라 반복 가능한 파이프라인이고, 바로 그 지점이 저작된 MCS 스킬이 빛나는 곳이에요.

그래서 이 스킬은 의도적으로 Copilot Studio용이에요. 개발 중에 에이전틱 루프가 Cowork 스타일의 탐색을 한 번 하도록 두고, 그것을 모든 요청에서 동일하게 실행되는 결정론적 스킬로 고정했어요. 물론 Cowork가 선호하는 방식이라면 같은 접근을 Cowork로 가져가는 걸 막을 이유는 없어요. 비즈니스 요구에 맞는 쪽을 사용하세요.

## 핵심 요약

- **올바른 코드는 루프가 쓰게 하세요.**<br>
  먼저 코드 없이 실행해보고, 그다음 에이전트가 실패 루프를 통해 동작하는 스크립트에 도달하게 하세요. 실패가 이 반복적 접근의 핵심이에요.
- **그다음 하드코딩을 제거하고 코드화하세요.**<br>
  동작하는 스크립트는 하나의 입력에 하드코딩되어 있어요. 모든 리터럴을 로직으로 바꾸고, 일반화된 의사코드를 스킬에 업로드하면 에이전트가 다시 도출하는 대신 실행하게 돼요. **그게 15분을 15초로 바꾸는 비결이에요.**
- **네이티브 수락/거부를 활용하세요.**<br>
  모든 변경 사항은 "Copilot Studio AI"에 의해 레드라이닝되며 수락하거나 거부할 수 있어요.
- **이미 완벽한 것은 변환하지 마세요.**<br>
  템플릿은 흠 없는 Word 문서예요. 수정 사항을 주입하는 게 매번 문서를 재구성하는 것보다 낫고, 변환이 항상 필요한 것도 아니에요.

직접 스크립트를 작성하는 대신 에이전틱 루프가 스크립트를 쓰게 해본 적이 있으신가요? 어땠는지 댓글로 들려주시면 좋겠어요.

---

## 어휘 주석

1. **OOXML(Office Open XML):** Word, Excel, PowerPoint 같은 Microsoft Office 문서가 내부적으로 쓰는 XML 기반 파일 형식. `.docx` 파일을 열어보면 실제로 이 형식의 태그들로 이뤄진 텍스트가 들어있어요.