프롬프트가 아니라 프로세스 (Ⅲ): 커맨드로 완성하는 자동화 루틴

서론: "매번 똑같은 걸 설명하는 게 지겹다"

지난 글에서 다섯 가지 벽을 만들었다.
Git Hook, Claude Hook, ArchUnit, Gradle, 문서 자동 주입.

그런데 매번 반복되는 작업이 있었다:

• PR 올리면 Gemini가 리뷰 → 코멘트 읽기 → "나중에 봐야지" → 까먹음
• Jira 태스크 받음 → 브랜치 이름 뭐로 하지? → Todo 리스트 머릿속으로 정리 → 놓침
• 이슈 생김 → GitHub Issue 등록 → 또 Jira에 복붙 → 귀찮

문제는 "반복"이 아니라 "수동"이었다.

AI한테 매번 같은 걸 설명하는 건 비효율의 극치다.
그래서 커맨드를 만들었다.

 

 

1. Gemini 리뷰를 자동으로 처리하는 마법

 

문제 상황

gemini가 PR마다 리뷰를 달아준다:

사실 그전까지 깃허브의 코드 어시스턴트로 gemini 를 쓰면 리뷰를 공짜로 달아준대서 한번 써봤는데 이게 뭐 리뷰를 달아줘도

사실상 거의 보기도 힘들고 무쓸모라고 생각했었는데 절대 아니였다. 내가 단지 사용을 못했을뿐

 

실제 PR

 

 

 

gemini 리뷰 일부

 

 

 

뭐 보통 이런식으로 리뷰를 정말 고맙게도 달아주는데

• 코멘트가 많으면 우선순위 파악 불가
• 사람이 해준게 아니라 컴퓨터가 해줬다는 생각에  "나중에 봐야지" → 결국 안 봄
• 보기도 복잡함
• 어떤 걸 먼저 고쳐야 할지 판단 비용 발생

 

해결: /gemini-review 커맨드

# 현재 PR의 Gemini 리뷰 분석
/gemini-review

# 특정 PR 분석
/gemini-review 6

# Critical 항목만 자동 리팩토링
/gemini-review 6 --auto

 

실행 결과:

커맨드 등록하면 이런 내용까지 자기가 알아서 해준다.

 

공유에 감사함을 느끼는 gemini ㅋ

 

핵심 포인트

• 우선순위 자동 분류: Critical → Improvement → Suggestion
• 영향도 분석: "왜 이게 중요한가?" 자동 설명
• 실행 계획: 단계별로 뭘 먼저 할지 명확
• 시간 절약: 8개 코멘트 검토 5분 → 30초

Before:

[Gemini 코멘트 8개 읽기]
→ "어떤 게 중요한지 모르겠는데?"
→ "일단 나중에..."
→ 결국 안 함

 

After:

/gemini-review 6
→ "Critical 1개, 30분이면 끝나네"
→ 바로 수정
→ 품질 향상

 

2. Jira 태스크를 Todo 리스트로 변환

문제 상황

매 태스크마다:

1. Jira 열어서 설명 읽기
2. 브랜치 이름 뭐로 하지? 고민
3. "뭘 먼저 해야 하지?" 머릿속 정리
4. 작업 시작 → "아 이거 빠뜨렸네"

반복의 연속, 그리고 놓치는 것들.

해결: /jira-task 커맨드

실제 만든 jira-task 커맨드 수행 과정

 

Jira Task 내용:

 

생성된 Todo 리스트:

구구절절 설명하던 프롬프트가 커맨드 하나로 해결

 

핵심 포인트

• Jira → Git 자동 연결: 브랜치 체크아웃까지 자동
• Acceptance Criteria → Todo: 요구사항을 작업 단위로 쪼갬
• 헥사고날 순서: Domain → Application → Adapter 순서로 정렬
• 놓치는 거 없음: 테스트까지 Todo에 포함

Before:

[Jira 열기]
→ "아 이거 뭐 만드는 거였지?"
→ 브랜치: git checkout -b feature/... 어? 이름 뭐로 하지?
→ "뭘 먼저 해야 하나" (머릿속 정리)
→ 작업 시작
→ "아 테스트 깜빡했다"

 

After:

/jira-task AAA-5
→ 브랜치 자동 체크아웃
→ Todo 8개 자동 생성
→ 순서대로 체크하며 작업
→ 놓치는 거 없음

 

3. 이슈 → 태스크 → 개선의 선순환

실제 워크플로우

[다른 프로젝트에서 claude-spring-standards 사용]
    ↓
"아 이 Hook이 없으면 불편한데?"
    ↓
GitHub Issue 생성
    ↓
/jira-task로 변환 (또는 직접 Jira에 등록)
    ↓
작업 → PR → Merge
    ↓
템플릿 업데이트
    ↓
