IT 개발 용역계약서

용역계약서 마스터·8분·2028.09.24

과업이 움직이는 것이 이 계약의 성질입니다

처음에 다 정할 수 있었다면 개발이 아닙니다.

개발 용역에서 벌어지는 다툼의 상당수는 같은 모양입니다. 계약할 때 정한 것과 다 만들고 났을 때의 결과물이 다르고, 그 차이를 누가 감당할지가 정해져 있지 않습니다.

이 상황을 처음에 범위를 제대로 못 정한 탓으로 돌리는 경우가 많습니다. 그런 면도 있지만 전부는 아닙니다. 만들어 보면서 알게 되는 것이 있고 쓰는 사람의 요구가 그사이에 바뀌기도 합니다. 처음에 모든 것을 확정할 수 있는 일이었다면 개발이라고 부르지 않았을 것입니다.

그래서 이 계약서에서 힘을 쏟을 자리는 범위를 촘촘히 적는 쪽이 아니라 범위가 움직일 때 무엇을 하는지를 적는 쪽입니다. 움직임을 막으려는 계약서는 대체로 실패하고, 움직임을 처리하는 계약서가 살아남습니다.

물론 처음의 범위도 필요합니다. 기준이 있어야 무엇이 얼마나 움직였는지를 말할 수 있기 때문입니다. 다만 그 범위는 움직임을 재는 자로 쓰는 것이지 못을 박는 용도가 아닙니다.

공공 발주에는 제도가 있고 민간에는 없습니다

이 차이를 모르고 남의 규칙을 가져다 쓰면 어긋납니다.

국가기관등이 발주한 소프트웨어사업에는 과업내용의 변경을 다루는 제도가 마련되어 있습니다. 과업심의위원회라는 이름의 기구가 있고, 국가기관등의 장은 과업내용의 변경과 관련된 사항을 확정하려는 경우 그 심의와 의결을 거치도록 되어 있습니다.

계약을 체결한 사업자 쪽에서도 과업내용 변경으로 계약 내용의 변경이 필요한 경우 위원회의 개최를 요청할 수 있고, 국가기관등의 장은 특별한 사정이 없으면 그 요청을 수용하여야 한다는 내용이 함께 확인됩니다. 위원회는 과업내용의 변경에 따른 계약금액과 계약기간의 조정도 심의합니다.

여기서 반드시 짚어야 할 것이 적용 대상입니다. 이 제도는 국가기관등이 발주한 사업의 것입니다. 민간이 발주한 개발 용역에 그대로 적용되는 제도라고 읽으면 안 됩니다.

민간 계약에서 이 제도가 주는 시사점은 다른 데 있습니다. 과업이 바뀔 때 그것을 확정하는 절차를 따로 두었다는 발상 자체입니다. 위원회를 만들 수는 없어도 무엇을 거쳐야 과업이 바뀐 것으로 보는지를 계약서에 두는 일은 민간에서도 할 수 있습니다.

변경을 처리하는 세 단계

요청 · 영향 검토 · 확정입니다.

민간 개발 계약에 넣을 수 있는 절차를 세 단계로 좁히면 요청과 영향 검토, 확정입니다. 이 세 단계를 조항으로 두면 대부분의 변경이 다툼 없이 지나갑니다.

핵심은 두 번째입니다. 요청이 들어왔을 때 곧바로 하겠다거나 못 하겠다고 답하지 않고, 그 요청이 일정과 금액에 어떤 영향을 주는지를 먼저 계산해 제시하는 것입니다. 이 단계가 없으면 요청은 늘 공짜로 보입니다.

1. 변경 요청을 문서로 받는다무엇을 어떻게 바꾸고 싶은지를 문장으로 받습니다. 대화에서 나온 이야기도 이 형태로 옮겨 적습니다.
2. 영향을 검토해 회신한다일정이 며칠 늘어나는지, 금액이 얼마나 바뀌는지, 다른 기능에 어떤 영향이 있는지를 적어 보냅니다.
3. 확정 여부를 서면으로 정한다진행할지 보류할지를 정하고 그 결과를 남깁니다. 보류한 것도 남겨 두어야 나중에 왜 안 했는지를 답할 수 있습니다.
4. 확정된 변경을 산출물 목록에 반영한다무엇을 만들기로 한 것인지가 한곳에서 관리되도록 목록을 갱신합니다.
5. 일정과 대금 조항을 갱신한다회차가 있다면 어느 회차가 어떻게 바뀌는지까지 반영합니다.
6. 누적된 변경을 주기적으로 정리한다작은 변경이 쌓이면 처음 계약과 크게 달라집니다. 일정한 주기로 현재 상태를 확인합니다.

