클로드를 고무오리처럼 쓰지 마세요: 실제 코드 리뷰 전략

Source: Dev.to

클로드처럼 고무 오리처럼 사용하지 마세요: 실제 코드 리뷰 전략

So you’ve started throwing your code at Claude or ChatGPT for reviews. Cool. But if you’re copy-pasting your entire 200-line function and waiting for generic comments, you’re wasting everyone’s time—including the AI’s.
Here’s what actually works.

클로드나 ChatGPT에게 코드를 던져 리뷰를 요청하기 시작했군요. 좋아. 하지만 전체 200줄짜리 함수를 복사 붙여넣고 Generic한 피드백만 기다린다면, 당신뿐 아니라 AI도时间的 낭비를 하는 겁니다.
실제로 통하는 방법은 이거다.

When you dump code and ask for feedback, you get feedback. Generic feedback. “Good variable naming here” and “Consider extracting this logic” and other things that read like they came from a linter output.
코드를 내놓고 피드백을 요청하면 피드백을 받는다. Generic한(일반적인) 피드백이다. ‘여기 변수 이름이 좋다’ ‘이 로직을 추출해라’ 같은 문장들이 리너스 출력처럼 보인다.

The AI doesn’t know what you’re worried about. Is the performance sketchy? Does the error handling suck? Are you confused about the logic? It’s guessing.
AI는 당신이 걱정하는 점이 무엇인지 알 수 없다. 성능이 의문스러운가? 오류 처리가 부족한가요? 로직이 복잡한가요? AI는 추측한다.

Bad: “Review this code”
나쁜 예시: ‘이 코드를 리뷰해줘’

Better: “I’m worried this function will timeout on large datasets. Walk me through the time complexity and suggest optimizations.”
좋은 예시: ‘대규모 데이터셋에서 이 함수가 타임아웃될까 걱정돼. 시간 복잡도를 설명하고 최적화 방법을 제시해줘.’

Bad: “Does this have any bugs?”
나쁜 예시: ‘이 코드에 버그가 있나요?’

Better: “I refactored our auth flow here. Are there edge cases around concurrent requests that would break this?”
좋은 예시: ‘인증 흐름을 여기서 리팩토링했어. 동시 요청 주변에 어떤 엣지 케이스가 이걸 깨뜨릴 수 있는지 확인해줘.’

Bad: “Is this readable?”
나쁜 예시: ‘이 코드가 읽기 쉬운가?’

Better: “This logic is getting complex. Can you explain what each section does in plain English, and if any part is confusing, suggest how to rewrite it.”
좋은 예시: ‘이 로직이 복잡해지고 있어. 각 부분을 평이한 영어로 설명하고, 어떤 부분이 혼동스럽다면 어떻게 다시 쓰면 좋을지 제안해줘.’

Specificity changes everything. The AI goes from guessing to actually helping.
구체성이 모든 것을 바꾼다. AI는 추측에서 실제 도움으로 바뀐다.

Here’s my workflow:
제 워크플로우입니다:

• Paste code + what I changed
  코드 붙여넣기 + 내가 변경한 내용

• Ask the AI to walk me through it - “What’s the execution flow here? Where could we hit edge cases?”
  AI에게 흐름을 설명하도록 요청 – “여기 실행 흐름은 어떻게 되는가? 어디서 엣지 케이스를 맞을 수 있을까?”

• Listen to what it says - Sometimes it catches something real. Sometimes it’s obviously wrong and that tells me something
  그 말을 들어라 – 가끔 실제 문제를 포착한다. 또 명백히 잘못된 경우도 있어 그 자체가 힌트가 된다.

• Make my own call - The AI isn’t the final authority; it’s a second set of eyes
  내 판단에 맡겨 – AI는 최종 권한이 아니라 두 번째 눈일 뿐이다

Example:
예시:

python
...

“I changed the payment retry logic from exponential backoff to fixed intervals.”
결제 재시도 로직을 지수 백오프에서 고정 간격으로 변경했습니다.

“Can you trace through what happens if a request fails 5 times in a row?”
요청이 5회 연속 실패하면 어떻게 되는지 추적해줘.

