Orbit · 가이드 · Trust Architecture
신뢰 계층과
조직 격리
Orbit의 신뢰는 정책 문서가 아닙니다. 모든 데이터에 신뢰 등급이 부여되고, 모든 조직이 구조적으로 격리되며, Acceptance Run마다 자동 검증됩니다.
Section 01
한 장면 — 신입 사원이 기준을 바꾸는 순간
개념을 먼저 풀기 전에 한 장면부터 봅니다. 재무팀에 합류한 지 일주일 된 준호가 Dictionary에서 "외주비 정산 기준"을 수정하려고 합니다.
Dictionary에서 "외주비 3천만원 초과 시 본부장 승인" 항목을 발견한다.
임계값을 5천만원으로 올리려고 편집 버튼을 누른다.
Authority가 차단한다: "이 항목은 Verified 상태이며, Finance Lead 이상만 수정 가능합니다."
준호는 대신 Candidate로 수정 제안을 제출한다. Bridge 큐에 들어간다.
Finance Lead가 제안을 검토하고 기각한다: "감사 기준이므로 임계값 변경 불가."
10:15의 차단이 핵심입니다. Authority가 없는 시스템이라면 준호의 수정은 바로 반영되고, 다음 분기 감사에서야 문제가 드러납니다. 이미 100건의 외주비가 잘못된 기준으로 처리된 뒤입니다.
신뢰의 핵심은 속도가 아니라 경계입니다. 누구나 모든 것을 바꿀 수 있으면 빠르지만, 기준이 흔들립니다. 느려도 올바른 사람이 올바른 범위에서 바꿔야 조직의 운영이 지켜집니다.
Section 02
신뢰 계층: Master · Verified · Candidate
Orbit Field 위의 모든 데이터는 출처에 따라 세 등급으로 분류됩니다. 이 분류는 권한 관리가 아닙니다 — 데이터의 신뢰도를 구분하는 것입니다.
| 계층 | 출처 | Orbit에서의 역할 | 충돌 시 |
|---|---|---|---|
| Master | HR, 결재 시스템, 공식 ERP | 진위가 확정된 source-of-truth | 항상 우선 |
| Verified | Git, 캘린더, 전자세금계산서 | 검증 가능한 자동 시스템 데이터 | Master 이하 우선 |
| Candidate | Notion, Figma, Slack, 수동 입력 | 사람이 작성한 비공식 자료 | 참고만 가능 |
핵심 규칙: Candidate 데이터는 AI 추천, Conductor 우선순위, Sentinel 사건 판단에 단독 근거로 사용되지 않습니다. 반드시 Verified 이상과 교차 확인됩니다.
Candidate가 나쁜 데이터라는 뜻이 아닙니다. Notion 문서가 정확할 수 있고, Slack 메시지가 중요한 맥락을 담을 수 있습니다. 하지만 그 정확성을 시스템이 자동으로 보장하지 못하기 때문에, 운영 판단의 단독 근거로는 사용하지 않는 것입니다.
Section 03
조직 격리: 정책이 아니라 구조
멀티 테넌트 환경에서 가장 중요한 보장은 한 조직의 데이터가 절대 다른 조직으로 노출되지 않는 것입니다. Orbit은 이를 정책이 아니라 구조로 강제합니다.
조직 전환 시 완전 격리
사용자가 조직을 전환하면 이전 조직의 sign-off, run, evidence, Dictionary가 보이지 않습니다. 세션 상태가 완전히 초기화됩니다.
기준의 조직 범위 제한
Dictionary의 기준, Authority의 권한, Protocol의 경계가 조직 범위 안에서만 유효합니다. A사의 Policy가 B사에 적용되는 일은 없습니다.
Cross-org 접근 차단
조직 간 데이터 접근 시도는 운영 전 검증에서 실패로 처리됩니다. 우회 경로가 아예 존재하지 않습니다.
Lineage 격리
감사 가능한 추적 경로(Trace)도 조직 경계 안에서만 재현됩니다. 한 조직의 판단 경로가 다른 조직에서 재생되지 않습니다.
격리는 편의가 아니라 요구사항입니다. 같은 Orbit 인스턴스를 쓰더라도, A사의 운영자가 실수로 B사의 Tax Field를 보는 일이 구조적으로 불가능해야 합니다. 이 보장이 없으면 엔터프라이즈 도입 자체가 불가능합니다.
Section 04
신뢰 충돌이 일어나면
같은 Field 위에 Master와 Candidate 데이터가 동시에 올라오면 어떻게 됩니까? Orbit은 충돌을 숨기지 않고 명시적으로 표면에 올립니다.
ERP(Master)에서 4월 매출 5.2억이 동기화된다.
영업팀 Notion(Candidate)에 4월 매출 5.8억이라는 메모가 있다.
Sentinel이 충돌을 감지: "매출 데이터 6천만원 차이, Master vs Candidate."
Atlas에서 5.2억(Master)이 공식 상태로 표시되고, 5.8억은 참고 주석으로 붙는다.
재무팀이 확인 후 영업팀 Notion의 6천만원이 다음 달 예약 매출임을 확인한다.
| 충돌 유형 | Orbit의 처리 | 사람의 역할 |
|---|---|---|
| Master vs Candidate | Master 우선, Candidate는 참고 주석 | 차이 원인 확인 |
| Master vs Verified | Sentinel 사건 생성, 판단 보류 | 어느 쪽이 최신인지 확인 |
| Verified vs Candidate | Verified 우선, 차이 기록 | Candidate 업데이트 여부 판단 |
| 같은 계층 간 충돌 | 시간순 최신 + 충돌 알림 | 승인자가 올바른 버전 선택 |
Section 05
자동 검증과 Acceptance Run
신뢰 구조가 실제로 작동하는지는 Acceptance Run에서 자동으로 검증됩니다. 매번 새 Field가 열리거나 Pilot이 시작될 때, 아래 항목들이 자동으로 점검됩니다.
Data Classification
모든 데이터에 신뢰 등급이 올바르게 부여되었는가
Org Boundary
조직 간 데이터가 완전히 격리되었는가
Authority Scope
기준의 승인 권한이 올바른 범위에만 적용되는가
Protocol Gate
AI 실행 경계가 계약대로 작동하는가
Trace Integrity
모든 판단의 추적 경로가 재현 가능한가
Conflict Resolution
신뢰 충돌이 올바른 우선순위로 해소되는가
보안은 추상이 아닙니다. "우리는 안전합니다"라는 약속은 의미가 없습니다. Acceptance Run에서 매번 자동 검증되는 구조 — 그것이 보안입니다. 검증을 통과하지 못하면 운영이 시작되지 않습니다.
Section 06
인증 · 컴플라이언스와 운영 연결
Orbit의 신뢰 구조는 외부 인증과도 연결됩니다. 다만 인증은 출발점이지 도착점이 아닙니다 — 인증을 받았다고 해서 매일의 운영이 안전한 것은 아닙니다.
| 인증 | 상태 | Orbit과의 연결 |
|---|---|---|
| SOC 2 Type II | 2025 취득 | 데이터 처리, 접근 통제, 가용성 검증 |
| ISO 27001 | 2024 취득 | 정보보안 관리체계 전반 |
| SSO · SCIM · RBAC | 기본 제공 | 조직 인증 및 권한 관리 통합 |
| BYOK · Data Residency | 요청 기반 | 고객 키 관리, 데이터 지역 제한 |
중요한 것은 이 인증들이 Orbit의 Trust Loop — Authority, Protocol, Memento, Bridge — 과 연결되어 매일 운영에서 작동한다는 점입니다. 인증서가 벽에 걸려 있는 것이 아니라, 매 Acceptance Run에서 자동으로 검증됩니다.
다음 단계. 신뢰 구조를 이해했다면, 실제 도입이 어떻게 진행되는지 — 6주 파일럿 가이드를 읽어보세요.