《함께 만드는 힘》

공개 커뮤니티는 누구에게나 열고, 공동사업의 권리와 책임은 사업자 조합원이 함께 정한다.

이 장은 2026년 9월 17일 현재 핸드북 개정의 기준이다. 한국인공지능커뮤니티는 사업협동조합 설립을 추진 중이며, 지금은 설립취지·공동사업계획·참여구조를 구체화하는 단계다. 아직 인가·등기를 마친 조합이나 확정된 복지제도가 아니다. 아래 내용은 운영 설계안으로, 채택된 정관·계약·법률의견을 대신하지 않는다.

하나의 사이트, 서로 다른 참여 경로

한국인공지능커뮤니티 사이트는 장차 사업협동조합이 운영하는 공개 플랫폼을 지향한다. 공개 콘텐츠와 핸드북은 일반 이용자도 읽을 수 있다. 계정·게시·댓글·행사 신청은 이용약관, 개인정보 처리, 신고와 이의제기 절차를 마련한 뒤 단계적으로 연다.

네 참여 경로는 사람이나 기관의 등급, 승급 단계가 아니다.

직업으로 지위를 정하지 않는다. 교수나 개발자도 적격 사업자라면 조합원 경로를 선택할 수 있고, 조합원도 전문성 평가는 실제 역량과 기록으로 받는다. 법인 조합원은 회사 자체이며 대표자와 담당자의 권한을 구분한다. 개인사업자는 사업주 본인이 법적 주체다.

관심을 듣는 단계와 정식 동의는 다르다

설립취지와 역할이 아직 구체화되지 않은 단계에서는 잠재적 참여자에게 즉시 활동을 요구하지 않는다. 먼저 관심과 현장의 의견을 듣고 설계에 반영한다.

구체안이 마련되면 목적·공동사업·예상 역할과 부담을 충분히 설명한다. 그 후 정식 추진위원, 법정 발기인, 전문 협력자, 기관 파트너와 성명·소속 공개에 대해 각각 별도로 동의받는다. 참여 소개서 제출이나 개인 담당자의 관심 표명만으로 법적 가입 또는 기관의 공식 참여가 확정되지 않는다.

왜 사업협동조합을 추진하는가

우리의 핵심은 친목이 아니라 공동사업이다. 1인·소규모 AI 관련 사업자들이 공동영업·수주·기술개발·구매·교육과 프로젝트 수행을 반복할 경제적 기반이 필요하다. 이를 위해 「중소기업협동조합법」상 사업협동조합을 우선 추진한다.

다만 사업자등록만으로 조합원이 되는 것은 아니다. 조합원 자격, 업무구역, 공동사업, 발기인·출자·인가 요건은 현행 법령과 관할기관 사전협의로 확인한다. 설립 전 조합 명의로 계약하거나 출자금을 받지 않는다.

연구소는 기술 연구에 집중하는 독립 협력기관이다. 커뮤니티의 상위기관이나 당연한 사이트 운영자로 두지 않는다. 필요한 연구·기술 업무는 다른 협력기관과 마찬가지로 범위와 대가를 계약으로 정한다.

함께 일하고 보상하는 법

조직이나 예산 확보 자체가 목적은 아니다. 회원과 현장의 실제 문제를 바탕으로 공동사업의 목적·대상·성과와 수행책임을 먼저 정하고, 그 일을 지속할 수 있도록 회비·사업수익·민간협력·적법한 공공지원 등 필요한 재원을 설계한다.

Project Cell은 프로젝트별 협업팀이지 그 자체가 법인이나 계약 당사자는 아니다. 시작 전에 다음을 서면으로 합의한다.

• 고객과 참여사의 계약주체, 업무 범위, 일정과 검수
• 영업·기술·제작·운영 등 역할, 의사결정과 책임
• 비용과 위험 부담, 지급일과 성과조건
• 지식재산·기밀·데이터·하자·중도종료·분쟁처리
• 기여 평가의 기준, 증거, 평가자, 정정과 이의제기

업무 대가와 조합의 결산상 잉여금 배당은 다르다. 매출의 일정 비율을 일률적으로 배분하지 않는다. 현금 보수를 노출·명예·점수로 일방 대체하지 않는다. 기술, 지식, 고객 연결, 멘토링, 운영과 돌봄 같은 비금전적 기여도 사전에 합의한 지표와 확인 가능한 기록으로 인정한다.

성장성과 핵심 가치를 지키는 법

자격을 충족한 신규 사업자를 정당한 사유 없이 막지 않는다. 가입 기준, 처리 절차, 보류·거절 사유와 이의제기를 마련한다. 기존 인맥이나 추천, 매출 규모만으로 기회를 독점하지 않는다.

보상과 운영규정은 소급하여 일방 변경하지 않는다. 이해상충 공개와 제척, 임기, 감사, 주요 공동자산의 처분 절차와 규정 버전 기록을 둔다. 어떤 문구도 미래의 왜곡을 완전히 막지는 못하므로 신규 참여, 지급 지연, 기회 편중, 분쟁 처리와 복지 지속성을 계속 측정하고 고친다.

복지는 사업의 상금이 아니다

회원들이 오래 일할 수 있도록 건강·심리·돌봄과 위기 시 생활 보호를 검토한다. GPU·API·공동영업 같은 기업 지원과 사람의 복지를 구분한다. 기본 보호는 매출이나 기여점수 순위의 보상으로 만들지 않는다.

복지재원은 사업 운영비·손실·채무보증에 사용하지 않는 방향으로 설계한다. 다만 별도 계좌만으로 법적 자산 격리가 되는 것은 아니다. 수혜자를 사업주·직원·가족 중 누구로 할지, 재원과 지급 기준, 별도 비영리법인 등 관리수단, 허가·세금·보험·공제·모금 규제를 먼저 검토한다. 현재 모집 중인 복지기금이나 보장되는 급부는 없다.

공개와 비공개의 경계

소개·추진계획·공개 동의를 받은 지식은 공개한다. 고객정보, 계약, 정산, 미공개 기술은 프로젝트 관계자만 접근한다. 조합원도 다른 프로젝트의 정보를 당연히 볼 수 없다. 복지 신청과 건강정보는 별도 권한과 보유기간으로 다룬다.

콘텐츠를 게시했다는 이유만으로 저작권이 조합에 이전되지 않는다. 게시 기능을 열기 전 저작권과 AI 콘텐츠 표시, 개인정보, 신고·삭제·제재·이의제기 정책을 공개한다.

이 핸드북을 읽는 방법

기존 장과 계약 예시는 조직의 초기 구상을 담은 개정 중 참고 원고다. 개인 전문가 회원제, 연구소 운영, 고정 배분율, 근로자성 부인, 포괄적 지식재산 조항은 현행 규정이나 바로 서명할 계약으로 사용하지 않는다. 이 장과 운영 모델 문서를 먼저 읽고, 실제 거래에는 해당 시점의 정관·규정·개별 계약과 전문가 검토를 적용한다.

다음 상태는 사업협동조합 설립 추진계획에서 증빙 가능한 단계만 갱신한다.

우리는 사람이 가진 가능성을 가볍게 여기지 않습니다.

누군가의 기술, 경험, 관계와 시간이 다른 누군가에게는 새로운 기회가 될 수 있다고 믿습니다.

그래서 우리는 서로의 기여를 기억하고, 신뢰를 지키며, 각자의 전문성을 연결해 혼자서는 만들 수 없는 더 큰 가치를 만들고자 합니다.

그리고 함께 만든 성과는 함께 만든 사람들에게 공정하게 돌아가야 한다고 믿습니다.

이 책은 그 약속을 지키기 위한 우리의 기준입니다.

흩어진 사람들

AI 기술은 매달 새로워집니다. 그런데 그 기술을 다루는 사람들은 이상할 만큼 서로 멀리 떨어져 있습니다. 같은 도시에서, 같은 모델을 쓰고, 같은 고민을 하면서도 서로의 존재를 모릅니다. 이 책은 그 거리에서 시작합니다.

먼저 몇 사람의 하루를 보겠습니다. 아래에 등장하는 사람들은 모두 가상의 인물입니다. 그러나 이 장면들이 낯설지 않다면, 이 책은 당신을 위해 쓰인 것입니다.

파운더 박 대표는 물류 회사를 대상으로 AI 상담 자동화 사업을 준비하고 있습니다. 고객사 두 곳이 관심을 보였고, 제안서도 통과했습니다. 문제는 만들 사람입니다. 지인의 소개로 만난 개발자는 포트폴리오는 화려했지만 실제로 LLM 서비스를 운영해 본 적이 없었습니다. 외주 업체는 견적을 세 배로 불렀습니다. 박 대표는 "이 사람이 정말 할 수 있는 사람인지"를 확인할 방법이 없어 두 달째 착수를 미루고 있습니다.

연구자 이 교수는 멀티모달 모델의 환각 억제를 연구합니다. 논문은 꾸준히 나오지만, 정작 이 연구가 어떤 산업 문제에 쓰이는지는 알지 못합니다. 기업에서 가끔 연락이 오지만 대부분 "자문 한 번 해 주십시오"에서 끝납니다. 연구실 학생들은 실제 데이터로 검증할 기회를 원하는데, 그 데이터를 가진 기업과 연결될 통로가 없습니다.

연구원 정 박사는 기업 연구소에서 나와 독립했습니다. 논문을 읽고 재현하는 데는 누구보다 빠릅니다. 하지만 GPU가 없습니다. 클라우드 비용은 개인이 감당하기 어렵고, 함께 실험할 동료도 없습니다. 좋은 아이디어를 노트에만 적어 두는 날이 늘어 갑니다.

개발자 김 씨는 에이전트 시스템을 만드는 실력이 뛰어납니다. 오픈소스에 기여도 하고, 기술 블로그도 씁니다. 그런데 일감은 늘 지인을 통해서만 들어옵니다. 영업을 해 본 적이 없어 고객 앞에서 자신의 가치를 설명하지 못합니다. 결국 헐값에 일을 받고, 요구사항이 늘어나도 추가 비용을 말하지 못하며, 정산이 미뤄져도 독촉하지 못합니다.

크리에이터 최 씨는 AI 영상 도구를 1년 넘게 파고들었습니다. 이제 광고 영상 한 편을 사흘 만에 만들 수 있습니다. 하지만 이 실력을 사 줄 고객이 어디 있는지 모릅니다. SNS에 작품을 올리면 "대단하다"는 댓글은 달리지만 일로 이어지지는 않습니다. 가끔 들어오는 일은 단가가 너무 낮거나, 결과물을 받고 연락이 끊기는 경우입니다.

마케터 한 팀장은 AI 캠페인을 기획해야 합니다. 대행사에 맡기자니 AI를 제대로 이해하는 곳이 없고, 직접 하자니 개발자·크리에이터·데이터 전문가를 한 명씩 찾아 팀을 꾸릴 시간이 없습니다. 오픈채팅방에 "함께 하실 분"이라고 올리면 수십 명이 연락하지만, 누가 진짜 실력자인지는 만나 봐야 압니다. 만나 보고 나서도 확신이 서지 않습니다.

이 여섯 사람은 서로를 필요로 합니다. 박 대표는 김 씨를, 김 씨는 박 대표를, 이 교수는 정 박사와 기업의 데이터를, 최 씨는 한 팀장을 필요로 합니다. 이들이 한 팀이 된다면 어느 대기업의 AI 사업부 못지않은 결과를 낼 수 있습니다. 그런데 이들은 서로의 존재를 모릅니다. 알게 되더라도 믿을 수 있는지 확인할 길이 없습니다. 확인이 되더라도 함께 일하고 정산하는 방법이 없습니다.

이것이 우리가 해결하려는 문제입니다. 기술의 문제가 아니라 사람과 사람 사이의 문제입니다.

사람을 더 모으는 것으로는 풀리지 않습니다

이런 문제 앞에서 흔히 나오는 답은 "사람을 더 모으자"입니다. 회원이 만 명이면 그 안에 좋은 개발자도, 좋은 사업가도 있을 것이라는 생각입니다.

우리는 그 방식을 택하지 않습니다. 이유는 간단합니다. 사람이 많아질수록 발견의 비용은 오히려 커지기 때문입니다. 천 명이 있는 방에서 믿을 만한 한 사람을 찾는 일은, 열 명이 있는 방에서 찾는 일보다 어렵습니다. 방이 커질수록 소음은 늘고, 광고가 들어오고, 실력자는 조용해지고, 목소리 큰 사람이 눈에 띕니다.

회원 숫자, 게시물 수, 조회수는 커뮤니티의 건강을 말해 주지 않습니다. 우리가 중요하게 여기는 자산은 다릅니다. 사람, 전문역량, 기여, 신뢰, 협력의 경험, 그리고 함께 만들어낸 성과입니다. 이 자산은 사람을 모은다고 저절로 생기지 않습니다. 설계해야 생깁니다.

그래서 우리는 다른 질문을 던집니다. "어떻게 더 많은 사람을 모을까"가 아니라 "어떻게 좋은 사람이 좋은 사람을 빨리 발견하고, 발견된 관계가 실제 실행으로 이어지게 할까"입니다. 조직의 경쟁우위는 인원수가 아니라 매칭의 정확도와 신뢰의 밀도에서 나옵니다.

네 번째 길

사람이 함께 일하는 방식은 크게 세 가지가 있었습니다.

첫째는 위계(Hierarchy), 즉 전통적인 기업입니다. 고용으로 사람을 묶고 명령으로 조정합니다. 안정적이지만 느리고, 개인의 독립성을 희생합니다. 박 대표가 김 씨를 정규직으로 채용하면 문제는 풀리지만, 김 씨는 자신의 다른 가능성을 접어야 합니다.

둘째는 시장(Market), 즉 프리랜서와 외주입니다. 계약으로 사람을 묶고 가격으로 조정합니다. 유연하지만 신뢰가 축적되지 않습니다. 프로젝트가 끝나면 관계도 끝나고, 다음 프로젝트에서는 탐색과 검증의 비용을 처음부터 다시 치릅니다.

셋째는 느슨한 커뮤니티, 즉 오픈채팅과 SNS입니다. 관심사로 사람을 모으고, 아무것도 조정하지 않습니다. 정보는 흐르지만 책임도 보상도 없습니다. 한 팀장이 오픈채팅방에서 겪은 일이 바로 이것입니다.

우리는 네 번째 길을 만들려고 합니다. 프로토콜 조직(Protocol Organization) 입니다. 사람을 고용이 아니라 공유된 규약과 기록된 신뢰로 묶는 조직입니다. 구성원은 각자의 회사, 직장, 연구실을 유지합니다. 좋은 기회가 생기면 필요한 사람들이 결합해 하나의 Project Cell(프로젝트 셀)을 만들고, 일이 끝나면 해체합니다. 그 과정에서 누가 무엇을 기여했고 약속을 어떻게 지켰는지가 기록으로 남습니다. 그 기록이 다음 결합의 근거가 됩니다.

회사도 아니고, 시장도 아니고, 채팅방도 아닙니다. 신뢰 네트워크 위에서 작동하는 실행 조직입니다. 이 책의 나머지 전부는 이 한 문장을 풀어 쓴 것입니다. 왜 이런 조직이 지금 가능해졌는지는 제1장에서, 왜 기존 커뮤니티로는 안 되는지는 제2장에서, 그 설계 원리는 제3장 이후에서 다룹니다.

이 조직이 작동하는 공식

한국인공지능커뮤니티(Korea AI Community)의 모든 제도와 화면과 규칙은 하나의 공식 위에 서 있습니다.

CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK

이 공식을 한 단계씩 풀어 보겠습니다. 이 여덟 단어를 이해하면 이 책의 절반을 이해한 것입니다.

CAPABILITY(역량). 모든 것은 한 사람이 무엇을 할 수 있는가에서 시작합니다. 직함이나 소속이 아닙니다. 우리는 사람을 하나의 Capability Node(역량 노드)로 봅니다. 개발 실력만 역량이 아닙니다. 연구, 영업, 마케팅, 제작, 네트워크, 리더십, 자본 모두 동등한 역량입니다. 유명하거나 직급이 높은 사람만 가치 있는 것이 아닙니다.

CONTRIBUTION(기여). 역량은 쓰일 때 비로소 의미가 있습니다. 지식을 나누고, 프로젝트에 참여하고, 사람을 소개하고, 인프라를 내놓고, 후배를 돕는 모든 행위가 기여입니다. 우리는 기여를 기록합니다. 기여한 사람을 잊지 않는다는 것은 감상적인 구호가 아니라 플랫폼의 데이터 구조입니다.

TRUST(신뢰). 기여가 쌓이면 신뢰가 됩니다. 여기서 신뢰란 인성에 대한 평가가 아닙니다. 약속을 지켰는가, 정산을 투명하게 했는가, 비밀을 지켰는가, 함께 일한 사람이 다시 함께 일하고 싶어 하는가에 대한 행동의 기록입니다. 이를 Trust Capital(신뢰 자산)이라고 부릅니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

COLLABORATION(협력). 신뢰가 있어야 결합이 빨라집니다. 처음 만난 사람과 계약서부터 쓰는 대신, 기록된 신뢰를 보고 곧바로 Project Cell을 만들 수 있습니다. 협력은 대화가 아니라 실행입니다. 사업가와 개발자와 연구자와 크리에이터와 마케터가 각자의 자리를 지키면서 하나의 팀처럼 움직입니다.

VALUE(가치). 협력은 혼자서는 만들 수 없는 결과를 만듭니다. 고객, 매출, 제품, 연구 성과, 재사용 가능한 자산이 여기서 나옵니다. 각자의 몫을 먼저 나누지 않습니다. 먼저 함께 더 큰 가치를 만듭니다.

REWARD(보상). 만들어진 가치는 기여한 사람에게 돌아가야 합니다. 실제 수행한 일에는 시장 단가로 먼저 보상하고(Work Compensation), 그 위에 생긴 잉여가치는 실제 기여에 따라 나눕니다(Value Sharing). 똑같이 나누는 것이 공정한 것이 아닙니다. 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다.

GROWTH(성장). 보상은 돈만이 아닙니다. 평판, 관계, 기술, 다음 기회가 함께 옵니다. 프로젝트를 하나 마친 사람은 그 전보다 더 신뢰받는 사람이 되고, 더 큰 프로젝트에 초대받습니다. 개인이 성장하고, 그 개인이 만든 회사가 성장합니다.

GIVE BACK(환원). 성장한 사람은 다시 기여합니다. 후배를 멘토링하고, 배운 것을 공유하고, 자신이 받은 기회를 다음 사람에게 엽니다. 강제된 기부가 아닙니다. 순환이 설계된 생태계에서는 환원이 다음 세대의 CAPABILITY가 되어 공식이 다시 처음부터 돌기 시작합니다.

이 공식에는 빠진 것이 하나 있습니다. 권력입니다. 의도적입니다. 운영 권한을 가진 사람이 사업기회를 우선 가져가는 순간 이 공식은 무너집니다. 그래서 우리는 처음부터 원칙을 세웁니다. Governance Power ≠ Economic Opportunity. 이 원칙은 제24장에서 자세히 다룹니다.

AI 시대라는 조건

왜 지금인가라는 질문에 답해야 합니다. 이런 조직은 예전에도 꿈꿀 수 있었습니다. 그런데 왜 지금 가능하고, 왜 지금 필요한가.

AI는 실행의 비용을 낮췄습니다. 코드를 짜고, 영상을 만들고, 문서를 쓰는 일이 몇 년 전과는 비교할 수 없이 싸졌습니다. 한 사람이 할 수 있는 일의 범위가 넓어졌습니다. 그런데 바로 그 이유로, 한 사람이 감당해야 할 범위도 넓어졌습니다. 개발자가 영업을 해야 하고, 크리에이터가 기술을 익혀야 하고, 사업가가 모델의 한계를 이해해야 합니다.

실행이 싸지면 무엇이 비싸질까요. 판단, 관계, 책임입니다. 어떤 문제를 풀 것인가를 판단하는 일, 누구와 함께할 것인가를 정하는 관계, 결과에 대해 책임지는 일은 AI가 대신해 주지 않습니다. "누구를 믿고 무엇을 맡길 것인가"가 가장 비싼 질문이 되었습니다.

그래서 결합이 필요합니다. 그리고 결합을 빠르고 안전하게 만드는 것이 신뢰의 기록입니다. AI 도구와 에이전트는 Project Cell의 구성원이 아닙니다. 구성원의 역량을 증폭하는 장비입니다. 책임은 언제나 사람이 집니다. 이 조건에 대한 자세한 논의는 제1장에서 이어집니다.

이 책을 읽는 법

이 책은 규정집 30%, 조직철학 30%, 공동사업 매뉴얼 30%, 사례 10%로 구성되어 있습니다. 한 조직의 헌법이면서 동시에 문화책입니다. 처음부터 끝까지 읽어도 좋고, 필요한 장만 찾아 읽어도 좋습니다. 독자에 따라 권하는 읽기 순서는 다음과 같습니다.

신규회원이라면 Prologue와 Part 1, Part 2를 먼저 읽으십시오. 이 조직이 사람을 어떻게 바라보고 무엇을 약속하는지를 이해하는 것이 먼저입니다. Part 3의 제9장과 제11장은 가입 전에 반드시 읽어야 합니다. 울타리를 왜 만드는지, 무엇이 신뢰를 깨는 행동인지를 알아야 안에서 안전하게 활동할 수 있습니다.

기존회원이 공동 프로젝트를 앞두고 있다면 Part 4와 Part 5를 다시 읽으십시오. 특히 제14장의 Project Charter(프로젝트 헌장) 작성법, 제17장의 고객 관계 원칙, 제20장과 제22장의 보상 설계는 프로젝트 시작 전에 참여자 전원이 같은 기준을 공유해야 하는 내용입니다.

Circle Leader(서클 리더)라면 Part 6의 제25장이 운영의 기준입니다. Circle은 채팅방이 아니라 결과물을 만드는 실행 공동체입니다. 제26장의 갈등 해결 절차와 제24장의 이해상충 원칙도 함께 읽어야 합니다. 리더는 회원보다 더 많은 것을 회피해야 하는 사람입니다.

Project Lead(프로젝트 리드)라면 Part 4 전체와 Appendix가 실무 도구입니다. Project Charter, Contribution Matrix(기여도 평가표), Project Settlement Sheet(정산표)는 그대로 가져다 쓸 수 있도록 만들었습니다. 제16장은 Lead의 권한과 책임을, 제18장은 프로젝트가 실패했을 때의 종료 원칙을 다룹니다.

추진위원과 임원이라면 이 책 전체가 의사결정의 기준입니다. 특히 제24장 "권력과 돈을 분리한다"는 임원이 가장 먼저 읽고 가장 자주 다시 읽어야 하는 장입니다. 조직의 신뢰는 위에서부터 무너지기 쉽습니다.

책의 구성

이 책은 일곱 개의 Part와 Appendix로 이루어져 있습니다.

Prologue  왜 우리는 새로운 종류의 AI 커뮤니티를 만드는가
Part 1    우리는 왜 함께하려 하는가            (제1장~제4장)
Part 2    사람을 어떻게 바라볼 것인가           (제5장~제8장)
Part 3    프라이빗 커뮤니티와 신뢰              (제9장~제12장)
Part 4    함께 사업하는 법                      (제13장~제18장)
Part 5    기여와 보상의 원칙                    (제19장~제22장)
Part 6    조직과 거버넌스                       (제23장~제26장)
Part 7    성장하는 생태계                       (제27장~제29장)
Appendix  양식·헌장·체크리스트                  (A~G)

Part 1은 문제에서 출발합니다. 혼자 일하는 AI 전문가의 한계, 기존 커뮤니티의 한계, 그리고 우리가 만들려는 Private Professional Community의 모습과 약속을 다룹니다.

Part 2는 사람을 보는 눈입니다. 사람을 직함이 아니라 Capability로 보는 관점, 실력의 여러 종류, 등급이 아닌 역할과 책임, 그리고 Member에서 Fellow에 이르는 성장의 사다리를 설명합니다.

Part 3은 신뢰입니다. 왜 울타리를 만드는지, 신뢰가 어떻게 행동의 기록으로 만들어지는지, 무엇이 신뢰를 깨는지, 그리고 어디까지 공유하고 어디부터 보호하는지를 다룹니다. 이 책에서 가장 중요한 Part입니다.

Part 4는 함께 사업하는 법입니다. Project Cell의 구조, 프로젝트의 시작, 참여자 선정, Project Lead의 의사결정, 고객 관계, 그리고 실패의 처리까지 실무를 다룹니다. 분량이 가장 많습니다.

Part 5는 기여와 보상입니다. 기여의 정의, Work Compensation과 Value Sharing의 두 층, 돈 외의 보상, 그리고 공평과 공정의 차이를 실제 금액 사례로 설명합니다.

Part 6은 거버넌스입니다. Association, Council, Circle, Project Cell, Member, Partner의 6층 구조와 권력·기회의 분리, Circle 운영, 분쟁 해결 절차를 다룹니다.

Part 7은 생태계입니다. Give Back의 문화, 커뮤니티가 기업을 만드는 AI 10K Initiative, 그리고 우리가 그리는 10년 후의 모습으로 마무리합니다.

Appendix에는 바로 쓸 수 있는 문서 일곱 개가 있습니다. Korea AI Community Charter, Project Charter, Contribution Matrix, Project Settlement Sheet, Project Closing Review, Confidentiality Checklist, Conflict of Interest Declaration입니다.

이 책이 약속하는 것과 약속하지 않는 것

이 책은 완성된 답이 아닙니다. 커뮤니티가 성장하면서 이 책도 함께 고쳐질 것입니다. 이 책에 나오는 숫자들은 대부분 "기본값(Default)"이며, 각 프로젝트의 Project Charter로 조정할 수 있습니다. 규칙이 많다고 느껴진다면 그것은 우리의 실패입니다. 우리가 바라는 것은 이 책을 덮으면서 "이 조직은 사람을 이렇게 대하고, 이렇게 함께 일하려는 곳이구나"라고 이해하는 것입니다.

이 책이 약속하지 않는 것도 분명히 하겠습니다. 이 책은 가입하면 일감이 생긴다고 약속하지 않습니다. 기여 없이 보상이 있다고 약속하지 않습니다. 오래 있었다는 이유로 더 많은 기회가 온다고 약속하지 않습니다. 과거의 기여는 신뢰를 만들지만 영구적인 권리는 만들지 않습니다.

대신 이 책은 다음을 약속합니다. 사람을 소모품처럼 다루지 않겠습니다. 기여한 사람을 잊지 않겠습니다. 신뢰를 지키는 사람과 더 큰 일을 함께하겠습니다. 함께 만든 성과가 기여한 사람들에게 공정하게 돌아가도록 하겠습니다.

앞의 여섯 사람에게 돌아가 보겠습니다. 박 대표가 김 씨의 기록된 신뢰를 보고 한 주 만에 착수를 결정하는 것. 이 교수의 연구가 정 박사의 재현과 H3Lab의 GPU를 거쳐 기업의 실제 데이터로 검증되는 것. 최 씨의 영상 실력이 한 팀장의 캠페인을 만나 정당한 대가를 받는 것. 그리고 이들이 함께 만든 성과가 다음 프로젝트의 근거가 되고, 성장한 이들이 다음 사람을 끌어올리는 것. 우리가 만들려는 것은 바로 이 장면입니다.

좋은 사람이 좋은 사람을 만나고, 좋은 기술이 좋은 사업을 만나며, 함께한 사람들이 혼자였을 때보다 더 크게 성장하는 조직. 그것이 우리의 목표입니다.

우리는 커뮤니티를 만들려는 것이 아니라, 함께 성장할 수 있는 새로운 방식의 조직을 만들려고 한다.

AI로 강해진 개인은 왜 여전히 힘든가. 각자의 독립성을 유지하면서도 대기업처럼 강한 집단 역량을 가질 수는 없을까.

질문에서 시작합니다

개발자 김 씨는 2년 전 회사를 나왔습니다. AI 코딩 도구 덕분에 혼자서도 예전 팀 셋이 하던 일을 해낼 수 있게 되었기 때문입니다. 첫 몇 달은 좋았습니다. 지인이 소개한 프로젝트를 빠르게 끝냈고, 단가도 나쁘지 않았습니다.

그런데 1년이 지나자 이상한 일이 벌어졌습니다. 일하는 시간은 줄지 않았는데 개발하는 시간은 줄었습니다. 제안서를 쓰고, 견적을 내고, 고객과 회의를 하고, 세금계산서를 발행하고, 미수금을 독촉하고, 새 모델이 나올 때마다 따라잡고, 다음 일감을 찾아 사람을 만나는 데 하루의 절반이 갑니다. 김 씨는 개발자로 독립했는데, 지금은 영업사원이자 회계 담당이자 프로젝트 매니저입니다.

더 큰 문제는 한계가 보인다는 것입니다. 혼자서 받을 수 있는 프로젝트의 크기는 정해져 있습니다. 3천만원짜리는 할 수 있지만 3억원짜리는 손을 대지 못합니다. 혼자서는 빠릅니다. 그런데 멀리 가지는 못합니다.

이 장은 하나의 질문을 붙잡습니다. 각자의 독립성을 유지하면서도 대기업처럼 강한 집단 역량을 가질 수 없을까. 김 씨가 다시 회사에 들어가지 않고도, 3억원짜리 프로젝트를 믿을 만한 사람들과 함께 해낼 수는 없을까.

왜 이것이 문제인가

실행이 싸졌다

AI가 바꾼 것을 한 문장으로 말하면 이렇습니다. 실행의 비용이 낮아졌습니다. 코드를 짜는 비용, 영상을 만드는 비용, 문서와 보고서와 제안서를 쓰는 비용, 데이터를 정리하고 분석하는 비용이 모두 내려갔습니다. 예전에는 팀이 필요했던 일을 한 사람이 며칠 만에 합니다.

개인이 강해졌습니다. 자본이 없어도, 조직이 없어도, 실력 있는 한 사람이 할 수 있는 일의 범위가 넓어졌습니다. 1인기업이 현실적인 선택이 된 것은 이 때문입니다.

그래서 감당할 것이 늘었다

그런데 실행이 싸지자 역설이 생겼습니다. 한 사람이 할 수 있는 일이 늘어나면서, 한 사람이 해야 하는 일도 늘었습니다. 개발자는 영업을 해야 합니다. 고객이 직접 개발자를 찾으니 중간에서 영업을 대신해 줄 회사가 없습니다. 크리에이터는 기술을 익혀야 합니다. 도구가 매달 바뀌고, 도구를 모르면 실력이 아무리 좋아도 뒤처집니다. 사업가는 모델을 이해해야 합니다. 어떤 것이 가능하고 어떤 것이 불가능한지를 모르면 제안서 자체를 쓸 수 없습니다.

한 사람이 이 모든 것을 잘할 수는 없습니다. 잘하려고 하면 정작 자기가 가장 잘하는 일을 할 시간이 사라집니다. 김 씨가 겪는 일이 정확히 이것입니다. 실행은 싸졌는데 실행 이외의 것이 그 자리를 채웠습니다.

실행이 싸지면 무엇이 비싸지는가

여기서 이 책의 가장 중요한 관찰 하나를 꺼내겠습니다. AI가 실행 비용을 낮출수록 판단, 관계, 책임의 가치가 올라갑니다.

세 가지를 나누어 보겠습니다.

판단입니다. 무엇을 만들 것인가, 어떤 문제가 풀 가치가 있는가, 이 고객의 요구 중 무엇이 진짜 요구인가, 이 결과물이 정말 쓸 만한가를 가리는 일입니다. 코드는 싸졌지만 "이 코드가 맞는 코드인가"를 아는 사람은 여전히 드뭅니다. 영상은 싸졌지만 "이 영상이 이 브랜드에 맞는가"를 아는 사람은 여전히 비쌉니다.

관계입니다. 누구와 함께할 것인가, 이 사람을 믿어도 되는가, 이 고객은 정산을 제때 하는가, 이 파트너는 비밀을 지키는가를 아는 일입니다. 실행이 싸지면서 실행할 사람은 많아졌습니다. 그런데 그중 누가 믿을 만한지는 더 알기 어려워졌습니다. 포트폴리오는 AI로 하루 만에 만들 수 있기 때문입니다. "누구를 믿고 무엇을 맡길 것인가"는 지금 가장 비싼 질문입니다.

책임입니다. 결과가 잘못되었을 때 누가 감당하는가입니다. AI는 코드를 짜 주지만 그 코드가 고객의 시스템을 멈추게 했을 때 책임지지 않습니다. 에이전트는 이메일을 보내 주지만 그 이메일이 계약 위반이 되었을 때 사과하지 않습니다. 책임은 언제나 사람이 집니다. 그리고 책임질 수 있는 사람, 책임진 기록이 있는 사람의 가치는 실행이 싸질수록 올라갑니다.

이것이 김 씨의 곤란을 설명합니다. 김 씨는 실행에서 강해졌지만, 시장이 비싸게 사는 것은 이제 판단·관계·책임입니다. 판단은 도메인을 아는 사업가와 연구자에게서, 관계는 신뢰가 축적된 네트워크에서, 책임은 함께 지는 구조에서 나옵니다. 혼자서는 갖출 수 없는 것들입니다.

역할마다 다른 얼굴의 같은 문제

이 문제는 개발자만의 것이 아닙니다.

파운더 박 대표에게는 "누구에게 맡길 것인가"의 문제입니다. 좋은 아이디어와 고객은 있는데, 실행할 사람을 검증할 방법이 없습니다. 한 번 잘못 맡기면 고객과의 관계까지 잃습니다.

연구자 이 교수에게는 "무엇을 위해 연구하는가"의 문제입니다. 논문은 나오지만 산업의 실제 문제를 만나지 못합니다. 실제 문제는 기업이 갖고 있고, 기업은 교수를 자문 이상으로 쓰는 법을 모릅니다.

크리에이터 최 씨에게는 "누가 사 주는가"의 문제입니다. 실력은 늘었지만 실력을 필요로 하는 고객과 만나는 통로가 없습니다. 통로가 있어도 정당한 단가를 받는 법을 모릅니다.

마케터 한 팀장에게는 "어떻게 팀을 꾸리는가"의 문제입니다. 전문가를 한 명씩 찾아 검증하고 조정할 시간이 없습니다.

얼굴은 다르지만 뿌리는 같습니다. 실행은 싸졌고, 결합은 여전히 비쌉니다.

우리의 철학

세 가지 길의 한계

이 문제를 푸는 전통적인 방법은 세 가지였습니다. 위계, 시장, 느슨한 커뮤니티입니다. 제2장에서 자세히 비교하겠지만, 이 장에서는 독립성의 관점에서만 짚겠습니다.

위계(전통 기업)는 결합의 문제를 고용으로 풉니다. 김 씨를 채용하면 박 대표는 검증의 비용을 한 번만 치릅니다. 그러나 김 씨는 독립성을 잃습니다. 회사가 정한 방향 안에서만 일합니다. 대기업은 강하지만 느리고, 개인의 가능성을 가둡니다.

시장(프리랜서·외주)은 결합의 문제를 계약으로 풉니다. 독립성은 유지됩니다. 그러나 신뢰가 축적되지 않습니다. 프로젝트마다 새로 찾고, 새로 검증하고, 새로 계약합니다. 잘된 협업의 기억은 두 사람 사이에만 남고, 조직의 자산이 되지 않습니다.

느슨한 커뮤니티는 결합의 문제를 풀지 않습니다. 사람을 모으기만 하고 조정하지 않습니다. 정보는 흐르지만 누가 믿을 만한지, 누가 무엇을 기여했는지, 결과에 대해 누가 책임지는지가 없습니다.

독립성과 결합성

우리가 지향하는 것은 네 번째 길, 프로토콜 조직입니다. 그 첫 번째 설계 원리가 이 장의 질문에 대한 답입니다. 독립성과 결합성(Independent & Composable) 입니다.

구성원은 각자의 회사, 직장, 연구실을 유지합니다. 김 씨는 계속 1인기업입니다. 이 교수는 계속 대학에 있습니다. 박 대표는 계속 자기 회사를 경영합니다. 아무도 고용되지 않습니다.

그러나 좋은 기회가 생기면 필요한 사람들이 결합합니다. 박 대표의 고객, 김 씨의 에이전트 기술, 이 교수의 모델 검증, 최 씨의 영상, 한 팀장의 캠페인이 하나의 Project Cell(프로젝트 셀)로 묶입니다. 그 순간 이 다섯 사람은 어느 대기업의 AI 사업부 못지않은 집단 역량을 냅니다. 프로젝트가 끝나면 해체합니다. 각자 자기 자리로 돌아갑니다. 그러나 함께 일한 기록은 남고, 다음 결합은 더 빨라집니다.

이것이 "독립성을 유지하면서 대기업급 집단 역량을 낸다"는 말의 뜻입니다. 대기업이 되지 않으면서 대기업처럼 강해지는 것입니다.

사람은 소모품이 아니다

이 결합에서 우리가 절대 놓지 않는 원칙이 하나 있습니다. 사람을 소모품처럼 다루지 않습니다. 시장은 사람을 가격으로 봅니다. 위계는 사람을 직급으로 봅니다. 우리는 사람을 Capability Node(역량 노드), 즉 무엇을 할 수 있는 하나의 가능성으로 봅니다. 결합은 사람을 쓰고 버리는 것이 아니라, 각자의 가능성을 잠시 한 곳에 모으는 것입니다.

결합이 끝났을 때 참여자는 결합 전보다 더 성장해 있어야 합니다. 돈뿐 아니라 신뢰가 쌓이고, 관계가 늘고, 다음 기회가 열려 있어야 합니다.

운영원칙

이 장은 철학의 장이지만, 독립성과 결합성이 실제로 무엇을 뜻하는지 기본값으로 정리합니다. 아래 원칙은 커뮤니티의 기본값(Default)이며, 개별 프로젝트는 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

몇 가지를 덧붙입니다.

1. 독립성은 방임이 아닙니다. 결합한 동안에는 프로젝트 전체의 성공을 개인의 단기이익보다 우선합니다.
2. 결합은 자발적입니다. 누구도 특정 Cell에 참여하도록 강요받지 않습니다. 반대로, 참여를 원한다고 해서 자리를 보장받지도 않습니다. 자리는 기준에 따라 정해집니다.
3. 기존 소속의 규정이 먼저입니다. 재직 중인 회사의 겸업 규정이나 대학의 산학 규정과 충돌하는 참여는 본인이 먼저 정리해야 합니다. 커뮤니티는 이를 대신 판단하지 않습니다.
4. 한 사람이 여러 Cell에 속할 수 있습니다. 다만 Availability(가용성)를 정직하게 밝혀야 합니다. 시간을 과장해서 약속하고 지키지 못하는 것은 실패가 아니라 약속 위반입니다.

Case: 3억원짜리 프로젝트를 혼자 받을 수 없었던 김 씨

아래는 가상의 사례입니다.

상황. 개발자 김 씨에게 물류 기업의 AI 상담 자동화 프로젝트 제안이 들어왔습니다. 예산은 3억원입니다. 요구사항은 LLM 기반 상담 봇, 기존 시스템 연동, 상담 품질 평가 모델, 그리고 도입 안내 영상과 내부 교육 자료까지입니다. 김 씨가 혼자 할 수 있는 부분은 전체의 40% 정도였습니다.

갈등. 선택지는 세 가지였습니다. 거절하거나, 혼자 다 하겠다고 하고 나머지를 급하게 외주로 돌리거나, 팀을 만들거나. 거절은 아까웠고, 외주는 위험했습니다. 외주가 일정을 어기면 고객과의 관계를 김 씨 혼자 책임져야 합니다. 팀이 맞지만, 김 씨는 평가 모델을 만들 연구자도, 영상을 만들 크리에이터도 알지 못했습니다. 안다고 해도 믿을 수 있는지, 정산은 어떻게 할지가 막막했습니다.

적용. 김 씨는 커뮤니티 플랫폼에 Opportunity로 이 기회를 올렸습니다. Builder Circle의 김 씨가 Project Lead를 맡고, Research Circle에서 상담 품질 평가 모델 경험이 있는 연구원 정 박사가, Creator Circle에서 기업 교육 영상 이력이 있는 크리에이터 최 씨가 합류했습니다. 세 사람은 서로 처음이었지만, 플랫폼에 기록된 이전 프로젝트의 정산 이력과 동료 평가를 볼 수 있었습니다. 정 박사는 두 건의 Cell에서 일정을 지켰고, 최 씨는 세 건에서 재협업 의사를 받은 기록이 있었습니다.

세 사람은 1페이지짜리 Project Charter를 썼습니다. 김 씨가 Contracting Party(계약주체)이자 Project Lead, 실행 판단은 김 씨가 하고 보상 구조 변경은 세 명의 합의로 정한다고 적었습니다. Work Compensation(수행 대가)은 각자의 시장 단가로 먼저 정하고, 그 위에 남는 잉여가치는 Contribution Matrix(기여도 평가표)에 따라 나누기로 했습니다. 이 기회를 발굴하고 고객 관계를 가져온 김 씨의 Origination 기여와, 계약과 위험을 짊어진 Leadership & Risk 기여도 Matrix에 명시했습니다.

결과. 프로젝트는 5개월 만에 끝났습니다. 직접비용 4천만원을 제하고, 세 사람의 Work Compensation 합계 1억 6천만원을 먼저 지급했습니다. 남은 잉여가치 1억원 가운데 커뮤니티 기여분(Community Share) 5%인 500만원을 뗀 뒤, 나머지 9천 5백만원을 Matrix에 따라 김 씨 55%, 정 박사 25%, 최 씨 20%로 나누었습니다. 세 사람 모두 시장 단가를 받고도 그 위에 추가 배분을 받았습니다.

숫자보다 중요한 것이 있었습니다. 세 사람은 각자의 자리로 돌아갔습니다. 김 씨는 여전히 1인기업이고, 정 박사는 여전히 독립 연구자이며, 최 씨는 여전히 프리랜서 크리에이터입니다. 그러나 이제 세 사람에게는 함께 3억원짜리 프로젝트를 끝낸 기록이 있습니다. 그 고객이 후속 프로젝트를 제안했을 때, 세 사람은 이틀 만에 다시 Cell을 만들었습니다. 첫 번째에는 검증에 3주가 걸렸던 일입니다.

Remember

• AI는 실행의 비용을 낮췄고, 그래서 개인은 강해졌습니다. 그러나 같은 이유로 한 사람이 감당해야 할 범위도 넓어졌습니다.
• 실행이 싸질수록 판단, 관계, 책임의 가치가 올라갑니다. "누구를 믿고 무엇을 맡길 것인가"가 가장 비싼 질문이 되었습니다.
• 위계는 결합을 주지만 독립성을 빼앗고, 시장은 독립성을 주지만 신뢰를 쌓지 못하며, 느슨한 커뮤니티는 아무것도 조정하지 않습니다.
• 우리는 각자의 자리를 유지한 채 필요할 때 Project Cell로 결합하고 끝나면 해체합니다. 관계는 끝나도 기록은 남습니다.
• 결합은 사람을 쓰고 버리는 것이 아닙니다. 결합이 끝났을 때 참여자는 결합 전보다 더 성장해 있어야 합니다.

"혼자서는 빨라질 수 있다. 그러나 멀리 가려면 독립성을 잃지 않고 결합하는 법을 알아야 한다."

오픈채팅, Facebook Group, Discord, LinkedIn에는 사람도 정보도 넘칩니다. 그런데 왜 거기서는 함께 사업이 만들어지지 않는가.

질문에서 시작합니다

마케터 한 팀장은 AI 캠페인을 위한 팀이 필요했습니다. 그래서 회원 3천 명이 넘는 AI 오픈채팅방에 글을 올렸습니다. "영상 생성 경험 있는 크리에이터와 에이전트 개발자 찾습니다. 프로젝트 기간 두 달." 한 시간 만에 열여덟 명이 연락을 해 왔습니다.

한 팀장은 열여덟 명의 포트폴리오를 받았습니다. 모두 그럴듯했습니다. 다섯 명과 화상회의를 했고, 그중 두 명을 골랐습니다. 첫 번째 크리에이터는 2주 뒤 연락이 끊겼습니다. 두 번째 개발자는 결과물을 냈지만, 나중에 보니 다른 곳에서 만든 것을 그대로 가져온 것이었습니다. 한 팀장은 한 달을 잃었습니다.

한 팀장이 잘못한 것은 없습니다. 그 방은 정보를 나누는 데는 훌륭했습니다. 문제는 한 팀장이 그 방에 없는 것을 그 방에서 찾으려 했다는 것입니다. 누가 믿을 만한지에 대한 기록입니다. 이 장은 기존 커뮤니티에 무엇이 있고 무엇이 없는지를 정확히 가려내는 데서 시작합니다.

왜 이것이 문제인가

정보는 넘친다

먼저 인정할 것이 있습니다. 기존 커뮤니티는 정보를 흘려보내는 데 탁월합니다. 새 모델이 나오면 오픈채팅방이 가장 빠릅니다. 논문 해설은 Facebook Group에 있고, 오픈소스 프로젝트의 실시간 토론은 Discord에 있으며, 경력과 이직 소식은 LinkedIn에 있습니다. 우리는 이 공간들을 대체하려는 것이 아닙니다.

그러나 정보가 넘치는 것과 일이 만들어지는 것은 다릅니다. 한 팀장의 방에 없던 것은 딱 다섯 가지였습니다.

다섯 가지 빈자리

첫째, 누가 믿을 만한지 모릅니다. 프로필은 스스로 쓴 것입니다. 포트폴리오는 검증되지 않았습니다. 발언이 많은 사람이 실력자로 보이고, 실력자는 바빠서 조용합니다. AI가 실행 비용을 낮춘 시대에는 이 문제가 더 심해집니다. 그럴듯한 포트폴리오를 하루에 만들 수 있기 때문입니다. 실행이 싸질수록 "누구를 믿을 것인가"는 비싸지는데, 기존 커뮤니티는 이 질문에 답할 데이터를 갖고 있지 않습니다.

둘째, 공동사업이 어렵습니다. 채팅방에서 "같이 하실 분"으로 시작한 프로젝트는 대부분 흐지부지 끝납니다. 누가 Lead인지, 의사결정은 어떻게 하는지, 돈은 어떻게 나누는지, 고객은 누구 것인지에 대한 합의 틀이 없기 때문입니다. 참고할 기준이 없어 매번 처음부터 협상하고, 협상이 길어지면 열정이 식고, 프로젝트는 사라집니다.

셋째, 기여가 기록되지 않습니다. 어떤 사람이 3년 동안 방에서 질문에 성실히 답하고, 후배의 코드를 봐 주고, 좋은 사람을 소개했다고 합시다. 그 기여는 어디에도 남지 않습니다. 새로 들어온 사람은 그 사람이 누구인지 모릅니다. 기여한 사람을 잊는 구조에서는 기여할 이유가 사라집니다.

넷째, 경제적 보상이 없습니다. 기존 커뮤니티에서 얻는 것은 정보와 인맥이지, 실제로 돈을 벌 수 있는 구조가 아닙니다. 어쩌다 일이 연결되어도 그 뒤의 정산·분쟁·성과는 커뮤니티 밖에서 두 사람이 알아서 할 일입니다. 그래서 커뮤니티에서 만난 일은 자주 헐값이 되고, 자주 미정산으로 끝납니다.

다섯째, 책임 구조가 없습니다. 한 팀장의 첫 번째 크리에이터가 연락을 끊었을 때, 그 사람은 아무런 불이익도 받지 않았습니다. 다른 방에서 같은 일을 반복할 수 있습니다. 두 번째 개발자가 남의 결과물을 가져왔을 때, 한 팀장이 방에 그 사실을 올리면 어떻게 될까요. 여론재판이 벌어지거나, 반대로 한 팀장이 "왜 공개적으로 망신을 주느냐"는 비난을 받습니다. 잘못을 가리고 바로잡는 절차가 없기 때문입니다.

플랫폼마다 다른 한계

오픈채팅은 속도가 장점입니다. 그러나 익명성과 유동성 때문에 신뢰가 쌓일 곳이 없습니다. 오늘 좋은 답을 준 사람이 내일 나가 버립니다. 광고가 섞이고, 관리자는 삭제 외에 할 수 있는 것이 없습니다.

Facebook Group은 실명이 있어 오픈채팅보다 낫습니다. 그러나 구조가 게시물과 댓글이라 지식은 쌓여도 사람에 대한 기록은 쌓이지 않습니다. 피드 알고리즘은 좋은 사람이 아니라 반응이 큰 게시물을 보여 줍니다.

Discord는 개발자 커뮤니티에 잘 맞습니다. 그러나 Discord의 역할은 기술적 권한이지 신뢰의 기록이 아닙니다. 오픈소스에서는 코드 기여가 기록되지만 코드에만 한정됩니다. 고객을 데려오고 위험을 부담한 사람의 기여는 어디에도 없습니다.

LinkedIn은 경력과 평판의 공간입니다. 그러나 경력은 자기 신고이며, 추천은 예의로 주고받습니다. 함께 일한 동료의 평가, 정산 이력, 비밀유지 여부는 볼 수 없습니다. 그리고 사람을 보여 줄 뿐, 함께 일하도록 조정하지 않습니다.

네 공간 모두 사람을 모읍니다. 그러나 어느 곳도 다음 세 가지를 하지 않습니다. 기여를 기록하지 않고, 신뢰를 축적하지 않고, 협력을 조정하지 않습니다.

우리의 철학

세 가지 형태의 비교

사람이 함께 일하는 방식을 세 가지 형태로 놓고 비교하면 빈자리가 어디인지 분명해집니다.

이 표에서 눈여겨볼 것은 마지막 열의 약점입니다. 프로토콜 조직은 저절로 굴러가지 않습니다. 규약을 지키는 문화가 없으면 느슨한 커뮤니티로 되돌아갑니다. 그래서 이 책이 필요합니다.

커뮤니티가 아니라 조직

한국인공지능커뮤니티는 이름에 "커뮤니티"가 들어 있지만, 우리가 만들려는 것은 위 표의 세 번째 열이 아니라 네 번째 열입니다. 회사도 아니고, 시장도 아니고, 채팅방도 아닌, 신뢰 네트워크 위에서 작동하는 실행 조직입니다.

이 조직은 세 형태의 장점을 가져오고 약점을 버리려 합니다. 위계에서 책임 구조를 가져오되 고용은 하지 않습니다. 시장에서 유연성과 시장 단가를 가져오되 신뢰가 사라지게 두지 않습니다. 느슨한 커뮤니티에서 개방성과 정보의 흐름을 가져오되 조정 없이 두지 않습니다.

그 대신 두 가지를 더합니다. 공유된 규약과 기록된 신뢰입니다. 규약은 Project Charter(프로젝트 헌장), Contribution Matrix(기여도 평가표), Project Settlement Sheet(정산표) 같은 문서와, 이 책에 담긴 원칙입니다. 기록된 신뢰는 플랫폼에 쌓이는 기여와 행동의 이력, 즉 Trust Capital(신뢰 자산)입니다. 규약이 있어서 매번 처음부터 협상하지 않아도 되고, 기록이 있어서 매번 처음부터 검증하지 않아도 됩니다.

우리는 무엇이 달라야 하는가

한 팀장의 다섯 가지 빈자리를 하나씩 채우면 우리가 달라야 할 것이 나옵니다.

누가 믿을 만한지 알 수 있어야 합니다. 그래서 우리는 신뢰를 자기소개가 아니라 행동의 기록으로 봅니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

공동사업이 가능해야 합니다. 그래서 우리는 Project Cell(프로젝트 셀)이라는 결합의 단위와, 1~2페이지의 Project Charter라는 합의의 틀을 둡니다.

기여가 기록되어야 합니다. 그래서 플랫폼은 Knowledge, Research, Technology, Mentoring, Project, Event, Connection, Infrastructure의 기여를 기록합니다. 기여한 사람을 잊지 않습니다.

경제적 보상이 있어야 합니다. 그래서 우리는 지식 공유에서 멈추지 않고 실제 프로젝트와 매출과 회사로 이어지는 구조를 만듭니다. 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다.

책임 구조가 있어야 합니다. 그래서 Project Lead가 실행을 책임지고, 윤리·분쟁위원회(Ethics & Dispute Committee)가 분쟁을 다루며, 실패에는 관대하되 부정직에는 엄격합니다.

운영원칙

기존 커뮤니티와 구분되는 최소한의 운영 기준을 정리합니다. 아래는 커뮤니티의 기본값(Default)이며, 세부 절차는 해당 장과 Project Charter에서 정합니다.

여기에 세 가지 경계를 덧붙입니다.

1. 기존 커뮤니티를 버리라는 뜻이 아닙니다. 정보를 얻고 넓은 관계를 유지하는 데는 그 공간이 낫습니다. 우리는 그 위에 신뢰와 실행의 층을 더하는 것입니다.
2. 울타리는 배제가 아닙니다. 검증은 기존 회원을 보호하기 위해서가 아니라 구성원 간의 신뢰와 정보, 사업기회와 관계를 보호하기 위한 것입니다. 새로운 사람도 역량과 신뢰를 보여 주면 참여하고 성장할 수 있어야 합니다. 제9장 참조.
3. 규약이 많아지는 것을 경계합니다. 규칙은 신뢰를 대신하지 못합니다. 규칙은 신뢰가 작동할 수 있는 최소한의 틀이어야 합니다.

Case: 같은 사람, 다른 구조

아래는 가상의 사례입니다. 앞의 한 팀장이 1년 뒤 같은 종류의 프로젝트를 다시 맡았다고 가정합니다.

상황. 이번에도 두 달짜리 AI 캠페인이고, 크리에이터 한 명과 개발자 한 명이 필요합니다. 예산은 6천만원입니다. 한 팀장은 이번에는 커뮤니티 플랫폼의 Opportunity에 기회를 올렸습니다.

갈등. 지원자는 여섯 명이었습니다. 열여덟 명보다 적어 처음에는 불안했습니다. 그런데 여섯 명의 화면을 열어 보니 지난번과 다른 것이 있었습니다. 각자가 참여한 Project Cell의 이력, 그 Cell의 Project Closing Review(종료평가)에서 받은 동료 평가, 일정 준수 여부, 그리고 함께 일한 사람이 재협업 의사를 표시했는지가 보였습니다. 크리에이터 최 씨는 세 건의 Cell을 마쳤고 세 건 모두에서 재협업 의사를 받았습니다. 개발자 한 명은 Cell 이력이 없는 신규회원이었지만 AI TEST 인증과 Builder Circle에서의 Knowledge 기여 기록이 있었습니다.

적용. 한 팀장은 최 씨를 크리에이터로, 이력이 많은 개발자 김 씨를 개발 담당으로 정하고, 신규회원인 개발자에게 Junior Slot을 열어 김 씨 아래에서 일부 모듈을 맡겼습니다. 네 사람은 Project Charter를 썼습니다. 한 팀장이 Originator이자 Contracting Party이고 Project Lead입니다. Work Compensation은 최 씨 1천 8백만원, 김 씨 2천만원, 신규회원 6백만원으로 시장 단가에 맞춰 먼저 정했습니다. 직접비용 6백만원을 제한 잉여가치 1천만원은 Community Share 5%인 50만원을 뗀 뒤 Contribution Matrix에 따라 나누기로 했습니다.

결과. 프로젝트는 일정 안에 끝났습니다. 남은 9백 5십만원은 기회를 가져오고 위험을 진 한 팀장 50%, 김 씨 25%, 최 씨 20%, 신규회원 5%로 나누어졌습니다. 신규회원은 첫 Cell 이력과 세 사람의 동료 평가를 얻었습니다. 다음 기회에서 그는 더 이상 이력 없는 지원자가 아닙니다.

한 팀장의 사람 보는 눈이 갑자기 좋아진 것이 아닙니다. 달라진 것은 구조였습니다. 기록이 있어서 검증이 빨랐고, Charter가 있어서 합의가 빨랐고, 정산 원칙이 있어서 끝이 깔끔했습니다. 그리고 이 프로젝트의 기록이 다시 네 사람의 다음 프로젝트를 빠르게 만듭니다.

Remember

• 기존 커뮤니티는 정보를 흘려보내는 데 탁월하며, 우리는 그것을 대체하려는 것이 아닙니다.
• 그러나 그곳에는 다섯 가지가 없습니다. 누가 믿을 만한지에 대한 기록, 공동사업의 틀, 기여의 기록, 경제적 보상, 책임 구조입니다.
• 위계는 책임을 주지만 독립성을 빼앗고, 시장은 독립성을 주지만 신뢰를 남기지 않으며, 느슨한 커뮤니티는 아무것도 조정하지 않습니다.
• 우리는 세 형태의 장점을 가져오고, 공유된 규약과 기록된 신뢰를 더합니다. 규약이 있어 매번 협상하지 않고, 기록이 있어 매번 검증하지 않습니다.
• 규칙은 신뢰를 대신하지 못합니다. 규칙은 신뢰가 작동할 수 있는 최소한의 틀입니다.

"사람을 더 모으는 것이 아니라, 기여를 기록하고 신뢰를 축적하고 협력을 조정하는 구조가 커뮤니티를 조직으로 만든다."

이 장은 "우리는 어떤 종류의 조직을 만들려는가"에 답합니다. 단순 커뮤니티와 Professional Guild의 차이, 정보공유가 사업으로 이어지는 다섯 단계, 그리고 한국인공지능커뮤니티가 지향하는 네 번째 조직 형태인 프로토콜 조직을 정식으로 정의합니다.

질문에서 시작합니다

가상의 상황 하나를 떠올려 보겠습니다. 파운더 박 대표는 AI 관련 오픈채팅 세 곳, 페이스북 그룹 두 곳, 디스코드 서버 한 곳에 들어가 있습니다. 회원 수를 합치면 2만 명이 넘습니다. 그런데 "도메인 데이터로 소형 언어모델을 파인튜닝해 본 사람"을 찾으려 하자, 결국 예전 직장 동료에게 전화를 걸어 소개를 부탁합니다.

2만 명이 있는 곳에서 왜 한 사람을 찾지 못했을까요. 사람이 없어서가 아닙니다. 누가 그 사람인지 알 수 없고, 안다고 해도 믿고 맡길 근거가 없으며, 함께 일하기로 해도 어떤 규칙으로 일하고 어떻게 나눌지 매번 처음부터 정해야 하기 때문입니다.

그렇다면 문을 닫고 소수만 남기면 해결될까요. 열 명이 매달 모여 식사하는 친목 모임도 사업을 만들지 못하기는 마찬가지입니다. 서로를 잘 알지만 그 관계를 실행으로 옮길 구조가 없기 때문입니다. 질문은 규모가 아니라 종류에 관한 것입니다. 우리가 만들려는 것은 커뮤니티라는 이름을 붙인 또 하나의 채팅방이 아닙니다. 역량이 발견되고, 기여가 기록되고, 신뢰가 쌓이고, 그 신뢰 위에서 실제 일이 일어나는 Private Professional Community입니다.

왜 이것이 문제인가 — 커뮤니티와 길드는 다르다

단순 커뮤니티는 관심사로 사람을 모읍니다. 들어오는 데 비용이 없고, 나가는 데도 비용이 없으며, 안에서 무엇을 하든 책임이 없습니다. 이것은 결함이 아니라 설계입니다. 정보가 넓게 퍼지는 데는 이보다 좋은 구조가 없습니다. 하지만 정보가 퍼지는 것과 일이 일어나는 것은 다른 문제입니다.

역사 속의 길드는 다르게 설계되었습니다. 중세의 장인 길드는 아무나 들어올 수 없었습니다. 도제 기간과 품질 기준이 있었고, 한 장인의 잘못이 길드 전체의 평판에 영향을 주었기에 서로가 서로를 보증했습니다. 규약을 어기면 잃는 것이 분명했습니다. 오늘날의 프로페셔널 길드도 뼈대는 같습니다. 자격이 있고, 기준이 있고, 분쟁을 다루는 절차가 있고, 구성원은 자기 이름을 걸고 일합니다.

물론 길드에는 진입을 막아 기득권을 지킨 그림자도 있었습니다. 우리가 가져오려는 것은 그림자가 아니라 뼈대입니다. 울타리는 기존 회원의 이익이 아니라 구성원 간의 신뢰와 정보, 사업기회와 관계를 보호하기 위한 것입니다(제9장 참조).

AI 시대라는 조건은 이 차이를 더 크게 만듭니다. 코드와 영상과 문서를 만드는 비용은 빠르게 내려갔고, 최신 모델의 사용법과 벤치마크는 공개 인터넷에 넘칩니다. 정보를 나누는 것만으로 존재 이유를 가지던 커뮤니티는 그 이유를 잃어 갑니다. 대신 비싸진 것이 있습니다. 누구를 믿을 것인가, 무엇을 맡길 것인가, 문제가 생기면 누가 책임지는가. 우리가 만들려는 조직은 바로 그 비싸진 것을 다루는 조직입니다.

정보공유에서 사업까지 — 다섯 단계

첫 번째 단계는 정보공유입니다. 누군가 자신이 실제로 해본 것을 이야기합니다. 어떤 모델이 어떤 데이터에서 무너졌는지, 어떤 워크플로우가 실제 납품에서 통했는지. 뉴스 링크가 아니라 경험입니다. 중요한 단계지만 여기서 멈추면 뉴스레터와 다르지 않습니다. 대부분의 AI 커뮤니티가 이 단계에 머뭅니다.

두 번째 단계는 관계입니다. 이름과 얼굴을 알게 됩니다. 어떤 사람이 어떤 질문을 하고 어떤 답을 하는지 지켜보게 됩니다. Circle의 소모임, 작은 스터디, 발표 뒤의 대화가 여기에 해당합니다. 친목 모임은 이 단계에서 멈춥니다.

세 번째 단계는 신뢰입니다. 관계가 신뢰로 바뀌는 지점은 작은 약속이 지켜지는 순간입니다. 벤치마크를 이번 주까지 정리하겠다고 했고 실제로 했습니다. 회의에서 들은 다른 회원의 미공개 정보를 밖에 옮기지 않았습니다. 소액의 공동 작업에서 정산이 깔끔했습니다. 신뢰는 말이 아니라 행동으로 쌓습니다. 그리고 이 행동은 기록되어야 다음 사람에게도 신뢰가 됩니다. 이것이 Trust Capital(신뢰 자본)입니다. 외주 플랫폼은 이 단계를 건너뛰고 곧바로 협력으로 가려 하기 때문에 매번 검증 비용을 다시 치릅니다.

네 번째 단계는 협력입니다. 신뢰가 있는 사람들이 Project Cell(프로젝트 셀)을 만듭니다. 목적과 범위, 역할과 보상 구조를 Project Charter(프로젝트 헌장)에 적고 실제 결과물을 만듭니다. 이 단계에서 비로소 커뮤니티는 실행 조직이 됩니다.

다섯 번째 단계는 사업입니다. 협력이 고객을 만나고, 매출이 생기고, 반복되고, 필요하다면 회사가 됩니다. AI 10K Initiative가 이 단계를 겨냥합니다(제28장 참조).

다섯 단계에는 순서가 있습니다. 관계 없이 신뢰가 생기지 않고, 신뢰 없이 협력을 시작하면 위험하며, 협력 없이 사업을 논하면 공허합니다. 동시에 순환합니다. 사업에서 얻은 경험이 다시 정보공유가 되고, 정산이 깔끔했던 기억이 다음 신뢰가 됩니다. 커뮤니티의 역할은 사람을 더 많이 모으는 것이 아니라 각 단계에서 다음 단계로 넘어가는 문턱을 낮추는 것입니다.

역할에 따라 막히는 단계는 다릅니다. 개발자는 관계까지는 쉽게 가지만 고객과 계약을 다뤄본 적이 없어 사업 단계에서 막힙니다. 사업가는 누가 진짜 실력자인지 판별할 방법이 없어 신뢰 단계에서 막힙니다. 교수와 연구원은 산업의 실제 문제를 만날 통로가 없어 협력 단계로 가지 못합니다. 크리에이터와 마케터는 관계는 넓지만 기술 파트너를 검증할 수 없습니다. 하나의 조직이 여섯 역할의 병목을 모두 낮출 수 있다면, 그 조직은 사람 수가 적어도 강합니다.

우리의 철학 — 네 번째 길, 프로토콜 조직

사람이 함께 일하는 방식은 오랫동안 크게 세 가지였습니다.

위계(Hierarchy) 는 전통적인 기업입니다. 고용으로 사람을 묶고 명령으로 조정합니다. 안정적이고 책임이 분명하지만 느리고, 구성원은 독립성을 내놓아야 합니다. 거래비용이라는 개념으로 설명하듯, 기업이 존재하는 이유는 시장에서 매번 사람을 찾고 계약하고 감시하는 비용이 크기 때문입니다. 그 비용을 줄이려고 사람을 안에 들이고 대신 자유를 가져갑니다.

시장(Market) 은 프리랜서와 외주입니다. 계약으로 사람을 묶고 가격으로 조정합니다. 유연하지만 신뢰가 축적되지 않습니다. 이번에 잘한 사람이 다음에 다시 검증받아야 하고, 거래가 끝나면 관계도 끝납니다.

느슨한 커뮤니티 는 오픈채팅과 SNS입니다. 관심사로 사람을 모으고 아무것도 조정하지 않습니다. 정보는 흐르지만 책임도 보상도 없습니다. 무언가를 함께 만들려면 결국 위계나 시장으로 돌아가야 합니다.

세 형태는 각각 무언가를 포기합니다. 위계는 독립성을, 시장은 신뢰의 축적을, 느슨한 커뮤니티는 실행을 포기합니다. 우리는 셋 중 하나를 고르지 않고 네 번째 길을 갑니다.

프로토콜 조직(Protocol Organization) 은 사람을 고용이 아니라 공유된 규약(프로토콜)과 기록된 신뢰로 묶고, 필요할 때 결합하고 끝나면 해체되는 조직입니다. 회사도 아니고 시장도 아니고 채팅방도 아닌, 신뢰 네트워크 위에서 작동하는 실행 조직입니다. 한국인공지능커뮤니티가 지향하는 형태가 바로 이것입니다.

프로토콜이란 함께 일할 때 매번 다시 정하지 않아도 되는 약속의 묶음입니다. 프로젝트는 어떻게 시작하는가, 팀은 어떤 기준으로 꾸리는가, 결정은 누가 하는가, 보상은 어떻게 나누는가, 고객은 누구의 것인가, 문제가 생기면 어떤 순서로 푸는가. 이 약속이 공유되어 있으면 처음 만난 두 사람도 빠르게 결합할 수 있습니다. 기록된 신뢰란 그 약속을 실제로 지켰다는 이력입니다. 프로토콜은 결합의 속도를 만들고, 기록된 신뢰는 결합의 안전을 만듭니다.

이 생각은 완전히 새롭지 않습니다. 영화 산업은 프로젝트마다 팀을 모으고 끝나면 해체합니다. 오픈소스 재단은 고용 없이 규약과 기여 기록만으로 수천 명의 협업을 조정합니다. 협동조합은 구성원이 소유하고 결정하며, 팀 오브 팀스 모델은 중앙 명령 대신 공유된 맥락으로 작은 팀들을 움직입니다. DAO의 실험은 규약을 코드로 옮기려 했으나 사람의 판단과 책임을 빼놓은 지점에서 한계를 드러냈습니다. 우리는 이들에게서 결합과 해체, 기여 기록, 공정한 배분, 공유된 맥락을 가져오고, 규약이 사람의 판단을 대신할 수 있다는 믿음은 버립니다. AI 도구와 에이전트는 Project Cell의 구성원이 아니라 구성원의 역량을 증폭하는 장비이며, 책임은 언제나 사람이 집니다.

프로토콜 조직의 6가지 설계 원리

이 책의 나머지 장은 모두 아래 여섯 원리를 풀어 쓴 것입니다.

1. 독립성과 결합성(Independent & Composable). 구성원은 각자의 회사, 직장, 연구실을 유지합니다. 필요할 때 Project Cell로 결합하고 끝나면 해체합니다. 독립성을 잃지 않으면서 대기업급 집단 역량을 냅니다. (제13장)
2. 사람은 Capability Node(역량 노드)다. 직함이 아니라 무엇을 할 수 있는가로 봅니다. Technical, Research, Business, Sales, Marketing, Creative, Network, Leadership, Capital은 모두 동등한 기여 가능성입니다. (제5장, 제6장)
3. 기여는 기록된다(Recorded Contribution). 기여한 사람을 잊지 않습니다. 플랫폼은 기여를 기록하고 축적합니다. 기록이 있어야 신뢰가 되고, 신뢰가 있어야 다음 협력이 생깁니다. (제19장)
4. 신뢰는 행동의 원장이다(Trust as Ledger). 신뢰는 인성평가가 아니라 약속 준수, 정산, 일정, 비밀유지, 결과물, 동료평가, 재협업 의사의 기록입니다. 이것을 Trust Capital이라 부릅니다. (제10장)
5. 권력과 기회의 분리(Governance Power ≠ Economic Opportunity). 운영 권한을 가진 사람이 사업기회를 우선 가져가지 않습니다. 이해상충은 회피(Recusal)합니다. (제24장)
6. 순환(Give Back). 성장한 사람이 다시 기여합니다. 강제 기부가 아니라 생태계의 순환 설계입니다. (제27장)

여섯 원리는 서로를 떠받칩니다. 독립성이 있어야 사람들이 자유롭게 들어오고, 사람을 역량으로 봐야 결합이 정확해지고, 기여가 기록되어야 신뢰가 쌓이고, 신뢰가 원장이 되어야 권력이 아닌 기록으로 기회가 배분되고, 기회가 공정하게 흐르면 순환이 일어납니다. 하나가 빠지면 나머지도 흔들립니다.

운영원칙

프로토콜 조직이 되기 위해 커뮤니티가 갖추는 최소한의 구성입니다. 숫자는 커뮤니티의 기본값(Default)이며 Project Charter로 조정할 수 있습니다.

다섯 단계마다 커뮤니티가 제공하는 것도 다릅니다. 정보공유에는 Circle과 Closed Room을, 관계에는 "I CAN OFFER / I AM LOOKING FOR" 프로필을, 신뢰에는 작은 기여의 기록을, 협력에는 Charter 양식과 정산표를, 사업에는 앵커 조직의 인프라를 제공합니다. 실행은 빠르게, 이해관계 변경은 합의로. 그리고 커뮤니티를 특정 회사의 외주 인력풀로 만들지 않습니다.

경계 상황도 정해 둡니다. 회원이 Charter 없이 다른 회원과 사적으로 일을 시작하는 것은 금지되지 않습니다. 각자의 독립성은 존중됩니다. 다만 그 일은 커뮤니티의 기록에 남지 않고, 문제가 생겨도 분쟁 절차를 쓸 수 없으며, 그 경험은 Trust Capital이 되지 않습니다. 프로토콜은 강제가 아니라 선택입니다. 선택하지 않으면 얻지 못하는 것이 있을 뿐입니다.

Case: 스터디 모임이 Project Cell이 되기까지

다음은 가상의 사례입니다.

Builder Circle의 Agent 소그룹에 개발자 김 씨, 연구자 이 박사, 마케터 정 씨가 있었습니다. 처음 석 달은 정보공유였습니다. 김 씨는 에이전트 프레임워크 세 가지를 실무에 적용한 결과를 올렸고, 이 박사는 도구 호출 정확도 벤치마크를 공유했으며, 정 씨는 고객사가 AI 도입을 미루는 실제 이유를 Chatham House Rule 아래에서 이야기했습니다. 넉 달째에 관계가 생겼습니다. 이 박사는 벤치마크 정리를 약속한 날짜에 냈고, 김 씨는 정 씨의 고객사 이름을 밖에서 언급하지 않았습니다. 작은 일이었지만 플랫폼에 Knowledge와 Research 기여로 기록되었습니다.

다섯 달째에 파운더 박 대표가 Founder Circle을 통해 기회를 가져왔습니다. 한 중견 제조업체가 사내 문서 검색·요약 자동화 PoC를 원했고 예산은 3천만원이었습니다. 박 대표는 처음에 "아는 개발자 둘이랑 그냥 빨리 하겠다"고 했습니다. Circle Leader는 막지 않았습니다. 다만 두 가지를 물었습니다. 그 개발자들이 에이전트 기반 문서 처리를 실제로 해봤는지 확인할 수 있는가. PoC가 잘 되어 후속 계약이 생겼을 때 누가 어떤 기여를 인정받을지 지금 정해 두었는가.

박 대표는 답하지 못했고, 대신 플랫폼에서 Agent 소그룹의 기여 기록을 열어 보았습니다. 네 사람은 Project Cell을 만들고 Charter를 썼습니다. 박 대표가 Project Lead와 Originator, 김 씨가 Executor(기술), 이 박사가 Executor(평가 설계), 정 씨가 고객 커뮤니케이션을 맡았습니다. Work Compensation은 시장 단가 기준으로 김 씨 1,200만원, 이 박사 500만원, 정 씨 300만원으로 먼저 정했습니다. 직접비용 200만원을 빼면 잉여가치는 800만원, 이 중 5%인 40만원이 Community Share로, 나머지 760만원이 Contribution Matrix에 따라 배분되도록 적었습니다.

PoC는 6주 만에 끝났고 고객은 1억원 규모의 본 구축을 논의하기 시작했습니다. 이때 고객사 담당자가 정 씨에게 "다음 건은 박 대표 없이 직접 하면 안 되겠느냐"고 물었습니다. 정 씨는 Charter의 Non-circumvention(우회 금지) 조항을 확인했습니다. 커뮤니티를 통해 만난 고객과 소개자를 배제하고 직접 거래하는 것은 기본 24개월간 금지되어 있었습니다. 정 씨는 고객에게 그 사실을 설명하고 박 대표에게 그대로 전했습니다. 박 대표는 그 행동을 Project Closing Review에 기록했습니다.

프로토콜이 한 일은 무엇입니까. 기록이 있었기에 사람을 찾는 시간이 줄었습니다. 친분 대신 역량과 신뢰로 팀을 골랐습니다. 갈등이 생겼을 때 다툼 대신 조항을 확인했습니다. 그리고 정 씨가 유혹을 거절한 행동은 다음 프로젝트에서 정 씨를 먼저 찾게 만드는 이유가 되었습니다.

Remember

우리가 만들려는 것은 정보가 흐르는 곳이 아니라 일이 일어나는 곳입니다. 단순 커뮤니티와 Professional Guild의 차이는 규모가 아니라 기준, 기록, 절차의 유무입니다.

커뮤니티가 사업이 되는 길은 정보공유, 관계, 신뢰, 협력, 사업의 다섯 단계를 지납니다. 커뮤니티의 역할은 사람을 더 모으는 것이 아니라 각 단계의 문턱을 낮추는 것입니다.

위계는 독립성을, 시장은 신뢰의 축적을, 느슨한 커뮤니티는 실행을 포기합니다. 프로토콜 조직은 공유된 규약과 기록된 신뢰로 사람을 묶어 그 셋을 모두 지키려는 네 번째 길입니다.

여섯 가지 설계 원리는 독립성과 결합성, Capability Node, 기록된 기여, 행동의 원장으로서의 신뢰, 권력과 기회의 분리, 순환입니다. 이 책의 나머지는 모두 이 여섯 원리의 해설입니다.

"회사도 아니고 시장도 아니고 채팅방도 아닌, 신뢰 네트워크 위에서 작동하는 실행 조직."

이 장은 "이 조직은 회원에게 무엇을 약속하고, 회원에게 무엇을 요구하는가"에 답합니다. 다섯 가지 약속을 하나씩 풀고, 각 약속이 커뮤니티에 요구하는 것과 회원에게 요구하는 것을 나란히 놓습니다.

질문에서 시작합니다

가상의 장면입니다. 개발자 최 씨는 지난해 어느 스타트업의 외주 프로젝트에 참여했습니다. 3개월 동안 밤을 새워 모델 파이프라인을 만들었고 결과물은 고객에게 납품되었습니다. 그 뒤로 최 씨는 그 회사에서 연락을 받지 못했습니다. 후속 프로젝트가 있었다는 사실은 나중에 다른 사람에게 들었습니다. 최 씨의 이름은 어디에도 남지 않았습니다.

이 이야기에는 법을 어긴 사람이 없습니다. 계약대로 일했고 계약대로 받았습니다. 그런데도 최 씨는 다시는 그 회사와 일하고 싶지 않습니다. 무엇이 잘못되었을까요. 약속이 없었던 것입니다. 일이 끝난 뒤에도 기여를 기억하겠다는 약속, 다음 기회가 생기면 먼저 떠올리겠다는 약속, 함께 만든 성과를 함께 나누겠다는 약속이 처음부터 없었습니다.

조직은 규칙만으로 움직이지 않습니다. 규칙은 무엇을 하면 안 되는지를 정하지만, 약속은 무엇을 하겠다는 것인지를 정합니다. 사람들은 규칙이 촘촘한 곳이 아니라 약속이 지켜지는 곳에 남습니다. 이 장은 한국인공지능커뮤니티가 회원에게 하는 다섯 가지 약속을 다룹니다. 그리고 약속은 한쪽만 지킬 수 없기에, 각 약속이 회원에게 요구하는 것도 함께 다룹니다.

왜 약속이 필요한가

제3장에서 우리는 프로토콜 조직을 정의했습니다. 고용이 아니라 공유된 규약과 기록된 신뢰로 사람을 묶는 조직입니다. 그런데 고용이 없다는 것은 붙잡는 힘이 없다는 뜻이기도 합니다. 회사는 월급으로 사람을 붙잡고, 시장은 다음 계약으로 사람을 붙잡습니다. 프로토콜 조직에는 그 둘이 없습니다. 사람들이 이곳에 남을 이유는 오직 하나, 이곳이 자신을 어떻게 대하는가입니다.

AI 시대는 이 문제를 더 날카롭게 만듭니다. 실행 비용이 내려가면서 한 사람이 감당할 수 있는 일의 범위가 넓어졌습니다. 개발자 혼자 서비스를 만들고, 크리에이터 혼자 광고 캠페인을 만듭니다. 혼자서도 꽤 할 수 있는 사람들에게 함께하자고 말하려면, 함께하는 편이 더 낫다는 것을 약속으로 보여 주어야 합니다. 함께하면 더 큰 일을 할 수 있다는 약속만으로는 부족합니다. 그 큰 일에서 자신이 소모되지 않고, 잊히지 않고, 공정하게 나눈다는 약속이 있어야 합니다.

약속이 없는 협력은 어떻게 무너지는지 우리는 알고 있습니다. 처음에는 좋은 의도로 시작합니다. 일이 잘되면 나누자고 말합니다. 그런데 일이 잘되는 순간, 누가 얼마나 기여했는지를 두고 기억이 갈립니다. 기록이 없으니 목소리 큰 사람의 기억이 이깁니다. 한 번 그런 일을 겪은 사람은 다음부터 먼저 자기 몫을 챙깁니다. 각자의 몫을 먼저 나누려는 순간 협력은 끝납니다. 약속은 이 순서를 뒤집기 위해 필요합니다. 먼저 함께 더 큰 가치를 만들고, 그 가치를 실제 기여와 책임에 따라 나눈다는 순서를 미리 정해 두는 것입니다.

우리의 철학 — 다섯 가지 약속

한국인공지능커뮤니티는 회원에게 다음 다섯 가지를 약속합니다.

1. 사람을 소모품처럼 다루지 않는다.
2. 기여한 사람을 잊지 않는다.
3. 신뢰를 지키는 사람과 더 큰 일을 한다.
4. 함께 만든 성과는 공정하게 나눈다.
5. 혼자서는 만들 수 없는 더 큰 기회를 함께 만든다.

이 다섯 약속은 이 책을 관통하는 공식의 다른 표현입니다. CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK. 첫 번째 약속은 사람을 Capability로 보는 출발점이고, 두 번째는 Contribution의 기록이며, 세 번째는 Trust가 Collaboration으로 이어지는 원리이고, 네 번째는 Value와 Reward의 관계이며, 다섯 번째는 Growth와 Give Back으로 닫히는 순환입니다.

약속은 계약이 아닙니다. 계약은 어기면 배상하지만, 약속은 어기면 관계가 끝납니다. 그래서 약속은 계약보다 가볍게 들리지만 실제로는 더 무겁습니다. 아래에서 다섯 약속을 하나씩 풀고, 각 약속이 커뮤니티에 요구하는 것과 회원에게 요구하는 것을 나란히 놓습니다. 약속은 언제나 양방향입니다.

첫 번째 약속. 사람을 소모품처럼 다루지 않는다

소모품은 쓰고 버리는 것입니다. 필요할 때 부르고, 일이 끝나면 잊고, 다음에 더 싼 사람이 있으면 바꿉니다. 많은 조직이 사람을 이렇게 씁니다. 나쁜 의도가 있어서가 아니라 그렇게 하지 않을 구조가 없어서입니다.

커뮤니티가 회원을 값싼 노동력이나 외주 인력풀로 취급하는 순간 이 약속은 깨집니다. 그래서 우리는 Work Compensation(수행 대가)을 시장 단가 기준으로 먼저 지급하도록 기본값을 정합니다. "나중에 잘되면 나누자"는 말로 지금의 노동을 헐값에 사지 않습니다. Community Share(커뮤니티 기여분)는 Work Compensation에서 떼지 않고 잉여가치에서만 뗍니다. 커뮤니티조차 회원의 노동에 손대지 않는다는 뜻입니다. 앵커 조직도 예외가 아닙니다. 앵커는 동등한 생태계 파트너 중 먼저 온 조직일 뿐이며, 커뮤니티를 특정 회사의 인력풀로 만들지 않습니다.

이 약속이 회원에게 요구하는 것도 있습니다. 다른 회원을 소모품처럼 다루지 않는 것입니다. 프로젝트에서 신규회원에게 잡일만 맡기고 이름을 남기지 않는 것, 크리에이터에게 "간단한 거니까" 하며 시장 단가 이하를 제안하는 것, 연구자의 결과를 가져다 쓰면서 출처를 지우는 것. 모두 이 약속의 위반입니다. 사람을 소모품으로 다루지 않는 조직은 회원 각자가 서로를 그렇게 대할 때만 가능합니다.

두 번째 약속. 기여한 사람을 잊지 않는다

기여는 돈이나 노동시간만이 아닙니다. 기술, 연구, 지식, 콘텐츠, 고객 연결, 영업, 마케팅, 투자, 멘토링, 소개, 데이터, GPU와 인프라, 공간, 운영, 그리고 커뮤니티를 위해 쓴 시간. 이 모두가 기여입니다. 문제는 이 중 대부분이 눈에 보이지 않는다는 것입니다. 코드는 저장소에 남지만, 고객을 소개한 전화 한 통은 어디에도 남지 않습니다.

커뮤니티는 이 약속을 지키기 위해 기여를 기록합니다. 플랫폼은 Knowledge, Research, Technology, Mentoring, Project, Event, Connection, Infrastructure의 여덟 유형으로 기여를 기록하고 축적합니다. 프로젝트가 끝나면 Contribution Matrix(기여도 평가표)를 작성하고, 고객을 가져온 Originator는 같은 고객의 후속 프로젝트에서 기본 24개월간 체감하는 소개 기여를 인정받습니다. 기록은 기억을 대신합니다. 기억은 편향되지만 기록은 남습니다.

다만 잊지 않는 것과 영구적인 권리는 다릅니다. Contribution creates Trust, not Permanent Privilege. 과거의 기여는 신뢰를 만들지만 영원한 지분을 만들지 않습니다. 24개월이라는 기본값은 기여를 인정하되 그것이 다음 세대의 기회를 막지 않도록 하는 균형점입니다.

회원에게 요구하는 것은 기여를 기록에 남기는 습관입니다. 자신이 한 일을 플랫폼에 적는 것은 자랑이 아니라 의무입니다. 기록하지 않은 기여는 커뮤니티가 기억할 수 없습니다. 그리고 다른 사람의 기여를 자기 것으로 적지 않는 것입니다. 기여 가로채기는 실패가 아니라 부정직이며, 우리는 실패에는 관대하되 부정직에는 엄격합니다.

세 번째 약속. 신뢰를 지키는 사람과 더 큰 일을 한다

신뢰는 자기소개나 직함으로 만들어지지 않습니다. 약속을 지켰는가, 맡은 일을 제대로 했는가, 정산을 투명하게 했는가, 동료를 존중했는가, 비밀을 지켰는가, 관계를 악용하지 않았는가, 함께 일한 사람들이 다시 함께 일하고 싶어 하는가. 이 행동의 기록이 Trust Capital(신뢰 자본)입니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

커뮤니티가 이 약속을 지킨다는 것은 Trust Capital이 높은 사람에게 실제로 더 깊은 네트워크와 더 큰 협력 기회가 열린다는 뜻입니다. 팀 구성 기준은 Capability + Experience + Trust + Availability + Fit이며, 친분 순이 아닙니다. 임원이나 오래된 회원이라는 이유로 기회를 먼저 받지 않습니다. Governance Power ≠ Economic Opportunity. 기회는 공개 채널로 흐르고, 그 기회를 누가 잡는지는 기록된 신뢰가 결정합니다.

동시에 이 약속은 신뢰를 깬 사람에게는 문이 좁아진다는 뜻이기도 합니다. 고객 우회, 정보 유출, 기여 가로채기, 대금 미정산, 반복적 약속 위반은 경고, 프로젝트 참여 제한, 등급 조정, 제명으로 이어집니다. 다만 그 판단은 단체방의 여론이 아니라 윤리·분쟁위원회의 절차로 합니다. 신뢰를 지키는 조직은 신뢰를 잃은 사람을 다루는 방식에서도 신뢰할 만해야 합니다.

회원에게 요구하는 것은 작은 약속부터 지키는 것입니다. 큰 프로젝트를 맡기 전에 작은 벤치마크 정리를 제때 내는 것, 회의에서 들은 이야기를 밖으로 옮기지 않는 것, 소액 정산을 미루지 않는 것. Trust Capital은 큰 사건이 아니라 작은 행동의 누적입니다. 그리고 실패했을 때 숨기지 않는 것입니다. 기술 실패와 일정 실패는 신뢰를 깎지 않습니다. 은폐가 깎습니다.

네 번째 약속. 함께 만든 성과는 공정하게 나눈다

공정하게 나눈다는 말은 똑같이 나눈다는 말이 아닙니다. 공평(Equal)과 공정(Fair)은 다릅니다. 1/n 배분은 기본값이 아닙니다. 다섯 명이 참여했다고 다섯으로 나누면, 가장 많이 기여한 사람이 다음에는 오지 않습니다.

커뮤니티는 보상을 두 층으로 나눕니다. Work Compensation은 실제 수행한 업무의 대가이며 먼저 지급합니다. Value Sharing(가치 배분)은 매출에서 직접비용과 Work Compensation을 뺀 잉여가치를 Contribution Matrix에 따라 나누는 것입니다. 기여 범주는 기회 발굴, 영업, 수행, 리더십과 위험부담, 자본과 인프라, 네트워크, 지식의 일곱 가지입니다. 영업만 기여가 아니고 기술만 기여가 아닙니다.

가상의 숫자로 보겠습니다. 5천만원짜리 프로젝트에서 직접비용이 500만원, Work Compensation 합계가 3천만원이면 잉여가치는 1,500만원입니다. Community Share 5%인 75만원을 제하면 1,425만원이 Value Sharing 대상입니다. 이것을 Contribution Matrix에 따라 Originator, Executor, Project Lead가 나눕니다. 누가 얼마를 받는지는 Charter를 쓸 때 정하고, 바꿀 때는 참여자 합의로 바꿉니다. 실행은 빠르게, 이해관계 변경은 합의로. 제20장과 제22장에서 자세히 다룹니다.

회원에게 요구하는 것은 각자의 몫을 먼저 계산하지 않는 것입니다. 프로젝트 전체의 성공을 개인의 단기이익보다 우선합니다. 그리고 자기 기여를 부풀리지 않는 것입니다. 비용 부풀리기와 기여 과장은 공정한 배분의 기반 자체를 무너뜨립니다. 공정함은 커뮤니티가 정한 공식이 아니라 회원들이 정직하게 적은 숫자 위에서만 작동합니다.

다섯 번째 약속. 혼자서는 만들 수 없는 더 큰 기회를 함께 만든다

앞의 네 약속이 지켜지면 무엇이 가능해집니까. 사업가가 믿을 수 있는 기술자를 만나고, 개발자가 시장과 고객을 만나고, 교수가 산업의 실제 문제를 만나고, 크리에이터가 고객을 만나고, 마케터가 실행 팀을 꾸릴 수 있게 됩니다. 각자 자기 회사와 직장을 유지하면서 필요할 때 Project Cell로 결합해 대기업급 역량을 냅니다. 이것이 다섯 번째 약속입니다.

커뮤니티는 이 약속을 위해 기회가 흐르는 통로를 만듭니다. Circle은 채팅방이 아니라 결과물을 만드는 실행 공동체이고, 플랫폼의 Opportunity는 기회를 공개적으로 흘려보내며, AI 10K Initiative는 커뮤니티에서 1만 개의 AI 사업과 회사를 키우자는 목표를 겁니다. 앵커 조직의 GPU, 테스트베드, 기업 고객 연결, 교육, 인증은 회원이 쓸 수 있는 인프라로 열립니다.

회원에게 요구하는 것은 성장한 뒤 돌아오는 것입니다. Give Back은 강제 기부가 아닙니다. 프로젝트 잉여가치의 일부가 신규회원의 성장에 쓰이고, Leader와 Fellow가 된 사람이 다음 사람을 멘토링하고, 자기가 받았던 첫 기회를 다른 신규회원에게 여는 것입니다. 팀을 꾸릴 때 신규회원에게 최소 한 자리를 열어 두는 것을 권장하는 이유가 여기 있습니다. 혼자서는 만들 수 없는 기회는 누군가 먼저 문을 열어 주었기 때문에 생긴 것입니다.

운영원칙 — 약속이 요구하는 것과 돌려주는 것

다섯 약속을 커뮤니티의 의무와 회원의 의무로 나란히 놓으면 다음과 같습니다.

이 약속이 지켜질 때 각 역할의 회원이 얻는 가치는 다음과 같습니다.

누구도 단순히 커뮤니티 숫자를 채우는 회원이 되어서는 안 됩니다. 이 표의 어느 칸에도 자기가 얻을 것이 없다면, 커뮤니티가 약속을 지키지 못하고 있는 것입니다. 위 숫자는 커뮤니티의 기본값이며 Project Charter로 조정할 수 있습니다.

Case: 약속이 시험받는 순간

다음은 가상의 사례입니다.

Creator Circle의 크리에이터 윤 씨는 AI 영상 제작 경력이 2년이었고, 커뮤니티에 가입한 지 석 달 된 Verified 회원이었습니다. 마케터 정 씨가 한 화장품 브랜드의 캠페인 영상 프로젝트를 Opportunity에 올렸고, Project Lead를 맡은 정 씨는 팀을 꾸리면서 윤 씨를 Junior Slot으로 불렀습니다. 예산 4천만원, 기간 8주였습니다.

첫 번째 시험은 보상에서 왔습니다. 정 씨는 처음에 윤 씨에게 "경력이 짧으니 이번엔 경험 쌓는다 생각하고 200만원에 하자"고 제안했습니다. 시장 단가는 그 세 배였습니다. Circle Leader가 Charter 검토에서 이를 지적했습니다. 첫 번째 약속의 위반이었습니다. 정 씨는 제안을 철회하고 Work Compensation을 시장 단가인 600만원으로 다시 적었습니다. 대신 윤 씨의 Value Sharing 비중은 신규 참여자로서 낮게 잡았고, 윤 씨는 그 구조에 동의했습니다. 수행 대가를 깎지 않되 잉여가치 배분은 기여에 따라 달리한다는 원칙이 여기서 작동했습니다.

두 번째 시험은 기여에서 왔습니다. 프로젝트 중반에 윤 씨가 만든 프롬프트 워크플로우가 제작 시간을 절반으로 줄였습니다. 정 씨는 고객 보고서에 이를 팀의 성과로 적으면서 윤 씨의 이름을 빼려 했습니다. 고객 앞에서 신입의 이름을 내세우기 어색하다는 이유였습니다. 이번에는 윤 씨가 아니라 같은 팀의 개발자 김 씨가 문제를 제기했습니다. 두 번째 약속의 문제였습니다. 정 씨는 보고서를 고쳤고, 플랫폼에 윤 씨의 Technology 기여를 기록했으며, 그 워크플로우는 Charter 기본값에 따라 만든 참여자 공동 소유에 커뮤니티 회원 비독점 재사용 라이선스로 귀속되었습니다.

프로젝트는 성공했습니다. 매출 4천만원에서 직접비용 400만원과 Work Compensation 합계 2,400만원을 빼면 잉여가치는 1,200만원이었습니다. Community Share 60만원을 제한 1,140만원이 Contribution Matrix에 따라 배분되었고, 윤 씨는 워크플로우 기여가 인정되어 처음 정한 비중보다 높은 몫을 받았습니다. 배분 비중 변경은 참여자 전원의 합의로 이루어졌습니다.

여섯 달 뒤 정 씨가 다음 프로젝트를 꾸릴 때 가장 먼저 부른 사람은 윤 씨였습니다. 세 번째 약속입니다. 그리고 윤 씨는 그 프로젝트에서 자기가 받았던 Junior Slot을 다른 신규회원에게 열었습니다. 다섯 번째 약속입니다. 정 씨가 두 번 흔들렸던 것은 기록에 남았지만, 두 번 모두 고쳤다는 것도 기록에 남았습니다. 실패에는 관대하되 부정직에는 엄격하다는 원칙은 고칠 기회를 준다는 뜻이기도 합니다.

Remember

약속은 규칙보다 가볍게 들리지만 더 무겁습니다. 규칙은 어기면 배상하지만 약속은 어기면 관계가 끝납니다.

다섯 약속은 사람을 소모품처럼 다루지 않고, 기여한 사람을 잊지 않고, 신뢰를 지키는 사람과 더 큰 일을 하고, 함께 만든 성과를 공정하게 나누고, 혼자서는 만들 수 없는 기회를 함께 만든다는 것입니다.

약속은 양방향입니다. 커뮤니티가 Work Compensation을 먼저 지급하고 기여를 기록하고 기회를 공개로 흘려보내는 만큼, 회원은 다른 회원을 값싸게 쓰지 않고 자기 기여를 정직하게 적고 성장한 뒤 돌아옵니다.

이 약속이 지켜지는지는 선언문이 아니라 Charter의 숫자, 플랫폼의 기록, 그리고 다음 프로젝트에서 누가 누구를 먼저 부르는가로 확인됩니다.

"우리는 사람을 소모품처럼 다루지 않고, 기여한 사람을 잊지 않는다."

이 장은 "우리는 사람을 무엇으로 보는가"에 답합니다. 직함이 아니라 무엇을 할 수 있는가로 사람을 보는 이유, 사람 = Capability Node라는 개념, 그리고 플랫폼의 프로필이 "I CAN OFFER / I AM LOOKING FOR"로 구성되는 이유와 자기 역량을 기술하는 방법을 다룹니다.

질문에서 시작합니다 — 명함이 말해 주지 않는 것

가상의 장면입니다. 어느 모임에서 명함 세 장을 받았습니다. 하나는 "OO대학교 교수", 하나는 "OO스타트업 대표", 하나는 "OO기업 선임연구원"입니다. 이 세 장으로 알 수 있는 것은 무엇입니까. 소속과 직급입니다. 알 수 없는 것은 무엇입니까. 이 교수가 산업 데이터를 실제로 다뤄 봤는지, 이 대표가 직접 코드를 짜는지 아니면 영업만 하는지, 이 연구원이 논문을 쓰는 사람인지 모델을 배포하는 사람인지입니다.

그리고 함께 일하는 데 정말 필요한 정보는 뒤쪽입니다. 파운더 박 대표가 찾는 사람은 "교수"가 아니라 "제조 현장 데이터로 이상 탐지 모델을 만들어 본 사람"입니다. 개발자 김 씨가 찾는 사람은 "대표"가 아니라 "B2B 고객에게 PoC를 팔아 본 사람"입니다. 명함은 소속을 말하고, 일은 역량을 묻습니다.

명함이 없는 사람도 있습니다. 회사를 그만두고 1인 기업을 시작한 크리에이터, 박사과정을 마치고 진로를 정하지 않은 연구자, 직장에 다니면서 주말에 에이전트를 만드는 개발자. 이들에게는 내세울 직함이 없지만 역량은 있습니다. 직함으로 사람을 보는 조직에서 이들은 보이지 않습니다. 이 장은 우리가 사람을 다르게 보기로 한 이유를 설명합니다.

왜 이것이 문제인가 — 직함의 세 가지 실패

직함은 오랫동안 사람을 빠르게 판단하는 도구였습니다. 조직이 위계로 움직이던 시대에 직함은 그 사람이 어디에서 무엇을 결정할 수 있는지를 알려 주었습니다. 그러나 프로토콜 조직에서 직함은 세 가지 방식으로 실패합니다.

첫째, 직함은 소속을 말할 뿐 역량을 말하지 않습니다. 같은 "선임연구원"이라도 한 사람은 데이터 파이프라인을 만들고 다른 사람은 정책 보고서를 씁니다. 같은 "대표"라도 한 사람은 기술 창업자이고 다른 사람은 영업 창업자입니다. 직함으로 팀을 꾸리면 필요한 역량이 빠지고 불필요한 역량이 겹칩니다.

둘째, 직함은 서열을 만듭니다. 교수가 있는 자리에서 석사 개발자가 말을 아끼고, 대표가 있는 자리에서 마케터가 의견을 접습니다. 그런데 실제 프로젝트에서 가장 중요한 판단이 그 석사 개발자나 마케터에게서 나올 때가 많습니다. 서열은 정보의 흐름을 막고, 막힌 정보는 프로젝트를 실패하게 합니다.

셋째, 직함은 한 사람의 여러 역량 중 하나만 보여 줍니다. 교수이면서 창업을 두 번 해본 사람, 개발자이면서 유튜브 채널을 운영하는 사람, 마케터이면서 파이썬으로 데이터 분석을 하는 사람. AI 시대에 이런 사람은 예외가 아니라 보통입니다. 실행 비용이 내려가면서 한 사람이 감당하는 범위가 넓어졌기 때문입니다. 직함은 그 넓어진 범위의 한 조각만 보여 줍니다.

AI 시대의 조건은 이 실패를 더 크게 만듭니다. 조직의 경쟁우위는 인원수가 아니라 매칭의 정확도와 신뢰의 밀도입니다. 매칭이 정확하려면 사람을 기술하는 단위가 정확해야 합니다. "교수"라는 단위로는 매칭이 되지 않습니다. "산업용 시계열 데이터 이상 탐지, 실제 공장 두 곳에서 검증, 논문 세 편, 주 1일 가능"이라는 단위라야 매칭이 됩니다.

우리의 철학 — 사람은 Capability Node다

한국인공지능커뮤니티는 조직 구성원 한 사람 한 사람을 가볍게 여기지 않습니다. 모든 사람은 서로 다른 경험, 기술, 지식, 네트워크와 가능성을 가진 하나의 중요한 Capability입니다. 유명하거나 직급이 높은 사람만 가치 있는 것이 아닙니다. 각자가 가진 역량과 수준에 맞게 참여하고 기여할 수 있어야 하며, 실제 기여에는 적절한 인정과 보상이 따라야 합니다.

이것을 우리는 사람 = Capability Node(역량 노드) 라고 표현합니다. 노드라는 말은 네트워크에서 온 것입니다. 노드는 혼자서는 점 하나지만 다른 노드와 연결될 때 경로가 되고 구조가 됩니다. 사람도 그렇습니다. 한 사람의 역량은 그 자체로도 가치가 있지만, 다른 사람의 역량과 결합될 때 혼자서는 만들 수 없는 것을 만듭니다. Capability Node라는 개념은 두 가지를 동시에 말합니다. 당신은 하나의 완결된 역량이다. 그리고 당신은 연결될 때 더 큰 것이 된다.

Capability Node로 사람을 본다는 것은 다음을 뜻합니다.

• 직함이 아니라 할 수 있는 것으로 봅니다. 프로필의 첫 줄은 소속이 아니라 역량입니다.
• 한 사람이 여러 역량을 가질 수 있습니다. Technical, Research, Business, Sales, Marketing, Creative, Network, Leadership, Capital은 모두 동등한 기여 가능성이며, 한 사람이 그중 여럿을 가질 수 있습니다(제6장 참조).
• 역량은 수준이 있지만 서열은 없습니다. 주니어 개발자와 시니어 개발자의 역량 수준은 다르지만 사람의 가치가 다른 것은 아닙니다. 역할에 맞는 책임과 기회를 줄 뿐입니다(제7장 참조).
• 역량은 기여로 증명됩니다. 프로필에 적은 역량은 주장이고, 기여 기록은 증거입니다. CAPABILITY → CONTRIBUTION → TRUST의 첫 두 단계가 여기서 이어집니다.
• AI 도구는 역량을 증폭하지만 대신하지 않습니다. 에이전트를 잘 쓰는 것은 역량이지만, 에이전트 자체는 노드가 아닙니다. 책임은 언제나 사람이 집니다.

이 관점은 신규회원에게 특히 중요합니다. 직함으로 보면 신규회원은 아직 아무것도 아닙니다. 역량으로 보면 신규회원은 아직 기록되지 않은 노드일 뿐입니다. 사람을 소모품처럼 다루지 않는다는 약속은 여기서부터 시작합니다. 첫 기여를 할 자리가 있어야 기록이 생기고, 기록이 생겨야 신뢰가 생깁니다.

여섯 역할, 여섯 가지 역량

직함을 버린다고 역할을 버리는 것은 아닙니다. 역할은 그 사람이 주로 어떤 종류의 역량을 가지고 있는지를 알려 주는 출발점입니다. 커뮤니티의 주요 여섯 역할이 가진 역량을 Capability Node의 눈으로 다시 보면 다음과 같습니다.

교수의 역량은 강의가 아닙니다. 문제를 구조화하는 힘, 검증 방법을 설계하는 힘, 학생과 연구 인력을 조직하는 힘, 그리고 연구비와 공동연구의 제도를 아는 힘입니다. 교수가 Project Cell에 들어오면 프로젝트는 "되는 것 같다"에서 "이 조건에서 이만큼 된다"로 바뀝니다.

사업가의 역량은 회사를 가지고 있다는 것이 아닙니다. 고객의 문제를 돈이 되는 문제로 번역하는 힘, 계약과 위험을 감당하는 힘, 사람을 모으고 결정을 내리는 힘입니다. 사업가가 없는 팀은 좋은 기술을 만들고도 누구에게 팔지 모릅니다.

연구원의 역량은 논문 편수가 아닙니다. 최신 방법을 실제 데이터에 적용할 때 무엇이 깨지는지 아는 힘, 실험을 설계하고 결과를 정직하게 읽는 힘, 데이터와 인프라를 다루는 힘입니다. 연구원이 있는 팀은 실패를 빨리 발견합니다.

개발자의 역량은 언어와 프레임워크 목록이 아닙니다. 요구사항을 동작하는 시스템으로 바꾸는 힘, 배포하고 운영하고 고치는 힘, 다른 사람의 코드를 읽고 이어받는 힘입니다. 개발자가 없는 팀은 데모는 만들지만 납품은 못 합니다.

크리에이터의 역량은 도구를 다루는 것이 아닙니다. 기술이 만든 결과물을 사람이 이해하고 반응하는 형태로 바꾸는 힘, 무엇이 보기 좋고 무엇이 설득력 있는지 아는 힘입니다. 크리에이터가 없는 팀은 좋은 모델을 만들고도 아무도 쓰고 싶지 않은 화면을 내놓습니다.

마케터의 역량은 광고를 집행하는 것이 아닙니다. 시장이 무엇을 원하는지 읽는 힘, 메시지를 만들고 반응을 측정하는 힘, 그리고 흩어진 전문가를 빠르게 조합해 실행하는 힘입니다. 마케터가 있는 팀은 만든 것을 필요한 사람에게 닿게 합니다.

여섯 역할 중 어느 하나도 다른 하나보다 위에 있지 않습니다. 프로젝트마다 필요한 조합이 다를 뿐입니다. 그리고 한 사람이 두세 역할의 역량을 동시에 가질 수 있습니다. 그것이 Capability Node가 직함보다 정확한 이유입니다.

운영원칙 — 프로필은 "I CAN OFFER / I AM LOOKING FOR"다

플랫폼의 회원 프로필은 이력서가 아닙니다. 이력서는 과거의 소속을 시간순으로 나열합니다. 우리의 프로필은 두 개의 질문으로 구성됩니다.

I CAN OFFER        — 나는 무엇을 줄 수 있는가
I AM LOOKING FOR   — 나는 무엇을 찾고 있는가

이렇게 구성하는 이유는 세 가지입니다. 첫째, 매칭은 공급과 수요가 만나는 곳에서 일어납니다. 한 사람의 OFFER가 다른 사람의 LOOKING FOR와 맞을 때 관계가 시작됩니다. 프로필이 이 두 축으로 되어 있으면 플랫폼은 사람을 더 잘 발견하게 합니다. 둘째, LOOKING FOR를 적는 것은 약점의 고백이 아니라 결합의 초대입니다. 개발자가 "B2B 영업 파트너를 찾는다"고 적을 때, 그것은 사업가에게 보내는 신호입니다. 셋째, 두 항목 모두 직함 없이 쓸 수 있습니다. 신규회원도, 소속이 없는 사람도 자기 노드를 정의할 수 있습니다.

프로필의 원칙은 다음과 같습니다.

프로필은 Verified 단계에서 검증됩니다. 검증 경로는 추천, 활동, AI TEST 인증 등 여러 가지이며, 검증은 "이 사람이 훌륭하다"가 아니라 "이 사람이 적은 것이 사실이다"를 확인하는 것입니다. 이 숫자와 절차는 커뮤니티의 기본값이며 Project Charter나 Council의 결정으로 조정할 수 있습니다.

자신의 Capability를 기술하는 방법

자기 역량을 적는 일은 생각보다 어렵습니다. 대부분의 사람은 자신을 직함으로 소개하는 데 익숙하고, 할 수 있는 것을 구체적으로 말하는 데는 서툽니다. 다음 네 단계를 권합니다.

1. 동사로 시작합니다. "AI 전문가"가 아니라 "만든다, 설계한다, 판다, 검증한다, 가르친다, 연결한다"로 시작합니다. 동사는 역량을 드러내고 명사는 직함을 드러냅니다.
2. 대상과 조건을 붙입니다. "모델을 만든다"가 아니라 "제조 현장 시계열 데이터로 이상 탐지 모델을 만든다, 라벨이 부족한 조건에서". 조건이 있어야 매칭이 정확해집니다.
3. 증거를 답니다. 실제로 한 것을 숫자와 함께 적습니다. 납품 건수, 다룬 데이터 규모, 운영 기간, 고객 유형. 기여 기록이 있으면 연결합니다. 없으면 "아직 기록 없음"이라고 적는 것이 부풀리는 것보다 낫습니다.
4. 찾는 것을 적습니다. 무엇이 있으면 자기 역량이 더 큰 일이 되는지 적습니다. 파트너, 고객, 데이터, 인프라, 멘토, 자본. LOOKING FOR가 비어 있는 프로필은 결합할 곳이 없는 노드입니다.

역할별로 흔한 실수도 있습니다. 교수는 연구 주제만 적고 산업에 줄 수 있는 것을 빠뜨립니다. 사업가는 회사 소개를 적고 자기가 직접 하는 것을 빠뜨립니다. 개발자는 기술 스택을 나열하고 무엇을 끝까지 만들어 봤는지를 빠뜨립니다. 크리에이터는 포트폴리오 링크만 걸고 어떤 고객의 어떤 문제를 풀었는지를 빠뜨립니다. 마케터는 캠페인 성과를 적고 어떤 기술 팀과 어떻게 일해 봤는지를 빠뜨립니다.

예시 프로필

다음은 모두 가상의 프로필입니다.

예시 1. 연구자 이 박사 (Research Circle)

I CAN OFFER
- 산업용 시계열 데이터 이상 탐지 모델 설계·검증. 라벨이 적은 조건에 강함.
- 실제 공장 2곳 파일럿 경험 (기여 기록: Research 3건, Project 1건)
- 실험 설계와 평가 프로토콜 작성. 논문·특허 작성 지원.
- 가용성: 주 1일 자문 + 학기 중 석사 연구원 1명 투입 가능

I AM LOOKING FOR
- 현장 데이터에 접근할 수 있는 제조·에너지 분야 사업 파트너
- 파일럿을 정식 제품으로 만들 수 있는 배포 경험 있는 개발자
- 공동연구 형태의 기업 PoC 기회

예시 2. 크리에이터 윤 씨 (Creator Circle, 신규회원)

I CAN OFFER
- AI 영상 생성 워크플로우로 30초~2분 광고·브랜드 영상 제작. 
- 기획부터 납품까지 혼자 진행 가능. 소규모 브랜드 납품 4건 (기여 기록: 아직 없음)
- 프롬프트 워크플로우 문서화. 팀에 공유 가능.
- 가용성: 프로젝트 단위 풀타임 가능 (최대 8주)

I AM LOOKING FOR
- 첫 Project Cell 참여 기회 (Junior Slot 환영)
- 브랜드 고객을 가진 마케터 파트너
- 영상 생성 파이프라인을 자동화할 개발자와의 협업

예시 3. 파운더 박 대표 (Founder Circle)

I CAN OFFER
- B2B AI 프로젝트 기회 발굴과 계약. 중견 제조·유통 고객 네트워크.
- Project Lead 경험 3건, 정산 완료 3건 (기여 기록: Project 3건, Connection 5건)
- 계약 주체(Contracting Party) 역할 수행 가능한 법인 보유.
- 가용성: 기회 발굴은 상시, Lead는 동시 1건까지

I AM LOOKING FOR
- 에이전트 기반 문서 처리를 납품해 본 개발자
- 도메인 검증을 맡아 줄 연구자
- 후속 영업을 함께할 마케터 (Originator 기여 인정, 24개월 기본값)

세 프로필의 공통점을 보십시오. 직함은 괄호 안에만 있습니다. 첫 줄은 모두 동사와 대상입니다. 증거가 있으면 적었고 없으면 없다고 적었습니다. LOOKING FOR는 다른 노드를 향한 초대입니다. 그리고 세 프로필을 나란히 놓으면 이미 하나의 Project Cell이 보입니다. 이 박사의 검증, 박 대표의 고객, 윤 씨의 제작이 결합되는 그림입니다. 플랫폼이 사람을 잘 발견하게 한다는 것은 이런 결합이 우연이 아니라 설계로 일어나게 한다는 뜻입니다.

Case: 직함이 가린 역량

다음은 가상의 사례입니다.

Expert Circle의 회원 중에 세무사 한 씨가 있었습니다. 프로필에는 "세무사, OO세무법인"이라고만 적혀 있었습니다. 다른 회원들은 한 씨를 세금 질문이 있을 때 찾는 사람으로만 알았습니다.

어느 날 Founder Circle에서 파운더 박 대표가 AI 기반 경비 처리 자동화 서비스를 기획하며 팀을 꾸리고 있었습니다. 개발자와 연구자는 구했지만 도메인 검증을 맡을 사람이 없었습니다. 박 대표는 "회계 도메인 전문가"를 Opportunity에 올렸고, 아무도 응답하지 않았습니다. 세무사 한 씨는 그 공고를 보고도 자기 일이 아니라고 생각했습니다. 자기 직함은 "세무사"였기 때문입니다.

Circle Leader가 프로필 갱신을 권하면서 한 씨에게 네 단계로 역량을 다시 적어 보라고 했습니다. 한 씨가 새로 적은 OFFER는 이랬습니다. "중소기업 200곳의 경비 처리 데이터를 5년간 다뤘다. 어떤 영수증이 어떤 계정으로 가는지, 어디에서 오류가 반복되는지 안다. 자동화 규칙을 설계하고 예외 케이스를 검증할 수 있다. 가용성 주 반나절." 그리고 LOOKING FOR에는 "내 도메인 지식을 제품으로 만들어 줄 개발 팀"이라고 적었습니다.

박 대표는 갱신된 프로필을 보고 바로 연락했습니다. 한 씨는 Project Cell에 Executor(도메인 검증)로 참여했고, Work Compensation은 시장 단가 기준 자문료로 먼저 정했으며, 그가 설계한 예외 규칙은 Knowledge 기여로 Contribution Matrix에 반영되었습니다. 서비스가 첫 매출을 내자 한 씨는 Value Sharing에서 자기 몫을 받았습니다. 이후 한 씨는 Expert Circle에서 세금 질문에 답하는 사람이 아니라 "회계 도메인을 제품 규칙으로 번역하는 사람"으로 알려졌습니다.

이 사례에서 바뀐 것은 한 씨의 역량이 아닙니다. 역량은 처음부터 있었습니다. 바뀐 것은 역량을 기술하는 방식이었습니다. 직함이 가리고 있던 노드가 보이게 되자 결합이 일어났습니다. 기여한 사람을 잊지 않는다는 약속은 기여가 기록될 때 지켜지지만, 그 전에 기여할 사람이 보여야 합니다.

Remember

명함은 소속을 말하고 일은 역량을 묻습니다. 직함은 역량을 말하지 않고, 서열을 만들며, 한 사람의 여러 역량 중 하나만 보여 줍니다.

모든 사람은 하나의 Capability Node입니다. 혼자서도 완결된 역량이고, 연결될 때 더 큰 것이 됩니다. 유명하거나 직급이 높은 사람만 가치 있는 것이 아닙니다.

프로필은 이력서가 아니라 "I CAN OFFER / I AM LOOKING FOR"입니다. 동사로 시작하고, 조건을 붙이고, 증거를 달고, 찾는 것을 적습니다.

프로필의 역량은 주장이고 기여 기록은 증거입니다. 역량이 기여가 되고, 기여가 신뢰가 되는 첫걸음은 자기 노드를 정직하고 구체적으로 적는 데서 시작합니다.

"사람을 직함으로 보지 않고, 무엇을 할 수 있는가로 본다."

기술이 뛰어난 사람만 실력자인가. AI가 실행을 싸게 만드는 시대에, 프로젝트를 실제로 성공시키는 실력은 무엇으로 이루어져 있는가.

질문에서 시작합니다

한 Project Cell(프로젝트 셀, 필요할 때 만들어지고 끝나면 해체되는 실행 단위)이 다섯 달 만에 첫 매출을 냈다고 가정해 봅시다. 고객사의 문서 검색 시스템을 만든 프로젝트였습니다. 정산 회의에서 누군가 이렇게 말합니다. "결국 코드는 개발자 둘이 다 짰잖아요. 나머지는 옆에서 도운 것 아닙니까."

이 말은 절반만 맞습니다. 코드는 분명 개발자 둘이 짰습니다. 하지만 그 고객은 누가 데려왔습니까. 계약 조건은 누가 협상했습니까. 검색 품질을 평가할 기준은 누가 세웠습니까. 첫 두 달 동안 GPU 비용은 누가 감당했습니까. 팀이 흔들릴 때 누가 방향을 잡았습니까.

"실력"이라는 말을 들으면 우리는 대개 기술을 떠올립니다. 그 실력은 실제로 귀합니다. 그러나 프로젝트가 성공하려면 그 외에도 여러 종류의 실력이 동시에 작동해야 합니다. 이 장은 그 여러 종류의 실력에 이름을 붙이고, 각각이 어느 순간에 결정적이며, 서로 어떻게 결합되는지를 설명합니다.

왜 이것이 문제인가

기술 중심의 실력관은 어디서 왔는가

AI 분야는 오랫동안 기술이 희소한 세계였습니다. 모델을 다룰 줄 아는 사람이 드물었고, 그래서 기술이 곧 실력이라는 등식이 자리 잡았습니다. 영업을 잘하는 사람, 사람을 잘 연결하는 사람은 "기술은 모르지만"이라는 말을 앞에 붙이고 이야기를 시작해야 했습니다.

이 실력관은 한 가지를 놓칩니다. 기술이 아무리 뛰어나도 고객이 없으면 매출이 없고, 매출이 없으면 프로젝트는 지속되지 않습니다. 많은 훌륭한 기술 프로젝트가 데모 단계에서 멈췄습니다. 그 기술을 필요로 하는 사람을 찾아 설득하고 계약하고 돈을 받아내는 실력이 팀 안에 없었기 때문입니다.

AI가 실행을 싸게 만들면 무엇이 비싸지는가

여기에 AI 시대라는 조건이 더해집니다. 코드를 짜는 비용, 영상을 만드는 비용, 문서를 쓰는 비용이 빠르게 내려가고 있습니다. 전에는 개발자 셋이 두 달 걸리던 일을 이제 한 사람이 도구의 도움으로 몇 주 만에 해냅니다. 이것은 기술 역량이 무가치해졌다는 뜻이 아닙니다. 기술 역량의 중심이 "직접 만드는 능력"에서 "무엇을 만들지 판단하고, 만들어진 것이 맞는지 검증하는 능력"으로 옮겨가고 있다는 뜻입니다.

실행이 싸지면 상대적으로 비싸지는 것이 있습니다. 첫째, 판단입니다. 어떤 문제가 돈이 되는지, 어느 고객이 진짜 고객인지를 아는 능력입니다. 둘째, 관계입니다. 누가 신뢰할 만한 사람인지, 누구를 누구에게 소개하면 일이 되는지를 아는 능력입니다. 셋째, 책임입니다. 결과가 잘못됐을 때 그 결과를 감당하겠다고 서명하는 능력입니다. AI는 코드를 대신 짜 줄 수 있지만 고객에게 "제가 책임지겠습니다"라고 말해 주지는 않습니다.

그래서 한 사람이 감당해야 하는 범위는 오히려 넓어졌습니다. 개발자는 영업까지 해야 하고, 크리에이터는 기술을 알아야 하고, 사업가는 모델의 한계를 이해해야 합니다. 한 사람이 이 모든 것을 잘하기는 어렵습니다. 그래서 결합이 필요하고, 결합하려면 먼저 결합할 역량의 종류를 정확히 볼 수 있어야 합니다.

저평가되는 실력이 팀을 떠난다

실력의 종류를 구분하지 못하면 한 가지 실력만 인정받고 나머지는 "도운 것"이 됩니다. 도운 사람으로 분류된 사람은 다음 프로젝트에 오지 않습니다. 고객을 데려온 사람이 첫 정산에서 인정받지 못하면 다음 고객을 다른 곳으로 데려갑니다. 이것은 보상의 문제이기 전에 인식의 문제입니다. 보이지 않는 기여는 보상할 수 없습니다.

우리의 철학

한국인공지능커뮤니티는 사람을 직함이 아니라 Capability Node(역량 노드), 즉 "무엇을 할 수 있는 사람"으로 봅니다(제5장 참조). 이 장은 그 "무엇"을 아홉 가지로 나눕니다. Technical, Research, Business, Sales, Marketing, Creative, Network, Leadership, Capital입니다. 우리는 이 아홉 가지를 동등한 기여 가능성으로 봅니다.

동등하다는 말은 항상 같은 값이라는 뜻이 아닙니다. 연구 과제에서는 Research가 중심이고, 기업 납품에서는 Sales와 Technical이 중심입니다. 동등하다는 것은 "어떤 역량도 태생적으로 부차적이지 않다"는 뜻입니다. 이 프로젝트에서 영업이 결정적이었다면 영업은 정당하게 그 몫을 인정받아야 합니다.

프로토콜 조직(Protocol Organization)에서 이 관점은 필수입니다. 위계 조직은 직급으로 사람을 정렬하고, 시장은 단가로 정렬하고, 느슨한 커뮤니티는 팔로워 수로 정렬합니다. 우리는 프로젝트마다 어떤 역량이 결합되어 어떤 가치를 만들었는지를 기록으로 정렬합니다. Contribution Matrix(기여도 평가표)의 기여 범주가 Origination, Sales, Execution, Leadership & Risk, Capital & Infra, Network, Knowledge로 나뉘어 있는 것도 같은 이유입니다(제19장 참조). 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다. 그 "실제 기여"를 보려면 실력의 종류를 먼저 볼 수 있어야 합니다.

아홉 가지 역량

각 역량이 결정적인 순간을 프로젝트 생애주기(제14장 참조)에 놓아 보면 다음과 같습니다.

Idea       → Research · Business · Creative    (무엇이 문제이고 왜 돈이 되는가)
Proposal   → Business · Sales · Creative       (고객이 이해하고 원하게 만든다)
Team       → Network · Leadership              (누구를 어떻게 모을 것인가)
Charter    → Leadership · Business             (역할·보상·위험을 합의한다)
Contract   → Sales · Business · Capital        (조건을 닫고 초기 비용을 감당한다)
Execution  → Technical · Research · Creative   (실제로 만든다)
Settlement → Leadership · Business             (정직하게 계산하고 나눈다)
Closing    → Leadership · Network · Marketing  (다음 기회로 잇는다)

Technical이 결정적인 순간은 여덟 단계 중 주로 하나입니다. 물론 그 하나가 가장 길고 가장 힘든 단계입니다. 그러나 나머지 일곱 단계가 없으면 그 단계는 시작조차 되지 않습니다.

역량은 어떻게 결합되는가

역량은 혼자 작동하지 않습니다. Research와 Sales가 결합하면 "할 수 있는 것과 없는 것"을 정직하게 말하는 제안이 나옵니다. 이런 제안은 성사율이 낮아 보이지만 성사된 후 실패율이 훨씬 낮습니다. Technical과 Creative가 결합하면, 크리에이터가 만든 3분짜리 데모가 개발자가 두 달 동안 만든 기능을 팔아 줍니다. 반대로 개발자가 없으면 크리에이터의 아이디어는 "실제로 되나요"라는 질문 앞에서 멈춥니다.

Network와 Capital이 결합하면 프로젝트는 매출이 나기 전까지의 공백을 건널 수 있습니다. 이 공백을 건너지 못해서 사라진 프로젝트는 기술이 부족해서 사라진 프로젝트보다 많습니다. Leadership은 다른 역량을 대체하지 않습니다. 다른 역량들이 충돌할 때 결정을 내리고 그 결과를 책임지는 역량입니다. "실행은 빠르게, 이해관계 변경은 합의로"라는 원칙(제16장 참조)은 실행 판단을 내릴 사람이 있어야 작동합니다.

한 사람이 두세 가지 역량을 동시에 가질 수 있습니다. 개발자 출신 파운더는 Technical과 Business를, 교수는 Research와 Network를 함께 가질 수 있습니다. 중요한 것은 이 프로젝트에서 어떤 역량으로 기여했는가입니다.

운영원칙

1. 역량은 자기 신고와 기록의 조합으로 확인합니다. 회원은 가입 시 주 역량과 부 역량을 아홉 가지 중에서 선택합니다. 이는 출발점일 뿐이며, 실제 프로젝트에서 어떤 역량으로 기여했는지가 기록되면서 점차 신고보다 기록이 우선합니다. 신고와 기록이 다르면 기록을 봅니다.

2. Project Charter(프로젝트 헌장)는 필요한 역량을 먼저 적습니다. 사람 이름을 먼저 적고 역할을 나중에 붙이지 않습니다. "Technical 둘, Sales 하나, Creative 하나, Leadership 하나가 필요하다"를 먼저 적고, 그 자리에 맞는 사람을 Capability + Experience + Trust + Availability + Fit 기준으로 찾습니다(제15장 참조).

3. 어떤 역량도 Contribution Matrix에서 사전에 배제되지 않습니다. "영업은 원래 성공보수만", "자본은 원래 이자만"과 같은 관행적 배제를 기본값으로 두지 않습니다. 모든 역량은 Work Compensation(수행 대가)과 Value Sharing(가치 배분) 양쪽에서 평가 대상이 됩니다.

4. 역량의 가중치는 프로젝트마다 다르며 Charter에서 정합니다. 커뮤니티는 "Technical 40%, Sales 30%"와 같은 고정 배분표를 두지 않습니다. 기본값은 "이 프로젝트에서 어떤 역량이 없었다면 결과가 나오지 않았을 것인가"를 참여자가 합의하는 것입니다. 합의가 어려우면 Project Lead가 초안을 만들고 참여자 전원의 동의를 받습니다.

5. AI 도구는 역량이 아니라 장비입니다. "AI로 코드를 짰으니 Technical 기여가 아니다"라고 하지 않습니다. 동시에 "AI가 짠 코드를 그대로 냈다"는 것도 Technical 기여로 인정하지 않습니다. 기여의 단위는 결과물에 대한 판단과 책임입니다.

6. 저평가되기 쉬운 역량은 기록의 형식을 미리 정합니다. Network 기여는 "누구를 언제 소개했고 그 결과 무엇이 생겼는가"를, Leadership 기여는 "어떤 결정을 언제 내렸고 어떤 위험을 감당했는가"를, Capital 기여는 "무엇을 얼마나 투입했고 회수 조건은 무엇이었는가"를 기록합니다. 기여한 사람을 잊지 않으려면 기여를 적어야 합니다.

7. 아홉 칸에 사람을 가두지 않습니다. 새로운 종류의 역량이 반복해서 나타나면 Council(운영위원회)이 분류를 갱신할 수 있습니다. 분류는 사람을 보기 위한 도구이지 제한하기 위한 틀이 아닙니다.

위 원칙은 커뮤니티의 기본값(Default)이며, 개별 Project Charter로 조정할 수 있습니다.

역할별로 다시 보기

개발자에게. Technical의 가치가 "코드를 짠 시간"으로 측정되는 시대는 끝나가고 있습니다. 무엇을 만들지 판단하고, 검증하고, 운영 중의 문제를 책임지는 부분이 점점 더 큰 몫을 차지합니다. 그리고 고객을 데려온 사람의 기여를 "도운 것"으로 부르지 않는 것이 여러분의 다음 프로젝트를 만듭니다.

교수·연구자, 사업가·파운더에게. Research·Business·Leadership은 산출물이 눈에 잘 보이지 않아 "말만 했다"는 오해를 받습니다. 어떤 접근법을 왜 골랐는지, 어떤 결정을 언제 내렸는지, 어떤 위험을 감당했는지를 남기십시오. 잘못된 접근법으로 쓸 뻔한 석 달을 절약한 것도 기여입니다.

크리에이터·마케터, 네트워크와 자본을 가진 분에게. 여러분의 기여는 "예쁘게 만들었다", "소개만 했다", "돈만 냈다"로 축소되기 쉽습니다. "이 데모로 이 고객이 계약을 결정했다", "이 소개로 이 계약이 생겼다"는 형태로 기록해야 인정받습니다. 동시에 그 인정은 영구적 권리가 아닙니다. Originator(기회를 가져온 사람) 보상이 기본 24개월간 체감하는 이유입니다(제17장 참조). Contribution creates Trust, not Permanent Privilege.

Case: 문서 검색 프로젝트의 정산

이것은 가상의 사례입니다.

제조업체 한 곳이 사내 기술문서 검색 시스템을 원했습니다. 계약 금액은 6천만원, 기간은 다섯 달이었습니다. Project Cell은 개발자 김 씨와 정 씨(Technical), 연구자 이 교수(Research), 파운더 박 대표(Business·Leadership·Sales), 크리에이터 최 씨(Creative)로 구성되었습니다. 고객은 Expert Circle 회원인 세무사 한 씨가 소개했습니다(Network).

프로젝트는 성공했습니다. 문제는 정산 회의에서 시작됐습니다. 정 씨는 "코드는 우리 둘이 다 짰다"며 Value Sharing의 대부분을 Technical에 배정해야 한다고 주장했습니다. 한 씨는 "소개만 했다"는 말을 들었고, 최 씨는 "데모 영상 하나 만든 것"으로 요약되었습니다.

Project Lead인 박 대표는 논쟁을 멈추고 Charter와 플랫폼의 기여 기록을 함께 열었습니다. 한 씨의 소개가 없었다면 고객은 존재하지 않았습니다. 최 씨의 데모 영상은 고객사 임원회의에서 결정적이었다고 고객 담당자가 직접 말했습니다. 이 교수가 세운 평가 기준 덕분에 팀은 두 번째 달에 접근법을 바꿀 수 있었고, 그 결정이 없었다면 다섯 달 안에 끝나지 못했을 것입니다. 박 대표는 셋째 달 고객의 범위 확장 요구를 막아 냈고, 그 협상이 없었다면 Work Compensation은 적자였을 것입니다.

정산은 다음과 같이 이루어졌습니다. 먼저 Work Compensation으로 김 씨·정 씨에게 각 1천만원, 이 교수에게 5백만원, 최 씨에게 4백만원, 박 대표에게 6백만원이 시장 단가 기준으로 지급되었습니다. 합계 3천5백만원입니다. 직접비용(GPU·서버)은 5백만원이었습니다. 잉여가치는 6천만원 − 5백만원 − 3천5백만원 = 2천만원입니다. 이 중 Community Share 5%인 1백만원을 커뮤니티에 배분하고, 남은 1천9백만원을 Contribution Matrix에 따라 나눴습니다. Origination(한 씨) 15%, Sales·Leadership & Risk(박 대표) 30%, Execution beyond paid work(김 씨·정 씨) 30%, Knowledge(이 교수) 15%, Creative(최 씨) 10%였습니다.

정 씨는 처음 예상보다 적은 몫을 받았습니다. 그러나 Closing Review에 이렇게 적었습니다. "코드는 우리가 짰지만 프로젝트는 다섯 종류의 실력이 만들었다. 다음에도 이 팀과 일하고 싶다." 한 씨는 그 다음 해에 같은 고객사의 후속 프로젝트를 다시 소개했습니다. 첫 정산에서 한 씨의 기여가 "소개만 한 것"으로 처리되었다면 그 후속 프로젝트는 커뮤니티 밖으로 갔을 것입니다.

Remember

• 실력은 한 종류가 아닙니다. Technical, Research, Business, Sales, Marketing, Creative, Network, Leadership, Capital은 모두 동등한 기여 가능성입니다.
• 동등하다는 것은 항상 같은 값이라는 뜻이 아니라, 어떤 역량도 태생적으로 부차적이지 않다는 뜻입니다. 가중치는 프로젝트마다 다르고 Charter가 정합니다.
• AI가 실행을 싸게 만들수록 판단·관계·책임의 값은 올라갑니다. 기술 역량의 중심도 "만드는 것"에서 "무엇을 만들지 판단하고 검증하는 것"으로 옮겨갑니다.
• 보이지 않는 기여는 보상할 수 없습니다. 저평가되기 쉬운 역량일수록 기록의 형식을 미리 정합니다.

"코드는 두 사람이 짰지만, 프로젝트는 아홉 종류의 실력이 만든다."

Junior와 Senior의 차이는 분명히 있다. 그런데 왜 우리는 사람을 등급으로 정렬하지 않는가. 경력 3년의 개발자와 경력 20년의 교수는 같은 Project Cell에서 어떻게 대등한 기여자가 되는가.

질문에서 시작합니다

가입한 지 두 달 된 회원이 Builder Circle의 소그룹 회의에서 손을 들었습니다. "지금 논의하는 에이전트 구조는 제가 지난 회사에서 여섯 달 동안 운영해 본 것과 같은데, 그때 트래픽이 늘면서 겪은 문제가 있습니다." 회의실이 잠깐 조용해졌습니다. 발언한 사람은 경력 3년의 개발자였고, 듣고 있던 사람 중에는 경력 20년의 교수와 스타트업을 두 번 매각한 파운더가 있었습니다.

이 순간 조직은 두 갈래로 갈립니다. 한쪽에서는 누군가 "신입은 일단 들어보세요"라고 말합니다. 다른 한쪽에서는 교수가 "그 문제를 좀 더 자세히 말해 주시겠습니까"라고 묻습니다. 어느 쪽이 되느냐가 그 조직이 사람을 어떻게 보는지를 결정합니다.

경력 3년과 경력 20년의 차이는 실재합니다. 경험의 폭, 실패의 목록, 판단의 정확도는 다릅니다. 우리는 그 차이를 부정하지 않습니다. 그러나 "그 차이가 사람의 가치를 정한다"는 것과 "그 차이가 이 프로젝트에서 맡을 책임을 정한다"는 것은 전혀 다른 문장입니다. 이 장은 그 두 문장을 분리하는 일에 관한 것입니다.

왜 이것이 문제인가

세 가지 서열, 세 가지 실패

우리가 익숙한 조직들은 각자의 방식으로 사람을 줄 세웁니다.

위계 조직(전통 기업)은 직급으로 줄 세웁니다. 사원·대리·과장·부장. 직급은 원래 책임의 범위를 나타내는 것이었지만, 실제로는 발언권과 신뢰의 기본값이 됩니다. 부장이 틀린 말을 해도 사원이 반박하려면 비용이 듭니다. 직급은 안정적인 조정 장치이지만 정보가 아래에서 위로 올라가는 속도를 늦춥니다. AI 시대에 가장 최신의 도구를 써 본 사람이 가장 낮은 직급에 있는 경우가 많다는 점을 생각하면 이 지연은 치명적입니다.

시장(프리랜서·외주)은 단가로 줄 세웁니다. 시간당 5만원인 사람과 시간당 30만원인 사람. 단가는 시장이 그 사람의 과거 산출물에 매긴 가격이지만, 실제로는 "누가 더 옳은가"의 대리 지표로 쓰입니다. 그런데 단가는 협상력과 자기 홍보 능력을 상당 부분 반영합니다. 실력이 같은데 단가가 다른 경우, 단가가 낮은 사람의 판단은 회의에서 가볍게 취급됩니다. 그리고 그 사람은 다음에 단가를 올리기 위해 실력보다 협상을 연습합니다.

느슨한 커뮤니티(SNS·오픈채팅)는 팔로워로 줄 세웁니다. 팔로워 수는 그 사람이 얼마나 많은 사람에게 보였는가를 나타낼 뿐, 그 사람과 함께 일해도 되는지는 아무것도 말해 주지 않습니다. 그럼에도 팔로워가 많은 사람의 말은 더 많이 인용되고, 팔로워가 적은 사람의 정확한 지적은 묻힙니다. 이 서열은 세 가지 중 가장 신뢰와 무관합니다.

세 서열의 공통점은 하나입니다. 서열이 만들어지면 사람들은 서열을 올리는 일에 시간을 씁니다. 승진을 위해, 단가를 위해, 팔로워를 위해. 그 시간은 실제로 무언가를 만드는 데 쓰이지 않습니다.

AI 시대에 경력 서열이 특히 위험한 이유

AI 도구는 매년, 때로는 매달 바뀝니다. 20년 전에 쌓은 경험 중 상당 부분은 여전히 유효하지만, 어떤 부분은 오히려 새로운 접근을 막는 편견이 됩니다. 반대로 경력 3년의 개발자가 지난 여섯 달 동안 직접 운영해 본 에이전트 구조에 대한 지식은, 그 순간에는 그 방에서 가장 정확한 정보일 수 있습니다.

경력이 곧 정확도라면 서열은 합리적입니다. 그러나 AI 시대에는 "이 특정 문제에 대해 누가 가장 최근에 손을 대 보았는가"가 "누가 가장 오래 이 분야에 있었는가"보다 정확도를 더 잘 예측하는 경우가 잦습니다. 경력 서열로 발언권을 정하는 조직은 이 정보를 체계적으로 버리는 셈입니다.

한 가지 더 있습니다. 실행이 싸지면서 한 사람이 감당하는 범위가 넓어졌습니다(제6장 참조). 파운더가 모델을 직접 돌려 보고, 개발자가 고객을 직접 만납니다. 그러면 모두가 어떤 영역에서는 Senior이고 어떤 영역에서는 Junior입니다. 사람 전체에 하나의 등급을 붙이는 것은 이 현실과 맞지 않습니다.

서열이 없으면 무질서해지는가

여기서 흔한 반론이 나옵니다. "그렇다고 모두가 동등하게 발언하면 결정이 안 된다. 누군가는 결정해야 한다." 맞습니다. 그래서 우리는 서열 대신 역할을 둡니다. Project Lead(프로젝트 리드)는 실행 판단을 내리고 그 결과를 책임집니다. 이것은 Project Lead가 다른 참여자보다 "높은" 사람이라는 뜻이 아닙니다. 이 프로젝트에서 그 역할을 맡았다는 뜻입니다. 다음 프로젝트에서는 다른 사람이 Lead일 수 있고, 지난번의 Lead가 이번에는 Executor(수행자)일 수 있습니다.

서열과 역할의 차이는 이것입니다. 서열은 사람에게 붙어서 프로젝트를 넘어 따라다닙니다. 역할은 프로젝트에 붙어서 프로젝트가 끝나면 해체됩니다. 우리가 없애려는 것은 결정 구조가 아니라 사람에게 영구히 붙는 등급입니다.

우리의 철학

한국인공지능커뮤니티는 사람을 Capability Node(역량 노드)로 봅니다(제5장 참조). 노드에는 위아래가 없습니다. 연결의 방식과 밀도가 다를 뿐입니다. 이 관점에서 "역할에 맞는 책임과 기회를 준다"는 문장은 다음 세 가지를 뜻합니다.

첫째, 책임은 사람이 아니라 역할에 따릅니다. Project Lead는 실행 판단의 책임을 지고, Executor는 맡은 결과물의 책임을 지고, Originator(기회를 가져온 사람)는 고객 관계의 책임을 집니다. 경력 20년이라는 이유로 책임이 자동으로 커지지 않고, 경력 3년이라는 이유로 책임이 자동으로 작아지지 않습니다. 물론 큰 책임을 맡으려면 그에 맞는 기록이 필요합니다. 그러나 그 기록은 경력 연수가 아니라 이 커뮤니티에서 실제로 무엇을 했는가입니다.

둘째, 기회는 서열이 아니라 적합성으로 배정됩니다. 팀 구성 기준은 Capability + Experience + Trust + Availability + Fit입니다(제15장 참조). Experience는 다섯 기준 중 하나이지 전부가 아닙니다. 어떤 프로젝트에서는 경험이 결정적이고, 어떤 프로젝트에서는 최근에 그 도구를 만져 본 사람이 결정적입니다. 그리고 Availability, 즉 실제로 시간을 낼 수 있는가는 경력과 무관하게 모두에게 똑같이 적용됩니다.

셋째, 차이는 인정하되 서열은 만들지 않습니다. 제8장의 성장 단계 Member → Verified → Contributor → Professional → Leader / Fellow는 등급이 아니라 신뢰와 책임의 깊이입니다. Fellow는 Member보다 높은 사람이 아니라 더 많은 것을 감당하겠다고 약속했고 그 약속을 지켜 온 사람입니다. 이 구분이 흐려지는 순간 성장 단계는 직급이 되고, 우리는 위계 조직의 실패를 반복하게 됩니다.

프로토콜 조직(Protocol Organization)에서 이 원칙은 장식이 아닙니다. 사람을 고용이 아니라 규약과 기록된 신뢰로 묶는 조직에서, 경력 서열은 기록을 대체하는 지름길입니다. 지름길이 있으면 사람들은 기록을 쌓지 않고 서열을 쌓습니다. 사람을 소모품처럼 다루지 않는다는 약속은, 사람을 등급표의 한 칸으로 다루지 않는다는 약속을 포함합니다.

운영원칙

1. 회원 프로필에 경력 연수·직급·팔로워 수를 정렬 기준으로 쓰지 않습니다. 플랫폼은 회원을 역량(아홉 가지), 기여 기록, Trust Capital(행동으로 축적되는 신뢰의 기록), 가용성으로 표시하고 검색합니다. 경력은 프로필에 적을 수 있지만 검색의 기본 정렬 축이 아닙니다.

2. Project Cell 안에서 발언권은 역할과 근거로 정해집니다. 실행 판단은 Project Lead가 내립니다. 그 판단에 이르기까지의 논의에서는 누구의 근거가 더 정확한가만 봅니다. "제가 이 분야 경력이 몇 년인데"는 근거가 아닙니다. "제가 이 구조를 지난 여섯 달 운영하면서 이런 문제를 겪었습니다"는 근거입니다.

3. 모든 Project Cell은 신규회원에게 최소 한 자리를 열어 두는 것을 권장합니다. 이 자리를 Junior Slot이라 부릅니다. Junior Slot은 보조 자리가 아닙니다. 명확한 결과물과 그 결과물에 대한 책임, 그리고 Contribution Matrix(기여도 평가표)에서의 정당한 평가가 따르는 자리입니다. "일단 보고 배우는 자리"로 두면 안 됩니다. 기본값은 프로젝트당 1자리이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

4. Work Compensation(수행 대가)은 시장 단가를 기준으로 하되, 결과물의 단가이지 사람의 단가가 아닙니다. 같은 결과물을 냈다면 경력이 짧다는 이유로 단가를 깎지 않습니다. 반대로 경력이 길다는 이유로 같은 결과물에 더 지급하지도 않습니다. 결과물의 난이도와 품질이 단가를 정합니다. 이는 기본값이며 Charter로 조정할 수 있습니다.

5. Value Sharing(가치 배분)은 경력이 아니라 기여로 나눕니다. Contribution Matrix에 "경력 가중치" 항목은 없습니다. 다만 경험이 실제 기여로 나타난 경우, 예를 들어 잘못된 접근을 초기에 막은 판단은 Knowledge 또는 Leadership & Risk 범주에서 기여로 기록됩니다.

6. Leader / Fellow 단계의 회원도 Project Cell 안에서는 하나의 참여자입니다. Fellow가 Executor로 참여한 프로젝트에서 Project Lead가 Contributor 단계 회원이라면, 실행 판단은 그 Lead가 합니다. Fellow라는 이유로 Lead의 판단을 뒤집을 권한은 없습니다. Governance Power ≠ Economic Opportunity라는 원칙(제24장 참조)은 프로젝트 안에서도 그대로 적용됩니다.

7. 경력·직급·소속을 근거로 다른 회원을 무시하는 발언은 동료평가에 기록됩니다. 이는 제재가 아니라 기록입니다. 그러나 반복되면 Trust Capital에 반영되고, 다음 팀 구성에서 Fit 항목으로 고려됩니다. 신뢰는 말이 아니라 행동으로 쌓습니다. 동료를 어떻게 대하는가도 행동입니다.

8. 차이를 부정하는 것도 금지합니다. 경험 많은 회원의 판단을 "서열을 만든다"는 이유로 무시하는 것 역시 원칙 위반입니다. 우리가 없애는 것은 근거 없는 서열이지 근거 있는 판단이 아닙니다. 20년의 경험에서 나온 판단은 그 판단의 근거와 함께 제시되면 정당하게 무겁습니다.

위 원칙은 커뮤니티의 기본값(Default)이며, 개별 Project Charter로 조정할 수 있습니다.

역할별로 다시 보기

경력이 긴 회원에게. 이 원칙은 여러분의 경험을 깎아내리지 않습니다. 오히려 여러분의 경험이 "연수"가 아니라 "판단의 근거"로 제시될 때 훨씬 더 큰 무게를 갖게 합니다. 그리고 여러분이 경력 3년의 회원에게 "그 문제를 자세히 말해 주시겠습니까"라고 묻는 순간, 그 회원은 다음 프로젝트에서 여러분과 다시 일하고 싶어 합니다. 그것이 Trust Capital입니다.

신규회원에게. Junior Slot은 배려가 아니라 자리입니다. 그 자리에는 결과물과 책임이 따릅니다. 발언할 때는 경력을 앞세우지도, 숨기지도 마십시오. 근거를 앞세우십시오. 그리고 여러분이 낸 결과물은 기록됩니다. 기여한 사람을 잊지 않는다는 약속은 신규회원에게 가장 먼저 적용되어야 하는 약속입니다.

Project Lead에게. 팀 안에서 서열이 생기는지를 가장 먼저 감지할 수 있는 사람은 Lead입니다. 회의에서 누가 말하지 않는지, 누구의 말이 반복해서 끊기는지를 보십시오. 실행 판단은 Lead가 내리지만, 그 판단에 이르는 정보가 서열 때문에 걸러지면 판단의 질이 떨어집니다. 서열 없는 팀은 Lead에게도 이익입니다.

Circle Leader(서클 리더)에게. Circle은 결과물을 만드는 실행 공동체입니다(제25장 참조). Circle 안에서 "오래된 회원"이 발언권을 독점하는지를 살피십시오. 오래된 회원이라는 이유로 사업기회를 우선 배정받지 않는다는 원칙은 Circle에서 가장 자주 시험받습니다.

Case: 경력 3년의 개발자와 경력 20년의 교수

이것은 가상의 사례입니다.

유통업체 한 곳이 고객 문의를 자동으로 분류하고 응답 초안을 만드는 에이전트 시스템을 의뢰했습니다. 계약 금액은 4천만원, 기간은 넉 달이었습니다. Project Lead는 파운더 박 대표였고, 팀에는 연구자 이 교수(Research·Technical), 개발자 김 씨(Technical), 그리고 Junior Slot으로 가입 두 달 차인 개발자 윤 씨가 들어왔습니다. 윤 씨는 경력 3년이었고, 이 교수는 이 분야에서 20년을 일했습니다.

첫 설계 회의에서 이 교수는 문의를 분류하는 단계와 응답을 만드는 단계를 하나의 모델 호출로 처리하는 구조를 제안했습니다. 단순하고 비용이 낮았습니다. 윤 씨는 이전 직장에서 비슷한 구조를 여섯 달 운영한 경험을 이야기했습니다. 트래픽이 하루 2천 건을 넘기면서 분류 오류가 응답 오류로 그대로 번졌고, 결국 두 단계를 분리해야 했다는 것이었습니다.

잠깐 침묵이 있었습니다. 김 씨는 "교수님 안이 더 검증된 것 아니냐"고 말했습니다. 여기서 박 대표는 서열이 아니라 근거를 물었습니다. "윤 씨, 그때 분리한 뒤에 비용은 얼마나 늘었습니까. 오류율은 얼마나 줄었습니까." 윤 씨는 구체적인 숫자를 기억하고 있었습니다. 이 교수는 그 숫자를 듣고 이렇게 말했습니다. "제가 다룬 시스템은 하루 수백 건 규모였습니다. 2천 건 이상은 제 경험 밖입니다. 이 고객은 하루 3천 건이니 윤 씨의 경험이 더 가깝습니다."

박 대표는 두 단계를 분리하는 구조로 실행 판단을 내렸고, 분류 단계의 설계와 구현을 윤 씨에게 맡겼습니다. 보조가 아니라 담당이었습니다. Charter에는 윤 씨의 결과물과 책임이 명시되었습니다. 이 교수는 응답 생성 단계의 평가 기준을 맡았고, 윤 씨의 분류기를 검증하는 역할도 함께 했습니다. 검증 과정에서 이 교수는 윤 씨가 놓친 경계 사례 여러 개를 찾아냈습니다. 경험이 근거로 제시되면 정당하게 무겁다는 것을 보여 준 순간이었습니다.

프로젝트는 넉 달 안에 끝났습니다. Work Compensation은 결과물 기준으로 지급되었습니다. 윤 씨는 분류 단계 전체를 담당했으므로 8백만원, 김 씨는 응답 생성과 통합으로 9백만원, 이 교수는 평가 기준 설계와 검증으로 6백만원, 박 대표는 Lead와 고객 관리로 5백만원을 받았습니다. 잉여가치 8백만원은 Community Share 5%를 뺀 뒤 Contribution Matrix에 따라 나뉘었고, 윤 씨의 초기 구조 판단은 Knowledge 범주로 기록되어 Value Sharing에서도 인정받았습니다.

Closing Review에서 이 교수는 이렇게 적었습니다. "윤 씨가 그 자리에서 손을 들지 않았다면 우리는 셋째 달에 구조를 뒤집었을 것이다." 윤 씨는 이 프로젝트를 기록으로 Verified에서 Contributor 단계로 올라갔습니다. 다음 해에 윤 씨는 다른 Project Cell의 Lead가 되었고, 그 팀의 Junior Slot에는 가입 한 달 차의 크리에이터가 들어왔습니다.

Remember

• Junior와 Senior의 차이는 실재하지만, 그 차이는 사람의 가치가 아니라 이 프로젝트에서의 역할과 근거로만 작동합니다.
• 서열은 사람에게 붙어 따라다니고, 역할은 프로젝트에 붙어 끝나면 해체됩니다. 우리가 없애는 것은 결정 구조가 아니라 사람에게 영구히 붙는 등급입니다.
• 발언의 무게는 경력 연수가 아니라 근거가 정합니다. 20년의 경험도 근거와 함께 제시될 때 정당하게 무겁습니다.
• Junior Slot은 배려가 아니라 결과물과 책임이 따르는 자리이며, 그 기여는 기록되고 보상됩니다.
• 성장 단계는 직급이 아닙니다. Fellow도 Project Cell 안에서는 하나의 참여자입니다.

"사람에게 등급을 붙이지 않는다. 역할에 책임을 붙이고, 발언에 근거를 붙인다."

개정 메모: 아래의 Member → Fellow 단계는 초기 아이디어이며 현재 회원제에 적용하지 않습니다. 일반 이용자·사업자 조합원·전문 협력자는 승급 서열이 아닙니다. 평판과 프로젝트 권한, 법적 의결권, 보상과 복지는 서로 분리합니다. 최신 기준은 ‘현재 운영 방향’을 따릅니다.

회원은 어떤 경로로 성장하는가. Member → Verified → Contributor → Professional → Leader / Fellow는 무엇을 기준으로 올라가고, 왜 이것은 권력의 서열이 아니라 신뢰와 책임의 깊이인가.

질문에서 시작합니다

가입 첫날, 신규회원 한 사람이 플랫폼을 열어 봅니다. 프로필에는 "Member"라고 적혀 있습니다. 다른 회원의 프로필에는 "Professional", "Fellow"가 보입니다. 그 사람은 자연스럽게 묻습니다. "저 단계까지 가려면 무엇을 해야 합니까. 그리고 저기까지 가면 무엇이 달라집니까."

이 질문에 "오래 있으면 됩니다"라고 답하면 이 사다리는 연공서열이 됩니다. "운영진과 친해지면 됩니다"라고 답하면 파벌이 됩니다. "많이 발언하면 됩니다"라고 답하면 SNS가 됩니다. 우리는 다르게 답하고 싶습니다. "약속을 지키고, 결과물을 내고, 그 기록이 쌓이면 됩니다. 그리고 올라갈수록 얻는 것은 권한이 아니라 더 큰 책임과 그에 맞는 기회입니다."

제7장에서 우리는 사람을 등급으로 줄 세우지 않는다고 했습니다. 그런데 이 장에서는 다섯 단계를 이야기합니다. 모순처럼 보이는 이 두 장이 어떻게 같은 원칙 위에 서 있는지가 이 장의 핵심입니다.

왜 이것이 문제인가

단계가 없으면 신뢰를 빌려줄 수 없다

프라이빗 커뮤니티에서 가장 자주 일어나는 일은 "이 사람을 믿어도 됩니까"라는 질문입니다. 고객을 소개할 때, Project Cell(프로젝트 셀)에 사람을 넣을 때, Closed Room(참여자만 접근하는 공간)에 초대할 때, 매번 이 질문이 나옵니다. 단계가 없으면 이 질문에 답하려고 매번 그 사람의 기록 전체를 읽어야 합니다. 그것은 시장(프리랜서·외주)이 매번 치르는 탐색·검증 비용과 같습니다.

단계는 이 비용을 줄이는 요약입니다. "이 사람은 Professional입니다"라는 말은 "이 사람은 최소 몇 건의 프로젝트를 정산까지 끝냈고, 동료평가가 일정 수준 이상이며, 심각한 신뢰 위반 기록이 없습니다"의 줄임말입니다. 요약이 있어야 신뢰를 빌려줄 수 있고, 빌려줄 수 있어야 좋은 사람이 좋은 사람을 빨리 발견합니다.

단계가 있으면 직급이 되려 한다

문제는 단계가 생기면 곧바로 직급으로 변질되려는 힘이 작동한다는 것입니다. 상위 단계 회원의 말이 자동으로 무거워지고, 하위 단계 회원은 발언을 주저하고, 어느새 단계가 "얼마나 오래 있었는가"와 상관관계를 갖기 시작합니다. 그 다음에는 상위 단계 회원이 사업기회를 먼저 보게 되고, 단계는 권력이 됩니다. 위계 조직의 실패가 그대로 재현됩니다.

이 변질을 막으려면 단계의 정의 자체에 두 가지를 심어야 합니다. 첫째, 올라가는 조건이 시간이나 관계가 아니라 기록이어야 합니다. 둘째, 올라가서 얻는 것이 권한이 아니라 책임이어야 합니다. 책임이 커지는 자리를 원하는 사람은 권력을 원하는 사람보다 적고, 그래서 이 사다리는 스스로 과열되지 않습니다.

AI 시대의 성장은 직선이 아니다

전통 기업의 경력은 대체로 한 방향으로 올라갑니다. 그러나 이 커뮤니티의 회원은 각자의 회사·직장·연구실을 유지합니다. 어떤 해에는 본업이 바빠서 참여가 줄고, 어떤 해에는 본업이 한가해서 두세 개의 Project Cell에 동시에 들어갑니다. 어떤 회원은 3년 동안 Contributor에 머물다가 갑자기 두 개의 프로젝트를 Lead로 성공시키고 Professional이 됩니다. 어떤 Fellow는 본업의 변화로 커뮤니티 활동을 거의 하지 못하는 시기를 맞습니다.

그래서 이 사다리는 올라가기만 하는 사다리가 아닙니다. 내려올 수도 있고, 다시 올라갈 수도 있습니다. 하향이 징벌이 아니고 복귀가 특혜가 아닌 구조여야, 회원은 본업이 바쁜 시기에도 커뮤니티를 떠나지 않습니다. 사람을 소모품처럼 다루지 않는다는 약속은, 활동이 줄어든 회원을 지워 버리지 않는다는 약속을 포함합니다.

우리의 철학

성장 단계는 권력의 서열이 아니라 신뢰와 책임의 깊이입니다. 이 문장을 세 가지로 풀면 다음과 같습니다.

첫째, 올라가는 기준은 기록입니다. Trust Capital(행동으로 축적되는 신뢰의 기록)은 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사로 구성됩니다(제10장 참조). 각 단계의 진입 조건은 이 기록의 양과 질로만 정의됩니다. 오래 있었다는 것, 운영진을 안다는 것, 발언이 많다는 것은 조건이 아닙니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

둘째, 올라가서 얻는 것은 책임이고, 기회는 책임에 따라옵니다. Professional은 Project Lead를 맡을 수 있습니다. 그것은 권한이라기보다 실행 판단의 결과를 감당하겠다는 책임입니다. Leader는 Circle을 운영하고, Fellow는 커뮤니티의 신뢰를 대표합니다. 각 단계에서 열리는 기회는 그 책임을 감당할 수 있는 사람에게만 열리는 것이 합리적이기 때문에 열립니다.

셋째, 단계는 Project Cell 안에서 권한이 되지 않습니다. 제7장에서 본 대로, Fellow가 Executor로 참여한 프로젝트에서 실행 판단은 그 프로젝트의 Lead가 합니다. 단계는 "누구를 어디까지 믿고 무엇을 맡길 것인가"를 요약하는 것이지, "누구의 말이 더 무거운가"를 정하는 것이 아닙니다. Governance Power ≠ Economic Opportunity라는 원칙은 성장 단계에도 그대로 적용됩니다. 상위 단계라는 이유로 사업기회를 우선 배정받지 않습니다.

프로토콜 조직(Protocol Organization)에서 이 사다리는 신뢰의 원장을 읽기 쉽게 만든 색인입니다. 색인은 원장을 대체하지 않습니다. 중요한 결정에서는 언제나 원장, 즉 기록 자체를 봅니다. Contribution creates Trust, not Permanent Privilege.

운영원칙

다섯 단계

Leader와 Fellow는 같은 층에 있는 두 갈래입니다. Leader는 운영의 길이고 Fellow는 신뢰와 전문성의 길입니다. 한 사람이 둘 다일 수 있고, 어느 한쪽만일 수도 있습니다. Circle을 운영하고 싶지 않은 뛰어난 연구자는 Fellow가 될 수 있고, 연구보다 사람을 모으는 데 능한 회원은 Leader가 될 수 있습니다.

Member ──▶ Verified ──▶ Contributor ──▶ Professional ──▶ Leader   (운영·Circle)
                                                      └──▶ Fellow   (신뢰·전문성·Give Back)
        ◀── 활동 정지·기준 미달 시 하향 / 조건 회복 시 복귀 ──▶

위 표의 숫자는 커뮤니티의 기본값(Default)이며 Council(운영위원회)이 조정할 수 있습니다.

Verified의 검증 경로

Verified는 사다리의 첫 번째 관문이며, 가장 많은 회원이 통과하는 단계입니다. 검증의 목적은 "이 사람이 실제로 존재하고, 말한 전문 분야가 사실인가"를 확인하는 것입니다. 다음 경로 중 하나 이상을 충족하면 Verified가 됩니다.

1. 실명·소속·전문분야 확인. 실명과 현재 소속(회사·대학·연구소·개인사업자), 주 전문분야를 제출하고 커뮤니티가 확인합니다. 명함, 재직 증명, 논문·프로젝트 링크 등 통상적인 수단으로 확인하며, 제출 정보는 Restricted 등급으로 보호합니다.
2. 기존 회원의 추천. Contributor 이상 회원 2인의 추천. 추천인은 "이 사람과 실제로 일해 본 적이 있는가"를 답해야 하며, 추천 기록은 추천인의 Trust Capital에도 남습니다. 추천한 회원이 심각한 위반을 저지르면 추천인의 기록에도 표시됩니다.
3. AI TEST 인증. 앵커 조직인 AI TEST의 인증을 취득한 경우, 해당 분야의 전문성이 확인된 것으로 봅니다. 인증은 검증 경로 중 하나일 뿐 필수가 아닙니다.
4. 공개된 결과물. 공개 저장소, 출간물, 작품, 제품 등 본인이 만든 것으로 확인 가능한 결과물.

경로가 여럿인 이유는 회원의 배경이 다양하기 때문입니다. 교수는 소속으로, 프리랜서 크리에이터는 결과물로, 이제 막 시작한 개발자는 AI TEST로 검증받을 수 있어야 합니다. 어떤 경로도 다른 경로보다 우월하지 않습니다.

하향과 복귀

1. 활동 정지에 따른 하향은 징벌이 아닙니다. Contributor 이상 회원이 기본 18개월 동안 프로젝트·기여 기록이 없으면 단계 표시가 한 단계 낮아집니다. 기록은 사라지지 않습니다. 활동을 재개하여 기여 기록 1건이 추가되면 이전 단계로 복귀합니다. 본업이 바쁜 시기를 보낸 회원이 처음부터 다시 시작하지 않도록 설계된 것입니다.
2. 기준 미달에 따른 하향. 동료평가와 재협업 의사 평가가 기본 두 프로젝트 연속으로 기준에 미달하면 Council이 하향을 검토합니다. 본인에게 소명 기회를 주고, 소명 후 결정합니다.
3. 신뢰 위반에 따른 하향. 제11장의 부정직 행위가 윤리·분쟁위원회(Ethics & Dispute Committee)에서 확인되면 제재 단계(경고 → 프로젝트 참여 제한 → 등급 조정 → 제명)에 따라 하향 또는 제명됩니다. 실패에는 관대하되 부정직에는 엄격합니다. 기술 실패·시장 실패·일정 실패는 하향 사유가 아닙니다.
4. 복귀 원칙. 활동 정지 하향은 기여 1건으로 복귀합니다. 기준 미달 하향은 정산까지 완료된 프로젝트 1건과 동료평가 기준 충족으로 복귀합니다. 신뢰 위반 하향은 재심 절차를 거치며, 복귀 조건은 위원회가 정합니다. 어떤 경우에도 복귀 조건은 문서로 본인에게 통지됩니다.
5. Leader·Fellow의 하향. 이 단계는 책임이 가장 크므로 하향 기준도 가장 엄격합니다. Recusal 의무 위반, 이해상충 미신고는 첫 회에도 하향 사유가 됩니다. 단계가 높을수록 지켜야 할 것이 많습니다.

위 원칙은 커뮤니티의 기본값(Default)이며 Council이 조정할 수 있습니다. 단계 조정은 언제나 기록에 근거하며, 단체방 공개 성토 같은 여론재판으로 이루어지지 않습니다.

Case: 개발자 서 씨의 5년

이것은 가상의 사례입니다.

1년 차, Member에서 Verified로. 개발자 서 씨는 중견 소프트웨어 회사에 다니는 경력 4년의 백엔드 개발자였습니다. 회사 동료의 추천으로 가입했습니다. 첫 석 달은 Builder Circle의 에이전트 소그룹에서 듣기만 했습니다. 넉 달째에 실명·소속 확인과 AI TEST 인증으로 Verified가 되었습니다. 여섯 달째에 Opportunity 게시판에서 물류업체의 재고 예측 프로젝트가 Junior Slot을 열어 둔 것을 보고 지원했습니다. Project Lead인 파운더 박 대표는 서 씨의 AI TEST 인증과 공개 저장소를 보고 데이터 파이프라인 담당으로 받아들였습니다. 서 씨는 결과물을 기한 안에 냈고 Work Compensation 6백만원을 받았습니다. 첫 기여가 기록되었습니다.

2년 차, Contributor. 첫 프로젝트가 정산까지 끝나고 동료평가에서 "다시 함께 일하고 싶다"는 평가를 받아 Contributor가 되었습니다. 이 해에 서 씨는 두 개의 프로젝트에 Executor로 참여했고, Circle에서 파이프라인 구축 워크플로우를 문서로 공유했습니다. 이 문서는 Knowledge 기여로 기록되었고 다른 세 개의 Project Cell에서 재사용되었습니다. 기여한 사람을 잊지 않는다는 말이 서 씨에게는 이 기록으로 다가왔습니다.

3년 차, 첫 Lead와 실패. 서 씨는 소규모 프로젝트의 Project Lead를 처음 맡았습니다. 소상공인 대상 챗봇, 계약 금액 2천만원. 프로젝트는 일정 실패로 끝났습니다. 고객의 요구가 계속 바뀌었고 서 씨는 범위 변경을 합의로 다루지 못했습니다. 그러나 서 씨는 문제를 숨기지 않았습니다. 셋째 달에 참여자와 고객에게 상황을 공유하고 범위를 줄여 재합의했고, Work Compensation은 전액 지급했으며, Closing Review에 실패 원인을 정직하게 적었습니다. 이 실패는 하향 사유가 아니었습니다. 오히려 동료평가에서 "정직하게 정리했다"는 기록이 남았습니다.

4년 차, Professional. 서 씨는 두 번째 Lead 프로젝트를 성공시켰습니다. 이번에는 Charter에 범위 변경 절차를 명시했고, 셋째 달에 고객이 범위 확장을 요구했을 때 그 절차대로 처리했습니다. 정산 완료 프로젝트가 네 건이 되면서 Professional이 되었습니다. 이 해에 서 씨는 본업을 그만두고 개인사업자를 등록했습니다. AI 10K Initiative의 Stage 1이었습니다. 커뮤니티에서 알게 된 마케터와 함께 Originator로 Opportunity를 등록하기 시작했습니다.

5년 차, Fellow. 서 씨는 Circle Leader 제안을 받았지만 사양했습니다. 사람을 모으는 일보다 기술을 깊게 파는 일이 맞다고 판단했습니다. 대신 지난 2년간 신규회원 여섯 명을 멘토링했고, 그중 두 명이 Contributor가 되었습니다. 자신이 만든 파이프라인 템플릿을 커뮤니티 회원에게 비독점 재사용 라이선스로 공개했습니다. Council의 추천과 Fellow 합의로 Fellow가 되었습니다. Fellow가 된 다음 달, 서 씨는 다른 회원이 Lead인 Project Cell에 Executor로 참여했습니다. 그 프로젝트에서 실행 판단은 Contributor 단계의 Lead가 했고, 서 씨는 그 판단을 따랐습니다.

5년이 걸렸습니다. 이 여정에서 서 씨를 올라가게 한 것은 시간이 아니라 기록이었고, 3년 차의 실패는 그 기록을 깎지 않았습니다. 그리고 Fellow가 된 뒤에도 서 씨는 Project Cell 안에서는 하나의 참여자였습니다.

Remember

• 성장 단계 Member → Verified → Contributor → Professional → Leader / Fellow는 권력의 서열이 아니라 신뢰와 책임의 깊이입니다.
• 올라가는 조건은 시간·관계·발언량이 아니라 기록입니다. 올라가서 얻는 것은 권한이 아니라 더 큰 책임과 그에 따르는 기회입니다.
• Verified의 검증 경로는 여럿이며 어느 것도 다른 것보다 우월하지 않습니다.
• 사다리는 내려올 수도 있고 다시 올라갈 수도 있습니다. 활동 정지 하향은 징벌이 아니고, 실패는 하향 사유가 아니며, 부정직만이 하향 사유입니다.
• 단계는 Project Cell 안에서 권한이 되지 않습니다. Fellow도 그 프로젝트의 Lead가 내린 판단을 따릅니다.

"올라갈수록 얻는 것은 권한이 아니라 책임이다. 그래서 이 사다리는 서열이 되지 않는다."

열어 두면 신뢰가 흩어지고, 닫아 두면 기득권이 됩니다. 이 장은 한국인공지능커뮤니티가 울타리를 세우는 이유와, 그 울타리가 카르텔이 되지 않도록 지키는 원칙을 설명합니다.

질문에서 시작합니다

한 개발자가 오픈채팅방에서 알게 된 사업가에게 프로젝트 제안을 받습니다. 몇 차례 통화를 하고, 요구사항 문서를 받고, 아키텍처 설계를 담은 견적서를 보냅니다. 그리고 연락이 끊깁니다. 몇 달 뒤 그 개발자는 자신이 제안한 구조가 그대로 담긴 서비스가 출시된 것을 봅니다. 사업가는 그 문서를 더 싼 외주사에 넘겼습니다.

반대의 경우도 있습니다. 한 사업가가 공개 커뮤니티에서 "LLM을 잘 다룬다"는 개발자를 소개받아 3천만원짜리 PoC를 맡깁니다. 두 달 뒤 받은 것은 동작하지 않는 데모와 "요구사항이 바뀌었다"는 항변입니다. 소개한 사람은 "저도 잘 모르는 분이에요"라고 말합니다. 아무도 책임지지 않습니다.

이런 일이 반복되면 사람들은 두 가지 중 하나를 선택합니다. 아무도 믿지 않거나, 이미 아는 사람하고만 일하거나. 첫 번째 선택은 협력을 없애고, 두 번째 선택은 협력을 좁은 인맥 안에 가둡니다. 어느 쪽도 우리가 원하는 결과가 아닙니다.

그래서 질문은 이렇습니다. 신뢰할 수 있는 사람들을 모으려면 어떤 형태의 경계가 필요한가. 그리고 그 경계는 어떻게 해야 새로운 사람을 막는 벽이 아니라 신뢰를 지키는 울타리로 남을 수 있는가.

왜 이것이 문제인가

열린 공간에서는 신뢰가 축적되지 않습니다

공개 커뮤니티는 정보를 퍼뜨리는 데 뛰어납니다. 그러나 정보가 흐르는 속도와 신뢰가 쌓이는 속도는 다릅니다. 누가 약속을 지키는 사람인지, 누가 정산을 미루는 사람인지는 링크로 알 수 없습니다.

열린 공간에는 세 가지 구조적 한계가 있습니다. 첫째, 누구나 들어올 수 있으므로 누구도 검증되지 않습니다. 둘째, 나쁜 행동을 해도 잃을 것이 없습니다. 이름을 바꾸거나 다른 방으로 옮기면 그만입니다. 셋째, 좋은 행동을 해도 기록되지 않습니다. 약속을 지킨 사람과 어긴 사람이 같은 프로필을 가집니다.

이 세 가지가 합쳐지면 한 가지 결과가 나옵니다. 협력의 비용이 매번 처음부터 다시 발생합니다. 새로운 사람을 만날 때마다 검증하고, 의심하고, 작은 일부터 시켜 보고, 계약서를 두껍게 씁니다. 시장(Market) 형태의 조직이 가진 고질적인 문제입니다. 유연하지만 신뢰가 축적되지 않고, 매번 탐색과 검증 비용을 다시 치릅니다.

AI 시대에 이 비용은 더 커집니다

AI가 실행 비용을 낮출수록 판단·관계·책임의 가치는 올라갑니다. 코드를 생성하고 영상을 만들고 문서를 쓰는 일은 싸졌습니다. 그러나 "이 사람에게 우리 고객 데이터를 맡겨도 되는가", "이 팀이 납기를 지킬 것인가", "이 파트너가 우리 사업계획을 경쟁사에 흘리지 않을 것인가"라는 질문은 더 비싸졌습니다.

역설적으로, 누구나 그럴듯한 포트폴리오를 만들 수 있게 되면서 포트폴리오의 신호 가치는 떨어졌습니다. 자기소개는 AI가 써 주고, 데모 영상은 하루 만에 만들어지고, 코드 저장소는 복제됩니다. 겉으로 드러난 역량으로 사람을 판단하기가 더 어려워졌습니다. 실제로 함께 일해 본 사람의 증언, 정산을 끝까지 마친 기록, 다시 함께 일하겠다는 의사 표시만이 남은 신호입니다.

이런 신호는 아무 데서나 만들어지지 않습니다. 정보가 흘러 나가도 아무도 책임지지 않는 공간에서는 사람들이 진짜 경험을 말하지 않습니다. 실패한 프로젝트의 교훈, 고객이 실제로 지불한 금액, 어떤 모델이 실제 서비스에서 어떻게 무너졌는지 같은 이야기는 신뢰할 수 있는 범위 안에서만 공유됩니다. 울타리가 없으면 가장 가치 있는 지식이 가장 먼저 침묵합니다.

그런데 울타리는 쉽게 카르텔이 됩니다

문제는 여기서 시작됩니다. 사람들은 울타리를 세우는 데 익숙합니다. 동문회, 동종업계 모임, 고위직 클럽, 오래된 인맥 네트워크가 모두 울타리입니다. 그러나 이 울타리들 대부분은 시간이 지나면 같은 방향으로 변질됩니다. 안에 있는 사람의 이익을 지키기 위해 밖에 있는 사람을 막는 구조가 됩니다.

카르텔의 특징은 분명합니다. 진입 기준이 역량이 아니라 관계입니다. 정보는 안으로만 돌고 밖으로는 나가지 않습니다. 새로 들어온 사람은 오래 있었던 사람의 아래에 놓입니다. 그리고 운영 권한을 가진 사람이 가장 좋은 기회를 먼저 가져갑니다. 이런 조직은 초기에는 결속력이 강하지만 곧 정체됩니다. 새로운 역량이 들어오지 못하고, 안에 있는 사람들은 서로를 검증하지 않게 됩니다.

우리는 이 두 가지 함정 사이에 서 있습니다. 열어 두면 신뢰가 흩어지고, 닫아 두면 기득권이 됩니다. 이 장의 나머지는 그 사이의 길에 대한 이야기입니다.

카르텔과 프라이빗 프로페셔널 커뮤니티는 무엇이 다른가

겉으로 보면 둘은 비슷합니다. 둘 다 아무나 들어올 수 없고, 둘 다 내부 정보를 보호하고, 둘 다 구성원끼리 사업을 합니다. 그러나 다섯 가지 축에서 방향이 정반대입니다.

이 표에서 가장 중요한 줄은 마지막 줄입니다. 카르텔과 프로페셔널 커뮤니티를 가르는 결정적 기준은 "권력을 가진 사람이 기회를 먼저 가져가는가"입니다. 진입 기준이 아무리 공정해도, 안에 들어온 뒤에 임원과 오래된 회원이 좋은 프로젝트를 먼저 가져간다면 그 조직은 이미 카르텔입니다. 이 원칙은 제24장에서 자세히 다룹니다.

두 번째로 중요한 줄은 신규 진입자 대우입니다. 카르텔은 신참에게 "기다리라"고 말합니다. 프로페셔널 커뮤니티는 신참에게 "보여 달라"고 말합니다. 기다림은 시간을 요구하고, 보여 줌은 행동을 요구합니다. 우리는 후자를 택합니다.

우리의 철학: 울타리는 신뢰를 보호합니다

사람을 배제하기 위해서가 아니라 신뢰를 보호하기 위해서

한국인공지능커뮤니티는 프로토콜 조직(Protocol Organization)을 지향합니다. 사람을 고용이 아니라 공유된 규약과 기록된 신뢰로 묶고, 필요할 때 Project Cell(프로젝트 셀)로 결합하고 끝나면 해체되는 조직입니다. 이 조직이 작동하려면 한 가지 전제가 필요합니다. 규약을 공유하고 기록을 신뢰할 수 있는 사람들만 안에 있어야 합니다.

울타리는 그 전제를 지키는 장치입니다. 우리는 사람을 배제하기 위해 울타리를 만들지 않습니다. 신뢰를 보호하기 위해 울타리를 만듭니다. 이 문장은 말장난이 아닙니다. 울타리의 목적이 무엇인가에 따라 울타리의 설계가 완전히 달라지기 때문입니다.

배제가 목적이면 울타리는 높을수록 좋습니다. 보호가 목적이면 울타리는 필요한 만큼만 높아야 하고, 문은 명확해야 하며, 문을 여는 기준은 누구에게나 같아야 합니다. 배제가 목적이면 안에 있는 사람은 검증받지 않습니다. 보호가 목적이면 안에 있는 사람도 계속 행동으로 검증받습니다. 울타리는 한 번 통과하면 끝나는 관문이 아니라, 안에서도 계속 작동하는 규약입니다.

울타리가 보호하는 네 가지

울타리가 보호하는 것은 구체적입니다. 네 가지입니다.

첫째, 신뢰입니다. 약속을 지킨 기록, 정산을 마친 기록, 동료의 평가는 그 기록을 존중하는 공간 안에서만 의미가 있습니다. 아무나 들어와 기록 없이 활동하는 공간에서는 기록이 있는 사람과 없는 사람이 구분되지 않습니다. 울타리는 기록이 가치를 갖게 만드는 조건입니다.

둘째, 정보입니다. 실제로 해본 사람만 아는 경험, 특정 산업의 고객이 실제로 지불하는 단가, 어떤 모델이 실제 서비스에서 어떻게 실패했는지 같은 지식입니다. 이 정보는 공개 인터넷에 없고, 아무 데서나 말할 수 없습니다. 말한 사람이 손해를 보지 않는다는 확신이 있어야 공유됩니다. 제12장에서 다루는 Chatham House Rule과 Closed Room은 이 확신을 만드는 도구입니다.

셋째, 사업기회입니다. 고객이 "믿을 만한 팀을 소개해 달라"고 요청할 때, 그 요청은 커뮤니티 전체의 자산입니다. 이 기회가 열린 공간에 던져지면 가장 싸게 부르는 사람, 가장 빨리 답하는 사람에게 갑니다. 울타리 안에서는 가장 잘 할 수 있고 가장 신뢰할 수 있는 사람에게 갑니다. 고객도 그것을 원해서 커뮤니티에 요청한 것입니다.

넷째, 관계입니다. 누군가 몇 년에 걸쳐 만든 고객 관계, 소개로 이어진 파트너 관계는 쉽게 복제되지 않는 자산입니다. 이 관계가 우회(circumvention)당하지 않는다는 확신이 있어야 사람들은 관계를 커뮤니티 안으로 가져옵니다. 제17장에서 다루는 Non-circumvention(우회 금지) 원칙은 이 확신을 지키는 규칙입니다.

울타리가 보호하지 않는 것

똑같이 중요한 것은 울타리가 보호하지 않는 것입니다. 울타리는 기존 회원의 이익 독점을 보호하지 않습니다.

먼저 온 사람이 나중에 온 사람보다 더 좋은 기회를 자동으로 받지 않습니다. 오래 있었다는 이유로 프로젝트에 우선 배정되지 않습니다. 임원이라는 이유로 고객을 먼저 만나지 않습니다. 특정 Circle이나 특정 앵커 조직이 커뮤니티를 자신의 외주 인력풀로 쓰지 않습니다. Contribution creates Trust, not Permanent Privilege. 과거의 기여는 신뢰를 만들지만 영구적인 권리는 만들지 않습니다.

이것은 기존 회원에게 불리한 조건처럼 보일 수 있습니다. 그러나 반대입니다. 기존 회원이 가장 잃고 싶지 않은 것은 자신이 쌓은 신뢰의 가치입니다. 신뢰의 가치는 새로운 역량이 계속 들어오고, 그 역량과 결합해 더 큰 일을 할 수 있을 때 유지됩니다. 새로운 사람이 들어오지 못하는 조직에서는 오래된 사람의 신뢰도 함께 늙습니다.

개방성의 원칙

그래서 우리의 울타리에는 명확한 개방성 원칙이 있습니다. 새로운 사람이라도 역량과 신뢰를 보여주면 참여하고 성장할 수 있어야 합니다.

여기서 "보여준다"는 말이 핵심입니다. 우리는 새로운 사람에게 학벌이나 경력 연차를 요구하지 않습니다. 대신 행동을 요구합니다. 작은 프로젝트의 Junior Slot에서 약속을 지키는 것, Circle에서 워크숍을 열어 아는 것을 나누는 것, 다른 회원의 프로젝트에 리뷰어로 참여하는 것. 이런 행동이 기록되면 신뢰가 되고, 신뢰가 있으면 더 큰 프로젝트로 갑니다. 성장 단계(Member → Verified → Contributor → Professional → Leader / Fellow)는 이 행동의 깊이를 나타냅니다. 권력 서열이 아닙니다.

운영원칙: 문은 어떻게 열리는가

울타리에는 문이 있어야 하고, 문을 여는 방법은 명확해야 합니다. 한국인공지능커뮤니티의 입회 경로는 세 가지입니다. 아래 기준은 커뮤니티의 기본값(Default)이며, Council(운영위원회)이 정하는 세부 규정으로 조정할 수 있습니다.

세 가지 입회 경로

세 경로는 우열이 없습니다. 초대로 들어온 사람이 지원으로 들어온 사람보다 높지 않습니다. 세 경로의 차이는 오직 "누가 처음의 신뢰를 보증하는가"에 있습니다. 초대와 추천은 기존 회원의 Trust Capital을 빌려서 들어오는 것이고, 지원은 자기 자신의 근거로 들어오는 것입니다.

초대와 추천에는 책임이 따릅니다

초대와 추천은 가벼운 행위가 아닙니다. 초대한 회원은 초대받은 사람의 첫 12개월(기본값) 활동에 대해 보증인으로 기록됩니다. 초대받은 사람이 부정직한 행동으로 제재를 받으면 초대자의 기록에도 그 사실이 남습니다. 초대자가 직접 처벌받는 것은 아닙니다. 그러나 반복적으로 문제 있는 사람을 초대한 회원은 초대 권한이 제한됩니다.

이 규칙은 초대를 어렵게 만들기 위한 것이 아닙니다. 초대를 진지하게 만들기 위한 것입니다. "그냥 아는 사람"을 초대하지 않고 "함께 일해 본 사람"을 초대하게 됩니다. 그러면 초대 자체가 하나의 신뢰 정보가 됩니다.

검증이 의미하는 것

입회 검증에서 우리가 확인하는 것은 네 가지입니다.

1. 역량의 실재: 주장하는 역량이 실제로 존재하는가. 포트폴리오, 공개된 결과물, AI TEST 인증, 추천자의 증언으로 확인합니다. 화려함이 아니라 실재를 봅니다.
2. 전문성의 방향: 이 사람이 AI 분야에서 무엇을 하려는 사람인가. 사업가·교수·연구원·개발자·크리에이터·마케터·전문가 중 어느 역량 축에 서 있는가. 어떤 Circle에 속할 것인가.
3. 규약의 이해: 이 책의 원칙, 특히 우회 금지·비밀유지·정산·이해상충에 대한 원칙을 읽고 동의하는가. Korea AI Community Charter(커뮤니티 헌장, Appendix A)에 서명하는가.
4. 행동의 이력: 알려진 부정직의 기록이 있는가. 이전 협업에서 정산 문제, 정보 유출, 기여 가로채기가 있었는가. 이것은 실패의 이력이 아니라 부정직의 이력을 묻는 것입니다. 실패에는 관대하되 부정직에는 엄격합니다.

검증에서 확인하지 않는 것도 분명히 합니다. 유명세, 팔로워 수, 출신 학교, 소속 회사의 규모, 직급은 검증 기준이 아닙니다. 이것들은 역량의 실재를 확인하는 보조 자료가 될 수는 있지만 그 자체로 문을 열지 않습니다.

입회는 시작이지 완성이 아닙니다

입회한 사람은 Member 단계에서 시작합니다. Member는 커뮤니티의 Community 등급 정보와 Circle 활동에 접근할 수 있지만, Cell-only·Restricted 등급의 정보와 일부 사업기회에는 아직 접근하지 못합니다. Verified 단계로 올라가려면 AI TEST 인증, 회원의 검증, 또는 첫 프로젝트 참여 기록 중 하나가 필요합니다.

이 단계 설계의 의도는 명확합니다. 문을 통과하는 것은 쉽게, 깊이 들어가는 것은 행동으로. 처음부터 높은 벽을 세우면 좋은 사람도 못 들어옵니다. 처음에는 낮은 문으로 들여보내되, 정보와 기회의 깊이를 행동의 기록에 따라 열어 줍니다. 울타리는 하나의 벽이 아니라 여러 겹의 방입니다.

    바깥 ──문──▶ Member ──행동──▶ Verified ──기여──▶ Contributor ──책임──▶ Professional ──▶ Leader / Fellow
                 Community 정보     첫 프로젝트        Cell-only 정보       Restricted 정보
                 Circle 활동        Junior Slot        Lead 가능            Circle 운영

울타리 안에서도 검증은 계속됩니다

입회 후에도 다음 세 가지 경우에는 회원 자격이 재검토됩니다.

• 부정직한 행동(제11장)이 윤리·분쟁위원회(Ethics & Dispute Committee)에서 확인된 경우. 제재는 경고 → 프로젝트 참여 제한 → 등급 조정 → 제명 순서로 하고, 재심 절차를 둡니다.
• 24개월(기본값) 동안 아무런 활동·기여 기록이 없는 경우. 자동 제명은 아닙니다. 활동 의사를 확인한 뒤 휴면으로 전환합니다.
• 입회 시 제출한 근거가 허위로 확인된 경우. 허위경력은 실패가 아니라 부정직입니다.

역할별로 본 울타리

같은 울타리도 서 있는 자리에 따라 다르게 보입니다.

사업가에게 울타리는 "여기서 소개받은 팀은 최소한 검증되었다"는 보증입니다. 시장에서 처음 만난 개발팀에게 3천만원짜리 PoC를 맡기는 것과, 정산 기록과 동료평가가 있는 팀에게 맡기는 것은 위험의 크기가 다릅니다. 동시에 사업가는 울타리 안에서 자신의 고객 관계가 우회당하지 않는다는 확신을 얻습니다.

교수·연구자에게 울타리는 "여기서 말한 미발표 연구 방향이 밖으로 새지 않는다"는 확신입니다. 학회에서는 발표된 것만 말하고, 기업 미팅에서는 계약된 것만 말합니다. 울타리 안에서는 아직 확정되지 않은 가설과 실패한 실험까지 말할 수 있고, 그것이 산업의 실제 문제와 만나는 접점이 됩니다.

개발자·크리에이터에게 울타리는 "내가 만든 것이 내 기여로 기록된다"는 보장입니다. 열린 공간에서 개발자의 아키텍처 제안은 견적서와 함께 사라집니다. 울타리 안에서는 Project Charter(프로젝트 헌장)에 역할이 기록되고, Contribution Matrix(기여도 평가표)에 기여가 남고, Project Closing Review(종료평가)에 결과가 남습니다. 기여한 사람을 잊지 않는다는 원칙은 울타리가 있어야 작동합니다.

마케터에게 울타리는 "빠르게 조합할 수 있는 검증된 풀"입니다. 캠페인은 시간과의 싸움입니다. 크리에이터와 엔지니어를 매번 처음부터 검증하면 기회를 놓칩니다. 울타리 안의 기록은 그 검증 시간을 줄여 줍니다.

신규회원에게 울타리는 벽처럼 보일 수 있습니다. 그러나 문이 명확하고 기준이 행동이라면, 울타리는 오히려 가장 공정한 경쟁 조건입니다. 학벌과 인맥이 아니라 행동으로 평가받는 공간은 열린 공간보다 신참에게 유리합니다. 열린 공간에서는 목소리 큰 사람이 이기고, 울타리 안에서는 약속을 지킨 사람이 이깁니다.

Case: 초대받지 못한 사람

이 사례는 가상의 사례입니다.

상황. 데이터 엔지니어 정 씨는 대기업에서 7년간 일하다 독립했습니다. 커뮤니티에 아는 사람이 없어 지원 경로로 들어왔습니다. 포트폴리오는 있었지만 대부분 회사 내부 프로젝트라 외부에 보여 줄 수 없었고, 추천인도 없었습니다. Builder Circle의 면담에서 정 씨는 자신이 만든 데이터 파이프라인의 구조를 화이트보드에 그려 설명했고, AI TEST 인증을 받았습니다. Member로 입회했습니다.

갈등. 입회 후 석 달 동안 정 씨는 프로젝트에 참여하지 못했습니다. Opportunity 채널에 올라오는 프로젝트마다 지원했지만, Project Lead(프로젝트 리드)들은 이미 함께 일해 본 사람들로 팀을 채웠습니다. 정 씨는 Circle Leader(서클 리더)에게 물었습니다. "결국 아는 사람끼리 하는 것 아닙니까. 울타리가 저를 위한 것이 아니라 저를 막는 것 같습니다."

Circle Leader 한 씨는 이 질문을 가볍게 넘기지 않았습니다. 확인해 보니 최근 석 달간 Builder Circle에서 시작된 프로젝트 여섯 건 중 네 건이 Junior Slot 없이 팀을 구성했습니다. 규약은 신규회원에게 최소 한 자리를 열어 두는 것을 권장하지만, Lead들은 일정 압박을 이유로 이를 생략하고 있었습니다.

적용. 한 씨는 두 가지를 했습니다. 첫째, Circle 운영 회의에서 이 수치를 공유하고, Junior Slot을 생략하는 경우 Project Charter에 그 이유를 기재하도록 했습니다. 강제가 아니라 기록입니다. 이유를 써야 하면 사람들은 이유를 생각하게 됩니다. 둘째, 정 씨에게 Circle 안의 작은 기여를 제안했습니다. 회원들이 반복해서 묻는 데이터 정합성 문제에 대해 워크숍을 열어 달라는 것이었습니다.

정 씨는 워크숍을 열었습니다. 열두 명이 참석했고, 그중 한 명이 파운더 박 대표였습니다. 박 대표는 물류 고객사의 데이터 파이프라인 프로젝트를 준비 중이었고, 정 씨의 설명에서 자기 문제의 답을 봤습니다. 박 대표는 Project Lead로서 정 씨를 팀에 넣었습니다. 4천5백만원 규모의 프로젝트였고, 정 씨의 Work Compensation(수행 대가)은 시장 단가 기준으로 1천2백만원이었습니다.

결과. 정 씨는 일정을 지켰고, 정산은 깨끗했고, Closing Review에서 박 대표와 동료 두 명은 "다시 함께 일하겠다"에 표시했습니다. 정 씨는 여섯 달 만에 Contributor 단계가 되었습니다. 이후 정 씨는 자신이 겪은 석 달을 기억하며, Lead를 맡은 프로젝트마다 Junior Slot을 열었습니다.

이 사례에서 울타리는 정 씨를 막지 않았습니다. 정 씨를 막은 것은 규약을 생략한 관행이었습니다. 울타리는 문이 있어야 울타리이고, 문은 사람이 열어야 열립니다. 규약을 기록으로 만들고, 신참이 행동을 보여 줄 작은 자리를 만드는 것. 그것이 울타리를 카르텔이 되지 않게 지키는 일상적인 작업입니다.

Remember

• 열린 공간에서는 신뢰가 축적되지 않고, 닫힌 공간은 쉽게 카르텔이 됩니다. 우리는 그 사이의 길을 갑니다.
• 카르텔과 프로페셔널 커뮤니티를 가르는 결정적 기준은 권력을 가진 사람이 기회를 먼저 가져가는가입니다. Governance Power ≠ Economic Opportunity.
• 울타리는 신뢰·정보·사업기회·관계를 보호합니다. 기존 회원의 이익 독점은 보호하지 않습니다.
• 문은 초대·추천·지원 세 가지이고, 우열이 없습니다. 검증은 유명세가 아니라 역량의 실재와 행동의 이력을 봅니다.
• 새로운 사람이라도 역량과 신뢰를 보여주면 참여하고 성장할 수 있어야 합니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

"우리는 사람을 배제하기 위해 울타리를 만들지 않습니다. 신뢰를 보호하기 위해 울타리를 만듭니다."

신뢰는 사람됨에 대한 인상이 아니라 행동의 기록입니다. 이 장은 한국인공지능커뮤니티가 신뢰를 어떻게 정의하고, Trust Capital로 어떻게 기록·축적·조회하며, 깨진 신뢰를 어떻게 다시 쌓는지를 설명합니다.

질문에서 시작합니다

파운더 박 대표는 제조 고객사의 품질검사 자동화 PoC를 맡게 되었습니다. 6천만원 규모, 석 달 일정입니다. 비전 모델을 다룰 엔지니어가 한 명 필요합니다. 플랫폼의 Opportunity에 올렸더니 두 사람이 지원했습니다.

첫 번째 지원자는 이력이 화려합니다. 대기업 AI 연구소 출신, 컨퍼런스 발표 경력, 팔로워 수만 명의 기술 블로그. 자기소개는 매끄럽고 자신감이 있습니다. 두 번째 지원자는 조용합니다. 커뮤니티 안에서 세 개의 프로젝트를 했고, 셋 다 Closing Review에 "다시 함께 일하겠다"가 기록되어 있습니다. 정산은 모두 기한 안에 끝났습니다. 팔로워는 없습니다.

박 대표는 누구를 택해야 할까요. 아마 대부분의 독자가 두 번째 사람에게 마음이 기울 것입니다. 그런데 그 이유를 정확히 말해 보라고 하면 답이 쉽지 않습니다. "믿을 만해서"라고 답한다면, 다시 묻게 됩니다. 믿을 만하다는 것은 정확히 무엇을 안다는 뜻인가.

이 장은 그 질문에 답합니다. 우리는 신뢰를 "좋은 사람이라는 느낌"으로 정의하지 않습니다. 신뢰는 특정한 행동이 반복되었다는 기록입니다. 그리고 그 기록에는 이름이 있습니다. Trust Capital(신뢰 자산)입니다.

왜 이것이 문제인가

인성으로 정의된 신뢰는 측정할 수 없습니다

대부분의 조직에서 신뢰는 인상의 문제입니다. "그 사람 괜찮아", "좀 조심해야 해" 같은 말이 오갑니다. 이 말들은 무엇을 근거로 하는지 불분명합니다. 한 번의 식사 자리일 수도 있고, 5년간의 협업일 수도 있고, 다른 사람에게 들은 소문일 수도 있습니다. 근거가 불분명하면 검증할 수 없고, 검증할 수 없으면 축적되지 않습니다.

인상으로 정의된 신뢰는 네 가지 방식으로 실패합니다. 첫째, 친분과 혼동됩니다. 자주 만난 사람을 믿을 만하다고 느끼지만, 자주 만난 것과 약속을 지킨 것은 다릅니다. 둘째, 첫인상에 좌우됩니다. 말을 잘하는 사람이 유리하고, 말수가 적은 사람이 불리합니다. 셋째, 이전될 수 없습니다. 김 씨가 이 씨를 믿는다는 사실은 박 씨에게 아무 정보도 주지 않습니다. 넷째, 신참에게 불공정합니다. 아직 인상을 남길 기회가 없었던 사람은 평가 대상조차 되지 못합니다.

직함, 팔로워, 자기소개는 왜 신뢰가 아닌가

사람들이 신뢰의 대용품으로 가장 많이 쓰는 것이 직함, 팔로워, 자기소개입니다. 세 가지 모두 나름의 정보를 담고 있지만, 우리가 알고 싶은 것에 대한 정보는 아닙니다.

직함은 과거의 어떤 조직이 그 사람을 어떻게 판단했는지를 말해 줍니다. 그 판단의 기준은 우리가 알 수 없고, 그 조직의 맥락 안에서만 유효합니다. 큰 회사에서 팀장이었던 사람이 3인 Project Cell에서 약속을 지킬 것인가는 별개의 질문입니다.

팔로워는 주목의 크기를 말해 줍니다. 좋은 콘텐츠를 만드는 능력, 설명하는 능력, 때로는 논쟁을 일으키는 능력을 반영합니다. 그러나 정산을 기한 안에 하는가, 고객 정보를 지키는가, 일정이 밀렸을 때 미리 알리는가에 대해서는 아무 정보가 없습니다.

자기소개는 자기 주장입니다. 검증되지 않은 주장이고, AI 시대에는 다듬어진 문장을 만드는 비용이 거의 없습니다. 자기소개가 좋을수록 오히려 판단이 어려워집니다.

이 세 가지의 공통점은 하나입니다. 모두 "그 사람이 나와 함께 일할 때 어떻게 행동할 것인가"에 대한 정보가 아닙니다. 그런데 우리가 알고 싶은 것은 정확히 그것입니다.

AI 시대에는 이 문제가 더 커집니다

AI가 실행의 비용을 낮추면서 역량을 증명하는 신호들이 값싸졌습니다. 포트폴리오, 데모, 발표 자료, 기술 블로그 모두 하루 이틀이면 그럴듯하게 만들어집니다. 반면 판단·관계·책임의 가치는 올라갔습니다. "이 사람에게 맡겨도 되는가"는 더 비싼 질문이 되었습니다.

위계 조직에는 이 문제를 다루는 장치가 있습니다. 인사 기록, 평가, 승진 이력입니다. 그러나 그 기록은 조직 밖으로 나오지 않습니다. 시장에는 장치가 없습니다. 프리랜서는 프로젝트가 끝날 때마다 신뢰를 처음부터 다시 증명합니다. 느슨한 커뮤니티에는 기록 자체가 없습니다.

프로토콜 조직이 이 문제에 답하는 방식이 이 장의 주제입니다. 고용 없이도, 조직 밖에서도, 이동 가능한 형태로 신뢰를 기록하는 것. 그래야 좋은 사람이 좋은 사람을 빨리 발견하고, 발견된 관계가 실제 실행으로 이어집니다.

우리의 철학: 신뢰는 행동의 원장이다

원장이라는 비유

회계에서 원장(ledger)은 모든 거래를 시간 순서대로 적은 장부입니다. 원장에는 인상이 없습니다. 어떤 거래가 언제 있었고 얼마였는지만 있습니다. 잔고는 누군가의 의견이 아니라 기록의 합계입니다. 그리고 원장은 지워지지 않습니다. 잘못된 항목이 있으면 정정 항목을 추가합니다.

우리는 신뢰를 이렇게 다룹니다. 신뢰는 평판이 아니라 원장입니다. 누군가 "그 사람 괜찮아"라고 말하는 대신, 우리는 기록을 봅니다. 그 사람이 참여한 프로젝트, 그 프로젝트의 종료평가, 정산이 끝난 날짜, 함께 일한 사람들의 평가, 그들이 다시 함께 일하겠다고 했는지. 신뢰는 말이 아니라 행동으로 쌓습니다.

이것이 프로토콜 조직의 네 번째 설계 원리입니다. 기여가 기록되어야 신뢰가 되고, 신뢰가 있어야 다음 협력이 생깁니다. 기록이 없으면 기여는 잊히고, 기여가 잊히면 사람은 소모품이 됩니다. 우리는 사람을 소모품처럼 다루지 않습니다. 그래서 기록합니다.

신뢰를 구성하는 일곱 가지 행동

우리는 신뢰를 일곱 가지 행동으로 정의합니다. 모두 관찰 가능하고, 기록 가능하며, 예 또는 아니오로 답할 수 있는 것들입니다.

1. 약속 준수: Project Charter(프로젝트 헌장)에 적힌 자신의 역할과 범위를 이행했는가.
2. 정산: Project Settlement Sheet(정산표)에 따라 받을 것을 받고 줄 것을 주었는가. 기한 안에 했는가. 비용을 부풀리지 않았는가.
3. 일정: 약속한 일정을 지켰는가. 지키지 못할 때 미리 알렸는가.
4. 비밀유지: Confidentiality 등급과 NDA를 지켰는가. 고객 정보와 내부 정보를 밖으로 내보내지 않았는가.
5. 결과물: 맡은 결과물이 합의된 기준을 충족했는가.
6. 동료평가: 함께 일한 사람들이 이 사람의 협업 태도를 어떻게 평가했는가. 동료를 존중했는가.
7. 재협업 의사: 함께 일한 사람들이 다시 함께 일하고 싶어 하는가.

이 일곱 가지 중 어느 것도 "좋은 사람인가"를 묻지 않습니다. 모두 "무엇을 했는가"를 묻습니다. 그래서 검증할 수 있고, 프로젝트가 끝날 때마다 쌓이고, 다음 Project Lead(프로젝트 리드)가 볼 수 있고, 신참에게도 공정합니다. 신참은 아직 기록이 없을 뿐, 기록을 만들 기회는 같습니다.

Trust Capital의 정의

이제 정식으로 정의합니다.

Trust Capital(신뢰 자산)은 한 회원이 한국인공지능커뮤니티 안에서 수행한 프로젝트와 기여에 대해 기록된 행동의 원장입니다. 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사의 기록으로 구성되며, 자기 주장이나 외부 평판이 아니라 함께 일한 사람들의 기록과 정산·종료 문서에 의해서만 축적됩니다.

"자본(Capital)"이라는 말을 쓰는 이유가 있습니다. 자본은 축적되고, 투자되고, 수익을 냅니다. Trust Capital도 그렇습니다. 프로젝트마다 축적되고, 다음 프로젝트에 참여할 때 투자되고, 더 큰 기회와 더 깊은 네트워크라는 수익을 냅니다. 관통 공식에서 CONTRIBUTION과 COLLABORATION 사이에 TRUST가 놓인 이유입니다.

다만 이 자본에는 두 가지 특성이 있습니다. 첫째, 양도할 수 없습니다. 초대와 추천으로 빌려줄 수는 있지만(제9장), 팔거나 넘길 수 없습니다. 둘째, 영구적이지 않습니다. 최근의 행동이 오래된 행동보다 무겁고, 쌓은 신뢰는 다음 행동으로 계속 갱신됩니다. Contribution creates Trust, not Permanent Privilege.

Trust Capital: 무엇이 기록되는가

Trust Capital은 별도의 평가 절차로 만들어지지 않습니다. 프로젝트를 정상적으로 끝내는 과정에서 생기는 문서들이 그대로 기록이 됩니다. 이것이 중요합니다. 신뢰를 쌓기 위해 따로 무언가를 할 필요가 없습니다. 일을 제대로 끝내면 기록은 저절로 남습니다.

이 표에서 가장 무거운 항목은 재협업 의사입니다. 다른 항목은 개별 행동에 대한 기록이지만, 재협업 의사는 그 모든 행동을 겪은 사람이 내리는 종합 판단입니다. 함께 일한 사람이 다시 함께 일하고 싶어 하는가. 이 질문에 대한 답이 쌓인 것이 신뢰의 가장 정직한 형태입니다.

어떻게 축적되고 어떻게 조회되는가

축적의 원리

Trust Capital은 프로젝트가 끝날 때마다 한 번씩 쌓입니다. 큰 프로젝트든 작은 프로젝트든 같은 문서를 남기므로, 5백만원짜리 워크숍 제작 프로젝트도 1억원짜리 시스템 구축 프로젝트도 기록이 됩니다. 신참이 Junior Slot으로 참여한 작은 프로젝트의 기록은, 그 신참이 다음 프로젝트에 지원할 때 유일하고 충분한 근거가 됩니다.

축적에는 세 가지 원리가 있습니다. 첫째, 상호적입니다. Lead가 팀원을 평가하는 만큼 팀원도 Lead를 평가합니다. Lead의 Trust Capital에는 "이 사람 밑에서 일한 사람들이 다시 일하고 싶어 하는가"가 기록됩니다. 둘째, 시간 가중입니다. 최근 36개월(기본값)의 기록이 요약에서 무겁게 반영되고, 그 이전의 기록은 비중이 낮아집니다. 3년 전의 실수가 영원히 따라다니지 않고, 3년 전의 공로가 영원히 앞서지도 않습니다. 셋째, 맥락이 함께 남습니다. 부정적 기록에는 당사자의 설명이 함께 기록됩니다.

조회의 원리

기록은 보는 사람에 따라 다르게 열립니다.

여기서 한 가지 설계 결정을 설명해야 합니다. 우리는 Trust Capital을 하나의 점수로 환원하지 않습니다. 점수가 있으면 사람들은 점수를 올리는 행동을 합니다. 작고 안전한 프로젝트만 골라서 하거나, 평가를 서로 좋게 주기로 약속하거나, 점수가 낮은 사람을 기피합니다. 그리고 점수는 곧 서열이 됩니다. 제7장에서 말했듯 우리는 사람을 등급으로 줄 세우지 않습니다.

대신 요약을 제공합니다. Lead가 팀을 구성할 때 보는 것은 "87점"이 아니라 "프로젝트 4건, 일정 4/4 준수, 정산 4/4 완료, 재협업 의사 예 3건·조건부 1건, 조건부 사유: 병행 프로젝트 과다"입니다. 이 요약은 판단의 재료이지 판단 자체가 아닙니다. 판단은 사람이 합니다. 그리고 Lead는 조건부 사유를 보고 지원자와 직접 이야기할 수 있습니다.

조회할 때 묻는 세 가지 질문

Project Lead가 지원자의 Trust Capital을 볼 때, 우리는 세 가지 질문을 권합니다.

1. 이 사람은 약속한 것을 끝내는가. 일정과 결과물 항목을 봅니다.
2. 일이 잘못되었을 때 어떻게 행동했는가. 일정을 못 지킨 기록이 있다면, 미리 알렸는지와 그 뒤의 처리를 봅니다. 실패 자체가 아니라 실패의 처리가 신뢰를 말합니다.
3. 함께 일한 사람들이 다시 일하고 싶어 하는가. 재협업 의사와 그 사유를 봅니다.

이 세 질문에 답할 수 있으면, 직함도 팔로워도 자기소개도 필요 없습니다. 반대로 이 세 질문에 답할 기록이 없다면, 직함과 팔로워와 자기소개가 아무리 좋아도 그 사람은 아직 Member일 뿐입니다. 유명한 사람도 이 커뮤니티에서는 Member에서 시작합니다. 그것이 불공정한 것이 아니라 공정한 것입니다.

운영원칙

아래는 커뮤니티의 기본값(Default)이며, Project Charter로 조정할 수 있습니다.

1. 모든 Project Cell은 종료 시 Closing Review를 작성합니다. 종료(정산 완료) 후 14일 이내가 기본값입니다. Closing Review가 없는 프로젝트는 Trust Capital에 "참여"만 기록되고 평가는 기록되지 않습니다.
2. 평가는 행동 항목별로 합니다. 약속·일정·정산·비밀유지·결과물·협업 태도의 여섯 항목을 각각 "이행 / 부분 이행 / 미이행"으로 표시하고, 재협업 의사를 "예 / 조건부 예 / 아니오"로 표시합니다. "조건부"와 "미이행"에는 사유를 씁니다.
3. 평가는 상호적입니다. Lead를 포함한 참여자 전원이 서로를 평가합니다. Lead는 자신의 팀원에게 평가받는 것을 면제받지 않습니다.
4. 정산 기록은 자동으로 신뢰 기록이 됩니다. Settlement Sheet의 완료 일자와 기한을 비교하여 기록합니다. 사람이 따로 평가하지 않습니다.
5. 기록은 삭제되지 않습니다. 잘못된 기록은 정정 항목을 추가하는 방식으로 바로잡습니다. 당사자는 모든 부정적 기록에 대해 설명을 덧붙일 권리가 있고, 사실과 다른 기록에 대해서는 윤리·분쟁위원회에 이의를 제기할 수 있습니다.
6. 기록은 점수로 환원되지 않고 요약으로 제공됩니다. 플랫폼은 순위표를 만들지 않습니다.
7. 시간 가중을 적용합니다. 최근 36개월의 기록이 요약의 중심이 됩니다. 그 이전의 기록은 본인과 위원회만 전체를 볼 수 있습니다.
8. 커뮤니티 밖의 평판은 기록에 반영하지 않습니다. SNS의 논란, 외부 소문, 다른 커뮤니티의 평가는 Trust Capital이 아닙니다. 단, 커뮤니티 밖에서의 행동이 커뮤니티 회원이나 고객에게 직접 피해를 준 경우는 윤리·분쟁위원회의 심의 대상이 됩니다.
9. 보복성 평가를 금지합니다. 분쟁 중인 상대에 대한 평가는 위원회 결정 뒤에 작성하며, 근거 없는 "아니오"가 반복되는 회원은 그 사실 자체가 기록됩니다.

신뢰의 회복

실패는 신뢰를 깎지 않습니다

먼저 분명히 할 것이 있습니다. 실패는 기록되지만 그 자체로 신뢰를 깎지 않습니다. 기술 실패, 시장 실패, 일정 실패는 일을 하다 보면 생기는 일입니다. 실패에는 관대하되 부정직에는 엄격합니다.

오히려 실패의 처리가 신뢰를 만듭니다. 일정이 밀릴 것을 2주 전에 알리고 대안을 제시한 사람과, 마감일에 "못 했습니다"라고 말한 사람은 같은 일정 실패를 겪었지만 Trust Capital에는 다르게 남습니다. 전자는 "일정: 부분 이행, 사유: 고객 요구사항 변경, 사전 통보 및 대안 제시"로 남고, 재협업 의사는 대개 "예"입니다. 후자는 "일정: 미이행, 사전 통보 없음"으로 남습니다. 실패한 프로젝트에서 좋은 기록을 남기는 것은 가능하고, 실제로 흔합니다.

부정직 이후의 회복 경로

부정직으로 신뢰를 잃은 경우는 다릅니다. 고객 우회, 정보 유출, 기여 가로채기, 대금 미정산 같은 행동(제11장)이 윤리·분쟁위원회에서 확인되면 제재가 따르고, 그 기록은 Trust Capital에 남습니다. 그러나 제명이 아닌 한, 회복의 길은 열려 있습니다.

원장은 지워지지 않지만 새 항목이 추가됩니다. 회복은 삭제가 아니라 덧쓰기입니다. 그 경로는 다음과 같습니다.

인정 ──▶ 피해 회복 ──▶ 제한 기간 ──▶ 작은 프로젝트에서 재시작 ──▶ 새 기록의 축적
(사실 인정,     (미정산 대금 지급,   (참여 제한 또는    (Junior Slot 등          (최근 36개월의
 반론이 아닌    사과, 유출 정보의    등급 조정 기간)    낮은 위험의 역할)          기록이 요약의
 설명)          회수 협조)                                                     중심이 됨)

첫 단계는 인정입니다. 위원회의 결정을 받아들이고 사실을 인정하는 것입니다. 변명이 아니라 설명을 남길 수 있고, 그 설명은 기록에 함께 남습니다. 두 번째는 피해 회복입니다. 미정산 대금이 있으면 지급하고, 피해를 본 사람에게 사과합니다. 세 번째는 제한 기간입니다. 제재의 내용에 따라 일정 기간 프로젝트 참여가 제한되거나 등급이 조정됩니다. 네 번째는 재시작입니다. 제한이 풀리면 작은 프로젝트의 낮은 위험 역할부터 다시 시작합니다. 다섯 번째는 축적입니다. 새 기록이 쌓이고, 시간 가중에 따라 과거의 기록은 요약에서 비중이 낮아집니다.

이 경로는 쉽지 않습니다. 쉬워서는 안 됩니다. 그러나 닫혀 있어서도 안 됩니다. 한 번의 부정직으로 사람을 영원히 지우는 조직은 사람을 소모품처럼 다루는 조직입니다. 우리는 그렇게 하지 않습니다. 다만 두 번째 부정직에는 첫 번째보다 훨씬 엄격합니다. 반복은 실수가 아니라 패턴이기 때문입니다.

다시 기회를 주는 것도 기여입니다

회복 경로에는 한 사람이 더 필요합니다. 제한이 풀린 사람을 자기 프로젝트에 받아 주는 Project Lead입니다. 이것은 위험을 감수하는 일이고, 우리는 그것을 기여로 봅니다. 그 Lead의 Trust Capital에는 Mentoring 유형의 기여가 기록됩니다. 다시 기회를 주는 사람이 없으면 회복 경로는 종이 위에만 존재합니다.

Case: 같은 실패, 다른 기록

이 사례는 가상의 사례입니다.

상황. 크리에이터 최 씨는 Creator Circle에서 AI 광고 영상 프로젝트에 참여했습니다. 화장품 고객사의 캠페인 영상 여섯 편, 총 3천6백만원 규모, Project Lead는 마케터 오 씨였습니다. 최 씨의 Work Compensation(수행 대가)은 편당 2백만원, 총 1천2백만원이었고, 나머지 잉여가치는 Contribution Matrix에 따라 나누기로 했습니다.

같은 시기에 개발자 윤 씨는 Builder Circle에서 유통 고객사의 챗봇 프로젝트에 참여했습니다. 2천4백만원 규모, 두 달 일정이었습니다.

갈등. 두 사람 모두 일정을 지키지 못했습니다. 최 씨는 다른 두 개의 프로젝트를 동시에 받았고, 고객사의 수정 요청이 예상보다 많아 넷째 편부터 일정이 밀리기 시작했습니다. 윤 씨는 고객사의 데이터 접근이 늦어졌고, 그 사이 다른 일을 하다 통합 테스트 기간을 놓쳤습니다.

차이는 그 다음이었습니다. 최 씨는 셋째 편을 납품하던 날 오 씨에게 상황을 알렸습니다. 남은 세 편의 일정이 각각 열흘씩 밀릴 것 같다고 말했고, 두 가지 대안을 제시했습니다. 하나는 Creator Circle의 다른 크리에이터에게 한 편을 넘기고 자신의 대가에서 그 비용을 부담하는 것, 다른 하나는 고객사와 일정을 재협의하는 것이었습니다. 오 씨는 고객사와 협의하여 2주 연장을 받았고, 최 씨는 한 편을 동료에게 넘겼습니다.

윤 씨는 마감일 이틀 전까지 아무 말이 없었습니다. Lead가 진행 상황을 묻자 "고객 쪽 데이터가 늦어서 어쩔 수 없었다"고 답했습니다. 데이터가 늦은 것은 사실이었지만, 그 3주 동안 윤 씨가 무엇을 했는지는 설명하지 않았습니다. 프로젝트는 한 달 늦게 끝났고, 고객사는 후속 프로젝트를 다른 곳에 맡겼습니다.

적용. 두 프로젝트 모두 Closing Review를 작성했습니다.

최 씨의 기록에는 "일정: 부분 이행. 사유: 병행 프로젝트 과다 및 고객 수정 증가. 3편 납품 시점에 사전 통보, 대안 2건 제시, 1편 이관 비용 자기 부담"이 남았습니다. 재협업 의사는 오 씨와 동료 크리에이터 모두 "조건부 예"였고, 조건은 "병행 프로젝트 수 사전 확인"이었습니다. 정산은 최 씨가 이관 비용 2백만원을 부담한 뒤 기한 안에 끝났습니다.

윤 씨의 기록에는 "일정: 미이행. 사전 통보 없음. 고객 데이터 지연은 사실이나 지연 기간 중 진행 상황 공유 없음"이 남았습니다. 재협업 의사는 Lead가 "아니오", 동료 한 명이 "조건부 예"였습니다. 윤 씨는 기록에 "데이터 지연은 제 책임이 아니다"라는 설명을 덧붙였고, 그 설명도 함께 남았습니다.

결과. 넉 달 뒤 최 씨는 새 프로젝트에 지원했습니다. Lead는 요약에서 "조건부 예"를 보고 최 씨에게 물었습니다. "지금 병행 중인 프로젝트가 몇 개입니까." 최 씨는 하나라고 답했고, Charter에 병행 상한을 명시하는 데 동의했습니다. 프로젝트는 일정대로 끝났고, 이번 재협업 의사는 "예"였습니다. 두 번째 기록이 첫 번째 기록에 맥락을 주었습니다. 최 씨의 Trust Capital은 "일정을 한 번 놓쳤지만 정직하게 처리했고, 그 뒤로 지킨 사람"을 말하게 되었습니다.

윤 씨는 그 뒤 두 번의 지원에서 선택받지 못했습니다. Circle Leader가 윤 씨와 이야기했습니다. 윤 씨는 처음에는 억울해했지만, 자기 기록을 다시 읽고 나서 "데이터가 늦었을 때 그 사실을 알렸어야 했다"고 인정했습니다. Circle Leader는 윤 씨에게 Circle 안의 작은 기여를 제안했고, 윤 씨는 챗봇 평가 프레임워크에 대한 워크숍을 열었습니다. 그 워크숍에서 만난 Lead가 윤 씨를 다음 프로젝트의 Junior Slot에 넣었습니다. 윤 씨는 이번에는 매주 진행 상황을 공유했고, 재협업 의사는 "예"로 기록되었습니다.

두 사람 모두 같은 실패를 겪었습니다. 그러나 원장에는 다르게 남았고, 둘 다 회복했지만 회복의 길이는 달랐습니다. 신뢰는 실패하지 않는 것이 아니라, 실패했을 때 어떻게 행동하는가의 기록입니다.

Remember

• 신뢰는 인상이 아니라 기록입니다. 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사의 일곱 가지 행동으로 정의합니다.
• Trust Capital은 프로젝트를 제대로 끝내면 저절로 쌓입니다. Charter, Contribution Matrix, Settlement Sheet, Closing Review가 그 기록입니다.
• 직함·팔로워·자기소개는 Capability의 힌트일 수는 있지만 Trust가 아닙니다. 유명한 사람도 Member에서 시작합니다.
• 기록은 점수가 아니라 요약으로 제공되고, 판단은 사람이 합니다. 최근 36개월이 중심이며, 기록은 지워지지 않고 덧쓰입니다.
• 실패는 신뢰를 깎지 않습니다. 실패의 처리가 신뢰를 만듭니다. 부정직 이후에도 인정·피해 회복·제한·재시작·축적의 회복 경로는 열려 있습니다.

"신뢰는 말이 아니라 행동으로 쌓습니다. 그리고 우리는 그 행동을 기록합니다."

실패한 사람과 부정직한 사람을 어떻게 구분하고, 커뮤니티는 부정직에 어떻게 대응하는가.

질문에서 시작합니다

한 프로젝트가 예정보다 두 달 늦게 끝났습니다. 모델 성능이 목표에 못 미쳤고, 고객은 실망했습니다. 같은 달, 다른 프로젝트에서는 한 참여자가 고객 담당자에게 따로 연락해 "다음 건은 제가 직접 하겠습니다"라고 제안했습니다. 두 사람 중 누구와 다시 일하시겠습니까.

대부분의 사람은 두 번째 사람을 피하겠다고 답합니다. 그런데 현실의 커뮤니티는 종종 첫 번째 사람을 더 가혹하게 대합니다. 실패는 눈에 보이고, 우회는 조용히 일어나기 때문입니다. 지연된 프로젝트는 모두가 알지만, 몰래 가져간 고객은 소개한 사람만 뒤늦게 압니다.

제10장에서 우리는 신뢰가 행동의 원장이라고 말했습니다. 이 장은 그 원장의 반대편 항목을 다룹니다. 어떤 행동이 신뢰를 깨는가, 왜 생기는가, 커뮤니티는 어디까지 관대하고 어디서부터 엄격한가. 목적은 회원을 겁주는 것이 아닙니다. 어떤 실수는 안전하고 어떤 행동은 안전하지 않은지를 미리 알려서, 실수를 두려워하지 않고 일할 수 있게 하는 것입니다.

왜 이것이 문제인가

느슨한 커뮤니티에서는 신뢰를 깨는 행동이 큰 문제가 되지 않습니다. 오픈채팅에서 누군가 약속을 어겨도 잃을 것이 없습니다. 관계도 기록도 보상도 없기 때문입니다. 반대로 전통 기업에서는 고용계약과 취업규칙이 이런 행동을 막습니다. 회사 고객을 빼돌리면 해고되고, 경우에 따라 소송이 따릅니다.

한국인공지능커뮤니티는 그 중간에 있습니다. 구성원은 각자의 회사와 직장을 유지한 채 필요할 때 Project Cell(프로젝트 셀)로 결합합니다. 고용이 아니므로 취업규칙이 없고, 단순한 모임이 아니므로 잃을 것이 있습니다. 이 조직을 묶는 것은 공유된 규약과 기록된 신뢰입니다. 그래서 신뢰를 깨는 행동은 한 사람의 잘못으로 끝나지 않습니다. 조직을 묶는 끈 자체를 끊습니다.

AI 시대의 조건은 이 문제를 더 날카롭게 만듭니다. 실행 비용이 낮아질수록 "누구와 일할 것인가"의 가치가 올라갑니다. 코드와 영상과 문서는 싸졌고, 판단과 관계와 책임은 비싸졌습니다. 한 사람이 고객을 우회하거나 정보를 유출하면, 그 사람이 가져간 것은 한 건의 계약이 아닙니다. 커뮤니티가 가장 비싸게 축적한 자산인 "여기서 만난 사람은 믿어도 된다"는 전제를 가져간 것입니다.

부정직은 전염됩니다. 한 사람이 우회하고도 아무 일이 없으면, 다음 사람은 "나만 손해 보는 것 아닌가"라고 생각하기 시작합니다. 그래서 커뮤니티는 부정직에 개인적 실망이 아니라 조직적 대응을 해야 합니다.

일곱 가지 행동

아래는 커뮤니티가 부정직으로 분류하는 일곱 가지 행동입니다. 등장인물은 모두 가상이며, 상황은 반복적으로 나타나는 유형을 조합한 것입니다. 각 사례는 상황, 유혹이 생기는 이유, 깨지는 것, 커뮤니티의 대응을 봅니다.

1. 고객 우회(Circumvention)

상황. 마케터 정 씨가 커뮤니티에서 만난 개발자 김 씨를 자신의 고객사에 소개했습니다. 첫 프로젝트는 3천만원 규모였고, 김 씨가 대부분을 수행했습니다. 프로젝트가 끝난 뒤 고객 담당자는 김 씨에게 직접 연락해 다음 프로젝트를 제안했습니다. 김 씨는 정 씨에게 알리지 않고 5천만원짜리 두 번째 계약을 자기 회사 명의로 체결했습니다.

왜 유혹이 생기는가. 김 씨의 논리는 이렇습니다. "일은 내가 다 했다. 정 씨는 소개만 했다. 고객이 나를 원한다." 틀린 말은 아닙니다. 그러나 고객이 김 씨를 알게 된 경로는 정 씨였고, 그 경로는 커뮤니티였습니다.

무엇이 깨지는가. 정 씨는 다시는 커뮤니티에 고객을 소개하지 않을 것입니다. Originator(기회를 가져온 사람)가 사라지면 Executor(수행자)도 일감을 잃습니다. 김 씨는 5천만원을 얻고 커뮤니티는 고객 유입 경로 하나를 잃었습니다.

커뮤니티의 대응. Non-circumvention(우회 금지) 원칙은 커뮤니티를 통해 만난 고객과 소개자를 배제하고 직접 거래하는 것을 기본 24개월간 금지합니다(제17장 참조). 고객이 직접 원한 경우는 예외가 아니라 절차의 시작입니다. 김 씨는 정 씨에게 알리고, 체감(逓減)하는 소개 기여를 인정하는 합의를 기록해야 했습니다. 이 사례에서 김 씨는 소개 기여분을 정산하고 경고를 받았습니다.

2. 정보 유출(Leakage)

상황. 연구자 이 박사는 한 제조사의 불량 검출 프로젝트에 참여했습니다. 프로젝트는 Cell-only(셀 내부 한정) 등급이었습니다. 몇 주 뒤 이 박사는 세미나 발표에서 고객사 이름과 불량률 수치, 그리고 고객이 검토 중인 설비 투자 계획을 언급했습니다. "좋은 사례라서 공유하고 싶었다"는 것이 이유였습니다.

왜 유혹이 생기는가. 실제 사례는 발표를 살립니다. 구체적인 숫자와 회사 이름이 있으면 청중이 집중합니다. 발표자는 인정을 받고, 다음 기회가 생깁니다. 유출은 대개 악의가 아니라 인정 욕구에서 시작됩니다.

무엇이 깨지는가. 고객은 자신의 설비 투자 계획이 외부 세미나에서 언급된 것을 알게 됩니다. 고객이 잃은 것은 정보이고, 커뮤니티가 잃은 것은 "여기에 맡기면 안전하다"는 평판입니다. 같은 Project Cell의 다른 참여자들은 아무 잘못 없이 신뢰를 잃습니다.

커뮤니티의 대응. 이 사례는 고의성 판단이 핵심입니다. 이 박사는 Confidentiality Checklist(비밀유지 체크리스트)에 서명했으나 등급의 의미를 정확히 이해하지 못했습니다. 윤리·분쟁위원회는 이를 "부주의한 유출"로 보고 경고와 재교육을 결정했습니다. 다만 고객에게는 Project Lead가 즉시 알리고 사과했습니다. 유출의 처리 절차는 제12장에서 자세히 다룹니다.

3. 기여 가로채기(Credit Theft)

상황. 크리에이터 한 씨는 AI 영상 프로젝트에서 핵심 워크플로우를 설계했습니다. 프로젝트가 끝나고 Project Lead인 오 대표는 외부 발표와 플랫폼의 프로젝트 기록에서 그 워크플로우를 자신의 성과로 기록했습니다. 한 씨는 "제작 참여"로만 남았습니다.

왜 유혹이 생기는가. Project Lead는 프로젝트의 얼굴입니다. 외부는 Lead를 기억하고, 다음 기회는 Lead에게 옵니다. 팀원의 기여를 자신의 것으로 만들면 다음 프로젝트를 따는 데 유리합니다. 게다가 "내가 방향을 잡았으니 내 성과"라는 자기합리화는 쉽습니다.

무엇이 깨지는가. 기여한 사람을 잊지 않는다는 원칙이 깨집니다. 한 씨는 다음 프로젝트에서 최선을 다할 이유를 잃습니다. 기여 기록은 신뢰의 원장인데, 그 원장이 거짓이 되면 다음 팀 구성은 잘못된 정보 위에서 이루어집니다. 매칭의 정확도가 떨어집니다.

커뮤니티의 대응. Contribution Matrix(기여도 평가표)는 Project Lead 혼자 작성하지 않습니다. 참여자 전원이 확인하고, 이의가 있으면 Project Closing Review(종료평가)에서 다룹니다. 한 씨는 기여 기록 정정을 요청했고, 프로젝트 자료가 이를 뒷받침했습니다. 기록이 정정되었고, 오 대표는 경고를 받았습니다. 정정을 거부했다면 Project Lead 역할 제한이 따랐을 것입니다.

4. 비용 부풀리기(Cost Inflation)

상황. 파운더 박 대표는 1억원 규모의 프로젝트에서 Project Lead를 맡았습니다. Project Settlement Sheet(정산표)에는 GPU 임대비 1,200만원이 직접비용으로 잡혔습니다. 실제 임대비는 700만원이었고, 차액 500만원은 박 대표가 자신의 회사 계좌로 처리했습니다. 잉여가치가 500만원 줄어들자 다른 참여자들의 Value Sharing(가치 배분)도 그만큼 줄었습니다.

왜 유혹이 생기는가. 직접비용은 Lead가 가장 잘 알고 다른 참여자는 확인하기 어렵습니다. 몇백만원 차이는 "관리 비용"이나 "리스크 프리미엄"으로 포장하기 쉽습니다. 정산이 복잡할수록 유혹은 커집니다.

무엇이 깨지는가. 함께 만든 가치를 실제 기여에 따라 공정하게 나눈다는 약속이 깨집니다. 비용 부풀리기는 다른 참여자의 주머니에서 직접 돈을 꺼내는 행위입니다. 발견되면 그 Lead와 다시 일할 사람은 없고, 발견되지 않으면 모든 정산이 의심받습니다.

커뮤니티의 대응. 직접비용은 증빙과 함께 정산표에 첨부되며, 참여자 누구나 열람할 수 있습니다. 이 사례는 한 참여자가 GPU 업체의 공개 단가와 비교하다 발견했습니다. 박 대표는 차액을 반환하고 Project Lead 역할이 12개월간 제한되었습니다.

5. 허위경력(Credential Fraud)

상황. 개발자 최 씨는 프로필에 "대규모 LLM 파인튜닝 프로젝트 3건 수행"이라고 적었습니다. 실제로는 튜토리얼을 따라 한 번 해 본 것이 전부였습니다. 이 프로필을 근거로 팀에 합류했고, 프로젝트는 최 씨가 맡은 부분에서 8주를 잃었습니다.

왜 유혹이 생기는가. 프로필은 기회의 입구입니다. 조금 부풀리면 더 좋은 프로젝트에 들어갈 수 있고, "들어가서 배우면 된다"고 생각합니다. AI 분야는 변화가 빨라 경력의 경계가 모호하고, 부풀리기가 쉽습니다.

무엇이 깨지는가. 팀 구성 기준인 Capability + Experience + Trust + Availability + Fit 중 앞의 두 가지가 거짓이 됩니다. 매칭이 틀리면 프로젝트가 흔들리고, 정직하게 자기 수준을 밝힌 다른 후보는 기회를 잃습니다.

커뮤니티의 대응. Verified 단계의 검증 경로(AI TEST 인증, 추천, 실적 확인)는 이런 상황을 줄이기 위한 것입니다. 최 씨는 등급이 Member로 조정되었고, 프로필은 검증된 내용으로 정정되었습니다. 처음부터 "해 본 적은 없지만 배우고 싶다"고 밝혔다면 Junior Slot으로 참여할 수 있었고, 아무 제재도 없었을 것입니다.

6. 대금 미정산(Non-settlement)

상황. 계약주체(Contracting Party)였던 윤 대표의 회사가 고객으로부터 6천만원을 수령했습니다. 정산표에 따라 참여자 4명에게 Work Compensation(수행 대가) 3,200만원을 지급해야 했지만, 윤 대표는 "회사 자금 사정"을 이유로 석 달째 미루었습니다. 그 사이 윤 대표는 새 프로젝트를 시작했습니다.

왜 유혹이 생기는가. 돈은 계약주체 계좌에 먼저 들어옵니다. 회사 운영이 어려우면 그 돈을 잠시 쓰고 싶어집니다. "곧 정산할 것"이라는 말은 자신에게도 진심처럼 들립니다.

무엇이 깨지는가. 사람을 소모품처럼 다루지 않는다는 원칙이 깨집니다. Work Compensation은 이미 수행한 노동의 대가입니다. 이를 미루는 것은 참여자에게 무이자 대출을 강요하는 것입니다.

커뮤니티의 대응. 정산 기한은 Project Charter(프로젝트 헌장)에 명시하며, 기본값은 고객 입금 후 14일 이내입니다(Charter로 조정 가능). 기한을 넘기면 계약주체는 사유와 새 기한을 참여자 전원에게 알려야 합니다. 이 사례에서 참여자들은 당사자 협의 후 윤리·분쟁위원회에 회부했고, 윤 대표는 분할 정산 계획에 합의했습니다. 정산이 완료될 때까지 윤 대표는 새로운 Project Cell의 계약주체가 될 수 없었습니다.

7. 반복적인 약속 위반(Repeated Breach)

상황. 연구원 장 씨는 세 개의 프로젝트에서 연속으로 중간 산출물 기한을 어겼습니다. 매번 그럴듯한 이유가 있었고, 매번 사과했습니다. 그러나 사전에 알린 적은 한 번도 없었습니다. 기한 당일에야 "못 했다"고 말했습니다.

왜 유혹이 생기는가. 미리 알리면 자기 무능을 인정하는 것 같고, 당일에 말하면 "어쩔 수 없었다"로 넘어갈 수 있다고 생각합니다.

무엇이 깨지는가. 한 번의 지연은 실패입니다. 알리지 않은 지연이 반복되면 부정직입니다. 팀은 장 씨의 일정을 믿을 수 없게 되고, 매번 여유를 두어야 합니다. 그 여유는 다른 사람의 시간에서 나옵니다.

커뮤니티의 대응. 커뮤니티는 지연 자체를 제재하지 않습니다. 사전 통보 없는 지연이 반복되면 Trust Capital의 일정 항목에 기록되고, 세 번째부터는 Project Lead가 참여 제한을 요청할 수 있습니다. 장 씨는 이후 두 프로젝트에서 "위험이 보이면 48시간 전에 알린다"는 조건으로 참여했고, 실제로 그렇게 했습니다. 기록은 그것도 남깁니다.

우리의 철학

일곱 가지 사례를 관통하는 것은 하나입니다. 실패에는 관대하되 부정직에는 엄격하다. 이 문장의 앞부분과 뒷부분은 같은 무게입니다. 어느 한쪽만 강조하면 조직은 망가집니다.

부정직에도 관대하면 정직한 사람이 손해를 봅니다. 우회하는 사람이 돈을 벌고 소개하는 사람이 사라집니다. 반대로 실패에도 엄격하면 아무도 어려운 일을 맡지 않습니다. AI 프로젝트는 본질적으로 불확실합니다. 이런 실패를 처벌하는 조직은 안전한 일만 하는 조직이 됩니다.

우리는 실패와 부정직을 결과가 아니라 행동으로 구분합니다. 프로젝트가 망했는가는 기준이 아닙니다. 그 과정에서 무엇을 알렸고, 무엇을 숨겼고, 누구의 것을 가져갔는가가 기준입니다. 성공한 프로젝트에서도 부정직은 있을 수 있고, 실패한 프로젝트에서도 정직은 있을 수 있습니다.

전통 기업은 인사평가로 사람을 판단하고, 시장은 가격으로 판단합니다. 우리는 기록된 행동으로 판단합니다. 신뢰는 말이 아니라 행동으로 쌓이고, 같은 이유로 행동으로 깨집니다. 제재 역시 인성에 대한 판단이 아니라 행동에 대한 대응입니다. 그래서 제재에는 반드시 재심과 회복의 경로가 있습니다.

운영원칙

실패와 부정직을 구분하는 기준

핵심은 두 가지 질문입니다. 알렸는가, 가져갔는가. 알렸다면 대부분 실패이고, 숨겼다면 부정직에 가깝습니다. 남의 것을 가져갔다면 결과와 무관하게 부정직입니다.

제재 단계

제재는 커뮤니티의 기본값이며, 윤리·분쟁위원회(Ethics & Dispute Committee)가 사안에 따라 조정합니다.

제재 원칙은 다음과 같습니다.

1. 행동에 비례합니다. 첫 부주의는 경고에서 시작합니다. 고의성, 피해 규모, 은폐 여부, 반복 여부가 단계를 올립니다.
2. 금전 피해는 먼저 회복합니다. 우회로 얻은 이익의 소개 기여분, 부풀린 비용, 미정산 대금은 제재와 별개로 정산합니다.
3. 공개 성토를 금지합니다. 단체방에서 특정인을 성토하는 것은 그 자체로 규약 위반입니다. 분쟁은 당사자 협의 → Project Lead 조정 → 윤리·분쟁위원회 → 외부 중재의 순서를 따릅니다(제26장 참조).
4. 기록은 사실만 남깁니다. Trust Capital에는 "어떤 행동이 있었고 어떤 조치가 있었는가"를 남깁니다. 인성에 대한 평가는 남기지 않습니다.
5. 이해상충은 회피합니다. 위원회 구성원이 당사자와 경제적 이해가 걸려 있으면 심의에서 물러납니다. Governance Power ≠ Economic Opportunity는 제재에서도 적용됩니다.

재심 절차

제재를 받은 사람은 결정 통지 후 14일 이내에 재심을 청구할 수 있습니다. 재심은 원심에 참여하지 않은 위원으로 구성된 별도 패널이 맡습니다. 재심 청구자는 새로운 사실이나 절차상 하자를 제시해야 합니다. 재심 결과는 30일 이내에 서면으로 통지되며, 제명은 Council의 확인을 거칩니다.

제재 기간이 끝나면 회복 절차가 있습니다. 참여 제한이 끝난 회원은 소규모 프로젝트로 다시 시작할 수 있고, 등급 조정을 받은 회원은 재검증으로 등급을 회복합니다. 기록은 지워지지 않지만, 그 이후의 행동도 기록됩니다. Contribution creates Trust, not Permanent Privilege라는 원칙은 반대로도 작동합니다. 과거의 위반은 기록을 만들지만 영구적인 낙인을 만들지는 않습니다.

회색지대를 다루는 법

모든 사안이 표에 깔끔하게 들어가지는 않습니다. 자주 나타나는 회색지대와 기본 처리 방향은 다음과 같습니다.

회색지대에서 위원회가 보는 것은 언제나 같습니다. 알렸는가, 기록했는가, 가져갔는가. 이 세 질문에 정직하게 답할 수 있으면 대부분 실패 쪽에 놓입니다.

Case: 고객이 먼저 손을 내밀었을 때

가상의 사례입니다. 개발자 서 씨는 파운더 강 대표의 소개로 한 물류회사의 재고 예측 프로젝트에 참여했습니다. 계약주체는 강 대표의 회사였고, 규모는 4천만원이었습니다. Contribution Matrix에서 강 대표는 Origination과 Sales, 서 씨는 Execution으로 기록되었습니다. 프로젝트는 성공적으로 끝났습니다.

넉 달 뒤, 물류회사 담당자가 서 씨에게 직접 연락했습니다. "강 대표 회사를 거치면 비용이 올라간다. 다음 건은 서 씨 개인과 직접 계약하고 싶다." 규모는 7천만원이었습니다. 서 씨에게는 두 가지 선택이 있었습니다.

첫 번째 선택은 조용히 계약하는 것입니다. 고객이 먼저 원했으니 문제없다고 생각할 수 있습니다. 두 번째 선택은 강 대표에게 알리는 것입니다. 서 씨는 두 번째를 택했습니다. 플랫폼의 프로젝트 기록에 고객의 제안 사실을 남기고, 강 대표에게 연락했습니다.

강 대표의 첫 반응은 서운함이었습니다. 그러나 규약은 명확했습니다. 고객은 누구의 소유물도 아니며, 다만 관계를 만든 기여는 인정됩니다. 두 사람은 다음과 같이 합의했습니다. 계약주체는 서 씨가 되고, 강 대표는 후속 프로젝트에 대한 체감하는 소개 기여로 잉여가치의 일정 비율을 받습니다. 7천만원 프로젝트에서 직접비용과 Work Compensation을 제한 잉여가치가 2천만원이었고, 그중 강 대표의 소개 기여분은 첫 후속 프로젝트 기준 15%인 300만원으로 정해졌습니다. 이 비율은 24개월에 걸쳐 줄어듭니다. 합의는 플랫폼에 기록되었습니다.

결과는 세 가지였습니다. 서 씨는 정당하게 계약주체가 되었고 Trust Capital에 "고객 직접 제안을 투명하게 처리"라는 기록이 남았습니다. 강 대표는 소개 기여를 인정받았고, 이후에도 커뮤니티에 고객을 소개했습니다. 물류회사는 커뮤니티의 절차를 보았고, 다음 프로젝트를 커뮤니티에 맡겼습니다. 만약 서 씨가 첫 번째 선택을 했다면 300만원을 더 벌었을 것입니다. 그리고 강 대표의 소개도, 물류회사의 다음 프로젝트도, 서 씨의 기록도 사라졌을 것입니다. 규약이 요구하는 것은 소개자의 허락이 아니라 투명한 통보와 기록입니다.

Remember

• 실패와 부정직은 결과가 아니라 행동으로 구분합니다. 알렸는가, 가져갔는가, 이 두 질문이 기준입니다.
• 일곱 가지 부정직(고객 우회, 정보 유출, 기여 가로채기, 비용 부풀리기, 허위경력, 대금 미정산, 반복적 약속 위반)은 한 사람의 이익을 위해 조직을 묶는 끈을 끊는 행동입니다.
• 제재는 경고 → 프로젝트 참여 제한 → 등급 조정 → 제명의 순서로 행동에 비례하며, 재심과 회복의 경로가 항상 있습니다.
• 회색지대에서 안전한 쪽은 언제나 같습니다. 먼저 알리고, 기록하고, 합의하는 것입니다.
• 공개 성토는 정의가 아니라 또 다른 위반입니다. 분쟁은 절차를 따릅니다.

"실패에는 관대하되 부정직에는 엄격하다."

지식을 숨기지 않으면서도 고객과 동료의 비밀을 지키는 커뮤니티는 어디까지 공유하고 어디부터 보호하는가.

질문에서 시작합니다

Builder Circle의 월례 세미나에서 개발자 김 씨가 발표를 준비합니다. 지난 석 달간 한 유통사의 상품 추천 프로젝트를 했고, 배운 것이 많습니다. 어떤 임베딩 모델이 한국어 상품명에 잘 맞았는지, 어떤 프롬프트 구조가 실패했는지, 고객사 데이터 파이프라인이 얼마나 엉망이었는지, 그리고 고객이 내년에 추천 시스템을 자체 개발팀으로 내재화할 계획이라는 것까지.

김 씨는 어디까지 말해야 할까요. 아무것도 말하지 않으면 세미나는 뉴스 요약이 됩니다. 인터넷에서 얻을 수 있는 정보를 나누려고 회원들이 시간을 내지는 않습니다. 반대로 전부 말하면 고객은 자신의 내재화 계획이 외부에 알려진 것을 알게 되고, 커뮤니티에 다시 일을 맡기지 않을 것입니다.

이 긴장은 한국인공지능커뮤니티의 정체성 한가운데 있습니다. 우리는 실제로 해본 사람만 아는 경험을 나누기 위해 모였습니다. 동시에 우리는 고객과 동료의 비밀을 지키기 위해 울타리를 쳤습니다(제9장 참조). 이 장은 그 두 약속을 동시에 지키는 방법을 다룹니다. Confidential Community는 입을 닫는 커뮤니티가 아닙니다. 무엇을 열고 무엇을 닫을지 아는 커뮤니티입니다.

왜 이것이 문제인가

느슨한 커뮤니티에는 이 문제가 없습니다. 오픈채팅에는 보호할 정보가 없기 때문입니다. 아무도 고객 이름을 말하지 않고, 아무도 실제 숫자를 말하지 않습니다. 그래서 정보는 흐르지만 가치가 없습니다. 전통 기업에도 이 문제는 다른 형태로 있습니다. 회사 안에서는 정보가 공유되지만 회사 밖으로는 거의 나가지 않습니다. 경쟁사의 실패담을 들을 방법은 없습니다.

프로토콜 조직은 그 사이에 있습니다. 구성원은 각자의 회사와 고객을 가지고 있으면서 Project Cell(프로젝트 셀)로 결합합니다. 한 사람이 여러 셀에 속하고, 한 셀에는 서로 다른 회사 사람들이 있습니다. 정보는 사람을 따라 이동합니다. 김 씨가 유통사 프로젝트에서 배운 것은 다음 프로젝트에서 다른 고객을 위해 쓰입니다. 이것이 커뮤니티가 만드는 가치입니다. 동시에 유통사의 내재화 계획도 김 씨를 따라 이동할 수 있습니다. 이것이 커뮤니티가 막아야 하는 것입니다.

AI 시대는 이 문제를 두 방향으로 키웁니다. 첫째, 경험의 가치가 올라갔습니다. 모델과 도구는 누구나 쓸 수 있지만, 어떤 조건에서 무엇이 실제로 작동하는가는 해본 사람만 압니다. 이 지식은 논문에도 블로그에도 없습니다. 커뮤니티에서 공유되지 않으면 어디서도 공유되지 않습니다. 둘째, 유출의 비용이 올라갔습니다. 고객 데이터 한 조각, 미공개 모델 가중치 하나, 사업 전략 한 줄이 AI 도구와 결합하면 예전보다 훨씬 빠르게 경쟁자의 자산이 됩니다.

그래서 "알아서 잘 판단하라"는 답이 되지 않습니다. 김 씨는 선의로 발표를 준비했지만, 어디까지가 안전한지 기준이 없으면 두 가지 중 하나가 일어납니다. 너무 많이 말하거나, 두려워서 아무것도 말하지 않거나. 커뮤니티는 김 씨에게 기준을 주어야 합니다. 그 기준이 정보 등급과 세 가지 규약입니다.

우리의 철학

우리는 지식을 숨기는 조직이 아닙니다. 커뮤니티가 존재하는 이유는 실제로 해본 사람만 아는 경험이 신뢰 가능한 범위 안에서 흐르게 하는 것입니다. 공유는 기여이고, 기여는 기록되며, 기록은 신뢰가 됩니다. Knowledge 유형의 기여가 플랫폼에 기록되는 이유입니다. 기여한 사람을 잊지 않는다는 원칙은 발표한 사람, 실패담을 나눈 사람, 벤치마크를 공개한 사람에게도 적용됩니다.

동시에 우리는 고객과 동료의 비밀을 강력하게 보호합니다. 이 두 가지는 모순이 아닙니다. 공유해야 하는 것과 보호해야 하는 것은 종류가 다르기 때문입니다.

기준은 단순합니다. 배운 것은 공유하고, 맡은 것은 보호합니다. 김 씨가 한국어 상품명 임베딩에서 배운 것은 김 씨의 경험입니다. 유통사의 내재화 계획은 김 씨가 맡은 것입니다. 전자는 공유해야 커뮤니티가 살고, 후자는 보호해야 커뮤니티가 삽니다.

이것은 프로토콜 조직의 설계 원리 중 "신뢰는 행동의 원장이다"와 직접 연결됩니다. 비밀유지는 Trust Capital의 항목입니다. 비밀을 지킨 기록이 쌓인 사람에게는 더 깊은 정보가 열리고, 더 깊은 정보가 열린 사람은 더 큰 프로젝트에 참여합니다. Restricted 등급의 프로젝트에 초대받는 것은 그 사람의 비밀유지 기록에 대한 신뢰의 표현입니다. Contribution creates Trust, not Permanent Privilege. 비밀유지도 기여입니다.

운영원칙: 정보 등급

커뮤니티의 모든 정보는 네 등급 중 하나에 속합니다. 등급은 정보를 만든 사람 또는 Project Lead가 정하며, 정하지 않은 정보의 기본값은 Community입니다.

등급 운영의 원칙은 다음과 같습니다.

1. 낮은 등급으로 내리는 것은 어렵고, 높은 등급으로 올리는 것은 쉽습니다. Cell-only 정보를 Community로 낮추려면 Project Lead와 고객의 확인이 필요합니다. 반대로 어떤 회원이든 자신이 다루는 정보를 더 높은 등급으로 지정할 수 있습니다.
2. 불확실하면 한 단계 위로 봅니다. 등급이 표시되지 않은 프로젝트 정보는 Cell-only로 취급합니다.
3. 등급은 Project Charter에 적습니다. 프로젝트를 시작할 때 Confidentiality Checklist(비밀유지 체크리스트, Appendix F)를 작성하고, 어떤 정보가 어느 등급인지 참여자 전원이 확인합니다.
4. 고객 식별 정보를 제거하면 등급이 내려갈 수 있습니다. "한 유통사의 상품 추천 프로젝트"는 Community 등급으로 공유할 수 있습니다. 회사 이름, 매출 규모, 담당자 이름이 없어야 합니다. 단, 업계가 좁아 식별이 가능하면 제거로 인정되지 않습니다.
5. 프로젝트 종료 후에도 등급은 유지됩니다. 기본값은 종료 후 24개월이며, Charter로 조정합니다. 고객과의 계약이 더 긴 기간을 정하면 계약이 우선합니다.

운영원칙: 세 가지 규약

정보 등급이 "무엇을"이라면, 규약은 "어떻게"입니다. 커뮤니티는 세 가지 수단을 씁니다.

NDA(비밀유지계약)는 프로젝트 단위로 체결합니다. 커뮤니티 가입 시 회원은 Korea AI Community Charter(커뮤니티 헌장)에 서명하며, 헌장에는 일반적 비밀유지 의무가 포함됩니다. 그러나 Restricted 등급 정보를 다루는 프로젝트는 별도의 NDA를 체결합니다. NDA는 계약주체(Contracting Party)와 참여자 사이에 맺으며, 고객이 요구하는 NDA가 있으면 그것이 우선합니다. NDA 없이 Restricted 정보를 공유한 사람과 받은 사람 모두 책임이 있습니다.

Chatham House Rule은 모임에서 적용됩니다. 규칙은 하나입니다. 모임에서 들은 내용은 쓸 수 있지만, 누가 말했는지와 어느 조직의 이야기인지는 밝히지 않습니다. 이 규칙이 있어야 사람들이 실패담을 말합니다. "우리 회사가 이 모델로 3개월을 날렸다"는 이야기는 발언자가 특정되지 않을 때만 나옵니다. 커뮤니티의 모든 세미나, 원탁 모임, 식사 자리는 별도 표시가 없으면 Chatham House Rule이 적용됩니다.

Closed Room은 참여자만 접근하는 공간입니다. 플랫폼의 Project Cell 공간이 대표적입니다. Cell-only 이상의 정보는 Closed Room 안에서만 다룹니다. Closed Room에는 참여자 목록이 있고, 누가 언제 무엇을 보았는지 기록됩니다. 기록의 목적은 감시가 아니라 유출이 생겼을 때 범위를 빠르게 확인하기 위함입니다.

정보 등급              적용 규약                    공간
─────────────────────────────────────────────────────────────
Public       →  제한 없음                     →  어디서나
Community    →  Chatham House Rule            →  회원 공간, 모임
Cell-only    →  Chatham House Rule + Charter  →  Closed Room
Restricted   →  NDA                           →  Closed Room 접근 통제 영역

모임에서 Chatham House Rule은 어떻게 작동하는가

규칙은 간단하지만 실제 적용은 상황마다 다릅니다. 커뮤니티의 세 가지 대표 모임에서 어떻게 작동하는지 봅니다.

세미나. 발표자는 발표 자료를 Community 등급으로 준비합니다. 고객 이름 대신 "제조 분야의 한 중견기업"으로, 실제 수치 대신 "약 30% 개선"처럼 상대 수치로 표현합니다. 질의응답에서 나온 이야기는 참석자가 자기 일에 쓸 수 있지만, "지난 세미나에서 김 씨가 A사 프로젝트에서"라고 옮길 수 없습니다. 발표 자료는 플랫폼에 Community 등급으로 올라가며, 회원이 아닌 사람에게 전달하지 않습니다. 발표 녹화는 발표자가 동의한 경우에만 하고, 동의해도 Community 등급을 유지합니다.

AI Table. 열 명 안팎이 한 주제로 깊게 이야기하는 원탁 모임입니다. 세미나보다 구체적인 이야기가 나옵니다. 여기서는 진행자가 시작할 때 규칙을 한 문장으로 확인합니다. "오늘 이야기는 쓸 수 있지만, 누가 어느 회사 이야기를 했는지는 밖으로 나가지 않습니다." 참석자가 "이건 여기서만"이라고 말하면 그 부분은 Cell-only에 준하는 것으로 취급하고 모임 밖에서 인용하지 않습니다. 모임 후 정리 노트는 진행자가 발언자를 제거한 형태로 작성하고, 참석자 확인 후 플랫폼에 올립니다.

Founder Dinner. Founder Circle의 저녁 모임입니다. 사업 이야기는 본질적으로 전략과 숫자를 포함합니다. 여기서는 규칙이 더 엄격하게 작동합니다. 매출, 투자 유치, 인력 문제 같은 이야기는 그 자리에서 끝납니다. 정리 노트를 만들지 않으며, 그 자리에서 들은 것을 근거로 다른 회원에게 투자나 채용을 제안하려면 발언자에게 먼저 동의를 받습니다. 저녁 자리에서 들은 정보로 상대의 고객에게 접근하는 것은 Chatham House Rule 위반이자 고객 우회입니다(제11장 참조).

세 모임에 공통되는 것이 있습니다. 규칙은 참석자를 침묵시키기 위한 것이 아니라 말하게 하기 위한 것입니다. 발언자를 보호해야 실패담이 나오고, 실패담이 나와야 커뮤니티에 올 이유가 생깁니다.

메신저와 플랫폼

현실의 대화는 카카오톡 같은 메신저에서 일어납니다. 프로젝트 팀은 메신저 방을 만들고, Circle은 단체방을 운영합니다. 커뮤니티는 이것을 막지 않습니다. 메신저는 빠르고 익숙하며, 실행은 빠르게 이루어져야 합니다. 그러나 원칙은 분명합니다. 대화는 메신저에서 하더라도, 관계와 기여와 기록은 플랫폼에 축적됩니다.

이유는 두 가지입니다. 첫째, 메신저는 기록이 아닙니다. 방이 사라지면 대화도 사라지고, 누가 무엇을 기여했는지 남지 않습니다. 기여한 사람을 잊지 않으려면 기여가 플랫폼에 있어야 합니다. 둘째, 메신저는 통제가 되지 않습니다. 누가 방에 있는지 확인하기 어렵고, 캡처 한 번이면 정보가 어디로든 갑니다. Cell-only 이상의 정보가 메신저에 있으면 그 정보는 사실상 등급을 잃은 것입니다.

메신저 방에서의 정보 취급 규칙은 다음과 같습니다.

이 규칙에서 Project Lead가 가장 자주 부딪히는 것은 "결정" 항목입니다. 메신저에서 "그럼 그렇게 하죠"로 끝난 보상 변경은 나중에 반드시 분쟁이 됩니다. 실행은 빠르게, 이해관계 변경은 합의로. 그 합의는 플랫폼에 있어야 합의입니다.

유출이 발생했을 때

유출은 일어납니다. 완전히 막을 수는 없으며, 중요한 것은 얼마나 빨리 알고 얼마나 정직하게 다루는가입니다. 대응 절차는 다음 순서를 따릅니다.

1. 발견과 신고(즉시). 유출을 발견하거나 자신이 유출했음을 인지한 사람은 Project Lead에게 즉시 알립니다. 자진 신고는 제11장의 기준에 따라 실패 쪽에 놓입니다. 숨기다가 발견되면 부정직입니다.
2. 범위 확인(24시간 이내). Project Lead는 무엇이, 어디까지, 누구에게 나갔는지 확인합니다. Closed Room의 접근 기록이 여기서 쓰입니다. 메신저 방이라면 방 구성원과 전달 경로를 확인합니다.
3. 고객 통보(48시간 이내). Cell-only 이상의 정보가 나갔다면 계약주체가 고객에게 알립니다. 늦게 알리는 것이 유출 자체보다 관계를 더 크게 훼손합니다. 통보에는 사실, 범위, 조치를 담고, 추측은 담지 않습니다.
4. 확산 차단. 전달받은 사람에게 삭제를 요청하고 확인을 받습니다. 외부로 나갔다면 계약주체와 고객이 함께 대응 방향을 정합니다.
5. 원인 기록과 위원회 회부. Project Lead는 경위를 플랫폼에 기록합니다. 고의성이 의심되거나 피해가 발생했으면 윤리·분쟁위원회(Ethics & Dispute Committee)에 회부합니다. 판단 기준은 제11장의 실패·부정직 구분을 따릅니다.
6. 재발 방지. 등급 지정이 불명확했는지, 메신저 규칙이 지켜졌는지, NDA가 있었는지를 확인하고 Charter를 수정합니다.

유출에 대한 제재는 제11장의 단계를 따릅니다. 고의가 아닌 유출을 스스로 알린 경우는 경고 이하입니다. 등급을 알면서 외부에 제공한 경우는 참여 제한 이상이며, 대가를 받고 제공한 경우는 제명 사유입니다. 단체방에서 유출자를 지목하는 것은 어떤 경우에도 금지됩니다. 그것 자체가 또 하나의 유출입니다.

Case: 세미나 발표 자료의 두 가지 버전

가상의 사례입니다. 크리에이터 윤 씨는 Creator Circle에서 한 화장품 브랜드의 AI 광고 영상 프로젝트를 마쳤습니다. 프로젝트는 Cell-only 등급이었고, 브랜드와 계약주체 사이에는 NDA가 있었습니다. Circle Leader가 윤 씨에게 세미나 발표를 제안했습니다. 윤 씨는 발표 자료 초안을 Project Lead인 마케터 조 씨에게 보냈습니다.

초안에는 다음이 있었습니다. 브랜드 이름과 제품 이미지, 영상 제작에 쓴 도구와 프롬프트 구조, 세 가지 스타일을 비교한 결과, 브랜드가 승인한 최종 영상, 제작비 1,500만원과 기존 실사 촬영 대비 절감률, 그리고 브랜드가 다음 분기에 AI 영상으로 전면 전환한다는 계획.

조 씨는 초안을 등급별로 나눴습니다. 도구와 프롬프트 구조, 스타일 비교 결과는 윤 씨가 배운 것이므로 Community 등급으로 공유 가능했습니다. 브랜드 이름과 제품 이미지는 고객 식별 정보였습니다. 최종 영상은 이미 공개된 광고였으므로 Public이었지만, 그 영상을 보여주면 브랜드가 특정되므로 발표에서는 뺐습니다. 제작비와 절감률은 계약 조건이므로 Restricted였습니다. 전면 전환 계획은 사업 전략이므로 Restricted였습니다.

윤 씨는 처음에 반발했습니다. "브랜드 이름 없이 광고 사례를 어떻게 발표합니까." 조 씨의 답은 이랬습니다. "회원들이 알고 싶은 것은 브랜드가 아니라 어떤 프롬프트 구조가 왜 실패했는지입니다." 윤 씨는 발표 자료를 다시 만들었습니다. "한 뷰티 브랜드"로 표현하고, 스타일 비교는 브랜드 요소를 제거한 테스트 영상으로 대체했습니다. 절감률은 "실사 촬영 대비 절반 이하"로만 표현하고 금액은 뺐습니다. 전면 전환 계획은 전부 삭제했습니다.

세미나에서 가장 반응이 좋았던 부분은 실패한 두 가지 스타일의 원인 분석이었습니다. 브랜드 이름은 아무도 묻지 않았습니다. 발표 자료는 Community 등급으로 플랫폼에 올랐고, 윤 씨의 기여 기록에 Knowledge 항목이 추가되었습니다. 두 달 뒤 윤 씨는 그 발표를 본 파운더의 제안으로 새 프로젝트에 참여했습니다.

같은 사례에서 윤 씨가 초안 그대로 발표했다면 어떻게 되었을까요. 브랜드는 자신의 전환 계획이 세미나에서 언급된 것을 알게 되었을 것입니다. 계약주체는 NDA 위반 책임을 졌을 것이고, 조 씨는 발표 자료를 사전에 확인하지 않은 책임을 졌을 것입니다. 윤 씨는 배운 것을 나누려 했을 뿐이지만, 커뮤니티는 고객 하나와 평판을 잃었을 것입니다. 발표 자료를 Lead가 먼저 보는 절차는 그래서 있습니다.

Remember

• 배운 것은 공유하고, 맡은 것은 보호합니다. 경험·워크플로우·벤치마크·인사이트·실패담은 공유의 대상이고, 고객정보·계약조건·미공개 기술·사업전략·개인정보는 보호의 대상입니다.
• 정보는 Public / Community / Cell-only / Restricted 네 등급 중 하나에 속하며, 불확실하면 한 단계 위로 봅니다.
• Chatham House Rule은 침묵을 위한 규칙이 아니라 발언을 위한 규칙입니다. 내용은 쓰되 발언자와 조직은 특정하지 않습니다.
• 대화는 메신저에서 하더라도 관계·기여·기록은 플랫폼에 축적됩니다. 플랫폼에 없는 합의는 합의가 아닙니다.
• 유출은 숨기지 않고 즉시 알립니다. 자진 신고는 실패이고, 은폐는 부정직입니다.

"Confidential Community는 입을 닫는 커뮤니티가 아니라, 무엇을 열고 무엇을 닫을지 아는 커뮤니티다."

한국인공지능커뮤니티에서 실제로 돈이 오가고 결과물이 만들어지는 단위는 무엇이며, 그것은 회사·외주팀·지인 모임과 어떻게 다른가.

질문에서 시작합니다

가상의 상황 하나로 시작합니다. 파운더 박 대표는 중견 제조기업으로부터 "현장 작업자용 AI 매뉴얼 검색 시스템"을 만들어 달라는 요청을 받았습니다. 예산은 있고 고객은 진지합니다. 문제는 박 대표의 회사에 직원이 두 명뿐이고, 그중 LLM을 다뤄본 사람이 없다는 것입니다.

박 대표에게는 세 가지 선택지가 있습니다. 첫째, 개발자를 채용합니다. 하지만 이 프로젝트는 넉 달짜리이고, 다음 프로젝트가 있을지는 모릅니다. 둘째, 외주 개발사에 맡깁니다. 하지만 어느 개발사가 이 일을 정말 할 수 있는지 판단할 능력이 박 대표에게 없고, 견적서 한 장으로 사람을 믿어야 합니다. 셋째, 아는 개발자에게 부탁합니다. 그러면 계약도, 보상 기준도, 무언가 잘못됐을 때의 절차도 없이 "우리 사이에 뭘"이라는 말로 시작하게 됩니다.

채용은 무겁고, 외주는 믿기 어렵고, 지인은 위험합니다. 그런데 커뮤니티 안에는 이 일을 해본 개발자 김 씨가 있고, 문서 검색 품질을 평가할 줄 아는 연구자 이 박사가 있으며, 현장 작업자 인터뷰와 화면 설계를 해본 기획자 최 씨가 있습니다. 이들은 각자 직장과 회사가 있습니다. 넉 달 동안만, 이 일을 위해서만, 하나의 팀처럼 움직일 수는 없을까요.

이 질문에 대한 커뮤니티의 답이 Project Cell(프로젝트 셀) 입니다.

왜 이것이 문제인가

AI 시대의 일은 점점 더 "짧고, 다양하고, 결합이 필요한" 형태로 바뀌고 있습니다. 하나의 프로젝트에 모델 이해와 데이터 처리, 화면과 영상, 고객과의 대화, 계약과 정산이 한꺼번에 필요합니다. 예전에는 이런 일을 하려면 이 모든 사람을 고용한 회사가 있어야 했습니다. 지금은 개인 한 사람이 AI 도구의 도움으로 훨씬 많은 일을 할 수 있지만, 그래도 한 사람이 다 감당하기에는 범위가 너무 넓습니다.

기존의 조직 형태는 이 조건에 잘 맞지 않습니다. 회사는 사람을 고용으로 묶기 때문에 일이 없을 때도 비용이 나가고, 일이 생겼을 때는 필요한 역량이 안에 없습니다. 프리랜서 시장은 유연하지만 매번 처음부터 사람을 찾고 검증해야 하며, 지난번 프로젝트에서 쌓은 신뢰가 다음 프로젝트로 이어지지 않습니다. 오픈채팅 같은 느슨한 커뮤니티는 사람이 많아도 아무도 책임지지 않기 때문에 일이 시작되지 않습니다.

그래서 현실에서는 어정쩡한 형태가 반복됩니다. 친한 사람끼리 구두로 시작한 프로젝트가 한 사람이 바빠지면서 멈추고, 누가 얼마를 받을지 정해 두지 않아 끝난 뒤 관계가 상합니다. 잘 되어도 고객이 다음 일을 주려 할 때 "우리"가 누구인지 아무도 정의하지 못하고, 결과물의 코드와 워크플로우가 누구 것인지도 불분명합니다.

이 문제의 본질은 사람이 부족한 것이 아니라 결합의 형식이 없는 것입니다. 좋은 사람들이 있어도, 그들이 언제 모이고 어떻게 일하고 무엇을 나누고 언제 헤어지는지에 대한 공유된 형식이 없으면 결합은 일어나지 않거나, 일어나도 오래가지 못합니다. 거래비용의 관점에서 보면, 회사는 시장에서 매번 사람을 찾고 검증하고 계약하는 비용이 너무 커서 생긴 조직입니다. Project Cell은 그 반대 방향의 질문에서 나옵니다. 신뢰가 기록되고 규약이 공유되어 거래비용이 충분히 낮아지면, 굳이 회사를 만들지 않고도 회사처럼 일할 수 있지 않을까.

우리의 철학

Project Cell은 한국인공지능커뮤니티의 실제 경제활동 단위입니다. Circle이 지식과 관계가 축적되는 실행 공동체라면, Project Cell은 그 관계가 실제 계약과 매출과 결과물로 바뀌는 자리입니다. 커뮤니티가 "이야기하는 곳"에서 "함께 만드는 곳"이 되는 지점이 바로 여기입니다.

   Business        Developer       Researcher       Creator         Marketer
  (사업·고객)      (엔지니어링)     (연구·검증)      (영상·이미지)     (시장·확산)
      │               │               │               │               │
      └───────────────┴───────────────┼───────────────┴───────────────┘
                                      ▼
                      ┌───────────────────────────────┐
                      │         PROJECT CELL          │
                      │  목적 · 기간 · Charter · Lead   │
                      │  보상 구조 · IP · 비밀유지       │
                      └───────────────┬───────────────┘
                                      ▼
                       결과물 · 매출 · 기록된 기여 · 신뢰
                                      ▼
                            해체 → 다음 결합으로

셀은 Virtual Company(가상 회사) 입니다. 회사처럼 목적과 책임자와 보상 구조와 계약이 있지만, 회사와 달리 일이 끝나면 해체됩니다. 구성원은 셀에 고용되지 않습니다. 각자의 회사, 직장, 연구실, 스튜디오를 그대로 유지한 채 이 셀에 자기 역량을 결합합니다. 이것이 프로토콜 조직의 첫 번째 설계 원리인 독립성과 결합성(Independent & Composable) 입니다. 독립성을 잃지 않으면서, 결합할 때는 대기업급 집단 역량을 냅니다.

이 구조는 새로운 것이 아닙니다. 영화 산업에서는 감독, 촬영, 조명, 편집, 음악을 담당하는 사람들이 한 편의 영화를 위해 모이고, 개봉하면 흩어지며, 다음 작품에서 다시 만납니다. 그들은 서로를 직함이 아니라 지난 작품에서 어떻게 일했는지로 기억합니다. 우리가 할리우드식 프로젝트 조직에서 배우려는 것은 그 점입니다. 짧게 결합하되, 평판과 기록은 길게 남는다는 것.

다만 우리는 그 방식의 약점도 압니다. 평판이 기록되지 않고 소문으로만 돌면, 처음 들어온 사람은 기회를 얻기 어렵고 기회는 아는 사람 사이에서만 순환합니다. 한국인공지능커뮤니티의 Project Cell은 여기에 두 가지를 더합니다. 기여와 신뢰를 플랫폼에 기록하고, 기회를 공개 채널로 흘려보냅니다. 기록이 있어야 신뢰가 되고, 신뢰가 있어야 다음 결합이 생깁니다. 기여한 사람을 잊지 않는다는 약속은 셀이 해체된 뒤에도 유효합니다.

셀의 구성원은 직함이 아니라 Capability Node(역량 노드) 로 참여합니다. 교수는 "교수"로 참여하는 것이 아니라 "검색 품질 평가 설계"라는 역량으로 참여합니다. 대표는 "대표"로 참여하는 것이 아니라 "고객 관계와 계약 책임"이라는 역량으로 참여합니다. 셀 안에서 사람은 직급으로 서열화되지 않고, 역할에 맞는 책임과 기회를 받습니다. 사람을 소모품처럼 다루지 않는다는 약속은 셀의 크기가 작을수록 더 분명하게 지켜져야 합니다.

역할별로 보는 셀

같은 셀이라도 서 있는 자리에 따라 다르게 보입니다.

사업가에게 셀은 고정비 없이 실행 역량을 확보하는 방법입니다. 다만 셀은 외주 인력풀이 아닙니다. 셀에 참여하는 사람들은 시장 단가로 먼저 보상받고, 잉여가치에 대한 몫을 가지며, 프로젝트의 방향에 의견을 냅니다.

교수와 연구자에게 셀은 실제 산업 문제와 데이터를 만나는 통로입니다. 논문 일정과 납품 일정은 자주 충돌하므로, 맡는 범위를 "검증 설계와 결과 해석"처럼 명확히 자르고 시간 투입의 한계를 Charter에 미리 적는 편이 좋습니다.

개발자와 크리에이터에게 셀은 본업을 지키면서 실전 프로젝트와 경제적 기회를 얻는 구조입니다. 가장 흔한 실패는 본업이 바빠질 때 셀에서 조용히 사라지는 것입니다. 사라지지 말고 알리십시오. 알린 이탈은 실패이고, 알리지 않은 이탈은 부정직입니다.

운영원칙

셀의 크기

셀의 권장 크기는 3명에서 7명입니다. 이것은 커뮤니티의 기본값이며 Project Charter로 조정할 수 있습니다. 두 명이면 역할 분담과 상호 검증이 어렵고 한 사람의 이탈이 곧 프로젝트의 중단이 됩니다. 여덟 명이 넘으면 조정 비용이 실행 비용을 넘어서기 시작하고, 기여를 구분하기 어려워지며, 회의가 일이 됩니다. 큰 프로젝트는 하나의 큰 셀보다 여러 개의 작은 셀로 나누고, 셀 사이의 인터페이스와 책임 경계를 각 Charter에 정하는 편이 낫습니다.

셀의 유형

네 유형은 보상 구조가 다릅니다. 고객 프로젝트는 Work Compensation(수행 대가)과 Value Sharing(가치 배분)이 모두 발생합니다. PoC·연구 셀은 당장의 매출이 없으므로 참여자가 "무엇을 얻는가"(데이터, 논문 공저, 후속 프로젝트 우선 참여 등)를 Charter에 미리 적어야 합니다. 제품 개발 셀은 성공하면 회사가 되므로 지분과 Background IP를 시작할 때 정리해야 합니다(제28장 참조). 커뮤니티 프로젝트는 금전 보상이 없는 대신 기여가 Event·Infrastructure·Knowledge 유형으로 기록되어 Trust Capital이 됩니다.

셀의 생애주기

Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review
 (씨앗)  (제안)   (구성)     (헌장)          (계약)      (실행)       (정산)        (종료평가)
                    ▲                                                                │
                    └──────────── 기록된 기여와 신뢰가 다음 셀로 이어진다 ─────────────┘

셀은 Charter가 서명되는 순간 만들어지고, Closing Review가 끝나는 순간 해체됩니다. 시작 전과 끝난 뒤에는 셀이 존재하지 않습니다. 셀이 끝났는데 계속 "우리 팀"으로 남아 고객을 붙들고 있으면 그것은 셀이 아니라 회사이며, 회사를 만들려면 정식으로 만들어야 합니다(제28장 참조). 각 단계에서 무엇을 하는지는 제14장에서 다룹니다.

셀과 Circle의 관계

Circle은 셀을 낳는 토양입니다. Circle 안에서 사람들은 서로의 실력을 보고, 작은 협업을 해 보고, 누구와 일하고 싶은지 알게 됩니다. 하지만 셀은 Circle의 하위 조직이 아닙니다. 한 셀에 Builder Circle과 Creator Circle과 Expert Circle 사람이 함께 있는 것이 정상입니다.

Circle Leader는 셀의 상급자가 아닙니다. Circle Leader가 자기 Circle에서 나온 셀에 참여하고 싶다면 다른 회원과 같은 기준으로 참여하며, 자기 Circle 안의 기회를 자기가 먼저 가져가는 것은 이해상충입니다(제24장 참조). Governance Power ≠ Economic Opportunity. 이 원칙은 Circle과 셀의 경계에서 가장 자주 시험받습니다.

셀에서 AI 도구와 에이전트의 위치

AI 시대의 셀에는 사람 외에도 많은 것이 일합니다. 코드를 쓰는 에이전트, 영상을 생성하는 모델, 문서를 요약하는 워크플로우가 셀의 생산성을 몇 배로 올립니다. 그러나 커뮤니티는 이들을 셀의 구성원으로 세지 않습니다. AI 도구와 에이전트는 장비입니다. 카메라가 촬영팀의 구성원이 아니듯, 에이전트는 개발자의 동료가 아니라 개발자의 장비입니다.

이 구분은 세 가지 실무적 결과를 낳습니다. 첫째, 책임은 언제나 사람이 집니다. 에이전트가 만든 코드에 결함이 있으면 그 에이전트를 운용한 사람의 결함입니다. 둘째, 기여도 사람에게 기록됩니다. "AI가 80%를 했다"는 말은 기여 평가에서 의미가 없습니다. 그 AI를 선택하고, 지시하고, 검증하고, 결과를 책임진 사람이 기여자입니다. 셋째, 도구 비용은 직접비용입니다. API 호출료, GPU 사용료, 유료 도구 구독료는 사람의 Work Compensation과 구분하여 프로젝트 직접비용으로 정산합니다. 이것은 기본값이며 Charter에서 달리 정할 수 있습니다.

다만 AI 장비를 누가 가져오는지는 기여로 인정합니다. 자기 회사의 GPU 서버를 셀에 제공한 사람, 검증된 워크플로우를 가져온 사람은 Capital & Infra 또는 Knowledge 범주의 기여자입니다. 장비 자체는 구성원이 아니지만, 장비를 가져온 사람은 구성원입니다.

셀이 아닌 것

회원 두 명이 커뮤니티 밖에서 개인적으로 하는 협업은 셀이 아니며, 커뮤니티의 분쟁 절차도 적용되지 않습니다. 한 회원이 자기 회사 직원들과 하는 내부 프로젝트도 셀이 아닙니다. 고객을 소개만 하고 실행에 관여하지 않는 것은 Connection 기여이지 셀이 아닙니다. 셀은 커뮤니티 안에서, Charter 위에서, 둘 이상의 Capability Node가 결합할 때 성립합니다.

셀이 지켜야 할 최소 규약

1. 셀은 반드시 Project Charter를 가집니다. Charter가 없으면 셀이 아니라 모임입니다.
2. 셀에는 반드시 한 명의 Project Lead가 있습니다. 공동 리드는 가능하지만 최종 실행 판단의 책임자는 한 명입니다.
3. 셀의 정보는 기본적으로 Cell-only 등급입니다. 참여자만 접근하는 Closed Room을 씁니다.
4. 셀에 참여하는 사람은 자기 본업과의 이해상충을 시작 전에 신고합니다. 본업 회사가 고객의 경쟁사라면 참여할 수 없거나 범위를 제한합니다.
5. 셀은 참여자의 본업을 침해하지 않습니다. 본업의 근무시간과 회사 자원을 쓰지 않으며, 고용계약상 겸업 제한이 있는 사람은 자기 책임으로 확인합니다.
6. 셀이 해체될 때 Closing Review를 남깁니다. 기여와 신뢰의 기록은 셀보다 오래 삽니다.

Case: 넉 달짜리 가상 회사

가상의 사례입니다. 앞서 등장한 파운더 박 대표는 제조기업의 요청을 플랫폼에 Proposal로 올렸습니다. 개발자 김 씨, 연구자 이 박사, 기획자 최 씨가 참여했고, Junior Slot으로 대학원생 정 씨가 들어왔습니다. 다섯 명, 넉 달, 계약금액 6천만원. 박 대표의 회사가 Contracting Party(계약주체)가 되었고 박 대표가 Project Lead를 맡았습니다.

두 번째 달에 갈등이 생겼습니다. 김 씨의 본업 회사에 큰 배포가 잡혀 3주 동안 셀에 쓸 시간이 거의 없어진 것입니다. 회사였다면 상사가 우선순위를 정해 줬을 것이고, 외주였다면 계약 위반을 따졌을 것입니다. 셀에서는 어떻게 할까요.

Charter에는 "주 10시간 이상 투입이 어려워지면 48시간 안에 Lead에게 알린다"는 조항이 있었습니다. 김 씨는 이를 지켰습니다. 박 대표는 실행 판단으로 정 씨의 역할을 일시적으로 넓히고, Builder Circle에 3주짜리 보조 개발자를 공개 모집했습니다. 이것은 참여자 변경이므로 전원 합의를 거쳤습니다. 김 씨의 Work Compensation은 실제 투입 시간에 맞춰 조정하되, Value Sharing에서의 Execution 기여는 설계를 주도한 몫을 그대로 인정하기로 기록했습니다. 실행은 빠르게, 이해관계 변경은 합의로.

프로젝트는 2주 늦게 끝났습니다. 고객은 만족했고, 정산 후 잉여가치의 5%가 Community Share로 갔습니다. Closing Review에서 김 씨는 "미리 알렸다"는 점에서 신뢰를 잃지 않았고, 정 씨는 첫 프로젝트 기록을 얻었으며, 셀은 해체되었습니다. 여섯 달 뒤 같은 고객이 2차 프로젝트를 요청했을 때, 새 셀은 다시 Proposal에서 시작했습니다. 다섯 명 중 셋이 다시 모였고, 두 자리는 공개 채널로 새 사람에게 열렸습니다.

셀이 회사와 다른 점은 김 씨가 본업을 포기하지 않고도 참여했다는 것이고, 외주와 다른 점은 일정 문제가 계약 분쟁이 아니라 기록된 신뢰의 문제로 다뤄졌다는 것이며, 지인 모임과 다른 점은 모든 것이 Charter와 기록 위에서 움직였다는 것입니다.

Remember

• Project Cell은 커뮤니티의 경제활동 단위입니다. 필요할 때 만들어지고 일이 끝나면 해체되는 Virtual Company입니다.
• 구성원은 각자의 회사와 직장을 유지한 채 역량으로 결합합니다. 독립성을 잃지 않으면서 집단 역량을 냅니다.
• 셀의 권장 크기는 3~7명이며, Charter와 Lead가 없으면 셀이 아닙니다.
• Circle은 셀을 낳는 토양이지 셀의 상급자가 아닙니다. Circle Leader의 권한은 사업기회의 우선권이 아닙니다.
• AI 도구와 에이전트는 장비입니다. 책임과 기여는 언제나 사람에게 기록됩니다.

"셀은 해체되지만, 기여와 신뢰의 기록은 남는다."

아이디어가 셀이 되고 셀이 계약이 되기까지 어떤 단계를 거치며, 시작할 때 무엇을 적어 두어야 끝날 때 싸우지 않는가.

질문에서 시작합니다

가상의 상황입니다. 마케터 한 씨는 오래 알고 지낸 화장품 브랜드의 마케팅 담당자로부터 연락을 받았습니다. 신제품 론칭에 맞춰 SNS용 광고 영상을 AI로 만들어 보고 싶은데, 예산은 3천만원 정도이고 6주 안에 나와야 한다는 것입니다. 한 씨는 영상을 직접 만들 수 없습니다. 하지만 커뮤니티의 Creator Circle에서 AI 영상을 만드는 크리에이터 윤 씨의 작업을 본 적이 있습니다.

한 씨는 윤 씨에게 연락합니다. 윤 씨는 흔쾌히 하겠다고 합니다. 여기서 두 사람이 흔히 하는 말은 "일단 시작하고 나중에 정하자"입니다. 고객이 급하고, 서로 호의가 있고, 세부 조건을 따지는 것이 야박해 보이기 때문입니다.

6주 뒤에 무슨 일이 생길지 상상해 봅시다. 영상은 나왔지만 고객이 세 번째 수정을 요구합니다. 수정은 범위에 포함되는 것일까요. 윤 씨가 만든 캐릭터 일관성 워크플로우는 누구 것일까요. 한 씨는 고객을 데려왔으니 얼마를 가져가야 할까요. 중간에 합류한 개발자 서 씨는 어떤 기준으로 보상받을까요. 고객이 다음 캠페인을 윤 씨에게 직접 맡기고 싶다고 하면 한 씨는 어떻게 될까요. 이 질문들은 시작할 때 30분이면 정할 수 있었던 것들입니다. 끝날 때는 30일을 싸워도 정하기 어렵습니다.

왜 이것이 문제인가

공동 프로젝트의 대부분은 끝에서 실패하는 것처럼 보이지만, 실제로는 시작에서 실패합니다. 시작할 때 정하지 않은 것이 끝날 때 갈등이 됩니다. 범위를 정하지 않으면 수정 요구가 끝나지 않고, 역할을 정하지 않으면 아무도 맡지 않은 일이 생기며, 보상 구조를 정하지 않으면 정산 자리에서 각자의 기억이 충돌합니다. 기억은 언제나 자기에게 유리한 쪽으로 기울어 있습니다.

"나중에 정하자"가 반복되는 이유는 두 가지입니다. 하나는 어색함입니다. 아직 매출도 없는데 돈 이야기를 꺼내면 관계가 계산적으로 보일까 걱정합니다. 다른 하나는 낙관입니다. 잘 될 것이라고 믿기 때문에 잘 안 될 때의 절차를 만들지 않습니다. 하지만 시작할 때 어색한 대화를 피한 대가는 끝날 때 관계 자체를 잃는 것입니다. 한 번 그렇게 잃은 관계는 커뮤니티 전체의 신뢰 밀도를 낮춥니다.

AI 시대에는 이 문제가 더 커집니다. 실행이 빨라졌기 때문입니다. 영상 한 편을 만드는 데 몇 주가 아니라 며칠이 걸리면, 사람들은 "이렇게 짧은 일에 무슨 문서까지"라고 생각합니다. 그러나 실행이 빨라질수록 판단·관계·책임의 비중은 커집니다. 만드는 데 사흘 걸린 영상을 두고 누가 무엇을 책임지는지 정하지 않으면, 사흘의 실행이 석 달의 분쟁이 됩니다.

시작을 형식화하지 않을 때 생기는 또 하나의 문제는 기회가 닫힌다는 것입니다. 한 씨가 윤 씨에게만 조용히 연락하면, 이 프로젝트에 더 잘 맞는 다른 크리에이터나 신규회원은 기회가 있었다는 사실조차 모릅니다. 조용한 시작은 기회를 아는 사람 사이에서만 순환시킵니다. 그것은 커뮤니티가 아니라 폐쇄된 인맥입니다.

우리의 철학

한국인공지능커뮤니티는 프로젝트의 시작을 형식화합니다. 관료주의를 위해서가 아니라 자유를 위해서입니다. 시작할 때 30분을 들여 적어 두면, 실행 중에는 매번 합의를 구하지 않고 빠르게 움직일 수 있습니다. 실행은 빠르게, 이해관계 변경은 합의로. 이 원칙이 작동하려면 "이해관계"가 무엇인지 처음에 적혀 있어야 합니다.

커뮤니티의 프로젝트 생애주기는 여덟 단계입니다. 이 장은 앞의 여섯 단계를 다룹니다. Settlement(정산)와 Closing Review(종료평가)는 제18장과 제20장에서 다룹니다.

 Idea ──▶ Proposal ──▶ Team ──▶ Project Charter ──▶ Contract ──▶ Execution
 씨앗       제안         구성        헌장               계약          실행
  │          │           │           │                 │             │
  아이디어    플랫폼의     공개 기준   1~2페이지          고객과의      Lead가
  검증       Opportunity  으로 선정   서명               법적 계약     실행 판단
            로 공개

각 단계는 "다음 단계로 가도 되는가"를 확인하는 관문입니다. 관문은 사람을 막기 위한 것이 아니라, 준비되지 않은 프로젝트가 사람을 소모하지 않도록 하기 위한 것입니다. 사람을 소모품처럼 다루지 않는다는 약속은 시작 단계에서 가장 구체적으로 지켜집니다.

이 형식의 핵심은 Project Charter(프로젝트 헌장) 입니다. Charter는 셀의 헌법입니다. 1~2페이지에 목적·범위·역할·Lead·의사결정 방식·보상 구조·IP·비밀유지·종료 조건·이해상충을 담습니다. 이 열 가지 항목은 모두 "끝날 때 싸우는 주제"의 목록입니다. Charter는 그 싸움을 시작으로 옮겨 놓은 문서입니다. 길게 쓸 필요는 없습니다. 짧아도 빠진 항목이 없어야 합니다.

여섯 단계에서 하는 일

Idea: 아이디어를 검증한다

아이디어는 고객의 요청일 수도 있고, 연구자의 가설일 수도 있고, 크리에이터가 발견한 시장의 빈틈일 수도 있습니다. 이 단계에서 확인할 것은 세 가지입니다. 이것이 실제 문제인가(고객이 돈을 내려 하는가, 또는 검증할 가치가 있는가). 커뮤니티 안에 이것을 할 사람이 있을 법한가. 내가 이 아이디어를 셀로 만들 만큼 시간을 낼 수 있는가. Circle에서 가볍게 이야기해 보는 것이 이 단계의 전형적인 모습입니다. 이때는 고객명이나 금액을 밝히지 않아도 됩니다.

Proposal: 제안을 쓰고 Opportunity로 공개한다

아이디어가 살아남으면 Proposal을 씁니다. Proposal은 Charter의 초안이자 팀 모집 공고입니다. 두 부분으로 나뉩니다. 공개 부분은 플랫폼의 Opportunity(기회)로 게시됩니다. 프로젝트의 성격, 필요한 역량과 역할, 기간, 보상의 범위, Confidentiality 등급, Junior Slot 여부가 들어갑니다. 비공개 부분은 고객명, 정확한 금액, 고객의 내부 사정처럼 셀에 참여한 뒤에야 볼 수 있는 정보입니다.

Proposal을 Opportunity로 공개하는 것은 커뮤니티의 원칙입니다. 기회는 공개 채널로 흐릅니다. 기본값으로 Opportunity는 최소 72시간 동안 게시되며, 이 기간 동안 조건을 충족하는 회원은 누구나 지원할 수 있습니다. 긴급한 경우 Circle Leader의 확인을 받아 48시간으로 줄일 수 있습니다. 고객이 특정 회원을 지명한 경우에도 나머지 자리는 공개합니다. 이 숫자들은 기본값이며 상황에 따라 조정할 수 있으나, 조정한 이유는 기록합니다.

Team: 공개 기준으로 팀을 만든다

지원자 가운데 Capability + Experience + Trust + Availability + Fit을 기준으로 팀을 구성합니다. 이 과정은 제15장에서 자세히 다룹니다. 이 단계에서 확인할 것은 셀의 크기가 3~7명 안에 있는지, 필요한 역량이 모두 채워졌는지, 누가 Project Lead인지, 신규회원에게 열린 자리가 있는지입니다. 선정 결과와 기준은 기록합니다.

Project Charter: 헌장을 쓰고 서명한다

팀이 모이면 첫 회의에서 Charter를 완성합니다. Proposal의 초안에 팀이 정한 역할·보상·IP·종료 조건을 채웁니다. 참여자 전원이 읽고 서명합니다. 서명은 전자 서명이나 플랫폼의 동의 기록으로 충분합니다. Charter가 서명되는 순간 셀이 성립합니다. 서명하지 않은 사람은 셀의 구성원이 아니며, 서명하지 않은 채 일을 시작하는 것은 셀이 아니라 호의입니다. 호의는 기록되지 않고, 기록되지 않은 기여는 보호받지 못합니다.

Contract: 고객과 계약한다

고객이 있는 프로젝트라면 Contracting Party(계약주체)가 고객과 법적 계약을 맺습니다. 계약주체는 셀의 참여자 가운데 사업자를 가진 개인이나 회사, 또는 여러 참여자가 합의한 하나의 회사입니다. 계약주체는 세금계산서를 발행하고 대금을 받고 법적 책임을 지므로, 그 위험부담은 Contribution Matrix의 Leadership & Risk 범주에서 인정합니다. 계약서와 Charter는 모순되어서는 안 됩니다. 특히 납품물의 IP, 수정 횟수, 대금 지급 시점, 중도 해지 조건은 두 문서에서 같은 내용이어야 합니다.

Execution: 실행한다

계약이 서명되고 계약금이 들어오면 실행합니다. 실행 판단은 Project Lead가 합니다. 무엇을 먼저 만들지, 어떤 도구를 쓸지, 고객에게 언제 중간본을 보여줄지는 Lead가 결정합니다. 보상 구조·범위·참여자를 바꾸는 것은 이해관계 변경이므로 참여자 합의를 거칩니다. 실행 중에 Charter를 바꿔야 한다면 바꾸되, 바뀐 내용과 날짜와 합의한 사람을 기록합니다. Lead의 권한과 책임은 제16장에서 다룹니다.

운영원칙

Project Charter의 열 가지 항목

이 표의 숫자와 비율은 커뮤니티의 기본값이며 Charter로 조정할 수 있습니다. 다만 조정한 항목은 "기본값과 다르게 정했다"고 표시합니다. 그래야 나중에 읽는 사람이 실수인지 의도인지 구분할 수 있습니다.

IP 귀속의 기본값

IP는 시작할 때 정하지 않으면 반드시 문제가 되는 항목이므로 따로 적습니다. 커뮤니티의 기본값은 세 층입니다.

1. 고객 납품물의 IP는 계약이 정합니다. 최종 영상, 코드, 보고서처럼 고객에게 넘기는 것의 권리는 고객과의 계약서를 따릅니다. 대개 고객에게 양도되거나 고객에게 사용권이 부여됩니다.
2. 셀이 만든 재사용 가능한 자산(워크플로우, 파인튜닝된 모델, 데이터셋, 프롬프트 템플릿, 평가 도구)은 Charter에서 귀속을 정합니다. 기본값은 만든 참여자의 공동 소유이며, 커뮤니티 회원에게는 비독점 재사용 라이선스를 부여합니다. 셀에서 만들어진 도구가 커뮤니티 전체의 역량이 되도록 하는 순환 설계입니다.
3. Background IP, 즉 참여 전에 이미 가지고 있던 코드·모델·데이터·노하우는 원소유자에게 남습니다. 셀에 가져와 쓰더라도 소유권이 이전되지 않으며, 셀은 프로젝트 목적 안에서의 사용권만 가집니다.

고객 계약이 "모든 산출물의 IP를 고객에게 양도"라고 되어 있다면, 재사용 자산과 Background IP를 양도 범위에서 제외하는 조항을 계약에 넣어야 합니다. 이것은 Contracting Party의 책임입니다.

시작 단계의 금지 사항

• Charter 없이 실행을 시작하지 않습니다. 급해서 먼저 시작했다면 일주일 안에 Charter를 완성합니다.
• Opportunity를 공개하지 않고 팀을 닫힌 채로 구성하지 않습니다. 고객이 지명한 자리를 제외한 나머지는 공개합니다.
• 계약금 없이 대규모 실행을 시작하지 않습니다. 기본값으로 계약금은 계약금액의 30% 이상을 권장합니다.
• Charter의 보상 구조를 비워 두고 "나중에 잘 나누자"고 적지 않습니다. 예상 비율이라도 적습니다.

Case: 브랜드 AI 광고 영상 프로젝트의 Charter

가상의 사례입니다. 앞의 한 씨와 윤 씨는 "일단 시작하자" 대신 Proposal을 썼습니다. Opportunity가 72시간 공개되었고, 개발자 서 씨(캐릭터 일관성 파이프라인 경험), 사운드·편집 크리에이터 오 씨, 그리고 Junior Slot으로 가입 두 달째인 강 씨가 합류했습니다. 다섯 명이 첫 회의에서 완성한 Charter의 요지입니다.

예상 배분액을 계산하면 한 씨 171만원, 한 씨 회사 85만 5천원, 윤 씨 142만 5천원, 서 씨 142만 5천원(Execution 85만 5천원 + Knowledge 57만원), 오 씨 28만 5천원입니다. 강 씨는 Work Compensation만 받지만, 첫 프로젝트 기록과 멘토링을 얻습니다. 이 숫자는 예시이며, 실제 비율은 프로젝트가 끝난 뒤 실제 기여를 보고 확정합니다(제20장, 제22장 참조).

여섯 주 뒤 무슨 일이 생겼는지 봅시다. 고객이 세 번째 수정을 요구했습니다. 윤 씨는 Charter의 범위 조항을 근거로 별도 견적을 제시했고, 고객은 받아들였습니다. 서 씨의 워크플로우는 출시 후 Builder Circle에 공유되어 다른 셀이 재사용했습니다. 고객이 다음 캠페인을 이야기했을 때, 한 씨는 Originator로서 후속 기여를 인정받되 새 셀은 다시 Proposal에서 시작했습니다. 시작할 때 적어 둔 30분이 끝날 때의 30일을 없앴습니다.

Remember

• 공동 프로젝트는 끝에서 실패하는 것처럼 보이지만 실제로는 시작에서 실패합니다. 시작할 때 정하지 않은 것이 끝날 때 갈등이 됩니다.
• 여섯 단계 Idea → Proposal → Team → Project Charter → Contract → Execution은 관문입니다. 준비되지 않은 프로젝트가 사람을 소모하지 않도록 합니다.
• Proposal은 플랫폼의 Opportunity로 공개됩니다. 기회는 공개 채널로 흐릅니다.
• Project Charter는 1~2페이지의 헌법입니다. 열 가지 항목이 모두 있어야 하며, 서명되는 순간 셀이 성립합니다.
• IP의 기본값은 세 층입니다. 납품물은 계약이, 재사용 자산은 만든 참여자 공동 소유와 커뮤니티 비독점 라이선스가, Background IP는 원소유자가 가집니다.

"시작할 때의 30분이 끝날 때의 30일을 없앤다."

기회가 생겼을 때 누구에게 연락합니까? 이 장은 친분 순이 아니라 Capability + Experience + Trust + Availability + Fit이라는 공개된 기준으로 팀을 만드는 방법과, 그 기준이 신규회원에게도 열려 있어야 하는 이유를 다룹니다.

질문에서 시작합니다

가상의 상황입니다. 파운더 장 대표는 물류기업으로부터 수요 예측 AI의 PoC(개념 검증)를 의뢰받았습니다. 계약금액 5천만원, 기간 10주. 장 대표는 휴대전화를 꺼내 연락처를 넘깁니다. 대학 동기인 개발자 문 씨, 전 직장 후배인 마케터 유 씨, 지난달 술자리에서 의기투합한 크리에이터 노 씨. 모두 커뮤니티 회원이고, 모두 "좋다, 하자"고 답합니다. 팀은 하루 만에 만들어졌습니다.

이 장면에서 잘못된 것은 없어 보입니다. 아는 사람과 일하는 것은 자연스럽고 빠르고 편합니다. 그러나 몇 가지 질문을 던져 보겠습니다. 문 씨는 시계열 예측을 해 본 적이 있습니까. 유 씨는 이 프로젝트에 주당 몇 시간을 낼 수 있습니까. 노 씨의 역할은 정확히 무엇입니까. 그리고 커뮤니티 안에서 수요 예측 모델을 세 번 납품해 본 연구자 신 박사는, 이 프로젝트가 있었다는 사실을 언제 알게 됩니까.

이 장이 답하려는 질문은 이것입니다. 누가 프로젝트에 참여해야 합니까? 그리고 그것을 누가, 어떤 기준으로, 어떻게 정합니까?

왜 친분 순 배정이 문제인가

친분 순 배정은 나쁜 사람이 하는 일이 아닙니다. 대부분의 사람이 하는 일입니다. 아는 사람은 검증 비용이 낮습니다. 시장(Market)에서 매번 낯선 사람을 탐색하고 검증하는 비용을 생각하면, 아는 사람에게 먼저 연락하는 것은 합리적인 선택처럼 보입니다.

문제는 그 합리성이 개인에게는 맞고 조직에는 틀리다는 데 있습니다. 첫째, 친분은 역량의 대리 지표로 부정확합니다. 친분으로 뽑은 팀은 역할이 사람에 맞춰지고, 필요한 역량이 비어 있어도 아무도 그 빈자리를 보지 못합니다.

둘째, 친분 순 배정은 기회를 폐쇄 회로에 가둡니다. 기회가 아는 사람 사이에서만 돌면 새 회원은 실력이 있어도 첫 프로젝트를 얻지 못합니다. 첫 프로젝트가 없으면 기록이 없고, 기록이 없으면 신뢰가 없고, 신뢰가 없으면 다음 프로젝트도 없습니다. 커뮤니티가 "먼저 들어온 사람들의 인맥 클럽"이 되는 것은 정확히 이 지점에서 시작됩니다. 제9장에서 말한 울타리의 목적은 기존 회원의 이익 보호가 아닙니다.

셋째, 친분 순 배정은 정산에서 갈등을 만듭니다. 친분으로 모인 팀은 역할과 투입 시간을 정하지 않은 채 시작하기 쉽습니다. "친구끼리 뭘 그렇게 따지냐"는 말이 시작을 흐리고, 끝날 때 "나는 이만큼 했는데"라는 말이 관계를 깨뜨립니다.

AI 시대에는 이 문제가 더 날카로워집니다. 개발자가 영업을 하고 크리에이터가 모델을 다루는 시대에, 명함과 친분으로는 역량을 읽을 수 없습니다. 조직의 경쟁우위가 인원수가 아니라 매칭의 정확도라면, 친분 순 배정은 그 정확도를 스스로 낮추는 선택입니다.

우리의 철학

한국인공지능커뮤니티는 사람을 직함이나 친분이 아니라 Capability Node(역량 노드)로 봅니다. 프로젝트에 필요한 것은 "내가 아는 사람"이 아니라 "이 일을 할 수 있는 사람"이고, 그 사람은 플랫폼에 기록된 역량·기여·신뢰의 원장에서 찾습니다. 친분은 기록을 대신할 수 없고, 기록은 친분을 필요로 하지 않습니다.

이것은 친분을 배제하라는 뜻이 아닙니다. 함께 일해 본 사람은 Trust와 Fit에서 실제로 높은 점수를 받을 수 있습니다. 재협업 의사는 Trust Capital의 정당한 항목입니다. 친분이 기준을 대체하는 것이 문제이지, 친분이 기준 안에서 평가되는 것은 문제가 아닙니다.

프로토콜 조직(Protocol Organization)에서 팀 구성은 개인의 호의가 아니라 규약에 따릅니다. 규약이 있어야 처음 온 사람도 어떤 기준으로 평가받는지 알고, 떨어졌을 때도 무엇을 쌓아야 하는지 알 수 있습니다. 기준이 공개되어 있다는 것은 기회가 공개되어 있다는 것과 같은 말입니다.

그래서 커뮤니티의 팀 구성 기준은 다섯 가지이며, 이 다섯 가지는 Project Charter(프로젝트 헌장)에 적히고 플랫폼에 기록됩니다.

 Capability   +   Experience   +   Trust   +   Availability   +   Fit
 할 수 있는가     해 봤는가        믿을 수 있는가   시간이 있는가     맞는가

다섯 가지 중 어느 하나가 다른 넷을 대신하지 못합니다. 신뢰가 아무리 높아도 시간이 없으면 참여할 수 없고, 역량이 아무리 높아도 신뢰 기록이 비어 있으면 큰 책임을 맡기기 어렵습니다.

운영원칙 1: 다섯 가지 기준의 정의와 평가

아래는 커뮤니티의 기본값(Default)입니다. Project Charter로 조정할 수 있습니다.

평가는 점수표로 해도 되고 서술로 해도 됩니다. 중요한 것은 다섯 가지를 모두 보았고 그 근거가 기록된다는 사실입니다. 기본값으로 Fit은 Project Lead가 판단하되 그 이유를 적습니다. 팀 구성은 완벽한 개인을 찾는 일이 아니라 다섯 가지의 합이 팀 전체에서 채워지도록 맞추는 일입니다.

역할에 따라 강조점이 다릅니다. 연구자에게 Experience는 "논문을 썼는가"가 아니라 "산업 데이터로 끝까지 가 봤는가"이고, 사업가에게 Capability는 "이 고객 유형을 설득해 본 적이 있는가"입니다. 크리에이터에게 Availability는 다른 클라이언트 일정과의 충돌입니다.

운영원칙 2: 기회는 공개 채널로 흐른다

기회는 플랫폼의 Opportunity(기회)로 공개됩니다. 제14장에서 다룬 대로 Proposal의 공개 부분은 기본값으로 72시간 동안 게시되며, 조건을 충족하는 회원은 누구나 지원할 수 있습니다. 기회가 있었다는 사실을 아는 사람의 범위가 곧 커뮤니티의 범위여야 합니다.

임원, Council 구성원, Circle Leader, 오래된 회원이라는 이유로 기회를 우선 배정받지 않습니다. Governance Power ≠ Economic Opportunity. 운영 권한을 가진 사람이 기회를 먼저 가져가기 시작하면 운영 권한은 봉사가 아니라 특권이 됩니다. 반대로 임원이라는 이유로 배제되지도 않습니다. 똑같이 지원하고 똑같은 기준으로 평가받습니다. 다만 자기가 관여하는 Circle이나 Council의 판단이 그 프로젝트에 걸려 있다면 회피(Recusal)하고 Conflict of Interest Declaration(이해상충 신고서)을 냅니다.

공개 원칙의 예외는 좁게 정합니다.

1. 고객 지명. 고객이 특정 회원을 지명한 경우 그 자리는 공개하지 않아도 됩니다. 나머지 자리는 공개합니다.
2. 후속 프로젝트. 같은 고객의 후속 프로젝트에서 직전 셀의 참여자는 우선 제안을 받을 수 있습니다. 이것도 Charter에 기록하고, 새로 생기는 자리는 공개합니다.
3. 긴급. 48시간 이내에 시작해야 하는 경우 Circle Leader의 확인을 받아 게시 기간을 줄일 수 있습니다. 줄인 이유는 기록합니다.

이 예외 밖에서 "조용히 아는 사람끼리" 셀을 만드는 것은 셀이 아니라 사적 거래입니다. 커뮤니티는 그 기여를 기록하지 않고 그 분쟁을 조정하지 않습니다.

운영원칙 3: 신규회원에게 열린 자리

기준으로 뽑으면 신규회원이 불리해집니다. Experience와 Trust는 기록으로 쌓이는데, 새로 온 사람에게는 기록이 없기 때문입니다. 이 문제를 그대로 두면 공정한 기준이 폐쇄적인 결과를 만듭니다. 커뮤니티는 세 가지 장치로 이 순환을 끊습니다.

Junior Slot(주니어 슬롯). 기본값으로 4명 이상의 셀은 최소 한 자리를 Member·Verified 단계의 회원에게 엽니다. 이 자리는 Capability·Availability·Fit으로 평가하며 Experience와 Trust는 요구하지 않습니다. 대신 역할을 명확히 하고 Work Compensation을 정상적으로 지급합니다. Junior Slot은 잡무 창구가 아니며, 값싼 노동력을 뽑는 자리가 아닙니다. 사람을 소모품처럼 다루지 않는다는 약속은 가장 경험이 적은 참여자에게 가장 구체적으로 적용됩니다.

멘토 동반 참여. Junior Slot에는 담당 멘토가 있습니다. 대개 같은 역량 영역의 참여자 한 명이 맡으며, 멘토링은 플랫폼에 Mentoring 기여로 기록됩니다. 멘토는 주니어의 결과물을 검토하고, 주니어가 실수하면 멘토와 Lead가 함께 책임집니다.

소규모 셀 우선 배정. 신규회원의 첫 참여는 3~4명 규모의 셀이나 PoC 단계의 프로젝트를 권장합니다. 규모가 작을수록 역할이 분명하고, 실수의 비용이 낮고, 기록이 빨리 쌓입니다. 그 기록이 다음 Opportunity에서 Experience와 Trust의 첫 줄이 됩니다.

이 세 장치는 시혜가 아니라 투자입니다. 새 회원이 첫 기록을 얻지 못하는 커뮤니티는 몇 년 뒤 같은 사람들만 남습니다.

운영원칙 4: 거절과 중도 이탈의 예절

참여를 제안받았다고 반드시 응해야 하는 것은 아닙니다. 거절은 신뢰를 깎지 않습니다. 시간이 없는데 응하는 것이 신뢰를 깎습니다. 거절의 예절은 셋입니다. 빨리 답합니다(기본값 48시간 이내). 이유를 짧게 말합니다(가용성·역량·이해상충). 가능하다면 대안을 제시합니다(다른 회원 추천, 축소된 역할). 거절 이력은 Trust Capital에 부정적으로 기록되지 않습니다.

중도 이탈은 다릅니다. Charter에 서명한 뒤 나가는 것은 이해관계 변경이므로 참여자 합의 사항이며, 남은 사람들에게 실제 비용을 발생시킵니다. 그러나 본업의 위기, 건강, 가족처럼 이탈해야 하는 상황은 생깁니다. 커뮤니티는 이탈 자체가 아니라 이탈하는 방식을 봅니다.

인수인계를 마치고 나간 사람의 기록은 "중도 이탈, 인수인계 완료"이며, 다음 프로젝트에서 크게 불리하지 않습니다. 연락을 끊고 사라진 사람의 기록은 "중도 이탈, 인수인계 없음"입니다. 이것은 실패가 아니라 약속 위반이며, 부정직으로 다룹니다. 실패에는 관대하되 부정직에는 엄격하다는 원칙은 이탈에도 그대로 적용됩니다.

운영원칙 5: 선정 과정의 투명성

누가 어떤 기준으로 누구를 골랐는지는 Project Charter의 역할 항목과 플랫폼의 팀 구성 기록에 남깁니다. 기본값으로 기록할 것은 다음과 같습니다.

1. Opportunity 게시 기간과 지원자 수.
2. 선정된 참여자별 다섯 기준의 평가 요지. 한두 줄이면 충분합니다.
3. 선정 판단을 한 사람(대개 Project Lead, 필요 시 Originator나 Circle Leader가 함께).
4. 기준을 조정했거나 예외를 적용한 이유.
5. Junior Slot의 유무와 멘토.

선정되지 않은 지원자에게는 기본값으로 결과와 함께 한 줄의 이유를 알립니다. "시계열 예측 경험이 있는 분을 우선했습니다"처럼 구체적일수록 좋습니다. 그 한 줄이 지원자에게는 다음에 무엇을 쌓아야 하는지 알려주는 지도가 됩니다.

투명성은 Lead를 감시하기 위한 것이 아니라 보호하기 위한 것입니다. 기록이 없는 선정은 아무리 공정했어도 공정했다고 증명할 수 없습니다.

Case: 친분 순 명단을 기준표로 다시 짜다

다음은 가상의 사례입니다.

상황. 앞의 장 대표는 Charter를 쓰기 전에 Builder Circle의 Circle Leader에게 조언을 구했습니다. Circle Leader는 명단을 보고 한 가지만 물었습니다. "이 네 분을 다섯 기준으로 적어 보셨습니까?" 장 대표는 적어 본 적이 없었습니다.

갈등. 적어 보니 빈칸이 보였습니다. 문 씨는 Capability와 Trust는 높았지만 수요 예측 모델의 Experience가 없었습니다. 유 씨는 마케터인데 이 프로젝트에는 마케팅 역할이 없어 Fit이 비어 있었습니다. 노 씨는 다른 클라이언트 작업이 꽉 차 Availability가 주당 2시간이었습니다. 무엇보다 시계열 예측 모델을 만들 사람이 명단에 없었습니다. 장 대표는 불편했습니다. 친구들에게 이미 "하자"고 말해 둔 뒤였기 때문입니다.

적용. 장 대표는 Proposal을 다시 썼고, Opportunity를 72시간 공개했습니다. 필요한 역할은 예측 모델, 데이터 파이프라인, 고객 보고서·데모, Junior Slot 한 자리였습니다. 지원자는 아홉 명이었고, 장 대표는 기준표를 채웠습니다. 요지는 다음과 같습니다.

결과. 최종 셀은 장 대표(Lead·Contracting Party·고객 커뮤니케이션), 신 박사(모델), 문 씨(파이프라인), 임 씨(Junior Slot, 데이터 정제)의 네 명이 되었습니다. 데모 영상은 범위에서 빼고 고객 보고서로 대체했습니다. 장 대표는 유 씨와 노 씨에게 직접 전화해 기준표를 보여주며 설명했습니다. 이유가 분명했고 다음 기회가 닫히지 않았기에 두 사람은 서운해하지 않았습니다. 유 씨는 PoC 이후 사업화 단계의 새 Opportunity에 지원해 선정되었습니다.

Charter에는 한 줄이 들어갔습니다. "참여자 선정: Opportunity 72시간 공개, 지원자 9명, Lead 장 대표가 다섯 기준으로 평가. Junior Slot 1(임 씨, 멘토 신 박사)." 10주 뒤 PoC는 목표 정확도를 넘겼고, 임 씨의 플랫폼 기록에는 Closing Review의 한 줄이 남았습니다. "데이터 정제 담당, 일정 준수, 재협업 의사 있음." 그것이 임 씨의 Experience와 Trust의 첫 줄이 되었습니다.

Remember

• 친분 순 배정은 대부분의 사람이 하는 일이지만, 친분은 역량의 대리 지표로 부정확하고 기회를 폐쇄 회로에 가둡니다.
• 팀 구성 기준은 Capability + Experience + Trust + Availability + Fit 다섯 가지입니다. 어느 하나가 다른 넷을 대신하지 못하며, 평가 근거를 기록합니다.
• 기회는 플랫폼의 Opportunity로 공개 채널을 통해 흐릅니다. 임원·오래된 회원이라는 이유로 우선 배정받지 않습니다. Governance Power ≠ Economic Opportunity.
• 신규회원에게는 Junior Slot, 멘토 동반 참여, 소규모 셀 우선 배정으로 첫 기록을 얻을 자리를 엽니다.
• 거절은 신뢰를 깎지 않습니다. 중도 이탈은 인수인계·부분 정산·기록으로 마무리하면 실패이고, 사라지면 부정직입니다. 누가 어떤 기준으로 골랐는지는 Charter에 남깁니다.

"기준이 공개되어 있다는 것은 기회가 공개되어 있다는 것이다."

모두가 동등한 팀은 누가 결정합니까? 이 장은 Project Cell이 빠르게 움직이면서도 누구의 몫도 함부로 바꾸지 않는 방법, 즉 "실행은 빠르게, 이해관계 변경은 합의로"라는 원칙을 다룹니다.

질문에서 시작합니다

가상의 장면 하나를 떠올려 보겠습니다. 다섯 명이 모인 Project Cell(프로젝트 셀)이 있습니다. 파운더 박 대표가 고객을 데려왔고, 개발자 김 씨와 연구자 이 교수가 모델을 만들고, 크리에이터 정 씨가 데모 영상을 맡고, 마케터 최 씨가 제안서를 씁니다. 모두 각자의 회사와 연구실을 가진 독립적인 전문가입니다. 누구도 누구의 상사가 아닙니다.

수요일 밤, 고객이 요구사항을 하나 바꿉니다. 모델 구조도, 데모 영상도 다시 만들어야 합니다. 납기는 열흘 남았습니다. 개발자 김 씨는 "지금 바꾸면 일정이 무너진다"고 하고, 박 대표는 "고객이 원하니 바꿔야 한다"고 합니다. 이 교수는 "다른 접근이 있다"고 합니다. 단체방에는 메시지가 쌓이는데 결론은 나지 않습니다.

이틀이 지났습니다. 아무도 결정하지 않았기 때문에 아무것도 진행되지 않았습니다. 다섯 명이 모두 동의해야 움직이는 팀은, 한 명만 확신이 없어도 멈춥니다. 그리고 고객은 기다려 주지 않습니다.

이 장이 답하려는 질문은 이것입니다. 상사가 없는 조직에서 누가 결정합니까? 그리고 그 결정 권한은 어디까지입니까?

왜 만장일치 조직은 위험한가

동등한 사람들이 모이면 자연스럽게 "모두가 합의해서 결정하자"고 말합니다. 좋은 의도입니다. 하지만 만장일치는 의사결정 방식이 아니라 의사결정을 미루는 방식이 되기 쉽습니다.

첫째, 만장일치는 속도를 죽입니다. 프로젝트에서 내려야 할 결정은 하루에도 수십 개입니다. 어떤 모델을 쓸지, 어떤 데이터를 먼저 정제할지, 고객에게 오늘 답할지 내일 답할지. 이 모든 것을 전원 합의로 하면 실행보다 회의가 길어집니다. AI가 실행 비용을 극적으로 낮춘 시대에, 결정이 느린 조직은 가장 비싼 자원인 시간을 낭비합니다.

둘째, 만장일치는 책임을 흐립니다. 모두가 결정했다는 말은 아무도 결정하지 않았다는 말과 같습니다. 결과가 나빴을 때 누구도 "내가 판단했다"고 말하지 않습니다. 책임이 없는 곳에는 배움도 없습니다. Project Closing Review(종료평가)에서 무엇이 잘못됐는지 되짚을 때, "우리 모두의 결정이었다"는 문장은 아무것도 알려주지 않습니다.

셋째, 만장일치는 가장 조심스러운 사람에게 거부권을 줍니다. 한 사람이 확신이 없으면 전체가 멈춥니다. 이것은 신중함이 아니라 마비입니다. 그리고 역설적으로, 마비를 피하려고 사람들은 회의 밖에서 따로 결정하기 시작합니다. 공식적으로는 만장일치인데 실제로는 목소리 큰 사람이 결정하는 조직이 됩니다. 이것이 만장일치 조직의 가장 나쁜 결말입니다.

그렇다고 반대편으로 가면 안 됩니다. 한 사람이 모든 것을 결정하는 조직은 빠르지만, 그 한 사람이 다른 사람의 몫을 바꿀 수 있게 되는 순간 협력은 무너집니다. 내 보상과 범위가 누군가의 단독 판단으로 달라진다면, 나는 더 이상 이 프로젝트에 나를 걸 수 없습니다.

실행 결정과 이해관계 변경은 다르다

한국인공지능커뮤니티의 답은 결정을 두 종류로 나누는 것입니다. 하나는 실행 결정(Execution Decision)입니다. 목표를 향해 어떻게 갈 것인가에 관한 판단입니다. 다른 하나는 이해관계 변경(Stake Change)입니다. 누가 무엇을 얼마나 받고 어디까지 책임지는가를 바꾸는 판단입니다.

실행 결정은 빠르게 해야 합니다. 그래서 Project Lead(프로젝트 리드)가 합니다. 이해관계 변경은 신중해야 합니다. 그래서 참여자 합의로 합니다. 이것이 "실행은 빠르게, 이해관계 변경은 합의로"라는 문장의 뜻입니다.

두 종류를 구분하는 기준은 하나입니다. 이 결정이 누군가의 몫을 바꾸는가. 바꾸지 않는다면 실행 결정입니다. 바꾼다면 이해관계 변경입니다.

같은 주제라도 어느 쪽인지가 갈립니다. 모델을 바꾸는 것은 실행 결정이지만, 그 때문에 연구자 이 교수의 역할이 사라진다면 이해관계 변경입니다. 경계가 애매할 때의 기본값은 합의 쪽입니다. 의심스러우면 물어보는 편이 신뢰를 지킵니다.

우리의 철학: 상사가 아니라 책임을 맡은 동료

전통 기업의 상사는 고용 관계 위에 서 있습니다. 상사는 부하의 평가·승진·급여에 영향을 미치고, 부하는 그 때문에 따릅니다. 명령이 조정 수단입니다. 위계(Hierarchy)는 안정적이지만 느리고, 구성원의 독립성을 희생합니다.

Project Lead는 다릅니다. Lead는 참여자를 고용하지 않았고, 참여자의 생계를 쥐고 있지 않습니다. 참여자들은 각자의 회사와 연구실을 가진 독립적인 Capability Node(역량 노드)입니다. Lead가 가진 것은 명령권이 아니라, 참여자들이 Project Charter(프로젝트 헌장)에 서명하면서 위임한 실행 판단의 권한입니다. 그리고 그 권한에 붙어 있는 책임입니다.

상사는 지위이고 Lead는 역할입니다. 상사는 프로젝트가 끝나도 상사이지만 Lead는 프로젝트가 끝나면 다시 동료입니다.

프로토콜 조직(Protocol Organization)에서 Lead가 필요한 이유는 명령하기 위해서가 아니라, 누군가는 판단의 주인이어야 하기 때문입니다. 판단에 주인이 있어야 속도가 나고, 결과가 나오고, 기여를 기록할 수 있습니다. Lead는 그 판단을 맡은 사람이고, 맡은 만큼 Contribution Matrix(기여도 평가표)의 Leadership & Risk 항목으로 인정받습니다. 권한은 특권이 아니라 기여의 한 형태입니다.

그래서 이 책은 반복해서 말합니다. 프로젝트 전체의 성공을 개인의 단기이익보다 우선한다. Lead는 이 문장을 가장 먼저, 가장 무겁게 짊어지는 사람입니다.

운영원칙 1: Project Lead의 권한과 책임

아래는 커뮤니티의 기본값(Default)입니다. Project Charter로 조정할 수 있습니다.

권한. Project Lead는 다음 사항을 단독으로 판단하고 실행합니다.

1. 실행 판단: 기술·방법·순서·우선순위. 범위 안에서 어떻게 갈지는 Lead가 정합니다.
2. 일정 관리: 마일스톤과 작업 배정을 조정합니다. 다만 Charter의 최종 납기를 바꾸는 것은 합의 사항입니다.
3. 품질 판단: 납품 가능 여부와 재작업 여부를 결정합니다. Lead가 "아직 아니다"라고 하면 아직 아닙니다.
4. 고객 커뮤니케이션: 고객과의 일상적 소통 창구를 맡거나 지정합니다. 고객이 여러 참여자에게 각각 다른 말을 듣는 일을 막습니다.
5. 정산 초안 작성: Project Settlement Sheet(정산표)의 초안을 씁니다. 초안은 초안입니다. 확정은 참여자 합의입니다.

책임. 권한에는 같은 크기의 책임이 따릅니다.

1. 투명성: 중요한 실행 판단은 그 이유와 함께 Closed Room에 기록합니다. 참여자가 "왜 그렇게 했는지" 나중에 확인할 수 있어야 합니다.
2. 경계 준수: 이해관계 변경을 실행 결정으로 위장하지 않습니다. "일정상 어쩔 수 없었다"는 말로 누군가의 범위나 보상을 바꾸는 것은 가장 흔한 경계 침범입니다.
3. 참여자 보호: 참여자를 소모품처럼 다루지 않습니다. 야간·주말 대응을 요청할 수는 있으나 상시화하지 않으며, 신규회원의 Junior Slot이 잡무 창구가 되지 않게 합니다.
4. 결과 책임: 프로젝트의 결과에 대해 고객과 참여자 앞에 서는 사람은 Lead입니다. 잘된 것은 팀의 몫이고 잘못된 판단은 Lead의 기록입니다.
5. 기록: 기여가 발생하는 대로 Contribution Matrix에 반영되도록 챙깁니다. 기여한 사람을 잊지 않는 것은 Lead의 일 중 하나입니다.

운영원칙 2: Lead의 선정, 교체, 이해상충

선정. Lead는 Project Charter를 작성할 때 참여자 합의로 정합니다. 기본 기준은 제15장의 팀 구성 기준과 같습니다. Capability + Experience + Trust + Availability + Fit. 여기에 Lead에게만 필요한 것이 하나 더 있습니다. 이 프로젝트에 시간을 실제로 쓸 수 있는가입니다. 가장 유명한 사람이나 고객을 데려온 사람이 자동으로 Lead가 되지 않습니다. Originator(기회를 가져온 사람)가 Lead를 맡는 경우가 많지만, 그것은 관행이지 규칙이 아닙니다.

Lead는 등급의 문제가 아닙니다. Contributor 단계의 회원이 Professional 단계의 회원을 참여자로 둔 프로젝트의 Lead가 될 수 있습니다.

교체. Lead는 다음 경우에 교체될 수 있습니다. 교체는 이해관계 변경이므로 참여자 합의 사항입니다.

교체된 Lead는 참여자로 남을 수 있습니다. 실행 판단의 실패는 실패이지 부정직이 아니기 때문입니다. 실패에는 관대하되 부정직에는 엄격하다는 원칙은 Lead에게도 똑같이 적용됩니다.

이해상충. Lead의 판단이 자기 보상과 충돌하는 지점이 있습니다. 정산 초안을 쓰는 사람이 자기 기여를 평가하는 순간이 대표적입니다. 기본값은 다음과 같습니다.

1. Lead는 자신의 Contribution Matrix 항목에 대해 초안을 쓰되, 확정 논의에서는 발언은 하고 표결에는 참여하지 않습니다.
2. Lead가 Originator를 겸하는 경우, Origination 기여 비율은 Lead가 아닌 다른 참여자가 초안을 씁니다.
3. Lead가 자신의 회사나 소속 기관에 하도급·구매를 맡기려 할 때는 Conflict of Interest Declaration(이해상충 신고서)을 내고 참여자 합의를 받습니다.
4. Lead가 Circle Leader나 Council 구성원을 겸하는 경우, 그 프로젝트에 대한 Circle·Council 차원의 판단에서는 회피(Recusal)합니다. Governance Power ≠ Economic Opportunity.

의견이 갈릴 때의 절차

실행 결정에 대해 참여자가 반대할 수 있습니다. 반대는 건강한 것입니다. 문제는 반대가 결정을 멈추게 하는 경우와, 반대가 기록되지 않고 사라지는 경우입니다. 커뮤니티의 기본 절차는 "반대 의견 기록 후 실행, 사후 검토"입니다.

실행 결정에 이견 발생
  │
  ├─ 1. 논의 (기본 24시간, 긴급 시 Lead가 단축)
  │      참여자는 근거와 대안을 제시
  │
  ├─ 2. Lead의 판단
  │      채택 / 수정 채택 / 기각 — 이유를 함께 기록
  │
  ├─ 3. 반대 의견 기록
  │      반대자는 Closed Room에 반대 이유를 남길 권리가 있음
  │      기록된 반대는 사후 검토의 근거가 됨
  │
  ├─ 4. 실행
  │      기록이 끝나면 전원이 결정을 따름
  │      "나는 반대했으니 안 하겠다"는 없음
  │
  └─ 5. 사후 검토
         다음 마일스톤 또는 Closing Review에서 결과 대조
         반대가 옳았다면 그 판단력이 기록됨
         Lead가 옳았다면 그 판단력이 기록됨

이 절차가 지키려는 것은 속도와 기록입니다. 논의 시간이 정해져 있으므로 결정이 미뤄지지 않고, 반대한 사람이 옳았을 때 그 사실은 사라지지 않고 그 사람의 Trust Capital이 됩니다. 신뢰는 말이 아니라 행동으로 쌓이고, 정확한 판단을 기록으로 남기는 것도 행동입니다.

역할에 따라 이 절차가 다르게 느껴질 수 있습니다. 연구자는 "충분히 검증되지 않은 결정"이 불편할 수 있습니다. 그럴 때 반대 기록은 연구자의 학문적 양심을 지키는 장치입니다. 사업가는 "논의 24시간"이 길게 느껴질 수 있습니다. 그럴 때 Lead는 긴급 단축 권한을 쓰되, 단축한 사실을 기록합니다. 개발자는 "결정 후 전원 준수"가 억울할 수 있습니다. 그럴 때 기억할 것은, 다음 프로젝트에서 그 개발자가 Lead일 수 있다는 사실입니다.

한 가지 예외가 있습니다. 반대의 내용이 "이것은 실행 결정이 아니라 이해관계 변경이다"라는 주장일 때입니다. 이 경우 Lead가 단독으로 기각할 수 없습니다. 어떤 결정이 어느 범주에 속하는지는 참여자 합의로 정하고, 합의가 안 되면 Circle Leader의 조정을 거칩니다. 경계를 정하는 권한을 Lead에게 주면 경계가 무너지기 때문입니다.

Case: 모델 교체를 두고 갈린 밤

다음은 가상의 사례입니다.

상황. 제조기업의 문서 검색 시스템을 만드는 프로젝트가 있었습니다. 계약금 6천만원, 기간 8주. Lead는 개발자 출신 파운더 한 대표였고, 연구자 윤 박사가 검색 모델을, 개발자 오 씨가 서비스 연동을, 크리에이터 서 씨가 고객 교육 영상을 맡았습니다. 신규회원인 학생 배 씨가 Junior Slot으로 데이터 정제를 도왔습니다.

갈등. 5주차에 윤 박사가 만든 검색 모델의 정확도가 목표에 미치지 못했습니다. 윤 박사는 "2주 더 주면 학습 데이터를 보강해서 목표를 넘길 수 있다"고 했습니다. 오 씨는 "이미 검증된 오픈모델로 바꾸면 사흘이면 된다. 다만 정확도는 약간 낮다"고 했습니다. 남은 기간은 3주. 한 대표는 판단해야 했습니다.

적용. 한 대표는 이것을 실행 결정으로 봤습니다. 모델을 바꾸는 것은 범위 안의 기술 선택이기 때문입니다. 그러나 한 가지를 확인했습니다. 오픈모델로 바꾸면 윤 박사의 남은 역할이 사라지는가. 윤 박사는 "평가 체계와 튜닝은 여전히 내 일"이라고 답했습니다. 역할이 사라지지 않으므로 이해관계 변경이 아니었습니다.

24시간 논의 후 한 대표는 오픈모델로 교체하되, 윤 박사의 데이터 보강 작업은 병행해서 납품 후 2차 개선안으로 고객에게 제안하기로 결정했습니다. 윤 박사는 반대 의견을 기록으로 남겼습니다. "자체 모델이 장기적으로 고객에게 더 유리하며, 오픈모델은 고객 데이터의 외부 전송 문제가 있을 수 있다." 기록 후 윤 박사는 결정을 따랐습니다.

결과. 납품은 기한 안에 이뤄졌습니다. 그런데 납품 2주 후 고객의 보안팀이 윤 박사가 지적한 데이터 전송 문제를 실제로 제기했습니다. 팀은 윤 박사의 보강 모델로 교체하는 2차 계약(2천만원)을 맺었습니다. Closing Review에는 한 대표의 판단이 납기를 지켰다는 점과, 윤 박사의 반대가 위험을 정확히 예측했다는 점이 함께 기록됐습니다. 두 사람의 Trust Capital은 모두 올라갔습니다. 반대가 기록되지 않았다면 윤 박사의 판단력은 아무도 기억하지 못했을 것입니다.

정산에서 한 대표는 자신의 Leadership & Risk 항목 표결에서 빠졌습니다. 권한을 쓰되 경계를 지킨 Lead는 그렇게 신뢰를 얻습니다.

Remember

• 만장일치는 결정 방식이 아니라 결정을 미루는 방식이 되기 쉽습니다. 속도를 죽이고 책임을 흐리고 가장 조심스러운 사람에게 거부권을 줍니다.
• 결정에는 두 종류가 있습니다. 실행 결정은 Project Lead가 빠르게 합니다. 이해관계 변경(보상·범위·참여자·계약 조건)은 참여자 합의로 합니다. 판단 기준은 "이 결정이 누군가의 몫을 바꾸는가"입니다.
• Project Lead는 상사가 아닙니다. 참여자가 위임한 실행 판단을 맡은 동료이며, 권한만큼 투명성·경계 준수·결과 책임을 집니다. 프로젝트가 끝나면 다시 동료입니다.
• 의견이 갈리면 정해진 시간 안에 논의하고, Lead가 판단하고, 반대 의견을 기록한 뒤 실행하고, 사후에 검토합니다. 반대가 옳았다면 그 판단력은 기록으로 남아 신뢰가 됩니다.
• Lead의 자기 보상, 자기 회사, 겸직한 거버넌스 역할이 걸린 사안에서는 회피합니다. Governance Power ≠ Economic Opportunity.

"실행은 빠르게, 이해관계 변경은 합의로."

고객을 소개한 사람, 계약한 주체, 실제로 일한 사람의 권리는 어떻게 다릅니까? 이 장은 공동 프로젝트에서 가장 많은 갈등을 만드는 질문에 대한 커뮤니티의 답을 다룹니다.

질문에서 시작합니다

"고객을 소개한 사람은 앞으로 그 고객 매출의 일부를 계속 받아야 할까요?"

이 질문을 회원들에게 던지면 답이 갈립니다. 소개한 쪽은 "관계를 만든 것은 나"라고 말합니다. 수행한 쪽은 "일은 내가 다 했다"고 말합니다. 계약한 쪽은 "책임과 위험은 내 회사가 진다"고 말합니다. 셋 다 틀리지 않습니다. 그래서 어렵습니다.

가상의 장면을 하나 보겠습니다. 마케터 최 씨가 오래 알고 지낸 유통기업 담당자를 커뮤니티에 소개했습니다. Builder Circle의 개발자 강 씨가 팀을 꾸려 5천만원짜리 프로젝트를 수행했습니다. 계약은 파운더 박 대표의 회사 이름으로 했습니다. 프로젝트는 성공했고, 고객은 1년 뒤 두 번째 프로젝트를 의뢰했습니다. 이번에는 최 씨를 거치지 않고 강 씨에게 직접 연락했습니다.

최 씨는 두 번째 프로젝트에서 무엇을 받아야 합니까? 강 씨는 최 씨에게 알려야 합니까? 박 대표의 회사는 여전히 계약주체여야 합니까? 3년 뒤 다섯 번째 프로젝트에서도 같은 질문이 유효합니까?

이 장은 이 질문들에 답합니다. 답의 뼈대는 한 문장입니다. 고객은 누구의 소유물도 아닙니다. 다만 관계를 만든 기여는 인정합니다.

왜 이것이 가장 많은 갈등을 만드는가

고객을 둘러싼 갈등이 유독 많은 데는 이유가 있습니다.

첫째, 고객은 한 번의 매출이 아니라 반복되는 매출의 원천이기 때문입니다. 한 번의 프로젝트 정산은 Contribution Matrix(기여도 평가표)로 끝납니다. 그러나 고객 관계는 끝나지 않습니다. 두 번째, 세 번째 프로젝트가 생길 때마다 "처음 소개한 기여를 얼마나 오래 인정할 것인가"라는 질문이 되살아납니다. 정산은 끝났는데 관계는 계속되는 것, 이것이 갈등의 구조입니다.

둘째, 고객 관계는 눈에 보이지 않기 때문입니다. 코드는 저장소에 남고 영상은 파일로 남습니다. 그러나 "담당자와 3년간 쌓은 신뢰"는 어디에도 기록되지 않습니다. 기록되지 않은 기여는 시간이 지나면 없었던 것처럼 취급됩니다. 기여한 사람을 잊지 않는다는 원칙은 이 지점에서 가장 자주 시험받습니다.

셋째, AI 시대의 조건이 이 갈등을 더 키웁니다. 실행 비용이 낮아질수록 판단·관계·책임의 가치가 올라갑니다. 예전에는 "누가 만들었는가"가 가치의 대부분이었다면, 이제는 "누가 고객을 데려왔는가"와 "누가 책임지는가"의 비중이 커졌습니다. 관계의 가치가 커질수록 관계를 둘러싼 다툼도 커집니다.

넷째, 시장(Market)의 방식과 위계(Hierarchy)의 방식이 모두 여기서는 잘 작동하지 않기 때문입니다. 시장에서는 소개비를 한 번 지불하면 끝입니다. 관계는 축적되지 않습니다. 위계에서는 고객이 회사의 것이므로 개인 간 다툼이 없습니다. 대신 개인의 기여가 회사에 흡수됩니다. 프로토콜 조직(Protocol Organization)은 둘 다 아닙니다. 고객은 조직의 것도 개인의 것도 아니며, 관계를 만든 기여만 기록되고 인정됩니다. 이것은 더 정교한 규약을 요구합니다.

세 주체: Originator, Contracting Party, Executor

갈등을 풀려면 먼저 "고객과 관계된 사람"을 하나로 뭉뚱그리지 않아야 합니다. 커뮤니티는 세 주체를 구분합니다.

• Originator(소개자): 고객과의 관계를 만들고 기회를 커뮤니티로 가져온 사람입니다.
• Contracting Party(계약주체): 고객과 법적 계약을 맺고 대금을 받고 책임을 지는 주체입니다. 개인일 수도 있고 참여자의 회사일 수도 있으며, 앵커 조직일 수도 있습니다.
• Executor(수행자): 실제로 결과물을 만든 사람입니다.

한 사람이 셋을 겸할 수도 있고, 셋이 모두 다른 사람일 수도 있습니다. 중요한 것은 각 역할의 권리와 책임이 다르다는 점입니다.

이 표에서 가장 중요한 줄은 "하지 말아야 할 것"입니다. 세 주체가 각자 가장 쉽게 빠지는 유혹이 거기 적혀 있습니다. 소개자는 영구 권리를 주장하고 싶어 합니다. 계약주체는 정산을 미루고 싶어 합니다. 수행자는 소개자를 빼고 고객과 직접 거래하고 싶어 합니다. 셋 다 단기적으로는 이익이고 장기적으로는 신뢰의 손실입니다.

우리의 철학: 소유가 아니라 기여

한국인공지능커뮤니티는 고객을 소유의 대상으로 보지 않습니다. 고객은 자기 문제를 가장 잘 풀어 줄 사람을 선택할 자유가 있는 독립된 주체입니다. "이 고객은 내 것"이라는 말은 고객에게도 무례하고 동료에게도 무례합니다.

그렇다고 관계를 만든 기여를 없는 것으로 취급하지도 않습니다. 누군가가 수년간 쌓은 신뢰 위에서 첫 계약이 만들어졌다면, 그 신뢰는 실제 기여입니다. 기여한 사람을 잊지 않는 것은 이 커뮤니티의 약속입니다. 다만 그 기여는 시간과 함께 체감(逓減)합니다. 두 번째 프로젝트부터는 수행자의 결과물이, 계약주체의 책임이, 고객 자신의 만족이 관계를 지탱하기 때문입니다.

이것을 한 문장으로 하면 이렇습니다. Contribution creates Trust, not Permanent Privilege. 소개는 신뢰를 만들고, 신뢰는 다음 협력의 우선순위를 만들지만, 영구적인 수수료 권리를 만들지는 않습니다.

이 원칙은 세 주체 모두를 보호합니다. Originator는 첫 프로젝트와 후속 24개월 동안 기여를 보장받으므로 안심하고 고객을 커뮤니티로 가져올 수 있습니다. Executor는 24개월이 지나면 자기 실력으로 만든 관계를 자기 것으로 이어갈 수 있으므로 열심히 할 이유가 있습니다. Contracting Party는 규칙이 명확하므로 매번 다투지 않고 계약할 수 있습니다. 규칙이 없으면 셋 다 서로를 의심하고, 의심은 협력의 가장 비싼 비용입니다.

운영원칙 1: Originator 보상의 기본값

아래는 커뮤니티의 기본값(Default)이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

1. 첫 프로젝트: Originator는 Contribution Matrix의 Origination 항목으로 기여를 인정받습니다. 비율은 Charter에서 참여자 합의로 정합니다. 소개의 난이도, 관계의 깊이, 소개자가 영업 과정에 얼마나 참여했는지에 따라 달라집니다.
2. 후속 프로젝트: 같은 고객의 후속 프로젝트에 대해 첫 계약일로부터 기본 24개월간 체감하는 Origination 기여를 인정합니다. Originator가 후속 프로젝트에 참여하지 않아도 적용됩니다.
3. 체감 기본값: 첫 프로젝트의 Origination 비율을 100으로 볼 때, 후속 프로젝트에서는 아래 표를 따릅니다.
4. 24개월 이후: Origination 기여는 소멸합니다. 다만 Originator가 후속 프로젝트에 실제로 참여(영업·관계 관리·수행)하면 그 기여는 별도로 평가합니다.
5. 기록: 체감 기간 중의 모든 후속 프로젝트는 Originator에게 통보하고, 정산표에 Origination 항목을 명시합니다.

숫자로 보겠습니다. 첫 프로젝트 잉여가치 1,500만원에서 Community Share 5%(75만원)를 뺀 1,425만원을 나누며, Origination 비율이 15%였다면 Originator는 약 214만원을 받습니다. 10개월 뒤 후속 프로젝트의 배분 대상 잉여가치가 1,900만원이라면, 인정 비율은 15% × 75% = 11.25%이므로 약 214만원입니다. 20개월 뒤 세 번째 프로젝트에서 배분 대상 잉여가치가 같다면 15% × 25% = 3.75%, 약 71만원입니다. 25개월 이후에는 없습니다.

체감 곡선은 기본값일 뿐입니다. 소개자가 고객사의 핵심 의사결정자와 오랜 관계를 가진 경우 Charter에서 기간을 36개월로 늘릴 수 있습니다. 반대로 공개 채널(플랫폼의 Opportunity)에 올라온 기회를 누군가 단순히 전달한 경우 Origination이 아니라 Network 기여로 낮게 평가할 수 있습니다. 중요한 것은 정하고 기록하는 것입니다.

운영원칙 2: Non-circumvention(우회 금지)

누군가가 어렵게 만든 관계를 몰래 가져가면 단기적으로는 돈을 벌 수 있습니다. 하지만 그 순간 우리는 가장 비싼 자산인 신뢰를 잃습니다. 그래서 규칙이 있습니다.

1. 커뮤니티를 통해 만난 고객·파트너와, 소개자를 배제하고 직접 거래하는 것을 첫 접촉일로부터 기본 24개월간 금지합니다.
2. 금지되는 것은 "배제"입니다. 고객과 대화하는 것, 고객이 먼저 연락하는 것, 고객과 다른 주제로 협업하는 것 자체가 금지되지 않습니다. 소개자에게 알리지 않고 계약하는 것이 금지됩니다.
3. 우회는 실패가 아니라 부정직입니다. 제11장에서 정한 대로 윤리·분쟁위원회(Ethics & Dispute Committee)가 다루며, 경고에서 제명까지의 제재 대상입니다.
4. 24개월이 지난 뒤의 직접 거래는 우회가 아닙니다. 다만 커뮤니티는 그때도 소개자에게 알리는 것을 권장합니다. 의무는 아니지만 신뢰는 그렇게 쌓입니다.
5. Non-circumvention은 Originator만 보호하지 않습니다. Executor가 만든 관계를 Originator가 다른 수행자에게 넘겨 배제하는 것도 우회입니다. 규칙은 양방향입니다.

운영원칙 3: 고객이 직접 원할 경우

고객이 특정 수행자와 직접 거래하기를 원하는 일은 자연스럽게 생깁니다. 고객의 선택은 존중합니다. 다만 절차를 거칩니다.

고객이 특정 회원과의 직접 거래를 원함
  │
  ├─ 1. 공개: 요청받은 회원은 3일 안에 Originator와 Contracting Party에게 알림
  │
  ├─ 2. 확인: 고객의 의사를 문서(이메일 등)로 확인. 회원의 유도가 아니었음을 기록
  │
  ├─ 3. 합의: Originator·Contracting Party·수행자가 후속 구조를 합의
  │      - 체감 기간 안이면 Origination 기여를 새 Charter에 반영
  │      - 계약주체 변경 여부, 기존 계약의 유지보수 책임 정리
  │
  ├─ 4. 기록: 합의 내용을 플랫폼에 기록. 새 Project Cell이 생기면 새 Charter
  │
  └─ 합의 불가 시: Project Lead 조정 → 윤리·분쟁위원회

이 절차의 핵심은 1번입니다. 고객이 직접 연락했다는 사실을 숨기지 않는 것. 알리기만 하면 나머지는 대개 원만하게 풀립니다. 알리지 않으면 아무리 고객이 먼저 원했어도 우회로 봅니다. 신뢰는 말이 아니라 행동으로 쌓이고, 여기서 행동은 "알리는 것"입니다.

역할별로 이 절차가 요구하는 것이 다릅니다. 개발자·크리에이터 같은 Executor에게는 "알릴 용기"가 필요합니다. 고객이 나를 선택했다는 사실을 소개자에게 말하는 것은 어색하지만, 그 어색함이 신뢰의 비용입니다. 사업가·마케터 같은 Originator에게는 "놓아줄 용기"가 필요합니다. 24개월 체감은 나를 보호하는 동시에 나의 권리가 어디서 끝나는지를 말해 줍니다. 계약주체에게는 "정리할 성실함"이 필요합니다. 기존 계약의 하자보수 책임과 새 계약의 경계를 문서로 남기는 일입니다.

Case 1: 소개만 하고 수행에 참여하지 않은 마케터

다음은 가상의 사례입니다.

상황. 마케터 최 씨는 유통기업의 마케팅팀장과 5년째 알고 지냈습니다. 팀장이 "상품 설명을 자동으로 만들고 싶다"고 하자 최 씨는 커뮤니티의 Builder Circle에 기회를 올렸습니다. 개발자 강 씨가 Lead를 맡아 Project Cell을 꾸렸고, 계약은 파운더 박 대표의 회사가 맡았습니다. 최 씨는 첫 미팅에 동석한 것 외에는 수행에 참여하지 않았습니다.

갈등. 프로젝트가 끝나고 정산할 때 개발자 한 명이 물었습니다. "최 씨는 미팅 한 번 나온 것뿐인데 잉여가치의 15%를 받는 게 맞습니까?" 최 씨는 "5년 관계가 없었으면 이 프로젝트 자체가 없었다"고 답했습니다.

적용. Charter에는 Origination 15%가 이미 합의돼 있었습니다. 강 씨는 정산 초안에서 이것을 바꾸지 않았습니다. 보상 구조 변경은 이해관계 변경이므로 Lead 단독으로 손댈 수 없고, 무엇보다 합의된 것을 사후에 깎는 것은 기여한 사람을 잊는 일이기 때문입니다. 매출 5천만원, 직접비용 500만원, Work Compensation 3천만원, 잉여가치 1,500만원, Community Share 75만원, 배분 대상 1,425만원. 최 씨의 몫은 약 214만원이었습니다.

10개월 뒤 고객은 두 번째 프로젝트(8천만원)를 강 씨에게 직접 의뢰했습니다. 강 씨는 이틀 안에 최 씨와 박 대표에게 알렸습니다. 새 Charter에서 최 씨의 Origination은 15% × 75% = 11.25%로 잡혔습니다. 최 씨는 이번에도 수행에 참여하지 않았습니다.

결과. 두 번째 정산에서 같은 질문이 다시 나왔지만 이번에는 답이 준비돼 있었습니다. "24개월 체감 기본값입니다. 20개월 뒤에는 25%, 그 후에는 0입니다." 개발자들은 끝이 있다는 것을 알았기에 받아들였고, 최 씨는 끝이 있다는 것을 알았기에 그 사이에 고객사의 다른 부서를 추가로 소개했습니다. 새 부서는 새 관계이므로 새 Origination입니다. 최 씨의 Trust Capital에는 "정직하게 소개하고, 기한이 지나면 주장하지 않은 사람"이라는 기록이 남았습니다.

Case 2: 수행자가 고객과 직접 후속 계약을 원할 때

다음은 가상의 사례입니다.

상황. 연구자 이 교수가 자신의 산학 네트워크를 통해 의료기기 회사를 소개했습니다. 크리에이터 정 씨가 제품 교육 영상 시리즈를 제작했고, 계약주체는 이 교수의 연구실이 아닌 정 씨의 1인 법인이었습니다. 계약금 3천만원. 결과가 좋아 고객사 마케팅 담당자가 정 씨에게 "앞으로 분기마다 영상을 직접 맡기고 싶다"고 했습니다. 첫 계약 후 8개월이 지난 시점이었습니다.

갈등. 정 씨는 고민했습니다. 이 교수는 소개 이후 아무 일도 하지 않았고, 고객이 원하는 것은 명백히 자신의 실력입니다. 이 교수에게 알리면 또 배분 이야기를 해야 합니다. 조용히 계약해도 아무도 모를 것 같았습니다.

적용. 정 씨는 알렸습니다. 이 교수에게 고객의 이메일을 그대로 전달하고, 분기별 계약을 자신의 법인이 직접 맡되 24개월 체감 기간 안의 Origination을 인정하겠다고 제안했습니다. 이 교수는 처음에는 "관계는 내가 만든 것"이라고 했지만, 기본값 표를 함께 보고 나서 동의했습니다. 8개월 시점이므로 75%, 14개월 시점부터 50%, 20개월부터 25%, 그 후 0. 두 사람은 이것을 플랫폼에 기록했습니다.

결과. 분기 계약은 3년째 이어지고 있습니다. 이 교수의 Origination 기여는 25개월째부터 사라졌지만, 이 교수는 정 씨를 자신의 다른 산학 프로젝트에 먼저 부릅니다. "알리지 않아도 됐을 때 알린 사람"이기 때문입니다. 반대의 길, 즉 조용히 계약하는 길을 택했다면 정 씨는 첫 분기에 약 100만원을 더 벌었을 것입니다. 대신 이 교수의 네트워크 전체를 잃었을 것입니다. 우회는 들키느냐의 문제가 아니라, 들키지 않아도 스스로 신뢰 네트워크 밖으로 걸어 나가는 일입니다.

Remember

• 고객을 둘러싼 갈등이 많은 이유는 고객이 반복 매출의 원천이고, 관계라는 기여가 눈에 보이지 않으며, AI 시대에 관계의 가치가 커졌기 때문입니다.
• Originator(소개자), Contracting Party(계약주체), Executor(수행자)는 권리와 책임이 다릅니다. 각자 가장 쉽게 빠지는 유혹도 다릅니다. 영구 권리 주장, 정산 지연, 소개자 배제.
• Originator는 첫 프로젝트의 Origination 기여와, 같은 고객의 후속 프로젝트에 대한 기본 24개월 체감 기여를 인정받습니다. 영구 권리는 없습니다.
• Non-circumvention은 기본 24개월입니다. 금지되는 것은 거래가 아니라 배제입니다. 고객이 직접 원하면 알리고, 확인하고, 합의하고, 기록합니다.
• 고객은 누구의 소유물도 아닙니다. 다만 관계를 만든 기여는 인정합니다.

"과거의 기여는 신뢰를 만들지만 영구적인 권리는 만들지 않는다."

프로젝트가 무너졌을 때 누가 무엇을 받고, 무엇이 기록되고, 무엇이 남습니까? 이 장은 실패와 부정직을 구분하는 기준, 조기 종료와 부분 정산의 절차, 그리고 실패를 다음 협력의 자산으로 바꾸는 방법을 다룹니다.

질문에서 시작합니다

가상의 장면입니다. 12주짜리 PoC(개념검증) 프로젝트가 7주차에 멈췄습니다. 고객이 준 데이터로는 목표 정확도가 나오지 않는다는 것이 분명해졌습니다. 연구자는 "데이터 자체가 문제"라고 하고, 개발자는 "접근을 바꾸면 될 수도 있다"고 하고, Lead는 고객에게 뭐라고 말해야 할지 모릅니다. 선금은 받았고, 다섯 명이 7주를 썼고, GPU 비용도 나갔습니다.

이때 팀 안에서 조용히 오가는 질문들이 있습니다. 내가 일한 7주는 보상받을 수 있을까. 실패한 프로젝트에 이름이 남으면 다음 프로젝트에 불려 갈 수 있을까. 고객에게 솔직하게 말하면 계약금을 돌려줘야 하나. 차라리 조금 더 끌면서 뭔가 보여 주는 게 낫지 않을까.

마지막 질문이 가장 위험합니다. 실패를 인정하는 비용이 너무 크다고 느끼는 순간, 사람들은 실패를 숨기기 시작합니다. 숨겨진 실패는 실패가 아니라 부정직이 됩니다. 그래서 이 장은 실패의 비용을 낮추는 방법에 관한 장입니다. 실패해도 괜찮은 조직만이 실패를 정직하게 다룰 수 있습니다.

왜 실패를 다루는 방식이 조직을 결정하는가

AI 프로젝트는 실패 확률이 높습니다. 모델이 목표 성능에 미치지 못하고, 데이터가 기대와 다르고, 고객의 문제가 알고 보니 AI로 풀 문제가 아니었다는 것이 뒤늦게 드러납니다. 기술이 빠르게 바뀌므로 12주 전의 최선이 지금은 최선이 아닐 수도 있습니다. 실패가 예외가 아니라 일상인 분야에서, 실패를 다루는 방식은 곧 조직의 작동 방식입니다.

전통 기업에서 실패는 인사 평가로 흡수됩니다. 누군가의 고과가 깎이고 조직은 계속 굴러갑니다. 시장에서 실패는 계약 분쟁으로 끝납니다. 손해배상을 다투고 다시는 서로 보지 않습니다. 느슨한 커뮤니티에서 실패는 조용히 사라집니다. 아무도 책임지지 않으므로 아무것도 배우지 못합니다.

프로토콜 조직(Protocol Organization)은 이 셋 어디에도 기댈 수 없습니다. 고용이 없으므로 인사 평가로 흡수할 수 없고, 관계가 계속되므로 분쟁으로 끝낼 수 없고, 기여가 기록되므로 조용히 사라질 수 없습니다. 실패가 남는 곳은 하나입니다. Trust Capital(신뢰 자산)입니다. 그래서 질문은 이렇게 바뀝니다. 실패를 어떻게 기록해야 그것이 다음 협력을 막지 않고 오히려 돕는가.

여기서 결정적인 구분이 필요합니다. 실패와 부정직은 다릅니다. 이 둘을 구분하지 못하는 조직은 두 가지 병에 걸립니다. 실패를 부정직처럼 다루면 아무도 어려운 프로젝트를 맡지 않습니다. 부정직을 실패처럼 다루면 아무도 서로를 믿지 않습니다. 둘 다 협력을 죽입니다.

실패와 부정직을 구분한다

커뮤니티는 프로젝트가 잘못되는 경우를 다섯 가지로 나눕니다. 앞의 셋은 실패이고, 뒤의 둘은 부정직입니다.

구분의 기준은 결과가 아니라 행동입니다. 기술 실패는 결과가 나쁜 것입니다. 고의 은폐는 행동이 나쁜 것입니다. 같은 프로젝트에서 같은 결과가 나와도, 문제를 3일 안에 팀에 알린 사람과 3주 동안 숨긴 사람은 다르게 기록됩니다. 신뢰는 말이 아니라 행동으로 쌓이고, 실패의 순간에 하는 행동이 가장 무겁게 기록됩니다.

경계에 있는 경우도 있습니다. 개발자가 "될 것 같다"고 말하며 2주를 더 쓴 뒤 안 됐다면 실패입니까, 은폐입니까. 기본 판단은 이렇습니다. 그 2주 동안 진행 상황을 사실대로 공유했다면 실패입니다. 진행 상황을 부풀리거나 질문을 피했다면 은폐입니다. 낙관은 실패의 원인이 될 수 있지만 부정직은 아닙니다. 부정직은 알면서 다르게 말하는 것입니다.

우리의 철학: 실패에는 관대하되 부정직에는 엄격하다

이 문장은 이 책의 여러 장에서 반복됩니다. 이 장에서는 그 이유를 실패의 편에서 설명합니다.

실패에 관대해야 하는 이유는 도덕이 아니라 설계입니다. 어려운 프로젝트에는 실패 확률이 있습니다. 실패의 비용이 크면 사람들은 쉬운 프로젝트만 맡고, 쉬운 프로젝트만 맡는 조직은 혼자서도 할 수 있는 일만 하게 됩니다. 함께 만드는 힘은 혼자서는 못 하는 일, 즉 실패할 수도 있는 일에서 나옵니다. 그래서 실패의 비용을 낮추는 것은 커뮤니티의 존재 이유와 직결됩니다.

부정직에 엄격해야 하는 이유도 설계입니다. 프로토콜 조직은 감시가 아니라 기록된 신뢰로 작동합니다. 감시 비용이 낮은 대신 신뢰가 깨졌을 때의 비용이 큽니다. 한 사람의 은폐가 허용되면 모든 사람이 서로를 확인해야 하고, 그 순간 이 조직은 시장(Market)보다 나을 것이 없어집니다. 부정직에 엄격한 것은 실패에 관대할 수 있기 위한 조건입니다.

그리고 한 가지가 더 있습니다. 사람을 소모품처럼 다루지 않는다는 약속은 실패한 프로젝트에서 가장 선명하게 시험받습니다. 성공한 프로젝트에서 사람을 잘 대하는 것은 쉽습니다. 무너진 프로젝트에서 7주를 일한 사람에게 "결과가 없으니 보상도 없다"고 말하지 않는 것, 그것이 이 약속의 실체입니다.

운영원칙 1: 조기 종료의 조건과 절차

프로젝트를 끝까지 끌고 가는 것이 언제나 옳지는 않습니다. 성공 가능성이 사라졌는데 계속하는 것은 참여자의 시간과 고객의 돈을 낭비하는 일입니다. 아래는 커뮤니티의 기본값(Default)이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

조기 종료를 검토해야 하는 신호.

1. 핵심 가설(기술적 실현 가능성, 데이터 품질, 고객 문제의 정의)이 틀렸음이 확인됐을 때
2. 남은 기간·예산으로 최소 목표에 도달할 수 없다고 Lead가 판단할 때
3. 고객의 사정(예산 삭감, 담당자 교체, 사업 방향 전환)으로 프로젝트의 전제가 사라졌을 때
4. 핵심 참여자의 이탈로 대체가 불가능할 때
5. 계속하는 것이 법적·윤리적 문제를 일으킬 때

절차.

위험 신호 인지
  │
  ├─ 1. 보고: 인지한 사람은 기본 3일 안에 Lead와 팀에 알림
  │      (이 3일이 실패와 은폐를 가르는 선입니다)
  │
  ├─ 2. 진단: Lead 주도로 원인과 선택지 정리
  │      계속 / 범위 축소 / 방향 전환 / 종료
  │
  ├─ 3. 결정: 범위·보상이 바뀌므로 이해관계 변경 → 참여자 합의
  │      Lead는 초안을 내고, 합의 시한은 기본 7일
  │
  ├─ 4. 고객 통보: 합의 후 즉시. 사실·원인·선택지·정산안을 함께
  │
  ├─ 5. 부분 정산: Project Settlement Sheet 작성
  │
  └─ 6. Closing Review: 종료 후 기본 2주 안에 실시

종료는 실행 결정이 아닙니다. 참여자의 보상과 범위가 달라지므로 이해관계 변경이고, 따라서 합의 사항입니다. 다만 Lead는 진단과 초안을 책임집니다. "실행은 빠르게, 이해관계 변경은 합의로"는 여기서도 작동합니다.

운영원칙 2: 부분 정산

실패한 프로젝트의 정산 원칙은 세 줄입니다.

1. 수행한 Work Compensation(수행 대가)은 지급합니다. 검수된 산출물 또는 Charter가 정한 투입 기준에 따라, 실제로 수행한 만큼 시장 단가로 지급합니다. 결과가 없다는 이유로 수행 대가를 깎지 않습니다.
2. Value Sharing(가치 배분)은 잉여가치가 없으면 없습니다. 잉여가치 = 수령 매출 − 직접비용 − Work Compensation. 이것이 0 이하면 나눌 것이 없습니다. 이것은 처벌이 아니라 정의입니다.
3. 손실 분담은 Charter가 정한 대로 합니다. 기본값은 Contracting Party(계약주체)가 손실을 부담하고, 그 부담을 Leadership & Risk 기여로 기록하는 것입니다. Charter에서 참여자 간 분담을 정했다면 그에 따릅니다. Charter에 규정이 없으면 참여자 합의로 정하되, Work Compensation을 소급해서 깎는 방식은 쓰지 않습니다.

숫자로 보겠습니다. 계약금 4천만원, 선금 40%인 1,600만원을 받은 상태에서 7주차에 종료했습니다. 직접비용(GPU 임대) 300만원. 7주간 수행분의 Work Compensation은 개발자 600만원, 연구자 500만원, 크리에이터 200만원, Lead 200만원, 합계 1,500만원입니다. 잉여가치는 1,600 − 300 − 1,500 = −200만원. Value Sharing은 없고, Community Share도 없습니다. 손실 200만원은 Charter 기본값에 따라 계약주체가 부담하고, 그 사실은 계약주체의 위험부담 기여로 기록됩니다.

수령한 돈이 Work Compensation에 미치지 못하는 경우도 있습니다. 이때 기본값은 수령액 범위에서 Work Compensation을 비율대로 먼저 지급하고, 부족분은 Charter의 손실 분담 규칙에 따라 처리하는 것입니다. 참여자 전원이 "이번 부족분은 각자 감수한다"고 합의할 수 있습니다. 그러나 그것은 합의여야 하지 Lead나 계약주체의 통보여서는 안 됩니다.

정산에서 자주 생기는 오해가 있습니다. "실패했으니 Lead가 책임지고 보상을 포기해야 한다"는 주장입니다. 기본값은 그렇지 않습니다. Lead의 판단이 실패의 원인이었더라도, Lead가 수행한 일의 Work Compensation은 지급합니다. Lead가 감당하는 것은 Closing Review에 자기 판단의 실패가 기록되는 것입니다. 그것으로 충분합니다. 돈으로 벌하기 시작하면 아무도 Lead를 맡지 않습니다.

운영원칙 3: 고객 대응

실패를 고객에게 알리는 방식은 고객 관계의 나머지 전부를 결정합니다.

1. 먼저 알립니다. 고객이 먼저 눈치채기 전에 팀이 알립니다. 늦게 알리는 것은 고객에게는 은폐로 보입니다.
2. 사실과 원인을 분리해서 말합니다. "정확도가 목표에 미달했다"는 사실과 "데이터의 라벨 오류율이 높았다"는 원인을 구분합니다. 원인이 고객 쪽에 있어도 비난하지 않고 기술합니다.
3. 선택지를 함께 냅니다. 범위 축소, 방향 전환, 종료. 각 선택지의 비용과 정산안을 붙입니다. 실패를 알리는 자리는 다음 결정을 묻는 자리입니다.
4. 정산은 계약과 Charter에 따릅니다. 선금 반환 여부는 계약이 정합니다. 계약에 없으면 수행한 산출물의 가치를 기준으로 협의합니다. 중간 산출물(정제된 데이터, 평가 체계, 실험 기록)은 고객에게 실제 가치가 있는 경우가 많습니다.
5. 창구는 하나입니다. 고객 커뮤니케이션은 Lead 또는 Lead가 지정한 사람이 맡습니다. 참여자가 각자 고객에게 다른 설명을 하는 것이 실패한 프로젝트에서 가장 흔한 2차 사고입니다.

역할별로 보면 이 원칙의 무게가 다릅니다. 사업가와 계약주체에게는 "먼저 알리기"가 어렵습니다. 후속 계약이 걸려 있기 때문입니다. 그러나 정직하게 실패를 알린 팀에 후속 프로젝트를 맡기는 고객은 생각보다 많습니다. 연구자에게는 "원인을 비난 없이 기술하기"가 어렵습니다. 데이터가 나빴다는 말은 사실이지만 고객에게는 책임 전가로 들릴 수 있습니다. 개발자와 크리에이터에게는 "창구를 하나로 두기"가 답답할 수 있습니다. 고객이 직접 물어 올 때 "Lead를 통해 정리해서 드리겠다"고 답하는 것이 팀을 지키는 일입니다.

운영원칙 4: 실패를 어떻게 기록하는가

Project Closing Review(종료평가)는 성공한 프로젝트보다 실패한 프로젝트에서 더 중요합니다. 기록이 없으면 실패는 소문이 되고, 소문은 사실보다 사람을 더 크게 다치게 합니다.

Closing Review에 기록하는 것.

• 프로젝트의 목표와 실제 결과
• 실패의 유형(기술·시장·일정)과 원인
• 위험 신호가 언제 인지됐고 언제 공유됐는지
• 각 참여자가 실제로 수행한 것과 그 품질
• 정산 내역과 손실 분담
• 배운 것과, 다음에 같은 프로젝트를 한다면 무엇을 다르게 할 것인지
• 참여자 상호 평가와 재협업 의사

실패가 Trust Capital을 깎지 않는 조건. 아래 다섯 가지를 지킨 참여자의 Trust Capital은 실패한 프로젝트로 인해 내려가지 않습니다. 오히려 "어려운 프로젝트를 끝까지 정직하게 다룬 사람"으로 기록됩니다.

반대로 이 조건을 어긴 경우, 즉 알고도 숨기거나, 정산을 회피하거나, Closing Review에 나타나지 않거나, 책임을 남에게 돌린 경우에는 실패가 아니라 부정직으로 기록됩니다. 같은 프로젝트에서 어떤 참여자는 신뢰가 올라가고 어떤 참여자는 내려갈 수 있습니다. 결과는 같아도 행동이 달랐기 때문입니다.

Trust Capital에 실패 프로젝트가 기록되는 방식도 중요합니다. 플랫폼은 "실패 1건"이라고 적지 않습니다. "기술 실패, 조기 공유, 정산 완료, 재협업 의사 4/4"처럼 행동을 적습니다. 다음 프로젝트의 Lead가 이 기록을 보고 판단할 수 있어야 합니다. 어려운 프로젝트에서 정직했던 사람은, 쉬운 프로젝트만 성공한 사람보다 더 믿을 만할 수 있습니다.

실패담 세션: 배운 것을 나누는 문화

실패는 한 Project Cell의 것이지만, 실패에서 배운 것은 커뮤니티의 것입니다. 커뮤니티는 Circle(서클) 단위로 실패담 세션을 엽니다. 종료된 프로젝트의 참여자가 무엇을 시도했고 왜 안 됐고 무엇을 배웠는지를 나누는 자리입니다.

이 세션에는 규칙이 있습니다.

1. Chatham House Rule을 적용합니다. 내용은 가져가되 발언자와 프로젝트를 특정하지 않습니다.
2. 고객 정보는 보호합니다. 고객명·계약 조건·미공개 기술은 말하지 않습니다. 프로젝트의 Confidentiality 등급이 Cell-only 이상이면 Lead가 공유 범위를 먼저 정합니다.
3. 비난하지 않습니다. 세션의 목적은 원인 분석이지 책임 추궁이 아닙니다. 책임 추궁은 Closing Review와 윤리·분쟁위원회의 일입니다.
4. 기여로 기록합니다. 실패담을 공유한 사람은 플랫폼에 Knowledge 기여로 기록됩니다. 실패를 나누는 것은 커뮤니티에 주는 것입니다.

실제로 해본 사람만 아는 지식의 절반은 실패에서 나옵니다. "이 데이터 유형에는 이 접근이 안 된다", "이 산업의 고객은 PoC 단계에서 이런 기대를 한다", "GPU 예산은 이렇게 잡으면 부족하다." 이런 지식은 공개 인터넷에 없습니다. 실패담 세션은 커뮤니티가 같은 실패를 두 번 하지 않게 하는 장치이며, 실패한 사람이 다시 기여자로 서는 자리입니다.

Case: 7주차에 멈춘 PoC

다음은 가상의 사례입니다.

상황. 물류기업의 수요 예측 PoC였습니다. 12주, 4천만원, 선금 1,600만원. 파운더 조 대표가 Originator이자 계약주체였고, 개발자 문 씨가 Lead, 연구자 남 박사가 모델, 크리에이터 류 씨가 결과 대시보드와 보고 영상, 신규회원 학생 홍 씨가 Junior Slot으로 데이터 정제를 맡았습니다.

갈등. 5주차에 홍 씨가 데이터 정제 중 이상한 것을 발견했습니다. 과거 2년치 데이터의 상당 부분이 실제 수요가 아니라 시스템 기본값으로 채워져 있었습니다. 홍 씨는 신규회원이라 말하기를 망설였습니다. 이틀 뒤 남 박사에게 조심스럽게 물었고, 남 박사는 즉시 Lead에게 알렸습니다. 문 씨는 하루 만에 팀 전체에 공유했습니다. 위험 인지에서 공유까지 3일이었습니다.

적용. 문 씨는 진단을 주도했습니다. 남은 데이터만으로는 목표 정확도의 절반도 어려웠습니다. 선택지는 셋이었습니다. 고객이 데이터를 다시 수집할 때까지 중단, 목표를 낮춰 계속, 종료. 조 대표는 후속 계약이 걸려 있어 "어떻게든 뭔가 보여 주자"고 했습니다. 남 박사는 "보여 줄 수 있는 것은 데이터가 왜 쓸 수 없는지뿐"이라고 했습니다.

참여자 합의는 5일 걸렸습니다. 결론은 종료였고, 대신 "데이터 진단 보고서와 재수집 설계안"을 산출물로 고객에게 전달하기로 했습니다. 조 대표가 고객에게 알렸습니다. 고객 담당자는 처음에 실망했지만, 데이터 문제가 자기 회사의 다른 시스템에도 영향을 준다는 것을 알고는 오히려 고마워했습니다.

정산은 앞서 본 숫자와 같습니다. 수령 1,600만원, GPU 300만원, Work Compensation 1,500만원(홍 씨의 데이터 정제 100만원 포함, Lead 200만원은 문 씨). 잉여 −200만원. Value Sharing 없음. 손실 200만원은 Charter대로 조 대표의 회사가 부담했고, Leadership & Risk 기여로 기록됐습니다.

결과. Closing Review에는 "시장 실패에 가까운 데이터 실패, 5주차 인지, 3일 내 공유, 고객 선통보, 정산 완료"가 기록됐습니다. 다섯 명 전원의 재협업 의사는 서로에 대해 긍정이었습니다. 홍 씨의 기록에는 "신규회원으로서 핵심 위험을 최초 발견"이 남았고, 다음 프로젝트에서 Junior Slot이 아닌 정식 자리를 제안받았습니다. 남 박사는 Research Circle 실패담 세션에서 "기본값으로 채워진 데이터를 탐지하는 법"을 발표했고, 이것은 Knowledge 기여로 기록됐습니다.

4개월 뒤 같은 고객이 데이터 재수집을 끝내고 다시 연락했습니다. 이번에는 6천만원짜리 정식 프로젝트였습니다. 고객이 같은 팀을 원한 이유는 하나였습니다. "안 되는 것을 안 된다고 말한 팀"이었기 때문입니다.

Remember

• 실패와 부정직은 다릅니다. 기술 실패·시장 실패·일정 실패는 결과가 나쁜 것이고, 책임회피·고의 은폐는 행동이 나쁜 것입니다. 기록도 다르게 남습니다.
• 성공 가능성이 사라졌으면 조기 종료를 검토합니다. 위험 신호를 인지한 뒤 기본 3일 안에 알리는 것이 실패와 은폐를 가르는 선입니다. 종료는 이해관계 변경이므로 참여자 합의로 정합니다.
• 부분 정산의 원칙은 세 줄입니다. 수행한 Work Compensation은 지급합니다. Value Sharing은 잉여가 없으면 없습니다. 손실 분담은 Charter가 정한 대로 합니다.
• 고객에게는 먼저, 사실대로, 선택지와 함께 알립니다. 창구는 하나로 둡니다.
• 조기 공유·사실 기록·고객 정직·정산 성실·검토 참여를 지킨 참여자의 Trust Capital은 실패로 깎이지 않습니다. 실패에서 배운 것은 실패담 세션을 통해 커뮤니티의 지식이 됩니다.

"실패에는 관대하되 부정직에는 엄격하다."

프로젝트에 200시간을 쓴 사람과, 그 프로젝트를 존재하게 만든 10시간의 사람 중 누가 더 기여했습니까. 이 장은 기여를 시간이 아니라 "무엇이 없었다면 이 결과가 없었는가"로 정의합니다.

질문에서 시작합니다

가상의 상황 하나를 떠올려 보겠습니다. 어느 제조기업의 문서 검색 시스템을 만드는 프로젝트가 끝났습니다. 개발자 최 씨는 두 달 동안 200시간 넘게 파이프라인을 만들었습니다. 마케터 한 씨는 그 기업의 담당 임원을 알고 있었고, 첫 미팅을 잡고 요구사항을 정리하는 데 10시간쯤을 썼습니다. 파운더 박 대표는 자기 회사 이름으로 계약서에 도장을 찍었고, 납품이 늦어지면 위약금을 물어야 하는 사람이었습니다.

정산 회의에서 최 씨가 말합니다. "제가 거의 다 만들었는데요." 한 씨가 말합니다. "제가 아니었으면 이 프로젝트 자체가 없었습니다." 박 대표는 조용히 계약서를 꺼냅니다. "문제가 생기면 책임지는 건 저입니다." 세 사람 모두 틀리지 않았습니다. 그런데 세 사람은 서로 다른 것을 기여라고 부르고 있습니다.

이 장은 이 질문에 답하기 위한 장입니다. 보상을 나누는 방법은 제20장에서 다룹니다. 여기서는 그 전에 반드시 합의되어야 할 것, 즉 "무엇을 세는가"를 다룹니다.

왜 시간만으로는 기여를 잴 수 없는가

가장 쉬운 측정 단위는 시간입니다. 시간은 세기 쉽고, 비교하기 쉽고, 다투기 어렵습니다. 그래서 대부분의 조직은 시간을 기준으로 사람을 평가하고 보상합니다. 회사는 월급을 주고, 외주는 공수를 계산합니다. 시간이 나쁜 기준이라는 말이 아닙니다. 시간은 기여의 일부일 뿐이라는 말입니다.

AI 시대에는 이 불일치가 더 커집니다. 코드와 영상과 문서를 만드는 비용은 급격히 낮아졌습니다. 예전에 200시간 걸리던 일이 40시간에 끝나기도 합니다. 그러면 실행에 쓴 시간의 가치는 상대적으로 낮아지고, 무엇을 만들지 판단하는 것, 누구와 연결되는가, 결과에 책임을 지는 것의 가치는 올라갑니다. 실행이 싸질수록 판단·관계·책임이 비싸집니다. 시간만 세면 바로 이 비싼 것들을 놓칩니다.

시간으로 잴 수 없는 기여를 몇 가지 들어 보겠습니다.

• 기회를 가져온 것: 고객이 없으면 프로젝트도 없습니다. 그러나 첫 소개는 30분짜리 전화 한 통일 수 있습니다.
• 위험을 진 것: 계약주체는 하자보수와 위약금과 세금 신고를 떠안습니다. 이 위험은 아무 일도 일어나지 않으면 보이지 않습니다.
• 실패한 영업: 다섯 번 제안해서 한 번 성사됐다면, 나머지 네 번의 시간은 어디에 기록됩니까.
• 조율: 밀리는 일정과 바뀌는 요구사항 사이에서 열 번의 통화를 한 사람이 있습니다. 결과물에는 그 이름이 없습니다.
• 가져온 자산: 3년 동안 다듬은 워크플로우, 이미 정제된 데이터셋, 빈 시간에 돌릴 수 있는 GPU 서버. 이번 프로젝트에서 새로 만든 것은 아니지만 이것이 없었다면 두 배의 시간이 들었을 것입니다.

이런 기여를 세지 않으면 다음 프로젝트에서 아무도 고객을 소개하지 않고, 아무도 계약주체가 되려 하지 않습니다. 시간만 세는 조직은 결국 시간을 파는 사람만 남는 조직이 됩니다. 그것은 외주 인력풀이지, 우리가 만들려는 조직이 아닙니다.

우리의 철학: 기여한 사람을 잊지 않는다

한국인공지능커뮤니티의 작동 원리는 CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK입니다. 이 사슬에서 기여(Contribution)는 두 번째 고리입니다. 역량은 아직 가능성일 뿐입니다. 역량이 실제 행동으로 바뀌는 순간이 기여이고, 기여가 기록될 때 비로소 신뢰가 됩니다. 기여가 기록되지 않는 조직에서는 신뢰가 쌓이지 않고, 신뢰가 없으면 매번 처음부터 사람을 검증해야 합니다.

그래서 우리는 "기여한 사람을 잊지 않는다"를 약속으로 둡니다. 이 문장은 따뜻한 구호처럼 들리지만 실제로는 매우 실무적인 원칙입니다. 잊지 않으려면 기억해야 하고, 기억하려면 기록해야 하고, 기록하려면 무엇을 기록할지 정의해야 합니다. 이 장의 나머지는 그 정의입니다.

우리는 사람을 Capability Node(역량 노드)로 봅니다. 직함이 아니라 무엇을 할 수 있는가로 봅니다. 기술·연구·사업·영업·마케팅·창작·네트워크·리더십·자본은 모두 동등한 기여 가능성입니다. 그러므로 기여의 정의도 한 종류일 수 없습니다. 형태가 다르다고 하나를 "진짜 기여"로, 나머지를 "도움"으로 부르지 않습니다.

한 가지 경계를 분명히 하겠습니다. 기여를 넓게 정의한다는 것은 모든 것을 기여로 인정한다는 뜻이 아닙니다. 회의에 앉아 있었던 것, 단체방에서 응원한 것, "제가 아는 사람이 있는데"라고 말만 한 것은 기여가 아닙니다. 기여는 결과에 인과적으로 연결된 행동입니다. "이것이 없었다면 이 결과가 없었거나, 훨씬 늦었거나, 훨씬 비쌌을 것이다"라고 말할 수 있어야 기여입니다.

기여의 지도: Contribution Matrix의 7개 범주

커뮤니티 컨셉 문서는 기여가 될 수 있는 것을 길게 나열합니다. 기술, 연구, 지식, 개발, 콘텐츠 제작, 고객 및 프로젝트 연결, 영업, 마케팅, 투자, 멘토링, 기업 및 전문가 소개, 데이터, GPU 및 인프라, 공간, 운영, 커뮤니티를 위해 사용한 시간. 이 목록은 정직하지만, 정산할 때 그대로 쓰기에는 너무 깁니다. 그래서 Contribution Matrix(기여도 평가표, Appendix C)는 이를 7개 범주로 묶습니다.

이 표에서 눈여겨볼 것이 둘 있습니다. 첫째, Execution은 "유급 업무를 넘어선 부분"입니다. 개발자가 계약된 범위의 일을 하고 시장 단가로 대가를 받았다면, 그것은 Work Compensation(수행 대가)으로 이미 보상된 것입니다. Contribution Matrix의 Execution은 그 위에 얹힌 부분, 즉 돈으로 미리 약속하지 않았지만 결과를 결정적으로 바꾼 기여를 셉니다. 이 구분이 없으면 개발자는 이중으로 보상받고 나머지는 과소평가됩니다.

둘째, 같은 사람이 여러 범주에 동시에 들어갈 수 있습니다. 파운더 박 대표는 계약주체(Leadership & Risk)이면서 견적을 협상했고(Sales) 사무실을 내주었습니다(Capital & Infra). 한 사람을 한 칸에 넣지 않습니다. 행동을 칸에 넣습니다.

역할별로 보면

같은 표를 서로 다른 자리에서 읽으면 다르게 보입니다. 개발자는 Execution이 크지만 자기 워크플로우를 가져왔다면 Knowledge도 있습니다. 교수·연구자는 Knowledge와 Network가 크고, 실험을 직접 돌렸다면 Execution도 있습니다. 마케터는 Origination과 Sales가 크고, 파운더는 Leadership & Risk와 Capital이 큽니다. 어느 역할도 표 전체를 혼자 채울 수 없습니다. 그래서 우리는 함께 일합니다.

프로젝트 기여와 커뮤니티 기여는 다르다

여기까지는 하나의 Project Cell(프로젝트 셀) 안에서의 기여입니다. 그런데 커뮤니티에는 특정 프로젝트에 속하지 않는 기여가 있습니다. 세미나에서 실패 경험을 공유한 것, 신규회원을 멘토링한 것, Circle(서클) 모임을 준비한 것, 공용 GPU를 한 달 내어준 것. 이런 기여는 매출이 없으므로 정산표에 오르지 않습니다. 그러나 이것을 잊으면 커뮤니티는 프로젝트의 합에 불과해집니다. 그래서 플랫폼은 커뮤니티 기여를 별도로 기록합니다. 분류는 다음 8가지입니다.

프로젝트 기여는 돈으로 이어지고, 커뮤니티 기여는 신뢰와 기회로 이어집니다. 두 흐름은 분리되어 있지만 서로를 먹여 살립니다. 세미나에서 경험을 나눈 사람은 다음 프로젝트 팀 구성에서 먼저 떠오릅니다. 신규회원을 멘토링한 사람은 Leader / Fellow 단계로 갈 때 그 기록이 근거가 됩니다. 돈 외의 보상은 제21장에서, 성장 단계는 제8장에서 다룹니다.

주의할 것이 하나 있습니다. 커뮤니티 기여가 많다는 이유로 프로젝트 정산에서 더 받지는 않습니다. 오래 활동한 회원, 임원, Circle Leader라는 이유로 Contribution Matrix에 가산점이 붙지 않습니다. Contribution creates Trust, not Permanent Privilege. 과거의 기여는 신뢰를 만들지만, 이번 프로젝트의 몫은 이번 프로젝트의 기여로만 정합니다.

보이지 않는 기여를 어떻게 드러내는가

가장 어려운 부분입니다. 코드는 저장소에 남고 영상은 파일로 남습니다. 그러나 위험부담과 실패한 영업과 조율은 흔적이 없습니다. 흔적이 없는 것은 잊히고, 잊힌 것은 다음에 아무도 하지 않습니다. 그래서 우리는 보이지 않는 기여에 대해 세 가지를 합니다.

첫째, 미리 이름을 붙입니다. Project Charter(프로젝트 헌장)를 쓸 때 "누가 계약주체인가, 누가 위약금 위험을 지는가, 누가 선지급을 부담하는가"를 명시합니다. 위험은 사고가 나야만 보이는 것이므로, 사고가 나기 전에 그 위험을 누가 들고 있는지 적어 둡니다. 위험을 진 것 자체가 기여입니다. 사고가 나지 않았다고 기여가 사라지지 않습니다. 보험료는 사고가 없어도 지불하는 것과 같습니다.

둘째, 과정을 기록합니다. 영업이 실패한 제안도 기록합니다. "3월에 A사에 제안, 예산 문제로 보류"라고 한 줄 남기면, 그 제안이 반년 뒤 다른 경로로 살아났을 때 누가 씨앗을 뿌렸는지 알 수 있습니다. 조율도 마찬가지입니다. Project Lead(프로젝트 리드)가 고객과 요구사항을 다시 협상한 통화, 참여자 사이의 갈등을 정리한 회의는 주간 기록에 한 줄씩 남깁니다. 길게 쓸 필요는 없습니다. 날짜, 무엇을, 왜.

셋째, 동료가 증언합니다. Project Closing Review(종료평가)에서 참여자는 "다른 사람의 기여 중 가장 결정적이었던 것"을 한 가지씩 적습니다. 자기 기여는 과장하기 쉽지만 남의 기여는 그렇지 않습니다. 보이지 않는 기여는 옆에서 본 사람이 가장 잘 압니다.

여기서 한 가지를 분명히 하겠습니다. 위험부담을 기여로 인정한다는 것은 계약주체가 잉여가치를 독식해도 된다는 뜻이 아닙니다. 위험은 Leadership & Risk 범주의 한 항목이고, 그 크기는 실제로 노출된 위험의 크기에 비례합니다. 위약 조항이 없는 소규모 계약에서 "내 회사 이름으로 했다"는 이유만으로 큰 몫을 주장하는 것은 위험부담이 아니라 명의 대여입니다.

운영원칙: 기여는 언제, 어떻게 기록하는가

기여의 정의보다 더 자주 무너지는 것이 기록의 시점입니다. 프로젝트가 끝나고 돈이 들어온 뒤에 "자, 이제 누가 얼마나 했는지 정리해 봅시다"라고 하면 늦습니다. 기억은 자기에게 유리하게 편집되고, 액수가 눈앞에 있으면 사람은 협상가가 됩니다. 그래서 원칙은 하나입니다. 기록은 사후가 아니라 진행 중에 합니다.

기록에 관한 기본값은 다음과 같습니다. 이 숫자는 커뮤니티의 기본값(Default)이며 Project Charter로 조정할 수 있습니다.

1. Charter 단계에서 범주별 예상 비중을 적습니다. 확정이 아니라 예상입니다. 그러나 예상이 있어야 종료 시의 차이를 설명할 수 있습니다.
2. 주 1회 기여 기록을 권장합니다. 3개월 넘는 프로젝트에서 기록이 한 달 이상 비어 있으면 Project Lead가 채우도록 요청합니다.
3. 기록은 참여자 모두가 볼 수 있습니다. 몰래 쌓는 기록은 기여 기록이 아니라 증거 수집입니다. Cell-only 등급으로 참여자에게는 열려 있어야 합니다.
4. 기록에 이의가 있으면 그 주에 제기합니다. 종료 시점에 3개월 전 기록을 뒤집는 것은 원칙적으로 받아들이지 않습니다. 다만 고의 누락이 드러난 경우는 예외입니다.
5. 자기 기여의 기록은 본인이, 검증은 Lead와 동료가 합니다. Lead의 기여는 Lead가 아닌 참여자 한 명이 확인합니다. Lead도 자기 기여를 스스로 확정하지 않습니다.
6. 실패한 프로젝트에서도 기록은 남깁니다. 매출이 없어 정산할 것이 없어도, 기여 기록은 Trust Capital(신뢰 자산)로 전환됩니다. 실패에는 관대하되 부정직에는 엄격하다는 원칙이 여기서도 적용됩니다. 실패한 프로젝트에서 성실하게 기록된 기여는 다음 프로젝트의 초대장이 됩니다.

기록이 부담스럽다는 반론이 있을 수 있습니다. 그래서 형식을 최소화합니다. "4/12, 요구사항 변경으로 파이프라인 재설계, 최 씨 16시간 추가, 범위 밖." 이 한 줄이 두 달 뒤 정산 회의에서 30분의 논쟁을 없앱니다. 기록은 관료주의가 아니라 기억의 외주입니다.

경계 상황

• 중간에 합류한 사람: 합류 시점부터 기록합니다. 합류 전의 기여는 없습니다. 다만 합류 전에 자문으로 도운 것이 있다면 Network 또는 Knowledge로 소급 기록할 수 있고, 이는 참여자 합의 사항입니다.
• 중간에 이탈한 사람: 이탈 시점까지의 기록은 유지됩니다. 기여가 결과에 실제로 남았다면 인정하고, 이탈로 인해 다른 사람이 다시 만들어야 했다면 그만큼 차감합니다. 이탈 자체를 벌하지 않지만, 이탈로 생긴 비용은 반영합니다.
• AI 도구가 한 일: AI 에이전트가 코드의 절반을 썼다면 그 기여자는 에이전트를 운용하고 결과에 책임진 사람입니다. 도구는 구성원이 아닙니다. "AI가 했으니 시간이 적게 들었다"는 이유로 Execution을 깎지 않습니다.

Case: 열 시간과 이백 시간

가상의 사례입니다. 장 첫머리의 프로젝트로 돌아가겠습니다. 제조기업 문서 검색 시스템, 계약금 4천만원, 기간 두 달.

상황. 팀은 다섯 명이었습니다. 마케터 한 씨(고객 소개, 요구사항 정리), 파운더 박 대표(계약주체, Project Lead), 개발자 최 씨(파이프라인 구축), 연구자 이 교수(검색 품질 평가 방법 자문), 그리고 신규회원인 크리에이터 정 씨(사용자 가이드 영상, Junior Slot). Charter에는 각자의 역할과 예상 기여 범주가 적혀 있었습니다. 박 대표는 계약서에 납품 지연 시 하루 0.1%의 지체상금 조항이 있다는 것을 Charter에 명시했습니다.

갈등. 프로젝트 6주 차에 고객이 문서 형식을 바꿨습니다. 최 씨는 파이프라인의 절반을 다시 짜야 했고, 3주 동안 추가로 60시간을 썼습니다. 그 사이 박 대표는 고객과 다섯 번 통화해 납기를 2주 연장받았고, 지체상금을 면제받았습니다. 한 씨는 고객 담당 임원에게 직접 연락해 형식 변경이 고객 쪽 사정임을 확인시켰습니다. 종료 시점에 최 씨는 이렇게 말했습니다. "제가 60시간을 더 썼는데, 박 대표님과 한 씨는 전화 몇 통 하신 것 아닙니까."

적용. 기록이 있었습니다. 6주 차 주간 기록에는 "고객 문서 형식 변경, 파이프라인 재설계, 최 씨 범위 밖 60시간 예상"이 있었고, 그 옆에 "박 대표 납기 연장 협상 5회, 지체상금 면제 확보"와 "한 씨 고객 임원 접촉, 변경 귀책 확인"이 있었습니다. Closing Review에서 이 교수는 동료 증언에 이렇게 썼습니다. "납기 연장이 없었다면 지체상금은 약 56만원이었고, 그보다 더 큰 것은 고객 신뢰였다. 박 대표의 협상이 없었다면 최 씨의 60시간은 있었어도 프로젝트는 실패로 기록됐을 것이다."

Contribution Matrix는 최 씨의 60시간을 Execution(유급 업무를 넘어선 부분)으로 크게 인정했습니다. 박 대표의 협상은 Leadership & Risk로, 한 씨의 임원 접촉은 Origination에 더해 Sales로 기록했습니다. 정 씨의 가이드 영상은 계약 범위 안이었으므로 Work Compensation으로 지급됐고, 고객이 요청하지 않은 관리자용 영상은 작지만 Execution으로 남겼습니다.

결과. 최 씨는 정산표를 보고 "전화 몇 통"이 무엇이었는지 이해했고, 자기 60시간이 가장 큰 Execution으로 남은 것도 확인했습니다. 박 대표는 다음 프로젝트에서도 계약주체가 되겠다고 했습니다. 한 씨는 같은 고객의 후속 프로젝트에서 Originator로 기록되었고, 정 씨의 플랫폼 기록에는 Project 기여 하나와 Knowledge 기여 하나가 남았습니다.

이 사례에서 갈등을 해결한 것은 설득이 아니라 기록이었습니다. 정산 회의에서 기억을 다투는 대신 6주 차의 한 줄을 읽었습니다. 기여한 사람을 잊지 않는다는 것은 이런 뜻입니다.

Remember

• 기여는 시간이 아니라 인과로 정의합니다. "이것이 없었다면 이 결과가 없었는가"가 기준입니다.
• 기여는 7개 범주로 봅니다. Origination, Sales, Execution(유급 업무를 넘어선 부분), Leadership & Risk, Capital & Infra, Network, Knowledge. 한 사람을 한 칸에 넣지 않고 행동을 칸에 넣습니다.
• 프로젝트 기여는 정산으로, 커뮤니티 기여는 신뢰와 기회로 이어집니다. 두 흐름은 다르지만 서로를 먹여 살립니다.
• 보이지 않는 기여(위험부담, 실패한 영업, 조율)는 미리 이름 붙이고, 과정을 기록하고, 동료가 증언해서 드러냅니다.
• 기록은 사후가 아니라 진행 중에 합니다. 한 줄이면 됩니다. 기록은 관료주의가 아니라 기억의 외주입니다.

"기여한 사람을 잊지 않는다. 잊지 않으려면 기록하고, 기록하려면 무엇이 기여인지 먼저 합의한다."

개정 메모: 사례 속 비율과 산식은 확정 규정이 아닙니다. 프로젝트 업무보수는 실제 계약으로 사전 합의하고, 사업협동조합의 결산상 잉여금 배당과 구분합니다. 조직 수수료·분담·복지 출연도 법률·회계·세무 근거 없이 고정 비율로 적용하지 않습니다.

돈이 들어온 뒤에 나누는 방법을 정하면 늦습니다. 이 장은 보상을 두 층으로 나누고, 시작하기 전에 합의하고, 끝날 때 숫자로 정산하는 방법을 다룹니다.

질문에서 시작합니다

가상의 상황입니다. 어느 물류 스타트업의 고객 응대 자동화 프로젝트가 끝났습니다. 계약금 5천만원이 계약주체의 통장에 들어왔습니다. 다섯 명이 참여했고, 넉 달이 걸렸습니다. 시작할 때는 모두 "일단 잘 만들어 봅시다, 정산은 끝나고 얘기하죠"라고 했습니다. 좋은 뜻이었습니다. 서로 믿었기 때문입니다.

이제 정산 회의입니다. 개발자는 "내가 제일 오래 일했다"고 합니다. 고객을 소개한 마케터는 "내가 없었으면 이 돈 자체가 없었다"고 합니다. 계약주체인 파운더는 "세금과 하자보수는 내 몫인데 그건 왜 아무도 얘기 안 하느냐"고 합니다. 자문한 교수는 말이 없습니다. 자기가 얼마를 받아야 하는지 스스로도 모르기 때문입니다. 넉 달 동안 잘 지내던 다섯 사람이 한 시간 만에 서로를 의심하기 시작합니다.

이 회의를 망친 것은 돈이 아닙니다. 순서입니다. 보상은 프로젝트가 끝난 뒤에 정하는 것이 아니라 시작하기 전에 설계하는 것입니다. 이 장은 그 설계의 방법을 다룹니다. 무엇을 세는가는 제19장에서 정리했습니다. 여기서는 그 기여를 어떻게 돈으로 바꾸는가를 다룹니다.

왜 보상 설계는 자주 실패하는가

공동 프로젝트의 보상이 무너지는 방식은 몇 가지로 정해져 있습니다. 새로운 실패는 거의 없습니다. 같은 실패가 팀만 바꿔 반복됩니다.

사후 협상. 가장 흔합니다. 끝나고 정하자는 말은 신뢰의 표현처럼 들리지만, 실제로는 가장 힘센 사람에게 유리한 구조입니다. 돈을 쥔 사람, 고객을 쥔 사람, 코드를 쥔 사람 순으로 협상력이 생깁니다. 시작할 때 다섯 명은 동료였지만, 정산할 때 다섯 명은 협상 상대입니다.

구두 약속. "잘 되면 챙겨 드릴게요." 이 말은 거짓말이 아닙니다. 말한 사람도 그럴 생각이었습니다. 그러나 "잘 되면"이 언제인지, "챙긴다"가 얼마인지 아무도 모릅니다. 기억은 각자에게 유리하게 편집됩니다. 여섯 달 뒤 두 사람은 서로 다른 약속을 기억합니다.

Lead 독식. 계약주체나 Project Lead(프로젝트 리드)가 돈을 받고, 나머지에게 "적당히" 나눠 주는 방식입니다. 참여자는 얼마가 들어왔는지 모르고, 얼마가 남았는지 모르고, 왜 그 액수인지 모릅니다. 이것은 Project Cell(프로젝트 셀)이 아니라 하청입니다. 커뮤니티가 회원을 값싼 노동력으로 쓰지 않는다는 약속은 여기서 깨집니다.

시간만 계산. 반대편의 실패입니다. 공수를 시간당 단가로 곱해 나누면 공정해 보입니다. 그러나 이 방식은 고객을 가져온 사람, 위험을 진 사람, GPU를 댄 사람에게 아무것도 주지 않습니다. 시간만 세면 다음 프로젝트에서는 아무도 시간 외의 것을 내놓지 않습니다.

1/n. 다섯 명이니 20%씩. 다투기 싫어서 택하는 방식입니다. 그러나 공평(Equal)과 공정(Fair)은 다릅니다. 200시간 일한 사람과 20시간 일한 사람이 같은 몫을 받으면, 200시간 일한 사람은 다음에 없습니다. 이 문제는 제22장에서 숫자로 다룹니다.

AI 시대에는 이 실패의 비용이 더 커집니다. 실행 비용이 낮아진 만큼 한 사람이 감당할 수 있는 프로젝트 범위가 넓어졌고, 그래서 "내가 다 했다"는 착각도 쉬워졌습니다. 그러나 코드가 싸진 세상에서 비싼 것은 고객과 판단과 책임입니다. 보상 설계가 이 비싼 것들을 세지 못하면 조직은 싼 것만 남습니다.

우리의 철학: 일한 것은 먼저 보상하고, 추가가치는 기여에 따라 나눈다

한국인공지능커뮤니티의 보상은 두 층으로 이루어집니다.

┌──────────────────────────────────────────────┐
│  매출 (고객이 지불한 금액)                       │
├──────────────────────────────────────────────┤
│  − 직접비용 (외부 API, 외주, 출장 등)             │
├──────────────────────────────────────────────┤
│  − Work Compensation (수행 대가)                 │
│     실제 수행한 업무 × 시장 단가, 먼저 지급          │
├──────────────────────────────────────────────┤
│  = 잉여가치 (Surplus)                            │
│     − 커뮤니티 기여분 (기본 5%, 3~10%)             │
│     = Value Sharing (가치 배분)                  │
│        Contribution Matrix에 따라 배분             │
└──────────────────────────────────────────────┘

Work Compensation(수행 대가) 은 실제로 한 일에 대한 대가입니다. 개발자가 파이프라인을 만들었으면 그 일의 시장 단가를 받습니다. 크리에이터가 영상을 만들었으면 영상의 시장 단가를 받습니다. 이것은 프로젝트가 잘 되든 못 되든 지급됩니다. 매출이 예상보다 적어도 먼저 지급됩니다. 사람을 소모품처럼 다루지 않는다는 약속의 가장 구체적인 형태가 이 층입니다.

Value Sharing(가치 배분) 은 함께 만들었기 때문에 생긴 추가가치를 나누는 층입니다. 개발자 혼자였으면 고객이 없었고, 마케터 혼자였으면 만들 사람이 없었습니다. 결합했기 때문에 생긴 가치가 잉여가치이고, 이것은 누가 얼마나 일했느냐가 아니라 누가 이 결합에 무엇을 기여했느냐로 나눕니다. 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다.

왜 두 층으로 나눕니까. 한 층으로 합치면 두 가지 중 하나가 무너지기 때문입니다. 전부 기여 비율로 나누면, 프로젝트가 실패했을 때 200시간 일한 개발자가 한 푼도 못 받습니다. 전부 시간으로 나누면, 고객을 가져온 사람과 위험을 진 사람이 한 푼도 못 받습니다. 두 층은 서로 다른 질문에 답합니다. 첫 층은 "당신이 한 일의 값은 얼마인가", 둘째 층은 "우리가 함께 만든 것에서 당신의 몫은 얼마인가"입니다.

이 구조의 전제는 순서입니다. "각자의 몫을 먼저 나누지 않는다. 먼저 함께 더 큰 가치를 만들고, 그 가치를 실제 기여와 책임에 따라 공정하게 나눈다." 프로젝트 전체의 성공을 개인의 단기이익보다 우선하는 것은 도덕이 아니라 계산입니다. 파이가 커야 나눌 것이 있습니다.

운영원칙: 잉여가치의 계산과 배분

아래 숫자는 커뮤니티의 기본값(Default)이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

계산식

잉여가치 = 매출 − 직접비용 − Work Compensation
Value Sharing 재원 = 잉여가치 − 커뮤니티 기여분

커뮤니티 기여분을 잉여가치에서만 떼는 이유는 분명합니다. 수행 대가에서 떼면 커뮤니티가 회원의 노동에서 수수료를 걷는 것이 됩니다. 그것은 플랫폼 노동의 구조이지 우리가 만들려는 구조가 아닙니다. 잉여가치가 없으면 커뮤니티 기여분도 없습니다. 커뮤니티는 회원이 함께 만든 추가가치에서만, 그것도 작은 몫만 가져갑니다.

배분 절차

Charter에서 사전 합의 → 진행 중 기여 기록 → 종료 시 Contribution Matrix 확정 → Settlement Sheet

1. Charter에서 사전 합의. 프로젝트 시작 전에 Work Compensation의 역할별 단가(또는 정액), 예상 직접비용, 커뮤니티 기여분 비율, Contribution Matrix의 예상 비율을 적습니다. 확정이 아니라 예상입니다. 그러나 예상이 있어야 끝날 때 "무엇이 달라졌는가"만 이야기할 수 있습니다.
2. 진행 중 기여 기록. 제19장의 방식대로 주 1회 기록합니다. 범위 밖 업무, 위험 사건, 영업 활동, 자산 투입을 한 줄씩 남깁니다.
3. 종료 시 Contribution Matrix 확정. 기록과 동료 증언을 바탕으로 최종 비율을 정합니다. 이것은 이해관계 변경이므로 Project Lead 단독이 아니라 참여자 합의(원칙적으로 전원, Charter에 정한 경우 다수결)로 확정합니다. 실행은 빠르게, 이해관계 변경은 합의로.
4. Project Settlement Sheet(정산표) 작성. 매출, 직접비용, Work Compensation, 잉여가치, 커뮤니티 기여분, Value Sharing 배분액을 한 장에 적습니다. 참여자 전원이 같은 표를 봅니다. 계약주체는 입금 후 기본 30일 이내에 Value Sharing을 지급하고, 세금·원천징수 처리 방식을 정산표에 적습니다.

경계 상황과 예외

• 매출이 예상보다 적을 때. Work Compensation을 먼저 지급하고 남는 것이 없으면 Value Sharing은 0입니다. 그래도 Contribution Matrix는 확정하고 기록합니다. 기여 기록은 Trust Capital(신뢰 자산)로 남기 때문입니다.
• 매출이 Work Compensation에도 못 미칠 때. Charter에서 미리 정합니다. 기본값은 계약주체가 부족분을 부담하지 않고, 참여자가 Work Compensation을 비율대로 감액합니다. 다만 계약주체가 위험을 지기로 Charter에 적었다면 그 위험은 Leadership & Risk 기여로 인정됩니다. 실패 시의 정산 원칙은 제18장을 참조하십시오.
• 분할 입금. 착수금·중도금·잔금으로 나뉘어 들어오면, Work Compensation은 입금마다 비례 지급하고 Value Sharing은 잔금 이후 한 번에 정산하는 것이 기본값입니다.
• 범위가 커졌을 때. 고객이 추가 요구를 하고 추가 매출이 생기면 Charter를 개정합니다. 추가 매출 없이 범위만 커졌다면, 그 추가 업무는 Execution 기여로 기록하고 잉여가치에서 인정합니다.

자본·GPU·공간을 댄 사람은 어떻게 보상하는가

돈과 장비와 공간은 시간과 다르게 다뤄야 합니다. 세 가지 방식이 있고, Charter에서 하나를 고릅니다.

원칙은 하나입니다. 같은 자산을 두 번 세지 않습니다. GPU 사용료를 직접비용으로 받았으면 Capital & Infra 기여는 없습니다. 무상으로 제공했으면 기여로 인정합니다. 둘 중 무엇을 택할지는 제공자가 정하되, 시작 전에 정합니다. 프로젝트가 잘된 뒤에 "사실 그 서버는 무상이었으니 기여로 쳐 달라"고 바꾸지 않습니다.

운영비를 선투입한 자본은 조금 다릅니다. 파운더가 넉 달 동안 참여자의 Work Compensation을 매출 입금 전에 먼저 지급했다면, 그것은 자본의 시간 가치와 회수 위험을 함께 진 것입니다. 원금은 매출에서 먼저 회수하고, 위험을 진 것은 Leadership & Risk 또는 Capital & Infra로 인정합니다. 다만 커뮤니티 안의 프로젝트에서 자본 제공자가 잉여가치의 과반을 가져가는 구조는 권장하지 않습니다. 그것은 Project Cell이 아니라 투자 계약이고, 투자 계약이 필요하면 별도로 명시적으로 맺습니다.

IP가 다시 쓰일 때의 보상

Project Cell이 만든 것 중 일부는 이번 프로젝트에서 끝나지 않습니다. 문서 검색 파이프라인, 평가 데이터셋, 프롬프트 템플릿, 영상 워크플로우는 다음 프로젝트에서 다시 쓰입니다. 이 재사용 가능한 자산의 귀속과 보상은 Charter에서 정합니다. 커뮤니티의 기본값은 다음과 같습니다.

• 고객 납품물의 IP는 계약이 정합니다. 계약서에 고객 귀속이라고 되어 있으면 그것을 따릅니다.
• Project Cell이 만든 재사용 가능한 자산은 만든 참여자의 공동 소유이며, 커뮤니티 회원에게 비독점 재사용 라이선스가 주어집니다.
• 참여 전부터 가지고 있던 것(Background IP)은 원소유자에게 남습니다. 이번 프로젝트에 투입했다면 Knowledge 기여로 인정합니다.

재사용 시의 보상은 두 가지로 처리합니다. 첫째, 다음 프로젝트가 그 자산을 쓰면 그 프로젝트의 Contribution Matrix에서 원제작자를 Knowledge 기여자로 기록합니다. 원제작자가 그 프로젝트에 참여하지 않았더라도 그렇습니다. 둘째, 커뮤니티 기여분의 일부는 이런 공용 자산을 유지·개선하는 데 쓰입니다. 자산을 커뮤니티에 공개한 사람은 플랫폼에 Technology 또는 Knowledge 기여로 기록되고, 이는 Trust Capital과 다음 협업 기회로 이어집니다.

영구 로열티는 기본값이 아닙니다. 과거의 기여는 신뢰를 만들지만 영구적인 권리는 만들지 않습니다. 원제작자가 매번 개입하지 않는 자산에 대해 매번 같은 비율을 요구하면, 자산은 쓰이지 않고 조용히 다시 만들어집니다. 그것은 모두에게 손해입니다. Knowledge 기여의 비중은 그 자산이 이번 프로젝트의 결과에 얼마나 기여했는가로 매번 정합니다.

Case: 5천만원 프로젝트의 정산표

가상의 사례입니다. 장 첫머리의 물류 스타트업 고객 응대 자동화 프로젝트를 처음부터 다시 설계해 보겠습니다. 이번에는 시작 전에 Charter를 썼습니다.

참여자와 역할.

• 마케터 한 씨 — Originator. 고객사 대표를 소개하고 요구사항을 정리했습니다.
• 파운더 박 대표 — 계약주체이자 Project Lead. 자기 회사 명의로 계약했고, 6개월 하자보수 책임을 졌습니다.
• 개발자 최 씨 — 응대 파이프라인과 관리자 화면 구축. 이전 프로젝트에서 만든 파이프라인 템플릿을 가져왔습니다.
• 연구자 이 교수 — 응답 품질 평가 설계, 격주 자문 6회.
• 크리에이터 정 씨 — 고객사 직원 교육 영상과 온보딩 화면 제작.
• 회원 강 씨 — 참여자가 아니지만 자기 GPU 서버를 넉 달간 무상으로 내주었습니다.

Charter의 보상 조항. Work Compensation은 역할별 정액으로 합의했습니다. 최 씨 1,200만원, 정 씨 500만원, 박 대표(PM 업무) 400만원, 이 교수 300만원, 한 씨(요구사항 정리·고객 미팅 실무) 200만원. 합계 2,600만원. 커뮤니티 기여분은 기본값 5%. 강 씨의 GPU는 Capital & Infra 기여로 인정하기로 했습니다. Contribution Matrix의 예상 비율도 적었습니다.

실행 중. 3개월 차에 고객이 채널을 하나 추가해 달라고 했고, 추가 매출 없이 최 씨가 40시간을 더 썼습니다. 주간 기록에 남겼습니다. 박 대표는 잔금 지급이 늦어지자 두 번 독촉해 받아냈습니다. 그것도 남겼습니다.

정산. 잔금까지 5,000만원(부가세 제외)이 입금됐습니다.

Contribution Matrix는 참여자 전원 합의로 다음과 같이 확정됐습니다.

최종 수령액.

이 표가 말하는 것. 가장 오래 일한 최 씨가 가장 많이 받았습니다. 시간이 무시되지 않았습니다. 그러나 한 씨는 200만원어치 실무만으로 675만원을 받았습니다. 프로젝트를 존재하게 만든 기여가 인정됐기 때문입니다. 박 대표는 PM 업무의 대가 400만원에 위험부담과 협상의 몫 475만원을 더했지만, 잉여가치의 4분의 1이지 전부가 아닙니다. 강 씨는 한 줄의 코드도 쓰지 않았지만 95만원을 받았습니다. 다음에도 서버를 내줄 이유가 생겼습니다.

만약 1/n이었다면 참여자 5명이 380만원씩 받고 강 씨는 아무것도 받지 못했을 것입니다. 만약 시간만 계산했다면 한 씨는 200만원, 박 대표는 400만원에서 끝났을 것입니다. 만약 사후 협상이었다면 이 회의는 한 시간이 아니라 한 달이 걸렸을 것입니다. 실제로는 Charter의 예상 비율과 최종 비율의 차이(최 씨의 범위 밖 40시간으로 Execution이 10에서 15로 올라간 것)만 논의했고, 회의는 40분에 끝났습니다.

정산표에는 한 줄이 더 있었습니다. 최 씨의 파이프라인 템플릿은 이번 프로젝트에서 개선된 버전으로 커뮤니티에 비독점 라이선스로 공개됐고, 최 씨와 이 교수의 공동 소유로 기록됐습니다. 다음 프로젝트가 이 템플릿을 쓰면 두 사람은 그 프로젝트의 Knowledge 기여자가 됩니다.

Remember

• 보상은 두 층입니다. Work Compensation은 실제 수행한 업무의 시장 단가로 먼저 지급하고, Value Sharing은 잉여가치를 Contribution Matrix에 따라 나눕니다.
• 잉여가치 = 매출 − 직접비용 − Work Compensation. 커뮤니티 기여분(기본 5%, 3~10%)은 잉여가치에서만 뗍니다. 회원의 노동에서는 떼지 않습니다.
• 절차는 네 단계입니다. Charter에서 사전 합의, 진행 중 기여 기록, 종료 시 Contribution Matrix 확정, Settlement Sheet. 사후 협상·구두 약속·Lead 독식·시간만 계산·1/n은 모두 이 절차를 건너뛴 결과입니다.
• 자본·GPU·공간은 직접비용, Work Compensation, Capital & Infra 기여 중 하나로 시작 전에 정하고, 같은 자산을 두 번 세지 않습니다.
• 재사용되는 IP는 만든 사람의 공동 소유와 커뮤니티 비독점 라이선스가 기본값이며, 재사용 프로젝트에서 Knowledge 기여로 매번 인정합니다. 영구 로열티는 기본값이 아닙니다.

"일한 것은 먼저 보상하고, 추가가치는 기여에 따라 나눈다. 그리고 그 방법은 돈이 들어오기 전에 정한다."

돈으로 지급되지 않는 보상에는 무엇이 있고, 그것은 언제 정당한 보상이 되며, 언제 착취를 감추는 포장이 되는가.

"경험이 되실 거예요"라는 말

연구원 정 박사는 독립한 지 1년이 되었습니다. 논문을 재현하고 모델을 개선하는 데는 누구보다 빠르지만, GPU가 없습니다. 어느 날 파운더 박 대표가 연락을 합니다. "저희 PoC에 참여해 주시면 좋은 경험이 되실 겁니다. 지금은 예산이 없지만 잘되면 지분도 드리겠습니다." 이 장면은 가상의 사례입니다. 그러나 이 문장을 처음 듣는 독자는 없을 것입니다.

정 박사는 망설입니다. 실제 기업 데이터를 다뤄 볼 기회입니다. 다만 "잘되면"이라는 조건은 정 박사가 통제할 수 없고, 지분은 종이에 적히지 않았으며, 경험은 어디에도 기록되지 않습니다. 같은 주에 개발자 김 씨는 반대의 제안을 받습니다. 한 Project Cell(프로젝트 셀)이 시장 단가로 Work Compensation(수행 대가)을 지급하겠다고 합니다. 그런데 김 씨가 정말 원하는 것은 돈이 아니라 아직 공개되지 않은 오픈모델을 먼저 만져 볼 기회입니다.

이 장은 이 두 질문에 답합니다. 돈이 아닌 보상은 실재하고, 때로 돈보다 귀합니다. 그러나 돈이 아닌 보상이 돈을 대신하는 순간, 그것은 보상이 아니라 착취가 됩니다. 이 경계를 분명히 긋는 것이 이 장의 목적입니다.

왜 이것이 문제인가

AI 시대에 희소한 것이 바뀌었습니다. 코드와 영상과 문서는 싸졌습니다. 반면 GPU, 공개되지 않은 모델에 대한 접근, 첫 번째 고객, 실제로 해 본 사람의 평판은 비싸졌습니다. 시장 단가로 환산하기 어려운 이 자산들이 실제로는 한 사람의 다음 단계를 결정합니다. 정 박사에게 GPU 200시간은 현금 몇백만원보다 큰 의미일 수 있습니다.

그런데 대부분의 조직은 이 보상을 다루는 언어가 없습니다. 위계 조직은 승진과 직함으로, 시장은 오직 돈으로, 느슨한 커뮤니티는 '좋아요'로 보상합니다. 셋 다 정 박사가 원하는 것을 주지 못합니다. 승진할 회사가 없고, 돈은 부족하고, '좋아요'는 GPU를 돌리지 못합니다.

여기서 두 가지 실패가 생깁니다. 첫째, 비금전 보상을 없는 것으로 취급하는 실패입니다. 김 씨가 오픈모델 테스트권을 받았다는 사실이 어디에도 남지 않으면, 그 보상은 사적인 호의가 되고 다음 프로젝트에서 김 씨는 처음부터 다시 부탁해야 합니다. 기여한 사람을 잊지 않는다는 원칙은 보상을 기록하는 데까지 확장되어야 합니다.

둘째, 비금전 보상으로 금전 보상을 대체하는 실패입니다. 이것이 더 위험합니다. "경험", "노출", "네트워크", "잘되면 지분"은 모두 실제 가치가 있습니다. 바로 그 때문에 무급 노동을 요구하는 가장 그럴듯한 포장이 됩니다. 제안하는 쪽은 미래를 크게 말하고, 받는 쪽은 미래를 크게 할인합니다. 그 사이에서 노동은 지급되지 않은 채 소비됩니다. 이런 인식이 커뮤니티 안에 퍼지면 실력 있는 사람부터 조용히 떠나고, 커뮤니티는 외주 인력풀보다 나쁜 곳이 됩니다. 사람을 소모품처럼 다루지 않는다는 약속은 여기서 가장 먼저 시험받습니다.

우리의 철학: 보상은 다음 단계로 가는 데 필요한 것이다

우리는 보상을 "일에 대한 대가"로만 보지 않습니다. 보상은 한 사람이 다음 단계로 가는 데 필요한 것입니다. CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK이라는 공식에서 REWARD 다음에 GROWTH가 옵니다. 보상이 성장으로 이어지지 않으면 순환이 끊깁니다.

사람을 Capability Node(역량 노드)로 본다는 것은 사람마다 병목이 다르다는 것을 인정하는 일입니다. 어떤 노드는 자본이, 어떤 노드는 인프라가, 어떤 노드는 고객이, 어떤 노드는 평판이 부족합니다. 같은 기여를 했더라도 각자에게 가장 가치 있는 보상은 다를 수 있습니다. 이 다름을 무시하고 모두에게 현금만 주는 것은 편리하지만 성장을 만들지는 못합니다.

그렇다고 비금전 보상이 금전 보상을 대신할 수는 없습니다. 비금전 보상은 대체가 아니라 추가 층입니다. 실제 수행한 일은 시장 단가로 먼저 지급하고, 그 위에서 잉여가치를 기여에 따라 나누며, 그 위에 비금전 보상이 놓입니다. 아래층을 빼고 위층만 올리면 건물은 서지 못합니다.

      ┌──────────────────────────────┐
  3층 │ 비금전 보상 (Non-monetary)    │  Reputation · Access · GPU · 고객 · Network · Fellow · 교육 · 투자기회
      ├──────────────────────────────┤
  2층 │ Value Sharing (가치 배분)     │  잉여가치를 Contribution Matrix에 따라
      ├──────────────────────────────┤
  1층 │ Work Compensation (수행 대가) │  시장 단가로 먼저 · 절대 생략하지 않음
      └──────────────────────────────┘

프로토콜 조직이 위계·시장·느슨한 커뮤니티와 다른 점이 여기에 있습니다. 위계는 승진을 주고 시장은 돈을 주지만, 프로토콜 조직은 기록된 신뢰 위에서 여러 종류의 보상을 조합할 수 있습니다. 그리고 그 조합이 기록되기 때문에 다음 협력의 조건이 됩니다.

아홉 가지 비금전 보상

아래는 커뮤니티가 인정하고 기록하는 비금전 보상의 종류입니다. 이 목록은 닫혀 있지 않으며, Project Charter(프로젝트 헌장)에서 다른 항목을 정의할 수 있습니다.

표의 세 번째 열이 중요합니다. 각 보상 옆에는 그것을 흉내 낸 가짜가 있습니다. 진짜와 가짜를 가르는 기준은 하나입니다. 구체적으로 정의되고 기록되는가. "GPU 100시간, 3개월 내, H3Lab 테스트베드"는 보상입니다. "필요하면 GPU 쓰세요"는 보상이 아닙니다.

누가 무엇을 원하는가

같은 보상이라도 역할에 따라 가치가 다릅니다. Project Lead(프로젝트 리드)가 보상 구조를 설계할 때 참고할 수 있도록, 역할별로 흔히 우선하는 보상을 정리합니다. 이것은 경향이지 규칙이 아닙니다. 실제 선호는 반드시 본인에게 묻습니다.

교수의 경우 소속 기관의 회계 규정 때문에 현금이 오히려 부담이 될 때가 있습니다. 이때 공동연구 계약이나 학생 참여 기회가 더 실질적인 보상이 됩니다. 반대로 개발자에게 "명함에 CTO라고 적어 드리겠다"는 것은 거의 아무 가치도 없습니다. 보상은 주는 사람이 아니라 받는 사람의 병목에 맞춰야 합니다.

크리에이터의 첫 번째 항목도 중요합니다. AI 영상·이미지 작업은 고객 계약상 공개가 제한되는 경우가 많고, 결과물을 포트폴리오로 공개할 권리는 다음 고객을 만드는 직접적인 자산입니다. 이 권리는 계약 단계에서 고객과 협의해야 얻을 수 있으므로 Project Lead는 계약 전에 확인해야 합니다. 프로젝트가 끝난 뒤에는 늦습니다.

운영원칙

아래 원칙은 커뮤니티의 기본값(Default)이며, Project Charter로 조정할 수 있습니다. 단, 1번 원칙은 조정할 수 없습니다.

2번 원칙에는 경계 상황이 있습니다. 파운더 박 대표가 자기 회사의 제품을 만들면서 스스로 Work Compensation을 받지 않는 것은 자기 사업에 대한 투자이므로 자연스럽습니다. 그러나 박 대표가 정 박사에게 "저도 안 받으니 박사님도 안 받으시죠"라고 말하는 순간, 그것은 유도된 포기가 됩니다. 자기 사업의 위험을 자기가 지는 것과 남에게 지우는 것은 다릅니다. 박 대표의 포기는 Contribution Matrix(기여도 평가표)의 Leadership & Risk와 Capital 범주에서 인정받고, 정 박사의 노동은 Work Compensation으로 지급받습니다.

3번 원칙의 교환 동의는 정산 시점이 아니라 Charter 작성 시점에 이루어져야 합니다. 프로젝트가 끝난 뒤 "현금 대신 GPU로 받으시죠"라고 제안하는 것은 이해관계 변경입니다. 실행은 빠르게, 이해관계 변경은 합의로. 정산 단계에서의 교환 제안은 참여자 전원의 합의가 필요합니다.

앵커 조직이 제공하는 비금전 보상

앵커 조직은 동등한 생태계 파트너 중 먼저 온 조직입니다. 이들이 제공하는 비금전 보상은 커뮤니티의 실질적인 자산이지만, 커뮤니티를 특정 회사의 외주 인력풀로 만들어서는 안 됩니다. 그래서 앵커의 제공 조건은 공개되고, 앵커가 아닌 회원·기업도 같은 방식으로 보상을 제공할 수 있어야 합니다.

AI TEST의 조건을 주목하십시오. 인증은 보상이 아니라 검증입니다. 프로젝트에 참여했다는 이유로 인증을 주면 인증의 가치가 무너집니다. 앵커가 제공하는 것은 "응시 기회"이지 "합격"이 아닙니다. 같은 이유로 H3Lab의 테스트권에는 결과를 공유한다는 조건이 붙습니다. 보상은 순환해야 합니다. 앵커가 아닌 회원도 같은 방식으로 보상을 제공할 수 있습니다. 개발자 김 씨가 자기 서버의 유휴 GPU를 정 박사에게 제공하면, 김 씨의 Infrastructure 기여로 기록되고 정 박사의 Reward로 기록됩니다. 기여와 보상은 같은 원장의 양면입니다.

Reputation은 어떻게 Trust Capital이 되는가

아홉 가지 비금전 보상 중 Reputation은 특별합니다. 다른 보상은 누군가가 "주는" 것이지만, 평판은 아무도 줄 수 없습니다. 평판은 기록에서 자라납니다.

Trust Capital(신뢰 자산)은 약속 준수, 정산, 일정, 비밀유지, 결과물, 동료평가, 재협업 의사의 기록입니다(제10장 참조). Reputation은 이 기록이 커뮤니티 안에서 읽히는 방식입니다. Trust Capital이 원장이라면 Reputation은 그 원장을 본 사람들의 판단입니다. 원장 없이 판단만 있으면 소문이고, 판단 없이 원장만 있으면 아무도 보지 않는 데이터입니다.

그래서 우리는 기여를 기록하고, 기록을 볼 수 있게 합니다. 개발자 김 씨가 세 개의 Project Cell에서 일정을 지켰고, 두 번의 동료평가에서 "다시 함께 일하고 싶다"는 답을 받았고, 한 번의 Closing Review에서 재사용 자산을 남겼다면, 그 사실이 김 씨의 프로필에서 읽혀야 합니다. 신뢰는 말이 아니라 행동으로 쌓습니다. 이 구조 때문에 Reputation은 조작이 어렵습니다. 목소리가 크거나 발표를 잘하는 것은 기록되지 않습니다. 조용히 일을 마치는 사람이 가장 높은 평판을 가질 수 있어야 커뮤니티는 SNS와 달라집니다.

Reputation은 다음 협력의 조건이 됩니다. Project Lead가 팀을 꾸릴 때 보는 Capability + Experience + Trust + Availability + Fit(제15장 참조)의 Trust가 바로 Reputation으로 읽히는 Trust Capital입니다. 그러나 여기서도 원칙은 같습니다. Contribution creates Trust, not Permanent Privilege. 과거의 평판은 다음 기회의 근거가 되지만, 다음 기회를 보장하지는 않습니다.

비금전 보상도 기록되어야 하는 이유

첫째, 기여한 사람을 잊지 않기 위해서입니다. GPU를 내놓은 사람, 고객을 소개한 사람, 멘토링을 한 사람의 기여는 그 보상이 기록될 때 함께 기록됩니다. 보상 기록이 없으면 기여 기록도 절반만 남습니다.

둘째, 착취를 막기 위해서입니다. Charter에 "비금전 보상: 없음, Work Compensation: 0원"이라고 적어야 한다면, 제안자는 그 문장을 쓰는 순간 자기 제안의 문제를 보게 됩니다. 기록은 부정직을 어렵게 만드는 가장 조용한 장치입니다.

셋째, 공정한 비교를 위해서입니다. 다음 장의 Value Sharing 배분에서, 어떤 참여자가 이미 비금전 보상을 받았다면 그것은 최종 수령액 판단에 반영되어야 합니다. 기록이 없으면 같은 기여에 두 번 보상하거나 한 번도 보상하지 않는 일이 생깁니다.

넷째, 커뮤니티 전체의 자산을 보기 위해서입니다. 어떤 앵커가 얼마나 많은 GPU를, 어떤 회원이 얼마나 많은 소개를 제공했는지가 기록되면 커뮤니티는 자기 생태계가 무엇으로 돌아가는지 알게 됩니다. 이것이 Give Back의 근거가 됩니다(제27장 참조). 형식은 단순합니다. 비금전 보상은 플랫폼 기여 기록(Knowledge · Research · Technology · Mentoring · Project · Event · Connection · Infrastructure)의 반대편에 Reward로 적힙니다. 제공자에게는 기여로, 수령자에게는 보상으로, 같은 사건이 두 사람의 원장에 동시에 남습니다.

Case: GPU가 필요한 연구자와 예산이 없는 파운더

이 사례는 가상의 사례입니다.

상황. 파운더 박 대표는 제조업 고객의 불량 검출 PoC를 준비하고 있습니다. 고객은 관심이 있지만 아직 계약 전이고, 박 대표 회사의 현금은 두 달치 운영비뿐입니다. 연구원 정 박사는 비전 모델 미세조정에 필요한 실력을 갖췄지만 GPU가 없습니다. 박 대표는 정 박사에게 "예산이 없으니 무급으로 참여하고 잘되면 지분을 드리겠다"고 제안합니다.

갈등. 정 박사는 제안을 받아들이려 합니다. 데이터가 탐나고, 거절하면 기회가 사라질 것 같습니다. 그러나 Project Lead를 맡은 PM 이 씨가 Charter 초안을 검토하다가 문제를 발견합니다. 보상 구조 항목에 "정 박사: Work Compensation 0원, 비금전 보상: 경험 및 향후 지분"이라고 적혀 있습니다. 운영원칙 1번 위반입니다.

적용. 세 사람이 함께 Charter를 다시 씁니다. 먼저 정 박사의 실제 수행 업무를 정의합니다. 모델 미세조정과 평가, 예상 10일, 시장 단가 기준 일당 45만원, Work Compensation 450만원. 박 대표는 지금 현금이 없다고 말합니다. 이 씨는 두 가지 방법을 제시합니다. 하나는 지급 시점을 고객 계약 후로 미루되 금액과 시점을 Charter에 못 박고, 미지급 시 프로젝트를 종료하는 것입니다. 지급 유예이지 포기가 아닙니다. 다른 하나는 정 박사가 스스로 원한다면 Work Compensation의 일부를 Value Sharing 지분과 교환하는 것입니다. 정 박사는 첫 번째를 택합니다. 아직 계약도 없는 회사의 지분을 자기 노동과 바꿀 이유가 없기 때문입니다.

GPU 문제는 따로 풉니다. 이 씨는 H3Lab 테스트베드의 제공 조건을 확인합니다. "GPU 150시간, 8주 내, 벤치마크 결과 공유 조건". 이것을 Charter의 비금전 보상 항목에 제공자·수령자·조건과 함께 적습니다. 정 박사의 Reward로, H3Lab의 Infrastructure 기여로 기록됩니다.

박 대표가 자기 Work Compensation을 받지 않기로 한 것은 자기 사업에 대한 투자이므로 환산액과 함께 기록합니다. 고객을 가져온 Origination, 계약주체로서 지는 위험, 운영비 선투입은 Contribution Matrix에서 인정됩니다. 잘되면 박 대표는 잉여가치의 큰 부분을 받고, 못 되면 자기가 감수하기로 한 위험을 집니다. 정 박사에게 그 위험을 넘기지 않습니다.

결과. PoC는 고객 계약으로 이어졌고, 정 박사의 Work Compensation은 계약금 입금 후 일주일 안에 지급되었습니다. 정 박사는 테스트베드에서 얻은 벤치마크를 Research Circle에 공유했고, 그 기록으로 다른 두 프로젝트의 초대를 받았습니다. 박 대표는 후속 프로젝트에서 정 박사를 다시 찾았습니다. 이번에는 "무급"이라는 말이 처음부터 나오지 않았습니다.

처음 제안대로 진행되었다면 어땠을까요. PoC가 실패하면 정 박사는 열흘의 노동을 잃고 박 대표는 신뢰를 잃습니다. 성공해도 "지분"의 조건이 문서에 없으니 다툼이 시작됩니다. 어느 쪽이든 두 사람은 다시 함께 일하지 않습니다. 프로젝트 전체의 성공을 개인의 단기이익보다 우선한다는 원칙은, 이 경우 박 대표의 단기 현금 절약보다 정 박사와의 다음 협력을 우선하라는 뜻입니다.

Remember

• 돈이 아닌 보상은 실재합니다. GPU, 조기 접근, 고객, 네트워크, 평판, 교육, 투자기회는 AI 시대에 현금보다 희소할 수 있으며, 사람마다 병목이 다르므로 각자에게 맞는 보상이 다릅니다.
• 그러나 비금전 보상은 Work Compensation을 대체하지 못합니다. 실제 수행한 일은 시장 단가로 먼저 지급합니다. "경험이 될 것"이라는 이유로 무급 노동을 요구하는 것은 금지이며, 이 원칙은 Charter로도 바꿀 수 없습니다.
• 비금전 보상은 종류·수량·기간·제공자·조건이 Charter에 적혀야 보상입니다. 적히지 않은 것은 호의이고, 호의는 기록되지 않으며, 기록되지 않은 것은 다음 협력의 근거가 되지 못합니다.
• Reputation은 아무도 줄 수 없습니다. 기록된 기여와 동료평가에서만 자랍니다. 조용히 약속을 지키는 사람이 가장 높은 평판을 가지는 구조여야 커뮤니티는 SNS와 달라집니다.
• 비금전 보상은 제공자에게는 기여로, 수령자에게는 보상으로 같은 원장에 남습니다. 기여한 사람을 잊지 않는다는 약속은 보상을 기록하는 데까지 이어집니다.

"경험은 보상이 될 수 있지만, 대가를 대신할 수는 없다."

네 명이니 4등분, 여섯 명이니 6등분. 가장 쉬운 배분이 왜 가장 나쁜 배분인지를 두 개의 정산표로 보여 드립니다. 그리고 기여도 평가가 사람의 편향에 휘둘리지 않게 하는 장치를 다룹니다.

질문에서 시작합니다

가상의 상황입니다. 중소 제조기업의 고객 문의 챗봇 PoC(개념 검증)가 3천만원에 계약됐습니다. 참여자는 고객사 대표를 소개한 사업가 윤 대표, 개발자 김 씨와 서 씨, PM을 맡은 Project Lead(프로젝트 리드) 오 씨, 네 명입니다. 착수 회의에서 누군가 말합니다. "네 명이니까 그냥 4등분하죠. 계산도 편하고 서운한 사람도 없고요."

모두 고개를 끄덕입니다. 아직 아무도 일하지 않았기 때문에 그날은 그것이 가장 공정해 보입니다. 두 달 뒤, 김 씨는 스무 날 넘게 코드에 썼고 윤 대표는 사흘을 썼습니다. 두 사람이 같은 돈을 받습니다. 김 씨는 정산표를 보고 조용히 계산합니다. "혼자 외주로 받았으면 얼마였지."

반대편에는 윤 대표가 있습니다. 이 고객은 윤 대표가 3년 동안 관계를 쌓은 사람이고, 그 관계가 없었으면 3천만원 자체가 없었습니다. 4등분에서 그 3년은 0원입니다. 윤 대표도 계산합니다. "다음 고객은 커뮤니티 밖에서 하는 게 낫겠다." 서운한 사람이 없도록 고른 방식이 가장 중요한 두 사람을 동시에 잃습니다.

왜 1/n은 협력을 무너뜨리는가

공평(Equal)은 모두에게 같은 것을 주는 것입니다. 공정(Fair)은 각자에게 마땅한 것을 주는 것입니다. 기여가 같지 않은데 몫이 같으면, 그것은 공평하지만 공정하지 않습니다.

1/n이 매력적인 이유는 계산도 평가도 필요 없기 때문입니다. 다시 말해 1/n은 배분 방식이 아니라 평가를 회피하는 방식입니다. 그러나 재지 않는다고 기여의 차이가 사라지지는 않습니다. 차이는 정산표 대신 각자의 마음에 기록되고, 다음 프로젝트에서 청구됩니다.

1/n이 협력을 무너뜨리는 경로는 세 가지입니다.

첫째, 가장 많이 기여한 사람이 먼저 떠납니다. 24일 일한 사람과 3일 일한 사람이 같은 몫을 받으면, 24일 일한 사람에게 커뮤니티 프로젝트는 외주보다 못한 조건이 됩니다. 실력 있는 사람부터 빠져나가는 조직은 오래가지 못합니다.

둘째, 시간 밖의 기여가 0이 됩니다. 고객을 가져온 사람, 계약서에 이름을 걸고 하자보수를 떠안은 사람, GPU를 무상으로 댄 사람의 기여는 시간으로 보이지 않습니다. 1/n은 이들을 "일은 안 하고 몫만 가져가는 사람"으로 보이게 만듭니다. 다음 프로젝트에는 고객도 계약주체도 서버도 없습니다.

셋째, 최소 기여가 최적 전략이 됩니다. 몫이 정해져 있으면 합리적인 개인은 투입을 줄이고 남들이 더 하기를 기다립니다. 모두가 그렇게 생각하면 프로젝트는 품질을 잃고, 품질을 잃은 프로젝트는 후속 계약을 잃습니다.

AI 시대에는 이 문제가 더 날카로워집니다. 실행 비용이 낮아진 만큼 참여자 사이의 격차는 시간이 아니라 판단·관계·책임에서 벌어집니다. 코드가 싸질수록 "누가 이 고객을 데려왔는가", "누가 품질을 책임졌는가"의 값이 비싸집니다. 1/n은 바로 그 비싼 것들을 세지 않는 방식입니다.

우리의 철학: 공평이 아니라 공정

한국인공지능커뮤니티는 함께 만든 가치를 실제 기여에 따라 공정하게 나눕니다. 똑같이 나누지 않고, 힘센 사람이 정하지 않고, 기여를 세어서 나눕니다.

프로토콜 조직(Protocol Organization)의 관점에서 이것은 도덕이 아니라 설계의 문제입니다. 위계 조직은 급여로, 시장은 계약 가격으로 몫을 미리 고정합니다. Project Cell(프로젝트 셀)은 필요할 때 결합하고 끝나면 해체되므로 매번 새로운 조합이 만납니다. 고정된 몫이 없으니 매번 기여를 세는 규약이 있어야 하고, 규약이 없으면 Cell은 결합할 때마다 협상부터 다시 시작해야 합니다.

공정한 배분은 세 가지 조건 위에 섭니다. 사전에 합의된 기준: 무엇을 기여로 셀지, 범주별로 얼마나 무겁게 볼지를 시작 전에 정합니다. 나중에 정해지는 기준은 나중에 힘센 사람의 것입니다. 기록된 근거: 기여는 기억이 아니라 제19장의 주간 기록으로 셉니다. 기여한 사람을 잊지 않는다는 원칙은 여기서 숫자가 됩니다. 검증 가능한 절차: 한 사람이 평가하지 않습니다. 자기·동료·Lead 평가를 정해진 비율로 합산하고, 결과를 전원이 같은 표로 봅니다.

세 조건이 갖춰지면 배분은 협상이 아니라 계산이 됩니다. 계산은 감정을 줄이고, 감정이 줄면 같은 사람들이 다시 만납니다. 신뢰는 말이 아니라 행동으로 쌓이고, 정산표는 가장 명확한 행동입니다.

분명히 해 둘 것이 있습니다. 공정은 "많이 일한 사람이 많이 받는다"가 아닙니다. 그것은 시간만 세는 방식이고 제20장에서 다룬 또 하나의 실패입니다. 공정은 두 층입니다. 일한 것은 Work Compensation(수행 대가)으로 시장 단가만큼 먼저 받고, 함께 만들었기 때문에 생긴 잉여가치는 Contribution Matrix(기여도 평가표)의 7개 범주로 나눕니다. 시간은 첫 층에서, 시간 밖의 기여는 둘째 층에서 셉니다.

운영원칙: 공정한 배분의 절차

아래 숫자는 커뮤니티의 기본값(Default)이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

절차는 네 단계입니다.

1. 범주 가중치를 먼저 정합니다. 사람이 아니라 범주부터 봅니다. 영업이 어려운 고객이면 Origination·Sales가 무겁고, 제작 품질이 결과를 좌우하면 Execution·Knowledge가 무겁습니다. "누구를 얼마나 줄까"가 아니라 "이 프로젝트에서 무엇이 중요한가"부터 이야기하게 됩니다.
2. 범주마다 전원의 몫을 적습니다. 각 참여자는 범주별로 전원에 대한 배분안(합 100%)을 제출합니다. 자기 몫을 올리면 누군가의 몫이 내려간다는 것이 보입니다.
3. 합산하고 정규화합니다. 자기·동료·Lead 평가를 기본 비율로 합산해 범주별 100%로 맞춘 뒤, 가중치를 곱해 개인별 총 비율을 구합니다.
4. 정산표에 옮기고 검산합니다. 직접비용 + 커뮤니티 기여분 + 최종 수령액 합계 = 매출. 맞지 않으면 두 번 센 것이 있거나 빠진 것이 있습니다.

같은 것을 두 번 세지 않는 것이 핵심 규율입니다. Work Compensation으로 받은 20일은 Execution에서 다시 세지 않습니다. Execution은 유급 수행을 넘어선 부분만 봅니다. 두 번 세는 순간 다른 누군가의 몫이 그만큼 사라집니다.

기여도 평가의 흔한 편향과 방지책

절차가 있어도 평가는 사람이 합니다. 편향을 없앨 수는 없지만, 알고 있으면 줄일 수 있습니다.

공통된 방지책은 두 가지입니다. 동시에 제출하고, 기억을 기록으로 대체합니다. 순서대로 말하면 첫 발언이 기준이 되고, 기억으로 다투면 목소리가 기준이 됩니다. 자기평가와 동료평가 평균의 차이가 20%포인트를 넘으면 그 범주에 대해 반드시 대화합니다. 이것은 징계가 아니라 신호입니다. 누군가의 기여가 보이지 않았거나 누군가의 기대가 현실과 달랐다는 뜻이고, 둘 다 대화로 풀 수 있습니다.

배분에 이견이 있을 때

대화로 합의되지 않는 경우가 있습니다. 자세한 내용은 제26장에서 다루고, 여기서는 배분에 특화된 순서만 적습니다.

① 당사자 대화 (20%p 이상 차이 나는 범주에 대해)
② Project Lead 조정안 (Lead 본인 몫이 쟁점이면 다른 참여자가 조정)
③ 윤리·분쟁위원회 회부
④ 외부 중재

• Work Compensation은 먼저 지급합니다. 다투는 것은 Value Sharing(가치 배분)이지 수행 대가가 아닙니다. 배분에 이견이 있다고 일한 대가를 볼모로 잡지 않습니다.
• 단체방으로 가져가지 않습니다. 배분 분쟁을 공개 채널에서 성토하는 것은 여론재판이며 제11장에서 다룬 신뢰를 깨는 행동입니다.
• 이견은 감점이 아닙니다. Trust Capital(신뢰 자산)에 기록되는 것은 "이견이 있었다"가 아니라 "절차를 따랐는가"입니다. 절차를 거부하거나 기록을 숨긴 경우가 감점입니다. 실패에는 관대하되 부정직에는 엄격합니다.

Case 1: 3천만원 챗봇 PoC, 네 사람

가상의 사례입니다. 장 첫머리의 프로젝트를 Charter부터 다시 설계합니다.

상황. 계약금 3천만원(부가세 제외), 기간 두 달. 윤 대표는 Originator이자 자기 회사 명의로 계약한 Contracting Party(계약주체), 김 씨는 검색·응답 파이프라인, 서 씨는 화면과 시스템 연동, 오 씨는 Project Lead. "4등분하죠"는 오 씨가 막았습니다. "Work Compensation부터 정합시다. 나누는 건 그 다음입니다."

Charter. Work Compensation은 김 씨 20일 × 35만원, 서 씨 12일 × 35만원, 오 씨 10일 × 30만원, 윤 대표(요구사항 정리·고객 미팅) 3일 × 30만원. 김 씨의 개인 개발 서버는 무상 제공, Capital & Infra로 인정. 고객 확보가 어려운 프로젝트라 가중치는 Origination 25, Sales 15, Execution 20, Leadership & Risk 20, Capital & Infra 5, Network 5, Knowledge 10.

갈등. 7주 차에 김 씨가 말했습니다. "고객 데이터가 지저분해서 20일이 아니라 24일 썼습니다." 주간 기록에 있었습니다. 같은 기록에 오 씨가 검수 담당자 교체로 검수 기준을 다시 협의한 이틀과, 윤 대표가 고객사 대표에게 연락해 잔금 일정을 확정한 일도 있었습니다. 각각 Execution, Leadership & Risk, Sales로 반영했습니다.

정산.

검산: 1,500,000 + 670,000 + 27,830,000 = 30,000,000. 일치합니다.

1/n이었다면. 직접비용을 뺀 2,850만원을 4등분하면 각자 712만 5천원입니다. 김 씨는 305만 7,500원이 줄고, 서 씨는 101만 5,500원, 윤 대표는 113만 3천원, 오 씨는 157만 9천원이 늡니다. 세 명이 이득이고 한 명이 손해지만, 손해 본 한 명이 24일을 일한 사람입니다. 김 씨가 외주로 같은 일을 했으면 840만원이었고, 1/n은 그보다 적습니다. 김 씨는 다음 프로젝트에 오지 않거나, 오더라도 12일만큼만 일합니다. 윤 대표는 겉으로 이득이지만 3년의 관계가 "3일 일한 사람"으로만 계산되는 구조에 다음 고객을 가져올 이유가 없습니다.

결과. 정산 회의는 35분에 끝났습니다. 논의한 것은 착수 시 예상과 달라진 세 가지뿐이었습니다. 김 씨는 가장 많이 받았고 모두가 이유를 이해했습니다. 윤 대표는 같은 고객의 후속 프로젝트를 커뮤니티 안에서 다시 열었습니다.

Case 2: 1억원 브랜드 AI 광고 캠페인, 여섯 사람

가상의 사례입니다. 규모가 커지고 사람이 늘면 1/n의 왜곡도 커집니다.

상황. 소비재 브랜드의 AI 광고 캠페인. 메인 영상, 채널별 숏폼 변형, 세그먼트별 개인화 버전까지 계약금 1억원(부가세 제외), 기간 석 달. 참여자는 브랜드 임원과 오래 일해 온 마케터 송 씨(Originator, 캠페인 기획), 크리에이터 임 씨(메인 영상), 크리에이터 조 씨(숏폼·이미지 변형), 개발자 배 씨(개인화 변형 자동 생성 파이프라인), 연구자 문 박사(브랜드 톤 유지를 위한 모델 조정과 품질 평가), Project Lead이자 Contracting Party인 노 대표입니다.

Charter. Work Compensation은 임 씨 25일 × 40만원, 조 씨 20일 × 35만원, 배 씨 20일 × 40만원, 문 박사 10일 × 45만원, 노 대표 15일 × 35만원, 송 씨 15일 × 35만원. 배 씨의 개인 GPU 워크스테이션은 무상 제공, Capital & Infra로 인정. 제작 품질과 브랜드 톤 방법론이 중요해 가중치는 Origination 20, Sales 15, Execution 25, Leadership & Risk 15, Capital & Infra 5, Network 5, Knowledge 15.

갈등. 종료 평가에서 조 씨의 자기평가와 동료평가가 Execution에서 25%포인트 차이가 났습니다. 조 씨는 마지막 3주 동안 변형 40개를 만들며 가장 늦게까지 일했고 그 기억이 선명했습니다. 동료들은 40개의 대부분이 계약 범위 안이며 Work Compensation으로 지급된 것이라고 보았습니다. 마지막에 일한 사람의 편향이었습니다. 중간 평가 기록을 나란히 놓고 보니 범위 밖 기여는 고객이 추가 요청한 세로형 버전 6개였고, 조 씨는 자기평가를 조정했습니다.

정산.

검산: 10,000,000 + 2,500,000 + 87,500,000 = 100,000,000. 일치합니다.

1/n이었다면. 마지막 열이 1/n입니다. 손해 보는 두 사람은 1억원짜리 계약을 존재하게 만든 송 씨(−450만원)와 가장 많은 날을 제작에 쓴 임 씨(−260만원)입니다. 프로젝트에 가장 결정적인 두 사람이 가장 큰 손해를 봅니다. 가장 큰 이득을 보는 문 박사(+527만 5천원)는 10일을 투입했습니다. 문 박사가 나쁜 사람이어서가 아니라 1/n이 그렇게 설계되어 있을 뿐입니다. Work Compensation을 먼저 주고 잉여가치만 6등분하는 절충안도 송 씨의 몫을 1,425만원에서 약 792만원으로 줄입니다. 첫 층을 바로잡아도 둘째 층을 똑같이 나누면 시간 밖의 기여는 여전히 세지지 않습니다.

결과. 송 씨가 가장 많이 받았습니다. 임 씨보다 적은 날을 일했지만 그 고객이 없었으면 여섯 명 중 누구도 이 프로젝트에 없었습니다. 임 씨는 25일치 시장 단가 1천만원을 먼저 받았으므로 송 씨의 몫이 자기 노동을 깎아서 나온 것이 아님을 알았습니다. 문 박사의 브랜드 톤 평가 방법론은 커뮤니티에 비독점 라이선스로 공개됐고, 다음 캠페인이 이를 쓰면 Knowledge 기여자로 기록됩니다.

두 정산표의 공통점은 둘입니다. 가장 많이 일한 사람은 첫 층에서 이미 보상받았기 때문에 둘째 층에서 Originator가 큰 몫을 가져가도 노동이 깎이지 않습니다. 그리고 1/n에서 손해 보는 사람은 늘 고객을 가져온 사람과 가장 많이 만든 사람, 조직이 가장 잃어서는 안 되는 두 유형입니다. 프로젝트 전체의 성공을 개인의 단기이익보다 우선한다는 원칙은 이렇게 정산표로 측정됩니다.

Remember

• 공평(Equal)과 공정(Fair)은 다릅니다. 기여가 다른데 몫이 같으면 공평하지만 공정하지 않습니다. 1/n은 배분 방식이 아니라 평가를 회피하는 방식이며, 커뮤니티의 기본값이 아닙니다.
• 1/n에서 손해 보는 사람은 고객을 가져온 사람과 가장 많이 만든 사람입니다. 두 유형이 떠나면 Project Cell에는 고객도 제작자도 남지 않습니다.
• 공정한 배분은 사전 합의된 범주 가중치, 기록된 근거, 자기·동료·Lead 평가의 합산 위에서 계산이 됩니다. 계산이 되면 정산 회의는 협상이 아니라 검증이 됩니다.
• 편향은 동시에 제출하고, 기억 대신 기록을 보고, Lead 본인 몫에서 Lead 평가를 빼는 것으로 줄입니다. 20%포인트 이상 차이는 대화의 신호입니다.
• 이견이 있어도 Work Compensation은 먼저 지급합니다. 절차는 당사자 대화, Lead 조정, 윤리·분쟁위원회, 외부 중재 순이며, 단체방으로 가져가지 않습니다.

"똑같이 나누면 가장 중요한 사람부터 떠나고, 공정하게 나누면 가장 중요한 사람부터 돌아온다."

개정 메모: 현재는 사업협동조합이 공개 커뮤니티 사이트와 회원사 공동사업을 운영하는 구조를 추진합니다. 연구소는 독립적 기술 협력기관이며, ‘협회 회장’과 아래의 6층 구조는 채택된 조직도가 아닙니다. 법정 기관·정관·프로젝트 계약의 권한을 구분해 다시 설계합니다.

회사도 아니고 시장도 아니고 채팅방도 아닌 조직은 누가, 무엇을, 어디까지 결정하는가. 이 장은 여섯 개의 층을 설명하고, 그것이 왜 위계가 아니라 기능의 분리인지를 밝힙니다.

누가 결정합니까

가상의 장면에서 시작하겠습니다. Builder Circle의 개발자 김 씨가 가입 석 달 만에 처음 Project Cell(프로젝트 셀)에 참여했습니다. 첫 회의에서 Project Lead(프로젝트 리드)가 보상 구조를 설명하는데, 김 씨는 문득 궁금해집니다. "이 규칙은 누가 정한 것입니까. Circle Leader(서클 리더)는 제 상사입니까. 협회 회장은 이 프로젝트에 관여합니까."

전통 기업이라면 조직도의 위에 있는 사람이 결정합니다. 오픈채팅방이라면 아무도 결정하지 않습니다. 한국인공지능커뮤니티는 둘 다 아니므로 조금 긴 답이 필요합니다. 결론부터 말하면, 이 조직에는 위아래가 아니라 층(layer) 이 있습니다. 각 층은 서로 다른 일을 하고 서로 다른 권한을 가지며, 서로를 명령하지 않습니다. 김 씨의 Project Lead는 실행을 결정하지만 김 씨의 몫을 혼자 바꿀 수 없습니다. Circle Leader는 김 씨의 상사가 아닙니다. 협회 회장이 이 프로젝트에 참여하려면 다른 회원과 같은 절차를 밟아야 합니다.

왜 구조가 문제인가

구조가 없는 조직과 구조만 있는 조직, 둘 다 실패합니다.

구조가 없는 커뮤니티는 돈이 걸린 프로젝트가 생기는 순간 문제가 드러납니다. 누가 참여자를 정하는지, 분쟁이 생기면 누가 판단하는지 아무도 답할 수 없습니다. 결국 목소리가 크거나 먼저 온 사람이 사실상의 권력을 갖고, 그 권력은 기록되지 않았기 때문에 견제되지도 않습니다. 구조가 없다는 것은 권력이 없다는 뜻이 아니라 보이지 않는 권력이 있다는 뜻입니다.

구조만 있는 협회는 반대의 문제를 겪습니다. 회장, 부회장, 이사, 분과위원장까지 직함은 완비되어 있는데 프로젝트는 일어나지 않습니다. 총회는 안건보다 자리 배정에 오래 걸리고, 새로 온 실력자는 직함이 없다는 이유로 발언권을 얻지 못합니다. 이런 조직에서 구조는 실행을 돕는 도구가 아니라 실행을 대체하는 장식입니다.

AI 시대는 이 문제를 더 날카롭게 만듭니다. 실행 비용이 낮아져 좋은 팀은 몇 주 만에 결과를 냅니다. 그 속도를 구조가 따라가지 못하면 사람들은 조직 밖에서 일합니다. 반대로 구조가 없으면 빠른 실행이 빠른 분쟁으로 바뀝니다. 우리에게 필요한 것은 실행을 막지 않으면서 신뢰를 보호하는 최소한의 구조입니다.

우리의 철학: 위계가 아니라 층위

프로토콜 조직(Protocol Organization)은 사람을 고용이 아니라 공유된 규약과 기록된 신뢰로 묶습니다. 이런 조직의 구조는 명령 계통이 아니라 기능의 분리로 그려야 합니다. 누가 누구 위에 있는가가 아니라, 어떤 일이 어느 층에서 일어나고 어떤 권한이 어느 층에 머무는가를 정하는 것입니다.

전통 기업의 조직도는 삼각형입니다. 위로 갈수록 권한과 정보와 보상이 집중되고, 명령은 한 방향으로 흐릅니다. 우리의 구조는 겹쳐진 층입니다. Association(협회)은 법적 기반과 규약을 제공하지만 개별 프로젝트의 팀 구성에 관여하지 않습니다. Council(운영위원회)은 규약을 관리하지만 Circle의 활동 주제를 지정하지 않습니다. Circle Leader는 실행 공동체를 이끌지만 회원에게 일을 시킬 수 없습니다. Project Lead는 실행을 결정하지만 참여자의 몫을 혼자 바꾸지 않습니다.

이 분리는 두 가지를 지킵니다. 첫째는 독립성입니다. 누구도 고용된 사람이 아니므로 누구도 명령받는 사람이 아닙니다. 둘째는 권력과 기회의 분리입니다. 운영 권한이 있는 층이 경제적 기회를 독점하기 시작하면 이 조직은 흔한 협회로 돌아갑니다. 이 주제는 제24장에서 따로 다룹니다.

여섯 개의 층

┌ ASSOCIATION ─ 운영 주체 · 법적 기반 · 규약의 보관자
│   (사단법인 한국인공지능연구소가 법적·신뢰 기반 제공)
├ COUNCIL ────── 운영위원회 · 규약 관리 · 공동 자원 배분
│   └─ 윤리·분쟁위원회 (산하이지만 판단은 독립)
├ CIRCLE ─────── 실행 공동체 · Research / Builder / Creator / Founder / Expert
├ PROJECT CELL ─ 경제 단위 · 만들어지고 해체되는 Virtual Company
├ MEMBER ─────── Capability Node · 모든 층의 재료이자 주인
└ PARTNER ────── 앵커 조직 · 기업 · 대학 · 연구기관 · 투자사

  위층은 아래층을 지휘하지 않습니다.

Member가 아래쪽에 있는 것은 지위가 낮아서가 아닙니다. 모든 층은 Member로 이루어져 있고, Member가 없으면 위의 모든 층이 비어 있기 때문입니다. Partner는 구조를 받치는 바깥 기반이지 구조를 지배하는 꼭대기가 아닙니다.

숫자는 커뮤니티의 기본값(Default)이며 헌장 개정 절차로 조정할 수 있습니다. 임기를 둔 이유는 단순합니다. 임기가 없는 자리는 자리가 아니라 소유가 됩니다.

구조를 이해하는 가장 빠른 방법은 각 층이 하지 않는 일을 보는 것입니다. Association은 Project Cell의 팀 구성과 보상 배분에 관여하지 않습니다. Council은 프로젝트를 만들거나 배정하지 않습니다. 기회는 플랫폼의 Opportunity라는 공개 채널로 흐르며, Council 위원도 그 채널로만 참여합니다. Circle은 부서가 아니고 Circle Leader는 부장이 아닙니다. Circle 안에서 Project Cell이 만들어지는 것은 자연스럽지만, 그 Lead가 Circle Leader일 필요는 없습니다.

윤리·분쟁위원회는 왜 독립적인가

윤리·분쟁위원회(Ethics & Dispute Committee)는 Council 산하에 있지만 판단에서는 독립적입니다. 산하에 두는 이유는 위원회가 허공에 떠 있을 수 없기 때문입니다. 위원을 누군가는 위촉해야 하고, 결정을 누군가는 집행해야 합니다. 독립적이어야 하는 이유는 더 중요합니다. 분쟁의 상당수는 Council 위원이나 Circle Leader가 당사자인 사건입니다. 권한이 있는 사람이 자기 사건을 심판하는 조직은 신뢰를 잃습니다.

그래서 세 가지 장치를 둡니다. 첫째, 위원 임기(기본값 2년)를 Council 임기와 어긋나게 배치하여 한 Council이 위원회 전체를 구성하지 못하게 합니다. 둘째, 위원회의 판단을 Council이 뒤집을 수 없습니다. 재심은 위원회 자체 절차로만 가능하며, 그 이후는 외부 중재입니다. 셋째, 사건에 관련된 Council 위원이나 Circle Leader는 위원회에 어떤 의견도 전달하지 않습니다. 회피(Recusal)는 판단하는 쪽뿐 아니라 영향을 미칠 수 있는 쪽에도 적용됩니다. 위원회는 법률·세무 전문가만으로 채우지 않습니다. 기술 분쟁에는 기술을 아는 사람이 필요합니다. 절차는 제26장에서 다룹니다.

앵커 조직: 먼저 온 동등한 파트너

Partner 층에는 다섯 개의 앵커 조직이 있습니다. 앵커라는 말은 배를 고정하는 닻에서 왔습니다. 커뮤니티가 초기에 표류하지 않도록 기반을 제공하는 조직이라는 뜻입니다.

원칙은 하나입니다. 앵커는 먼저 온 동등한 파트너일 뿐이며, 커뮤니티를 특정 회사의 외주 인력풀로 만들지 않습니다. 이 원칙이 무너지는 순간 커뮤니티는 다섯 회사의 채용 채널이 되고, 회원은 값싼 노동력이 됩니다. 사람을 소모품처럼 다루지 않는다는 약속은 앵커 조직에게 가장 먼저 적용됩니다.

구체적으로 이렇게 작동합니다. H3Lab이 GPU를 제공했다고 해서 H3Lab의 프로젝트에 회원이 우선 배정되지 않습니다. H3Lab도 다른 파트너와 똑같이 Opportunity에 올리고 똑같은 기준으로 팀이 구성됩니다. U09가 기업 고객을 연결했다면 그 연결은 Originator(소개자) 기여로 인정받되, 고객이 U09의 소유가 되지는 않습니다. AI TEST 인증이 없어도 다른 경로로 Verified가 될 수 있습니다. 앵커 조직 소속 위원은 Council의 과반을 넘지 않고, 앵커 조직이 당사자인 안건에서 회피하며, 앵커와의 협약은 회원에게 공개됩니다.

새로운 파트너는 어떻게 들어오는가

다섯이라는 숫자는 출발점일 뿐입니다. 향후 기업, 대학, 연구기관, 투자사가 동등한 생태계 파트너로 참여합니다. 파트너는 협약(Partnership Agreement)을 맺고, 제공할 자원과 기대하는 것을 명시합니다. 협약에는 반드시 두 조항이 들어갑니다. 회원을 외주 인력풀로 취급하지 않는다는 조항과, 당사자가 관련된 안건에서 이해상충을 신고한다는 조항입니다.

기업은 실제 문제와 예산을 가져와 Contracting Party(계약주체)가 됩니다. 대학과 연구기관은 연구 문제와 검증 환경을 가져와 Research Circle과 공동연구를 합니다. 투자사는 자본을 가져와 AI 10K Initiative의 Stage 2 이상 회원 기업에 접근하되, 접근은 공개 채널을 통하며 특정 회원 기업의 정보를 우선 열람하지 않습니다. 파트너의 기준은 크기나 명성이 아니라 회원에게 실제로 무엇을 열어 주는가입니다. 파트너 사이에도 서열은 없습니다.

운영원칙

숫자는 모두 기본값이며 헌장 개정 절차로 조정할 수 있습니다.

1. 층은 서로를 지휘하지 않습니다. 예외는 헌장 위반에 대한 구제 절차뿐입니다.
2. 모든 운영 직위에는 임기가 있습니다. Council 위원 2년(연임 1회), Circle Leader 1년(연임 1회), 윤리·분쟁위원 2년(Council과 어긋나게 배치).
3. 운영 직위는 경제적 기회를 만들지 않습니다. Council 위원, Circle Leader, 앵커 조직 소속이라는 이유로 프로젝트에 우선 배정되지 않습니다(제24장 참조).
4. 어느 한 조직도 Council의 과반을 넘지 않습니다. 앵커 조직을 포함한 모든 파트너에 적용됩니다.
5. 회의록과 협약은 회원에게 공개합니다. Council 회의록, 파트너 협약의 요지, Community Share 집행 내역은 Community 등급으로 공개합니다.
6. 회원은 구조를 바꿀 수 있습니다. 활동 회원 10% 이상의 연서로 헌장 개정을 발의하고, Council 심의와 회원 투표를 거쳐 Association이 승인합니다.
7. 윤리·분쟁위원회의 판단은 Council이 뒤집지 않습니다.

Case: 파트너가 자기 팀을 원할 때

가상의 사례입니다. 중견 제조기업이 새 파트너로 참여해 첫 프로젝트로 설비 이상 탐지 PoC를 제안했습니다. 예산은 8천만원이었습니다. 기업 측 담당자 정 이사는 협약 과정에서 Council 위원 몇 사람과 친해졌고, Builder Circle의 Circle Leader인 개발자 오 씨와도 여러 차례 만났습니다.

정 이사는 Council 위원 한 사람에게 요청했습니다. "오 리더와 오 리더가 추천하는 세 사람으로 팀을 꾸리고 싶습니다. Opportunity에 올리는 절차는 생략해 주십시오. 빨리 시작하고 싶습니다."

위원은 요청을 그대로 받지 않았습니다. 첫째, Council은 팀을 구성하는 층이 아닙니다. 그 권한은 Council에 없습니다. 둘째, Circle Leader가 자기 Circle의 회원을 직접 골라 파트너 프로젝트에 넣는 것은 권한 밖이며 이해상충 신고 대상입니다. 셋째, 절차 생략은 이 프로젝트 하나를 빠르게 하는 대신 다음 열 개의 프로젝트에서 "누구는 절차를 건너뛴다"는 불신을 만듭니다.

대신 위원은 다른 길을 제안했습니다. 정 이사가 원하는 것은 사실 "빠른 착수"이지 "특정 인물"이 아니었습니다. Opportunity에 올리되 지원 기간을 기본값보다 짧게(5일) 잡고, 요구 역량을 구체적으로 적었습니다. 오 씨는 Circle Leader로서 Opportunity를 Circle에 알리는 역할만 했고, 자신도 참여를 원했기 때문에 이해상충 신고서(Appendix G)를 내고 팀 구성 심사에서 빠졌습니다.

팀은 여드레 만에 구성되었습니다. 오 씨는 지원자 중 한 사람으로 평가받아 참여했고, 추천하려던 세 사람 중 두 사람이 자기 역량으로 선발되었습니다. 나머지 한 자리는 오 씨가 알지 못했던 신규회원 연구원 정 박사에게 갔습니다. 설비 진동 데이터를 다뤄 본 경험이 있었는데, 오 씨의 인맥 안에는 없던 사람입니다. 정 이사는 나중에 말했습니다. "제가 원했던 팀보다 나은 팀이 나왔습니다."

층이 분리되어 있었기 때문에 Council 위원은 "그건 제 권한이 아닙니다"라고 말할 수 있었고, 그 말이 파트너와의 관계를 해치지 않았습니다. 권한의 경계가 분명하면 거절도 쉬워집니다.

Remember

• 한국인공지능커뮤니티에는 위아래가 아니라 여섯 개의 층이 있습니다. 각 층은 자기 층의 결정을 하고, 다른 층을 지휘하지 않습니다.
• 사단법인 한국인공지능연구소는 법적·신뢰 기반을 제공하는 첫 번째 파트너이지 커뮤니티의 주인이 아닙니다. 앵커 조직은 먼저 온 동등한 파트너일 뿐이며, 커뮤니티를 특정 회사의 외주 인력풀로 만들지 않습니다.
• 모든 운영 직위에는 임기가 있고, 운영 직위는 경제적 기회를 만들지 않습니다.
• 윤리·분쟁위원회는 Council 산하에 있지만 판단에서 독립적입니다. 권한이 있는 사람이 자기 사건을 심판하지 않습니다.
• 기업, 대학, 연구기관, 투자사는 동등한 파트너로 참여합니다. 기준은 크기가 아니라 회원에게 무엇을 열어 주는가입니다.

"구조는 사람을 줄 세우기 위해 있는 것이 아니라, 권한의 경계를 분명히 하여 실행을 자유롭게 하기 위해 있습니다."

운영 권한을 가진 사람이 사업기회를 먼저 가져가면 어떻게 되는가. 협회가 무너지는 가장 흔한 길과, 그 길을 피하기 위한 원칙과 절차를 밝힙니다. Governance Power ≠ Economic Opportunity.

리더가 좋은 프로젝트를 먼저 가져가도 됩니까

가상의 장면입니다. Creator Circle의 Circle Leader(서클 리더)인 한 대표는 AI 영상 제작 회사를 운영합니다. 회사에 브랜드 캠페인 의뢰가 들어왔고, 예산은 6천만원이었습니다. 한 대표는 Circle 안에서 누가 무엇을 잘하는지 가장 잘 아는 사람입니다. 그래서 단체방에 이렇게 올렸습니다. "좋은 프로젝트가 있습니다. 제가 아는 세 분과 함께하고 싶습니다. 다음 주에 시작합니다."

이 장면에는 나쁜 의도가 없습니다. 한 대표는 회원에게 일을 주려고 했고, 그 세 사람은 실력이 있습니다. 그런데 방을 보고 있던 다른 회원들은 다른 것을 느낍니다. "리더가 아는 사람만 기회를 얻는구나." "나는 리더와 친하지 않으니 이 Circle에서는 프로젝트를 못 하겠구나." 아무도 말하지 않지만 모두가 계산을 시작합니다.

리더가 좋은 프로젝트를 먼저 가져가도 되는가. 우리의 답은 "먼저 가져갈 수는 없지만, 같은 절차를 거쳐 참여할 수는 있다"입니다. 이 장은 그 차이를 설명합니다.

왜 이것이 문제인가: 협회가 무너지는 전형적인 길

협회, 조합, 학회, 동문회 같은 조직이 무너지는 경로는 놀랄 만큼 비슷합니다. 누구나 한 번쯤 본 장면입니다.

첫 단계는 선의입니다. 초기에 헌신한 사람들이 임원이 됩니다. 그들은 실제로 가장 많이 기여했고 가장 많은 관계를 갖고 있습니다. 기회가 들어오면 자연스럽게 그들에게 먼저 연락이 갑니다. 아무도 문제라고 생각하지 않습니다. "가장 잘 아는 사람이 하는 것이 효율적"이기 때문입니다.

두 번째 단계는 정보의 비대칭입니다. 임원은 어떤 기업이 무엇을 찾는지, 어떤 예산이 어디에 있는지 먼저 알게 됩니다. 이 정보는 자리 때문에 얻은 것이지 기여 때문에 얻은 것이 아닙니다. 그러나 그 정보로 자기 회사가 먼저 움직입니다. 다른 회원이 알게 되었을 때 기회는 이미 배정되어 있습니다.

세 번째 단계는 구조의 고착입니다. 기회를 가진 사람이 다시 임원이 되고, 임원이 다시 기회를 가집니다. 심사하는 사람과 참여하는 사람이 같아집니다. 새로 온 실력자는 이 순환에 들어갈 방법이 없다는 것을 깨닫고 조용히 떠납니다. 어느 시점부터 조직은 회원의 조직이 아니라 임원의 사업 채널이 됩니다.

마지막 단계는 신뢰의 붕괴입니다. 문제를 제기하면 "헌신한 사람에게 이 정도는 당연하다"는 답이 돌아옵니다. 헌신은 사실이므로 반박하기 어렵습니다. 하지만 회원들은 이미 마음속으로 떠났습니다. 조직은 남지만 실행은 사라집니다.

AI 시대는 이 경로를 더 빠르게 만듭니다. 실행 비용이 낮아져 임원 한 사람이 회원 몇 사람만 붙이면 대기업급 결과를 냅니다. 그만큼 "누가 누구를 붙이는가"라는 배정 권한의 가치가 커졌습니다. 조직의 경쟁우위가 매칭의 정확도와 신뢰의 밀도라면, 매칭 권한이 사유화되는 순간 경쟁우위 자체가 사라집니다.

우리의 철학: Governance Power ≠ Economic Opportunity

프로토콜 조직(Protocol Organization)의 여섯 가지 설계 원리 중 다섯 번째가 권력과 기회의 분리입니다. 운영 권한을 가진 사람이 사업기회를 우선 가져가지 않는다는 원칙입니다.

앞의 네 가지 원리는 사람을 Capability Node(역량 노드)로 보고, 기여를 기록하고, 신뢰를 행동의 원장으로 쌓자는 것입니다. 모두 기회가 역량과 신뢰를 따라 흐른다는 전제 위에 서 있습니다. 기회가 직위를 따라 흐르기 시작하면 이 전제가 무너집니다. 기여를 기록할 이유도, 신뢰를 쌓을 이유도 없어집니다. 직위를 얻는 것이 더 빠르기 때문입니다. 권력과 기회의 분리는 앞의 원리들을 지키는 울타리입니다.

여기서 중요한 구분이 있습니다. 우리는 운영 권한을 가진 사람에게 경제활동을 하지 말라고 하지 않습니다. 회원은 각자의 회사와 연구실을 유지하고, Circle Leader도 Council(운영위원회) 위원도 자기 사업이 있습니다. 그것이 독립성과 결합성이라는 첫 번째 원리입니다. 우리가 분리하려는 것은 운영 권한과 우선권입니다. 임원이라서 먼저 알고, 먼저 고르고, 심사를 면제받는 것을 막는 것입니다.

기여는 신뢰를 만들지만 영구적인 특권을 만들지 않습니다. Contribution creates Trust, not Permanent Privilege. 헌신은 Trust Capital로 기록되어 다음 프로젝트에서 선택받을 가능성을 높입니다. 그것으로 충분합니다. 헌신의 대가로 배정 권한을 갖는 것은 다른 이야기입니다. 전자는 신뢰이고 후자는 권력입니다.

이해상충의 유형

이해상충(Conflict of Interest)은 어떤 결정으로 자신이 이익이나 손해를 볼 수 있는 상황입니다. 이해상충 자체는 잘못이 아닙니다. 활동하는 사람이라면 누구나 만납니다. 잘못은 그것을 숨기고 결정에 관여하는 것입니다.

가장 흔한 것은 첫 번째와 네 번째입니다. 노골적인 부정보다 "좋은 사람에게 좋은 일을 주려는" 선의가 이해상충의 대부분을 만듭니다. 선의는 절차를 대신하지 못합니다.

회피(Recusal)의 원칙과 절차

회피(Recusal)는 이해가 걸린 사안에서 스스로 물러나는 것입니다. 논의·표결·심사·배정에 관여하지 않고, 관련 정보를 먼저 얻지 않는다는 뜻입니다. 제23장에서 보았듯이 회피는 판단하는 쪽뿐 아니라 영향을 미칠 수 있는 쪽에도 적용됩니다. 절차는 세 단계입니다.

1. 신고합니다. 이해가 걸렸다고 판단되는 즉시 Conflict of Interest Declaration(이해상충 신고서, Appendix G)을 냅니다. 기준은 하나입니다. "이 결정으로 내가 이익을 보거나 손해를 볼 수 있는가"에 "예"라면 신고합니다. 애매하면 신고합니다. 신고했는데 이해상충이 아니었던 경우는 아무 비용이 없지만, 신고하지 않았는데 이해상충이었던 경우는 부정직으로 기록됩니다.
2. 빠집니다. 기본값은 해당 사안의 논의·표결·심사·배정에서 전부 물러나는 것입니다. 부분 회피(정보는 열람하되 표결하지 않음 등)는 사유를 적고 Council이 확인합니다. 심사와 참여를 둘 다 원하면 하나를 고릅니다. 두 가지를 다 가질 수는 없습니다.
3. 기록을 남깁니다. 신고서는 Council(신고자가 Council 위원이면 본인을 제외한 위원)이 확인하고, 사안이 끝난 뒤에도 보관합니다. 기록 등급의 기본값은 Community입니다. 누가 어떤 사안에서 물러났는지 회원이 볼 수 있어야 회피가 실제로 작동합니다.

신고하고 물러난 사실은 Trust Capital에 긍정적으로 기록됩니다. 회피는 벌이 아니라 기여입니다. 자기 이해가 걸린 사안에서 물러나는 사람은 조직 전체의 신뢰를 지킨 사람이며, 그 행동은 잊히지 않습니다. 신뢰는 말이 아니라 행동으로 쌓습니다.

임원도 프로젝트에 참여할 수 있습니다

권력과 기회의 분리를 "임원은 프로젝트를 하지 말라"로 읽으면 안 됩니다. 그러면 실력 있는 사람이 운영 직위를 맡지 않게 되고, 운영은 실행과 멀어집니다. 임원도, Circle Leader도, 앵커 조직 소속 회원도 프로젝트에 참여할 수 있습니다. 조건은 세 가지입니다.

세 조건을 모두 만족하면 임원의 참여는 정당합니다. 하나라도 빠지면 결과가 좋아도 재검토 대상입니다.

임원이 자기 회사의 프로젝트에 회원을 초대하고 싶다면 방법은 하나입니다. Opportunity에 올리는 것입니다. 요구 역량, 기간, Work Compensation(수행 대가)의 기준, Value Sharing(가치 배분)의 유무를 적습니다. 그러면 임원의 회사는 Contracting Party(계약주체)가 되고, 임원 자신은 배정에서 빠집니다. 팀은 다른 회원이 심사하거나, Project Lead가 정해진 뒤 그 Lead가 구성합니다. 임원이 아는 사람이 선발될 수도 있습니다. 문제는 아는 사람만 지원할 수 있었던 경우입니다.

앵커 조직도 예외가 아닙니다

사단법인 한국인공지능연구소, H3Lab, U09, 한국인공지능아카데미, AI TEST는 커뮤니티의 초기 기반을 제공한 앵커 조직입니다. 기반을 제공했으므로 우선권이 있어야 한다는 생각은 자연스럽지만, 이 장의 원칙은 앵커 조직에 가장 먼저 적용됩니다. 앵커는 다른 회원보다 많은 것을 알고, 많은 것을 가지고 있으며, Council에 사람을 보냅니다. 이해상충이 생길 가능성이 구조적으로 가장 높은 자리입니다. 앵커가 자기 프로젝트에 회원을 우선 배정하기 시작하면 커뮤니티는 다섯 회사의 외주 인력풀이 됩니다. 회원이 값싼 노동력이 되는 순간 좋은 사람은 떠나고, 앵커가 얻고자 했던 것도 함께 사라집니다.

그래서 앵커 조직의 프로젝트도 Opportunity에 올라갑니다. GPU를 제공했다고 해서 H3Lab의 프로젝트에 회원이 우선 배정되지 않습니다. 기업 고객을 연결한 U09는 Originator(기회를 가져온 사람) 기여를 인정받되, 그 고객의 프로젝트 팀을 직접 정하지 않습니다. 아카데미의 교육 이수는 참여 조건이 아니고, AI TEST 인증은 Verified 검증 경로 중 하나일 뿐입니다. 앵커 조직 소속 Council 위원은 앵커의 이해가 걸린 안건에서 회피하고, 그 기록은 공개됩니다. 먼저 온 조직이 먼저 물러날 때 회원은 이 커뮤니티가 말한 대로 작동한다는 것을 믿게 됩니다.

운영원칙

숫자는 커뮤니티의 기본값(Default)이며 헌장 개정 절차로 조정할 수 있습니다.

1. 기회는 공개 채널로 흐릅니다. 커뮤니티를 통해 회원을 모으는 프로젝트는 플랫폼의 Opportunity에 게시합니다. 지원 기간 기본값은 7일이며, 긴급한 경우 3일까지 줄일 수 있되 사유를 적습니다.
2. 운영 직위는 우선권을 만들지 않습니다. Council 위원, 임원, Circle Leader, 윤리·분쟁위원, 앵커 조직 소속이라는 이유로 기회를 먼저 알거나 먼저 배정받지 않습니다.
3. 심사와 참여는 겸하지 않습니다. 팀 구성·배정에 관여한 사람은 그 프로젝트에 참여하지 않고, 참여하려는 사람은 심사에서 빠집니다.
4. 이해상충은 즉시 신고합니다. 애매하면 신고합니다. 신고서(Appendix G)는 Council이 확인하고 사안 종료 후에도 보관합니다.
5. 회피는 정보에도 적용됩니다. 물러난 사람은 해당 사안의 비공개 정보를 다른 회원보다 먼저 열람하지 않습니다.
6. 공동 자원은 공개 기준으로 배분합니다. Circle 예산·GPU·공간·Community Share의 배분 기준과 결과는 Community 등급으로 공개합니다.
7. 신고하지 않은 이해상충은 부정직입니다. 나중에 드러나면 해당 결정은 재검토 대상이 되고, 미신고 사실은 Trust Capital에 기록됩니다. 실패에는 관대하되 부정직에는 엄격합니다.
8. 반복되는 패턴은 Council이 살핍니다. 특정 임원이나 조직에 기회가 반복해서 모이면, 개별 사안에 문제가 없더라도 Council이 구조를 점검합니다.

Case: 자기 회사 프로젝트에 회원을 배정하려던 Circle Leader

가상의 사례입니다. 이 장의 첫 장면으로 돌아가겠습니다. Creator Circle의 Circle Leader 한 대표는 자기 회사에 들어온 6천만원짜리 브랜드 캠페인에 Circle 회원 세 사람을 붙이려고 단체방에 공지했습니다. 크리에이터 두 사람과 프롬프트 설계를 맡을 개발자 한 사람이었습니다.

한 시간 뒤, 소그룹 운영을 돕던 크리에이터 윤 씨가 따로 메시지를 보냈습니다. "이 프로젝트는 Opportunity에 올라가 있습니까. 리더가 직접 팀을 정하면 다른 회원들이 어떻게 볼지 걱정됩니다." 한 대표는 처음에는 이해하지 못했습니다. "일을 주려는 것인데 무엇이 문제입니까." 윤 씨는 이해상충 유형 표의 첫 줄과 네 번째 줄을 보여 주었습니다. 자기 회사 배정과 친분 배정. 한 대표는 잠시 뒤 답했습니다. "제가 하려던 것이 정확히 그것이군요."

한 대표는 그날 이해상충 신고서를 냈습니다. 직위는 Circle Leader, 이해관계 유형은 자기 회사, 회피 조치는 팀 구성 심사에서 전부 물러남. 참여 여부 항목에는 이렇게 적었습니다. "제 회사가 Contracting Party이므로 심사에 관여하지 않습니다. Circle Leader로서는 Opportunity를 Circle에 알리는 역할만 합니다." Council이 지정한 위원이 다음 날 확인 서명을 했습니다.

Opportunity에 조건을 적는 과정에서 한 가지가 더 드러났습니다. 한 대표가 처음 생각한 크리에이터의 Work Compensation은 시장 단가보다 낮았습니다. "커뮤니티 회원이니 조금 저렴하게"라는 생각이 있었던 것입니다. 조건은 수정되었습니다. 6천만원 중 직접비용 5백만원을 빼고 Work Compensation 3천5백만원을 시장 단가로 먼저 지급하며, 남은 잉여가치 2천만원에서 Community Share 5%인 1백만원을 제외한 1천9백만원을 Contribution Matrix에 따라 나누는 구조였습니다. 사람을 소모품처럼 다루지 않는다는 약속이 여기서도 지켜졌습니다.

팀 구성은 Circle의 Professional 단계 회원 두 사람이 맡았습니다. 지원자는 아홉 명이었습니다. 한 대표가 처음 생각했던 세 사람 중 두 사람이 자기 역량으로 선발되었고, 한 자리는 가입 두 달 된 신규회원 크리에이터 서 씨에게 갔습니다. 같은 업종의 포트폴리오가 있었는데, 한 대표가 몰랐던 사람입니다.

프로젝트는 예정대로 끝났습니다. 한 대표는 나중에 말했습니다. "제가 직접 팀을 정했다면 이 프로젝트 하나는 더 빨랐을 것입니다. 하지만 그다음부터 회원들이 저를 리더가 아니라 발주처로 봤을 것입니다." 신고서는 Community 등급으로 보관되었고, 회피한 사실은 Trust Capital에 기록되었습니다. 다음 임기에 한 대표는 다시 Circle Leader로 추천받았습니다.

Remember

• 협회가 무너지는 길은 선의에서 시작합니다. 임원이 먼저 알고, 먼저 고르고, 심사를 면제받는 순간 조직은 회원의 조직에서 임원의 사업 채널로 바뀝니다.
• 우리가 분리하는 것은 경제활동이 아니라 우선권입니다. 임원도 프로젝트에 참여할 수 있지만, 공개 채널·회피 절차·기록이라는 세 조건을 모두 만족해야 합니다.
• 이해상충은 잘못이 아닙니다. 신고하지 않는 것이 잘못입니다. 애매하면 신고하고, 신고했으면 물러나고, 물러났으면 기록합니다. 회피는 벌이 아니라 기여입니다.
• 앵커 조직은 이 원칙의 예외가 아니라 첫 번째 적용 대상입니다.
• 기회는 직위가 아니라 역량과 신뢰를 따라 흐릅니다. Contribution creates Trust, not Permanent Privilege.

"운영할 권한과 먼저 가져갈 권리는 다른 것입니다. 권력을 가진 사람이 기회 앞에서 한 걸음 물러설 때 조직은 비로소 모두의 것이 됩니다."

Circle은 채팅방이 아니라 결과물을 만드는 실행 공동체입니다. 이 장은 다섯 개의 Circle이 무엇을 만들고, 어떤 리듬으로 움직이며, 어떻게 Project Cell을 배출하는지를 답합니다.

질문에서 시작합니다

한 회원이 커뮤니티에 들어와 Builder Circle(빌더 서클)에 참여했다고 해 보겠습니다. 첫 주에는 흥미로운 링크가 하루에도 여러 개 올라옵니다. 새 모델 소식, 누군가 돌려 본 벤치마크 캡처, 에이전트 프레임워크에 대한 짧은 감상이 이어집니다. 석 달이 지나면 이 회원은 스스로에게 묻게 됩니다. "여기서 내가 실제로 만든 것이 무엇인가."

링크와 감상이 오가는 공간은 인터넷에 이미 넘칩니다. 우리가 울타리를 치고, 검증을 거쳐 사람을 모으고, 기여를 기록하는 이유는 대화를 더 잘하기 위해서가 아닙니다. 대화가 실행이 되고, 실행이 결과물이 되고, 결과물이 신뢰가 되게 하기 위해서입니다. 그래서 Circle은 다른 질문에서 시작합니다. "이번 분기에 우리 Circle이 세상에 내놓을 것은 무엇인가." 이 질문에 답이 없는 Circle은 아무리 활발해 보여도 채팅방입니다.

왜 대화는 결과물이 되지 못하는가

관심사로 모인 방이 결과물을 내지 못하는 데는 구조적인 이유가 있습니다. 첫째, 마감이 없습니다. 언제까지 무엇을 내놓겠다는 약속이 없으니 모든 논의는 "언젠가 해 보면 좋겠다"에서 멈춥니다. 둘째, 책임자가 없습니다. 아무나 발언할 수 있지만 아무도 마무리를 맡지 않습니다. 셋째, 기록이 없습니다. 좋은 통찰이 나와도 대화의 흐름 속에 묻히고, 다음 사람은 같은 이야기를 처음부터 다시 합니다.

AI 시대는 이 문제를 더 날카롭게 만듭니다. 새 모델과 도구가 매주 나오기 때문에 "따라가기"만으로도 하루가 갑니다. 정보를 소비하는 일이 곧 무언가를 하고 있다는 착각을 줍니다. 그러나 코드와 영상과 문서는 싸졌습니다. 비싸진 것은 실제로 해 본 사람의 판단, 그 판단을 검증한 기록, 함께 해 본 사람 사이의 신뢰입니다.

Circle은 그 비싼 것을 만드는 장치입니다. 다섯 명이 각자 새 모델을 써 보고 감상을 올리는 것과, 다섯 명이 같은 기준으로 비교 실험을 설계해 하나의 벤치마크 리포트를 내는 것은 완전히 다른 일입니다. 전자는 흘러가고 후자는 남습니다. 남은 것은 커뮤니티의 자산이 되고, 만든 사람들의 Trust Capital(행동으로 축적되는 신뢰의 기록)이 됩니다. 연구자에게는 논문 밖의 실제 데이터를, 개발자에게는 혼자 돌릴 수 없는 규모의 실험을, 크리에이터에게는 다음 프로젝트에서 바로 쓸 워크플로우를, 파운더에게는 사업 단계로 넘어가는 문턱을 주는 곳이 Circle입니다.

우리의 철학: Circle은 실행 공동체다

프로토콜 조직의 6층 구조에서 Circle은 Council(운영위원회)과 Project Cell(프로젝트 셀) 사이에 있습니다(제23장 참조). Council은 규약을 지키고, Project Cell은 계약과 정산이 걸린 경제활동을 합니다. Circle은 그 사이에서 두 가지 일을 합니다. 결과물을 만드는 것, 그리고 Project Cell이 태어날 토양을 만드는 것입니다.

Circle에서 사람들은 돈이 걸리기 전에 먼저 함께 일해 봅니다. 벤치마크 리포트를 같이 쓰면서 누가 약속을 지키는지, 누가 마감 앞에서 사라지는지, 누가 남의 기여를 자기 것처럼 말하는지가 드러납니다. 신뢰는 말이 아니라 행동으로 쌓습니다. Circle은 그 행동이 처음 기록되는 곳이며, 활동은 플랫폼에 Knowledge·Research·Technology·Event 등의 기여 유형으로 남습니다.

Circle은 위계가 아닙니다. Circle Leader(서클 리더)는 상사가 아니라 결과물의 마감을 책임지는 사람입니다. 시장도 아닙니다. Circle에서 만든 리포트와 워크플로우는 함께 만들고 함께 쓰는 공동 자산입니다. 채팅방도 아닙니다. 대화는 수단이고 결과물이 목적입니다. 그리고 회원을 값싼 노동력으로 쓰는 곳도 아닙니다. 결과물에는 참여자의 이름이 기여자로 남습니다. 기여한 사람을 잊지 않습니다. 특정 회원이나 앵커 조직의 상업 프로젝트에 Circle이 무상으로 동원되는 일이 생기면, 그것은 Project Cell로 전환해 Work Compensation(수행 대가)을 정해야 합니다(제20장 참조).

다섯 개의 Circle과 소그룹

Circle 안에는 주제별 소그룹이 있을 수 있습니다. Builder Circle 안의 LLM 소그룹과 Agent 소그룹, Creator Circle 안의 AI Video 소그룹이 그 예입니다. 소그룹은 하위 조직이 아니라 결과물 단위입니다. 세 사람 이상이 한 가지 결과물을 한 분기 안에 내겠다고 약속하면 소그룹이 되고, 결과물이 나오면 다음 주제로 옮기거나 해산합니다. 사람 수가 많다고, 관심이 높다고 소그룹이 되지 않습니다. 약속이 있어야 소그룹입니다.

운영 리듬

Circle은 리듬으로 움직입니다. 아래 형식은 커뮤니티의 기본값이며 Circle마다 조정할 수 있습니다.

분기 초  결과물 선언 ─▶ 소그룹 구성 ─▶ 중간 점검 ─▶ Demo Day ─▶ 분기 회고
         (월 1회 정기 모임과 형식별 모임이 그 사이를 채웁니다)

정기 모임은 모든 Circle의 기본입니다. 월 1회, 결과물의 진행을 확인하고 막힌 곳을 함께 풉니다. 새 소식은 짧게, 결과물 이야기는 길게 합니다.

AI Table은 Circle의 경계를 넘어 열리는 여섯에서 여덟 명의 저녁 모임입니다. 한 주제를 깊게 이야기하며 Chatham House Rule(내용은 쓰되 발언자를 특정하지 않는 규칙)이 적용됩니다. 서로 다른 Circle의 사람들이 처음 만나는 접점입니다.

Research Seminar는 Research Circle이 주관합니다. 논문 재현 결과나 벤치마크 리포트를 발표하고, Builder Circle의 엔지니어가 "실제 서비스에 쓰려면 무엇이 더 필요한가"를 묻습니다.

Creator Night는 Creator Circle이 주관합니다. 한 달 동안 만든 영상과 이미지를 보여 주고 어떤 워크플로우로 만들었는지 공개합니다. 결과물이 아니라 과정을 공유하는 자리입니다.

Founder Dinner는 Founder Circle의 형식입니다. Closed Room(참여자만 접근하는 공간)으로 운영하며 매출 숫자와 실패 경험을 솔직하게 나눕니다. Expert Circle 회원이 초대되어 법률·세무 질문에 답하기도 합니다.

Demo Day는 분기의 마감입니다. 각 소그룹이 결과물을 발표하고, 결과물은 플랫폼에 등록되며 기여가 기록됩니다. 올릴 것이 없는 소그룹은 그 사실 자체가 회고의 출발점입니다.

Workshop은 결과물을 만드는 손을 늘리는 자리입니다. Builder Circle의 워크플로우를 Creator Circle 회원이 직접 따라 해 보거나, Expert Circle의 계약 체크리스트를 Founder Circle이 실제 계약서에 적용해 봅니다. 한국인공지능아카데미와 함께 열기도 합니다.

Circle Leader의 역할과 임기

Circle Leader는 Circle의 결과물이 나오게 하는 사람입니다. 권한보다 책임이 먼저입니다. 분기 초에 결과물을 선언하도록 이끌고, 소그룹이 마감을 지키는지 살피고, 리듬을 유지하고, 신규회원이 첫 결과물에 참여할 자리를 마련하고, Demo Day에서 성과를 공개합니다.

Leader는 Circle 회원의 추천과 Council의 승인으로 정해집니다. 임기는 기본값 1년, 연임은 한 번까지입니다. 임기를 두는 이유는 한 사람에게 Circle이 종속되는 것을 막기 위해서입니다. 임기가 끝난 Leader는 다음 Leader를 돕되 의사결정에서는 물러납니다. Contribution creates Trust, not Permanent Privilege.

Leader가 하지 않는 일도 분명합니다. 회원의 등급을 정하지 않습니다. 사업기회를 배정하지 않습니다. Circle에서 태어나는 Project Cell의 Project Lead(프로젝트 리드)를 자동으로 맡지 않습니다.

여기서 제24장의 원칙이 그대로 적용됩니다. Governance Power ≠ Economic Opportunity. Leader는 회원의 역량과 관심을 가장 먼저, 가장 자세히 알게 되는 자리입니다. 그 정보로 좋은 사람을 자기 프로젝트에 먼저 데려가거나, 자기 회사의 고객을 Circle 결과물로 무상 지원받는다면 이해상충입니다. Leader는 자기 회사나 자신이 Originator(기회를 가져온 사람)인 프로젝트가 Circle과 얽힐 때 Conflict of Interest Declaration(이해상충 신고서, Appendix G)을 내고 관련 결정에서 회피(Recusal)합니다. 결과물이 특정 회원의 사업에 유리하게 잡히는 일이 반복되면 Council이 살펴봅니다.

Circle에서 Project Cell이 태어나는 과정

Circle의 가장 중요한 산출물은 리포트가 아니라 사람 사이의 신뢰이고, 그 신뢰가 Project Cell로 이어집니다. 경로는 대체로 셋입니다.

첫째, 결과물이 시장을 만납니다. Creator Circle이 공개한 워크플로우를 본 기업이 "우리 제품으로 만들어 달라"고 요청합니다. 요청은 플랫폼의 Opportunity로 공개되고, 워크플로우를 만든 사람들이 첫 후보가 됩니다. 다만 후보일 뿐 자동 배정은 아닙니다. 팀 구성은 Capability + Experience + Trust + Availability + Fit을 따릅니다(제15장 참조).

둘째, 회원이 기회를 가져옵니다. Founder Circle의 한 회원이 고객사를 발굴하고 필요한 엔지니어를 Builder Circle에서 찾습니다. 이 회원은 Originator가 되고, 이후는 제14장의 생애주기 Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review를 따릅니다.

셋째, Circle 자체가 사업을 검증합니다. Founder Circle의 소그룹이 한 분기 동안 아이디어를 검증하고, Demo Day에서 AI 10K Initiative의 Stage 0에서 Stage 1로 넘어가겠다고 선언합니다. 이때 Circle 활동은 끝나고 Project Cell이 시작됩니다.

세 경로의 공통점은 전환하는 순간 Project Charter(프로젝트 헌장)를 쓴다는 것입니다. Circle에서는 공동 자산이던 것이 Project Cell에서는 정산 대상이 되기 때문입니다. Circle에서 만든 워크플로우를 Project Cell이 쓰면 그것은 Background IP이고, 새로 만든 것은 Charter가 귀속을 정합니다(제13장 참조). 이 경계를 흐리면 "다 같이 만든 것을 몇 사람이 돈으로 바꿨다"는 갈등이 생깁니다. Leader는 이 전환을 돕되 개입하지 않습니다. 할 일은 어디까지가 공동 자산인지 기록으로 넘겨주는 것입니다.

Circle 간 협력

혼자 만들 수 없는 결과는 대개 Circle 하나로도 만들 수 없습니다. 광고 영상을 대량으로 만드는 파이프라인은 Creator Circle의 감각과 Builder Circle의 자동화가 결합해야 나옵니다. Founder Circle이 만든 사업은 Expert Circle의 계약·세무 검토를 거쳐야 안전해집니다. 그래서 분기마다 최소 하나의 Circle 간 공동 결과물을 권장하며, 기여 기록은 두 Circle 모두에 남깁니다.

흔한 실수는 한 Circle이 다른 Circle을 "지원 조직"으로 여기는 것입니다. "이 기능만 만들어 주면 된다"고 요청하는 순간 협력은 외주가 됩니다. 기획 단계부터 두 Circle이 함께 앉아야 합니다. 사람을 소모품처럼 다루지 않는다는 원칙은 Circle 사이에서도 유효합니다.

운영원칙

숫자는 커뮤니티의 기본값이며 Circle 운영 계획으로 조정할 수 있습니다.

경계 상황도 정해 둡니다. 소그룹이 두 분기 연속 결과물을 내지 못하면 해산하고, 원하면 새 약속으로 다시 시작합니다. 해산은 징계가 아니라 Circle을 가볍게 유지하는 일입니다. Leader가 임기 중 사임하면 회원이 임시 Leader를 추천하고 Council이 승인합니다. 회원이 열 명 미만으로 줄면 다른 Circle의 소그룹으로 합치는 것을, 소그룹 하나가 Circle만큼 커지면 독립을 검토합니다.

채팅방으로 퇴화하는 징후와 회복법

Circle은 방치하면 채팅방으로 돌아갑니다. 징후는 이렇습니다. 링크 공유가 결과물 논의보다 많아집니다. 정기 모임에서 지난 결과물의 진행을 묻는 사람이 없습니다. 같은 몇 사람만 말하고 나머지는 읽기만 합니다. Demo Day 발표가 "다음 분기에는 꼭"으로 두 번 미뤄집니다. 신규회원이 들어와도 무엇에 참여할지 알 수 없습니다.

회복법은 규칙을 더 만드는 것이 아니라 결과물을 다시 세우는 것입니다. Leader는 다음 정기 모임의 안건을 하나로 줄입니다. "이번 분기에 내놓을 것 하나를 정합시다." 세 사람이 한 달 안에 낼 리포트 하나면 충분합니다. 작은 결과물이 나오면 리듬이 돌아오고, 리듬이 돌아오면 사람이 돌아옵니다. 온라인 대화가 늘어졌다면 AI Table이나 Workshop처럼 손을 움직이는 자리를 열고, 신규회원의 "이것은 왜 이렇게 하나요"라는 질문이 방향을 다시 잡게 합니다. 그래도 회복되지 않으면 Council과 함께 Circle의 초점을 다시 정의합니다. Circle은 조직도의 칸이 아니라 결과물을 내는 사람들의 약속이기 때문입니다.

Case: Creator Circle과 Builder Circle이 만난 분기

아래는 가상의 사례입니다.

Creator Circle의 AI Video 소그룹은 지난 분기 Demo Day에서 짧은 광고 영상 제작 워크플로우를 공개했습니다. 크리에이터 최 씨가 이끌었고 세 명이 참여했습니다. 반응은 좋았지만 영상 한 편에 여전히 사람의 손이 서른 번 이상 필요했습니다.

Creator Night에 초대받은 Builder Circle의 개발자 김 씨가 물었습니다. "서른 번 중에 판단이 필요한 것은 몇 번입니까?" 세어 보니 여섯 번이었습니다. 두 사람은 다음 분기의 Circle 간 공동 결과물로 "판단 여섯 번으로 영상 열 편을 만드는 파이프라인"을 제안했습니다. 두 Leader가 승인했고, 각 Circle에서 두 명씩, 그리고 신규회원 한 명이 Junior Slot으로 합류했습니다.

갈등은 중간 점검에서 나왔습니다. 김 씨는 자동화를 자기 회사의 내부 도구 위에 얹으면 빠르다고 했습니다. 최 씨는 그러면 결과물이 김 씨 회사 없이는 돌아가지 않는 것 아니냐고 물었습니다. Builder Circle의 Leader는 자기 이해가 걸려 있지 않았으므로 회피할 필요가 없었고, 원칙에 따라 정리했습니다. 공개 파이프라인은 오픈 도구만으로 구성하고, 김 씨 회사의 도구를 쓰는 버전은 별도 선택 사항으로 두되 공동 자산에는 포함하지 않는다는 것이었습니다. 김 씨도 동의했습니다.

Demo Day 발표를 본 마케터 한 팀장이 고객사 캠페인에 이것을 쓰고 싶다고 했습니다. 한 팀장은 요청을 플랫폼의 Opportunity로 올렸고, 파이프라인을 만든 다섯 명 중 일정이 맞는 네 명이 참여했으며 한 팀장이 Originator로 합류해 Project Cell이 만들어졌습니다. Charter에는 Circle의 파이프라인이 Background IP로 명시되었고, 고객사를 위해 새로 만드는 부분은 참여자 공동 소유에 커뮤니티 비독점 라이선스를 붙이기로 했습니다. 규모는 4천만원이었고, Work Compensation을 먼저 정한 뒤 잉여가치를 Contribution Matrix(기여도 평가표)로 나누기로 했습니다.

두 Circle에 남은 것은 공개 파이프라인 하나, 다섯 명의 기여 기록, 신규회원의 첫 결과물, 그리고 Project Cell 하나입니다. 두 Leader는 Project Cell에 참여하지 않았고, 결과물의 경계를 기록으로 넘겨주는 일만 했습니다. 이것이 Circle이 일하는 방식입니다.

Remember

Circle은 채팅방이 아니라 결과물을 만드는 실행 공동체입니다. 분기마다 무엇을 내놓을지 선언하고, Demo Day에서 공개하고, 기여자를 기록합니다.

Circle Leader는 결과물의 마감을 책임지는 사람이지 사업기회를 배정하는 사람이 아닙니다. 임기는 1년이며, 이해가 걸린 사안에서는 신고하고 회피합니다.

Circle의 가장 큰 산출물은 사람 사이의 신뢰이고, 그 신뢰가 Project Cell로 이어집니다. 전환하는 순간 Charter를 쓰고 Background IP의 경계를 기록합니다.

"Circle은 대화가 아니라 결과물로 기억된다."

함께 일하는 사람들 사이에 이견이 생겼을 때, 관계와 신뢰를 잃지 않고 답을 찾는 절차는 무엇인가. 당사자 협의에서 외부 중재까지 네 단계와, 그 과정이 Trust Capital에 남는 방식을 답합니다.

질문에서 시작합니다

프로젝트가 끝났고 고객은 만족했습니다. 그런데 Project Settlement Sheet(정산표)를 받아 본 개발자 노 씨는 표정이 굳었습니다. 중간에 고객 요청으로 늘어난 3주치 작업이 어디에도 없었기 때문입니다. Project Lead(프로젝트 리드)인 윤 대표는 "그건 Value Sharing에서 반영하면 된다"고 말했고, 노 씨는 "내가 수행한 일이니 Work Compensation이다"라고 답했습니다. 둘 다 거짓말을 하고 있지 않습니다. 같은 사실을 다른 눈으로 보고 있을 뿐입니다.

이런 순간에 사람들은 흔히 둘 중 하나를 택합니다. 참고 넘어가거나, 단체방에 올립니다. 참으면 관계는 남지만 마음이 떠납니다. 올리면 속은 시원하지만 관계도 절차도 사라집니다. 이 장의 질문은 이것입니다. 세 번째 길이 있는가. 있다면 얼마나 빠르고, 누가 판단하고, 그 기록은 나에게 어떻게 남는가.

왜 분쟁은 조직을 시험하는가

분쟁 자체는 문제가 아닙니다. 서로 다른 전문성을 가진 사람이 돈이 걸린 일을 함께 하면 이견은 반드시 생깁니다. 배분에 대한 감각이 다르고, 범위에 대한 기억이 다르고, 품질에 대한 기준이 다릅니다. 문제는 이견이 있느냐가 아니라, 이견이 생겼을 때 조직이 무엇을 하느냐입니다.

전통 기업에는 인사부와 상급자가 있고, 시장에는 계약서와 법원이 있습니다. 느슨한 커뮤니티에는 아무것도 없어서, 분쟁이 생기면 목소리 큰 사람이 이기거나 조용히 사람이 떠납니다. 한국인공지능커뮤니티를 묶는 것은 고용도 계약도 아닌 공유된 규약과 기록된 신뢰입니다. 그래서 분쟁을 다루는 절차 역시 규약의 일부여야 합니다.

AI 시대의 조건은 분쟁의 성격도 바꿉니다. 실행 비용이 낮아지면서 프로젝트는 짧아지고, 범위는 자주 바뀌고, 한 사람이 여러 역할을 겸합니다. 역할의 경계가 흐려질수록 "그 일이 누구의 기여였는가"는 더 자주 다투게 됩니다. 분쟁이 잘못 다루어지면 잃는 것은 한 건의 정산이 아닙니다. 공개적으로 성토당한 사람은 떠나고, 그 장면을 본 사람들은 이견이 있어도 말하지 않게 됩니다.

우리의 철학: 분쟁은 절차로 다루고, 사람은 남긴다

프로토콜 조직에서 분쟁 해결은 처벌 제도가 아니라 관계 보존 장치입니다. 목적은 누가 옳았는지를 가리는 데서 끝나지 않고, 이견을 거친 뒤에도 두 사람이 다시 같은 Project Cell(프로젝트 셀)에 들어갈 수 있게 하는 것입니다. 그래서 절차는 가장 가까운 곳에서 시작해 먼 곳으로 올라갑니다. 당사자끼리 풀 수 있는 것을 위원회로 가져가지 않고, 위원회가 풀어야 할 것을 단체방으로 가져가지 않습니다.

우리는 분쟁을 사실의 문제로 다룹니다. Project Charter(프로젝트 헌장)에 무엇이 적혀 있었는가, 주간 기록에 무엇이 남았는가. 기록이 있으면 분쟁의 대부분은 감정이 아니라 해석의 문제가 되고, 해석의 문제는 합의로 풀립니다. 제19장에서 기여를 그 주에 기록하라고 한 이유가 여기서 드러납니다.

또 하나의 원칙은 이의 제기가 안전해야 한다는 것입니다. 신뢰는 말이 아니라 행동으로 쌓이는데, 절차를 지켜 이견을 밝히는 것은 좋은 행동입니다. 반대로 허위 신고와 공개 성토는 절차를 무기로 쓰는 것이며, 그것은 부정직입니다. 실패에는 관대하되 부정직에는 엄격하다는 원칙은 분쟁 절차 안에서도 그대로 작동합니다. 그리고 판단하는 사람은 이해가 걸리지 않은 사람이어야 합니다. Governance Power ≠ Economic Opportunity. 자기 사건을 자기가 심판하지 않는 것도 같은 원칙입니다.

네 단계의 절차

분쟁은 아래 순서를 따릅니다. 기한은 커뮤니티의 기본값이며 Project Charter로 조정할 수 있습니다. 어느 단계에서든 합의가 이루어지면 절차는 거기서 끝나고, 합의 내용은 기록됩니다.

당사자 협의 ─▶ Project Lead 조정 ─▶ 윤리·분쟁위원회 ─▶ 외부 중재
  (7일)          (14일)              (30일)           (외부 규정)

세 가지를 특히 기억해야 합니다. 첫째, 절차가 진행되는 동안에도 Work Compensation(수행 대가)은 먼저 지급합니다. 다투는 것은 대개 Value Sharing(가치 배분)이지 수행 대가가 아닙니다. 사람을 소모품처럼 다루지 않는다는 원칙은 분쟁 중에도 유효합니다. 둘째, 기한은 상한이며 빨리 끝날수록 좋습니다. 셋째, 제11장의 부정직 유형(고객 우회, 정보 유출, 비용 부풀리기 등)이 의심될 때는 협의를 생략하고 바로 위원회에 신고할 수 있습니다. 부정직은 협의의 대상이 아니라 조사의 대상이기 때문입니다.

여론재판을 금지하는 이유

단체방에 분쟁을 올리는 것은 커뮤니티가 명시적으로 금지하는 행동입니다. 정의감을 의심해서가 아니라, 공개 성토는 구조적으로 나쁜 결과를 내기 때문입니다.

단체방에는 판단할 자료가 없습니다. 읽는 사람들은 Charter도 주간 기록도 보지 못한 채 먼저 올라온 이야기를 믿습니다. 상대는 방어할 수 없습니다. 반론을 올리면 싸움이 되고, 침묵하면 인정이 됩니다. 분쟁의 맥락을 설명하려면 프로젝트 내부를 말해야 하므로 고객 정보와 계약 조건이 새어 나갑니다(제12장 참조). 그리고 지켜본 모든 사람이 배웁니다. "여기서는 이견을 말하면 저렇게 된다."

그래서 규칙은 다음과 같습니다.

1. 분쟁 중인 사안은 당사자, 조정자, 위원회 외의 회원에게 공개하지 않습니다. SNS도 포함됩니다.
2. 특정인을 지목하는 성토, 암시적 언급("어떤 Lead가 정산을 안 한다더라"), 편들기 요청은 그 자체로 규약 위반이며 경고 대상입니다.
3. 상대의 부정직이 확실하다고 믿어도 공개하지 않습니다. 확신은 위원회에 제출하는 것입니다.
4. 결정 후 공개 범위는 위원회가 정합니다. 기본값은 당사자와 해당 Project Cell 참여자까지입니다.
5. 조언이 필요하면 Circle Leader나 Expert Circle 회원에게 개별적으로, 상대를 특정하지 않고 묻습니다.

흔한 분쟁과 1차 해결 기준

대부분의 분쟁은 여섯 가지 유형 중 하나입니다. 각 유형에는 당사자 협의 단계에서 먼저 적용할 기준이 있습니다. 이 기준으로 풀리는 분쟁은 위원회까지 갈 필요가 없습니다.

여섯 유형을 관통하는 기준은 하나입니다. 기록이 먼저 말하게 하고, 기록이 없을 때만 사람이 말합니다.

윤리·분쟁위원회: 구성, 독립성, 회피, 재심

윤리·분쟁위원회(Ethics & Dispute Committee)는 Council(운영위원회) 산하에 있지만 판단에서는 독립적입니다(제23장 참조). 구성과 절차의 기본값은 다음과 같습니다.

구성. 위원은 5인 이상 홀수로 두며 Council이 위촉합니다. 임기는 2년이고 Council 임기와 엇갈리게 배치합니다. 법률·세무 전문가만으로 채우지 않습니다. 기술 분쟁에는 기술을 아는 사람이, 배분 분쟁에는 프로젝트를 이끌어 본 사람이 필요합니다. 사안마다 3인의 심의 패널을 구성하고, 결정은 다수결로, 근거와 함께 서면으로 남깁니다.

독립성. Council은 위원회의 결정을 뒤집을 수 없습니다. 사건에 관련된 Council 위원이나 Circle Leader는 위원회에 어떤 의견도 전달하지 않습니다. 제명 결정만 Council이 확인하며, 이것도 판단을 다시 하는 것이 아니라 절차를 확인하는 것입니다.

회피(Recusal). 위원은 당사자이거나 당사자와 같은 Project Cell에 참여했던 경우, 당사자와 경제적 이해관계(투자, 고용, 거래)가 있는 경우, 당사자가 소속된 앵커 조직의 구성원인 경우, 그 밖에 공정하게 판단하기 어렵다고 스스로 판단하는 경우에 해당 사안에서 물러납니다. 회피 여부는 패널 구성 전에 Conflict of Interest Declaration(이해상충 신고서, Appendix G)로 밝힙니다. 당사자도 특정 위원의 회피를 요청할 수 있으며, 수용 여부는 나머지 위원이 정합니다.

재심. 제11장의 재심 절차를 그대로 따릅니다. 결정 통지 후 14일 이내에 청구하고, 원심에 참여하지 않은 위원으로 별도 패널을 구성하며, 청구자는 새로운 사실이나 절차상 하자를 제시해야 합니다. 결과는 30일 이내에 서면으로 통지됩니다. 재심은 한 번이며, 그 뒤에 남은 길은 외부 중재입니다.

제재. 부정직이 인정되면 제11장의 단계, 즉 경고 → 프로젝트 참여 제한 → 등급 조정 → 제명 중에서 행동에 비례하여 정하고, 금전 피해는 별개로 먼저 회복합니다. 그러나 대부분의 분쟁은 부정직이 아니라 이견이고, 이견에 대한 결정은 제재가 아니라 정산의 확정입니다.

분쟁 기록과 Trust Capital

분쟁의 사실과 결과는 Trust Capital(행동으로 축적되는 신뢰의 기록)에 남습니다. 회원들이 가장 궁금해하는 것은 "문제를 제기한 나에게 불리한 기록이 남는가"입니다.

정당한 문제 제기는 감점되지 않습니다. 이견이 있었다는 사실은 신뢰의 손상이 아니라 그 사람이 절차를 믿고 지켰다는 증거입니다. 감점되는 것은 절차를 거부하거나, 은폐하거나, 절차를 무기로 쓴 행동입니다. 허위 신고는 상대의 신뢰를 빼앗으려는 시도이므로 부정직으로 다룹니다. 기록은 사실만 남깁니다. "정산 이견, 조정 단계에서 합의"는 남지만 "까다로운 사람"이라는 평가는 남지 않습니다.

Case: 3주치 작업은 누구의 것인가

가상의 사례입니다. 파운더 윤 대표는 한 유통사의 고객상담 챗봇 프로젝트를 가져와 Project Lead와 Contracting Party(계약주체)를 맡았습니다. 규모는 8천만원이었고, 개발자 노 씨가 모델 연동과 백엔드를, 연구자 문 박사가 상담 데이터 정제를 맡았습니다. Charter에는 직접비용 1,500만원, Work Compensation 4,500만원이 잡혀 있었고, 잉여가치 2,000만원에서 Community Share 5%를 뗀 1,900만원을 Contribution Matrix로 나누기로 했습니다.

8주 차에 고객이 메신저 채널 연동을 추가로 요청했습니다. 윤 대표는 "일단 해 주자"고 했고, 노 씨는 3주를 더 썼습니다. 정산표가 나왔을 때 노 씨의 Work Compensation은 Charter 그대로였습니다. 노 씨는 추가 3주 300만원을 요구했고, 윤 대표는 고객에게 추가 대금을 받지 못했으니 Execution 기여로 잉여가치에서 반영하자고 했습니다.

협의. 노 씨는 단체방에 올리는 대신 윤 대표에게 플랫폼 메시지로 쟁점과 근거를 보냈습니다. 두 사람은 7일 안에 두 번 만났고, 윤 대표는 Charter의 Work Compensation 4,500만원을 입금 후 14일 안에 먼저 지급했습니다. 그러나 추가 300만원에 대해서는 합의하지 못했습니다.

조정. Lead가 당사자였으므로 문 박사가 조정을 맡았습니다. 8주 차 주간 기록에 노 씨가 남긴 "고객 요청으로 채널 추가, 윤 대표 구두 승인"이라는 한 줄이 있었습니다. 조정안은 이랬습니다. 승인 기록이 있으니 범위 변경으로 보고 300만원을 Work Compensation에 추가하되, 추가 대금을 받지 못한 것은 Lead의 영업 판단이므로 잉여가치에서 감당한다. 노 씨는 수락했고, 윤 대표는 "구두 승인은 정식 합의가 아니다"라며 거부했습니다. 사안은 위원회로 갔습니다.

위원회. 패널 3인 중 한 명이 윤 대표의 회사에 투자한 사실을 신고하고 회피했고, 다른 위원으로 교체되었습니다. 패널은 기록을 검토하고 양측을 각각 청문한 뒤 회부 후 22일 만에 결정했습니다. 범위 변경은 Lead의 승인이 있었으므로 성립했고, 승인을 서면으로 남기지 않은 것은 Lead의 기록 누락이지 노 씨의 책임이 아니다. 따라서 300만원을 Work Compensation으로 추가한다. 잉여가치는 1,700만원으로 줄고, Community Share 85만원을 뗀 1,615만원을 Contribution Matrix로 나눈다. 윤 대표의 행동은 부정직이 아니라 기록의 실패이며, 제재는 없다.

결과. 노 씨의 Trust Capital에는 "정산 이견을 절차로 제기하여 해결"이 남았고 감점은 없었습니다. 윤 대표에게는 "범위 변경 기록 누락, 절차 준수"가 남았고, 재심은 청구하지 않았습니다. 여덟 달 뒤 두 사람은 같은 유통사의 후속 프로젝트에 다시 들어갔고, 이번 Charter에는 "범위 변경은 48시간 내 서면 승인"이라는 조항이 들어갔습니다. 노 씨가 단체방에 먼저 올렸다면 300만원은 받았을지 몰라도 후속 프로젝트는 없었을 것입니다.

Remember

• 분쟁은 있느냐가 아니라 어떻게 다루느냐의 문제입니다. 절차는 이견을 억누르는 장치가 아니라 이견이 들릴 곳으로 보내는 장치입니다.
• 순서는 당사자 협의(7일) → Project Lead 조정(14일) → 윤리·분쟁위원회(30일) → 외부 중재입니다. 어느 단계에서든 Work Compensation은 먼저 지급합니다.
• 단체방 공개 성토는 정의가 아니라 규약 위반입니다. 위원회는 Council 산하이되 판단은 독립적이며, 이해가 걸린 위원은 회피하고, 재심은 14일 이내 청구하여 30일 안에 답합니다.
• 정당한 문제 제기는 감점되지 않습니다. 감점되는 것은 절차의 거부, 은폐, 그리고 절차를 무기로 쓰는 허위 신고입니다.

"이견은 절차로 풀고, 사람은 남긴다."

개정 메모: Give Back은 확정된 매출 비율이나 납부 의무가 아닙니다. 회비·서비스 대가·자발적 출연·복지 분담을 실질에 따라 구분하고, 복지재원은 수혜자·관리 법인·세무·모금 규제를 검증한 뒤 별도 제도로 정합니다. 현재 모집 중인 기금이나 보장 급부는 없습니다.

커뮤니티에서 성장한 사람은 무엇을 돌려주어야 하는가. 그리고 왜 그것을 "의무"로 만드는 순간 순환은 멈추는가.

질문에서 시작합니다

파운더 박 대표는 3년 전 Member로 들어왔습니다. 첫해에는 Junior Slot(신규회원을 위해 열어 두는 자리)으로 남의 프로젝트에 참여했고, 둘째 해에는 자기 Project Cell(프로젝트 셀, 필요할 때 만들어지고 끝나면 해체되는 실행 단위)을 만들었고, 셋째 해에는 그 셀이 회사가 되어 월 단위 반복 매출을 내고 있습니다. 어느 날 박 대표가 Circle Leader(서클 리더)에게 묻습니다. "저는 이제 커뮤니티에 뭘 해야 하나요. 회비를 더 내야 하나요, 아니면 매출의 몇 퍼센트를 내야 하나요."

이 질문은 진심이고, 동시에 잘못된 전제 위에 서 있습니다. 박 대표는 Give Back을 "빚 갚기"로 이해하고 있습니다. 받은 것이 있으니 갚아야 한다는 생각입니다. 그 마음은 고맙지만, 커뮤니티가 원하는 것은 채무 상환이 아닙니다.

반대편에는 다른 유형이 있습니다. 개발자 정 씨는 커뮤니티에서 두 개의 프로젝트를 거쳐 실력과 고객을 얻었고, 그 뒤로 조용히 사라졌습니다. 규칙을 어긴 것은 없습니다. 정산도 깨끗했습니다. 다만 그가 얻은 경험은 그와 함께 나갔고, 그가 앉았던 Junior Slot은 다음 사람에게 열리지 않았습니다.

이 장은 이 두 사람 사이의 어딘가에 있는 질문을 다룹니다. 성장한 사람은 무엇을 돌려주는가. 강제하지 않는데 왜 돌려주는가. 그리고 돌려준 것은 어디에 기록되고 무엇으로 이어지는가.

왜 이것이 문제인가

사다리는 위에서 끌어올려야 계속 서 있다

성장의 사다리(제8장 참조)는 Member → Verified → Contributor → Professional → Leader / Fellow로 이어집니다. 이 사다리가 작동하려면 아래 단에 있는 사람이 위 단에 있는 사람과 실제로 일할 기회가 있어야 합니다. Junior Slot이 그 장치이고, 멘토링과 Closing Review(종료평가) 공유가 그 장치입니다.

문제는 이 장치들이 모두 위 단에 있는 사람의 시간을 요구한다는 점입니다. Professional이 자기 셀에 Junior Slot을 열지 않으면 신규회원은 첫 프로젝트를 만나지 못합니다. Leader가 자기 실패를 공유하지 않으면 다음 셀이 같은 실패를 반복합니다. 성장한 사람이 빠져나가면 사다리는 위쪽부터 사라지고, 커뮤니티는 매년 처음부터 다시 시작하는 신입 모임이 됩니다.

강제하면 세금이 되고, 방치하면 무임승차가 된다

이 문제를 푸는 두 가지 흔한 방법이 있고, 둘 다 실패합니다.

첫째는 강제입니다. "Professional 이상은 연 20시간 멘토링 의무", "매출의 3%를 커뮤니티에 납부". 이렇게 하면 한 가지는 확실히 얻습니다. 최소치입니다. 그리고 최소치만 얻습니다. 의무가 된 기여는 세금처럼 느껴지고, 세금은 가능한 한 적게 내는 것이 합리적인 행동이 됩니다. 20시간을 채우기 위해 형식적인 멘토링이 생기고, 3%를 피하기 위해 매출을 커뮤니티 바깥으로 옮깁니다. 강제는 기여를 늘리는 것이 아니라 기여의 질을 최소치로 고정합니다.

둘째는 방치입니다. 느슨한 커뮤니티가 택하는 길입니다. 아무것도 요구하지 않으면 아무것도 돌아오지 않습니다. 정보를 가져가고 관계를 가져가고 고객을 가져간 뒤 사라지는 것이 규칙 위반이 아니므로, 그것이 기본 행동이 됩니다. 남는 사람은 늘 새로 온 사람뿐입니다.

위계 조직은 이 문제를 고용으로 풉니다. 선배가 후배를 가르치는 것은 회사가 월급을 주기 때문입니다. 시장은 이 문제를 풀지 못합니다. 프리랜서는 경쟁자를 키울 이유가 없습니다. 프로토콜 조직(Protocol Organization)은 고용도 없고 명령도 없습니다. 그래서 Give Back을 다른 방식으로 설계해야 합니다.

AI 시대에 돌려줄 것은 무엇인가

AI가 실행 비용을 낮추면서 "돌려줄 것"의 성격이 바뀌었습니다. 예전에는 코드를 공개하거나 튜토리얼을 쓰는 것이 큰 기여였습니다. 지금은 코드와 문서는 싸졌습니다. 비싸진 것은 경험입니다. 어떤 고객이 진짜 고객이었는지, 어떤 모델이 데모에서는 잘 되다가 운영에서 무너졌는지, 정산 회의에서 어떤 말이 팀을 깨뜨렸는지. 이것은 AI가 생성해 주지 않고, 해 본 사람만 알고 있습니다.

그래서 이 시대의 Give Back은 돈이나 시간의 양보다 경험의 밀도로 측정됩니다. 성장한 사람이 가진 가장 비싼 자산은 매출이 아니라 "해 봤다는 것"이고, 그것을 다음 사람이 쓸 수 있는 형태로 넘기는 것이 순환의 핵심입니다.

우리의 철학

기부가 아니라 순환이다

한국인공지능커뮤니티의 관통 공식은 CAPABILITY → CONTRIBUTION → TRUST → COLLABORATION → VALUE → REWARD → GROWTH → GIVE BACK입니다. 많은 사람이 이 공식을 직선으로 읽습니다. 그러나 이 공식은 원입니다. 마지막 고리 GIVE BACK은 첫 고리 CAPABILITY로 돌아갑니다.

            CAPABILITY ──→ CONTRIBUTION ──→ TRUST
                ↑                              │
                │                              ↓
            GIVE BACK                    COLLABORATION
                ↑                              │
                │                              ↓
             GROWTH ←──── REWARD ←──── VALUE

   GIVE BACK → CAPABILITY 로 돌아가는 세 경로
   ① 내 경험이 다른 사람의 역량이 된다      (멘토링 · 지식 공개 · Junior Slot)
   ② 내 자원이 다음 셀의 출발점이 된다      (인프라 · 커뮤니티 기여분 · 추천)
   ③ 내 Give Back이 내 Trust Capital이 된다  (기록 → Fellow → 더 큰 협력)

세 경로가 모두 중요합니다. ①과 ②는 커뮤니티가 얻는 것이고, ③은 기여한 사람이 얻는 것입니다. 이 셋이 동시에 작동하기 때문에 Give Back은 희생이 아니라 순환입니다. 성장한 사람이 돌려주면 새로운 Capability Node(역량 노드)가 생기고, 그 노드가 기여하고, 신뢰를 얻고, 협력하고, 다시 성장하고, 다시 돌려줍니다. 강제 없이도 돌아가는 이유는, 돌려주는 사람도 이 순환의 수혜자이기 때문입니다.

오픈소스 재단과 길드에서 배우는 것

이 설계는 새롭지 않습니다. 오픈소스 재단은 코드를 가져다 쓴 회사가 개선한 코드를 다시 올리는 순환으로 유지됩니다. 강제 조항이 있는 라이선스도 있지만, 실제로 생태계를 지탱하는 것은 강제가 아닙니다. 기여자가 재단 안에서 얻는 평판, 다음 협력의 기회, 자기가 쓰는 도구가 좋아지는 직접적 이익입니다. 기여를 멈춘 회사는 규칙을 어긴 것이 아니지만, 생태계 안에서 서서히 발언권을 잃습니다.

중세 길드와 현대의 프로페셔널 길드도 같은 구조를 가졌습니다. 마스터는 도제를 가르칠 의무가 있었지만, 그 의무는 처벌보다 지위와 연결되어 있었습니다. 도제를 키우지 않는 마스터는 마스터로 인정받지 못했습니다. 우리는 이 두 모델에서 같은 원리를 가져옵니다. Give Back은 처벌로 강제하지 않고, 인정과 연결한다. 기여한 사람을 잊지 않는다는 원칙은 여기서도 그대로 적용됩니다.

Give Back은 Trust Capital이 되고, Fellow의 조건이 된다

Trust Capital(행동으로 축적되는 신뢰의 기록)은 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사로 쌓입니다(제10장 참조). Give Back은 이 기록의 한 축입니다. 플랫폼은 기여를 Knowledge·Research·Technology·Mentoring·Project·Event·Connection·Infrastructure로 분류해 기록하는데, Give Back은 이 여덟 유형 중 특히 Mentoring·Knowledge·Connection·Infrastructure로 남습니다.

성장 단계의 마지막인 Leader / Fellow는 여기서 갈립니다. Leader는 셀과 Circle을 이끈 사람이고, Fellow는 그에 더해 다른 사람을 성장시킨 기록이 있는 사람입니다. Fellow는 임명되는 자리가 아니라 기록으로 도달하는 자리입니다. 그리고 Fellow가 된다고 사업기회가 먼저 배정되지는 않습니다. Governance Power ≠ Economic Opportunity는 Give Back에도 적용됩니다. Fellow가 얻는 것은 발언의 무게, 더 깊은 네트워크, 더 큰 협력의 초대이지, 기회의 우선권이 아닙니다. Contribution creates Trust, not Permanent Privilege.

Give Back의 여덟 가지 형태

Give Back은 한 가지가 아닙니다. 사업가와 교수와 개발자와 크리에이터는 돌려줄 수 있는 것이 다릅니다. 아래 표는 여덟 가지 형태와 각각이 누구에게 자연스러운지, 플랫폼에 어떤 유형으로 기록되는지를 정리한 것입니다.

이 중 커뮤니티 기여분만이 구조적으로 정해진 것이고, 나머지 일곱은 모두 자발적입니다. 커뮤니티 기여분이 Work Compensation(수행 대가)에서는 떼지 않고 잉여가치에서만 떼는 이유는 제20장에서 설명했습니다. 사람을 소모품처럼 다루지 않는다는 원칙은, 커뮤니티 자신이 회원의 노동에서 몫을 가져가지 않는다는 원칙이기도 합니다.

역할별로 보면 이렇습니다. 교수는 멘토링과 인프라와 커뮤니티 프로젝트 리드에 강합니다. 연구실의 GPU 유휴 시간과 대학원생의 평가 방법론은 초기 셀에 큰 자산입니다. 사업가는 Junior Slot과 인프라와 추천에 강합니다. 자기 회사의 실제 문제를 셀에 열어 주는 것 자체가 Give Back입니다. 크리에이터는 워크플로우 공개에 강합니다. 어떤 프롬프트 구조가 광고주 시사에서 통과됐는지는 해 본 사람만 압니다. 마케터는 강연과 추천에 강합니다. 개발자는 지식 공개와 멘토링에 강합니다.

왜 강제하면 망가지는가

앞에서 강제가 최소치를 만든다고 했습니다. 조금 더 정확히 말하면 강제는 세 가지를 망가뜨립니다.

첫째, 기여의 성격을 바꿉니다. 자발적 기여는 "내가 아는 것 중 가장 쓸모 있는 것"을 고릅니다. 의무적 기여는 "요건을 채우는 것 중 가장 싼 것"을 고릅니다. 같은 멘토링 시간이라도 내용이 달라집니다.

둘째, Trust Capital을 오염시킵니다. 의무로 한 것은 신뢰의 신호가 되지 못합니다. 모두가 20시간을 채우면 20시간은 아무것도 말해 주지 않습니다. 자발적이기 때문에 기록에 의미가 있고, 기록에 의미가 있기 때문에 Fellow가 의미를 가집니다.

셋째, 성장한 사람을 밀어냅니다. 매출의 일정 비율을 내라고 하면 회사가 된 셀은 커뮤니티와 거리를 둡니다. 우리가 원하는 것은 정반대입니다. 성장한 회사가 커뮤니티 가까이에 남아 다음 셀에 고객과 인프라와 경험을 열어 주는 것입니다. 그것은 세율로 얻을 수 없고, 남아 있는 것이 이익이 되는 구조로만 얻을 수 있습니다.

그렇다고 아무것도 요구하지 않는 것은 아닙니다. 커뮤니티가 요구하는 것은 하나입니다. 기록하는 것입니다. 무엇을 돌려주었는지 기록하고, 기록이 신뢰가 되게 하고, 신뢰가 다음 협력으로 이어지게 합니다. 신뢰는 말이 아니라 행동으로 쌓습니다. Give Back은 그 행동 중 가장 오래 남는 것입니다.

운영원칙

아래는 커뮤니티의 기본값(Default)이며, Circle 운영 규칙이나 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

1. Give Back은 자발적이다. 커뮤니티 기여분을 제외한 어떤 형태의 Give Back도 의무로 규정하지 않는다. 등급 유지 조건으로 시간·금액을 요구하지 않는다.
2. Give Back은 기록된다. 멘토링·지식 공개·Junior Slot·인프라 제공·강연·추천은 플랫폼의 기여 유형으로 기록된다. 기록은 본인이 등록하고 수혜자 또는 Circle Leader가 확인한다.
3. Give Back은 Trust Capital의 일부다. 팀 구성 기준 Capability + Experience + Trust + Availability + Fit에서 Trust를 판단할 때 Give Back 기록을 함께 본다.
4. Fellow는 Give Back 기록으로 도달한다. 기본값: Leader 단계에서 최근 24개월간 Mentoring·Knowledge·Connection·Infrastructure 유형의 기여가 확인되고, 자기가 성장시킨 회원이 Contributor 이상에 도달한 사례가 있을 때 Council(운영위원회)이 Fellow로 인정한다. 숫자 기준은 Council이 정하고 공개한다.
5. Fellow는 기회의 우선권이 아니다. Fellow는 발언·초대·자문의 역할이며, 사업기회는 여전히 공개 채널(Opportunity)로 흐른다. Fellow가 Council 역할을 겸할 때는 회피(Recusal) 원칙이 그대로 적용된다.
6. Junior Slot은 권장 기본값이다. 참여자 4인 이상의 Project Cell은 최소 한 자리를 신규회원에게 여는 것을 권장한다. Charter에 열지 않는 사유를 적으면 열지 않을 수 있다.
7. 커뮤니티 기여분은 잉여가치에서만 뗀다. 기본값 5%, 범위 3~10%. 용도는 운영·신규회원 성장·인프라로 한정하고 Council이 연 1회 사용 내역을 공개한다.
8. Give Back을 빌미로 한 요구는 부정직이다. "내가 멘토링해 줬으니 다음 프로젝트에 넣어 달라", "인프라를 빌려줬으니 지분을 달라"는 요구는 Give Back이 아니라 거래이며, 거래라면 처음부터 Charter에 적어야 한다. 사후에 대가를 요구하는 행위는 제11장의 기여 가로채기에 준해 다룬다.

경계 상황 몇 가지를 덧붙입니다. 인프라 제공이 Give Back인지 Capital 기여인지는 시점과 합의로 구분합니다. Charter에 Capital & Infra 항목으로 적혀 Value Sharing(가치 배분)을 받는다면 그것은 기여이지 Give Back이 아닙니다. 아무 대가 없이 초기 두 달 GPU를 빌려주고 Charter에 적지 않았다면 Give Back입니다. 둘 다 정당하고, 둘 다 기록됩니다. 다만 어느 쪽인지는 시작할 때 정해야 합니다.

멘토링이 곧 셀 참여는 아닙니다. 멘토는 결과물에 책임을 지지 않고 Work Compensation도 받지 않습니다. 멘토가 실제 작업을 하기 시작하면 그 순간부터는 참여자이며 Charter를 고쳐야 합니다. 실행은 빠르게, 이해관계 변경은 합의로.

Case: Stage 3 파운더의 Give Back

이것은 가상의 사례입니다.

파운더 박 대표의 회사는 AI 10K Initiative 기준으로 Stage 3(반복 매출) 단계에 있습니다. 월 매출 약 4천만원, 직원 다섯 명. 박 대표가 커뮤니티에 "무엇을 해야 하느냐"고 물었을 때, Circle Leader 최 씨는 돈 이야기를 하지 않았습니다. 대신 세 가지를 제안했습니다.

첫째, 박 대표의 회사가 가진 실제 문제 하나를 Founder Circle에 Opportunity로 열 것. 회사가 필요로 하던 고객 응대 자동화 모듈을 외부 외주 대신 커뮤니티 셀에 맡기되, Charter에 Junior Slot을 두 자리 열 것. 박 대표는 발주자이지 Lead가 아니므로 셀의 실행 판단에는 관여하지 않기로 했습니다.

둘째, 박 대표가 2년 전 첫 셀에서 겪은 정산 갈등을 Founder Circle 세션에서 Chatham House Rule로 공유할 것. 고객 이름과 금액은 빼고, 어떤 문장이 팀을 흔들었고 어떻게 수습했는지를 말했습니다. 이 세션은 Event · Knowledge 유형으로 기록됐습니다.

셋째, 박 대표가 알고 있는 바깥의 사업가 두 사람을 추천할 것. 박 대표는 추천서에 "함께 일해 본 적은 없지만 3년간 약속을 어긴 적이 없는 사람"이라고 적었고, 그 문장이 초기 신뢰가 되었습니다.

갈등도 있었습니다. 셀에 들어온 Junior Slot의 개발자 한 씨가 넉 달 뒤 박 대표 회사에 정규직으로 채용되었습니다. 셀의 다른 참여자가 "커뮤니티를 채용 창구로 쓴 것 아니냐"고 문제를 제기했습니다. 윤리·분쟁위원회까지 가지 않고 Project Lead 조정 단계에서 정리됐습니다. 한 씨가 셀의 결과물을 끝까지 납품했고, 채용은 셀 종료 후 본인이 선택했으며, 박 대표가 채용 사실을 Circle에 먼저 알렸기 때문입니다. 위원회는 이 사례를 계기로 "셀 참여자를 종료 전에 채용 제안하려면 Lead와 참여자에게 먼저 알린다"는 기본값을 Charter 템플릿에 추가했습니다.

1년 뒤 박 대표의 기여 기록에는 Project 1건, Mentoring 2건, Event 1건, Connection 2건이 남았습니다. 그가 추천한 사업가 중 한 사람은 Contributor가 되어 자기 셀을 만들었습니다. 박 대표는 Fellow 인정을 요청하지 않았지만, Council은 이듬해 그를 Fellow로 인정했습니다. 그가 얻은 것은 사업기회가 아니라, 다음 해 Founder Circle이 Stage 전환 기준을 다시 쓸 때 첫 번째로 의견을 물어보는 사람이 된 것이었습니다.

박 대표가 회비를 더 낸 것은 없습니다. 그러나 그가 돌려준 것은 회비로는 살 수 없는 것이었습니다.

Remember

• Give Back은 빚 갚기가 아니라 순환입니다. 관통 공식의 마지막 고리는 첫 고리로 돌아가고, 돌려주는 사람도 그 순환의 수혜자입니다.
• 돌려줄 것은 돈보다 경험입니다. AI 시대에 가장 비싼 것은 해 본 사람만 아는 것이고, 그것을 다음 사람이 쓸 수 있는 형태로 넘기는 것이 핵심입니다.
• Give Back은 여덟 가지 형태가 있고, 커뮤니티 기여분을 제외하면 모두 자발적입니다. 강제하면 최소치가 되고, 최소치는 신뢰의 신호가 되지 못합니다.
• Give Back은 기록되어 Trust Capital이 되고, Fellow의 조건이 됩니다. 그러나 Fellow는 기회의 우선권이 아닙니다.
• 기여한 사람을 잊지 않는다는 약속은, 돌려준 사람에게도 똑같이 적용됩니다.

"성장한 사람이 돌려주는 것은 의무가 아니라 다음 사람의 출발점이다."

Project Cell은 끝나면 해체되는 조직인데, 끝나지 않는 매출이 생기면 어떻게 되는가. 커뮤니티는 어디까지 돕고, 회사가 된 뒤 커뮤니티와는 어떤 관계로 남는가.

질문에서 시작합니다

Creator Circle에서 시작한 한 Project Cell(프로젝트 셀)이 있습니다. 처음에는 한 고객사의 광고 영상 다섯 편을 AI로 만드는 3천만원짜리 프로젝트였습니다. 납품이 끝나고 정산이 끝나고 Closing Review(종료평가)까지 마쳤는데, 고객이 다음 달에도 열 편을 더 주문했습니다. 그다음 달에는 다른 고객 둘이 같은 것을 원했습니다. 석 달째, Project Lead(프로젝트 리드)인 크리에이터 서 씨가 Circle Leader에게 묻습니다. "이건 이제 프로젝트가 아니라 사업 같은데요. 회사를 만들어야 합니까. 만들면 셀에 있던 사람들은 어떻게 되나요. 커뮤니티는 뭘 해 주고, 저는 커뮤니티에 뭘 해야 하나요."

이 질문에는 네 개의 질문이 들어 있습니다. 언제 회사가 되는가. 회사가 될 때 함께 만든 사람들의 몫은 어떻게 되는가. 커뮤니티는 이 과정에서 무엇을 하는가. 회사가 된 뒤 커뮤니티와의 관계는 무엇인가. 이 장은 네 질문에 차례로 답합니다.

왜 이것이 문제인가

해체되는 조직과 지속되는 매출 사이

Project Cell은 필요할 때 만들어지고 끝나면 해체되는 Virtual Company입니다(제13장 참조). 이 설계는 한 번의 프로젝트에는 완벽합니다. 시작·종료·정산이 분명하고, 참여자는 각자의 회사와 직장을 유지합니다. 그러나 매출이 반복되기 시작하면 셀의 형태는 불편해집니다. 계약 주체가 매번 달라지고, 세금과 회계가 복잡해지고, 고객은 "이 팀이 내년에도 있느냐"고 묻고, 참여자는 "이걸 언제까지 부업으로 하느냐"고 묻습니다.

셀을 그대로 두면 사업이 크지 못하고, 회사를 만들면 셀의 원칙이 깨질 위험이 있습니다. 회사는 지분과 고용으로 사람을 묶습니다. 셀에서 함께 만든 사람들이 회사에서 직원이 되거나, 아예 빠지거나, 지분 없이 외주가 됩니다. 이 전환에서 가장 많이 상하는 것이 "함께 만들었다"는 감각입니다.

커뮤니티가 외주 인력풀이 되는 순간

또 하나의 위험은 반대 방향에 있습니다. 회사가 된 셀이 계속 커뮤니티에서 사람을 데려다 쓰는 것입니다. 처음에는 Junior Slot(신규회원 자리)이었다가, 점점 "우리 회사 일을 커뮤니티 회원에게 싸게 맡기는 것"이 됩니다. 커뮤니티는 이 회사의 채용 창구이자 외주 풀이 됩니다. 앵커 조직에 대해서도 같은 경계가 필요합니다. 한국인공지능연구소, H3Lab, U09, 한국인공지능아카데미, AI TEST는 먼저 온 생태계 파트너일 뿐이고, 커뮤니티가 이들의 고객 유치나 인력 확보 수단이 되어서는 안 됩니다.

시장(Market) 조직에서는 이것이 문제가 아닙니다. 외주는 외주입니다. 하지만 프로토콜 조직(Protocol Organization)에서 이것은 조직의 성격 자체를 바꾸는 문제입니다. 회원이 값싼 노동력이 되는 순간, 기여는 기록되지 않고 신뢰는 축적되지 않으며 사람은 소모품이 됩니다. 사람을 소모품처럼 다루지 않는다는 첫 번째 약속이 무너집니다.

정보만 공유하는 커뮤니티는 회사를 만들지 못한다

한편 이 모든 위험을 피하려고 "커뮤니티는 지식 공유까지만"으로 선을 긋는 조직도 많습니다. 안전하지만 아무것도 만들어지지 않습니다. 좋은 사업가는 좋은 기술자를 찾지 못하고, 좋은 연구는 시장을 만나지 못합니다. 회원들이 실제로 돈을 벌 수 있는 구조를 만드는 것은 이 커뮤니티의 중요한 목적입니다. 그래서 우리는 회사를 만드는 것을 피하지 않고, 회사를 만드는 원칙을 세웁니다.

AI 시대라는 조건이 이 방향을 강하게 밀어 줍니다. 제품을 만드는 비용이 낮아지면서 회사를 시작하는 데 필요한 사람 수가 줄었습니다. 서너 명이 결합한 셀이 예전의 수십 명짜리 팀이 하던 일을 합니다. 그러므로 셀에서 회사로 가는 문턱은 낮아졌고, 문턱이 낮아진 만큼 그 문을 통과하는 방식이 중요해졌습니다.

우리의 철학

People → Project → Revenue → Company → Growth

한국인공지능커뮤니티가 기업을 만드는 순서는 사람에서 시작합니다. 아이디어나 자본이 아니라 사람입니다.

   PEOPLE          누가 무엇을 잘하는가 — Capability Node의 발견
     ↓
   PROJECT         필요한 사람이 결합한다 — Project Cell
     ↓
   REVENUE         고객이 돈을 낸다 — Work Compensation과 Value Sharing
     ↓
   COMPANY         반복되는 매출이 지속 조직을 요구한다 — 셀에서 회사로
     ↓
   GROWTH          회사가 크고, 사람이 크고, 다시 커뮤니티로 — Give Back

이 순서가 중요한 이유는, 각 단계가 앞 단계의 검증 위에 서기 때문입니다. 사람이 먼저 확인되고, 프로젝트로 협력이 확인되고, 매출로 시장이 확인된 뒤에야 회사가 생깁니다. 회사를 먼저 만들고 사람을 찾는 순서와 정반대입니다. 이 순서에서는 회사가 만들어질 때 이미 팀이 함께 일해 봤고, 정산을 해 봤고, 고객을 가지고 있습니다.

두 개의 흐름

커뮤니티 안에서 사업이 만들어지는 흐름은 크게 둘입니다.

① IDEA → PEOPLE → PROJECT → PoC → CUSTOMER → REVENUE → BUSINESS
   사업가·크리에이터·마케터가 주로 시작하는 흐름.
   문제를 먼저 보고, 사람을 모으고, 작게 검증하고, 고객을 얻는다.

② RESEARCH → TECHNOLOGY → MARKET → BUSINESS
   교수·연구원·개발자가 주로 시작하는 흐름.
   연구 결과가 기술이 되고, 기술이 시장을 찾고, 시장이 사업이 된다.

두 흐름은 서로를 필요로 합니다. ①은 기술이 부족해서 PoC(개념 검증)에서 멈추기 쉽고, ②는 시장이 없어서 TECHNOLOGY에서 멈추기 쉽습니다. Circle이 다섯 개(Research·Builder·Creator·Founder·Expert)로 나뉘어 있으면서도 Project Cell은 Circle을 넘어 구성되는 이유가 이것입니다. Research Circle의 연구가 Founder Circle의 사업가를 만나 ②가 ①과 합쳐질 때, 셀은 회사가 될 가능성이 가장 높아집니다.

프로토콜 조직이 회사를 낳는 방식

오픈소스 재단은 회사를 직접 만들지 않지만, 재단 위에서 수많은 회사가 생깁니다. 재단은 기술과 평판과 관계를 제공하고, 회사는 그 위에서 상업화를 담당하며, 회사가 커진 뒤에도 재단에 기여합니다. 할리우드식 프로젝트 조직에서는 한 작품을 위해 모인 팀이 흥행 뒤 제작사가 되기도 합니다. 우리는 이 두 모델에서 원리를 가져옵니다. 커뮤니티는 회사의 모회사가 아니라 회사가 태어나는 토양이다. 커뮤니티는 지분을 요구하지 않고, 회사는 커뮤니티를 떠나지 않습니다.

AI 10K Initiative

AI 10K Initiative는 커뮤니티에서 1만 개의 AI 사업·회사를 키우자는 이니셔티브입니다. 1만이라는 숫자는 목표라기보다 방향입니다. 몇 개의 큰 회사가 아니라 아주 많은 작은 사업이 생기는 생태계, 1인 사업과 5인 회사와 50인 회사가 같은 토양에서 자라는 생태계를 뜻합니다.

AI 10K는 사업을 다섯 단계로 봅니다. 단계는 규모가 아니라 "무엇이 검증되었는가"로 나뉩니다.

각 Stage에서 커뮤니티가 하는 일의 성격이 다릅니다. Stage 0에서 커뮤니티는 사람을 찾아 줍니다. Stage 1에서는 서류를 도와줍니다. Stage 2에서는 첫 고객과 인프라를 줍니다. Stage 3에서는 두 번째 고객과 투자자를 소개합니다. Stage 4에서는 아무것도 주지 않습니다. 대신 받습니다. Stage 4에 도달한 회사는 다음 Stage 0을 위한 Opportunity와 인프라와 경험의 공급자가 됩니다. 이것이 제27장의 Give Back이 사업 차원에서 작동하는 방식입니다.

Stage는 등급이 아닙니다. Stage 4 회사의 대표가 Stage 0 회원보다 커뮤니티 안에서 더 큰 권한을 갖지 않습니다. Stage는 "이 사업에 지금 무엇이 필요한가"를 커뮤니티가 파악하기 위한 표시이고, Stage 전환은 본인이 신고하고 Founder Circle이 확인합니다. Stage가 내려가는 것도 정상입니다. Stage 3에 있다가 고객을 잃고 Stage 1로 돌아가는 회사는 실패한 것이지 부정직한 것이 아닙니다. 실패에는 관대하되 부정직에는 엄격합니다.

앵커 조직의 역할

앵커 조직(Anchor Organization)은 생태계에 먼저 온 조직입니다. 각자 다른 것을 제공하고, 어느 하나도 커뮤니티를 소유하지 않습니다.

앵커 조직이 Project Cell에 참여할 때는 다른 참여자와 같은 규칙을 따릅니다. U09가 고객을 소개하면 Originator(소개자)로서 기본 24개월간 체감하는 소개 기여를 인정받고, 그 이상은 없습니다. H3Lab이 GPU를 제공하면 Charter에 Capital & Infra 기여로 적거나 Give Back으로 기록하며, 둘 중 어느 쪽인지는 시작할 때 정합니다. 앵커 조직의 구성원이 Council(운영위원회)에 있다면 자기 조직이 참여하는 셀의 사안에서는 회피(Recusal)합니다. Governance Power ≠ Economic Opportunity는 앵커에게 가장 먼저 적용됩니다.

앞으로 다른 기업·대학·연구기관·투자사가 같은 조건으로 앵커가 될 수 있습니다. 앵커의 자격은 "먼저 왔는가"가 아니라 "동등한 파트너로서 무엇을 제공하고 무엇을 하지 않기로 약속하는가"입니다.

운영원칙

Project Cell이 회사로 전환될 때의 기본값(Default)입니다. Project Charter(프로젝트 헌장)와 전환 시 작성하는 주주 간 계약으로 조정할 수 있습니다.

1. 전환은 이해관계 변경이다. 셀을 회사로 만드는 결정은 Project Lead 단독으로 하지 않는다. 참여자 전원의 합의(Charter에 정한 경우 다수결)로 한다. 실행은 빠르게, 이해관계 변경은 합의로.
2. 셀 참여자에게 먼저 제안한다. 회사를 만들기로 하면 셀의 모든 참여자에게 참여 여부와 형태(공동창업·지분 참여·고용·자문·불참)를 선택할 기회를 먼저 준다. 선택은 자유이며, 불참을 이유로 불이익을 주지 않는다.
3. 셀의 기여는 지분으로 이어진다. 기본값: 회사 설립 시 셀의 마지막 Contribution Matrix(기여도 평가표)를 창업 지분 논의의 출발점으로 삼는다. 출발점이지 결론이 아니다. 향후 기여·자본·위험을 반영해 조정한다. 불참자의 과거 기여는 지분 대신 정산·Value Sharing으로 마무리한다.
4. IP는 Charter가 정한 대로 따라간다. 셀이 만든 재사용 자산은 기본값대로 만든 참여자 공동 소유 + 커뮤니티 회원 비독점 재사용 라이선스다. 회사가 이 자산을 독점하려면 공동 소유자 전원의 합의와 정당한 대가가 필요하다. Background IP(참여 전 보유 자산)는 원소유자에게 남는다.
5. 고객 관계는 우회 금지 원칙을 따른다. 셀에서 만난 고객을 회사가 승계할 때 Originator의 소개 기여는 기본 24개월 체감 원칙대로 인정한다. 회사 설립이 Non-circumvention(우회 금지)의 예외가 되지 않는다.
6. 커뮤니티는 지분을 요구하지 않는다. 커뮤니티 기여분은 셀 단계의 잉여가치에서만 뗀다(기본값 5%). 회사가 된 뒤 매출이나 지분을 요구하지 않는다. 회사가 커뮤니티에 돌려주는 것은 Give Back으로, 자발적이고 기록된다.
7. 비독점. 회사는 커뮤니티 회원을 독점적으로 쓰지 않고, 커뮤니티는 회사에 독점적으로 사람을 보내지 않는다. 회사가 커뮤니티에서 사람을 구할 때는 공개 채널(Opportunity)로 하고, Junior Slot과 같은 규칙을 따른다.
8. 외주 인력풀 금지. 회사가 커뮤니티 회원에게 일을 맡길 때는 Project Cell을 만들고 Charter를 쓴다. Work Compensation(수행 대가)은 시장 단가 기준이며, "커뮤니티니까 싸게"는 허용하지 않는다. 반복적으로 이를 어기는 회사는 Opportunity 발행을 제한한다.
9. 채용은 알리고 한다. 셀 참여자를 회사로 채용하려면 셀 종료 전에 Lead와 참여자에게 알린다(제27장 참조).
10. 앵커도 예외가 아니다. 앵커 조직이 셀에서 회사를 만들거나 셀의 회사에 투자할 때 위 원칙을 그대로 적용하며, 관련 Council 구성원은 회피한다.

경계 상황을 몇 가지 봅니다. 셀 참여자 중 한 사람만 회사를 만들고 싶어 하고 나머지는 원하지 않는 경우, 그 사람은 회사를 만들 수 있습니다. 다만 셀의 공동 자산과 고객 관계는 위 원칙대로 처리하고, 나머지 참여자의 기여는 정산으로 마무리합니다. 회사가 잘 되었을 때 "우리가 함께 만든 것인데"라는 말이 나오지 않게 하려면, 전환 시점에 이 정리를 문서로 남겨야 합니다. 기여한 사람을 잊지 않는다는 원칙은 회사가 된 뒤에도 유효합니다.

셀이 아니라 회원 개인이 커뮤니티에서 얻은 아이디어로 회사를 만드는 경우는 어떨까요. 아이디어는 누구의 소유도 아닙니다. 다만 Closed Room에서 다른 회원이 공유한 미공개 사업전략을 가져다 쓰는 것은 정보 유출이고, Circle 세션에서 공개적으로 논의된 방향을 발전시키는 것은 정당합니다. 이 경계는 제12장의 Confidentiality 등급이 정합니다.

Case: Creator Circle에서 Stage 3까지

이것은 가상의 사례입니다.

크리에이터 서 씨는 Creator Circle의 AI Video 소그룹에서 활동하던 Contributor였습니다. 마케터 임 씨가 자기 고객사의 광고 영상 다섯 편을 AI로 제작할 사람을 찾는다는 Opportunity를 올렸고, 서 씨가 응답했습니다. 셀은 넷으로 구성됐습니다. 서 씨(Lead, 제작), 임 씨(Originator·고객 관리), Builder Circle의 개발자 오 씨(영상 파이프라인 자동화), 그리고 Junior Slot으로 들어온 신규회원 크리에이터 윤 씨. 계약금 3천만원. Charter는 Work Compensation을 먼저 지급하고 잉여가치를 Origination 25 · Execution 45 · Leadership 15 · Knowledge 15로 나누기로 했습니다. Stage 0에서 Stage 2까지 넉 달이 걸렸습니다.

납품 뒤 고객이 열 편을 더 주문했고, 임 씨의 다른 고객 둘이 합류했습니다. 석 달째 월 매출이 2천만원을 넘겼습니다. 서 씨가 Circle Leader에게 물었고, Founder Circle의 세션에서 전환을 논의했습니다. 참여자 넷이 모였습니다. 서 씨와 오 씨는 공동창업을 원했습니다. 임 씨는 자기 마케팅 회사를 유지하고 싶어서 지분 참여 없이 Originator 관계로 남기로 했습니다. 윤 씨는 회사에 합류하되 고용 형태를 원했습니다.

갈등은 두 군데서 생겼습니다. 첫째, 오 씨가 만든 영상 파이프라인의 귀속. Charter 기본값대로 서 씨·오 씨·윤 씨 공동 소유에 커뮤니티 비독점 라이선스였습니다. 회사가 이를 핵심 자산으로 쓰려면 독점이 필요하다고 서 씨가 주장했습니다. 오 씨는 공동 소유자이므로 합의했지만, 커뮤니티 라이선스를 회수하는 것은 거부했습니다. 결론은 "회사는 파이프라인을 자유롭게 쓰되, 커뮤니티 회원의 비독점 재사용 라이선스는 유지한다"였습니다. 회사의 경쟁력은 파이프라인 자체가 아니라 그것을 운영하는 팀이라는 판단이었습니다.

둘째, 임 씨의 고객 셋. 회사가 이 고객들과 직접 계약하게 되면서 임 씨의 몫이 문제가 됐습니다. 우회 금지 원칙대로 임 씨는 24개월간 체감하는 소개 기여를 인정받기로 했습니다. 첫 12개월은 해당 고객 매출의 일정 비율, 다음 12개월은 절반, 이후 종료. 임 씨는 그 뒤로도 새 고객을 소개할 때마다 새 Originator 기여를 인정받습니다.

Stage 1(사업자 등록)은 Expert Circle의 세무사 회원이 도왔고, Charter를 주주 간 계약으로 옮기는 템플릿을 썼습니다. Stage 2에서 3으로 가는 동안 H3Lab의 테스트베드에서 새 오픈모델을 먼저 검증했고, U09가 기업 고객 둘을 추가로 연결했습니다. U09의 소개 역시 같은 24개월 원칙을 따랐습니다. 설립 1년 뒤 회사는 직원 여섯 명, 월 매출 약 5천만원으로 Stage 3에 있습니다.

회사가 된 뒤 서 씨는 Creator Circle에 Opportunity 두 건을 발행했습니다. 둘 다 Project Cell을 만들고 Charter를 썼으며 Work Compensation은 시장 단가였습니다. 윤 씨는 이제 그 셀들의 Junior Slot에 들어오는 신규회원을 멘토링합니다. 서 씨의 회사는 커뮤니티에 지분을 주지 않았고, 커뮤니티는 요구하지 않았습니다. 대신 서 씨의 기여 기록에는 Project 3건, Mentoring 2건, Knowledge 1건이 새로 쌓였습니다.

Remember

• 커뮤니티가 기업을 만드는 순서는 People → Project → Revenue → Company → Growth입니다. 사람과 협력과 시장이 검증된 뒤에 회사가 생깁니다.
• AI 10K Initiative의 Stage 0~4는 규모가 아니라 검증의 단계이며, 커뮤니티는 단계마다 다른 것을 줍니다. Stage 4에서는 주는 대신 받습니다.
• 앵커 조직은 먼저 온 파트너일 뿐이며, 셀에 참여할 때는 다른 참여자와 같은 규칙을 따릅니다.
• 셀이 회사가 될 때 셀 참여자에게 먼저 제안하고, 기여는 지분 논의의 출발점이 되며, IP와 고객 관계는 Charter와 우회 금지 원칙을 그대로 따릅니다.
• 커뮤니티는 지분을 요구하지 않고, 회사는 커뮤니티를 외주 인력풀로 쓰지 않습니다. 함께 만든 가치는 실제 기여에 따라 공정하게 나눕니다.

"커뮤니티는 회사의 모회사가 아니라, 회사가 태어나는 토양이다."

이 책의 원칙이 10년 동안 지켜졌다면 한국인공지능커뮤니티는 어떤 모습이 되어 있는가. 그리고 그 모습에 도달하기 위해 이 책은 어떻게 고쳐져야 하는가.

질문에서 시작합니다

앞의 스물여덟 장은 "지금 무엇을 어떻게 할 것인가"를 다뤘습니다. 마지막 장은 방향을 바꿔 묻습니다. 이 원칙들이 10년 동안 지켜진다면 우리는 어디에 서 있을까요.

미래를 말하는 일은 조심스럽습니다. 회원 몇 명, 회사 몇 개, 매출 얼마 같은 숫자는 약속할 수 없고, 약속해서도 안 됩니다. 그러나 우리가 만들고 싶은 풍경은 말할 수 있습니다. 그 풍경은 세 문장으로 요약됩니다. 한국에서 AI를 잘하는 사람을 찾고 싶으면 이곳에 온다. 좋은 AI 아이디어를 사업화하고 싶으면 이곳에서 사람을 만난다. 여기서 성장한 사람이 또 다른 사람을 성장시킨다. 이 장은 세 문장을 한 절씩 풀고, 그 풍경 속 어느 하루를 그린 뒤, 이 책 자체의 미래를 이야기하며 끝납니다.

한국에서 AI를 잘하는 사람을 찾고 싶으면 이곳에 온다

첫 번째 문장은 발견에 관한 것입니다. Prologue에서 우리는 "사람이 많을수록 발견의 비용이 커진다"고 썼습니다. 10년 후 이 문장이 실현된 커뮤니티는 규모 때문이 아니라 기록 때문에 사람을 찾는 곳이 됩니다. 기업의 담당자가 "멀티모달 검색 시스템을 실제로 운영해 본 사람"을 찾을 때, 이력서와 자기소개 대신 Trust Capital(신뢰 자산)을 봅니다. 어떤 Project Cell(프로젝트 셀)에서 어떤 역할을 맡았고, 정산은 어떻게 마쳤고, 함께 일한 사람들이 다시 함께 일하고 싶어 했는지가 거기 있습니다.

이것이 가능해지려면 기록이 10년치 쌓여야 합니다. 첫해의 기록은 얇고, 셋째 해의 기록은 참고가 되고, 열 번째 해의 기록은 시장이 신뢰하는 기준이 됩니다. 신뢰는 말이 아니라 행동으로 쌓이고, 행동의 기록은 시간이 만드는 것입니다. 지금 한 건의 Closing Review(종료평가)를 성실히 쓰는 일은 10년 후의 이 풍경을 위한 투자입니다.

여기서 경계할 것이 하나 있습니다. "잘하는 사람을 찾는 곳"이 "유명한 사람이 모인 곳"으로 변질되는 일입니다. 우리가 기록하는 것은 명성이 아니라 기여입니다. 10년 후에도 신규회원에게 Junior Slot(신규회원 자리)이 열려 있고, 이름 없는 Contributor의 성실한 기록이 유명한 Fellow의 이름값보다 먼저 검색되는 곳이어야 합니다.

좋은 AI 아이디어를 사업화하고 싶으면 이곳에서 사람을 만난다

두 번째 문장은 결합에 관한 것입니다. 제28장은 커뮤니티가 기업을 만드는 순서를 People → Project → Revenue → Company → Growth로 정리했습니다. 10년 후 이 순서가 반복되어 몸에 밴 커뮤니티에서는, 아이디어를 가진 사람이 처음 하는 일이 투자자를 찾는 것도 회사를 세우는 것도 아닙니다. Circle에 문제를 가져와 사람을 만나는 것입니다.

이 문장이 실현된 풍경에는 두 가지 특징이 있습니다. 첫째, 결합이 빠릅니다. 기록된 신뢰가 있으므로 처음 만난 사람과도 한 주 안에 Project Charter(프로젝트 헌장)를 쓸 수 있습니다. 둘째, 해체가 깨끗합니다. 셀이 끝날 때 정산이 끝나고 기여가 기록되므로, 실패한 셀의 참여자들이 다음 셀에서 다시 만나는 데 앙금이 남지 않습니다. AI 10K Initiative의 Stage 0에서 Stage 4까지 오른 회사들이 다시 Stage 0의 Opportunity를 발행하는 순환이 여기서 돌아갑니다.

여기서도 경계가 필요합니다. 사업화가 활발해질수록 Governance Power ≠ Economic Opportunity의 원칙은 더 자주 시험받습니다. Council(운영위원회)의 구성원이 좋은 기회를 먼저 보는 위치에 있다는 사실은 10년이 지나도 변하지 않습니다. 그래서 회피(Recusal)와 공개 채널의 원칙은 초기의 임시 조치가 아니라 영구적인 설계입니다.

여기서 성장한 사람이 또 다른 사람을 성장시킨다

세 번째 문장은 순환에 관한 것입니다. 앞의 두 문장은 다른 조직도 부분적으로 이룰 수 있습니다. 인력 시장은 사람을 찾게 하고, 액셀러레이터는 사업을 만들게 합니다. 세 번째 문장이 우리를 다르게 만듭니다. 제27장의 Give Back은 강제 기부가 아니라 생태계의 순환 설계라고 했습니다. 10년 후 이 설계가 작동하는 커뮤니티에서는, 첫해에 Junior Slot으로 들어왔던 사람이 열 번째 해에는 Project Lead(프로젝트 리드)로서 다음 Junior Slot을 열고 있습니다.

이 순환에는 세대라는 개념이 생깁니다. 첫 세대는 규칙을 만들었고, 둘째 세대는 규칙 위에서 성장했고, 셋째 세대는 규칙을 고쳐 씁니다. 각 세대는 앞 세대에게 받은 것을 뒤 세대에게 돌려주되, 똑같은 방식으로 돌려주지 않습니다. 사람을 소모품처럼 다루지 않는다는 첫 번째 약속은 세대를 건너면서 더 구체적인 형태로 자랍니다.

어느 하루의 풍경

아래는 10년 후의 어느 하루를 그린 가상의 장면입니다. 등장인물은 모두 가상이며, Prologue에서 서로를 모른 채 흩어져 있던 여섯 사람과 같은 역할을 맡고 있습니다.

파운더 박 대표는 아침에 플랫폼의 Opportunity를 확인합니다. 제조 기업 한 곳이 검사 자동화 PoC(개념 검증)를 원한다는 건이 올라왔습니다. 박 대표는 지난 3년간 셀 네 개를 이끈 Professional입니다. 필요한 역량을 적어 팀을 제안하고, 오후에는 셀 둘의 Charter를 검토합니다. 셀 하나에서는 참여자 한 명이 범위 변경을 제안했고, 이해관계 변경이므로 저녁에 전원 합의 회의를 잡습니다. 실행은 빠르게, 이해관계 변경은 합의로.

연구자 이 교수는 Research Circle의 세션을 진행합니다. 연구실 학생 둘이 기업 데이터로 검증한 결과를 발표하고, Founder Circle에서 온 사업가 셋이 그 결과의 시장 가능성을 묻습니다. 3년 전 이 교수의 연구가 셀을 거쳐 회사가 되었고, 그 회사가 오늘 세션의 인프라 비용을 Give Back으로 냈습니다. 이 교수는 그 회사의 지분을 갖고 있지 않지만, 기여 기록에는 Research 12건, Mentoring 9건이 쌓여 있습니다.

연구원 정 박사는 H3Lab의 테스트베드에서 새 오픈모델을 돌리고 있습니다. 10년 전에는 GPU가 없어 노트에만 적던 아이디어였습니다. 지금은 Charter에 Capital & Infra 기여로 적힌 인프라 위에서 실험합니다. 결과가 나오면 Knowledge로 기록되고, 커뮤니티 회원은 그 벤치마크를 비독점 라이선스로 씁니다.

개발자 김 씨는 이제 영업을 직접 하지 않습니다. 하지 않아도 됩니다. Trust Capital이 대신 말해 주기 때문에 고객이 먼저 찾아옵니다. 오늘은 Junior Slot으로 들어온 신규회원과 코드 리뷰를 합니다. 10년 전 헐값에 일하며 정산 독촉도 못 하던 사람이, 이제 후배에게 "Work Compensation(수행 대가)은 시장 단가로 먼저 받는 것"이라고 가르칩니다. Contribution creates Trust, not Permanent Privilege. 김 씨의 신뢰도 매년 새 기록으로 갱신됩니다.

크리에이터 최 씨는 Creator Circle의 Circle Leader(서클 리더)입니다. 오전에 회원이 올린 이해상충 신고서를 확인했습니다. 최 씨 자신의 회사가 관련된 사안이어서 오늘 회의에서는 회피합니다. 리더는 회원보다 더 많은 것을 회피해야 하는 사람입니다. 오후에는 자기 회사의 Opportunity를 셀로 발행합니다. 시장 단가, Charter, Junior Slot. 회사가 커뮤니티를 외주 인력풀로 쓰지 않는다는 원칙을 리더 자신이 먼저 지킵니다.

마케터 한 팀장은 이제 오픈채팅방에 "함께 하실 분"이라고 올리지 않습니다. 플랫폼에서 Capability와 Trust를 보고 크리에이터 둘, 개발자 하나를 골라 캠페인 셀을 제안합니다. 사흘 안에 Charter가 나옵니다. 저녁에는 Expert Circle의 세션에서 지난 셀의 Closing Review를 공유합니다. Chatham House Rule이 적용되므로 고객 이름은 없지만, 실패한 부분은 그대로 적혀 있습니다. 실패에는 관대하되 부정직에는 엄격합니다.

여섯 사람은 서로 다른 Circle에 있고 서로 다른 회사에 속해 있습니다. 그러나 같은 규약 위에서 움직이고, 같은 기록을 신뢰합니다. Prologue의 여섯 사람과 다른 점은 단 하나입니다. 이들은 서로의 존재를 알고, 믿을 수 있는지 확인할 수 있으며, 함께 일하고 정산하는 방법을 가지고 있습니다.

이 조직론은 어디까지 갈 수 있는가

이 책은 AI 분야의 한국 커뮤니티를 위해 쓰였습니다. 그러나 프로토콜 조직(Protocol Organization)의 여섯 설계 원리는 AI에만 해당하는 것이 아닙니다. 독립성과 결합성, 사람을 Capability Node(역량 노드)로 보는 것, 기여의 기록, 행동의 원장으로서의 신뢰, 권력과 기회의 분리, 순환. 이 원리들은 실행 비용이 낮아지고 판단과 관계와 책임의 가치가 높아지는 모든 분야에 적용될 수 있습니다. 바이오, 콘텐츠, 교육, 법률 서비스처럼 전문가가 흩어져 있고 결합이 어려운 분야가 먼저 떠오릅니다.

다른 나라로의 확장도 생각할 수 있습니다. 규약과 기록은 언어를 넘어 옮길 수 있고, 신뢰의 원장은 국경에 묶이지 않습니다. 다만 우리는 이 점에서 겸손해야 합니다. 이 책의 원칙들은 아직 한 조직에서 검증되는 중이며, 다른 문화와 법 체계에서는 다르게 작동할 것입니다. 우리가 할 수 있는 최선은 이 실험을 성실히 기록하고, 무엇이 작동했고 무엇이 실패했는지를 숨기지 않는 것입니다. 실패의 기록이 다음 실험의 출발점이 됩니다. 확장은 우리가 선언하는 것이 아니라, 누군가 이 책을 자기 분야에 맞게 고쳐 쓸 때 일어나는 것입니다.

이 책은 완성본이 아닙니다

Prologue에서 우리는 "이 책은 완성된 답이 아니며 커뮤니티가 성장하면서 함께 고쳐질 것"이라고 썼습니다. 마지막 장에서 그 약속을 절차로 만듭니다. 이 책은 웹북이며, 헌법이자 문화책입니다. 헌법은 고치기 어려워야 하고, 문화책은 살아 있어야 합니다. 두 성격을 함께 지키기 위한 기본값은 다음과 같습니다.

이 책이 버전업되어야 하는 이유는 분명합니다. 이 책의 숫자들은 경험에서 나온 기본값이지 검증된 최적값이 아닙니다. Non-circumvention(우회 금지)의 24개월이 너무 길거나 짧다는 것은 셀 수십 개의 기록이 쌓여야 알 수 있습니다. 새로운 갈등 유형은 제11장의 목록에 없을 것이고, 새로운 기여 유형은 제19장의 범주에 없을 것입니다. 그때마다 이 책은 고쳐져야 합니다. 그러나 고쳐지지 않아야 하는 것도 있습니다. Our Promise의 다섯 문장과 Governance Power ≠ Economic Opportunity의 원칙입니다. 이것들이 바뀌는 날은 이 조직이 다른 조직이 되는 날입니다.

Remember

• 우리가 만들고 싶은 미래는 세 문장입니다. 한국에서 AI를 잘하는 사람을 찾고 싶으면 이곳에 온다. 좋은 AI 아이디어를 사업화하고 싶으면 이곳에서 사람을 만난다. 여기서 성장한 사람이 또 다른 사람을 성장시킨다.
• 그 미래는 규모가 아니라 10년치 기록으로 만들어집니다. 지금 쓰는 한 건의 Charter와 Closing Review가 그 기록의 첫 줄입니다.
• 이 조직론은 다른 분야와 다른 나라로 옮겨질 수 있지만, 그것은 선언이 아니라 성실한 기록과 누군가의 고쳐 쓰기로 일어납니다.
• 이 책은 버전이 있는 문서입니다. 기본값은 기록을 근거로 고치고, 약속은 고치지 않습니다.

이 책은 Prologue의 다섯 문장으로 시작했습니다. 같은 약속으로 닫습니다.

우리는 사람을 소모품처럼 다루지 않는다.

우리는 기여한 사람을 잊지 않는다.

우리는 신뢰를 지키는 사람과 더 큰 일을 함께한다.

우리는 서로의 전문성을 연결하여 혼자서는 만들 수 없는 가치를 만든다.

우리는 함께 만든 성과가 기여한 사람들에게 공정하게 돌아가도록 노력한다.

이 다섯 문장이 지켜지는 한, 이 책의 나머지는 얼마든지 고쳐 써도 좋습니다. 이 책은 그 약속을 지키기 위한 우리의 기준이고, 기준은 약속보다 자주 바뀝니다. 10년 후 이 책을 읽는 사람이 "이 조직은 사람을 이렇게 대하고, 이렇게 함께 일하려는 곳이구나"라고 여전히 말할 수 있다면, 우리는 만들고 싶은 미래에 도착한 것입니다.

"좋은 사람이 좋은 사람을 만나고, 좋은 기술이 좋은 사업을 만나며, 함께한 사람들이 혼자였을 때보다 더 크게 성장하는 조직. 그것을 우리는 함께 만든다."

이 부록은 읽는 문서가 아니라 쓰는 문서입니다. 앞의 29개 장이 "왜"와 "어떻게"를 설명했다면, 여기에 실린 일곱 개의 문서는 그 원칙을 실제 프로젝트의 첫날과 마지막 날에 종이 위로 옮기기 위한 것입니다. 회원은 아래 문서를 그대로 복사해 쓸 수 있습니다. 항목을 빼도 되고 더해도 됩니다. 다만 무엇을 뺐는지 참여자 전원이 알고 있어야 합니다.

일곱 문서는 프로젝트 생애주기 Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review의 각 지점에 놓입니다.

이 부록에 나오는 숫자(커뮤니티 기여분 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조 (목적)

1. 한국인공지능커뮤니티(Korea AI Community, 이하 "커뮤니티")는 AI 분야의 사업가·교수·연구원·개발자·크리에이터·마케터·전문가가 서로의 전문성을 존중하고, 신뢰를 기반으로 지식과 기술을 공유하며, 실제 프로젝트와 사업을 함께 만들고, 그 성과를 공정하게 나누며 함께 성장하는 프라이빗 프로페셔널 커뮤니티를 지향한다.
2. 커뮤니티의 가장 중요한 자산은 회원 수나 게시물 수가 아니라 사람, 전문역량, 기여, 신뢰, 협력의 경험, 그리고 함께 만들어낸 성과다.
3. 커뮤니티는 회원을 값싼 노동력이나 특정 회사의 외주 인력풀로 취급하지 않는다. 앵커 조직은 동등한 생태계 파트너 가운데 먼저 온 조직일 뿐이다.

제2조 (정의)

1. Capability Node(역량 노드)란 회원 한 사람을 말한다. 회원은 직함이 아니라 무엇을 할 수 있는가로 본다. Technical·Research·Business·Sales·Marketing·Creative·Network·Leadership·Capital은 모두 동등한 기여 가능성이다.
2. Project Cell(프로젝트 셀)이란 특정 목적을 위해 회원이 결합하여 만들고, 목적이 끝나면 해체되는 실행 단위(Virtual Company)를 말한다.
3. Circle(서클)이란 결과물을 만드는 실행 공동체를 말하며, Research Circle·Builder Circle·Creator Circle·Founder Circle·Expert Circle을 둔다.
4. Trust Capital이란 약속 준수·정산·일정·비밀유지·결과물·동료평가·재협업 의사의 기록으로 축적되는 신뢰의 자산을 말한다.
5. Originator란 기회 또는 고객을 가져온 사람, Contracting Party란 고객과 계약한 주체, Executor란 실제 업무를 수행한 사람, Project Lead란 Project Cell의 실행 판단을 맡은 사람을 말한다.

제3조 (회원)

1. 회원은 일정한 전문성·활동·추천 또는 검증을 거쳐 참여한다. 울타리의 목적은 기존 회원의 이익을 보호하는 것이 아니라 회원 간의 신뢰·정보·사업기회·관계를 보호하는 것이다.
2. 회원의 성장 단계는 Member → Verified → Contributor → Professional → Leader / Fellow로 한다. 이 단계는 권력의 서열이 아니라 신뢰와 책임의 깊이를 뜻한다. Verified 단계의 검증 경로 중 하나로 AI TEST 인증을 둔다.
3. 회원은 각자의 회사·직장·연구실을 유지한다. 커뮤니티는 회원의 독립성을 요구하지도, 침해하지도 않는다.
4. 신규회원이라도 역량과 신뢰를 보여주면 참여하고 성장할 수 있어야 한다. Project Cell은 신규회원에게 최소 한 자리(Junior Slot 등)를 열어 두는 것을 권장한다.

제4조 (기여)

1. 기여는 돈이나 노동시간만으로 측정하지 않는다. 기술·연구·지식·개발·콘텐츠 제작·고객 및 프로젝트 연결·영업·마케팅·투자·멘토링·소개·데이터·GPU 및 인프라·공간·운영·커뮤니티를 위해 사용한 시간은 모두 기여가 될 수 있다.
2. 플랫폼은 기여를 Knowledge·Research·Technology·Mentoring·Project·Event·Connection·Infrastructure로 분류하여 기록하고 축적한다. 기여한 사람을 잊지 않는다.
3. 과거의 기여는 신뢰를 만들지만 영구적인 권리를 만들지 않는다(Contribution creates Trust, not Permanent Privilege).

제5조 (신뢰)

1. 신뢰는 자기소개나 직함이 아니라 행동으로 만들어진다. 약속을 지켰는가, 맡은 일을 제대로 수행했는가, 정산을 투명하게 했는가, 동료를 존중했는가, 비밀을 지켰는가, 관계를 악용하지 않았는가, 함께 일한 사람들이 다시 함께 일하고 싶어 하는가를 기록한다.
2. 기술 실패·시장 실패·일정 실패는 실패다. 실패에는 관대하다. 책임회피·고의 은폐·고객 우회·정보 유출·기여 가로채기·비용 부풀리기·허위경력·대금 미정산·반복적 약속 위반은 부정직이다. 부정직에는 엄격하다.
3. 신뢰를 지키는 사람에게 더 깊은 네트워크와 더 큰 협력의 기회가 열린다.
4. Trust Capital은 인성평가가 아니라 행동의 원장이다. 기록은 당사자가 열람할 수 있고, 반론을 기록할 수 있다.

제6조 (협력과 Project Cell)

1. 프로젝트는 Idea → Proposal → Team → Project Charter → Contract → Execution → Settlement → Closing Review의 생애주기를 따른다.
2. 모든 Project Cell은 착수 전에 Project Charter(부록 B)를 작성한다. Charter는 1~2페이지로 하며 목적·범위·역할·Lead·의사결정 방식·보상 구조·IP·비밀유지·종료 조건·이해상충을 담는다.
3. 팀 구성의 기준은 Capability + Experience + Trust + Availability + Fit이다. 친분의 순서가 아니다.
4. 실행은 빠르게, 이해관계 변경은 합의로 한다. 실행 판단은 Project Lead가 한다. 보상 구조·범위·참여자 변경 등 이해관계의 변경은 참여자 합의(원칙적으로 전원, Charter에 정한 경우 다수결)로 한다.
5. AI 도구와 에이전트는 Project Cell의 구성원이 아니라 구성원의 역량을 증폭하는 장비다. 책임은 언제나 사람이 진다.

제7조 (보상)

1. 실제 수행한 업무의 대가(Work Compensation)는 시장 단가를 기준으로 먼저 지급한다.
2. 매출에서 직접비용과 Work Compensation을 뺀 잉여가치는 Contribution Matrix(부록 C)에 따라 나눈다(Value Sharing). 기여 범주는 Origination·Sales·Execution·Leadership & Risk·Capital & Infra·Network·Knowledge로 한다. 1/n 배분은 기본값이 아니다.
3. 잉여가치의 일정 비율(기본값 5%, 범위 3~10%)을 커뮤니티 기여분으로 하여 커뮤니티 운영·신규회원 성장·인프라에 사용한다. 커뮤니티 기여분은 Work Compensation에서 떼지 않고 잉여가치에서만 뗀다.
4. Originator는 첫 프로젝트에서 Origination 기여를 인정받고, 같은 고객의 후속 프로젝트에 대해 기본 24개월간 체감하는 소개 기여를 인정받는다. 영구 권리는 없다. 기간과 체감률은 Project Charter로 조정할 수 있다.
5. 커뮤니티를 통해 만난 고객·파트너와 소개자를 배제하고 직접 거래하는 것을 기본 24개월간 금지한다(Non-circumvention). 고객이 직접 원할 경우 소개자와 합의하고 기록한다. 고객은 누구의 소유물도 아니지만, 관계를 만든 기여는 인정한다.

제8조 (비밀유지)

1. 프로젝트 내부 정보·고객정보·계약조건·미공개 기술·사업전략은 보호한다. 경험·워크플로우·벤치마크·시장 인사이트는 신뢰 가능한 범위에서 공유한다.
2. 정보는 Public·Community·Cell-only·Restricted 네 등급으로 분류하며, 각 Project Cell은 Charter에서 기본 등급을 정한다.
3. 비밀유지의 수단으로 프로젝트 단위 NDA, Chatham House Rule, Closed Room을 둔다. 회원은 부록 F의 체크리스트를 따른다.
4. 비밀유지 의무는 Project Cell 해체 후에도 Charter가 정한 기간 동안 유지된다(기본값 24개월, 고객 계약이 더 긴 기간을 정한 경우 그에 따른다).

제9조 (이해상충과 권력·기회의 분리)

1. 운영의 권한과 사업의 기회는 분리한다(Governance Power ≠ Economic Opportunity). Council·임원·Circle Leader·오래된 회원이라는 이유로 사업기회를 우선 배정받지 않는다.
2. 사업기회는 공개 채널(플랫폼의 Opportunity)로 흐른다. 기회를 비공개로 특정인에게 먼저 배정하려면 그 사유를 기록한다.
3. Council·임원·Circle Leader는 자기 권한의 범위와 자기 이해가 걸린 사안에서 회피(Recusal)하며, 이해상충 신고서(부록 G)를 낸다.
4. 심사와 참여를 겸하지 않는다. 심사자는 심사하는 사안의 참여자가 될 수 없고, 참여자는 그 사안을 심사할 수 없다.

제10조 (분쟁)

1. 분쟁은 당사자 협의 → Project Lead 조정 → 윤리·분쟁위원회 → 외부 중재의 순서로 해결한다.
2. 단체방 공개 성토 등 감정적 여론재판을 금지한다. 분쟁 중인 사안을 당사자·조정자·위원회 외의 회원에게 공개하는 것은 그 자체로 신뢰 위반이다.
3. 윤리·분쟁위원회는 Council 산하에 두되 독립적으로 판단한다. 위원은 해당 사안의 당사자·같은 Project Cell 참여자·이해관계자일 경우 회피한다.
4. 제재는 경고 → 프로젝트 참여 제한 → 등급 조정 → 제명의 순서로 하며, 재심 절차를 둔다. 제재 사실은 기록하되, 공개 범위는 위원회가 정한다.

제11조 (개정)

1. 이 헌장은 Council이 개정안을 발의하고, Circle Leader 회의의 의견을 들은 뒤, 회원 의견수렴 기간(기본값 14일)을 거쳐 Council이 확정한다.
2. 제7조·제9조·제10조의 개정은 회원 의견수렴 기간을 두 배로 하며, 확정 전 반대 의견을 요약하여 함께 공개한다.
3. 개정된 헌장은 웹북에 버전·최종 개정일·변경사항을 표시하여 공개한다. 개정 전에 착수한 Project Cell은 해당 프로젝트가 끝날 때까지 착수 시점의 헌장을 따른다.

---

B. Project Charter

프로젝트 헌장 (1~2페이지 양식)

Project Lead가 초안을 쓰고, 참여자 전원이 읽고 서명한 뒤 고객과 계약합니다. 계약 후에 Charter를 고치려면 "이해관계 변경"이므로 참여자 합의가 필요합니다. 빈칸은 비워 두지 말고 "해당 없음"이라도 적습니다.

작성 후 이 문서의 비밀유지 등급은 기본적으로 Cell-only입니다. 고객명과 금액을 지운 요약본은 Community 등급으로 플랫폼의 Project 기록에 남깁니다.

---

C. Contribution Matrix

기여도 평가표

범주 정의

가중치 설정 방법

1. Project Charter 단계에서 범주별 가중치(합 100)를 먼저 정합니다. 프로젝트의 성격에 따라 다릅니다. 영업이 어려운 대기업 PoC라면 Origination·Sales가 크고, 기술 난이도가 높은 연구형 프로젝트라면 Execution·Knowledge가 큽니다.
2. 참여자 개인의 예상 비율은 착수 시점에 "가정"으로만 적고, 종료 시점에 재평가하는 것이 기본값입니다.
3. 가중치는 이해관계 사항이므로 변경은 참여자 합의로 합니다.
4. Originator의 후속 프로젝트 소개 기여는 Origination 범주 안에서 체감합니다. 기본값: 첫 계약일부터 12개월까지 100%, 13~24개월 50%, 이후 0%. Charter로 조정할 수 있습니다.

평가 시점

합산 규칙

1. 각 참여자는 범주마다 참여자 전원에 대한 배분안(합 100%)을 제출합니다. 본인 몫도 포함합니다.
2. 자기평가는 본인이 제출한 배분안 중 본인 몫, 동료평가는 다른 참여자들이 제출한 배분안의 평균, Lead 평가는 Project Lead가 제출한 배분안입니다.
3. 합산 비율의 기본값은 자기평가 20% : 동료평가 50% : Lead 평가 30%입니다. Lead 본인의 몫에 대해서는 Lead 평가를 제외하고 동료평가 70% : 자기평가 30%로 합니다.
4. 범주별 합산 결과를 100%로 정규화한 뒤, 범주 가중치를 곱하여 참여자별 총 기여 비율을 구합니다.
5. 결과는 소수점 첫째 자리까지 쓰고, 참여자 전원이 합의하면 5% 단위로 반올림할 수 있습니다.

이견이 있을 때

1. 어느 참여자의 자기평가와 동료평가 평균의 차이가 20%포인트를 넘으면 그 범주에 대해 반드시 대화합니다. 숫자만 제출하고 끝내지 않습니다.
2. 대화로 합의되지 않으면 Project Lead가 조정안을 냅니다. Lead 본인의 몫이 쟁점이면 Lead가 아닌 참여자 중 한 명이 조정합니다.
3. 조정안에도 합의하지 못하면 윤리·분쟁위원회에 회부합니다. 회부 중에도 Work Compensation은 먼저 지급합니다. 다투는 것은 Value Sharing이지 수행 대가가 아닙니다.
4. 분쟁 사실과 결과는 Trust Capital에 기록됩니다. 다만 "이견이 있었다"는 사실 자체는 감점이 아닙니다. 합의 절차를 거부하거나 은폐한 경우가 감점입니다.

작성 예시 (가상)

프로젝트: 제조업 A사 품질검사 AI PoC. 참여자 4명. 파운더 박 대표(Originator·Project Lead), 개발자 김 씨(모델 개발), 연구자 이 박사(알고리즘 설계·기술 발표), 크리에이터 최 씨(데모 영상·발표자료). 종료 시점 평가. 아래 표는 자기·동료·Lead 평가를 합산하고 정규화한 결과입니다.

계산 예: 박 대표 = 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을 비율대로 줄이지 않고, 먼저 참여자 합의를 거칩니다.

양식

작성 예시 (가상)

부록 C의 예시와 같은 프로젝트. 계약금액 6,000만원(부가세 제외). 커뮤니티 기여분 기본값 5% 적용. Contribution Matrix 최종 비율 45 : 25 : 20 : 10.

이 예시에서 가장 많이 받은 사람은 Originator이자 Lead인 박 대표가 아니라 개발자 김 씨입니다. Work Compensation을 먼저 지급하는 구조에서는 실제로 가장 많이 일한 사람이 먼저 보상받고, 기회를 만들고 위험을 진 사람은 잉여가치에서 보상받습니다. 두 층이 서로를 대신하지 않습니다.

---

E. Project Closing Review

프로젝트 종료평가

정산 완료 후 2주 이내에 Project Lead가 주관합니다. 참여자 전원이 한자리에 모여 작성하는 것을 기본값으로 합니다. 이 문서의 목적은 책임을 묻는 것이 아니라 다음 프로젝트를 더 잘하기 위한 것입니다. 다만 부정직이 발견되면 이 문서와 별개로 윤리·분쟁위원회 절차를 따릅니다.

실패 유형 분류

안 된 것이 있다면 아래 중 어디에 해당하는지 표시합니다. 하나의 프로젝트에 여러 유형이 있을 수 있습니다. 앞의 세 가지는 실패이고, 뒤의 두 가지는 부정직입니다. 구분이 중요합니다.

실패 유형이 책임회피 또는 고의 은폐로 분류되면, 해당 참여자는 이 문서에 반론을 쓸 권리가 있고, 분류의 최종 확정은 윤리·분쟁위원회가 합니다. Project Cell 내부에서 확정하지 않습니다.

재협업 의사

참여자 각자가 다른 참여자 각각에 대해 표시합니다. 결과는 본인과 윤리·분쟁위원회만 열람할 수 있으며, Trust Capital에는 "재협업 의사 긍정 비율"만 기록됩니다. 이 항목은 Lead가 대신 쓸 수 없습니다.

표기: ◎ 다시 함께 일하고 싶다 / ○ 조건에 따라 / △ 이번 역할로는 어렵다 / 빈칸은 미응답.

재사용 가능한 자산

커뮤니티에 공유할 교훈

고객명·금액·미공개 기술을 제외하고, 같은 종류의 프로젝트를 하는 다음 Project Cell이 알아야 할 것을 씁니다. Community 등급으로 플랫폼 Knowledge 기여에 기록됩니다. "실제로 해본 사람만 아는 것"을 씁니다.

Trust Capital 반영 항목

Project Lead가 참여자 전원 확인 아래 체크합니다. 항목별로 "예 / 아니오 / 해당 없음"으로 답하고, "아니오"에는 한 줄 사유를 씁니다.

---

F. Confidentiality Checklist

비밀유지 체크리스트

Project Lead가 착수 시 체크하고, 참여자 각자가 진행 중과 종료 시 체크합니다. 체크하지 못한 항목이 있으면 그 이유를 Lead에게 알립니다. 체크리스트는 사람을 의심하기 위한 것이 아니라, 실수로 신뢰를 잃는 일을 막기 위한 것입니다.

정보 등급 분류표

등급이 불분명하면 한 단계 높은 등급으로 취급합니다. 등급을 낮추는 결정은 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개월)을 참여자 전원이 확인했다.

메신저 방 취급 규칙

1. 프로젝트 채널은 Closed Room으로만 만듭니다. 초대 링크를 공개하지 않습니다.
2. 채널에 들어온 사람은 Charter의 참여자 명단과 일치해야 합니다. 명단에 없는 사람이 있으면 Lead가 즉시 내보내고 기록합니다.
3. Restricted 정보는 메신저에 올리지 않습니다. 저장소 링크로 대신하고, 링크의 접근 권한을 별도로 관리합니다.
4. 프로젝트 채널의 대화를 다른 방으로 복사·전달하지 않습니다. 캡처도 같습니다.
5. 프로젝트가 끝난 채널은 "보관"으로 전환합니다. 계속 대화하고 싶으면 새 방을 만듭니다.
6. 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에 준하여 취급하며 기록·전달하지 않습니다.
• 모임의 요약을 플랫폼에 남길 때는 발언자·조직명·고객명을 뺀 인사이트만 남깁니다.
• 녹음·녹화는 참석자 전원 동의 없이 하지 않습니다.

유출 발생 시 대응 절차

1. 즉시 보고: 유출을 알게 된 사람은 24시간 이내에 Project Lead에게 알립니다. 본인의 실수라도 같습니다. 스스로 보고한 유출과 은폐된 유출은 Trust Capital에서 다르게 기록됩니다.
2. 범위 확인: Lead는 무엇이, 어디까지, 누구에게 나갔는지 확인하고 기록합니다.
3. 확산 차단: 해당 채널·링크·파일의 접근을 즉시 차단합니다.
4. 고객 통보: Restricted 정보가 포함되었으면 Contracting Party가 고객에게 계약에 따라 통보합니다. 통보를 늦추지 않습니다.
5. 위원회 회부: 고의 여부가 불분명하거나 Restricted 정보가 포함되었으면 윤리·분쟁위원회에 회부합니다. 실수에 의한 Community 등급 유출은 Lead 선에서 기록으로 마무리할 수 있습니다.
6. 여론재판 금지: 유출자의 이름을 단체방에서 거론하지 않습니다. 절차는 위원회가 진행합니다.

---

G. Conflict of Interest Declaration

이해상충 신고서

이해상충은 잘못이 아닙니다. 신고하지 않는 것이 잘못입니다. 이해가 겹치는 상황에서 스스로 물러나는 것(Recusal)은 신뢰를 잃는 행동이 아니라 신뢰를 쌓는 행동입니다.

신고가 필요한 상황

• Council·임원·Circle Leader·윤리·분쟁위원이 자기 회사, 자기가 투자한 회사, 가족의 회사가 관련된 사안을 다루게 될 때.
• 공개된 Opportunity의 심사·배정에 관여하는 사람이 그 Opportunity에 참여하고 싶을 때.
• Project Cell 참여자가 고객사·경쟁사와 고용·자문·투자 관계에 있을 때.
• 회원 검증(Verified 이상 승급) 심사자가 심사 대상과 같은 회사·연구실·Project Cell에 속해 있을 때.
• 윤리·분쟁위원이 분쟁 당사자와 최근 24개월 이내 같은 Project Cell에 있었을 때.
• Circle Leader가 자기 Circle의 예산·인프라(GPU 등)를 자기 프로젝트에 배정하려 할 때.
• 앵커 조직 소속 회원이 앵커 조직의 이해가 걸린 커뮤니티 의사결정에 참여할 때.
• 위에 없더라도 "이 결정으로 내가 이익을 보거나 손해를 볼 수 있는가"에 "예"라고 답하게 될 때.

양식

신고서는 사안이 종료된 후에도 보관합니다. 신고했어야 할 이해상충을 신고하지 않은 사실이 나중에 드러나면, 그 결정은 재검토 대상이 되고, 신고하지 않은 사실은 부정직으로 기록됩니다. 신고하고 물러난 사실은 Trust Capital에 긍정적으로 기록됩니다.

---

양식의 버전과 개정

이 부록의 일곱 문서는 한국인공지능커뮤니티의 기본값입니다. 프로젝트 단위에서는 Project Charter로, 커뮤니티 단위에서는 Council의 개정으로 바뀔 수 있습니다. 바뀌지 않는 것은 문서 뒤에 있는 원칙입니다. 사람을 소모품처럼 다루지 않고, 기여한 사람을 잊지 않으며, 함께 만든 가치를 실제 기여에 따라 공정하게 나눈다는 것입니다.

양식의 개정은 다음 원칙을 따릅니다.

1. 개정 주체: Council이 개정합니다. 회원은 누구나 개정을 제안할 수 있으며, 실제 프로젝트에서 양식이 작동하지 않았던 경험은 가장 좋은 개정 제안입니다.
2. 개정 절차: 헌장(A)은 헌장 제11조의 절차를 따릅니다. 나머지 양식(B~G)은 Council이 개정안을 공개하고 회원 의견수렴 기간(기본값 14일)을 거쳐 확정합니다.
3. 버전 표시: 웹북(aiopen.org)의 이 부록 상단에 현재 버전, 최종 개정일, 변경사항 요약을 표시합니다. 예: 현재 버전 v1.0 / 최종 개정일 YYYY-MM-DD / 변경사항: 최초 제정.
4. 적용 시점: 개정 전에 Project Charter에 서명한 Project Cell은 그 프로젝트가 끝날 때까지 서명 당시의 양식을 따릅니다. 참여자 전원이 합의하면 새 양식으로 옮길 수 있습니다.
5. 이력 보존: 이전 버전은 삭제하지 않고 웹북에서 열람할 수 있게 둡니다. 어느 프로젝트가 어느 버전을 따랐는지 확인할 수 있어야 합니다.

문서는 신뢰를 대신하지 못합니다. 그러나 좋은 문서는 신뢰가 오해로 깨지는 일을 줄여 줍니다. 이 양식들이 회원 여러분의 다음 프로젝트에서 그런 역할을 하기를 바랍니다.