용어집

이 핸드북 전체에서 반복적으로 쓰이는 용어를 한곳에 모았다. 각 항목의 "자세히"는 그 용어를 처음 자세히 설명한 장으로 연결된다.

핵심 개념 팀 구성요소 워크스페이스 구조 도구·플랫폼

핵심 개념

하네스 엔지니어링 Harness Engineering
모델이 어떤 도구·규칙·검증 장치를 통해 일하게 할지 설계하는 일. 프롬프트 엔지니어링(무엇을 말할지) → 컨텍스트 엔지니어링(무엇을 알게 할지)에 이어지는 세 번째 단계. 자세히: 2장 §1
서브에이전트 Subagent
메인 세션과 독립된 컨텍스트 창을 가지고 좁은 작업을 처리한 뒤 요약만 돌려주는 보조 에이전트. 스페셜리스트 개념을 실제 도구에서 구현하는 메커니즘. 자세히: 2장 §3b
핸드오프 Handoff
에이전트 사이에 작업을 넘기는 행위 또는 그 지점. 핸드오프 계약(Handoff Contract)은 주고받는 정보의 형식을 구조화한 것으로, 목적·범위·이전 단계 산출물을 명시하면 다음 에이전트가 다시 물어볼 필요 없이 바로 시작할 수 있다. 자세히: 2장 §3
동적 팀 구성 Dynamic Team Composition
오케스트레이터가 매 요청마다 실제로 어떤 서브에이전트를 몇 번, 어떤 순서로 투입할지 새로 판단하는 것. 정의된 팀 명단은 고정이어도 실제 투입 구성은 작업마다 달라진다. 자세히: 2장 §4b · 실습: 4장 D-2
오케스트레이션 패턴 Orchestration Pattern
Anthropic이 정리한 다섯 가지가 대표적이다. 프롬프트 체이닝(단계별 순차 처리), 라우팅(요청을 분류해 적합한 에이전트/모델로 분배), 병렬화(팬아웃으로 독립 작업 동시 실행, 또는 투표로 같은 작업을 반복해 다수결), 오케스트레이터-워커(하위 작업을 미리 정하지 않고 동적으로 분해), 평가자-최적화(초안을 독립 검증한 뒤에만 반영, 검증-후-적용). 한 워크플로우 안에서 자유롭게 조합해 쓸 수 있다. 자세히: 2장 §4
컨텍스트 윈도우 / 컨텍스트 과부하 Context Window / Context Overload
AI 모델이 한 번에 처리할 수 있는 토큰(텍스트)의 한계를 컨텍스트 윈도우라 한다. 이 한계 안에 역할 정의·과거 대화·작업 지시·결과물을 모두 담아야 하는데, 내용이 많아지면 앞부분의 정보가 희미해지는 현상을 컨텍스트 과부하라고 한다. 멀티 에이전트팀은 이를 역할별로 분산해 해결하는 핵심 동기 중 하나다. 자세히: 1장 §멀티 에이전트: 전문가 팀의 원리
프론트매터 Frontmatter
에이전트 정의 파일(agents/*.md) 맨 위에 YAML 형식으로 작성하는 메타데이터 블록. 에이전트 이름·역할·허용 도구(tools)·모델 티어(tier) 등을 기계적으로 파싱할 수 있도록 정의한다. extends 필드로 다른 에이전트 파일을 상속받을 수도 있다. 자세히: 8장 §1 배포와 SSOT
스캐폴딩 Scaffolding
bun scripts/new-project.ts로 variant 템플릿의 전체 구성(에이전트·스킬·커맨드·거버넌스 파이프라인)을 독립 git 저장소로 복제하는 작업. "프로젝트를 처음부터 만드는 게 아니라, 미리 설계된 뼈대 위에서 시작한다"는 의미. 자세히: 6장 §2
가드레일 Guardrails
허가 모델·훅·감사 등 에이전트 행동 경계를 강제하는 안전장치. 자세히: 3장 §1
훅 Hook
에이전트가 특정 도구를 호출하기 전·후에 자동으로 실행되는 스크립트. 예: PostToolUse 훅으로 파일 수정 후 자동 감사(audit) 검사. Claude Code(CLI)에서는 .claude/hooks/에 정의된 훅이 발화하지만, Claude Desktop App에서는 동작하지 않으므로 도구별 동작 차이에 주의해야 한다. Codex는 훅 미지원 — CODEX.md 지침을 세션에서 스스로 실행하는 방식으로 대체한다. 자세히: 3장 §감사 로그와 관측성
칸반 / WIP 한계 Kanban / WIP Limit
동시에 진행 중인 작업(Work In Progress)의 수를 제한하는 병렬성 통제 방법. 팬아웃으로 에이전트를 여러 개 동시에 투입할 때, WIP 한계를 설정해 두면 동시 실행이 너무 많아져 발생하는 자원 경합이나 컨텍스트 누락을 방지할 수 있다. 자세히: 2장 §오케스트레이션 패턴
서비스 티켓 모델 Service Ticket Model
AI를 "요청을 받으면 처리해 주는 서비스"로만 사용하는 운영 방식. 기존 IT 조직의 티켓 시스템과 유사하다. 사용자가 일일이 요청 형태로 지시해야 하며, 에이전트 팀의 자율성이 제한된다. 이 핸드북이 제안하는 "개발 도구 + variant 모델"과 대비되는 접근법. 자세히: 7장 · 기업 내 운영 전략 비교
생애주기 / 상태 Lifecycle / State
생애주기는 에이전트·스킬·스크립트가 거치는 순차적 단계 전체(예: Create→Verify→Operate→Improve→Deprecate)를 말한다. 상태는 특정 시점에 그 구성요소가 생애주기의 어느 단계에 있는지를 나타내는 스냅샷이다. YAML frontmatter의 status 필드(draft, active, deprecated, retired)가 상태 값을 저장한다. 생애주기는 "지하철 노선도"이고 상태는 "현재 열차가 어느 역에 있는지"를 보여주는 표시판에 비유할 수 있다. 자세히: 8장 §2 · 상태와 생애주기의 구분
스킬 관계 그래프 Skill Relationship Graph
스킬·에이전트·ADR·의사결정 기록 사이의 관계를 기계가 읽을 수 있는 형태로 표현한 투영(projection). 원천(SKILL.md 프론트매터의 prerequisites/relates_to, 에이전트 required_skills, variant.json 등)에서 항상 다시 생성되며 그 자체는 1차 저장소가 아니다(ADR-0060). 결과물은 docs/skill-graph.json과 사람이 읽는 docs/skill-graph.md다. 모든 관계 엣지는 자문적(advisory)이며 실행을 강제로 막지 않는다. 자세히: 8장 §2 · 스킬 관계 그래프
도메인 운영 모델 Domain Operating Model
variant 템플릿이 자기 도메인의 업무 흐름(스테이지), 책임 체계(RACI), 판정 지점(결정 게이트)을 데이터로 스스로 선언하는 구조. 공식 명칭은 반드시 풀네임으로 쓰며 약어(DOM·AOM)는 다른 용어와의 충돌 때문에 금지된다. 4개 그룹(Process·Governance·Execution·Graph)으로 구성된다(ADR-0083). 자세히: 13장 · Domain Operating Model
도메인 실행 그래프 Domain Execution Graph
스킬 관계 그래프 위에 얹히는 어휘 프로파일(graph_profile: "deg/v1"). 스테이지·RACI·게이트의 데이터를 in_stage·accountable_for·gated_by 같은 엣지로 연결해, 흩어진 운영 지식을 하나의 그래프 조회로 답할 수 있게 만든다(ADR-0083). 자세히: 13장 §5 · Graph
스테이지 축 Stage Axis
도메인 업무가 흘러가는 단계의 선언(process/stages.yaml). PM 작업 실행 축인 phase(0–6)와는 다른 축으로, 절차 간 산출물 인계 흐름에서 도출된다. phase와 구별되지 못하면(DEG-P-01) 기계 부트스트랩이 아니라 사람의 작성이 필요하다. 자세히: 13장 §2 · Process
RACI 매트릭스 RACI Matrix
각 스테이지의 각 활동에 대해 Responsible(실행)·Accountable(최종 책임)·Consulted(자문)·Informed(통보)를 선언하는 책임 표. 사람이 읽는 문서가 아니라 generate-raci.ts가 절차 데이터에서 생성하고 validate-raci.ts가 검증하는 데이터다(governance/raci.yaml). 자세히: 13장 §3 · Governance
결정 게이트 Decision Gate
워크플로우 안에서 판정이 필요한 지점을 go/no-go 형식으로 선언한 것(decisions/gates.yaml). 실제 내려진 판정의 기록인 결정 기록(DEC-*.md, 참고 B)과 대응되며, 게이트의 판정은 record_kind: DEC로 기록에 남는다(ADR-0083). 자세히: 13장 §4 · Execution

멀티 에이전트팀 구성요소

오케스트레이터 Orchestrator
전체 작업을 단계로 나누고 스페셜리스트를 호출하며, 사용자 확인이 필요한 지점에서 멈추는 역할. 흔히 "PM 에이전트"라고 부른다.
스페셜리스트 Specialist
설계·구현·테스트·보안 검토처럼 좁고 명확한 책임을 가진 에이전트. 입력과 출력이 분명히 정의돼 있다.
모델 티어 Model Tier
에이전트 역할별로 배정하는 모델 비용 등급(high/medium/low). 판단이 무거운 역할에는 high, 정형화된 반복 작업에는 low를 배정해 비용과 품질의 균형을 맞춘다. agents/*.md frontmatter의 tier 필드로 지정하며, 실제 모델명은 model: inherit로 플랫폼이 번역한다. 자세히: 5장 §3. L0→L1→L2의 "3-tier"와는 다른 개념이니 혼동 주의

ai-workspace-standards 구조

SSOT Single Source of Truth
어떤 정보의 원본이 오직 한 곳에만 존재한다는 원칙. 예: CONSTITUTION.md는 워크스페이스 전체 규칙의 SSOT, context.md는 개별 프로젝트의 설정 문서. 자세히: 5장 §4
L0 / L1 / L2 / L3
워크스페이스 루트(L0, 유일한 원본) → 공통 템플릿 스냅샷(L1, templates/common/) → variant 템플릿(L2, templates/co-*/) → 라이브 프로젝트 작업 디렉토리(L3, Projects/*/, new-project.ts로 L2 variant에서 스캐폴딩됨 — 외부 클론이 아니라 동일한 워크스페이스 저장소 내부)로 이어지는 4단 계층. 흐름은 항상 위에서 아래로만 가고, L1→L2는 variant 생성 시점에 딱 한 번만 전달되는 "포크"며, L2→L3는 프로젝트 생성 시점의 일회성 스캐폴딩으로 만들어진다. 자세히: 8장 §1 배포와 SSOT
포크 모델 Fork Model
L1에서 L2가 갈라져 나온 뒤에는 자동 역동기화 없이 독립적으로 진화하는 방식. 공식 템플릿으로 승격하려면 l3-to-variant-pipeline.ts를 사람이 명시적으로 실행해야 한다.
variant
templates/ 아래에 있는, 특정 도메인을 위한 완결된 멀티 에이전트팀 구성(PM·전문 에이전트·거버넌스 파이프라인 묶음). co-develop, co-design, co-work 등이 예시다. 자세히: 5장 §3
Phase A / Phase B
신규 베리언트(variant)를 만드는 두 단계. Phase A는 Projects/ 아래 독립 프로토타입으로 자유롭게 실험하는 단계, Phase B는 promote-variant로 정식 templates/ 베리언트(variant)로 승격하는 단계. 자세히: 11장 · 신규 variant 생성
보일러플레이트 Boilerplate
매 프로젝트마다 처음부터 다시 작성해야 할 PM 역할 정의·거버넌스 파이프라인·커맨드/스킬 배선을 미리 갖춰 둔 출발점. ai-workspace-standards가 배포하는 것의 본질.
컨테이너 연계 Container Integration
ai-workspace-standards의 고도화 방향 중 하나. 스캐폴딩된 프로젝트가 Docker/Kubernetes 환경에서 Open WebUI 같은 서비스와 연계되어 개인 단위로 지원될 수 있어야 한다는 요구. 현재는 로컬 AI 코딩 도구와 직접 연동되는 방식만 지원된다. 자세히: 8장 §5 고도화 로드맵
메모리 취합 Memory Consolidation
ai-workspace-standards의 고도화 방향 중 하나. 개별 프로젝트 단위로 흩어져 있는 memory/YYYY-MM-DD.md 파일들을 워크스페이스 수준에서 취합·정리하여 전체 트렌드를 파악할 수 있는 기능. 자세히: 8장 §5 고도화 로드맵

도구·플랫폼

AGENTS.md
30개 이상의 AI 코딩 도구가 공통으로 읽는 개방형 표준 파일. 빌드·테스트 명령, 코드 스타일 등 도구 중립적 규칙을 정의한다. 이 저장소에서는 추가로 "에이전트 로스터" 역할도 겸한다. 자세히: 2장 §도구를 넘나드는 하네스, AGENTS.md
CODEX.md
Codex 계열(CLI·Desktop App)의 행동 지침 파일. 훅이 없는 Codex에서는 이 파일에 명시된 규칙을 PM이 매 세션 스스로 인지하고 실행하는 프롬프트 자체 강제의 근거가 된다.
역할 컨텍스트 Role Context
Codex의 서브에이전트 구현 방식. 별도 정의 파일 없이 PM이 AGENTS.md·CODEX.md의 역할 정의를 읽고 한 단계가 끝날 때마다 다음 역할로 순차 전환한다. 자세한 것은 4장 §1-C.
teammateMode
Agent Teams(실험적 기능)의 병렬 실행 모드. Claude Desktop App은 in-process만 지원하고, Claude Code(CLI)는 tmux 분할 창 모드도 추가로 지원한다. 자세히: 공통 참고 §1
Agent Manager
Antigravity(Desktop)에서 여러 워크스페이스를 한 화면에서 감독하는 상위 인터페이스. Workspace마다 에이전트 하나씩 배정하는 것이 원칙이다.
/goal / /agent / /agents
Antigravity CLI(agy)에서 동적 서브에이전트 오케스트레이션을 부르는 슬래시 커맨드. /goal은 목표를 끝까지 실행, /agent는 백그라운드 장기 작업 위임, /agents는 지금까지 생성된 서브에이전트 상태 목록 확인. 이 능력 자체는 agy만의 것이 아니다 — Claude Code/App은 같은 동적 오케스트레이션을 Agent(Task) 툴과 자연어 요청으로, Antigravity(Desktop)는 Agent Manager GUI로 수행한다. 이 세 명령은 그 동작을 CLI 화면에서 부르는 이름일 뿐이다. 자세히: 공통 참고 §2