oh-my-gx

---

설치

# Claude Code CLI에서 실행
/plugin marketplace add bs-koo/oh-my-gx
/plugin install oh-my-gx@oh-my-gx

시작

/oh-my-gx:setup

---

사용법

명령어를 외울 필요는 없습니다. 자연어로 말하면 의도에 맞는 스킬이 알아서 발동됩니다.

이렇게 말하면	발동 스킬
"기획서 보고 context 만들어줘"	context
"현재 로깅 정책 정리해줘"	lens
"대시보드 기능 개발해줘"	dev
"TDD로 결제 검증 만들어줘"	tdd
"실패 테스트 먼저 작성해줘"	red
"테스트 통과시켜줘"	green
"중복 제거 정리해줘"	refactor
"완료 검증해줘"	verify
"긴급 수정해줘"	dev (hotfix)
"PRD만 작성해줘"	dev / tdd (단일 단계)
"이어서 해줘"	dev / tdd (재개)
".dev/prd.md AI 흔적 교정해줘"	humanizer
"클라우드 네이티브 트렌드 조사해줘"	research
"기술 부채 확인해줘"	tech-debt
"교차 리뷰 해줘"	cross-review
"커밋해줘"	commit
"PR 만들어줘"	pull-request

개발 흐름

개발은 context → dev(또는 tdd)의 두 단계로 진행합니다. dev/tdd만 단독으로 써도 됩니다.

1. requirements/ 폴더에 기획서(PDF, 이미지, 텍스트)를 넣습니다
2. 준수해야 할 외부 규격 문서가 있다면 references/ 폴더에 넣어둡니다. 설계·구현·리뷰 단계에서 자동으로 참조합니다
3. "context 만들어줘"로 도메인 지식을 등록합니다
4. "개발해줘"(dev) 또는 "TDD로 개발해줘"(tdd)라고 하면 PRD → 설계 → 구현 → 리뷰 → PR까지 한 번에 이어집니다

단계와 단계 사이에는 사용자 승인이 필요합니다. 승인 없이 다음으로 넘어가는 일은 없습니다.

dev vs tdd — 어떤 걸 쓰나

둘은 PRD → 설계 → 구현 → 리뷰 → PR 골격을 공유하지만, 구현을 끌고 가는 방식이 정반대입니다. dev는 설계를 확정한 뒤 구현하고 사후에 검증하고, tdd는 실패 테스트를 먼저 쓰고 그걸 통과시키며 구현합니다.

	dev (설계 우선)	tdd (테스트 우선)
접근	설계 확정 → 구현 → 사후 검증	실패 테스트 먼저 → 통과시키며 구현
요구사항	자연어 수용 기준	Given-When-Then 강제 (자동 테스트로 변환 가능)
설계	비판 검토	+ testability 점수(7 미만이면 재설계)
구현	coder가 설계대로 한 번에	RED → GREEN → REFACTOR 격리 사이클
리뷰	qa + security 병렬	spec(AC) → quality(품질) 순차
완료	qa 통과 → commit	verify 게이트(실제 테스트 실행 증거) → commit
테스트	선택 — 있으면 좋음	필수 — 없으면 진행 불가

dev가 맞는 작업 — UI·화면 조정, 설정·문서·인프라 변경, 외부 시스템 연동, 빠른 프로토타입, 테스트 인프라가 없는 레거시처럼 자동 테스트로 명세를 떨어뜨리기 어렵거나 그럴 필요가 적은 작업.

tdd가 맞는 작업 — 결제·인증·정산 같은 핵심 비즈니스 로직, 계산·검증처럼 입출력이 명확한 로직, 회귀가 치명적인 모듈, 리팩토링(안전망 필요), 버그 수정(재현 테스트 먼저)처럼 정답을 자동 테스트로 표현할 수 있고 그래야 하는 작업.

한 줄 기준: "이 작업의 정답을 자동 테스트로 표현할 수 있고, 그래야 하는가?" → 예면 tdd, 아니오·애매하면 dev.

"TDD로", "테스트 먼저" 같은 명시적 키워드가 있으면 tdd로, 없으면 dev로 갈립니다. 애매하면 어느 방식으로 갈지 물어봅니다.

외부 규격 참조

프로젝트가 지켜야 할 외부 규격이 있다면 references/ 디렉토리에 문서를 넣어둡니다:

references/
├── 시큐어코딩-가이드.md
├── API-설계-표준.md
└── eGovFrame/
    └── 규칙.md

/gx-dev·/gx-tdd를 실행하면 설계·구현·리뷰 에이전트가 이 문서들을 자동으로 참조합니다. 없어도 동작하지만, 등록해두면 규격 준수 여부를 알아서 검증해줍니다.

