Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표

· · Excel, 장표, Windows 개발, Office, 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. 참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

ActiveX 이관

COM / ActiveX / OCX 자산을 유지할지, 감쌀지, 교체할지의 단계적 판단을 정리한 토픽 페이지입니다.

토픽 보기

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

블로그 목록으로 돌아가기