VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면과 현실적인 이행 패턴

VBA의 상담에서는 다음 같은 이야기가 자주 섞입니다.

• 애초에 VBA란 무엇인가
• 매크로는 위험하다고 하는데 이제 쓰지 말아야 하는가
• 앞으로 쓸 수 없게 되는가
• Office Scripts나 Power Automate에 전부 옮기면 되는가
• 기존의 .xlsm이나 Access 자산은 남겨야 하는가, 버려야 하는가
• Excel을 야간 배치나 서버에서 돌려도 되는가

이쯤은 하나의 답으로 전부 깔끔하게 정리되는 주제가 아닙니다.
가장 먼저 봐야 하는 것은 새로운가 오래됐는가보다도 어디에서 실행하는가, 누가 쓰는가, Excel / Access 자체가 UI인가, 무인 실행인가입니다.

이 글에서는 VBA란 무엇인가, 어디에 제약이 있는가, 앞으로 쓸 수 없게 되는가, 교체해야 할 장면은 어디인가, 어떻게 단계 이행하면 현실적인가, 라는 순서로 정리합니다.
덧붙여 내용은 2026년 3월 시점에 확인할 수 있는 Microsoft의 공식 정보를 전제로 합니다.¹²³⁴⁵

1. 먼저 결론

결론만 먼저 나열하면 대체로 다음과 같습니다.

• VBA는 Office 데스크톱 앱을 확장하기 위한 이벤트 구동 언어입니다. Excel이나 Word, PowerPoint, Access 등의 안에서 돌아가는 것을 전제로 하는 기술입니다.¹
• 적어도 2026년 3월 시점에 Microsoft의 공식 정보로서 「VBA 자체를 조만간 종료한다」는 명확한 안내는 확인할 수 없습니다. 지금 일어나고 있는 것은 「갑작스러운 전폐」보다도 쓸 수 있는 장소와 전제 조건이 분명해졌다는 변화입니다.¹²³⁴
• 구체적으로 Excel for the web에서는 VBA를 작성·실행·편집할 수 없습니다. 또한 인터넷 유래 파일의 매크로는 기정으로 차단됩니다.²³
• 따라서 지금의 논점은 「VBA를 전부 버릴까」가 아니라 어느 영역을 VBA에 남기고 어느 영역을 밖으로 낼까입니다.
• 특히 무인 실행, 서버 실행, 다인 운영, 브라우저 대응, 중앙 배포, 엄격한 감사가 필요한 처리는 VBA만으로 떠안지 않는 편이 자연스럽습니다. Microsoft도 Office의 서버 측 자동화를 권장·지원하지 않습니다.⁶
• 교체 대상은 하나가 아닙니다.
  Excel을 남긴다면 .NET DLL이나 별도 프로세스로 처리를 내보낸다, Microsoft 365 상의 업무 플로라면 Office Scripts + Power Automate, 크로스 플랫폼 확장이라면 Office Add-ins, 애초에 Excel이 UI가 아니게 되어 있다면 Windows 앱이나 Web 앱으로 내보낸다는 구분 방식이 현실적입니다.⁴⁵⁶

요컨대 VBA는 「즉사할 기술」이 아니라 「적재적소가 분명한 기술」로 보는 것이 실무적입니다.

2. VBA란 무엇인가

VBA는 Visual Basic for Applications의 약자로, Microsoft Office에 부속하는 Visual Basic의 일종입니다. Microsoft의 공식 문서에서도 Office 애플리케이션을 확장하기 위한 이벤트 구동형 프로그래밍 언어로 설명되어 있습니다.¹⁷

여기서 중요한 것은 VBA를 범용의 앱 개발 기반으로 보기보다 Office 앱의 안쪽에 꽂아 넣는 확장 언어로 보는 편이 실태에 가깝다는 점입니다.

예를 들어 Excel이라면 다음 같은 대상에 가까운 장소에서 돕니다.

• Workbook
• Worksheet
• Range
• 버튼이나 폼
• 북을 열었을 때, 저장했을 때, 셀 변경 시의 이벤트

즉 VBA의 강점은 Excel이나 Access의 화면·장표·북 구조에 매우 가까운 점입니다.
이용자가 데스크톱의 Office를 열고 버튼을 누르고 로컬 파일이나 공유 폴더의 데이터를 처리해 그대로 장표를 내놓는다. 그런 「이용자의 손 근처에서 완결되는 자동화」에는 지금도 강점이 있습니다.¹

