diff --git a/AGENTS.md b/AGENTS.md
index 3550bbb1..6f93a488 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,8 +1,8 @@
# AGENTS.md
-이 저장소에서 AI 보조 개발을 수행할 때 따르는 규칙입니다.
+이 저장소에서 AI 보조 개발을 수행할 때 따르는 실행 규칙입니다.
-상세 작업 흐름: [`ai/ai-assisted-development-workflow.md`](ai/ai-assisted-development-workflow.md)
+AI가 따라야 할 규칙은 이 파일을 기준으로 합니다. `ai/ai-assisted-development-workflow.md`는 AI 활용 흐름을 기록하고 개선하기 위한 워크플로우 정리본이고, `ai/ai-usage-guide.html`은 사람이 AI 활용 흐름을 이해하기 위한 설명 문서입니다. 문서 간 내용이 충돌하면 이 `AGENTS.md`를 우선합니다.
## 구현 전 계획
@@ -15,6 +15,13 @@
- 예상 리스크와 의도적으로 제외할 범위
- 사용자가 즉시 구현을 명시적으로 요청하지 않았다면 승인 후 파일을 수정한다.
+## Superpowers 사용
+
+- 기능 추가, 리팩터링, 버그 수정, 운영 구조 변경처럼 판단이 필요한 작업은 관련 Superpowers skill을 먼저 확인하고 적용한다.
+- 사용자가 Superpowers 또는 특정 skill 사용을 명시하면 해당 skill 지침을 따른다.
+- 단순 조회, 상태 확인, 사용자가 명시한 일회성 명령 실행에는 불필요하게 긴 Superpowers 절차를 적용하지 않는다.
+- Superpowers 지침과 이 저장소 규칙이 충돌하면 사용자 지시와 이 `AGENTS.md`를 우선한다.
+
## 문서 작성 언어
- 저장소에 추가하는 문서, 설계안, 구현 계획, 리뷰 요약은 한국어로 작성한다.
@@ -32,6 +39,37 @@
- 커밋이 필요해 보이면 먼저 변경 범위와 추천 커밋 메시지를 제안한다.
- 사용자가 직접 커밋하거나 push하겠다고 말한 경우에는 명령을 실행하지 않고 필요한 확인 정보만 제공한다.
+## Branch naming
+
+- 브랜치를 만들 때는 사용자가 지정한 브랜치명을 우선한다.
+- 별도 지정이 없으면 기존 저장소의 브랜치 네이밍 관례를 확인하고 따른다.
+- 이 저장소에서는 기본적으로 `feat/`, `fix/`, `refactor/`, `docs/`, `test/` 같은 작업 유형 prefix를 사용한다.
+- `codex/` prefix는 사용자가 명시적으로 요청한 경우에만 사용한다.
+
+## GitHub Issue 작성
+
+- 구조 변경, 운영 리스크, API/DB 계약 영향, 여러 파일이나 서비스에 걸친 변경, 성능 주장처럼 사전 합의가 필요한 작업은 먼저 이슈를 작성하거나 기존 이슈를 확인한다.
+- 오타 수정, 작은 테스트 보강, 영향 범위가 명확한 단일 파일 수정은 사용자가 요청하지 않는 한 이슈 없이 진행할 수 있다.
+- 이슈를 작성할 때는 `.github/ISSUE_TEMPLATE`의 해당 템플릿 구조를 따른다.
+- 이슈 제목은 기존 이슈의 접두사 형식(`Feat:`, `Fix:`, `Refactor:` 등)을 확인해 일치시킨다.
+- 라벨은 템플릿 파일의 문자열만 보고 새로 만들거나 지정하지 않는다. GitHub에 이미 존재하는 저장소 라벨 체계를 확인하고 기존 라벨을 사용한다.
+- 이슈 assignee는 별도 지시가 없으면 이슈 작성을 요청한 사람으로 지정한다.
+- 요청한 사람의 GitHub 계정을 확정할 수 없으면 assignee를 임의로 지정하지 말고 먼저 확인한다.
+
+## GitHub PR 작성
+
+- PR을 작성할 때는 `.github/PULL_REQUEST_TEMPLATE.md` 구조를 따른다.
+- PR 제목은 기존 PR, 연결 이슈, 브랜치 맥락의 접두사 형식(`Feat:`, `Fix:`, `Refactor:` 등)을 확인해 일치시킨다.
+- `Issue Number`에는 연결된 이슈 번호를 명시한다. 연결 이슈가 없다면 사유를 PR 본문에 간단히 남긴다.
+- `작업 내용`에는 단순 파일 목록이 아니라 무엇을 왜 변경했는지와 주요 동작 변화를 작성한다.
+- `Reference`에는 관련 이슈, 설계 문서, 측정 결과, 외부 근거가 있을 때만 추가한다.
+- AI를 사용했다면 `AI 보조 작업 기록` 섹션을 삭제하지 않고 사용 범위, 채택/기각한 제안, 실행한 검증, 남은 리스크를 작성한다.
+- AI를 사용하지 않았다면 템플릿 안내대로 `AI 보조 작업 기록` 섹션을 삭제할 수 있다.
+- `Check List`는 실제로 확인한 항목만 체크한다. 실행하지 않은 테스트나 확인하지 않은 브랜치/라벨 항목을 체크하지 않는다.
+- PR 라벨은 새로 만들지 말고 GitHub에 이미 존재하는 저장소 라벨 체계를 확인하고 사용한다.
+- PR assignee는 별도 지시가 없으면 PR 작성을 요청한 사람으로 지정한다.
+- 요청한 사람의 GitHub 계정을 확정할 수 없으면 assignee를 임의로 지정하지 말고 먼저 확인한다.
+
## 구현과 리뷰 분리
- 구현 단계에서는 승인된 계획을 따르고 계획에서 벗어난 변경을 보고한다.
@@ -41,14 +79,17 @@
## Review guidelines
Codex GitHub Code Review가 PR 리뷰에서 따라야 할 기준이다.
+아래 항목은 우선 확인해야 할 고위험 영역이며, 리뷰 범위를 이 목록으로 제한하지 않는다.
+전체 diff를 기준으로 기능 오류, 요구사항 불일치, 보안/권한 문제, 데이터 정합성, 운영 안정성, 누락된 테스트를 폭넓게 확인한다.
- 리뷰 코멘트는 한국어로 작성한다.
- 각 코멘트는 심각도, 문제 상황, 위험, 수정 방향을 짧게 포함한다.
+- 목록에 없는 명백한 버그, 회귀, 운영 리스크가 보이면 반드시 지적한다.
- 트랜잭션 경계와 부분 실패 가능성을 확인한다.
- 비동기 작업의 유실, 중복 처리, 재시도 경로를 확인한다.
- API와 데이터베이스 호환성 회귀를 확인한다.
- 누락된 테스트와 근거가 부족한 성능 주장을 확인한다.
-- AI 워크플로우 문서를 리뷰할 때는 과장된 성과 표현, 비밀 정보 노출 위험, 실제 구현 전 주장된 자동화 여부를 확인한다.
+- AI 활용 설명 문서를 리뷰할 때는 과장된 성과 표현, 비밀 정보 노출 위험, 실제 구현 전 주장된 자동화 여부를 확인한다.
- 사소한 서식보다 기능 오류와 운영 리스크를 우선한다.
## 판단 기록
diff --git a/ai/README.md b/ai/README.md
index 16bb51eb..903f85d8 100644
--- a/ai/README.md
+++ b/ai/README.md
@@ -4,7 +4,8 @@
| 문서 | 역할 |
| --- | --- |
-| [`ai-assisted-development-workflow.md`](ai-assisted-development-workflow.md) | 전체 작업 흐름과 단계별 산출물 |
+| [`ai-assisted-development-workflow.md`](ai-assisted-development-workflow.md) | AI 활용 흐름을 기록하고 개선하는 워크플로우 정리본 |
+| [`ai-usage-guide.html`](ai-usage-guide.html) | AI 활용 흐름과 판단 기준을 설명하는 사람용 HTML 문서 |
| [`logging-hook-reproducibility-plan.md`](logging-hook-reproducibility-plan.md) | Logging Hook과 검증 재현성 구축 계획 |
-저장소 루트의 `AGENTS.md`는 AI가 따라야 할 실행 규칙이다. 이 폴더의 문서는 사람이 작업 방식과 판단 근거를 이해할 수 있도록 설명한다.
+저장소 루트의 `AGENTS.md`는 AI가 따라야 할 실행 규칙이다. `ai-assisted-development-workflow.md`는 AI 활용 흐름을 기록하고 개선하는 정리본이고, HTML 문서는 사람이 작업 방식과 판단 근거를 이해하기 위한 설명 문서이다.
diff --git a/ai/ai-assisted-development-workflow.md b/ai/ai-assisted-development-workflow.md
index 44b42825..59dde946 100644
--- a/ai/ai-assisted-development-workflow.md
+++ b/ai/ai-assisted-development-workflow.md
@@ -1,136 +1,56 @@
-# AI 보조 개발 워크플로우
+# AI 활용 워크플로우 정리
-## 1. 목적
+이 문서는 Docsa에서 AI를 어떤 흐름으로 활용할지 기록하고, 실제 작업을 거치며 개선해 나가기 위한 워크플로우 정리본이다.
-AI가 코드를 빠르게 생성하는 것보다 변경 범위와 리스크를 사람이 이해하고 검증할 수 있도록 관리하는 것을 목표로 한다.
+실행 규칙의 기준은 저장소 루트의 [`AGENTS.md`](../AGENTS.md)이다. 이 문서는 `AGENTS.md`를 대체하지 않으며, 작업 방식과 판단 기준을 더 구체적으로 정리하고 개선 이력을 남기기 위한 문서다.
-이 워크플로우는 다음 질문에 답할 수 있어야 한다.
+사람이 보기 좋게 정리한 설명 문서는 [`ai-usage-guide.html`](ai-usage-guide.html)이다.
-- AI는 어떤 범위에서 사용됐는가
-- 구현 전에 어떤 영향과 리스크를 검토했는가
-- 어떤 제안을 사람이 채택하거나 기각했는가
-- 구현 결과는 별도 리뷰와 테스트를 거쳤는가
-- 다른 사람이 변경 이유와 검증 방법을 다시 확인할 수 있는가
+## 1. 운영 목적
-## 2. 핵심 원칙
+AI를 단순 코드 생성 도구로 쓰지 않고, 문제 분석, 대안 검토, 구현 보조, 검증 누락 확인, PR 리뷰 보조에 활용한다.
-1. AI는 구현 전에 기존 구조와 영향 범위를 분석한다.
-2. 사람은 계획을 검토하고 승인한다.
-3. AI는 승인된 범위 안에서만 구현한다.
-4. 구현과 리뷰는 다른 작업으로 분리한다.
-5. 사람은 리뷰 의견의 채택 여부를 최종 판단한다.
-6. 테스트 결과와 남은 리스크를 PR에 기록한다.
-7. 원본 로그보다 설명 가능한 판단과 검증 결과를 우선한다.
+이 워크플로우의 목적은 다음과 같다.
-## 3. 역할 구분
+- 구현 전에 문제와 변경 범위를 명확히 한다.
+- AI 제안을 그대로 수용하지 않고 사람이 채택하거나 기각한다.
+- 테스트와 리뷰를 통해 AI가 만든 변경을 검증한다.
+- PR에 AI 사용 범위, 판단 근거, 검증 결과, 남은 리스크를 남긴다.
+- 실제 작업 사례를 바탕으로 이 문서를 계속 갱신한다.
-| 역할 | 책임 | 하지 않는 일 |
-| --- | --- | --- |
-| 사람 | 문제 정의, 계획 승인, 제안 채택과 기각, 최종 검증 | AI 결과를 검토 없이 수용하지 않는다 |
-| 구현 AI | 구조 분석, 계획 제안, 승인 범위 구현, 테스트 실행 | 승인 전 파일을 수정하지 않는다 |
-| 리뷰 AI | diff 기반 오류, 회귀, 누락 테스트, 운영 리스크 검토 | 리뷰 중 코드를 직접 수정하지 않는다 |
-| Logging Hook | 도구 실행과 검증 흐름 기록 | 코드 정확성이나 동일 결과 생성을 보장하지 않는다 |
+## 2. 문서 역할
-구현 AI와 리뷰 AI는 같은 모델을 사용해도 된다. 다만 리뷰 AI는 구현 대화의 맥락보다 PR diff와 리뷰 기준을 중심으로 검토해야 한다.
+| 문서 | 역할 |
+| --- | --- |
+| `AGENTS.md` | AI가 따라야 하는 저장소 실행 규칙 |
+| `ai/ai-assisted-development-workflow.md` | AI 활용 흐름을 기록하고 개선하는 워크플로우 정리본 |
+| `ai/ai-usage-guide.html` | 사람이 보기 좋게 정리한 AI 활용 설명 문서 |
+| `.github/ISSUE_TEMPLATE/*` | GitHub Issue 작성 형식 |
+| `.github/PULL_REQUEST_TEMPLATE.md` | PR에 남길 판단과 검증 기록 형식 |
-## 4. 현재 적용 상태
+규칙과 설명이 충돌하면 `AGENTS.md`를 우선한다.
-| 항목 | 상태 | 근거 |
-| --- | --- | --- |
-| 전역 AI 작업 원칙 | 적용 중 | `~/.codex/AGENTS.md` |
-| 저장소별 작업 규칙 | 적용 중 | `AGENTS.md` |
-| AI 사용 판단 기록 | 적용 시작 | `.github/PULL_REQUEST_TEMPLATE.md` |
-| 구현과 GitHub PR 리뷰 분리 | 적용 시작 | Codex GitHub Code Review |
-| 도구 실행 Logging Hook | 계획 | [`logging-hook-reproducibility-plan.md`](logging-hook-reproducibility-plan.md) |
-| 검증 재현성 효과 측정 | 계획 | Hook과 PR 기록 누적 후 확인 |
+## 3. 기본 흐름
-## 5. 1회 설정
+### 3.1 문제 정의
-### 5.1 전역 규칙
+작업을 시작할 때 먼저 해결하려는 문제를 분명히 한다.
-전역 `~/.codex/AGENTS.md`에는 모든 프로젝트에 공통으로 적용할 개인 원칙을 둔다.
+특히 다음 작업은 이슈를 먼저 작성하거나 기존 이슈를 확인한다.
-- 구현 전 가정과 트레이드오프 확인
-- 최소 범위 변경
-- 관련 없는 코드 수정 금지
-- 검증 가능한 성공 조건 정의
+- 운영 구조, 배포, 모니터링, 인프라 변경
+- API 계약, 데이터베이스 스키마, 트랜잭션 경계에 영향을 줄 수 있는 변경
+- 여러 파일, 모듈, 서비스에 걸친 변경
+- 성능 개선처럼 측정과 검증 기준 합의가 필요한 변경
+- 원인 분석이나 대안 선택이 필요한 리팩터링
-### 5.2 저장소 규칙
+오타 수정, 작은 테스트 보강, 영향 범위가 명확한 단일 파일 수정, 읽기 전용 조사는 이슈 없이 진행할 수 있다.
-루트 `AGENTS.md`에는 Docsa에서 지킬 구체적인 규칙을 둔다.
+### 3.2 구조 분석
-- 구현 전 변경 파일과 영향 범위 제시
-- 승인 전 파일 수정 금지
-- API와 데이터베이스 호환성 검토
-- 구현과 리뷰 역할 분리
-- PR에 AI 사용 범위와 판단 기록
+AI에게 바로 구현을 맡기기 전에 기존 구조를 먼저 확인하게 한다.
-리뷰 기준은 Codex GitHub Code Review가 명확히 인식할 수 있도록 `## Review guidelines` 섹션에 둔다.
-
-- 리뷰 코멘트는 한국어로 작성한다.
-- 사소한 서식보다 기능 오류, 데이터 정합성, 운영 리스크, 누락 테스트를 우선한다.
-- AI 워크플로우 문서는 실제 구현 전 주장된 자동화나 과장된 효과 표현을 확인한다.
-
-### 5.3 PR 기록 구조
-
-PR 템플릿에는 다음 내용을 기록한다.
-
-```markdown
-## AI 보조 작업 기록
-
-- 사용 범위:
-- 채택한 제안과 이유:
-- 기각한 제안과 이유:
-- 실행한 검증:
-- 남은 리스크:
-```
-
-### 5.4 Codex GitHub Code Review
-
-GitHub PR에서 구현과 리뷰를 분리하기 위해 Codex Code Review를 사용한다.
-
-1. Codex Cloud에 GitHub 저장소를 연결한다.
-2. Codex Code Review 설정에서 저장소의 Code review를 활성화한다.
-3. 처음에는 Automatic reviews를 끄고 수동 리뷰로 동작을 확인한다.
-4. PR 댓글에 `@codex review`를 작성해 리뷰를 요청한다.
-5. 운영 방식이 안정되면 Automatic reviews 적용을 검토한다.
-
-참고:
-
-- [Codex code review in GitHub](https://developers.openai.com/codex/integrations/github)
-- [Codex Code Review 설정](https://chatgpt.com/codex/settings/code-review)
-
-## 6. 작업별 실행 흐름
-
-### 6.1 작업 정의
-
-Issue 또는 작업 문서에 문제와 성공 조건을 먼저 작성한다.
-
-```markdown
-## 문제
-
-어떤 기능에서 어떤 비용이나 실패 가능성이 발생하는가
-
-## 성공 조건
-
-- 변경 후 지켜야 할 동작
-- 반드시 통과해야 할 테스트
-- 유지해야 할 API 또는 데이터 계약
-
-## 제외 범위
-
-- 이번 작업에서 변경하지 않을 영역
-```
-
-이 단계의 목적은 AI가 해결해야 할 문제와 해결하지 않아야 할 문제를 구분하는 것이다.
-
-### 6.2 구조 분석 요청
-
-구현 AI에게 파일 수정 없이 분석과 계획만 요청한다.
-
-```text
-아직 구현하지 마.
-기존 구조를 분석하고 다음 내용을 먼저 정리해줘.
+분석에는 다음 내용을 포함한다.
- 문제 원인
- 변경이 필요한 파일과 책임
@@ -138,150 +58,116 @@ Issue 또는 작업 문서에 문제와 성공 조건을 먼저 작성한다.
- 필요한 테스트
- 예상 리스크
- 이번 작업에서 제외할 범위
-```
-산출물:
+이 단계의 목적은 구현 전에 변경 범위를 줄이고, 불필요한 리팩터링이나 추측성 변경을 막는 것이다.
-- 변경 계획
-- 영향 범위
-- 테스트 계획
-- 리스크 목록
+### 3.3 계획 검토와 승인
-### 6.3 사람의 계획 검토와 승인
+AI가 제안한 계획은 사람이 검토한다.
-사람은 AI 계획을 다음 기준으로 검토한다.
+검토 기준은 다음과 같다.
- 문제 원인이 정확한가
- 변경 범위가 과도하지 않은가
-- 기존 설계 원칙과 충돌하지 않는가
- 더 단순한 대안이 있는가
- 트랜잭션 경계와 실패 경로를 고려했는가
- 검증 방법이 충분한가
+- 이번 작업에서 제외할 범위가 명확한가
-계획을 그대로 승인할 필요는 없다. 수정하거나 기각한 내용과 이유가 중요한 판단 근거가 된다.
+계획을 그대로 승인할 필요는 없다. 사람이 수정하거나 기각한 내용과 이유가 중요한 판단 기록이 된다.
-승인 예시:
+### 3.4 구현
-```text
-조회 API 응답 계약은 유지하고 Graph 조회는 제외해.
-Domain Event Outbox와 Read Model 변경만 이 계획으로 구현해줘.
-계획 밖의 변경이 필요하면 수정 전에 설명해줘.
-```
-
-### 6.4 구현
-
-구현 AI는 승인된 계획 안에서만 파일을 수정한다.
+AI는 승인된 범위 안에서만 구현한다.
-- 계획에서 벗어나는 변경이 필요하면 먼저 이유와 영향을 설명한다.
-- 관련 없는 리팩터링과 서식 변경은 하지 않는다.
-- 기존 사용자 변경을 되돌리지 않는다.
-- 테스트가 필요한 변경은 검증 코드와 함께 구현한다.
+구현 중 계획 밖 변경이 필요하면 먼저 이유와 영향을 설명해야 한다. 관련 없는 리팩터링, 서식 변경, 기존 사용자 변경 되돌리기는 하지 않는다.
-산출물:
+브랜치를 새로 만들 때는 사용자가 지정한 브랜치명을 우선한다. 별도 지정이 없으면 기존 저장소 관례에 맞춰 `feat/`, `fix/`, `refactor/`, `docs/`, `test/` 같은 작업 유형 prefix를 사용한다. `codex/` prefix는 사용자가 명시적으로 요청한 경우에만 사용한다.
-- 코드 변경
-- 테스트 코드
-- 계획과 달라진 내용의 설명
+### 3.5 검증
-### 6.5 로컬 검증
+구현 후에는 변경 위험에 맞는 검증을 실행한다.
-구현 후에는 변경 위험에 맞는 검증을 수행한다.
+검증 예시는 다음과 같다.
-- 컴파일
+- 컴파일 또는 빌드
- 단위 테스트
- 통합 테스트
- API 계약 확인
- 데이터 마이그레이션 영향 확인
-- 성능 주장이 있다면 측정 결과 확인
+- 성능 주장에 대한 측정
-테스트를 실행하지 못했다면 이유와 남은 리스크를 명시한다.
+테스트를 실행하지 못했다면 이유와 남은 리스크를 기록한다.
-### 6.6 PR 작성
-
-브랜치를 push하고 PR을 만든다. PR에는 AI 사용 자체보다 사람의 판단과 검증 결과를 기록한다.
-
-```markdown
-## AI 보조 작업 기록
+### 3.6 PR 기록
-- 사용 범위: 기존 구조 분석, 구현 계획, 테스트 누락 검토
-- 채택한 제안과 이유: 변경 이벤트를 Outbox에 저장해 후속 작업을 재시도할 수 있도록 함
-- 기각한 제안과 이유: 요청 시점 이중 쓰기는 부분 실패 복구가 어려워 제외
-- 실행한 검증: 통합 테스트, 중복 이벤트 테스트
-- 남은 리스크: 최종적 일관성으로 인한 조회 반영 지연
-```
+PR은 변경 결과만 설명하는 문서가 아니라, 변경 이유와 검증 근거를 리뷰어가 다시 확인할 수 있게 남기는 기록이다.
-### 6.7 독립 리뷰
+PR을 작성할 때는 `.github/PULL_REQUEST_TEMPLATE.md`의 구조를 따른다.
-GitHub PR 댓글에 다음과 같이 리뷰를 요청한다.
+- `Issue Number`: 연결된 이슈 번호를 적는다. 연결 이슈가 없다면 왜 이슈 없이 진행했는지 본문에 짧게 남긴다.
+- `작업 내용`: 무엇을 왜 변경했는지, 주요 동작 변화가 무엇인지 작성한다.
+- `Reference`: 관련 이슈, 설계 문서, 측정 결과, 외부 근거가 있을 때만 추가한다.
+- `AI 보조 작업 기록`: AI를 사용했다면 사용 범위와 사람의 판단을 남긴다.
+- `Check List`: 실제로 확인한 항목만 체크한다.
-```text
-@codex review
-```
+AI 보조 작업 기록에는 AI 사용 자체보다 사람이 판단한 내용과 검증 결과를 남긴다.
-특정 관점이 필요하면 리뷰 범위를 명시한다.
+```markdown
+## AI 보조 작업 기록
-```text
-@codex review for transaction boundaries, event duplication, and missing tests
+- 사용 범위:
+- 채택한 제안과 이유:
+- 기각한 제안과 이유:
+- 실행한 검증:
+- 남은 리스크:
```
-리뷰 AI는 PR diff와 저장소 `AGENTS.md`의 리뷰 기준을 바탕으로 문제를 찾는다. 리뷰 중에는 코드를 직접 수정하지 않는다.
-
-### 6.8 리뷰 의견 판단
-
-사람은 리뷰 의견을 무조건 반영하지 않는다.
-
-- 실제 오류인가
-- 기존 요구사항과 충돌하지 않는가
-- 복잡도를 불필요하게 높이지 않는가
-- 추가 테스트로 확인할 수 있는가
+원본 프롬프트, 도구 실행 로그, 비밀 정보, 인증 정보, 개인정보는 커밋하지 않는다.
+실행하지 않은 테스트, 확인하지 않은 브랜치 위치, 지정하지 않은 라벨은 체크하지 않는다.
-채택하거나 기각한 의견과 이유를 PR에 남긴다.
+## 4. Superpowers 활용
-### 6.9 수정과 최종 검증
+Superpowers는 모든 작업에 기계적으로 적용하지 않는다. 판단이 필요한 작업이거나 사용자가 명시한 경우에 활용한다.
-채택한 리뷰 의견만 별도 구현 작업으로 반영한다.
+주요 적용 기준은 다음과 같다.
-1. 리뷰 의견의 수정 범위를 정의한다.
-2. 구현 AI가 수정한다.
-3. 관련 테스트를 다시 실행한다.
-4. 필요하면 `@codex review`를 다시 요청한다.
-5. 사람이 최종 diff와 테스트 결과를 확인한 뒤 merge한다.
+- 새 기능 또는 구조 변경: `brainstorming`
+- 복잡한 구현 계획: `writing-plans`
+- 버그 수정: `systematic-debugging`
+- 테스트 중심 변경: `test-driven-development`
+- 완료 보고 전 검증: `verification-before-completion`
-## 7. 자동화와 사람의 판단 경계
+단순 조회, 상태 확인, 사용자가 명시한 일회성 명령 실행에는 긴 Superpowers 절차를 적용하지 않는다.
-| 단계 | 자동화 가능 여부 | 최종 책임 |
-| --- | --- | --- |
-| 기존 구조 분석 | 가능 | 사람 |
-| 변경 계획 작성 | 가능 | 사람 |
-| 계획 승인 | 자동화하지 않음 | 사람 |
-| 코드 구현 | 가능 | 사람 |
-| 테스트 실행 | 가능 | 사람 |
-| PR 리뷰 요청 | 자동화 가능 | 사람 |
-| 리뷰 의견 채택과 기각 | 자동화하지 않음 | 사람 |
-| merge 결정 | 자동화하지 않음 | 사람 |
+## 5. 리뷰 분리
-Human Approval Gate는 사람이 계획과 리뷰 결과를 실제로 판단할 때 의미가 있다. 단순히 승인 버튼을 누르는 절차로 만들지 않는다.
+구현과 리뷰는 분리한다.
-## 8. 단계별 확장 계획
+구현 AI는 승인된 계획을 수행하고, 리뷰 AI는 PR diff와 `AGENTS.md`의 `Review guidelines`를 기준으로 문제를 찾는다.
-### 1단계: 수동 워크플로우 검증
+리뷰 기준은 특정 항목에 갇힌 체크리스트가 아니다. 트랜잭션, 비동기, API/DB 호환성, 누락 테스트를 우선 확인하되, 목록에 없는 기능 오류, 요구사항 불일치, 보안/권한 문제, 데이터 정합성 문제, 운영 리스크도 지적해야 한다.
-- 최소 3건의 PR에서 계획 승인, 구현, PR 리뷰, 판단 기록 흐름을 반복한다.
-- 실제로 필요한 기록 항목과 불필요한 항목을 구분한다.
+리뷰 의견은 무조건 반영하지 않는다. 사람은 실제 오류 여부, 요구사항 충돌 여부, 복잡도 증가, 추가 테스트 가능성을 기준으로 채택하거나 기각한다.
-### 2단계: 리뷰 자동화 검토
+## 6. 개선 방식
-- 수동 `@codex review`가 안정적으로 동작하면 Automatic reviews 적용을 검토한다.
-- 자동 리뷰가 사소한 문제보다 운영 리스크를 우선하도록 `AGENTS.md` 리뷰 기준을 조정한다.
+이 문서는 고정된 규칙집이 아니라, AI 활용 흐름을 작업 사례를 통해 개선하기 위한 정리본이다.
-### 3단계: Logging Hook 구축
+개선할 때는 다음 기준을 사용한다.
-- Codex Hook으로 도구 실행과 검증 흐름을 작업 단위로 기록한다.
-- 원본 로그는 Git에 커밋하지 않고 사람이 검토한 요약만 PR에 연결한다.
-- 상세 계획은 [`logging-hook-reproducibility-plan.md`](logging-hook-reproducibility-plan.md)를 따른다.
+- 실제 PR에서 반복적으로 도움이 된 절차는 유지한다.
+- 형식만 늘리고 판단 품질을 높이지 못한 절차는 줄인다.
+- AI가 자주 놓치는 리스크는 `AGENTS.md`나 이 문서에 반영한다.
+- 이슈/PR 템플릿과 맞지 않는 기록 방식은 템플릿을 기준으로 조정한다.
+- 자동화는 사람이 판단해야 할 부분을 대체하지 않는 범위에서만 도입한다.
-### 4단계: 검증 재현성 확인
+## 7. 현재 개선 메모
-- 작업 시작 commit과 검증 명령을 연결한다.
-- 다른 사람이 같은 기준점에서 검증 명령을 다시 실행할 수 있는지 확인한다.
-- 로그를 이용해 변경 원인이나 검증 누락을 찾은 사례를 남긴다.
+- AI 실행 규칙은 `AGENTS.md`로 단일화한다.
+- 이 문서는 AI 활용 흐름을 기록하고 개선하는 정리본으로 유지한다.
+- 사람에게 보여줄 설명은 HTML 문서로 분리한다.
+- GitHub Issue 작성 시 템플릿 구조뿐 아니라 기존 제목 형식, 기존 라벨 체계, assignee 지정 방식을 확인한다.
+- GitHub PR 작성 시 템플릿 구조, 기존 제목 형식, 연결 이슈, 기존 라벨 체계, assignee 지정 방식, 실제 검증 여부를 확인한다.
+- 브랜치 생성 시 `codex/`를 기본값으로 쓰지 않고, 기존 저장소의 작업 유형 prefix를 우선한다.
+- Codex GitHub Code Review는 고위험 영역을 우선 확인하되, 리뷰 범위를 특정 항목으로 제한하지 않는다.
diff --git a/ai/ai-usage-guide.html b/ai/ai-usage-guide.html
new file mode 100644
index 00000000..8d762ab9
--- /dev/null
+++ b/ai/ai-usage-guide.html
@@ -0,0 +1,496 @@
+
+
+
+
+
+ Docsa AI 활용 흐름 설명서
+
+
+
+
+
+
Docsa AI 운영 문서
+
AI 활용 흐름 설명서
+
+ 이 문서는 Docsa 개발에서 AI를 어떤 순서로 활용하고, 어떤 판단을 기록하며,
+ 실제 작업을 통해 어떻게 개선해 나갈지 보여주는 사람용 설명서다.
+
+
+ 핵심 원칙
+ AI는 구현을 대신 결정하지 않는다. 문제 정의, 계획 승인, 검증, 리뷰 의견 채택은 사람이 판단하고 그 근거를 기록한다.
+
+
+
+
+
+
목적
+
+ AI를 빠른 코드 생성 도구로만 쓰지 않고, 변경 범위와 리스크를 사람이 검토할 수 있는 개발 보조 도구로 사용한다.
+
+
+
+ 확인할 질문
+
+
어떤 문제를 해결하려고 했는가
+
구현 전에 어떤 영향과 리스크를 검토했는가
+
AI 제안 중 무엇을 채택하거나 기각했는가
+
+
+
+ 남길 증거
+
+
실행한 테스트와 검증 결과
+
PR에 남은 리스크
+
리뷰 의견의 채택 또는 기각 이유
+
+
+
+
+
+
+
개발 흐름
+
+
+
1
+ 문제 정의
+ 해결할 문제, 성공 조건, 제외 범위를 먼저 정리한다.
+
+
+
2
+ 구조 분석
+ 기존 코드, 변경 파일, API/DB 영향, 테스트 범위를 확인한다.
+
+
+
3
+ 계획 승인
+ AI 제안을 검토하고 채택, 수정, 기각할 범위를 결정한다.
+
+
+
4
+ 구현
+ 승인된 범위 안에서만 변경하고 계획 밖 변경은 다시 설명한다.
+
+
+
5
+ 검증
+ 빌드, 테스트, 계약 영향, 성능 근거를 실제로 확인한다.
+
+
+
6
+ 기록과 개선
+ 채택/기각 이유, 검증 결과, 남은 리스크를 남기고 흐름을 개선한다.
+
+
+
+
+
+
단계별 AI 활용
+
+
+
분석 단계
+
+
AI에게 기존 구조를 읽게 하고 변경 후보 파일을 좁힌다.
+
API, 데이터베이스, 트랜잭션, 비동기 경계 영향을 먼저 확인한다.
+
불확실한 부분은 구현 전에 질문이나 대안으로 드러낸다.
+
+
+
+
구현 단계
+
+
사람이 승인한 범위 안에서만 AI에게 구현을 맡긴다.
+
계획 밖 변경이 필요하면 먼저 이유와 영향을 다시 설명한다.
+
관련 없는 리팩터링과 서식 변경은 작업 범위에서 제외한다.
+
+
+
+
+
+
+
검증과 기록
+
+
+
검증
+
+
테스트를 실행했다는 말보다 어떤 명령을 실행했고 어떤 결과였는지를 남긴다.
+
성능 개선이나 운영 안정성 주장은 측정 결과가 있을 때만 주장한다.
+
실행하지 못한 검증은 숨기지 않고 이유와 남은 리스크로 적는다.
+
+
+
+
기록
+
+
AI 사용 범위와 사람이 채택하거나 기각한 제안을 기록한다.
+
남은 리스크를 PR이나 작업 요약에 남겨 다음 리뷰에서 확인할 수 있게 한다.
+
원본 프롬프트, 도구 로그, 비밀 정보, 개인정보는 커밋하지 않는다.
+
+
+
+
+
+
+
리뷰와 개선
+
+ 리뷰는 AI가 만든 변경을 신뢰하기 위한 통과 의례가 아니라, 사람이 놓칠 수 있는 회귀와 운영 리스크를 다시 찾는 단계다.
+
+
+
+
리뷰
+
+
전체 diff 기준으로 기능 오류, 요구사항 불일치, 데이터 정합성을 확인한다.
+
트랜잭션, 비동기, API/DB 호환성, 누락 테스트를 우선 점검한다.
+
리뷰 의견은 실제 오류 여부와 복잡도 증가를 기준으로 채택하거나 기각한다.
+
+
+
+
개선
+
+
반복적으로 도움이 된 절차는 유지한다.
+
형식만 늘고 판단 품질을 높이지 못한 절차는 줄인다.
+
AI가 자주 놓치는 리스크는 실행 규칙과 워크플로우에 반영한다.
+
+
+
+
+
+
+
Superpowers 사용 방식
+
+ Superpowers는 모든 작업에 기계적으로 적용하지 않는다. 판단이 필요한 작업이거나 사용자가 명시한 경우에 사용한다.
+
+
+
+
+
작업 성격
+
주로 사용하는 skill
+
+
+
+
+
새 기능 또는 구조 변경
+
brainstorming
+
+
+
복잡한 구현 계획
+
writing-plans
+
+
+
버그 수정
+
systematic-debugging
+
+
+
테스트 중심 변경
+
test-driven-development
+
+
+
완료 보고 전 검증
+
verification-before-completion
+
+
+
+
+ Superpowers는 AGENTS.md의 저장소 규칙을 대체하지 않는다. 승인 전 파일 수정 금지, 변경 범위 제한, 한국어 문서 작성, Git 작업 제한은 그대로 유지한다.
+