VBScript 폐지에 대비하는 VBA·사내 도구 점검 가이드

경영진 요약

이 글에서 말하는 「사내 도구」는 Excel 매크로나 .vbs 파일만이 아닙니다. GPO 로그온 스크립트, Task Scheduler에 등록한 작업, Intune으로 배포 중인 스크립트, MSI의 VBScript Custom Action까지 포함합니다. 직접 VBScript를 작성한 기억이 없어도, 이 가운데 어디에든 .vbs가 들어 있으면 대상입니다.

2026년 4월 시점 기준으로 Microsoft는 VBScript를 단계적으로 폐지하는 방침을 공개했으며, Windows 11 버전 24H2에서는 먼저 Feature on Demand로 기본 사용(켜짐), 다음 단계에서는 기본 사용 안 함, 최종 단계에서는 이후 Windows 릴리스에서 삭제할 계획을 제시합니다. 지금 실제로 해야 할 일은 「전부 다시 쓰기」보다 앞서 「어디에 VBScript 의존이 있는지를 드러내는 일」입니다.

시기에 대해서는 확정일이 공개되어 있지 않습니다. Microsoft의 VBA 안내에서는 Phase 2(FOD를 기본 사용 안 함)를 「2026〜2027년경」, Phase 3(삭제)를 「TBD(미정)」으로 적습니다. 따라서 이 건은 「언제까지 끝낼지」를 날짜부터 역산할 수 없습니다. Windows 11 24H2 이후 PC가 늘어날수록 기한이 다가온다는 전제로, 인벤토리만이라도 먼저 마쳐 두어야 합니다.

VBA·Excel 매크로의 현실적인 논점은 크게 두 가지입니다. 하나는 .vbs를 외부에서 실행하는 경우이고, 다른 하나는 VBScript.RegExp 같은 VBScript형 라이브러리 참조입니다. 후자에 대해서는 Office version 2508(Build 19127.20154) 이후 RegExp 클래스가 VBE에 기본 포함되어, 적어도 RegExp 의존의 일부는 이전하기 쉬워졌습니다. 한편 구버전 Office 클라이언트가 남은 혼합 환경에서는, 같은 VBA라도 동작하는 PC와 동작하지 않는 PC가 나오기 쉽습니다.

이전을 어렵게 만드는 것은 VBScript 자체보다 「주변 운용」입니다. 예를 들어 Excel에서 powershell.exe를 실행하도록 바꿔도, 공격 표면 감소 규칙인 「Office 앱에 의한 자식 프로세스 생성 차단」이나 「Office 매크로의 Win32 API 호출 차단」, AppLocker, App Control for Business, PowerShell 실행 정책, 서명 운용, MOTW가 붙은 파일의 매크로 제어에 걸리면 운영 환경에서는 동작하지 않습니다. 이전 계획은 코드 변환만이 아니라 정책과 서명, 로그 감사까지 포함해 설계해야 합니다.

가장 짧은 경로는 인벤토리 → 정적 검출 → 실행 로그 수집 → 대체처 선정 → 테스트 → 단계적 배포입니다. 이 글에서는 그 순서로 실무에 맞게 정리합니다.

또한 이 글에 나오는 코드는 실행·테스트할 수 있는 샘플 세트(PowerShell 감사 스크립트, 치환 샘플, VBA·Office Scripts 참조용 코드, Pester 테스트)로 GitHub에 공개하고 있습니다.

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

이 글의 지식 맵

Microsoft는 VBScript를 Feature on Demand로서 기본 사용에서 기본 사용 안 함으로, 장래 삭제까지 단계적으로 폐지하는 방침을 제시하고 있으며, VBA에서의 외부 .vbs 실행이나 VBScript 계열 라이브러리 참조, GPO 로그온 스크립트·작업 스케줄러·Intune 배포 스크립트·MSI의 Custom Action이 그 영향을 받습니다. 대체 기술은 OS·파일·작업을 다루는 처리라면 PowerShell, Excel 통합 문서 안에서 끝나는 처리라면 VBA 네이티브나 Office Scripts, 복잡한 업무 로직이라면 .NET/VSTO, 플로가 기점이라면 Power Automate처럼 역할에 따라 골라 씁니다. 다만 대체한 뒤의 PowerShell이나 매크로는 공격 표면 감소 규칙(ASR)이나 AppLocker, App Control for Business 정책에 따라 차단될 수 있으므로, Sysmon이나 AppLocker 이벤트 로그에서의 감사 로그 수집, 실행 정책과 Authenticode 서명 운용까지 포함해 이전을 설계해야 합니다.

