현업 담당자와 몇 차례 미팅한 뒤 이런 말을 들을 수 있습니다. “이 프로젝트는 같이 진행하시죠. 일정부터 잡아주세요.” 개발사 입장에서는 수주가 확정된 것처럼 들립니다. 다른 일을 미루고 기획이나 개발을 먼저 시작하고 싶어집니다.

그런데 다음에 도착하는 것은 계약서가 아닐 수 있습니다. 신규 협력사 등록 양식, 보안 질문서, 신용평가 동의서가 차례로 옵니다. 구매팀과 법무팀의 검토가 남았고, 공식 발주일은 아직 정해지지 않았다는 설명도 뒤따릅니다.

담당자의 말이 가벼워서 생기는 문제는 아닙니다. 현업 담당자는 프로젝트의 필요성을 승인할 수 있지만, 회사의 구매 절차와 비용 집행까지 혼자 확정하지 못할 수 있습니다. 그래서 담당자의 진행 의사와 개발사의 착수 기준을 나누어 봐야 합니다.

담당자의 승인은 수요 신호이고, 발주는 착수 신호입니다

“진행하죠”라는 말은 고객사 안에 해결하려는 문제가 있고 담당자가 개발사를 선택했다는 강한 신호입니다. 다만 이 말만으로 개발 범위, 금액, 검수 조건과 지급 책임까지 확정되지는 않습니다.

대기업 거래에는 보통 두 개의 일정이 함께 움직입니다. 하나는 공급자 등록, 보안·법무 검토, 계약과 발주로 이어지는 구매 일정입니다. 다른 하나는 요구사항 정리, 설계, 구현과 검수로 이어지는 개발 일정입니다. 두 일정을 한 줄로 적으면 구매 승인이 늦어진 시간까지 개발 지연처럼 보일 수 있습니다.

저라면 착수일을 먼저 약속하지 않습니다. 고객사에 “어떤 문서나 승인이 완료되면 유상 개발을 시작하는가”를 먼저 묻고, 그 시점부터 개발 기간을 계산합니다. 회사에 따라 서명된 계약서, 구매 주문서, 기본계약에 따른 서면 발주 중 답이 달라질 수 있습니다.

협력사 등록은 계약이 아니라 거래 자격을 확인하는 과정입니다

공급자 등록 과정에서는 사업자 정보, 계좌, 납세 자료와 담당자 정보를 수집하고 서로 맞는지 확인합니다. 등록이 끝나면 해당 회사와 거래할 수 있는 공급자가 된 것이지, 특정 프로젝트의 주문이 자동으로 생기는 것은 아닙니다. 외부 개발사에 고객 데이터나 내부 시스템 접근 권한을 주면 그 개발사도 공급망의 일부가 되기 때문에, 등록 단계의 확인이 그만큼 까다로워집니다.[1]

제가 협력사 등록 자료를 검토한다면 서류의 양보다 답변이 서로 맞는지를 먼저 봅니다. 사업자등록증의 상호와 계좌 명의, 계약 당사자와 실제 개발 주체가 다르면 보완이 길어질 수 있습니다. 보유하지 않은 인증이나 운영 체계를 있는 것처럼 적기보다, 현재 가능한 통제와 고객사에 요청할 예외를 구분해서 답하는 편이 안전합니다.

AI 프로젝트라면 보안 질문이 하나 더 늘어납니다

AI 기능이 들어가면 어떤 데이터를 외부 모델에 보내는지, 프롬프트와 결과를 누가 보관하는지, 모델 제공사가 학습에 사용하는지 같은 질문이 추가됩니다.

저는 AI 기능이 들어간 제안서에 모델 이름부터 적지 않습니다. 보안 담당자가 먼저 확인할 것은 어떤 모델을 쓰는지가 아니라 고객 데이터가 어디까지 나가는지이기 때문입니다. 그래서 데이터가 이동하는 경로, 외부 API에 전달되는 항목, 로그와 파일의 저장 기간, 개발 계정의 접근 권한을 함께 적습니다.[2]

보안 검토가 끝나기 전에 기술 검증이 필요하다면 운영 데이터 대신 비식별 샘플이나 가상 데이터를 쓰는 방법이 있습니다. 실제 고객 데이터 연결, 운영 계정 발급, 사내 시스템 변경은 승인 이후 단계로 남깁니다. 이렇게 나누면 구매 절차를 기다리는 동안에도 위험이 낮은 준비 작업은 진행할 수 있습니다.

무료 준비와 유상 개발의 경계를 먼저 적습니다

공식 발주 전에도 미팅, 제안서 보완, 일정 조율은 필요합니다. 문제는 준비 작업의 범위가 요구사항 분석과 화면 설계, 실제 구현까지 조금씩 넓어지는 경우입니다. 발주가 무산되면 그동안의 작업 비용과 결과물 권리를 설명하기 어려워집니다.

저는 발주 전 작업을 세 구간으로 나누는 편이 명확하다고 봅니다.

  • 영업 준비: 미팅, 공개 자료 검토, 개략 견적
  • 유상 사전 진단: 요구사항 분석, 기술 검증, 상세 범위 작성
  • 본 개발: 운영 데이터와 시스템을 사용하는 설계·구현·배포

유상 사전 진단이 필요하다면 본 개발 계약을 기다리며 무료로 진행하지 않고, 기간과 산출물을 줄인 별도 계약으로 제안할 수 있습니다. 고객사도 무엇을 근거로 본 개발 예산을 확정하는지 분명해집니다.

개발 일정과 지급 일정은 같은 날 시작하지 않습니다

개발사가 일정을 비운 날부터 대금 지급 시계가 움직이는 것은 아닙니다. 계약과 발주가 끝나도 검수 승인, 세금계산서 발행, 월 마감과 지급일까지 시간이 더 필요할 수 있습니다.

착수 전에 다음 다섯 가지를 확인하면 일정과 현금 흐름을 함께 볼 수 있습니다.

  • 신규 협력사 등록이 필요한가
  • 보안·법무 검토와 계약을 병행할 수 있는가
  • 유상 작업의 시작을 증명하는 문서는 무엇인가
  • 산출물을 누가 어떤 기준으로 검수하는가
  • 검수와 세금계산서 발행 후 실제 지급일은 언제인가

고객사 담당자도 이 순서를 개발사에 알려주는 편이 좋습니다. 내부 승인에 필요한 시간을 감춘 채 납기만 먼저 약속하면, 개발사는 확정되지 않은 일정에 사람을 배정하게 됩니다.

두 개의 일정을 나누면 착수일을 약속할 수 있습니다

대기업 프로젝트가 느려서 어려운 것은 아닙니다. 구매 승인 시간과 실제 개발 시간을 한 일정으로 적을 때 책임이 흐려집니다. 협력사 등록·보안·계약·발주의 완료 조건을 먼저 확인하고, 합의한 착수 신호가 온 날부터 개발 일정을 시작하면 양쪽이 같은 날짜를 보게 됩니다.

출처