IT·개발 용역 견적서 쓰는 법

견적서 마스터·8분·2026.04.13

만들기 전에 값을 정해야 하는 거래의 어려움

물건을 보고 값을 부르는 것이 아니라, 설명을 듣고 값을 부릅니다.

개발 용역의 견적은 다른 거래와 출발점이 다릅니다. 자재를 사서 조립하는 일이라면 무엇을 얼마나 쓸지 세어 볼 수 있지만, 소프트웨어는 아직 존재하지 않는 것을 말로 설명해 놓고 그 설명에 값을 붙이는 일입니다.

그래서 같은 요청을 받고도 견적이 크게 갈립니다. 설명을 들은 사람마다 머릿속에 그리는 결과물이 다르기 때문입니다. 한쪽은 화면 몇 개를 떠올리고 다른 쪽은 그 뒤에 붙는 관리자 기능과 데이터 이관까지 떠올립니다.

받는 쪽에서는 이것이 값의 차이로만 보입니다. 그러나 실제로 갈린 것은 값이 아니라 범위입니다. 싼 견적이 싼 것이 아니라 덜 만드는 견적인 경우가 흔한데, 견적서에 범위가 적혀 있지 않으면 그 사실이 계약 뒤에야 드러납니다.

그러니 개발 견적서를 쓰는 쪽이든 받는 쪽이든 요령은 같습니다. 이 문서를 금액을 알리는 종이가 아니라 범위를 적어 두는 문서로 다루는 것입니다. 값은 범위가 정해지면 따라옵니다.

개발비와 유지관리비는 세는 방식부터 다르다

만드는 일은 결과의 크기로, 돌보는 일은 들이는 시간으로 셉니다.

소프트웨어 대가를 산정하는 방식에는 이미 정리된 틀이 있습니다. 한국소프트웨어산업협회가 공표하는 SW사업 대가산정 가이드가 그것인데, 여기서는 개발비와 운영·유지관리비를 서로 다른 방식으로 산정합니다.

개발비는 기능점수 방식으로 봅니다. 만들어 낼 기능의 크기를 세어 그것을 기준으로 값을 산정하는 방식입니다. 몇 사람이 며칠을 붙었는지가 아니라 결과물이 얼마나 큰지를 기준으로 삼는다는 점이 특징입니다.

운영과 유지관리는 투입공수 방식으로 봅니다. 이쪽은 결과물의 크기로 셀 수가 없습니다. 장애에 대응하고 문의를 받고 잔손질을 하는 일은 새로 만들어지는 결과물이 없거나 아주 작기 때문입니다. 그래서 얼마나 붙어 있느냐로 셉니다.

이 구분을 알아 두면 견적서를 쓸 때 한 가지가 분명해집니다. 만드는 값과 그 뒤로 돌보는 값은 성격이 다르므로 한 줄에 섞으면 안 된다는 것입니다. 섞어 놓으면 개발이 끝난 뒤에 무엇이 남은 것인지, 얼마를 더 받아야 하는지가 흐려집니다.

표에서 느낌표가 붙은 네 줄은 견적서에 항목으로 올라오지 않는 일이 잦은 자리입니다. 그런데 프로젝트가 끝날 무렵 가장 자주 다투게 되는 자리이기도 합니다.

특히 마지막 줄을 비워 두지 마십시오. 납품 뒤에 들어오는 요청이 하자 대응인지 새 작업인지가 정해져 있지 않으면, 무상으로 해 주기를 기대하는 쪽과 청구하려는 쪽이 계속 부딪힙니다.

그 산정 기준은 누구에게 걸리는가

공공 발주의 예산과 대가를 정하기 위한 기준입니다.

앞 절의 가이드를 소개하면 곧바로 나오는 질문이 있습니다. 그렇다면 민간 외주도 그 방식으로 계산해야 하느냐는 것입니다. 답은 아니라는 쪽입니다.

그 가이드는 국가기관 등이 소프트웨어 사업의 예산을 세우고 발주와 계약을 할 때 적정한 대가를 산정하기 위해 만들어진 기준입니다. 민간의 회사가 다른 회사에 개발을 맡기는 계약에 그 방식을 강제하는 근거는 확인된 것이 없습니다.

그러니 민간 외주에서 이 가이드를 꺼낼 때는 위치를 분명히 해야 합니다. 우리 계약이 이 기준을 따라야 한다는 뜻이 아니라, 값을 무엇으로 세는지 서로 말을 맞추기 위한 참고라는 뜻으로 써야 합니다. 참고로 쓰는 데는 아무 문제가 없습니다.

이 글에서 기능점수당 얼마라거나 한 사람이 한 달에 얼마라는 값을 적지 않는 것도 같은 이유입니다. 그런 값은 해마다 개정되고 사업의 성격에 따라 달리 적용되므로, 여기에 적어 두면 읽는 시점에는 이미 맞지 않는 숫자가 됩니다.

