
C# 기반 Excel AI는 .NET 애플리케이션 내에서 언어 모델의 판단력과 실제 Excel 처리 라이브러리를 결합하는 것을 의미합니다. 이를 통해 애플리케이션은 열 단위의 복잡한 코드 대신 자연어 지시사항을 기반으로 스프레드시트 데이터를 병합, 정규화, 분석 및 서식 지정할 수 있습니다. Excel 보고서 작업에서 가장 어려운 부분은 차트를 그리는 것이 아니라, 서로 다른 형식의 소스 워크북들을 실제로 신뢰할 수 있는 데이터로 변환하는 것입니다. AI 에이전트를 사용하면 보고 작업("이 20개 매장 워크북을 병합하고 매출이 30% 이상 감소한 매장을 표시해 줘")을 설명하기만 하면 단순한 채팅 답변이 아닌 서식이 지정된 워크북을 받게 됩니다. Spire.Agent.Office는 언어 이해 기능과 실제 .xlsx(또는 PDF) 파일 출력을 보장하는 결정론적 문서 레이어를 모두 제공합니다.
빠른 이동
1. Excel 보고서 자동화의 진정한 병목 현상
대부분의 "월간 보고" 요청 뒤에 숨겨진 반복적인 작업을 예로 들어보겠습니다. 운영팀은 20개의 지역 매장을 운영하고 있으며, 각 매장은 월말에 매출 워크북을 전송합니다. 이론상으로는 하나의 보고서이지만, 실제로는 파일 이름 패턴만 공유할 뿐 서로 다른 20개의 파일입니다.
- 열(Column)이 일치하지 않습니다. 한 매장은 수치를
Revenue로, 다른 매장은Sales Amount로, 세 번째 매장은Net Sales로 부릅니다. - 레이아웃이 일치하지 않습니다. 한 매장은 월을 열 방향으로, 다른 매장은 행 방향으로 배치하며, 세 번째 매장은 중간에 메모 열을 집어넣습니다.
- 데이터 형식이 일치하지 않습니다. 날짜가 텍스트로 입력되거나, 숫자에 천 단위 구분 기호가 들어가고, 최소 한 매장은 헤더 행에 제목 행을 병합해 놓습니다.
따라서 경영진을 위한 차트를 만들기 전에 분석가는 일주일 내내 파일을 열고, 열을 매핑하고, 날짜를 정규화하고, 오탈자를 찾은 후에야 비로소 이상 징후를 확인하고 보고서를 작성합니다. 이 과정 중 그 어떤 것도 "보고서 생성" 단계가 아닙니다. 모두 데이터 준비 작업일 뿐입니다.
여기서 명심해야 할 점은 Excel 보고서 작업에서 어려운 부분은 최종 차트를 만드는 것이 아니라, 일관성 없는 소스 워크북을 실제로 신뢰할 수 있는 데이터로 변환하는 것입니다. 차트 라이브러리는 잘못된 데이터라도 얼마든지 그려냅니다. 팀에 정말 필요한 것은 수신함의 원시 파일에서 깨끗하고 비교 가능한 테이블로 이어지는 신뢰할 수 있는 경로입니다. AI 에이전트는 바로 이 과정의 비효율성을 완전히 바꿔놓습니다.
2. AI 에이전트가 워크플로우에 도입되면 바뀌는 것들
이 작업을 자동화하는 것 자체는 새로운 개념이 아니지만, 기존 방식은 비쌉니다. 두 워크플로우를 비교해 보세요.
기존 자동화 방식
파일 검사
→ 열 매핑
→ 데이터 정규화
→ 규칙 작성
→ 워크북 생성
마지막 단계를 제외한 모든 단계가 사전에 정의되어야 합니다. 알려진 헤더마다 열 매핑을 작성하고, 알려진 형식마다 날짜 파서를 만들며, 각 규칙마다 임계값을 설정해야 합니다. 매장이 열 이름을 바꾸거나 비즈니스 규칙이 변경되는 순간, 매핑과 규칙은 무용지물이 되고 사람이 다시 개입해야 합니다.
에이전트 기반 자동화
보고 작업 설명
→ 소스 워크북 제공
→ 결과 검토
에이전트는 고정된 위치 대신 각 워크북의 의미(Semantic)를 읽어내므로 열 매핑과 규칙 세트를 사전에 일일이 나열할 필요가 없습니다. 이를 통해 다음 파일에서 쉽게 깨지곤 했던 스키마 및 규칙 세트의 사전 정의 작업이라는 가장 비싼 비용을 제거할 수 있습니다.

