AX 운영 모델

AX ≠ AI Utilization

사람의 일을 AI가 대신 한다.
역할형 AI가 운영 구조 안에 배치되고,
게이트와 QA 루프가 품질을 잠근다.

사람은 방향과 기준을 정하고, AI는 역할별로 실행을 나누어 맡으며,
게이트는 단계 사이의 품질을 잠급니다.

01 · ROLE

역할로 배치된 AI

도구가 아니라 역할이다. 오케스트레이터 · 기획 · 디자인 · 개발 · QA · 분석. 각 에이전트는 자기 역할의 산출물에 책임진다.

02 · GATE

품질을 잠그는 게이트

실행 / 기획 / 디자인 / 반영 / QA — 5종 유저 게이트. PO 1인이 기준을 잠그고, 게이트 통과 없이는 다음 단계로 넘어가지 않는다.

03 · LOOP

반복으로 수렴하는 루프

DEV → QA 리포트 → 재라우팅. 1차에 완벽하지 않아도 된다. 루프가 빠르면 품질은 반복으로 수렴한다.

×

"AI한테 다 시키면 됨"

○

"AI가 역할별로 실행하되, 방향과 품질은 사람이 잡는 구조"

이 운영 모델은 새로 발명한 것이 아닙니다. 검증된 방법론 위에, AI를 역할로 배치하는 레이어를 얹은 것입니다.

M01·PRIMARY

Stage-Gate

엔터프라이즈의 승인 회의 대신, PO 1인 확인 + AI가 승인 재료를 자동 생성. 5종 게이트(실행/기획/디자인/반영/QA)가 촘촘한 잠금 역할.

원본: 단계별 게이트 (Gate 1–5)
우리식: 실행 · 기획 · 디자인 · 반영 · QA
변형 포인트: 회의체 승인 → PO 1인 게이트 + AI 자동 재료.

M02·PRIMARY

Double Diamond

발산은 요청 구조화와 사전 토론에서. 수렴은 게이트에서. 각 다이아몬드 안에서 AI가 옵션을 확장하고, 사람이 기준으로 좁힌다.

원본: Discover / Define / Develop / Deliver
우리식: 요청 + 토론 / 기획 게이트 / 디자인 3안 / QA→배포
변형 포인트: 워크숍 기반 → AI 토론 + PO 게이트.

M03 / M04 · SECONDARY — 보조 매핑

Dual Track Agile M03

두 도메인이 각자의 비중으로 dual-track을 운영한다. 서비스 개발 쪽은 Discovery 비중이, 제품 개발 쪽은 Delivery 비중이 크다. 두 도메인 모두 discovery/delivery 루프를 내장한다.

Lean UX · Build-Measure-Learn M04

가설 → Build(DEV) → Measure(대시보드) → Learn(QA 리포트) → 재설계. QA 5차 반복 사례처럼 루프를 빠르게 돌려 품질을 수렴시킨다.

차별점. "AI가 대신한다"가 아니라 역할형 AI + 게이트 + QA 루프 세트가 같이 돈다는 점.

01 · DECISION

의사결정 — PO

제품 전략, 우선순위, IA 변경, 범위 조정, 배포 승인 — 방향과 기준을 사람이 정한다. 짧은 지시에도 게이트·순서·금지사항이 함축되어 있으며, 중간 산출물을 확인한 뒤 다음 단계 진행 여부를 결정한다.

02 · ORCHESTRATION

오케스트레이션 — 오케스트레이터

PO의 요청을 구조화해 실행 가능한 단위로 변환한다. 질문인지 업무인지 판별하고, 단계를 분류하고, 기준 문서를 연결하며, 실행 계층으로 라우팅한 뒤 상태를 추적한다. 의사결정과 실행 사이의 유일한 브릿지이기 때문에, 이 계층이 얇아지면 전체 구조가 흔들린다.

03 · EXECUTION

실행 — 역할형 AI 에이전트

기획·디자인·개발·QA·분석·문서화·대시보드·배포 — 각 역할별 AI 에이전트가 실질적 업무를 수행한다. 한 에이전트가 모든 걸 하는 대신, 역할을 나누어 병렬로 처리한다.

실행 계층 역할 맵

역할	주요 담당
기획 에이전트	IA · DB · API 설계, 사양서화, 팀 조율
디자인 에이전트	화면 설계, 컴포넌트, 디자인 정합성
개발 에이전트	코드 구현, 브랜치 관리, 배포 연결
QA 에이전트	회귀 테스트, FAIL/PASS 리포트, 3분류 관리
분석 에이전트	데이터 쿼리, DiD/보정, 대시보드, 릴리즈 code-diff
문서 에이전트	사양서 · 회의록 · 릴리즈 리포트 저장

