VB6 앱은 언제까지 동작하는가 ── 런타임 지원 현황과 현실적인 .NET 이전 진행 방법

「이 VB6 시스템, 언제까지 동작합니까」──기존 시스템 상담에서 가장 많이 나오는 질문 중 하나입니다.

답은 의외로 명확합니다. 마이크로소프트가 공식 지원 정책을 내놓고 있습니다. 다만 그 내용은 「런타임은 당분간 동작한다. 그러나 개발의 뒷받침은 이미 없다」는 비대칭입니다. 이 비대칭을 제대로 이해하지 못하면 「아직 동작하니 괜찮다」와 「지금 당장 전부 다시 만들어야 한다」는 양극단으로 흔들립니다.

이 블로그에서는 「VB6 / Access 업무 앱의 연명과 이전 ── 남기다·감싸다·교체하다의 판단표」에서 VB6 자산을 어떻게 다룰지를 정하기 위한 판단을 정리했습니다. 이 기사는 그 후속으로, 「교체한다(이전한다)」고 정한 뒤, 혹은 정하기 위해, VB6에서 .NET으로의 이전을 실제로 어떻게 진행할지로 들어갑니다.

이 기사에서 쓰는 용어

VB6 세대를 직접 모르는 독자도 있을 것이므로, 먼저 용어를 정리합니다.

1. 먼저 결론

• VB6의 IDE(개발 환경)는 2008년 4월 8일에 지원이 종료되었습니다. VB6 앱을 작성·유지보수하는 지원된 수단은 더 이상 없으며, 마이크로소프트는 모던한 기술로의 교체를 강하게 권장하고 있습니다.³
• 한편 VB6 런타임은 「함께 제공되는 Windows의 지원 기간 중」에는 지원 대상입니다. 대상 OS 목록에는 Windows 11, Windows 10, Windows Server 2025 등이 포함되어 있으며, 기존 앱은 「그대로 동작한다(It Just Works)」가 목표로 되어 있습니다.⁴ 즉 「언제까지 동작하는가」에 대한 답은, 실행만 보면 Windows 지원이 이어지는 한입니다.
• 다만 그 지원 범위는 기존 앱에 대한 심각한 리그레션과 중대한 보안 문제 대응에 한정됩니다. 또한 런타임은 32bit 전용이며, 64bit Windows에서는 WOW64 환경에서만 지원됩니다.⁴
• 진짜 리스크는 「동작하지 않게 되는 것」보다 고칠 수 없게 되는 것입니다. IDE의 입수·유지가 해마다 어려워지고, 참조 중인 OCX의 벤더 지원이 끊기며, 코드를 짤 수 있는 사람이 퇴사합니다. 이 세 가지는 Windows 지원 기간과 무관하게 진행됩니다.
• 이전 진행 방식에는 전면 재작성·자동 변환·단계 이전의 3계통이 있습니다. 먼저 정할 것은 방식이 아니라 자산 파악이며, 화면 수·외부 연동·OCX·API 선언의 양을 파악한 뒤에 방식을 고릅니다.
• 이전 대상 언어는, 새로 쓰는 부분은 C#을 권장합니다. VB.NET(Visual Basic)은 안정 노선이 공식으로 명시되어 있으며, 새로운 구문·새로운 워크로드로의 확장은 이루어지지 않습니다.⁵

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

2. 「언제까지 동작하는가」의 정확한 답 ── 지원 정책을 읽는 법

마이크로소프트의 VB6 지원 정책은 VB6를 세 구성 요소로 나눠 설명합니다.⁴

대상 OS 표에서는 Windows 11·Windows 10, Windows Server 2012~2025에서 「런타임: 지원」「IDE: 미지원」이라고 명시되어 있습니다.⁴

읽는 법의 핵심은 세 가지입니다.

첫째, 런타임 지원은 Windows 라이프사이클에 완전히 종속됩니다. 「VB6 런타임의 지원 기한」이라는 독립된 날짜는 없으며, 사용 중인 Windows의 지원 종료가 그대로 기한입니다.

