핵심 답변
코드를 작성한 사람이 곧바로 귀사의 사업에 있어 코드의 소유자가 되는 것은 아닙니다. 태국 법에는 기본 규칙이 있으며, 개발자가 귀사의 직원인지 외부 도급인인지에 따라 달라집니다. 또한 이 규칙은 실제로 귀사를 위해 창작된 코드의 범위에서 멈춥니다.
규칙(불기 2537년 저작권법). 컴퓨터 프로그램은 어문저작물로서 보호됩니다(제4조). 개발자가 직원인 경우 제9조에 따라 서면 합의로 달리 정하지 않는 한 저작권은 직원에게 귀속되고, 사용자는 고용의 목적을 위하여 해당 저작물을 공표할 수 있습니다. 개발자가 위탁을 받은 경우 제10조에 따라 창작자와 위탁자가 달리 합의하지 않는 한 위탁자가 저작권을 가집니다. 양도는 서면으로 하여야 하며 양측이 서명하여야 합니다(제17조).
저희의 실무적 견해. 기본 규칙에 의존하지 마십시오. 누가 무엇을 소유하는지 명시한 서면 계약을 사용하고, 코드를 서면으로 귀사에 양도하며, 개발자가 보유할 수 있는 것(개발자의 도구와 기존 코드)을 열거하고, 대금 지급을 테스트를 거친 마일스톤에 연결하십시오. 제8항의 계약 조항 체크리스트는 변호사에게 그대로 전달하실 수 있는 부분입니다.
1. 태국에서 소스코드는 저작권으로 보호되나요?
네. 제4조는 "어문저작물"에 컴퓨터 프로그램이 포함된다고 정의하고, 컴퓨터 프로그램을 프로그래밍 언어를 불문하고 컴퓨터를 작동시키거나 결과를 얻기 위하여 사용되는 명령, 명령의 집합 또는 그 밖의 것으로 정의합니다. 제15조는 저작권자에게 저작물을 복제하거나 각색하고, 공중에게 전달하고, 프로그램의 원본이나 복제물을 대여하며, 저작권으로부터 이익을 얻고, 타인에게 이용을 허락할 배타적 권리를 부여합니다.
제4조는 또한 프로그램의 실질적인 부분을 새로운 저작물이 되지 않는 형태로 수정하는 것을 "각색"으로 취급합니다. 따라서 나중에 두 번째 개발자를 고용하여 첫 번째 개발자의 코드를 변경하게 하려면, 저작권을 소유하거나 수정을 포함하는 이용허락을 받는 방법으로 각색할 권리를 가지고 있어야 합니다.
2. 개발자를 고용하면 코드는 누구의 것인가요?
양자의 관계에 따라 다릅니다.
| 관계 | 기본 규칙 | 실무상 의미 |
|---|---|---|
| 직원(근로계약) | 제9조: 서면으로 달리 합의하지 않는 한 저작권은 창작자(직원)에게 귀속. 사용자는 고용상 필요한 범위에서 저작물을 공표할 수 있음. | 회사는 직무와 연결된 이용권을 가지지만 반드시 소유권을 가지는 것은 아님. 근로계약서에 소유권 조항을 추가할 것. |
| 도급인 또는 에이전시(도급) | 제10조: 창작자와 위탁자가 달리 합의하지 않는 한 위탁자가 저작권을 가짐. | 유리한 기본 규칙이지만, 위탁에 따라 창작된 저작물에만 해당함. |
| 계약 없이 비공식적으로 일하는 프리랜서 | 실무상 불분명함. 고용인지, 도급인지, 다른 관계인지는 사실관계로 결정됨. | 피할 것. 작업 시작 전에 계약을 체결할 것. |
도급인의 경우 계약은 도급으로 분류될 수 있으며, 민상법전 제587조는 도급을 수급인이 일정한 일을 완성하기로 하고 위탁자가 그 결과에 대하여 보수를 지급하기로 하는 계약으로 정의합니다. 범위가 확정된 소프트웨어 구축은 보통 이 유형에 해당합니다. 리테이너 계약, 인력 파견형 개발, 지속적인 유지보수 지원은 고용이나 용역 관계에 더 가까워 보일 수 있으며, 그래서 계약서에 붙인 명칭만으로는 이 문제가 결정되지 않습니다.
3. 그래도 서면 양도가 필요한 이유는 무엇인가요?
네 가지 이유가 있습니다.
- 기본 규칙에는 빈틈이 있습니다. 제10조는 개발자가 그 위탁을 위하여 창작한 저작물에만 미칩니다. 라이브러리, 프레임워크, 템플릿, 개발자가 귀사의 프로젝트 이전에 작성한 코드는 "귀사를 위해" 창작된 것이 아닙니다.
- 제10조는 변경할 수 있습니다. 에이전시의 표준 약관에 "개발자가 모든 권리를 보유한다"고 되어 있다면, 그것이 법에서 말하는 "달리 합의한" 것입니다.
- 입증. 분쟁이 생기면 "프로젝트에서 창작된 모든 코드, 문서, 디자인은 고객에게 양도된다"는 서명된 조항이 관계의 분류를 둘러싼 논쟁보다 훨씬 쉽게 증명됩니다.
- 제17조. 이용허락이 아니라 양도를 원한다면 서면으로 하여야 하고 양측이 서명하여야 합니다. 기간이 정해져 있지 않으면 법은 10년으로 취급합니다. 영구적인 이전에는 "저작권 보호기간 전체에 걸쳐"와 같은 문구가 필요합니다.
인격권은 별개의 문제입니다. 제18조에 따라 창작자는 서면으로 달리 합의하지 않는 한 저작자임을 주장할 수 있고, 자신의 명예를 해치는 왜곡이나 수정에 이의를 제기할 수 있습니다. 계약서에는 개발자의 크레디트를 어떻게 표기하는지, 그리고 고객이 코드를 수정할 수 있다는 조항이 자주 들어갑니다.
양도인가, 이용허락인가? 영구적이고 독점적이며 철회할 수 없는 이용허락으로 사업상 필요를 충족할 수 있는 경우도 있으며, 개발자가 핵심 플랫폼을 다른 고객들에게도 재사용하는 경우에 흔합니다. 이용허락을 선택한다면 독점적인지, 수정, 재이용허락, 제3자를 통한 호스팅이 가능한지, 사업 양도 시 이전할 수 있는지를 명시하십시오. 상호와 로고에 관한 유사한 문제는 저희 가이드 회사 설립 시 브랜드와 상표의 소유권에서 다룹니다.
4. 저장소와 접근 권한은 어떻게 해야 하나요?
유일한 사본을 개발자가 가지고 있다면 코드의 소유권은 큰 의미가 없습니다. 실질적인 통제권을 계약으로 확보하십시오.
- 저장소는 귀사가 소유하는 계정(조직 수준)에 두고, 개발자는 기여자로 초대합니다.
- 클라우드 계정, 도메인 이름, 앱스토어 등록, API 키, 인증서는 개인이 아니라 귀사 명의로 등록합니다.
- 개발자가 정기적으로 커밋하여, 대금을 지급한 코드가 마지막에만이 아니라 모든 마일스톤마다 귀사의 저장소에 존재하도록 합니다.
- 자격 증명은 안전한 경로로 인계하고, 인계 시 교체합니다.
- 테스트 및 운영 시스템의 고객 정보나 개인정보는 사전에 합의한 규칙에 따라 처리합니다. 저희의 PDPA 준수 체크리스트와, 공개 AI 도구에 소스코드를 입력하는 문제를 다루는 가이드 회사 AI 정책과 고객 정보를 참고하십시오.
5. 오픈소스와 제3자 구성요소는 어떻게 되나요?
현대의 거의 모든 소프트웨어에는 개발자가 작성하지 않은 구성요소가 포함되어 있습니다. 그 라이선스도 구성요소와 함께 따라옵니다. 실무적으로는 다음과 같습니다.
- 허용형 라이선스는 요구되는 고지를 유지하는 한 일반적으로 상업 제품에서의 사용을 허용합니다.
- 카피레프트 라이선스는 해당 구성요소와 결합하거나 이를 배포하는 소프트웨어에 조건을 붙일 수 있으며, 경우에 따라서는 귀사 자신의 소스코드를 같은 라이선스로 공개하도록 요구할 수 있습니다. 조건은 라이선스에 따라, 그리고 소프트웨어를 어떻게 사용하는지(예를 들어 고객에게 배포하는지, 귀사의 서버에서만 실행하는지)에 따라 다르므로, 구성요소에 의존하기 전에 실제 라이선스를 검토받으십시오.
- 유료 제3자 구성요소(SDK, 글꼴, 템플릿, 결제 또는 지도 API)에는 대개 프로젝트별 또는 사용자별 요금이 있으며 귀사에 자동으로 이전되지 않을 수 있습니다.
계약상의 요점은 다음과 같습니다. 개발자는 모든 제3자 및 오픈소스 구성요소를 해당 라이선스와 함께 목록으로 작성하고(부품 명세서), 인도물의 어떤 부분도 귀사의 독점 코드를 공개하도록 강제하지 않는다고 보증하며, 귀사의 승인 없이 제한적인 라이선스의 구성요소를 추가하지 않습니다. 개발자는 또한 코드를 인도할 권리가 있다는 점과 그것이 타인의 권리를 침해하지 않는다는 점을 보증하여야 합니다. 여기서는 특정 라이선스에 대한 결론을 내리지 않습니다. 관련된 라이선스의 문언을 확인하십시오.
6. 마일스톤과 검수 테스트는 어떻게 운영해야 하나요?
태국 법은 소프트웨어 검수 절차를 정하고 있지 않으므로 계약에서 정하여야 합니다. 이것이 중요한 이유는 민상법전 제598조에 따라 위탁자가 하자가 있는 일의 결과물을 명시적으로 또는 행동으로 이의 없이 수령하면, 인도 시에 발견할 수 없었던 하자이거나 수급인이 하자를 숨긴 경우가 아닌 한, 수급인은 일반적으로 그 하자에 대하여 책임을 지지 않기 때문입니다. 따라서 인도 후의 침묵이 귀사에 불리하게 작용할 수 있습니다. 고정된 검토 기간을 정하고, 테스트를 위하여 운영 환경에서 사용하는 것은 검수가 아니라고 명시하십시오.
가정 사례(예시용 수치). 한 회사가 온라인 주문 시스템을 60만 바트에 위탁합니다. 아래 표는 대금 지급이 테스트를 거친 인도물을 따라가도록 하는 방법을 보여줍니다.
| 마일스톤 | 인도물 | 검수 테스트 | 대금(예시) |
|---|---|---|---|
| 1. 명세서와 설계 | 서면 요구사항, 사용자 흐름, 화면 설계, 기술 계획 | 고객이 서면 범위를 승인하고 미해결 사항이 해소됨 | 20% |
| 2. 핵심 구축 | 테스트 서버에서 동작하는 핵심 기능, 코드는 고객의 저장소에 있음 | 명세서의 테스트 케이스를 통과하고 미해결 치명적 결함이 없음 | 30% |
| 3. 연동과 데이터 | 테스트 계정으로 결제, 알림, 데이터 가져오기가 동작함 | 고객이 합의된 테스트 스크립트를 실행하고 가져온 데이터가 원본 데이터와 대조됨 | 20% |
| 4. 사용자 인수 테스트(UAT) | 스테이징 환경의 전체 시스템, 릴리스 노트 | 고객이 합의된 기간 동안 테스트하고 결함은 심각도별로 분류되며 치명적 또는 주요 결함이 미해결 상태가 아님 | 20% |
| 5. 서비스 개시와 인계 | 운영 환경 배포, 소스코드, 문서, 자격 증명, 교육 | 운영 환경 스모크 테스트, 인계 체크리스트 서명 | 10%(서명 때까지 유보) |
좋은 검수 문구에는 다음이 포함됩니다. 누가, 어떤 환경에서, 어떤 테스트 케이스로 테스트하는지, 검토에 며칠을 쓰는지(예를 들어 7일에서 14일, 프로젝트에 맞게 설정), 결함을 어떻게 분류하는지(치명적, 주요, 경미), 개발자가 언제까지 수정하여야 하는지, 그리고 회신 없이 검토 기간이 지나면 어떻게 되는지입니다. 많은 고객은 침묵을 검수로 간주하지 않기를 선호합니다. 개발자가 간주 검수를 고집한다면 기간을 충분히 테스트할 수 있을 만큼 길게 하십시오.
7. 변경, 하자, 계약의 종료
변경 요청. 범위 확대는 가장 흔한 분쟁입니다. 변경은 작업 시작 전에 서면으로 작성하고, 가격을 정하고, 양측이 서명하도록 요구하며, 일정에 미치는 영향을 명시하십시오. 어떤 요청이 "변경"인지 "하자"인지를 누가 결정하는지도 정하십시오.
하자담보와 하자. 반대되는 약정이 없는 경우 민상법전 제600조는 수급인이 인도 후 1년 이내에 나타난 하자에 대하여 책임을 지도록 합니다(토지 위의 건물은 5년이나 소프트웨어와는 무관합니다). 제601조는 하자가 나타난 때로부터 1년이 지난 후에 제기된 청구를 배제합니다. 이 법은 유형의 일을 염두에 두고 만들어졌으며, 법원이 소프트웨어에 어떻게 적용할지는 변호사에게 물어야 할 문제이므로, 하자담보는 계약으로 정하십시오. 기간, 하자의 정의, 심각도 등급, 대응 및 수정 시간, 그리고 하자담보 기간 이후의 지원을 별도의 유료 플랜으로 할지 여부입니다.
계약의 종료. 제605조에 따라 위탁자는 일이 완성되지 않은 동안 도급계약을 종료할 수 있으며, 이 경우 해제로 인한 수급인의 손해를 배상합니다. 계약서는 이보다 구체적이어야 합니다. 통지 기간, 지금까지 한 작업에 대한 대금, 그리고 중요하게는 프로젝트가 중단되더라도 지금까지 작성된 모든 코드와 문서를 인도한다는 점입니다. 또한 개발자의 위반(마일스톤 지연, 포기)으로 인한 종료와 귀사의 위반(대금 미지급)으로 인한 종료도 정하고, 분쟁 중인 청구서를 지급할지 코드를 잃을지 중에서 선택을 강요당하지 않도록 소유권의 이전을 대금 지급에 연결하십시오.
인계. 완료 또는 종료 시에는 전체 소스코드와 빌드 스크립트, 데이터베이스 스키마, 배포 지침, 환경 및 자격 증명 목록, 오픈소스 부품 명세서, 그리고 짧은 기간의 지식 이전 지원을 인계합니다. 개발자가 저장소나 호스팅을 유지하고 싶어 한다면, 에스크로를 두거나 정기적으로 사본을 귀사에 인도하도록 요구하십시오.
8. 계약 조항 체크리스트
- 당사자, 프로젝트 설명, 그리고 별첨으로 첨부하는 서면 명세서.
- 확정 가격 또는 시간·재료 방식의 규칙, 그리고 검수를 마친 마일스톤에 연결된 대금 지급 일정.
- 소유권: 귀사에 대한 명시적인 서면 양도(제17조), 저작권 전체 기간에 대한 것임을 명시하고 양측이 서명.
- 예외: 개발자의 기존 도구와 코드를 열거하고, 귀사에 영구적이고 철회 불가하며 수정과 호스팅을 포함하는 이용허락을 부여.
- 오픈소스 및 제3자 목록(부품 명세서)과 그 라이선스, 그리고 귀사의 코드에 대한 공개 의무가 없다는 보증.
- 저장소와 계정은 귀사가 소유. 정기적인 커밋. 자격 증명 인계.
- 검수 절차: 테스트 케이스, 환경, 검토 기간, 심각도 등급, 간주 검수 규칙.
- 서면으로 하는 변경 요청 절차, 작업 전에 가격 결정.
- 하자담보 기간, 하자의 정의, 수정 시간, 지원 조건.
- 비밀유지, 개인정보 처리, 보안 의무(위의 PDPA 가이드 참조).
- 인격권과 크레디트: 개발자를 어떻게 표기하는지. 고객은 수정할 수 있음.
- 하도급은 귀사의 승인이 있는 경우에만 하고, 각 하수급인으로부터 동일한 양도를 받음.
- 지연에 대한 구제, 책임 한도, 침해 청구에 대한 면책.
- 해지권, 지금까지 한 작업에 대한 대금, 종료 시 코드 인도(제605조가 기본 규칙으로 적용됨).
- 준거법, 관할, 전자서명 방식. 회사 계약의 전자서명을 참고하십시오.
서면 계약은 구두 계약보다 훨씬 입증하기 쉽습니다. 그 이유는 구두 계약과 그 강제력에서 확인하십시오.
함께 읽으면 좋은 글
- 태국에서 회사를 설립할 때 브랜드와 상표의 소유권
- 태국의 회사 AI 정책과 고객 정보
- 회사 계약의 전자서명
- 태국에서 구두 계약은 강제력이 있나요?
- SaaS 창업자를 위한 BOI: 해외 지식재산권과 태국 내 개발
대금을 지급하기 전에 서면으로 코드를 자기 것으로 만드십시오. 서명된 양도, 회사가 소유하는 저장소, 테스트를 거친 마일스톤에 연결된 대금 지급이 어떤 기본 규칙보다 귀사를 더 잘 보호합니다.
우리는 태국 기업을 위해 소프트웨어 개발 계약, 이용허락 계약, 용역 계약을 작성하고 검토합니다. 최초 상담은 무료입니다 — +66 92 254 2045로 전화하시거나 내용을 보내주십시오. 더 자세한 내용은 계약 및 문서와 법률 자문 계약에서 확인하실 수 있습니다.
이 가이드는 수완와라 법률사무소가 발행했습니다 — 1986년에 설립된 콘깬(Khon Kaen) 주의 법률사무소입니다. 본 내용은 일반적인 정보일 뿐이며, 특정 사안에 대한 법률 자문이 아닙니다.

