작업기술서 SOW 란 무엇인가: 계약에 꼭 넣어야 할 항목

작업기술서 SOW 란 서비스 계약에서 무엇을 전달하는지, 언제까지, 누가 맡는지, 대금은 얼마인지를 정한 문서입니다. 영문 Statement of Work를 줄여 SOW라고 부릅니다. 작업기술서 SOW 란 공통 법적 조건이 담긴 기본계약 아래에 놓이는 프로젝트 단위의 문서라고 이해하면 쉽습니다. 계약 분쟁에서 "그건 합의한 적 없다"는 말이 나올 때, 그 판단은 대부분 이 문서에서 갈립니다.

작업기술서에는 어떤 내용이 들어가나요?

SOW는 한 건의 업무만 다룹니다. 두 회사 사이의 관계 전체를 덮으려고 하지 않습니다. 잘 쓰인 SOW에는 보통 같은 핵심 항목이 들어갑니다.

• 작업 범위: 공급자가 무엇을 하고 무엇을 하지 않는지, 평이한 동사로 적습니다.

• 산출물: 이관된 데이터베이스, 브랜드 가이드, 40시간 분량의 지원처럼 구체적인 결과물입니다.

• 일정과 마일스톤: "분기 말까지"처럼 모호한 표현이 아니라, 산출물에 묶인 날짜나 기간입니다.

• 대금과 지급 일정: 정액, 공수 기준 실비 정산, 또는 두 방식의 혼합이며, 청구 시점을 함께 적습니다.

• 검수 기준: 고객이 산출물이 완료됐다고 판단하는 방법입니다.

• 역할과 선행 조건: 접근 권한, 데이터, 승인, 테스트 환경을 누가 언제까지 제공하는지 정합니다.

• 변경 절차: 작업이 시작된 뒤 범위, 가격, 일정을 어떻게 바꾸는지 정합니다.

이 구조가 실제로 하는 일은, 말로 주고받은 합의를 제3자가 읽고 확인할 수 있는 문서로 바꾸는 것입니다. 여기서 제3자는 판사, 감사인, 또는 프로젝트를 넘겨받는 새 담당자일 수 있습니다.

SOW는 MSA, 제안서, 발주서와 무엇이 다른가요?

이 문서들은 모양이 비슷하고 거래 과정에서 가까이 놓이기 때문에 혼동이 자주 생깁니다.

기본계약(MSA)은 책임, 지식재산권, 비밀유지, 개인정보 처리, 해지, 준거법 같은 공통 법적 조건을 담습니다. 한 번 체결하고, 각각의 SOW가 그 아래에서 프로젝트 하나씩을 다룹니다. 하나의 MSA에 여러 해에 걸친 SOW 여러 건이 달릴 수 있습니다.

제안서는 영업 문서입니다. 공급자가 무엇을 하고 싶은지, 왜 이 업체를 골라야 하는지를 설명합니다. 보통 구속력이 없고, 그 내용이 SOW의 첫 초안으로 재사용되는 경우가 많습니다. 여기서 문제가 시작됩니다. 마케팅 문구가 계약서에 그대로 들어가기 때문입니다.

발주서는 대금과 수량을 정하는 지급 승인 문서입니다. 범위는 거의 적지 않습니다. 용역 프로젝트를 발주서만으로 처리하면 실제 작업 내용이 정의되지 않은 채로 남습니다.

일회성 작업이라면 SOW를 부속서로 둔 하나의 통합 계약도 충분히 괜찮습니다. MSA와 SOW를 나누는 방식은 같은 공급자와 반복해서 거래할 때 실익이 큽니다.

MSA와 SOW가 충돌하면 어느 쪽이 우선하나요?

대부분의 사람이 건너뛰는 질문입니다. 그런데 이 질문에 대한 답이 비용을 가장 크게 좌우합니다.

잘 작성된 계약은 대개 단순한 패턴을 따릅니다. MSA가 법적 조건을 통제하고, SOW가 범위, 일정, 대금을 통제합니다. 이를 한두 문장의 우선순위 조항으로 명시하고, 두 문서가 충돌할 때 어느 쪽이 이기는지 적어 둡니다.

이 조항이 없으면 두 문서를 법원이 어떻게 함께 해석하는지에 결과를 맡기게 됩니다. 예를 들어 영국법에서는 계약 문서들을 대개 하나의 합의로 함께 읽습니다. 그래서 문서 사이의 불일치가 저절로 상쇄되지 않고, 논쟁거리가 됩니다. 논쟁은 결국 시간과 비용으로 돌아옵니다.

