외주 계약서 필수 조항 10가지 — 개발자·클라이언트 공통

외주 계약서 필수 조항 10가지 — 개발자·클라이언트 공통

새로운 프로젝트를 시작하는 설렘은 늘 짜릿합니다. 개발자에게는 새로운 기술 스택을 탐구하고 아이디어를 현실로 구현할 기회이며, 클라이언트에게는 비즈니스를 한 단계 도약시킬 핵심 솔루션을 얻는 과정이죠. 하지만 이 설렘 뒤에는 종종 보이지 않는 그림자가 드리워지곤 합니다. 바로 계약이라는 이름의 그림자입니다.

"설마 문제가 생기겠어?" 하는 안일한 생각이나, "대충 말로 해도 통하겠지" 하는 막연한 신뢰는 종종 예상치 못한 분쟁의 씨앗이 됩니다. 프로젝트가 순항할 때는 문제가 없지만, 작은 오해나 예상치 못한 상황이 발생했을 때, 명확한 계약서는 개발자와 클라이언트 양쪽 모두를 보호하는 최후의 보루가 됩니다. 오히려 잘 작성된 계약서는 불신을 조장하는 것이 아니라, 서로의 역할을 명확히 하고 신뢰를 쌓는 기반이 됩니다.

오늘 코드픽에서는 개발자와 클라이언트 모두가 반드시 알아야 할 외주 계약서의 필수 조항 10가지를 실제 사례를 중심으로 자세히 살펴보겠습니다. 이 글을 통해 여러분의 소중한 프로젝트가 법적 문제없이 성공적으로 마무리되기를 바랍니다.

1. 계약 당사자 및 프로젝트 범위의 명확화

외주 계약의 가장 기본 중 기본이지만, 의외로 간과하기 쉬운 부분입니다. "누가 누구와 무엇을 하는가?"에 대한 명확한 정의가 없다면 모든 후속 조항은 흔들릴 수밖에 없습니다.

누가 계약 당사자인가?

계약 당사자는 개인인지, 법인인지, 그리고 그 법인의 대표자는 누구인지 정확히 명시해야 합니다.
실사례: 김 개발자는 한 클라이언트와 웹사이트 개발 계약을 맺었습니다. 그런데 알고 보니 클라이언트는 법인이 아니라 개인 사업자였고, 계약서에는 대표자의 이름만 명시되어 있었습니다. 나중에 프로젝트가 지연되자 클라이언트가 책임을 회피하며 "개인적인 일"이라고 주장하는 황당한 상황이 발생했습니다. 만약 법인이었다면 법적 책임 소재가 더 명확했을 것입니다. 이처럼 계약 당사자를 정확히 명시하는 것은 책임의 주체를 분명히 하는 첫걸음입니다.

프로젝트의 범위는 어디까지인가? (Scope of Work)

가장 많은 분쟁이 발생하는 지점 중 하나입니다. "개발"이라는 두루뭉술한 표현 대신, 어떤 기능이 포함되고 어떤 기능은 제외되는지, 어떤 기술 스택을 사용하는지, 어떤 결과물을 언제까지 제공할 것인지 구체적으로 명시해야 합니다.

실사례: 한 스타트업 클라이언트는 "모바일 앱 개발"을 의뢰했습니다. 개발사는 계약서에 명시된 기능들을 모두 구현하여 납품했습니다. 그러나 클라이언트는 "당연히 포함될 줄 알았던 푸시 알림 기능이 없다"며 추가 개발을 요구했고, 개발사는 이는 계약 범위 밖의 일이라며 추가 비용을 요청했습니다. 결국 양측은 몇 달간 분쟁을 겪었고, 프로젝트는 지연되고 관계는 악화되었습니다.
이러한 상황을 방지하기 위해, 계약서에는 기능 목록(Feature List), 사용자 스토리(User Story), 와이어프레임(Wireframe), 기술 스택(Tech Stack) 등 구체적인 명세서를 첨부하여 프로젝트의 범위를 명확히 해야 합니다. "A라는 기능을 개발한다"가 아니라 "사용자가 회원가입 후 로그인하여 게시글을 작성하고 댓글을 달 수 있는 기능을 구현한다"와 같이 상세하게 기술해야 합니다.

2. 용역 대금 및 지급 조건

