.NET 외주 개발 업체 선정부터 계약까지 실무 가이드

.NET 외주 개발을 처음 알아보는 기업 담당자라면, "어디서 시작해야 하는가"부터 막막하다. ASP.NET Core, Blazor, WPF, MAUI — 기술 스택 이름은 익숙한데, 어느 업체가 실제로 그 스택을 제대로 다루는지 검증하는 방법은 따로 배운 적이 없다. 이 글은 그 검증 방법, 계약 구조, 비용 산정 방식, 그리고 흔한 실패 패턴을 실무 관점에서 정리한다. AI-Native 방식으로 개발 속도를 높인 팀이라면 동일한 .NET 프로젝트를 더 짧은 주기로 납품할 수 있다 — 그 메커니즘까지 설명할 것이다.

---

.NET 외주 개발이란 무엇인가?

.NET 외주 개발이란 Microsoft의 .NET 런타임과 C# 언어를 기반으로 하는 소프트웨어 개발을 외부 업체 또는 팀에 위탁하는 방식이다. 단순히 코드를 받아오는 것이 아니라, 요구사항 분석·설계·개발·테스트·배포까지의 전 과정을 외부 전문 인력에게 맡기는 계약 형태다.

.NET의 적용 범위는 넓다. 기업 내부용 ERP 모듈, 대고객 B2C 웹 서비스(ASP.NET Core), 데스크탑 애플리케이션(WPF, WinForms, MAUI), 제조 현장의 HMI 소프트웨어, 금융·의료 분야의 백엔드 API — 이 모두가 .NET 외주의 실제 수요처다. 공통점은 Windows 생태계와의 친화성, Active Directory 연동, SQL Server와의 긴밀한 통합이다.

발주자 입장에서 .NET 외주를 선택하는 이유는 대개 두 가지다. 첫째, 기존에 .NET으로 구축된 레거시 시스템이 있어서 그 스택을 유지해야 한다. 둘째, 엔터프라이즈 환경에서 Microsoft 생태계를 사용 중이고, Azure와의 네이티브 연동이 필요하다. 어느 경우든 "C# 할 줄 아는 개발자"가 아니라 "해당 도메인을 .NET으로 구현해본 팀"이 필요하다는 점이 핵심이다.

.NET과 Java 스프링 기반 외주는 종종 혼용되어 비교된다. 기술적 완성도 면에서 우열을 가리기 어렵지만, 팀 선정 시 참고할 기준은 명확하다: 발주자 조직의 운영 환경, 유지보수 담당자의 기술 수준, 클라우드 공급사(Azure vs AWS vs GCP) 중 어디를 쓰는지다. 이 세 가지가 Microsoft 쪽이라면 .NET 선택이 운영 비용을 낮춘다.

---

어떤 프로젝트에 .NET 외주가 맞는가?

.NET이 강점을 발휘하는 프로젝트 유형과 그렇지 않은 유형은 뚜렷하게 구분된다. 아래 표는 의사결정 기준을 정리한 것이다.

프로젝트가 표의 상단에 해당한다면 .NET 외주 업체를 찾는 것이 맞다. 중간 이하라면, .NET 고집 대신 "어떤 스택이 이 팀이 더 빠르게 납품할 수 있는가"를 기준으로 재검토할 가치가 있다.

---

.NET 외주 업체를 어떻게 기술적으로 검증할까?

외주 업체의 기술력을 검증하는 가장 빠른 방법은 코드 리뷰와 아키텍처 설명 요청이다. 포트폴리오 페이지의 스크린샷이나 클라이언트 목록은 참고 자료일 뿐, 기술 수준의 증거가 되지 않는다.

1단계 — 기술 질문지 발송. 사전에 아래 항목을 서면으로 질문한다.

• ASP.NET Core 미들웨어 파이프라인 커스터마이징 경험이 있는가?
• 의존성 주입(DI) 컨테이너를 직접 구성해본 프로젝트가 있는가?
• Entity Framework Core에서 N+1 쿼리를 어떻게 방지하는가?
• Blazor Server와 Blazor WebAssembly 중 어느 쪽을 선택하는 기준은?
• .NET 8 이후의 Native AOT 컴파일을 실제 프로덕션에 적용해봤는가?

이 질문들은 정답이 공개된 것들이다. "경험이 있다"는 답변 대신, 실제로 어떤 트레이드오프를 선택했고 왜 그랬는지를 묻는다. 납득할 수 있는 설명이 나오지 않으면 그 업체의 실전 경험을 의심해야 한다.