다음은 우선순위를 적는 문구의 예시입니다. 특정 관할의 법률 자문이 아니라 작성 방식을 보여주는 예시입니다.

§ 두 문서에 충돌이 있는 경우 법적 조건에 관하여는 기본계약이 우선한다. 다만 해당 프로젝트의 범위, 산출물, 일정 및 대금에 관하여는 SOW가 우선한다.

주의할 함정이 하나 있습니다. SOW가 이 프로젝트에 한해 책임 상한이나 지식재산권 귀속 조항을 슬쩍 바꾸는 경우입니다. 양측이 의도했다면 정당한 선택이지만, 아무도 눈치채지 못했다면 큰 문제가 됩니다. SOW에 서명하는 사람은 프로젝트 계획서가 아니라 계약서로 읽어야 합니다.

범위 조항이 분쟁에서 버티려면 어떻게 써야 하나요?

SOW가 무너지는 지점은 대부분 범위입니다. 모호한 범위는 중립적이지 않습니다. 나중에 따지는 데 더 적극적인 쪽에 유리하게 작동하고, 그 쪽은 대개 협상력이 더 큰 당사자입니다.

범위를 튼튼하게 만드는 습관은 세 가지입니다.

첫째, 제외 범위를 적습니다. 무엇이 범위에 포함되는지보다 무엇이 빠지는지를 적는 편이 더 유용할 때가 많습니다. "고객사의 기존 청구 시스템과의 연동은 포함하지 않는다"는 한 줄이 세 번의 회의로 이어질 논쟁을 끝낼 수 있습니다.

둘째, 산출물을 형용사가 아니라 명사로 묶습니다. "반응형 웹사이트"는 해석이 갈립니다. "지정된 네 개 브라우저의 최신 두 버전에서 테스트한 템플릿 여덟 개"는 확인할 수 있습니다.

셋째, 가정을 명시합니다. 일정이 고객의 피드백 회신을 영업일 5일 안에 받는다는 전제에 기대고 있다면 그 사실을 적고, 회신이 없을 때 일정이 어떻게 바뀌는지도 적습니다. 지연에 대한 주장은 의존 관계가 서면에 있을 때 훨씬 설득력이 있습니다.

템플릿을 복사해서 빈칸만 채우는 방식은 피하세요. 템플릿은 목차를 보여줄 뿐, 내 프로젝트에만 해당하는 가정이 무엇인지는 알려주지 못합니다.

검수 기준과 변경 요청은 어떻게 적어야 하나요?

검수 기준은 한 가지 질문에 답해야 합니다. 이 산출물은 대금을 지급할 만큼 끝났는가. "높은 품질"이나 "고객이 만족할 수준"은 그 질문에 답하지 못합니다. 검증 가능한 기준은 답할 수 있습니다. 예를 들어 데이터 이관이라면 "모든 레코드가 이관되었고, 대조 보고서에 설명되지 않은 차이가 없을 것"처럼 쓸 수 있습니다.

간주 인수 조항도 함께 두는 것이 좋습니다. 흔한 방식은 정해진 기간, 보통 영업일 10일 안에 고객이 서면으로 결함을 통보하지 않으면 산출물을 인수한 것으로 보는 것입니다. 이 조항이 없으면 고객은 검수를 무기한 미룰 수 있고, 최종 청구도 함께 멈춥니다. 고객 입장이라면 공급자가 지적받은 내용을 고칠 수 있는 보완 기간을 명확히 요구하세요. 그래야 양쪽 모두에게 시계가 공정하게 돌아갑니다.

변경 요청도 같은 주의가 필요합니다. 범위 확대는 대개 큰 요청 하나로 오지 않습니다. 합리적으로 보이는 작은 요청 열 개로 옵니다. 범위, 가격, 일정을 바꾸려면 작업 시작 전에 양측이 서명한 변경 주문서가 필요하다는 한 단락짜리 절차만 있어도 이 문제는 크게 줄어듭니다. 구두 합의를 허용하는 SOW 때문에 마진을 잃는 공급자가 적지 않습니다.

정액제와 실비 정산 중 어떤 방식이 맞나요?

대금 구조는 위험을 어떻게 나눌지를 결정하므로 신중하게 고를 가치가 있습니다.