반대로 말하면 VBA의 본래 수비 범위는 처음부터 서버, 브라우저, 모바일, 멀티 테넌트한 Web 시스템이 아닙니다.

3. 왜 지금도 쓰이는가

VBA가 지금도 현장에 계속 남는 이유는 단순히 「오래됐으니까 관성으로 남아 있다」만이 아닙니다.

우선 Excel이나 Access에는 단순한 데이터가 아니라 업무 절차 그 자체가 들어가기 쉽습니다.

• 장표의 겉모습
• 인쇄 설정
• 입력 체크
• 월차 처리의 순서
• 부문별 예외 규칙
• 현장이 오래 익숙해진 조작 절차

이쯤은 다른 시스템으로 옮길 때 「코드 이식」만으로는 끝나지 않습니다.
겉모습, 조작, 예외, 운영이 일체가 되어 있으므로 VBA 자산은 겉보기 이상의 사양을 안고 있습니다.

또한 VBA는 Office의 오브젝트 모델에 가까워서, 이용자의 눈앞에 있는 Excel 그 자체를 조작해 결과를 돌려주는 용도에서는 손수가 적습니다.
이 가까움은 후계 후보를 생각할 때도 중요해서, 단순히 새로운 기술로 다시 쓰면 그걸로 끝이라고는 할 수 없습니다.

실무에서는 다음처럼 생각하는 것이 자연스럽습니다.

• Excel이 UI로 계속 있는다면 VBA를 일부 남길 가치가 있다
• Excel은 입출력뿐이어도 된다면 내용의 로직은 밖으로 내기 쉽다
• Excel 자체가 이미 본래의 UI가 아니라면 다시 만드는 후보가 된다

4. VBA의 주요 제약

4.1 데스크톱 전제이다

가장 큰 제약은 이것입니다.
VBA는 기본적으로 데스크톱판 Office의 안쪽에서 도는 기술입니다.

Microsoft의 공식 정보에서도 Excel for the web에서는 VBA를 작성·실행·편집할 수 없으며, 매크로 첨부 북을 열어 편집은 할 수 있지만 VBA의 실행은 할 수 없다고 되어 있습니다.²⁸

이 시점에서 다음 요건과는 상성이 나빠집니다.

• 브라우저에서 완결하고 싶다
• Mac / iPad / Web을 넘나들며 같은 확장을 쓰고 싶다
• 관리자가 중앙 배포하고 싶다
• 로컬의 Excel 데스크톱 앱에 의존하고 싶지 않다

Microsoft 자체도 복수 플랫폼용 확장을 만들고 싶다면 Office Add-ins를 봐야 한다고 VBA 문서 쪽에서 안내하고 있습니다.⁹⁵

4.2 보안과 배포의 마찰이 크다

VBA가 「쓸 수 없게 됐다」고 오해되기 쉬운 이유의 큰 부분은 실은 보안 강화입니다.

Microsoft는 인터넷 유래 파일에 포함되는 VBA 매크로를 기정으로 차단하도록 했습니다. 메일 첨부나 다운로드한 .xlsm을 그대로 열어도 예전보다 솔직하게는 실행되지 않습니다.³

이것은 보안으로서는 올바른 방향입니다.
다만 운영 측에서 보면,

• 첨부로 배포하면 동작하지 않는다
• 사외 사이트에서 받은 템플릿이 동작하지 않는다
• OneDrive / SharePoint / 네트워크 경유에서의 취급이 알기 어렵다
• 「유효화해 주세요」라는 안내가 운영의 약점이 된다

라는 마찰이 늘어납니다.

즉 VBA의 문제는 「언어 기능」만이 아니라 배포와 신뢰의 설계에서도 일어납니다.

4.3 32bit / 64bit의 벽이 있다

Office는 32bit 판과 64bit 판이 있고, Office 2019와 Microsoft 365에서는 기정이 64bit입니다.⁷

그래서 오래된 VBA 코드 중 특히 Windows API를 Declare로 호출하고 있는 것은 64bit 환경에서 그대로 동작하지 않을 수 있습니다.
Microsoft도 PtrSafe, LongPtr, LongLong 등을 써서 32bit / 64bit의 차이를 흡수할 필요가 있다고 안내하고 있습니다.⁷

여기서 괴로운 것은 코드뿐만 아니라 다음 의존도 함께 문제가 되기 쉽다는 점입니다.

