Governance
누가 책임지는가? 어떤 규칙을 따르는가?
Kyndof에서 거버넌스가 중요한 이유
K-pop 무대 의상을 제조하는 Kyndof에서 의사결정의 속도와 정확성은 사업의 성패를 좌우합니다. 아이돌 컴백 일정은 단 하루도 늦출 수 없고, 무대 의상의 디자인 변경 하나가 전체 생산 일정에 연쇄적인 영향을 미칩니다. 이런 환경에서 "이 결정을 누가 내리나?"라는 질문에 즉시 답할 수 없다면, 팀은 불필요한 대기 시간을 보내게 되고 납기를 지키지 못할 위험이 커집니다.
Kyndof의 거버넌스는 이 문제를 해결하기 위해 설계되었습니다. 모든 의사결정에 명확한 책임자를 지정하고, 승인이 필요한 경우와 자율적으로 진행해도 되는 경우를 사전에 구분하며, 막혔을 때의 에스컬레이션 경로를 미리 정해둡니다. 거버넌스는 관료주의가 아니라, 빠르고 정확한 실행을 위한 인프라입니다.
이 섹션에서는 Kyndof의 거버넌스 프레임워크인 RABSIC, 승인 프로세스, 에스컬레이션 경로, 그리고 의사결정 기록 체계를 상세히 다룹니다. 신입 직원이라면 먼저 RABSIC 프레임워크 개요를 읽고, 이어서 자신의 역할에 해당하는 의사결정 유형을 확인하는 것을 권장합니다.
Kyndof에서 거버넌스란 명확한 책임, 투명한 의사결정, 그리고 모든 선택에 주인이 있고, 모든 행동에 권한이 있으며, 모든 결과를 그 원점까지 추적할 수 있도록 보장하는 체계적인 프로세스를 의미합니다. 좋은 거버넌스는 실행을 늦추지 않습니다. 오히려 의사결정 권한과 승인 경로에 대한 모호함을 제거함으로써 실행을 가속화합니다.
Kyndof의 거버넌스 모델을 이해하면 언제 독립적으로 행동할 수 있는지, 언제 승인이 필요한지, 어떤 결정에 누구의 의견이 중요한지, 그리고 막혔을 때 어떻게 에스컬레이션해야 하는지 알 수 있습니다. 이러한 명확함이 거버넌스를 관료적 오버헤드에서 실행 인프라로 탈바꿈시킵니다.
거버넌스 철학
Kyndof의 거버넌스는 두 가지 핵심적인 긴장 관계의 균형을 맞춥니다:
속도 vs. 통제: 팀은 빠르게 움직이기 위해 자율성이 필요하지만, 조직은 혼란을 방지하기 위해 조율이 필요합니다. 우리는 의사결정 권한을 가능한 한 낮은 단계로 위임하되, 중대한 선택에 대해서는 적절한 감독을 유지합니다.
책임 vs. 협업: 모든 결정에는 책임의 분산을 방지하기 위해 정확히 한 명의 주인(Accountable)이 필요하지만, 대부분의 의미 있는 결정은 다양한 관점의 혜택을 받습니다. RABSIC 프레임워크는 명확한 책임과 구조화된 협업을 모두 제공합니다.
거버넌스 시스템은 명시적 프레임워크(RABSIC), 체계적 워크플로우(승인), 투명한 추적(의사결정 로그)을 통해 이러한 균형을 체계화합니다. 거버넌스 규칙은 직급에 관계없이 모두에게 동등하게 적용됩니다. 권한은 역할 배정과 승인 매트릭스에서 비롯되며, 조직 정치에서 비롯되지 않습니다.
거버넌스 프레임워크 개요
Kyndof의 거버넌스는 네 가지 상호 연결된 기둥 위에 세워져 있습니다:
1. RABSIC 책임 프레임워크
모든 결정에는 6가지 역할이 배정됩니다: Responsible(업무 실행), Accountable(결과 책임), Backup(Responsible 대리), Support(Responsible 지원), Informed(사후 통보), Consulted(사전 자문). 절대 규칙: 결정당 Accountable은 정확히 1명입니다.
RABSIC은 주인 없는 결정(모든 사람의 책임은 아무도의 책임이 아님)과 합의 마비(모든 사람의 동의 요구는 모든 사람에게 거부권을 부여함)를 모두 방지합니다. 한 사람이 결과를 책임지고, 많은 사람이 결정에 기여합니다.
2. 승인 워크플로우
모든 행동에 승인이 필요한 것은 아닙니다. 대부분의 일상 업무는 자율적으로 진행됩니다. 승인 요건은 영향도, 범위, 복구 가능성, 위험도에 따라 발동됩니다. 승인은 단계별로 나뉩니다: 승인 불필요, 역할 기반 승인, 경영진 승인, 또는 이사회 승인.
잘 설계된 승인 워크플로우는 관료적 병목(사소한 선택 승인)과 무분별한 실행(필요한 권한 없이 행동) 모두를 방지합니다. 명확한 승인 기준은 승인이 필요한 시점과 승인 권한자에 대한 추측을 제거 합니다.
3. 에스컬레이션 메커니즘
이슈가 권한을 초과하거나, 부서 간 조율이 필요하거나, 지속적인 차단 요소에 직면할 때, 에스컬레이션 경로는 상위 수준 의사결정으로의 명확한 경로를 제공합니다. 에스컬레이션은 실패가 아닙니다. 문제가 더 넓은 시각이나 더 큰 권한을 필요로 할 때 이를 인식하는 것입니다.
효과적인 에스컬레이션은 적절한 시점에 적절한 의사결정자를 참여시켜 해결을 가속화합니다. 잘못된 에스컬레이션은 팀이 독립적으로 해결해야 할 문제에 리더십의 관심을 낭비합니다.
4. 의사결정 추적
주요 결정은 배경, 대안, 근거, 예상 결과와 함께 문서화됩니다. 의사결정 로그는 조직적 기억상실을 방지합니다. 6개월 후에도 원래 의사결정자가 이동한 경우에도 팀은 왜 그런 선택이 이루어졌는지 이해할 수 있습니다.
의사결정 추적은 패턴 분석을 통한 학습을 가능하게 합니다: 어떤 결정 유형이 성공하거나 실패하는지, 어떤 가정이 정확한 것으로 증명되는지, 시간이 지남에 따라 결정 품질을 어떻게 개선할 수 있는지.
핵심 문서 가이드
RABSIC Operating Guide
언제 읽나: RABSIC을 실무에서 적용할 때, Value Stream과 연동할 때, 안티 패턴을 피하고 싶을 때
RABSIC의 실무 적용 가이드입니다. 자동 추천 로직, Position↔Person 매핑, Task 생성 시 규칙, 안티 패턴을 다룹니다.
RABSIC Framework
언제 읽나: 새 프로젝트 시작 시, 의사결정 책임 불명확 시, 팀 협업 구조 설계 시
RABSIC의 6가지 역할(R-A-B-S-I-C) 정의와 실제 적용법을 다룹니다. 모든 의사결정에 적용되는 기본 프레임워크입니다.
핵심 질문 해결:
- 이 결정에서 누가 최종 책임자인가?
- 누구의 승인이 필요한가?
RABSIC 의사결정 매트릭스
언제 읽나: 특정 의사결정에서 내 역할이 무엇인지 확인할 때, 에스컬레이션 조건을 파악할 때
핵심 의사결정 10가지에 대한 구체적인 RABSIC 역 할 배정표입니다. 주문 수락, 생산 일정, 품질 관리, 채용, 예산 등 주요 의사결정마다 누가 실행(R)하고 누가 책임(A)지는지 확인할 수 있습니다.
핵심 질문 해결:
- 이 의사결정에서 구체적으로 누가 어떤 역할을 하는가?
- 에스컬레이션은 언제, 어떤 경로로 하는가?
- 내 Position의 기본 RABSIC 역할은 무엇인가?
- 누구에게 의견을 물어야 하나?
- 결정 후 누구에게 알려야 하나?
Decision Types
언제 읽나: 승인이 필요한지 판단할 때, 결정 수준을 가늠할 때
Kyndof의 결정 유형별 특성, 누가 결정 권한을 가지는지, 에스컬레이션 경로를 설명합니다.
핵심 질문 해결:
- 이 결정은 어떤 범주에 속하나? (전술적/운영적/전략적)
- 내가 단독으로 결정할 수 있나?
- 누구의 승인이 필요한가?
- 잘못 판단하면 어떤 영향이 있나?
Approval Process
언제 읽나: 승인 요청할 때, 승인 대기 중일 때, 막혔을 때
실제로 승인을 받는 방법—요청 작성법, 응답 시간 기대치, 막혔을 때 대처법을 다룹니다.
핵심 질문 해결:
- 승인 요청에 무엇을 포함해야 하나?
- 응답을 얼마나 기다려 야 하나?
- 승인자가 응답 안 하면?
- 거절당하면 어떻게 하나?
Approval Workflows
언제 읽나: 표준 승인 프로세스 이해할 때, 특정 상황별 승인 규칙 찾을 때
세부적인 승인 워크플로우—프로젝트 시작, 예산 지출, 기술 아키텍처, 채용, 정책 변경 등 상황별 승인 규칙을 상세히 설명합니다.
핵심 질문 해결:
- 이 유형의 결정은 표준 프로세스가 있나?
- 순차 승인인가 병렬 승인인가?
- 긴급 상황에서는 어떻게 하나?
Escalation Paths
언제 읽나: 막혔을 때, 갈등 상황일 때, 빠른 결정이 필요할 때
언제 에스컬레이션해야 하는지, 어떻게 효과적으로 에스컬레이션하는지를 다룹니다.
핵심 질문 해결:
- 지금 에스컬레이션해야 하나?
- 누구에게 에스컬레이션하나?
- 어떻게 요청을 작성하나?
- 에스컬레이션 안티패턴은 무엇인가?
Decision Log
언제 읽나: 과거 의사결정 이유 궁금할 때, 유사한 선례 찾을 때
주요 조직 의사결정 기록과 그 배경, 결과를 담고 있습니다. 현재 상태가 "왜" 이렇게 되었는지 이해하는 데 유용합니다.
핵심 질문 해결:
- 왜 이 기술을 선택했나?
- 과거에 비슷한 결정은 어떻게 했나?
- 당시 어떤 대안을 고려했나?
- 결정 결과는 어땠나?
실전 시나리오별 가이드
"나는 이 결정을 내릴 권한이 있나?"
- Decision Types에서 결정 유형 확인
- RABSIC Framework에서 당신의 역할 확인
- 권한 범위 초과 시 → Approval Process 참조
"승인이 필요한데 어떻게 하나?"
- Approval Process에서 요청 템플릿 확인
- Approval Workflows에서 해당 상황별 프로세스 확인
- 요청 제출 후 타임라인 대로 대기
"승인자가 응답을 안 해요"
- Approval Process의 타임아웃 섹션 확인
- 리마인더 시점 도달 시 자동 알림
- 2차 타임아웃 시 Escalation Paths 활용
"팀 간 의견 충돌로 막혔어요"
- RABSIC Framework에서 Accountable 확인
- Accountable에게 의사결정 요청
- 여전히 해결 안 되면 Escalation Paths 참조
"과거에 이런 결정 어떻게 했나?"
- Decision Log에서 유사 사례 검색
- 당시 RABSIC matrix 확인
- 선례를 현재 상황에 적용
Position별 기본 권한
| Position | 기본 RABSIC 역할 | 주요 권한 |
|---|---|---|
| CEO | A (최종 의사결정) | 전략/투자/정책 최종 승인 |
| CTO | A (기술), C (비즈니스) | 기술 아키텍처/보안 최종 승인 |
| Department Head | A (부서 내), C (타 부서) | 부서 예산/채용/프로젝트 승인 |
| Team Lead | R (팀 업무), A (팀 내) | 팀 내 운영 결정 |
| Individual Contributor | R (할당 업무), S (협업) | 할당된 작업 실행 |
이 기본 권한은 시작점이며, 구체적인 의사결정마다 RABSIC matrix가 별도로 할당됩니다.
거버넌스 원칙의 실제 적용
원칙 1: Position > Person
모든 거버넌스 참조는 역할/Position 이름을 사용하며, 개인 이름은 절대 사용하지 않습니다. 이는 인원이 변경될 때 조직의 연속성을 보장합니다. 시스템은 누가 그 역할을 맡든 독립적으로 운영됩니다.
예시: "CTO가 아키텍처 결정을 승인한다"이지, "홍길동이 아키텍처 결정을 승인한다"가 아닙니다.
원칙 2: Accountable은 정확히 1명
모든 결정에는 정확히 한 명의 Accountable이 있어야 합니다. 공유된 책임은 무책임이 됩니다. 여러 사람이 기여할 수 있지만(Responsible, Support, Consulted), 결과의 주인은 한 사람입니다.
예시: 프로젝트에는 여러 엔지니어가 실행(Responsible)하더라도 Project Owner(Accountable)는 한 명입니다.
원칙 3: 프로세스를 신뢰하라
RABSIC 프레임워크는 의사결정 흐름을 체계적으로 관장합니다. 승인 규칙은 직급에 관계없이 모든 요청에 동등하게 적용됩니다. 권한은 역할 + 승인 매트릭스에서 비롯되며, 조직 정치에서 비롯되지 않습니다.
예시: CEO의 예산 요청도 단일 승인자 한도를 초과하면 다른 모든 사람과 동일한 승인 프로세스를 따릅니다.
원칙 4: 주요 결정을 문서화하라
중요한 선택은 배경, 대안, 근거와 함께 기록됩니다. 조직은 결정보다 그 이유를 더 빨리 잊습니다. 문서화는 조직적 기억상실을 방지합니다.
예시: 기술 선택 시 왜 대안 대신 이 선택을 했는지 설명하는 Architecture Decision Record를 포함합니다.
거버넌스 도구 및 시스템
RABSIC-Engine 에이전트
결정에 필요한 역할을 판단하고, 책임 매트릭스를 생성하며, "Accountable은 정확히 1명" 규칙을 강제하고, 배정을 추적합니다.
사용 시점: 신규 프로젝트 설정, 복잡한 다중 역할 결정, 또는 책임 분쟁 시 호출합니다.
Back-Writer 에이전트
결정과 승인을 외부 시스템(Notion 보드, Slack 채널)에 게시합니다. 수동 알림 부담 없이 조직 가시성을 확보합니다.
사용 시점: 주요 결정 후 결과를 전파하기 위해 자동 호출됩니다.
승인 추적 시스템
모든 승인 요청, 결정, 일정, 근거의 기록을 관리합니다. 패턴 분석과 프로세스 개선을 가능하게 합니다.
위치: .omc/state/approvals.json (런타임 상태), world-model/databases/approvals.json (이력 기록)
의사결정 아카이브
Architecture Decision Record 형식을 사용하는 주요 결정의 구조화된 저장소입니다.
위치: world-model/knowledge/decisions/ (전체 아카이브), 이 의사결정 로그 (하이라이트)
데이터 소스
| Source | Path | Purpose |
|---|---|---|
| Decisions | world-model/databases/decisions.json | 의사결정 기록 |
| Approvals | world-model/databases/approvals.json | 승인 내역 추적 |
| RABSIC Matrix | world-model/databases/rabsic-matrix.json | 역할 할당 매트릭스 |
| Positions | world-model/databases/positions.json | 조직 역할 정의 |
| Decision Archive | world-model/knowledge/decisions/ | ADR 형식 상세 기록 |
Common Governance Questions
Q: Do I need approval for this? Check Decision Types to categorize your decision, then Approval Process for specific approval requirements.
Q: Who is the Accountable party for this decision? Check RABSIC Framework for role definitions. If unclear, use RABSIC-Engine agent to generate accountability matrix.
Q: My approver isn't responding. What do I do? See Approval Process timeout section. System auto-escalates after defined periods.
Q: Can I escalate my manager's decision? Yes. See Escalation Paths for guidance on escalating manager decisions professionally.
Q: Where do I find past decisions on similar topics?
Check Decision Log for major decisions. Full archive at world-model/knowledge/decisions/.
Q: How do I propose a policy change? Follow Approval Workflows policy change section. Requires stakeholder consultation before approval.
관련 문서
- Teams - 조직 구조와 Position
- Projects - 프로젝트 실행
- Goals & Strategy - 전략적 방향
- Knowledge Graph - 전체 의사결정 아카이브
원본 문서: Notion - RABSIC & Value Stream 운영 가이드 최종 동기화: 2026-02-08