금요일 오후 5시 20분, 매니저로부터 메시지가 옵니다:

숫자가 확정되었습니다. 이것을 제대로 된 보고서로 만들어서 오늘 밤까지 클라이언트에게 보내세요.

당신은 소스 자료를 AI 어시스턴트에게 전달합니다. 1분 후, AI는 요약본, 발견 사항 목록, 그리고 다듬어진 결론을 내놓습니다.

그다음 당신은 Word를 엽니다.

제목(headings)에는 계층 구조가 없습니다. 목차(table of contents)도 없습니다. 표(table)의 너비는 깨져 있고, 페이지 번호는 누락되었으며, Excel에 복사된 수치들은 수식(formulas)이 아닌 정적 값(static values)입니다. 발표 자료도 필요하기 때문에, 폰트 크기, 정렬, 색상, 차트(charts)를 맞추느라 또 다른 한 시간이 사라집니다.

AI는 1분 만에 콘텐츠를 작성했습니다. 당신은 그것을 파일로 만드는 데 2시간을 썼습니다.

그 격차는 중요합니다. 대부분의 사무 업무는 채팅창에 답변이 나타난다고 해서 끝나는 것이 아닙니다. 클라이언트는 Word 보고서를 필요로 합니다. 재무팀은 입력값이 변할 때 여전히 계산이 작동하는 Excel 모델을 필요로 합니다. 경영진은 깔끔하게 열리고 회의 5분 전에도 편집할 수 있는 PowerPoint 덱(deck)을 필요로 합니다.

Office CLI Agents는 문서 제작(document-production) 단계를 처리합니다.

좋은 답변은 시작점일 뿐입니다

생성형 AI (Generative AI)는 이미 이메일 초안 작성, 회의 요약, 문서 번역, 그리고 보고서의 초안(first pass)을 만드는 데 능숙합니다. 약점은 출력물이 실제 업무 워크플로우(workflow)에 진입해야 할 때 나타납니다.

A 보고서는 단순히 몇 천 단어의 집합 그 이상입니다. 표지, 제목 스타일(heading styles), 목차, 머리글(headers), 바닥글(footers), 페이지 필드, 참조(references), 그리고 나중에 수정해도 유지되는 표(tables)가 필요할 수 있습니다.

A 스프레드시트(spreadsheet)는 단순히 숫자 행들의 집합이 아닙니다. 수식(formulas), 서식(formats), 틀 고정(frozen panes), 유효성 검사 규칙(validation rules), 조건부 서식(conditional formatting), 그리고 라이브 셀(live cells)과 연결된 차트(charts)가 필요합니다.

A 프레젠테이션(presentation)은 단순히 10개의 슬라이드로 나뉜 문서가 아닙니다. 각 슬라이드에는 명확한 요점, 읽기 쉬운 타이포그래피(type), 합리적인 간격, 편집 가능한 차트, 그리고 위치가 어긋나지 않는 도형(shapes)이 필요합니다.

채팅 어시스턴트(chat assistant)는 목차(table of contents)를 추가하라고 권장할 수 있습니다. 하지만 파일 내에 목차가 실제로 존재하기 전까지는 작업이 완료된 것이 아닙니다. 어시스턴트는 분기별 수익을 나타내는 막대 차트(bar chart)를 제안할 수 있습니다. 누군가가 그 차트를 수동으로 직접 만들어야 한다면 그 작업은 여전히 미완성 상태입니다.

Office CLI는 작업의 단위를 텍스트에서 문서 객체(document objects)로 변경합니다.

Office CLI가 에이전트(Agent)에 추가하는 것

OfficeCLI는 .docx, .xlsx, .pptx 파일을 읽고 수정하기 위한 오픈 소스 명령줄 도구(command-line tool)입니다. 에이전트(Agent)는 이를 사용하여 문서 구조를 검사하고, 네이티브 Office 객체를 생성하며, 선택된 요소를 업데이트하고, 결과를 검증할 수 있습니다.

이를 통해 이전과는 다른 종류의 요청이 가능해집니다:

이 노트와 스프레드시트를 바탕으로 공식 분기 보고서를 작성해줘. 표지, 요약문(executive summary), 제목 계층 구조(heading hierarchy), 목차, 데이터 테이블, 페이지 번호를 포함해줘. 반환하기 전에 문서 구조를 확인한 다음, PDF로 내보내줘.

에이전트(Agent)는 자료를 정리하고, Word 문서를 생성하며, 제목 스타일(heading styles)을 적용하고, 테이블과 필드(fields)를 삽입하며, 완성된 구조를 검사한 뒤 파일을 반환할 수 있습니다.