2단계 — 소규모 테스트 과제. 전체 프로젝트를 바로 맡기기 전에, 실제 요구사항에서 추출한 작은 기능 하나를 개발 의뢰한다. 예를 들어, "JWT 인증이 붙은 REST API 엔드포인트 2개, 단위 테스트 포함"처럼 구체적으로 범위를 제한한다. 코드를 받았을 때 테스트 커버리지가 있는지, 예외 처리가 일관적인지, 네이밍 컨벤션이 .NET 가이드라인(Microsoft Naming Conventions)을 따르는지 확인한다.

3단계 — CI/CD 파이프라인 질문. 납품 코드가 어떤 빌드 파이프라인으로 검증되는지 물어본다. GitHub Actions나 Azure DevOps 기준으로, dotnet build → dotnet test → SonarQube 정적 분석 → Docker 이미지 빌드까지 자동화가 되어 있는 팀인지 확인한다. 이 파이프라인이 없는 팀은 "작동은 하는데 유지보수가 안 되는" 코드를 납품할 가능성이 높다.

---

.NET 외주 개발 비용은 어떻게 산정되는가?

비용 산정 방식은 계약 구조와 직결된다. 업계에서 쓰이는 방식은 크게 세 가지다.

고정가(Fixed Price). 요구사항이 명확하게 문서화된 프로젝트에 적합하다. 발주자 입장에서 예산 통제가 쉽지만, 요구사항 변경이 발생하면 추가 계약이 필요하다. .NET ERP 모듈처럼 기능 명세가 이미 있는 경우에 주로 쓴다.

시간제(Time & Material). 요구사항이 유동적이거나, MVP를 만들면서 방향을 조정해야 하는 스타트업 프로젝트에 맞다. 단, 상한선(cap)을 계약서에 명시하지 않으면 비용 통제가 어렵다.

마일스톤 기반. 고정가와 T&M의 중간이다. 1차 납품(설계+DB 스키마), 2차 납품(API 완성), 3차 납품(프론트엔드+QA) 등으로 단계를 나누고 각 단계마다 검수 후 비용을 집행한다. 발주자가 중간에 방향을 바꿀 수 있고, 업체는 작업 범위를 관리할 수 있어서 실무에서 가장 많이 쓰이는 구조다.

비용의 절대 수준은 팀 구성, 개발 기간, 온/오프프레미스 배포 여부에 따라 달라진다. 국내 시장 기준으로, 소규모 .NET 웹 API 프로젝트(3~4개월, 2명 팀)와 대형 SI 사이의 격차는 수배에 달한다. 중요한 것은 "얼마냐"가 아니라 "무엇이 포함되어 있는가"다. 단위 테스트, 배포 파이프라인, 코드 문서화, 납품 후 안정화 기간이 계약에 포함되어 있는지 반드시 확인한다. 구체적인 비용 구간과 견적서 검토 항목은 .NET Core 백엔드 외주 비용 산정 방법에서 상세히 다룬다.

---

.NET 외주 계약서에서 놓치기 쉬운 조항은?

계약서는 프로젝트가 잘 진행될 때가 아니라 문제가 생겼을 때 기준이 된다. 따라서 "우리는 신뢰 기반으로 합니다"라는 말은 계약 조항을 대체할 수 없다.

소스코드 소유권. 납품 시점에 소스코드의 저작권이 발주자에게 완전히 이전되는지 확인한다. 일부 계약에서는 "사용권만 부여"되는 경우가 있는데, 이 경우 나중에 다른 업체로 전환할 때 문제가 생긴다. 소유권 조항의 세부 구성과 산출물 유형별 귀속 방식은 AI 개발 외주 계약에서 소스 코드 소유권을 명확히 귀속하는 방법에서 자세히 정리했다.

기술 부채 책임 범위. "작동하는 코드"와 "유지보수 가능한 코드"는 다르다. 납품 기준을 계약에 명시해야 한다. 예를 들어, "단위 테스트 커버리지 60% 이상, SonarQube 기준 Critical 이슈 0건" 같은 객관적 기준을 넣는다.

하자보수 기간. 납품 후 일정 기간 내 발견된 버그는 무상으로 수정한다는 조항이다. 통상 1~3개월이며, 기간과 범위(기능 결함만인지, 성능 이슈도 포함인지)를 명확히 한다.

변경 요청 프로세스(Change Request). 개발 중 요구사항이 바뀌는 것은 자연스러운 일이다. 그런데 이 과정이 구두로만 진행되면 나중에 "그런 말 한 적 없다"는 분쟁이 생긴다. CR은 항상 서면으로, 비용과 일정에 대한 영향을 명시하고 양측이 확인하는 절차를 계약에 박아야 한다.