돈 문제는 언제나 민감합니다. 외주 계약에서 대금 지급 조건은 개발자의 생계와 클라이언트의 예산 집행에 직접적인 영향을 미치므로, 그 어떤 조항보다 명확해야 합니다.

대금의 총액 및 산정 방식

총 개발 비용이 얼마인지, 그리고 이 비용이 어떤 기준으로 산정되었는지 (예: 인건비, 솔루션 비용, 라이선스 비용 등) 명확히 명시해야 합니다. VAT 포함 여부도 중요합니다.

지급 방식 및 일정

일시불인지, 분할 지급인지, 분할 지급이라면 어떤 마일스톤에 따라 얼마를 지급할 것인지 구체적인 일정을 명시해야 합니다. 예를 들어, 계약금 20%, 중도금 (기획 완료 시) 30%, 중도금 (개발 50% 완료 시) 30%, 잔금 (최종 검수 완료 시) 20% 와 같이 명확히 해야 합니다.

지연 이자 및 페널티

만약 클라이언트가 약속된 기한 내에 대금을 지급하지 못할 경우, 지연 이자율을 명시하여 개발자의 손실을 보전하고 클라이언트의 책임감을 높일 수 있습니다. 반대로 개발자가 약속된 결과물을 제공하지 못할 경우의 페널티도 고려할 수 있습니다.

실사례: 한 프리랜서 개발자는 클라이언트와 앱 개발 계약을 맺었습니다. 계약서에는 "개발 완료 후 일시불 지급"이라고만 명시되어 있었습니다. 개발은 순조롭게 진행되었고, 앱은 예정대로 완성되었습니다. 하지만 클라이언트는 "사업 자금 조달이 늦어지고 있다"며 대금 지급을 계속 미뤘습니다. 결국 개발자는 몇 달간 대금을 받지 못해 생활고에 시달렸고, 내용증명을 보내고 나서야 겨우 일부를 받을 수 있었습니다.
이러한 상황을 막기 위해, 마일스톤별 지급 방식을 채택하고, 각 마일스톤의 완료 기준을 명확히 하는 것이 중요합니다.

{
  "clause_number": 2,
  "clause_title": "용역 대금 및 지급 조건",
  "details": {
    "total_amount": "50,000,000 KRW (VAT 별도)",
    "payment_schedule": [
      {"milestone": "계약금", "percentage": "20%", "amount": "10,000,000 KRW", "due_date": "계약 체결일로부터 7일 이내"},
      {"milestone": "중도금 (개발 50% 완료)", "percentage": "40%", "amount": "20,000,000 KRW", "due_date": "2024년 10월 30일"},
      {"milestone": "잔금 (최종 완료 및 검수)", "percentage": "40%", "amount": "20,000,000 KRW", "due_date": "최종 검수 완료일로부터 7일 이내"}
    ],
    "late_payment_penalty": "약정된 지급 기한으로부터 7일 초과 시, 미지급 금액에 대해 연 12%의 지연 이자 부과"
  }
}

위 JSON 스니펫처럼 구체적인 조건을 명시하면 오해의 소지를 줄일 수 있습니다.

3. 개발 기간 및 완료 기준

시간은 돈과 직결됩니다. 프로젝트의 시작과 끝, 그리고 그 사이의 중요한 지점들을 명확히 정의하는 것은 양측의 기대를 일치시키고 효율적인 진행을 돕습니다.

개발 기간 명시

프로젝트의 시작일과 예상 완료일을 명확히 기재해야 합니다. 단순히 "3개월 소요"가 아니라 "2024년 9월 1일부터 2024년 11월 30일까지"와 같이 구체적인 날짜를 명시하는 것이 좋습니다.

마일스톤 및 중간 보고

장기 프로젝트의 경우, 주요 마일스톤(예: 기획 완료, 디자인 완료, 프론트엔드 개발 완료, 백엔드 개발 완료 등)을 설정하고, 각 마일스톤별 예상 완료일과 중간 보고 일정을 명시하여 진행 상황을 공유하고 피드백을 주고받는 과정을 공식화해야 합니다.

완료 기준 및 검수 절차

