프리랜서와 에이전시를 위한 MSA와 SOW 해설: 마스터 계약서와 작업 명세서에 각각 무엇이 들어가는가

고객과의 첫 프로젝트는 두 장짜리 견적서로 잘 끝났습니다. 이제 두 번째 프로젝트가 더 커졌고, 고객은 자신들의 표준 벤더 약관을 참조하는 자체 작업 명세서를 보내옵니다. 그리고 프로젝트 중간쯤에서 결과물이 늦어지고 청구서는 지급되지 않습니다. 당신은 견적서를 가리키고, 고객은 자기네 벤더 약관을 가리킵니다. 과연 어느 쪽 서류가 실제로 효력을 가지는 걸까요? 이 질문에 한 문장으로 답할 수 없다면, 당신의 계약은 이미 관계를 따라가지 못한 것입니다. 해법은 더 긴 견적서가 아니라 두 문서 구조, 즉 마스터 서비스 계약서와 각 프로젝트별 작업 명세서입니다.

이 가이드는 각 문서에 무엇이 들어가는지, 왜 둘을 분리하면 매 프로젝트마다 같은 조항을 다시 협상하지 않아도 되는지, 그리고 이 구조 전체를 무력화하는 실수들을 설명합니다. 시작하기 전에 한 가지 표준적인 주의사항: 이 글은 서비스 계약이 일반적으로 어떻게 작동하는지에 대한 정보이며, 당신의 구체적인 상황에 대한 법률 자문이 아닙니다.

한눈에 보는 두 문서​

마스터 서비스 계약서(MSA)는 같은 고객과의 모든 프로젝트에 걸쳐 변하지 않는 모든 조건을 담습니다: 어떻게 지급받는지, 누가 결과물을 소유하는지, 누가 무엇에 대해 책임지는지, 어느 쪽이든 어떻게 관계를 종료할 수 있는지. 작업 명세서(SOW)는 정확히 하나의 프로젝트를 설명합니다: 무엇을 만들거나 납품할지, 언제까지, 얼마에, 그리고 고객이 어떻게 승인하는지.

MSA를 운영체제, 각 SOW를 그 위에서 실행되는 앱이라고 생각하세요. 세 번째, 네 번째, 다섯 번째 프로젝트가 들어오면 SOW만 협상하면 됩니다 — 이미 확보한 책임 한도, IP 양도, 지급 조건은 그대로 유지됩니다.

마스터 계약서에 들어가는 내용​

MSA의 모든 내용은 이 고객을 위해 앞으로 수행할 모든 프로젝트에 해당되어야 합니다. 프로젝트마다 달라질 조건이라면 대신 SOW에 들어갑니다.

관계의 범위. 역설적이게도, MSA는 보통 프로젝트 범위를 전혀 담지 않습니다 — 향후 작업 명세서에 기술된 서비스를 위해 고객이 당신을 고용할 수 있다는 프레임워크 문장 하나만 있을 뿐입니다. 프로젝트 세부사항을 여기에 붙여넣고 싶은 충동을 참으세요. 프로젝트 구체성이 마스터 계약서에 스며드는 순간, 작업이 바뀔 때마다 마스터 계약서를 수정해야 하는데, 그것이 바로 이 구조가 없애려는 바로 그 수고입니다.

지급 방식. 어떤 프로젝트의 가격이 아니라 지급받는 시스템입니다: 청구서는 며칠 내 지급, 무엇이 연체로 간주되는지, 연체료나 이자율, 경비를 누가 지급하고 어떻게 문서화하는지, 작업 시작 전에 계약금이 필요한지. 연체료는 여기서 한 번 확정하세요 — 일반적인 조항은 미지급 잔액에 대해 월 1.5퍼센트입니다 — 그러면 향후 모든 SOW가 새로 논쟁할 필요 없이 이를 승계합니다.