기존 문서를 그대로 넣어도 됩니다. 다만 에이전트가 더 잘 찾아 쓰게 하려면 아래 팁이 도움이 됩니다:

• 문서 맨 위에 요약이나 목차를 두면 에이전트가 필요한 부분만 골라 봅니다
• 항목마다 번호나 ID(§3.2 등)를 붙이면 설계서에서 정확히 짚어 인용합니다
• 체크리스트 형태로 적어두면 QA가 항목별로 준수 여부를 확인합니다

---

스킬 상세

context

기획서, 요구사항 문서, 코드베이스를 분석해 도메인 지식을 context/{도메인}/에 등록합니다. 한번 등록한 context는 dev/tdd를 실행할 때 자동으로 참조됩니다.

"requirements 폴더에 있는 기획서 보고 context 만들어줘"   ← 문서 기반 생성
"사용량 분석 도메인 등록해줘"                            ← Q&A 기반 생성
"코드베이스 분석해서 context 자동 생성해줘"               ← 코드 스캔
"사용량 분석 도메인 동기화해줘"                          ← git 히스토리 기반 진행도 갱신

lens

코드에 묻혀 있는 비즈니스 정책을 찾아 PO/PD가 읽을 수 있는 보고서로 뽑아냅니다. 코드는 건드리지 않습니다. 변경 아이디어를 이어서 말하면 복잡도와 리스크 분석까지 해줍니다.

"현재 사용자 활동 로깅이 어떻게 되어 있는지 정리해줘"
"로그 보관 기간을 180일로 늘리면 어디에 영향이 가?"

dev

자연어 요청 한 줄이면 PRD 작성부터 PR 생성까지 전체 사이클이 돌아갑니다.

"사용량 분석 대시보드 기능 개발해줘"    ← 전체 사이클
"집계 스케줄러 오류 긴급 수정해줘"     ← hotfix 모드 (설계/리뷰 생략)
"PRD만 작성해줘"                     ← 특정 단계만
"이어서 해줘"                        ← 중단 지점부터 재개

내부에서는 에이전트 팀이 요구사항 → 설계 → 구현 → 리뷰 → 완료로 단계를 나눠 처리합니다. UI·설정·문서 변경, 외부 연동, 프로토타입처럼 자동 테스트로 명세를 떨어뜨리기 어려운 작업에 적합합니다. 정답을 테스트로 먼저 표현할 수 있는 작업이라면 tdd를 쓰세요.

tdd

dev와 같은 6단계 골격을 쓰지만 구현을 테스트가 끌고 가는 별도 파이프라인입니다. 실패 테스트를 먼저 쓰고(RED) 통과시키며 구현하고(GREEN) 정리하며(REFACTOR), 완료 전에는 verify 게이트를 반드시 통과해야 합니다. dev와 어떤 작업에 무엇을 쓸지는 위 dev vs tdd — 어떤 걸 쓰나 표를 참고하세요.

"TDD로 결제 한도 검증 만들어줘"      ← 전체 TDD 사이클
"테스트 주도로 로그인 개발해줘"

• requirements: 수용 기준(AC)을 Given-When-Then 형식으로 강제 (자동 테스트로 변환 가능)
• design: test-architect가 testability 점수(1-10)를 매기고, 7 미만이면 재설계
• implement: red-writer(실패 테스트) → green-coder(통과 최소 코드) → refactor-coder(정리)를 격리된 순서로
• review: spec-reviewer(AC 충족) → quality-reviewer(코드 품질) 순차 게이트
• complete: verify 게이트(신선한 테스트 실행 증거)를 통과해야만 commit/PR

보조 스킬 red / green / refactor / verify는 파이프라인 안에서 자동으로 불려 나오며, 단독으로도 쓸 수 있습니다.

humanizer

AI 글쓰기 패턴(40+가지, 한국어 K1K19 / 영어 E1E19 / 공통 C1~C6)을 감지하고 교정합니다. 모드는 세 가지입니다.

모드	동작
audit	감지 리포트만 (수정 안 함)
rewrite	감지 + 수정 + 변경률 상한(30% 경고 / 50% 중단)
strict	rewrite + 의미 보존 검증(humanizer-fidelity) + 과윤문 검토(humanizer-naturalness) + 단계별 산출물

"정밀/꼼꼼히/--strict"라고 명시하거나 입력이 8,000자를 넘으면 자동으로 strict로 올라갑니다. 한국어와 영어를 모두 처리하고, 블로그·에세이에는 "숨결 불어넣기"(개성·리듬 주입)를 적용합니다.