출력물은 더 이상 복사하기를 기다리는 Markdown 형식이 아닙니다. 누군가가 열 수 있는 .docx 파일이자, 누군가에게 보낼 수 있는 .pdf 파일입니다.

사무직 직원이 "콘텐츠가 존재하는 상태"와 "파일이 준비된 상태" 사이에서 얼마나 많은 시간을 소비하는지 계산해 보기 전까지는 이 차이가 작게 느껴질 수 있습니다.

Excel에는 정답의 스크린샷이 아닌 로직(logic)이 포함되어야 합니다

연간 순증가(net-additions) 수치가 12개월치 월별 값의 합계와 같아야 한다고 가정해 봅시다. 유용한 워크북(workbook)은 다음과 같이 포함합니다:

=SUM(E13:E24)

반면, 성능이 낮은 생성형 워크북은 2552와 같은 현재 결과값만을 포함합니다.

두 방식 모두 오늘 보기에는 정확해 보입니다. 하지만 다음 달에도 유용하게 남는 것은 단 하나뿐입니다.

Office CLI 에이전트(Agent)는 수식(formulas)을 작성하고, 숫자 및 날짜 형식(number and date formats)을 적용하며, 틀 고정(freeze panes)을 수행하고, 드롭다운 유효성 검사(drop-down validation)를 추가하며, 목표치 미달 지표를 강조 표시하고, 네이티브 차트(native charts)나 스파크라인(sparklines)을 생성할 수 있습니다. 입력값이 변경되면 계산식과 연결된 차트들도 함께 업데이트될 수 있습니다.

이것이 스프레드시트와 단순히 .xlsx 확장자를 가진 정적 보고서의 차이점입니다.

동일한 접근 방식은 반복적인 운영 보고서에도 적용됩니다. 에이전트는 여러 소스 시트에서 값을 가져오고, 일관되지 않은 열을 표준화하며, 수식을 업데이트하고, 예외 사항을 표시하며, 관리 요약본을 준비할 수 있습니다. 사람이 여전히 각 지표의 정의와 보고서 뒤에 숨겨진 비즈니스 판단권을 가집니다. 에이전트는 반복적인 구성 작업을 처리합니다.

회의록은 구조화된 회의 기록으로 변환될 수 있다

회의가 끝난 후, 원자료는 보통 지저분합니다: 녹취록, 몇 장의 스크린샷, 개인 메모, 그리고 명확한 담당자가 지정되지 않은 결정 사항들입니다.

일반적인 요약기는 깔끔한 회고본을 만들 수 있습니다. 하지만 누군가는 여전히 배경 정보(context), 결정 사항, 실행 항목(action items), 담당자(owners), 마감 기한 등을 위한 섹션을 만들어야 합니다. 만약 이 문서가 클라이언트에게 전달된다면, 회사 헤더, 날짜, 버전 번호, 푸터, 기밀 유지 고지 등이 필요할 수도 있습니다.

Office CLI 에이전트는 요약과 문서 제작 단계를 결합할 수 있습니다. 실행 항목을 구조화된 표에 배치하고, Word 제목 스타일을 적용하며, 모든 푸터에 '페이지 1'이라고 타이핑하는 대신 PAGE 필드를 삽입할 수 있습니다.

그러한 구조는 나중에 중요해집니다. 구조화된 문서는 검색되고, 업데이트되며, 일괄적으로 수정될 수 있습니다. 일반 텍스트는 다른 워크플로우에 들어갈 때마다 다시 정리되어야 합니다.

파워포인트 작업은 주로 작은 결정들의 연결고리이다

"이 보고서로 발표 자료를 만들어줘"라는 요청은 콘텐츠 요청처럼 들립니다. 하지만 실제로는 수십 가지의 결정이 필요한 레이아웃 작업입니다:

• 추세를 라인 차트로 할지, 컬럼 차트로 할지?
• 세 가지 지표가 카드에 들어가야 할까, 아니면 하나의 표에 들어가야 할까?
• 4단계 프로세스가 왼쪽에서 오른쪽으로 진행되어야 할까, 아니면 두 경로로 분기되어야 할까?
• 본문 18pt 크기가 회의실에서도 여전히 읽을 만할까?
• 긴 제목은 줄여야 할까, 아니면 크기를 줄여야 할까?

Office CLI Agent는 슬라이드, 텍스트 상자, 표, 이미지, 커넥터 (connectors), 차트 (charts), 그리고 발표자 노트 (speaker notes)를 네이티브 PowerPoint 객체 (native PowerPoint objects)로 생성할 수 있습니다. 차트 데이터는 편집 가능한 상태로 유지됩니다. 텍스트는 텍스트로 남습니다. 커넥터는 도형 (shapes)에 계속 붙어 있습니다.

