VB6 / Access 업무 애플리케이션의 연명과 이전 ── 남기다·감싸다·교체하다 판단표

“VB6로 작성된 기간계 시스템의 일부가 아직 현역이다”, “Access로 만든 대장이 실은 부서 업무를 지탱하고 있다”──중소기업 상담에서는 이 두 가지가 지금도 꽤 높은 빈도로 나옵니다. 공통적인 것은 만든 본인이 이미 퇴사했거나, 동작하는 이유를 아무도 정확히 설명할 수 없다는 점입니다. 그래도 고장 없이 동작하고 있기 때문에, 우선순위는 아무래도 낮아지기 쉽습니다.

이 블로그에서는 지금까지 COM / ActiveX / OCX란 무엇인가, ActiveX / OCX의 남기다·감싸다·교체하다 판단표, VBA의 제약과 향후 전망처럼 개별 기술 요소에 대해서는 써 왔습니다. 이 글에서는 대상을 좁혀, 일본 중소기업에 지금도 널리 남아 있는 2대 레거시 자산──VB6 애플리케이션과 Microsoft Access 업무 앱──에 대해 “그대로 남길지”, “일부만 감싸서 연명할지”, “교체할지”를 판단하는 실무 가이드를 정리합니다. 판단의 틀은 ActiveX / OCX 글에서 쓴 “남기다·감싸다·교체하다”의 3지선다를 그대로 따르지만, 대상이 바뀌면 리스크의 내용도 바뀌므로 이 글만의 논점을 중심으로 정리합니다.

1. 먼저 결론

• VB6의 IDE·개발 환경 자체는 2008년 4월 시점에 정식 지원이 종료되었습니다.신규 개발이나 개조를 정식 수단으로 진행하는 방법은 더 이상 제공되지 않습니다.¹
• 한편 VB6 런타임(msvbvm60.dll 등)은 그것이 포함된 Windows의 지원 기간 중에는 동작합니다.“기존 VB6 앱은 대응 Windows 위에서는 대체로 계속 동작한다”는 전제는 지금도 성립하지만, 이것은 Windows 쪽의 지원 기간에 완전히 종속된 이야기입니다.¹
• VB6는 32bit 전용이며, 64bit 네이티브 컴파일은 할 수 없습니다.64bit OS에서는 WOW64라는 32bit 호환 환경 안에서 동작하고 있습니다.¹ 64bit 전용 DLL·SDK·COM 컴포넌트와 연동할 필요가 생긴 시점에, 단일 프로세스로는 완결되지 않게 됩니다.
• Access의 .mdb / .accdb를 읽고 쓰는 “Access Database Engine(ACE)”에도 32bit/64bit의 제약이 있습니다.한 대의 머신에는 한쪽 비트 수만 설치할 수 있으며, Office의 비트 수와 일치시켜야 합니다.² Office는 Office 2019 / Microsoft 365 이후 기본 설치가 64bit로 바뀌었기 때문에, 기존 32bit 전제로 만들어진 Access 앱이나 ActiveX 부품은 새 단말로 교체하는 순간 동작하지 않게 되는 경우가 있습니다.³⁴
• 공유 폴더 위에서 여러 명이 동시에 .accdb를 여는 운영 방식은 지금도 현장에서 많지만, 손상·성능 저하의 리스크 요인입니다.네트워크를 통한 쓰기는 연결이 불안정해질 때 데이터 손상으로 이어질 수 있다고 안내되고 있습니다.⁵ 대장의 규모나 동시 이용 인원이 늘어나면, SQL Server 등으로의 업사이징을 검토할 단계입니다.
• 판단의 축은 ActiveX / OCX 때와 마찬가지로, 그 자산이 단순한 화면인지, 업무 로직과 데이터를 떠안은 경계면인지입니다. 안정적으로 가동하고 있고 범위가 닫혀 있다면 남기고, 일부만 근대화하고 싶다면 감싸고, UI나 실행 기반의 제약이 사업의 발목을 잡고 있다면 교체한다, 는 순서로 생각합니다.

2. VB6의 현재 상황 ── 런타임은 살아 있지만, 개발의 뒷받침은 없다

