외주 개발 견적서에서 꼭 봐야 할 항목

외주 개발 견적서에서 꼭 봐야 할 항목

외주 개발 견적서를 받으면 가장 먼저 눈에 들어오는 것은 총액입니다. 하지만 개발 견적서는 단순히 “얼마인지”만 보는 문서가 아닙니다. 정말 중요한 것은 그 금액에 무엇이 포함되어 있고, 무엇이 제외되어 있는지입니다.

같은 3,000만 원짜리 견적서라도 한 업체는 기획, 디자인, 개발, 관리자 페이지, 테스트, 하자보수까지 포함했을 수 있고, 다른 업체는 개발 구현만 포함했을 수 있습니다. 겉으로는 같은 금액처럼 보여도 실제 범위가 다르면 전혀 다른 견적입니다.

그래서 외주 개발 견적서를 볼 때는 총액보다 먼저 확인해야 할 항목들이 있습니다. 이번 글에서는 개발 견적서를 받을 때 반드시 봐야 할 핵심 항목을 실무 기준으로 정리해보겠습니다.

1. 기능 범위가 구체적으로 적혀 있는가

가장 먼저 확인해야 할 것은 기능 범위입니다. 견적서에 “앱 개발”, “웹사이트 개발”, “관리자 개발”처럼 큰 항목만 적혀 있다면 실제로 무엇이 포함되어 있는지 알기 어렵습니다.

예를 들어 “회원 기능”이라고 적혀 있어도 범위는 다양할 수 있습니다.

• 이메일 회원가입만 포함되는지

• 휴대폰 인증이 포함되는지

• 소셜 로그인이 포함되는지

• 비밀번호 찾기가 포함되는지

• 회원 탈퇴와 개인정보 삭제가 포함되는지

• 관리자에서 회원을 조회하고 관리할 수 있는지

이처럼 하나의 기능명 안에도 여러 세부 기능이 숨어 있습니다. 견적서가 기능을 너무 넓은 단어로만 표현하고 있다면, 나중에 “그건 포함이 아니었다”는 이야기가 나올 수 있습니다.

좋은 견적서는 기능명을 나열하는 데서 끝나지 않고, 각 기능이 어떤 범위까지 포함되는지 어느 정도 구체적으로 설명합니다.

2. 제외 범위가 명확한가

견적서에서 포함 항목만큼 중요한 것이 제외 항목입니다. 외주 개발에서 분쟁이 생기는 이유 중 하나는 클라이언트는 당연히 포함된다고 생각했지만, 개발사는 제외 범위로 생각한 항목이 있기 때문입니다.

자주 빠지는 제외 항목은 아래와 같습니다.

• 스토어 등록 대행

• 서버 비용

• 도메인 구입 비용

• 문자, 알림톡, 이메일 발송 비용

• PG 가입 및 심사 대응

• 콘텐츠 입력 작업

• 데이터 이전 작업

• 운영 매뉴얼 작성

• 런칭 후 기능 개선

견적서에 제외 범위가 명확하게 적혀 있으면 오히려 좋은 견적서입니다. 무엇을 하지 않는지 분명히 적혀 있어야 나중에 추가 비용이 발생할 수 있는 부분을 미리 알 수 있습니다.

반대로 제외 범위가 전혀 없고 “전체 개발”처럼만 표현되어 있다면, 실제로는 해석 차이가 생길 가능성이 큽니다.

3. 기획과 화면 설계가 포함되어 있는가

많은 견적서에서 놓치기 쉬운 항목이 기획과 화면 설계입니다. 개발을 시작하려면 기능을 정리하고, 화면 흐름을 만들고, 정책을 정해야 합니다. 이 작업이 이미 준비되어 있다면 개발사는 구현 중심으로 일할 수 있지만, 준비되어 있지 않다면 기획 작업이 필요합니다.

견적서에서 아래 항목이 포함되어 있는지 확인해보는 것이 좋습니다.

• 요구사항 정리

• 기능 정의

• 화면 설계 또는 와이어프레임

• 사용자 흐름 정리

• 관리자 기능 정의

• 운영 정책 정리

기획이 포함되지 않은 견적은 처음에는 저렴해 보일 수 있습니다. 하지만 개발 중간에 기능과 정책을 계속 정해야 한다면 일정이 지연되고, 추가 비용이 발생할 수 있습니다.

