Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리할 점

Windows 앱 외주·수탁 개발을 검토할 때 먼저 정해야 하는 것은 기술 선정만이 아닙니다.

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

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

즉 Windows 앱 외주·수탁 개발은 화면을 새로 만드는 일만이 아닙니다. 기존 자산 조사, 수정, 교체, 장치 연동, 배포, 유지보수, 장애 조사까지 포함하는 일로 봐야 합니다.

이 글에서는 Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해 둘 점을 발주자 관점에서 정리합니다.

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

1.1 신규 업무 앱 개발

사내 업무를 뒷받침하는 입력 화면, 검색 화면, 장표 출력, CSV 연동, 파일 연동, 외부 시스템 연동 등을 Windows 앱으로 만드는 경우입니다.

Windows 앱을 Web 앱 대신 고르는 이유는 대개 다음입니다.

• 로컬 PC의 파일이나 폴더를 세밀하게 다루고 싶다
• USB 기기, 측정기, PLC, 카메라 등과 연동하고 싶다
• 오프라인 환경이나 폐쇄망에서 쓰고 싶다
• 기존 Excel, VBA, COM, DLL 자산을 살리고 싶다
• 현장 단말에서 키보드, 바코드 리더, 터치 패널 등을 쓰고 싶다
• 상주 감시나 백그라운드 처리가 필요하다

신규 개발이어도 처음부터 Windows 앱이 맞는지, Web 앱으로도 되는지, 일부만 Windows에 남길지를 정해 두면 되돌릴 일이 줄어듭니다.

1.2 기존 Windows 소프트웨어의 수정·유지보수

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

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

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

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

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

기존 소프트웨어는 동작하고 있다는 것 자체가 가치입니다. 그래서 수탁 개발에서는 전부를 버리고 다시 만드는 것만이 아니라, 유지·래핑·교체라는 단계적 관점이 중요해집니다.

COM / ActiveX / OCX가 얽혀 있으면 먼저 용어를 정리하고, 그다음 부품마다 유지·래핑·교체 중 무엇을 할지 정하면 진행하기 쉽습니다.

관련 글

• COM/ActiveX/OCX의 차이를 자세히 설명 — 용어 정리
• ActiveX/OCX 유지·래핑·교체 판단표 — 이전 방침 판단

1.3 장치 연동·외부 기기 연동 앱

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

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

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

이 영역에서는 화면을 만드는 것만으로는 부족하고, 통신이 끊기는 방식, 재연결, 타임아웃, 로그, 원시 데이터 저장, 상태 표시까지 설계해야 합니다.

특히 시리얼 통신은 수신 단위, 타임아웃, 재연결, UI 프리즈에서 문제가 나오기 쉬우므로, 이 관점을 처음부터 잡아 두면 안전합니다.

또한 외부 기기 상태는 “연결 중”, “미연결”만으로는 부족한 경우가 있습니다. 기기 존재, 응답, 기능 준비, 데이터 최신성, 구성 일치 등을 나누어 보면, 현장에서 오해하기 어려운 화면이 됩니다.

관련 글

• 시리얼 통신 앱 개발의 함정 — 수신 단위, 타임아웃, 재연결
• 외부 기기 상태 표시 설계 — 상태 구분과 화면 표시

1.4 장애 조사·원인 분석

Windows 앱 수탁 개발에서는 기능 추가보다 장애 조사가 먼저인 경우도 있습니다.

자주 있는 상담은 다음과 같습니다.

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

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

크래시 조사에서는 죽은 순간의 증적을 어떻게 남길지가 핵심입니다.

메모리가 늘어나는 문제에서는 단순한 GC 대기인지, 실제 메모리 누수인지를 가려야 합니다. .NET 앱이면 관측하고 비교해 증명하는 절차를 밟습니다.

관련 글

• Windows 앱 크래시 시 로그 출력 방법 — 죽은 순간의 로그 설계
• 크래시 덤프 수집 입문〖WER/ProcDump/WinDbg〗 — 덤프 취득 방법
• .NET에서 GC 대기와 메모리 누수를 구분하기 — 메모리 증가 원인 분리

1.5 배포·서명·자동 업데이트

Windows 앱은 완성한 뒤에 배포 방식에서 막히는 경우가 있습니다.

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

배포 방식에는 MSI, MSIX, ClickOnce, xcopy, 자체 updater 등이 있습니다. 고르는 기준은 쉬운 쪽이 아니라, OS에 무엇을 등록할지, 업데이트 책임을 누가 질지로 정해야 합니다.

사내용 .NET Windows 앱을 표준 사용자에게 배포하고 자동 업데이트까지 가볍게 운영하고 싶다면 ClickOnce가 후보가 됩니다.

