VB6 / Access 업무 앱의 수명 연장과 마이그레이션 ── 유지·래핑·교체 판단표

「VB6로 작성한 핵심 시스템의 일부가 아직 현역이다」「Access로 만든 대장이 실제로는 부서 업무를 떠받치고 있다」──중소기업 상담에서는 이 두 가지가 지금도 꽤 높은 빈도로 나옵니다. 공통점은 만든 본인이 이미 퇴직했거나, 동작하는 이유를 아무도 정확히 설명하지 못한다는 것입니다. 그래도 고장 없이 돌아가고 있으므로 우선순위는 아무래도 낮아지기 쉽습니다.

이 블로그에서는 지금까지 COM / ActiveX / OCX란 무엇인가, ActiveX / OCX의 유지·래핑·교체 판단표, VBA의 제약과 장래성과 같이 개별 기술 요소를 다뤄 왔습니다. 이 기사에서는 대상을 좁혀, 일본 중소기업에 지금도 널리 남아 있는 2대 레거시 자산──VB6 애플리케이션과 Microsoft Access 업무 앱──에 대해 「이대로 유지할지」「일부만 래핑해 수명을 연장할지」「교체할지」를 판단하는 실무 가이드를 정리합니다. 판단의 틀은 ActiveX / OCX 기사에서 쓴 「유지·래핑·교체」 세 가지 선택을 그대로 따르지만, 대상이 바뀌면 리스크의 내용도 바뀌므로 이 기사 고유의 논점을 중심으로 정리합니다.

이 기사를 읽기 위한 전제는 두 가지뿐입니다. 하나는 VB6도 Access도 COM(ActiveX / OCX)을 기반으로 한 32bit 중심 기술이며, 64bit화된 지금의 Windows·Office와의 맞물림이 문제가 되기 쉽다는 점입니다. 다른 하나는 판단의 틀로 「유지·래핑·교체」 세 가지 선택을 쓴다는 점입니다. COM이나 VBA 같은 개별 기술의 자세한 설명은 본문에서도 그때그때 링크하지만, 전제 지식으로 모아 읽고 싶다면 말미 「관련 기사」에 모두 나와 있으므로, 처음 읽을 때는 본문 링크를 따라가지 않고 이어서 읽으셔도 됩니다.

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 부품은 새 PC로 바꾼 순간에 동작하지 않게 되는 경우가 있습니다.³⁴
• 공유 폴더에서 여러 사람이 동시에 .accdb를 여는 운영은 지금도 현장에서 많은 반면, 손상·성능 저하 리스크 요인입니다. 네트워크를 넘는 쓰기는 연결이 불안정해졌을 때 데이터 손상으로 이어질 수 있다고 안내되어 있습니다.⁵ 대장의 규모나 동시 이용 인원이 늘어났다면 SQL Server 등으로의 업사이즈를 검토할 단계입니다.
• 판단의 축은 ActiveX / OCX 때와 같으며, 그 자산이 단순한 화면인지, 업무 로직과 데이터를 품은 경계면인지입니다. 안정적으로 돌아가고 범위가 닫혀 있으면 유지, 일부만 현대화하고 싶으면 래핑, UI나 실행 기반의 제약이 사업을 발목 잡고 있으면 교체, 라는 순으로 생각합니다.
• 이 기사에서 말하는 「래핑」이란 오래된 자산 자체에는 손대지 않고, 그 주변에 새로운 창구(별도 프로세스의 COM 서버, SQL Server로의 연결된 테이블, Web API 등)를 마련해 밖에서는 새로운 구조로 다룰 수 있게 하는 것입니다. 속을 다시 만들지 않으므로 공수를 가늠하기 쉽고, 리스크가 높은 부분만 먼저 현대화하기 위한 일시적 거점으로 씁니다(제 8장).

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

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

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

한편 같은 발표 안에서 VB6 런타임은 그것이 포함된 Windows 버전의 지원 기간 동안은 동작 대상이다라고도 말하고 있습니다. 기존 VB6 앱은 지원 대상 Windows에서 「그대로 동작한다」고 기대되며, 지원 범위는 심각한 후퇴(회귀, regression)와 중대한 보안 문제에 대한 대응으로 한정된다고 되어 있습니다.¹ 즉 「새 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 둘 다 제공되지만 한 대의 PC에는 어느 한쪽만 설치할 수 있으며, 그 PC의 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가 동작하지 않는 원인과 확인 절차」에 정리되어 있습니다.