견적서에 기획이 포함되어 있다면 어느 수준까지 포함되는지 확인해야 합니다. 단순 회의만 포함인지, 실제 문서 작성까지 포함인지, 화면 설계까지 포함인지에 따라 작업 범위가 달라집니다.

4. 디자인 범위와 수정 횟수가 적혀 있는가

디자인은 견적 차이를 크게 만드는 항목입니다. 하지만 견적서에는 “디자인 포함”이라고만 적혀 있는 경우가 많습니다. 이 문장만으로는 어떤 수준의 디자인이 포함되는지 알 수 없습니다.

디자인 항목에서는 아래 내용을 확인해야 합니다.

• UI 디자인이 포함되는지

• UX 설계가 포함되는지

• 모바일과 PC 반응형 디자인이 포함되는지

• 디자인 시안은 몇 개 제공되는지

• 디자인 수정은 몇 회까지 가능한지

• 디자인 원본 파일을 제공하는지

특히 반응형 웹서비스라면 PC, 태블릿, 모바일 화면 대응 여부가 중요합니다. 디자인은 하나처럼 보여도 기기별 화면을 고려하면 작업량이 크게 늘어날 수 있습니다.

디자인 수정 횟수도 반드시 확인해야 합니다. 수정 횟수가 명확하지 않으면 클라이언트는 계속 수정할 수 있다고 생각하고, 개발사는 일정 범위를 넘었다고 판단할 수 있습니다.

5. 관리자 페이지가 포함되어 있는가

외주 개발 견적서에서 반드시 확인해야 할 항목 중 하나가 관리자 페이지입니다. 사용자에게 보이는 화면만 개발하면 서비스가 완성된다고 생각하기 쉽지만, 실제 운영에는 관리자 기능이 필요한 경우가 많습니다.

예를 들어 서비스 성격에 따라 아래와 같은 관리자 기능이 필요할 수 있습니다.

• 회원 관리

• 게시글 또는 콘텐츠 관리

• 상품 관리

• 주문 및 결제 관리

• 예약 관리

• 문의 관리

• 알림 발송 관리

• 통계 확인

• 권한 관리

관리자 페이지가 포함되어 있는지뿐 아니라, 관리자에서 무엇을 직접 할 수 있는지도 확인해야 합니다. 단순 조회만 가능한 관리자와 데이터 수정, 상태 변경, 권한 관리까지 가능한 관리자는 개발 범위가 다릅니다.

견적서에 “관리자 페이지 포함”이라고만 적혀 있다면, 어떤 메뉴와 기능이 포함되는지 별도로 확인하는 것이 좋습니다.

6. 일정과 단계별 산출물이 적혀 있는가

개발 견적서에는 금액뿐 아니라 일정도 함께 적혀 있어야 합니다. 하지만 단순히 “개발 기간 3개월”이라고만 되어 있다면 충분하지 않습니다.

실제 프로젝트에서는 단계별 일정이 중요합니다.

• 요구사항 정리 기간

• 기획 및 화면 설계 기간

• 디자인 기간

• 개발 기간

• 내부 테스트 기간

• 클라이언트 검수 기간

• 수정 반영 기간

• 배포 및 런칭 기간

특히 클라이언트가 피드백을 줘야 하는 구간과 개발사가 작업하는 구간이 구분되어 있어야 합니다. 모든 일정이 개발사 작업 기간처럼 보이면, 피드백 지연이나 검수 지연이 생겼을 때 책임 범위가 불명확해질 수 있습니다.

좋은 견적서는 전체 기간뿐 아니라 단계별 산출물과 확인 시점을 함께 제시합니다.

7. 검수 기준이 포함되어 있는가

외주 개발에서 검수 기준은 매우 중요합니다. 개발이 완료되었는지 판단하려면 무엇을 기준으로 확인할지 정해야 합니다.

검수 기준이 없으면 클라이언트는 “내가 기대한 결과와 다르다”고 느끼고, 개발사는 “요구사항대로 개발했다”고 생각할 수 있습니다. 이 차이가 분쟁으로 이어지기도 합니다.

견적서 또는 계약 전 협의에서 아래 내용을 확인하는 것이 좋습니다.

• 검수는 언제 진행하는가?

• 검수 기간은 며칠인가?

• 버그와 추가 요청은 어떻게 구분하는가?

• 검수 중 발견된 오류는 어떻게 처리하는가?

• 검수 완료 기준은 무엇인가?

• 검수 지연 시 일정은 어떻게 조정되는가?