NDA와 보안 조항. .NET 시스템은 기업 내부 데이터를 다루는 경우가 많다. 개발 중 접근하는 데이터의 범위, 개발자 계정 관리 정책, 프로젝트 종료 후 데이터 삭제 확인서 수령까지 포함한다.

---

AI-Native 개발 방식이 .NET 외주 속도에 미치는 영향

AI-Native 팀과 일반 외주 팀의 차이는 결과물의 방향이 아니라 개발 루프의 밀도에서 드러난다. 전통적인 .NET 외주 프로세스는 요구사항 분석 → 설계 → 개발 → 코드 리뷰 → QA → 배포의 선형 흐름이다. 이 루프의 주기가 2~4주 단위일 때, 요구사항 오해나 설계 결함은 늦게 발견된다.

AI-Native 방식에서는 이 루프가 훨씬 촘촘하게 돌아간다. Claude Code Max와 같은 AI 코딩 환경을 표준 개발 도구로 쓰는 팀은, 보일러플레이트 코드 생성·단위 테스트 작성·리팩터링 제안을 AI와 페어 프로그래밍 방식으로 처리한다. 개발자가 설계 판단에 집중하는 시간이 늘어나고, 반복적인 코드 작성 시간은 줄어든다.

.NET 프로젝트에서 이 방식이 특히 효과적인 영역은 두 가지다. 첫째, Entity Framework Core 마이그레이션과 DTO 매핑 코드처럼 구조가 정해진 반복 작업이다. 이 부분은 AI가 패턴을 이해하고 생성 속도를 크게 높인다. 둘째, Playwright MCP를 활용한 E2E 자동 QA다. 테스트 시나리오를 자연어로 기술하면 테스트 코드로 변환되는 방식이라, QA 작업의 병목이 줄어든다.

주의할 점은, AI 코딩 도구가 개발자의 판단을 대체하지 않는다는 것이다. ASP.NET Core의 미들웨어 순서, 인증 흐름의 보안 설계, 데이터베이스 인덱스 전략 — 이런 결정은 여전히 사람의 경험이 필요하다. AI-Native 팀의 강점은 "AI가 다 해준다"가 아니라, "판단이 필요한 일에 더 많은 시간을 쓸 수 있다"는 구조다.

treesoop.com은 AI-Native 개발 방식을 표준 개발 환경으로 채택한 팀으로, .NET 기반의 기업 내부 시스템 외주를 포함한 AX 프로젝트에서 이 구조를 적용하고 있다.

---

.NET 외주 개발 프로세스는 어떻게 구성해야 하는가?

발주자가 프로세스를 설계할 때 참고할 수 있는 단계별 구성이다.

0단계 — 요구사항 문서화. 기능 요구사항(FR)과 비기능 요구사항(NFR)을 분리한다. FR은 "사용자가 무엇을 할 수 있어야 하는가", NFR은 "시스템이 어떤 조건에서 동작해야 하는가(응답속도, 동시 접속자, 보안 등급 등)"다. NFR이 빠진 외주 계약은 나중에 "작동은 하는데 느리다"는 분쟁으로 이어진다.

1단계 — 업체 선정 (2~3주). 앞서 설명한 기술 질문지와 소규모 테스트 과제를 통해 2~3개 업체를 최종 후보로 좁힌다. 이 단계에서 계약서 초안도 함께 검토하기 시작한다.

2단계 — 설계 단계 (1~2주). 데이터베이스 스키마, API 인터페이스 정의(OpenAPI spec), 시스템 아키텍처 다이어그램을 업체에서 제출하게 한다. 이 산출물을 검토하기 전에 개발을 시작하면 안 된다.

3단계 — 개발 + 주 단위 리뷰 (프로젝트 기간 내). 1주 단위 마일스톤으로 진행 상황을 공유받는다. Jira나 Linear 같은 이슈 트래커를 공유하고, 진행 중인 이슈의 상태를 언제든 볼 수 있어야 한다. 이메일로 "이번 주 진행 상황"을 받는 구조는 너무 느리다.

4단계 — QA 및 수락 테스트 (1~2주). 발주자 측에서 직접 수락 테스트(UAT)를 수행한다. 외주 업체의 QA 결과만 믿지 말 것. 실제 사용 환경에서 발생하는 엣지 케이스는 발주자가 더 잘 안다.

5단계 — 배포 및 안정화 (2~4주). 프로덕션 배포 후 첫 2~4주는 모니터링 집중 기간이다. Application Insights나 Sentry를 통해 에러율을 추적하고, 이상이 발생하면 업체와 즉시 대응하는 채널을 유지한다.

---

