---
status: historical-snapshot
applies-to-version: "registry 62 roles / 26 families / 11 lenses (설계 시점)"
superseded-by: "현재 정본 registry 73 roles / 28 families / 12 lenses — org-os/00-role-registry/*"
exclude-from: [must-read, default-search]
note: "구현 완료된 과거 설계. 본문의 62/26/11 수치는 당시 스냅샷이며 현재 정본은 org-os 레지스트리다(finding #20)."
---

# 협업 효율화 + 다양성 보존 오버레이 설계

- 작성일: 2026-07-05
- 대상 하네스: `company-haness` / Org OS (현재 100% 명세 단계)
- 범위: **설계/명세만** 개선 (`.claude` 구현·validator 스크립트는 이번 범위 밖)
- 인코딩 방식: **가산적 오버레이** (새 파일 추가 + 기존 파일 참조 한 줄씩만)

---

## 1. 목적과 문제

### 문제
현재 구조는 모든 작업을 동일한 무거운 DRAI 의식으로 처리한다. Claude Code subagent는 서로 직접 대화하지 못하고 파일을 경유해 직렬로 handoff하며, **handoff마다 컨텍스트 전체를 재적재**한다. 그 결과:

- 저위험 작업(오타·소규모 기능)도 다수 역할이 순차 개입해 느리고 토큰이 무겁다.
- 발산(아이디어)과 수렴(결정)을 같은 무거운 기계로 처리해, 아이디어를 얻는데도 결정용 의식을 돌린다.
- 62개 세분 역할이 유사 역할로 흩어져 같은 컨텍스트를 반복 재적재한다.

### 목표
협업의 **handoff 수·직렬성·재적재 비용을 낮추되, 관점 다양성은 보존/강화**한다. 핵심 통찰: **다양성 = 서로 다른 렌즈의 수이지 역할 headcount가 아니다.** 따라서 중복 역할 통합과 의식 경량화는 다양성을 줄이지 않는다.

### 비목표 (Out of scope)
- `.claude/agents`·commands·hooks·`.mcp.json` 등 실행체 구현
- 참조 무결성 validator 스크립트(코드) — 다음 라운드 후속
- 신규 role 추가 또는 기존 62 role 삭제

---

## 2. 핵심 모델: 2개의 직교 축 + 다양성 바닥

|            | TIER-LIGHT (저위험·가역·단일도메인) | TIER-STANDARD (중간·교차도메인) | TIER-HEAVY (고위험·비가역·프로덕션/매출/보안/법무) |
|------------|--------------------------------------|----------------------------------|------------------------------------------------------|
| **DIVERGENT** (아이디어 생성) | 3개 렌즈 병렬 + 합성 1 | 5개 렌즈 + 역발상 필수 + 합성 | 전 관련 렌즈 + 역발상 필수 + 트레이드오프 매트릭스 |
| **CONVERGE** (결정·승인) | owner + 리뷰어 1, 감사 없음 | decider + 추천(병렬) + 감사 1 | 풀 DRAI + 감사 병렬 팬아웃(≥3) + 인간 게이트 |

- **Mode(무엇을):** `divergent` | `converge` — intake에서 **명시적으로 선택**.
- **Tier(얼마나 무겁게):** `light` | `standard` | `heavy` — 위험도·가역성·영향반경에서 **파생**.
- **하위호환 원칙:** **TIER-HEAVY = 오늘의 DRAI 동작 그대로.** 기존 rigor를 제거하지 않고, 그 아래 급행 차선(light/standard)을 신설한다. 기존 High/Critical 경로는 자동으로 TIER-HEAVY에 대응된다.

---

## 3. 신규 오버레이 파일 (관심사당 파일 하나)

### 3.1 `org-os/00-role-registry/lens-registry.yaml` — 다양성 바닥
서로 구별되는 11개 평가 렌즈를 불가침으로 고정한다. 각 렌즈는 "이 렌즈가 던지는 질문"과 "이 렌즈를 실을 수 있는 패밀리"를 명시한다.