정액제는 납품 위험을 공급자에게 둡니다. 범위가 잘 이해되어 있고 바뀔 가능성이 낮을 때 잘 맞습니다. 범위가 모호하면 잘 맞지 않습니다. 공급자가 가격에 여유분을 얹거나 모든 변경에 맞서 싸우게 되기 때문입니다.

공수 기준 실비 정산은 투입 노력의 위험을 고객에게 둡니다. 탐색적인 작업에 어울리지만, 상한선이나 최대 금액을 함께 두어야 합니다. 그렇지 않으면 예산은 사실상 의견에 불과합니다.

마일스톤별 정액제를 조합한 방식은 종종 가장 현실적인 절충안입니다. 각 마일스톤마다 산출물, 검수 기준, 청구 시점이 따로 있으므로 SOW를 점검하기 쉽고, 프로젝트가 어긋날 때 중간에 멈추기도 쉽습니다.

서명할 때 반복되는 실수는 무엇인가요?

이런 문서를 많이 읽어 보면 같은 실패가 계속 나타납니다.

• 기본계약이 아직 없는 상태에서 SOW에 서명해, 프로젝트가 책임과 지식재산권 조건 없이 진행되는 경우

• 일정을 "대략"이라고만 적고, 기한을 넘겼을 때의 결과는 정하지 않는 경우

• 산출물을 결과가 아니라 활동으로 적는 경우. "지원 제공"이라고 쓰고 "우선순위 문의에 영업일 기준 4시간 안에 응답"이라고 쓰지 않는 식입니다.

• 공급자가 개인정보를 다루는데 개인정보 처리 관련 문서를 빠뜨리는 경우. 개인정보 처리를 맡기는 구조라면 관련 문서를 SOW와 함께 두어야 하며, 구체적인 요건은 적용 법령과 관할에 따라 달라집니다.

• 구두로 바뀐 내용을 SOW에 반영하지 않고, 1년 뒤 기억에 의존하는 경우

이것은 이론상의 위험이 아니라 변호사들이 실제로 자주 보는 사례입니다. 어느 것도 법률 전문성이 있어야 피할 수 있는 것은 아닙니다. 서명 전에 누군가 문서를 천천히 읽기만 하면 됩니다.

다음 SOW에 서명하기 전에 무엇을 해야 하나요?

도구가 좋은 범위를 대신 써 주지는 않습니다. 다만 그 주변의 반복 작업을 줄여 줄 수는 있습니다.

재사용 가능한 블록으로 초안을 만들고, 승인과 전자서명을 한 흐름에서 처리하고 싶다면 문서 플랫폼이 실용적입니다.

서명만 필요하고 감사 추적 기록과 상대방의 익숙함이 중요하다면, 전용 전자서명 서비스로 충분합니다.

한 해에 SOW를 많이 다루고 각 문서를 기본계약과 연결해 관리해야 한다면, 계약 수명주기 관리 플랫폼이 마스터 조건과 프로젝트 문서 사이의 연결을 유지해 줍니다.

Word 안에서 조항 위험을 1차로 점검하고 싶다면, AI 검토 기능을 가진 Word 추가 기능이 제외 범위가 빠졌거나 책임 조항이 충돌하는 부분을 사람이 읽기 전에 표시해 줄 수 있습니다.

어떤 도구도 중대한 사안에서 변호사를 대신하지는 않습니다. 도구로 반복적인 문제를 잡고, 특이하거나 금액이 크거나 국경을 넘는 조항은 반드시 법률 자문과 함께 확인하세요.

핵심 조치는 세 가지로 정리됩니다.

1. 기본계약이 있는지 확인하고, SOW에 법적 조건과 범위, 대금 중 어느 쪽이 우선하는지 적습니다.

2. 모든 산출물을 제3자가 완료 여부를 예 또는 아니오로 판단할 수 있도록 다시 쓰고, 제외 범위와 가정을 추가합니다.

3. 검수 기간, 보완 기간, 서면 변경 주문 규칙을 확인하고, 모든 수정 사항을 SOW에 첨부해 함께 보관합니다.

프로젝트 규모가 크거나 개인정보가 포함되거나 국경을 넘는다면 반드시 법률 전문가에게 검토를 맡기세요. 준거법에 따라 답이 달라지며, 짧은 검토 비용은 분쟁 비용보다 훨씬 작습니다.