SKILL · PLANNING

/spec-draft

피그마 프레임과 짧은 요청 한 줄을 입력받아 사내 사양서 템플릿에 맞는 MD 초안을 작성하고, ADF로 변환해 Confluence에 자동 업로드한다.

INPUT 피그마 + 요청 → OUTPUT 사양서 MD + Confluence 페이지

SKILL · DOCUMENTATION

/meeting-notes

녹취록을 받아 K(결정)/O(의견)/A(액션)/D(디스커션)으로 구조화하고, Confluence에 정리된 회의록으로 저장한다.

INPUT 녹취록 → OUTPUT 구조화된 회의록

SKILL · QA

/qa-ticket

QA 이슈 설명과 스크린샷을 받아 Jira ADF로 변환하고, 이미지 첨부와 함께 티켓을 API로 등록한다.

INPUT 이슈 + 스크린샷 → OUTPUT Jira 티켓

SKILL · DEPLOYMENT

/deploy-dashboard

데이터 싱크, git push, Vercel 배포까지 한 번의 호출로 완결한다. 여러 단계를 수동 연결하던 작업을 하나의 스킬로 잠금.

INPUT 스킬 호출 → OUTPUT 대시보드 업데이트

프로세스 위 AX 매핑

프로세스 단계	AX 자동화 영역
기획	`/spec-draft` — 사양서 자동 작성 + Confluence 업로드
분석	AI 에이전트 — DiD · 날씨 보정 · DB 쿼리 · 보고서
문서화	`/meeting-notes` — K/O/A/D 구조화 + Confluence
QA	`/qa-ticket` — Jira ADF 변환 + 이미지 첨부 + API 등록
배포 QA	릴리즈 code-diff 리포트 (분석 에이전트)
대시보드	`/deploy-dashboard` — 데이터 싱크 + 배포
파이프라인	배치 스케줄러 — 매일 자동 수집/갱신

릴리즈 Code-Diff QA — 5단계

1pv-version.yaml 현재/이전 버전 조회 (git 히스토리 비교)
2변경된 서비스 감지 (버전 비교)
3각 서비스 커밋/diff 조회 (dev 브랜치)
4JIRA 티켓 4단계 스캔 (커밋 메시지 / MR source_branch / MR 타이틀·디스크립션 / MR 하위 커밋)
5리포트 작성 + obsidian/release/{date}/ 저장 + 채팅 알림

유저 게이트 5종

#	게이트	확인 내용
1	실행 게이트	업무인가 질문인가? 어떤 섹션·도메인으로 라우팅되는가?
2	기획 게이트	IA가 기존 구조를 깨지 않는가? v1/v2 경계가 명확한가? 빠진 기능은 없는가?
3	디자인 게이트	기획과 디자인이 정합적인가? 빠진 화면은 없는가?
4	반영 게이트	push / build / deploy — "push ≠ 배포". 각 단계 완료 상태 구분.
5	QA 게이트	수정됨 · 미수정 · 신규 3분류. 재작업 or 통과.

12단계 프로세스

P0요청 접수
P1요청 구조화 + 토론
P2PM 라우팅 + WBS 생성
P3기획 (IA / 플로우 / DB / API) ⛩ 기획 게이트
P4디자인 ⛩ 디자인 게이트
P5Dev 범위 정리
P6구현
P7DEV 반영 ⛩ 반영 게이트
P8QA ⛩ QA 게이트
P9재작업 루프 (수정됨 / 미수정 / 신규)
P10PRD 배포
P11배포 후 모니터링
P12회고 + 스킬화

PATTERN · 01 / HIGH-DENSITY COMMAND

짧은 요청 = 높은 밀도

"이건 기준이랑 어긋났어. 기존 구조 깨지 말고, 방금 올린 기준 문서에 맞춰 다시 정렬해줘."

기준 — 방금 올린 문서를 정답으로 본다
제약 — 기존 구조는 보존
순서 — 구현 전에 구조부터 맞춘다

PATTERN · 02 / DETAILED OPERATIONAL DESIGN

상세 요청 = 운영 설계

"기존 IA 구조는 깨지 말 것. v1/v2 경계 먼저 명확히 하고, 기획부터 맞춘 다음에 디자인으로 넘어가자. 중간에 한 번 확인해."

범위 — 기존 IA 구조 보존, v1/v2 경계 명시
금지 — 구조 재해석, 단계 건너뛰기
순서 — 기획 게이트 → 중간 확인 → 디자인

PATTERN · 03 / OPTIONS + RECOMMENDATION

선택지 + 추천