| lens-id | 던지는 질문 | 주 carrier 패밀리 |
|---|---|---|
| LENS-VALUE | 장기 회사가치·포트폴리오 적합성? | FAM-CEO, FAM-STRATEGY |
| LENS-TECH | 아키텍처·안정성·확장성·기술부채? | FAM-CTO, FAM-ARCHITECTURE-TECH, FAM-PLATFORM-INFRA, FAM-DATA, FAM-VPENG |
| LENS-PRODUCT | 고객문제·제품가치·로드맵·P/L? | FAM-CPO, FAM-PRODUCT-MGMT |
| LENS-FINANCE | 비용·ROI·자본효율·기회비용? | FAM-CFO, FAM-REVOPS, FAM-STRATEGY |
| LENS-OPS | 운영타당성·프로세스·지원부담? | FAM-COO, FAM-OPS-DELIVERY, FAM-ARCHITECTURE-BIZ |
| LENS-INTEGRATION | 제품-기술 통합·충돌 감소? | FAM-CPTO |
| LENS-SECURITY | 위협·shift-left·데이터 무결성? | FAM-SECURITY, FAM-PLATFORM-INFRA |
| LENS-LEGAL | 계약·컴플라이언스·프라이버시? | FAM-LEGAL |
| LENS-CUSTOMER | 사용자 리서치·고객의 소리·경험? | FAM-UX-RESEARCH, FAM-DESIGN, FAM-GTM-SALES, FAM-OPS-DELIVERY |
| LENS-REVENUE | 매출영향·GTM motion·lead-to-cash? | FAM-REVOPS, FAM-GTM-GROWTH, FAM-GTM-SALES |
| LENS-CONTRARIAN | 이걸 하지 말아야 할 이유·무엇이 깨지나? | (로테이션) 옵션 작성 패밀리가 아닌 임의 reviewer/auditor 가능 패밀리 |

**규칙(파일에 명문화):**
- R1. 패밀리 통합 시 **서로 다른 렌즈는 절대 병합 금지.** 같은 렌즈의 중복 역할만 합친다.
- R2. `divergent` 모드는 tier별 최소 렌즈 수 이상을 **병렬** 커버해야 한다.
- R3. `converge` 모드(특히 heavy)는 렌즈 의견을 하나로 뭉치지 말고 **트레이드오프째 노출**한다. (기존 `team-topology-map.yaml`의 executive-balance 계승)
- R4. LENS-CONTRARIAN을 담당하는 패밀리는 해당 옵션을 작성한 패밀리와 달라야 한다(이해상충 방지).

### 3.2 `org-os/00-role-registry/capability-families.yaml` — 62 → 26 패밀리
62개 role은 **참조 분류체계로 보존**하고, 실제 인스턴스화·라우팅 단위는 아래 26개 패밀리로 한다. 각 패밀리는 같은 렌즈/역량을 공유하는 role의 묶음이다.

