개발 외주에서 현업 담당자는 “다음 주부터 진행해 주세요”라고 말하지만 구매팀은 신규 협력사 등록을 요청하고, 법무 검토와 공식 발주일은 아직 정해지지 않았을 수 있습니다. 이때 계약서가 없으니 아무 효력이 없다고 단정하는 것도, 진행하죠를 듣자마자 개발팀을 비우는 것도 정확한 대응이 아닙니다.

이 차이는 고객을 믿느냐의 문제가 아닙니다. 담당자가 프로젝트를 선택한 시점, 회사가 비용 집행을 승인한 시점, 외부 인력이 유상 업무를 시작한 시점이 서로 다르기 때문에 생깁니다.

“진행하죠”가 어디까지 합의였는지 확인해야 합니다

계약은 서명된 최종 계약서 외에도 성립할 수 있습니다. 대법원은 청약과 승낙이 명시적일 필요는 없으며, 계약의 본질적·중요 사항에 구체적인 의사 합치가 있거나 나중에 그 내용을 정할 기준과 방법에 합의하면 된다고 봅니다(2024다294033). 다만 당사자가 별도의 본계약이나 특정 형식을 갖추기로 명확히 정한 경우에는 판단이 달라질 수 있습니다(2022다225767, 225774).[1]

따라서 이메일과 회의에서 범위, 금액, 일정에 합의했다면 이를 단순한 인사말로 취급해서는 안 됩니다. 반대로 진행하죠 한마디에 개발 범위와 대금, 검수, 지급일까지 모두 합의됐다고 볼 수도 없습니다. 그 말을 한 담당자에게 해당 조건을 확정할 권한이 있는지도 별도 문제입니다. 대법원은 영업팀 과장이 고객 수요 파악과 서비스 제안 업무를 맡았다는 사실만으로 계약 체결 권한까지 인정하지는 않았습니다. 직함만 보고 권한이 전혀 없거나 충분하다고 단정하기보다, 고객사의 결재·구매 절차와 계약 권한을 확인해야 합니다.[2]

개별 거래의 계약 성립 여부는 사실관계에 따라 달라집니다. 개발사가 스스로 정할 수 있는 것은 법적 결론이 아니라 착수 기준입니다. 이미 착수했거나 권한과 합의 범위에 이견이 있다면 계약 자료 전체를 법무 담당자나 변호사에게 검토받는 편이 안전합니다. 저는 고객의 의사를 확인한 날과 개발 기간을 계산하기 시작하는 날을 분리해 적는 편이 안전하다고 봅니다.

계약이 있어도 청구할 프로젝트는 아직 없을 수 있습니다

협력사 등록은 고객사마다 범위가 다르며 특정 프로젝트의 발주와 별도로 운영될 수 있습니다. 거래자 코드, 지급계좌, 보안·재무 정보를 등록했어도 이번 프로젝트의 범위와 예산은 아직 승인 전일 수 있습니다. 반대로 기본계약을 이미 체결한 협력사도 새 프로젝트마다 개별 발주 문서나 주문번호를 받아야 할 수 있습니다.

이 문서의 이름은 회사마다 다릅니다. 구매주문서, 발주서, 개별계약서, 주문번호, 시스템 승인 등으로 나타납니다. 중요한 것은 이름이 아니라 그 증거가 실제 비용 집행과 연결되는지입니다. 개발사가 결과물을 제출했을 때 고객의 어느 프로젝트로 검수하고, 어떤 번호로 세금계산서와 청구서를 접수하며, 누가 지급을 승인하는지가 이어져야 합니다.

계약의 법적 성립과 고객사 내부 시스템의 준비는 다른 문제입니다. 계약상 대금을 받을 권리가 있다는 주장과, 정해진 지급일에 분쟁 없이 청구가 처리되는 운영 상태도 같지 않습니다. 내부 발주가 늦어진 시간을 개발사가 먼저 일해서 메우면, 구매 일정의 불확실성이 개발사의 인건비와 납기 책임으로 넘어옵니다.

법이 적용되는 거래라면 서면 시점 자체가 의무가 되기도 합니다. 하도급법상 용역위탁에 해당하는 경우 원사업자는 수급사업자가 용역 수행을 시작하기 전에 하도급대금과 지급 방법 등 법정 사항을 담은 서면을 발급해야 합니다. 다만 대기업과 개발사가 거래한다는 이유만으로 모든 프로젝트에 하도급법이 자동 적용되지는 않습니다. 당사자의 규모와 지위, 위탁 업무의 성격 등 적용 요건을 따로 확인해야 합니다.[3]

착수일보다 착수 조건을 먼저 합의해야 합니다

9월 1일 착수만 적으면 고객의 구매 승인이 9월 5일로 밀렸을 때 일정 책임이 모호해집니다. 날짜와 함께 조건을 적으면 두 조직의 시계를 맞출 수 있습니다.

저라면 다음 다섯 가지가 한 흐름으로 연결되는지 확인합니다.

  • 이번 버전에서 구현할 범위와 제외 범위
  • 개발 대금, 지급 단계와 지급 예정일
  • 산출물을 승인할 사람과 검수 기준
  • 고객사에서 특정 프로젝트의 비용 집행을 확인할 문서나 번호
  • 위 조건이 충족된 뒤 개발 기간을 계산하기 시작한다는 합의

문장은 길 필요가 없습니다. 예를 들어 범위·대금·검수 조건을 확정하고 고객사의 공식 발주 문서 또는 주문번호를 확인한 다음 영업일부터 개발 기간을 계산한다고 적을 수 있습니다. 고객사가 다른 착수 신호를 사용한다면 그 명칭으로 바꾸면 됩니다.

고객사 담당자도 이 조건을 개발사에 먼저 알려주는 편이 좋습니다. “내부 구매 절차가 2주 걸리니 그 이후부터 개발 일정을 잡아 주세요”라고 말하면, 개발사는 승인되지 않은 날짜에 인력을 묶지 않아도 됩니다. 고객은 구매 지연을 개발 지연과 구분해 보고할 수 있습니다.

급한 프로젝트는 무료 착수가 아니라 범위를 줄여야 합니다

공식 발주 전에도 미팅과 개략 견적, 공개 자료 검토는 필요합니다. 문제는 준비라는 이름으로 요구사항 분석, 화면 설계, 기술 검증과 실제 구현이 조금씩 시작될 때입니다. 발주가 늦어지거나 무산되면 비용뿐 아니라 결과물의 사용 권리도 모호해집니다.

급해서 기다릴 수 없다면 원칙을 없애기보다 계약 단위를 줄일 수 있습니다. 1~2주의 유상 사전 진단으로 범위, 기간, 산출물과 금액을 작게 확정하고, 운영 데이터 연결과 본 개발은 정식 발주 뒤에 시작하는 방식입니다. 반복 거래라면 기본계약을 미리 두고 프로젝트마다 짧은 개별 발주로 여는 방법도 있습니다.

저는 진행하죠라는 말을 의심하지 않습니다. 다만 그 말을 개발팀의 빈 일정으로 바로 바꾸지도 않습니다. 고객의 선택이 범위·예산·검수·지급 경로와 연결된 순간을 착수 조건으로 남길 때, 개발사는 확정된 일에 사람을 배정하고 고객은 약속한 납기를 제대로 계산할 수 있습니다.

출처