Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표
Excel 장표 출력 상담에서는 「Excel로 내고 싶다」는 말 속에 실은 서로 다른 요건이 여러 개 섞여 있는 경우가 상당히 많습니다.
- 사용자가 나중에 직접 수정하고 싶다
- 지금 있는
.xlsm을 남기고 싶다 - 피벗, 그래프, 인쇄 설정까지 그대로 쓰고 싶다
- 야간 배치로 대량으로 내고 싶다
- 서버에서 무인 실행하고 싶다
- PDF도 필요하다
이런 요건들은 한 가지 방식으로 모두 깔끔하게 풀리지 않습니다.
가장 먼저 봐야 하는 것은 라이브러리 이름보다도, Excel 애플리케이션을 움직일 것인가, Excel 파일을 만들 것인가입니다.
여기를 잘못 잡으면 처음에는 돌아가더라도 나중에 유지보수가 힘들어집니다.
이번에는 Windows 앱이나 업무 시스템에서의 Excel 장표 출력을 전제로, COM 자동화 / Open XML / 템플릿 차입 / 기존 VBA 병용의 선택 방법을 정리합니다.
1. 먼저 결론
결론만 먼저 나열하면 대체로 다음과 같습니다.
- 사용자가 나중에 Excel을 열어 편집하는 장표라면 첫 번째 후보는 템플릿 +
.xlsx/.xlsm직접 생성입니다. - 서버 / 서비스 / 스케줄러에서 자동 생성한다면 Office 자동화를 전제로 하지 않는 편이 안전합니다.
- 기존의
.xlsm, VBA, 그래프, 피벗, 인쇄 설정을 살리고 싶다면 레이아웃과 Excel 고유 기능은 템플릿 쪽에 모으고, 코드는 데이터 차입에 집중하는 편이 잘 부서지지 않습니다. - 정말로 Excel 애플리케이션의 동작 그 자체가 필요할 때만 COM 자동화를 데스크톱상의 유인 실행에 한정해서 쓰는 것이 자연스럽습니다.
- 단순한 목록 출력이라면 처음부터 CSV / PDF / 웹 화면 쪽이 요건에 맞는 경우도 상당히 많습니다.
요컨대, 많은 업무 장표에서는 “Excel을 조작한다”가 아니라 “Excel 파일을 조립한다”는 편이 자연스럽습니다.
2. 가장 먼저 정할 것
Excel 장표 출력에서 가장 먼저 정하고 싶은 것은 다음과 같은 점입니다.
| 확인 항목 | 먼저 정하는 이유 |
|---|---|
최종 산출물은 .xlsx / .xlsm / PDF / CSV 중 무엇인가 |
여기서 방식을 꽤 좁힐 수 있습니다 |
| 사용자는 출력 후에 Excel에서 편집하는가 | 편집 전제라면 Excel 기능과 레이아웃 유지가 중요합니다 |
| 실행 장소는 사용자 PC인가, 서버 / 서비스 / 배치인가 | COM 자동화를 쓸 수 있는 범위가 크게 달라집니다 |
| 기존 VBA / 매크로 / 애드인을 남길 것인가 | .xlsm 템플릿이나 단계적 이행 설계가 필요합니다 |
| 그래프, 피벗, 인쇄 범위, 머리글 / 바닥글까지 고정하고 싶은가 | 코드보다 템플릿으로 모으는 편이 잘 부서지지 않습니다 |
| 1회당 행 수, 파일 수, 동시 실행 수는 어느 정도인가 | 대량 출력에서는 COM보다 직접 생성이 더 어울립니다 |
| 장표의 겉모습은 누가 변경하는가 | 개발자뿐만 아니라 현장도 건드린다면 템플릿 방식이 잘 맞습니다 |
3. 주요 구현 방식
3.1 Excel COM 자동화
Excel을 기동하고 Workbook, Worksheet, Range를 COM을 통해 조작하는 방식입니다.
진짜 Excel을 운전하는 방식이라고 생각하면 이해하기 쉽습니다.
강점은 Excel 고유의 동작을 그대로 쓸 수 있다는 점입니다.
기존 통합 문서, 그래프, 피벗, 인쇄 설정, 매크로, PDF 출력 등과 잘 어울리고, 「최종적으로 Excel이 어떻게 보여줄 것인가」를 그대로 다룰 수 있습니다.
다만 약점도 꽤 분명합니다.
- Excel 설치가 필요
- 프로세스 수명, 파일 잠금, 대화상자, bitness, 사용자 프로파일 의존을 안고 있음
- 무인 서버나 서비스로부터의 Office Automation은 Microsoft 자체가 권장·지원하지 않음
3.2 .xlsx 직접 생성
.xlsx는 Open XML 형식이므로 Excel을 기동하지 않고 파일을 직접 조립할 수 있습니다.
Open XML SDK 같은 수단을 쓰면 프로그램 쪽에서 통합 문서, 시트, 셀, 스타일, 테이블을 조작할 수 있습니다.
이 방식의 강점은 Excel이 설치되지 않은 환경에서도 돌리기 쉽고, 배치나 서버와 잘 어울리는 점입니다.
한편으로, Excel 그 자체가 가진 UI 쪽 동작까지 자연스럽게 재현하고 싶을 때는 조금 힘들어집니다.
열 너비 자동 조정, 페이지 분할, 복잡한 겉모습, 기존 통합 문서의 깊은 편집 등을 코드만으로 전부 깔끔하게 하려고 하면 금방 진흙탕 싸움이 됩니다.
3.3 템플릿 차입
실무에서 가장 권장하기 쉬운 것은 Excel 템플릿을 먼저 만들고, 코드는 데이터 차입에만 집중하는 방식입니다.
장표의 겉모습, 수식, 조건부 서식, 인쇄 범위, 머리글 / 바닥글, 로고, 그래프는 템플릿 쪽에 둡니다.
코드 쪽은 템플릿을 복제하고, 이름 정의 범위, 테이블, 셀 범위 같은 「정해진 입구」에 데이터를 씁니다.
이렇게 하면 레이아웃 수정과 업무 로직 수정이 분리됩니다.
Excel 장표에서 흔히 보이는 Cells[37, 9] = ... 지옥을 꽤 피하기 쉬워집니다.
3.4 기존 VBA 자산을 남기는 방식
기존의 .xlsm이나 VBA가 살아 있다면 전부를 한 번에 다시 만들지 않는 편이 자연스러운 경우가 많습니다.
장표의 UI나 마지막 정형은 VBA에 남기고, 무거운 계산이나 DB / HTTP / 업무 로직은 C# / .NET 쪽으로 옮기는 분할 방식은 꽤 현실적입니다.
이때 중요한 것은 책임을 애매하게 하지 않는 것입니다.
- VBA 쪽은 통합 문서 안의 동작
- .NET 쪽은 데이터 취득과 업무 처리
- 양쪽의 경계는 이름 정의 범위, 테이블, 공개 인터페이스 등으로 고정
3.5 Microsoft 365 / Graph를 쓰는 경우
Excel 파일이 처음부터 OneDrive / SharePoint 위에 있고, 웹 앱이나 모바일 앱에서 공동 이용하고 싶다면 Microsoft Graph의 Excel API도 선택지에 들어옵니다.
다만 로컬 PC상의 임의 파일을 대충 양산하는 일반 해답은 아닙니다. 권한, 저장 위치, 세션, 운영이 처음부터 M365 전제가 됩니다.
3.6 애초에 Excel일 필요가 있는가
장표의 요건이 「사람이 나중에 만지는 표」라면 Excel이 꽤 자연스럽습니다.
다만 요건이 다음 중 하나라면 다른 형식이 더 솔직한 경우도 많습니다.
- 인쇄해서 보관한다 -> PDF
- 다른 시스템에 취합한다 -> CSV / TSV / JSON
- 브라우저에서 보기만 하면 된다 -> HTML / 웹 화면
- 집계와 시각화가 주목적 -> BI나 대시보드
4. 방식 비교
방식의 차이를 대략 한 장으로 보면 다음과 같습니다.
| 방식 | Excel 설치 | 무인 실행과의 궁합 | 기존 레이아웃 재사용 | Excel 고유 기능과의 궁합 | 잘 맞는 상황 |
|---|---|---|---|---|---|
| COM 자동화 | 필요 | 약함 | 강함 | 매우 강함 | 사용자 PC에서의 출력, 기존 .xlsm, 최종 PDF화 |
.xlsx 직접 생성 |
불필요 | 강함 | 중 | 중 | 배치, 서버, 대량 출력 |
| 템플릿 차입 | 불필요(출력 시) | 강함 | 강함 | 중~강 | 많은 업무 장표의 제1 후보 |
| 기존 VBA 병용 | 이용 형태에 따름 | 약함~중 | 매우 강함 | 강함 | 단계적 이행, 기존 자산 활용 |
| Graph Excel API | M365 전제 | 중 | 중 | 중 | OneDrive / SharePoint상의 공동 이용 |
5. 흔한 요건별 선택법
5.1 사용자 PC에서 출력하고 그대로 편집한다
이 경우는 템플릿 + 직접 생성이 꽤 유력합니다.
사용자는 출력 후에 Excel로 여니까 최종 편집은 Excel에 맡겨도 되기 때문입니다.
5.2 야간 배치나 서비스에서 대량 생성한다
이 경우는 COM 자동화를 빼는 데서부터 시작하는 편이 안전합니다.
생성은 .xlsx의 직접 생성으로 모으고, 필요하면 나중에 사용자가 Excel로 여는 형태로 만듭니다.
5.3 기존의 .xlsm / VBA를 살리고 싶다
이 경우는 템플릿으로 .xlsm을 남기고, 데이터 차입만 밖에서 하는 것이 현실적입니다.
5.4 명세 행이 크다
Excel 한 시트의 상한은 1,048,576행 × 16,384열입니다.
그래서 명세가 큰 경우에는 처음부터 다음을 정합니다.
- 몇 행을 넘으면 시트를 분할할 것인가
- 몇 건을 넘으면 파일을 분할할 것인가
- 애초에 CSV 쪽이 더 자연스럽지 않은가
6. 실무에서 권장하기 쉬운 구성
실무에서 잘 부서지지 않는 것은 다음 4층으로 나눈 구성입니다.
| 층 | 역할 | 여기서 안 하는 것 |
|---|---|---|
| ReportModel | 장표에 필요한 값을 정형 | 셀 번지를 모름 |
| Template | 겉모습, 수식, 인쇄 설정, 그래프를 보유 | DB나 업무 로직을 모름 |
| Binder | 이름 정의 범위 / 테이블에 데이터를 씀 | 비즈니스 판단을 끌어들이지 않음 |
| Finisher | 필요하다면 VBA / COM / PDF화를 수행 | 원본 데이터 취득을 하지 않음 |
이 분할의 좋은 점은 코드가 Excel의 겉모습에 끌려가기 어려워진다는 것입니다.
7. 빠지기 쉬운 곳
7.1 셀 번지를 업무 사양으로 삼지 않는다
Cells[12, 7]이 업무 규칙을 나타내기 시작하면 레이아웃 변경이 그대로 사양 변경이 됩니다.
코드는 이름 정의 범위나 테이블 이름을 통해 장표를 만지는 편이 오래갑니다.
7.2 병합 셀을 데이터의 입구로 삼지 않는다
병합 셀은 겉모습을 위한 기능입니다.
차입 대상으로 쓰면 행 추가나 범위 계산에서 사고가 나기 쉽습니다.
7.3 숫자나 날짜를 「겉모습 붙은 문자열」로 채우지 않는다
값은 값으로 넣고, 겉모습은 셀 서식으로 모으는 편이 자연스럽습니다.
7.4 템플릿 변경을 비공식 운영으로 만들지 않는다
템플릿은 코드는 아니지만 실질적으로는 사양 그 자체입니다.
따라서 버전 관리, 차분 확인, 리뷰 대상으로 다루는 편이 안전합니다.
7.5 COM을 쓴다면 bitness와 수명 관리를 가볍게 보지 않는다
COM 자동화나 VBA 연계에서는 32bit / 64bit의 차이, Excel 프로세스의 뒤처리, 파일 잠금, 사용자 환경 차분이 은근히 작용합니다.
8. 정리
Excel 장표 출력은 「Excel로 낸다」는 한 줄로 끝나는 이야기처럼 보이지만, 실제로는 다음 분기를 먼저 정할 필요가 있습니다.
- Excel 애플리케이션을 움직일 것인가
- Excel 파일을 만들 것인가
- 사용자 PC인가, 무인 실행인가
- 기존 VBA나
.xlsm을 남길 것인가 - 최종 산출물은 Excel인가, PDF나 CSV인가
실무에서의 제1 후보로는 템플릿 + 직접 생성이 꽤 강합니다.
거기에 필요에 따라 기존 VBA의 재사용이나 사용자 PC상에서의 최종 Excel 처리를 덧붙이는 형태가 정리하기 좋습니다.
9. 참고 자료
- Considerations for server-side Automation of Office
- Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment
- About the Open XML SDK for Office
- How to: Copy a worksheet using SAX (Simple API for XML)
- Working with Excel workbooks and charts using the Microsoft Graph API
- Access OneDrive and SharePoint using the Microsoft Graph API
- Excel specifications and limits
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면과 현실적인 이행 패턴
VBA의 강점과 제약을 정리하고, Excel for the web 미지원이나 매크로 차단 같은 현실을 전제로 어디까지 VBA에 남기고 무엇을 .NET·Office Scripts·Office Add-ins로 분리할지, 단계 이행의 판단 기준과 진행...
COM 컴포넌트나 OCX / ActiveX 개발에서 빠지기 쉬운 것 - Visual Studio의 32bit / 64bit, 등록, 관리자 권한의 덫을 정리
COM 컴포넌트와 ActiveX, OCX 개발에서 자주 만나는 0x80040154나 0x80070005를 비트 수, 등록 방식, HKCU와 HKLM 스코프, 관리자 권한이라는 네 축으로 풀어 Visual Studio 2022의 64bit화 시대에...
Reg-Free COM이란 무엇인가 - 등록 불필요로 COM을 쓰는 구조와, 맞는 장면·맞지 않는 장면
Reg-Free COM은 COM 등록 정보를 매니페스트로 가져 앱 단위 액티베이션 컨텍스트로 해결하는 구조입니다. XCOPY 배포·버전 충돌·롤백을 가볍게 하는 한편, bitness·의존 DLL·TLB·설계 시 참조는 별개임을 정리하고 도입 판단...
.NET 8의 DLL을 형 있게 VBA에서 쓰는 방법 - COM 공개 + dscom으로 TLB를 생성
.NET 8 클래스 라이브러리를 EnableComHosting으로 빌드하고 dscom으로 TLB를 생성·등록하면, VBA에서 조기 바인딩으로 형 있게 호출할 수 있습니다. bitness 정합과 인터페이스 설계의 요점도 짚었습니다.
COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 정리해서 해설
Windows 레거시 안건에서 자주 마주치는 COM과 ActiveX, OCX의 차이를 토대·부품·파일이라는 축으로 정리해, regsvr32와 32/64bit, IE 모드 같은 키워드를 만났을 때 헷갈리지 않고 조사와 이전 방침을 잡을 수 있도록 ...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
ActiveX 이관
COM / ActiveX / OCX 자산을 유지할지, 감쌀지, 교체할지의 단계적 판단을 정리한 토픽 페이지입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.
기존 자산 활용 & 이관 지원
COM / ActiveX / OCX 자산, 네이티브 코드, 32비트 의존성을 유지하면서 단계적인 이관 계획을 지원합니다.