클로드는 코드를 새로 짜는 것만큼이나 이미 있는 코드를 봐주는 일에 강합니다. 클로드 코드리뷰, 디버깅, 리팩터링 세 가지는 입문자도 바로 효과를 보는 영역입니다. 핵심은 하나예요. 막연히 시키지 말고, 관점과 맥락을 주고, 결과를 검토하는 것. 항목마다 실제 예시로 보겠습니다. (Claude Code 기본기는 워크플로우 글을 먼저 보면 좋습니다.)
1. 코드리뷰 시키기 — “리뷰해줘”보다 ‘관점’을 줘라
그냥 “이 코드 리뷰해줘”는 두루뭉술한 답이 옵니다. 무엇을 볼지 기준을 주는 게 핵심입니다. 예를 들어 이런 코드가 있다고 합시다.
function getUser(id) {
const q = "SELECT * FROM users WHERE id = " + id;
return db.query(q);
}막연히 “리뷰해줘”라고 하면 “함수가 사용자를 조회합니다…” 같은 맥없는 답이 옵니다. 대신 이렇게 물어보면 좋습니다.
“이 함수를 ① 보안 ② 버그 가능성 ③ 가독성 순으로 리뷰해줘. 항목마다 문제 라인과 수정안을 짧게. 사소한 스타일은 빼고.”
그러면 클로드는 보통 이런 식으로 짚어줍니다.
- 보안(치명적) —
id를 문자열로 이어붙여 SQL 인젝션 위험. 파라미터 바인딩 사용 →db.query("SELECT * FROM users WHERE id = ?", [id])- 버그 —
id검증 없음. 숫자가 아닐 때 처리 필요.- 가독성 — 에러 처리(try/catch)·반환 타입 명시 권장.
프롬프트는 목적에 따라 이렇게 변형할 수 있습니다.
- 보안 집중 → “OWASP 관점에서 취약점만 심각도와 함께.”
- 머지 판단 → “이 PR diff만 보고 머지해도 될지 + 반드시 고쳐야 할 라인.”
- 초보 학습용 → “왜 문제인지 초보자도 알게 한 줄씩 이유를 붙여서.”
팁. 파일 전체보다 변경분(diff)·함수 단위로 줄수록 정확합니다.
2. 디버깅 — 에러·재현·기대 동작을 함께 줘라
디버깅은 정보가 절반입니다. 에러 전문 + 재현 단계 + 기대/실제 동작을 같이 주세요. 예를 들어 화면이 흰색으로 뜨고 콘솔에 다음 에러가 나온다고 합시다.
TypeError: Cannot read properties of undefined (reading 'name')
at UserCard (UserCard.jsx:12)이럴 때 이렇게 물어보면 좋습니다.
“위 에러가 난다. 재현: 새로고침 직후 발생, 잠시 뒤엔 정상. 기대: 사용자 이름 표시. 바로 고치지 말고 원인 가설을 가능성 순으로 2~3개 먼저 제시해줘.”
클로드는 보통 이런 답을 줍니다.
- (가장 유력) 데이터 로딩 전 렌더 —
user가 아직undefined인데user.name접근. →user?.name또는 로딩 가드.- API 응답 키 불일치(
userNamevsname).- 비동기 경쟁(이전 요청 응답이 늦게 도착).
가설이 맞으면 그때 “1번 방향으로 수정해줘”라고 이어가면 됩니다. ‘가설부터’ 시키는 것이 엉뚱한 수정을 막습니다. 프롬프트는 이렇게도 변형할 수 있습니다.
- 로그 추가 → “원인 좁히게 어디에 어떤 로그를 넣을지 알려줘.”
- 재현 코드 → “이 버그를 재현하는 최소 예제를 만들어줘.”
3. 리팩터링 — 반드시 ‘테스트’와 함께, 작게
리팩터링의 위험은 동작이 바뀌는 것입니다. 테스트를 두고 작게 합니다. 예를 들어 이런 중첩 if 덩어리가 있다고 합시다.
function discount(user) {
if (user) {
if (user.isMember) {
if (user.years > 5) { return 0.2 } else { return 0.1 }
} else { return 0 }
} else { return 0 }
}이럴 때 이렇게 물어보면 좋습니다.
“동작은 그대로 두고 가독성만 개선해줘. 먼저 현재 동작을 고정할 테스트부터 만들고, 통과하는 선에서 리팩터링해.”
클로드는 이런 결과를 줍니다.
// 1) 동작 고정 테스트
test('비회원/없음은 0', () => {
expect(discount(null)).toBe(0);
expect(discount({ isMember: false })).toBe(0);
});
test('회원 5년 초과는 0.2, 이하는 0.1', () => {
expect(discount({ isMember: true, years: 6 })).toBe(0.2);
expect(discount({ isMember: true, years: 3 })).toBe(0.1);
});
// 2) 조기 반환으로 정리
function discount(user) {
if (!user || !user.isMember) return 0;
return user.years > 5 ? 0.2 : 0.1;
}큰 모듈을 통째로 “예쁘게 바꿔줘”는 금물입니다. 검토가 어렵고 사고가 납니다.
4. 잘 안 되는 경우와 한계 (예시로)
- 없는 API를 지어냄(환각). 예를 들어 자바스크립트에 없는
array.sortBy()를 제안하기도 합니다. 실제로는array.sort((a,b)=>…)이죠. 처음 보는 메서드는 공식 문서로 확인하세요. - 버전 차이를 모름. 라이브러리 v3 문법을 주는데 내 프로젝트는 v2인 경우가 있습니다. “우리는 React Router v6야”처럼 버전을 알려주면 정확해집니다.
- 큰 변경에서 일부 누락. 파일 10개를 동시에 고치다 한 곳의 import를 빠뜨리기도 합니다. 변경 후 빌드·테스트로 확인하세요.
- 결론적으로 클로드의 제안은 초안입니다. 머지 전 사람 검토 단계를 생략하지 마세요.
5. 복붙용 프롬프트 모음
- 리뷰 → “이 diff를 보안·버그·성능·가독성 순으로 리뷰하고, 머지 가능 여부와 반드시 고칠 라인을 알려줘. 사소한 스타일은 제외.”
- 디버깅 → “[에러 전문 + 재현 + 기대/실제] 원인 가설을 가능성 순으로 먼저. 수정은 내가 고르면 그때 진행.”
- 리팩터링 → “동작 보존 + 테스트 동반으로, 작게 나눠 가독성 개선. 각 단계 설명.”
- 테스트 보강 → “이 함수의 엣지 케이스를 찾아, 먼저 실패하는 테스트부터 추가해줘.”
- 성능 → “이 코드의 시간복잡도를 분석하고, 병목과 개선안을 측정 가능한 형태로.”
마무리
세 작업의 패턴은 같습니다. 맥락을 주고 → 가설/계획부터 → 작게 → 검토. 다음 글에서는 테스트·문서·커밋메시지 자동화로 생산성을 한 단계 더 끌어올립니다. 전체 로드맵은 개발자를 위한 클로드 활용법에서 볼 수 있습니다.
본 글은 정보 제공 목적이며, 클로드의 출력은 항상 검토가 필요합니다.