먼저 전제를 정확히 해 둡니다. 마이크로소프트는 2008년 4월 8일자로 “Visual Basic 6.0의 IDE(및 Visual Studio 6.0의 IDE)는 지원 대상 외”라고 표명하고 있으며, VB6 애플리케이션을 작성·유지보수하는 정식 수단은 더 이상 제공되지 않고, 모던한 기술로의 교체를 강하게 권장한다는 입장을 명확히 하고 있습니다.¹

한편 같은 발표 안에서, VB6 런타임은 그것이 포함된 Windows 버전의 지원 기간 중에는 동작 대상이다라고도 명시되어 있습니다. 기존 VB6 앱은 대응 Windows 위에서 “그대로 동작”할 것으로 기대되며, 지원 범위는 심각한 후퇴(리그레션)와 중대한 보안 문제 대응에 한정된다고 되어 있습니다.¹ 즉 “새로운 Windows에 넣어도 깨지지 않아 주었으면 한다”는 최소한의 기대는 할 수 있지만, “곤란할 때 기능 추가나 개별 조사를 해 준다”는 의미의 지원은 없습니다.

실무상 또 하나 영향을 주는 것이, VB6 런타임은 32bit 전용 파일이며, 64bit OS에서는 WOW64라는 32bit 에뮬레이션 환경 안에서만 지원 대상이 된다는 점입니다.¹ 이는 “VB6 앱은 앞으로도 32bit 프로세스로서만 살아갈 수 있다”는 것을 의미합니다. 64bit 전용 계측기 SDK나 새로운 암호화 라이브러리를 쓰고 싶어졌을 때, VB6 쪽 프로세스에 그대로 로드하는 것은 원리적으로 불가능합니다. 이 벽을 넘는 방법은 실질적으로 “별도 프로세스로 분리해 연동한다”의 한 가지뿐이며, 구체적인 구성은 「32bit 앱에서 64bit DLL을 부르는 COM 브리지 실제 사례」에서 다룬 내용을 그대로 쓸 수 있습니다. VB6 앱에서 브리지를 사용하는 경우도 사고방식은 같아서, 64bit 기능을 아웃 프로세스 COM 서버나 헬퍼 EXE에 가두고, VB6 쪽은 그것을 부르기만 하면 됩니다.

VB6 앱의 다수는 ActiveX / OCX 컨트롤을 화면 부품으로 안고 있습니다. 이 부품 자체의 남기다·감싸다·교체하다 판단은 「ActiveX / OCX를 지금 어떻게 다룰 것인가」에서 자세히 다루고 있으므로, VB6 앱 안에 내장된 개별 컨트롤의 판단은 그쪽을 참조해 주십시오. 이 글에서는 VB6 앱 전체를 어떻게 다룰지, 라는 한 단계 위 레이어의 판단에 초점을 맞춥니다.

3. Access의 현재 상황 ── 파일 형식·ACE의 비트 수·공유 폴더의 현실

3.1. .mdb / .accdb와 ACE의 비트 수

Access의 데이터는 .mdb(구 형식) 또는 .accdb(2007 이후)라는 파일에 저장되며, 이를 읽고 쓰는 런타임 컴포넌트가 Access Database Engine(ACE, Jet의 후속)입니다. 실무에서 자주 발생하는 것이 비트 수 불일치 문제입니다. 종래의 Jet OLE DB 공급자는 32bit 버전만 제공되었고, ACE는 32bit / 64bit 모두 제공되지만, 한 대의 단말에는 한쪽만 설치할 수 있으며, 해당 단말의 Office 비트 수와 일치시켜야 한다고 안내되고 있습니다.² Visual Studio 쪽에서도, Visual Studio 2022 이후가 64bit 프로세스가 되면서 32bit Access 공급자를 사용하는 데이터 도구가 연결할 수 없게 되는 경우가 명시되어 있습니다.⁶

