“그거 또 해야 해?”를 없애는 법: Claude Code Commands로 개발 워크플로우 자동화하기

LinkDropper·2025년 12월 19일

AI Claude Link Dropper

Others

목록 보기

5/9

들어가며

개발하면서 진짜 자주 드는 생각이 있어요.

“테스트… 또 써야 하지?”
“PR 본문… 또 정리해야 하지?”
“리뷰 코멘트… 또 반영하고 답글 달아야 하지?”

문제는 이 작업들이 매번 조금씩 다르지만, 패턴은 거의 동일하다는 겁니다.
그래서 저는 Claude Code의 Custom Commands 기능을 이용해, 반복되는 흐름을 명령어 5개로 고정해버렸습니다.

이 글에서는 “어떤 명령어를 어떻게 묶어서” 개발 워크플로우 전체를 자동화했는지, 그리고 왜 이 방식이 생각보다 강력했는지를 벨로그 스타일로 편하게 공유해볼게요.

Claude Code의 Custom Commands란?

Claude Code에서는 .claude/commands/ 폴더에 마크다운 파일을 만들어두면, 터미널에서 /명령어 형태로 실행할 수 있어요.

.claude/
└── commands/
    ├── spec.md          # /spec으로 실행
    ├── create-jest.md   # /create-jest로 실행
    ├── w-context.md     # /w-context로 실행
    ├── pr.md            # /pr로 실행
    └── apply-review.md  # /apply-review로 실행

포인트는 이겁니다.

“스크립트를 짜는 게 아니라, 작업 지시서를 마크다운으로 적는다.”

즉, 마크다운 안에 자연어로
“이 상황에서는 이렇게 분석하고, 이런 규칙을 따라, 이런 결과를 만들어줘”
라고 적어두면 Claude가 그걸 그대로 실행 가능한 워크플로우로 돌려줍니다.

내가 자동화한 개발 워크플로우 (한 장 요약)

제가 만든 명령어 5개는 개발 사이클을 처음부터 끝까지 커버합니다.

기능 명세서 작성
      ↓
  ① /spec         →  명세서 기반 코드 구현
      ↓
  ② /create-jest  →  테스트 코드 자동 생성
      ↓
  ③ /w-context    →  AI용 문서(CONTEXT.md) 작성
      ↓
  ④ /pr           →  커밋 & PR 생성
      ↓
  ⑤ /apply-review →  코드 리뷰 자동 반영

여기서 중요한 건, 이 흐름이 “AI가 똑똑해서 알아서”가 아니라
명령어마다 역할과 규칙을 명확히 분리해두었기 때문에 안정적으로 돌아간다는 점이에요.

그럼 각각을 짧게 살펴볼게요.

1) `/spec` — 명세서 기반 코드 구현

한 줄 요약: 명세서를 주면, 구현을 “절차적으로” 끝냅니다.

/spec user-auth  # specs/user-auth.md를 읽고 구현

specs/ 폴더에 기능 명세서를 마크다운으로 작성해두면, Claude가 아래처럼 단계적으로 구현합니다.

Phase 0: 명세서 로드
Phase 1: 명세서 분석 및 이해
Phase 2: 구현 전 검토 (질문 필요 시)
Phase 3: 구현 계획 수립
Phase 4: 코드 구현
Phase 5: 검증 (타입 체크, 린트)

제가 느낀 체감 포인트는 두 가지였어요.

“바로 코딩”이 아니라 “이해→계획→구현→검증”이 강제됨
결과가 코드만 던지고 끝이 아니라, 생성 파일/검증 결과/사용 예시까지 보고서처럼 나옴

즉, 단순 생성기가 아니라 “개발 프로세스”를 명령어에 박아둔 느낌입니다.

2) `/create-jest` — 테스트 코드 자동 생성

한 줄 요약: git diff 기준으로 바뀐 파일을 잡고 테스트를 만들어줍니다.

/create-jest  # git diff 기반으로 테스트 대상 파일 자동 감지

특히 마음에 들었던 건 “테스트 대상 선정”을 규칙으로 박아둔 부분이에요.

libs/, hooks/, utils/, services/ 등 테스트 대상 폴더를 정의
__tests__/에 테스트 파일 생성
테스트명은 한글로 (it("사용자를 생성한다", ...))
AAA 패턴(Arrange-Act-Assert) 적용

이렇게 해두면, 테스트를 “쓸지 말지 고민”하는 단계가 줄어듭니다.
그냥 변경되면 → 테스트가 생깁니다.

3) `/w-context` — AI를 위한 문서(CONTEXT.md) 작성

한 줄 요약: 주석 대신, “모듈의 설계 의도”를 문서로 남깁니다.

/w-context  # 현재 폴더에 CONTEXT.md 생성

이건 생각보다 효과가 컸어요.
코드는 시간이 지나면 “왜 이렇게 했지?”가 남는데, 그걸 보통 주석이나 위키로 해결하려다 실패하잖아요.

/w-context는 아예 AI가 다음 수정 때 읽을 문서를 만들어줍니다.

이 모듈이 하는 일 (한 문장)
파일 구조와 역할
핵심 설계 결정
사용 패턴 예시
확장 시 고려사항

결과적으로 다음 작업에서 Claude가 맥락을 먼저 잡고 들어오니까,
수정 품질이 확 좋아지더라고요.

