소스 코드가 없어도 상담할 수 있나요?

상담은 가능합니다. 다만 소스 코드가 없는 경우, 할 수 있는 일이 제한됩니다. 설정, 환경, 로그, 외부 의존성, 실행 파일, 설치 프로그램, 통신 내용 등에서 조사할 수 있는 경우도 있습니다. 한편, 기능 추가나 근본적인 수정에는 소스 코드가 필요한 경우가 많으므로, 먼저 현황 조사부터 시작하는 것이 현실적입니다.

오래된 VB6, VBA, COM, ActiveX를 포함한 앱도 상담할 수 있나요?

상담 가능합니다. 이 영역에서는 무리하게 한 번에 전부 교체하기보다, 남길 부분, 감쌀 부분, 교체할 부분을 나누어 생각하는 것이 중요합니다. 특히 업무상 아직 동작하고 있는 자산은 리스크를 살펴보며 단계적으로 이전하는 것이 안전합니다.

Windows 앱을 웹 앱으로 교체해야 하나요?

목적에 따라 다릅니다. 웹 앱은 여러 사업장, 단말 관리 간소화, 브라우저 이용에 적합합니다. 한편, 장치 연계, 로컬 파일 처리, 오프라인 운용, 기존 DLL 이용 등이 있는 경우에는 Windows 앱을 남기는 쪽이 자연스러울 때도 있습니다. 전부를 웹화하는 것이 아니라, Windows 쪽과 웹 쪽의 책임을 나누는 설계도 하나의 선택지입니다.

불량 조사만 의뢰할 수도 있나요?

가능합니다. 장시간 가동 후 발생하는 크래시, 통신 정지, 메모리 증가, 특정 PC에서만 발생하는 불량 등은 곧바로 수정하기보다, 먼저 원인을 추적할 수 있는 상태로 만드는 것이 중요합니다. 로그와 덤프를 정비하고 재현 조건을 좁힌 뒤 수정 방침을 결정합니다.

관리자 권한이 필요한 앱도 만들 수 있나요?

만들 수 있지만, 항상 관리자 권한으로 동작시키는 설계는 신중하게 검토해야 합니다. 일상적으로 사용하는 부분은 표준 사용자 권한으로 동작시키고, 필요한 처리만 분리하는 쪽이 안전합니다. 설치, 서비스 등록, 보호 영역에 대한 쓰기, 드라이버, 전체 사용자 설정 등은 권한 설계를 처음에 정리해 둡니다.

사내용 소규모 Windows 앱도 수탁 개발할 수 있나요?

가능합니다. 작은 앱이라도 배포, 업데이트, 로그, 설정, 백업, 담당자 교체까지 미리 생각해 두면 오래 사용하기 편해집니다. 특히 Excel 작업 자동화, CSV 변환, 파일 감시, 보고서 출력, 장치 데이터 수집 같은 작은 업무 개선에는 Windows 앱이 적합한 경우가 있습니다.

Windows 앱 개발 외주·의뢰 전 체크리스트

Windows 앱의 외주·수탁 개발을 검토할 때, 가장 먼저 정해야 할 것은 「어떤 기술로 만들 것인가」만이 아닙니다.

실무에서는 다음과 같은 상담이 자주 있습니다.

오래된 Windows 소프트웨어를 개수하고 싶다
전임자가 만든 사내 앱을 인수받을 수 없다
장치나 계측기와의 통신이 간혹 멈춘다
32bit / 64bit, COM / ActiveX, VBA 연계가 얽혀 있다
Windows 11이나 새 PC로 옮기니 동작하지 않게 되었다
배포, 코드 서명, 자동 업데이트, SmartScreen 경고까지 포함해서 정리하고 싶다
장시간 가동 후의 크래시나 메모리 증가를 조사하고 싶다

즉, Windows 앱의 외주·수탁 개발은 「새로 화면을 만드는 일」만이 아닙니다. 기존 자산의 조사, 개수, 리플레이스, 장치 연계, 배포, 보수, 장애 조사까지 포함하는 일로 생각할 필요가 있습니다.