"개발 완료"란 무엇을 의미하는지 구체적으로 정의해야 합니다. 단순히 코드를 넘겨주는 것인지, 아니면 QA를 거쳐 특정 버그율 이하를 달성하는 것인지, 클라이언트의 최종 승인을 받는 것인지 등을 명확히 해야 합니다. 또한, 클라이언트의 검수 기간과 검수 방식(예: 테스트 서버에서 직접 확인)도 명시해야 합니다.

실사례: 한 개발팀은 클라이언트에게 약속한 기간 내에 웹 서비스를 납품했습니다. 그러나 클라이언트는 "기능은 작동하지만, 디자인이 마음에 들지 않고, 몇몇 사소한 버그가 있다"며 최종 완료를 인정하지 않았습니다. 계약서에 "클라이언트의 최종 승인 시 완료"라고만 되어 있었고, 구체적인 완료 기준이나 검수 절차가 없었기 때문에 양측은 서로 다른 기대를 가지고 있었습니다. 결국, 디자인 수정과 버그 해결로 인해 프로젝트는 한 달 이상 지연되었고, 이는 개발팀의 다음 프로젝트 일정에도 영향을 미쳤습니다.
이런 상황을 피하기 위해, "최종 결과물은 요구사항 명세서에 명시된 모든 기능을 구현하고, 중요도 상의 버그가 없으며, 클라이언트가 7일 이내에 서면으로 승인하는 경우 완료된 것으로 간주한다"와 같이 구체적인 완료 기준을 설정하는 것이 중요합니다.

4. 지식재산권 및 저작권

개발 결과물의 소유권은 외주 계약에서 가장 복잡하고 중요한 쟁점 중 하나입니다. 누가 코드의 주인인지, 어떤 권리를 가지는지 명확히 해야 합니다.

결과물의 소유권

일반적으로 외주 개발의 경우, 개발된 소프트웨어의 저작권은 개발자에게 있지만, 클라이언트가 대금을 지급하면 해당 저작권을 클라이언트에게 양도하거나 독점적 사용권을 부여하는 형태로 계약이 이루어집니다. 계약서에는 개발 완료 및 대금 지급 완료 시, 개발 결과물에 대한 저작재산권은 클라이언트에게 양도된다는 조항을 명확히 명시해야 합니다.

개발자의 포트폴리오 활용 여부

개발자는 자신이 개발한 결과물을 포트폴리오로 사용하고 싶어 하는 경우가 많습니다. 클라이언트의 동의 없이 사용했다가 문제가 될 수 있으므로, 계약서에 포트폴리오 사용 가능 여부 및 범위(예: 스크린샷만 공개, 특정 기능만 설명 등)를 명시하는 것이 좋습니다.

제3자 저작물 사용

오픈소스 라이브러리, 유료 폰트, 스톡 이미지 등 제3자의 저작물을 사용할 경우, 해당 저작물의 라이선스 정책을 준수하고, 필요한 경우 라이선스 비용 부담 주체를 명확히 해야 합니다.

실사례: 한 중소기업은 외주 개발사를 통해 ERP 시스템을 구축했습니다. 몇 년 후, 시스템에 중대한 보안 취약점이 발견되어 다른 개발사에 유지보수를 의뢰했습니다. 그런데 새로운 개발사가 코드 분석 중, 기존 개발사가 허락 없이 유료 상용 라이브러리를 사용했음을 발견했습니다. 결국 클라이언트는 라이선스 위반으로 인한 법적 문제와 추가 비용을 떠안게 되었습니다.
이러한 문제를 방지하기 위해, 개발자는 계약서에 "개발 결과물에 포함된 모든 제3자 저작물은 합법적인 라이선스를 보유하며, 그 책임은 개발자에게 있다"는 조항을 명시해야 합니다. 클라이언트 역시 "제3자 저작물 사용 시, 반드시 라이선스 정보를 공유하고 클라이언트의 승인을 받는다"는 조항을 추가하여 위험을 최소화해야 합니다.

5. 수정 및 추가 개발 (Scope Creep 방지)

"이것도 해주세요", "저것도 넣어주세요"는 외주 프로젝트에서 가장 흔하게 발생하는 문제입니다. 명확한 계약이 없다면 스콥 크립(Scope Creep)으로 인해 프로젝트는 산으로 가고, 개발자는 번아웃에 시달리며, 클라이언트는 예상치 못한 비용에 직면하게 됩니다.