| 패밀리 | 소속 role-id | 비고 |
|---|---|---|
| FAM-CEO | EXEC-CEO | 렌즈: VALUE |
| FAM-ORCH | OPS-ORCH | 코디네이터(무렌즈) |
| FAM-CTO | EXEC-CTO | 렌즈: TECH |
| FAM-CPO | EXEC-CPO | 렌즈: PRODUCT |
| FAM-CFO | EXEC-CFO | 렌즈: FINANCE |
| FAM-COO | EXEC-COO | 렌즈: OPS |
| FAM-CPTO | EXEC-CPTO | 렌즈: INTEGRATION |
| FAM-VPENG | EXEC-VPENG | 엔지니어링 딜리버리 리더십(reviewer) |
| FAM-PRODUCT-MGMT | PROD-PM, PROD-PO, PROD-TPO, PROD-PPO | 제품관리(stream/tech/platform) |
| FAM-UX-RESEARCH | UX-RESEARCHER, DATA-ANALYST | 고객·데이터 인사이트 |
| FAM-DESIGN | DES-PROD, DES-PLATFORM, DES-INTERNAL | 디자인 |
| FAM-STRATEGY | STR-ANALYST | 전략분석 |
| FAM-ENG-FRONTEND | ENG-FE, ENG-FEPLAT, ENG-FEUX | 프론트엔드 |
| FAM-ENG-BACKEND | ENG-BE, ENG-BEGEN, ENG-PRODSERVER, ENG-PLATSERVER, ENG-PRODUCTMINDED, ENG-SW | 백엔드 6역할 통합 |
| FAM-ENG-SPECIAL | ENG-DESKTOP, ENG-PRODCHAPTER | 데스크톱/생산성 특수 |
| FAM-PLATFORM-INFRA | INFRA-DEV, INFRA-PLATFORM, INFRA-DEVOPS, SRE, SEC-DEVSECOPS | 인프라·신뢰성 (SRE=audit-capable) |
| FAM-ARCHITECTURE-TECH | ARCH-EA, ARCH-SOLUTION, ARCH-APP, ARCH-TECH, ARCH-IT, ARCH-SYSANALYST, ARCH-SWAT | 기술 아키텍처 (SWAT=audit-capable) |
| FAM-ARCHITECTURE-BIZ | ARCH-BA, ARCH-BIZANALYST | 비즈니스 아키텍처 |
| FAM-DATA | ARCH-DATA, DATA-ENGINEER, DATA-BIGDATA | 데이터 플랫폼 |
| FAM-QA | QA | 품질(audit-capable) |
| FAM-SECURITY | SEC-ENGINEER, SEC-APPSEC, SEC-CHAMPION | 보안(audit-capable) |
| FAM-OPS-DELIVERY | OPS-CH, OPS-CREW | 고객상담·오퍼레이션 |
| FAM-GTM-GROWTH | GTM-GROWTHPM, GTM-DEMANDGEN, GTM-PMM, GTM-CI | 수요창출·성장·마케팅·경쟁정보 |
| FAM-GTM-SALES | GTM-SALES, GTM-CS, GTM-PARTNER | 영업·CS·파트너 |
| FAM-REVOPS | GTM-REVOPS, GTM-PRICING | 레비뉴옵스·프라이싱 |
| FAM-LEGAL | GTM-LEGAL | 법무/컴플라이언스(렌즈: LEGAL) |

- 총 26개 패밀리, 62개 role 전부 정확히 1개 패밀리에 배정(중복·누락 없음).
- 효율 이득의 핵심: 엔지니어 11→3, 아키텍처/데이터 10→3, GTM 10→4로 통합. 임원 8개는 각자 distinct 렌즈라 통합하지 않음(다양성 유지의 직접 결과).
- 각 패밀리 필드: `family-id`, `member-role-ids`, `carries-lenses`, `audit-capable`(bool), `default-team-types`, `instantiation-priority`(MVP 여부).

### 3.3 `org-os/06-agent-work/collaboration-modes.yaml` — 발산/수렴
- **DIVERGENT**
  - 목적: 다양한 옵션·아이디어 생성.
  - 메커니즘: 렌즈별 **병렬 팬아웃** — 서로 다른 렌즈/프레이밍을 부여한 N개 에이전트를 동시에 스폰.
  - 합성: 합성 에이전트 1명이 옵션을 **수집·정리(결정 아님)**, 렌즈별 트레이드오프 노출. 하나의 추천으로 병합 금지.
  - 배리어: **허용**(모든 옵션을 모아야 합성 가능 — 정당한 배리어).
- **CONVERGE**
  - 목적: 책임소재 있는 결정·승인.
  - 메커니즘: tier 가중 DRAI. 추천자 병렬 실행, 감사자 병렬(heavy), decider가 종합.
  - 출력: decision-record = 선택 옵션 + 인정된 트레이드오프 + **반대의견(dissent) 기록**.
  - 규칙: High/Critical 위험 → 인간 decider (기존 유지).
- **2단계 파이프라인:** `divergent → converge`를 원할 때 파이프라인으로 연결(발산 결과가 수렴 입력).

### 3.4 `org-os/06-agent-work/governance-tiers.yaml` — 기어(티어)
- **파생 입력 3종:** `risk-level`(Low/Med/High/Critical), `reversibility`(two-way-door/one-way-door), `blast-radius`(single-role/cross-team/production-customer-revenue).
- **파생 규칙(레벨 가산 방식 — "비가역=무조건 HEAVY" 과분류 방지):**
  1. **base** = 위험도로 결정: `Low`→LIGHT, `Med`→STANDARD, `High|Critical`→HEAVY.
  2. **modifier**(각 +1 레벨, HEAVY에서 상한): `one-way-door` +1, `cross-team` +1.
  3. **hard floor**: `production/customer/revenue blast`이면 최소 HEAVY.
  - 예) Low+one-way+single = LIGHT+1 = **STANDARD** (HEAVY 아님). Med+one-way+cross = **HEAVY**. Low+two-way+single = **LIGHT**.
  - 인간은 언제나 상향 escalate 가능. Orchestrator는 제안만. **위험도 base 아래로 자동 하향 금지**(High/Critical는 항상 HEAVY).