• 오래된 COM / ActiveX / OCX
• 32bit 전제의 외부 DLL
• 레지스트리 등록 전제의 부품
• Office의 참조 설정 어긋남

즉 VBA의 이행은 언어의 다시 쓰기라기보다 Office bitness와 외부 의존의 정리가 되는 경우가 꽤 많습니다.

4.4 무인 실행·서버 실행에 맞지 않는다

여기는 꽤 중요합니다.
Microsoft는 Office 애플리케이션의 서버 측 자동화를 권장·지원하지 않는다고 명언하고 있습니다. Office는 대화적인 데스크톱과 사용자 프로파일을 전제로 설계되어 있으며, 무인 환경에서는 불안정이나 데드록이 일어날 수 있습니다.⁶

그래서 다음 같은 구성은 위험한 쪽입니다.

• Windows 서비스에서 Excel을 기동한다
• ASP.NET이나 DCOM에서 Office를 자동화한다
• 태스크 스케줄러 위에서 보이지 않는 Excel을 계속 돌린다
• 서버 위의 Excel에 장표 생성을 통째로 맡긴다

「가끔 동작한다」는 있습니다.
다만 동작하고 있는 것과 지지될 수 있는 구성인 것은 별개입니다.

무인 실행이 필요하다면 먼저 의심해야 하는 것은 VBA가 아니라 Excel 앱 자체를 운전하는 구성 쪽입니다.

4.5 보수성·테스트성·차분 관리에서 불리해지기 쉽다

VBA는 북이나 Access 파일 안에 코드가 갇히기 쉽습니다.
그 결과 다음 문제가 일어나기 쉬워집니다.

• 어느 파일이 정본인지 애매해진다
• 폼, 시트, 표준 모듈에 책임이 흩어진다
• 참조 설정이나 ActiveX 의존이 환경마다 어긋난다
• 코드 리뷰나 차분 확인이 어렵다
• 단체 테스트를 만들기 어렵다
• Excel의 셀 번지 그 자체가 사양화되어 간다

이것은 VBA라는 언어만의 문제가 아니라 「Office 파일 안에 업무 로직을 가진다」 구조의 문제입니다.
작은 자동화에서는 큰 문제가 되지 않아도, 업무 시스템화되어 가면 갑자기 작용합니다.

4.6 VBScript 의존이 있는 경우는 별도의 주의가 필요

2025년에는 Microsoft 365 Developer Blog에서 Windows에서의 VBScript의 단계적 폐지가 VBA 프로젝트에도 영향을 줄 수 있다는 점이 안내되었습니다.
특히 외부 .vbs를 실행하고 있는 케이스나 VBScript.RegExp의 참조에 의존하고 있는 케이스는 영향 대상이 됩니다.¹⁰

한편으로 Microsoft는 Microsoft 365 Version 2508(Build 19127.20154) 이후의 Windows 판 Office에서는 RegExp 클래스를 VBA에 기정으로 포함한다는 형태로도 대응을 진행하고 있습니다.¹⁰

여기서 중요한 것은 VBScript의 폐지와 VBA의 폐지는 같은 이야기가 아니다라는 것입니다.
VBA 그 자체가 사라지는 이야기가 아니라 VBA에서 매달려 있던 일부의 외부 의존을 재검토할 필요가 있다는 이해 쪽이 정확합니다.

5. VBA는 앞으로 쓸 수 없게 되는가

결론부터 말하면 「내일부터 전부 쓸 수 없게 된다」는 아닙니다.
다만 「어디서나 무엇에든 쓸 수 있는」 시대도 아닙니다.

적어도 Microsoft의 공식 정보의 읽는 방식으로서 지금 강하게 보이는 것은 다음 방향입니다.

• 데스크톱 Office의 확장으로서의 VBA는 계속해서 존재한다¹
• Web / 크로스 플랫폼 쪽은 Office Scripts나 Office Add-ins를 구분해 쓴다⁴⁵⁹
• 매크로 배포의 안전성은 이전보다 엄격하게 다룬다³
• VBScript 의존 같은 주변 부품은 장래의 영향을 받을 수 있다¹⁰

또한 Microsoft는 Office Scripts에 대해 VBA는 데스크톱 중심, Office Scripts는 안전하고 크로스 플랫폼인 클라우드 기반의 솔루션용이라고 명시하고 있습니다.
동시에 데스크톱 클라이언트에서 쓸 수 있는 Excel 기능의 커버 범위는 현시점에서는 VBA 쪽이 넓다고도 설명하고 있습니다.⁴

