Office 2024/Microsoft 365에서 ActiveX가 작동하지 않는 원인과 확인 절차

1. 가장 먼저 알아 두어야 할 것

Office 2024와 Microsoft 365에서는 ActiveX 컨트롤이 기본으로 비활성화되어 있습니다. 예전에는 동작하던 Excel 버튼이나 폼, Word / PowerPoint의 포함 개체가 업데이트 뒤에 갑자기 “작동하지 않는” 것처럼 보이는 것은, 대개 프로그램 고장이 아니라 보안 기본값 변경이 원인입니다.

원인은 크게 3가지로 나눌 수 있습니다.

1. 보안 설정 변화(Trust Center, ActiveX 기본 비활성화)
2. 32bit / 64bit 불일치(64bit Office에 32bit 전용 컨트롤을 올린 경우)
3. COM 등록이나 의존 DLL / 런타임 부족(regsvr32 미실행, VC++ 런타임 누락)

실무 원칙: 이 순서대로 위에서부터 원인을 좁히는 것이 가장 빠릅니다.

이 글에서 쓰는 용어

IT 관리자(정보시스템 담당)를 위해, 본문에서 따로 설명하지 않고 나오는 용어를 먼저 정리합니다.

이 글의 구성

길기 때문에 필요한 부분부터 읽으면 됩니다. 크게 3묶음입니다.

급하면 먼저 11장 “자주 있는 증상과 대응”에서 자신의 증상을 찾고, 해당 Step으로 돌아가면 됩니다.

이 글의 지식 맵

Office 2024와 Microsoft 365에서는 ActiveX 컨트롤이 기본적으로 사용하지 않도록 설정되어 있으며, 이전에 동작하던 버튼이나 포함 개체가 동작하지 않게 되는 주된 원인은 이 기본값 변경에 있습니다. ActiveX의 동작은 COM으로서의 레지스트리 등록을 전제로 하며, Office와 컴포넌트의 bitness가 일치하지 않으면 동작하지 않고, RegAsm의 bitness 차이도 같은 불일치를 초래합니다. Trust Center의 ActiveX 설정과 Trusted Publisher에 의한 코드 서명 취급, MOTW 부여에 의한 보호된 보기, .NET Framework나 Visual C++ Redistributable과 같은 의존 런타임 부족, Click-to-Run 특유의 설치 방식, Edge의 IE 모드 미구성도 비슷한 증상을 일으킬 수 있습니다. 원인을 가려내는 데에는 Process Explorer나 Procmon으로 실제로 확인하는 것이 유효하며, 항구적인 조치에는 제한적인 허용과 Monthly Enterprise Channel 채택이 권장됩니다.