- **티어별 요구(converge):**
  - LIGHT: owner + 리뷰어1. evidence-grade 최소 E2. 보안/법무/프라이버시 접촉 시에만 감사자 +1. 인간 불필요.
  - STANDARD: decider + 관련 추천(병렬) + 감사1. evidence 최소 E3. 인간 informed(비차단).
  - HEAVY: `drai-matrix` 그대로 풀 DRAI + 감사 병렬 팬아웃(≥3) + evidence 최소 E3, unresolved-critical-risks=false (기존 state-transition Approved 조건과 동일).
    - **인간 게이트 조건(단일 인간 병목 완화):** 위험 `High|Critical` **또는** `production/customer/revenue blast`이면 **인간 decider(차단)**. 그 외 modifier로만 HEAVY에 도달한 경우(예: Med+비가역+교차팀)는 **EXEC-CEO decider + 인간 informed(비차단)**. 인간은 항상 상향해 직접 decider가 될 수 있다.
- **티어별 요구(divergent):** LIGHT=3렌즈/역발상 선택, STANDARD=5렌즈+역발상 필수, HEAVY=전 관련 렌즈+역발상 필수+트레이드오프 매트릭스.

### 3.5 `org-os/06-agent-work/execution-policy.yaml` — 파이프라인·병렬감사
- `pipeline-default: true` — 항목이 wave 동료를 기다리지 않고 단계 간 흐름.
- `barrier-allowed-only-when: [divergent-synthesis, dedup-across-all-findings, early-exit-on-zero, cross-item-comparison-required]`.
- `wave-size ≤ 5` = **동시성 상한이지 배리어가 아님**(scorecard의 hard-rule 재해석).
- `parallel-audit-fanout`(heavy): 독립 검증자 N≥3, 서로 다른 렌즈, 각자 **반증(refute) 지향** 프롬프트; 과반 반증 → `Blocked`.
- `verifier-independence`: 검증자 패밀리는 자기 패밀리가 작성한 산출물을 검증하지 않는다(기존 independent-audit 이해상충 규칙과 정합).
- `re-hydration-control`: 각 단계는 **구조화 요약(evidence 링크)**만 다음 단계로 전달, raw 로그 금지 — `context-package-spec`의 compression-policy 강제.

---

## 4. 기존 파일 최소 수정 (참조만 추가, 의미 제거 없음)

### 4.1 `role-selection-scorecard.yaml`
- `output-template`에 `mode`, `tier`, `assigned-lens`, `lens-coverage` 필드 추가.
- hard-rules 추가:
  - "wave 전에 mode와 tier를 선언해야 한다."
  - "divergent는 tier별 최소 렌즈 수를 충족해야 한다."
  - "converge-heavy는 렌즈를 하나로 병합하지 않는다."

### 4.2 `context-package-spec.yaml`
- required/schema에 `mode`, `tier`, `assigned-lens`, `divergent-framing`(발산 시 각 에이전트에 주는 상이한 프레이밍) 추가.

### 4.3 `state-transition-rules.yaml`
- **상태 어휘 3중 정합(state-vocabulary-map) 블록 추가** — 이번 작업의 파이프라인/티어가 돌기 위한 전제라 포함:
  - `workflow-stage`(라이프사이클, 단일 원천): intake→discovery→design→review→implementation→verification→release→closed (+blocked)
  - `document-state`(개별 산출물): Draft→Review→Approved→Closed
  - `review-state`(부모-자식 수용 1건): Submitted-for-Review→Accepted|Changes-Requested|Blocked
  - 매핑: workflow-stage가 워크플로우의 단일 원천. 각 stage 내부에서 document는 document-state를, handoff는 review-state를 가진다. hook은 document-state/review-state를 전이시키고, 해당 stage의 게이팅 문서가 Approved/Accepted에 도달하면 workflow-stage가 전진한다.