기밀유지. 각 측의 비공개 정보에 대한 상호 의무, 해지 후 존속 기간, 이미 공개되었거나 독립적으로 개발된 정보에 대한 표준 예외 조항. 프리랜서들은 종종 단독 견적서에서 이를 건너뜁니다. MSA에서는 포함하는 데 비용이 들지 않으며 모든 프로젝트에 걸쳐 양측을 보호합니다.

지식재산권 프레임워크. MSA는 소유권 규칙을 명시합니다 — 일반적으로 완성된 결과물을 고객에게 양도하며, 이상적으로는 전액 지급 시 양도합니다 — 그리고 기존 IP에 대한 예외를 둡니다: 프로젝트 이전에 존재했고 계속 당신의 것으로 남는 프레임워크, 템플릿, 코드 라이브러리, 방법론으로, 결과물에 내장된 형태로만 고객에게 라이선스됩니다. SOW는 그런 다음 각 과제가 어떤 결과물을 포함하는지 식별합니다. 규칙은 마스터 계약서에, 목록은 SOW에 두세요.

보증 및 면책. 서비스를 전문가답게 수행하고 결과물이 타인의 IP를 침해하지 않는다는 짧은 보증과, 정의된 제3자 청구에 대해 각 측이 상대방을 방어할 의무를 지우는 면책 조항이 짝을 이룹니다. 이 조항들은 하도급업체의 차용 코드나 무허가 스톡 사진이 청구서를 촉발하기 전까지는 상투적인 문구처럼 읽힙니다 — 그 시점에 누가 방어 비용을 부담할지 결정합니다.

책임 한도. 최악의 노출을 제한하는 조항으로, 거의 항상 관련 SOW에 따라 지난 12개월 동안 지급된 비용으로 설정되며, 간접 및 결과적 손해에 대한 상호 면제가 함께합니다. MSA에서 이 조항을 한 번 협상하면 모든 프로젝트를 포괄합니다. 여기서 한도 없는 책임 조항을 수용하면 향후 모든 작업에도 수용한 것입니다. 따라서 마스터 수준에서 가장 강력하게 다투어야 할 조건입니다.

기간, 해지, 종료 정리. MSA가 얼마나 지속되는지, 어느 쪽이든 어떻게 해지할 수 있는지(일반적으로 30일 서면 통지), 해지가 진행 중인 SOW를 종료하는지 완료까지 진행시키는지, 그리고 종료 시 어떻게 되는지: 기밀 자료 반환, 해지일까지 수행한 작업에 대한 지급, 전환 지원. 프리랜서에게 가장 가치 있는 한 문장은 중도 해지 수수료입니다: 고객이 프로젝트를 중도 취소하면 해지 시점까지 완료된 작업과 정의된 정리 수수료가 지급됩니다.

우선순위. 서두의 시나리오에 답하는 조항: 문서가 충돌할 때 어느 쪽이 이기는가? 일반적인 순위는 프로젝트별 조건에 대해 SOW를 MSA 위에 두고, 둘 다 발주서나 청구서 세부 약관 위에 둡니다. 이 조항이 없으면 고객의 조달 포털이 모든 발주서마다 당신이 협상한 조건을 조용히 덮어쓸 수 있습니다.

작업 명세서에 들어가는 내용​

MSA가 헌법이라면 SOW는 법률입니다 — 구체적이고, 날짜가 있으며, 일회용입니다. 각 SOW는 하나의 프로젝트에 대한 완전한 설명으로 독립적이어야 하면서, 나머지 모든 사항에 대해서는 MSA를 가리켜야 합니다. 다섯 가지 요소가 거의 모든 무게를 담당합니다.

범위, 그리고 범위 외 목록. 결과물, 마일스톤, 일정, 각 측의 책임을 기술하세요 — 데이터 접근, 영업일 기준 5일 이내 피드백, 단일 의사결정자 등 고객이 당신에게 빚진 것 포함. 그런 다음 거울상을 작성하세요: 포함되지 않는 것의 명시적 목록. 추가 수정 라운드, 구현 지원, 긴급 처리, 합의하지 않은 도구에서의 작업 — 이들을 명시하고, 범위를 벗어난 모든 것은 추가 비용이 있는 서면 변경 주문이 필요하다고 명시하세요. 그 단락이 대부분의 범위 확장을 논쟁에서 청구서로 바꿉니다.