둘째, 지원의 내용은 「계속 동작하는 것」의 보증에 가깝습니다. 대응하는 것은 심각한 리그레션(OS 업데이트로 기존 앱이 깨진 경우)과 중대한 보안 문제뿐이며, 개별 조사나 기능 개선은 포함되지 않습니다.⁴

셋째, VB6 앱은 앞으로도 32bit 프로세스로만 살아남을 수 있습니다. 런타임은 32bit 전용이며, 64bit OS에서는 WOW64 에뮬레이션 환경에서만 지원됩니다.⁴ 64bit 전용 DLL이나 SDK와 연동해야 하는 시점이 오면, 단일 프로세스만으로는 끝나지 않습니다. 이 벽을 넘는 방법은 「32bit 앱에서 64bit DLL을 호출하는 COM 브리지 사례」에서 다룹니다.

3. 「동작한다」와 「유지할 수 있다」는 다른 문제

지원 정책만 보면 「서두를 필요는 없다」고 읽힐 수 있습니다. 그러나 실무에서는 실행 환경보다 먼저 개발과 유지보수의 환경이 무너져 갑니다.

• IDE를 마련할 수 없다. VB6 IDE는 현행 OS에서 지원 대상이 아니며, 정식 입수 수단·설치 수단을 유지하기가 해마다 어려워지고 있습니다. 「고칠 수 있는 환경이 사내에 한 대밖에 없다」는 상태는 드물지 않습니다.
• 서드파티 OCX의 벤더 지원이 끊겨 있다. 지원 정책도 서드파티 컨트롤은 벤더 쪽 책임 범위라고 명시합니다.⁴ 그리드나 장표 OCX가 이미 입수 불가인 경우는 많으며, 이 판단에는 「ActiveX / OCX를 지금 어떻게 다룰까」에서 정리한 내용을 그대로 적용할 수 있습니다.
• 코드를 짤 수 있는 사람이 없어진다. 언어 사양의 문제가 아니라 사람의 문제입니다. 새로 VB6를 배우는 기술자는 거의 공급되지 않으므로, 유지보수할 수 있는 인원은 줄어들기만 합니다.
• 주변 요건이 32bit 벽에 부딪힌다. 새로운 기기 SDK, 인증 라이브러리, 클라우드 연동 등이 64bit 전제·.NET 전제가 되어, VB6 프로세스에 넣을 수 없는 요구가 늘어갑니다.

즉 「언제까지 동작하는가」는 문제의 절반일 뿐입니다. 나머지 절반은 「다음에 수정이 필요해졌을 때, 고칠 수 있는 체제가 남아 있는가」입니다. 이전 계획은 장애가 난 뒤가 아니라, 고칠 수 있는 사람과 환경이 남아 있는 동안에 세워야 합니다.

4. 이전 방식의 판단표

「교체한다」고 정한 경우에도 진행 방식에는 폭이 있습니다. 주요 방식을 정리합니다.

어느 것을 고를지는 코드 줄 수만으로 정해지지 않습니다. 마이크로소프트 자신도 이전에 즈음해 공식 가이드와 함께 업그레이드·이전 파트너(이전 도구 벤더를 포함) 이용을 안내하고 있어³, 기계 변환이라는 선택지는 실제로 존재합니다. 다만 어느 방식이든 공통으로 필요한 것이 다음 장의 자산 파악입니다.

4.1 「변환 도구」란 구체적으로 무엇인가

「자동 변환 도구」로 묶어 적었지만, 마이크로소프트는 VB6 파트너 제품을 실명으로 안내하는 페이지를 공개하고 있습니다. 「Visual Basic 6.0에서 Visual Basic .NET으로의 더 완전한 이전을 지원하는, 파트너의 무상·유상 도구와 솔루션」이라는 위치이며, 다음 세 가지가 거론됩니다.⁶

위는 마이크로소프트 페이지에 실린 설명의 요약이며, 당사가 추천·보증하는 것은 아닙니다. 선정은 반드시 자사 코드로 시험한 뒤에 해 주세요. 볼 관점은 다음과 같습니다.

마지막 「반복할 수 있는지」는 놓치기 쉬운 관점입니다. 이전 기간 중에도 VB6 쪽에는 장애 대응이 들어갑니다. 한 번만 변환할 수 있는 도구라면, 그 수정을 신구 양쪽에 손으로 계속 넣게 됩니다.

