표준 계약서 체계. 말을 문서로, 문서를 약속으로

개정 상태: 이 장과 뒤의 계약 1~15는 이전 조직 구상에 따른 참고 초안입니다. 설립 전 조합이나 연구소를 계약 당사자로 바꾸어 바로 서명하지 마세요. 회원 자격·노무·세무·지식재산·개인정보·배분 조항은 실제 당사자와 거래에 맞춰 별도 법률 검토가 필요합니다.

핸드북은 우리가 어떻게 일하겠다는 말입니다. 계약서는 그 말을 지키게 만드는 도구입니다. 이 장은 어떤 단계에 어떤 계약서가 필요하고, 그 계약서들이 서로 어떻게 연결되는지를 설계합니다.

왜 계약서가 필요한가

《함께 만드는 힘》은 스물아홉 개 장에 걸쳐 우리가 사람을 어떻게 대하고, 어떻게 함께 일하고, 어떻게 나눌 것인가를 말했습니다. 그러나 말은 기억에 의존하고, 기억은 이해관계 앞에서 흔들립니다. 3천만원짜리 프로젝트가 끝나고 정산할 때, 고객이 수행자에게 직접 다음 일을 제안할 때, 참여자 한 사람이 중간에 떠날 때, 우리는 핸드북의 어느 장을 펴서 읽어 주는 것으로 문제를 풀 수 없습니다. 그 순간 필요한 것은 모두가 미리 서명한 문서입니다.

계약서는 불신의 표시가 아닙니다. 오히려 그 반대입니다. 신뢰는 말이 아니라 행동으로 쌓이고, 행동은 기준이 있어야 평가할 수 있습니다. 계약서는 그 기준을 미리 적어 두는 일입니다. 좋은 계약서가 있으면 좋은 사람들이 오해로 갈라서는 일이 줄어듭니다. 나쁜 의도를 가진 사람은 계약서 앞에서 멈추고, 좋은 의도를 가진 사람은 계약서 덕분에 안심하고 더 큰 일을 맡습니다.

다만 하나의 계약서로 모든 것을 담을 수는 없습니다. 입회할 때 서명하는 문서와 1억원 프로젝트를 시작할 때 서명하는 문서는 당사자도, 시점도, 다루는 위험도 다릅니다. 모든 것을 한 문서에 넣으면 아무도 읽지 않는 문서가 됩니다. 그래서 우리는 단계별로 나뉜 표준 계약서 세트를 만들고, 그 문서들이 서로를 참조하며 하나의 체계로 작동하게 설계합니다.

설계 원리

계층 구조

계약서는 네 층으로 쌓입니다. 아래층은 위층을 편입하고, 위층과 충돌할 수 없습니다.

┌──────────────────────────────────────────────────────┐
│ 1층  헌장 (Appendix A)          — 가치와 원칙. 개정은 Council │
├──────────────────────────────────────────────────────┤
│ 2층  회원 규약 (계약 1·2·3)      — 모든 회원이 입회 시 서명     │
├──────────────────────────────────────────────────────┤
│ 3층  프로젝트 협약 (계약 4~9)    — 기회·셀·고객·정산의 뼈대     │
├──────────────────────────────────────────────────────┤
│ 4층  개별 약정 (계약 10~15)      — 자산·자원·이탈·종료·전환·분쟁 │
└──────────────────────────────────────────────────────┘
         ↓ 숫자 기본값은 Project Charter(Appendix B)로 조정

충돌이 생기면 헌장, 회원 규약, Project Cell 협약, 개별 약정, Project Charter의 조정값 순서로 우선합니다. 예외는 하나입니다. 계약서가 "Charter로 조정 가능"이라고 표시한 숫자는 Charter에 적힌 값이 우선합니다. 이렇게 하면 원칙은 위에서 지키고, 숫자는 아래에서 프로젝트마다 맞출 수 있습니다.

고정 조항과 조정 조항

모든 조항은 두 종류로 표시됩니다.

고정 조항이 있는 이유는 협상력의 차이 때문입니다. 경험 많은 Project Lead와 첫 프로젝트에 참여한 신규회원이 마주 앉으면 조항은 한쪽으로 기울기 쉽습니다. 고정 조항은 협상 테이블에 올라오지 않기 때문에, 힘이 약한 쪽을 보호합니다. 사람을 소모품처럼 다루지 않는다는 약속은 조항으로 고정될 때 비로소 약속이 됩니다.

읽히는 계약

우리 계약서의 각 조항 앞에는 이탤릭으로 한 줄 설명이 붙습니다. "왜 이 조항이 있는가"입니다. 제17장에서 고객 우회를 규정으로 쓰지 않고 이야기로 먼저 설명한 것과 같은 이유입니다. 설명문은 계약의 일부가 아니며 권리와 의무를 만들지 않습니다. 그러나 설명문이 있어야 사람들이 계약서를 읽고, 읽어야 지킵니다. 읽지 않고 서명한 계약서는 분쟁이 생겼을 때만 열리는 문서가 됩니다.

플랫폼과 신뢰 원장에 연결

서명, 기여 기록, 정산표, 종료평가는 aiopen.org 플랫폼의 기록과 연결됩니다. 계약서는 전자문서와 전자서명의 효력을 인정하고, 플랫폼에 남은 기록을 이행의 증거로 삼는 데 당사자가 동의하는 조항을 둡니다. 그리고 계약 이행의 결과가 Trust Capital에 기록되는 것에도 동의합니다. 정산을 기한 안에 마쳤는가, 비밀을 지켰는가, 종료평가에 참여했는가가 다음 프로젝트의 신뢰가 됩니다. 정당한 문제 제기와 실패는 감점 사유가 아니라는 점도 함께 명시합니다. 계약서와 신뢰 원장이 연결되지 않으면 계약서는 분쟁 때만 쓰이는 문서에 머물고, 연결되면 매일 작동하는 문서가 됩니다.