flowchart LR
    accTitle: VBScript 폐지와 VBA·사내 도구 이전의 지식 맵
    accDescr: VBScript의 단계적 폐지가 VBA·GPO·작업 스케줄러·Intune·MSI에 어떤 영향을 주고, PowerShell이나 Office Scripts 등 대체 기술이 AppLocker나 ASR 같은 보안 기능과 어떻게 관련되는지를 보여주는 그림
    vbscript["VBScript"]
    vba["VBA(Visual Basic for Applications)"]
    powershell["PowerShell"]
    feature_on_demand["Feature on Demand(FOD)"]
    group_policy["그룹 정책"]
    task_scheduler["작업 스케줄러의 무인 실행"]
    intune["Microsoft Intune"]
    msi_custom_action["MSI Custom Action"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    attack_surface_reduction_rules["공격 표면 감소 규칙(ASR)"]
    powershell_execution_policy["PowerShell 실행 정책"]
    authenticode_signing["Authenticode 서명(PowerShell 스크립트)"]
    applocker_log["AppLocker 이벤트 로그"]
    app_control_for_business["App Control for Business(구 WDAC)"]
    audit_mode["감사 모드"]
    applocker["AppLocker"]
    sysmon["Sysmon"]
    office_scripts["Office 스크립트(Office Scripts)"]
    vsto["VSTO(Visual Studio Tools for Office)"]
    power_automate["Power Automate"]
    powershell -->|"의 후속"| vbscript
    vba -.->|"이용한다"| vbscript
    vbscript -->|"전제로 한다"| feature_on_demand
    group_policy -.->|"전제로 한다"| vbscript
    task_scheduler -.->|"전제로 한다"| vbscript
    intune -.->|"전제로 한다"| vbscript
    msi_custom_action -.->|"전제로 한다"| vbscript
    vba -.->|"양립하지 않는다"| zone_identifier
    vba -.->|"이용한다"| powershell
    powershell -.->|"양립하지 않는다"| attack_surface_reduction_rules
    vba -.->|"양립하지 않는다"| attack_surface_reduction_rules
    powershell -->|"전제로 한다"| powershell_execution_policy
    powershell_execution_policy -.->|"전제로 한다"| authenticode_signing
    powershell -->|"에서 구성할 수 있다"| authenticode_signing
    powershell -.->|"에서 확인할 수 있다"| applocker_log
    app_control_for_business -.->|"에서 구성할 수 있다"| audit_mode
    applocker -.->|"에서 구성할 수 있다"| audit_mode
    vbscript -.->|"에서 확인할 수 있다"| sysmon
    office_scripts -.->|"권장되는 대응"| vbscript
    vba -->|"권장되는 대응"| vbscript
    powershell -->|"권장되는 대응"| vbscript
    vsto -.->|"권장되는 대응"| vbscript
    power_automate -.->|"권장되는 대응"| vbscript
    powershell -.->|"양립하지 않는다"| applocker
    vba -.->|"양립하지 않는다"| app_control_for_business

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

용어 미니 사전

이후 장에서는 Windows 보안 기능의 약어가 이어서 나옵니다. 먼저 여기만 잡아 두면 읽기 쉬워집니다.

변화 정리

먼저 잡아야 할 점은, 이번 논점이 「VBA가 폐지된다」는 이야기가 아니라는 것입니다. Microsoft가 공개한 것은 VBScript의 단계적 폐지이며, VBA 프로젝트에 대한 영향은 주로 외부 .vbs 실행과 VBScript 계열 라이브러리 참조에 모입니다. Microsoft 365 Developer Blog에서도 VBA에서의 .vbs 실행과 VBScript.RegExp 이용이 대표적인 영향 지점으로 정리되어 있습니다.

실무상의 우선순위는 다음 표 형태로 보면 판단하기 쉽습니다.

이 우선순위는 Windows 측 VBScript 폐지 계획, 공식 검출 전략, ASR/AppLocker/App Control 사양을 바탕으로 한 실무 판단입니다.

RegExp만은 사정이 조금 다릅니다. Office version 2508 이후에는 VBE 쪽에 RegExp 클래스가 기본 포함되므로, RegExp 용도에 한하면 「VBScript 의존의 일부를 Office 업데이트로 해소할 수 있게」 되었습니다. 다만 이것이 구버전 Office나 업데이트 채널이 느린 환경, 혼합 환경, 오래된 PC 이미지가 남은 조직에서 자동으로 해결되는 이야기는 아닙니다. 「Office 업데이트」와 「Windows의 단계 전환」 양쪽을 목록에 넣는 것이 중요합니다.

인벤토리 진행 방법

인벤토리는 파일 이름 검색만으로는 부족합니다. 최소한 다음 10가지 관점을 건별·도구별·업무별로 열(칼럼)로 갖추기를 권합니다.

• ① VBScript 의존 위치의 검출 방법 파일 검색, 코드 분석, 로그 분석을 나누어 기록한다.
• ② VBA 안의 CreateObject / GetObject / Execute / ExecuteGlobal 등 이용 의존처가 문자열에 숨으므로 정적 검색 누락이 나오기 쉽다.
• ③ Excel 매크로에서의 외부 스크립트 호출 WScript.Shell, Shell 함수, wscript.exe / cscript.exe, .vbs / .js / .ps1을 따로 가진다.
• ④ 사내 배치·도구의 스크립트 의존 Scheduled Task, GPO, Intune, 공유 폴더의 운용 스크립트, 설치 프로그램을 포함한다.
• ⑤ 보안·권한·서명·정책 AppLocker, App Control for Business, ASR, PowerShell 실행 정책, 디지털 서명, 관리자 권한 필요 여부.
• ⑥ 대체 기술과 이전 비용 비교 VBA 네이티브, PowerShell, .NET/VSTO, Office Scripts, Power Automate로 비교한다.
• ⑦ 테스트 계획 단위, 통합, 사용자 인수, 정책 적용 후 재시험을 나눈다.
• ⑧ 운용 절차와 롤백 무엇을 되돌리면 복구되는지, 어디까지 자동화할지를 명시한다.
• ⑨ 호환성과 성능 Office 버전 차이, 32/64bit, PC 성능, 로그 수집 부하, 클라우드 흐름의 타임아웃.
• ⑩ 샘플 이전 사례 연구 현장에 설명하는 데 쓸 대표 예를 하나 만들어 둔다.

이 10항목 가운데 특히 GPO, Scheduled Task, Intune 배포 스크립트, MSI Custom Action, Sysmon/AppLocker/App Control에 의한 감지는 Microsoft 공식 안내에서도 중점 영역으로 명시되어 있습니다.

이전 전체 흐름은 그림처럼 보면 흔들리지 않습니다.

flowchart TD
    A[자산 인벤토리] --> B{의존의 종류}
    B -->|외부 .vbs 실행| C[PowerShell 또는 VBA 네이티브로 치환]
    B -->|VBScript.RegExp| D[Office 2508+ 의 내장 RegExp로 정리]
    B -->|GPO / 작업 / MSI| E[중앙 관리 설정과 배포물을 수정]
    B -->|불명·묻힌 의존| F[Sysmon / AppLocker / App Control로 실행 로그 수집]
    C --> G[단위 테스트]
    D --> G
    E --> H[통합 테스트]
    F --> H
    H --> I[감사 모드로 파일럿 배포]
    I --> J[VBScript FOD의 단계적 사용 안 함]

그림이 표시되지 않는 환경을 위해 3줄로 요약합니다.

1. 인벤토리에서 찾은 의존을 외부 .vbs 실행 / VBScript.RegExp / 중앙 관리 설정(GPO·작업·MSI) / 불명 네 가지로 가른다
2. 가른 뒤마다 치환처를 정해 단위 테스트를 통과시키고, 거기서 통합 테스트로 합류시킨다
3. 감사 모드로 파일럿 배포하고, 문제가 없으면 VBScript FOD를 단계적으로 끈다

이 순서로 두면 「먼저 바꿨는데 나중에 GPO나 ASR에서 실패했다」는 전형적인 재작업을 상당히 줄일 수 있습니다.

실무적인 검출과 코드 예

파일 검색과 구성 정보 파악

Microsoft 검출 안내에서는 C:\Users, C:\ProgramData, C:\Scripts처럼 용도가 분명한 경로를 우선해 .vbs를 재귀 검색하고, GPO, Scheduled Task, Intune 배포 스크립트, MSI 패키지도 별도 계통으로 확인하라고 권합니다. Sysmon의 vbscript.dll 감시는 유효하지만, Image Load 감시는 로그량과 운용 부하가 크므로 먼저 소규모 파일럿으로 검증해야 합니다.

# PC·공유 폴더의 스크립트 의존을 대략 훑는다
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

이어서 Task Scheduler를 훑습니다. 사내 도구는 파일보다 작업 정의 안에 wscript.exe / cscript.exe / .vbs가 들어 있는 경우가 많기 때문입니다.

# Scheduled Task 에서 VBScript 호출을 추출
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

VBA 코드 분석

VBA 쪽은 참조 설정만 봐서는 부족합니다. CreateObject나 GetObject는 문자열로 COM 개체를 만들 수 있어, 참조 설정에 아무것도 없어도 의존하는 경우가 있습니다. Microsoft의 VBA/Office 문서에서도 CreateObject는 COM 객체 생성의 기본 수단으로 설명되며, FileSystemObject나 Scripting.Dictionary도 그 형태로 쓰입니다. 또한 VBA 프로젝트를 프로그램에서 읽으려면 「VBA 프로젝트 개체 모델에 대한 액세스 신뢰」가 필요합니다.

' 전제:
'  - [보안 센터]의 「VBA 프로젝트 개체 모델에 대한 액세스 신뢰」를 켭니다
'  - 보호된 프로젝트는 별도로 소스 내보내기나 담당자 확인이 필요합니다
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

이 스캔에서는 CreateObject("VBScript.RegExp"), WScript.Shell, Shell(, .vbs, ExecuteGlobal을 최소한 찾아냅니다. 특히 Execute / ExecuteGlobal 같은 문자열 실행은 의존처나 실행 코드가 동적으로 조립되므로 인벤토리 누락이 생기기 쉽습니다.

로그 분석

실행 로그를 보는 단계에서는 Sysmon + AppLocker/App Control 조합이 강합니다. Sysmon에서는 vbscript.dll 로드를 Event ID 7로 추적할 수 있고, AppLocker는 스크립트/MSI에 대한 허용·감사 이벤트를 Event Viewer에서 확인할 수 있습니다. App Control for Business를 감사 모드로 돌리면 스크립트와 MSI는 AppLocker\MSI and Script 로그에 기록됩니다.

# Sysmon: vbscript.dll 을 읽은 프로세스를 확인
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control: 스크립트·MSI 관련 감사 로그를 확인
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

여기서 중요한 것은 「동작하고 있다」는 로그만이 아니라 「감사라면 멈췄을」 로그도 모으는 일입니다. AppLocker 감사 이벤트와 App Control 감사 모드는 운영 환경 차단 전의 안전 확인에 맞습니다.

치환의 최소 샘플

외부 .vbs를 불러 CSV를 내보내는 정도의 처리라면, 우선 VBA 네이티브로 바꾸는 편이 가장 짧습니다.

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

Excel에서 외부 처리를 불러야 하고 OS나 공유 폴더, AD, 설치 프로그램, 로그 수집까지 포함한다면 PowerShell 쪽으로 모으는 편이 현실적입니다. Microsoft는 VBScript 대체로 PowerShell을 권장하며, PowerShell 쪽에는 실행 정책, 서명, Authenticode 검증의 공식 운용 수단이 있습니다. 또한 VBA의 Shell은 기본이 비동기이므로, 순서 제어가 필요한 처리는 흐름 설계나 대기 처리를 따로 생각해야 합니다.

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# 서명 부여와 확인
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

Excel 처리가 통합 문서 내부의 정리·집계·변환만으로 끝난다면 Office Scripts도 유력합니다. Office Scripts는 Excel용이며, 클라우드 기반·크로스 플랫폼·Power Automate 연동에 맞습니다.

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

대체 기술 선정

대체처는 「무엇으로 작성할 수 있는가」가 아니라 어디까지 책임을 맡길 것인가로 고르는 편이 맞습니다. PowerShell은 Windows·파일·작업·설치 프로그램 쪽, VBA 네이티브는 Office 내부 쪽, Office Scripts는 Excel 통합 문서 처리 쪽, VSTO/.NET은 두터운 데스크톱 통합 쪽, Power Automate는 오케스트레이션 쪽입니다. 아래 표는 공식적으로 공개된 각 방식의 특성을 바탕으로 한 실무 가늠입니다. 작업량은 필자 가늠입니다.

작업량 가늠의 스케일은 도구 1개(매크로 1개, 또는 스크립트 1개)를 이전할 때의 가늠으로, 낮음＝수일, 중간＝수주, 높음＝1〜수개월로 읽으십시오. 대상이 10개면 그만큼 쌓입니다.

선정 가늠을 조금 더 직관적으로 그리면 다음과 같습니다.

flowchart TD
    A[찾은 VBScript 의존] --> B{Excel 통합 문서 안에서 끝나는가}
    B -->|예| C[VBA 네이티브]
    B -->|예 그리고 공유/클라우드 중시| D[Office Scripts]
    B -->|아니요| E{OS·파일·작업·AD에 손대는가}
    E -->|예| F[PowerShell]
    E -->|아니요| G{두터운 UI 통합이나 오래 쓰는 애드인인가}
    G -->|예| H[.NET / VSTO]
    G -->|흐름 기점이나 승인 중심| I[Power Automate]

이쪽도 3줄로 하면 다음과 같습니다.

1. Excel 통합 문서 안에서 끝나면 VBA 네이티브. 공유나 클라우드 실행을 중시하면 Office Scripts
2. OS·파일·작업·AD에 손대면 PowerShell
3. 두터운 UI 통합이나 오래 쓰는 애드인이면 .NET / VSTO. 흐름 기점이나 승인 중심이면 Power Automate

RegExp에 대해서만 덧붙이면, Office version 2508 이후만 갖춰진 환경이라면 Dim re As RegExp / Set re = New RegExp로 정리하는 일이 상당히 유효합니다. 다만 구버전 Office가 한 대라도 남아 있으면 그 코드는 컴파일 호환성 벽에 부딪힙니다. 혼합 환경에서는 이전 방침을 「새 구문」「기존 구문」「분기 래퍼」 중 무엇으로 할지를 먼저 정해야 합니다.

테스트와 운용

테스트 계획

VBScript 이전은 단위 테스트만으로는 부족합니다. 보안 정책이 켜진 운영 환경에 가까운 조건에서 재시험하지 않으면, 바꾼 뒤의 PowerShell이나 .NET 스크립트가 다른 이유로 멈춥니다. Microsoft 자료에서도 PowerShell 실행 정책, AppLocker, App Control 감사 모드, ASR, MOTW가 붙은 매크로 제어를 별개 규칙으로 다룹니다.

특히 놓치기 쉬운 것은 이쪽입니다.

• Excel에서 PowerShell을 실행하는 치환은 ASR의 「Office 앱에 의한 자식 프로세스 생성 차단」에 걸릴 수 있다.
• VBA의 선언이나 API 호출을 남겨 두면 ASR의 「Office 매크로의 Win32 API 호출 차단」에 걸릴 수 있다.
• 다운로드 파일이나 메일 첨부에서 배포한 테스트용 .xlsm / .ps1은 MOTW나 서명 상태에 따라 동작이 달라진다.
• Office Scripts와 Power Automate 조합은 편리하지만, 큰 CSV나 대량 셀에서는 타임아웃이나 데이터 전송 제한을 의식해야 한다.
• Sysmon의 Image Load 감시는 편리한 반면, 전사에서 대충 넓히면 로그량이 늘기 쉽다.

이전 절차 체크리스트

• .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell(, ExecuteGlobal을 정적 검색했다
• GPO, Scheduled Task, Intune, 공유 폴더 운용, MSI를 별도 계통으로 인벤토리했다
• Office 버전과 업데이트 채널을 목록화하고, 2508 미만의 잔존을 파악했다
• 치환처를 「VBA 네이티브 / PowerShell / .NET / Office Scripts / Power Automate」로 정했다
• 서명 방침과 인증서 배포 방침을 정했다
• AppLocker / App Control / ASR / 실행 정책의 영향을 시험했다
• 파일럿 부서에서 감사 로그를 수집했다
• 롤백 절차를 문서화했다
• VBScript FOD를 끄기 전에 「미사용」의 근거를 남겼다

리스크와 대책

이 표의 대책은 Microsoft 공식 자료에 있는 설계상의 제약을 사내 운용에 옮긴 것입니다.

롤백은 「코드를 되돌리는 것」만으로는 부족합니다. 최소한 배포물의 구버전 복원, 정책 되돌리기, 옵션 기능 재사용 여지, 로그 수집 지속을 세트로 생각하십시오. VBScript가 아직 FOD로 존재하는 단계라면 Phase 2 안내대로 옵션 기능으로 다시 켤 여지는 있지만, Phase 3에서 삭제된 뒤에는 그 우회로가 없어집니다.

샘플 이전 사례 연구

전형 예로 경리부의 월별 집계 매크로를 가정합니다. 현황은 Excel 매크로가 WScript.Shell을 통해 cleanup.vbs를 실행하고, CSV 정리 후 VBScript.RegExp로 코드를 검증한 뒤, 마지막으로 공유 폴더에 출력한다고 둡니다. 이 구성은 VBScript 폐지의 직격을 받는 데다, PowerShell로 단순 치환해도 ASR이나 서명 운용에서 다시 멈추기 쉬운 구성입니다.

규모감이 없으면 품의에 올리기 어려우므로, 설명용으로 둔 가상의 숫자도 나란히 둡니다. 실제 값은 인벤토리 결과로 정해지지만, 이 세밀도로 다시 쓰면 그대로 계획표의 밑그림이 됩니다.

기간이 작업량보다 긴 것은 월별 처리이기 때문입니다. 단위 테스트가 하루 만에 끝나도 「지난달과 같은 결과가 되는지」는 월말을 한 번 넘기지 않으면 확인할 수 없습니다. 연간 처리를 포함한 도구라면 이 대기 시간은 더 늘어납니다. 계획에서는 작업량이 아니라 확인할 수 있는 시점부터 역산하십시오.

이 사례에서는 나누어 생각하는 것이 정답입니다. Excel 내부에서 끝나는 검증이나 서식·집계는 VBA 네이티브나 Office 2508+의 내장 RegExp로 모은다. 파일 변환이나 공유 폴더 입출력은 PowerShell로 모은다. 실행 기점이 「파일 도착」이나 「매일 정시」라면 Power Automate로 모은다. 이렇게 하면 하나의 .vbs에 밀어 넣었던 책임을 정리할 수 있습니다.

이전 후 구성 예는 다음과 같습니다.

• Excel 매크로: 입력 확인, 화면 조작, 사용자용 메시지
• PowerShell: CSV 정규화, 공유 폴더 I/O, 로그 출력
• 서명 운용: PowerShell 스크립트에 Authenticode 서명
• 보안: AppLocker/App Control을 감사 모드로 선행 확인, ASR 예외 필요 여부를 판단
• 향후 확장: Excel 내부의 정형 처리는 Office Scripts로 단계 이전

이 방식의 이점은 VBScript 런타임 의존을 빨리 끊으면서, 전부를 한 번에 다시 만들지 않아도 되는 것입니다. RegExp는 Office 업데이트로 흡수하고, 운용 스크립트는 PowerShell로, 업무 흐름은 Power Automate로 책임마다 나누면 장애 범위도 작아집니다.

권장 도구와 참고 링크

• 이 글의 샘플 코드 세트(PowerShell 감사 스크립트와 Pester 테스트) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

공식 자료는 이 순서로 읽는 것을 권합니다.

• VBScript deprecation: Timelines and next steps 전체 로드맵과 Phase의 의미를 확인하기 위한 출발점.
• VBScript deprecation: Detection strategies for Windows Sysmon, GPO, Scheduled Task, Intune, MSI Custom Action까지 포함한 실무적인 검출 지침.
• Prepare your VBA projects for VBScript deprecation in Windows VBA 관점에서 가장 중요. RegExp의 내장화, Office 2508 이후의 취급, 호환 표가 정리되어 있습니다.
• Office 스크립트와 VBA 매크로의 차이 Excel 중심 처리를 Office Scripts로 모아야 할지 판단하기 쉬운 자료.
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature PowerShell 이전 시 서명·실행 정책 운용의 기본 세트.
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / App Control for Business를 사용한 스크립트 적용 감사 모드 설계, 이벤트 수집, 스크립트 적용 동작을 이해하는 데 필요.
• 공격 표면 감소 규칙 참조 Office 자식 프로세스, Win32 API, JS/VBS 다운로드 실행의 차단 규칙을 확인하기 위한 자료.
• 인터넷에서 받은 매크로는 Office에서 기본적으로 차단됩니다 테스트 배포나 운영 배포 시 MOTW 문제를 이해하기 위해 필수.

보조 도구로는 이쪽을 실무에서 자주 씁니다.

• Sysmon vbscript.dll의 로드 감시나 프로세스 계열 이벤트 수집의 기본.
• GitHub의 Sysmon 설정 템플릿 SwiftOnSecurity의 sysmon-config는 품질 좋은 초기 템플릿, Olaf Hartong의 sysmon-modular는 모듈형으로 운용하기 쉬운 출발점입니다.
• oletools / olevba Office 파일에서 VBA 소스를 추출하고, 수상한 키워드나 자동 실행 매크로를 검출하는 보조에 맞습니다.

결론적으로, VBScript 폐지에 대한 대비는 「VBScript를 찾아 PowerShell로 바꾸는 것」만으로는 부족합니다. Office 업데이트, 코드 분석, 운용 구성, 서명, ASR/AppLocker/App Control, UAT까지 한 장의 목록으로 관리하는 것이 가장 짧고 확실한 진행 방법입니다. RegExp처럼 Office 업데이트로 살릴 수 있는 영역은 일찍 살리고, .vbs 실행이나 GPO/작업/MSI 의존처럼 Windows 측 단계 전환으로 깨지기 쉬운 영역은 우선 분리하십시오.

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

VBScript는 언제 폐지되나요?

2026년 4월 시점 기준으로 Microsoft는 VBScript를 단계적으로 폐지하는 방침을 공개하고 있습니다. Windows 11 버전 24H2에서는 먼저 Feature on Demand(FOD)로 기본 사용(켜짐), 다음 단계에서는 기본 사용 안 함, 최종 단계에서는 이후 Windows 릴리스에서 삭제할 계획입니다. 지금 실제로 해야 할 일은 전부 다시 쓰기보다 앞서, 어디에 VBScript 의존이 있는지를 드러내는 일입니다. FOD로 남아 있는 단계라면 옵션 기능으로 다시 켤 여지는 있지만, 삭제된 뒤에는 그 우회로가 없어집니다.

VBScript가 폐지되면 VBA나 Excel 매크로도 쓸 수 없게 되나요?

아닙니다. 이번 논점은 「VBA가 폐지된다」는 이야기가 아닙니다. Microsoft가 공개한 것은 VBScript의 단계적 폐지이며, VBA 프로젝트에 대한 영향은 주로 외부 .vbs 파일 실행과 VBScript.RegExp 같은 VBScript 계열 라이브러리 참조에 모입니다. VBA / Excel에서 .vbs를 직접 실행하는 처리는 단계 전환 이후 멈출 위험이 높아, 우선 찾아내야 할 대상입니다. GPO 로그온 스크립트, Scheduled Task, Intune 배포 스크립트, MSI의 VBScript Custom Action도 한꺼번에 장애가 나기 쉬운 중점 영역입니다.

VBScript 대체에는 무엇을 쓰면 되나요?

대체처는 「무엇으로 작성할 수 있는가」가 아니라, 어디까지 책임을 맡길 것인가로 고릅니다. OS·파일·공유 폴더·AD·작업·설치 프로그램을 다루는 처리는 Microsoft가 권장하는 PowerShell이 유력하며, 서명과 실행 정책의 공식 운용 수단도 있습니다. Excel 통합 문서 안에서 끝나는 셀 조작이나 장표는 VBA 네이티브, 클라우드 실행이나 Power Automate 연동을 중시한다면 Office Scripts, 두터운 데스크톱 통합이나 오래 쓰는 사내 애드인은 .NET / VSTO, 예약 실행이나 승인 흐름이 기점이라면 Power Automate가 후보입니다. 바꾼 뒤에 ASR이나 AppLocker에 막히지 않는지, 정책까지 포함한 시험이 필요합니다.

VBA에서 VBScript.RegExp를 쓰는 경우에는 어떻게 하면 되나요?

Office version 2508(Build 19127.20154) 이후에는 RegExp 클래스가 VBE에 기본 포함되어, RegExp 용도에 한하면 VBScript 의존의 일부를 Office 업데이트로 해소할 수 있게 되었습니다. 다만 구버전 Office 클라이언트가 남은 혼합 환경에서는, 같은 VBA라도 동작하는 PC와 동작하지 않는 PC가 나오기 쉽습니다. 2508 미만 PC가 한 대라도 남아 있으면 새 구문은 컴파일 호환성 벽에 부딪히므로, Office 버전과 업데이트 채널을 목록으로 남겨 잔존을 파악하고, 이전 방침을 「새 구문」「기존 구문」「분기 래퍼」 중 무엇으로 할지 먼저 정해야 합니다.

저자 프로필

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

Go Komura

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

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