Claude를 러버덕(Rubber Duck)처럼 사용하지 마세요: 실제적인 코드 리뷰 전략

이제 Claude나 ChatGPT에 코드를 던져 리뷰를 받기 시작하셨군요. 좋습니다. 하지만 200줄짜리 함수 전체를 복사해서 붙여넣고 일반적인 코멘트만 기다리고 있다면, 여러분은 AI를 포함한 모두의 시간을 낭비하고 있는 것입니다.

실제로 효과가 있는 방법은 다음과 같습니다.

"이것 좀 리뷰해 줄래?"의 문제점

코드를 통째로 던지며 피드백을 요청하면, 피드백을 받기는 합니다. 하지만 일반적인(Generic) 피드백이죠. "변수 명명법이 좋습니다"라거나 "이 로직을 추출하는 것을 고려해 보세요"와 같이 마치 린터(Linter) 출력 결과처럼 보이는 내용들 말입니다.

AI는 여러분이 무엇을 걱정하고 있는지 모릅니다. 성능이 불안한가요? 에러 핸들링(Error handling)이 엉망인가요? 아니면 로직이 헷갈리나요? AI는 그저 추측하고 있을 뿐입니다.

의도를 담아 프롬프트(Prompt) 하세요

나쁜 예: "이 코드 리뷰해 줘"
더 나은 예: "이 함수가 대규모 데이터셋에서 타임아웃(Timeout)이 발생할까 봐 걱정됩니다. 시간 복잡도(Time complexity)를 단계별로 설명해 주고 최적화 방안을 제안해 주세요."

나쁜 예: "여기에 버그가 있나요?"
더 나은 예: "여기서 인증 흐름(Auth flow)을 리팩터링(Refactor)했습니다. 동시 요청(Concurrent requests) 상황에서 이 로직을 깨뜨릴 만한 엣지 케이스(Edge cases)가 있을까요?"

나쁜 예: "이거 읽기 쉬운가요?"
더 나은 예: "이 로직이 점점 복잡해지고 있습니다. 각 섹션이 무엇을 하는지 쉬운 영어로 설명해 주고, 만약 혼란스러운 부분이 있다면 어떻게 다시 작성할지 제안해 주세요."

구체성이 모든 것을 바꿉니다. AI는 추측하는 단계에서 실제로 도움을 주는 단계로 넘어갑니다.

사고를 대체하지 말고, 설명을 위해 사용하세요

저의 워크플로우(Workflow)는 다음과 같습니다:

1. 코드 + 변경 사항 붙여넣기
2. AI에게 단계별 설명을 요청하기 - "여기서 실행 흐름(Execution flow)이 어떻게 되나요? 어떤 엣지 케이스(Edge cases)가 발생할 수 있을까요?"
3. AI의 답변을 경청하기 - 때로는 AI가 진짜 문제를 잡아내기도 합니다. 때로는 AI가 명백히 틀리기도 하는데, 그 사실 자체가 저에게 무언가를 알려줍니다.
4. 스스로 결정하기 - AI는 최종 권위자가 아닙니다. 단지 두 번째 눈(Second set of eyes)일 뿐입니다.

예시:

결제 재시도 로직을 지수 백오프(Exponential backoff)에서 고정 간격(Fixed intervals)으로 변경했습니다.
요청이 연속으로 5번 실패할 경우 어떤 일이 발생하는지 추적해 줄 수 있나요?
새로운 방식에 어떤 문제가 있을까요?

AI가 논리 과정을 안내합니다. 당신은 문제를 발견합니다. 무언가를 배웁니다. 이것이 코드 리뷰 (Code Review)가 작동해야 하는 방식입니다.

실제로 효과가 있는 세 가지 패턴

패턴 1: Diff + Context (차이점 + 문맥)

새로운 함수를 통째로 붙여넣는 대신, 차이점 (Diff)을 보여주세요:

변경 전:

for user in users:
    if user.premium:
        process(user)

변경 후:

premium_users = [u for u in users if u.premium]
for user in premium_users:
    process(user)

질문: "이 변경이 메모리 프로필 (Memory Profile)을 변화시키나요? 성능 차이가 있을까요?"

AI는 무엇이 정확히 바뀌었는지 볼 수 있습니다. 그로 인한 영향 (Implications)을 파악하기가 훨씬 쉬워집니다.

### 패턴 2: "무엇이 잘못될 수 있는가 (What Could Go Wrong)"

이 방식은 과소평가되어 있습니다. 버그를 찾아달라고 요청하는 대신, 실패 모드 (Failure Modes)를 물어보세요:

우리는 이것을 한 번에 50,000개의 레코드를 배치 처리 (Batch Process)하는 데 사용하려고 합니다.
무엇이 망가질 수 있을까요? 어떤 엣지 케이스 (Edge Cases)를 테스트해야 할까요?

AI는 타임아웃 (Timeout) 시나리오, 메모리 문제, 부분적 실패 (Partial Failures) 등을 짚어줄 것입니다. 이제 당신에게는 체크리스트가 생겼습니다.

패턴 3: 러버 스탬프 (The Rubber Stamp)

때로는 단순히 확인만 받고 싶을 때가 있습니다. 그래도 괜찮습니다:

이 재귀적 (Recursive) 접근 방식이 맞다고 생각하지만, 새로운 시각으로 확인하고 싶습니다.
기본 케이스 (Base Case)와 깊이 제한 (Depth Limits)을 어떻게 처리하는지 설명해 줄 수 있나요?

빠르고, 구체적이며, 유용합니다.

무시해야 할 것들

• 중요하지 않은 스타일 관련 지적 (Stylistic Nitpicks)
• 이유 없이 동작을 변경하려는 제안
• 일반적인 찬사 ("구조가 잘 잡혀 있네요!")
• 당신의 코드베이스 (Codebase) 실제 패턴과 모순되는 내용

당신이 전문가입니다. AI는 도구일 뿐입니다. 판단력을 발휘하세요.

진정한 승리

AI 코드 리뷰의 실제 이점은 완벽한 피드백을 받는 것이 아닙니다. 그것은 누군가(또는 무언가)가 듣고 있는 동안 자신의 코드를 깊이 생각하는 것입니다. 자신의 논리를 소리 내어 설명하다 보면 빈틈을 발견하게 됩니다. AI가 이를 다시 반영해 줄 때, 당신이 인지하지 못했던 가정 (Assumptions)들을 찾아내는 데 도움이 됩니다.

그것만으로도 프롬프팅 (Prompting)에 쓰는 30초의 가치는 충분합니다.

보너스: AI가 작성한 코드를 AI에게 리뷰해달라고 하지 마세요

만약 Claude가 코드를 작성했는데 당신이 Claude에게 그 코드를 리뷰해달라고 요청하고 있다면, 당신은 루프 (Loop)에 빠진 것입니다. 사소한 수정 (Minor tweaks)에는 괜찮을 수 있지만, 진지한 리뷰를 원한다면 ChatGPT와 같은 Claude의 경쟁사에게 붙여넣거나, 더 나은 방법으로는 사람이 직접 확인하게 하세요. 서로 다른 관점 (Perspectives)이 서로 다른 문제들을 잡아낼 수 있습니다.