이 2가지를 나란히 두면 꽤 실무적인 시각이 됩니다.

• 데스크톱 Excel의 깊은 조작에서는 아직 VBA의 수비 범위가 넓다
• 브라우저 / M365 / 공유 워크플로에서는 Office Scripts나 Add-ins 쪽이 자연스럽다
• 그래서 「전부 Office Scripts로 바꾸면 된다」도 「VBA를 영구적으로 중심에 두면 된다」도 아니다

요컨대 VBA의 장래는 소멸보다 경계의 명확화로 보는 것이 자연스럽습니다.

6. 교체해야 할 케이스 / 교체하지 않아도 되는 케이스

우선 거칠지만 도움이 되는 판단표를 둡니다.

이 표에서 중요한 것은 교체의 판단 축이 「VBA는 오래됐으니까」가 아닌 점입니다.
정말로 봐야 할 것은 실행 환경, 운영, 배포, 의존, 감사, 확장성입니다.

7. 현실적인 교체 대상

7.1 Excel을 남기고 내용만 .NET이나 별도 프로세스로 낸다

가장 현실적이고 실패하기 어려운 것은 이것입니다.

• 화면이나 장표의 입구는 Excel / Access 그대로
• 버튼이나 입력 폼도 당분간 그대로
• 다만 업무 로직, HTTP, 암호, CSV / JSON, 무거운 계산, 파일 처리는 밖으로 낸다
• VBA는 「다리 놓기」와 「UI 조작」만으로 치우친다

이 구성의 이점은 이용자의 겉모습과 조작을 깨뜨리기 어려운 점입니다.
전면 리플레이스보다 우선 책임을 얇게 하는 방향으로 진행할 수 있습니다.

관련 기사:

• .NET 8의 DLL을 형 있게 VBA에서 쓰는 방법 - COM 공개 + dscom으로 TLB를 생성

「전부 다시 쓰기 전에 우선 무거운 곳만 내보낸다」는 꽤 실무용입니다.

7.2 무인 실행이나 장표 생성은 Office 앱 자동화가 아니라 파일 직접 생성으로 치우친다

Excel 장표를 야간 배치나 서비스에서 대량 생성하고 싶다면 먼저 의심해야 할 것은 「VBA가 오래됐는가」가 아니라 Excel 앱을 기동하고 있는 것 자체입니다.

Microsoft는 서버 측에서의 Office Automation을 권장하지 않습니다.
대신 Open XML 형식 등을 써서 Office 파일을 직접 다루는 방법을 권장하고 있습니다.⁶

즉 요건이,

• .xlsx를 만들고 싶다
• 정형 장표를 대량으로 내고 싶다
• PDF화하고 싶다
• 야간 배치로 돌리고 싶다

같은 것이라면 선택해야 할 축은 Excel을 운전할까가 아니라 Excel 파일을 조립할까입니다.

관련 기사:

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

7.3 Microsoft 365 상의 업무 플로라면 Office Scripts + Power Automate

업무가 이미 OneDrive / SharePoint / Teams / Outlook / Forms 위에 치우쳐 있다면 Office Scripts는 꽤 후보가 됩니다.

Microsoft는 Office Scripts를 안전하고 크로스 플랫폼인 클라우드 기반의 솔루션용으로 설명하고 있습니다.
또한 Power Automate와 조합함으로써 메일이나 폼이나 스케줄을 트리거로 Excel 처리를 자동화할 수 있습니다.⁴¹¹

다만 여기도 만능은 아닙니다.

• Office Scripts는 Excel 레벨의 이벤트를 지원하지 않습니다
• 실행은 수동 개시 또는 Power Automate로부터의 호출이 기본입니다⁴
• Power Automate 연계에는 Microsoft 365의 비즈니스 라이선스가 필요합니다¹¹
• Run script 액션에는 1 사용자당 하루 1,600회, 동기 처리 120초 등의 제한이 있습니다¹²

즉 Office Scripts는 「VBA의 대체물」보다 M365 상의 자동화 부품으로 보는 편이 정확합니다.

7.4 크로스 플랫폼 확장이 필요하다면 Office Add-ins

Word, Excel, Outlook 등을 Windows / Mac / iPad / 브라우저에서 확장하고 싶다면 Office Add-ins가 제1 후보입니다.

