AX Solution Orchestration

한눈에 보기

AX Solution Orchestration은 요구사항을 문서, 작업 단위, agent 책임, 검증 계획으로 나누는 설계 트랙입니다. 좋은 오케스트레이션은 agent를 많이 부르는 것이 아니라, 누가 무엇을 끝내야 하는지와 어떤 증거로 닫을지를 먼저 정하는 것입니다.

• 핵심 질문: 요구사항을 어떻게 agent가 실행 가능한 작업 단위로 바꿀 것인가?
• 읽는 대상: PRD, IA, spec, agent workplan을 하나의 실행 흐름으로 묶고 싶은 사람
• 연결 문서: Agent Orchestration, Agent Team Playbook, Evidence Dashboard

이 문서에서 확인할 것

• Intent, Plan Pack, Task Graph, Agent Workplan의 관계
• 작업 규모별 agent 라우팅 기준
• 공개 문서로 남길 수 있는 orchestration 증거

무엇을 오케스트레이션하는가

AX Solution Orchestration은 요구사항을 사람용 문서와 에이전트용 작업 단위로 나누는 트랙입니다. 좋은 오케스트레이션은 에이전트를 많이 부르는 것이 아니라, 책임과 종료 조건을 명확히 나누는 것입니다.

flowchart TD
  U["사용자 요청"] --> I["Intent<br/>목표와 비목표"]
  I --> P["Plan Pack<br/>PRD / IA / spec"]
  P --> T["Task Graph<br/>작업 단위와 의존성"]
  T --> A["Agent Workplan<br/>planner / builder / QA / reviewer"]
  A --> E["Evidence Plan<br/>검증과 수집 지점"]

Plan Pack 구성

산출물	역할
Intent	요청의 목적, 범위, 제외 항목을 고정
PRD	사용자 가치와 기능 범위를 설명
IA	화면, 정보 구조, 탐색 흐름을 정리
Functional Spec	상태, 입력, 출력, 에러 케이스를 정의
Agent Workplan	에이전트별 책임과 검증 기준을 배분

에이전트 라우팅

flowchart LR
  A["작은 수정<br/>1~3 files"] --> B["Builder direct"]
  C["중간 작업<br/>4~15 files"] --> D["Planner -> Builder -> QA"]
  E["큰 작업<br/>16+ files"] --> F["Orchestrator -> Parallel agents"]
  G["반복 오류"] --> H["Investigator"]
  I["보안/DB/배포"] --> J["Security / Release gate"]

연결되는 원천

원천	쓰임
ai-rules agents	planner, builder, reviewer, security 같은 역할 정의
ai-rules profiles	프로젝트별 포함 규칙과 에이전트 조합
keystone-hub skills	실제 호출 가능한 작업 스킬
keystone-hub hooks	완료 선언, 증거 누락, 위험 명령을 검증

공개 문서화 기준

공개 페이지에는 내부 PRD 원문이나 고객 정보를 옮기지 않습니다. 대신 어떤 판단 구조로 요청을 작업 단위로 바꾸었는지, 어떤 검증 지점을 붙였는지, 결과가 어떤 증거로 닫혔는지를 보여줍니다.

체크리스트

• 요청을 “목표 / 비목표 / 공개 경계”로 다시 썼는가?
• 작업 단위마다 담당 역할과 종료 조건이 있는가?
• 검증 방법이 구현 전부터 정해졌는가?
• 같은 작업을 다음 프로젝트에서도 재사용할 수 있는가?
• 내부 경로나 고객 맥락이 공개 문서에 남지 않았는가?