동의 vs. 합의: 그룹의 결정 방식을 변화시키는 이의 제기 테스트

제안서는 작성하는 데 세 주가 걸렸고, 사라지는 데는 사십 분이 걸렸다. 누군가 반대해서가 아니라 — 아무도 반대하지 않았다. 한 명의 위원이 "아직 완전히 편안하지 않다"고 했고, 두 번째 위원은 "더 많은 시간을 갖고 싶다"고 했으며, 그룹의 규칙 — 모두가 동의해야 한다 — 이 두 개의 명확하지 않은 주저함을 거부권으로 바꾸었다. 제안서는 아무도 구체적으로 설명할 수 없는 수정 작업을 위해 돌아갔다.

이제 다른 규칙에 따라 회의를 다시 진행합니다. 진행자는 "모두 동의하나요?" 대신 "이것이 해를 끼칠 이유가 있는 사람 있나요 — 논리적인 반대 의견이 있나요?"라고 묻습니다. 두 가지 주저함이 표현되고, 검토되며 우려사항으로 기록됩니다: 실제 정보로, 추적할 가치가 있으며, 차단하는 것이 아닙니다. 제안은 검토 날짜와 함께 통과됩니다. 만약 우려사항이 예언적이라면, 검토 시 증거를 가지고 이를 포착합니다.

합의와 동의의 차이는 바로 이것입니다 — 대부분의 조직에서 서로 바꿔 사용할 수 있는 두 단어가 실제로는 두 가지 다른 의사결정 규칙을 나타냅니다. 이 게시물은 적용된 비교입니다: 동의를 작동하게 만드는 이의 제기 대 우려 메커니즘, 주요 프레임워크가 이의 제기 테스트를 다르게 정의하는 어색한 사실, 그리고 어떤 규칙이 어떤 결정에 적합한지 선택하는 방법입니다. (정의에 대한 심층 분석은 동의 기반 및 합의 의사결정에 대한 우리의 참조 페이지에 있습니다 — 이 게시물은 그것들을 운영하는 것에 관한 것입니다.)

두 가지 규칙, 두 가지 다른 질문

합의는 더 오래되고 더 요구가 많은 규칙입니다: 그룹은 모든 참가자가 긍정적으로 수용할 때까지 제안을 개발하고 다듬습니다. 그 약속은 완전한 소유권입니다 — 나중에 아무도 "나는 이것에 동의하지 않았다"고 말할 수 없습니다 — 그리고 이를 진지하게 사용하는 전통(협동조합, 퀘이커 관습, 지역 사회 회의)에서 그 소유권이 핵심입니다: 결정은 그룹의 정체성이므로 모든 사람이 그것을 가져야 합니다.

동의는 사회적 전통에서 부담을 전환합니다: 제안은 아무도 합리적이고 중요한 반대 의견을 제기할 수 없을 때 채택됩니다 — 제안이 그룹의 목표에 해를 끼치거나 후퇴시킬 것이라는 주장입니다. 제안이 마음에 들거나 선호하거나 심지어 좋아할 필요는 없습니다. 기준은 "시도하기에 충분히 안전하고, 지금은 충분히 좋다"는 것이며, 이는 Sociocracy 3.0에서 사용하는 표현입니다 — 결정이 수정 가능하다는 중요한 동반자가 있어 시도가 진정으로 안전합니다.

변화한 점을 주목하세요: 합의는 동의를 최적화하고, 동의는 논의된 해악의 부재를 최적화합니다. 이는 동의의 전체 무게가 하나의 정의에 달려 있다는 것을 의미합니다 — 무엇이 이의로 간주되는가? 그곳에 흥미로운 기계가 존재합니다.

하중 지지 기계: 반대 vs. 우려

동의를 작동하게 만드는 구분 — 그리고 이를 채택하는 대부분의 팀이 간과하는 점 — 은 모든 불편함이 차단되는 것은 아니라는 것입니다. 우려는 걱정, 선호, 무언가 잘못될 수 있다는 직관입니다: 이는 표현되고, 기록되며, 결정에 첨부되지만 채택을 막지는 않습니다. 반대는 주장입니다: 제안이 해를 끼치거나 그룹의 목표에서 멀어지게 할 이유를 명시한 것으로, 이는 주장으로서 검토를 견뎌야 합니다.