- `tier-modifiers` 참조 추가: LIGHT는 감사자 요구 완화 + evidence 최소 E2 허용, HEAVY는 기존 조건 그대로. (실제 값은 `governance-tiers.yaml`이 단일 원천)

### 4.4 `org-os/README.md`
- 신규 5개 파일 등재.
- `03-products` 드리프트 정리: `{product-id}/pr-faq.md·roadmap.md·metrics.md` 구조를 정본으로 채택(README 기준), Claude Code 명세 쪽을 이에 맞춤은 후속 메모.
- 패밀리가 인스턴스화 단위이고 62 role은 참조 분류체계임을 한 줄 명시.

---

## 5. 의도된 흐름 (나중 구현용 스펙 — 이번엔 문서화만)

```
/ceo-intake  → CEO AI: (a) mode 선택받음(divergent/converge)
                        (b) risk·reversibility·blast-radius로 tier 제안
/plan-wave   → Orchestrator: mode×tier로 팬아웃 형태 결정
                divergent → 렌즈별 병렬 팬아웃 + 합성
                converge  → tier 가중 DRAI(추천 병렬, heavy면 감사 병렬 팬아웃)
/run-wave    → execution-policy에 따라 배리어가 아닌 파이프라인으로 실행
```
이 흐름은 command 계층(=.claude) 구현 대상이므로 이번 라운드에서는 **명세 기술만** 하고 구현하지 않는다.

---

## 6. 컴포넌트 경계 (격리·독립성)

| 컴포넌트 | 하는 일 | 의존 |
|---|---|---|
| lens-registry | 다양성 바닥·렌즈↔패밀리 매핑 제공 | capability-families |
| capability-families | 62 role → 26 패밀리 인스턴스화 매핑 | roles.yaml(참조) |
| collaboration-modes | 발산/수렴의 실행 형태 정의 | lens-registry, execution-policy |
| governance-tiers | 위험→티어 파생·티어별 요구 정의 | drai-matrix, state-transition-rules(참조) |
| execution-policy | 파이프라인·병렬감사·재적재 제어 | context-package-spec(참조) |

각 파일은 단일 관심사만 담고 다른 파일은 id/참조로만 연결 → 하나를 바꿔도 나머지가 안 깨진다.

---

## 7. 성공 기준 (수용 조건)

1. 62개 role이 정확히 1개 패밀리에 배정(중복·누락 0).
2. 11개 렌즈 각각 carrier 패밀리 ≥ 1.
3. tier×mode 6개 셀 모두 요구사항 정의됨.
4. 기존 파일 변경은 **참조 추가뿐**이고 기존 rigor 의미 제거 없음(HEAVY == 오늘 동작).
5. 신규 파일이 참조하는 모든 role-id/family-id/lens-id가 실제 정의에 존재(orphan 0).
6. TIER-HEAVY 경로가 기존 `state-transition-rules`의 Approved/Closed 조건과 모순되지 않음.

---

## 8. 리스크와 대응

| 리스크 | 대응 |
|---|---|
| 티어 오분류로 고위험 작업이 경량 처리 | 위험도 바닥 규칙(High/Critical→HEAVY 자동), 인간 상향 escalate 상시 허용 |
| 패밀리 통합으로 시각 축소 우려 | R1(다른 렌즈 병합 금지) + 성공기준 2로 구조적 차단 |
| 상태 어휘 3중이 hook 구현 시 혼란 | §4.3 state-vocabulary-map으로 단일 원천(workflow-stage) 확정 |
| 명세만 바뀌고 실행체와 괴리 | §5를 구현용 스펙으로 남겨 다음 라운드(.claude) 입력으로 사용 |

---

## 9. 후속(이번 범위 밖, 메모)
- 참조 무결성 validator 스크립트(모든 role/family/lens id 존재 검사).
- thin vertical slice(.claude 에이전트·command·hook) — 위 §5 흐름을 실제로 구현·검증.
- Claude Code 명세 문서와 README의 `03-products` 표기 일원화 반영.