윈도우 응용 프로그램 개발 2026 — 어플리케이션·GUI 소프트웨어 외주 업체 선정과 발주 체크리스트

윈도우 응용 프로그램 외주 개발은 사용자 PC에 설치해서 쓰는 화면 있는 프로그램을 외부 개발사에 맡겨 만드는 일이다. 브라우저로 접속하는 웹과 달리 설치 파일을 배포해 각 PC에서 실행하며, 국내 외주 시장에서는 대부분 C#과 WPF 또는 WinForms로 만든다. 배포는 앱스토어가 아니라 사내망이나 설치 관리 도구, USB로 이뤄지고, 그 PC에 꽂힌 계측기·PLC·바코드 스캐너 같은 장비를 직접 다뤄야 하는 경우가 많다. 발주서에서는 같은 것을 윈도우 어플리케이션, GUI 소프트웨어, PC 프로그램, 전산 프로그램으로 부르기도 한다.

이 글은 기술을 고르기 전에 발주처가 먼저 답해야 하는 것들을 다룬다. 어떤 프레임워크가 좋은지는 프로젝트 성격이 확정된 다음의 질문이고, 견적서가 서로 다른 숫자로 오는 이유는 대개 그 앞 단계가 비어 있기 때문이다.

발주서에 쓰는 말과 실제로 발주되는 것

같은 프로그램을 부르는 말이 최소 열 가지다. 문제는 이 말들이 서로 다른 범위를 뜻한다는 점이고, 업체마다 다르게 해석해서 견적을 내면 비교 자체가 성립하지 않는다.

여기서 한 가지는 따로 갈라 둘 필요가 있다. 모니터링 프로그램이라고 적었을 때 국내 발주 현장에서 실제로 요구되는 것은 장비 상태, 통신 데이터, 실시간 차트를 보여주는 윈도우 화면이다. 서버와 클라우드 인프라를 관측하는 도구도 같은 단어를 쓰지만 그쪽은 제품군도 예산 구조도 다르다. 발주서에 모니터링이라고만 적으면 이 둘의 견적이 섞여서 들어온다. 무엇을 관측 대상으로 하는지를 첫 줄에 적어 두는 편이 안전하다.

표기 흔들림은 규격서 1항의 정의 조항 한 줄로 닫는다. 윈도우 어플리케이션과 애플리케이션, 윈도우 응용 프로그램과 응용프로그램, 데스크톱과 데스크탑은 모두 같은 것을 가리키지만, 범위 다툼이 생겼을 때는 서로 다른 것을 가리키고 있었다는 주장이 나온다. 그대로 베껴 쓸 수 있는 형태는 이렇다.

계약서에 그대로 넣을 수 있는 문구 제1조(정의) 본 계약에서 「윈도우 응용 프로그램(Windows Desktop Application)」이라 함은 발주처가 지정한 Windows PC에 설치 파일로 배포되어 실행되는 화면 기반 프로그램을 말하며, 발주서·제안서에 기재된 윈도우 어플리케이션, 애플리케이션, 데스크톱 프로그램, GUI 소프트웨어는 모두 동일한 대상을 지칭한다. 화면 없이 상주하는 윈도우 서비스는 별도 산출물로 본다.

첫 번째 갈림길: 이 프로그램이 정말 데스크톱이어야 하는가

총칭어로 문의가 들어오는 단계에서는 데스크톱이 확정된 경우보다 아직 정해지지 않은 경우가 많다. 설치형은 배포, 업데이트, 인력 확보가 모두 웹보다 불리하므로 데스크톱이어야 하는 이유가 하나라도 있을 때만 데스크톱으로 간다. 다만 여기서 흔히 쓰이는 「브라우저는 장비를 못 만진다」, 「웹은 인터넷이 끊기면 안 뜬다」는 설명은 2026년 기준으로 반만 맞다. 경계를 정확히 그어야 견적이 정확해진다.

발주서에는 판단 결과가 아니라 조건을 적는다. 특히 네트워크 항목은 「사내망 전용」과 「네트워크 단절 중에도 동작」을 서로 다른 항목으로 나눠 적는다. 앞엣것은 웹 서버를 사내에 두면 끝나는 요구이고, 뒤엣것은 단절 시간과 그동안의 데이터 처리 방식까지 적어야 하는 요구다. 「폐쇄망이라 exe로 주세요」라고만 적힌 발주서가 가장 자주 잘못된 견적을 부른다.

두 번째 줄에서 데스크톱이 확정됐다면 그 순간 프로젝트 성격이 바뀐다. 장비가 붙으면 통신 규격부터 정해야 하고, 통신 규격은 화면 수보다 견적을 크게 흔든다. 시리얼, Modbus, PLC 전용 프로토콜, OPC UA 중 무엇을 쓰는지와 레지스터 맵 문서를 갖고 있는지가 착수 조건이 되므로, 이 갈래는 장비 제어 프로그램 개발 외주 가이드에서 프로토콜별로 따로 정리했다.

