프로젝트는 어떻게 시작하는가

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

질문에서 시작합니다

가상의 상황입니다. 마케터 한 씨는 오래 알고 지낸 화장품 브랜드의 마케팅 담당자로부터 연락을 받았습니다. 신제품 론칭에 맞춰 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일을 없앤다."