VBA란 무엇인가 - 제약, 전망, 교체가 필요한 경우와 현실적인 이전 패턴

VBA 상담에서는 이런 이야기가 자주 섞입니다.

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

이 주제는 하나의 답으로 전부 깔끔하게 끝나지 않습니다. 먼저 볼 것은 새로운가 오래된가보다 어디서 실행하는지, 누가 쓰는지, Excel / Access 자체가 UI인지, 무인 실행인지입니다.

flowchart TB
    accTitle: VBA 판단에서 먼저 볼 축
    accDescr: VBA를 유지할지 교체할지 판단할 때는 새로운가 오래된가보다, 어디서 실행하는지, 누가 쓰는지, Excel이나 Access 자체가 UI인지, 무인 실행인지를 먼저 봐야 한다는 점을 나타내는 그림.
    a0["새로운가 오래된가"] -.-> a1["먼저 볼 축이 아니다"]
    b0["먼저 봐야 할 축"] --> b1["어디서 실행하는지"]
    b0 --> b2["누가 쓰는지"]
    b1 --> b3["Excel / Access 자체가 UI인지"]
    b2 --> b4["무인 실행인지"]

그림1: VBA 판단 축은 새로운가 오래된가가 아니라 실행 장소·사용자·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는 「바로 죽는 기술」이 아니라 「적재적소가 분명한 기술」로 보는 것이 실무적입니다.

flowchart TB
    accTitle: 지금 일어나는 변화를 보는 방식
    accDescr: 지금 일어나는 일은 갑작스러운 전면 폐지가 아니라 쓸 수 있는 장소와 전제 조건이 분명해진 변화이며, 논점은 VBA를 전부 버릴지가 아니라 어느 영역을 VBA에 남기고 어느 영역을 밖으로 낼지임을 나타내는 그림.
    c1["갑작스러운 전면 폐지"] -.-> c2["공식 정보에서는 확인되지 않는다"]
    d1["쓸 수 있는 장소와 전제 조건의 명확화"] --> d2["논점이 바뀐다"]
    d2 --> d3["어느 영역을 VBA에 남길지"]
    d2 --> d4["어느 영역을 밖으로 낼지"]

그림2: 논점은 「전부 버릴까」가 아니라, 남길 영역과 밖으로 낼 영역의 분담입니다.

이 글의 지식 맵

VBA는 Office 데스크톱 앱 안에서 동작하는 이벤트 구동 언어로, Excel for the web에서는 작성·실행·편집을 할 수 없고, 인터넷에서 온 파일의 매크로는 기본적으로 차단됩니다. 이 차단은 신뢰할 수 있는 위치·신뢰할 수 있는 사이트·신뢰할 수 있는 게시자와 코드 서명 인증서 같은 수단으로 개별적으로 회피할 수 있습니다. VBA는 Office의 서버 측 자동화에는 적합하지 않으며, Microsoft는 무인 장표 생성에 Open XML 형식으로 직접 생성하는 방식을 권장합니다. 오래된 Declare 문은 64bit Office에서 동작하지 않는 경우가 있고, 외부 .vbs 실행이나 VBScript.RegExp에 대한 의존은 VBScript의 단계적 폐지 영향을 받을 수 있습니다. 대체 대상은 하나가 아니며, 무거운 업무 로직은 .NET DLL로, 크로스 플랫폼 확장은 Office Add-ins로, M365상의 워크플로는 Office Scripts와 Power Automate로, 책임 영역별로 나누는 것이 현실적입니다.