무인 단말처럼 사람이 지키지 않는 자리에 놓이는 화면이라면 데스크톱이긴 하지만 요구사항 목록이 또 다르다. 결제, 영수증, 원격 관리가 처음부터 붙기 때문에 키오스크·POS 프로그램 개발 가이드 쪽이 맞다. 반대로 네 질문에 전부 아니오라면, 맞춤 개발 자체가 필요한지부터 확인하는 편이 낫다. 재고, 고객, 일정처럼 일반적인 업무는 기성 SaaS와 맞춤 개발의 비교에서 갈린다.

두 번째 갈림길: 윈도우에서만 도는가, 맥·리눅스에서도 도는가

데스크톱으로 확정됐다면 다음 질문은 대상 운영체제다. 이 질문을 건너뛰면 착수 후에 「영업팀은 맥을 쓴다」, 「현장 단말은 리눅스다」 같은 사실이 나오고, 그때는 화면을 다시 만드는 비용이 든다.

이 표에서 발주처가 실제로 확인할 수 있는 것은 유지보수 단계다. 확인 방법은 두 가지다. 첫째, 같은 요구사항을 세 곳에 보내고 제안 스택이 갈리는지 본다. 한 곳만 다른 스택을 제안하면 그 이유를 문서로 받는다. 둘째, 유지보수 계약 초안에 인력 교체 조항을 넣어 회신을 받는다. 「담당 개발자 교체 시 인수인계 기간 2주, 승계 대상 문서는 빌드 절차서·통신 사양서·화면 목록」처럼 적어 보내면, 그 스택으로 사람을 붙일 수 있는 업체와 아닌 업체의 답이 갈린다. 처음 만드는 비용보다 3년 차에 화면 하나를 고치는 비용이 문제가 되는 쪽은 대개 이 회신이 모호한 선택지다.

.NET 계열로 좁혀졌다면 그 안에서 무엇을 고를지, 구조가 제대로 잡혀 있는지를 확인하는 단계가 남는다. WPF·WinForms 선택과 MVVM 구조 확인에 프레임워크 비교와 구조 점검 방법이 정리돼 있다. 스택이 정해진 다음의 업체 기술 검증, 계약 조항, 비용 산정 방식은 C#·.NET 업체 기술 검증과 계약 조항 쪽이다.

세 번째 갈림길: 한 대에서 쓰는가, 여러 대가 같은 데이터를 보는가

데스크톱 프로그램 하나를 만드는 줄 알았는데 데스크톱 더하기 서버 더하기 데이터베이스가 되는 지점이 여기다. 견적이 두세 배로 뛰는 이유의 대부분이 이 한 줄에서 갈린다.

세 번째 줄부터는 구조 하나를 더 결정해야 한다. 데스크톱이 데이터베이스에 직접 붙는 구조는 개발이 빠르지만 접속 계정 정보가 사용자 PC 안에 들어간다. 보안 감사에서 지적되는 전형적인 항목이고, 사용자가 늘면 접속 수 관리와 권한 처리가 감당이 안 돼 결국 중간에 서버 레이어를 넣게 된다. 나중에 넣으면 화면 쪽 코드를 상당 부분 다시 쓴다.

착수 시점에 서버 레이어를 넣을지는 인원수가 아니라 세 가지 조건으로 판단한다. 사용자 PC에 DB 접속 계정이 저장되는 구조가 보안 감사 대상인가, 외부망이나 다른 사업장에서 접속할 일이 있는가, DB 라이선스가 접속 수 기준인가. 하나라도 해당하면 착수 시점에 넣는 편이 싸다. 세 가지 모두 아니고 한 사무실 안에서만 쓴다면 직접 연결로 시작해도 된다.

장비나 설비 상태를 윈도우 화면으로 보는 프로그램도 이 갈림길 위에 있다. 장비 한 대 옆 PC에서만 보면 되는지, 사무실에서도 같은 화면을 봐야 하는지에 따라 완전히 다른 프로젝트가 된다. 수집과 통신 쪽 사양은 장비 제어 프로그램 개발 외주 가이드에 프로토콜별로 나눠 두었고, 이 글에서는 화면과 데이터 위치만 다룬다.

네 번째 줄까지 가는 경우, 즉 여러 현장의 데이터를 서버에 모아 이상 징후 탐지나 자동 경보까지 붙이는 경우는 데스크톱 외주의 범위를 넘어간다. 그 단계의 구성과 비용 구조는 서버에 모아 분석하는 관측 시스템 구축에서 따로 다룬다.

네 번째 갈림길: 새로 만드는 일인가, 있던 것을 늘리는 일인가