이것이 중요한 이유는 비즈니스 파일이 변경 없이 그대로 유지되는 경우가 거의 없기 때문입니다. 매니저가 제목을 다시 쓰고, 고객이 새로운 수치를 보내며, 브랜드 팀에서 다른 색상을 요구합니다. 슬라이드를 이미지로 생성해 버리면 모든 수정 작업이 더 어려워집니다. 네이티브 객체 (native objects)는 데크 (deck)를 계속 사용할 수 있는 상태로 유지해 줍니다.

두 번째 편집이 첫 번째 생성보다 더 중요하다

도구가 파일을 한 번 생성할 때는 인상적으로 보일 수 있습니다. 진짜 테스트는 피드백이 도착했을 때 이루어집니다:

두 번째 섹션을 절반으로 줄여줘.

모든 리스크 항목을 빨간색으로 만들어줘.

3월 수치를 교체하고 차트를 업데이트해줘.

6번 슬라이드를 3번 슬라이드 뒤로 옮겨줘.

모든 변경 사항에 대해 파일 전체를 다시 생성하는 것은 위험합니다. 한 가지 요청을 해결하는 동안 다른 곳의 서식 (formatting)을 망가뜨릴 수 있기 때문입니다.

Office CLI는 다음과 같은 형태의 경로 (paths)를 포함하여 문서 요소에 대한 구조화된 경로를 노출합니다:

/body/tbl[1]/tr[2]/tc[4]
/Sheet1/B26
/slide[3]/shape[@name=RiskCard]

에이전트 (Agent)는 이러한 경로를 사용하여 하나의 테이블 셀 (table cell), 하나의 스프레드시트 범위 (spreadsheet range), 또는 이름이 지정된 하나의 PowerPoint 도형 (shape)을 업데이트할 수 있습니다. Office 파일은 단순히 내보내기 (export) 형식에 그치지 않고, 에이전트가 계속해서 작업할 수 있는 워크스페이스 (workspace)가 됩니다.

이를 통해 다음과 같이 정밀한 후속 요청이 가능해집니다:

본문 텍스트는 건드리지 말고 모든 1단계 제목을 진한 파란색으로 변경해줘.

워크북 (workbook) 내의 모든 수식 오류를 찾아줘.

18pt 미만인 모든 프레젠테이션 본문 텍스트를 나열해줘.

주변 서식을 유지하면서 "초안"을 "최종"으로 교체해줘.

제어된 두 번째 편집을 수행할 수 있는 능력이야말로 생성을 협업 (collaboration)으로 바꾸는 핵심입니다.

검증 (Validation)은 워크플로 (workflow)에 포함되어야 한다

어떤 문서 오류들은 파일이 열리는 것을 막지는 않습니다.

Excel 수식은 마지막 행을 누락하더라도 여전히 그럴듯한 숫자를 반환할 수 있습니다. Word 문서는 제목(headings)에 잘못된 스타일이 사용되었음에도 목차(table of contents)를 표시할 수 있습니다. PowerPoint 텍스트는 몇 픽셀 정도 넘쳐서 프로젝터에서 잘릴 수 있습니다. 바닥글(footer)에 페이지 번호 필드 대신 일반 텍스트가 포함되어 있으면 모든 페이지에 "Page 1"이라고 표시될 수 있습니다.

Office CLI는 구조 검사(structure inspection), 이슈 스캔(issue scans), 그리고 OpenXML 검증(validation) 기능을 제공합니다. 예를 들어:

officecli validate report.docx
officecli view report.docx issues
officecli view report.docx outline

이를 통해 에이전트(Agent)는 기본적인 품질 루프(quality loop)를 가질 수 있습니다:

1. 파일을 생성합니다.
2. 구조를 검사합니다.
3. 감지 가능한 문제들을 찾습니다.
4. 이를 수정합니다.
5. 다시 검사합니다.

검증(Validation)이 에이전트를 무결하게 만들어주는 것은 아닙니다. 에이전트는 여전히 잘못된 수식을 쓰거나 보기 흉한 슬라이드를 만들 수 있습니다. 하지만 파일이 클라이언트에게 전달되기 전에 일부 실패 사례를 잡아낼 수 있는 방법을 갖게 됩니다.

사무 자동화(office automation) 측면에서 이는 문장 품질을 조금 더 개선하는 것보다 더 유용할 수 있습니다.