더 골치 아픈 것이 Office 쪽 기본값의 변화입니다. Office 2010~2016은 기본값으로 32bit 버전이 설치되었지만, Office 2019 및 Microsoft 365부터는 기본 설치가 64bit 버전으로 바뀌었습니다.³ 게다가 64bit 버전 Office 프로세스는 32bit 바이너리를 읽어들일 수 없기 때문에, 기존 32bit ActiveX 컨트롤이나 COM 추가 기능은 64bit Office에서 그대로 동작하지 않습니다.⁴ 즉 “몇 년이나 같은 Access 앱을 계속 써 왔는데, PC를 교체했더니 갑자기 동작하지 않게 되었다”는 사고의 다수는, Office의 비트 수가 기본값으로 전환된 것과, 그것에 ACE나 내장 컨트롤의 비트 수가 따라가지 못한 것이 원인입니다. 이런 종류의 문제를 구분하는 절차는 「Office 2024/Microsoft 365에서 ActiveX가 동작하지 않는 원인과 확인 절차」에 정리해 두었습니다.

3.2. 공유 폴더에서의 다인 이용이라는 리스크

Access 앱의 또 다른 정석 구성이, 공유 폴더 위에 놓은 .accdb를 여러 명이 동시에 여는 운영 방식입니다. 소규모라면 오랫동안 문제없이 동작하지만, 이것은 본질적으로 위험한 구성입니다. 네트워크를 통한 쓰기는 연결이 불안정해질 때 쓰기 실패나 파일 손상으로 이어질 수 있다고 안내되고 있으며,⁵ 파일 서버 접근이 지연·타임아웃될 때 Access가 디스크/네트워크 오류를 보고하는 사례도 예전부터 알려져 있습니다.⁷ 손상의 씨앗 자체는 공유 파일에 대한 동시 접근이라는 점에서, 이 블로그의 「파일 연동의 배타 제어 기초 지식」에서 다룬 경합 패턴과 구조가 매우 비슷합니다. Access는 잠금 파일(.laccdb)에 의한 배타 제어를 내장하고 있지만, Wi-Fi 경유 노트북, VPN 경유 재택 이용, 슬립 복귀 후 재연결처럼 “연결이 불안정해지기 쉬운 경로”가 늘어날수록 사고율은 올라갑니다.

동시 이용 인원이 늘거나 처리가 무거워졌을 때의 정석 도피처가, Access의 테이블을 SQL Server나 Azure SQL로 옮기고, Access 쪽은 연결 테이블로 참조하는 구성입니다. SQL Server Migration Assistant(SSMA) 같은 도구를 사용해 Access 테이블을 이전한 후, 원래 Access 테이블을 이전 대상 테이블로의 링크로 바꿔줌으로써, 화면(폼·리포트·쿼리)은 그대로 두고 데이터만 더 견고한 기반으로 옮길 수 있습니다.⁸ 다만 연결 테이블화에는 집계 처리가 느려진다(서버 쪽에서 실행할 수 없는 함수에 의존하고 있으면, Access가 테이블 전체를 로컬로 끌어내린 후 처리한다), 자동 번호 열의 동작이 바뀐다는 이전 후 특유의 문제가 알려져 있으며, 통과 쿼리나 뷰로의 교체가 필요해지는 경우도 있습니다.⁸ 또한 Access 애플리케이션은 테이블을 가진 “백엔드” 데이터베이스와, 화면·쿼리·매크로를 가진 “프런트엔드” 데이터베이스로 분할하는 설계가 예전부터 권장되고 있습니다.⁹ 여기서 중요한 것은, 분할만으로는 충분하지 않다는 점입니다. 백엔드(테이블)만 공유 폴더에 두고, 프런트엔드는 각 사용자의 단말에 복사해 배치하여, 각자의 로컬 사본에서 이용하는 것이 올바른 구성입니다. 프런트엔드까지 공유 폴더 위의 파일 하나를 전원이 계속 여는 운영 방식은, 분할하고 있어도 “화면·쿼리·매크로를 공유 파일에 대해 동시에 읽고 쓰는” 리스크가 그대로 남아 있으며, 열릴 때까지의 대기 시간 악화나 디자인 변경 시 충돌 같은 문제를 일으킵니다. 공유 폴더 운영을 유지하며 연명하든 SQL Server로 이전하든, 먼저 “백엔드의 공유”와 “프런트엔드의 각 단말 배치”가 둘 다 되어 있는지가 첫 번째 점검 포인트가 됩니다.

