이 부록은 읽는 문서가 아니라 쓰는 문서입니다. 앞의 29개 장이 "왜"와 "어떻게"를 설명했다면, 여기에 실린 일곱 개의 문서는 그 원칙을 실제 프로젝트의 첫날과 마지막 날에 종이 위로 옮기기 위한 것입니다. 회원은 아래 문서를 그대로 복사해 쓸 수 있습니다. 항목을 빼도 되고 더해도 됩니다. 다만 무엇을 뺐는지 참여자 전원이 알고 있어야 합니다.
일곱 문서는 프로젝트 생애주기 Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review의 각 지점에 놓입니다.
| 문서 | 쓰는 시점 | 작성 주체 | 관련 장 |
|---|---|---|---|
| A. Korea AI Community Charter | 가입 시 읽고 동의 | Council 개정, 회원 동의 | 제4장·제23장·제24장 |
| B. Project Charter | 팀 구성 직후, 계약 전 | Project Lead가 초안, 참여자 전원 서명 | 제14장·제16장 |
| C. Contribution Matrix | 착수·중간·종료 | 참여자 전원 + Project Lead | 제19장·제22장 |
| D. Project Settlement Sheet | 대금 입금 후 | Project Lead 또는 Contracting Party | 제20장·제22장 |
| E. Project Closing Review | 정산 완료 후 2주 이내 | Project Lead 주관, 참여자 전원 | 제18장·제10장 |
| F. Confidentiality Checklist | 착수·진행·종료 | Project Lead와 참여자 각자 | 제12장 |
| G. Conflict of Interest Declaration | 이해상충 상황 발생 즉시 | 해당 회원 | 제24장 |
이 부록에 나오는 숫자(커뮤니티 기여분 5%, Non-circumvention 24개월, Originator 24개월 체감 등)는 모두 커뮤니티의 기본값(Default)이며, 프로젝트 단위에서는 Project Charter로, 커뮤니티 단위에서는 Council의 개정으로 조정할 수 있습니다. 예시에 등장하는 프로젝트·인물·금액은 모두 가상입니다.
A. Korea AI Community Charter
한국인공지능커뮤니티 헌장
전문(Preamble)
우리는 사람이 가진 가능성을 가볍게 여기지 않습니다. 누군가의 기술, 경험, 관계와 시간이 다른 누군가에게는 새로운 기회가 될 수 있다고 믿습니다.
AI가 실행의 비용을 낮출수록 판단과 관계와 책임의 가치는 올라갑니다. 우리는 고용이 아니라 공유된 규약과 기록된 신뢰로 서로를 묶고, 필요할 때 결합하고 끝나면 해체되는 새로운 방식의 조직을 만들고자 합니다. 회사도 아니고 시장도 아니고 채팅방도 아닌, 신뢰 네트워크 위에서 작동하는 실행 조직입니다.
우리는 사람을 소모품처럼 다루지 않습니다. 기여한 사람을 잊지 않습니다. 신뢰는 말이 아니라 행동으로 쌓습니다. 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다. 실패에는 관대하되 부정직에는 엄격합니다. 운영의 권한과 사업의 기회를 분리합니다. 그리고 성장한 사람이 다시 기여하는 순환을 설계합니다.
이 헌장은 그 약속을 지키기 위한 우리의 기준입니다. 관통하는 공식은 다음과 같습니다.
CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK
제1조 (목적)
- 한국인공지능커뮤니티(Korea AI Community, 이하 "커뮤니티")는 AI 분야의 사업가·교수·연구원·개발자·크리에이터·마케터·전문가가 서로의 전문성을 존중하고, 신뢰를 기반으로 지식과 기술을 공유하며, 실제 프로젝트와 사업을 함께 만들고, 그 성과를 공정하게 나누며 함께 성장하는 프라이빗 프로페셔널 커뮤니티를 지향한다.
- 커뮤니티의 가장 중요한 자산은 회원 수나 게시물 수가 아니라 사람, 전문역량, 기여, 신뢰, 협력의 경험, 그리고 함께 만들어낸 성과다.
- 커뮤니티는 회원을 값싼 노동력이나 특정 회사의 외주 인력풀로 취급하지 않는다. 앵커 조직은 동등한 생태계 파트너 가운데 먼저 온 조직일 뿐이다.
제2조 (정의)
- Capability Node(역량 노드)란 회원 한 사람을 말한다. 회원은 직함이 아니라 무엇을 할 수 있는가로 본다. Technical·Research·Business·Sales·Marketing·Creative·Network·Leadership·Capital은 모두 동등한 기여 가능성이다.
- Project Cell(프로젝트 셀)이란 특정 목적을 위해 회원이 결합하여 만들고, 목적이 끝나면 해체되는 실행 단위(Virtual Company)를 말한다.
- Circle(서클)이란 결과물을 만드는 실행 공동체를 말하며, Research Circle·Builder Circle·Creator Circle·Founder Circle·Expert Circle을 둔다.
- Trust Capital이란 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사의 기록으로 축적되는 신뢰의 자산을 말한다.
- Originator란 기회 또는 고객을 가져온 사람, Contracting Party란 고객과 계약한 주체, Executor란 실제 업무를 수행한 사람, Project Lead란 Project Cell의 실행 판단을 맡은 사람을 말한다.
제3조 (회원)
- 회원은 일정한 전문성·활동·추천 또는 검증을 거쳐 참여한다. 울타리의 목적은 기존 회원의 이익을 보호하는 것이 아니라 회원 간의 신뢰·정보·사업기회·관계를 보호하는 것이다.
- 회원의 성장 단계는
Member → Verified → Contributor → Professional → Leader / Fellow로 한다. 이 단계는 권력의 서열이 아니라 신뢰와 책임의 깊이를 뜻한다. Verified 단계의 검증 경로 중 하나로 AI TEST 인증을 둔다. - 회원은 각자의 회사·직장·연구실을 유지한다. 커뮤니티는 회원의 독립성을 요구하지도, 침해하지도 않는다.
- 신규회원이라도 역량과 신뢰를 보여주면 참여하고 성장할 수 있어야 한다. Project Cell은 신규회원에게 최소 한 자리(Junior Slot 등)를 열어 두는 것을 권장한다.
제4조 (기여)
- 기여는 돈이나 노동시간만으로 측정하지 않는다. 기술·연구·지식·개발·콘텐츠 제작·고객 및 프로젝트 연결·영업·마케팅·투자·멘토링·소개·데이터·GPU 및 인프라·공간·운영·커뮤니티를 위해 사용한 시간은 모두 기여가 될 수 있다.
- 플랫폼은 기여를 Knowledge·Research·Technology·Mentoring·Project·Event·Connection·Infrastructure로 분류하여 기록하고 축적한다. 기여한 사람을 잊지 않는다.
- 과거의 기여는 신뢰를 만들지만 영구적인 권리를 만들지 않는다(Contribution creates Trust, not Permanent Privilege).
제5조 (신뢰)
- 신뢰는 자기소개나 직함이 아니라 행동으로 만들어진다. 약속을 지켰는가, 맡은 일을 제대로 수행했는가, 정산을 투명하게 했는가, 동료를 존중했는가, 비밀을 지켰는가, 관계를 악용하지 않았는가, 함께 일한 사람들이 다시 함께 일하고 싶어 하는가를 기록한다.
- 기술 실패·시장 실패·일정 실패는 실패다. 실패에는 관대하다. 책임회피·고의 은폐·고객 우회·정보 유출·기여 가로채기·비용 부풀리기·허위경력·대금 미정산·반복적 약속 위반은 부정직이다. 부정직에는 엄격하다.
- 신뢰를 지키는 사람에게 더 깊은 네트워크와 더 큰 협력의 기회가 열린다.
- Trust Capital은 인성평가가 아니라 행동의 원장이다. 기록은 당사자가 열람할 수 있고, 반론을 기록할 수 있다.
제6조 (협력과 Project Cell)
- 프로젝트는
Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review의 생애주기를 따른다. - 모든 Project Cell은 착수 전에 Project Charter(부록 B)를 작성한다. Charter는 1~2페이지로 하며 목적·범위·역할·Lead·의사결정 방식·보상 구조·IP·비밀유지·종료 조건·이해상충을 담는다.
- 팀 구성의 기준은
Capability + Experience + Trust + Availability + Fit이다. 친분의 순서가 아니다. - 실행은 빠르게, 이해관계 변경은 합의로 한다. 실행 판단은 Project Lead가 한다. 보상 구조·범위·참여자 변경 등 이해관계의 변경은 참여자 합의(원칙적으로 전원, Charter에 정한 경우 다수결)로 한다.
- AI 도구와 에이전트는 Project Cell의 구성원이 아니라 구성원의 역량을 증폭하는 장비다. 책임은 언제나 사람이 진다.
제7조 (보상)
- 실제 수행한 업무의 대가(Work Compensation)는 시장 단가를 기준으로 먼저 지급한다.
- 매출에서 직접비용과 Work Compensation을 뺀 잉여가치는 Contribution Matrix(부록 C)에 따라 나눈다(Value Sharing). 기여 범주는 Origination·Sales·Execution·Leadership & Risk·Capital & Infra·Network·Knowledge로 한다. 1/n 배분은 기본값이 아니다.
- 잉여가치의 일정 비율(기본값 5%, 범위 3~10%)을 커뮤니티 기여분으로 하여 커뮤니티 운영·신규회원 성장·인프라에 사용한다. 커뮤니티 기여분은 Work Compensation에서 떼지 않고 잉여가치에서만 뗀다.
- Originator는 첫 프로젝트에서 Origination 기여를 인정받고, 같은 고객의 후속 프로젝트에 대해 기본 24개월간 체감하는 소개 기여를 인정받는다. 영구 권리는 없다. 기간과 체감률은 Project Charter로 조정할 수 있다.
- 커뮤니티를 통해 만난 고객·파트너와 소개자를 배제하고 직접 거래하는 것을 기본 24개월간 금지한다(Non-circumvention). 고객이 직접 원할 경우 소개자와 합의하고 기록한다. 고객은 누구의 소유물도 아니지만, 관계를 만든 기여는 인정한다.
제8조 (비밀유지)
- 프로젝트 내부 정보·고객정보·계약조건·미공개 기술·사업전략은 보호한다. 경험·워크플로우·벤치마크·시장 인사이트는 신뢰 가능한 범위에서 공유한다.
- 정보는 Public·Community·Cell-only·Restricted 네 등급으로 분류하며, 각 Project Cell은 Charter에서 기본 등급을 정한다.
- 비밀유지의 수단으로 프로젝트 단위 NDA, Chatham House Rule, Closed Room을 둔다. 회원은 부록 F의 체크리스트를 따른다.
- 비밀유지 의무는 Project Cell 해체 후에도 Charter가 정한 기간 동안 유지된다(기본값 24개월, 고객 계약이 더 긴 기간을 정한 경우 그에 따른다).
제9조 (이해상충과 권력·기회의 분리)
- 운영의 권한과 사업의 기회는 분리한다(Governance Power ≠ Economic Opportunity). Council·임원·Circle Leader·오래된 회원이라는 이유로 사업기회를 우선 배정받지 않는다.
- 사업기회는 공개 채널(플랫폼의 Opportunity)로 흐른다. 기회를 비공개로 특정인에게 먼저 배정하려면 그 사유를 기록한다.
- Council·임원·Circle Leader는 자기 권한의 범위와 자기 이해가 걸린 사안에서 회피(Recusal)하며, 이해상충 신고서(부록 G)를 낸다.
- 심사와 참여를 겸하지 않는다. 심사자는 심사하는 사안의 참여자가 될 수 없고, 참여자는 그 사안을 심사할 수 없다.
제10조 (분쟁)
- 분쟁은
당사자 협의 → Project Lead 조정 → 윤리·분쟁위원회 → 외부 중재의 순서로 해결한다. - 단체방 공개 성토 등 감정적 여론재판을 금지한다. 분쟁 중인 사안을 당사자·조정자·위원회 외의 회원에게 공개하는 것은 그 자체로 신뢰 위반이다.
- 윤리·분쟁위원회는 Council 산하에 두되 독립적으로 판단한다. 위원은 해당 사안의 당사자·같은 Project Cell 참여자·이해관계자일 경우 회피한다.
- 제재는 경고 → 프로젝트 참여 제한 → 등급 조정 → 제명의 순서로 하며, 재심 절차를 둔다. 제재 사실은 기록하되, 공개 범위는 위원회가 정한다.
제11조 (개정)
- 이 헌장은 Council이 개정안을 발의하고, Circle Leader 회의의 의견을 들은 뒤, 회원 의견수렴 기간(기본값 14일)을 거쳐 Council이 확정한다.
- 제7조·제9조·제10조의 개정은 회원 의견수렴 기간을 두 배로 하며, 확정 전 반대 의견을 요약하여 함께 공개한다.
- 개정된 헌장은 웹북에 버전·최종 개정일·변경사항을 표시하여 공개한다. 개정 전에 착수한 Project Cell은 해당 프로젝트가 끝날 때까지 착수 시점의 헌장을 따른다.
B. Project Charter
프로젝트 헌장 (1~2페이지 양식)
Project Lead가 초안을 쓰고, 참여자 전원이 읽고 서명한 뒤 고객과 계약합니다. 계약 후에 Charter를 고치려면 "이해관계 변경"이므로 참여자 합의가 필요합니다. 빈칸은 비워 두지 말고 "해당 없음"이라도 적습니다.
| 항목 | 내용 |
|---|---|
| 프로젝트명 | 짧고 검색 가능한 이름. 고객명을 넣지 않아도 됩니다. |
| 목적 | 이 프로젝트가 끝났을 때 고객과 우리에게 무엇이 남아야 하는지 두 문장 이내. |
| 범위 — 포함 | 납품물을 항목별로 나열합니다. "품질검사 모델 1종, 추론 API, 운영 매뉴얼"처럼 셀 수 있게. |
| 범위 — 제외 | 하지 않는 것을 명시합니다. 범위 분쟁의 대부분은 여기가 비어 있어서 생깁니다. |
| 기간 | 착수일 / 중간 점검일 / 납품 예정일 / 검수 완료 예정일. |
| 고객 · 계약주체(Contracting Party) | 고객명(등급이 Restricted면 가명 사용 가능) / 우리 쪽 계약주체(회원 개인, 회원의 회사, 또는 Association). 세금계산서 발행 주체를 씁니다. |
| Originator | 기회를 가져온 사람. 후속 프로젝트 소개 기여 인정 기간(기본값 24개월, 체감)을 함께 씁니다. |
| Project Lead | 실행 판단을 맡는 한 사람. 공동 Lead는 권장하지 않습니다. 부재 시 대행자를 씁니다. |
| 참여자와 역할 | 이름 / Capability / 역할 / 투입 예상(일수 또는 시간) / Junior Slot 여부. 신규회원 자리를 열어 두었는지 씁니다. |
| 의사결정 방식 | 실행 판단은 Lead. 이해관계 변경(보상·범위·참여자)은 전원 합의가 기본값. 다수결로 할 항목이 있으면 여기에 한정하여 명시합니다. |
| Work Compensation 기준 | 참여자별 단가(일당 또는 시간당)와 상한. 시장 단가 기준. 지급 시점(입금 후 N일 이내). 무급 참여는 참여자 본인이 서면으로 동의한 경우에만 허용. |
| Value Sharing 사전 합의 | Contribution Matrix 초기 가중치. 범주별 가중치(합 100)와, 가능하면 참여자별 예상 비율. "종료 시 재평가"를 기본값으로 명시합니다. |
| 커뮤니티 기여분 | 잉여가치의 __ % (기본값 5%, 범위 3~10%). 잉여가치가 0 이하이면 0. |
| IP 귀속 — Background IP | 참여 전에 이미 가지고 있던 코드·모델·데이터·템플릿을 참여자별로 나열합니다. 원소유자에게 남습니다. |
| IP 귀속 — 납품물 | 고객 계약이 정하는 대로. 계약서 조항 번호를 씁니다. |
| IP 귀속 — 재사용 자산 | 이 프로젝트에서 새로 만들어질 워크플로우·모델·데이터셋·템플릿의 귀속. 기본값: 만든 참여자 공동 소유 + 커뮤니티 회원 비독점 재사용 라이선스. 고객 계약이 금지하면 "없음". |
| 비밀유지 등급 | 기본 등급(Public / Community / Cell-only / Restricted) 하나를 고르고, 예외 항목을 씁니다. 고객 NDA 유무. 해체 후 유지 기간(기본값 24개월). |
| 종료 조건 | 정상 종료(검수 완료·입금 완료) / 조기 종료 사유(고객 취소, 기술적 불가, 참여자 이탈 등)와 그 경우의 정산 원칙(수행분 Work Compensation 우선 지급). |
| 이해상충 신고 | 참여자 중 고객사·경쟁사와 이해관계가 있는 사람, Council·Circle Leader 겸임자가 있으면 부록 G 제출 여부를 씁니다. 없으면 "해당 없음". |
| 분쟁 해결 | 기본값: 당사자 협의 → Lead 조정 → 윤리·분쟁위원회 → 외부 중재. 변경 시 사유. |
| 서명 | 참여자 전원 이름 / 날짜 / 서명. Originator와 Contracting Party가 참여자가 아닌 경우에도 서명합니다. |
작성 후 이 문서의 비밀유지 등급은 기본적으로 Cell-only입니다. 고객명과 금액을 지운 요약본은 Community 등급으로 플랫폼의 Project 기록에 남깁니다.
C. Contribution Matrix
기여도 평가표
범주 정의
| 범주 | 정의 | 포함되는 것 | 포함되지 않는 것 |
|---|---|---|---|
| Origination | 기회 발굴 / 고객 | 고객 발굴, 문제 정의, 첫 미팅 성사 | 단순 명함 전달 |
| Sales | 영업 / 계약 | 제안서, 협상, 계약 체결, 대금 회수 책임 | 이미 체결된 계약의 서류 처리 |
| Execution | 기술 / 제작 / 연구 — 유급 수행을 넘어선 부분 | Work Compensation으로 보상되지 않은 초과 기여, 품질을 결정적으로 끌어올린 기여 | 단가로 이미 지급된 노동 |
| Leadership & Risk | PM / 책임 / 위험부담 | 일정·품질 책임, 고객 대응, 선투자, 손실 시 부담, 하자 보수 책임 | 회의 참석 |
| Capital & Infra | 자본 / 인프라 | GPU·서버·데이터 구매, 선지급 비용, 공간 | 개인 노트북 사용 |
| Network | 네트워크 / 소개 | 핵심 인력·파트너·전문가 연결, 의사결정자 접근 | 단체방 링크 공유 |
| Knowledge | 지식 / IP 제공 | Background IP 제공, 재사용 자산 기여, 결정적 노하우 | 공개된 자료 전달 |
가중치 설정 방법
- Project Charter 단계에서 범주별 가중치(합 100)를 먼저 정합니다. 프로젝트의 성격에 따라 다릅니다. 영업이 어려운 대기업 PoC라면 Origination·Sales가 크고, 기술 난이도가 높은 연구형 프로젝트라면 Execution·Knowledge가 큽니다.
- 참여자 개인의 예상 비율은 착수 시점에 "가정"으로만 적고, 종료 시점에 재평가하는 것이 기본값입니다.
- 가중치는 이해관계 사항이므로 변경은 참여자 합의로 합니다.
- Originator의 후속 프로젝트 소개 기여는 Origination 범주 안에서 체감합니다. 기본값: 첫 계약일부터 12개월까지 100%, 13~24개월 50%, 이후 0%. Charter로 조정할 수 있습니다.
평가 시점
| 시점 | 목적 | 산출물 |
|---|---|---|
| 착수 | 기대치 정렬. 누가 무엇을 기여하기로 했는지 확인 | 범주별 가중치 + 예상 비율(가정) |
| 중간 | 실제 기여가 예상과 다른지 조기 발견. 이탈·추가 투입 반영 | 수정 예상 비율 + 변경 사유 기록 |
| 종료 | 최종 확정. 정산표(부록 D)의 입력값 | 최종 비율 + 참여자 전원 서명 |
합산 규칙
- 각 참여자는 범주마다 참여자 전원에 대한 배분안(합 100%)을 제출합니다. 본인 몫도 포함합니다.
- 자기평가는 본인이 제출한 배분안 중 본인 몫, 동료평가는 다른 참여자들이 제출한 배분안의 평균, Lead 평가는 Project Lead가 제출한 배분안입니다.
- 합산 비율의 기본값은 자기평가 20% : 동료평가 50% : Lead 평가 30%입니다. Lead 본인의 몫에 대해서는 Lead 평가를 제외하고 동료평가 70% : 자기평가 30%로 합니다.
- 범주별 합산 결과를 100%로 정규화한 뒤, 범주 가중치를 곱하여 참여자별 총 기여 비율을 구합니다.
- 결과는 소수점 첫째 자리까지 쓰고, 참여자 전원이 합의하면 5% 단위로 반올림할 수 있습니다.
이견이 있을 때
- 어느 참여자의 자기평가와 동료평가 평균의 차이가 20%포인트를 넘으면 그 범주에 대해 반드시 대화합니다. 숫자만 제출하고 끝내지 않습니다.
- 대화로 합의되지 않으면 Project Lead가 조정안을 냅니다. Lead 본인의 몫이 쟁점이면 Lead가 아닌 참여자 중 한 명이 조정합니다.
- 조정안에도 합의하지 못하면 윤리·분쟁위원회에 회부합니다. 회부 중에도 Work Compensation은 먼저 지급합니다. 다투는 것은 Value Sharing이지 수행 대가가 아닙니다.
- 분쟁 사실과 결과는 Trust Capital에 기록됩니다. 다만 "이견이 있었다"는 사실 자체는 감점이 아닙니다. 합의 절차를 거부하거나 은폐한 경우가 감점입니다.
작성 예시 (가상)
프로젝트: 제조업 A사 품질검사 AI PoC. 참여자 4명. 파운더 박 대표(Originator·Project Lead), 개발자 김 씨(모델 개발), 연구자 이 박사(알고리즘 설계·기술 발표), 크리에이터 최 씨(데모 영상·발표자료). 종료 시점 평가. 아래 표는 자기·동료·Lead 평가를 합산하고 정규화한 결과입니다.
| 범주 | 가중치 | 박 대표 | 김 씨 | 이 박사 | 최 씨 | 합 |
|---|---|---|---|---|---|---|
| Origination | 20 | 100% | 0% | 0% | 0% | 100% |
| Sales | 15 | 80% | 0% | 20% | 0% | 100% |
| Execution | 20 | 0% | 50% | 25% | 25% | 100% |
| Leadership & Risk | 15 | 60% | 40% | 0% | 0% | 100% |
| Capital & Infra | 5 | 40% | 60% | 0% | 0% | 100% |
| Network | 10 | 20% | 0% | 60% | 20% | 100% |
| Knowledge | 15 | 0% | 40% | 40% | 20% | 100% |
| 가중 합산 | 100 | 45.0 | 25.0 | 20.0 | 10.0 | 100.0 |
계산 예: 박 대표 = 20×1.00 + 15×0.80 + 20×0 + 15×0.60 + 5×0.40 + 10×0.20 + 15×0 = 20 + 12 + 0 + 9 + 2 + 2 + 0 = 45.0.
이 프로젝트에서 김 씨는 40일을 투입했지만 Execution 범주가 50%에 그친 이유는, 40일의 대부분이 Work Compensation으로 이미 보상되었기 때문입니다. Execution 범주는 유급 수행을 넘어선 부분만 봅니다. 반대로 최 씨는 5일만 투입했지만 데모 영상이 고객 임원 설득에 결정적이었다는 데 전원이 동의하여 Execution 25%를 인정받았습니다.
D. Project Settlement Sheet
프로젝트 정산표
대금이 입금된 뒤 Project Lead 또는 Contracting Party가 작성하고 참여자 전원이 확인합니다. 계산식은 아래 순서를 따릅니다. 어느 줄도 건너뛰지 않습니다.
계산식
① 매출(부가세 제외)
② 직접비용 = 프로젝트를 위해 실제 지출한 외부 비용의 합
③ Work Compensation 합계 = Σ(참여자별 투입 × 단가)
④ 잉여가치 = ① − ② − ③
⑤ 커뮤니티 기여분 = ④ × 기본값 5% (④ ≤ 0이면 0)
⑥ Value Sharing 대상 = ④ − ⑤
⑦ 참여자별 Value Sharing = ⑥ × Contribution Matrix 최종 비율
⑧ 참여자별 최종 수령액 = 참여자별 ③ + 참여자별 ⑦
검산: ② + ⑤ + Σ⑧ = ①
잉여가치가 음수이면 Value Sharing은 없고, 손실은 Charter의 Leadership & Risk 합의에 따라 부담합니다. 손실 부담 합의가 없으면 Work Compensation을 비율대로 줄이지 않고, 먼저 참여자 합의를 거칩니다.
양식
| 구분 | 항목 | 금액(원) | 비고 |
|---|---|---|---|
| ① 매출 | 계약금액(부가세 제외) | 입금일 | |
| ② 직접비용 | 항목 1 | 증빙 | |
| 항목 2 | |||
| 직접비용 합계 | |||
| ③ Work Compensation | 참여자 A: 투입 × 단가 | ||
| 참여자 B: 투입 × 단가 | |||
| Work Compensation 합계 | |||
| ④ 잉여가치 | ① − ② − ③ | ||
| ⑤ 커뮤니티 기여분 | ④ × __ % | 기본값 5% | |
| ⑥ Value Sharing 대상 | ④ − ⑤ | ||
| ⑦ Value Sharing | 참여자 A: ⑥ × __ % | Matrix 최종 비율 | |
| 참여자 B: ⑥ × __ % | |||
| ⑧ 최종 수령액 | 참여자 A: ③ + ⑦ | ||
| 참여자 B: ③ + ⑦ | |||
| 검산 | ② + ⑤ + Σ⑧ = ① | 일치 여부 |
| 지급 일정 | 기한 | 상태 |
|---|---|---|
| Work Compensation | 입금 후 7일 이내(기본값) | |
| Value Sharing | Contribution Matrix 최종 서명 후 7일 이내(기본값) | |
| 커뮤니티 기여분 | Value Sharing과 동시 |
| 확인 | 이름 | 날짜 | 서명 |
|---|---|---|---|
| Project Lead | |||
| 참여자 | |||
| 참여자 | |||
| Contracting Party |
작성 예시 (가상)
부록 C의 예시와 같은 프로젝트. 계약금액 6,000만원(부가세 제외). 커뮤니티 기여분 기본값 5% 적용. Contribution Matrix 최종 비율 45 : 25 : 20 : 10.
| 구분 | 항목 | 금액(원) | 비고 |
|---|---|---|---|
| ① 매출 | 계약금액 | 60,000,000 | 검수 완료 후 일괄 입금 |
| ② 직접비용 | GPU 클라우드 임대 | 3,000,000 | 영수증 |
| 라벨링 외주 | 4,000,000 | 세금계산서 | |
| 출장·기타 | 1,000,000 | 영수증 | |
| 직접비용 합계 | 8,000,000 | ||
| ③ Work Compensation | 김 씨: 40일 × 350,000 | 14,000,000 | |
| 이 박사: 15일 × 400,000 | 6,000,000 | ||
| 박 대표: 20일 × 300,000 | 6,000,000 | PM·고객 대응 | |
| 최 씨: 5일 × 300,000 | 1,500,000 | ||
| Work Compensation 합계 | 27,500,000 | ||
| ④ 잉여가치 | 60,000,000 − 8,000,000 − 27,500,000 | 24,500,000 | |
| ⑤ 커뮤니티 기여분 | 24,500,000 × 5% | 1,225,000 | |
| ⑥ Value Sharing 대상 | 24,500,000 − 1,225,000 | 23,275,000 | |
| ⑦ Value Sharing | 박 대표: 23,275,000 × 45% | 10,473,750 | |
| 김 씨: 23,275,000 × 25% | 5,818,750 | ||
| 이 박사: 23,275,000 × 20% | 4,655,000 | ||
| 최 씨: 23,275,000 × 10% | 2,327,500 | ||
| Value Sharing 합계 | 23,275,000 | ||
| ⑧ 최종 수령액 | 박 대표: 6,000,000 + 10,473,750 | 16,473,750 | |
| 김 씨: 14,000,000 + 5,818,750 | 19,818,750 | ||
| 이 박사: 6,000,000 + 4,655,000 | 10,655,000 | ||
| 최 씨: 1,500,000 + 2,327,500 | 3,827,500 | ||
| 최종 수령액 합계 | 50,775,000 | ||
| 검산 | 8,000,000 + 1,225,000 + 50,775,000 | 60,000,000 | ① 과 일치 |
이 예시에서 가장 많이 받은 사람은 Originator이자 Lead인 박 대표가 아니라 개발자 김 씨입니다. Work Compensation을 먼저 지급하는 구조에서는 실제로 가장 많이 일한 사람이 먼저 보상받고, 기회를 만들고 위험을 진 사람은 잉여가치에서 보상받습니다. 두 층이 서로를 대신하지 않습니다.
E. Project Closing Review
프로젝트 종료평가
정산 완료 후 2주 이내에 Project Lead가 주관합니다. 참여자 전원이 한자리에 모여 작성하는 것을 기본값으로 합니다. 이 문서의 목적은 책임을 묻는 것이 아니라 다음 프로젝트를 더 잘하기 위한 것입니다. 다만 부정직이 발견되면 이 문서와 별개로 윤리·분쟁위원회 절차를 따릅니다.
| 항목 | 내용 |
|---|---|
| 프로젝트명 / 기간 / Lead | |
| 결과 요약 | 세 문장 이내. 무엇을 납품했고, 고객은 어떻게 반응했고, 정산은 끝났는가. |
| 목표 대비 달성 | Charter의 "목적"과 "범위 — 포함"을 항목별로 대조. 달성 / 부분 달성 / 미달성. |
| 무엇이 잘 되었나 | 구체적으로. "협업이 좋았다"가 아니라 "중간 점검에서 범위를 줄이기로 한 결정이 일정을 지켰다"처럼. |
| 무엇이 안 되었나 | 구체적으로. 사람이 아니라 상황과 결정을 씁니다. |
실패 유형 분류
안 된 것이 있다면 아래 중 어디에 해당하는지 표시합니다. 하나의 프로젝트에 여러 유형이 있을 수 있습니다. 앞의 세 가지는 실패이고, 뒤의 두 가지는 부정직입니다. 구분이 중요합니다.
| 유형 | 해당 | 설명 |
|---|---|---|
| 기술 실패 | [ ] | 시도했으나 기술적으로 목표에 못 미침. 예: 목표 정확도 미달. |
| 시장 실패 | [ ] | 만들었으나 고객·시장이 원하지 않음. 예: PoC 후 본사업 미진행. |
| 일정 실패 | [ ] | 범위 산정 오류, 외부 요인, 인력 이탈 등으로 기한 초과. |
| 책임회피 | [ ] | 맡은 역할을 통보 없이 방치, 문제를 알고도 Lead에게 보고하지 않음. |
| 고의 은폐 | [ ] | 결함·비용·일정 지연을 알면서 숨김. 허위 보고. |
실패 유형이 책임회피 또는 고의 은폐로 분류되면, 해당 참여자는 이 문서에 반론을 쓸 권리가 있고, 분류의 최종 확정은 윤리·분쟁위원회가 합니다. Project Cell 내부에서 확정하지 않습니다.
재협업 의사
참여자 각자가 다른 참여자 각각에 대해 표시합니다. 결과는 본인과 윤리·분쟁위원회만 열람할 수 있으며, Trust Capital에는 "재협업 의사 긍정 비율"만 기록됩니다. 이 항목은 Lead가 대신 쓸 수 없습니다.
| 평가자 \ 대상 | 참여자 A | 참여자 B | 참여자 C | 참여자 D |
|---|---|---|---|---|
| 참여자 A | — | |||
| 참여자 B | — | |||
| 참여자 C | — | |||
| 참여자 D | — |
표기: ◎ 다시 함께 일하고 싶다 / ○ 조건에 따라 / △ 이번 역할로는 어렵다 / 빈칸은 미응답.
재사용 가능한 자산
| 자산 | 유형 | 귀속(Charter 기준) | 커뮤니티 공유 등급 |
|---|---|---|---|
| 워크플로우 / 모델 / 데이터셋 / 템플릿 / 프롬프트 / 문서 | 공동 소유 + 비독점 라이선스 / 참여자 개인 / 고객 | Public / Community / Cell-only / Restricted |
커뮤니티에 공유할 교훈
고객명·금액·미공개 기술을 제외하고, 같은 종류의 프로젝트를 하는 다음 Project Cell이 알아야 할 것을 씁니다. Community 등급으로 플랫폼 Knowledge 기여에 기록됩니다. "실제로 해본 사람만 아는 것"을 씁니다.
Trust Capital 반영 항목
Project Lead가 참여자 전원 확인 아래 체크합니다. 항목별로 "예 / 아니오 / 해당 없음"으로 답하고, "아니오"에는 한 줄 사유를 씁니다.
| 항목 | 대상 | 예 / 아니오 / 해당 없음 | 사유 |
|---|---|---|---|
| 약속한 역할을 수행했는가 | 참여자별 | ||
| 일정을 지켰는가 (지연 시 사전 통보했는가) | 참여자별 | ||
| 정산을 투명하게 했는가 | Lead · Contracting Party | ||
| 비밀유지 등급을 지켰는가 | 참여자별 | ||
| 납품물이 검수를 통과했는가 | Project Cell | ||
| Work Compensation이 기한 내 지급되었는가 | Lead · Contracting Party | ||
| Value Sharing이 합의대로 지급되었는가 | Lead · Contracting Party | ||
| 커뮤니티 기여분이 납부되었는가 | Lead · Contracting Party | ||
| 종료평가에 전원이 참여했는가 | Project Cell |
| 확인 | 이름 | 날짜 | 서명 |
|---|---|---|---|
| Project Lead | |||
| 참여자 전원 |
F. Confidentiality Checklist
비밀유지 체크리스트
Project Lead가 착수 시 체크하고, 참여자 각자가 진행 중과 종료 시 체크합니다. 체크하지 못한 항목이 있으면 그 이유를 Lead에게 알립니다. 체크리스트는 사람을 의심하기 위한 것이 아니라, 실수로 신뢰를 잃는 일을 막기 위한 것입니다.
정보 등급 분류표
| 등급 | 정의 | 공유 범위 | 예시 |
|---|---|---|---|
| Public | 누구나 볼 수 있음 | 커뮤니티 밖 포함 | 프로젝트가 존재한다는 사실(고객 동의 시), 공개 발표 자료 |
| Community | 회원만 볼 수 있음 | 커뮤니티 회원 전체 | 워크플로우, 벤치마크, 교훈, 고객명을 지운 사례 |
| Cell-only | Project Cell 참여자만 볼 수 있음 | 해당 Project Cell + 필요 시 Council 지정 1인 | Project Charter 원본, 정산표, 고객 요구사항, 중간 산출물 |
| Restricted | 지정된 사람만 볼 수 있음 | Charter에 이름을 적은 사람만 | 고객 원본 데이터, 계약서, 고객 내부 사업전략, 개인정보 |
등급이 불분명하면 한 단계 높은 등급으로 취급합니다. 등급을 낮추는 결정은 Lead가, Restricted에서 낮추는 결정은 고객 동의를 받아 Lead가 합니다.
착수 시
- Project Charter에 기본 비밀유지 등급을 적었다.
- Restricted 정보의 목록과 접근 가능자 이름을 적었다.
- 고객 NDA가 있으면 참여자 전원이 읽고 서명했다. 고객 NDA가 없어도 프로젝트 단위 NDA를 체결했다.
- 참여자 전원이 이 체크리스트를 읽었다.
- Closed Room(참여자만 접근하는 채널·저장소)을 만들고, 참여자 외의 사람이 없는지 확인했다.
- 고객 데이터의 저장 위치(어느 서버, 어느 계정)를 정했고, 개인 클라우드·개인 메신저에 두지 않기로 했다.
- AI 도구에 고객 데이터·계약조건을 입력해도 되는지, 된다면 어떤 도구까지인지 정했다.
- 참여자 각자가 이 프로젝트와 이해가 겹치는 다른 프로젝트·고객·회사가 있는지 확인했다(부록 G).
진행 중
- Cell-only 이상의 정보를 Closed Room 밖(단체방, SNS, 다른 Circle 모임)에서 말하지 않았다.
- 고객명·금액을 커뮤니티 안에서 언급할 때 등급을 확인했다.
- 외부 발표·SNS 게시 전에 Lead의 확인을 받았다.
- 새 참여자가 들어올 때 NDA 서명과 체크리스트 확인을 먼저 했다.
- 참여자가 나갈 때 접근 권한을 즉시 회수했다.
- 스크린샷·화면공유 시 Restricted 정보가 노출되지 않도록 확인했다.
- 다른 회원이 이 프로젝트 정보를 물을 때 "말할 수 없다"고 답하는 것이 실례가 아님을 서로 확인했다.
종료 시
- 고객 원본 데이터를 계약에 따라 반환 또는 삭제했고, 삭제 사실을 기록했다.
- 참여자 개인 기기·계정에 남은 Restricted 정보를 삭제했다.
- Closed Room을 보존할지 폐쇄할지 정했고, 보존 시 접근자를 Lead와 Contracting Party로 한정했다.
- 커뮤니티에 공유할 교훈(부록 E)에서 고객명·금액·미공개 기술을 지웠다.
- 재사용 자산의 공유 등급을 정했다.
- 해체 후 비밀유지 유지 기간(기본값 24개월)을 참여자 전원이 확인했다.
메신저 방 취급 규칙
- 프로젝트 채널은 Closed Room으로만 만듭니다. 초대 링크를 공개하지 않습니다.
- 채널에 들어온 사람은 Charter의 참여자 명단과 일치해야 합니다. 명단에 없는 사람이 있으면 Lead가 즉시 내보내고 기록합니다.
- Restricted 정보는 메신저에 올리지 않습니다. 저장소 링크로 대신하고, 링크의 접근 권한을 별도로 관리합니다.
- 프로젝트 채널의 대화를 다른 방으로 복사·전달하지 않습니다. 캡처도 같습니다.
- 프로젝트가 끝난 채널은 "보관"으로 전환합니다. 계속 대화하고 싶으면 새 방을 만듭니다.
- Circle 단체방과 Project Cell 채널을 섞지 않습니다. Circle 방에서는 Community 등급까지만 말합니다.
Chatham House Rule 적용 모임
Chatham House Rule: 모임에서 들은 내용은 쓸 수 있지만, 누가 말했는지와 어느 조직의 이야기인지는 밝히지 않습니다.
- Circle 정기 모임, Founder Circle 사례 공유, Expert Circle 세미나는 기본적으로 Chatham House Rule로 진행합니다.
- 모임 시작 시 진행자가 "이 자리는 Chatham House Rule입니다"라고 선언합니다. 선언이 없으면 Community 등급 기본 규칙을 따릅니다.
- 발언자가 "이 부분은 여기서만"이라고 말한 내용은 Cell-only에 준하여 취급하며 기록·전달하지 않습니다.
- 모임의 요약을 플랫폼에 남길 때는 발언자·조직명·고객명을 뺀 인사이트만 남깁니다.
- 녹음·녹화는 참석자 전원 동의 없이 하지 않습니다.
유출 발생 시 대응 절차
- 즉시 보고: 유출을 알게 된 사람은 24시간 이내에 Project Lead에게 알립니다. 본인의 실수라도 같습니다. 스스로 보고한 유출과 은폐된 유출은 Trust Capital에서 다르게 기록됩니다.
- 범위 확인: Lead는 무엇이, 어디까지, 누구에게 나갔는지 확인하고 기록합니다.
- 확산 차단: 해당 채널·링크·파일의 접근을 즉시 차단합니다.
- 고객 통보: Restricted 정보가 포함되었으면 Contracting Party가 고객에게 계약에 따라 통보합니다. 통보를 늦추지 않습니다.
- 위원회 회부: 고의 여부가 불분명하거나 Restricted 정보가 포함되었으면 윤리·분쟁위원회에 회부합니다. 실수에 의한 Community 등급 유출은 Lead 선에서 기록으로 마무리할 수 있습니다.
- 여론재판 금지: 유출자의 이름을 단체방에서 거론하지 않습니다. 절차는 위원회가 진행합니다.
G. Conflict of Interest Declaration
이해상충 신고서
이해상충은 잘못이 아닙니다. 신고하지 않는 것이 잘못입니다. 이해가 겹치는 상황에서 스스로 물러나는 것(Recusal)은 신뢰를 잃는 행동이 아니라 신뢰를 쌓는 행동입니다.
신고가 필요한 상황
- Council·임원·Circle Leader·윤리·분쟁위원이 자기 회사, 자기가 투자한 회사, 가족의 회사가 관련된 사안을 다루게 될 때.
- 공개된 Opportunity의 심사·배정에 관여하는 사람이 그 Opportunity에 참여하고 싶을 때.
- Project Cell 참여자가 고객사·경쟁사와 고용·자문·투자 관계에 있을 때.
- 회원 검증(Verified 이상 승급) 심사자가 심사 대상과 같은 회사·연구실·Project Cell에 속해 있을 때.
- 윤리·분쟁위원이 분쟁 당사자와 최근 24개월 이내 같은 Project Cell에 있었을 때.
- Circle Leader가 자기 Circle의 예산·인프라(GPU 등)를 자기 프로젝트에 배정하려 할 때.
- 앵커 조직 소속 회원이 앵커 조직의 이해가 걸린 커뮤니티 의사결정에 참여할 때.
- 위에 없더라도 "이 결정으로 내가 이익을 보거나 손해를 볼 수 있는가"에 "예"라고 답하게 될 때.
양식
| 항목 | 내용 |
|---|---|
| 신고자 | 이름 / 회원 단계 |
| 직위 | Council 위원 / 임원 / Circle Leader / 윤리·분쟁위원 / 심사자 / Project Lead / 참여자 중 해당하는 것 모두 |
| 관련 사안 | 어떤 결정·심사·프로젝트·Opportunity인지. 식별 가능한 번호 또는 이름. |
| 이해관계 유형 | 아래 중 해당하는 것 모두 표시 |
| [ ] 자기 회사 — 본인이 대표·임원·주요 주주인 회사가 관련됨 | |
| [ ] 가족 — 배우자·직계가족·형제자매 또는 그들의 회사가 관련됨 | |
| [ ] 투자 — 본인 또는 본인의 회사가 투자했거나 투자받은 관계 | |
| [ ] 고객 관계 — 관련 고객사·경쟁사와 고용·자문·계약 관계 | |
| [ ] 심사와 참여 겸임 — 심사·배정 권한이 있는 사안에 참여자로도 관여하고 싶음 | |
| [ ] 기타 — 구체적으로 | |
| 이해관계의 내용 | 어떤 이익 또는 손해가 생길 수 있는지 구체적으로. "관련 있을 수 있음" 같은 표현은 쓰지 않습니다. |
| 회피 조치 | 신고자가 택하는 조치. 기본값: 해당 사안의 논의·표결·심사에서 전부 물러남. 부분 회피(정보 열람은 하되 표결은 하지 않음 등)를 택할 경우 사유. |
| 참여를 원하는 경우 | 심사와 참여 중 참여를 택하면 심사 권한을 내려놓습니다. 두 가지를 다 가질 수는 없습니다. 어느 쪽을 택하는지 씁니다. |
| Council 확인 | Council(또는 Council이 지정한 위원)이 회피 조치의 적절성을 확인하고 서명. 신고자 본인이 Council 위원이면 본인을 제외한 위원이 확인. |
| 기록 등급 | 기본값 Community. 사안의 성격상 Cell-only 또는 Restricted로 할 경우 사유. |
| 서명 | 신고자 이름 / 날짜 / 서명 |
| 확인자 이름 / 날짜 / 서명 |
신고서는 사안이 종료된 후에도 보관합니다. 신고했어야 할 이해상충을 신고하지 않은 사실이 나중에 드러나면, 그 결정은 재검토 대상이 되고, 신고하지 않은 사실은 부정직으로 기록됩니다. 신고하고 물러난 사실은 Trust Capital에 긍정적으로 기록됩니다.
양식의 버전과 개정
이 부록의 일곱 문서는 한국인공지능커뮤니티의 기본값입니다. 프로젝트 단위에서는 Project Charter로, 커뮤니티 단위에서는 Council의 개정으로 바뀔 수 있습니다. 바뀌지 않는 것은 문서 뒤에 있는 원칙입니다. 사람을 소모품처럼 다루지 않고, 기여한 사람을 잊지 않으며, 함께 만든 가치를 실제 기여에 따라 공정하게 나눈다는 것입니다.
양식의 개정은 다음 원칙을 따릅니다.
- 개정 주체: Council이 개정합니다. 회원은 누구나 개정을 제안할 수 있으며, 실제 프로젝트에서 양식이 작동하지 않았던 경험은 가장 좋은 개정 제안입니다.
- 개정 절차: 헌장(A)은 헌장 제11조의 절차를 따릅니다. 나머지 양식(B~G)은 Council이 개정안을 공개하고 회원 의견수렴 기간(기본값 14일)을 거쳐 확정합니다.
- 버전 표시: 웹북(aiopen.org)의 이 부록 상단에 현재 버전, 최종 개정일, 변경사항 요약을 표시합니다. 예:
현재 버전 v1.0 / 최종 개정일 YYYY-MM-DD / 변경사항: 최초 제정. - 적용 시점: 개정 전에 Project Charter에 서명한 Project Cell은 그 프로젝트가 끝날 때까지 서명 당시의 양식을 따릅니다. 참여자 전원이 합의하면 새 양식으로 옮길 수 있습니다.
- 이력 보존: 이전 버전은 삭제하지 않고 웹북에서 열람할 수 있게 둡니다. 어느 프로젝트가 어느 버전을 따랐는지 확인할 수 있어야 합니다.
문서는 신뢰를 대신하지 못합니다. 그러나 좋은 문서는 신뢰가 오해로 깨지는 일을 줄여 줍니다. 이 양식들이 회원 여러분의 다음 프로젝트에서 그런 역할을 하기를 바랍니다.