이 문서의 나머지 부분에서는 20개 매장 시나리오를 예시로 삼아 원시 워크북에서 인쇄 가능한 PDF 생성까지의 파이프라인을 살펴봅니다. 3절부터 5절까지는 각 단계에서 에이전트가 수행하는 작업을 설명하며, 6절에서는 이를 실행하는 전체 C# 코드를 제공합니다.
3. 서로 다른 워크북에서 공통 데이터 모델로
Excel 관련 문제의 특수성은 서로 다른 워크북들이 실제로는 같지 않음에도 "같아 보인다"는 점입니다. 세 매장이 각각 4개의 열이 있는 테이블을 보내오더라도 사람이 해석하지 않고는 병합할 수 없는 경우가 많습니다.
| 매장 A | 매장 B | 매장 C |
|---|---|---|
| Revenue | Sales Amount | Net Sales |
| Month | Reporting Period | Date |
| Units | Quantity Sold | Qty |
이 매핑은 위치가 아닌 의미적(Semantic) 매핑이기 때문에 서로를 직접 연결하는 열 인덱스가 존재하지 않습니다. Revenue, Sales Amount, Net Sales는 동일한 개념을 가리키는 세 가지 이름이며, 헤더의 의미를 이해해야만 맞출 수 있습니다.
에이전트의 통합 단계는 이러한 의미적 맞춤을 단일 스키마로 변환합니다.
Store / Region / SKU / UnitsSold / Revenue / Month
에이전트는 각 소스 워크북을 읽고 대상 모델에 맞게 헤더 이름을 해독하며, 행과 열을 맞추고, 중복된 헤더 및 제목 행을 건너뛰며, 하나의 정규화된 테이블을 작성합니다. 개발자는 FindColumnByHeader("Revenue")와 같은 루틴을 작성할 필요가 없습니다. 지시사항에 대상 스키마 이름을 지정하면 에이전트가 각 파일의 매핑을 스스로 해결합니다.
이 단계는 현재 분석가의 시간을 가장 많이 소모하고 새로운 매장이 추가될 때 가장 자주 깨지는 구간이므로, 자동화 시 단일 작업 기준으로 가장 큰 이점을 제공합니다.
4. 비즈니스 규칙을 자연어 분석으로 변환하기
데이터가 한곳에 모이면 보고에는 판단이 필요하며, 하드코딩된 규칙은 이 판단 단계에서 한계를 드러냅니다. 대표적인 재무 규칙 예시를 살펴보겠습니다.
전월 대비 매출이 30% 이상 감소했거나 50% 이상 증가한 행을 표시합니다.
이 한 문장에 얼마나 많은 내용이 담겨 있는지, 그리고 코드로 구현하려면 각 부분이 얼마나 까다로운지 확인해 보세요.
-
왜 30%와 50%인가? 이 숫자들은 맥락이 있는 비즈니스 임계값입니다. 계절성을 타는 매장, 신규 SKU, 또는 프로모션 행사에 따라 "이상 현상"의 기준이 달라집니다. 하드코딩된
if (change < -0.30)조건문은 모든 매장을 동일하게 취급하므로 계절성 변화에 오탐(False Alarm)을 발생시킵니다. - 규칙을 어떻게 변경하는가? 코드에서는 다시 컴파일하고 배포해야 합니다. 그러나 지시사항 방식에서는 분석가가 "20% 이상 감소"나 "동부 지역에만 적용", 또는 "100개 이상 판매된 SKU만 표시"와 같이 한 문장만 수정하면 됩니다.
- 차원을 추가하려면? 매장별, 지역별, 월별로 규칙을 적용하고 싶으신가요? 중첩 루프문 대신 지시사항에 조건절 하나만 추가하면 됩니다.
-
결과를 설명해야 하는가? 에이전트는 감지된 각 행에 대해 한 문장으로 된 유력한 설명이 담긴
Cause열을 추가할 수 있습니다. 이는 단순 임계값 비교 코드가 결코 제공할 수 없는 기능입니다.
이 내용이 전달하는 핵심 원칙은 다음과 같습니다.
코드는 '어떻게(How)'를 정의하고, 지시사항은 '무엇을(What)'할지 정의합니다.
개발자는 규칙을 일일이 코딩하는 대신 원하는 결과를 설명하기 시작합니다. 규칙은 명확하고 비즈니스 담당자가 직접 수정할 수 있는 형태로 유지되며, 매장이 추가되거나 임계값이 변경되어도 코드를 수정할 필요가 없습니다.
지시사항 기반 분석이 순위 산출 워크플로우에 적용된 전체 예제는 학생 점수 분석 및 순위 매기기 튜토리얼을 참조하세요.
5. 분석에서 경영진 보고서 작성까지
이상 징후를 찾는 것은 보고 작업의 절반에 불과합니다. 결과물은 누군가가 실제로 사용할 수 있는 워크북 형태가 되어야 합니다. 분석가의 단순 스프레드시트는 최종 제출물이 아니며, 경영진 요약 보고서가 진짜 제출물입니다.
파이프라인은 다음과 같이 완성됩니다.
원시 워크북
↓
통합 데이터
↓
이상 징후
↓
경영진 요약
↓
PDF
최종 지시사항은 결과물을 구성합니다. 맨 앞에 KPI 블록(총 매출, 최고 매출 매장, 최저 매출 매장, 감지된 이상 징후 수)이 포함된 Summary 시트를 추가하고, 월별 추이 테이블, 지역별 매출 막대 차트, 인쇄용 서식을 설정합니다. 동일한 지시사항에서 저장 경로를 .pdf로 지정하면 별도의 렌더링 단계 없이 동일한 보고서가 배포용 PDF로 내보내집니다.
여기서 얻을 수 있는 점은 분석과 구성은 서로 다른 두 가지 작업이며, 에이전트가 이 두 가지를 모두 수행한다는 것입니다. 분석가의 역할은 매달 프레젠테이션을 처음부터 다시 만드는 것이 아니라 감지된 항목을 검토하고 승인하는 것으로 전환됩니다.
6. C#으로 워크플로우 구축하기
위의 모든 단계는 하나의 C# 파이프라인으로 실행됩니다. 에이전트를 한 번 설정한 후 통합, 분석, 보고의 세 가지 지시사항을 순차적으로 실행합니다. 토큰, 패키지 및 프로젝트 연결을 포함한 전체 설정은 시작하기 튜토리얼에 단계별로 설명되어 있으며, 여기서는 워크플로우 자체에 집중합니다.
using System.IO;
using Spire.Xls;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
AIOptions options = new AIOptions {
SpireToken = spireToken,
WorkDir = @"C:\retail-ops\output",
TimeoutMs = 300000
};
string[] storeFiles = Directory.GetFiles(@"C:\retail-ops\inbox", "*.xlsx");
Directory.CreateDirectory(@"C:\retail-ops\output");
1. 통합(Consolidate). 20개의 수신함 파일을 첨부 파일로 전달하고 대상 스키마를 지정합니다. 3절에서 설명한 정규화 작업이 열 매핑 코드 없이 지시사항에 의해 수행됩니다.
using (Workbook consolidated = new Workbook())
{
AIResult result = consolidated.AI(options).ExecuteInstruction(
consolidated,
"Read every regional sales workbook in the inbox and merge them into one worksheet. " +
"Each store names its columns differently (for example Sales vs Amount, Month vs Period); " +
"normalize them to a single schema: Store, Region, SKU, UnitsSold, Revenue, Month. Skip " +
"duplicate header rows and save the merged result as a workbook.",
@"C:\retail-ops\output\consolidated.xlsx",
storeFiles);
if (result == null || !result.Success)
throw new InvalidOperationException($"Consolidation failed: {result?.ErrorMessage}");
}
2. 분석(Analyze). 통합된 파일을 로드하고 4절의 규칙을 자연어로 명시합니다. 에이전트는 원본 데이터를 유지한 채 Anomalies 시트를 추가합니다.
using (Workbook analysis = new Workbook())
{
analysis.LoadFromFile(@"C:\retail-ops\output\consolidated.xlsx");
AIResult result = analysis.AI(options).ExecuteInstruction(
analysis,
"Add an 'Anomalies' sheet. Compare each store and SKU's Revenue against the prior " +
"month, flag rows where revenue fell by more than 30% or grew by more than 50%, apply " +
"a red fill to declines and a green fill to jumps, and add a 'Cause' column with a " +
"one-sentence likely explanation. Leave the original data sheets unchanged.",
@"C:\retail-ops\output\analyzed.xlsx");
if (result == null || !result.Success)
throw new InvalidOperationException($"Analysis failed: {result?.ErrorMessage}");
}
소스 데이터와 함께 생성된 Anomalies 시트에는 지시사항에 따라 플래그가 지정된 행, 셀 채우기 색상 및 Cause 열이 추가됩니다.

