WPF 외주 개발 2026 — 윈도우 데스크톱 업체 선정과 WinForms·MAUI 비교 7단계

# WPF 외주 개발 2026 — 윈도우 데스크톱 앱 업체 선정과 WinForms·MAUI 비교 7단계

WPF 외주를 찾는 이유는 대개 둘 중 하나다

웹이 표준이 된 지 오래인데도 WPF 외주 문의는 꾸준하다. 이유는 정해져 있다.

첫째, 장비와 붙어야 한다. 계측기·PLC·카메라·바코드 스캐너를 직접 제어해야 하는데, 브라우저는 로컬 하드웨어 접근이 막혀 있다. 제조 현장의 HMI, 검사 장비 UI가 여기 해당한다.

둘째, 기존 윈도우 자산이 있다. 사내에 WinForms로 만든 시스템이 돌아가고 있고 그걸 확장하거나 갈아엎어야 한다. Active Directory 인증, SQL Server 연동, 로컬 파일 시스템 접근이 이미 얽혀 있어 웹으로 옮기는 비용이 크다.

⚠️ 이 둘 중 어디에도 해당하지 않으면 웹을 먼저 검토하는 게 맞다. 「데스크톱이 빠를 것 같아서」는 근거가 약하다. 요즘 업무용 화면은 웹이 배포·업데이트·접근성에서 유리하고, 인력 확보도 쉽다.

판단이 애매하면 이렇게 나눈다. 「이 프로그램이 인터넷 없이 돌아가야 하나」와 「이 PC에 꽂힌 장비를 써야 하나」 둘 다 아니면 웹이다. 사내망만 쓰는 것과 오프라인은 다른 얘기다 — 사내망이면 웹 서버를 사내에 두면 된다.

반대로 데스크톱이 확실히 유리한 경우도 있다. 대량 데이터를 로컬에서 빠르게 처리해야 하거나, 엑셀·한글 같은 설치형 프로그램을 직접 조작해야 하는 경우다.

.NET 스택 전반의 업체 검증은 .NET 외주 개발 업체 선정 가이드에 따로 정리했다.

WPF · WinForms · MAUI · Avalonia — 무엇을 고를 것인가

발주 단계에서 개발사가 이 중 하나를 제안하는데, 차이를 모르면 판단이 안 된다.

국내 외주 시장에서 실질 선택지는 WPF와 WinForms 둘이다. MAUI·Avalonia는 인력 풀이 얇아 유지보수 리스크가 크다.

그래도 WinForms를 고르는 경우

「오래됐으니 WPF」가 항상 맞지는 않다.

• 기존 WinForms 시스템에 화면 몇 개만 추가하는 경우
• UI가 단순한 입력 폼 위주이고 디자인 요구가 없는 경우
• 유지보수 인력이 WinForms만 다루는 경우

⚠️ 혼용도 가능하다. WinForms 안에 WPF 화면을 끼워 넣거나 그 반대도 된다(`ElementHost`·`WindowsFormsHost`). 전체를 갈아엎지 않고 새 화면만 WPF로 가는 방식이 현실적인 경우가 많다.

다만 혼용은 디자인이 어긋나 보인다는 점을 미리 알고 시작한다. 두 프레임워크의 기본 컨트롤 모양이 달라서, 같은 프로그램 안에서 화면마다 버튼 생김새가 다르다. 사용자가 「왜 여기만 이래요」라고 물을 지점이다. 신경 쓰이면 새 화면 쪽에 기존 스타일을 맞추는 작업이 추가로 든다.

MVVM을 요구해야 하는 이유

WPF 외주에서 발주처가 확인할 수 있는 몇 안 되는 기술 항목이다. 제안서에 MVVM 구조가 있는지 본다.

MVVM은 화면(View)·화면 로직(ViewModel)·데이터(Model)를 분리하는 방식이다. 발주처 입장에서 중요한 건 구조 자체가 아니라 그게 없을 때 생기는 일이다.

「코드비하인드에 다 넣는」 방식은 처음엔 빠르지만 화면 20개를 넘어가면서 손을 못 대게 된다. 그리고 그 시점이 대개 개발사와 계약이 끝난 뒤다.

⚠️ 제안서에 MVVM이 적혀 있어도 실제 코드가 그런지는 별개다. 착수 후 첫 화면이 나왔을 때 ViewModel 파일이 실제로 분리돼 있는지 확인한다. 이건 개발자가 아니어도 파일 목록으로 볼 수 있다.