4. 판단표

VB6 앱과 Access 앱을, 이용 상황·리스크 요인별로 정리하면 다음과 같이 판단할 수 있습니다.

보충하면, 이 표의 “감싼다”는 대부분의 경우, 데이터만, 또는 경계만 먼저 근대화하고 화면이나 조작감은 일단 유지한다는 의미입니다. 전부를 한 번에 다시 만드는 것이 아니라, 리스크가 높은 부분부터 순서대로 손을 대기 위한 일시적인 착지점으로 받아들여 주십시오.

판단표를 사용하는 방법으로는, 먼저 “대상” 행을 좁히고, 다음으로 “이용 상황·리스크 요인”에 자신의 상황이 해당하는지를 확인합니다. 같은 VB6 앱이라도 어떤 화면은 남기고, 어떤 기능은 감싼다는 식으로 행 단위·기능 단위로 판단을 나눠도 된다는 점이 중요합니다. “VB6 앱이니까 전부 같은 취급”으로 묶어버리면, 원래는 남길 수 있는 안정 부분까지 끌려 들어가 공수가 늘어납니다.

5. 시나리오별로 보는 판단의 적용 방법

판단표를 실제 상담에 적용하면, 대체로 다음 3가지 패턴으로 수렴하는 경우가 많습니다.

시나리오 1: 사내 전용 재고 관리 VB6 앱, 변경 요구는 작다. 대상 단말이 몇 대로 고정되어 있고 네트워크에도 나가지 않는 구성이라면, 판단표는 “남긴다”로 기웁니다. 여기서의 실무 대응은 제7장의 리스크 경감 대책(백업·문서화·실행 환경 고정)을 담담히 쌓아 가는 것에 그칩니다. 무리하게 .NET으로 이전할 동기가 없는 한, 비용 대비 효과가 맞지 않는 경우가 더 많습니다.

시나리오 2: 여러 부서가 공유하는 Access 대장, 이용 인원이 늘어났다. 몇 년 전에는 2~3명이 쓰던 Access 앱이, 부서 통합이나 업무 확대로 10명 규모의 동시 접근이 되었다는 것은 흔한 상담입니다. 이 경우 판단표는 “감싼다”로 기웁니다. 먼저 백엔드의 공유·프런트엔드의 각 단말 로컬 배치가 되어 있는지 확인하고(3.2절), 되어 있지 않다면 먼저 분할·재배치합니다. 그런 다음, 손상이나 성능 저하의 징조(열릴 때까지의 대기 시간이 늘어났다, .laccdb가 남아 잠금이 풀리지 않는다 등)가 나타난다면, 테이블을 SQL Server로 이전하고 Access 쪽은 연결 테이블로 참조하는 구성으로 전환합니다.⁸ 화면은 거의 그대로 쓸 수 있으므로, 이용자 측의 교육 비용을 억제하면서 데이터 기반만 견고하게 만들 수 있습니다.

시나리오 3: 개발자가 퇴사한 VB6 기간계 앱, 웹화 요구가 있다. 소스는 있지만 손댈 수 있는 사람이 없고, 사외에서 쓰고 싶다는 요구도 나왔다는 상황에서는, 판단표는 “교체한다”로 기웁니다. 다만 기간계일수록 갑작스러운 전면 재작성은 리스크가 너무 높습니다. 제9장의 절차대로, 먼저 업무 로직의 정리와 영향 범위가 작은 기능의 분리부터 시작해, 단계적 이전으로 진행하는 것이 현실적입니다.

6. 흔한 안티패턴

VB6·Access 연명·이전 안건에서 반복적으로 보이는 실패 패턴을 먼저 공유해 둡니다. 판단표를 적용하기 전에, 먼저 여기에 해당하지 않는지 확인해 주십시오.

이 중에서 특히 발생 빈도가 높은 것은, 비트 수 혼재 방치와 공유 폴더 다인화 이 두 가지입니다. 둘 다 “오늘 당장 깨지는” 이야기가 아니라, 단말 갱신이나 이용자 증가처럼 언젠가 반드시 오는 계기로 드러난다는 공통점이 있습니다.

7. 남길 경우의 현실적인 리스크 경감책