Microsoft의 공식 문서에서도 Office Add-ins는 HTML / CSS / JavaScript로 구축할 수 있으며, 복수 플랫폼에서 동작하고 중앙 배포에도 맞다고 설명되어 있습니다.⁵

이것은 예를 들어 다음 같은 요건에 맞습니다.

• 사내 포털이나 기간 시스템과 Office를 잇고 싶다
• Outlook / Excel / Word에 같은 UI나 커맨드를 내고 싶다
• 사용자의 PC별 매크로 배포가 아니라 관리자 배포하고 싶다
• 로컬한 .xlsm 배포 모델에서 떨어지고 싶다

VBA와는 씨름판이 다르므로 Excel 안에 코드를 쓰는 감각과는 꽤 바뀝니다.
그 대신 운영과 배포는 정리하기 쉬워집니다.

7.5 Excel / Access 자체가 본래의 UI가 아니게 되어 있다면 Windows 앱이나 Web 앱으로 낸다

다음 같은 상태라면 VBA의 연명보다 앱으로서 다시 만드는 편이 자연스럽습니다.

• 화면 전환이나 권한 제어가 너무 늘어나 있다
• DB, 감사 로그, 승인 플로, 사용자 관리가 중심
• 외부 기기 연계나 장시간 처리가 있다
• Excel의 셀이나 폼이 업무 사양서 대신이 되어 있다
• 북을 닫으면 상태 관리가 사라지는 것 자체가 괴롭다

이 경우 Windows 전제의 업무 도구라면 C# / .NET의 데스크톱 앱, 이용자나 단말이 넓다면 Web 앱 쪽이 구조를 솔직하게 할 수 있습니다.

8. 단계 이행의 진행 방식

VBA의 교체에서 가장 위험한 것은 처음부터 전부를 1개의 새 기술로 치우치려는 것입니다.
실무에서는 다음 순서 쪽이 대체로 안전합니다.

8.1 우선 자산 대장을 만든다

처음에 파내고 싶은 것은 코드 양 그 자체보다 의존 관계입니다.

• 어느 .xlsm / .xlam / .accdb / .mdb가 있는가
• 어느 것이 실운용의 입구인가
• 참조 설정에 무엇이 들어 있는가
• Declare, 외부 DLL, COM / ActiveX / OCX는 무엇인가
• 32bit / 64bit의 전제는 어떻게 되어 있는가
• 어느 매크로가 누구의 어느 절차로 쓰이고 있는가
• 출력물은 무엇인가(Excel, CSV, PDF, 인쇄, 메일 송신 등)

여기를 애매하게 둔 채 교체하면 나중에 「아무도 안 건드릴 줄 알았던 매크로가 월말에만 살아 있었다」 같은 사고가 일어납니다.

8.2 코드를 책임으로 나눈다

다음으로 하는 것은 파일 단위가 아니라 책임 단위로 나누는 것입니다.

• Excel / Access의 UI 조작
• 시트 입출력
• 장표 레이아웃
• 업무 규칙
• 외부 API / 파일 / DB I/O
• 배치 처리
• 인쇄 / 배포

이 나눔 방식을 하면 남길 것, 얇게 할 것, 밖으로 낼 것이 보기 쉬워집니다.

8.3 교체 대상을 책임별로 정한다

추천하기 쉬운 나눔 방식은 다음입니다.

• UI와 시트 조작: 당분간 VBA에 남긴다
• 업무 로직: .NET DLL, 별도 프로세스, 서비스로 낸다
• 무인 장표 생성: Open XML이나 직접 생성으로 치우친다
• M365 워크플로: Office Scripts + Power Automate
• 크로스 플랫폼 UI: Office Add-ins
• 업무 시스템화된 영역: Windows / Web 앱으로 분리한다

중요한 것은 이행 대상을 하나로 통일하지 않는 것입니다.
VBA 자산의 내용은 대체로 복수의 책임이 섞여 있습니다.

8.4 먼저 인터페이스를 굳힌다

이행을 시작하기 전에 최소한 여기는 정해 두는 편이 좋습니다.

• 입력은 무엇인가
• 출력은 무엇인가
• 에러 시에 어떻게 돌려줄 것인가
• 어느 시트, 어느 이름 붙인 범위, 어느 파일 패스를 계약으로 할 것인가
• 어느 시점에서 결과가 확정됐다고 볼 것인가