변경 요청 절차

계약 범위 외의 수정이나 추가 개발 요청이 발생했을 때, 이를 어떻게 처리할 것인지 명확한 절차를 명시해야 합니다. 예를 들어, 모든 변경 요청은 서면으로 이루어져야 하며, 개발자는 요청 내용을 검토 후 변경에 따른 추가 비용 및 개발 기간을 산정하여 클라이언트에게 제안한다. 클라이언트가 이를 승인하면, 별도의 변경 계약 또는 추가 계약을 체결한다와 같이 구체적으로 명시해야 합니다.

추가 비용 및 기간 산정

변경 요청에 따른 추가 비용은 어떻게 산정할 것인지 (예: 투입 공수 기준, 기능 단위 기준)와 추가 기간은 얼마인지도 명시해야 합니다.

실사례: 한 웹 에이전시는 클라이언트의 요청으로 쇼핑몰 웹사이트를 개발 중이었습니다. 계약서에는 "기능 구현 완료 후 2회에 걸쳐 디자인 수정 가능"이라고만 명시되어 있었습니다. 그런데 클라이언트는 개발 중간중간 수시로 새로운 기능을 추가해달라고 요청했고, 개발팀은 "고객 만족"이라는 명분으로 이를 수용했습니다. 결국 프로젝트는 2배 이상 지연되었고, 개발팀은 초기 견적보다 훨씬 많은 공수를 투입하고도 추가 비용을 받지 못해 큰 손실을 입었습니다.
이처럼 모호한 계약은 개발사에게는 손해를, 클라이언트에게는 무리한 요구를 할 수 있다는 착각을 심어줄 수 있습니다. 명확한 변경 요청 절차는 양측 모두에게 합리적인 의사결정을 유도합니다.

6. 유지보수 및 하자보수

프로젝트가 완료되었다고 해서 모든 것이 끝나는 것은 아닙니다. 개발된 시스템은 지속적인 관리가 필요하며, 예상치 못한 오류가 발생할 수도 있습니다.

하자보수(Bug Fix) 기간 및 범위

개발 완료 후 일정 기간(예: 3개월 또는 6개월) 동안 발생하는 버그에 대한 무상 보수 기간을 명시합니다. 이때 버그의 정의를 명확히 하는 것이 중요합니다. (예: 요구사항 명세서와 다르게 작동하는 기능 오류, 서비스 운영에 치명적인 오류 등). 단순 기능 개선이나 추가 개발은 하자보수 범위에 포함되지 않음을 명시해야 합니다.

유지보수(Maintenance) 계약

하자보수 기간이 끝난 후에는 별도의 유상 유지보수 계약을 통해 서비스를 관리할 수 있습니다. 유지보수 계약에는 월별/연간 비용, 서비스 범위(예: 서버 관리, 백업, 보안 업데이트, 정기 점검, 기술 지원 등), 응답 시간(SLA) 등을 구체적으로 명시합니다.

실사례: 한 스타트업은 외주 개발사에게 자사 핵심 서비스를 맡겨 개발했습니다. 계약서에는 "개발 완료 후 3개월간 무상 하자보수"라고만 되어 있었습니다. 2개월 후, 서비스 이용자가 급증하면서 예상치 못한 서버 부하 문제가 발생했습니다. 개발사는 이는 버그가 아니라 운영상의 문제라며 유상 지원을 요구했고, 클라이언트는 무상 하자보수 기간이라며 개발사의 지원을 기대했습니다. 결국 양측은 공방을 벌였고, 서비스 장애는 장기화되었습니다.
이러한 상황을 방지하기 위해, 하자보수의 범위와 유지보수의 범위를 명확히 구분하고, 각 서비스에 대한 비용과 조건을 상세히 계약서에 포함해야 합니다.

7. 비밀유지 의무 (NDA)

클라이언트는 아이디어, 사업 계획, 고객 정보 등 민감한 정보를 개발자에게 공개해야 할 때가 많습니다. 개발자 또한 프로젝트 진행 중 알게 된 클라이언트의 기밀 정보를 보호할 의무가 있습니다. NDA(Non-Disclosure Agreement)는 이러한 정보 유출을 방지합니다.

비밀 정보의 정의