「기존 프로그램에 화면 몇 개만 추가」는 견적 편차가 가장 큰 요청이다. 같은 문장이 며칠짜리일 수도 있고 재작성일 수도 있다. 가르는 것은 하나, 소스 코드를 확보할 수 있는가이고, 확보 여부는 물어보기 전에는 알 수 없다. 그래서 이 갈림길은 판단이 아니라 절차로 처리한다.

1단계. 원 개발사에 보내는 요청 목록. 견적을 받기 전에 원 개발사에 아래를 그대로 적어 보낸다. 회신이 오는 데 걸리는 시간 자체가 판단 재료다.

• 최종 버전 소스 코드 일체와 형상 이력(Git 저장소 또는 이력 포함 압축본)
• 빌드 절차서. 필요한 IDE·SDK 버전, 외부 라이브러리와 그 버전, 빌드 설정
• 데이터베이스 스크립트와 초기 코드값 데이터
• 장비 통신 사양서와 현장 설정값(장비가 붙는 프로그램인 경우)
• 코드 서명 인증서의 명의와 보관 주체
• 제3자 라이브러리 라이선스 목록과 이전 가능 여부

2단계. 받은 소스가 실제로 도는지 확인하는 조항. 소스를 받았다는 사실과 빌드가 된다는 사실은 다르다. 새 개발사와의 계약에 착수 조건을 넣는다. 「인수한 소스를 지정 환경에서 빌드하여 현행 운영 버전과 동일하게 동작함을 착수 후 N영업일 내에 재현한다. 재현에 실패하는 경우 본 계약은 기능 추가가 아닌 전환 견적으로 재산정한다.」 이 한 줄이 없으면 재현 실패의 비용을 누가 지는지를 개발 중간에 다투게 된다. 재현 확인은 새 개발사가 하되 발주처 담당자가 화면 한 번 띄우는 것까지 참관한다.

3단계. 세 갈래로 견적 단위가 갈린다.

세 번째 줄에서 가장 자주 빠지는 요구사항은 화면에 드러나지 않는 규칙이다. 할인 계산식, 예외 처리, 특정 조건에서만 뜨는 경고 같은 것들은 실행 파일을 봐도 복원되지 않고 현재 담당자의 기억에만 있다. 재작성 착수 전에 그 담당자와 한 번은 앉아서 화면별로 훑어야 하고, 그 시간을 일정에 넣어야 한다. 판단 기준과 전환 방식은 레거시 시스템 전환 판단에, 사내 업무 시스템을 새로 짜는 경우의 범위 설정은 사내 관리 시스템 범위 설정에 정리돼 있다.

지원할 윈도우 범위와 런타임은 누가 정하는가

여기서부터는 웹 외주에는 아예 없는 항목들이다. 견적서에 잘 안 적히고, 안 적히면 검수 단계에서 문제가 된다.

Windows 10 지원은 2025년 10월 14일에 종료됐다. 그 뒤의 보안 업데이트는 확장 보안 업데이트(ESU)로 따로 받는데, 소비자용과 기업용의 종료 시점이 다르다. 소비자용 ESU는 1년짜리로 2026년 10월 13일에 끝나고, 기업용 ESU는 연 단위로 최대 3년까지 구매해 2028년 10월까지 연장할 수 있다. 현장 PC가 아직 Windows 10이라면 지금 확인할 것은 두 가지다. 우리 PC가 어느 트랙으로 ESU를 받고 있는가, 그리고 그 종료일이 이 프로그램의 운영 기간보다 앞서는가.

지원 대상 윈도우 버전과 빌드는 계약서에 숫자로 적는다. 「최신 윈도우에서 동작」이라고 적으면 검수 때 구형 PC 한 대에서 안 도는 것이 누구 책임인지 다투게 된다.

런타임 버전은 트랙까지 같이 적는다. .NET 지원 정책은 LTS와 STS 두 트랙으로 나뉘고 LTS는 3년, STS는 18개월을 지원한다. 그래서 종료일이 서로 다르다. .NET 8(LTS)은 2026년 11월 10일에 끝나고, .NET 9(STS)는 2026년 5월 12일로 이미 지원이 끝났다. 2025년 11월에 나온 .NET 10은 LTS로 2028년 11월 14일까지다. 지금 착수하는 신규 프로젝트를 .NET 8이나 9로 제안하는 업체가 있다면 이유를 물어야 한다. 기존 사내 자산과 맞춘다는 답이면 납득할 수 있지만, 별 이유가 없다면 인도 시점에 이미 지원이 끝났거나 한 해도 못 가는 런타임을 받는 셈이다.