이 글에서는 Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해 두고 싶은 포인트를, 발주자 관점에서 정리합니다.

Windows 앱 외주·수탁 개발에서 상담이 많은 영역

1. 신규 업무 앱 개발

사내 업무를 지원하는 입력 화면, 검색 화면, 보고서 출력, CSV 연계, 파일 연계, 외부 시스템 연계 등을 Windows 앱으로 만드는 사례입니다.

Web 앱이 아니라 Windows 앱을 선택하는 이유는 대체로 이런 부분입니다.

로컬 PC 상의 파일이나 폴더를 세밀하게 다루고 싶다
USB 기기, 계측기, PLC, 카메라 등과 연계하고 싶다
오프라인 환경이나 폐쇄 네트워크에서 사용하고 싶다
기존 Excel, VBA, COM, DLL 자산을 활용하고 싶다
현장 단말에서 키보드, 바코드 리더, 터치 패널 등을 사용하고 싶다
상주 모니터링이나 백그라운드 처리가 필요하다

신규 개발이라도, 처음부터 「Windows 앱으로 해야 하는지」, 「Web 앱이라도 괜찮은지」, 「일부만 Windows 쪽에 남길지」를 정해 두면 나중에 되돌릴 일이 줄어듭니다.

2. 기존 Windows 소프트웨어의 개수·보수

외주·수탁 개발 상담에서 많은 것은 완전한 신규 개발보다, 기존 소프트웨어의 개수·보수입니다.

예를 들면 이런 상태입니다.

소스 코드는 있지만 빌드 방법을 모른다
오래된 버전의 Visual Studio에서만 열린다
VB6, MFC, WinForms, .NET Framework 상태에서 멈춰 있다
담당자가 퇴사해서 사양을 아는 사람이 없다
Windows 업데이트나 PC 교체로 동작이 불안정해졌다
거래처나 현장에서 기능 추가를 요구받고 있다

이 경우, 곧바로 다시 만들기보다 먼저 현황을 파악합니다.

어떤 업무를 지원하고 있는지
어떤 기능이 필수적인지
어떤 환경에서 동작하고 있는지
어떤 외부 기기·DLL·DB·공유 폴더에 의존하고 있는지
로그나 오류 정보가 남아 있는지
소스 코드, 빌드 절차, 설치 프로그램, 설정 파일이 남아 있는지

기존 소프트웨어는 동작하고 있다는 것 자체가 가치입니다.
그렇기 때문에 수탁 개발에서는 「전부 버리고 다시 만든다」뿐만 아니라, 남기기·감싸기·교체하기라는 단계적인 사고방식이 중요해집니다.

COM / ActiveX / OCX가 얽혀 있는 경우에는 먼저 COM/ActiveX/OCX의 차이를 철저히 해설에서 용어를 짚어 보고, 이행 방침은 ActiveX/OCX를 남기기·감싸기·교체하기 판단표와 같은 관점으로 생각하면 진행하기 쉬워집니다.

3. 장치 연계·외부 기기 연계 앱

제조업, 검사, 계측, 의료 주변, 연구 용도 등에서는 Windows 앱이 외부 기기와 연결되어 있는 경우가 있습니다.

대표적인 연계 대상은 다음과 같습니다.

시리얼 통신 기기
USB 기기
산업용 카메라
PLC
계측기
바코드 리더
공유 폴더나 NAS
기존 네이티브 DLL
벤더 제공 SDK

이 영역에서는 단순히 화면을 만드는 것만이 아니라, 통신이 끊기는 방식, 재접속, 타임아웃, 로그, 원시 데이터 저장, 상태 표시까지 설계해야 합니다.

특히 시리얼 통신은 수신 단위, 타임아웃, 재접속, UI 프리징 등에서 문제가 발생하기 쉬우므로, 시리얼 통신 앱 개발의 함정과 같은 관점을 처음부터 짚어 두면 안전합니다.