참고로 「현상 유지+문서화」를 고르는 경우의 실무(실행 환경 고정, 백업, 리스크를 떠안는 방법)는 이전 VB6 / Access 기사에서 다룹니다.

5. 이전 전 자산 파악 ── 코드보다 먼저 조사할 것

산정과 방식 선정의 정밀도는 자산 파악의 정밀도로 정해집니다. 최소한 다음을 목록화합니다.

1. 화면과 장표 목록 ── 폼 수, 실제로 쓰이는 화면(쓰이지 않는 화면의 이전은 낭비가 됩니다), 장표의 종류와 출력처(프린터 직접 인쇄인지, Excel 경유인지)
2. 외부 연동 목록 ── 데이터베이스(ADO/DAO/RDO 중 무엇이며, 연결 대상은 무엇인지), 파일 입출력, 시리얼·소켓 통신, 다른 시스템 호출
3. OCX / ActiveX / COM 참조 목록 ── 프로젝트 파일(.vbp)의 참조에서 기계적으로 추출할 수 있습니다. 각 컴포넌트의 입수 가능 여부·대체 유무가 방식 선정에 직결됩니다
4. Win32 API 선언(Declare 문) 목록 ── API의 용도(인쇄, INI 읽기/쓰기, 창 조작 등)마다, .NET 쪽 표준 기능으로 대체할 수 있는지를 분류합니다
5. 코드에만 있는 업무 규칙 ── 단수 처리, 날짜 마감, 거래처별 예외 등. 「왜 이렇게 적혀 있는지 아무도 모르는」 지점이야말로 이전 후 결함의 온상입니다
6. 테스트 수단의 유무 ── 이전이 맞았는지를 무엇과 비교해 확인할지. 많은 경우, 구 시스템의 출력(장표, CSV, DB 내용)과의 대조가 가장 실용적인 검증 수단이 됩니다

이 자산 파악은 전면 재작성을 고르지 않는 경우에도 낭비가 되지 않습니다. 오히려 자산 파악의 결과, 「전면 재작성이라고 생각했지만, 실은 core 로직은 DB 쪽으로 모을 수 있다」「이 10개 화면만 먼저 옮기면 64bit 벽을 넘을 수 있다」와 같은 단계 이전의 실마리가 나오는 것이 보통입니다.

5.1 「기계적으로 추출할 수 있습니다」의 내용 ── .vbp에서 참조 부품을 뽑아 내기

세 번째 항목에 「.vbp의 참조에서 기계적으로 추출할 수 있습니다」라고 적었습니다. 그 방법을 구체적으로 보입니다.

프로젝트 파일(.vbp)은 ASCII 텍스트 파일입니다. 마이크로소프트 공식 문서에도 내용 예가 실려 있으며, 참조 설정은 다음 형태의 한 줄로 기록됩니다.⁷

Type=Exe
Form=B_Form.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\WINDOWS\SYSTEM\STDOLE2.TLB#OLE Automation
Form=A_Form.frm
Module=CModule; C_Module.bas
Class=DClass; D_Class.cls
Startup="BForm"
Name="Project1"

Reference= 값은 #로 구분되며, GUID(타입 라이브러리 ID) → 버전 → 로케일 → 파일 경로 → 설명(라이브러리 이름) 순입니다. 위 예에서는 OLE Automation이 설명에 해당합니다. 화면에 붙인 ActiveX 컨트롤(OCX)은 Object= 행으로 기록되므로, 이 두 종류의 행을 모으면 「이 프로젝트가 의존하는 외부 부품 목록」이 됩니다.

프로젝트가 수십 개인 시스템에서는, 다음과 같은 스크립트로 일괄 뽑아냅니다.

# 폴더 아래의 모든 .vbp에서, 참조 중인 부품 행을 뽑아 CSV로 만든다
# 동작 환경: Windows PowerShell 5.1
Get-ChildItem -Path . -Filter *.vbp -Recurse | ForEach-Object {
    $project = $_.FullName
    Get-Content -LiteralPath $project | Where-Object {
        $_ -like 'Reference=*' -or $_ -like 'Object=*'
    } | ForEach-Object {
        $kind, $value = $_ -split '=', 2
        [pscustomobject]@{
            Project = $project
            # Reference = 참조 설정한 타입 라이브러리 / Object = 화면에 붙인 ActiveX 컨트롤
            Kind    = $kind
            Entry   = $value
        }
    }
} | Sort-Object Kind, Entry | Export-Csv .\vb6-components.csv -NoTypeInformation -Encoding UTF8

