코드를 짜는 시간만큼 잡아먹는 게 테스트·문서·커밋입니다. 여기서 클로드 개발 생산성이 크게 갈립니다. 단위테스트 생성, README·docstring, 커밋메시지·PR 설명을 클로드에 맡기면 반복 작업이 확 줄어듭니다. 다만 그대로 믿지 말고 검수하는 게 핵심이에요. 항목별 프롬프트와 예시로 보겠습니다. (코드를 봐주게 시키는 법은 코드리뷰·디버깅 글을 참고하세요.)
1. 단위테스트 생성·보강
테스트는 “엣지 케이스부터” 시키면 가치가 큽니다. 예를 들어 이런 함수가 있다고 합시다.
function formatPrice(n) {
return n.toLocaleString('ko-KR') + '원';
}이렇게 물어보면 좋습니다.
“이 함수의 단위테스트를 만들어줘. 0·음수·소수·아주 큰 수 같은 엣지 케이스를 포함하고, 실패할 수 있는 케이스부터.”
클로드는 이런 결과를 줍니다.
test('기본 천 단위 콤마', () => expect(formatPrice(1000)).toBe('1,000원'));
test('0 처리', () => expect(formatPrice(0)).toBe('0원'));
test('음수 처리', () => expect(formatPrice(-5000)).toBe('-5,000원'));
test('소수점', () => expect(formatPrice(1234.5)).toBe('1,234.5원'));프롬프트는 이렇게 변형할 수 있습니다.
- 커버리지 보강 → “이 파일에서 테스트가 빠진 분기를 찾아 케이스를 추가해줘.”
- 회귀 방지 → “방금 고친 버그를 재현하는 테스트를 먼저 추가해줘.”
2. README·docstring·API 문서
문서는 코드를 근거로 쓰게 해야 어긋나지 않습니다. 함수 주석은 이렇게 시킵니다.
“이 함수에 JSDoc 주석을 달아줘. 매개변수·반환값·발생 가능한 예외를 포함해서.”
결과 예시입니다.
/**
* 숫자를 한국 원화 표기로 변환한다.
* @param {number} n - 변환할 금액
* @returns {string} 천 단위 콤마 + '원' (예: "1,000원")
*/
function formatPrice(n) { ... }README는 프로젝트 자료를 참고하게 합니다.
“이 저장소의 README 초안을 만들어줘. 설치·사용법·예시를 포함하고, package.json과 CLAUDE.md를 근거로.”
주의 — 문서는 코드와 어긋나기 쉽습니다. 항상 코드를 기준으로 검토하세요.
3. 커밋메시지·PR 설명
변경분(diff)을 보고 일관된 형식으로 쓰게 하면 커밋 품질이 올라갑니다.
“방금 변경(diff)을 보고 Conventional Commits 형식으로 커밋 메시지를 써줘. 제목은 50자 이내, 본문엔 ‘왜’ 바꿨는지.”
결과 예시입니다.
fix: 로그인 후 결제 시 흰 화면 버그 수정
user 데이터 로딩 전에 user.name에 접근하던 문제를
옵셔널 체이닝과 로딩 가드로 해결.PR 설명도 같은 방식으로 시킬 수 있습니다.
- PR 본문 → “이 브랜치 변경을 요약·테스트 방법·리스크로 나눠 PR 설명을 써줘.”
- 변경 로그 → “이번 릴리스 변경을 사용자 관점 changelog로 정리해줘.”
4. 반복 작업 루틴화
매번 시키지 않으려면 규칙으로 박아두세요.
- CLAUDE.md에 규칙 → “코드 수정 후에는 항상 관련 테스트를 실행한다” 같은 항목을 적어두면 자동 반영됩니다.
- 커스텀 슬래시 커맨드 → 자주 쓰는 작업을
.claude/commands에 템플릿으로 만들어 한 번에 호출합니다. - 훅(hooks) → 저장 시 포매터 자동 실행처럼 손 안 가는 자동화를 겁니다.
(CLAUDE.md·훅 기본은 Claude Code 워크플로우 글 참고.)
5. 검수 체크리스트 (맹신 금지)
자동화의 함정은 ‘그럴듯하지만 틀린’ 결과입니다. 발행·머지 전 이것만 확인하세요.
- 테스트 → 통과만 하는 빈 테스트가 아닌지, 단언이 의미 있는지.
- 문서 → 코드와 실제로 일치하는지(시그니처·예시).
- 커밋/PR → 실제 변경을 과장하거나 빠뜨리지 않았는지 diff와 대조.
- 결론적으로 클로드는 초안 생성기입니다. 최종 책임과 검토는 사람의 몫입니다.
마무리
테스트·문서·커밋은 “맡기되 검수”가 원칙입니다. 작은 자동화부터 CLAUDE.md·슬래시 커맨드·훅으로 루틴에 박아두면 생산성이 꾸준히 쌓입니다. 다음 글에서는 개발자가 실제로 쓰는 MCP·스킬·플러그인을 골라봅니다. 전체 로드맵은 개발자를 위한 클로드 활용법에서 볼 수 있습니다.
본 글은 정보 제공 목적이며, 클로드의 출력은 항상 검토가 필요합니다.