어떤 정보가 비밀 정보에 해당하는지 구체적으로 정의해야 합니다. (예: 기술 정보, 사업 계획, 재무 정보, 고객 정보, 마케팅 전략, 계약 내용 등)

비밀유지 의무 기간

계약 기간 동안은 물론, 계약 종료 후에도 일정 기간(예: 3년 또는 5년) 동안 비밀유지 의무가 지속됨을 명시해야 합니다.

위반 시 책임

비밀유지 의무를 위반했을 경우 발생할 수 있는 손해배상 책임 등을 명시하여 경각심을 주어야 합니다.

실사례: 한 개발자는 클라이언트의 의뢰로 경쟁사에는 없는 혁신적인 서비스를 개발하고 있었습니다. 계약서에 비밀유지 조항이 있었지만, 개발자는 친한 동료 개발자에게 프로젝트 내용을 자랑하듯 이야기했습니다. 이 정보가 결국 경쟁사로 흘러 들어가 유사한 서비스가 먼저 출시되었고, 클라이언트는 막대한 사업적 손실을 입었습니다. 결국 클라이언트는 개발자에게 손해배상 청구를 진행했습니다.
NDA는 단순히 형식적인 조항이 아니라, 클라이언트의 사업 아이디어를 보호하고 개발자의 직업윤리를 지키는 중요한 장치입니다. 특히 스타트업의 경우 핵심 아이디어가 유출되면 사업 자체가 흔들릴 수 있으므로, NDA는 필수적입니다.

8. 계약 해지 및 손해배상

모든 프로젝트가 순조롭게 흘러가지는 않습니다. 때로는 계약을 중도에 해지해야 하는 상황이 발생할 수도 있습니다. 이 경우, 어떻게 책임을 지고 손해를 배상할 것인지 미리 정해두어야 합니다.

계약 해지 사유

어떤 경우에 계약을 해지할 수 있는지 구체적으로 명시해야 합니다. (예: 상대방의 중대한 계약 위반, 파산, 회생 절차 개시, 프로젝트 진행 불가능 등)

해지 절차

계약 해지를 통보하는 절차(예: 서면 통보 후 일정 기간 내 시정 기회 부여)를 명시해야 합니다.

손해배상

계약 해지로 인해 발생한 손해에 대한 배상 책임을 명시합니다. 이때 위약금 또는 위약벌 조항을 포함하여 계약 위반에 대한 책임을 강화할 수 있습니다. 예를 들어, "클라이언트의 귀책사유로 계약이 해지될 경우, 개발자는 이미 수행한 용역에 대한 대금과 더불어 총 계약 금액의 20%를 위약금으로 청구할 수 있다"와 같이 명시할 수 있습니다.

실사례: 한 클라이언트는 외주 개발사에게 모바일 앱 개발을 의뢰했으나, 내부 사정으로 인해 프로젝트 중간에 계약 해지를 통보했습니다. 계약서에는 해지 시점에 대한 조항이 없었고, 개발사는 이미 상당 부분 개발을 진행한 상태였습니다. 개발사는 "일방적인 해지이므로 개발된 부분에 대한 대금과 위약금을 지급해야 한다"고 주장했지만, 클라이언트는 "아직 완성되지 않았으니 지급할 수 없다"고 맞섰습니다. 결국 법적 분쟁으로 이어져 양측 모두 시간과 비용을 낭비했습니다.
이러한 분쟁을 피하기 위해, 계약서에 계약 해지 시점의 진행률에 따른 대금 정산 방식, 위약금 조항 등을 명확히 포함해야 합니다.

9. 분쟁 해결

아무리 완벽한 계약서를 작성해도 분쟁의 가능성을 0%로 만들 수는 없습니다. 분쟁이 발생했을 때, 어떻게 해결할 것인지에 대한 합의된 절차가 있다면 불필요한 소모전을 줄일 수 있습니다.

협의에 의한 해결

가장 먼저 양 당사자가 성실하게 협의하여 해결하도록 노력한다는 조항을 명시합니다.

조정 및 중재

협의가 불가능할 경우, 대한상사중재원과 같은 공신력 있는 기관의 조정 또는 중재를 통해 해결한다는 조항을 포함할 수 있습니다. 중재는 법원의 판결과 동일한 효력을 가지면서도, 소송보다 빠르고 비공개적으로 진행될 수 있다는 장점이 있습니다.