또한 외부 기기의 상태는 「연결됨」「연결 안 됨」만으로는 부족한 경우가 있습니다.
기기의 존재, 응답, 기능 준비, 데이터 신선도, 구성 일치 등을 나누어 생각하면 현장에서 오해받기 어려운 화면이 됩니다. 자세한 내용은 외부 기기의 상태 표시 설계도 참고가 됩니다.

4. 불량 조사·원인 분석

Windows 앱의 수탁 개발에서는 기능 추가보다 먼저 불량 조사가 필요한 경우도 있습니다.

자주 있는 것은 이런 상담입니다.

하루에 몇 번만 다운된다
장시간 가동 후 메모리가 계속 증가한다
특정 PC에서만 동작하지 않는다
장치와의 통신이 몇 초간 멈춘다
파일 연계에서 누락이 발생한다
재현 절차를 모른다
로그가 적어서 원인을 추적할 수 없다

이런 문제는 코드를 들여다보는 것만으로는 해결되지 않습니다.
먼저 관측 지점을 설계하고, 로그, 크래시 덤프, 통신 로그, 이벤트 로그, 메모리 사용량, 핸들 수 등을 수집합니다.

크래시 조사에서는 Windows 앱의 크래시 시 로그 출력 방법이나 크래시 덤프 수집 입문〖WER/ProcDump/WinDbg〗처럼, 다운된 순간의 증거를 어떻게 남기는가가 핵심이 됩니다.

메모리가 증가하는 문제에서는 단순한 GC 대기인지, 진짜 메모리 누수인지를 구분해야 합니다.
.NET 앱의 경우에는 .NET에서 GC 대기와 메모리 누수를 구별하는 방법처럼, 관측하고 비교하고 증명하는 절차를 밟습니다.

5. 배포·서명·자동 업데이트

Windows 앱은 완성된 후에 「어떻게 배포할 것인가」에서 막히는 경우가 있습니다.

설치 프로그램을 만들 것인가
그냥 두기만 해도 동작하게 할 것인가
표준 사용자로 설치할 수 있는가
관리자 권한이 필요한가
사내 파일 공유로 배포할 것인가
Web에서 다운로드하게 할 것인가
자동 업데이트할 것인가
코드 서명 인증서를 어떻게 다룰 것인가
SmartScreen 경고를 어떻게 설명·대응할 것인가

배포 방식에는 MSI, MSIX, ClickOnce, xcopy, 자체 updater 등이 있습니다.
선택 기준은 「어느 것이 간단한가」가 아니라, OS에 무엇을 등록하는가, 업데이트 책임을 누가 지는가로 정해야 합니다. 자세한 내용은 Windows 앱 배포 방식 선정 가이드에 정리되어 있습니다.

사내용 .NET Windows 앱을, 표준 사용자에게 배포하고 자동 업데이트까지 가볍게 돌리고 싶은 경우에는 ClickOnce 입문: 배포·업데이트·선정 기준이 참고가 됩니다.

한편, Web 배포나 사외 배포에서는 SmartScreen 경고나 코드 서명 문제가 발생합니다.
「Windows에서 PC를 보호했습니다」라고 표시되는 이유는 Windows에서 「Windows에서 PC를 보호했습니다」가 표시되는 이유에 정리되어 있습니다.

Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리하고 싶은 5가지

1. 무엇을 멈추고 싶지 않은가

가장 먼저 정리해야 할 것은 기능 목록이 아니라 「멈추면 곤란한 업무」입니다.

수주 처리가 멈춘다
검사 라인이 멈춘다
보고서를 낼 수 없다
장치와의 통신이 멈춘다
현장 담당자가 수작업으로 돌아간다
감사나 증적이 남지 않는다

수탁 개발에서는 화면이나 기능을 만드는 것만이 아니라, 업무가 멈추지 않도록 하는 것까지가 설계입니다.
이 우선순위를 알면, 만들어야 할 기능, 나중으로 미룰 수 있는 기능, 먼저 조사해야 할 불량을 판단하기 쉬워집니다.

