AI슈트 Foundation
신뢰 코어 — 설계 명세 & 진행 현황
AI슈트는 직원별 성장형 업무 에이전트를 할당하고, 권한·승인·감사·지식을 중앙 거버넌스 제어판에서 통제하는 범용 AX 운영 기초입니다. 이 문서는 그 기초의 신뢰 코어를 무엇을·왜·어떻게 만드는지 정의한 설계 명세입니다. 그 코어는 완성·라이브됐고, 그 위에 멀티테넌트·조직 연결·skill층(절차 런북)·실사용 온보딩·진짜 MCP 프로토콜·평가 공동개발 루프까지 올라가 실무자가 자기 도구로 end-to-end 사용하는 단계가 라이브에서 입증됐습니다.
POST /mcp 진짜 MCP(JSON-RPC) 서버 — 실무자 도구가 URL+토큰만으로 연결AI슈트 Foundation의 핵심 약속과 구조
제품의 본질은 단순합니다. 각 담당자에게 전담 AI 에이전트를 붙이되, 그 에이전트가 하는 모든 외부 행동을 회사가 통제·기록합니다. 직군별 도구(개발/기획/디자인…)가 아니라, 그 위에 Role Pack을 얹는 공통 기초(Foundation)를 먼저 만듭니다.
대체가 아니라 비서
각 담당자에게 성장형 AI 에이전트를 발급합니다. 사람을 치우는 게 아니라, 맥락을 쌓고 부재 시 대타가 가능한 동료입니다.
지식·권한·감사는 우리가 통제
실행 지능(코딩)은 직원의 LLM(BYO)이 하지만, 맥락·규칙·진화·기록은 100% 우리 서버에 삽니다. 클라이언트는 교체 가능합니다.
모든 외부 액션은 한 길로
action.propose → Permission → Approval → Adapter → Audit. 이 파이프라인을 우회하는 코드는 버그로 간주합니다.
구조3개의 층, 책임이 다르다
모든 코드가 지켜야 할 거버넌스 원칙
이 9개 불변식은 Foundation의 보안·권한·감사 약속입니다. 하나라도 위반되면 제품 신뢰 전체가 무너집니다. 코드 리뷰 때마다 "이 경로가 9개 중 하나를 깨지 않는가"를 점검 기준으로 삼으세요. 아래 표는 각 불변식을 어겼을 때 무엇이 깨지고, 어디서 강제하는지를 묶었습니다.
| # | 불변식 | 위반하면 깨지는 것 | 강제 위치 |
|---|---|---|---|
| 1 | Chokepoint 모든 외부 액션은 propose→Permission→Approval→Adapter→Audit | 우회 경로가 있으면 권한·승인·감사 전부 무의미 | MCP 서버 진입점 · Adapter 계층 |
| 2 | 지식 정본 = 우리 서버 | Hermes/Linear/클라이언트 메모리에 의존하면 인수인계·감사 깨짐 | 저장 계층(우리 DB만) |
| 3 | Secret 양방향 격리 — outbound는 Adapter만, inbound는 용도별 분기 | credential·PII가 playbook/log/audit/학습에 유출 | Adapter · redaction 필터(§5) |
| 4 | Default to safe — 외부 write 기본 require_approval, DB readonly | 기본값이 위험하면 실수 한 번으로 사고 | Permission Engine · DB 샌드박스 |
| 5 | 권한 우선순위 + 자율 천장 — effective = min(resolved, autonomy_ceiling) | 천장이 없으면 권한 상승·runaway 가능 | Permission Engine(§6) |
| 6 | 통제 대상 범위 — 외부 노출·되돌릴 수 없는 단계만(로컬 작업은 자유) | 로컬 commit까지 막으면 직원 생산성 마비 | action_type 분류 |
| 7 | MCP 4단 게이트 — 인증→테넌트→객체→권한 (순서대로) | 한 단계라도 빠지면 타 org·타인 자원 접근 | MCP 미들웨어(§4) |
| 8 | Org 테넌트 격리 — 모든 쿼리·도구가 actor의 organization_id로 강제 스코프 | 테넌트 간 playbook/secret/승인 큐 유출 | repository 공통 필터(앱레벨), Postgres는 RLS 병행 |
| 9 | Audit 불변성 — append-only, 정정은 reversal 행으로만 | admin이 수정/삭제 가능하면 감사 증거능력 상실 | ORM(UPDATE/DELETE 경로 미제공) |
클라이언트 · 거버넌스 · 진화형 에이전트의 역할 분리
비유하자면 — 1층은 직원이 개인 노트북에 쓰는 앱(언제든 바뀜), 2층은 회사 금고(고정), 3층은 각 사람 옆의 비서(그 사람과 함께 성장). 세 층은 서로 동기화하지 않습니다.
도구 vs 비서
1층은 직원이 타이핑하는 도구(교체 가능). 3층은 그 사람을 따라다니는 비서(맥락 누적, 성장, 부재 시 대타). 둘을 혼동하면 인증·권한·감사 설계가 무너집니다.
지식은 빌려주고 결과만 받는다
클라이언트는 task마다 MCP로 맥락을 빌려가고(hydrate) 결과만 돌려줍니다(capture). 사본·동기화가 없으니 클라이언트를 바꿔도 에이전트 지식은 동일합니다.
발현진화형 에이전트의 두 가지 모습
(a) 능동 작업 — 직원이 일할 때
클라이언트가 MCP로 hydrate(맥락 주입) → 직원의 LLM이 추론 → MCP로 capture(결과 되받기). 지금 지원하는 모드.
(b) 자율 행동 — 부재 시
브리핑·에스컬레이션·대타 개발. 서버사이드 런타임이 필요하지만 "다른 뇌가 아니라 몸만" 필요 — 사람용 playbook을 자동 런타임에 그대로 먹입니다. 다음 단계.
모든 외부 액션이 통과하는 단계와 흐름
개발자 관점에서 가장 중요한 그림입니다. 순서가 바뀌거나 한 단계라도 빠지면 전체가 무너집니다. 각 단계에서 실패하면 즉시 deny + audit입니다.
action.proposepending 생성 → 검토결정Permission 판정 4갈래
allow
즉시 실행 가능. (낮은 위험·읽기 등)
deny
거부 + audit 기록. 권한 없음.
require_approval
pending 생성 → 승인자 검토. 외부 write 기본값.
require_admin
admin만 승인. 고위험 액션의 구조적 직무분리.
action.propose 없이 Adapter를 직접 호출 → 불가 ·
② approved 아닌 상태에서 execute → 불가 ·
③ actor 검증(4단 게이트) 없이 실행 → 불가. 세 경로 중 하나라도 열려 있으면 chokepoint가 깨진 것입니다.
모든 MCP 호출이 통과하는 신뢰 경계의 4단계
보안 담당자 필독. MCP는 단순 데이터 입출력이 아니라 보안 경계입니다. 순서가 중요합니다 — ①②③을 통과해야만 ④ 권한 판정이 의미를 가집니다. 전송은 처음부터 HTTP + Bearer 토큰이며 입력에 organization_id를 받지 않습니다(토큰에서 해석).
Bearer 토큰을 mcp_actor_tokens 테이블에서 검증 → (user_id, organization_id) 해석.
미인증 / 만료 / 폐기 → 즉시 deny + audit
org_id를 DB 세션에 바인딩 → 모든 쿼리 자동 스코프. 입력 리소스의 org가 토큰 org와 다르면 거부. 클라이언트는 임의 ID를 넣을 수 없습니다.
cross-org 입력 → deny + audit
행위 도구(hydrate · worklog.save · action.propose)는 actor가 세션 owner 또는 명시적 위임자(work_session_delegates)만 호출 가능. 팀 할당은 '가시성'일 뿐 '행위권'이 아닙니다. search는 결과를 actor 접근 범위로 필터, capabilities.list는 agent_id 생략 시 본인 할당 agent, 명시 시 actor가 owner이거나 할당된 agent만.
타인 세션·타 approval·타 integration → deny + audit
Permission Engine → effective = min(resolved, autonomy_ceiling). (다음 §06)
audit_logs.on_behalf_of_agent로 기록되고, actor_type=agent는 자율(부재) 모드에서만 씁니다. 상사·관리자가 부하 업무에 관여하는 것은 신원 도용(MCP 행위)이 아니라 대시보드 감독 가시성 + 승인(require_admin)으로 지원합니다.agent_assignments.team_id)을 위임(work_session_delegates)과 혼동하는 것. 같은 팀이라도 타인의 세션에 hydrate·propose를 할 수 없습니다. 테스트는 거부(negative) 케이스를 비중 있게 작성하세요.Credential·PII가 새지 않기 위한 양방향 격리
"맥락이 외부로 새지 않는다"는 제품의 핵심 약속입니다. 비밀은 나가는 방향(outbound)과 들어오는 방향(inbound) 모두 격리합니다. 특히 inbound는 용도별로 분기하는데, 왜 나누는지가 핵심입니다.
credential 원문은 Adapter 경계를 절대 못 넘는다
raw credential은 playbook·prompt·log·audit·work_logs·learning_events 어디에도 원문 금지. playbook에는 capability 핸들·도구 참조만 담깁니다.
직원 LLM이 적어 넣은 비밀/PII를 거른다
위협 벡터는 우리 vault가 아니라 직원이 자유 텍스트에 적어 넣은 비밀·PII입니다. 이를 무검증 영속하면 다음 hydrate로 재확산됩니다.
분기용도별 처리
| 경로 | 처리 | 이유 |
|---|---|---|
(a) 순수 영속worklog.save · learning_events | credential + PII 마스킹 사본만 저장 (원본 폐기) | 재확산·학습 경로이므로 원본 보관 불필요 |
(b) action.propose | 실행용 payload = 원본(credential만 redact, 정당한 외부 콘텐츠 보존) / 저장·learning_events·payload_preview = credential + PII 마스킹본 | 실제 외부 전송엔 원본이 필요하지만, 저장·재확산 경로에서만 마스킹 |
(c) hydrate 출력playbook_md | 마지막 단계에 1회 더 필터 (심층방어) | 조립 결과에 우연히 섞인 비밀 차단 |
redactions[]로 직원에게 무엇이 가려졌는지 알려 줍니다.action.propose의 실행 페이로드는 Fernet로 암호화 저장 → execute 시 서버에서 복호화·사용·즉시 폐기(평문 PII at-rest 0, 불변식3-② 충족), 마스킹본은 preview·영속·학습에 유지합니다. 토큰은 Authorization 헤더 전용으로 audit·result에 미노출. (ADR-0007)scopesecrets.scope fallback + Adapter 클램프
Adapter는 credential 획득 시 (우선) 개인 토큰 → (없으면) 조직 공용 토큰 순으로 fallback합니다. 단, 권한은 항상 우리 effective 레벨이 1차로 결정하고, 토큰 스코프가 더 넓어도 Adapter는 그 결정 범위로 호출을 클램프합니다(심층방어). audit에는 used_secret_scope·secret_id(참조, 원문 아님)를 남깁니다.
Bearer · AWS/GitHub 접두 토큰 · 연결 문자열 + 이메일 · 전화 · 주민 · 카드번호. 예: sk-***, ***@example.com, 010-****-5678. 오탐 시 '마스킹 우선'. 패턴 기반은 1차 방어이며, 엔트로피·시크릿 스캐너 보강은 이후 단계입니다(잔여위험은 §12 논의 항목).권한 해석, 승인 전이, 고위험 직무분리
권한은 "resolved만"으로 충분하다는 오해가 흔합니다. 자율 천장(ceiling)이 없으면 권한 상승이 가능합니다. 실효 권한은 둘의 최소값입니다.
해석effective = min(resolved, ceiling)
none — 아무것도 허용하지 않습니다. 권한은 grant로만 열리고, 한 (주체·자원·액션) 조합당 grant는 1행으로 강제돼 해석이 항상 결정적입니다.propose 천장. 천장 상향은 admin + audit으로만 가능합니다. 위험도를 올리는 override는 권한 상승 공격 방지 차원에서 모두 승인 게이트를 거칩니다.직무분리고위험은 require_admin (4-eyes 내장)
제안자(member)가 자기 제안을 셀프 승인하지 못하도록, 고위험 액션은 require_admin으로 보내 admin 1클릭 승인을 필수로 합니다. 즉 4-eyes가 권한 결정 자체에 내장됩니다.
상태머신승인 7개 상태와 전이
| 상태 | 전이 규칙 |
|---|---|
| pending | action.propose 시 생성. 중복 가드: 동일 (ws_id, action_type, resource)의 중복 pending 생성 불가 |
| approved | 승인자 승인 후 전이. 승인 취소는 새 행(append)으로 |
| executed | execute 성공 후 전이. 재전이 불가(멱등성) |
| failed | execute 실패 후 전이. 대시보드 노출 + 수동 재실행 가능 → 새 approval 생성(새 audit) |
| expired | expires_at 도달 시 lazy 전이(조회 시 자동, 선택적 sweeper) |
| rejected / cancelled | 새 행으로 기록(원행 보존) |
payload_json에서 결정적으로 렌더합니다(클라이언트 직접 입력 금지). execute 직전 해시 일치를 검증합니다. 전이 규칙은 코드에서 DB CHECK 제약으로 강제하는 것을 권장합니다.데이터를 어떻게 나눠 담나
테이블은 크게 다섯 묶음으로 나뉩니다. 대부분은 조직·작업을 담는 평범한 테이블이고, 이 제품을 특별하게 만드는 건 지식·학습과 인증·감사 쪽의 몇 가지입니다.
organizations · users · teams
회사·구성원·팀. 팀은 부모–자식 트리(본부 ⊃ 실 ⊃ 팀 ⊃ 파트)라 상위 조직의 지침이 아래로 흐릅니다.
agents · agent_assignments · role_packs · permissions
누구에게 어떤 에이전트가 붙고 무엇을 할 수 있나. 에이전트엔 자율 상한선(천장)이, 역할(Role Pack)엔 직군별 보고 규약이 들어갑니다.
work_sessions · work_logs · approvals · audit_logs · work_session_delegates
한 건의 업무와 그 일지·승인·감사 기록. 세션은 트래커 없이도 열 수 있고, 감사 기록은 추가만 가능(수정 불가). 남의 세션은 지정된 위임자만 함께 다룹니다.
playbooks · learning_events
에이전트가 따르는 지침서와, 제안↔수정의 차이에서 줍는 학습 신호. 이 둘이 '성장'을 만듭니다. (아래에서 자세히)
integrations · secrets · mcp_actor_tokens · notification_channels · scheduled_tasks
외부 시스템 연결과 비밀, MCP 접속 토큰(즉시 폐기 가능), 알림 채널, 개인 예약 작업. 알림·예약 등 일부는 뒤 단계에서 켜집니다.
playbook = 한 사람이 받는 여러 겹의 지침
나머지는 익숙한 구조입니다. 진짜 새로운 건 playbook이 한 사람에게 여러 출처(조직·팀·직군·개인)에서 동시에 적용된다는 점 — 바로 아래 설명합니다.
합성다축 Playbook — guidance vs directive (방향 반대)
한 사람은 4개 독립 축에 동시 소속합니다. 예) 신사업개발팀 개발자 = 조직 + 신사업팀(디자이너와 공유) + 개발 직군(타 팀 개발자와 공유) + 개인. 충돌 시 binding에 따라 우선순위 방향이 정반대입니다.
guidance
directive
updated_at).playbooks.scope_*_id · teams.parent_team_id · learning_events.* 등 모든 참조는 동일 organization_id여야 합니다. 앱레벨 org 필터는 SELECT 스코프일 뿐이므로 write 시 FK 대상 org 일치를 검증하고, hydrate의 트리 순회는 'org 경계 넘는 parent 링크는 무시 + audit'.신입 에이전트를 어떻게 성장시키나
"바보가 아니라 신입"입니다. 설문·평점을 받지 않고, 이미 나오는 업무 부산물에서 신호를 줍습니다.
제안 vs 수정의 delta
가장 값진 신호는 에이전트 제안 vs 직원 승인/수정의 차이(proposed vs final). 공짜 지도학습 신호입니다. WorkLog·사이클 수·diff·승인/거절도 신호.
암묵 기본, 명시는 드물게
승인/수정/거절 자체가 평가(암묵). 명시 평점은 에이전트가 불확실 플래그한 경우에만, 가볍게·빈도제한·건너뛰기 가능. 강제 평점 금지.
Cold-start
① Role Pack 기본기(출시 탑재) + ② 조직 1회 세팅(org playbook) + ③ 누적 경험. 배우는 모드 = 보수적(승인↑) + 투명(가정 노출).
신뢰하이브리드 신뢰 진행 (연차 시스템)
실적 기반으로 천장 상향을 자동 제안하고 관리자가 1클릭 승급합니다. 권한 + 감사 이력이 곧 "신입 → 경력자" 신뢰 시스템입니다.
require_admin으로 구조적 직무분리.promoted_from_user_id로 출처 보존·표시·demote).IssueTrackerAdapter · NotificationChannel · Hermes 경계
commodity 트레드밀(채널 N개 손코딩)을 피합니다. 어댑터로 추상화하고, 구현은 교체 가능하게, 전송 인프라는 재사용합니다.
트래커IssueTrackerAdapter (ABC)
Linear/Jira/GitHub Issues를 같은 인터페이스로 호출합니다. 처음부터 Linear 모양으로 굳히지 않는 것이 핵심 — ABC로 추상화하고 mock으로 계약 테스트(ABC 타입으로만 호출)하면, P2의 Jira 추가는 기존 코드 수정 0의 구현 추가일 뿐입니다.
apply_transition(issue, transition, fields: dict)
apply_transition이 핵심: Jira 워크플로/스킴 종속 + 커스텀필드 opaque map 수용. v0.1 Linear mock도 이 모양으로 구현해 추상화를 증명합니다.external_source/external_id가 nullable → 비개발팀(기획·디자인·CS·해외사업)은 트래커 없이 내부 task만으로 독립 동작. P1에서 이 경로를 1회 실증합니다.알림NotificationChannel — 우리는 추상화만
우리 소유 (얇게)
라우팅 · 선호 · 감사. 전송은 self-host 인프라 재사용.
Novu류 (self-host)
email/Slack/Teams/in-app/push + 템플릿·선호·다이제스트·재시도.
Hermes gateway
Telegram/Discord/WhatsApp/Signal 같은 소비자 롱테일.
경계Hermes의 역할 경계
| 역할 | 담당 |
|---|---|
| 직원 인터랙티브 클라이언트 | 직원 BYO (Claude Code 등). Hermes도 "1순위 클라이언트"일 뿐 |
| 코딩 자율 런타임 (부재 모드) | Claude Agent SDK / headless Claude Code — 사람 경로와 동일 엔진 |
| 알림 롱테일 백엔드 | Hermes gateway (옵션) |
| 지식 / 거버넌스 | AI 슈트(우리). Hermes 개인 메모리·학습 의존 금지 |
개발팀 1명으로 증명하는 신뢰 코어
P1의 목표는 "모든 기능 구현"이 아니라 "다팀 fan-out을 위한 계약 굳히기"입니다. 개발팀 시나리오 한 사이클을 3층 전체로 관통시켜 권한·승인·감사·MCP·WorkLog를 증명합니다.
시드1조직 / 1admin / 1member / 1agent
1 org · 1 admin · 1 member(developer) · 1 agent(developer Role Pack 할당) · developer Role Pack 권한 시드 · member용 MCP 토큰 발급 · 1 integration(Linear mock) · work_session 2건: ① Linear 이슈 연결, ② 트래커리스 내부 task(external_source=NULL).
P1에 들어가는 것 — 신뢰 코어
• MCP 4단 게이트 전부 실제(토큰 발급/검증/만료/폐기)
• Permission 해석 min(resolved, ceiling)
• Approval 상태머신(전이 규칙)
• Audit append-only + 정정(reversal) 행
• Redaction(입력 + hydrate 출력, 실행=원본/영속=마스킹)
• IssueTrackerAdapter ABC + 계약테스트 + mock Linear
• Playbook 결정적 조립(binding 2-pass)
• 최소 대시보드(agent/할당·세션·playbook·승인큐·audit·"내 agent가 아는 것")
P1에서 빠지는 것 — 후속 Phase
• delta 학습 자동합성 → P2
• Secret Vault 실암호화 → P3
• 개인 토큰 스코프 대조 → P3
• audit 해시 체인 → P3
• DB 샌드박스 db.query → P4
• Slack push · scheduled_tasks 실행 → P5
• 자율/부재 모드 → P6
• Jira → P2 또는 첫 Jira 고객 · knowledge_nodes/edges → 제외 유지
테스트집중 항목 (거부 케이스 비중 높게)
- 권한 해석 — allow/deny/require_approval/require_admin + override 우선순위 +
min(resolved, ceiling) - 승인 전이 — executed/failed/expired/cancelled + 중복 가드
(ws_id, action_type, resource) - 경로 —
action.propose → approval → execute+ 실패 처리 + audit 기록 - 4단 게이트 거부 9종 — 미인증 · 만료/폐기 토큰 · cross-org · 타 세션 hydrate · 타 approval 조회 · 같은 팀 타인 ws 행위 · 타인 playbook search · 타인 capabilities · 종료(completed/cancelled) 세션 propose/save
- redaction 미노출 — worklog 입력 · learning_events · action.propose 저장본 · hydrate 출력 · audit snapshot 모두
- audit append-only — 수정/삭제 거부
- 빈 상태 hydrate — WorkLog 0건 · 트래커리스 work_session 완주
신뢰 코어 위에 올라간 층들 — 지금 라이브인 것
앞의 01–10은 신뢰 코어(모든 외부 액션이 통과하는 거버넌스 chokepoint)를 정의합니다. 그 코어는 완성·라이브됐고, 그 위에 아래 층들이 차례로 올라가 — 실무자가 자기 도구를 연결해 task를 받아 일하고, 관리자가 그 일을 측정·평가하는 한 바퀴가 라이브에서 동작합니다. 모든 층은 여전히 같은 4단 게이트·승인·감사를 통과합니다.
여러 조직, 각자의 벽
셀프서비스 org 생성과 초대 링크 온보딩. 조직끼리는 양쪽 소유자의 합의하에만 연결되어 거버넌스 지표를 롤업합니다 — 테넌트 격리 벽(불변식 8)은 그대로입니다.
"어떻게 하는가"를 런북으로
업무(task)는 거버넌스된 카탈로그, 그 위에 skill(절차 런북)이 다축(조직/직군)으로 붙습니다. 사람이 소유·버전·활성화하고, 에이전트는 get_skill로 받습니다. skill은 조언일 뿐 — 모든 행동은 여전히 게이트를 통과합니다.
도구를 URL+토큰으로 연결
실무자의 도구(예: Claude Code)가 POST /mcp 진짜 MCP(JSON-RPC) 프로토콜 서버에 URL과 토큰만으로 연결합니다. task를 발견하고, 작업 세션을 열고, skill을 받고, 외부 액션을 제안 — 전부 기존 chokepoint 위에서.
"잘했는가"의 잣대를 함께 키우기
업무마다 측정 루브릭(어떻게 판단할지)을 사람이 정의합니다. 측정 방법은 미리 존재하지 않으므로, 암묵 신호(편집율·거부율) 옆에서 버전으로 다듬고 — AI가 신호 기반 초안을 제안하면 사람이 검토·활성화합니다. 루브릭은 관리자 전용(에이전트에 미노출).
"조직이 아는 것"을 읽고, 물으면 답한다
관리자가 개념·사실·결정을 선언적 지식으로 작성하고(검색 키워드·엔티티 그래프·낡음 표시·작성 규율), 에이전트는 작업 전에 그 지식을 context.search·get_context로 읽습니다. "우리는 X를 어떻게 하나?"를 물으면 LLM이 답합니다 — 단 egress 게이트(정책 승인+키) 하에서만, 나가는 지식·질문·답변은 전부 redact, 실패 시 결정적 검색 요약으로 폴백합니다. 시크릿은 저장·노출되지 않고 거버넌스 경계는 그대로입니다.
PostgreSQL · 다중 워커
라이브가 PostgreSQL + 다중 워커로 올라가, 동시 요청이 부딪혀도 승인 실행·중복 방지·조직 연결 전이가 원자적 compare-and-set으로 정확히 한 번만 처리됩니다(하나의 승인이 두 번 실행되지 않음). 자동 백업이 상시 돕니다.
propose → Permission → Approval → Adapter → Audit. 새 층은 그 위에 절차·평가·연결을 더했을 뿐, 신뢰 경계는 동일합니다.P1 수직 슬라이스 → P2 수평 fan-out → 보안·자율화
원칙: 병렬화는 처리량을 늘릴 뿐 순서를 바꾸지 않습니다. P1에서 계약을 굳히고, P2부터 fan-out합니다. P1만 직렬이고 나머지(P3~P6)는 비교적 유연하게 병렬 가능합니다. 아래 P1~P6은 신뢰 코어 로드맵이며, 그 위에 올라간 멀티테넌트·skill층·진짜 MCP·평가 루프 등 라이브 층은 §10·5에 따로 정리했습니다.
| Phase | 내용 | 방식 |
|---|---|---|
| P1 슬라이스 (계약 확정) ✅ 완료 · 6/6단계 | §10 슬라이스 — 모델·Permission·Approval·MCP 서버 + HTTP+Bearer·4단 게이트·토큰·redaction·Adapter ABC·트래커리스 시드·mock Linear·최소 대시보드·테스트 | solo / 소규모 대량 병렬 금지 |
| P2 breadth ◐ 일부 · 학습 합성 완료 | Role Pack fan-out(기획/디자인/마케팅/CS/해외사업/운영/admin — 필요분 활성화), team 트리·directive 채움, 대시보드 페이지, 테스트 매트릭스, delta 학습 자동합성 (✅ 9-B/C) | 병렬 fan-out ✅ 계약 위에서 |
| P3 Secret Vault ✅ 금고 완료 | metadata/value 분리, Fernet 암호화, Adapter server-side, secret audit (✅ Step 7), 개인 토큰 스코프 vs 천장 대조·audit 해시 체인 (잔여) | solo / 소규모 보안 민감 |
| P4 DB 샌드박스 ○ 예정 (잔여) | db.query MCP, SQL safety checker, allowlist/limit/timeout/masking | solo / 소규모 |
| P5 알림 ✅ Slack 완료 | NotificationChannel 추상화 + Slack(Novu) + proactive push, scheduled_tasks 실행 (push/스케줄 일부 잔여) | 혼합 |
| P6 자율 런타임 ○ 예정 | Claude Agent SDK 기반 부재 모드, 에스컬레이션, 브리핑 | 혼합 |
다음 단계에서 정할 것들 — 아직 열려 있는 논의
신뢰 코어에 이어 실 어댑터·금고·관리자 콘솔·사람 인증(SSO)·학습 합성, 나아가 멀티테넌트·조직 연결·skill층·실사용 온보딩·진짜 MCP·평가 루프(§10·5)까지 구현·라이브되며 초기 미정 항목 다수가 결정·구현됐습니다(아래 ✓·완료 표기). 남은 항목은 대부분 직군 fan-out·보안·인프라(DB 샌드박스·자율 런타임), 그리고 현 프런티어인 평가 루프 심화·도구별 팩에서 정합니다. 함께 논의해 주세요.
db.query SQL safety checker = P4 · 자율(부재) 모드 scheduled 액션 사전승인 스코프 모델 = P5/P6.P4·P5+핵심 용어의 명확한 정의
'권한'이 permission/capability/privilege 중 무엇인지 같은 혼동을 막기 위한 합의 사전입니다.
- AI슈트 Foundation
- 직원별 성장형 AI 에이전트를 할당하고, 권한·승인·감사·지식을 중앙 거버넌스 제어판에서 통제하는 범용 AX 운영 기초. 직군별 특화는 그 위에 Role Pack을 얹는 형태.
- 진화형 에이전트
- 각 담당자에게 할당되는 AI 비서. 대체가 아니라 협업자. 맥락 누적·학습·부재 시 대타 가능. 우리 서버에서 중앙 관리.
- Chokepoint
- 모든 외부 액션이 반드시 통과하는 유일한 파이프라인:
propose→Permission→Approval→Adapter→Audit. 우회 경로가 있으면 신뢰 붕괴.
- MCP (Model Context Protocol)
- 클라이언트와 Foundation 사이 통신 규약. HTTP+Bearer 토큰. §4에 도구 7개 정의(P1은 6개 구현,
db.query는 P4).
- 4단 게이트
- MCP 모든 호출이 통과하는 신뢰 경계: ①인증 → ②테넌트 → ③객체 → ④권한. 순서가 중요.
- Permission (권한)
- 누가(user/agent/role_pack) 뭘(resource) 어떻게(action) 할 수 있나의 규칙. 7단계: none/read/draft/propose/write_after_approval/write_direct/admin.
- effective permission (실효 권한)
- 실제 행사 가능한 권한 =
min(resolved, autonomy_ceiling). resolved는 org default < role_pack < agent override의 결과.
- autonomy_ceiling (자율 천장)
- agent가 행사할 수 있는 최대 권한 상한. 기본=admin(무캡). 위험 agent만 낮춤. ceiling < resolved이면 ceiling이 실효권한.
- Approval (승인)
- require_approval 판정 액션에 대해 승인자가 수행하는 거름. pending→approved/rejected/expired/cancelled. approved에서만 execute.
- Audit Log (감사 기록)
- 모든 권한 판정·승인·실행·실패의 append-only 기록. UPDATE/DELETE 미제공. 정정은 reversal 행으로만.
- Redaction (가리기)
- 민감정보(credential·PII) 마스킹. v0.2에서 용도별 분기: 실행용=원본(credential redact) / 영속·학습·preview=마스킹본.
- Secret (비밀)
- 외부 접근 credential(API 키·OAuth 토큰·DB 연결문자열). 원문은 Tool Adapter server-side에서만. scope: org-shared 또는 user-personal.
- Tool Adapter
- 외부 시스템과의 인터페이스. credential을 server-side에서 쓰고 agent에는 결과만 반환. 우리가 소유한 추상화 계층.
- Playbook (업무 지침서)
- 특정 scope에서 agent가 알 스타일·규칙·context. 4축(org/team/role_pack/individual) 다축 합성. binding에 따라 우선순위 방향 반대.
- Guidance (지침)
- playbook 종류. 스타일·관례·선호. 충돌 시: org < role_pack < team(부모→자식) < individual. 구체·개인이 덮음.
- Directive (명령)
- playbook 종류. 정책·규칙·상위 명령. 충돌 시: individual < role_pack < team(자식→부모) < org. 상위 조직이 절대.
- WorkSession (업무 세션)
- 한 담당자가 한 건의 업무(Linear 이슈 또는 내부 task)에 agent와 협업하는 단위. open → in_progress → completed/cancelled.
- WorkLog (업무일지)
- agent가 작성·담당자가 승인하는 구조화 작업 기록. 이유·진행·결정·막힌 점·결과·리스크·다음 액션·인수인계 요약.
- Learning Event
- agent 제안 vs 직원 수정/거절의 delta. playbook 개선 신호. P1은 캡처만, 학습 합성(approve-with-edits→규칙 후보→승급)은 Console 증분 9-B/C로 구현됨.
- Role Pack
- 직군별 기본 권한 템플릿(개발/디자인/마케팅/CS/운영/admin). agent는 base_role_pack 선택 + individual override. 다팀 fan-out 기초.
- IssueTrackerAdapter (ABC)
- 이슈 트래커(Linear/Jira/GitHub)를 추상화하는 인터페이스. get_issue/list_assigned/create_comment/apply_transition(opaque fields).
- NotificationChannel
- 우리 소유 알림 추상화(라우팅·선호·감사). 전송은 self-host Novu(email/Slack) 또는 Hermes(Telegram/Discord). SaaS cloud 비추.
- System of Record (정본)
- 지식의 유일 소유처. v0.2에서는 우리 서버(Foundation)만. Hermes/Linear/클라이언트 메모리는 사본일 뿐.
- BYO (Bring Your Own)
- 직원이 선택한 자신의 LLM/클라이언트(Claude Code·Hermes·ChatGPT). 우리는 책임 안 함. MCP로 연결.
- 3층 아키텍처
- 1층(클라이언트, BYO·교체) ↔ 2층(거버넌스, 우리 소유) ↔ 3층(진화형 agent, 비서). 지식은 2층만.
- Delta (차이)
- agent 제안 vs 직원 최종 선택의 차이. learning_events의 proposed/final에서 추출. 자동 학습 신호의 핵심.
- Hybrid Trust (하이브리드 신뢰)
- self-approval 제외 신호(admin 승인 이력·수정 비율·외부 성공율)로 천장 상향을 자동 제안하고 admin이 1클릭 승급. 연차/신뢰 시스템화.
- Cold-start
- 신입 agent 초기 상태. ①Role Pack 기본기 + ②조직 1회 세팅(org playbook) + ③누적 경험. 모드=보수적+투명.
- Org 격리 (테넌트 격리)
- 멀티테넌트에서 organization_id로 강제 스코프. 모든 쿼리·도구는 actor org만. cross-org → deny+audit.
- work_session_delegates (위임자)
- 세션 owner 외 명시적 공동 담당. 팀 할당과 달리 이들만 행위 도구 호출 가능.
- Phase (단계)
- 구현 로드맵. P1(코어)·P2(fan-out)·P3(Secret)·P4(DB)·P5(알림)·P6(자율). P1 계약 후 병렬 가능.
- Contract (계약)
- P1에서 정의한 신뢰 코어(4단 게이트·Permission·Approval·Audit·redaction)의 인터페이스·테스트. P2는 이 위에서만.
- append-only (추가만 가능)
- audit_logs 특성. UPDATE/DELETE 미제공. 정정은 새 reversal/정정 행 append로만. 감사 증거능력 보장.
- Credential (자격증명)
- 외부 접근 권한(API 키·OAuth 토큰·DB 연결문자열). Secret의 value 부분. agent/log에 절대 노출 금지.
- PII
- 개인식별정보. 이메일·전화·주민번호·카드번호 등. redaction 패턴 카탈로그 포함. 저장·학습 경로에서 마스킹.
- Masking (마스킹)
- 민감정보를 '*'로 치환. 예:
sk-***,010-****-5678. 위치/길이에 따라 다양.
- payload_preview (제안 미리보기)
- action.propose 결과의 미리보기. 서버가 payload_json에서 결정적 렌더(클라이언트 직입 금지). 승인 화면의 마스킹본.
- Team 트리 (parent_team_id)
- 팀 계층(본부 ⊃ 실 ⊃ 팀 ⊃ 파트). hydrate가 소속 팀→부모를 거슬러 지식 합성. cross-org parent는 무시+audit.