합동회사 코무라소프트
문의하기
메뉴

VB6 애플리케이션은 언제까지 동작할까 ── 런타임 지원 현황과 현실적인 .NET 이전 진행 방법

· · VB6, .NET, C#, 레거시 기술, 기존 자산 활용, 마이그레이션, 모더나이제이션, 32bit, Windows 개발, 판단표, 기술 상담

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

답은 의외로 명확합니다. 마이크로소프트가 공식 지원 정책을 발표해 두었기 때문입니다. 다만 그 내용은 “런타임은 당분간 동작한다. 그러나 개발의 뒷받침은 이미 없다”는 비대칭적인 것입니다. 이 비대칭성을 제대로 이해하지 못하면 “아직 동작하니 괜찮다”와 “지금 당장 전부 다시 만들어야 한다”는 양극단의 결론으로 치우치게 됩니다.

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

1. 먼저 결론

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

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

마이크로소프트의 VB6 지원 정책은 VB6를 3가지 구성 요소로 나누어 설명하고 있습니다.2

구성 요소 내용 지원 상황
VB6 IDE 개발 환경(Visual Studio 6.0) 2008년 4월 8일에 종료
VB6 런타임 msvbvm60.dll 등 OS에 포함되는 실행 기반 함께 제공되는 Windows의 지원 기간 중 지원
런타임 확장 파일 주요 OCX 컨트롤류(앱과 함께 재배포) 위와 동일(앱 측에서 배포 필요)

대상 OS 목록에는 Windows 11・Windows 10, Windows Server 2012～2025에서 “런타임: 지원”, “IDE: 지원 외”라고 명시되어 있습니다.2

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

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

둘째, 지원의 실질적인 내용은 “계속 동작하는 것”에 대한 보증에 가깝습니다. 대응되는 것은 심각한 회귀(OS 업데이트로 기존 앱이 깨진 경우)와 중대한 보안 문제뿐이며, 개별 조사나 기능 개선은 포함되지 않습니다.2

셋째, VB6 앱은 앞으로도 32bit 프로세스로서만 살아남을 수 있습니다. 런타임은 32bit 전용이며, 64bit OS에서는 WOW64 에뮬레이션 환경 안에서만 지원됩니다.2 64bit 전용 DLL이나 SDK와 연동해야 하는 필요성이 생긴 시점에, 단일 프로세스만으로는 해결되지 않게 됩니다. 이 벽을 넘는 방법은 “32bit 앱에서 64bit DLL을 호출하는 COM 브리지 사례”에서 다루고 있습니다.

3. “동작한다”와 “유지보수할 수 있다”는 별개의 문제

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

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

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

4. 이전 방식의 판단표

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

방식 개요 적합한 경우 주요 리스크
전면 재작성 사양을 다시 정리하고 .NET으로 새로 만든다 화면 수가 적다 / 업무 흐름 자체를 재검토하고 싶다 / 사양을 설명할 수 있다 숨겨진 업무 규칙 누락, 병행 개발 기간의 장기화
자동 변환 도구 변환 도구로 VB6 코드를 .NET 코드로 기계 변환하고 사람이 마무리한다 코드량이 많고 로직을 그대로 유지하고 싶다 / 화면 구성을 바꾸지 않는다 변환 후 코드의 품질・가독성, 결국 남는 수작업, 도구 비용
단계적 이전(스트랭글러) 기능 단위로 잘라내어 신구를 공존시키며 순차적으로 교체한다 업무를 멈출 수 없다 / 화면・기능이 많다 / 리스크를 분산하고 싶다 신구 공존 기간의 복잡성, 경계(연동부) 설계 능력이 필요
현상 유지+문서화 이전하지 않고 환경 고정・백업・문서화로 연명한다 변경 요구가 거의 없다 / 단말과 OS를 고정할 수 있다 앞 장의 리스크가 해소되지 않는다(뒤로 미룰 뿐)

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

또한 “현상 유지+문서화”를 선택하는 경우의 실무(실행 환경 고정, 백업, 리스크를 감수하는 방법)는 지난 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의 벽을 넘을 수 있다” 같은 단계적 이전의 실마리가 발견되는 것이 일반적입니다.

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

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