flowchart LR
    accTitle: VBA의 제약과 대체 대상 지식 맵
    accDescr: VBA가 Office 데스크톱 내부에 한정된 확장 언어라는 점, Excel for the web와의 비호환, 기본 매크로 차단과 신뢰할 수 있는 위치·신뢰할 수 있는 사이트·신뢰할 수 있는 게시자를 통한 회피, 서버 측 자동화의 비권장과 Open XML로의 대체, bitness나 VBScript 의존이라는 제약, Office Scripts·Office Add-ins·.NET으로의 책임 영역별 대체 대상을 보여주는 그림
    vba["VBA(Visual Basic for Applications)"]
    excel_for_the_web["Excel for the web"]
    macro_block_policy["인터넷 출처 매크로의 기본 차단"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    trusted_location["신뢰할 수 있는 위치"]
    trusted_site_zone["신뢰할 수 있는 사이트/로컬 인트라넷 영역"]
    trusted_publisher_store["신뢰할 수 있는 게시자 저장소"]
    code_signing_cert["코드 서명 인증서"]
    server_side_office_automation["서버 사이드 Office 자동화"]
    open_xml_format["Open XML 형식"]
    unattended_report_generation["무인 장표 생성"]
    bitness_match_requirement["비트수 일치 요건"]
    vba_64bit_migration["VBA 64비트 대응(PtrSafe/LongPtr)"]
    com["COM(컴포넌트 오브젝트 모델)"]
    activex["ActiveX"]
    ocx["OCX"]
    cross_platform_office_extension["크로스 플랫폼 Office 확장"]
    office_addins["Office Add-ins"]
    m365_cloud_workflow["M365상의 클라우드 워크플로"]
    office_scripts["Office 스크립트(Office Scripts)"]
    power_automate["Power Automate"]
    vbscript_regexp_dependency["VBScript.RegExp/외부 .vbs 의존"]
    vbscript_deprecation["VBScript 단계적 폐지"]
    dotnet[".NET(Core 이후)"]
    vba -->|"양립하지 않는다"| excel_for_the_web
    macro_block_policy -.->|"방지한다"| vba
    zone_identifier -->|"원인이 될 수 있다"| macro_block_policy
    vba -->|"에서 구성할 수 있다"| trusted_location
    vba -->|"에서 구성할 수 있다"| trusted_site_zone
    vba -->|"에서 구성할 수 있다"| trusted_publisher_store
    trusted_publisher_store -->|"전제로 한다"| code_signing_cert
    vba -->|"사용은 비권장"| server_side_office_automation
    open_xml_format -->|"권장되는 대응"| unattended_report_generation
    server_side_office_automation -->|"사용은 비권장"| unattended_report_generation
    vba -.->|"전제로 한다"| bitness_match_requirement
    vba -.->|"전제로 한다"| vba_64bit_migration
    vba -.->|"이용한다"| com
    vba -.->|"이용한다"| activex
    vba -.->|"이용한다"| ocx
    vba -->|"양립하지 않는다"| cross_platform_office_extension
    office_addins -->|"권장되는 대응"| cross_platform_office_extension
    vba -->|"사용은 비권장"| m365_cloud_workflow
    office_scripts -->|"권장되는 대응"| m365_cloud_workflow
    power_automate -.->|"이용한다"| office_scripts
    vba -.->|"전제로 한다"| vbscript_regexp_dependency
    vbscript_regexp_dependency -.->|"양립하지 않는다"| vbscript_deprecation
    dotnet -->|"권장되는 대응"| vba

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. VBA란 무엇인가

VBA는 Visual Basic for Applications의 약자로, Microsoft Office에 딸린 Visual Basic의 일종입니다. Microsoft 공식 문서에서도 Office 애플리케이션을 확장하기 위한 이벤트 기반 프로그래밍 언어라고 설명합니다.¹⁷

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

flowchart TB
    accTitle: VBA를 올바로 보는 방식
    accDescr: VBA는 범용 앱 개발 기반으로 보기보다 Office 앱 안에 꽂는 이벤트 기반 확장 언어로 보는 편이 실상에 가깝다는 점을 나타내는 그림.
    v1["VBA"] --> j1{"어떻게 볼 것인가"}
    j1 -.->|"실상에서 멀다"| a1["범용 앱 개발 기반"]
    j1 -->|"실상에 가깝다"| a2["Office 앱 안에 꽂는 확장 언어"]
    a2 --> a3["Office 안에서 동작하는 이벤트 기반 언어"]

그림3: VBA는 범용 개발 기반이 아니라, Office 안에 꽂는 확장 언어로 봅니다.

예를 들어 Excel이라면 이런 대상에 가까운 자리에서 동작합니다.

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

즉 VBA의 강점은 Excel이나 Access의 화면·보고서·통합 문서 구조에 매우 가깝다는 점입니다. 사용자가 데스크톱 Office를 열고, 버튼을 누르고, 로컬 파일이나 공유 폴더의 데이터를 처리한 뒤 그대로 보고서를 냅니다. 그런 「사용자 손안에서 끝나는 자동화」에는 지금도 강점이 있습니다.¹

실제 코드는 예를 들어 이 정도 길이입니다. 시트 위 버튼에 할당해 쓰는, 가장 작은 형태입니다.

' Excel 표준 모듈에 둡니다. 시트 위 버튼에서 호출하는 전제입니다
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("明細")

    If MsgBox("明細 시트의 2행 이후를 지웁니다. 계속할까요?", _
              vbOKCancel + vbQuestion, "확인") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

시트에 도형이나 폼 컨트롤 버튼을 두고, 오른쪽 클릭의 「매크로 등록」에서 이 ClearMeisai를 고르면, 누를 때마다 이 처리가 실행됩니다. 여기서 볼 것은 ThisWorkbook, Worksheets, Rows 같은 Excel 오브젝트가 변환이나 API 호출을 거치지 않고 그대로 나온다는 점입니다. 「Office 안에서 동작하는 언어」란, 구체적으로는 이 가까움을 말합니다. 반대로 이 가까움이 사라지는 교체 대상에서는 같은 작업량으로는 쓸 수 없습니다.

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

flowchart TB
    accTitle: VBA의 적용 범위
    accDescr: VBA는 Excel이나 Access의 화면·보고서·통합 문서 구조에 가깝고 사용자 손안에서 끝나는 자동화에는 지금도 강한 반면, 서버·브라우저·모바일·멀티 테넌트 Web 시스템은 처음부터 본래 적용 범위가 아님을 나타내는 그림.
    s1["Excel 오브젝트에 그대로 가깝다"] --> s2["사용자 손안에서 끝나는 자동화"]
    s2 --> s3["지금도 강한 영역"]
    t1["서버 / 브라우저 / 모바일 / Web 시스템"] -.-> t2["처음부터 본래 적용 범위가 아니다"]

그림4: Office에 가까운 것이 강점이고, 그 가까움이 필요 없는 자리는 처음부터 적용 범위 밖입니다.

3. 왜 지금도 쓰이는가

VBA가 현장에 남는 이유는 단순히 「오래되어서 관성으로 남았다」만이 아닙니다.

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

• 보고서의 겉모습
• 인쇄 설정
• 입력 검사
• 월별 처리의 순서
• 부서별 예외 규칙
• 현장이 오래 익힌 조작 절차

이 부분은 다른 시스템으로 옮길 때 「코드 이식」만으로 끝나지 않습니다. 겉모습, 조작, 예외, 운영이 한 덩어리라서, VBA 자산은 겉보기보다 많은 사양을 안고 있습니다.

flowchart TB
    accTitle: VBA 자산이 안고 있는 것
    accDescr: Excel이나 Access에는 보고서 겉모습·인쇄 설정·입력 검사·처리 순서·예외 규칙·조작 절차 같은 업무 절차 자체가 들어가기 쉽고, 겉모습·조작·예외·운영이 한 덩어리라서 코드 이식만으로는 이전이 끝나지 않음을 나타내는 그림.
    e1["Excel / Access 자산"] --> e2["업무 절차 자체가 들어가 있다"]
    e2 --> f1["보고서 겉모습·인쇄 설정"]
    e2 --> f2["입력 검사·처리 순서"]
    e2 --> f3["예외 규칙·조작 절차"]
    f2 --> g1["코드 이식만으로는 끝나지 않는다"]

그림5: VBA 자산은 코드만이 아니라 업무 절차와 운영을 통째로 안고 있습니다.

또한 VBA는 Office 오브젝트 모델에 가깝기 때문에, 사용자 눈앞의 Excel 자체를 조작해 결과를 돌려주는 용도에서는 손이 덜 갑니다. 이 가까움은 후속 후보를 생각할 때도 중요하며, 단순히 새 기술로 다시 쓰면 끝은 아닙니다.

실무에서는 이렇게 생각하는 것이 자연스럽습니다.

• Excel이 UI로 남는다면 VBA를 일부 남길 가치가 있습니다
• Excel은 입출력만으로 충분하다면 안의 로직은 밖으로 빼기 쉽습니다
• Excel 자체가 더 이상 본래 UI가 아니라면 다시 만들 후보가 됩니다

flowchart TB
    accTitle: Excel의 UI로서의 위치로 생각한다
    accDescr: Excel이 UI로 남는다면 VBA를 일부 남길 가치가 있고, Excel은 입출력만으로 충분하다면 안의 로직은 밖으로 빼기 쉬우며, Excel 자체가 더 이상 본래 UI가 아니라면 다시 만들 후보가 된다는 실무적 생각을 나타내는 그림.
    q1{"Excel은 어떤 위치인가"}
    q1 -->|"UI로 남는다"| r1["VBA를 일부 남길 가치"]
    q1 -->|"입출력만으로 충분하다"| r2["로직은 밖으로 빼기 쉽다"]
    q1 -->|"더 이상 본래 UI가 아니다"| r3["다시 만들 후보"]

그림6: Excel이 UI인지에 따라 남김·밖으로 뺌·다시 만들기의 방향이 갈립니다.

4. VBA의 주요 제약

4.1 데스크톱이 전제이다

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

Microsoft 공식 정보에서도 Excel for the web에서는 VBA를 작성·실행·편집할 수 없고, 매크로가 있는 통합 문서를 열어 편집은 할 수 있어도 VBA 실행은 할 수 없다고 되어 있습니다.²⁸

이 시점에서 이런 요건과는 궁합이 나빠집니다.

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

Microsoft 스스로도 여러 플랫폼용 확장을 만들고 싶다면 Office Add-ins를 보라고 VBA 문서 쪽에서 안내합니다.⁹⁵

flowchart TB
    accTitle: 데스크톱 전제라는 제약
    accDescr: VBA는 데스크톱판 Office 안에서 동작하는 기술이고 Excel for the web에서는 작성·실행·편집이 불가능하므로 브라우저 완결이나 플랫폼을 가로지르는 요건과는 궁합이 나쁘며, 여러 플랫폼용 확장은 Office Add-ins가 안내된다는 점을 나타내는 그림.
    h1["VBA"] --> h2["데스크톱판 Office 안에서 동작한다"]
    h2 --> h3["Excel for the web에서는 작성·실행·편집이 불가"]
    h3 --> h4["브라우저 완결이나 중앙 배포 요건과 궁합이 나쁘다"]
    h4 -.-> h5["여러 플랫폼이라면 Office Add-ins를 본다"]

그림7: 가장 큰 제약은 데스크톱이 전제라는 점입니다.

4.2 보안과 배포 마찰이 크다

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

Microsoft는 인터넷에서 온 파일에 들어 있는 VBA 매크로를 기본으로 차단합니다. 메일 첨부나 내려받은 .xlsm을 그대로 열어도, 예전처럼 순순히 실행되지 않습니다.³

보안으로서는 올바른 방향입니다. 다만 운영 쪽에서 보면

• 첨부해서 배포하면 동작하지 않는다
• 사외 사이트에서 받은 템플릿이 동작하지 않는다
• OneDrive / SharePoint / 네트워크를 거친 취급이 알기 어렵다
• 「사용하도록 설정하세요」라는 안내가 운영의 약점이 된다

는 마찰이 늘어납니다.

flowchart TB
    accTitle: 기본 매크로 차단이 만드는 마찰
    accDescr: 인터넷에서 온 파일에 들어 있는 VBA 매크로는 기본으로 차단되므로 메일 첨부나 내려받은 파일이 예전처럼 실행되지 않고, 배포와 운영의 마찰이 늘어남을 나타내는 그림.
    m1["인터넷에서 온 파일"] --> m2["VBA 매크로는 기본으로 차단"]
    m2 --> m3["첨부나 다운로드에서는 순순히 동작하지 않는다"]
    m3 --> m4["배포와 운영의 마찰이 늘어난다"]
    m2 -.-> m5["보안으로서는 올바른 방향"]

그림8: 「쓸 수 없게 됐다」는 오해의 큰 부분은 기본 매크로 차단입니다.

다만 「동작하지 않으니 끝」은 아닙니다. Microsoft는 같은 문서에서 신뢰하는 파일의 매크로를 동작시키기 위한 수단도 정리합니다. 운영에서 자주 쓰는 것은 다음 4가지입니다.³

동시에 주의점도 분명합니다.³

• 신뢰할 수 있는 위치와 신뢰할 수 있는 사이트는 그곳에 둔 것을 통째로 신뢰합니다. 「누가 쓸 수 있는지」를 관리할 수 있는 장소로 한정해야 합니다.
• 신뢰할 수 있는 게시자는 Windows 전체 설정이며, Office만의 이야기가 아닙니다.
• Excel 추가 기능(.xla / .xlam)은 Mark of the Web이 붙어 있으면 서명하고 게시자를 신뢰해도 동작하지 않습니다. 이 경우는 Mark of the Web을 제거하거나 신뢰할 수 있는 위치에 두거나 둘 중 하나입니다.
• 네트워크 공유를 IP 주소로 열고 있으면, 그것만으로 신뢰할 수 있는 사이트에도 로컬 인트라넷에도 해당하지 않아 차단되는 경우가 있습니다.

바꿔 말하면 VBA를 남기기로 했다면, 코드 이야기와 별도로 「어디에 두고, 어떻게 신뢰시킬지」를 배포 설계로 정해야 합니다. 여기를 정하지 않은 채 .xlsm을 메일 첨부로 계속 배포하는 운영이 마찰이 가장 큰 형태입니다.

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

flowchart TB
    accTitle: VBA를 남긴다면 배포 설계까지 정한다
    accDescr: VBA를 남기기로 했다면 코드 이야기와 별도로 어디에 두고 어떻게 신뢰시킬지를 배포 설계로 정해야 하며, 정하지 않은 채 .xlsm을 메일 첨부로 계속 배포하는 운영이 마찰이 가장 큰 형태임을 나타내는 그림.
    p1["VBA를 남기는 판단"] --> p2["코드 이야기"]
    p1 --> p3["배포 설계 이야기"]
    p3 --> p4["어디에 둘지"]
    p3 --> p5["어떻게 신뢰시킬지"]
    p4 -.-> p6["정하지 않고 .xlsm을 첨부 배포 =마찰이 가장 크다"]

그림9: 남기기로 했다면 코드와 별도로 「두는 곳과 신뢰시키는 방법」을 설계합니다.

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와 외부 의존을 정리하는 일이 되는 경우가 꽤 많습니다.

flowchart TB
    accTitle: 32bit / 64bit의 벽
    accDescr: Office 2019와 Microsoft 365에서는 64bit가 기본이므로 Windows API를 Declare로 호출하는 오래된 코드는 PtrSafe나 LongPtr로 대응이 필요하고, 오래된 COM이나 ActiveX, 32bit 전제 외부 DLL, 참조 설정 어긋남도 함께 문제가 되므로 이전은 언어를 다시 쓰는 일보다 외부 의존 정리가 됨을 나타내는 그림.
    b1["Office 2019 / M365는 64bit가 기본"] --> b2["오래된 Declare 호출이 그대로 동작하지 않는 경우가 있다"]
    b2 --> b3["PtrSafe나 LongPtr로 차이를 흡수한다"]
    b2 -.-> b4["COM / ActiveX / OCX나 32bit 전제 DLL도 함께 문제화"]
    b4 --> b5["이전의 실체는 bitness와 외부 의존 정리"]

그림10: 64bit 이전에서는 코드보다 외부 의존이 먼저 문제가 되기 쉽습니다.

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

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

그래서 이런 구성은 위험한 쪽에 가깝습니다.

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

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

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

flowchart TB
    accTitle: 무인 실행·서버 실행에 맞지 않는 이유
    accDescr: Office는 대화형 데스크톱과 사용자 프로필을 전제로 설계되어 서버 측 자동화는 권장·지원되지 않고, 무인 환경에서는 불안정이나 deadlock이 날 수 있으므로 의심할 것은 VBA가 아니라 Excel 앱 자체를 운전하는 구성임을 나타내는 그림.
    u1["서비스나 배치에서 Excel을 기동하는 구성"] --> u2["Office는 대화형 데스크톱 전제의 설계"]
    u2 --> u3["무인 환경에서는 불안정이나 deadlock이 날 수 있다"]
    u3 --> u4["서버 측 자동화는 권장·지원 밖"]
    u4 -.-> u5["의심할 것은 VBA가 아니라 Excel을 운전하는 구성"]

그림11: 「가끔 동작한다」와 「지탱할 수 있는 구성」은 별개이며, 무인 실행에서는 구성 자체를 의심합니다.

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

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

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

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

flowchart TB
    accTitle: Office 파일 안에 로직을 두는 구조의 문제
    accDescr: VBA는 통합 문서나 Access 파일 안에 코드가 갇히기 쉬워 원본이 모호해지고 책임이 흩어지며 차이 확인이나 테스트가 어려운 문제가 생기고, 작은 자동화에서는 눈에 띄지 않아도 업무 시스템화가 되면 갑자기 문제가 됨을 나타내는 그림.
    k1["Office 파일 안에 코드가 갇힌다"] --> k2["원본이 모호·책임이 흩어진다"]
    k1 --> k3["차이 확인·테스트가 어렵다"]
    k2 --> k4["작은 자동화에서는 눈에 띄지 않는다"]
    k3 --> k4
    k4 --> k5["업무 시스템화가 되면 갑자기 문제가 된다"]

그림12: 언어가 아니라 「파일 안에 업무 로직을 두는」 구조가 문제를 만듭니다.

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에 기본으로 포함하는 형태로도 대응을 진행하고 있습니다.¹⁰

자기 자산이 영향을 받는지 여부는 다음 3가지를 찾으면 판단할 수 있습니다. VBE의 「편집」 메뉴에 있는 검색이든, .bas / .cls로 내보낸 텍스트에 대한 grep이든 상관없습니다.

참조 설정 목록은 VBE의 「도구」 메뉴의 「참조 설정」에서 확인할 수 있습니다.

이 가운데 RegExp는 앞에서 말한 대로 Microsoft 365 Version 2508(Build 19127.20154) 이후 Windows판 Office에서는 RegExp 클래스가 VBA 쪽에 기본으로 포함되는 형태로 조치가 진행되고 있습니다.¹⁰ 영향이 무거운 것은 3행의 「외부 .vbs를 실행하는」 패턴이며, 이쪽은 처리 자체를 VBA 쪽이나 다른 실행 기반으로 모으는 검토가 필요합니다. 자산 목록을 만들 때(8.1) 이 3가지도 함께 기록해 두면 두 번 일이 되지 않습니다.

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

flowchart TB
    accTitle: VBScript 폐지와 VBA의 관계
    accDescr: Windows의 VBScript 단계적 폐지는 외부 .vbs를 실행하는 경우나 VBScript.RegExp 참조에 의존하는 경우에 영향을 줄 수 있는 것이며, RegExp는 새 Office에서 VBA에 기본으로 포함되는 형태의 조치가 진행 중이고, VBA 전체 종료와 같은 이야기가 아님을 나타내는 그림.
    w1["VBScript의 단계적 폐지"] --> w2["외부 .vbs 실행에 의존"]
    w1 --> w3["VBScript.RegExp에 의존"]
    w2 --> w4["다른 실행 기반으로 모으는 검토"]
    w3 -.-> w5["새 Office는 VBA에 기본으로 포함"]
    w1 -.-> w6["VBA 전체 종료와는 다른 이야기"]

그림13: 영향을 받는 것은 VBScript에 매달린 의존뿐이며, VBA 본체 폐지가 아닙니다.

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

먼저 「내일부터 전부 쓸 수 없게 된다」는 이야기가 아닙니다. 다만 「어디서든 무엇에든 쓸 수 있는」 시대도 아닙니다.

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

• 데스크톱 Office 확장으로서의 VBA는 계속 존재합니다¹
• Web / 크로스 플랫폼 쪽은 Office Scripts나 Office Add-ins를 나눠 씁니다⁴⁵⁹
• 매크로 배포의 안전성은 예전보다 엄격히 다룹니다³
• VBScript 의존 같은 주변 부품은 장래 영향을 받을 수 있습니다¹⁰

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

이 둘을 나란히 두면 꽤 실무적인 그림이 됩니다.

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

VBA의 앞날은 소멸보다 경계의 명확화로 보는 것이 자연스럽습니다.

flowchart TB
    accTitle: 소멸이 아니라 경계의 명확화
    accDescr: 데스크톱 Excel의 깊은 조작에서는 아직 VBA의 적용 범위가 넓고, 브라우저나 M365나 공유 워크플로에서는 Office Scripts나 Add-ins가 더 자연스러우며, 전부를 한쪽으로 몰지 않고 경계가 분명해지는 변화임을 나타내는 그림.
    z1{"어디서 쓰는가"}
    z1 -->|"데스크톱 Excel의 깊은 조작"| z2["아직 VBA의 적용 범위가 넓다"]
    z1 -->|"브라우저 / M365 / 공유 워크플로"| z3["Office Scripts나 Add-ins가 자연스럽다"]
    z2 --> z4["경계의 명확화"]
    z3 --> z4

그림14: 「전부 Office Scripts로」도 「VBA를 영원히 중심으로」도 아니며, 경계가 정해져 갑니다.

6. 교체가 필요한 경우 / 교체하지 않아도 되는 경우

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

표 2행의 하이브리드화는 이 글에서 「Excel / Access를 UI와 보고서 입구로 남긴 채, 업무 로직이나 I/O만 밖의 실행 단위로 빼낸다」는 뜻으로 씁니다. 전면 교체와의 차이는 사용자에게 보이는 화면과 조작을 바꾸지 않는 것입니다. 구체적인 형태는 7.1에서 다룹니다.

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

flowchart TB
    accTitle: 교체 판단의 축
    accDescr: 교체 판단 축은 「VBA는 오래되어서」가 아니라 실행 환경·운영·배포·의존·감사·확장성이라는 요소를 봐야 하며, 하이브리드화에서는 사용자에게 보이는 화면과 조작을 바꾸지 않고 로직과 I/O만 밖으로 빼낸다는 점을 나타내는 그림.
    j0["VBA는 오래되어서"] -.-> j1["판단 축으로 쓰지 않는다"]
    j2["정말 봐야 할 축"] --> j3["실행 환경·운영·배포"]
    j2 --> j4["의존·감사·확장성"]
    j3 --> j5["남김 / 하이브리드화 / 밖으로 냄을 고른다"]
    j4 --> j5

그림15: 판단 축은 낡음이 아니라 실행 환경·운영·배포·의존·감사·확장성입니다.

7. 현실적인 교체 대상

구체적인 이야기에 들어가기 전에 후보를 한 장에 나란히 둡니다. 6장의 판단표에서 「어느 쪽으로 모을지」를 정한 뒤, 이 표에서 「그 앞이 무엇을 요구하는지」를 확인하는 순서로 쓰십시오.

가장 놓치기 쉬운 것은 「전제·라이선스」 열입니다. 특히 Office Scripts는 조건이 분명하므로 7.3에서 따로 정리합니다.

7.1 Excel을 남기고 안쪽만 .NET이나 별도 프로세스로 뺀다

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

• 화면이나 보고서 입구는 Excel / Access 그대로
• 버튼이나 입력 폼도 당분간 그대로
• 다만 업무 로직, HTTP, 암호, CSV / JSON, 무거운 계산, 파일 처리는 밖으로 뺀다
• VBA는 「중개」와 「UI 조작」만으로 모은다

이 구성의 이점은 사용자의 겉모습과 조작을 깨뜨리기 어렵다는 점입니다. 전면 교체보다 먼저 책임을 얇게 하는 방향으로 진행할 수 있습니다.

flowchart TB
    accTitle: Excel을 남기고 안쪽만 밖으로 빼는 하이브리드 구성
    accDescr: 화면이나 보고서 입구는 Excel이나 Access 그대로 남기고, 업무 로직이나 HTTP·암호·무거운 계산·파일 처리는 .NET이나 별도 프로세스로 빼며, VBA는 중개와 UI 조작만으로 모아 사용자의 겉모습과 조작을 깨뜨리지 않고 책임을 얇게 할 수 있음을 나타내는 그림.
    x1["화면·보고서 입구는 Excel / Access 그대로"] --> x2["VBA는 중개와 UI 조작만으로 모은다"]
    x2 --> x3["무거운 로직이나 I/O는 .NET이나 별도 프로세스로"]
    x3 -.-> x4["사용자의 겉모습과 조작을 깨뜨리지 않는다"]

그림16: 가장 실패하기 어려운 것은 입구를 남기고 안쪽만 밖으로 빼는 형태입니다.

관련 기사:

• .NET 8 DLL을 VBA에서 형 지정으로 쓰는 방법 - COM 공개와 dscom TLB

「전부 다시 쓰기 전에, 먼저 무거운 곳만 빼낸다」는 꽤 실무적입니다.

7.2 무인 실행이나 보고서 생성은 Office 앱 자동화가 아니라 파일 직접 생성으로 모은다

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

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

즉 요건이

• .xlsx를 만들고 싶다
• 정형 보고서를 대량으로 내고 싶다
• PDF로 만들고 싶다
• 야간 배치로 돌리고 싶다

같은 것이라면, 고를 축은 Excel을 운전할지가 아니라 Excel 파일을 조립할지입니다.

flowchart TB
    accTitle: 무인 보고서 생성은 파일 직접 생성으로
    accDescr: 보고서를 야간 배치나 서비스에서 대량 생성하고 싶을 때 먼저 의심할 것은 Excel 앱을 기동하고 있다는 것 자체이며, 서버 쪽 Office Automation은 권장되지 않고 Open XML 형식 등으로 Office 파일을 직접 조립하는 방법이 권장됨을 나타내는 그림.
    y1["보고서를 무인으로 대량 생성하고 싶다"] --> y2{"어느 축으로 생각하는가"}
    y2 -.->|"비권장"| y3["Excel 앱을 운전한다"]
    y2 -->|"권장되는 방향"| y4["Open XML 등으로 파일을 직접 조립한다"]

그림17: 무인 실행 요건에서는 「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는 「무료로 따라오는 VBA의 대체」가 아닙니다. 로컬 .xlsm을 돌려 배포하던 운영과 비교하면 OneDrive / SharePoint와 M365 라이선스라는 전제가 늘어납니다. 여기를 놓친 채 「Office Scripts로 이전」을 정하면, 이전 도중에 라이선스 조달 이야기로 돌아가게 됩니다.

flowchart TB
    accTitle: Office Scripts 이전에서 먼저 확인할 전제
    accDescr: Office Scripts는 무료로 따라오는 VBA의 대체가 아니며, 로컬 .xlsm을 돌려 배포하던 운영과 비교하면 OneDrive나 SharePoint와 M365 라이선스라는 전제가 늘어나므로, 놓친 채 이전을 정하면 도중에 라이선스 조달 이야기로 돌아감을 나타내는 그림.
    o1["로컬 .xlsm을 돌려 배포하는 운영"] --> o2["Office Scripts로 이전을 검토"]
    o2 --> o3["OneDrive / SharePoint와 M365 라이선스 전제가 늘어난다"]
    o3 -->|"먼저 확인한다"| o4["이전 계획에 전제를 넣는다"]
    o3 -.->|"놓치면"| o5["도중에 라이선스 조달 이야기로 돌아간다"]

그림18: Office Scripts는 「무료 VBA 대체」가 아니며, 전제 조건 확인이 먼저입니다.

그 위에서 기능면도 만능이 아닙니다.

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

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

flowchart TB
    accTitle: Office Scripts가 실행되는 방식
    accDescr: Office Scripts는 Excel 수준의 이벤트를 지원하지 않고, 실행은 수동 시작이나 Power Automate에서의 호출이 기본이며, 호출 횟수나 동기 처리 시간 제한도 있으므로 VBA의 대체물이라기보다 M365 위의 자동화 부품으로 보는 것이 정확함을 나타내는 그림.
    a1["Office Scripts"] --> a2["수동으로 시작한다"]
    a1 --> a3["Power Automate에서 호출한다"]
    a1 -.-> a4["Excel 수준의 이벤트는 지원하지 않는다"]
    a2 --> a5["M365 위의 자동화 부품으로 본다"]
    a3 --> a5

그림19: 이벤트 기반 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 안에 코드를 쓰는 감각과는 꽤 달라집니다. 그 대신 운영과 배포는 정리하기 쉬워집니다.

flowchart TB
    accTitle: Office Add-ins가 맞는 형태
    accDescr: Office Add-ins는 HTML·CSS·JavaScript로 구축할 수 있고 Windows·Mac·iPad·브라우저를 가로질러 동작하며 중앙 배포에도 맞으므로, PC마다 매크로 배포나 로컬 .xlsm 배포 모델에서 벗어나고 싶은 요건에 맞음을 나타내는 그림.
    d1["HTML / CSS / JavaScript로 구축한다"] --> d2["Windows / Mac / iPad / 브라우저에서 동작한다"]
    d2 --> d3["관리자에 의한 중앙 배포"]
    d3 --> d4["로컬 .xlsm 배포 모델에서 벗어난다"]

그림20: 크로스 플랫폼과 중앙 배포가 요건이라면 Add-ins의 무대가 됩니다.

7.5 Excel / Access 자체가 더 이상 본래 UI가 아니라면 Windows 앱이나 Web 앱으로 뺀다

이런 상태까지 왔다면 VBA를 연명하기보다 앱으로 다시 만드는 편이 자연스럽습니다.

• 화면 전환이나 권한 제어가 너무 늘었다
• DB, 감사 로그, 승인 흐름, 사용자 관리가 중심이다
• 외부 기기 연동이나 장시간 처리가 있다
• Excel 셀이나 폼이 업무 사양서 대신이 되어 버렸다
• 통합 문서를 닫으면 상태 관리가 사라진다는 것 자체가 힘들다

이 경우 Windows 전제 업무 도구라면 C# / .NET 데스크톱 앱, 사용자나 단말이 넓다면 Web 앱이 구조를 더 곧게 만들 수 있습니다.

8. 단계적 이전의 진행 방식

VBA 교체에서 가장 위험한 것은 처음부터 전부를 하나의 새 기술로 모으려 하는 것입니다. 실무에서는 지금부터 쓰는 순서로 단계를 밟는 편이 대체로 안전합니다.

8.1 먼저 자산 목록을 만든다

처음에 파악해야 할 것은 코드 양 자체보다 의존 관계입니다.

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

여기를 모호한 채 교체하면, 나중에 「아무도 안 만진 줄 알았던 매크로가 월말에만 살아 있었다」 같은 사고가 납니다.

flowchart TB
    accTitle: 자산 목록에서 파악하는 것
    accDescr: 단계적 이전의 처음에 할 일은 코드 양보다 의존 관계 파악이며, 어느 파일이 실운영 입구인지, 참조 설정이나 외부 DLL이나 bitness 전제는 어떤지, 어느 매크로가 누가 어떤 절차로 쓰이며 무엇을 출력하는지를 목록으로 만들고, 모호한 채면 월말에만 살아 있던 매크로 같은 사고가 난다는 점을 나타내는 그림.
    r1["파일 파악"] --> r2["의존 파악 (참조 설정·DLL·bitness)"]
    r2 --> r3["쓰임새 파악 (누가·어떤 절차로·출력은)"]
    r3 -.-> r4["모호한 채면 월말에만 살아 있던 매크로 사고"]

그림21: 목록에서 볼 것은 코드 양이 아니라 의존 관계와 쓰임새입니다.

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 자산 안은 대체로 여러 책임이 섞여 있습니다.

flowchart TB
    accTitle: 책임마다 이전 대상을 정한다
    accDescr: 코드를 파일 단위가 아니라 책임 단위로 나누면 남길 것·얇게 할 것·밖으로 낼 것이 보이기 쉬워지고, UI와 시트 조작은 당분간 VBA에 남기며, 업무 로직은 .NET으로, 무인 보고서 생성은 Open XML로, M365 워크플로는 Office Scripts로 책임마다 이전 대상을 정할 수 있음을 나타내는 그림.
    m1["코드를 책임 단위로 나눈다"] --> m2["남김 / 얇게 함 / 밖으로 냄이 보인다"]
    m2 --> n1["UI·시트 조작은 당분간 VBA에 남긴다"]
    m2 --> n2["업무 로직은 .NET이나 별도 프로세스로"]
    n1 --> n3["무인 보고서 생성은 Open XML로"]
    n2 --> n4["M365 워크플로는 Office Scripts로"]

그림22: 파일 단위가 아니라 책임 단위로 나누면 이전 대상은 자연히 여러 개가 됩니다.

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

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

• 입력은 무엇인가
• 출력은 무엇인가
• 오류 시 어떻게 돌려주는가
• 어느 시트, 어느 이름 있는 범위, 어느 파일 경로를 계약으로 하는가
• 어느 시점에 결과가 확정되었다고 볼 것인가

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

8.5 병행 가동으로 비교한다

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

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

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

flowchart TB
    accTitle: 병행 가동으로 비교한 뒤 전환한다
    accDescr: 보고서나 집계는 바로 전환하지 않고 기존 VBA판과 새 구현판을 병행으로 내며, 출력된 파일의 날짜·반올림·서식·인쇄 범위 차이를 확인하고, 예외 경우나 빈 데이터 경우도 시험한 뒤 전환해 숫자나 서식이 조용히 어긋나는 사고를 막는다는 점을 나타내는 그림.
    h1["기존 VBA판과 새 구현판을 병행으로 낸다"] --> h2["출력을 비교한다 (날짜·반올림·서식·인쇄 범위)"]
    h2 --> h3["예외 경우·빈 데이터 경우도 시험한다"]
    h3 --> h4["차이가 없음을 확인하고 전환한다"]
    h2 -.-> h5["사고는 숫자나 서식이 조용히 어긋나는 형태로 난다"]

그림23: 바로 전환하지 않고, 기존과 새 출력을 병행해 비교한 뒤 옮깁니다.

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 폼에는 코드에 쓰이지 않은 운영 규칙이 꽤 묻혀 있습니다.

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

flowchart TB
    accTitle: 동시에 전부 바꾸면 일어나는 일
    accDescr: VBA 교체에서 정말 두려운 것은 코드 변환보다 업무 사양을 빠뜨리는 것이며, Excel 시트나 Access 폼에는 코드에 쓰이지 않은 운영 규칙이 묻혀 있어 화면·보고서·업무 규칙을 동시에 전부 바꾸면 겉모습은 가까운데 월말만 다른 사고가 나기 쉽다는 점을 나타내는 그림.
    g1["화면·보고서·업무 규칙을 동시에 전부 바꾼다"] --> g2["코드에 쓰이지 않은 운영 규칙을 빠뜨린다"]
    g2 --> g3["겉모습은 가까운데 월말만 다른 사고"]
    g2 -.-> g4["두려운 것은 코드 변환보다 업무 사양을 빠뜨리는 것"]

그림24: 한 번에 전부를 바꾸면, 코드 밖에 있는 업무 사양을 빠뜨리기 쉽습니다.

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 앱으로 뺍니다

답은 「전부 교체한다」도 「아무것도 바꾸지 않는다」도 아니라, 「책임마다 나눠 단계적으로 얇게 한다」입니다.

flowchart TB
    accTitle: 교체의 답
    accDescr: VBA에 대한 답은 전부 교체하는 것도 아무것도 바꾸지 않는 것도 아니라 책임마다 나눠 단계적으로 얇게 하는 것이며, 교체는 번역이 아니라 정리로서 진행하는 것이 안전함을 나타내는 그림.
    q0{"VBA 자산을 어떻게 할 것인가"}
    q0 -.->|"극단"| e1["전부 교체한다"]
    q0 -.->|"극단"| e2["아무것도 바꾸지 않는다"]
    q0 -->|"실무적인 답"| e3["책임마다 나눠 단계적으로 얇게 한다"]
    e3 --> e4["번역이 아니라 정리로서 진행한다"]

그림25: 답은 양쪽 극단이 아니라, 책임마다 나눠 단계적으로 얇게 하는 것입니다.

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

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

11. 관련 기사

• COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 정리해 해설
• .NET 8 DLL을 VBA에서 형 지정으로 쓰는 방법 - COM 공개와 dscom TLB
• Excel 보고서 출력 만드는 법 - COM/Open XML/템플릿

12. 참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

VBA는 앞으로 쓸 수 없게 되나요?

적어도 2026년 3월 시점에서 Microsoft 공식 정보로 「VBA 자체를 가까운 시일 내에 종료한다」는 명확한 안내는 확인되지 않습니다. 지금 일어나는 일은 갑작스러운 전면 폐지가 아니라, 쓸 수 있는 장소와 전제 조건이 분명해진 변화입니다. 구체적으로 Excel for the web에서는 VBA를 작성·실행·편집할 수 없고, 인터넷에서 온 파일의 매크로는 기본으로 차단됩니다. VBA의 앞날은 소멸보다 경계가 분명해지는 일로 보는 것이 자연스럽습니다.

VBA를 전부 Office Scripts로 옮기면 되나요?

권하지 않습니다. Microsoft 스스로, 데스크톱 클라이언트에서 쓸 수 있는 Excel 기능의 커버 범위는 현시점에서는 VBA 쪽이 넓다고 설명하며, Office Scripts는 Excel 수준의 이벤트를 지원하지 않습니다. Office Scripts는 VBA의 대체물이라기보다, OneDrive나 SharePoint 위의 통합 문서를 Power Automate와 조합해 돌리는 M365 위의 자동화 부품으로 보는 편이 정확합니다. 이전 대상은 책임 영역마다 나눠 고르는 것이 현실적입니다.

서버나 야간 배치에서 Excel 매크로를 무인 실행해도 되나요?

위험합니다. Microsoft는 Office 애플리케이션의 서버 측 자동화를 권장·지원하지 않는다고 분명히 말하고 있습니다. Office는 대화형 데스크톱과 사용자 프로필을 전제로 설계되어 있어, 무인 환경에서는 불안정이나 deadlock이 날 수 있습니다. 대량 보고서 생성이 요건이라면 Excel 앱을 기동하는 것이 아니라, Open XML 형식 등으로 Excel 파일을 직접 조립하는 방법이 권장됩니다.

기존 VBA 자산은 어떻게 이전하면 되나요?

처음부터 전부를 하나의 새 기술로 몰지 말고, 단계적 이전이 안전합니다. 먼저 .xlsm이나 참조 설정·외부 DLL·32bit/64bit 전제 같은 자산 목록을 만들고, 코드를 UI 조작·업무 로직·보고서·I/O 같은 책임으로 나눕니다. 그다음 UI와 시트 조작은 당분간 VBA에 남기고, 업무 로직은 .NET DLL이나 별도 프로세스로, 무인 보고서 생성은 Open XML로, M365 워크플로는 Office Scripts로 책임마다 이전 대상을 정합니다. 보고서나 집계는 병행 가동으로 기존과 새 출력을 비교한 뒤 전환합니다.

저자 프로필

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

Go Komura

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

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