공공 발주에 참여하는 경우라면 이야기가 달라집니다. 그때는 발주 공고와 제안요청서가 요구하는 방식을 따르게 되므로, 이 글이 아니라 그 문서를 기준으로 삼으십시오.

다만 그 경우에도 견적서에 무엇을 적어야 하는지를 정한 조문이 따로 있는 것은 아닙니다. 조달 절차가 정하는 것은 발주기관 쪽의 절차이지 문서의 서식이 아닙니다.

범위를 적는 순서 — 견적서를 내는 쪽의 작업

무엇을 만드는지보다 무엇을 만들지 않는지가 더 어렵습니다.

아래 순서는 개발 용역의 견적서를 작성할 때 쓰기 좋은 흐름입니다. 값을 계산하는 일은 마지막에 있습니다. 앞의 다섯 단계가 끝나면 값은 비교적 쉽게 나오고, 앞을 건너뛰면 값은 나오지만 그 값이 무엇에 대한 값인지가 남지 않습니다.

특히 둘째 단계를 부담스러워하는 경우가 많습니다. 안 하는 것을 적으면 인색해 보인다고 여기기 때문인데, 실제로는 그 줄이 양쪽을 모두 보호합니다.

1. 만들 것을 기능 단위로 늘어놓는다화면이나 모듈처럼 셀 수 있는 단위로 적습니다. 문장으로 뭉뚱그리면 나중에 세어 볼 수가 없습니다.
2. 이번 범위에 넣지 않는 것을 함께 적는다흔히 함께 기대되는 기능 가운데 이번에 하지 않는 것을 적어 둡니다. 이 줄이 추가 요청을 다투지 않게 해 줍니다.
3. 발주자가 제공해야 할 것을 적는다자료와 계정, 검토와 승인처럼 상대가 해 주어야 진행되는 일이 있습니다. 이것이 늦어지면 일정이 밀린다는 점도 함께 적습니다.
4. 일정을 단계로 나누고 각 단계의 산출물을 적는다무엇이 나오면 그 단계가 끝난 것인지를 적어 두어야 진행률을 두고 다투지 않습니다.
5. 유지관리와 하자 대응을 개발과 분리해 적는다기간과 대응 범위를 적고, 그 뒤의 요청은 별도 산정이라는 점을 한 줄로 남깁니다.
6. 변경이 생겼을 때의 처리 방식을 적는다요청이 오면 범위와 금액을 다시 정해 문서로 확인한 뒤 진행한다는 절차를 미리 적어 둡니다.

여섯째 단계가 실제로 가장 값어치가 큽니다. 개발 프로젝트에서 변경은 예외가 아니라 기본값에 가깝기 때문입니다. 변경이 생길 것을 전제로 처리 방식을 적어 두면, 변경이 생겼을 때 그것이 사고가 아니라 절차가 됩니다.

이 여섯 줄은 견적서에 다 들어가지 않을 수도 있습니다. 그렇다면 견적서에는 요약해 적고 별지나 제안서에 자세히 적은 뒤, 견적서에서 그 문서를 가리키게 하면 됩니다.

범위가 흐릿한 견적서가 만들어 내는 것

추가인지 아닌지를 가릴 기준이 사라집니다.

프로젝트가 중반을 넘어가면 요청이 들어옵니다. 이것도 되면 좋겠다는 말은 악의 없이 나오고, 받는 쪽도 대개 처음에는 흔쾌히 받습니다. 그러다 어느 순간 이것까지는 어렵다는 말이 나오면서 관계가 틀어집니다.

이때 서로가 기대는 것이 처음에 무엇을 하기로 했느냐입니다. 견적서와 계약 문서에 범위가 적혀 있으면 지금 들어온 요청이 그 안인지 밖인지가 보입니다. 밖이라면 얼마에 언제까지 할지를 정하면 되고, 그것은 다툼이 아니라 협의입니다.

적혀 있지 않으면 이 대화가 성립하지 않습니다. 한쪽은 당연히 포함이라고 생각하고 다른 쪽은 처음부터 없던 이야기라고 생각하는데, 종이 위에는 어느 쪽 근거도 없습니다. 추가로 든 비용을 청구하려 해도, 추가 작업과 그 대금에 관한 합의가 있어야 한다는 것이 법원이 보여 온 방향입니다.

그래서 개발 견적서를 자세히 쓰는 일은 상대를 의심하는 일이 아닙니다. 서로 좋은 관계로 끝내기 위한 준비에 가깝습니다. 관계가 나빠지는 것은 대개 사람이 나빠서가 아니라 기준이 없어서입니다.

범위를 적어 두었더라도 진행 중에 오간 합의는 그때그때 남겨야 합니다. 처음 문서만 완벽하고 이후의 변경이 통화로만 오가면, 프로젝트 후반의 기준은 다시 사라집니다.

메일이나 메신저로 남긴 확인도 기록입니다. 다만 어디에 어떻게 남길지를 처음에 정해 두어야 나중에 찾을 수 있습니다.

자주 묻는 질문