관할 법원

최종적으로 소송으로 이어질 경우, 어느 법원을 관할 법원으로 할 것인지 명시합니다. (예: "본 계약과 관련하여 발생한 분쟁에 대한 소송은 서울중앙지방법원을 전속 관할 법원으로 한다.") 이는 양측 중 한쪽이 불필요하게 먼 지역의 법원에 출석해야 하는 불편함을 막아줍니다.

실사례: 한 개발사와 클라이언트는 프로젝트 진행 중 사소한 의견 차이로 갈등을 겪기 시작했고, 결국 서로를 비난하며 감정 싸움으로 번졌습니다. 계약서에는 분쟁 해결 조항이 없었기 때문에, 양측은 각자의 변호사를 선임하여 법적 대응을 준비했습니다. 만약 계약서에 "협의를 통해 해결하고, 불가능할 경우 중재를 거친다"는 조항이 있었다면, 불필요한 법적 비용과 시간을 절약하고 원만하게 해결할 수 있었을 것입니다.
분쟁 해결 조항은 단순히 법적 절차를 정하는 것을 넘어, 양측이 합리적인 방식으로 문제를 해결하도록 유도하는 역할을 합니다.

10. 불가항력 (Force Majeure)

예측 불가능한 재난이나 사건으로 인해 계약 이행이 불가능해지는 경우를 대비하는 조항입니다. 이는 개발자와 클라이언트 모두에게 예상치 못한 위험으로부터 보호받을 수 있는 안전장치입니다.

불가항력의 정의

어떤 상황을 불가항력으로 볼 것인지 구체적으로 명시합니다. (예: 천재지변, 전쟁, 폭동, 정부의 규제, 전염병 확산 등으로 인해 계약 이행이 불가능해진 경우)

책임 면제

불가항력으로 인해 계약 이행이 지연되거나 불가능해진 경우, 해당 기간 동안 계약 위반에 대한 책임을 면제한다는 조항을 포함합니다.

통보 의무 및 조치

불가항력 사유가 발생했을 때, 해당 사실을 상대방에게 즉시 통보하고, 사태 해결을 위해 최선을 다해야 한다는 의무를 명시합니다.

실사례: 한 개발사는 해외 클라이언트와 대규모 프로젝트를 진행 중이었습니다. 그런데 갑작스러운 글로벌 팬데믹으로 인해 개발팀의 핵심 인력이 감염되어 개발이 중단될 위기에 처했습니다. 계약서에 불가항력 조항이 명시되어 있었기 때문에, 개발사는 클라이언트에게 상황을 통보하고 불가피한 개발 지연에 대한 책임을 면제받을 수 있었습니다. 클라이언트 역시 이 조항 덕분에 계약 위반에 대한 무리한 요구 대신, 상황을 이해하고 유연하게 대처할 수 있었습니다.
불가항력 조항은 양측이 통제할 수 없는 외부 요인으로 인한 피해를 최소화하고, 상호 이해를 바탕으로 유연하게 대처할 수 있는 기반을 마련해 줍니다.

외주 계약서 필수 조항 체크리스트

FAQ (자주 묻는 질문)

Q1: 외주 계약서 작성 시 가장 중요한 점은 무엇인가요?

A1: 외주 계약서 작성 시 가장 중요한 점은 명확성입니다. 프로젝트의 범위(Scope), 용역 대금 및 지급 조건, 그리고 지식재산권의 귀속을 모호함 없이 구체적으로 명시하는 것이 핵심입니다. 양측이 서로 다른 기대를 가지지 않도록, 모든 조항을 명확하고 상세하게 작성하여 잠재적인 오해와 분쟁의 소지를 최소화해야 합니다.

Q2: NDA(비밀유지 협약)는 모든 외주 계약에 필수적인가요?

A2: 모든 외주 계약에 필수는 아니지만, 민감한 정보(예: 미출시 아이디어, 영업 비밀, 고객 데이터 등)를 다루는 프로젝트라면 NDA는 필수적입니다. 그렇지 않더라도 프로젝트의 세부 내용이나 클라이언트의 내부 정보를 알게 될 가능성이 있다면, 개발자와 클라이언트 양쪽 모두의 이