레거시 .NET Framework 시스템을 어떻게 .NET Core로 전환하는가?

많은 기업이 .NET Framework 4.x 기반의 레거시 시스템을 가지고 있다. 이 시스템을 .NET 8 이상으로 마이그레이션하는 작업 역시 외주의 주요 수요다.

마이그레이션 전략은 크게 두 가지다. Big Bang과 Strangler Fig 패턴이다. Big Bang은 전체 시스템을 한 번에 재작성하는 방식으로, 프로젝트 기간 동안 기존 시스템이 계속 운영된다면 최신 코드와의 동기화 문제가 발생한다. 대규모 시스템에서는 위험이 크다.

Strangler Fig 패턴(Martin Fowler가 정의한 개념)은 기존 시스템을 바로 교체하는 대신, 새 기능은 .NET 최신 버전으로 작성하고 기존 기능은 점진적으로 이전하는 방식이다. 기존 시스템이 계속 작동하면서 새 시스템이 그것을 "감싸며" 성장한다. 실무에서는 이 패턴이 훨씬 안전하다.

.NET Framework에서 .NET 8로 이전 시 대표적인 걸림돌은 다음과 같다.

• System.Web 의존성. HttpContext, HttpModules, HttpHandlers는 ASP.NET Core에서 완전히 재설계됐다. 이 부분을 직접 포팅하는 건 불가능하고, 미들웨어 방식으로 재구현해야 한다.
• WCF 서비스. ASP.NET Core gRPC나 REST API로 대체를 고려해야 한다. CoreWCF 오픈소스 프로젝트가 일부 시나리오를 커버하지만 완전한 대안은 아니다.
• 전역 정적 상태 사용. .NET Framework 시절 관행이었던 정적 클래스 기반의 전역 상태 관리는 .NET Core의 DI 중심 아키텍처와 충돌한다. 리팩터링 범위가 생각보다 넓어질 수 있다.

마이그레이션 외주를 맡길 때는, 업체가 .NET Upgrade Assistant(Microsoft 공식 도구)를 활용해 자동 분석을 먼저 수행하는지 확인한다. 이 도구는 포팅 불가 API의 목록과 마이그레이션 복잡도 점수를 출력한다. 이 결과 없이 공수 산정을 하는 업체는 견적의 신뢰도가 낮다.

---

.NET 외주 업체 유형별 비교 기준

발주자가 접하는 업체 유형은 크게 넷으로 나뉜다.

이 표에서 "어느 유형이 낫다"는 정답이 없다. 프로젝트 규모, 발주자 조직의 내부 기술 역량, 계약 요건(법인 계약 필수 여부)에 따라 선택이 달라진다. 단, 어느 유형을 선택하든 앞서 설명한 기술 검증 단계는 생략하지 않는다.

---

.NET 외주에서 자주 발생하는 실패 패턴

경험상 .NET 외주 프로젝트가 실패하는 경우는 기술이 아닌 프로세스와 커뮤니케이션에서 비롯된다.

요구사항 모호성. "사용자 관리 기능"이라는 한 줄 요구사항에는 RBAC 설계, 비밀번호 정책, 계정 잠금 규칙, 감사 로그 등 수십 가지 세부 결정이 숨어 있다. 이것을 명세 없이 개발을 시작하면, 납품된 결과가 발주자의 기대와 다를 수밖에 없다. 해결책은 개발 전에 와이어프레임이나 기능 명세서로 세부 시나리오를 합의하는 것이다.

중간 리뷰 부재. "다 만들면 보여드릴게요" 방식은 큰 낭비를 만든다. 4주 후에 완성된 화면이 기대와 다르면, 4주를 다시 쓴다. 1주 단위로 작동하는 기능을 직접 보는 구조를 만들어야 한다.

테스트 환경 불일치. 개발 환경과 프로덕션 환경의 OS, .NET 버전, SQL Server 버전이 다를 때 "개발에서는 됐는데 서버에서 안 된다"는 문제가 생긴다. Docker 기반 개발 환경을 사용하거나, 프로덕션과 동일한 사양의 스테이징 서버를 미리 준비하는 방식으로 예방한다.

납품 후 이관 실패. 소스코드는 받았는데 어떻게 빌드하고 배포하는지 아무도 모르는 상황이 생긴다. 계약에 "납품 시 README와 배포 가이드 포함, 담당자 교육 1회 이상 포함"을 명시한다.

---

온프레미스 vs. Azure 클라우드 배포 결정 기준

.NET 시스템의 배포 환경 선택은 운영 비용과 보안 요건을 동시에 고려해야 한다.