두 가지 결과가 따른다. 첫째, 반대는 거부가 아닌 선물이다: 반대는 특정한 해를 지적하기 때문에 그룹에게 제안을 개선하는 방법을 정확히 알려준다 — 사회적 과정은 반대를 포기하는 것이 아니라 수정함으로써 해결한다. 둘째, 우려가 낭비되지 않는다: 개방 제안을 무산시킨 모호한 불안은 검토 날짜가 있는 기록된 정보가 되어, 마땅히 있어야 할 조기 경고 시스템이 된다 — 설명되지 않은 거부 대신에.

이 메커니즘은 이 블로그의 독자들에게 익숙하게 들릴 것입니다: 그것은 거버넌스에 적용되는 논증 기준입니다. 블록은 반드시 주장이어야 하며; 주장은 이유를 가져야 하고; 이유는 검토되고 답변될 수 있습니다. 숙의를 생산적으로 만드는 동일한 기준이 의사결정 규칙을 실행 가능하게 만듭니다.

어색한 사실: 프레임워크가 테스트를 다르게 정의한다

팀들이 "동의"를 채택한 후에만 발견하는 것은 주요 프레임워크들이 유효한 이의 제기가 무엇인지에 대해 동의하지 않는다는 것입니다. 그들의 공식 문서에서:

같은 단어, 실질적으로 다른 테스트 — S3의 게이트는 개선 주장을 허용하지만, 홀라크라시의 게이트는 역할에 기반한 제안으로 생성된 피해만을 허용합니다. 둘 다 "정확한" 것은 아니며, 보호와 속도 사이의 다른 트레이드오프를 인코딩합니다. 이것이 만들어내는 실용적인 규칙: 합의를 채택하는 팀은 그들의 반대 테스트를 문서화해야 합니다. 문서화된 테스트 없이 "우리는 합의를 사용합니다"라고 말하는 것은 진행자가 표준을 즉흥적으로 결정하게 하며, 이는 합의가 제거하고자 하는 임의성을 다시 도입합니다.

각 규칙이 그 비용을 정당화할 때

동의는 수정 가능한 운영 결정에 승리합니다 — 정책, 프로세스, 도구 선택, 역할 정의: 자연적인 검토 날짜가 있는 모든 것. 그 속도 이점은 그룹 규모와 함께 증가합니다(합의 비용은 인원 수에 따라 가혹하게 증가합니다), 그리고 그 안전성은 결코 떨어져서는 안 되는 쌍에서 옵니다: 동의는 때문에 결정이 수정 가능하기 때문에 채택됩니다. 검토 날짜 없이 동의는 단순한 결정에 불과합니다.

합의는 정체성 계층에서 더 큰 비용을 발생시킨다 — 미션 변경, 합병, 가치, 완전한 소유권 없이는 되돌리기 어렵고 공허한 약속들. 아무도 반대하지 않았지만 그룹의 절반이 소유하지 않는 전략은 절반의 힘으로 실행될 것이다; 이러한 결정에 대해, 비싼 질문 — "당신은 이것을 긍정적으로 소유하고 있습니까?" — 가 올바른 질문이다. (우리의 결정 기록 가이드 독자들은 되돌리기 비용 논리를 인식할 것이다: 결정이 되돌리기 어려울수록 더 많은 프로세스가 필요하다.)

그리고 언급할 가치가 있는 경계: 두 가지 모두 숙고하는 집단을 위한 결정 규칙입니다. 어느 것도 고장 난 숙고를 고치지 않습니다 — 반대 의견을 억압하는 방은 잘못된 합의와 공허한 동의를 모두 만들어낼 것이기 때문에, 구조적 반대 조치가 결정 규칙의 선택 이전에 이루어져야 하고, 그 이후가 아닙니다.

동의 잘 관리하기: 네 가지 실천 방법