2. 현재 앱과 주변 환경

기존 앱의 개수·보수에서는 앱 단독이 아니라 주변 환경까지 확인합니다.

짚어 두고 싶은 정보는 다음과 같습니다.

앱 이름, 용도, 이용 부서
이용 인원, 이용 대수
Windows 버전
32bit / 64bit
.NET Framework / .NET 버전
Visual Studio 버전
DB, 공유 폴더, 외부 API
연계하고 있는 장치, DLL, SDK
설치 절차
설정 파일의 위치
로그의 위치
소스 코드의 유무
빌드 절차의 유무
전임자가 남긴 자료의 유무

이 정보가 갖추어져 있을수록 견적이나 조사의 정확도가 높아집니다.
반대로 정보가 부족한 경우에는 첫 공정을 「현황 조사」로 따로 떼어 내는 것이 안전합니다.

3. 신규 개발·개수·리플레이스 중 어느 것인가

Windows 앱 상담에서는 처음부터 「다시 만든다」로 정하지 않는 것이 좋을 때가 있습니다.

방침	적합한 상태	주의점
기존 개수	소스 코드가 있고 주요 기능은 동작하고 있음	오래된 설계의 제약을 받음
랩·연명	COM, ActiveX, DLL 등 기존 부품을 계속 사용하고 싶음	경계 설계와 운용 규칙이 중요
단계적 이전	업무를 멈추지 않고 새 환경으로 이전하고 싶음	신구 병행 가동과 데이터 정합성이 필요
전면 리플레이스	사양을 정리할 수 있고 현행 제약이 큼	사양 누락과 전환 리스크가 큼
불량 조사만	먼저 원인을 알고 싶음	로그와 재현 환경 정비가 필요

.NET Framework 앱을 앞으로도 계속 사용할지, .NET으로 이행할지는 앱 종류, 의존 라이브러리, COM 연계, 배포 방법에 따라 달라집니다.
이행 전 확인 항목은 .NET Framework→.NET 이행 사전 체크리스트처럼, 먼저 파악해 두면 판단하기 쉬워집니다.

4. 배포·업데이트·권한

Windows 앱에서는 개발보다 배포에서 막히는 경우가 있습니다.

특히 확인하고 싶은 점은 다음과 같습니다.

표준 사용자로 사용할 것인가
관리자 권한이 필요한 처리가 있는가
전체 사용자용으로 설치할 것인가, 사용자 단위로 충분한가
사내에서만 사용할 것인가, 사외에도 배포할 것인가
자동 업데이트가 필요한가
오프라인 단말이 있는가
코드 서명이 필요한가
Microsoft Defender SmartScreen에 대한 설명이 필요한가
Intune, GPO, App Control 등의 관리 정책이 있는가

관리자 권한이 필요한 처리와 불필요한 처리를 나누면, 일상 이용의 안전성과 운용성이 높아집니다.
권한의 경계는 Windows 관리자 특권의 필요/불필요 경계와 같은 관점으로 확인할 수 있습니다.

5. 보수하기 쉬움

수탁 개발에서 중요한 것은 납품 시점에 동작하는 것만이 아닙니다.
몇 년 후 다른 담당자가 보더라도 조사·개수·재배포할 수 있는 상태로 남겨 두고 싶은 부분입니다.

보수하기 쉬운 Windows 앱에는 이런 특징이 있습니다.

빌드 절차가 남아 있다
의존 라이브러리와 버전을 알 수 있다
설정 파일의 위치와 의미를 알 수 있다
조사에 사용할 수 있는 수준으로 로그가 출력된다
크래시 시 증적이 남는다
배포 절차와 되돌리기 절차가 있다
소스 코드의 책임이 나뉘어 있다
관리자 권한이 필요한 처리가 한정되어 있다
비밀 정보가 평문으로 저장되지 않는다

출시 전 최소한의 보안 확인은 Windows 앱 보안 체크리스트처럼, 권한, 서명, 비밀 정보, 통신, 입력, DLL, 로그의 관점에서 확인합니다.