검수 기준이 명확하면 개발사와 클라이언트 모두 같은 기준으로 완료 여부를 판단할 수 있습니다.

8. 유지보수와 하자보수 조건이 적혀 있는가

개발이 끝난 뒤에도 서비스에는 문제가 생길 수 있습니다. 그래서 견적서에서 유지보수와 하자보수 조건을 반드시 확인해야 합니다.

확인해야 할 항목은 아래와 같습니다.

• 하자보수 기간

• 무상 수정 범위

• 버그와 추가 개발의 구분

• 유지보수 비용

• 응답 시간

• 긴급 장애 대응 여부

• 서버 관리 포함 여부

• 보안 업데이트 포함 여부

하자보수는 개발사가 만든 기능의 오류를 수정하는 개념이고, 유지보수는 서비스 운영 중 필요한 대응과 개선을 포함할 수 있습니다. 두 개념이 섞여 있으면 나중에 비용이나 책임 범위에 대한 오해가 생길 수 있습니다.

견적이 저렴해 보이더라도 런칭 후 대응이 전혀 포함되어 있지 않다면, 실제 운영 비용은 더 커질 수 있습니다.

9. 추가 비용 조건이 명확한가

외주 개발 프로젝트에서 추가 비용은 흔히 발생할 수 있습니다. 중요한 것은 추가 비용이 생기는 것 자체가 아니라, 어떤 경우에 발생하는지 기준이 명확한가입니다.

추가 비용이 발생할 수 있는 대표적인 경우는 아래와 같습니다.

• 처음 범위에 없던 기능 추가

• 확정된 디자인의 큰 변경

• 외부 연동 추가

• 관리자 기능 추가

• 데이터 이전 작업 추가

• 검수 완료 후 새로운 요구사항 발생

• 스토어 심사나 외부 기관 요청으로 인한 변경

견적서에 추가 비용 조건이 없으면, 나중에 비용 논의가 감정적인 문제가 되기 쉽습니다. 반대로 추가 비용 기준이 명확하면 변경 요청이 생겼을 때 일정과 비용을 다시 협의하기가 훨씬 쉽습니다.

견적서 비교는 총액 비교가 아니라 범위 비교입니다

외주 개발 견적서를 볼 때 가장 중요한 기준은 총액이 아닙니다. 정말 중요한 것은 그 금액에 포함된 범위입니다.

두 업체의 견적이 아래와 같다고 가정해보겠습니다.

• A업체: 2,000만 원, 사용자 화면 개발 중심

• B업체: 3,500만 원, 기획, 디자인, 관리자, QA, 하자보수 포함

이 경우 단순히 A업체가 싸고 B업체가 비싸다고 판단하면 안 됩니다. 두 견적은 포함 범위가 다르기 때문에 같은 기준으로 비교할 수 없습니다.

견적서를 비교할 때는 아래 항목을 표로 정리해보는 것이 좋습니다.

• 기능 범위

• 제외 범위

• 기획 포함 여부

• 디자인 범위

• 관리자 페이지 범위

• 일정과 단계별 산출물

• 검수 기준

• 유지보수 조건

• 추가 비용 조건

이렇게 비교해야 어떤 견적이 실제로 합리적인지 판단할 수 있습니다.

견적서보다 중요한 것은 포함 범위를 기록으로 남기는 것입니다

견적서는 프로젝트 시작 전 중요한 기준이 됩니다. 하지만 견적서만으로 모든 것을 해결할 수는 없습니다. 프로젝트가 진행되면서 요구사항이 바뀌고, 회의에서 결정이 추가되고, 검수 과정에서 수정 요청이 생길 수 있기 때문입니다.

그래서 중요한 것은 견적서에 적힌 내용을 기준으로 삼고, 이후 변경되는 내용도 계속 기록으로 남기는 것입니다. 무엇이 포함되어 있었는지, 무엇이 제외되어 있었는지, 어떤 요청이 추가되었는지, 어떤 내용이 합의되었는지를 남겨야 프로젝트가 흔들리지 않습니다.

Pronika는 외주 개발 프로젝트에서 요구사항, 견적 범위, 회의록, 변경 요청, 검수 내역을 한곳에 모아 관리할 수 있도록 돕습니다. 견적서에 적힌 범위와 실제 진행 중 변경되는 내용을 같은 흐름 안에서 관리하면, 클라이언트와 개발사가 같은 기준으로 프로젝트를 이어갈 수 있습니다.