세 번째 단계에서 보류한 것을 남기라는 조언이 낯설 수 있습니다. 실제로는 이 기록이 가장 유용한 자료가 됩니다. 나중에 왜 이 기능이 없느냐는 물음에 언제 어떤 이유로 보류했는지를 답할 수 있기 때문입니다.

여섯 번째 단계를 건너뛰면 작은 변경이 쌓여 처음 계약과 전혀 다른 결과물이 됩니다. 한 달에 한 번쯤 현재 무엇을 만들기로 되어 있는지를 양쪽이 함께 확인하십시오.

산출물과 권리를 나누어 적습니다

무엇이 넘어가는지와 무엇을 쓸 수 있는지는 다른 문제입니다.

개발 용역에서 산출물은 여러 층으로 되어 있습니다. 실행되는 결과물이 있고 그것을 만든 원본이 있으며 설계와 설명을 담은 문서가 있습니다. 어디까지를 넘기는 것으로 할지는 계약마다 다릅니다.

그래서 산출물 조항에는 항목별로 적으십시오. 무엇을 어떤 형태로 몇 개 넘기는지를 목록으로 두면 다 넘겼는지를 세어 볼 수 있습니다. 넘기지 않는 것이 있다면 그것도 적어 두어야 합니다.

권리에 관한 조항은 별도로 둡니다. 산출물이 넘어가는 것과 그것을 자유롭게 쓸 수 있는 권리가 넘어가는 것은 다른 문제입니다. 이전 시점을 대금과 묶어 두는 방식이 실무에서 널리 쓰입니다.

여기에 더해 만드는 쪽이 원래 가지고 있던 것과 외부에서 가져온 것을 구분해 두십시오. 이전부터 쓰던 공통 모듈이나 외부의 구성 요소가 결과물에 들어가는 경우가 많은데, 그것까지 통째로 넘긴다고 적으면 지킬 수 없는 약속이 됩니다.

다섯 번째 줄은 개발 용역에서만 특별히 중요한 자리입니다. 외부의 구성 요소마다 붙어 있는 이용 조건이 다르고, 그 조건이 결과물의 사용 방식을 제한하는 경우가 있습니다. 목록을 넘기는 것이 서로에게 안전합니다.

두 번째 줄은 협의 자체가 필요한 항목입니다. 넘기기로 한다면 그에 맞는 대가가 반영되어야 하고, 넘기지 않기로 한다면 유지보수를 어떻게 할지가 따라옵니다.

검수와 유지보수의 경계

고쳐 주는 것과 새로 만드는 것을 갈라 둡니다.

납품 이후에 생기는 다툼의 대부분은 하나의 물음으로 모입니다. 이것은 고쳐 주어야 하는 것인가 새로 만들어 주어야 하는 것인가입니다.

계약에서 정한 대로 동작하지 않는 것은 앞쪽입니다. 계약에서 정하지 않았던 동작을 요구하는 것은 뒤쪽입니다. 말로는 간단해 보이지만 계약서에 무엇을 정했는지가 흐릿하면 이 구분이 서지 않습니다.

그래서 검수 기준을 문서로 만들어 두는 편이 낫습니다. 어떤 조건에서 무엇이 어떻게 동작하면 합격인지를 항목으로 적어 두면, 납품 이후의 요청이 어느 쪽인지가 그 문서에서 갈립니다.

유지보수를 별도 계약으로 둘지 이 계약에 포함할지도 정해야 합니다. 포함한다면 기간과 대응 범위, 응답 시간을 적고, 별도로 둔다면 언제부터 시작하는지와 그 전까지의 처리를 적어 두십시오.

정리하면 이 계약서의 중심은 변경 절차와 산출물 목록, 검수 기준 세 가지입니다. 세 가지가 서로를 참조하도록 만들어 두면 과업이 움직여도 계약이 따라 움직입니다.

범위를 적는 문장과 검수 조항을 짜는 방법은 각각 다른 편에서 자세히 다룹니다.

자주 묻는 질문