나온 CSV에서 중복을 제거하고 늘어놓으면, 「이 시스템은 결국 어느 COM 부품에 의존하는가」가 반나절이면 목록이 됩니다. 나머지는 한 건씩, 입수 가능한지·벤더 지원이 있는지·.NET 쪽 대체가 있는지를 채워 가면 됩니다. 이 표가 그대로 제4장의 방식 선정과 산정의 토대가 됩니다.

같은 발상으로, Declare 문 목록도 .bas / .frm / .cls를 가로질러 Declare를 포함한 행을 줍으면 만들 수 있습니다. 자산 파악에서 수작업에 의존해야 하는 것은 「코드에만 있는 업무 규칙」뿐이며, 그 외는 거의 기계화할 수 있습니다.

5.2 공수와 기간을 산정하는 방법

「화면 한 장당 며칠」이라는 숫자는, 화면의 복잡도, OCX 유무, 업무 로직의 밀도, 요구되는 테스트의 엄격함에 따라 쉽게 한 자릿수가 바뀝니다. 다른 회사의 사례 값을 그대로 가져와서는 맞지 않습니다. 대신, 자사 수치를 만드는 절차를 둡니다.

1. 센다. 자산 파악에서 화면 수·장표 수·외부 연동 수·OCX 종류 수·Declare 문 수·테이블 수를 확정합니다.
2. 난이도로 가른다. 화면을 대략 3단계로 나눕니다(단순한 목록·참조 화면/입력과 검증이 있는 화면/그리드나 장표 미리보기를 포함한 화면).
3. 각 단계에서 한 장씩, 실제로 이전한다(파일럿). 설계·구현·단위 테스트·구 시스템과의 출력 대조까지 포함한 실시간을 잽니다. 여기가 산정의 단가가 됩니다.
4. 곱해 쌓는다. 3에서 얻은 단가를 2의 장수에 곱해 쌓아 올립니다.
5. 별도 항목을 더한다. 공통 부분(인증, 로그, 인쇄 기반, 배포, 환경 구축)과 「코드에만 있는 업무 규칙」의 해독 시간은 화면 수에 비례하지 않습니다. 이 별도 항목이 빠진 산정은 반드시 부족합니다.
6. 맞지 않으면 방식으로 돌아간다. 파일럿 실측이 예상보다 크게 나쁘면, 그것은 산정의 오차가 아니라 방식 선정의 오류 신호입니다. 제4장으로 돌아가 전면 재작성·자동 변환·단계 이전을 다시 고릅니다.

요점은, 산정의 근거를 다른 회사의 사례 값이 아니라 자사 파일럿 실측에 두는 것입니다. 파일럿은 비용이 아니라, 산정 정밀도를 사는 투자라고 생각하세요.

6. VB6와 .NET의 주요 비호환 지점

VB6와 VB.NET/C#은 이름이 주는 인상보다 먼 언어입니다. 기계 변환이든 사람 손 재작성이든, 다음 차이는 반드시 설계 판단이 필요합니다.

여기서 중요한 것은, 비호환의 양에 압도되어 전면 재작성만이 유일한 선택이라고 생각하지 않는 것입니다. 반대로, 이 표의 왼쪽(VB6) 자산이 지금도 올바르게 동작하고 있다는 사실 자체가, 이전 때의 가장 좋은 사양서가 됩니다. 구 시스템을 「동작하는 사양서」로 병행 가동하고, 출력을 대조하면서 진행하는 것이 실무적으로는 가장 확실합니다.

7. 단계 이전의 실무 패턴

업무를 멈추지 않고 이전하는 경우, 신구 공존 구성이 핵심이 됩니다. 대표적인 패턴을 세 가지 듭니다. 차이는 한 마디로 「신구의 경계를 어디에 둘 것인가」입니다.