「누가 누구의 비트 수에 묶이는지」는 헷갈리기 쉬우므로, 의존 관계를 표로 둡니다(각 행의 근거는 본 절 및 제 2장에서 든 출처와 같습니다).

표의 세로 배열이 그대로 사고의 전파 경로가 됩니다. Office의 비트 수(1행)가 바뀌면 ACE도, Access가 로드하는 부품도, 그것에 연결하는 자체 앱도 한꺼번에 영향을 받는다는 구도입니다. PC 갱신 전에 확인할 첫 항목은 항상 「새 PC의 Office는 몇 bit인가」입니다.

3.2 공유 폴더에서 여러 명이 함께 쓰는 리스크

Access 앱의 또 다른 단골 구성이 공유 폴더에 둔 .accdb를 여러 사람이 동시에 여는 운영입니다. 소규모라면 오랜 기간 문제없이 동작하지만, 본질적으로 위태로운 구성입니다. 네트워크를 넘는 쓰기는 연결이 불안정해졌을 때 쓰기 실패나 파일 손상으로 이어질 수 있다고 안내되어 있고, ⁵ 파일 서버 접근이 지연·타임아웃됐을 때 Access가 디스크/네트워크 오류를 보고하는 사례도 오래전부터 알려져 있습니다.⁷ 손상의 원인 자체는 공유 파일에 대한 동시 접근이라는 점에서, 이 블로그의 「파일 연동의 배타 제어 기초 지식」에서 다룬 경합 패턴과 구조가 비슷합니다. Access는 잠금 파일(.laccdb)에 의한 배타 제어를 내장하고 있지만, Wi-Fi 경유 노트북, VPN 너머의 재택 이용, 슬립 복귀 후의 재연결과 같이 「연결이 불안정해지기 쉬운 경로」가 늘수록 사고율은 올라갑니다.

동시 이용 인원이 늘거나 처리가 무거워졌을 때의 흔한 탈출구가 Access 테이블을 SQL Server나 Azure SQL로 옮기고, Access 쪽은 연결된 테이블로 참조하는 구성입니다. SQL Server Migration Assistant(SSMA) 같은 도구로 Access 테이블을 이전한 뒤, 원래 Access 테이블을 이전 대상 테이블로의 링크로 바꿔 넣으면 화면(폼·리포트·쿼리)은 그대로 두고 데이터만 더 견고한 기반으로 옮길 수 있습니다.⁸ 다만 연결된 테이블화에는 집계 처리가 느려진다(서버 쪽에서 실행하지 못하는 함수에 의존하면 Access가 테이블 전체를 로컬로 끌어내린 뒤 처리한다), AutoNumber 열의 동작이 바뀐다는 이전 후 특유의 문제가 알려져 있으며, 패스스루 쿼리나 뷰로의 교체가 필요해지는 장면도 있습니다.⁸ 또한 Access 애플리케이션은 테이블을 가진 「백엔드」 데이터베이스와 화면·쿼리·매크로를 가진 「프론트엔드」 데이터베이스로 나누는 설계가 오래전부터 권장되어 왔습니다.⁹ 여기서 중요한 것은 나누기만 해서는 부족하다는 점입니다. 백엔드(테이블)만 공유 폴더에 두고, 프론트엔드는 각 사용자 PC에 복사해 배치하고 각자의 로컬 복사본에서 이용하는 것이 올바른 구성입니다. 프론트엔드까지 공유 폴더의 한 파일을 전원이 계속 여는 운영은, 분할했더라도 「화면·쿼리·매크로를 공유 파일에 대해 동시에 읽고 쓰는」 리스크가 남은 채이며, 열기까지의 대기 시간 악화나 디자인 변경 시 경합 같은 문제를 일으킵니다. 공유 폴더 운영 그대로 수명을 연장하든 SQL Server로 모으든, 먼저 「백엔드 공유」와 「프론트엔드의 각 PC 배치」가 둘 다 되어 있는지가 첫 체크포인트가 됩니다.

그림으로 그리면 다음 형태입니다. 실선이 현황(공유 폴더 백엔드로의 링크), 파선이 동시 이용이 늘었을 때의 이전 대상입니다.