비밀번호나 토큰을 설정 파일에 저장하는 경우에는 평문 저장을 피하고, Windows의 메커니즘을 사용해 보호하는 설계가 필요합니다. 자세한 내용은 설정 파일의 기밀 정보를 안전하게 저장하는 방법도 참고가 됩니다.

Windows 앱 기술 선정에서 자주 있는 판단

WinForms, WPF, WinUI 중 무엇을 선택할 것인가

Windows 앱의 신규 개발에서는 WinForms, WPF, WinUI 중 무엇을 사용할지가 논점이 됩니다.

큰 틀에서 비교하면 다음과 같습니다.

기술	적합한 경우
WinForms	사내 업무 앱, 입력 화면, 기존 자산과의 친화성, 단기 개발
WPF	복잡한 화면, 데이터 바인딩, 장기 보수, 업무 앱의 정교한 구현
WinUI	Windows 11 전제, 모던 UI, Microsoft Store / MSIX 등과의 친화성

다만, 항상 새로운 기술이 정답이라고는 할 수 없습니다.
기존 팀의 경험, 보수 기간, 배포 방식, 화면 요구 사항, 주변 라이브러리까지 포함해서 선택해야 합니다.

자세한 내용은 WinForms/WPF/WinUI 선정 가이드에 판단표로 정리되어 있습니다.

C# / .NET만으로 충분한가, C++나 네이티브 DLL이 필요한가

업무 앱의 대부분은 C# / .NET으로 충분히 만들 수 있습니다.
하지만 다음과 같은 경우에는 C++, 네이티브 DLL, P/Invoke, C++/CLI, COM 등을 검토하는 경우가 있습니다.

벤더 SDK가 C/C++ 대상이다
기존 DLL을 호출해야 한다
고속 이미지 처리나 장치 제어가 있다
기존 COM 자산을 사용해야 한다
32bit / 64bit의 경계를 넘어야 한다

이런 프로젝트에서는 화면 쪽의 만들기 쉬움만이 아니라, 프로세스 경계, 메모리 소유권, 예외, 스레드, bitness를 정리해야 합니다.

Windows 앱인가 Web 앱인가

「오래된 Windows 앱을 웹화하고 싶다」는 상담도 있습니다.
웹화가 적합한 경우도 있지만, 모든 것을 웹으로 만들면 되는 것은 아닙니다.

Windows 앱이 적합한 것은, 예를 들면 이런 경우입니다.

장치나 로컬 기기와 직접 연결한다
오프라인으로 사용한다
큰 로컬 파일을 다룬다
기존 COM / DLL / VBA 자산을 사용한다
현장 단말에서 빠른 조작이 필요하다
상주 모니터링이나 백그라운드 처리가 필요하다

한편, 여러 사업장에서 같은 데이터를 참조하고 싶다, 브라우저만으로 이용하고 싶다, 단말 관리를 줄이고 싶다면 웹화나 클라우드화가 적합한 경우도 있습니다.

실무에서는 모든 것을 한 번에 웹화하는 것이 아니라, Windows 앱이 필요한 부분만 남기고, 데이터 관리나 열람 부분을 Web 쪽으로 내놓는 구성도 있습니다.

수탁 개발의 진행 방식

Windows 앱의 외주·수탁 개발은 다음과 같이 진행하면 안전합니다.

1. 현황 파악

먼저 대상 업무, 이용 환경, 기존 앱, 외부 기기, 배포 방법, 곤란한 증상을 정리합니다.

기존 앱이 있는 경우에는 소스 코드, 빌드 환경, 설정 파일, 로그, 설치 프로그램, 관련 자료를 확인합니다.

2. 관측 지점 설계

불량이나 불안정함이 있는 경우에는 곧바로 수정하기 전에, 원인을 추적할 수 있게 합니다.

