실력에는 여러 종류가 있다

기술이 뛰어난 사람만 실력자인가. 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가 실행을 싸게 만들수록 판단·관계·책임의 값은 올라갑니다. 기술 역량의 중심도 "만드는 것"에서 "무엇을 만들지 판단하고 검증하는 것"으로 옮겨갑니다.
• 보이지 않는 기여는 보상할 수 없습니다. 저평가되기 쉬운 역량일수록 기록의 형식을 미리 정합니다.

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