flowchart TB
    subgraph P1["7.1 데이터 계층을 먼저 옮긴다 ── 경계는 데이터베이스"]
      A1["VB6 앱 ── 연결 대상만 전환한다"] --> DB["이전 후의 데이터베이스 ── SQL Server 등"]
      A2[".NET의 새 화면 ── 차례로 늘려 간다"] --> DB
    end
    subgraph P2["7.2 COM 상호 운용으로 연결한다 ── 경계는 COM 인터페이스, 동일 프로세스"]
      B1["VB6 앱 ── 32bit 프로세스"] --- B2["COM 인터페이스"]
      B2 --- B3[".NET 부품 ── 32bit로 빌드해야 한다"]
    end
    subgraph P3["7.3 프로세스를 나눈다 ── 경계는 IPC, 별도 프로세스"]
      C1["VB6 앱 ── 32bit 프로세스"] --- C2["네임드 파이프 / 파일 / localhost 통신"]
      C2 --- C3[".NET 앱 ── 64bit여도 된다"]
    end

그림 1: 단계 이전의 3패턴 ── 신구의 경계를 어디에 둘 것인가

7.1 데이터 계층을 먼저 옮긴다

VB6 앱의 데이터를 Access 파일이나 독자 형식에서 SQL Server 등으로 먼저 옮기고, VB6 쪽은 연결 대상만 바꿔 계속 동작시키는 구성입니다. 데이터가 먼저 현대화되어 있으면, 새 화면(.NET 쪽)은 같은 DB를 보며 단계적으로 늘릴 수 있습니다. Access가 관련된 구체적 절차는 이전 기사의 업사이즈 장을 참조하세요.

7.2 새 기능·새 화면을 .NET으로 만들고, COM 상호 운용으로 연결한다

기존 VB6 화면은 그대로 두고, 새 기능을 .NET으로 만들어 공존시키는 구성입니다. 방향은 두 가지입니다.

• .NET 쪽 부품을 VB6에서 호출한다: .NET 클래스를 COM으로 공개하면, VB6에서는 보통의 COM 컴포넌트로 참조할 수 있습니다. .NET 8 이후에도 형 정보를 갖춰 공개하는 방법을 「.NET 8 DLL을 VBA에서 형 정보를 갖춰 쓰는 방법 - COM 공개와 dscom TLB」에서 해설하고 있으며, 호출 쪽이 VB6여도 발상은 같습니다.
• VB6 쪽 자산을 .NET에서 호출한다: VB6로 만든 ActiveX DLL은 .NET에서 COM 상호 운용으로 참조할 수 있습니다. 로직을 덩어리째 살리고, 화면만 먼저 .NET화하는 경우에 씁니다. 다만 32bit 제약은 남으므로, 영구책이 아니라 이전 기간 중의 다리로 받아들입니다.

다리의 구현은, 최소 구성이라면 몇 줄입니다. 먼저 .NET 쪽 부품을 VB6에서 호출하는 방향입니다. 공개할 인터페이스와 클래스에 특성을 붙입니다.⁸

// .NET 쪽(C# / .NET 8)── VB6에서 호출할 수 있도록 COM 공개한다
using System.Runtime.InteropServices;

[ComVisible(true)]
[Guid("fe103d6e-e71b-414c-80bf-982f18f6c1c7")]   // 인터페이스의 IID. 반드시 직접 새로 생성한다
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITaxCalculator
{
    decimal CalcTax(decimal amount);
}

[ComVisible(true)]
[Guid("9f35b6f5-2c05-4e7f-93aa-ee087f6e7ab6")]   // 클래스의 CLSID. 이것도 새로 생성한다
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Komura.TaxCalculator")]
public class TaxCalculator : ITaxCalculator
{
    public decimal CalcTax(decimal amount) => Math.Floor(amount * 0.1m);
}

csproj에 COM 호스트 생성을 지시해 빌드하고, 생성된 .comhost.dll을 관리자 권한 명령 프롬프트에서 등록합니다.⁸

<PropertyGroup>
  <EnableComHosting>true</EnableComHosting>
</PropertyGroup>

regsvr32 TaxLib.comhost.dll

호출 쪽 VB6는, 평소의 COM 객체와 같습니다.