반면 Web 배포나 사외 배포에서는 SmartScreen 경고나 코드 서명 문제가 나옵니다.

관련 글

• Windows 앱 배포 방식 선정 가이드 — MSI / MSIX / ClickOnce / xcopy / 자체 updater 비교
• ClickOnce 입문: 배포·업데이트·선정 기준 — 표준 사용자 배포와 자동 업데이트
• Windows에서 “Windows가 PC를 보호했습니다”가 나오는 이유 — SmartScreen과 코드 서명

이 글의 지식 맵

Windows앱의 외주·수탁 개발은 신규 화면 개발만이 아니라, COM·ActiveX·VB6·MFC와 같은 기존 자산을 존속·래핑·교체한다는 단계적 방침으로 정리하는 작업과 장치 연동, 배포, 보수, 장애 조사까지를 포함하는 일입니다. 기존 자산의 개수에서는 Windows Forms·WPF·WinUI의 기술 선정과 .NET Framework에서 .NET으로의 마이그레이션 판단이 필요해지며, 배포에서는 MSI·MSIX·ClickOnce의 용도 구분과 코드 서명을 통한 SmartScreen 경고 대책이 요구됩니다. 보수 단계에서는 DPAPI에 의한 비밀 정보 보호, 크래시 덤프 수집, 크래시 시 로그·증적 설계, GC 대기와 메모리 누수의 원인 분리와 같은 관측점 정비가 오래 쓸 수 있는 Windows앱을 뒷받침합니다.

flowchart LR
    accTitle: Windows앱 외주·수탁 개발의 지식 맵
    accDescr: Windows앱의 외주·수탁 개발이 기존 자산의 존속·래핑·교체 판단, COM/ActiveX 등의 레거시 자산, WinForms/WPF/WinUI 기술 선정, MSI/MSIX/ClickOnce를 통한 배포, 코드 서명과 SmartScreen, DPAPI에 의한 비밀 정보 보호, 크래시 덤프나 크래시 시 로그를 통한 장애 조사까지를 포함하는 업무임을 보여주는 그림
    contract_software_development["Windows 앱 외주·수탁 개발"]
    keep_wrap_replace_strategy["유지·래핑·교체(단계적 이행 방침)"]
    com["COM(컴포넌트 오브젝트 모델)"]
    vb6["Visual Basic 6.0(VB6)"]
    winui["WinUI(Windows App SDK)"]
    dotnet[".NET(Core 이후)"]
    wpf["WPF"]
    windows_forms["Windows Forms"]
    msi["MSI(Windows Installer)"]
    msix["MSIX"]
    clickonce["ClickOnce"]
    code_signing_cert["코드 서명 인증서"]
    smartscreen["Windows SmartScreen"]
    dpapi["DPAPI"]
    plaintext_secret_storage_risk["비밀 정보의 평문 저장 리스크"]
    crash_dump["크래시 덤프"]
    crash_time_logging_design["크래시 시점 로그·증적 설계"]
    external_device_integration["장치 연동·외부 기기 연동"]
    memory_leak_vs_gc_wait["GC 대기와 메모리 누수의 구분"]
    windows_app_assets["기존 Windows 장비 소프트웨어 자산"]
    activex["ActiveX"]
    mfc["MFC(Microsoft Foundation Classes)"]
    dotnet_framework[".NET Framework"]
    keep_wrap_replace_strategy -.->|"권장되는 대응"| com
    keep_wrap_replace_strategy -.->|"권장되는 대응"| vb6
    winui -.->|"전제로 한다"| dotnet
    winui -.->|"양립하지 않는다"| wpf
    winui -.->|"양립하지 않는다"| windows_forms
    contract_software_development -.->|"이용한다"| msi
    contract_software_development -.->|"이용한다"| msix
    contract_software_development -.->|"이용한다"| clickonce
    code_signing_cert -.->|"완화한다"| smartscreen
    dpapi -->|"완화한다"| plaintext_secret_storage_risk
    contract_software_development -.->|"이용한다"| crash_dump
    contract_software_development -.->|"이용한다"| crash_time_logging_design
    contract_software_development -.->|"이용한다"| external_device_integration
    contract_software_development -.->|"이용한다"| memory_leak_vs_gc_wait
    windows_app_assets -.->|"이용한다"| com
    windows_app_assets -.->|"이용한다"| activex
    windows_app_assets -.->|"이용한다"| windows_forms
    windows_app_assets -.->|"이용한다"| mfc
    windows_app_assets -.->|"전제로 한다"| dotnet_framework
    dotnet -->|"의 후속"| dotnet_framework
    contract_software_development -.->|"전제로 한다"| windows_app_assets
    contract_software_development -.->|"이용한다"| code_signing_cert
    contract_software_development -.->|"이용한다"| dpapi

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

2. Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리할 5가지

2.1 무엇을 멈추고 싶지 않은가

먼저 정리할 것은 기능 목록이 아니라, 멈추면 곤란한 업무입니다.

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

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

2.2 현재 앱과 주변 환경

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

잡아 둘 정보는 다음과 같습니다.

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

이 정보가 갖춰질수록 견적과 조사의 정확도가 올라갑니다. 정보가 부족하면 첫 공정을 현황 조사로 떼어 내는 편이 안전합니다.

2.3 신규 개발·수정·교체 중 무엇인가

Windows 앱 상담에서는 처음부터 다시 만든다고 정하지 않는 편이 나은 경우가 있습니다.

.NET Framework 앱을 계속 쓸지 .NET으로 옮길지는 앱 종류, 의존 라이브러리, COM 연동, 배포 방법에 따라 달라집니다. 이전 전 확인 항목을 먼저 파악해 두면 판단하기 쉬워집니다.

관련 글

• .NET Framework→.NET 이전 사전 체크리스트 — 이전 전 파악 항목

2.4 배포·업데이트·권한

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

특히 확인할 점은 다음과 같습니다.

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

관리자 권한이 필요한 처리와 불필요한 처리를 나누면 일상 이용의 안전성과 운용성이 올라갑니다.

관련 글

• Windows 관리자 권한의 필요/불필요 경계 — 권한 경계 구분

2.5 유지보수하기 쉬움

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

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

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

출시 전 최소한의 보안 확인은 권한, 서명, 비밀 정보, 통신, 입력, DLL, 로그 관점에서 합니다.

비밀번호나 토큰을 설정 파일에 넣을 때는 평문 저장을 피하고, Windows 메커니즘으로 보호하는 설계가 필요합니다.

관련 글

• Windows 앱 보안 체크리스트 — 출시 전 최소 확인
• 설정 파일의 기밀 정보를 안전하게 저장하는 방법 — DPAPI에 의한 보호

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

3.1 WinForms, WPF, WinUI 중 무엇을 고를까

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

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

셋 모두 Windows 전용입니다. 나중에 크로스 플랫폼이 필요하면 이 셋 밖까지 포함해 검토해야 합니다.

다만 항상 새 기술이 정답은 아닙니다. 기존 팀의 경험, 유지보수 기간, 배포 방식, 화면 요건, 주변 라이브러리까지 포함해 골라야 합니다.

관련 글

• WinForms/WPF/WinUI 선정 가이드 — 관점별 판단표

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

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

• 벤더 SDK가 C/C++용이다
• 기존 DLL을 호출해야 한다
• 빠른 이미지 처리나 디바이스 제어가 있다
• 기존 COM 자산을 써야 한다
• 32bit / 64bit 경계를 넘어야 한다

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

3.3 Windows 앱인가 Web 앱인가

오래된 Windows 앱을 Web으로 옮기고 싶다는 상담도 있습니다. Web화가 맞는 경우도 있으나, 전부를 Web으로 옮기면 되는 것은 아닙니다.

Windows 앱이 맞는 예는 다음과 같습니다.

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

반면 여러 거점에서 같은 데이터를 보고 싶거나, 브라우저만으로 쓰고 싶거나, 단말 관리를 줄이고 싶으면 Web화나 클라우드화가 맞는 경우도 있습니다.

실무에서는 전부를 한 번에 Web으로 옮기지 않고, Windows 앱이 필요한 부분만 남기고 데이터 관리나 열람을 Web 쪽으로 내는 구성도 있습니다.

4. 수탁 개발의 진행 방법

Windows 앱 외주·수탁 개발은 다음처럼 진행하면 안전합니다.

