이것은 제가 기능 구현이나 버그 수정을 위해 AI 에이전트를 사용하기 _전_에 따르는 워크플로우입니다. 🧭

요구사항/사양 (Requirements/Specification)
↓
설계/아키텍처 (Design/Architecture)
↓
AI 코드 생성 (AI Code Generation)
↓
사람의 검토 (Human Review)
↓
빌드 및 정적 분석 (Build & Static Analysis)
↓
테스트 및 검증 (Testing & Validation)
↓
결함 해결 (Defect Resolution)
↓
보안 및 컴플라이언스 검토 (Security & Compliance Review)
↓
릴리스 (Release)
↓
운영 모니터링 (Production Monitoring)

vs

Claude Code
↓
기능 구현 (Implements feature)
↓
Codex QA 에이전트 (Codex QA Agent)
↓
애플리케이션 실행 (Runs application)
↓
해피 패스 테스트 (Tests happy path)
↓
엣지 케이스 테스트 (Tests edge cases)
↓
에러 핸들링 테스트 (Tests error handling)
↓
QA 보고서 생성 (Produces QA report)

이 방식은 자기 검토 편향 (self-review bias), 확증 편향 (confirmation bias), 또는 AI 간 편향 (AI-to-AI bias)을 해결할 것입니다.

1️⃣ 코드 작성 전 이해하기

코드를 건드리기 전에, 저는 제가 무엇을 만들고 있고 왜 만드는지를 이해하려고 노력합니다. 저는 보통 다음 파일들을 읽는 것으로 시작합니다:

• specs/<module>/<TICKET>-<slug>.md
• plan/<module>/<TICKET>-<slug>.md
• status.md

그 다음 프로젝트 컨벤션 (conventions)을 검토합니다:

• specs/CONVENTIONS.md
• specs/conventions/core-porting.md

마지막으로, 기존 구현체(entities, services, mappers 등)를 읽어서 저의 변경 사항이 새로운 스타일을 도입하는 대신 기존 아키텍처를 따르도록 합니다.

💡 프로 팁 (Pro-Tip)
좋은 코드는 코드베이스에 잘 어우러집니다. 위대한 코드는 마치 원래부터 그곳에 있었던 것처럼 보입니다.

2️⃣ 변경 사항 계획하기

요구사항을 이해하고 나면, 어떤 아키텍처 계층 (architectural layers)이 영향을 받는지 식별합니다. 저는 항상 의존성 순서 (dependency order)를 존중합니다:

Schema / Entities / DAOs
        ↓
Mappers / DTOs
...

bash
mvn -pl test

로컬에서는 보통 `-am`을 포함하는데, Liquibase가 비활성화되어 있고 스키마 변경 사항이 먼저 적용되어야 하기 때문입니다.

...

plaintext
사양 읽기 (Read the specification)
↓
컨벤션 읽기 (Read the conventions)
↓
기존 코드 이해 (Understand the existing code)
↓
구현 계획 (Plan the implementation)
↓
최소한의 변경 작성 (Write minimal changes)
↓
테스트 및 검증 (Test and verify)
↓
결과를 정직하게 보고 (Report results honestly)

이 프로세스를 따르면 기존 코드베이스와 자연스럽게 통합되고, 회귀 (regressions)를 최소화하며, 향후 유지보수를 훨씬 쉽게 만드는 코드를 작성하는 데 도움이 됩니다.

...