```

✅ MemberListView.xaml 화면

MemberListView.xaml.cs (거의 비어 있어야 정상)

MemberListViewModel.cs 로직이 여기 있다

❌ MemberListView.xaml

MemberListView.xaml.cs 2,000줄 ← 전부 여기 들어 있다

```

`.xaml.cs` 파일이 수백 줄을 넘어가면 구조가 없는 것이다. 첫 화면에서 이걸 확인하면 되돌릴 수 있고, 20개 만든 뒤에는 못 되돌린다.

장비 UI와 업무용 데스크톱은 다른 프로젝트다

같은 WPF인데 견적과 리스크가 완전히 다르다.

장비 UI를 업무용 데스크톱 견적으로 받으면 반드시 초과한다. 통신 프로토콜 대응·실장비 시운전·안전 로직이 통째로 빠져 있기 때문이다.

구분하는 질문은 하나다. 「이 프로그램이 잘못 동작하면 물리적으로 뭔가 움직이나」. 답이 예면 장비 UI이고, 견적·기간·검증 방식이 전부 달라진다. 화면만 안 뜨는 것과 설비가 오작동하는 것은 다른 위험이다.

장비 쪽 상세는 장비 제어 프로그램 개발 외주 가이드에 시리얼·Modbus·PLC별로 정리했다.

배포와 자동 업데이트를 착수 전에 정한다

데스크톱 외주에서 가장 자주 빠지는 항목이다. 웹과 달리 고쳐도 사용자 PC에 자동으로 반영되지 않는다.

⚠️ 「일단 exe로 주세요」가 나중에 가장 비싸다. 사용자 50명에게 배포한 뒤 버그를 하나 고치면, 50대에 다시 설치해야 한다. 자동 업데이트를 넣는 비용은 초기에 며칠이고, 나중에 붙이면 배포 구조를 다시 짠다.

그리고 코드 서명 인증서를 누가 준비하는지 정한다. 없으면 실행할 때마다 윈도우가 「알 수 없는 게시자」 경고를 띄우고, 그걸 본 사용자는 IT팀에 문의한다. 연 수십만 원짜리 항목인데 견적서에서 빠지는 경우가 흔하다.

인증서는 발주처 명의로 발급받는 것이 맞다. 개발사 명의로 서명하면 프로그램 게시자가 개발사 이름으로 뜨고, 나중에 업체를 바꾸면 서명을 새로 해야 한다. 발급에 며칠이 걸리므로 오픈 일정에서 역산해 미리 신청한다.

견적을 가르는 변수

WPF 외주 견적은 화면 개수만으로 안 나온다. 아래가 실제 변수다.

인쇄가 의외로 크다. 화면에 보이는 것과 인쇄물은 다른 작업이고, 라벨 프린터나 정해진 양식 출력이 붙으면 화면 몇 개 분량이 추가된다. 요구사항에 「출력」 한 줄로 적혀 있으면 반드시 구체화한다.

구체화할 항목은 셋이다. 어떤 프린터로 뽑나(일반·라벨·감열지), 양식이 정해져 있나(관공서 제출 서식이면 여백까지 맞춰야 한다), 미리보기가 필요한가. 이 셋에 따라 같은 「출력」이 3일이 되기도 하고 3주가 되기도 한다.

유형별 범위

⚠️ 레거시 전환이 가장 예측이 어렵다. 기존 코드에 문서가 없으면 「무엇을 하는 프로그램인지」부터 역추적해야 하고, 그 시간이 견적에 안 들어가 있는 경우가 많다. 착수 전에 기존 소스와 화면 목록을 넘길 수 있는지 확인한다.

소스를 못 받는 경우도 실제로 있다. 원 개발사와 연락이 끊겼거나 계약상 인도 조항이 없던 경우다. 그때는 실행 파일과 화면 캡처만으로 재작성하게 되는데, 화면에 안 보이는 계산 규칙과 예외 처리는 복원할 방법이 없다. 그 부분은 현재 담당자의 기억에 의존하게 되고, 그게 전환 프로젝트에서 가장 자주 누락되는 요구사항이다.

업체 선정 6가지 기준