flowchart LR
    accTitle: Office 2024/Microsoft 365의 ActiveX 문제 해결의 지식 맵
    accDescr: ActiveX가 기본적으로 사용하지 않도록 설정되어 있다는 점, COM 등록과 bitness 일치라는 전제, Trust Center·보호된 보기·의존 런타임·Click-to-Run·IE 모드라는 여러 원인이 ActiveX 동작 실패로 어떻게 이어지는지를 보여주는 그림.
    activex["ActiveX"]
    com["COM(컴포넌트 오브젝트 모델)"]
    clsid["CLSID(Class ID)"]
    wow6432node["WOW6432Node"]
    regsvr32["regsvr32"]
    regasm["Regasm.exe"]
    bitness_match_requirement["비트수 일치 요건"]
    activex_load_failure["ActiveX 동작 실패"]
    office_trust_center["보안 센터"]
    trusted_publisher_store["신뢰할 수 있는 게시자 저장소"]
    code_signing_cert["코드 서명 인증서"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    protected_view["보호 보기"]
    dotnet_framework[".NET Framework"]
    vc_redistributable["Visual C++ 재배포 가능 패키지"]
    procmon["Process Monitor(procmon.exe)"]
    process_explorer["Process Explorer"]
    ie_mode["IE 모드"]
    enterprise_site_list["Enterprise Site List"]
    click_to_run["Click-to-Run"]
    office_msi_install["Office MSI 설치(구방식)"]
    disableallactivex_policy["DisableAllActiveX(검증용 레지스트리)"]
    monthly_enterprise_channel["월별 엔터프라이즈 채널"]
    activex -->|"전제로 한다"| com
    com -->|"이용한다"| clsid
    com -.->|"에 저장된다"| wow6432node
    regsvr32 -->|"구현을 담당한다"| com
    regasm -->|"구현을 담당한다"| com
    regasm -->|"전제로 한다"| bitness_match_requirement
    activex -->|"전제로 한다"| bitness_match_requirement
    bitness_match_requirement -->|"원인이 될 수 있다"| activex_load_failure
    activex -.->|"에서 구성할 수 있다"| office_trust_center
    office_trust_center -->|"이용한다"| trusted_publisher_store
    trusted_publisher_store -->|"전제로 한다"| code_signing_cert
    code_signing_cert -->|"권장되는 대응"| activex
    zone_identifier -->|"원인이 될 수 있다"| protected_view
    protected_view -.->|"원인이 될 수 있다"| activex_load_failure
    activex -.->|"전제로 한다"| dotnet_framework
    activex -.->|"전제로 한다"| vc_redistributable
    activex_load_failure -->|"에서 확인할 수 있다"| procmon
    activex_load_failure -->|"에서 확인할 수 있다"| process_explorer
    ie_mode -.->|"에서 구성할 수 있다"| enterprise_site_list
    ie_mode -.->|"원인이 될 수 있다"| activex_load_failure
    click_to_run -->|"의 후속"| office_msi_install
    click_to_run -.->|"원인이 될 수 있다"| activex_load_failure
    disableallactivex_policy -->|"사용은 비권장"| activex
    monthly_enterprise_channel -->|"권장되는 대응"| activex

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

2. Office 2024 계열 vs Microsoft 365 ── 무엇이 다른가

중요: 레지스트리 경로는 Office 2024에서도 16.0 그대로입니다. “2024이니까 24.0을 찾는다”는 전형적인 멀리 돌아가는 실수입니다.

Windows 10에서 주의할 점

Windows 10의 일반 지원은 2025년 10월 14일에 종료되었습니다. 다만 Microsoft 365 Apps는 Windows 10에서도 2028년 10월 10일까지 보안 업데이트가 제공되는 전환 유예 기간 중입니다. 즉 다음 상태입니다.

• “Windows 10에서는 전혀 동작하지 않는다”는 것은 아닙니다
• “OS는 지원 종료, Apps는 유예 중”이라는 이중 전제로 운용하는 상태입니다

3. 문제 해결의 전체 그림

flowchart TD
    A[증상 재현] --> B[Office 제품명·build·bitness·OS 정보 수집]
    B --> C{OS / Office 지원 전제는 OK?}
    C -- NG --> C1[전제 수정: OS / Office 에디션 / 채널 재검토]
    C -- OK --> D[Trust Center 확인]
    D --> E{ActiveX 설정 / 보호된 보기 / 신뢰할 수 있는 문서에 문제?}
    E -- 있음 --> E1[설정·서명·배포 설계 수정]
    E -- 없음 --> F{레거시 Web / IE 전제?}
    F -- 예 --> F1[IE 모드와 사이트 목록 확인]
    F -- 아니오 --> G[CLSID / InprocServer32 / TypeLib 확인]
    G --> H{COM 등록은 정상?}
    H -- NG --> H1[regsvr32 / RegAsm / 재설치]
    H -- OK --> I[의존 DLL / .NET / VC++ 런타임 확인]
    I --> J{의존성은 충족하는가?}
    J -- NG --> J1[해당 런타임 복구·재배포]
    J -- OK --> K[로그 수집 / Procmon / Process Explorer]
    K --> L[build 차이·보안 업데이트 차이 확인]

4. Step 1 ── 환경 정보를 수집한다

먼저 아래 정보를 반드시 기록합니다. 감이 아니라 수치로 판단하기 위해서입니다.

Office 쪽

• [파일] → [계정] → [제품 정보]에서 확인
  • 제품명(Office 2024 / Microsoft 365 구분)
  • 버전과 빌드 번호(가장 중요)
  • 설치 종류(Click-to-Run)
• [Excel의 버전 정보] / [Word의 버전 정보] 등 제품 정보 대화상자에서 32bit / 64bit를 확인

Windows 쪽

# OS 의 기본 정보
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber, OSArchitecture

# Office 프로세스의 실행 파일 경로
Get-Process WINWORD, EXCEL, POWERPNT, VISIO -ErrorAction SilentlyContinue |
  Select-Object ProcessName, Path

가져온 결과를 어떻게 읽을까

출력 자체는 환경마다 다르므로, 봐야 할 열과 판단 기준을 적습니다.

Get-Process가 한 건도 반환하지 않으면, 대상 Office 앱이 실행되지 않은 것뿐입니다. 확인할 앱을 연 뒤 다시 실행하십시오. -ErrorAction SilentlyContinue를 붙였으므로, 실행 중이 아닌 프로세스 이름이 있어도 오류가 되지 않습니다.

Office 쪽 bitness는 앱 메뉴에서도 확인할 수 있습니다. Excel이라면 “파일”→”계정”→”Excel의 버전 정보”로 들어가면, 연 대화상자의 첫 줄에 버전, 빌드 번호, “32비트” 또는 “64비트” 표기가 나란히 있습니다. 이 줄을 그대로 적어 두면 벤더 문의나 재현 검증에서 이야기가 빨라집니다.

흔한 함정

5. Step 2 ── Trust Center와 보안 설정을 확인한다

여기서 할 일은 “파일 자체가 차단된 것인지”, 아니면 “COM 실체 로드에 실패한 것인지”를 나누는 것입니다.

체크리스트(위에서부터 순서대로)

화면의 어디를 볼까

화면 예시 대신 위치와 조작 순서를 적습니다.

• 메시지 표시줄: 파일을 연 직후, 리본과 편집 영역 사이에 가로로 긴 띠로 나타납니다. 닫았다면 파일을 닫았다가 다시 열면 다시 표시됩니다.
• ActiveX 설정 화면: “파일”→”옵션”→”보안 센터”까지 가도, 거기 보이는 것은 설명문과 단추뿐입니다. 설정의 실체는 “보안 센터 설정(T)…” 단추를 누른 뒤에 있고, 연 화면 왼쪽 목록에서 “ActiveX 설정”을 고릅니다. 이 한 단계를 건너뛰면 목적 화면에 닿지 않습니다. Microsoft 안내에서도 ActiveX를 사용하는 절차는 메시지 표시줄의 일시 허용이 아니라 이 설정 변경으로 설명되어 있습니다.
• 보호된 보기 / 신뢰할 수 있는 문서 / 신뢰할 수 있는 게시자: 모두 같은 “보안 센터 설정” 화면의 왼쪽 목록에 있습니다. 재현 확인 전에 신뢰할 수 있는 문서 기록을 지워 두면 단말 간 차이가 나기 어렵습니다.

설정 적용 범위에 주의: ActiveX 설정은 지금 연 파일만이 아니라 Word / Excel / PowerPoint / Visio의 모든 파일에 적용됩니다. “이 파일만 허용”하는 설정이 아닙니다. 조사를 위해 잠시 느슨하게 했다면 반드시 원래대로 되돌리십시오.

먼저 시험할 것

1. 문제 파일을 로컬의 관리된 폴더(예: C:\Temp)에 복사하고 다른 이름으로 저장
2. 네트워크 공유나 메일 첨부에서 바로 열지 않기(보호된 보기 영향을 배제)
3. Office를 안전 모드로 시작해 추가 기능 영향을 나눈다

excel /safe
winword /safe
powerpnt /safe

6. Step 3 ── IE 모드 의존 여부를 확인한다

“평범한 ActiveX 장애”라고 생각했는데, 실제로는 Edge의 IE 모드 미구성이 원인인 경우가 있습니다.

• IE 모드는 브라우저 전체 스위치가 아니라, Enterprise Site List에 등록한 사이트에만 적용됩니다
• 사내 Web 연동의 일부만 동작하지 않으면, 그 사이트가 IE 모드 대상인지 확인합니다

확인할 곳은 다음과 같습니다.

• Edge 정책: 관리 템플릿 > Microsoft Edge
• 레지스트리: HKLM\SOFTWARE\Policies\Microsoft\Edge
• 진단 페이지: edge://compat/iediagnostic

7. Step 4 ── COM 등록을 확인한다

Trust Center에 문제가 없으면, 다음은 COM 실체가 올바르게 등록되어 있는지 확인합니다.

기본 확인 명령

:: CLSID 의 등록 상황을 확인
reg query "HKLM\SOFTWARE\Classes\CLSID\{YOUR-CLSID-HERE}\InprocServer32" /s

:: 네이티브 COM / ActiveX DLL 의 등록·해제
regsvr32 C:\Path\YourControl.dll
regsvr32 /u C:\Path\YourControl.dll

확인 결과 읽는 법

reg query 결과에서 볼 것은 세 가지입니다.

1. 키가 존재하는가. 키가 없으면 아무 것도 표시되지 않고 “찾을 수 없습니다” 오류만 반환됩니다. 이 시점에서 미등록이 확정됩니다.
2. 기본값에 들어 있는 DLL 경로. 여기가 COM 실체입니다.
3. 그 경로에 파일이 실제로 있는가. 제거나 이동으로 실체만 사라지고 등록만 남은 상태는 흔합니다.

판정까지 한 번에 하려면 PowerShell이 더 읽기 쉽습니다.

# 조사할 CLSID 로 바꿔 실행합니다(중괄호를 포함해 지정)
$clsid = '{00000000-0000-0000-0000-000000000000}'
$key   = "HKLM:\SOFTWARE\Classes\CLSID\$clsid\InprocServer32"

if (Test-Path $key) {
  $server = Get-ItemPropertyValue -Path $key -Name '(default)'
  [pscustomobject]@{
    CLSID      = $clsid
    Server     = $server
    FileExists = Test-Path $server
  }
} else {
  Write-Host "미등록: $key 을(를) 찾을 수 없습니다"
}

FileExists가 False이면 등록은 남았는데 실체가 없는 상태입니다. 재설치나 재등록이 필요합니다.

보는 곳을 틀리지 않기: 64bit Windows에서 32bit COM을 등록하면 실체는 HKLM\SOFTWARE\Classes\WOW6432Node\CLSID\{CLSID} 쪽에 들어갑니다. 64bit PowerShell이나 reg query에서 HKLM\SOFTWARE\Classes\CLSID만 보면 “미등록”으로 보이므로, 32bit Office 문제에서는 WOW6432Node 아래도 반드시 확인하십시오.

.NET으로 만든 COM의 경우(중요)

.NET 어셈블리에는 regsvr32를 쓸 수 없습니다. RegAsm을 사용합니다.

:: 32bit Office on 64bit Windows → Framework 의 RegAsm 을 사용
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

:: 64bit Office → Framework64 의 RegAsm 을 사용
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

전형적인 사고: “RegAsm의 bitness가 Office의 bitness와 맞지 않다” → 레지스트리상으로는 등록에 성공해도 Office에서는 찾을 수 없다.

8. Step 5 ── 의존 DLL / 런타임을 확인한다

“본체 DLL은 있는데 로드되지 않는다”면 의존 대상이 부족한 경우가 많습니다.

실무에서 자주 부족한 런타임

저수준 조사 도구

Procmon으로 재현 순간의 로그를 잡고 NAME NOT FOUND로 필터하면, 어느 DLL이나 레지스트리 키를 찾지 못했는지 한눈에 알 수 있습니다.

필터 거는 법, 노이즈 줄이는 법, 어느 이벤트부터 읽을지는 Process Monitor(ProcMon) 실무 가이드에 절차로 정리해 두었습니다. 또한 등록과 bitness 조합에서 막힌 경우에는 COM/OCX/ActiveX 개발에서 빠지는 등록과 bitness의 함정이 개발 쪽에서 본 같은 문제를 다룹니다.

9. Step 6 ── 로그를 모아 최종 확인

여기까지 원인을 특정하지 못하면 로그를 켜고 재현 순간을 잡습니다.

Office 일반 로그 활성화

reg add HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /t REG_DWORD /d 1

Click-to-Run 상세 로그 활성화

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1

로그는 %windir%\temp나 %temp%에 출력됩니다.

이벤트 뷰어도 함께 쓴다

eventvwr.msc

• Windows 로그 > 애플리케이션을 확인합니다
• .NET Runtime이나 SideBySide 오류가 결정적인 경우가 많습니다

검증 후 로그 끄기(잊지 말 것)

reg delete HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

10. 주요 레지스트리 / 정책 빠른 표

기억할 네 경로

32bit Office on 64bit Windows에서는 COM 관련은 Wow6432Node 아래도 확인합니다.

자주 쓰는 테스트용 레지스트리(검증 전용)

Windows Registry Editor Version 5.00

; 테스트 전용: ActiveX 일괄 비활성화를 해제
[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]
"DisableAllActiveX"=dword:00000000

경고: 이 설정은 검증 전용입니다. 항구적 대응은 “신뢰할 수 있는 배포 경로와 서명”으로 하십시오.

11. 자주 있는 증상과 대응

12. 기업용 권장 설정

상시 대책의 기본은 “전체 보안을 낮추는 것”이 아니라 “필요한 대상만 제한적으로 허용하는 것”입니다.

Microsoft 365 배포 설정 예(32bit + 월별 엔터프라이즈)

<Configuration>
  <Add OfficeClientEdition="32" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

13. 마지막 수단 ── 복구

• 빠른 복구 / 온라인 복구는 설정이나 등록 손상에는 효과가 있습니다
• 다만 x86 / x64 불일치나 서명 / 정책 문제 자체는 해결하지 않습니다
• 복구는 “마지막에 한다”(먼저 하면 조사 로그가 더러워집니다)

14. 명령 빠른 표

15. 정리 ── 좁히는 순서를 틀리지 않기

설정 실수 → OS / bitness 불일치 → COM 실체 문제 → 의존 관계 → 업데이트 차이

ActiveX 문제는 “Excel만의 문제”처럼 보여도, 실제로는 Office의 기본 보안 + Windows의 지원 전제 + COM 실체 등록 + 의존 런타임 + 업데이트 모델이라는 5개 층이 겹치는 문제입니다. 무작정 설정을 느슨하게 하기 전에 위에서부터 원인을 나누면, 재발하기 어려운 복구에 닿을 수 있습니다.

참고 링크

• ActiveX controls are disabled by default in Microsoft 365 and Office 2024 ─ 기본 비활성화의 영향 범위
• Enable or disable ActiveX settings in Office files ─ 사용자 조작에 가장 가까운 자료
• Update history for Office LTSC 2024 and Office 2024 ─ build 비교, 업데이트 전후 차이
• Overview of update channels for Microsoft 365 Apps ─ Current / Monthly Enterprise / Semi-Annual의 차이
• Release Information for Updates to Microsoft 365 Apps ─ 채널에서 오는 동작 차이
• Compatibility between the 32-bit and 64-bit versions of Office ─ ActiveX / COM 자산이 얽일 때의 판단 기준
• Microsoft Edge에서의 Internet Explorer 모드 ─ Enterprise Site List와 정책
• regsvr32 명령 ─ 네이티브 COM의 등록 / 해제
• Regasm.exe (어셈블리 등록 도구) ─ .NET으로 만든 COM의 등록
• Process Monitor (Procmon) ─ NAME NOT FOUND / PATH NOT FOUND 추적
• Process Explorer ─ 프로세스의 DLL 로드 상황
• Latest supported Visual C++ Redistributable Downloads ─ VC++ 런타임 부족을 확인할 곳
• .NET Framework 설치 가이드 ─ .NET Framework 버전 확인

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Office 2024나 Microsoft 365에서 ActiveX가 기본으로 비활성화되었다는 것은 무슨 뜻인가요?

Office 2024와 Microsoft 365에서는 ActiveX 컨트롤이 기본으로 비활성화되어 있습니다. 예전에는 동작하던 Excel 버튼이나 폼, Word / PowerPoint의 포함 개체가 업데이트 뒤에 갑자기 "작동하지 않는" 것처럼 보이는 것은, 대개 프로그램 고장이 아니라 이 보안 기본값 변경이 원인입니다. 파일을 열 때 나오는 노란색 메시지 표시줄에서 [콘텐츠 사용]을 골라 일시적으로 동작하는지 시험하고, Trust Center(보안 센터)의 ActiveX 설정을 확인하는 것이 첫 단계입니다.

Office 업데이트 뒤에 Excel의 ActiveX 버튼이 반응하지 않습니다. 무엇부터 확인해야 하나요?

원인은 크게 3가지로 나눌 수 있습니다. 첫째는 보안 설정 변화(Trust Center, ActiveX 기본 비활성화, 보호된 보기), 둘째는 32bit / 64bit 불일치(64bit Office에 32bit 전용 컨트롤을 올린 경우), 셋째는 COM 등록이나 의존 DLL / 런타임 부족(regsvr32 미실행, VC++ 런타임 누락)입니다. 이 순서대로 위에서부터 원인을 좁히는 것이 가장 빠릅니다. 함께 제품명·빌드 번호·Office의 bitness·OS 정보를 먼저 기록하고, 네트워크 공유나 메일 첨부에서 바로 열지 말고 로컬 폴더에서 재현 차이를 확인합니다.

64bit Office에서만 ActiveX 컨트롤이 작동하지 않는 이유는 무엇인가요?

Office의 bitness와 COM / ActiveX의 bitness는 반드시 일치해야 하기 때문입니다. 64bit Office에 32bit 전용 컨트롤을 올려도 동작하지 않습니다. 벤더에 x64 버전이 있는지 확인하고, 없으면 Office 32bit로 바꾸는 방안을 검토합니다. .NET으로 만든 COM이면 regsvr32가 아니라 RegAsm을 쓰며, 32bit Office면 Framework, 64bit Office면 Framework64의 RegAsm으로 등록합니다. RegAsm의 bitness가 Office와 맞지 않으면, 레지스트리상으로는 등록에 성공해도 Office에서는 찾을 수 없는 전형적인 사고가 됩니다.

ActiveX를 계속 쓰려면 어떻게 설정해야 하나요?

전체 보안을 낮추지 말고, 필요한 대상만 제한적으로 허용하는 것이 기본입니다. DisableAllActiveX 레지스트리 변경은 검증 전용이며, 항구적 대응은 신뢰할 수 있는 배포 경로와 서명으로 합니다. 구체적으로는 사내 배포 ActiveX / 매크로 / 추가 기능에 코드 서명을 하고 Trusted Publisher를 한곳에서 관리하며, Microsoft 365에서는 변경 지점을 읽기 쉬운 월별 엔터프라이즈 채널을 검토하고, 벤더가 x64 지원을 명시하지 않는 한 Office 32bit를 우선 검토합니다. 프로덕션 배포 전에는 pilot ring을 만들고, 대표 서식·대표 단말에서 빌드를 고정해 검증합니다.

저자 프로필

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

Go Komura

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

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