남긴다는 판단이 현실적인 경우는 많고, 그 자체는 잘못이 아닙니다. 다만 “동작하고 있으니 손대지 않는다”를 계속할수록, 전제를 누구도 설명할 수 없게 되는 리스크는 쌓여 갑니다. 최소한 다음은 조치해 두어야 합니다.

• 백업의 세대 관리를 기계적으로 돌린다.Access의 .accdb는 파일 하나로 완결되는 만큼, 일별로 세대 백업을 받아 두는 것만으로도 상당한 사고를 흡수할 수 있습니다. VB6 앱은 소스 일체(.vbp, .frm, .bas, .cls)와, 의존하는 OCX·DLL·레지스트리 등록 정보까지 함께 보전합니다.
• 후계자 부재 대책으로, 실행 환경의 전제를 문서화한다.대응 OS, Office의 비트 수, 필요한 런타임·의존 DLL·등록 절차를, 최소한 “새 PC에서 동작하지 않게 되었을 때 무엇을 확인하면 되는가”를 알 수 있는 수준으로 남깁니다.
• 실행 환경을 의도적으로 고정한다.Windows나 Office의 자동 업데이트로 비트 수나 기본 설정이 바뀌는 것이 사고의 계기가 되기 때문에(3.1절), 대상 단말만은 업데이트 정책을 분리해, 업데이트 전에 검증한 후 배포하는 운영으로 합니다.
• 클린 환경에서의 스모크 테스트를 준비한다.새 단말에 배포하기 전에, 아무것도 없는 환경에서 설치·등록·실행·주요 조작이 통과하는지 확인할 수 있는 절차를 준비해 두면, 배포할 때마다 “동작할 텐데 동작하지 않는다”로 멈추는 시간을 줄일 수 있습니다.
• 호출 지점을 한 곳으로 모은다.VB6의 COM 호출이나 Access의 연결 테이블 참조를 앱 전체에 흩뿌리지 않고, 가능한 범위에서 창구를 좁혀 두면, 나중에 감싸거나 교체할 때 착수 지점이 명확해집니다.

VB6 특유의 주의점으로, 개발 머신 자체의 보전도 들 수 있습니다. IDE의 설치 미디어나 라이선스, 빌드에 필요한 외부 컨트롤(OCX)의 개발자 버전, 빌드 절차 메모는 실행 환경 이상으로 흩어지기 쉬운 자산입니다. 개조 예정이 당분간 없더라도, 빌드가 재현되는 상태를 한 대의 환경(가상 머신 스냅샷 등)으로 보존해 두면, 막상 작은 개조가 필요해졌을 때의 선택지가 크게 넓어집니다.

기존 Windows 소프트웨어를 깨지 않고 유지보수·개조하고 싶은 경우는, 기존 Windows 소프트웨어의 개조·유지보수의 대상 영역입니다.

8. 감쌀 경우의 현실적인 선택지

“감싼다”는 오래된 자산을 좁은 경계 안쪽에 가두고, 주변에는 새로운 창구로 보이게 하는 접근입니다. VB6·Access에서는 대체로 다음 3가지 패턴으로 수렴됩니다.

(a) VB6의 COM 컴포넌트를 .NET에서 COM 상호 운용으로 부른다. VB6로 작성된 클래스 모듈을 ActiveX DLL(아웃 프로세스라면 EXE)로 공개하고 있는 경우, .NET 쪽에서 COM 상호 운용으로 호출할 수 있습니다. VB6 쪽은 32bit 그대로이므로, 64bit .NET 앱에서 부르는 경우는 제2장에서 다룬 비트 수의 벽이 같은 형태로 가로막습니다. 호출하는 쪽을 32bit로 맞추거나, 아웃 프로세스 COM 서버로 32bit 프로세스에 가두는 선택은, 「32bit 앱에서 64bit DLL을 부르는 COM 브리지 실제 사례」의 구성을 그대로 뒤집어 적용할 수 있습니다. COM 자체의 기초는 「COM / ActiveX / OCX란 무엇인가」를 참조해 주십시오.

