donghyeon.kang/company-haness
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
bac770dc4c5cc03e9efa62873c9c95eaed3fe9ce
company-haness/docs/superpowers/specs/2026-07-05-collaboration-efficiency-design.md
T

16 KiB
Raw Blame History

status, applies-to-version, superseded-by, exclude-from, note
status applies-to-version superseded-by exclude-from note
historical-snapshot registry 62 roles / 26 families / 11 lenses (설계 시점) 현재 정본 registry 73 roles / 28 families / 12 lenses — org-os/00-role-registry/*
must-read
default-search
구현 완료된 과거 설계. 본문의 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 표기 일원화 반영.
Reference in New Issue View Git Blame Copy Permalink