“Are there any issues with the new approach?”
새로운 방식에 문제점이 있는가?

The AI walks you through the logic. You spot problems. You learn something. This is how code review is supposed to work.
AI는 로직을 설명한다. 당신은 문제를 발견하고 배운다. 이것이 코드 리뷰가 의도한 방식이다.

Instead of pasting the new function, show the diff:
새로운 함수를 붙여넣기보다 디프(diff)를 보여줘:

python
...

Question: “Does this change the memory profile? Any performance difference?”
질문: ‘이 변경이 메모리 프로파일에 영향을 미치는가? 성능에 차이가 있는가?’

plaintext
The AI can see exactly what changed. Way easier to spot implications.
AI는 정확히 바뀐 부분을 볼 수 있다. 의미와 결과가 훨씬 쉬워진다.

This is underrated. Instead of asking for bugs, ask for failure modes:
이건 과소평가된다. 버그를 묻기보다 실패 모드에 대해 물어봐라:

“We’re using this to batch process 50,000 records at a time.”
우리는 한 번에 50,000개 레코드를 배치 처리하고 있어.

“What could break? What edge cases should we test?”
’무엇이 깨질 수 있을까?’ ‘어떤 엣지 케이스를 테스트해야 할까?’

The AI will walk through timeout scenarios, memory issues, partial failures, etc. You now have a checklist.
AI는 타임아웃 시나리오, 메모리 문제, 부분 실패 등을 설명한다. 이제 체크리스트를 갖게 됐다.

Sometimes you just want confirmation. That’s fine:
때로는 단순히 확인만 원할 때도 있다. 괜찮은 일이다:

“I think this recursive approach is correct, but I want a fresh pair of eyes.”
’이 재귀 접근법이 맞다고 생각해, 하지만 새로운 시선을 원해.’

“Walk through the base case and how it handles depth limits?”
베이스 케이스와 깊이 제한을 어떻게 처리하는지 추적해줘.

Quick, specific, useful.
빠르고 구체적이며 유용하다.

Stylistic nitpicks that don’t matter
의미가 없는 스타일적 미세한 수정들

Suggestions that change behavior without reason
이유 없이 동작을 바꾸는 제안들

Generic praise (“This is well-structured!”)
’이 구조가 잘 짜여졌어!’ 같은 일반적인 칭찬

Contradictions with your codebase’s actual patterns
코드베이스의 실제 패턴과矛盾 (실제 패턴과 배치)

You’re the expert. The AI is a tool. Use judgment.
당신은 전문가다. AI는 도구일 뿐이다. 판단을 사용해라.

The actual benefit of AI code review isn’t getting perfect feedback. It’s thinking through your own code while someone (or something) listens. Explaining your logic out loud catches gaps. Having it reflected back helps you spot assumptions you didn’t know you made.
AI 코드 리뷰의 실제 이점은 완벽한 피드백을 얻는 것이 아니라, 자신의 코드를 설명하면서 누군가가(또는 Something)가 듣고 있다는 점이다._logic를 크게 말하면 구멍이 드러나고, 그 결과를 되돌아보며 몰랐던 가정을 발견할 수 있다.

That’s worth the 30 seconds of prompting.
프롬프팅에 30초만 투자하는 게 충분히 가치있다.

If Claude wrote the code and you’re asking Claude to review it, you’re in a loop. Works okay for minor tweaks, but for serious review, paste it to ChatGPT, Claude’s competitor, or better yet, have a human look at it. Different perspectives catch different things.
클로드가 코드를 썼고 당신이 그 코드를 클로드에게 리뷰하도록 하면 루프에 빠진다. 작은 수정에는 괜찮지만, 진지한 리뷰는 ChatGPT(클로드의 경쟁자)에게 붙여넣거나, 더 나은 방법으로 인간에게 보여라. 다른 관점이 다른 것을 포착한다.

Want more on building with AI sustainably? Check out LearnAI Weekly newsletter for practical patterns and tools that actually save time.
지속 가능한 AI 활용법에 대해 더 알고 싶다면 LearnAI Weekly 뉴스레터를 확인해 보세요. 실제 시간 절약을 제공하는 실용적인 패턴과 도구를 제공합니다.