다만 .NET 10에는 운영체제 조건이 붙는다. 지원 운영체제 목록에 올라 있는 Windows 10은 Enterprise LTSC(1607·1809·21H2)와 IoT 에디션뿐이고, 일반 Windows 10 22H2(Home·Pro)는 목록에 없다. Windows 7과 8.1도 지원하지 않는다. 현장 PC가 일반 Windows 10이라면 .NET 10을 그대로 쓸 수 없고, 지원이 끝난 .NET 8이나 .NET Framework 4.8을 검토 대상으로 올리게 된다. 그 자체가 PC 교체 계획을 앞당겨야 하는 근거이고, 교체가 불가능하다면 런타임 선택의 제약을 계약서에 명시해 두어야 한다. 어느 쪽이든 발주처가 먼저 결정해서 알려주는 항목이지 업체가 알아서 정할 항목이 아니다.

런타임을 설치 파일에 동봉할지 여부는 폐쇄망에서는 선택이 아니라 제약이다. 인터넷이 막힌 현장 PC는 런타임을 따로 내려받을 수 없으므로 동봉이 사실상 강제된다. 동봉하면 설치 파일 용량이 커지고 업데이트할 때마다 그 용량이 다시 돈다. USB로 배포하는 환경이라면 이 점을 미리 계산해 둔다.

32비트와 64비트는 취향이 아니라 제약이다

비트수는 개발사가 편한 대로 정하면 되는 항목처럼 보이지만, 실제로는 외부 요인이 먼저 결정한다.

첫째, 장비 SDK가 강제한다. 계측기나 카메라 제조사가 제공하는 DLL이 32비트로만 나온다면 그것을 쓰는 프로그램도 x86으로 빌드해야 한다. 그 순간 프로세스가 쓸 수 있는 메모리 한계가 따라오므로, 대용량 이미지나 장시간 로그를 다루는 기능은 설계를 바꿔야 한다.

둘째, 구형 컨트롤이 강제한다. 오래된 OCX와 ActiveX 컨트롤은 32비트 전용인 경우가 많다. 기존 프로그램에서 그대로 가져다 쓰려면 새 프로그램도 32비트가 된다.

셋째, 오피스 계열 드라이버가 강제한다. 엑셀이나 액세스 파일을 직접 읽는 기능이 있으면 Access Database Engine의 ACE OLEDB 드라이버를 쓰게 되는데, 이 드라이버의 비트수와 프로그램의 비트수가 다르면 실행 시점에 `'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine` 형태의 오류로 죽는다. 프로바이더 번호는 설치된 엔진에 따라 12.0 또는 16.0으로 갈린다.

이 셋은 요구사항 정의서에 한 줄씩만 적으면 되는데, 안 적으면 개발이 거의 끝난 뒤에 드러나서 되돌리는 비용이 크다. 적는 문구는 이런 형태다.

발주서에 그대로 넣을 수 있는 문구 빌드 대상 플랫폼은 x64로 고정한다. 단 연동 대상 장비 SDK가 x86 전용인 경우 착수 후 5영업일 내에 발주처에 통보하고, 그에 따른 메모리 한계 관련 설계 변경 사항을 함께 제출한다. 엑셀·액세스 파일 직접 읽기 기능이 있는 경우, 현장 PC에 설치된 Office 비트수와 Access Database Engine 버전(12.0 또는 16.0)을 착수 전에 조사해 요구사항에 반영한다.

설치 파일에 누가 서명하는가

코드 서명은 예전에는 선택 항목이었지만 최근 2년 사이에 제도가 두 번 바뀌면서 계약 항목이 됐다.

2023년 6월 1일 이후 발급되는 코드 서명 인증서는 OV와 EV를 불문하고 개인키를 FIPS 140-2 또는 140-3 Level 2, 혹은 CC EAL4+ 하드웨어에서 생성하고 보관해야 하며, 그 키는 내보낼 수 없다. 개발사에 `.pfx` 파일을 넘겨서 서명하게 하는 방식이 더는 성립하지 않는다는 뜻이다. 그래서 「USB 토큰이나 HSM을 누가 보관하고, 빌드에 누가 서명하며, 업체가 바뀌면 그 권한을 어떻게 넘기는가」가 계약에 들어가야 할 항목이 된다. 하드웨어 보관 요건은 OV와 EV에 공통으로 걸리지만 가격과 SmartScreen 평판 축적 조건은 여전히 다르므로, 견적서에 「코드 서명 인증서」 한 줄만 적혀 있으면 OV인지 EV인지, 어느 CA 제품인지, 연 단가가 얼마인지를 따로 받아야 세 곳 비교가 성립한다.

