범위, 가격, 일정만 정하고 나머지를 비워 둔 구축 파트너 계약이라면, 납품은 상대의 선의에 달리게 됩니다. 서명 전에 일곱 가지를 서면으로 정합니다. 지정 인력과 각자의 투입 비율, 누군가 빠질 때의 교체 규칙, 검수(누가 시험하고, 누가 서명하며, 무엇을 완료로 보는지), 데이터 마이그레이션 책임자, 자사 팀이 단독 운영을 시작하는 날짜, 다른 산출물처럼 검수하는 문서, 그리고 해지 조항입니다. 킥오프로 미룬 항목은 나중에 일정에 쫓기는 상황에서, 모호하게 남겨 두어야 이득을 보는 쪽이 정하게 됩니다.
가장 흔한 빈틈은 인력입니다. 제안서에는 요구사항 분석 워크숍을 이끌었고 설계 선택마다 그 이유를 아는 리드 컨설턴트가 나옵니다. 그런데 계약서에는 사람이 아니라 회사 이름만 적힙니다. 설계 단계가 끝나면 그 리드는 다른 고객사로 옮기고, 후임은 그때 손이 비는 사람이 맡습니다. 약속한 게 없으니 어긴 것도 없습니다. 그리고 첫 담당자가 이미 내린 결정을 새 담당자가 다시 익히는 동안 그 비용은 고객사가 치릅니다.
의사결정 권한과 설계 권한은 선정 과정에서 따질 문제이며, Salesforce RFP에서 운영 모델을 검증하는 방법을 다룬 노트에서 설명합니다. 이 노트에서는 선정을 마친 뒤 서명하는 계약서에 무엇이 담겨야 하는지를 다룹니다.
투입 인력은 누구이며, 누군가 빠지면 어떻게 됩니까?
제안서에서는 팀 전체를 소개하지만, 계약서에는 대개 회사 이름만 적힙니다. 이 간극은 납품을 실제로 맡을 사람의 이름을 적어서 메웁니다. 딜리버리 리드, 설계를 책임지는 리드 컨설턴트, 데이터 작업을 맡는 담당자입니다. 사람마다 이 프로젝트에 쓰는 시간 비율과 맡는 단계를 적습니다. 투입 비율 없이 이름만 적으면, 그 사람의 시간은 이 프로젝트에 확보되지 않습니다.
사람은 실제로 떠나고, 이를 금지하는 조항은 지켜지지 않습니다. 정할 수 있는 건 규칙입니다. 서면 통보, 고객사가 거부할 수 있는 후임 프로필, 새 담당자가 업무를 넘겨받는 동안 구축 파트너가 비용을 부담하는 중첩 기간, 그리고 구축이나 컷오버 중에는 고객사 동의 없이 딜리버리 리드를 바꾸지 않는다는 조건입니다. 여기에 이름 하나를 더 적습니다. 프로젝트가 지연될 때 연락할, 딜리버리 리드의 상급자입니다.
마케팅 자료는 어디까지나 홍보물입니다. Salesforce 파트너 페이지는 구매자를 컨설팅 파트너 디렉터리로 안내하고, 이와 별도로 Forward Deployed Engineering 파트너도 소개합니다. 함께 실린 사례에는 $15M 규모의 파이프라인부터 자율 케이스 해결률 84%까지 여러 성과가 나옵니다. 이 성과는 다른 고객사와 다른 팀에서 나왔고, 어느 파트너 분류에 속하든 각 회사가 내세우는 자체 사례도 마찬가지입니다. 고객사가 맡기는 이번 프로젝트를 실제로 맡을 사람은 인력 조항에 이름이 적힌 사람입니다.
무엇을 완료로 보고, 검수에는 누가 서명합니까?
구축 파트너와의 분쟁은 결국 검수에서 불거집니다. 대금과 품질이 맞닿는 지점이기 때문입니다. 검수는 양쪽이 서명하는 계약서 자체에 적고, 산출물마다 세 가지 질문에 답합니다.
시험하는 사람. 고객사 핵심 사용자가 자사 프로세스로, 운영 환경에 가까운 데이터를 써서 시험합니다. 구축 파트너는 핵심 사용자가 시험하는 동안 결함을 고치려고 그 자리에 있습니다.
서명하는 사람. 산출물마다 고객사 쪽에서 지정한 한 사람이 서명하고, 휴가에 대비해 대리인을 둡니다. 운영위원회 회의는 서명을 대신하지 못하며, 구축 파트너가 자기 산출물의 검수에 서명하는 일도 없어야 합니다.
완료의 기준. 구축을 시작하기 전에 적어 둔 기준, 미리 합의한 심각도 등급, 그리고 종료 규칙이 필요합니다. 예를 들면 미해결 차단 결함이 하나도 없고, 나머지 결함은 모두 수정 날짜와 함께 목록에 올라 있어야 한다는 규칙입니다. 간주 검수 조항도 조심합니다. 일정 기간 이의가 없으면 산출물을 검수한 것으로 보는 조항입니다. 이 조항을 남긴다면, 그 기간은 구축 파트너가 이메일을 보낸 시점이 아니라 고객사 시험 담당자가 빌드와 데이터를 모두 받은 시점부터 셉니다.
대금 지급 마일스톤은 하나하나 서명된 검수에 묶습니다. 달력상의 날짜나, 산출물이 준비됐다는 구축 파트너의 통보에 묶지 않습니다.
데이터 마이그레이션은 누가 책임집니까?
양쪽에 따로 물어보면 답이 엇갈리는 경우가 많습니다. 제안서에는 구축 파트너가 마이그레이션을 “지원”한다고 적혀 있는데, 고객사는 이를 “수행”으로 읽습니다. 그러다 아무도 정리를 요청받지 않은 중복 데이터 때문에 첫 시험 적재가 실패하고, 양쪽이 서로 책임을 미룹니다.
데이터와 그 의미는 고객사의 몫입니다. 따라서 고객사 쪽 한 사람, 대개 해당 데이터의 현업 책임자가 마이그레이션 결과를 책임집니다. 어떤 레코드를 옮길지, 중복 레코드 중 어느 쪽을 남길지, 어떤 이력을 옮기지 않을지를 정합니다. 구축 파트너는 대가를 받는 실무를 책임집니다. 매핑 문서, 변환, 적재 스크립트, 리허설, 정합성 보고서입니다. 이 분담을 계약서에 적습니다. 기존 시스템에서 데이터를 추출하는 작업도 명시합니다. 이 작업은 이 프로젝트에서 이 프로젝트와 아무 계약도 없는 제삼자(기존 시스템 공급사, 사내 IT 팀)가 맡는 경우가 많기 때문입니다.
두 줄을 더 넣으면 흔한 다툼을 피할 수 있습니다. 계약 금액에 포함된 전체 리허설 횟수, 그리고 원천 데이터가 준비되지 않아 실패한 리허설의 비용을 누가 부담하는지입니다. 컷오버 전에 입증할 항목(객체별 책임자, 현업이 서명하는 건수, 롤백 마감 시각)은 Salesforce 데이터 마이그레이션 노트에서 다룹니다.
자사 팀은 언제부터 org를 단독으로 운영합니까?
인계 날짜를 계약서에 넣습니다. 자사 팀이 org를 단독으로 운영하고 구축 파트너가 릴리스 작업에서 손을 떼는 날입니다. 계획은 그 날짜에서 거꾸로 세웁니다.
그 날짜 전까지 자사 관리자는 마지막 주에 데모를 구경하는 데 그치지 않고, 구축 기간 내내 구축 파트너 옆에서 함께 일한 상태여야 합니다. 문서(설계 결정, 설정 노트, 릴리스와 장애 대응 런북)도 다른 산출물처럼 시험하고 서명을 마쳐야 합니다. 교육 계획도 여기에 들어갑니다. 검수 테스트 전에 정해 두면 핵심 사용자가 나중에 가르칠 내용을 직접 시험하게 됩니다. 교육 순서는 출시 시점의 Salesforce 교육 계획 노트에서 정리합니다.
인계는 검증할 수 있어야 합니다. 그 날짜 전에 자사 팀이 릴리스 한 번을 스스로 배포하고, 구축 파트너는 지켜보기만 합니다. 해내지 못하면 날짜가 밀리고, 늘어난 기간의 비용을 누가 낼지는 이미 계약서에 적혀 있습니다. 날짜 이후에는 범위와 응답 시간을 서면으로 정한 지원 기간이 이어집니다. 이 기간에도 종료일을 정해 둡니다. 종료일이 없으면 지원은 합의한 한도 없이 이어지고, 비용은 협상한 적 없는 조건으로 계속 나갑니다.
일이 틀어지면 어떻게 계약에서 빠져나옵니까?
계약을 끝낼 생각으로 서명하는 고객사는 드뭅니다. 그래서 해지 조항은 표준 문구 그대로 남는 경우가 가장 많습니다. 그런데 일이 틀어졌을 때 자사 작업물을 계속 손에 쥘 수 있는지를 정하는 조항이 바로 해지 조항입니다.
실제로 쓸 수 있는 해지 조항은 네 부분으로 이루어집니다.
- 계약 위반이 있을 때만이 아니라, 사전 통보를 조건으로 임의로 계약을 끝낼 권리. 지연된 프로젝트에서 위반을 입증하는 일은 더디고 다툼이 많으며, 논쟁하는 사이에도 프로젝트는 계속 시간을 잃습니다.
- 지금까지 만든 모든 작업물(메타데이터, 코드, 스크립트, 데이터 매핑, 테스트 케이스, 문서)을 쓸 수 있는 상태로, 고객사 소유로 넘겨받는 조건.
- 다음 팀에 넘기는 인계 지원. 기간을 정하고, 단가는 지금 합의해 둡니다.
- 첫날부터 고객사가 보유하는 접근 권한: 관리자 계정, 연동 자격 증명, 환경, 저장소. 계약 종료가 비밀번호 협상으로 번져서는 안 됩니다.
해지 조항은 인력 조항과 나란히 놓고 읽습니다. 지정된 리드가 떠나고 고객사가 후임 프로필을 두 번 연속 거부했다면, 위반을 입증하지 않아도 해지할 수 있어야 합니다.