3. 보고서 생성(Report). 5절의 경영진 요약 보고서를 구성하고 내보냅니다. savePath의 확장자 지정만으로 형식이 결정됩니다(여기서는 .xlsx, 배포용은 .pdf).
using (Workbook report = new Workbook())
{
report.LoadFromFile(@"C:\retail-ops\output\analyzed.xlsx");
AIResult result = report.AI(options).ExecuteInstruction(
report,
"Produce a management report. Add a 'Summary' sheet at the front with a KPI block " +
"(total revenue, top store, bottom store, count of flagged anomalies), a monthly trend " +
"table, and a bar chart of revenue by region. Format it for print and save the finished " +
"workbook.",
@"C:\retail-ops\output\monthly-report.xlsx");
if (result == null || !result.Success)
throw new InvalidOperationException($"Report generation failed: {result?.ErrorMessage}");
}
워크북 맨 앞에 Summary 시트가 추가되어 인쇄나 PDF 내보내기가 가능한 상태로 완성됩니다.

주요 API 호출
-
Workbook.AI(options)— 기존 워크북 객체에 AI 문서 프로세서를 연결합니다. -
ExecuteInstruction(doc, instruction, savePath, attachments)— 단계를 실행하고 결과를 작성합니다. -
AIResult.Success/AIResult.ErrorMessage— 각 단계를 검증하고 오류 발생 시 내용을 확인합니다.
에이전트가 없을 때 작성해야 하는 코드
대조적으로, 동일한 3단계를 수행하기 위한 기존 SDK 방식은 문자열로 각 열을 찾고, 모든 임계값을 하드코딩하며, 셀별로 서식을 지정해야 합니다. 그리고 매장이 열 이름을 바꾸거나 규칙이 변경될 때마다 모든 코드를 다시 수정해야 합니다.
foreach (string file in storeFiles)
{
Workbook wb = new Workbook();
wb.LoadFromFile(file);
Worksheet sheet = wb.Worksheets[0];
// 매장이 열 이름을 "Revenue" 대신 "Sales"로 지정하는 순간 오류 발생.
int revenueCol = FindColumnByHeader(sheet, "Revenue");
int storeCol = FindColumnByHeader(sheet, "Store");
for (int r = sheet.LastRow; r >= 2; r--)
{
double current = double.Parse(sheet.Range[r, revenueCol].Text);
double prior = double.Parse(sheet.Range[r, revenueCol + 1].Text);
double change = (current - prior) / prior;
// 하드코딩된 임계값; 계절성 매장의 경우 잘못된 알림 발생.
if (change < -0.30) sheet.Range[r, revenueCol].Style.Color = Color.Red;
}
// ... 이후 병합, 요약 작성, 차트 생성 등 매장 및 월별로 수백 줄의 코드가 필요함.
}

