제20장

보상을 어떻게 설계할 것인가

개정 메모: 사례 속 비율과 산식은 확정 규정이 아닙니다. 프로젝트 업무보수는 실제 계약으로 사전 합의하고, 사업협동조합의 결산상 잉여금 배당과 구분합니다. 조직 수수료·분담·복지 출연도 법률·회계·세무 근거 없이 고정 비율로 적용하지 않습니다.

20v1.3-draft · 2026-09-17
제20장 대표 이미지: 유동성 현금 흐름과 장기적 신뢰 자본의 이중 하모니
CHAPTER 20 ART · 즉각적인 현금성 보상과 영구적인 가치 지분이 조화롭게 교차하는 2층 보상 아키텍처

개정 메모: 사례 속 비율과 산식은 확정 규정이 아닙니다. 프로젝트 업무보수는 실제 계약으로 사전 합의하고, 사업협동조합의 결산상 잉여금 배당과 구분합니다. 조직 수수료·분담·복지 출연도 법률·회계·세무 근거 없이 고정 비율로 적용하지 않습니다.

돈이 들어온 뒤에 나누는 방법을 정하면 늦습니다. 이 장은 보상을 두 층으로 나누고, 시작하기 전에 합의하고, 끝날 때 숫자로 정산하는 방법을 다룹니다.

질문에서 시작합니다

가상의 상황입니다. 어느 물류 스타트업의 고객 응대 자동화 프로젝트가 끝났습니다. 계약금 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 재원 = 잉여가치 − 커뮤니티 기여분
항목정의기본값과 원칙
매출고객이 계약에 따라 지불한 금액 (부가세 제외)계약주체의 입금 기준. 분할 입금이면 입금 시점마다 부분 정산 가능
직접비용이 프로젝트 때문에 실제로 지출된 외부 비용영수증이 있는 것만. 참여자 개인의 장비·시간은 직접비용이 아니라 기여
Work Compensation참여자가 실제 수행한 업무의 대가시장 단가 기준. Charter에 역할별 단가 또는 정액을 미리 적음. 잉여가치보다 먼저, 입금 후 기본 14일 이내 지급
커뮤니티 기여분커뮤니티 운영·신규회원 성장·인프라에 쓰는 몫잉여가치의 5% (범위 3~10%). Work Compensation에서는 떼지 않음
Value Sharing남은 잉여가치를 Contribution Matrix 비율로 배분1/n은 기본값이 아님. Charter에서 예상 비율을 합의하고 종료 시 확정

커뮤니티 기여분을 잉여가치에서만 떼는 이유는 분명합니다. 수행 대가에서 떼면 커뮤니티가 회원의 노동에서 수수료를 걷는 것이 됩니다. 그것은 플랫폼 노동의 구조이지 우리가 만들려는 구조가 아닙니다. 잉여가치가 없으면 커뮤니티 기여분도 없습니다. 커뮤니티는 회원이 함께 만든 추가가치에서만, 그것도 작은 몫만 가져갑니다.

배분 절차

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 사용료, 외부 서버 임대)영수증 기준으로 매출에서 먼저 차감. 기여로 이중 계산하지 않음
Work Compensation으로 정산회원이 보유한 자산을 대여 형태로 제공할 때 (자기 GPU 서버, 사무 공간)Charter에 시장 임대료 이하의 정액을 적고 수행 대가와 함께 지급
Capital & Infra 기여로 인정무상으로 제공하고 프로젝트의 성패를 함께 지기로 할 때Contribution Matrix의 Capital & Infra 범주에서 잉여가치의 일부를 받음

원칙은 하나입니다. 같은 자산을 두 번 세지 않습니다. 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만원(부가세 제외)이 입금됐습니다.

항목금액
매출50,000,000원
직접비용 (외부 API 사용료 150만원, 데이터 라벨링 외주 200만원, 출장·회의 50만원)−4,000,000원
Work Compensation (5명 합계)−26,000,000원
잉여가치20,000,000원
커뮤니티 기여분 (5%)−1,000,000원
Value Sharing 재원19,000,000원

Contribution Matrix는 참여자 전원 합의로 다음과 같이 확정됐습니다.

참여자주요 기여 범주비율Value Sharing
한 씨Origination 20 + Sales 525%4,750,000원
박 대표Leadership & Risk 20 + Sales 525%4,750,000원
최 씨Execution(범위 밖 40시간) 15 + Knowledge(템플릿) 520%3,800,000원
이 교수Knowledge 10 + Research 515%2,850,000원
정 씨Execution 1010%1,900,000원
강 씨Capital & Infra 55%950,000원
합계100%19,000,000원

최종 수령액.

참여자Work CompensationValue Sharing합계
최 씨12,000,000원3,800,000원15,800,000원
박 대표4,000,000원4,750,000원8,750,000원
정 씨5,000,000원1,900,000원6,900,000원
한 씨2,000,000원4,750,000원6,750,000원
이 교수3,000,000원2,850,000원5,850,000원
강 씨0원950,000원950,000원
커뮤니티 기여분1,000,000원
직접비용4,000,000원
합계50,000,000원

이 표가 말하는 것. 가장 오래 일한 최 씨가 가장 많이 받았습니다. 시간이 무시되지 않았습니다. 그러나 한 씨는 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 기여로 매번 인정합니다. 영구 로열티는 기본값이 아닙니다.

"일한 것은 먼저 보상하고, 추가가치는 기여에 따라 나눈다. 그리고 그 방법은 돈이 들어오기 전에 정한다."