개발 외주 견적서, 총액보다 먼저 볼 것들
총액만 봐서는 비싼 곳이 바가지인지, 싼 곳이 뭘 빼먹었는지 알 수 없습니다. 무엇을 만들어 주는지, 돈은 언제 내는지, 다 만든 뒤 누가 고쳐 주는지까지 계약 전에 볼 것들입니다.
견적서 세 장을 받아 나란히 펼쳐 놓으면 대부분 맨 아래 총액부터 봅니다. 그런데 금액이 두 배쯤 차이 나면 그때부터 막막해지죠. 비싼 곳이 바가지인지, 싼 곳이 뭔가를 빼먹은 건지 총액만으로는 알 수가 없습니다.
집 인테리어 견적을 떠올려 보세요. 같은 '거실 공사'라도 도배만 하는 곳과 조명·가구까지 해 주는 곳은 값이 다를 수밖에 없죠. 개발 견적서도 똑같습니다. 가격표가 아니라 '무엇을 만들어 주고, 무엇은 안 만드는지' 적은 약속입니다. 그러니 읽는 순서부터 바꿔야 합니다. 총액은 맨 마지막에 보세요.
먼저 세 줄로
- 총액보다 '무엇이 들어 있는지'를 먼저 봅니다.
- '안 해 주는 일'이 적혀 있는지 확인합니다.
- 돈은 결과물을 눈으로 확인할 때마다 나눠서 냅니다.
기능 목록부터 한 줄씩 맞춰 봅니다
'회원 기능'이라고 똑같이 적혀 있어도 속은 다를 수 있습니다. 한 업체는 비밀번호 찾기와 직원마다 볼 수 있는 화면 나누기까지 넣었고, 다른 업체는 가입과 로그인만 넣었을 수도 있죠. 이름이 같다고 같은 견적은 아닙니다.
제일 조심할 표현은 '관리자 기능 일체' 같은 뭉뚱그린 말입니다. 나중에 "그건 일체에 안 들어갑니다"라는 말이 나오기 딱 좋거든요. 관리자 화면, 결제, 알림은 자주 빠지는 항목입니다. 외부 서비스 연동(카카오 로그인이나 카드 결제처럼 다른 회사 서비스를 붙이는 일)도 그렇고요. 이런 항목은 포함인지 별도인지 꼭 물어보세요.
비교할 때는 표를 하나 만들면 편합니다. 행에는 기능을, 열에는 업체를 놓고 칸마다 포함·제외·모름 중 하나를 적습니다. '모름'으로 남은 칸은 메일로 물어서 답을 받아 두세요. 전화로 들은 답은 석 달만 지나도 서로 기억이 다릅니다.
| 기능 | A 업체 | B 업체 | C 업체 |
|---|---|---|---|
| 가입·로그인 | 포함 | 포함 | 포함 |
| 비밀번호 찾기 | 포함 | 제외 | 모름 |
| 관리자 화면 | 포함 | 모름 | 포함 |
| 결제 연동 | 제외 | 포함 | 모름 |
| 기존 데이터 옮기기 | 모름 | 제외 | 제외 |
여러 곳에 견적을 받는다면 처음부터 같은 자료를 같은 순서로 보내는 게 좋습니다. 업체마다 들은 이야기가 다르면, 견적이 다른 이유가 업체 차이인지 설명 차이인지 가려낼 수 없으니까요.
안 해 주는 일이 적혀 있는지 봅니다
잘 쓴 견적서에는 '하지 않는 일'도 적혀 있습니다. 제외 항목이 한 줄도 없다면 꼼꼼해서가 아니라 아직 무엇을 만들지 서로 맞춰 보지 않았다는 뜻일 가능성이 큽니다. 계약 전에 아래 다섯 가지는 짚고 넘어가세요.
- 디자인을 새로 해 주는지, 우리가 준 시안대로 만드는지
- 문구, 사진, 기존 데이터 옮기기는 누가 하는지
- 수정 요청은 몇 번까지, 언제까지 받아 주는지
- 서버·도메인·외부 서비스 요금은 누가 내고, 계정은 누구 이름으로 만드는지
- 테스트 서버(미리 시험해 보는 곳)와 실제 손님이 쓰는 서버 설정까지 해 주는지
견적 밑에는 업체가 깔아 둔 가정도 있습니다. '이 정도일 거라고 치고' 계산했다는 뜻이에요. 사용자가 몇 명쯤일지, 연동할 시스템이 몇 개인지, 우리 쪽 확인이 며칠 걸릴지 같은 것들이죠. 이 가정이 틀리면 금액과 일정도 함께 흔들립니다. 어떤 가정으로 계산했는지 문서에 적어 달라고 하세요. 무리한 요청이 아닙니다.
돈을 언제, 무엇과 바꾸는지 봅니다
총액 한 줄짜리 견적서보다 단계별로 나눈 견적서가 관리하기 훨씬 쉽습니다. 단계마다 무엇이 나오고 우리가 무엇을 확인해야 하는지 보이기 때문입니다.
돈은 날짜에 맞춰 내지 말고, 눈으로 확인한 결과물에 맞춰 나눠 내세요. 일을 시작할 때, 중간 결과를 볼 때, 다 만든 걸 확인하고 넘겨받을 때처럼요. 다 만든 걸 약속대로 됐는지 확인하는 일을 '검수'라고 부릅니다. 그리고 중간에 직접 눌러 볼 수 있는 화면이 적어도 한 번은 나와야 합니다. 공개 직전에야 화면을 처음 보면, 방향이 틀렸다는 걸 알아도 되돌릴 시간이 없습니다.
- 시작만들 것과 일정을 문서로 정하기
- 중간 확인화면을 직접 눌러 보기
- 다 만든 것 확인약속대로 되는지 직접 해 보기
- 넘겨받기원본 파일·계정·설명서 받기
일정표에 우리 쪽 검토 기간이 들어 있는지도 보세요. 자료를 늦게 넘기거나 피드백이 밀리면 공개 날짜도 그만큼 밀립니다. 이건 업체 탓만 할 수 없는 부분이죠. 만들 내용이 중간에 바뀔 수도 있습니다. 그때 금액과 일정을 어떻게 다시 정하는지 미리 물어 두세요. 나중에 얼굴 붉힐 일이 줄어듭니다.
'다 됐다'의 기준을 글로 남깁니다
검수 때 다툼이 생기는 이유는 대개 하나입니다. 무엇을 완료로 볼지 정한 적이 없어서입니다. "잘 돌아가면 끝"으로는 부족합니다. "이 화면에서 이 순서로 누르면 이 결과가 나온다"처럼 누가 해 봐도 같은 결론이 나오는 문장으로 적어야 합니다.
넘겨받을 것도 정해 두세요. 소스 코드(프로그램의 설계도 같은 원본 파일), 각종 계정, 배포 방법(고친 내용을 실제 사이트에 올리는 방법), 사용 설명서를 어떤 형태로 받는지요. 코드 소유권이 누구에게 있는지, 안에 쓰인 오픈소스(누구나 가져다 쓰도록 공개된 코드)나 외부 서비스에 어떤 조건이 붙어 있는지도 같이 확인해야 합니다. 이게 없으면 나중에 다른 업체로 옮길 때 처음부터 다시 만들어야 할 수도 있습니다.
공개한 다음 날부터의 일을 따로 묻습니다
서비스는 공개하는 날 끝나는 게 아니라 그날부터 시작됩니다. 견적서에 '유지보수(공개 뒤에 고쳐 주고 관리해 주는 일) 포함'이라고 적혀 있으면 반갑지만, 그 안에 뭐가 들었는지는 따로 봐야 합니다. 오류 수정과 기능 추가는 다른 일이고, 서버 관리와 보안 업데이트는 또 다른 일입니다.
- 무상으로 고쳐 주는 기간이 있는지, 어떤 문제까지 해당하는지
- 사이트가 멈추거나 고장 나면 어디로 연락하고, 몇 시까지 대응해 주는지
- 기능을 더할 때는 어떤 단위로 견적을 받는지
- 다른 업체나 내부 직원에게 넘길 수 있게 문서와 코드를 정리해 주는지
계약 전에 업체에 보낼 질문
- '모름'으로 남은 기능은 포함인가요?
- 제외 항목과 계산에 쓴 가정을 문서로 받을 수 있을까요?
- 중간에 직접 써 볼 수 있는 시점은 언제인가요?
- 완료 기준과 무상 수정 기간은 어떻게 되나요?
견적을 받기 전에 준비할 것
기능 목록을 완벽하게 만들어 갈 필요는 없습니다. 지금 무엇이 불편한지, 누가 쓸 건지, 연동해야 할 시스템이 있는지, 언제쯤 열고 싶은지, 예산은 대략 어느 정도인지. 이 정도만 있어도 업체는 무엇을 만들어야 할지 훨씬 정확하게 제안할 수 있습니다.
혜록정보기술이 하는 일은 서비스 페이지에 정리해 두었습니다. 아직 생각이 정리되지 않았어도 괜찮습니다. 지금 상황을 그대로 프로젝트 문의로 보내 주세요.