에이전트가 코드의 필요성을 완전히 없애는 것은 아닙니다. 데이터 매핑 코드를 작성할 필요성을 없애주는 것입니다. 차이점은 로직이 위치하는 곳입니다. 열 검색 로직과 임계값 코드에 존재하는 대신, 비즈니스 담당자가 읽고 수정할 수 있는 문장에 존재하게 됩니다.
7. AI의 한계와 애플리케이션 로직의 역할
가능과 불가능의 단순 목록보다 한계를 이해하는 더 현실적인 시각은 다음과 같습니다. AI 에이전트는 결정론적인 애플리케이션 로직을 대체하는 것이 아니라, 그 위에서 작동합니다.
애플리케이션은 여전히 스프레드시트의 의미 해석과 관련 없는 다음 항목들을 담당합니다.
- 파일 검색 및 접근 권한 — 수신함 파일 검색, 권한 확인 및 파일 준비
- 워크플로우 스케줄링 — 보고서 실행 시점, 트리거 조건 및 실행 순서
- 데이터 소스 제어 — 어떤 파일이 승인된 입력값인지 및 출처 관리
- 오류 처리 및 재시도 — 파일 누락 또는 특정 단계 실패 시 대처 로직
- 최종 승인 — 최종 제출 전 사람이 감지된 이상 징후를 검토
- 외부 데이터 대조 — 생성된 보고서를 원장 시스템(System of Record)과 대조
에이전트는 의미적(Semantic) 해석이 필요한 영역을 전담합니다.
- 이해 — 각 열의 실제 의미 파악
- 정규화 — 서로 다른 스키마를 하나의 모델로 정렬
- 해석 — 비즈니스 규칙을 적용하여 이상 항목 판단
- 변환 — 원시 데이터를 요약, 차트 및 서식으로 변환
- 구성 — 최종 워크북 또는 PDF 완성
이러한 역할 분담은 엔지니어링 리소스를 어디에 투입해야 하는지 명확히 알려줍니다. 검증과 감사가 필요한 결정론적 플러밍(Plumbing) 코드는 프로그래밍 코드로 유지하고, 의미적 해석 작업은 에이전트에게 맡기는 것입니다. 각 영역이 가장 잘하는 역할을 수행하게 됩니다.
8. 기존 .NET Excel 워크플로우에 AI 추가하기
마지막으로 명확히 할 점은 이 환경을 구축하기 위해 기존 코드를 재작성할 필요가 거의 없다는 것입니다. 이미 Spire.Xls를 통해 Excel을 다루고 있는 애플리케이션이라면, 기존 문서 모델이 바로 통합 포인트가 됩니다.
Workbook
↓
Workbook.AI(options)
↓
ExecuteInstruction(...)
새로운 문서 레이어나 별도의 문서 처리 서비스를 도입할 필요가 없습니다. 기존에 사용하던 Workbook 객체에 자연어 실행 레이어를 추가하기만 하면 됩니다. 파일을 열고, 병합하고, 저장하던 동일한 객체가 이제 지시사항을 받아 워크플로우를 수행하며, 결정론적 Excel 엔진이 병합된 셀, 숫자 서식, 차트 등이 온전히 유지된 올바른 형태의 파일을 출력하도록 보장합니다. 동일한 ExecuteInstruction 패턴은 Word 및 PDF 문서에도 확장 적용할 수 있습니다. 자세한 내용은 C#을 활용한 AI 계약서 검토를 참조하세요.
이것이 Excel 개발자를 위한 핵심 가치 제안입니다. "새로운 AI 플랫폼을 도입하는 것"이 아니라 "기존에 사용하던 워크북이 지시사항을 이해하도록 만드는 것"입니다. 매장이 열 이름을 바꾸거나 재무팀이 플래그 설정 규칙을 변경할 때, 해결책은 문서 파이프라인을 다시 빌드하는 것이 아니라 문장 하나를 수정하는 것입니다.
9. 자주 묻는 질문(FAQ)
Excel 데이터를 클라우드로 전송해야 하나요?
반드시 그렇지는 않습니다. Spire.Agent.Office는 사용자 애플리케이션 내부에서 실행되므로 SDK와 문서 처리 로직이 자체 환경 내에 유지됩니다. 즉, 저장이나 변환을 위해 파일이 제3자 서비스로 업로드되지 않습니다. 콘텐츠를 분석하려면 AI 모델에 관련 데이터가 전달되어야 하며, 이는 모든 AI 워크플로우의 필수적인 과정입니다. 로컬 네트워크에 자체 AI 모델을 구축한 경우 데이터는 완전히 자체 인프라 내에 머물게 됩니다. OpenAI 또는 Azure OpenAI와 같은 호스팅된 모델 API를 연동하는 경우 설정에 따라 관련 데이터가 해당 공급업체로 전송됩니다.
어떤 Excel 형식을 지원하나요?
입력 파일로는 XLSX, XLS 등 표준 워크북 파일을 지원하며, 에이전트가 기본 형식 그대로 직접 읽어들입니다. 출력 결과물은 XLSX, XLS, CSV, PDF 또는 HTML로 저장할 수 있으므로 완성된 보고서를 아카이브나 배포 목록으로 즉시 보낼 수 있습니다.
재무 또는 운영 검토 작업을 완전히 대체할 수 있나요?
아닙니다. 에이전트는 읽기, 정규화, 분석, 서식 지정 등 분석가가 매달 소요하는 정리 작업을 자동화하지만, 최종 승인은 여전히 사람이 수행해야 합니다. 감지된 이상 항목은 이미 결정된 결론이 아니라 검토를 위한 요약 목록으로 활용해야 합니다.
ChatGPT에 데이터를 붙여넣는 것과 무엇이 다른가요?
대화형 모델은 이상 항목이 무엇인지 알려줄 수는 있지만, 그 결과를 요약 시트, 조건부 서식, 차트가 포함된 워크북으로 구성하거나 PDF로 내보낼 수 없습니다. AI Excel 에이전트는 언어 모델의 판단력과 결정론적 Excel 레이어를 결합하여, 팀이 즉시 열고 공유할 수 있는 완성된 실제 파일을 출력합니다.
자체 AI 모델을 사용할 수 있나요?
네, 가능합니다. Spire.Agent.Office는 유연한 AI 모델 연동을 지원하며, 호스팅된 모델 API 및 사설 구축(On-Premise) 모델을 포함한 주요 AI 인프라와 호환됩니다. 에이전트가 자체 엔드포인트를 바라보도록 설정할 수 있습니다. 배포 환경에서 지원되는 공급업체에 대한 문의는 문의하기를 통해 확인해 주세요.
Excel 보고서 자동화를 시작할 준비가 되셨나요?
데이터 통합, 이상 징후 분석, 보고서 생성은 AI를 통해 가장 빠르게 성과를 낼 수 있는 분야입니다. 수신함을 지정하고, 보고서를 설명하면 서식이 완료된 워크북이나 PDF를 얻을 수 있습니다. 시작하기 튜토리얼을 따라 .NET에서 첫 번째 스프레드시트 워크플로우를 실행해 보세요.
추가 자료
- 학생 점수 분석 및 순위 매기기 자동화 튜토리얼 -- 에이전트가 종단 간 실행하는 Excel 워크플로우
- C#을 활용한 AI 계약서 검토 -- Word 및 PDF 문서에 적용된 지시사항 기반 패턴
- Spire.Agent.Office 제품 개요 -- 모든 Office 문서 형식을 지원하는 AI 에이전트 SDK