여기를 정하지 않은 채 진행하면 셀 번지 그 자체가 API가 되어 망가지기 쉬워집니다.

8.5 병행 가동으로 비교한다

특히 장표나 집계는 바로 전환하지 않는 편이 안전합니다.

• 구 VBA판과 신 구현판을 병행으로 낸다
• 출력된 .xlsx / CSV / PDF를 비교한다
• 날짜, 반올림, 서식, 인쇄 범위의 차를 확인한다
• 예외계와 빈 데이터계도 시험한다

VBA 교체의 사고는 대체로 「동작하는가 아닌가」가 아니라 숫자나 서식이 조용히 어긋나는 형태로 일어납니다.

9. 흔한 실패

9.1 「VBA는 오래됐으니까 전부 Office Scripts로」로 시작한다

Office Scripts는 유력하지만, Microsoft 자체가 VBA 쪽이 데스크톱 Excel 기능의 커버 범위가 넓다고 설명하고 있습니다.
또한 Office Scripts는 Excel 레벨의 이벤트를 지원하지 않습니다.⁴

그래서 깊은 Excel 데스크톱 의존의 매크로를 그대로 옆으로 옮기는 발상은 위험합니다.

9.2 무인 실행인데 Excel 자체를 계속 기동한다

이것은 꽤 많습니다.
동작하고 있는 동안은 편리해 보이지만, Microsoft는 Office의 서버 측 자동화를 권장하지 않습니다.⁶

야간 배치나 서비스라면 Excel을 운전한다가 아니라 Excel 파일을 조립한다 쪽으로 치우치는 편이 안전합니다.

9.3 화면, 장표, 업무 규칙을 동시에 전부 바꾼다

VBA 교체에서 정말 무서운 것은 코드 변환 그 자체보다 업무 사양의 놓침입니다.
Excel의 시트나 Access 폼에는 코드에 쓰이지 않은 운영 규칙이 꽤 묻혀 있습니다.

전부를 한 번에 바꾸면 「겉보기는 가까운데 월말에만 다르다」 같은 사고가 일어나기 쉽습니다.

9.4 32bit / 64bit와 외부 참조를 뒤로 미룬다

이행 안건에서는 VBA 코드 그 자체보다,

• Declare
• 외부 DLL
• COM / ActiveX / OCX
• Office bitness
• 참조 설정

이 먼저 폭발하는 경우가 자주 있습니다.
여기를 뒤로 돌리면 구현의 종반에 단번에 괴로워집니다.⁷

9.5 VBScript의 이야기와 VBA의 이야기를 혼동한다

VBScript의 단계적 폐지는 VBA에서 보면 일부 의존의 재검토의 이야기입니다.
VBA 전체의 종료와 같은 의미가 아닙니다.¹⁰

여기를 섞으면 「VBA가 끝나는 것 같다」는 거친 사내 정보만이 홀로 걸어 다니기 쉬워집니다.

10. 정리

VBA를 한마디로 말하면 Office 데스크톱 앱에 밀착한 확장 언어입니다.
Excel이나 Access의 바로 옆에서 이용자의 손 근처의 업무를 자동화하는 데는 지금도 꽤 실용적입니다.¹

다만 앞으로의 실무에서 중요한 것은 VBA를 만능한 중심 기술로 다루지 않는 것입니다.

• 브라우저 / 크로스 플랫폼이 필요하다면 Office Scripts나 Office Add-ins를 본다⁴⁵
• 무인 실행 / 서버 처리라면 Office Automation을 피한다⁶
• 무거운 로직이나 외부 연계는 .NET이나 별도 프로세스로 낸다
• Excel / Access가 이미 UI로서 괴로운 경우라면 Windows 앱이나 Web 앱으로 낸다

요컨대 답은 「전부 교체한다」도 「아무것도 바꾸지 않는다」도 아니라 「책임별로 나누어 단계적으로 얇게 한다」입니다.

VBA 자산은 거칠게 보면 오래되어 보입니다.
다만 실무에서는 그 안에 업무 사양, 운영 절차, 장표 설계, 현장의 익숙함이 꽤 담겨 있습니다.

그래서야말로 교체는 번역이 아니라 정리로 진행하는 것이 가장 안전합니다.

11. 관련 기사

• COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 모아서 해설
• .NET 8의 DLL을 형 있게 VBA에서 쓰는 방법 - COM 공개 + dscom으로 TLB를 생성
• Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표

12. 참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.