Operating Model

한눈에 보기

Operating Model은 사용자 요청이 KeystoneHub 안에서 어떤 경로로 흘러가는지 설명하는 중심 문서입니다. 요청을 바로 구현하지 않고, 목표와 경계, 계획, 실행, 검증, 기억, 회고로 나누어 다음 작업 품질까지 연결합니다.

• 핵심 질문: 하나의 요청을 어떻게 검증 가능한 작업 시스템으로 바꿀 것인가?
• 읽는 대상: 전체 운영 흐름을 가장 빠르게 파악하려는 방문자와 운영자
• 연결 문서: AX Solution Orchestration, Evidence Dashboard, Retrospective Loop

이 문서에서 확인할 것

• Intake부터 Evolution까지 이어지는 6단계 흐름
• 각 단계에서 묻는 핵심 질문과 산출물
• ai-rules, keystone-hub, keystone-portfolio의 역할 분담

요청에서 자가 발전까지

Operating Model은 Keystone 전체 메뉴의 중심입니다. 사용자 요청을 바로 구현으로 보내지 않고, 목표와 경계, 계획, 실행, 검증, 기억, 회고로 나눕니다.

flowchart LR
  A["01 Intake<br/>요청과 공개 경계"]
  B["02 AX Plan<br/>범위와 산출물"]
  C["03 Orchestration<br/>역할과 도구 선택"]
  D["04 Build & QA<br/>구현과 검증"]
  E["05 Memory<br/>결정과 증거 저장"]
  F["06 Evolution<br/>rule / skill / hook 후보"]

  A --> B --> C --> D --> E --> F --> B

단계별 판단

단계	핵심 질문	산출물
Intake	무엇을 만들고, 무엇을 공개하지 않을 것인가?	목표, 범위, 공개 경계
AX Plan	어떤 단위로 실행할 것인가?	plan pack, task graph, acceptance criteria
Orchestration	어떤 에이전트와 도구가 필요한가?	role assignment, skill/MCP/plugin 선택
Build & QA	결과가 실제로 동작하는가?	code, docs, tests, browser evidence
Memory	다음 작업에서 다시 쓸 판단인가?	decision note, fact, handoff
Evolution	반복을 줄이기 위해 무엇을 승격할 것인가?	rule, hook, skill, guide 후보

ai-rules와 keystone-hub의 역할

계층	담당
ai-rules	작업 원칙, 위험 등급, 에이전트 역할, sync 정책
keystone-hub	hooks, commands, Codex skills, settings, doctor, eval runner
keystone-portfolio	공개 가능한 설명, 결과, 다이어그램, 가이드

운영 원칙

• 작업은 목표와 종료 조건을 먼저 정한다.
• 자동화는 낮은 위험과 명확한 범위에서만 확장한다.
• 사람 승인은 매번 묻는 것이 아니라 위험과 범위 기준으로 요청한다.
• 검증 결과는 말이 아니라 증거로 남긴다.
• 회고는 사과문이 아니라 다음 자동화 후보를 만드는 작업이다.

관련 메뉴

다음 메뉴	연결 이유
AX Solution Orchestration	계획을 실제 에이전트 작업 단위로 바꾼다
Evidence Dashboard	검증 결과를 공개 가능한 증거로 요약한다
Retrospective Loop	실패와 지연을 다음 규칙 후보로 보낸다
Capabilities	실제 호출 가능한 작업 표면을 확인한다