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 작업 제한은 그대로 유지한다. +
+
+ +
+

앞으로 개선할 점

+
    +
  • 실제 작업 사례를 보며 분석, 계획, 구현, 검증 단계 중 도움이 된 절차를 유지한다.
  • +
  • 형식은 늘었지만 판단 품질을 높이지 못한 절차는 줄인다.
  • +
  • AI가 반복해서 놓치는 리스크는 다음 작업 흐름에 반영한다.
  • +
  • 자동화는 사람이 판단해야 할 부분을 대체하지 않는 범위에서만 도입한다.
  • +
+
+
+ + +
+ +