' VB6 쪽 ── ProgId를 사용한 지연 바인딩 호출
Dim calc As Object
Set calc = CreateObject("Komura.TaxCalculator")
MsgBox calc.CalcTax(12345)
Set calc = Nothing

여기서 반드시 걸리는 함정이 두 가지 있습니다. 둘 다 공식 문서에 적혀 있습니다.⁸

• 기본값으로는 64bit 클라이언트에서만 쓸 수 있습니다. .NET Framework 때와 달리, .NET Core / .NET 5 이후에는 「Any CPU」로 빌드해도 따라오는 *.comhost.dll은 기본이 64bit입니다. VB6는 32bit 프로세스이므로, 이대로는 로드할 수 없습니다(WOW64 제약 그 자체입니다¹). 32bit판 comhost.dll이 나오도록 빌드 구성을 맞추세요.
• 자기 완결형(self-contained) 배포의 COM 컴포넌트는 지원되지 않습니다. 프레임워크 의존 배포만 지원 대상입니다. 배포 방식을 먼저 정한 뒤에 설계하세요.

또 하나, VB6 자산을 .NET에서 호출하는 방향은, VB6 ActiveX DLL을 COM 참조로 추가하기만 하면 됩니다.

// .NET 쪽 ── VB6 ActiveX DLL을 COM 참조해 호출한다
// 사전 준비: 프로젝트에 「COM 참조」를 추가하고, 32bit(x86) 빌드로 해 둔다
var legacy = new LegacyBiz.OrderCalc();      // VB6로 작성된 클래스
decimal total = legacy.CalcTotal(orderId);   // 업무 로직은 VB6 쪽 그대로
Marshal.ReleaseComObject(legacy);            // COM 객체는 명시적으로 해제한다

이쪽도 호출하는 .NET 쪽을 32bit(x86)로 빌드해야 합니다. VB6 ActiveX DLL은 32bit DLL이며, 64bit 프로세스는 32bit DLL을 실행을 위해 로드할 수 없기 때문입니다.¹ 「64bit 새 기능을 넣고 싶은데 VB6 로직도 호출하고 싶다」는 요구는, 이 시점에서 동일 프로세스에서는 성립하지 않습니다. 다음 7.3이 나설 차례입니다.

7.3 프로세스를 나눠 연동한다

COM 상호 운용으로 동일 프로세스에 같이 두면, 비트 수(32bit/64bit)와 장애의 파급이 제약이 됩니다. 64bit 새 기능이 필요한 경우나, 신구의 장애를 분리하고 싶은 경우에는, 별도 프로세스로 나눠 파일·네임드 파이프·localhost 통신 등으로 연동합니다. 프로세스 간 연동의 선택지는 「Windows의 IPC 판단표」에, 32bit→64bit 브리지의 사례는 「COM 브리지 사례」에 정리했습니다.

어느 패턴이든 공통 원칙은, 「신구의 경계를 한곳으로 모으고, 경계를 넘는 데이터의 형식을 고정한다」는 것입니다. 경계가 화면마다·기능마다 제각각 늘어나면, 공존 기간의 비용이 이전의 효과를 잠식합니다.

8. 이전 대상 언어 ── C#인가 VB.NET인가

「VB6에서라면 VB.NET이 자연스럽다」고 생각하기 쉽지만, 현재 마이크로소프트의 언어 전략을 보면 단순하지 않습니다.

공식 언어 전략에서는 Visual Basic(VB.NET)을 「안정된 설계를 유지하는, 알기 쉽고 친숙한 언어」로 두고, 새 기능은 원칙적으로 소비(consumption-only)만이며 새 구문은 추가하지 않는다, 새 워크로드로의 확장은 하지 않는다는 방침이 명시되어 있습니다. 한편 Windows Forms나 라이브러리 같은 핵심 시나리오에 대한 투자와, Visual Studio상의 개발 경험 개선은 계속된다고 되어 있습니다.⁵

이를 이전의 관점에서 읽으면 다음과 같습니다.