유효기간도 줄었다. CA/Browser Forum의 Ballot CSC-31이 2025년 11월 17일 채택되면서 Code Signing Baseline Requirements v3.10.0이 적용됐고, 2026년 3월 1일부터 코드 서명 인증서의 최대 유효기간이 460일이다. 이전 상한은 39개월이었다. 460일은 약 15개월이므로 갱신은 매년이 아니라 15개월 주기로 돌아온다. 계약서에 「연 1회」로 박아 두면 실제 만료일과 어긋난다.

여기서 재서명 비용을 잘못 잡는 경우가 많다. 서명할 때 RFC 3161 타임스탬프를 함께 찍으면 인증서가 만료된 뒤에도 그 바이너리는 계속 유효한 것으로 취급된다. 즉 이미 현장에 깔린 설치 파일을 전수 재서명할 일은 없고, 새 인증서는 갱신 이후에 만드는 신규 빌드에만 적용된다. 계약에 넣을 것은 재서명 비용이 아니라 갱신 시점의 신원 재확인 소요 기간과 신규 빌드 서명 주체다. 같은 이유로 업체를 교체할 때도 기존 배포본을 다시 서명하는 것이 아니라 교체 이후 새로 빌드하는 버전부터 새 인증서로 서명된다. 다만 서명 시 타임스탬프를 찍는다는 조건 자체를 계약이나 요구사항에 명시해 두어야 한다.

인증서를 직접 사는 대신 클라우드 서명 서비스를 쓰는 선택지도 있다. Microsoft의 Azure Artifact Signing(옛 Trusted Signing)은 공식 문서 기준으로 한국을 포함한 국가의 법인에 공개 신뢰 인증서를 발급하며, 개인 개발자는 미국과 캐나다 거주자만 가능하다. Korea Central 리전을 제공하고, 신원 검증에 영업일 기준 1일에서 20일이 걸린다. 제출 서류는 12개월 이내에 발급된 것이어야 하고 만료일이 최소 2개월 이상 남아 있어야 한다. 검색하면 한국은 지원하지 않는다고 쓴 2차 자료가 나오지만 1차 문서 기준으로는 사실이 아니다. 다만 검증 기간이 최대 4주에 가까울 수 있으므로 오픈 일정에서 역산해 미리 신청해야 한다.

서명을 안 하면 실제로 벌어지는 일은 세 단계다. 실행할 때 윈도우 SmartScreen이 알 수 없는 게시자 경고를 띄우고, 국내 백신이 설치 파일을 격리하며, 결국 사용자가 IT 담당자에게 문의한다. 사내 배포라도 대수가 많으면 이 문의가 운영 비용이 된다. 인증서를 발주처 명의로 받으면 게시자 이름이 발주처로 뜨고 업체를 바꿔도 그 명의가 유지되므로, 특별한 사정이 없으면 발주처 명의가 기본이다.

배포 방식별로 서명이 언제 필요한지는 다음과 같이 갈린다.

표의 근거는 MSIX 지원 플랫폼 문서와 ClickOnce 서명 요건 문서다.

자동 업데이트를 붙이기 전에 정할 네 가지

자동 업데이트는 붙이기로 결정하는 순간 배포 구조 전체가 따라 바뀐다. 다음 네 가지가 안 정해진 채로 붙이면 나중에 다시 짠다.

1. 업데이트 서버는 누가 호스팅하는가. 개발사 서버에 두면 계약 종료 후 업데이트가 멈춘다. 발주처 인프라에 두면 초기 구축 공수가 든다.
2. 사용자가 쓰고 있는 중에 새 버전이 올라오면 어떻게 하는가. 강제로 종료할지, 다음 실행 때 적용할지, 작업 중 데이터를 어떻게 보존할지가 화면 설계에 영향을 준다.
3. 문제가 생겼을 때 이전 버전으로 되돌릴 수 있는가. 롤백을 지원하려면 이전 설치 파일 보관과 데이터 구조 하위 호환이 필요하다.
4. 특정 버전 미만은 실행을 막을 것인가. 서버나 장비 규격이 바뀌는 경우 구버전이 잘못된 데이터를 쓰는 사고가 나므로 최소 버전 강제가 필요할 수 있다.

다중 모니터와 DPI가 견적에 들어오는 지점

현장 PC는 사무실 노트북과 화면 환경이 다르다. 고해상도 모니터와 일반 모니터를 같이 쓰거나, 노트북을 도킹 스테이션에 꽂았다 뺐다 하거나, 원격 데스크톱으로 접속한다. 이 환경에서 글자가 흐려지거나 레이아웃이 어긋나는 문제가 DPI 스케일링이다.

Microsoft의 High DPI 문서에 따르면 모니터마다 배율을 따로 적용하는 Per-Monitor V2는 Windows 10 1703부터 쓸 수 있고, 그 이전 방식인 V1은 8.1부터다. 다만 어느 프레임워크든 PMv2는 매니페스트로 프로세스 단위 선언을 해야 켜진다. 자동으로 되는 것이 아니다.