(b) Access의 VBA 로직을 단계적으로 .NET / 웹으로 옮긴다. Access 앱 중에는, 폼 뒤에 업무 로직이 짙게 쌓여 있는 경우와, 단순한 데이터 입력·목록 표시에 그치는 경우가 섞여 있습니다. 먼저 VBA 모듈을 정리하고, 다른 시스템에 의존하지 않는 순수한 계산·검증 로직부터 .NET 클래스 라이브러리로 분리하여, Access 쪽에서는 COM 경유, 또는 중간의 Web API 경유로 부르는 형태로 바꾸어 가는 방식이 현실적입니다. VBA 자체의 제약과, 어디까지를 VBA에 남겨야 할지의 판단 기준은 「VBA란 무엇인가 - 제약, 향후 전망, 교체해야 할 상황」에서 자세히 정리하고 있습니다.

(c) UI만 먼저 교체하고, 데이터와 로직은 온존한다. Access의 폼이 오래되었다, 느리다, 사외에서 쓸 수 없다 같은 불만이 중심이라면, 데이터 계층(SQL Server화한 테이블)과 로직은 그대로 두고, UI만 웹이나 데스크톱의 새로운 기술로 교체하는 선택지가 있습니다. 3.2절의 연결 테이블화와 조합하면, “데이터는 SQL Server, 구 UI(Access)와 신 UI가 같은 데이터를 본다”는 과도적인 이중 가동도 가능합니다. 다만 Access 쪽 VBA가 UI와 로직을 밀결합시키고 있는 경우, 이 분리 작업 자체가 (b)의 정리를 먼저 마치지 않으면 성립하지 않습니다.

3가지 선택지를 정리하면 다음과 같습니다.

경계 정리나 이전 방침을 먼저 상담하고 싶은 단계라면 기존 자산 활용·이전 지원, 구현에 들어가기 전 설계 리뷰로는 기술 상담·설계 리뷰가 대응 영역입니다.

9. 교체할 경우의 진행 방법

교체를 선택하는 것은, UI나 비트 수의 제약이 사업의 속도를 직접적으로 저해하고 있다, 개발자 부재로 유지보수 자체가 어려워졌다는 상황입니다. 전면 재작성을 갑자기 시작하는 것이 아니라, 다음 순서를 밟으면 사고가 줄어듭니다.

1. 데이터 이전 검증을 먼저 한다. Access → SQL Server 같은 데이터 이전에서는, 자동 번호 부여 시점의 차이, Access 쪽에만 있는 함수에 대한 의존, 고유 인덱스의 누락 등, 이전 후에야 드러나는 차이가 있습니다.⁸ 운영 데이터의 복제로 이전과 업무 시나리오를 왕복 테스트한 후, 실제 전환으로 진행합니다.
2. 업무 로직의 정리를 한다. VB6의 폼/모듈, Access의 VBA/매크로/쿼리 내용을 기능 단위로 파악해, “단순한 화면”인지 “사양을 떠안은 경계면”인지를 구분합니다. 이 구분 방법은 ActiveX / OCX의 판단과 같지만, VB6·Access의 경우 오랜 운영으로 쌓인 업무 이해 자체가 자산이 된 만큼, 발굴에 시간이 걸리기 쉬운 점이 고유한 무게입니다.
3. 단계적 이전(스트랭글러 패턴)으로 진행한다. 모든 기능을 한 번에 교체하는 것이 아니라, 리스크가 낮고 독립성이 높은 기능부터 신규 시스템으로 분리하여, 구 앱과 신 앱을 일정 기간 병행 가동시킵니다. 신구 어느 쪽 데이터가 정본인지를 기능 단위로 명확히 하고, 병행 기간의 종료 조건을 미리 정해 두는 것이, 이 방식을 파탄시키지 않기 위한 최소 조건입니다.
4. UI 부품이나 화면 구성의 교체를 먼저 끝내 두면 편해진다. VB6 앱이 ActiveX / OCX를 UI 부품으로 사용하고 있는 경우, 그 부품만 먼저 현대적인 컨트롤로 교체해 두면, 후속 전체 교체의 견적을 세우기 쉬워집니다. 개별 판단은 「ActiveX / OCX를 지금 어떻게 다룰 것인가」를 참조해 주십시오.
5. 병행 기간 중의 관측 수단을 준비한다. 구 앱과 신 앱을 병행 가동시키는 동안은, 어느 쪽의 처리로 어떤 결과가 나왔는지 비교할 수 있는 로그나 대조 체계를 준비해 둡니다. 관측 수단이 없는 채로 전환을 진행하면, “신규 시스템으로 전환했더니 숫자가 맞지 않게 되었다”는 사고를 깨닫는 것이 몇 달 후가 될 수도 있습니다.