flowchart TD
    S1["1. 현황 파악<br/>업무·환경·기존 자산·증상"]
    S2["2. 관측 지점 설계<br/>로그 / 덤프 / 통신 로그"]
    S3["3. 방침 결정<br/>수정 / 수명 연장 / 단계 이전 / 교체"]
    S4["4. 구현·테스트<br/>정상 경로와 이상 경로"]
    S5["5. 배포·이전<br/>배포 / 업데이트 / 되돌리기 / 병행 가동"]
    S6["6. 유지보수·개선<br/>로그와 문의를 보고 고친다"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6
    S2 -.->|"관측할 수 있어야<br/>고칠 대상이 정해진다"| S3
    S6 -.->|"OS 업데이트·PC 교체·<br/>주변 기기 변경으로 다시"| S1

그림 1: 수탁 개발 6단계와, 관측 지점 설계가 방침 결정보다 앞서는 관계

단계 순서에서 중요한 것은 2의 관측 지점 설계가 3의 방침 결정보다 앞에 있다는 점입니다. 증상 원인을 모르는 채로 수정한다, 다시 만든다고 정하면, 고친 줄 알았는데 고쳐지지 않은 결과가 나오기 쉽기 때문입니다.

4.1 현황 파악

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

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

4.2 관측 지점 설계

장애나 불안정함이 있으면 바로 고치기 전에, 원인을 추적할 수 있게 합니다.

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

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

4.3 방침 결정

현황을 본 뒤에 수정, 수명 연장, 단계 이전, 전면 교체, 장애 조사만 등의 방침을 정합니다.

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

4.4 구현·테스트

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

테스트에서는 정상 경로만이 아니라 이상 경로도 확인합니다.

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

4.5 배포·이전

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

기존 앱에서 이전하는 경우에는 기존·신규 병행 가동, 되돌리기, 데이터 이전, 사용자 교육까지 계획에 넣습니다.

4.6 유지보수·개선

납품 후 로그와 문의 내용을 보면서 운용에 맞게 개선합니다.

Windows 앱은 OS 업데이트, PC 교체, 주변 기기 변경, 보안 방침 변경의 영향을 받습니다. 그래서 유지보수를 전제로 한 설계와 자료화가 빠질 수 없습니다.

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

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

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

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

6. 정리

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

의뢰 전에 잡아 둘 것은 이 5가지입니다.

• 어떤 업무를 멈추고 싶지 않은가
• 기존 자산, 외부 기기, DLL, COM, ActiveX를 포함해 현재 앱과 주변 환경이 어떤가
• 신규 개발인가, 기존 수정인가, 교체인가(WinForms, WPF, WinUI, .NET 이전 등 기술 선정을 포함)
• 배포, 서명, 자동 업데이트, 관리자 권한을 어떻게 다룰 것인가
• 로그, 크래시 덤프, 메모리, 통신 등 조사 설계까지 포함해, 납품 후 유지보수할 수 있는 상태를 어떻게 남길 것인가

Windows 앱은 현장 업무, 장치, 파일, 주변 기기, Windows OS 제약과 깊게 맞물립니다. 그래서 외주·수탁 개발에서는 만드는 것만이 아니라, 조사하고, 고치고, 남기고, 배포하고, 운용하는 것까지 포함해 설계하는 것이 중요합니다.

Windows 앱 외주·수탁 개발, 신규 개발, 기존 소프트웨어 수정·유지보수, 장치 연동, 장애 조사, 배포·업데이트 설계로 곤란한 경우에는, 먼저 현재 상황을 정리하는 것부터 상담해 주세요.

Windows 앱 개발을 상담하기

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

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

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

상담할 수 있습니다. 이 영역에서는 한 번에 전부를 무리하게 교체하기보다, 유지할 부분, 래핑할 부분, 교체할 부분을 나누어 보는 것이 중요합니다. 특히 업무상 아직 동작하는 자산은 리스크를 보면서 단계적으로 이전하는 편이 안전합니다.

Windows 앱을 Web 앱으로 바꿔야 하나요?

목적에 따라 다릅니다. Web 앱은 여러 거점, 단말 관리 간소화, 브라우저 이용에 맞습니다. 반면 장치 연동, 로컬 파일 처리, 오프라인 운용, 기존 DLL 이용이 있으면 Windows 앱을 남기는 편이 자연스러운 경우도 있습니다. 전부를 Web으로 옮기지 않고, Windows 쪽과 Web 쪽의 책임을 나누는 설계도 선택지입니다.

장애 조사만 의뢰할 수도 있나요?

가능합니다. 장시간 가동 후의 크래시, 통신 중단, 메모리 증가, 특정 PC에서만 나는 문제는 바로 고치기보다, 먼저 원인을 추적할 수 있는 상태로 만드는 것이 중요합니다. 로그와 덤프를 갖추고 재현 조건을 좁힌 뒤 수정 방침을 정합니다.

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

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

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

가능합니다. 작은 앱이어도 배포, 업데이트, 로그, 설정, 백업, 담당자 교체까지 생각해 두면 오래 쓰기 쉬워집니다. 특히 Excel 작업 자동화, CSV 변환, 파일 감시, 장표 출력, 장치 데이터 수집 같은 작은 업무 개선에는 Windows 앱이 맞는 경우가 있습니다.

저자 프로필

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

Go Komura

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

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