검수 시나리오는 셋으로 고정해 두면 된다. ① 노트북을 도킹 스테이션에 꽂고 빼는 동안 창 레이아웃이 유지되는가, ② 4K 모니터와 FHD 모니터에 창을 하나씩 걸쳐 놓았을 때 글자가 흐려지지 않는가, ③ 고해상도 노트북에서 저해상도 기기로 원격 데스크톱 접속했을 때 화면이 깨지지 않는가. 검수 환경에 이 셋이 없으면 통과했다가 현장에서 문제가 나온다.

다중 모니터를 쓰는 현장이라면 두 가지를 요구사항에 더 적는다. 창 위치와 크기를 저장했다가 다음 실행 때 복원할 것인지, 그리고 모니터를 하나 빼서 저장된 위치가 화면 밖이 됐을 때 어떻게 처리할 것인지다. 두 번째는 적어 두지 않으면 프로그램이 보이지 않는 곳에 떠서 사용자가 실행이 안 된다고 문의하게 된다.

관리자 권한, 오프라인 동작, 백신

권한. Program Files 아래에는 프로그램이 자기 설정 파일, 로그, 데이터베이스 파일을 쓸 수 없다. 그래서 쓰기가 필요한 파일은 %ProgramData%나 %AppData% 경로로 잡아야 한다. 이것을 피하려고 요구사항에 「관리자 권한으로 실행」을 넣는 경우가 있는데, 그러면 표준 사용자 계정을 쓰는 보안 정책, 부팅 시 자동 시작, 무인 설치와 전부 충돌한다. 대가를 알고 넣는 것과 모르고 넣는 것은 다르다.

오프라인. 네트워크가 끊긴 상태에서 동작해야 한다면 네 가지를 발주서에 적는다. 라이선스나 인증을 어떻게 처리할지, 시각 동기화가 안 될 때 기록 시각을 무엇으로 삼을지, 업데이트 확인이 실패할 때 얼마나 기다렸다 넘어갈지, 그리고 오프라인 동안 쌓인 데이터를 나중에 어떻게 동기화할지다. 마지막 항목이 빠지면 나중에 데이터 중복과 충돌 처리를 다시 개발한다.

백신과 보안 정책. 서명 없는 실행 파일이 국내 백신에 격리되는 일은 흔하다. 공공기관이나 대기업 현장에서는 매체 제어 정책이 USB와 시리얼 포트 접근 자체를 막는 경우도 있다. 확인은 착수 전에 정보보안 담당자에게 네 가지를 서면으로 회신받는 형태로 한다. 매체 제어 정책의 적용 범위(USB 저장장치·시리얼 포트·COM 포트), 서명 없는 실행 파일의 격리 정책, 화이트리스트 등록 절차와 소요일, 원격 접속 허용 여부와 허용 도구. 개발이 끝난 뒤에 확인하면 예외 처리를 받는 데 걸리는 시간이 일정에 그대로 얹힌다.

어느 유형의 팀으로 가야 하는가

업체를 고르는 일반적인 절차는 IT 외주 프로젝트 진행 절차와 외주 업체 선정 배점표에 정리돼 있다. 여기서는 데스크톱 프로젝트에서만 갈리는 축, 즉 어느 유형의 팀에 문의를 넣어야 하는지만 다룬다. 같은 「윈도우 프로그램 개발 회사」라도 잘하는 영역이 서로 다르다.

확인 방법은 질문 하나로 충분한 경우가 많다. 견적 회의에서 지원 대상 윈도우 버전, 코드 서명 주체, 배포 방식을 먼저 물었을 때 바로 답이 나오는 팀과 나중에 정하자는 팀은 데스크톱 프로젝트를 실제로 해 본 횟수가 다르다.

산출물과 인도 항목을 계약서에 적는다

데스크톱 프로젝트는 인도 후에 개발사를 바꾸는 일이 드물지 않다. 그때 다음 개발사가 이어받을 수 있는지는 계약서에 무엇이 적혀 있었는지로 결정된다.

• 설치 파일과 빌드 산출물. 최종 버전만이 아니라 버전별로 보관할 것인지를 정한다.
• 소스 코드와 형상 이력. 최종 압축 파일만 받으면 왜 그렇게 고쳤는지가 사라진다.
• 빌드 절차 문서. 소스가 있어도 빌드가 안 되는 경우가 실제로 많다. 필요한 SDK 버전과 외부 라이브러리 목록이 여기 들어간다.
• 데이터베이스 스크립트와 초기 데이터. 스키마만 있고 초기 코드값이 없으면 새 환경을 못 세운다.
• 코드 서명 인증서의 귀속. 발주처 명의인지, 토큰이나 HSM 접근 권한을 누가 보관하는지를 문서로 남긴다.
• 사용자 매뉴얼과 운영 절차. 장애 시 무엇을 먼저 확인하는지가 들어가야 실제로 쓰인다.
• 장비 통신 사양과 현장 설정값. 장비가 붙는 프로젝트라면 이것이 없으면 다음 팀은 처음부터 다시 조사한다.