이 프로젝트의 비용. 고정 가격, 시간당 요율과 상한, 또는 리테이너 금액 — 이 SOW의 숫자만, MSA의 지급 시스템 위에 얹혀 있습니다. 각 지급을 달력 날짜나 검증 가능한 이벤트가 있는 마일스톤에 연결하고, 계약금이 환불 불가인지 총액에서 공제되는지 명시하세요. 마일스톤 일정은 이중 역할을 합니다: 현금 흐름을 조절하고, 고객이 피드백을 계속 진행시킬 이유를 제공합니다. 그들의 지연이 자신들의 날짜를 눈에 띄게 밀어내기 때문입니다.

검수 기준. 고객이 각 결과물을 어떻게 승인하는지, 그리고 결정적으로 그들이 침묵하면 어떻게 되는지. 묵시적 승인 조항, 일반적으로 서면 이의 없이 10영업일이 지나면, 고객이 승인을 무기한 지연시키고 최종 마일스톤을 인질로 잡는 것을 막습니다. 검수 기준이 없는 모호한 SOW는 범위 확장의 가장 흔한 원인입니다: "완료"가 정의되지 않으면 모든 것이 여전히 범위 안에 있습니다.

변경 관리. 한 단락짜리 절차: 범위, 일정, 비용의 변경은 서면으로 요청되고, 당신이 가격을 책정하고, 변경된 작업이 시작되기 전에 양측이 서명해야 합니다. 서명된 변경 주문이 없으면 변경된 작업도 없습니다. 이를 일관되게 시행하는 프리랜서들은 대부분의 범위 확장 대화가 시작되기도 전에 끝난다고 보고합니다. 고객이 우회로의 가격을 확정하기 전에 보기 때문입니다.

의존성 및 핵심 인력. 당신의 일정이 고객 입력에 의존한다면, 고객 지연에 대해 일정이 하루씩 연장된다고 명시하세요. 고객이 특정 사람 때문에 당신의 에이전시를 고용한다면, 그들을 명시하고 누군가 이탈하면 어떻게 되는지 명시하세요. 어느 문장이든 상대방의 3주 침묵이 당신의 마감일 미준수로 바뀌는 것을 막습니다.

마일스톤, 지급 조건, 검수: 돈이 서류와 만나는 곳​

SOW의 마일스톤 일정은 단순한 프로젝트 계획이 아니라 — 계약 형태의 수익 예측이며, 당신의 부기는 이를 반영해야 합니다. 각 마일스톤에 정의된 금액과 검수 트리거가 있으면 청구는 기계적이 됩니다: 마일스톤 승인, 청구서 발송, MSA 조건에 따라 지급 시계 시작. 마일스톤이 흐릿하면 청구는 매번 협상이 됩니다.

각 SOW를 장부에서 별도의 수입원으로 추적하세요. 작업 시작 전에 받은 계약금은 아직 수익이 아닙니다 — 그것이 공제된 마일스톤을 납품할 때까지 부채(미실현 수익)입니다. 마일스톤 지급은 날짜가 있는 청구서에 깔끔하게 대응되므로, 매출채권 연령 분석 보고서가 조기 경보 시스템이 됩니다: 한 고객의 SOW가 계속 연체되는데 다른 고객은 제때 지급한다면, 문제는 당신의 청구 프로세스가 아니라 그 고객입니다. 그리고 세금 신고 시기에 SOW별 기록은 어떤 수입이 어느 연도에 속하는지 보여주는 것을 간단하게 만듭니다 — 1년치 은행 입금에서 재구성할 필요 없이. Beancount 문서는 평문 장부가 월말의 허둥대림 없이 이런 프로젝트 수준 추적을 감사 가능하게 유지하는 방법을 보여줍니다.

두 문서에 걸친 IP 소유권​