동의가 작동하도록 만드는 팀은 네 가지 습관을 공유합니다 — 각 습관은 알려진 실패 모드를 차단합니다:

동의는 소수자를 압박하는 경량 합의에 불과하지 않나요?

강철맨은 그 힘을 충분히 받을 자격이 있다: 동의는 채택의 기준을 낮추고, 낮아진 기준은 남용될 수 있다. 모든 불편한 논쟁을 "우려, 반대가 아닌" 것으로 규정하는 조정자는 무엇이든 밀어붙일 수 있다; 다수는 소수가 두려워하지만 아직 반대할 수 없는 제안을 채택할 수 있다 — 직관은 종종 표현 가능한 이유에 앞선다, 그리고 동의는 구조적으로 표현할 수 있는 사람에게 특권을 부여한다. 합의는 그 비용이 무엇이든 모든 구성원에게 무조건적인 제동 장치를 제공한다.

답변은 구조적이지, 수사적이지 않다. 서면 이의 제기 테스트는 양쪽 모두에 제약을 가한다 — 이는 이의 제기자만큼이나 진행자를 제약하며, 논란이 있는 판결은 서면 기준에 따라 검토될 수 있다. 우려 등록은 직관 문제에 대한 답변을 제공한다: 아직 논의할 수 없는 두려움이 기록된 우려로 변환되어 검토 촉발 요소가 되며, 이는 실제로 합의가 제공하는 것보다 더 많은 보호를 제공한다 — 표현할 수 없는 불안이 모든 것을 차단하거나 어쨌든 사회적으로 압도당하는 경우가 많기 때문이다. 그리고 재검토 가능성 쌍은 피해를 제한한다: 당신의 우려에 따라 채택된 사항은 당신의 우려가 예정한 검토에 의해 다시 열릴 수 있다.

정직한 양보: 진정으로 신뢰가 낮은 그룹에서는 어떤 결정 규칙도 신뢰를 해결하지 못한다 — 그곳에서는 동의가 조작될 것이고, 합의는 교착 상태에 빠질 것이다. 결정 규칙은 그룹의 목표를 널리 수용하는 사람들 사이에 권력을 분배하지만, 그 수용을 대체할 수는 없다.

Argumentree가 이의 제기 테스트를 실행하는 방법

동의의 기계는 논증 기준입니다 — 이는 정확히 Argumentree의 소시오크라시 도구가 본질적으로 구조화하는 것입니다. 제안은 주장이고, 반대는 이유를 가져야 하는 반론입니다; 그룹은 이를 공개적으로 검토하며, 반대를 해결하는 수정안은 논증 트리가 발전함에 따라 가시화됩니다. 서면 반대 테스트는 더 이상 라미네이팅된 카드가 아니라 논의 자체의 구조가 됩니다.

우려 사항도 1급 대우를 받습니다: 결정에 대해 기록되고, 검토 날짜와 함께 기록에 보존되어 그룹의 조기 경고 시스템이 실제로 축적됩니다. 검토가 도착하면 원래의 주장은 — 반대, 우려, 해결책 — 클릭 한 번으로 접근할 수 있으며, 기억에 의존하지 않습니다.

실제로 답변이 필요한 질문을 하세요.

합의와 동의는 모두 정직한 비용을 가진 정직한 규칙입니다 — 실패 모드는 잘못된 것을 선택하는 것이 아니라 아예 선택하지 않는 것입니다: 서면 테스트, 우려 사항 등록, 검토 날짜 없이 한 이름 또는 다른 이름으로 "모두가 편안해야 한다"는 회의를 진행하는 것입니다. 그 하이브리드는 합의의 속도와 동의의 소유권을 가지고 있습니다 — 두 가지의 최악입니다.

그러므로 중요한 다른 사항을 결정하듯이 규칙을 명확하게, 기록하고, 검토 날짜를 정하여 결정하세요. 그리고 다음에 3주 제안이 방에 올라올 때, 그것이 좋은 제안이 그래야만 죽을 수 있도록 하세요 — 논쟁에 의해.