로그를 추가한다
크래시 덤프를 확보한다
통신 로그를 남긴다
메모리나 핸들 수를 기록한다
조작 이력을 남긴다
이상 발생 시의 스크린샷이나 상태를 저장한다

재현하기 어려운 문제일수록 관측 지점 설계가 효과를 발휘합니다.

3. 방침 결정

현황을 확인한 후, 개수, 연명, 단계적 이전, 전면 리플레이스, 불량 조사만 등의 방침을 결정합니다.

이 단계에서 기술 선정, 배포 방법, 업데이트 방법, 보수 범위도 함께 결정합니다.

4. 구현·테스트

구현에서는 화면, 업무 로직, 외부 기기 연계, 파일 연계, 오류 처리, 로그, 설정, 배포를 나누어 만듭니다.

테스트에서는 정상 케이스뿐만 아니라 비정상 케이스도 확인합니다.

장치가 미연결 상태
통신이 중간에 끊긴다
파일이 잠겨 있다
권한이 부족하다
네트워크가 불안정하다
설정이 깨져 있다
업데이트에 실패한다
앱이 비정상 종료한다

5. 배포·이행

완성 후에는 배포 절차, 업데이트 절차, 되돌리기 절차, 초기 설정, 이용자용 설명을 정리합니다.

기존 앱에서 이행하는 경우에는 신구 병행 가동, 롤백, 데이터 이행, 사용자 교육까지 계획에 포함합니다.

6. 보수·개선

납품 후에는 로그나 문의 내용을 보면서 운용에 맞는 형태로 개선합니다.

Windows 앱은 OS 업데이트, PC 교체, 주변 기기 변경, 보안 방침 변경의 영향을 받습니다.
그러므로 보수를 전제로 한 설계와 자료화가 필수적입니다.

견적 전에 준비해 두면 좋은 정보

상담 시점에 모든 것이 갖추어져 있을 필요는 없습니다.
다만 다음 정보가 있으면 이야기가 빨리 진행됩니다.

앱의 목적
현재 곤란한 점
이용 인원·이용 대수
Windows 버전
기존 앱의 유무
소스 코드의 유무
개발 언어나 프레임워크
연계하고 있는 기기·DB·파일·API
오류 화면이나 로그
재현 절차
원하는 납기
절대로 멈추고 싶지 않은 업무
사내 배포인지 사외 배포인지
보수도 필요한지

모르는 항목이 있어도 문제없습니다.
무엇을 알고 있고 무엇을 모르는지를 명확히 하는 것이, 수탁 개발의 첫 번째 일이 됩니다.

정리

Windows 앱 외주·수탁 개발을 의뢰할 때는, 단순히 「앱을 만들어 달라」고 전달하는 것만으로는 필요한 범위가 잘 보이지 않게 됩니다.

의뢰 전에 짚어 두고 싶은 것은 다음 7가지입니다.

신규 개발인지, 기존 개수인지, 리플레이스인지
어떤 업무를 멈추고 싶지 않은지
기존 자산, 외부 기기, DLL, COM, ActiveX가 있는지
WinForms, WPF, WinUI, .NET 이행 등의 기술 선정
배포, 서명, 자동 업데이트, 관리자 권한을 어떻게 다룰지
로그, 크래시 덤프, 메모리, 통신 등의 조사 설계
납품 후 보수할 수 있는 상태를 어떻게 남길지

Windows 앱은 현장의 업무, 장치, 파일, 주변 기기, Windows OS의 제약과 밀접하게 관련되어 있습니다.
그렇기 때문에 외주·수탁 개발에서는 「만들기」만이 아니라, 「조사하기」「고치기」「남기기」「배포하기」「운용하기」까지 포함해서 설계하는 것이 중요합니다.

Windows 앱의 외주·수탁 개발, 신규 개발, 기존 소프트웨어의 개수·보수, 장치 연계, 불량 조사, 배포·업데이트 설계로 고민 중이라면, 먼저 현재 상황을 정리하는 것부터 상담해 보세요.

Windows 앱 개발 상담하기

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

이 주제와 연결되는 서비스

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