Azure는 .NET의 1급 클라우드다. App Service, Azure Functions, Azure Container Apps — 이 세 가지가 ASP.NET Core 애플리케이션의 주요 배포 타깃이다. Azure DevOps와의 통합, Application Insights를 통한 모니터링, Managed Identity를 활용한 시크릿 관리까지, Microsoft 스택 안에서 완결되는 운영 경험을 제공한다.

온프레미스는 데이터 국내 보관 의무, 내부 보안 정책, 기존 인프라 활용 요건이 있을 때 선택한다. 제조, 금융, 공공 부문에서 자주 요구된다. 이 경우 IIS(Internet Information Services) 또는 Kestrel 직접 운영 방식이 일반적이며, Windows Server 라이선스와 운영 인력이 추가로 필요하다.

하이브리드 구성도 있다. 핵심 데이터는 온프레미스에 유지하고, 프론트엔드와 API 게이트웨이는 Azure에 올리는 방식이다. 이 아키텍처는 Azure API Management와 VPN Gateway를 활용해 구현하는데, 복잡도가 높아지므로 외주 업체가 이 구성을 실제로 운영해본 경험이 있는지 반드시 확인한다.

외주 계약 시에는 "어디에 배포할 것인가"를 초기 설계 단계에서 확정해야 한다. 개발 완료 후 온프레미스에서 Azure로 바꾸거나, 그 반대로 전환하는 것은 재설계 수준의 작업이 될 수 있다.

---

자주 묻는 질문

.NET 외주와 자바 스프링 외주 중 어느 것을 선택해야 하나?

기존에 .NET 기반 레거시 시스템이 있거나, Azure를 주요 클라우드로 사용 중이거나, 내부 유지보수 인력이 C# 개발자라면 .NET을 유지하는 것이 운영 부담을 낮춘다. 이 세 조건이 없다면 스택 선택보다 팀의 실력과 도메인 경험이 더 중요한 기준이 된다.

.NET 외주 개발 기간은 어느 정도 예상해야 하는가?

규모에 따라 다르지만, 기능 명세가 확정된 기업 내부 포털 기준으로 소규모(핵심 기능 5~10개)는 2~3개월, 중규모(모듈 복수, 외부 연동 포함)는 4~6개월을 일반적인 범위로 볼 수 있다. 이 기간은 설계 단계가 충분히 이루어졌을 때 기준이다. 명세가 불명확하면 기간 예측 자체가 의미 없다.

외주 업체가 중간에 프로젝트를 포기하는 경우를 어떻게 방지하는가?

마일스톤 기반 계약 구조에서 각 마일스톤 완료 후 비용을 집행하면 업체의 이탈 위험이 줄어든다. 또한 소스코드를 처음부터 공유 레포지터리(GitHub, GitLab)에서 관리하고 발주자도 접근 권한을 갖는 방식을 계약에 포함시킨다. 업체가 이탈하더라도 지금까지 작성된 코드는 발주자가 바로 확보할 수 있다.

.NET Framework 4.x에서 .NET 8로 마이그레이션하는 데 외주가 필요한가?

마이그레이션 복잡도는 System.Web 의존성, WCF 서비스 수, 전역 상태 사용 규모에 따라 크게 달라진다. 먼저 .NET Upgrade Assistant로 자동 분석을 실행해 호환 불가 항목 수를 파악한다. 이 분석 결과 없이 견적을 내는 업체는 신뢰하기 어렵다.

외주 개발 후 내부 팀이 유지보수하려면 어떤 조건이 필요한가?

소스코드와 함께 아키텍처 문서, 데이터베이스 스키마 설명, 배포 절차서, 주요 설계 결정 이유(ADR: Architectural Decision Records)를 납품 항목에 포함시켜야 한다. 내부 팀을 대상으로 한 인수인계 교육 세션도 계약에 명시하는 것이 권장된다.

---

.NET 외주 개발에서 실패는 대부분 기술이 아닌 프로세스에서 온다. 요구사항을 문서로 확정하고, 1주 단위로 작동하는 결과물을 검토하며, 계약서에 소유권과 품질 기준을 명문화하는 것 — 이 세 가지가 갖춰지면 업체의 기술력이 제대로 발휘될 환경이 만들어진다. 웹·백엔드 구축 역량은 웹 앱 개발 서비스에서 확인할 수 있고, AI-Native 개발 방식을 채택한 팀을 고려한다면 treesoop.com에서 무료 초기 상담을 통해 프로젝트 규모와 적합한 계약 구조를 먼저 확인해보기를 권한다.

---

*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*

AI 관련 프로젝트가 필요하시면 카카오톡으로 문의하세요.