영역 VB6 .NET 실무상 주의점
오류 처리 On Error GoTo / Resume 구조화된 예외(Try...Catch) 단순 치환 불가. “오류를 삼키고 계속 진행”하던 부분의 사양 확인이 필요
타입 Variant, Integer는 16bit 정적 타입 지정 중심, Integer는 32bit 암묵적 변환에 의존한 코드의 정리. 숫자형 크기 차이는 호환 버그의 단골
기본 속성 Text1 = "abc" 같은 생략 표기 폐지(명시 필요) 변환 도구가 오해석하기 쉬운 지점. 객체 대입과 값 대입의 구분이 애매한 코드에 주의
데이터 액세스 ADO / DAO / RDO ADO.NET 이후 연결・트랜잭션・커서에 대한 개념이 별개입니다. 데이터 계층은 “변환”이 아니라 “재설계”가 전제
화면 VB6 폼+OCX WinForms / WPF 컨트롤이 1대1로 대응하지 않습니다. 그리드 등의 OCX는 대체재 선정이 필요
인쇄・그리기 Printer 객체, 폼 직접 그리기 GDI+ / 인쇄 API 장표는 이전 공수를 가늠하기 어려운 영역입니다. Excel 장표로 이관하는 것도 선택지
실행・배포 EXE+런타임+OCX 등록 자기 완결형 배포도 가능 레지스트리 등록(regsvr32)을 전제로 한 운영에서 벗어날 수 있는 것이 이전의 이점

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

7. 단계적 이전의 실무 패턴

업무를 멈추지 않고 이전하는 경우, 신구 공존 구성이 핵심이 됩니다. 대표적인 패턴 세 가지를 소개합니다.

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에서 타입 있게 호출하기 ── dscom과 TLB”에서 해설했으며, 호출 측이 VB6여도 사고방식은 같습니다.
  • VB6 측 자산을 .NET에서 호출한다: VB6로 만들어진 ActiveX DLL은 .NET에서 COM 상호운용으로 참조할 수 있습니다. 로직을 덩어리째 살리고, 화면만 먼저 .NET화하는 경우에 사용합니다. 다만 32bit의 제약은 남기 때문에, 영구적인 대책이 아니라 이전 기간 중의 다리로 여기는 것이 좋습니다.

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상의 개발 경험 개선은 계속된다고 되어 있습니다.3

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

  • 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년에 지원이 종료되어, 다시 만들거나 고칠 수단의 공식적인 뒷받침은 이미 없다는 비대칭적인 상태입니다.21
  • 진짜 기한은 OS가 아니라, 고칠 수 있는 환경과 사람이 남아 있는가로 결정됩니다. 이전 계획은 장애 발생 후가 아니라, 구 시스템이 “동작하는 사양서”로 사용 가능한 동안에 세웁니다.
  • 진행 방식은 전면 재작성・자동 변환・단계적 이전의 3가지 계통. 방식 선정 전에 화면・외부 연동・OCX・API 선언・코드에만 존재하는 업무 규칙의 자산 파악을 합니다.
  • 업무를 멈추지 않는 이전에서는 데이터 계층 선행・COM 상호운용・프로세스 분리 중 하나로 신구를 공존시키고, 경계를 한 곳으로 집약합니다.
  • 새로 작성하는 부분의 언어는 C#을 권장합니다. VB.NET은 안정 노선이 공식 방침이며3, 장기 유지보수의 토대로는 C# 쪽이 유리합니다.

관련 글

관련 상담 영역

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

참고 링크

  1. Microsoft Learn, Visual Basic 6.0 Support Announcement. VB6 IDE / Visual Studio 6.0 IDE가 2008년 4월 8일에 지원이 종료되었다는 점, VB6 앱을 작성・유지보수할 수 있는 지원된 수단이 존재하지 않기 때문에 모던한 기술로의 교체를 강력히 권장한다는 점, 이전 시 업그레이드 가이드와 이전 파트너가 안내된다는 점에 대해. ↩ ↩2 ↩3

  2. Microsoft Learn, Support Statement for Visual Basic 6.0 on Windows. VB6 런타임은 함께 제공되는 Windows 버전의 지원 기간 중에는 지원 대상이라는 점, Windows 11・Windows 10・Windows Server 2025 등이 대상 OS에 포함된다는 점, 지원 범위는 심각한 회귀와 중대한 보안 문제에 한정된다는 점, 런타임은 32bit 전용이며 64bit OS에서는 WOW 환경에서만 지원된다는 점, 서드파티 제작 컨트롤은 벤더의 책임 범위라는 점에 대해. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Microsoft Learn, Annotated Visual Basic language strategy 및 Microsoft .NET language strategy. Visual Basic은 안정된 설계를 유지하며, 새로운 기능은 소비(consumption-only) 중심으로 새로운 구문 추가를 피한다는 점, 새로운 워크로드로는 확장하지 않는다는 점, Windows Forms나 라이브러리 등 핵심 시나리오와 Visual Studio 경험에 대한 투자는 계속된다는 점에 대해. ↩ ↩2 ↩3

관련 기사

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

관련 토픽

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

ActiveX 이관

COM / ActiveX / OCX 자산을 유지할지, 감쌀지, 교체할지의 단계적 판단을 정리한 토픽 페이지입니다.

토픽 보기

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

문의하기
블로그 목록으로 돌아가기