문서 항목을 발주서 단계에서 어떻게 적는지는 산출물과 RFP 요구사항 정리에, 검수 기준으로 바꾸는 방법은 테스트 케이스 작성과 검수에 정리돼 있다.

유지보수와 하자보수는 어디서부터 세는가

하자보수와 유지보수는 다른 것이다. 하자보수는 계약한 대로 동작하지 않는 것을 고치는 일이고, 유지보수는 계약 범위 밖의 변경과 운영 지원이다. 이 구분이 없으면 인도 직후부터 모든 요청이 무상 하자보수 요구로 들어온다.

정리하면 이렇다. 연 유지보수 요율은 계약금액의 10~15%가 통상 범위다. 하자보수 기간은 계약에 명시하지 않으면 민법 제670조에 따라 인도일부터 1년이고, 명시하는 경우 3~12개월 범위에서 정한다. 기산점은 검수확인서 날짜로 잡는 것이 분쟁이 적다. 인도와 검수가 몇 달 떨어져 있는 프로젝트에서는 이 한 줄의 차이가 크다. 계약 형태별 세부와 소스 코드 에스크로는 에스크로·하자보수·유지보수 계약 정리에 표로 나와 있다.

데스크톱 프로젝트에서 유지보수 범위에 추가로 들어가야 하는 항목이 하나 있다. 앞에서 본 코드 서명 인증서 갱신이다. 유효기간이 460일이므로 15개월마다 갱신과 신원 재확인이 돌아오고, 계약에 없으면 그때마다 별도 비용 협의를 하게 된다. 갱신 이후 첫 빌드를 누가 서명하는지까지 같이 적어 둔다.

견적을 비교할 때: 기준선과 자주 빠지는 항목

총액이 타당한지 보려면 기준선이 있어야 한다. 아래는 트리숲이 다른 글에서 정리해 둔 유형별 범위를 한곳에 모은 것이다. 상세 산정 근거와 변수는 각 글에 있고, 여기서는 견적 세 장을 나란히 놓을 때의 출발점으로만 쓴다.

이 표는 하한선이지 예상가가 아니다. 세 곳에서 받은 견적의 총액이 크게 다르다면 대개 아래 항목들이 포함 여부에서 갈린 것이므로, 총액을 비교하기 전에 이 항목들이 각 견적서에 분리 표기돼 있는지부터 확인한다.

자주 묻는 질문

윈도우 응용 프로그램과 윈도우 서비스는 뭐가 다른가요?

화면 유무가 다르다. 응용 프로그램은 사용자가 실행해서 화면을 보고 쓰는 것이고, 윈도우 서비스는 화면 없이 부팅 때부터 상주하며 처리만 한다. 데이터 수집을 24시간 돌려야 하는데 사용자가 로그아웃해도 계속돼야 한다면 서비스가 필요하고, 그 경우 화면 프로그램과 서비스 두 개를 만드는 프로젝트가 된다. 견적을 비교할 때 이 둘을 한 덩어리로 적으면 업체마다 다르게 읽는다.

견적서에 인력 등급별 단가가 적혀 있는데, 데스크톱 프로젝트에는 어떤 구성이 맞나요?

등급 구성보다 먼저 볼 것은 역할이 나뉘어 있는지다. 데스크톱 프로젝트에서 실제로 따로 필요한 역할은 화면·업무 로직 개발, 장비나 DB 연동, 그리고 배포·설치·서명 처리다. 세 번째가 견적서에 아예 없는 경우가 많은데 그 업체는 그 공수를 계산하지 않은 것이다. 인력 수와 기간을 곱한 값(인월)이 같은데 총액이 다르다면 등급 구성이 다른 것이므로, 투입 인력의 실제 이력서를 제안서 단계에서 요구한다. 제안서 인력과 투입 인력이 다른 것은 대형 원청 구조에서 특히 자주 생긴다.

설치 파일을 보안팀이 반려했습니다. 개발사에 무엇을 요구해야 하나요?

반려 사유부터 서면으로 받는다. 사유는 대개 셋 중 하나다. 서명이 없거나, 백신이 휴리스틱으로 잡았거나, 화이트리스트에 없는 실행 파일이라서다. 개발사에 요구할 것은 서명된 설치 파일과 그 인증서 정보, 설치 파일의 해시값(SHA-256), 설치 시 생성·수정되는 경로 목록, 그리고 프로그램이 여는 네트워크 포트와 통신 대상이다. 이 네 가지가 화이트리스트 등록 신청서의 표준 첨부 항목이고, 없으면 보안팀이 검토를 시작할 수 없다. 등록 소요일을 미리 확인해 오픈 일정에 넣는다.