독립 전문가의 협업

Project Cell 참여는 고용이 아닙니다. 참여자는 각자의 회사, 직장, 연구실을 유지하는 독립 전문가이고, 셀은 도급과 위임의 성격이 섞인 협업 관계입니다. 계약서는 사용종속관계를 만들지 않으며 각자 자기 사업의 세무와 보험을 책임진다는 점을 분명히 합니다. 이것은 법적 안전장치이기도 하지만, 제13장에서 말한 독립성과 결합성의 원리를 문서로 옮긴 것이기도 합니다.

단계별 계약서 지도

회원의 여정을 따라가면 어느 시점에 어떤 문서가 필요한지 보입니다.

입회 ──→ Circle 활동 ──→ 기회 발생 ──→ 셀 결성 ──→ 수주 ──→ 실행 ──→ 정산·종료 ──→ 회사 전환
 │                         │             │           │         │           │              │
 계약1 회원 규약            계약4 기회소개   계약6 셀협약  계약8 고객계약  계약11 자원   계약13 종료확인   계약14 전환협약
 계약2 비밀유지 서약        계약5 상호NDA   계약7 합류    계약9 정산약정  계약12 이탈   (Appendix C·D·E)
 계약3 임원 서약(해당자)                    계약10 IP약정
                                                                    분쟁 발생 시 어느 단계든 → 계약15

열여섯 개 문서 가운데 모든 회원이 서명하는 것은 계약 1과 2, 두 개뿐입니다. 나머지는 해당 상황이 생길 때만 꺼내 씁니다. 대부분의 프로젝트는 계약 4, 6, 9, 10 네 개로 시작하고, 고객이 있으면 계약 8이 더해집니다. 문서가 많아 보이지만 한 프로젝트가 실제로 서명하는 문서는 네다섯 개입니다.

계약서와 부록 양식의 관계

Appendix의 일곱 양식은 계약서의 별지가 됩니다. 계약서는 권리와 의무를 정하고, 양식은 그 권리와 의무를 실행하는 데 필요한 정보를 담습니다.

서명 흐름

한 프로젝트의 서명 순서는 다음과 같습니다.

1. 기회가 공유될 때: Originator가 계약 4를 제안합니다. 소개받는 회원이 서명하면 기회의 출처와 우회 금지가 기록됩니다.
2. 셀이 결성될 때: 참여자 전원이 계약 6과 계약 10에 서명하고, Project Charter(Appendix B)를 별지로 붙입니다. Charter에 조정 조항의 값이 들어갑니다. 임원이 참여하면 이해상충 신고서(Appendix G)를 냅니다.
3. 고객과 계약할 때: 계약주체가 계약 8로 고객과 계약하고, 같은 날 셀 참여자와 계약 9에 서명합니다. 고객 계약의 대금 조건이 정산 약정의 입력값이 됩니다.
4. 실행 중: 자원이 투입되면 계약 11, 사람이 합류하면 계약 7, 떠나면 계약 12를 씁니다.
5. 종료할 때: Contribution Matrix(C)와 Settlement Sheet(D)를 확정하고 계약 13에 서명합니다. Closing Review(E)를 플랫폼에 기록합니다.
6. 회사가 될 때: 계약 14로 전환 조건을 정합니다.

서명은 플랫폼의 전자서명으로 합니다. 종이 서명이 필요한 고객 계약(계약 8)은 예외입니다.

법률 검토에 관하여

이 표준 계약서들은 커뮤니티의 기본값이며 법률 자문이 아닙니다. 실제 체결 전에 각 당사자가 변호사 검토를 받을 것을 권고합니다. 특히 고객 계약(계약 8), 회사 전환(계약 14), 개인정보가 포함된 데이터 제공(계약 11)은 사안마다 법률 검토가 필요합니다. Expert Circle은 표준 계약서의 개정을 검토하고, Council은 개정을 승인합니다. 개정된 계약서는 웹북에 버전과 변경사항이 표시되고, 이미 서명된 계약은 서명 당시의 버전을 따릅니다.

개정과 버전

계약서는 핸드북과 같은 버전 체계를 따릅니다. 어느 프로젝트가 어느 버전의 계약서로 시작했는지 플랫폼에 기록됩니다. 프로젝트 도중 계약서가 개정되어도 진행 중인 프로젝트에는 적용되지 않습니다. 참여자 전원이 합의하면 새 버전으로 갈아탈 수 있고, 그 합의도 기록됩니다.

Remember

• 핸드북은 말이고 계약서는 그 말을 지키게 만드는 도구입니다. 계약서는 불신이 아니라 신뢰를 평가할 기준을 미리 적어 두는 일입니다.
• 하나의 계약서로 모든 것을 담지 않습니다. 네 층으로 나뉜 열여섯 개 문서가 서로를 편입하며 하나의 체계로 작동합니다.
• 고정 조항은 협상 테이블에 올라오지 않습니다. 그래서 힘이 약한 쪽을 보호합니다.
• 숫자는 Project Charter로 조정하고, 원칙은 헌장이 지킵니다.
• 서명과 이행은 플랫폼에 기록되어 Trust Capital이 됩니다. 계약서가 신뢰 원장과 연결될 때 매일 작동하는 문서가 됩니다.

"약속은 말로 하고, 신뢰는 행동으로 쌓고, 기준은 문서로 남긴다."