4) `/pr` — 커밋 & PR 생성

한 줄 요약: 변경사항을 분석해서 “커밋하고 PR까지” 올려줍니다.

/pr  # 자동으로 브랜치 생성, 커밋, PR 생성

PR은 사실 코딩보다도 피로도가 큰 작업이죠.

브랜치 이름 자동 생성 (feature/, fix/, hotfix/)
변경사항을 논리 단위로 나눠 커밋
PR 제목/본문 자동 작성
gh CLI로 GitHub 연동

커밋 메시지 포맷도 프로젝트 규칙으로 고정했습니다.

[카테고리] 작업 제목

작업 설명 (복잡한 변경일 경우에만)

이렇게 해두면 PR 품질이 개인 컨디션에 따라 흔들리지 않습니다.
“늘 일정한 수준”으로 나오는 게 팀에서는 진짜 큰 장점이에요.

5) `/apply-review` — 코드 리뷰 자동 반영

한 줄 요약: 리뷰 코멘트를 읽고 “반영/거절/답글”까지 처리합니다.

/apply-review  # 현재 브랜치의 PR 리뷰를 가져와서 처리

제가 이 명령어에서 제일 중요하게 둔 건 “무조건 반영”이 아니라, 판단 기준을 넣는 것이었습니다.

적용하는 경우

버그 지적, 보안 이슈, 성능 문제
코드 컨벤션 위반, 가독성 개선

거절하는 경우

단순 취향 차이
과도한 추상화 요청
PR 범위를 벗어난 리팩토링 요청

그리고 반영 후엔 PR에 자동으로 답글도 남깁니다.

“반영했습니다”
혹은 “이번 PR 범위를 넘어선 변경이라 다음 작업으로 분리하겠습니다” 같은 거절 사유

리뷰 대응에서 에너지가 많이 빠지는데, 이걸 “규칙화” 해두니까 팀 커뮤니케이션도 훨씬 매끄러워졌어요.

왜 이 방식이 효과적이었나

1) 자연어로 정의되는 “팀의 규칙”

스크립트는 유지보수 비용이 커요.
그런데 마크다운 지시서는 읽고 고치기 쉬워서 팀 규칙을 담기에 좋습니다.

2) 프로젝트 맞춤형 커스터마이징이 쉬움

커밋 메시지 규칙
폴더 구조
테스트 스타일(한글 테스트명, AAA 패턴)

이런 것들이 “우리 팀 방식”인데, 명령어로 고정해두면 신규 인원 온 날부터 바로 맞춰집니다.

3) 개선 루프가 빠름

명령어가 마음에 안 들면?

.md 파일 열고
문장 몇 줄 고치고
다시 실행

피드백 반영 속도가 빨라서 “우리 팀에 맞는 자동화”로 점점 진화합니다.

4) 공유가 쉽다

.claude/commands/를 Git에 올리면 끝입니다.
온보딩 문서에 “이거 하세요” 적는 것보다, 명령어로 강제하는 게 더 강력하더라고요.

시리즈 안내

이 글은 전체 개요이고, 다음 글부터는 각 명령어를 더 깊게 파볼 예정입니다.

순서	제목	내용
1편	Claude Code Commands로 개발 워크플로우 자동화하기	전체 개요 (현재 글)
2편	/spec - 명세서 기반 코드 구현 자동화	가장 핵심인 구현 자동화
3편	/create-jest - 테스트 코드 자동 생성	테스트 작성 자동화
4편	/w-context - AI를 위한 문서 작성	CONTEXT.md 개념과 활용
5편	/pr + /apply-review - PR 워크플로우 자동화	PR 생성부터 리뷰 반영까지

마치며

Custom Commands는 “AI 기능”이라기보다, 제게는 개발 프로세스를 마크다운으로 코드화하는 도구처럼 느껴졌습니다.

반복 작업을 줄이는 수준을 넘어서
팀의 컨벤션과 판단 기준을 명령어로 고정하고
결과 품질을 일정하게 만들 수 있었거든요.

다음 글에서는 가장 핵심인 /spec를 깊게 다뤄보겠습니다.
명세서를 어떻게 써야 Claude가 덜 헤매는지, 그리고 실제로 어떤 흐름으로 구현이 진행되는지 예시까지 포함해서 정리해볼게요.

10. 🧪 링크 드라퍼, 정식 출시!

링크 드라퍼는 단순한 저장 툴이 아닙니다.
정리하고, 다시 꺼내보게 만드는 링크 관리 도구를 지향하고 있어요.

🔗 빠르고 간편한 링크 저장
iOS/Android 앱, 웹, 크롬 익스텐션 어디서든 바로 저장
🧠 폴더별로 깔끔하게 정리
읽을 거리, 레퍼런스, 쇼핑 후보까지 주제별 정리
🌐 폴더를 친구에게 공유
같이 보는 자료는 폴더 단위로 링크 한 번에 공유
⚡ 크롬 익스텐션 원클릭 저장
지금 보고 있는 페이지를 버튼 한 번으로 저장

👉 링크 드라퍼 앱 다운로드 (iOS)
👉 링크 드라퍼 웹에서 사용하러 가기
👉 크롬 웹스토어에서 익스텐션 설치하기