Orbit · 가이드 · Chapter 09
Authority
기준의 출처와 승인을 지키는 층
단순한 권한 관리가 아니라, 조직의 기준이 어디서 왔고, 누가 승인했고, 어디까지 적용되는지 지키는 신뢰의 층.
Section 01
한 장면 — 신입이 정책 용어를 바꾼 날
개념을 펼치기 전에 장면 하나부터 봅니다. 구매팀에 합류한 지 2주 된 수현의 첫 번째 목요일입니다.
팀장이 "외주 계약 정책 문서 정리해 둬" 라고 Slack에 남긴다.
수현이 Dictionary에서 "외주비"를 "외부 용역비"로 용어를 수정한다. 같은 뜻이라고 판단했다.
Protocol 3건이 "외주비"를 참조하고 있었다. AI Agent가 새 용어로 정책을 재해석한다.
Sentinel이 경고를 띄운다 — "외주비 3천만 원 초과 시 본부장 승인" 규칙이 더 이상 매칭되지 않는다.
본부장이 묻는다. "승인 규칙이 왜 작동 안 해?"
수현의 의도는 나쁘지 않았습니다. 하지만 Authority가 없는 시스템에서는 누구든 검증된 용어를 수정할 수 있고, 그 수정이 즉시 Protocol과 AI에 전파됩니다. 한 사람의 선의가 조직의 승인 체계를 무력화한 것입니다.
Authority가 있는 시스템이라면 같은 시도에서 전혀 다른 결과가 나옵니다:
수현은 "외부 용역비"를 후보(Candidate)로 제안할 수 있습니다. 하지만 기존의 Verified 용어 "외주비"를 직접 바꿀 수는 없습니다. 변경은 권한 있는 Approver가 검토한 뒤에만 반영됩니다. Authority는 선의의 실수가 조직 전체로 전파되는 것을 구조적으로 막습니다.
Section 02
Authority가 무엇인가
Authority를 "권한 관리"라고 부르면 절반만 맞습니다. 권한 관리는 "누가 무엇을 할 수 있는가"에 답합니다. Authority는 그보다 넓은 질문에 답합니다 — 이 기준은 왜 믿을 수 있는가.
같은 문장이라도 출처에 따라 힘이 다릅니다. 본사 정책 위원회가 승인한 규칙과 팀 Slack에서 합의한 관행과 AI가 패턴에서 추출한 제안은 같은 선반에 놓일 수 없습니다. Authority는 이 신뢰의 위계를 운영 시스템 안에 심습니다.
인감과 메모의 차이. 회사 대표의 인감이 찍힌 계약서와 팀장이 메모장에 적은 합의는 법적 효력이 다릅니다. 둘 다 "기준"이지만, 하나는 검증된 것이고 하나는 참고 수준입니다. Authority는 디지털 운영에서 이 구분을 강제합니다.
정확한 정의: Authority는 조직의 기준(Term, Policy, Decision Rule)이 어디서 왔고, 누가 검증했고, 어느 범위에 적용되며, AI와 시스템이 어떤 수준까지 활용할 수 있는지를 관리하는 신뢰 계층입니다.
| 구분 | 일반 권한 관리 | Authority |
|---|---|---|
| 핵심 질문 | 누가 접근할 수 있는가? | 이 기준은 왜 믿을 수 있는가? |
| 관리 대상 | 사용자 + 리소스 | 기준의 출처 · 승인 · 범위 · AI 권한 |
| 상태 분류 | 허용 / 거부 | Candidate → Review → Verified |
| AI 관계 | 읽기/쓰기 제어 | 참조만 / 제안 가능 / 실행 가능 구분 |
| 변경 이력 | 로그 | Memento로 승인 맥락까지 보존 |
Authority가 없으면 Orbit의 다른 레이어들이 흔들립니다. Dictionary의 용어가 아무나 바꿀 수 있으면 Protocol이 예측 불가능해지고, Protocol이 불안하면 Agent Studio의 자동화를 신뢰할 수 없습니다. Authority는 신뢰 체인의 첫 번째 고리입니다.
Section 03
네 개의 기둥 — Source · Approver · Scope · Permission
Authority가 기준을 지키는 방식은 네 기둥으로 나뉩니다. 네 기둥 중 하나라도 빠지면 신뢰의 빈틈이 생깁니다.
Source
기준이 어디서 왔는가 — 정책 위원회, 법규, 현장 관행, AI 추출
Approver
누가 검증했는가 — 승인자, 승인 일시, 승인 조건
Scope
어디까지 적용되는가 — 법인, 팀, 기간, 업무 유형
Permission
AI/시스템이 무엇을 할 수 있는가 — 참조, 제안, 실행
결합
네 기둥이 모여야 하나의 신뢰 가능한 기준이 된다
Source — 출처의 무게
같은 "외주비 3천만 원 초과 시 본부장 승인"이라도, 어디서 왔는지에 따라 기준의 무게가 달라집니다. 이사회 결의에서 나온 규칙과 팀 회의에서 합의된 관행과 AI가 과거 데이터에서 추출한 패턴은 신뢰도가 다릅니다.
| Source 유형 | 예시 | 기본 신뢰 수준 |
|---|---|---|
| 법규 / 외부 규정 | 세법, 노동법, 감독 기관 고시 | 최상위 — 자동 Verified |
| 정책 위원회 결의 | 이사회, 내부 통제 위원회 결정 | 상위 — 위원회 승인으로 Verified |
| 부서 합의 | 팀 미팅, Slack 합의, 구두 약속 | 중간 — Approver 검토 필요 |
| AI 추출 패턴 | 반복 관찰된 승인 기준, 관행 | 후보 — 사람 승인 전 실행 불가 |
Approver — 검증의 책임
Approver는 단순히 "승인 버튼을 누른 사람"이 아닙니다. 기준이 올바르다는 것을 조직 안에서 책임지는 사람입니다. Approver가 명시되지 않은 기준은 아무리 내용이 좋아도 Candidate 상태를 벗어날 수 없습니다.
Scope — 적용 범위
기준은 무한정 적용되지 않습니다. 한국 법인의 외주비 승인 규칙이 일본 법인에 자동 적용되어서는 안 됩니다. Scope는 기준이 유효한 울타리를 정합니다. 자세한 내용은 Section 05에서 다룹니다.
Permission — AI의 경계
Authority에서 가장 독특한 기둥입니다. 같은 Verified 기준이라도 AI에게 허용되는 범위가 다릅니다.
참조만 (Reference Only)
AI가 기준의 존재를 알고 사용자에게 보여줄 수 있지만, 자동 판단에 사용하지 않는다. 민감한 인사 정책, 법무 해석 등.
제안 가능 (Suggest)
AI가 기준을 근거로 제안할 수 있지만, 실행은 사람이 확인한 뒤에만. 구매 승인 규칙, 예산 기준 등.
실행 가능 (Execute)
AI가 기준을 직접 적용해 자동으로 처리할 수 있다. 매출 자동 분류, 세금계산서 매칭 등 반복적이고 명확한 규칙.
Permission은 기준별로 다릅니다. "외주비 3천만 원 초과 시 본부장 승인"은 AI가 제안(S)할 수 있지만, "본부장 부재 시 대리 승인 허용 여부"는 참조(R)만 가능합니다. 같은 정책 문서에서 나왔더라도 항목마다 Permission이 다를 수 있습니다.
Section 04
Candidate에서 Verified까지
Authority에서 모든 기준은 태어날 때 Candidate입니다. AI가 과거 데이터에서 추출했든, 사람이 직접 등록했든, 검증을 거치기 전에는 같은 출발선에 놓입니다.
Candidate 등록
새 기준이 시스템에 들어온다. AI가 반복 패턴에서 추출하거나, 담당자가 직접 입력한다. 이 단계에서는 Protocol에 영향을 주지 않는다.
Review 요청
Candidate에 Source와 Scope를 붙여 Approver에게 검토를 요청한다. 관련 Protocol과 기존 기준과의 충돌 여부가 자동으로 표시된다.
충돌 검사
같은 Scope 안에 이미 유사한 기준이 있는지, 상위 정책과 모순되는지 시스템이 검사한다. 충돌이 있으면 Approver에게 함께 보여진다.
Approver 승인
Approver가 Source, Scope, Permission을 확인하고 승인한다. 승인 이유와 조건이 Memento에 기록된다.
Verified 전환
기준이 Verified 상태가 된다. 이제 Permission에 따라 Protocol과 AI가 이 기준을 참조·제안·실행할 수 있다.
Bridge가 최근 6개월 외주 계약 42건을 분석한다.
반복 패턴 발견: "5천만 원 초과 계약은 법무 검토를 거친다" — 38/42건 일치.
Candidate로 등록: source=AI추출, scope=구매팀/KR, permission=S(제안만).
구매팀장(Approver)이 확인. "맞다, 이건 실제 내부 규칙이다." Verified로 전환.
Permission을 S→X로 상향. "5천만 원 초과 시 자동으로 법무 검토 요청을 걸어도 된다."
AI는 절대 스스로 Verified를 만들지 않습니다. Bridge가 42건 중 38건이 일치하는 패턴을 발견해도, 그것은 여전히 Candidate입니다. 나쁜 습관이 38번 반복되었을 수도 있습니다. "자주 일어난다"와 "올바르다"는 다른 판단이고, 후자는 사람의 영역입니다.
| 상태 | Protocol에 영향 | AI 활용 범위 | 수정 가능자 |
|---|---|---|---|
| Candidate | 없음 — 격리 상태 | 화면에 "후보" 표시만 | 등록자 본인 |
| Review | 없음 — 심사 중 | Approver에게 충돌 분석 제공 | 등록자 + Approver |
| Verified | Permission에 따라 적용 | R: 참조 / S: 제안 / X: 실행 | Approver만 |
| Deprecated | 새 건에 미적용 | 이력 조회만 | Approver만 |
Section 05
Scope 경계 — 법인·팀·업무 범위
Authority에서 가장 자주 문제가 생기는 곳은 Scope입니다. 기준 자체는 올바른데, 적용 범위를 잘못 잡아서 엉뚱한 팀이나 법인에 규칙이 적용되는 사고가 반복됩니다.
Scope는 세 축으로 정의됩니다: 조직 단위(어느 법인, 어느 팀), 업무 유형(어떤 Field에 적용되는지), 기간(언제부터 언제까지 유효한지).
한국 법인: "외주비 3천만 원 초과 시 본부장 승인" — Verified, scope=KR/Finance.
일본 법인: 같은 기준 없음. 일본은 "5백만 엔 초과 시 부장 승인"이 별도 기준.
Scope가 없었다면 한국 법인 규칙이 일본 법인에도 적용되어 모든 외주 계약이 본부장에게 올라갔을 것.
Authority가 법인별 Scope를 분리했기 때문에 각 법인은 자기 기준만 따른다.
| Scope 축 | 역할 | 빠졌을 때 생기는 일 |
|---|---|---|
| 조직 단위 | 법인 · 사업부 · 팀 | 다른 법인 규칙이 자동 적용 |
| 업무 유형 | 구매 · 세무 · 인사 등 Field 종류 | 세무 규칙이 인사 업무에 간섭 |
| 기간 | 유효 시작일 · 종료일 | 만료된 규칙이 계속 실행 |
Scope는 상속되지 않습니다. 본사 정책이 있다고 해서 모든 자회사에 자동 적용되지 않습니다. 각 법인이 같은 기준을 채택하려면 해당 Scope의 Approver가 별도로 승인해야 합니다. 이것은 번거로움이 아니라, 각 조직의 맥락이 다르기 때문에 필요한 안전장치입니다.
Section 06
Authority가 연결하는 것들
Authority는 홀로 작동하지 않습니다. Orbit의 다른 레이어와 연결되어 기준의 생성부터 실행, 기록까지의 전체 생명주기를 만듭니다.
| 레이어 | Authority와의 관계 | 연결이 끊기면 |
|---|---|---|
| Dictionary | Verified 용어만 기준으로 인정 | 누구나 용어를 바꿔 기준이 흔들림 |
| Protocol | Permission 범위 안에서만 AI가 기준 활용 | AI가 후보 기준을 확정처럼 사용 |
| Bridge | 패턴을 Candidate로 올림, Verified는 못 만듦 | AI가 자동으로 기준을 확정 |
| Memento | 승인 이유, 조건, 변경 이력을 보존 | "왜 이 기준이 바뀌었는지" 추적 불가 |
| Sentinel | Scope 밖 적용 시도를 경고 | 엉뚱한 법인에 규칙 적용 |
| Field | 업무 건에서 어떤 기준이 적용됐는지 기록 | 같은 업무에 다른 기준이 적용되는 사고 |
Bridge가 반복 패턴을 발견하고 Candidate를 Authority에 등록한다.
Approver가 Dictionary의 용어를 확인하고, Scope를 지정해 Verified로 전환한다.
Protocol이 Permission(R/S/X)에 따라 AI Agent에게 기준을 전달한다.
Sentinel이 Scope 밖 적용, 만료 기준 사용, 충돌 발생을 경고한다.
Memento가 모든 변경과 승인의 맥락을 보존한다. 1년 뒤에도 "왜"를 확인할 수 있다.
Authority는 Trust Loop의 시작점입니다. Protocol이 AI의 행동 범위를 정하고, Memento가 이력을 보존하고, Bridge가 새로운 기준을 발굴하지만, 이 모든 것의 기초 — "이 기준을 믿어도 되는가" — 는 Authority가 답합니다. Trust Loop의 다른 장들은 Authority 위에 서 있습니다.