IP 조건을 MSA와 SOW에 나누는 것은 사람들을 혼란스럽게 하므로, 여기서 역할 분담을 정리합니다. MSA는 소유권 규칙과 예외를 명시합니다: 결과물은 전액 지급 시 고객에게 양도되고, 기존 툴킷은 라이선스 하에 당신의 것으로 남으며, 협상했다면 포트폴리오 권리를 유지합니다. SOW는 규칙이 적용되는 결과물을 식별합니다 — 이 프로젝트가 생산하는 디자인, 코드, 보고서, 콘텐츠.

여기서 프리랜서를 잡는 두 가지 함정이 있습니다. 첫째는 "업무상 저작물" 문구에만 의존하는 것입니다. 미국 저작권법에서 그 원칙은 직원과 특별히 의뢰된 저작물의 좁은 범주만을 포함합니다. 대부분의 프리랜서 결과물은 해당하지 않으며, 법원은 계약서에 업무상 저작물이라고 표시한다고 해서 그렇게 되는 것은 아니라고 반복적으로 판시했습니다. 실제로 소유권을 이전하는 것은 MSA의 서면 양도 조항입니다 — 이를 유지하고, 업무상 저작물 문구는 메커니즘이 아니라 백업으로 취급하세요.

둘째 함정은 하도급업체 공백입니다. 다른 누군가가 작업에 손을 대면, 당신의 하도급 계약이 그들의 작업물을 당신에게로 사슬을 따라 양도해야 합니다. 그렇지 않으면 당신이 법적으로 소유하지 않은 결과물의 소유권을 고객에게 약속하게 되고, MSA의 IP 보증은 발견 날짜를 기다리는 위반이 됩니다.

책임 한도: 한 번 설정하고 모든 프로젝트를 커버​

책임 조건은 다른 어떤 조항보다 MSA 구조에 보상을 줍니다. 협상하기 가장 어렵고 잘못하면 가장 위험하기 때문입니다. 마스터 수준에서 세 가지를 요구하세요.

첫째, 고객이 실제로 지급한 금액에 연동된 한도 — 일반적으로 청구 전 12개월 동안 영향받은 SOW에 따라 지급된 비용. 한 고객을 위해 대량 작업을 한다면 MSA의 모든 비용에 연동된 한도는 피하세요. 그 숫자는 매년 더 큰 목표로 자라납니다. 둘째, 간접, 부수적, 결과적 손해의 상호 배제: 이것이 없으면 늦은 결과물이 이론적으로 고객의 출시 수익 손실에 대해 당신을 책임지게 할 수 있습니다. 셋째, 한도가 적용되지 않는 좁은 예외 — 보통 기밀 위반, IP 침해, 고의적 위법 행위. 그 목록을 짧게 유지하세요. 모든 예외는 보호의 구멍이며, 예외에 "또는 이 계약의 모든 위반"을 추가하는 고객의 수정안은 당신의 한도를 조용히 완전히 삭제한 것입니다.

1인 프리랜서들은 때때로 이 조항들이 대기업용 연극이라고 가정합니다. 그렇지 않습니다. 지급된 비용으로 설정된 책임 한도는 15,000달러 프로젝트에서 최악의 경우가 대략 15,000달러라는 의미입니다 — 고통스럽지만 생존 가능합니다. 한도가 없으면 최악의 경우는 판사가 고객의 손해를 얼마로 보는지입니다. 한도를 한 번 서명하면 그 MSA 아래에서 서명하는 모든 SOW가 이를 승계합니다.

구조 전체를 무력화하는 흔한 실수들​

두 문서 시스템은 문서들이 실제로 연결될 때만 작동합니다. 다음은 가장 자주 나타나는 실패입니다.

MSA를 참조하지 않는 SOW에 서명하기. 마스터 계약서에서 떠다니는 SOW는 또 하나의 단독 견적서일 뿐입니다 — 협상한 보호 조항 중 어느 것도 붙지 않습니다. 모든 SOW는 날짜와 제목으로 MSA를 편입하는 것으로 시작해야 합니다. 한 문장이면 됩니다.