1. WPF 실적을 화면으로 확인한다 — 「.NET 경험」이 아니라 실제 WPF 화면 스크린샷이나 시연
2. MVVM 구조를 쓰는지 묻는다 — 안 쓴다면 이유를 듣는다. 답이 막히면 거른다
3. 장비 연동이 필요하면 그 프로토콜 경험을 확인한다 — 「산업 현장 경험」이 아니라 Modbus·시리얼 등 구체적으로
4. 배포 방식 제안이 있는지 본다 — 제안서에 없으면 그 항목을 안 생각한 것이다
5. 소스 코드 인도 조건을 계약서에 넣는다 — 데스크톱은 특히 다음 개발사 교체가 잦다
6. 유지보수 단가와 대응 시간 — 현장에서 멈추면 언제까지 오는지

흔한 실패 4가지

① 장비 연동을 화면 작업으로 견적받는다

가장 비싼 오해다. 통신·실시간성·안전 로직이 통째로 빠진 금액이다.

② 배포를 나중에 생각한다

50대에 수동 설치하는 상황이 되고, 그때 자동 업데이트를 붙이면 구조를 다시 짠다.

③ MVVM 없이 만들어진다

화면 20개를 넘기면서 수정이 불가능해진다. 개발사 교체 시 재작성이다.

④ 인쇄·출력을 한 줄로 적는다

라벨·바코드·정해진 양식은 각각 별도 작업이다. 관공서 제출 서식처럼 여백까지 맞춰야 하는 경우는 특히 시간이 든다.

AI-Native 팀이 WPF 프로젝트를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. WPF에서 시간이 많이 드는 것은 화면을 그리는 일이 아니라 반복되는 구조를 맞추는 일이다.

• MVVM 골격 생성 — 화면마다 반복되는 ViewModel·바인딩·커맨드 구조를 빠르게 세우고, 사람은 업무 로직에 집중한다
• 레거시 WinForms 해독 — 문서 없는 기존 코드에서 화면 목록과 데이터 흐름을 역으로 정리해 전환 범위를 산정한다
• 통신 파서 테스트 — 장비 응답의 정상·분할·타임아웃·깨진 패킷 케이스를 생성해 검증한다

WPF 프로젝트의 품질은 화면이 예쁜가가 아니라 2년 뒤 화면 하나를 추가할 수 있는가로 갈린다. 반복 구조를 자동화해 사람이 업무 규칙에 시간을 쓰게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

WPF가 이제 오래된 기술 아닌가요?

2006년 기술이지만 현재도 .NET에서 정식 지원되고 인력 풀이 가장 두껍다. 윈도우 전용 업무·장비 UI에서는 여전히 실질적인 표준이다.

웹으로 만들면 안 되나요?

장비를 직접 제어해야 하거나 기존 윈도우 자산이 얽혀 있지 않다면 웹이 대체로 낫다. 배포·업데이트·인력 확보가 유리하다.

MAUI로 만들면 모바일도 되지 않나요?

가능하지만 국내 외주 시장에서 MAUI 경험 인력이 얇다. 유지보수 단계에서 사람을 못 구하는 위험이 WPF보다 크다.

기존 WinForms를 WPF로 다 바꿔야 하나요?

아니다. 혼용이 가능해서 새 화면만 WPF로 만드는 방식이 흔하다. 전체 전환은 비용 대비 효과를 따로 계산한다.

개발사가 코드 서명 인증서를 준비해 주나요?

계약에 명시하지 않으면 대개 안 한다. 발주처 명의로 발급받는 것이 맞고, 연 단위 비용이 든다. 발급에 며칠 걸리니 오픈 일정에서 역산해 미리 신청한다.

개발 중에 화면을 바꿔도 되나요?

MVVM 구조가 있으면 화면 배치 변경은 비교적 싸다. 다만 입력 항목이 늘거나 업무 규칙이 바뀌면 그건 화면 수정이 아니라 기능 추가다. 이 구분을 착수 전에 합의해 두면 변경 요청 때 다투지 않는다.

정리

WPF 외주는 기술 선택보다 프로젝트 유형 판별이 먼저다.

실무에서 결과를 가르는 지점은 셋이다.

1. 장비 UI인가 업무 화면인가 — 장비를 업무 화면 견적으로 받으면 반드시 초과한다
2. MVVM 구조가 실제로 있는가 — 없으면 화면 20개에서 손을 못 대게 된다
3. 배포와 서명을 착수 전에 정했는가 — 나중에 붙이면 구조를 다시 짠다

이 셋만 확인해도 데스크톱 외주의 대표적인 사고가 대부분 예방된다.