flowchart TB
    subgraph CLIENTS["각 사용자의 PC ── 1인에 1개 복사본을 배치한다"]
        FE1["프론트엔드 .accdb<br/>폼·쿼리·리포트·VBA"]
        FE2["프론트엔드 .accdb<br/>같은 내용의 다른 복사본"]
    end
    BE["공유 폴더의 백엔드 .accdb<br/>테이블만 둔다"]
    SQL[("SQL Server / Azure SQL<br/>동시 이용이 늘면 여기로 옮긴다")]
    FE1 -->|"연결된 테이블"| BE
    FE2 -->|"연결된 테이블"| BE
    BE -.->|"업사이즈"| SQL
    FE1 -.->|"이전 후의 링크 대상"| SQL
    FE2 -.->|"이전 후의 링크 대상"| SQL

그림 1: 백엔드와 프론트엔드의 분할과, 그 앞의 업사이즈. 프론트엔드를 공유 폴더에 하나만 두고 전원이 여는 형태가 흔한 오류입니다. 이전할 때도 화면(프론트엔드)은 그대로 두고, 링크 대상만 SQL Server로 바꿉니다.

4. 판단표

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

보충하면, 이 표의 「래핑」은 많은 경우 데이터만, 또는 경계만 먼저 현대화하고 화면이나 조작감은 일단 유지한다는 뜻입니다. 전부를 한 번에 다시 만드는 것이 아니라, 리스크가 높은 부분부터 손대기 위한 일시적 거점으로 봐 주세요.

판단표 사용법은 먼저 「대상」 행을 좁힌 다음, 「이용 상황·리스크 요인」에 자신의 상황이 해당하는지를 확인합니다. 같은 VB6 앱이라도 어떤 화면은 유지, 어떤 기능은 래핑처럼 행 단위·기능 단위로 판단을 나눠도 된다는 점이 중요합니다. 「VB6 앱이니까 전부 같은 취급」으로 묶으면, 원래 유지할 수 있었을 안정 부분까지 끌어들여 공수가 부풀어 오릅니다.

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

판단표를 실제 상담에 대입하면 대체로 다음 3가지 패턴으로 모이는 경우가 많습니다.

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

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

시나리오 3: 개발자가 퇴직한 VB6 핵심 앱, Web화 요구가 있다. 소스는 있지만 손댈 사람이 없고, 사외에서도 쓰고 싶다는 요구까지 나온 상황에서는 판단표가 「교체」 쪽으로 기울니다. 다만 핵심 시스템일수록 한꺼번에 전면 재작성하는 것은 리스크가 너무 큽니다. 제 9장 절차대로 먼저 업무 로직 정리와 영향 범위가 작은 기능 잘라 내기부터 시작해, 단계 이전으로 진행하는 것이 현실적입니다.

6. 흔한 안티패턴

VB6·Access의 수명 연장·마이그레이션 건에서 반복해서 보는 실패 패턴을 먼저 공유합니다. 판단표를 대입하기 전에 여기에 해당하지 않는지부터 확인하세요.

이 가운데 발생 빈도가 특히 높은 것은 비트 수 혼재 방치와 공유 폴더 이용자 확대 두 가지입니다. 둘 다 「오늘 깨진다」는 이야기가 아니라, PC 갱신이나 이용자 증가처럼 언젠가 반드시 오는 계기로 표면화한다는 공통점이 있습니다.

7. 유지하는 경우의 현실적인 리스크 경감책

유지라는 판단이 현실적인 경우는 많고, 그 자체는 잘못이 아닙니다. 다만 「동작하니까 손대지 않는다」를 이어 갈수록, 전제를 아무도 설명하지 못하게 되는 리스크는 쌓입니다. 최소한 다음은 손봐 두어야 합니다.