다른 프로젝트에도 적용

 

결과:

• 현재까지 13개 이슈 처리
• 템플릿이 점점 고도화
• 내가 겪은 불편함 = 남도 겪을 불편함 → 공유

예시: "ArchUnit 테스트 실패 메시지 개선" 이슈

문제:

$ ./gradlew test

> Task :bootstrap:test FAILED
Architecture Violation [Priority: MEDIUM] - Rule violated

 

개선 후:

$ ./gradlew test

> Task :bootstrap:test FAILED

❌ DOMAIN VIOLATION
   위치: domain/model/Upload.java:5
   문제: org.springframework.stereotype.Component 사용 금지
   
   Domain 레이어는 순수 Java만 사용해야 합니다.
   Spring 의존성 제거 후 다시 시도하세요.

 

과정:

1. 다른 프로젝트에서 불편함 발견
2. GitHub Issue: "ArchUnit 에러 메시지가 불친절함"
3. /jira-task 또는 직접 작업
4. PR → Merge
5. 템플릿 업데이트
6. 13개 이슈 중 하나 완료

커맨드의 본질: "설명하지 말고 실행시켜라"

프롬프트 vs 커맨드

프롬프트:

"Gemini가 리뷰한 PR 6번의 코멘트를 분석해줘.
각 코멘트를 Critical/Improvement/Suggestion으로 분류하고,
우선순위와 예상 시간을 포함한 실행 계획을 만들어줘."

 

커맨드:

/gemini-review 6

 

 

언제 커맨드를 만들어야 하는가?

3회 이상 반복되는 작업이면 커맨드로 만들어라.

 

체크리스트:

• 매번 같은 프롬프트를 쓰고 있는가?
• 도구 사용 순서가 정해져 있는가? (Jira → Git → Todo)
• 출력 형식이 일정한가? (항상 표로, 항상 리스트로)
• 에러 처리가 필요한가? (Jira 없으면 어떻게?)

하나라도 Yes면 커맨드 후보.

 

claude-spring-standards의 커맨드들

템플릿에 포함된 실제 커맨드:

1. /gemini-review

• 위치: .claude/commands/gemini-review.md
• MCP: sequential-thinking (다단계 추론)
• 도구: Bash (gh CLI), Grep, Read, Write

2. /jira-task

• 위치: .claude/commands/jira-task.md
• MCP: atlassian, serena
• 도구: Bash (git), TodoWrite

 

커맨드 구조 예시

---
description: Jira 태스크 분석 및 TodoList 생성
tags: [project, gitignored]
---

# Jira Task Analysis

## 입력 형식
- Jira URL 또는 이슈 키

## 실행 단계
1. Cloud ID 확인
2. Jira 이슈 조회
3. Epic 정보 조회
4. Git 브랜치 체크아웃
5. Todo 리스트 생성

## MCP 도구 사용 순서
1. mcp__atlassian__getAccessibleAtlassianResources
2. mcp__atlassian__getJiraIssue
3. Bash (git checkout)
4. TodoWrite

## 에러 처리
- Cloud ID 없음 → URL에서 추출
- 이슈 없음 → 확인 요청
- 브랜치 충돌 → 전략 확인

 

 

실전 루틴: 하루 개발 워크플로우

Morning: 오늘 뭐 할지 확인

# 1. Jira에서 오늘 할 태스크 확인
/jira-task KAN-7

# 2. 브랜치 자동 체크아웃 + Todo 생성
✅ 브랜치 체크아웃 완료
⏳ 8개 작업 항목 생성됨

 

Coding: Todo 따라 작업

⏳ 2. Domain: UploadCommand 정의
   → 구현
   → ✅ 완료

⏳ 3. Application: UploadUseCase
   → 구현
   → ✅ 완료

...

 

Pre-Commit: Hook이 자동 검증

$ git commit -m "feat: Upload 기능 구현"

🔍 Validating domain/model/Upload.java
✅ 모든 검증 통과
[feature/KAN-7 abc1234] feat: Upload 기능 구현

 

PR 생성 후: Gemini 리뷰 자동 분석

# PR 생성
$ gh pr create

# Gemini가 리뷰 달면
/gemini-review 8

📊 리뷰 요약
- Critical: 0개
- Improvement: 2개
- Suggestion: 3개

→ Improvement 2개만 수정
→ 10분 소요
→ 완료

 

이슈 발견 시: 바로 템플릿 개선

# "이 에러 메시지 불친절한데?"
$ gh issue create --title "ArchUnit 에러 메시지 개선"

# 나중에 작업
/jira-task (또는 직접 작업)

# PR → Merge → 템플릿 업데이트
# 13개 이슈 중 +1

 

 

이런 흐름으로 개발 루틴을 완성하면 압도적인 효율성을 발휘할 수 있다.