정부과제 외주 계약, 계약서 한 장이 정산을 결정합니다 - 지급 구조와 검수 조건 설계

정부 창업과제에 선정되어 개발 외주 파트너를 정하고 나면, 다음 순서는 계약입니다. 그런데 많은 창업자분들이 이 단계를 "견적서 금액을 확인하고 서명하는 절차" 정도로 지나가십니다. 개발 내용은 미팅에서 충분히 이야기했으니 계약서는 형식이라고 여기는 것입니다. 그리고 그 계약서는 과제가 끝나갈 무렵, 정산이라는 이름으로 돌아옵니다.

결론을 먼저 말씀드리면, 사업비 정산에서 담당자가 확인하는 것은 개발의 품질이 아니라 "문서들의 정합성"이며, 그 정합성의 출발점이 외주 계약서입니다. 계약서, 세금계산서, 검수 문서, 지급 기록이 하나의 앞뒤 맞는 이야기를 이루면 정산은 순조롭고, 어느 하나가 어긋나면 실제로 개발이 잘 되었어도 소명의 시간이 시작됩니다. 이 시리즈에서 다뤄온 사업계획서, 지원사업 선택, 발표평가, 준비 단계의 실수, 시제품의 목적 구분, 산출물 자산 관리에 이어, 일곱 번째 주제로 집행의 실무 중 가장 문서가 중요한 지점인 외주 계약을 정리합니다.

지급의 근거는 검수이고, 검수의 근거는 계약서에 적힌 조건입니다.

정산의 눈으로 계약서를 읽으면 다르게 보입니다

이전 글에서 영수증이 있어도 사업비로 인정되지 않는 경우들을 다뤘습니다. 그 문제의 뿌리를 거슬러 올라가면 상당수가 계약 단계에 닿습니다. 계약서에 없는 항목이 지급되었거나, 계약 금액과 지급 금액이 다르거나, 잔금이 나갔는데 무엇을 확인하고 지급했는지의 근거가 없는 경우입니다. 개발 현장에서는 "진행하다 보니 자연스럽게" 일어난 일들이지만, 정산 서류 위에서는 설명이 필요한 어긋남이 됩니다.

그래서 외주 계약서는 개발사와 나 사이의 약속이면서, 동시에 "미래의 정산 담당자에게 보내는 설명서"라는 두 번째 독자를 갖습니다. 계약서를 쓸 때 이 두 번째 독자를 의식하는 것만으로도 문서의 모습이 달라집니다. 협약서의 과업 내용과 계약서의 개발 범위가 같은 언어로 연결되어 있는지, 지급의 조건이 문장으로 적혀 있는지가 그 핵심입니다.

지급 구조는 개발 단계와 짝을 이뤄야 합니다

지급 구조에서 가장 피해야 할 형태는 근거 없는 일시 선지급입니다. 개발 착수 전에 전액이 나가면, 이후 일정이 늘어지거나 결과가 기대와 다를 때 창업자가 쓸 수 있는 수단이 사라지고, 정산에서도 "지급 시점에 무엇이 확인되었는가"라는 질문에 답하기 어려워집니다. 건강한 구조는 선금, 중도금, 잔금이 각각 개발의 단계와 짝을 이루는 형태입니다. 착수와 함께 선금이, 중간 산출물의 검수와 함께 중도금이, 최종 검수와 함께 잔금이 움직이는 것입니다.

이 구조의 핵심은 각 지급 옆에 "무엇이 확인되면 지급하는가"가 문장으로 적히는 것입니다. 이렇게 짝지어진 지급은 세 가지를 동시에 해결합니다. 창업자에게는 진행을 관리할 자연스러운 점검 지점이 생기고, 개발사에게는 명확한 목표가 생기며, 정산 서류에는 지급마다의 근거 문서가 남습니다. 과제 일정을 역산해 개발 마일스톤을 세웠다면, 지급 일정은 그 마일스톤 위에 얹으면 됩니다.

중도금의 근거는 눈에 보이는 중간 산출물과 그 검수 기록입니다.

검수 조건은 명사가 아니라 문장으로

계약서의 산출물 항목이 "시제품 일식"처럼 명사로만 적혀 있으면, 검수는 기준 없는 감상이 됩니다. 검수 조건은 문장이어야 합니다. 어떤 기능이 어떤 조건에서 동작하는 것을 확인하면 통과인지, 함께 인수할 산출물은 무엇이고 어떤 형식으로 전달되는지가 적혀야, 검수하는 날의 논의가 짧아지고 검수 문서가 곧 정산 증빙이 됩니다. 지난 글에서 다룬 산출물 자산 관리의 인수 목록이 바로 이 자리, 계약서 안에 들어가는 것이 가장 이상적입니다.

• "과업과의 정합": 계약서의 개발 범위가 협약서의 과업 내용과 같은 표현으로 연결되어 있는지 확인합니다. 두 문서의 언어가 다르면 정산에서 연결을 소명해야 하는 쪽은 창업자입니다
• "지급의 조건": 선금·중도금·잔금 각각에 대해 지급 시점과 확인 사항이 문장으로 적혀 있는지 확인합니다
• "산출물의 명세": 실물 외에 설계 파일, 제조용 파일, 소스의 제공 범위와 형식, 전달 시점이 목록으로 있는지 확인합니다
• "변경의 절차": 개발 중 범위가 바뀔 때 어떤 절차로 합의하고 문서화할지 정합니다. 과업 변경이 승인되면 계약서도 함께 고쳐야 두 문서의 정합이 유지됩니다
• "하자 대응": 검수 통과 후 발견되는 문제를 언제까지, 어떤 범위로 보완하는지의 조항이 있는지 확인합니다

판단 기준은 한 문장입니다

"이 계약서를 처음 보는 정산 담당자가 읽어도, 언제 왜 얼마가 지급되었는지가 한눈에 이어지는가." 서명하기 전에 이 질문으로 계약서를 한 번 읽어 보시기 바랍니다. 이어지지 않는 부분이 보인다면, 그곳이 몇 달 뒤 소명 요청이 도착할 자리입니다. 지금 고치면 문장 몇 줄이지만, 정산에서 만나면 서류 뭉치가 됩니다.

좋은 계약은 개발의 결과물과 문서의 기록이 같은 이야기를 하게 만듭니다.

제언: 계약서는 형식이 아니라 과제 운영의 설계도입니다