자연어 한 줄로
개발 사이클 전체를.
GX 사업본부 개발자를 위한 자동화 플러그인입니다. PRD·설계·구현·리뷰·PR까지, 역할을 나눠 맡은 에이전트 팀이 단계마다 승인을 받으며 처리합니다.
사용법
명령어를 외울 필요 없습니다
명령어를 외울 필요는 없습니다. 자연어로 말하면 의도에 맞는 스킬이 알아서 발동되고, "TDD로" 같은 키워드가 있으면 tdd 파이프라인으로 갈립니다.
두 가지 개발 파이프라인
dev vs tdd — 어떤 걸 쓰나
둘은 같은 6단계 골격을 공유하지만 구현을 끌고 가는 방식이 정반대입니다. dev는 설계를 확정한 뒤 구현하고, tdd는 실패 테스트를 먼저 쓰고 그걸 통과시키며 구현합니다.
한 줄 기준 — "이 작업의 정답을 자동 테스트로 표현할 수 있고, 그래야 하는가?" 예면 tdd, 아니오·애매하면 dev.
정상 경로 (Normal) · dev·tdd 공통 6단계
스킬 상세
15개 스킬이 사이클을 나눠 맡습니다
스킬 하나는 한 가지 역할만 맡습니다. 단독으로 불러 써도 되고, dev/tdd 파이프라인 안에서 자동으로 엮여 돌아가기도 합니다.
context
기획서·요구사항 문서·코드베이스를 분석해 도메인 지식을 context/{도메인}/에 등록합니다. 한번 등록해두면 dev·tdd를 실행할 때 자동으로 참조됩니다.
- 스캔 — 패키지 구조·엔티티·API 분석으로 도메인 자동 생성
- 문서 기반 — PDF·이미지·텍스트에서 context 추출
- 동기화 — git log·PR 분석으로 status.md 진행도 갱신
dev
자연어 요청 한 줄이면 PRD 작성부터 PR 생성까지 전체 사이클이 돌아갑니다. 요청을 분석해 normal·hotfix·단일단계·재개 가운데 알맞은 모드를 스스로 고릅니다.
- 단계마다 사용자 승인 — 승인 없이 다음으로 넘어가지 않음
- 구현은 의존성 분석 후 coder 병렬 배치로 처리
- "이어서 해줘"로 중단 지점부터 정확히 재개
tdd
dev와 같은 6단계 골격을 쓰지만 구현을 테스트가 끌고 가는 별도 파이프라인입니다. 실패 테스트를 먼저 쓰고 통과시키며 구현하고 정리하며, 완료 전에는 verify 게이트를 반드시 통과해야 합니다. 결제·인증·계산처럼 정답을 테스트로 표현할 수 있는 작업에 씁니다.
- requirements — AC를 Given-When-Then으로 강제
- design — test-architect가 testability 점수(1–10) 산정, 7 미만이면 재설계
- implement — red-writer → green-coder → refactor-coder 격리 순차
- complete — verify 게이트(신선한 테스트 실행 증거) 통과 후 commit
실패하는 테스트를 먼저 짭니다. 의도한 실패를 눈으로 확인한 뒤에야 다음 단계로 넘어갑니다.
테스트를 통과시킬 최소한의 코드만 짭니다. YAGNI 원칙으로 과잉 구현을 막습니다.
GREEN을 유지하면서 중복을 제거하고 구조를 정리합니다. 매 단계 테스트로 검증합니다.
"should work" 같은 추측성 표현을 막습니다. 실제 테스트 실행 증거가 없으면 완료로 쳐주지 않습니다.
분석 · 글쓰기 스킬
코드를 읽고, 글을 다듬습니다
구현 파이프라인과 따로 단독으로 부르는 읽기 전용·문서 스킬입니다.
lens
코드에 묻혀 있는 비즈니스 정책을 찾아 PO·PD가 읽을 수 있는 보고서로 뽑아냅니다. 코드는 건드리지 않습니다. 변경 아이디어를 이어 말하면 복잡도와 리스크까지 분석해줍니다.
tech-debt
기술 부채를 코드·아키텍처·의존성·테스트 네 가지 유형으로 나눠 스캔하고, 심각도 × 수정 용이성 × 영향 범위를 따져 우선순위 로드맵과 A~F Health Score를 내놓습니다. 읽기 전용이라 코드는 손대지 않습니다.
research
웹 검색과 문서 분석을 함께 돌려 도메인 리서치를 수행합니다. 결과는 종합 리포트·비교표·핵심 요약 형태로 .research/에 저장되고, 모든 발견에 출처 URL이 붙어 context에 그대로 반영할 수 있습니다.
cross-review
dev·tdd를 끝낸 뒤 한 번만 부릅니다. PRD·설계서·Trust Ledger를 컨텍스트로 넣어 "약속한 대로 만들었는가"를 교차 검증하고, AC 충족·범위 이탈·신규 위험만 짚어 보고합니다. advisor는 codex 또는 claude 중에서 고릅니다.
commit · pull-request
브랜치명에서 타입을 파싱해 한국어 커밋 메시지를 만들고, 커밋 히스토리를 분석해 PR 제목·본문을 자동으로 써줍니다. Git 전용이라 SVN에서는 svn commit을 직접 실행하세요.
setup
플러그인을 설치한 뒤 한 번만 실행하면 됩니다. VCS(Git/SVN)를 자동으로 감지하고 gh CLI·인증·Google Chat 웹훅을 점검합니다.
humanizer
AI 글쓰기 패턴 40여 종(한국어 K1–K19 / 영어 E1–E19 / 공통 C1–C6)을 감지하고 교정합니다. "정밀/꼼꼼히/--strict"라고 명시하거나 입력이 8,000자를 넘으면 자동으로 strict로 올라갑니다.
- audit — 감지 리포트만 (수정 안 함)
- rewrite — 감지 + 교정 + 변경률 상한(30% 경고 / 50% 중단)
- strict — rewrite + 의미 보존 검증(humanizer-fidelity) + 과윤문 검토(humanizer-naturalness)
에이전트 팀
17개 에이전트, 하나의 관점씩
스킬은 내부적으로 직무별 에이전트 팀을 부릅니다. 에이전트 하나는 관점 하나만 맡고, 작업 성격에 따라 Opus나 Sonnet 모델이 배정됩니다.
제품 · 설계
4구현
4리뷰
4윤문 검증 · 분석 · 복구
5안전장치
자동화하되, 위험한 일은 사람에게.
자동화는 PR 생성까지입니다. 머지·강제 푸시·민감 파일은 설정 수준에서 막히거나 사람의 확인을 거칩니다.
gh pr merge는 설정 수준에서 차단됩니다.
git push --force 차단. 저장소 강제 푸시를 허용하지 않습니다.
.env · *.key · *.pem · credentials* · *secret* 커밋 전 경고.
build/ · node_modules/ tracked 시 .gitignore 보강 제안.
자주 묻는 질문
궁금할 만한 것들
dev와 tdd 중 뭘 써야 하나요?
context 없이도 dev/tdd를 실행할 수 있나요?
dev/tdd를 실행하면 바로 코드를 짜나요?
도중에 멈추면 처음부터 다시 해야 하나요?
.dev/state.md에 저장된 진행 상태를 읽어 멈춘 단계부터 다시 시작합니다.humanizer의 strict 모드는 일반 모드와 뭐가 다른가요?
PR이 자동으로 머지되나요?
gh pr merge는 설정 수준에서 막혀 있습니다.SVN 프로젝트에서도 사용할 수 있나요?
/gx-setup을 실행하면 VCS를 자동으로 감지합니다. SVN 프로젝트에서도 dev·tdd 파이프라인의 PRD·설계·구현·리뷰가 똑같이 동작하고, 커밋만 svn commit으로 직접 하면 됩니다. context·lens·research·humanizer 같은 다른 스킬도 모두 그대로 쓸 수 있습니다.플러그인 업데이트는 어떻게 하나요?
/plugin marketplace update oh-my-gx 를 실행하면 됩니다.지금 설치하고 한 줄로 시작하세요
Claude Code CLI에서 마켓플레이스를 추가하고 플러그인을 설치하면 그걸로 끝입니다.