• VB.NET을 골라도, 기존 시나리오(WinForms 업무 앱)는 당분간 문제없이 성립합니다. VB6 경험자가 많고, 문법의 가까움이 학습 비용을 낮추는 팀에서는 합리적인 선택입니다.
• 다만, 앞으로 새로 쓸 자산의 토대로는 C#을 권장합니다. 언어와 생태계의 진화가 이어지고 있으며, 샘플·라이브러리·인력의 공급도 C#에 모입니다. 「VB6 유지보수 인력이 없다」는 문제를, 10년 뒤에 「VB.NET 유지보수 인력이 없다」는 문제로 반복하지 않기 위한 선택입니다.
• 절충안으로, 변환 도구의 출력은 VB.NET으로 받고, 신규 개발은 C#으로 쓰는 구성도 취할 수 있습니다. .NET에서는 두 언어의 어셈블리를 서로 참조할 수 있으므로, 언어를 섞는 것 자체는 장애가 되지 않습니다.

화면 프레임워크 선택(WinForms / WPF / WinUI)은 「WinForms·WPF·WinUI의 판단표」를, .NET Framework가 아니라 현행 .NET으로 직접 이전할 때의 확인 사항은 「.NET Framework→.NET 이전 전 체크리스트」를 참조하세요. VB6에서의 이전에서 굳이 .NET Framework 4.8을 새로 채택할 이유는, 참조 라이브러리의 제약이 없는 한 없습니다.

9. 정리

• 「VB6는 언제까지 동작하는가」에 대한 답은, 런타임은 Windows 지원 기간 중에는 동작 대상(Windows 11도 대상)입니다. 다만 IDE는 2008년에 지원이 종료되어, 다시 만들거나 고치는 수단의 공식 뒷받침은 이미 없다는 비대칭 상태입니다.⁴³
• 진짜 기한은 OS가 아니라, 고칠 수 있는 환경과 사람이 남아 있는가로 정해집니다. 이전 계획은 장애 발생 후가 아니라, 구 시스템이 「동작하는 사양서」로 쓸 수 있는 동안에 세웁니다.
• 진행 방식은 전면 재작성·자동 변환·단계 이전의 3계통입니다. 방식 선정 전에, 화면·외부 연동·OCX·API 선언·코드에만 있는 업무 규칙의 자산 파악을 합니다.
• 업무를 멈추지 않는 이전에서는, 데이터 계층 선행·COM 상호 운용·프로세스 분리 중 하나로 신구를 공존시키고, 경계를 한곳으로 모읍니다.
• 새로 쓰는 부분의 언어는 C#을 권장합니다. VB.NET은 안정 노선이 공식 방침이며⁵, 장기 유지보수의 토대로는 C# 쪽이 유리합니다.

9.1 다음 한 걸음 ── 처음 1주일 동안 할 일

「이전을 검토한다」에서 멈추지 않기 위한, 바로 착수할 수 있는 단위의 체크리스트입니다. 코드는 한 줄도 쓰지 않습니다.

• 소스 코드 전체가 어디에 있는지 확인한다. 최신 운영 실행 파일과 맞춰 보고, 그 소스가 정말 현행판인지 확인한다(제3장과 같이, 여기가 어긋나면 이후가 전부 낭비가 됩니다)
• VB6 IDE가 동작하는 단말을 확인한다. 몇 대인지, 그 OS는 무엇인지, 고장 나면 재구축할 수 있는지
• .vbp에서 참조 부품을 목록화한다. 제5장의 스크립트를 그대로 돌려 CSV로 만든다
• 목록의 각 부품에 「입수 가능 여부/벤더 지원/.NET 쪽 대체」 3열을 더해 채운다. 채워지지 않는 칸이 이전의 난관입니다
• 화면과 장표를 센다. 그 위에서 현장에 「실제로 쓰는 화면」을 확인한다. 쓰이지 않는 화면을 이전하지 않는 것만으로 공수는 크게 바뀝니다
• Declare 문을 가로질러 추출한다. 용도별로 분류하고, .NET 표준 기능으로 대체할 수 있는지를 가른다
• 검증의 기준을 정한다. 이전 후의 옳음을 무엇과 비교해 확인할지(장표, CSV, DB 내용)를 하나 정해 둔다
• 32bit 때문에 막혀 있는 요건이 있는지 확인한다. 있다면, 그 한 점이 방식 선정의 최우선 조건이 됩니다