팀은 문서 습관을 반복 가능한 규칙으로 바꿀 수 있다

많은 기업이 숙련된 직원 한 명에게 의존하는 문서 프로세스를 가지고 있습니다.

어떤 사람은 주간 운영 보고서를 업데이트하는 방법을 알고 있습니다. 다른 사람은 아무도 건드리고 싶어 하지 않는 재무 모델(financial model)을 관리합니다. 고객 제안서(Client proposals)는 항상 템플릿을 잘 이해하는 동료를 거쳐 나갑니다. 프로젝트 매니저가 퇴사하면, 상태 차트(status charts)가 어떻게 만들어졌는지 아무도 기억하지 못합니다.

프로세스가 문서화되어 있는 것처럼 보이지만, 그 중 상당 부분은 개인의 기억 속에 존재합니다.

Office CLI 에이전트는 그러한 지식의 일부를 실행 가능한 형태로 만들 수 있습니다. 팀은 어떤 제목 스타일을 사용할지, 최소 프레젠테이션 글꼴 크기는 얼마인지, 재무 입력값(financial inputs)이 수식과 어떻게 다른지, 어떤 지표에 조건부 서식(conditional formatting)이 필요한지, 각 슬라이드에 발표자 노트(speaker notes)가 필요한지, 그리고 전달 전에 무엇을 확인해야 하는지를 정의할 수 있습니다.

반복적인 실행이 검토(review)의 필요성을 완전히 없애지는 않습니다. 다만 그 주에 누가 파일을 준비했느냐에 따라 품질이 좌우되는 정도를 줄여줄 수 있습니다.

경계가 여전히 존재하는 지점

Office CLI는 구조화된 파일(structured-file) 도구이며, Microsoft Office를 완전히 대체하거나 비즈니스적 판단을 대신하는 도구가 아닙니다.

OpenXML 검증(validation)을 통해 파일이 구조적으로 유효한지는 확인할 수 있습니다. 하지만 복잡한 표가 읽기에 쾌적한지, 혹은 발표 자료의 논리가 강력한지는 확인할 수 없습니다. Microsoft Office, WPS, LibreOffice, Google Slides, Keynote 등은 글꼴(font), 필드(field), 차트 색상 및 애니메이션을 서로 다르게 렌더링(render)할 수 있습니다. 복잡한 프레젠테이션은 여전히 실제 발표될 환경에서 테스트를 거쳐야 합니다.

목차, 페이지 번호, 상호 참조(cross-references)와 같은 Word 필드(field)는 레이아웃 엔진(layout engine)에 의존합니다. 에이전트(Agent)가 이를 생성할 수는 있지만, Word, WPS 또는 LibreOffice가 이를 다시 계산(recalculate)해야 할 수도 있습니다. PDF 내보내기(export) 또한 렌더링 백엔드(rendering backend)가 필요하며, 누락된 글꼴은 페이지 매김(pagination)을 변경할 수 있습니다.

더 깊은 한계는 책임(responsibility)에 있습니다. 에이전트는 매출 공식이 오류를 반환하는지 확인할 수 있습니다. 하지만 예측치가 지나치게 낙관적인지는 결정할 수 없습니다. 슬라이드 위의 리스크를 정리할 수는 있지만, 이사회가 어떤 리스크를 가장 먼저 문제 삼을지는 알지 못합니다.

파일 생성은 자동화될 수 있습니다. 하지만 책임(accountability)은 자동화될 수 없습니다.

오피스 AI를 위한 더 나은 질문

대부분의 오피스 AI 제품은 하나의 질문으로 평가받습니다: "얼마나 글을 잘 쓰는가?"

더 유용한 테스트는 다음과 같습니다: "업무를 완수했는가?"

파일이 정상적으로 열리는가? 워크북(workbook)에 고정된 값 대신 수식(formula)이 포함되어 있는가? Word 목차가 업데이트되는가? 누군가 PowerPoint 차트를 편집할 수 있는가? 에이전트가 결과를 검사(inspect)했는가? 모든 것을 다시 구축하지 않고도 객체(object) 하나만 변경할 수 있는가?

이러한 세부 사항들이 AI 도구가 일상적인 사용 환경에 남을지 여부를 결정합니다.

즉시 사용 가능한 구현체는 ClawMama의 Office Document Assistant에서 확인할 수 있습니다. 이 도구는 오픈 소스인 OfficeCLI 기능을 사용하여 채팅을 통해 Word, Excel, PowerPoint 파일을 생성, 편집, 분석, 복구 및 검증(validate)합니다.

에이전트는 답변에서 멈추지 않고 완성된 파일을 반환합니다.