오래된 Windows 앱의 사양 정리부터 단계적 교체까지를 대상으로 하는 서비스로는, Windows 앱 리플레이스가 있습니다.

10. 이전을 시작할 때의 체크리스트

판단표(제4장)를 적용하기 전에, 다음 순서로 정리해 두면 방침 결정에 걸리는 시간을 꽤 줄일 수 있습니다.

1. 대상을 파악한다. VB6의 .exe / .dll / .ocx, Access의 .mdb / .accdb를, 파일명·버전·배치 위치별로 목록화합니다.
2. 이용 상황을 확인한다. 이용자 수, 동시 접근 여부, 공유 폴더 운영 여부, 일별·월별 중 어떤 빈도로 사용되는지를 확인합니다.
3. 실행 환경의 전제를 확인한다. 대응 Windows 버전, Office의 비트 수, 필요한 런타임·의존 DLL·COM 등록 여부를 파악합니다(제2~3장).
4. 데이터의 소재와 규모를 확인한다. Access라면 파일 크기, 테이블 수, 레코드 수와 증가 속도를 파악합니다. SQL Server화의 필요성을 판단하는 자료가 됩니다.
5. 업무 로직의 복잡성을 추정한다. VBA 모듈의 줄 수, 매크로의 수, 폼의 수, VB6 쪽 폼·클래스 모듈의 수로부터, 정리에 걸릴 공수의 대략적인 감을 잡습니다.
6. 백업과 복구 절차의 유무를 확인한다. 백업이 이루어지지 않고 있거나, 복구를 시도해 본 적이 없는 대상은, 판단 이전에 먼저 여기를 정비합니다.
7. 여기까지의 결과를 판단표에 적용한다. 대상·이용 상황이 정리되면, 제4장의 표에 비추어, 남기다·감싸다·교체하다 중 어디로 기우는지 기능 단위로 임시 결정합니다.

이 절차를 건너뛰면, 나중에 “무엇이 어려웠는지”를 설명할 수 없는 채 공수만 늘어나는 전개가 되기 쉽습니다.

11. 정리

VB6·Access의 취급을 결정할 때 가장 먼저 봐야 할 것은 “오래되었는가”가 아니라, 다음 3가지입니다.

• VB6는 IDE의 뒷받침을 잃은 32bit 전용 실행 환경이다라는 전제를 올바르게 이해하고 있는가(제2장).
• Access의 ACE·ActiveX는 Office의 비트 수에 얽매이고, 공유 폴더 운영은 동시 접근이 늘어날수록 손상 리스크가 올라간다는 전제를 반영할 수 있는가(제3장).
• 그 자산이 단순한 화면인지, 업무 로직과 데이터를 떠안은 경계면인지를 구분할 수 있는가(제4장의 판단표).

이 3가지가 정리되면, “남긴다”면 실행 환경을 고정하고 백업과 문서화를 게을리하지 않는다(제7장), “감싼다”면 32/64bit 브리지나 단계적인 .NET/웹화로 데이터와 로직을 지킨다(제8장), “교체한다”면 데이터 이전 검증과 업무 로직 정리를 먼저 한다(제9장), 라는 진행 방식으로 자연스럽게 이어집니다. VB6·Access는 오래되었다는 이유만으로 무작정 버려야 할 대상이 아니라, 오랜 업무 지식이 담긴 실물입니다. 다만 그 실물과 계속 함께하기 위한 실행 환경 고정·경계 정리·이전 검증이라는 과제로부터, 언제까지나 계속 도망칠 수 있는 것은 아닙니다. 먼저 제10장의 체크리스트를 따라 정리부터 시작하는 것을 권해 드립니다.

관련 글

