외주 개발 견적서 읽는 법 — 비개발자 체크리스트 [2026]

외주 개발 견적서란 프로젝트 범위·인력·기간·산출물을 가격으로 환산한 제안이며, 비개발자 발주 담당자에게 가장 어렵게 느껴지는 문서입니다. 같은 한 줄 요구사항이라도 어떤 범위를 어떻게 포함했느냐에 따라 금액이 몇 배씩 벌어지기 때문에, 외주 개발 견적서는 ‘가격표’가 아니라 ‘책임 범위 설명서’로 읽어야 합니다.

외주 개발 견적을 세 곳에서 받으면 흔히 금액이 두세 배씩 차이가 납니다. 문제는 이 차이가 단순히 ‘비싼 업체와 싼 업체’의 차이가 아니라는 점입니다. 포함된 항목, MD 산정 방식, 산출물 소유권, 재하청 여부 같은 구조가 다르기 때문에 같은 숫자라도 의미가 전혀 달라집니다. 이 글에서는 비개발자 발주 담당자가 외주 개발 견적서를 받았을 때 무엇부터 확인해야 하는지, 어떤 견적서를 경계해야 하는지 순서대로 정리합니다.

견적이 3배씩 차이 나는 진짜 이유#

같은 한 줄 요구사항(예: “회원가입과 결제가 되는 웹사이트”)이라도 견적서가 가리키는 범위는 제각각입니다. 디자인이 포함됐는지, 서버 호스팅 비용을 1년치 묶었는지, 오픈 후 유지보수 몇 개월이 들어 있는지, 기획·화면설계서 작성을 누가 하는지에 따라 단가가 달라집니다. 또 품질보증(QA)과 테스트 케이스 작성, 보안 점검, 배포 자동화, 데이터 이관까지 견적에 들어 있는 곳과 빠진 곳이 섞여 있기 때문에 ‘싸 보이는’ 견적이 실제로는 더 비싼 경우가 자주 생깁니다.

외주 개발 견적서를 비교할 때는 그래서 금액부터 보지 말고, 항목 목록부터 나란히 두고 봐야 합니다. 항목이 다르면 가격이 같아도 사실상 다른 제품을 사는 것이고, 항목이 같아야 비로소 단가 비교가 의미를 가집니다.

견적서에 꼭 들어가야 하는 항목#

숫자 너머: 외주 개발 견적서에서 봐야 할 5가지#

항목이 다 들어 있더라도, 그 안에 어떤 ‘조건’이 적혀 있는지가 더 중요합니다. 비개발자 발주 담당자가 외주 개발 견적서를 받았을 때 가장 먼저 형광펜으로 표시해야 할 다섯 가지를 정리했습니다.

1) 범위 정의(스코프 명문화). 견적이 어떤 화면·기능 목록 기준으로 산정됐는지가 본문 또는 별첨에 명시되어야 합니다. 동시에 ‘범위 외 요청이 들어왔을 때 어떻게 처리하는가(변경관리 조항)’가 함께 있어야 합니다. 이게 없으면 작은 추가 요청이 모두 분쟁의 씨앗이 됩니다.

2) MD(맨먼스) 산정 근거. 총 MD만 적힌 견적서는 해석이 불가능합니다. 어떤 역할(기획·디자인·프론트·백엔드·QA)이 며칠씩 투입되어 어떤 산출물을 만드는지가 분해되어 있어야 추후 변경·축소 협상이 가능합니다.

3) 소통 채널·정례 회의. 슬랙·노션·주간 회의 등 운영 합의가 견적서에 명시되어 있으면 프로젝트가 ‘블랙박스’가 되지 않습니다. ‘완료되면 전달드리겠다’만 적힌 견적은 중간 점검이 어려워 후반에 큰 수정이 들어갈 위험이 있습니다.

4) 산출물 소유권·코드 인수인계. 코드 저장소·디자인 원본·서버 계정의 소유권이 발주처로 귀속된다는 조항, 그리고 종료 시 인수인계 범위(문서·계정 양도·코드 패키징)가 명시되어 있어야 합니다. 이게 없으면 다음 단계 확장이나 다른 업체로의 이관 자체가 막힙니다.

5) 재하청 여부. 견적서에 적힌 ‘개발팀’이 실제로 그 회사 인력인지, 다시 외주로 쪼개지는지 확인해야 합니다. 알파카랩스는 기획·디자인·개발을 한 팀이 끝까지 수행하며 재하청을 두지 않습니다. 카카오·네이버·쿠팡 출신 인력이 직접 투입되는 구조이기 때문에 요구사항이 전달 단계에서 흐려지지 않습니다.

핵심 체크리스트#