Project Lead와 의사결정

모두가 동등한 팀은 누가 결정합니까? 이 장은 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.

"실행은 빠르게, 이해관계 변경은 합의로."