• VBA란 무엇인가 - 제약, 향후 전망, 교체해야 할 상황과 현실적인 이전 패턴
• ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남기다·감싸다·교체하다 판단표
• COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 정리해서 설명
• Office 2024/Microsoft 365에서 ActiveX가 동작하지 않는 원인과 확인 절차
• 32bit 앱에서 64bit DLL을 부르는 COM 브리지 실제 사례
• 파일 연동의 배타 제어 기초 지식 - 파일 잠금과 원자적 claim의 모범 사례

관련 상담 영역

합동회사 코무라소프트에서는 VB6·Access를 포함한 기존 자산의 정리와 이전 방침 수립, 32bit/64bit 브리지를 포함한 연명 설계, 단계적 리플레이스의 계획·구현을 다루고 있습니다.

• 기존 자산 활용·이전 지원
• Windows 앱 리플레이스
• 기존 Windows 소프트웨어의 개조·유지보수
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

VB6 앱은 지금의 Windows에서도 동작하나요?

VB6의 IDE(개발 환경)는 2008년 4월에 정식 지원이 종료되었지만, VB6 런타임(msvbvm60.dll 등)은 그것이 포함된 Windows의 지원 기간 중에는 동작 대상입니다. 즉 기존 VB6 앱은 대응 Windows 위에서는 대체로 계속 동작합니다. 다만 VB6는 32bit 전용이며, 64bit OS에서는 WOW64라는 호환 환경 안에서 동작하기 때문에, 64bit 전용 DLL·SDK·COM 컴포넌트와의 연동이 필요해진 시점에 별도 프로세스로 분리해 연동하는 구성이 필요해집니다.

PC를 교체했더니 Access 앱이 동작하지 않게 된 이유는 무엇인가요?

많은 경우 Office의 비트 수 변화가 원인입니다. Office 2010~2016은 기본값이 32bit 버전이었지만, Office 2019 및 Microsoft 365부터는 기본 설치가 64bit 버전으로 바뀌었습니다. Access의 데이터를 읽고 쓰는 ACE(Access Database Engine)는 한 대의 단말에 32bit/64bit 중 한쪽만 설치할 수 있으며, Office의 비트 수와 일치시켜야 합니다. 게다가 64bit 버전 Office는 32bit ActiveX 컨트롤이나 COM 추가 기능을 읽어들일 수 없기 때문에, 기존 32bit 전제로 만들어진 부품이 새 단말에서 동작하지 않게 됩니다.

공유 폴더에서 여러 명이 Access 파일을 여는 운영 방식은 문제가 있나요?

손상·성능 저하의 리스크 요인입니다. 네트워크를 통한 쓰기는 연결이 불안정해질 때 데이터 손상으로 이어질 수 있습니다. Wi-Fi 경유 노트북이나 VPN 경유 재택근무 이용이 늘어날수록 사고율은 올라갑니다. 최소한 테이블을 가진 백엔드만 공유하고, 화면·쿼리를 가진 프런트엔드는 각 사용자의 단말에 복사해 배치하는 분할 구성으로 해야 합니다. 동시 이용 인원이 늘어나면, 테이블을 SQL Server로 이전하고 Access 쪽은 연결 테이블로 참조하는 구성으로 전환하는 것을 검토할 단계입니다.

VB6/Access 앱은 남기다·감싸다·교체하다 중 무엇을 선택해야 하나요?

판단의 축은 그 자산이 단순한 화면인지, 업무 로직과 데이터를 떠안은 경계면인지입니다. 단말이나 Windows 버전이 고정되어 있고 변경 요구도 작다면, 백업·문서화·실행 환경 고정을 전제로 남기는 편이 비용 대비 효과에 맞습니다. 64bit 연동이나 데이터 기반 강화가 필요하다면, COM 브리지나 SQL Server로의 연결 테이블화로 일부만 감쌉니다. 개발자 부재로 유지보수가 어렵거나 웹화 요구가 있다면 교체이지만, 갑작스러운 전면 재작성이 아니라 데이터 이전 검증과 업무 로직 정리를 먼저 하는 단계적 이전이 현실적입니다.

저자 프로필

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

Go Komura

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

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