소프트웨어 외주 견적은 같은 요구를 전달해도 금액과 항목이 크게 달라질 수 있습니다. 업체마다 기술 수준이 달라서만은 아닙니다. 포함한 범위, 재사용 자산, 품질 기준과 운영 책임이 서로 다를 수 있습니다.
가격을 협상하기 전에 견적서가 같은 결과를 약속하는지 확인해야 합니다. 싼 견적에서 빠진 기능을 계약 뒤 추가하면 최종 비용이 더 커질 수 있고, 비싼 견적에 필요하지 않은 운영 범위가 포함돼 있을 수도 있습니다.
이 글은 특정 직군의 단가표를 제시하지 않습니다. 임금과 대가산정 기준은 매년 바뀌며 계약 형태도 다릅니다. 대신 견적 방식을 구분하고, 비교 가능한 문서로 만드는 방법을 정리합니다.
먼저 알아둘 것: 견적 방식은 하나가 아니다
투입공수
직무별 인원과 기간, 단가를 기준으로 계산합니다. 범위가 계속 바뀌거나 발주처와 함께 일하는 상주·운영 업무에 적합할 수 있습니다.
인원과 기간만으로는 결과를 알 수 없습니다. 역할, 투입률, 산출물과 의사결정 권한까지 확인해야 합니다.
T&M
실제 사용한 시간과 비용을 정산합니다. 탐색과 연구, 기존 시스템 분석처럼 결과를 미리 고정하기 어려운 일에 맞습니다. 시간 기록, 승인 단위와 비용 상한이 필요합니다.
고정가
합의한 범위와 완료 조건을 정해진 금액으로 납품합니다. 고객은 총액을 예측할 수 있고, 공급자는 내부 자동화와 경험으로 효율을 높일 수 있습니다.
범위가 불명확하면 변경 요청과 검수에서 분쟁이 생깁니다. 고정가라는 이름보다 포함·제외 범위가 중요합니다.
기능 단위
로그인, 결제, 관리자와 앱 패키징처럼 기능별 가격을 합산합니다. 빠르게 견적을 구성할 수 있지만 같은 이름의 기능도 요구가 다릅니다.
결제에는 PG 한 곳의 일반 카드결제만 포함될 수도 있고, 정기결제·부분취소·현금영수증·정산 대사까지 포함될 수도 있습니다. 기능 이름 옆에 조건을 적어야 비교할 수 있습니다.
구독·유지보수
월 기본 시간, 장애 대응과 운영 업무를 계약합니다. 포함 시간, 긴급 대응, 초과 단가와 기능 개발의 경계를 정해야 합니다.
KOSA 자료는 기준이지 정답 가격표가 아니다
한국인공지능·소프트웨어산업협회는 SW사업 대가산정 자료와 SW기술자 평균임금을 공표합니다. 공공·민간 사업에서 투입공수와 개발비를 계산할 때 참고할 수 있습니다.
그러나 평균임금에 사람 수와 기간을 곱했다고 모든 프로젝트의 적정가가 자동으로 나오지는 않습니다. 2025년 개정 가이드에서도 사업 성격에 따라 기능점수, 투입공수와 운영·유지관리 기준을 구분합니다.
견적에 KOSA라는 이름이 적혀 있다면 다음을 확인합니다.
- 어떤 연도의 어떤 표를 적용했는가
- 직무와 투입 기간을 어떻게 계산했는가
- 제경비, 기술료와 직접경비에 무엇이 들어 있는가
- 투입공수 외에 기능점수나 별도 산정 기준을 사용했는가
- 부가세가 포함됐는가
견적 차이를 만드는 범위
요구사항 정리
회의 기록을 누가 요구사항과 화면 흐름으로 바꾸는지 확인합니다. 고객이 완성된 명세를 제공하는 계약과 개발사가 업무를 분석하는 계약은 가격이 다릅니다.
디자인
와이어프레임, 최종 UI, 반응형, 디자인 시스템과 이미지 제작의 범위가 다릅니다. 페이지 수보다 상태 수를 봐야 합니다. 같은 주문 화면에도 빈 상태, 오류, 로딩, 취소와 권한별 화면이 있습니다.
데이터 이전
기존 회원, 상품, 주문과 파일을 옮기는 일은 별도 범위입니다. 데이터 정제, 누락 처리, 암호화된 비밀번호와 중단 시간까지 확인합니다.
외부 연동
PG, 문자, 지도, ERP와 소셜 로그인은 API 호출 한 번으로 끝나지 않습니다. 계약·심사, 테스트 계정, 실패 재시도, 웹훅, 대사와 정책 변경 대응이 필요합니다.
품질과 테스트
지원 브라우저와 기기, 성능, 접근성, 보안, 자동 테스트와 사용자 검수 지원을 확인합니다. 테스트 포함보다 어떤 환경과 흐름을 확인하는지가 중요합니다.
배포와 운영
서버 계정, 도메인, 인증서, 앱스토어 계정, 모니터링, 백업과 장애 대응이 포함됐는지 확인합니다. 개발 서버에서 동작하는 것과 운영 책임을 넘기는 것은 다른 산출물입니다.
비교 가능한 견적 요청서 만들기
견적 문의 전에 다음 문서를 준비하면 업체별 가정 차이를 줄일 수 있습니다.
- 사업과 사용자의 문제
- 사용자 역할과 권한
- 사용자가 완료해야 하는 핵심 흐름
- 첫 버전에 포함할 것과 제외할 것
- 기존 데이터와 연동 시스템
- 지원 기기·브라우저·운영체제
- 납기와 반드시 지켜야 할 외부 일정
- 납품 뒤 운영 방식
- 예산 범위와 우선순위
화면 목록만 전달하지 말고 업무 흐름과 예외를 적습니다. 업체가 다른 방법을 제안할 수 있도록 해결하려는 문제도 함께 설명합니다.
견적서를 같은 표로 다시 정리한다
업체마다 항목 이름이 다르므로 다음 기준으로 재정리합니다.
- 분석·기획
- UI·디자인
- 프런트엔드
- 백엔드와 데이터
- 외부 연동
- 데이터 이전
- 테스트와 보안
- 배포와 인수인계
- 하자보수
- 운영·유지보수
- 라이선스·클라우드·문자 같은 직접비
- 포함하지 않은 항목
금액이 없는 항목은 무료가 아니라 빠졌을 가능성이 있습니다. 별도 협의가 많은 견적은 어떤 조건에서 얼마가 달라지는지 질문합니다.
가격을 낮추려면 범위를 줄인다
근거 없이 총액만 깎으면 업체는 투입을 줄이거나 보이지 않는 항목을 제외할 수 있습니다. 가격 협상은 다음 순서가 안전합니다.
첫 버전과 이후 버전을 나눈다
핵심 거래를 완료하는 기능만 첫 버전에 넣습니다. 관리자 편의 기능, 고급 통계와 자동화는 실제 사용 뒤 우선순위를 다시 정할 수 있습니다.
불확실한 영역을 탐색 계약으로 분리한다
기존 시스템 분석이나 복잡한 기술 검증을 짧은 유료 단계로 먼저 진행합니다. 결과물은 요구사항, 위험 목록, 검증 코드와 구축 견적입니다.
표준 서비스를 활용한다
일반 쇼핑몰, 인증, 결제와 알림은 검증된 서비스를 쓸 수 있습니다. 다만 월 비용, 데이터 이동, 정책 의존과 맞춤 범위를 함께 계산합니다.
고객이 제공할 자료와 결정을 정한다
콘텐츠, 정책, 테스트 계정과 피드백이 늦으면 일정과 비용이 늘어납니다. 고객이 준비할 자료와 의사결정 기한을 계약에 적습니다.
외주 구조와 실제 작업자를 확인한다
계약 회사가 모든 작업을 직접 수행하는지, 일부 전문 영역을 협력사에 맡기는지 확인합니다. 협력 자체가 문제는 아닙니다. 고객에게 공개되지 않은 재하청과 책임 공백이 문제입니다.
다음 질문을 할 수 있습니다.
- 분석·설계와 구현을 실제로 누가 맡는가
- 프로젝트 책임자와 직접 대화할 수 있는가
- 외부 인력을 사용하면 고객에게 알리는가
- 코드리뷰와 품질 책임은 어느 회사에 있는가
- 문제가 생기면 누가 수정하고 비용을 부담하는가
- 계약 종료 뒤 저장소와 계정에 접근할 수 있는가
회사 소개서의 인원수보다 내 프로젝트에 투입되는 역할과 책임을 봅니다.
소유권과 인수인계
납품 범위에는 실행 파일이나 화면뿐 아니라 운영에 필요한 자산이 포함돼야 합니다.
- 소스코드 저장소와 커밋 이력
- 디자인 원본과 이미지 라이선스
- 도메인·클라우드·PG·앱스토어 계정
- 환경변수와 비밀정보의 전달 방식
- 데이터베이스 구조와 배포 문서
- 관리자와 운영자 사용법
- 오픈소스·상용 라이선스 목록
- 백업과 복구 절차
고객 계정으로 만들 수 있는 자산은 처음부터 고객 명의로 개설하는 편이 안전합니다.
변경 요청을 계약 전에 정한다
프로젝트 중 요구사항은 바뀔 수 있습니다. 변경을 금지하기보다 절차를 정합니다.
- 변경 내용을 문서로 요청합니다.
- 일정·비용·기존 기능에 미치는 영향을 계산합니다.
- 기존 범위와 교체할지 추가할지 결정합니다.
- 승인 뒤 일정과 견적을 갱신합니다.
- 검수 기준에도 변경을 반영합니다.
회의에서 나온 요청이 자동으로 무료 범위가 되거나, 작은 문구 수정까지 모두 추가 견적이 되는 상황을 막을 수 있습니다.
위험 신호
다음 상황은 계약 전에 더 확인해야 합니다.
- 요구사항을 거의 묻지 않고 총액과 납기를 확정한다
- 중요한 기능이 모두
가능이라고만 적혀 있다 - 데모와 포트폴리오에서 실제 담당 범위를 설명하지 못한다
- 소스코드와 운영 계정 전달 조건이 없다
- 테스트와 검수 기준이 없다
- 재하청과 작업자 구성을 공개하지 않는다
- 계약금 이후 단계별 산출물과 지급 조건이 없다
- 하자보수와 기능 변경을 구분하지 않는다
낮은 가격 자체가 위험 신호는 아닙니다. 같은 결과와 책임을 약속하는지 확인하는 것이 먼저입니다.
견적 협상의 목표는 가장 싼 숫자가 아니다
좋은 견적은 고객이 받을 결과와 공급자가 맡을 위험을 보여줍니다. 범위를 줄이면 가격이 내려가고, 품질과 운영 책임을 넓히면 가격이 올라가는 이유를 설명할 수 있어야 합니다.
여러 견적서의 포함 범위와 위험을 비교하거나 프로젝트 요청서를 정리해야 한다면 프로젝트 문의에 현재 자료를 보내주세요. 기능, 품질, 운영과 직접비를 같은 기준으로 나눠 답하겠습니다.