발주서 세부 약관에 지게 놔두기. 많은 고객이 모든 프로젝트를 조달을 통해 처리하고, 발주서는 지급 시기, 책임, IP에 대해 당신의 MSA와 모순되는 약관이 뒷면에 인쇄되어 도착합니다. MSA의 우선순위 조항은 발주서를 마지막 순위로 두어야 하며, SOW와 모순되는 발주서에는 문제를 제기하지 않고 서명해서는 안 됩니다. 발주서는 지급 수단이지 재협상이 아닙니다.

구두 변경 주문. "나중에 정리하자"는 구두 약속으로 수행한 모든 범위 외 호의는 고객이 당신의 변경 관리 조항을 우회하도록 훈련시키고 — 청구서가 도착할 때 서명된 기록이 없게 만듭니다. 변경의 가격을 책정하고, 서명을 받은 다음, 작업하세요. 서명 없으면 작업도 없습니다.

요율 검토 없는 자동 갱신. 해마다 자동 갱신되는 MSA는 편리하지만, SOW 요율이 2023년 이후 동결되어 있는데 비용은 20퍼센트 증가했다는 것을 깨닫기 전까지입니다. 자동 갱신은 연간 요율 검토 창구와 짝을 이루어 가격이 시장과 함께 움직일 수 있게 하세요.

1인 프리랜서로서 대기업 MSA를 복사하기. 기업 MSA는 당신에게 없는 보험 증권, 보안 인증, 법무 부서를 가정합니다. 그대로 서명하면 연간 SOC 2 감사, 99.9퍼센트 가동률 SLA, 또는 일곱 자릿수 보험 보장에 당신을 묶을 수 있습니다. 모든 의무를 당신이 개인적으로 지켜야 할 약속으로 읽고, 당신보다 백 배 큰 벤더를 위해 만들어진 것은 삭제하거나 좁히세요.

아직 MSA가 필요한가?​

모든 프로젝트가 전체 구조를 필요로 하지는 않습니다. 정의된 결과물과 깔끔한 결말이 있는 일회성 프로젝트는 잘 작성된 단독 계약서 하나로 충분합니다 — 다시 만나지 않을지도 모르는 고객을 위해 MSA를 만드는 것은 보상 없는 프로세스 부담입니다.

단일 문서를 졸업할 신호는 같은 고객의 반복 사업, "완료"가 날짜가 아닌 리테이너나 지속 지원 작업, 당신의 프로젝트에 합류하는 하도급업체, 약관이 뒷면에 인쇄된 채 도착하는 조달 서류입니다. 에이전시는 이 신호를 빠르게, 종종 첫 다중 프로젝트 고객과 함께 맞닥뜨립니다. 1인 프리랜서는 보통 좋은 고객과의 두 번째나 세 번째 프로젝트쯤에서 맞닥뜨리는데 — 이때가 MSA를 제안하기 가장 쉬운 시점입니다. 양측이 이미 관계를 계속하고 싶어 하니까요. 확대가 아니라 효율성으로 프레이밍하세요: "상시 조건을 한 곳에 모아서 향후 프로젝트에는 짧은 SOW만 필요하게 합시다."

계약서만큼 프로젝트 재정도 정리하세요​

MSA와 프로젝트별 SOW는 모든 프로젝트에 정의된 범위, 마일스톤 일정, 문서 기록을 제공합니다 — 이것이 바로 좋은 부기가 작동하는 원재료입니다. 각 SOW가 자체 수입원에 대응하고, 계약금이 수익으로 실현될 때까지 미실현 수익에 있고, 마일스톤 청구서가 매출채권에서 눈에 띄게 연령이 매겨지면, 장부는 하나의 뒤섞인 흐림이 아니라 고객별 수익성을 알려줍니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 제공하는 평문 회계를 제공합니다 — 블랙박스도, 벤더 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 평문 회계로 전환하는 이유를 확인하세요.