• 백업의 세대 관리를 기계적으로 돌린다. Access의 .accdb는 한 파일로 끝나므로, 일 단위로 세대 백업만 받아도 상당한 사고를 흡수할 수 있습니다. VB6 앱은 소스 전체(.vbp, .frm, .bas, .cls)와 의존하는 OCX·DLL·레지스트리 등록 정보까지 묶어 보존합니다.
• 후임자 부재 대책으로 실행 환경 전제를 문서화한다. 대응 OS, Office의 비트 수, 필요한 런타임·의존 DLL·등록 절차를, 적어도 「새 PC에서 동작하지 않게 됐을 때 무엇을 확인하면 되는지」가 보이는 수준으로 남깁니다.
• 실행 환경을 의도적으로 고정한다. Windows나 Office의 자동 업데이트로 비트 수나 기본 설정이 바뀌는 것이 사고의 방아쇠가 되므로(제 3.1절), 대상 PC만은 업데이트 정책을 나누고, 업데이트 전에 검증한 뒤 배포하는 운영으로 합니다.
• 클린 환경에서의 스모크 테스트를 마련한다. 새 PC에 배포하기 전에, 깨끗한 환경에서 설치·등록·시작·주요 조작이 통과하는 것을 확인할 수 있는 절차를 마련해 두면, 배포할 때마다 「동작해야 하는데 동작하지 않는다」로 멈추는 시간을 줄일 수 있습니다.
• 호출 지점을 한곳으로 모은다. 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 / Web으로 옮긴다. Access 앱 안에는 폼 뒤에 업무 로직이 짙게 들어 있는 경우와, 단순한 데이터 입력·목록 표시에 그치는 경우가 섞여 있습니다. 먼저 VBA 모듈을 정리하고, 다른 시스템에 의존하지 않는 순수한 계산·검증 로직부터 .NET 클래스 라이브러리로 잘라 내, Access 쪽에서는 COM 경유 또는 중간의 Web API 경유로 호출하는 형태로 바꿔 가는 진행이 현실적입니다. VBA 자체의 제약과, 어디까지를 VBA에 남겨야 하는지의 판단 축은 「VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면」에서 자세히 정리하고 있습니다.

(c) UI만 먼저 교체하고, 데이터와 로직은 남겨 둔다. Access 폼이 오래됐다, 느리다, 사외에서 쓰지 못한다는 불만이 중심이면, 데이터 계층(SQL Server화한 테이블)과 로직은 그대로 두고 UI만 Web이나 데스크톱의 새 기술로 바꾸는 선택지가 있습니다. 제 3.2절의 연결된 테이블화와 조합하면 「데이터는 SQL Server, 구 UI(Access)와 신 UI가 같은 데이터를 본다」는 과도기적 이중 가동도 가능합니다. 다만 Access 쪽 VBA가 UI와 로직을 강하게 결합하고 있으면, 이 분리 작업 자체가 (b)의 정리를 먼저 끝내지 않으면 성립하지 않습니다.

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

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

9. 교체하는 경우의 진행 방법

교체를 고르는 것은 UI나 비트 수 제약이 사업 속도를 직접 가로막고 있거나, 개발자가 없어 유지보수 자체가 어려운 상황입니다. 전면 재작성을 한꺼번에 시작하지 말고, 다음 순서를 밟으면 사고가 줄어듭니다.

1. 데이터 마이그레이션 검증을 먼저 한다. Access → SQL Server 같은 데이터 이전에서는 AutoNumber 채번 타이밍의 차이, 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의 취급을 정할 때 먼저 봐야 할 것은 「오래됐는지」가 아니라 다음 세 가지입니다.

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

이 세 가지가 정리되면, 「유지」라면 실행 환경을 고정하고 백업과 문서화를 게을리하지 않으며(제 7장), 「래핑」이라면 32/64bit 브리지나 단계적인 .NET/Web화로 데이터와 로직을 지키고(제 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)는 한 대의 PC에 32bit/64bit 중 한쪽만 들어가며, Office의 비트 수와 일치시켜야 합니다. 게다가 64bit 버전 Office는 32bit ActiveX 컨트롤이나 COM 추가 기능을 로드하지 못하므로, 예전의 32bit 전제로 만든 부품이 새 PC에서 동작하지 않게 됩니다.

공유 폴더에서 여러 사람이 Access 파일을 여는 운영은 문제가 있습니까?

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

VB6/Access 앱은 유지·래핑·교체 중 어느 것을 골라야 합니까?

판단의 축은 그 자산이 단순한 화면인지, 업무 로직과 데이터를 품은 경계면인지입니다. PC나 Windows 버전이 고정되어 있고 변경 요구도 작다면, 백업·문서화·실행 환경 고정을 전제로 유지하는 편이 비용 대비 효과에 맞습니다. 64bit 연동이나 데이터 기반 강화가 필요하면 COM 브리지나 SQL Server로의 연결된 테이블화로 일부만 래핑합니다. 개발자가 없고 유지보수가 어려워지거나 Web화가 필요하면 교체이지만, 한꺼번에 전면 재작성하는 것이 아니라 데이터 마이그레이션 검증과 업무 로직 정리를 먼저 하는 단계적 이전이 현실적입니다.

저자 프로필

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

Go Komura

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

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