장비 제조사가 SDK와 통신 사양서를 안 줍니다. 착수해도 되나요?

착수 조건이 성립하지 않는다. 레지스터 맵이나 통신 사양서 없이 견적을 내는 업체는 그 부분을 추정으로 잡은 것이고, 착수 후에 범위 변경으로 돌아온다. 순서를 바꿔서, 장비 구매 계약이 살아 있다면 제조사에 사양서 제공을 요청하고, 이미 끝난 건이라면 유상으로라도 받는다. 그것이 불가능하면 통신 패킷을 직접 관찰해 규격을 역추적하는 작업을 별도 항목과 별도 기간으로 잡아 발주한다. 이 작업의 결과가 안 나올 수도 있다는 점을 계약에 명시한다.

검수를 개발사 PC에서 해도 되나요, 현장 PC여야 하나요?

현장 PC다. 데스크톱 프로젝트에서 검수 통과 후 문제가 터지는 원인은 대부분 환경 차이이고, 개발사 PC에는 그 차이가 없다. 검수 환경으로 맞춰야 하는 항목은 윈도우 버전과 에디션, 오피스 비트수, 백신과 보안 정책, 화면 배율과 모니터 구성, 그리고 실제 장비다. 이 다섯을 검수확인서 앞에 목록으로 붙이고, 발주처와 개발사가 각각 무엇을 준비하는지 나눠 적는다. 현장 PC를 뺄 수 없다면 같은 이미지로 복제한 PC를 한 대 준비하는 편이 낫다.

개발사가 원격 접속을 요구하는데 어디까지 허용해야 하나요?

용도를 개발용과 장애 대응용으로 나눠서 판단한다. 개발 기간의 접속은 테스트 환경에 한정하고 운영 데이터에는 닿지 않게 하는 것이 기본이다. 인도 후 장애 대응용 접속은 유지보수 계약 항목이므로, 허용 도구, 접속 가능 시간대, 접속 시 발주처 담당자 동석 여부, 접속 기록 보관 방식을 적어 둔다. 원격 접속을 아예 막는 현장이라면 그만큼 현장 방문 회차가 유지보수 단가에 들어가야 하므로, 보안팀 확인은 계약 전에 끝내는 편이 싸다.

트리숲이 이 유형의 프로젝트를 다루는 방식

트리숲은 데스크톱 프로젝트에서 반복되는 부분, 즉 화면 골격 생성, 데이터 구조와 화면의 연결, 테스트 케이스 초안 작성을 자동화하고 사람 시간을 업무 규칙 확정과 현장 검증에 쓴다. 발주처가 확인할 수 있는 형태로 적으면 이렇다. 착수 전에 현장 환경 점검표(윈도우 버전과 에디션, 오피스 비트수, 보안·매체 제어 정책, 장비 프로토콜과 사양서 보유 여부, 모니터 구성)를 보내 회신을 받고, 착수 후 첫 주에 화면 골격과 테스트 케이스 초안을 제출한다. 이 글에서 내내 말한 항목들이 그대로 그 점검표의 내용이다. 방식에 대한 관점은 AI-Native 개발 방식에 정리해 두었다.

정리

윈도우 응용 프로그램 외주에서 견적이 어긋나는 이유는 기술 선택이 아니라 그 앞의 네 가지가 비어 있기 때문이다. 각 항목 뒤에 발주서 어디에 무엇을 적는지를 붙였다.

1. 데스크톱이어야 하는 이유가 있는가. 발주서 환경 항목에 「사내망 전용」과 「네트워크 단절 중 동작(단절 시간 O시간)」을 별개 줄로 적는다.
2. 윈도우에서만 도는가. 대상 운영체제 항목에 사용자 부서별 PC 구성을 적고, 유지보수 계약 초안에 인력 교체 시 인수인계 조항을 넣는다.
3. 데이터를 어디 두는가. 보안 감사 대상 여부, 외부망 접속 여부, DB 라이선스 방식 세 줄을 적으면 서버 레이어 필요 여부가 결정된다.
4. 새로 만드는가, 있던 것을 늘리는가. 원 개발사에 소스·빌드 절차서·DB 스크립트 인도 가능 여부를 먼저 묻고, 계약에 빌드 재현 착수 조건을 넣는다.

여기에 데스크톱에만 있는 항목 네 가지를 발주서에 적으면 견적 비교가 성립한다. 지원 대상 윈도우 버전과 에디션, 런타임 트랙과 배포 방식·비트수, 배포 방식과 코드 서명 주체·등급, 그리고 자동 업데이트 운영 주체다.

발주 단계별로 함께 볼 문서