기여란 무엇인가

프로젝트에 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. 한 사람을 한 칸에 넣지 않고 행동을 칸에 넣습니다.
• 프로젝트 기여는 정산으로, 커뮤니티 기여는 신뢰와 기회로 이어집니다. 두 흐름은 다르지만 서로를 먹여 살립니다.
• 보이지 않는 기여(위험부담, 실패한 영업, 조율)는 미리 이름 붙이고, 과정을 기록하고, 동료가 증언해서 드러냅니다.
• 기록은 사후가 아니라 진행 중에 합니다. 한 줄이면 됩니다. 기록은 관료주의가 아니라 기억의 외주입니다.

"기여한 사람을 잊지 않는다. 잊지 않으려면 기록하고, 기록하려면 무엇이 기여인지 먼저 합의한다."