"안 3개로 정리해줘. 각 안의 장단점 간단히 비교하고, 네가 추천하는 안도 같이 알려줘. 결정은 내가 한다."

AI — 옵션 확장 · 정리 · 비교 · 추천안 제시
PO — 기준에 맞춰 최종 결정
흐름 — 정리 → 비교 → 추천 → 선택 → 다음 단계

PATTERN · 04 / DEFINITION OF DONE, SPLIT

완료 기준 분리

"push, deploy, QA pass는 각각 다른 상태야. 세 개를 섞어서 말하지 말고, 어느 단계까지 완료됐는지 분리해서 리포트해."

push — 코드가 원격 브랜치에 올라간 것
deploy — 실제 환경에 배포된 것
QA pass — 테스트를 통과한 것

CASE · IN-HOUSE · POLICY ANALYSIS

사내 정책 실험 효과 분석

요청: "이번 정책 실험 효과 분석해줘. DiD로 접근하고, 외부 변수(계절성·날씨 등) 보정이 필요한지 같이 검토해서 방법부터 합의하고 가자."
게이트: 분석 방법 게이트 — DiD / 보정 변수 / 대조군 선택을 PO와 먼저 합의
루프: 1차 분석 → 리뷰 → 외부 변수 편향 발견 → 보정 로직 추가 후 재실행
결과: 분석 보고서 + 대시보드 + Vercel 배포 → PO가 데이터 근거 위에서 정책 방향 결정

CASE · ASTERDUCK · FEATURE DESIGN

제품에 신규 기능 추가

요청: "기존 IA 깨지 않는 선에서 신규 기능 들어갈 자리 3안 정리해줘. 각 안의 장단점 비교하고, 토론 먼저 한 뒤 기획 → 디자인 순서로 간다."
게이트: 실행 → 기획 → 디자인 → 반영 → QA, 5개 게이트 전부 경유
루프: IA 3안 토론 → B안 선택 → "기존 IA 깨지 않게" 재지시 → 재기획
결과: IA 문서 + DB 설계 + API 설계 + 디자인 + 개발 + 배포

CASE · ASTERDUCK · QA LOOP

QA 반복 수렴

요청: "이번 릴리즈 QA 돌려줘. 수정됨·미수정·신규 3분류로 리포트하고, 일부만 고치지 말고 잔여 이슈 전부 닫는 방향으로 가자."
게이트: QA 게이트 — 수정됨 · 미수정 · 신규 3분류
루프: 1차 6건 발견 → 2차 1건만 수정 → 3~5차 재요청. 원칙: "일부만 고치지 말 것. 잔여 전부 닫기"
결과: 최종 3분류 리포트 → 잔여 이슈 전부 닫힘

CASE · IN-HOUSE · SPEC AUTOMATION

사양서 자동화

요청: 피그마 프레임 + "이 화면 사양서 작성해줘. 사내 템플릿 준수하고, Confluence에도 자동으로 올려줘."
게이트: 문서화 게이트 — 사내 사양서 템플릿 준수 확인
루프: 단일 호출로 완결 (작성 → ADF 변환 → Confluence 업로드)
결과: 사양서 MD + Confluence 페이지 → 반복 업무가 /spec-draft 스킬로 잠김

01

방향은 PO가 정한다

전략, 우선순위, 정책 방향은 사람이 결정한다. AI는 이 기준 없이 움직이지 않는다.

02

구조는 오케스트레이터가 잡는다

의도를 구조화해 실행 가능한 단계로 분해한다. 질문과 업무를 구분하고 라우팅한다.

03

순서를 지킨다

기획 → 디자인 → 개발 → QA. 단계를 건너뛰지 않는다.

04

반복은 자동화한다

2회 이상 반복되는 업무는 스킬로 만든다. 같은 일을 세 번 하지 않는다.

05

데이터로 결정한다

감이 아닌 데이터로 판단한다. 가설은 측정 가능하게 세운다.

06

완료를 분리한다

push ≠ deploy ≠ QA pass. 각 단계를 분리해서 확인한다.

계층	구성 요소	설명
에이전트 런타임	NanoClaw · OpenClaw	AI 에이전트 실행 환경 (맥미니 / 회사망)
배포	Vercel · Railway	대시보드(Vercel), 앱(Railway)
문서 · 이슈	Confluence · Obsidian · Jira	사양서 / 개인 지식 / 티켓 관리
데이터	MySQL · ChromaDB	서비스 DB / 벡터 DB
스케줄링	NanoClaw 스케줄러	배치 자동 실행 (매일 CSV 수집 등)
버전 관리	Git · GitHub	코드 버전 관리

KoalStudio가 AI를 운영하는 방식. 도구가 아니라 역할로 배치합니다.