여기까지면 제4장의 방식 선정과, 제5장의 파일럿으로 나아갈 재료는 갖춰집니다.

관련 기사

• VB6 / Access 업무 앱의 연명과 이전 - 남기다·감싸다·교체하다의 판단표
• ActiveX / OCX를 지금 어떻게 다룰까 - 남기다·감싸다·교체하다 판단표
• 32bit 앱에서 64bit DLL을 호출하는 COM 브리지 사례
• .NET 8 DLL을 VBA에서 형 정보를 갖춰 쓰는 방법 - COM 공개와 dscom TLB
• .NET Framework→.NET 이전 전 체크리스트
• WinForms·WPF·WinUI의 판단표
• VBA란 무엇인가 - 제약, 장래성, 교체해야 할 장면과 현실적인 이전 패턴

관련 상담 영역

합동회사 코무라소프트에서는, VB6를 포함한 기존 자산의 파악과 이전 방침 정리, COM 브리지·프로세스 분리에 의한 신구 공존 구성의 설계·구현, .NET으로의 단계적 리플레이스를 다룹니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

VB6 앱은 Windows 11에서도 동작합니까?

동작 대상입니다. 마이크로소프트의 지원 정책에서는 VB6 런타임(msvbvm60.dll 등)이 함께 제공되는 Windows 버전의 지원 기간 중에는 지원 대상이며, 대상 OS 목록에는 Windows 11·Windows 10이나 Windows Server 2025 등이 포함되어 있습니다. 다만 지원 범위는 기존 앱에 대한 심각한 리그레션과 중대한 보안 문제 대응에 한정됩니다. 또한 VB6 런타임은 32bit 전용이며, 64bit Windows에서는 WOW64라는 32bit 호환 환경 안에서만 지원됩니다.

VB6에서 .NET으로의 이전은 자동 변환 도구만으로 끝낼 수 있습니까?

끝낼 수 없다고 봐야 합니다. 변환 도구는 화면 정의나 단순한 로직의 재작성을 줄여 주지만, On Error에 의한 오류 처리, Variant 형이나 기본 속성에 의존한 코드, ActiveX 컨트롤, Win32 API 선언 등은 사람이 설계를 판단하고 수정해야 합니다. 도구 출력을 그대로 운영에 쓰지 말고, 「변환 후 사람이 마무리하는 공수」를 포함해 전체를 산정하고, 변환 결과의 검증 방법(병행 가동이나 출력 비교)을 먼저 정해 두는 것이 중요합니다.

이전 대상은 VB.NET과 C# 중 어느 쪽을 골라야 합니까?

새로 쓰는 부분은 C#을 권장합니다. 마이크로소프트의 언어 전략에서는 Visual Basic(VB.NET)을 안정된 설계를 유지하는 언어로 두고, 새로운 구문 추가나 새로운 워크로드로의 확장은 하지 않는다는 방침이 명시되어 있습니다. 기존 시나리오(Windows Forms 등)에 대한 투자는 이어지므로 VB.NET을 쓸 수 없게 되는 것은 아니지만, 앞으로 10년을 유지보수할 코드의 토대로는 언어·생태계가 모두 계속 진화하는 C# 쪽이 인력 확보 면에서도 유리합니다. VB6 경험자가 많은 팀에서는 문법이 가까운 VB.NET을 경유하는 판단도 있을 수 있습니다.

전면 재작성 전에 먼저 무엇을 해야 합니까?

코드를 쓰기 전에 자산 파악을 해야 합니다. 구체적으로는 화면·장표 목록, 외부 연동(DB, 파일, 시리얼 통신, 다른 시스템) 목록, 참조 중인 OCX/ActiveX 컨트롤과 COM 컴포넌트 목록, Win32 API 선언(Declare 문) 목록, 그리고 「사양서는 코드밖에 없는」 업무 규칙의 정리입니다. 이 자산 파악 결과에 따라, 전면 재작성이 아니라 일부만 잘라 내는 단계 이전이나, 데이터 계층을 먼저 옮기는 구성이 더 현실적이라는 점이 드러나는 경우가 많습니다.

저자 프로필

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

Go Komura

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

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